Heltec Wireless Tracker (v1.1) GPS module resets periodically on USB-only power

allanmac commented 1 month ago

Here are a number of issues I observed when powering the Wireless Tracker with USB-C and no battery.

After "turning off screen" is logged, VEXT drops to 1.48V instead of 0V.
I haven't measured VEXT with a battery attached.
Once the screen is blanked/off, VEXT periodically cycles between 1.48V and 3.3V.
The UC6580 will stop transmitting NMEA sentences on GNSS_TX and has maybe browned out at 1.48V. The 3.3V supply never drops out.
After 10+ seconds (10-30s?), VEXT returns to 3.3V while the screen remains blanked/off.
The UC6580 emits its product info "boot" message and begins emitting all the default sentences.
The brown out / reset results in all of the NMEA message output configuration settings ($CFGMSG) being lost so there is a verbose stream of sentences being transmitted.
According to the manual, V_BACK will maintain RTC, almanac, and ephemeris data but not other settings.

Again, I have only observed this when powering the Tracker solely with USB-C.

Perhaps it's a board design issue and/or the expectation is that there is always a battery or a VDD_5V supply?

Of less importance:

According to the Unicore Firebird II Protocol Specification doc, a $CFGSYS,hXXXXX implicitly resets the UC6580 GNSS module and any other prior settings will be lost and would be need to replayed.
You can try this and you will see the boot info replayed.
The "enable everything" $CFGSYS,h35155 command is likely unnecessary as the module defaults to this configuration and the default enables all possible constellations. This can be confirmed by a $CFGSYS query.

Of even less importance:

The on-screen GPS count appears to be "latched" to the last successful fix.
If GPS lock is lost then the display still shows the count of the last fix ($GNGGA).
This might be by design? I'd still like to know if I have lock or not. This observation might be a result of the UC6580 resetting and not the norm.

fifieldt commented 1 month ago

Thank you for the detailed investigation. I hope to get some time to confirm soon.

Regarding setting $CFGSYS,h35155 , we probably need to keep that for now since previously we were setting something different!

allanmac commented 1 month ago

It appears I can repro this on battery + USB as well.

Maybe the summary here is that given there is no choice but to power off the UC6580 module along with the OLED/etc. then the NMEA verbosity should be cranked down once the module restarts.

I'm still surprised about the ~1.5V on VEXT (physical PIN 7).

HarukiToreda commented 1 month ago

yeah this is unfortunately a poorly designed board for this specific problems, no amount of coding will be able to resolve it. We should honestly remove it from the list of supported boards.

allanmac commented 1 month ago

I hope I measured everything correctly. :pray:

Still very impressed with the GNSS module! It's excellent outside.

My current solution is a 4500 mAh battery and never powering off the display! It lasts for a long time. :rofl:

allanmac commented 1 month ago

The code shows the GPIO GNSS_RST (PIN 35) is driven low for 10 ms. to reset the UC6580 module's RESETN pin and then left high... forever.

The schematic shows the GNSS RESETN pin is normally pulled high by the 3.3V VEXT and driving it low via GNSS_RST works as expected.

But when VEXT is grounded by the regulator controlled by VEXT_CTRL, I think GNSS_RST is left high.

I'll keep digging...

fifieldt commented 3 weeks ago

I've been trying to get the GPS to go nuts and reset to factory defaults as described through various means, but haven't been able to :(

fifieldt commented 3 weeks ago

Ah, got it. I can see after we come back from HARDSLEEP, GNGSA messages are present, which we turn off as part of our config. So we are indeed losing some config.

INFO | 12:26:07 933 [GPS] GPS power state moving from HARDSLEEP to ACTIVE

DEBUG | 12:26:08 934 [GPS] 

DEBUG | 12:26:08 934 [GPS] 

DEBUG | 12:26:08 934 [GPS] ..UC6580I G1B1L1E1 COM1..PN 2400615000268..SN 20230316152842005..HWVer 00..FWVer R6.0.0.0Build2810..Copyright (c), Unicore Communications Inc...All rights res

DEBUG | 12:26:08 934 [GPS] 

DEBUG | 12:26:08 935 [GPS] 

DEBUG | 12:26:09 935 [GPS] 

DEBUG | 12:26:09 935 [GPS] $GNRMC,,V,,,,,,,,,,N,V*37..$GNGGA,,,,,,0,00,99.99,,,,,,*56..$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,1*33..$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,2*30..$GNG

DEBUG | 12:26:09 935 [GPS]

fifieldt commented 3 weeks ago

So, potential solution - given it looks like there's nothing we can do to make the sleep better: run the setup code again to configure the GPS?

allanmac commented 2 weeks ago

I've also been pulling PIN_GPS_RESET low before deep sleep.

I need to take a look at this with my scope.

meshtastic / firmware

Heltec Wireless Tracker (v1.1) GPS module resets periodically on USB-only power #5088