Different GPS Fix time on different PyTracks



  • Hello,

    I have four Pytracks. I tested the time to get GPS fix on all of them. Below are the results:

    GPS_A
    2020/02/12 11:26:14.000 = Started
    2020/02/12 11:26:56.000 = Fix (42 seconds)

    GPS_B
    2020/02/12 11:37:52.000 = Started
    2020/02/12 11:40:47.000 = Fix (2 minutes 55 seconds)

    GPS_C
    2020/02/12 11:48:56.000 = Started
    2020/02/12 11:52:30.000 = Fix (3 minutes 34 seconds)

    GPS_D
    2020/02/12 12:05:55.000 = Started
    2020/02/12 12:07:52.000 = Fix (1 min 57 seconds)

    Could somebody explain why there is a huge difference between fix time on these four different PyTracks ?



  • @smarok I believe this shows that by default the GPS chip does not save any state at all when powered off, so you are in a cold start scenario in those cases, while you are in warm start after a reset.

    I wonder what makes the difference between the scenarios with ≈30s TTFF and those with immediate fix, though. It would be interesting to log the chip’s full output in both cases, there are probably hints in there.



  • @jcaron

    I performed the test with only one PyTrack and got there varying results...

    Experiment #1 GPS_A

    PyTrack turned off for 24 Hours
    (Power On)
    2020/02/13 16:06:14.000 = Started
    2020/02/13 16:10:43.000 = Fix (4 mins 29 seconds)

    (Press Reset Button)
    2020/02/13 16:11:06.000 = Started
    2020/02/13 16:11:44.000 = Fix (38 seconds)

    (Press Reset Button)
    2020/02/13 16:12:38.000 = Started
    2020/02/13 16:13:08.000 = Fix (30 seconds)

    (Press Reset Button)
    2020/02/13 16:14:04.000 = Started
    2020/02/13 16:14:40.000 = Fix (36 seconds)

    Experiment #2 GPS_A

    PyTrack turned off for 30-35 mins
    (Power On)
    2020/02/13 16:55:45.000 = Started
    2020/02/13 16:58:48.000 = First Fix (3 mins 3 seconds)

    PyTrack turned off for around 1 min
    2020/02/13 17:00:08.000 = Started
    2020/02/13 17:01:42.000 = Fix (1 min 34 seconds)

    (Press Reset Button)
    2020/02/13 17:01:59.000 = Started
    2020/02/13 17:01:59.000 = Fix (0 seconds)

    (Press Reset Button)
    2020/02/13 17:02:23.000 = Started
    2020/02/13 17:02:23.000 = Fix (0 seconds)

    (Press Reset Button)
    2020/02/13 17:02:46.000 = Started
    2020/02/13 17:02:46.000 = Fix (0 seconds)

    PyTrack turned off for around 30 seconds
    (Power On)
    2020/02/13 17:03:35.000 = Started
    2020/02/13 17:05:38.000 = Fix (2 mins 3 seconds)



  • and the same direction of the GPS antenne ;)

    Depending on the modes the L76 can save the almanac. But playing around with settings is some kind of risky. The L76 stores the settings in an internal flash. So it may not give you usable results until you find the right settings again >:-|



  • @smarok GPS satellites send a stream of data (the almanac and the ephemeris) which takes a long time to go through (because it's a very very slow link: 50 bits/s!), which the GPS chips need before they are able to get a fix.

    To get the whole almanac for all satellites from a single satellite, it takes 12.5 minutes. But based on the satellites it sees (and thus needs data for and/or can receive data from), the chip should be able to get the required data faster, but how long it takes to get the whole data depends on which satellites are visible and where in the transmission the satellites are. Take also in consideration that satellites can enter or exit the visible field during this period, and that the signal from one or more satellites could be blocked by interference or obstacles at various times. And of course, the GPS chip needs to detect which of those satellites are visible!

    You'll find more information on Wikipedia about the whole message format, almanac, ephemeris, etc.

    Also, if the chip was turned on (even if you were not actively waiting for a position), it started accumulating data during that time.

    I'm not quite sure what (if anything) the GPS chip on the PyTrack will save when it is reset or switched off. If it does save data, remember that this data is valid for a few hours, so depending on when they were last active that will influence TTFF (time to first fix) as well.

    If you want to compare the performance of the 4 PyTracks, you need to switch all of them off for several hours (at least 4 to make sure all ephemeris data has expired), then turn them on and start listening at the same time (and they should of course be in the same location with the same view of the sky).

    Let us know what results you get when doing that.


Log in to reply
 

Pycom on Twitter