I’d have to clear the almanac for that and I’ve only just screwed it’s case back together! I’m sure u-Center has a button but v1 seems to have been modelled on the flight deck of Concorde and I haven’t got to registering for v2 yet.
But you’ve peaked my interest so I’ll drape the damn thing over the side of my monitor as a reminder to do it today.
Remove it from the power and\or the backup supply and leave it a few minutes, unless the almanac has been programmed into flash from an on-line source, dont know much about dealing with that.
The Ublox M8s do perform a good deal better than the older 6M series, and with a lot of fake 6Ms out there, comparisions are sometimes not good.
I’ll have to open the only recently closed case to pull the battery.
But I did use the online assist from v1 recently on that device but as it’s the v1 rocket surgery GUI it was hard to tell if it ‘took’ - seemed to. Whereas some other random series 6 module couldn’t cope with a download so that may be a fake.
I don’t discount testing fakes because it is all too easy for someone to buy some in good faith and then start asking questions - but my backstop is that it has to come from a known distributor for the acid test however achingly expensive. But also learning to cope with the fakes isn’t so bad as they do a basic job OK, so can be put to use for non-critical applications - tracking JCBs for instance - only need a 10m fix for them, the rest I can figure out by looking for the big yellow metal thing.
Could be, I have some alleged 6Ms that dont take the standard configuration commands.
I’ve did measuring on ublox PIN6 (backup voltage) and can confirm that voltage is presented when tracker is switched on only. Once you power off the tracker, voltage disappear. It’s OK but I hoped that backup voltage is not used and log hot fix is caused by that.
I have several MB of logs from an M8N & a 6M to process - both had a radical battery-ectomy (removal with pliers). Hopefully it will show more detail but I need some downtime to get those logs in to order.
The logs were enlightening but not scientific.
The 6M of questionable provenance could get a fix from power up inside 30s but had an active antenna outside with a good view of the sky.
The M8N drone puck with ceramic top stuck in the rafters with a felt roof above it took between 3.5 and 4.5 minutes to get a fix.
I’ve started downloading various documentation to try to see if there is a consensus on GNSS. There is an interesting ST doc that shows various modes for their chipset that minimises power vs keeping enough almanac or ephemeris data available to perform the quickest fix in line with the power policy - so sometimes allowing the ephemeris to expire but then using hard math to extrapolate it to get a better than warm fix.
None of the vendors are very explicit about how they may combine GPS (USA), GLONASS (Russia) and the built-in-the-UK satellite constellation called Galileo that the Europeans have stolen sequestered. Apparently do-able but not simple.
Looking at the official GPS docs it seems that the ephemeris runs to about 4 hours now, but GLONASS is only 30 minutes - which would explain why a hot fix is possible way beyond 30 minutes as I thought.
The GNSS world is like a LoRaWAN cliche of special people who mainline TLA’s and move the goal posts on the transmissions with each new series of satellite with more & more refinements to increase accuracy and keep the rest of us on our toes. The situation is further complicated with a new constellation that is just coming on-line now that there are enough of them so all our modern chipsets should start doing even better.
I’m going to get an M8N module from Uputronics, a very trustworthy source / manufacturer and setup a spare Pi to run tests as I think of them. But the creation of a summary of how GNSS works I think I’m going to have to delegate to someone with more time & a less full brain.
To solve the question as to whether the GPS hot fix time reduces if the GPS has been powered for a period, its easiest, in my view to use simple point to point LoRa setups.
I currently have a ‘tracker’ running in my garden, sending the fix time via LoRa which is picked up by another LoRa device with an SD openlog on the serial port.
Around Thursday this week it will have been running a full week, so the logs on the SD should reveal what the long term average of hot fix is. The last ‘hot fix’ was 16.9 seconds.
So next week, I will let the GPS stay powered for a long time, an hour maybe, and see in practice how much difference it makes.
Shhh, don’t tell anyone, I have a pile of Arduino Nano’s with on-board nRF24L01’s for remote serial port capture. Plus some ESP thingys. My RFM95 / WLR08U / Murata ABZ stock is under lock & key so not for trivial use - only client projects.
I am tempted to explore the ST offering to see how the power saving works out - I’ve an STM32 IOT LoRa Tracker somewhere in the “to try out” pile.