In regards to my SIM7600E-H 4G HAT. While the module responds to standard AT commands over serial, I’m running into persistent issues with the GPS functionality and suspect a firmware limitation may be the cause.
Here’s a summary of the testing I’ve done:
Basic Communication:
AT → responds OK
AT+CGPS=1 → responds OK
AT+CGPSINFO → always returns the same coordinates:
+CGPSINFO: 2643.036061,S,15307.951612,E
These coordinates do not change, regardless of the module’s actual location, even after waiting outdoors under clear sky conditions for over 15 minutes.
Failing or Unsupported Commands:
AT+CGPSSTATUS? → returns ERROR
AT+CGPSPWR? → returns ERROR
AT+CGNSPWR=1 → returns ERROR
AT+CGNSINF → returns ERROR
This suggests the GPS subsystem is either not fully powered on or not supported by the currently installed firmware.
Hardware Setup:
The active GNSS antenna is correctly connected to the GNSS SMA port (not MAIN)
The SIM7600E-H is wired via GPIO serial (TXD: GPIO15, RXD: GPIO14)
I’m using it with a Raspberry Pi 4B and powering it via GPIO with solid PWR and flashing NET LEDs
Any advice on the following:
Is this behavior expected from the factory firmware on the SIM7600E-H module?
Does this module require a firmware reflash to properly enable GPS/GNSS functionality?
If so, does anyone have GNSS-enabled firmware and instructions for updating?
Just quickly wanted to confirm you have the SIM7600E (Asia), not the G(lobal) version?
Would it be possible to send a link through to where you purchased it
Would it be possible to send through a photo of your setup?
Have you configured any jumpers on the yellow pins up top?
It sounds like there might be a filter running on the module with a random location - but it isn’t updating
Defintely not, provided all of the other instructions are followed - you should be able to get a fix.
Is there any additional info when you enter the command: AT+CGPSINFO
In theory, I cant imagine it should - the OEM of the HAT might have some listed on their resources page? But the problem ought to be fix-able without flashing new firmware.
Great to be here! Shame I didn’t find this earlier, I’ve been doing fair bit of head banging to make heads or tails of it all.
-It’s for sure the Asia one (MiniCom has confirmed this as the SIMCOM_SIM7600E-H)
-I’ve dug through the trash and it seems I bought it when I went on a tear on AliExpress (Sorry, straight to the naughty corner now)
-I’ve got jumpers on GND, 5v, TXD and RXD (both TX and RX are the reciprocal on the Pi), and PWR to a GPIO (to pulse on startup to start the 7600 on pi Boot) On the flip side, I have tried the UART jumpers on the 7600 itself, with the 2 little bridges. I even tried both jumpers and bridges, didn’t work before, surely it couldn’t hurt to try (this may have been the wrong attitude to take though…)
All that is shown for AT+CGPSINFO is the following.
AT+CGPSINFO
A firmware upgrade is usually required to enable full GNSS functionality. Fortunately, SIMCom does release GNSS-enabled firmware, although not all board vendors flash them.
Yeah thats exactly how it’s powered a the moment, being a HAT built specificatically for that 40 pin GPIO. There’s a 5v yellow pin that I was under the assumption can be used to power the HAT. There is a micro USB on the side of it though. Are you thinking it needs to be connected to a power source there in addition to the 5v PWR or lieu of the 5v pin?
Roger, that may be my last ditch effort to reflash If thats the case, any idea where I can find the necessary bits to do it or is there a trusted process anyone has followed?
I have also contacted Waveshare direct, but theyre saying 2 day return on contact support and were rolling into the weekend, so I dont anticipate hearing back from them for a good 2-3 days.
Hi Danny
Jeff has answered that question. The post reads like you are using an actual “GPIO” pin. I don’t think that is the case. More like a “power” pin, not an actual GPIO (General Purpose IN Out. (I think)) pin.
Cheers Bob
That’s splitting hairs. Perhaps it should be called GP/IO, but I think most people understand that the term covers a number of different GP ports, not just IO.
Hi Jeff
I have not bothered to look at the pin out diagram for those units but I would be very surprised if the pin under question would be called “GPIO”.
I don’t think that would be correct. Most pins labeled as such carry a number like GPIOXX and has been pointed out repeatedly this number might have nothing in common with the board pin number. It is usually also stated these pins should NOT be used to power anything.
I was just pointing out that using this term for a power pin could cause some (like me) to think Danny’s problem might be lack of power. I mistakenly missed the fact that this is a “Hat”, I will put my hand up for that, but reading some of these posts leads me to believe that some hats and the board pin outs are not necessarily compatible.
So, just for a change how about some accuracy with pin terminology. Would save all this to-ing and fro-ing.
Cheers Bob
Then please do so. For instance: Raspberry Pi hardware - Raspberry Pi Documentation
Under the heading GPIO is listed, for each device, “40-pin GPIO Header” or “26-pin GPIO Header”, and so on. These headers include IO ports, 5V, 3.3V and Gnd. Or, look at the UNO - the GPIO headers there include ARef, Reset and VIN as well as 5V, 3.3V and Gnd. The GPIO pins on almost any MCU development module will include a number of things other than IO ports - they are General Purpose. It is very common to use GPIO pins for suppling voltage and ground to attached devices, either via a HAT as in this case or as individual connections.
This clearly shows
2 X 5V
2 X 3V3
8 X Ground
2 X Advanced use only
In no way could you define these pins as “General Purpose”
So I will stand by my statement.
Also Danny says above
Where does he find a 5V “Yellow” pin on that above diagram. I can’t see one. Maybe I am going blind.
Anyway argument closed for now. I am off the Brisbane to-morrow and unless I can find a computer or at least WiFi I am out of here fora couple of weeks.
Cheers Bob
We’re all in a community that’s here to help, not squabble. Wish I was here to catch it earlier to keep this chat productive and moving forward. I’m only new to this world so my wording may be a little off kilter. It’s a 40 pin header but only 26 are programable IO pins, the remaining are either 3.3 or 5 or GND.
The yellow pin is on the Sim7600 hat that is marked in the photo jumped straight to a 5v header pin. The other jumper on PWR (on the SIM hat) is to a programmed IO pin to pulse on start to automatically start the NET (i assume network) led flashing rather than manually pulse.
Hi Danny
Sorry about the “squabble”.
I know not much about RPi. Just about enough to stay away which I intend to do in the future on this Forum.
The following started it all
I know enough to realise the GPIO will not power ANYTHING above maybe a LED or opto coupler so you statement above stood out like a neon sign.
Sorry that my clairvoyant powers are just about nil and I took this statement at face value and suggested the power availability might be a bit light and contribute to the problem.
I apologise once again for apparently starting this “squabble” but I grew up in this business where there were almost no “Grey” areas. If there were you did your best to fix them.
Trying to Guess exactly what is going on does not help anyone.
Cheers Bob
The SIM7600 can draw up to 2A in bursts, especially when connecting to a mobile network. If you’re powering the Pi and the HAT from a standard USB-C power supply, make sure it’s rated for at least 3A and of good quality. Undervoltage can cause instability that’s hard to track down.
Thanks Ryan, I did have dramas at the start with a DAC HAT and that exact problem so invested in a raspberry pi 5v5a wall charger in hopes it would solve all dramas.
With a 2amp pulse, it might be worth my while plugging in the charger to the SIM7600 direct in case I’m overloading the GPIO as mentioned above.
