Dear: I have a problem with the Tracker v1.1 Gnss. I use the HT_tinygps library. The process is to acquire the GPS position as quickly as possible to save battery and then enter deep sleep for 15 minutes. The first reading cycles without moving the GPS are excellent less than 5 seconds. with Hdop < 4… Then the time goes away for about 30 seconds and does not return regardless of the weather conditions… When I reset the Tracker it has short cycles again. I can’t identify if the problem is the ESP32 or the GNSS. From what I see in the V0.5 diagram, the GNSS does not have the CHIP_PU pin connected, so it should not know about the reset.
I await your comments… thank you
Gnss problem with tracker
What exactly do you mean by this? “the time goes away”? How does it “go away for 30 seconds”, but then “not return”? What do you mean by this 30 seconds if it doesn’t come back at all?
Dear, thanks for your help. I see that you have a lot of experience with this device.
Right now I am testing 3 trackers v1.1 using the Tinygps library. The 3 devices have different behavior having the same software and being in the same place.
The application turns on every 15 min. after a deep sleep, collects the position data and sends it via lora.
Problem: Time from Vext = 1 and the function gps.location.isUpdated () = 1
On the first device it is always in the order of 5 seconds (Hot Start)
On the second device 5 seconds the first 10 start and then it goes to 29 seconds (cold start) and it never returns to Hot Start.
On the third device always approximately 30 seconds (Cold Start).
I don’t understand what is happening. Is the antenna integrated?.. For the application, a Hot Start is necessary in most cases so that the solar panel has the energy to charge the battery.
Thank you very much in advance,
Have you left all of them out turned on for about 20 minutes so they all have the same up to date almanac & ephemeris??
As per @nmcc, the GNSS almanac & ephemeris have an expiry date. If I don’t mix up the names, for the ephemeris, this is a few hours (four). The almanac should last anywhere up to14 (with some reports of 90 days). Source.
The reason why a cold start takes 29s for each and every GNSS receiver ever, is because the ephemeris is broadcast over a duration of 30 seconds. But that assumes that the almanac is already known and fully up to date.
Now the almanac reception can take a long time. Nick mentions 20 minutes, but I have seen some of my Trackers take four hours to get going. So the first thing to do is to put them outside with a good view of the sky for a day.
But a device will never be able to keep going on Hot Starts, as at least every four hours it will need to do a Cold Start. Cutting power as soon as any fix is found however, turns out to be a bad decision. In my own devices, I wait for a fix of HDOP < 3 for 5 seconds, then do an uplink, then do a 7 second timeout, and then turn off GNSS power (5+6+7 seconds). And even then, I don’t get continuous Hot Starts, more like Warm Starts around 15~20 seconds. I suspect there’s something about the UC6580 that Heltec didn’t completely get right which means that the GNSS memory isn’t perfectly preserved, but GNSS is hard anyway so it may be a knowledge error on my behalf just as well.
Ah, yeah, my bad, if you already know where the sats are, you know where to listen so you can download in 15 minutes, as far as I recall. Starting from scratch is a bit of a lottery on checking different frequencies at different intervals - so two lots of random - to get going.
There’s no coin cell battery backup so no LiPo= no data preserved when unplugged.
Yes, but as long as the battery is plugged in (and has power), its supposed to preserve everything. I don’t fully believe that that works as it should in the Tracker.
Dear: excellent information. It works OK. But I want to improve this information. Do you know if the UC6580 emits any proprietary message when it updates the ephemerides and the almanac? Thanks very much.
GNSS simply isn’t made for ultra-low-power. Here are the UC6580 docs - you can have a look for yourself. But I advise you to accept that the GNSS receiver must be turned on for at least 30s every time you want to use it, with an order of 5 minutes on first boot / long sleep. You are probably better off including an accelerometer that signals when something happens, only then you need to turn the receiver on.
There is no standard for this info and I’ve long given up chasing my tail on it - mostly because the very second that you have a full almanac, it’s immediately out of date so saying “I’m fully up to date” would be followed by “I’m not up to date”, followed by “Up to date” followed by “No longer up to date”.
The data transmitted is a constant stream of updates, if you go longer than 30 minutes you’ll need to keep the GNSS on for longer but over the space of the day you’ll probably end up with patchy data so need to commit to one good update session - if it’s on solar, you’ve got the time, if you are well charged & you’ve got sun, leave it on a bit longer.