firmware icon indicating copy to clipboard operation
firmware copied to clipboard

[Board]: heltec tracker v1.2. gps works w 2.7.3 and 2.7.4 but no lock with 2.7.5

Open gaspo1sky opened this issue 4 months ago • 20 comments

SOC

ESP32

Lora IC

sx1262

Product Link

https://www.amazon.com/dp/B0D2WZG1N6

Description

received heltec tracker v1.2 from amazon. loaded 2.7.3 from linux cli. ble, wifi, gps, lcd, lora all work fine. 2.7.4 is also ok. but w 2.7.5, gps shows no sats. i tried gpsrx 33, gpsrx 34, gpsen3, and it goes into a boot loop after displaying M logo. (got that from here https://github.com/HelTecAutomation/HeltecDocs/blob/master/doc/node/esp32/source/wireless_tracker/meshtastic_tracker.md)

also, i tried setting display to "color" (heltec stock firmware is in color), the display briefly flashes in color on boot but then jumps to off-white on black. also when reboot, screen switches to color for a flash right before goes blank. so it's "trying" to be in color?

i could not find any docs on heltec for tracker v1.2 so not sure legit.

thanks to all the devs, awesome project, awesome fun.

--gaspo.

gaspo1sky avatar Aug 13 '25 07:08 gaspo1sky

What is "heltec tracker v1.2" ?

  1. HTIT v1.0 https://resource.heltec.cn/download/Wireless_Tracker/Wireless_Tacker1.0
  2. HTIT v1.1 https://resource.heltec.cn/download/Wireless_Tracker/Wireless_Tacker1.1 are the only listed in the docs section of Heltec site.

lyusupov avatar Aug 14 '25 16:08 lyusupov

Yes, that's the problem. My board says "htit tracker 1.2". I just got them from amazon. I do not have any 1.0 or 1.1 to compare. only other I have is heltec v3 units.

I sent email to heltec support asking if it's any different than 1.1. And if they can provide schematic or docs.

2.7.4 works ok. 2.7.5 the gps says 0 sat even outside.

The LCD flashes in color then goes back to monochrome.

Thanks.

On August 14, 2025 9:46:31 AM PDT, Linar Yusupov @.***> wrote:

lyusupov left a comment (meshtastic/firmware#7616)

What is "heltec tracker v1.2" ?

  1. HTIT v1.0 https://resource.heltec.cn/download/Wireless_Tracker/Wireless_Tacker1.0
  2. HTIT v1.1 https://resource.heltec.cn/download/Wireless_Tracker/Wireless_Tacker1.1 are the only listed in the docs section of Heltec sire.

-- Reply to this email directly or view it on GitHub: https://github.com/meshtastic/firmware/issues/7616#issuecomment-3189149825 You are receiving this because you authored the thread.

Message ID: @.***>

gaspo1sky avatar Aug 14 '25 19:08 gaspo1sky

I'm running into the same GPS issue on latest stable (2.6.11) and alpha (2.7.5) with a heltec wireless tracker v.1.2 ordered from Amazon that showed v1.1 on the PCB in the pictures (nothing in the description). It doesn't sound like there's much of a change, but I'm interested to hear Heltec's response. https://github.com/orgs/meshtastic/discussions/140

Meshtastic logs indicate that the UC6580 GNSS is detected, but never gets a lock. What's interesting is that it states "NMEA GPS time 2025-06-14 08:44:23 age 5" which is 64 days ago and all nodes (including this node) in the android app show the last update as 64 days ago as well.

INFO  | ??:??:?? 2 GPS power state move from OFF to ACTIVE
DEBUG | ??:??:?? 2 Use GPIO33 for GPS RX
DEBUG | ??:??:?? 2 Use GPIO34 for GPS TX
DEBUG | ??:??:?? 4 [GPS] Probe for GPS at 115200
DEBUG | ??:??:?? 4 [GPS] Set Baud to 115200
DEBUG | ??:??:?? 4 [GPS] Trying $PDTINFO (Unicore Family)...
INFO  | ??:??:?? 4 [GPS] UC6580 detected
DEBUG | ??:??:?? 6 [GPS] Publish pos@0:2, hasVal=0, Sats=0, GPSlock=0
DEBUG | ??:??:?? 6 [GPS] No GPS lock
DEBUG | ??:??:?? 6 [GPS] onGPSChanged() pos@0 time=0 lat=0 lon=0 alt=0
INFO  | ??:??:?? 6 [GPS] updatePosition LOCAL pos@0 time=0 lat=0 lon=0 alt=0
DEBUG | ??:??:?? 6 [GPS] Set local position: lat=0 lon=0 time=0 timestamp=0
DEBUG | ??:??:?? 6 [GPS] Node status update: 6 online, 6 total
DEBUG | ??:??:?? 6 [GPS] NMEA GPS time 2025-06-14 08:44:23 age 5
DEBUG | ??:??:?? 6 [GPS] Upgrade time to quality GPS
DEBUG | 08:44:23 6 [GPS] Read RTC time as 1749890663
WARN  | 08:44:23 6 [GPS] 1 new GPS checksum failures, for a total of 1
DEBUG | 08:44:23 6 [GPS] Publish pos@0:2, hasVal=0, Sats=0, GPSlock=0
DEBUG | 08:44:23 6 [GPS] onGPSChanged() pos@0 time=1749890663 lat=0 lon=0 alt=0
INFO  | 08:44:23 6 [GPS] updatePosition LOCAL pos@0 time=1749890663 lat=0 lon=0 alt=0
DEBUG | 08:44:23 6 [GPS] Set local position: lat=0 lon=0 time=1749890663 timestamp=0
DEBUG | 08:44:23 6 [GPS] Node status update: 5 online, 6 total

Then it ignores time from the mesh since it has a time source in the past day from RTC.

DEBUG | 08:48:09 232 [Router] decoded message (id=0xf3ba6cc6 fr=0xfee9a206 to=0xffffffff, transport = 1, WantAck=0, HopLim=3 Ch=0x0 Portnum=3 rxtime=1749890889 rxSNR=5.25 rxRSSI=-85 hopSta
DEBUG | 08:48:09 232 [Router] handleReceived(REMOTE) (id=0xf3ba6cc6 fr=0xfee9a206 to=0xffffffff, transport = 1, WantAck=0, HopLim=3 Ch=0x0 Portnum=3 rxtime=1749890889 rxSNR=5.25 rxRSSI=-85
DEBUG | 08:48:09 232 [Router] Module 'position' wantsPacket=1
INFO  | 08:48:09 232 [Router] Received position from=0xfee9a206, id=0xf3ba6cc6, portnum=3, payloadlen=33
DEBUG | 08:48:09 232 [Router] POSITION node=fee9a206 l=33 lat=275747310 lon=-824434561 msl=2 hae=0 geo=0 pdop=606 hdop=0 vdop=0 siv=6 fxq=0 fxt=0 pts=0 time=1755475589
DEBUG | 08:48:09 232 [Router] Ignore time from mesh because we have a GPS, RTC, or Phone/NTP time source in the past day
INFO  | 08:48:09 232 [Router] updatePosition REMOTE node=0xfee9a206 time=1755475589 lat=275747310 lon=-824434561

From that point forward it never gets a GPS lock and it hangs on the incorrect RTC time.

WARN  | 08:59:19 902 [GPS] Couldn't publish a valid location: didn't get a GPS lock in time
DEBUG | 08:59:19 902 [GPS] Took 900s to get lock
DEBUG | 08:59:19 902 [GPS] Predict 0s to get next lock
DEBUG | 08:59:19 902 [GPS] 9s until next search
INFO  | 08:59:19 902 [GPS] GPS power state move from ACTIVE to IDLE
DEBUG | 08:59:19 902 [GPS] Publish pos@0:2, hasVal=0, Sats=0, GPSlock=0
DEBUG | 08:59:19 902 [GPS] onGPSChanged() pos@0 time=1749891559 lat=0 lon=0 alt=0
INFO  | 08:59:19 902 [GPS] updatePosition LOCAL pos@0 time=1749891559 lat=0 lon=0 alt=0
DEBUG | 08:59:19 902 [GPS] Set local position: lat=0 lon=0 time=1749891559 timestamp=0
DEBUG | 08:59:19 902 [GPS] Node status update: 5 online, 6 total

eric-becker avatar Aug 18 '25 00:08 eric-becker

Hi, thanks for writing in. There was no change to the GPS code between these two releases, so this might be something else.

Most problems where GPS is successfully detected but doesn't get lock are because people are trying to use the GPS indoors - just checking you're outdoors when trying to get lock?

fifieldt avatar Aug 18 '25 00:08 fifieldt

I thought I was crazy, I've tried the 2.6 branch versions and 2.7 versions and have had no luck, I've had it outside in open sky for days... same problem, 2025-06-14, it always thinks this is the date, never finds any satellites, does the same things other people have reported in other issues where it boots with static on the screen for a moment, screen wakes inverted for a moment before it goes to green and black, no GPS signal.

What could I provide to help with this?

Xipherisroot avatar Aug 20 '25 06:08 Xipherisroot

I thought I was crazy, I've tried the 2.6 branch versions and 2.7 versions and have had no luck, I've had it outside in open sky for days... same problem, 2025-06-14, it always thinks this is the date, never finds any satellites, does the same things other people have reported in other issues where it boots with static on the screen for a moment, screen wakes inverted for a moment before it goes to green and black, no GPS signal.

What could I provide to help with this?

Just an update on this, turns out I hadn't tried 2.7.4 yet, I'd only tried 2.7.3 and 2.7.5, I skipped 2.7.4.... and 2.7.4 works, but the current stable 2.6.11 doesn't, and 2.7.3 doesn't, neither does 2.7.5...

At a loss as to of what would cause this....

Xipherisroot avatar Aug 20 '25 20:08 Xipherisroot

ok so i've gone down a rabbit hole with the trackerv1.2 and also the v3 boards. i've run into some very weird behavior trying to get the i2c telemetry working. AFAICT there is possible errors in how the i2c0 is attached to the lcd, and i2c1 is not. example i can get a bmp388 baro-temp module to work just fine on the board using adafruit demo arduino code, but only if i force i2c1 on different pins. i'm seeing same problems with the heltec v3 lora boards. i don't have much experience with esp32 chips so not sure how the peripherals are turned on/off, i'll start mucking w/ the meshtastic code once i have a working understanding of the i2c and lcd connections.

fwiw, heltec replied to my email, they say v1.2 is same as v1.1 wrt schematic.

my plan is to keep digging into the i2c pins and code, that's my hunch what's wrong w/ the LCD flashing color, and possibly why the gps wont sync.

also, i got 2 more of the tracker, total 3 boards, and all 3 the lcd module is "loose" in the metal frame, and it slides around and gets crooked very easy. there may be other Quality issues here.....

i'm going to stay with v2.7.4 as the gps works very good

--gaspo.

gaspo1sky avatar Aug 21 '25 07:08 gaspo1sky

Very much appreciate your continued efforts on this and sharing the research.

fifieldt avatar Aug 21 '25 07:08 fifieldt

Can I ask that someone else try something I tried that seems to suddenly make the GPS work again regardless of the version?

If you have it displaying 6/14/25 as the date, run it on battery, run it /absolutely dead/, to the point that the reset button won't turn it back on, then plug it into power, charge it for a bit, /then/ turn it on and see if it comes up with a 1970 year for the date, then leave it for 3-4 hours to get sat signal.

I did this on a unit, watching the logs while it died, it NEVER got a single sat signal for the entire life of a 3000mah battery pack, hours and hours and hours, a unit that still showed 6/14/2025 after a shutdown and reboot even, but after running the battery absolutely dead and leaving it absolutely dead for 6-8 hr and then charging it, /then/ booting it.... it stopped saying 6/14/2025, and within about an hour it was seeing 26 sats in the same location where it hasn't worked trying for a solid week.

I think there needs to be a way for the Meshtastic firmware to issue the "$RESET,1,H10" AT command to the GPS directly to reset it when/if it gets stuck like this, there's an account of someone fixing their heltec tracker by doing just that here https://www.reddit.com/r/meshtastic/comments/1ciru46/comment/lbmpytv/

I have no idea why it seems to work to drain the power, but draining the power seems to trigger the GPS to reset, I've only seen this like two other times with other GPS modules where I did essentially the same thing in lieu of the AT command to reset it and they also suddenly decided to work again...

Xipherisroot avatar Aug 21 '25 18:08 Xipherisroot

Thanks for the triage!

Do you happen to know how long the GPS chip takes to become responsive again after issuing this command? We can add this command as part of the software setup of the chip in the firmware, but need to know how long to wait before we can set configuration...

fifieldt avatar Aug 21 '25 22:08 fifieldt

here's something interesting, the Vext line wrt the schematic is a FET controlled power line. the docs say Vext is connected to "OLED and GNSS". does this mean the gps is powered by the Vext? or Vext is enable or some other way possibly reseting/turningoff the gps?

on schematic "HTIT_TRACKER_V0.5" i see Vext thru 10k ladder to GNSS_RST on the UC6580. this is also connected to VDD and thru diode to LEDA on the oled. perhaps this is the issue? Vext is getting set low somewhere and that resets the GPS? every time the screen blanks? confusing to me is there is also GPIO35 on the mcu says "GNSS_RST" also. which one is correct? both? Vext "on" brings RST on GPS hi, but the mcu could set it low? i have not checked if this is the reality on the board. i'm considering removing the LCD to look underneath.

also, does anyone know what pins the second i2c bus connect to?

and is this "color LCD" actually an LCD? or is a color OLED?

gaspo1sky avatar Aug 23 '25 01:08 gaspo1sky

and more question. a lot of GPS units have a small battery or super-cap to remember the ephemeris between boots so boots faster. does draining the battery drain this backup too? it doesnt explain why 2.7.3 works and the others don't, so maybe its just a detail in init? needs to clear the ephem first? i will try the power-drain thing and see what happens.

gaspo1sky avatar Aug 23 '25 01:08 gaspo1sky

here's something interesting, the Vext line wrt the schematic is a FET controlled power line. the docs say Vext is connected to "OLED and GNSS". does this mean the gps is powered by the Vext? or Vext is enable or some other way possibly reseting/turningoff the gps?

on schematic "HTIT_TRACKER_V0.5" i see Vext thru 10k ladder to GNSS_RST on the UC6580. this is also connected to VDD and thru diode to LEDA on the oled. perhaps this is the issue? Vext is getting set low somewhere and that resets the GPS? every time the screen blanks? confusing to me is there is also GPIO35 on the mcu says "GNSS_RST" also. which one is correct? both? Vext "on" brings RST on GPS hi, but the mcu could set it low? i have not checked if this is the reality on the board. i'm considering removing the LCD to look underneath.

also, does anyone know what pins the second i2c bus connect to?

and is this "color LCD" actually an LCD? or is a color OLED?

I don't have an answer on the question from fifeldt yet regarding timing...

but I can tell you it has to be an LCD, not OLED, its got a backlight, when the screen is 'on' the 'unlit' or 'black' parts of the screen have an obvious backlight behind them unlike the OLED units I have and its also probably a reason why these units have notoriously bad battery life.

You might be on to something, and yes it is absolutely a color screen, I've flashed other firmware projects on it and seen them display in full color.

Xipherisroot avatar Aug 23 '25 01:08 Xipherisroot

ok, i thought so. mine briefly flashes in color when it wakes-up and boots. wish i knew for sure what the model/driver/proto is....

gaspo1sky avatar Aug 23 '25 01:08 gaspo1sky

@gaspo1sky inspect if this issue https://github.com/meshtastic/firmware/issues/7786 is your use case

lyusupov avatar Aug 31 '25 07:08 lyusupov

For information: the time issues mentioned here were fixed in a recent release, with #7772 #7261 #7375

fifieldt avatar Oct 16 '25 22:10 fifieldt

This issue has not had any comment or update in the last month. If it is still relevant, please post update comments. If no comments are made, this issue will be closed automagically in 7 days.

github-actions[bot] avatar Dec 02 '25 06:12 github-actions[bot]

anyone any luck w/ gps on v1.2 newer than 2.7.5 ?

gaspo1sky avatar Dec 02 '25 06:12 gaspo1sky

I picked up a couple of the tracker v1.2's over the weekend to experiment. Ran into this problem and chose to experiment with a simple arduino sketch and tinygpsplus. I don't know if its because I did a hard reset ("$RESET,3,h0\r\n") and letting it sit in the window or what, but the device started working after what I assume is downloading data from the sat.

Some sites suggested $CFGINS,0 in case it was enabled in factory.

jtmcdole avatar Dec 07 '25 03:12 jtmcdole

Just to follow up:

Made the Arduino sketch do a "$CFGCLR\r\n" on another new device. Updated the initialization code on a fork of meshtastic to do:

            _serial_gps->write("$RESET,1,hFF\r\n"); delay(100); // chip level reset, cold start
            _serial_gps->write("$CFGPRT,1,0,115200,3,3\n\r"); delay(200);
            _serial_gps->write("$CFGSYS,h35155\r\n"); delay(750);
            _serial_gps->write("$CFGMSG,0,0,1\r\n"); delay(100); // GGA - required
            _serial_gps->write("$CFGMSG,0,2,0\r\n"); delay(100); // GSA - off.
            _serial_gps->write("$CFGMSG,0,3,1\r\n"); delay(100); // GSV  - sats seen
            _serial_gps->write("$CFGMSG,0,4,1\r\n"); delay(100); // RMC -
            _serial_gps->write("$CFGMSG,0,5,1\r\n"); delay(100); // VTG -
            _serial_gps->write("$CFGMSG,0,6,1\r\n"); delay(100); // ZTA - time
            _serial_gps->write("$CFGMSG,6,0,0\r\n"); delay(250);

And wrote some debug code to parse the GSV lines for sanity checking. Both of my v1.2 devices get a fix now in about a minute or so:

INFO | 06:53:59 74 [GPS] GPS-RX: $GNRMC,FIXDATA
INFO | 06:53:59 74 [GPS] GPS-RX: $GNGGA,FIXDATA
INFO | 06:53:59 74 [GPS] SAT - GPS: id:26 band:L1 C/A:1 snr:Weak azim:112 elv:32
INFO | 06:53:59 74 [GPS] SAT - GPS: id:31 band:L1 C/A:1 snr:Good azim:59 elv:63
INFO | 06:53:59 74 [GPS] SAT - GPS: id:3 band:L1 C/A:1 snr:Weak azim:0 elv:0
INFO | 06:53:59 74 [GPS] SAT - GPS: id:26 band:unknown:8 snr:Unusable azim:112 elv:32
INFO | 06:53:59 74 [GPS] SAT - GPS: id:3 band:unknown:8 snr:Weak azim:0 elv:0
INFO | 06:53:59 74 [GPS] SAT - GLONASS: id:67 band:G1 C/A:1 snr:Good azim:60 elv:40
INFO | 06:53:59 74 [GPS] SAT - GLONASS: id:68 band:G1 C/A:1 snr:Weak azim:343 elv:50
INFO | 06:53:59 74 [GPS] SAT - GLONASS: id:78 band:G1 C/A:1 snr:Good azim:132 elv:46
INFO | 06:54:00 74 [GPS] SAT - BeiDou: id:23 band:B1I:1 snr:Weak azim:39 elv:12
INFO | 06:54:00 74 [GPS] SAT - BeiDou: id:32 band:B1I:1 snr:Good azim:95 elv:21
INFO | 06:54:00 74 [GPS] SAT - BeiDou: id:23 band:B2a:5 snr:Weak azim:39 elv:12
INFO | 06:54:00 74 [GPS] SAT - BeiDou: id:32 band:B2a:5 snr:Weak azim:95 elv:21

jtmcdole avatar Dec 08 '25 14:12 jtmcdole