Hi folks,
I’m using three those trackers and work well but when trying to change GPS searching from default GPS only to GPS+Galileo+Glonas then got “Wrong parameter” response. I’m running current firmware 1.6.7 but same situation was in 1.6.4 as well.
The reason to change setting is speed-up fixing possition. Currently GPS fix tooks approx 60 second. I hope switching to use GPS+Galileo+Glonas can speed up fix to few seconds instead of minute or two.
Have you any hint for me, pls?
If your device supports multiple gnss systems depends on the hardware version. Your version obviously does not.
By the way, have a look at this link for GPS issues with lgt92
Some GNSS chipsets can combine constellation signals to get a rough fix (given that they all have little variations and they don’t all share the same reference clock), but if it’s taking 60 seconds to get a fix it means you’ve not got the almanac up to date so the chip has to start from scratch each time, see a previous answer related to fix time here:
TL;DR: It has to be on with a good view of the sky at regular intervals to be able to do a hot fix.
I have tested first fix times for plain GPS versus the GNSS ones and not seen a difference.
Fix times from cold for most GPSs is around 35-40 seconds when outside with a good view of the sky. The only way of improving that first fix time is with GPS assist schemes where the almanac\empheriss is downloaded direct from the internet, as with a mobile phone for instance.
Once the GPS has a first fix then subsequent hot fixes can be in the 2 second region (if the GPS has backup) but it will on ocaision, every hour maybe, drop back to 35-40 seconds again. Also bear in mind that after the first fix the downloaded empheris is only valid for up to 4 hours.
Longer first fix periods than 35-40 seconds are down to the antenna or the GPS.
That was good hint to set FTIME=0 to keep GPS powered and load almanac. Seems to be better (faster) now.
BTW I surprised that still exists GNSS receiver working with one positioning system only.
If the GPS is always powered, then after the intial cold fix period, 35 seconds or so, it will normally keep reporting fix information every second as a default. This uses a great deal of power though, around 20mA, so batteries wont last long.
It’s not, the Quectel L76 does multiple constellations, it just can’t do magic.
If you read the link to a prior explanation you may gain some insight in the information that a GNSS module has to download to be able to perform a warm or hot fix, how long it takes to download and how long it will last for.
Then you can turn your GNSS module off between fixes and know roughly what to expect and conserve a considerable amount of battery life.
Yep, I’ve read that. I’m disappointed of situation when I have to set FTIME=0, keep receiver to load data, then set FTIME=150 back to save battery and repeat all of that once a week or two.
I’ve made a couple of trackers using different ways of communication and never met this limitation even 13 years back Sirf3 chip was on the top and some GPS modules took up to 200mA so was necessary to switch off the power few seconds after GPS fix. GPS module never was powered longer than was necessary for fix and fix in next cycle was under 5 seconds. Well, modules had backup battery but ublox has backup as well I guess or am I wrong?
Anyway, thanks for hint. There is space for improvement so going to modify sources and adjust behaviour as I need 
It depends on the module, some modules have battery backup, some do not.
The presense of a supply to the backup pin on a GPS, which does not need to be a seperate battery, does mean the the emphersis and other stuff is stored and subsequent power ups can produce a fix in a few seconds.
In general if you power up a GPS from cold and as soon as there is the first fix you turn it off, it will struggle a bit on subsequent hot fixes. But eventually the GPS settles down after some hours and average hot fix times can be in the 5 second region, depending on the GPS. The L76 averages around 5 seconds in my tests.
As for the theory that letting the GPS initially run for 15 minutes or so before powering it down will then subsequently (significantly ?) reduce hot fix times and in turn power consumption, I cannot say.
Is there any pratical evidence that modern GPS benefit from this initial power on period ?
I need to revisit my combo of documentation & testing as it has got quite old and we now have the much better L2C signal to receive. My first Garmin used to take many minutes to do a warm fix and when I used it in the States in 2006 it took well over an hour to get enough satellites before it became vaguely useable.
Testing a NEO-6M based module recently in the office, downloading assist data via the u-Blox software certainly kick started each one but I wasn’t paying much attention to the details - finding a position in the rafters to put an antenna so I didn’t have to string multiple SMA to SMA cables to get one outside was taking up my attention. But it was clear from a brief test between rain that the most beneficial thing was an active antenna outside with a 45° cone of visible sky, second best was the same active antenna in the rafters but away from other cables / flourescent tubes etc.
Most of the personal trackers are pendant based with a ceramic block antenna - I don’t know how that particularly differs from one of the mag-mount active units but I bet being sideways to the sky doesn’t help. But I do know a NEO-M8N with ceramic block wasn’t picking up anything when put in the same place as the active antenna.
I’ve a box of NEO-6M’s which I think would represent a typical entry level GNSS module that have never been used, maybe I can figure out a test setup and try things out - included the all important current consumption.
I’ve looked into schematic diagram and I’m confused a bit.
Have to check directly on board and measure if backup PIN is powered or not. And if isn’t then try to connect 3.3 V via cca 4k7 resistor since backup current is 14 uA.
Me too, the LGT-92 datasheet says it uses a Quectel L76, no u-Blox insight!
All of my trackers have the same ublox module.
Interesting and frustrating.
Anyhoo, from the AT command reference:
AT+NMEA353=? For L76-L only
The command is taken by the STM32 and then relayed on to the GPS thus:
void PMTK353(void) {
if(se_mode==1) {
txdata353="$PMTK353,1,1,0,0,0*2B\r\n";
} else if(se_mode==2) {
txdata353="$PMTK353,1,0,0,0,1*2B\r\n";
} else if(se_mode==3) {
txdata353="$PMTK353,1,0,1,0,0*2B\r\n";
} else if(se_mode==4) {
txdata353="$PMTK353,1,1,1,0,0*2A\r\n";
}
}
The PMTK353 command is not supported by u-Blox …
Unfortunatly the ‘myth’ of the 1 hour before a ‘factory fresh’ GPS gets a fix persists to this day, even though the most basic of tests will show that a modern ‘factory fresh’ GPS will get a first fix in the 40 second mark.
Older GPS had fewer channels so the almanac data, when available, could allow the GPS to use the limited number of channels to seach for GPSs that should be in view.
In general the Ublox GPSs dont perform so well with poor antennas, whn compared to the Quectels for instance, see here for some tests;
Average current consumptions of GPSs here;
Indeed not …
It make sense. I did not realized that “L76” is different brand and type receiver. I consider for ublox “sub-type”
I had spotted some time ago that leaving a GPS powered up for a couple of minutes after its first fix from cold did reduce the subsequent hot fix times in the short term. But still hot fix times could be quite long.
With an L76 (with backup) setup to get powered up, get a new fix and transmit it every hour, these were the average hot fix times over the next 24 hour period;
No startup delay, average hot fix, 23.9 seconds, total powered uptime 631 seconds
5minute powered startup delay, average hot fix, 19.9 seconds, total powered uptime 792 seconds
20minute powered startup delay, average hot fix, 19.6 seconds, total powered uptime 1691 seconds
So beyond a short startup delay, the GPS does not seem to make good use of the potential almanac data it has downloaded to quickly identify which satellites are in view, at least in the short term.
There are many many conflicting “official” pronouncements on how long the ephemeris & the almanac are valid for. About the only thing that is consistent is the time to transmit.
I ran a few tests just to get my bearings again - once it’s heard something in the last few days (so it has the almanac on board) a M8N with ceramic top stuck on top of a rafter under a flat roof (felt + some puddles & leaf matter) gets a fix after a few minutes. A 6M with active antenna next to the M8N is totally deaf unless I take the antenna outside and once it’s got a fix, it will then work happily inside. Not hugely scientific but it shows how the almanac can help get a fix under edge conditions but the newer chip is overall much more superior. The 6M clearly needs to know exactly what to listen for to have a fighting chance of getting going when reception is spotty.
The reason I go for poor sky view is that seems to be the sticking point for most use cases (and support issues). TTFF when you are outside with at least a 45° cone of view never seems to be a problem unless it’s a small PCB antenna with the PCB & 18650 battery between it & the sky.
And the time for the M8N GPS to get a fix from cold, in the same location ?