I recently crafted 25 sensor boxes that I then put out onto the yard to get an initial GNSS fix with a full battery (5000mAh). I seriously had a couple of boxes run out of battery (2.5 days) before getting their initial GNSS fix. I am not sure whether the proximity of lots of electronics messed up their reception, but it was the worst TTF I’ve had so far. Usually it takes <4 hours, but yes, it can take very very long!
When I charged them a few days later and put the remaining two in the window sill, they got a fix in a few hours.
Thanks for chiming in. You are right, this module feels like it is perfect for long range sensors. I see a power draw of about 150mA on mine (with an active WiFi link and no LORA). Looks like you got the power draw down to 83mA. Nice. And still you ran out of battery before getting a TTF?
That is indeed wildly out of the “usual” TTF range. The UC6580 modules strike me as pretty nice modules with good potential. The documentation is good and the command / feature set gives the impression like someone put a lot of though into it. It would be interesting to get a proper reference design with the UC6580 Unicore module to compare performance as intended. I wonder if Heltec’s adoption of the module causes it to perform so poorly. In the UC6580 documentation Unicore states a cold start is expected to take about 25 minutes.
I asked ChatGPT about ephemeris data and cold start duration:
“Ephemeris data is ~900 bits per satellite. So at 50 bps, 900 bits / 50 bps = 18 seconds (which aligns with the 3 subframes).”
And then “Almanac data (coarse orbit data for all satellites) takes much longer — ~12.5 minutes to receive a full set, since it’s broadcast more slowly across all satellites.”
A “cold start” is the longest acquisition scenario , where:
No satellite is known
No time is known
No almanac or ephemeris data is available
The receiver must search the sky blindly
Data Rates (Key Bottleneck)
GNSS
Ephemeris Rate
Almanac Rate
Notes
GPS
~50 bps
~50 bps
Ephemeris = ~30 seconds/sat
QZSS
~50 bps
~50 bps
Same as GPS for core signals
GLONASS
~50 bps
~50 bps
Similar, but different framing
To get a position fix , the receiver must download:
Ephemeris data for at least 4 satellites (usually 5–6 for good 3D fix)
(Almanac is optional for cold start but helps with future starts)
Each ephemeris block takes ~ 30 seconds to receive per satellite — assuming good signal and no errors.
How Long Does a Cold Start Take?
Under ideal sky view conditions:
First fix: 30–60 seconds
(this assumes the receiver can lock onto several satellites in parallel )
If reception is poor or antenna is obstructed: 2–5 minutes
(especially if data blocks are corrupted or partially received)
Modern chipsets like the UC6580 use multi-channel parallel decoding , so they can listen to multiple sats at once — this dramatically shortens fix time.
The answer isn’t exactly consistent on ephemeris/sat… but 2-5 minutes sounds about what I used to have to wait for a TTF on a SiRF Star III receiver.
About your interference concern… It’s hard to say… GPS L1 is on 1575.42 MHz. In general I expect it should be pretty free of interference. Also both the GNSS and LoRA on the Tracker are shielded. It could be that the way Heltec handle the GPS signal is suboptimal, causing poor performance.
It is also interesting that Heltec planned some caps on the GNSS antenna lines and then decided not to use them.
Note that I didn’t use WiFi there. There’s also a thread somewhere on the forum where I list a lot of power draw values in different circumstances for the Tracker.
Screw what ChatGPT says, cold hard evidence is much more useful. And that is that almanac can take up to four hours. Not sure what went on with some of my boxes, but it does show that physics are weird. And that was only the case on the first fix ever; as long as they’re used somewhat frequently, subsequent fixes are in the order of minutes or down to seconds depending on the downtime.
Apologies, I didn’t mean to sound negative. Let me try and balance things out a little. I do like the module. I now have purchased two.
It has a sleek design, it gives the impression of a good quality PCB, it has many cool integrated features: LiPo charger, LORA, GNSS, Display, user button and LED, … The selected ESP32-S3 CPU is a nice performing chip with WiFi and BT, I love the control over Vext to save power, a lot of the GPIO is exposed and even some pins are left over - just enough for my project.
But we must be able to also recognize and acknowledge shortcomings. Comparing it to a reference design seeks to identify the problem not assign blame - hopefully it can be fixed? If Unicore quotes better performance, why is it not working on this board? I recognized the intend of the PCB designer to include elements that were not used in the end - it is not bad - it could be a hint towards where the problem lies.
The GNSS is an essential part of any Tracker module…
I can also see some members here have had success obtaining a GPS fix. Maybe the error is in my code. I would just like to get my boards to work and help the community achieve the same thing. And even if there is a problem with the module… Hopefully Heltec can improve it in V1.4. Our feedback should help with that.
Which ones - it’s not clear to me that any have been identified. As my experience and to an even greater extent, @bns’s is that these GNSS modules are totally badass - I get a quick fix indoors at my desk when other modules, like my U-BOX Max 8Q, need the external antenna hooking up.
I’m not sure anyone has compared the claims of the manufacturer to what we have observed. Bearing in mind that manufacturers make optimistic claims and that we haven’t undertaken any methodical testing.
Not at all - almost everyone and anyone providing an antenna socket will put those components on with the capacitors as do-not-fit - I have it on my designs. This way if you wish to tune the antenna you are using, you can run the tests and fit an appropriate capacitor & inductor combination. As Heltec can’t account for what you may chose to use, it can’t fit those components in advance. I’d worry that they weren’t on the board.
The time to first fix EVER or if not ever, at least half-way around the globe, as an off-the-cuff anecdotal report on 25 boxes where only 2 had issue which sorted itself after a reboot, that is, all 25 are working, really isn’t the basis for picking apart a design, particularly as I believe this is the second batch of a new build, so about 100+ have been used so far.
Your first device, did you put it outside, patch antenna facing up, so it could get the initial data? Is it now working? Let’s concentrate on that first.
I had issues acquiring a GNSS fix for over a week with the module outside, on-board ceramic patch facing up. I would call that a potential shortcoming, which I am trying to understand, document and help other users to understand / work around. I also acknowledge that others have managed to get a GNSS fix with the module. I was trying to ask questions to gather understanding on the matter, not assign blame or mark something as not working.
I agree. On paper they looked so good, I opened a conversation with Unicore and am considering use of their GNSS modules in my projects. I would also be happy to use the Heltec Tracker modules if they are close enough to what I need.
Manufacturers sometimes do tend to overestimate the performance of their products and I do take the stated values with a grain of salt. But I hope you agree it can be used as an acceptable best-case scenario - as in don’t expect better than that.
That is amazing. I hope I can achieve the same with my modules. The roof here may block more signal.
Thank you for explaining the purpose of the unpopulated cap contacts - I was really curious about that. I do not design PCBs, but that makes a lot of sense. In light of what you said, Heltec did a good job on the PCB design. The board does look very clean and precision engineered and it is clear a lot of thought went into the design.
I agree. But it is a report of a (possible) issue and we can take them for what they are worth. We cannot deduct all the test conditions or local interference without extra information.
I am surprised… I had no idea it was such a small batch. I can’t believe I have two out of this batch. They looked like a good seller on Amazon. There were 16 reviews, 4.0 stars, if ~5% of people give reviews (could be a generous estimation on the feedback ratio)… I expected a much larger volume. But I digress.
Thank you for your offer to assist. Let’s concentrate on my specific scenario, and I would love it if you would help me speculate on what is wrong, and why I didn’t manage to get a fix. I will describe the test setup, if you want some extra info, please do not hesitate to ask.
Test setup:
Heltec HTIT-Tracker v1.3 (I assume there are no clones?)
Attached via USB to my computer to read serial data
placed outside on the balcony (estimated unobstructed view of the sky ~50%)
initially I used only the on-board ceramic patch antenna, always facing up to maximize signal reception
later I added an external “32dB High Gain 5cm Ceramic Antenna” with an ~5cm cable, again, facing upwards (antenna is actually 25mm squared, not sure what that 5cm is about)
Since I initially turned on my first module inside as I was soldering on connections and testing the code, this may have somehow affected the GNSS state and the way it is processing the signal.
Since I cannot 100% vouch the timeline or state of the GNSS module on the first tracker, I got another Heltec HTIT-Tracker v1.3 two days ago.
Since the new module arrived with the GNSS with factory default settings and state, I wanted to limit any effects of my code on the receiver. I made sure no consequential configuration calls were made. Initially I did use the Meshtastic config commands to limit the GNSS to the US GPS constellation, but then decided to remove them as well and use factory defaults.
And to remove any influence the external patch antenna might have on the test, I decided to use the on-board antenna only. Again, receiver was placed on the balcony, ceramic patch antenna up, USB connection plugged into my computer.
Yesterday, the receiver was out on the balcony (on board antenna up) from 7:30 onward. After two hours I saw several SV were in sight from GSV data, time was synced but no position.
At 18:10 I made a snapshot of the NMEA sentences. From the GSV sentences it looks like 43 SVs from several constellations (GP,GL,GB,GA,GQ) were in sight. What I did not notice until just now that I hand parsed the GSV data, was that GNSS reported only very poor signal strength. Only one SV from GP had 14dB-Hz, one GL had 37dB-Hz and one GA SV 26dB-Hz.
From what I understand 25–35 dBHz is considered usable and 35–45 dBHz good signal strength. It looks like it took so long to get a GNSS fix, because in my test setup only one SV had good signal strength.
At 18:25, the GNSS receiver still had no fix, but since I had to disconnect the USB connection to be able to close the window, I attached a 1Ah battery, boxed the receiver in a plastic IKEA box (patch antenna up) and left it for as long as it would run (probably less than 6 hours). In the morning, I reconnected it to USB to charge it, and… it immediately locked on and showed a fix!
So it looks like the GNSS receiver needed ~17 hours to download all the needed data from satellites in my test setup - with weak signal.
But here is something I cannot explain at all. Since my second tracker arrived, I put the first tracker aside (disconnected on my table) and concentrated on the new module. After seeing my second module got a fix this morning, I wanted to share the GPS data from the first tracker, so I connected the first tracker to the same USB cable, placed it in the same spot on the balcony, and it also immediately found a fix. I didn’t reflash the code, no changes… Considering that it didn’t have a fix when I turned it off… I can only assume the needed data was not downloaded yet when I turned it off.
So I am happy to report that the problem was me. Considering the weak signal from the NMEA snippet yesterday afternoon, it looks like I overestimated my choice of placing the receiver. It was outside, but it looks like it was too close to the building. After I got the longest USB extension cable I could find, and placed it on the edge of the balcony, the signal improved on average by 22dBHz and the number of visible unique satellites went from 19 to 36. To make sure nobody assumes there is something wrong with the tracker I will be clear: At the time, I do not see any shortcomings of the Heltec Wireless Tracker v1.3. For a cold start it needs to be placed clear of buildings in the open sky and it can take more than 12 hours to get a first fix.
I will do another test with a full GNSS reset (cold start) and place the tracker in the known-good spot on my balcony and report back.
Thank you for all your help and I apologize if I offended anyone with my questions.
Thank you, I will have a look. Heltec documentation also states quite a few consumption values.
Absolutely. Not just with ChatGPT but any-one/thing.
That has always been the case, even on SiRF Star III that I used to play with way back. GPS data gets stale. I also noticed being stationary seemed to help with that module - probably a better chance of uncorrupted signal due to intermittent obstacles while moving about.
It appeared from the number of components questioning Heltec’s engineering and looking to get a reference design to compare with that it was some sort of Spanish Inquisition rather than one person that hadn’t got one board going.
Not a report, just a passing remark about first setup - with no actual data to analyse.
The 25 he provisioned were in @bns’s latest batch - he has worked his way through about 100 of this board so far. These numbers are not related to how many are made by Heltec or how many have been sold.
Read a few of the posts on this & other similar forums - most issues are related to becoming familiar with a device and once you know you know. But until you know, it seems like everything is against you. And then there are the layers, which are like Shrek an onion, just when you get the hang of something, new details emerge.
It’s good to hear you have resolved the situation - the use of the word balcony is everything - you’ve obscured more than half the sky there and patch antennas mostly look up so anything near the horizon isn’t going to be heard well. Once it has the almanac it can concentrate it’s efforts much better. From experience with satellite comms, I’ve found that having a clear 90º cone perpendicular to the antenna is the minimum for “clear sky”.
It can, based on an anecdotal comment and your experience, but bearing in mind that Google indexes things and that can lead people to misleading conclusions about perfectly good products, so that statement needs further investigation to become something to plan for.
Expecting the GNSS module to get up & running whilst it has Meshtastic firmware on the board is subject to far too many variables to do with the configuration and could potentially confuse the heck out of the GNSS module.
I’ve an unused tracker, I’ll put TinyGPS on it or some such to route to the serial port, run a stupid long cable out the office door and record the first startup using QStar.
Heh, you may have a point there. You know that external GPS antenna from Amazon I used? I wrote a parser for the NMEA data and it looks like the antenna drops even the strongest signal down to just 14dBHz. No wonder I didn’t get a fix.
True. The signal needed for position tracking can be a lot weaker.
That may indeed be a good definition for a “clear sky”. I was surprised how much stronger the signal was just 2m further out on the balcony. I assumed a tilted 90º cone was good enough.
Perhaps the GNSS systems inside phones have skewed my understanding of “clear sky”, because they rutinely inject the assist data into the GNSS modules and I haven’t experienced a true “cold start” in over a decade.
Absolutely. That is why I was asking questions. Conclusions require evidence not index results. I consider those hints.
I haven’t tried Meshtastic (yet). It seems ok, but I feel a little critical about the protocol implementation. I am hoping to do better. I am aware Meshtastic could be changing the GNSS configuration and it actually is doing that. I wrote my own program / firmware… and I was testing both the “factory default” and “Meshtastic init” for the GNSS module. I believe Meshtastic is limiting the position to just the US GPS constellation, which seems a bit of a waste considering the capabilities of the UC6580.
I am curious what TTF you get. Thanks for trying.
My software isn’t quite ready… but preliminary findings seem to show that with a proper “clear sky” the UC6580 by far outperforms the 20 minutes stated in the Unicore documentation. I can’t remember precisely… could have been under 10 minutes with the on-board antenna. Will report more when I have properly formatted actual data.
You’ll need a ~28dBi gain antenna for L1+L5 to properly help the UC6580, like this one. They’re also available from some AliExpress stores for a third of the price but beware that it’s a swamp trying to find the right antenna with high gain and right frequency band.
A 30s cold start is pretty much excellent. I believe the theoretical minimum is 18 with optimistic times at 30s and 60-90s typical. And this was all tested with the on-board antenna, and a clear view of the sky.
I also re-tested the module placed in the position where I initially tested it - close to a building that was blocking half of the sky. It still got a fix in only 112 seconds. So it looks like the external antenna I used was really not well suited for the UC6580.
But there is also something I cannot explain. Why are all the reset types taking approximately the same amount of time? A hot start of 30s is not very fast.
An alternative explanation would be that the restart I have requested is not doing what i think it is.
Does anyone else have any ideas why the different reset types take the same amount of time?
Reset doesn’t necessarily mean a Cold Start, it could just “reboot” and load up the data it has on hand.
Either we need to be sure a command will ‘zap’ the memory or we get a couple of modules side by side, one that’s never been run and one that has, to see what occurs.
All that said, any GNSS modules I despatch (admittedly not many, but the principle applies), is run before it leaves so that anyone receiving it within a few hundred miles that powers it up with a clear sky view gets a quick start up with the pre-seeded information.
As far as my limited serial interaction with the UC6580 goes, I’m quite sure it wants to see lower case values such as hff instead of HFF. This can partly be checked by observing the return output - have you checked it?
I do like the module. I now have purchased two. 
Considering the weak signal from the NMEA snippet yesterday afternoon, it looks like I overestimated my choice of placing the receiver. It was outside, but it looks like it was too close to the building. After I got the longest USB extension cable I could find, and placed it on the edge of the balcony, the signal improved on average by 22dBHz and the number of visible unique satellites went from 19 to 36. 
To make sure nobody assumes there is something wrong with the tracker I will be clear: At the time, I do not see any shortcomings of the Heltec Wireless Tracker v1.3. For a cold start it needs to be placed clear of buildings in the open sky and it can take more than 12 hours to get a first fix.
the UC6580 by far outperforms the 20 minutes stated in the Unicore documentation. I can’t remember precisely… could have been under 10 minutes with the on-board antenna. Will report more when I have properly formatted actual data.