stratux icon indicating copy to clipboard operation
stratux copied to clipboard

GPS assist load in development

Open jamez70 opened this issue 8 years ago • 23 comments

This is in development. Could you help test it please? I just want you to see it to see if it works for you.

jamez70 avatar Dec 15 '15 03:12 jamez70

current_14d.alp - which file is this? api link

cyoung avatar Dec 15 '15 04:12 cyoung

http://alp.u-blox.com/current_14d.alp :)

jamez70 avatar Dec 15 '15 04:12 jamez70

I have a Beagle USB protocol analyzer somewhere around here, I'll sniff the bus and see what is sent.

jamez70 avatar Dec 15 '15 04:12 jamez70

Has anyone done testing on lock times? @AvSquirrel ?

I'm getting 12 seconds to a 3D lock on hot starts (30 seconds no power). Seems faster than before but not sure?

cyoung avatar Dec 15 '15 05:12 cyoung

Use this commit..I verified that it is uploaded

jamez70 avatar Dec 15 '15 05:12 jamez70

Probably have to find a way to handle how to get the data on the stratux, maybe through the web page? I'm all ears if there are any suggestions.

jamez70 avatar Dec 15 '15 05:12 jamez70

@cyoung : Without assist, I recall seeing see 8-15 seconds on hot starts, and maybe 20-30 seconds on warm starts after a couple days of nonuse.

Let me play with u-center a bit -- it can command cold/warm/hot starts, and I can monitor the console real-time.

ghost avatar Dec 16 '15 03:12 ghost

@cyoung : I ran several tests with both the Neo M8N and a u7-based receiver, connected to u-connect software over USB. UBX commands were sent to restart the receivers with three different methods.

Hot start: GPS module is reset, but ephemeris, almanac, clock, previous position, etc. are retained in memory. Position lock takes 2-4 seconds. Hot starts performed by unplugging / replugging the receiver had similar lock times.

Warm start: GPS module is reset, and ephemeris is cleared. Almanac, clock, previous position, etc. are retained in memory. Position lock typically took 15-30 seconds, though occasionally it took as much as 45 seconds.

Cold start: GPS module is reset. All data, including ephemeris, almanac, clock, previous position, etc. are cleared. Position lock typically takes 45-120 seconds, though I saw as little as 25 seconds and as much as 200 seconds.

These numbers seem reasonable to the extent of my understanding of the GPS system. On warm starts, the receiver has almanac data (rough position of all satellites in the constellation, ionospheric corrections, etc.) and a prior fix, so it knows roughly where the satellites should be, and just needs the ephemeris (short-term, precise satellite position data). The full ephemeris for each satellite is transmitted every 30 seconds, so it should never take more than about half a minute to get a position lock if the receiver isn't far from the last fix, and has been used in the last several weeks.

On cold starts, we also need clock and almanac data. Clock data typically showed up within 10 seconds in my testing. Almanac data appeared incrementally; each satellite transmits 1/25th of the almanac during each 30-second frame (12.5 minutes to receive the full almanac from a single satellite) but the full almanac wasn't needed to calculate a position.

For both the cold and warm starts, satellite visibility has a big impact on lock time. Even on a cold start, if several SVs are overhead with 25 dB SNR, it doesn't take long to collect enough almanac data to calculate a position. Longer cold-start times then 3-4 minutes would seem to indicate a problem with the antenna, receiver, interference, and/or visibility to the satellites.

ghost avatar Dec 16 '15 14:12 ghost

1m34s to write the whole alp

cyoung avatar Dec 16 '15 18:12 cyoung

@AvSquirrel - thanks for the info. Do you know of a definitive way to tell which mode my unit is starting up in?

cyoung avatar Dec 16 '15 18:12 cyoung

Does this code work at all?

On Wed, Dec 16, 2015 at 12:26 PM, cyoung [email protected] wrote:

@AvSquirrel https://github.com/AvSquirrel - thanks for the info. Do you know of a definitive way to tell which mode my unit is starting up in?

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/pull/148#issuecomment-165200674.

jamez70 avatar Dec 16 '15 18:12 jamez70

Be advised: in the real world, GPS altitude is ROUTINELY off by as much as +/- 90 - 120 feet. Sometimes a lot more. Occasionally a bit less.

On 12/16/2015 12:26 PM, cyoung wrote:

@AvSquirrel https://github.com/AvSquirrel - thanks for the info. Do you know of a definitive way to tell which mode my unit is starting up in?

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/pull/148#issuecomment-165200674.

skypuppy avatar Dec 16 '15 18:12 skypuppy

@cyoung - With the existing Stratux code base, you should be able to parse the NMEA messages to see if the receiver is in "warm start" versus "cold start" by the presence of clock signal and almanac data.

Clock data is the first field in the GxRMC and GxGGA messages, and will show the current UTC time in HHMMSS.ss format. The presence of satellite azimuth / elevation data in the GPGSV (GPS/WAAS) and GLGSV (GLONASS) tells you that the receiver still has an almanac.

The data below is warm-start console output from my Neo M8N, after being off for about six hours. The timestamps ahead of the $Gxxxx were appended by the u-center software and wouldn't normally be seen on the RPi. You can see from the GNTXT messages that it takes about two seconds to run through startup and antenna initialization. However, the GNRMC and GNGGA messages contain cached clock data, and the GxGSV messages still hold a list of satellites that the receiver is attempting to track. Previous fix information has been lost / invalidated, as can be seen by the 99.99° lat/lon.

19:51:24  $GNTXT,01,01,02,Resetting GNSS*3B
19:51:24  $GNTXT,01,01,02,RF0 dev ok*04
19:51:25  $GNRMC,195124.98,V,,,,,,,161215,,,N*68
19:51:25  $GNVTG,,,,,,,,,N*2E
19:51:25  $GNGGA,195124.98,,,,,0,00,99.99,,,,,,*73
19:51:25  $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
19:51:25  $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
19:51:25  $GPGSV,3,1,10,08,17,300,,10,69,316,,14,48,233,,15,20,059,*7C
19:51:25  $GPGSV,3,2,10,18,70,081,,20,08,105,,21,41,170,,22,59,299,*7E
19:51:25  $GPGSV,3,3,10,24,45,081,,27,21,267,*73
19:51:25  $GLGSV,3,1,09,66,28,069,,67,64,001,,68,30,286,,75,04,012,*6D
19:51:25  $GLGSV,3,2,09,76,34,058,,77,31,124,,82,36,230,,83,38,305,*6B
19:51:25  $GLGSV,3,3,09,84,03,346,*52
19:51:25  $GNGLL,,,,,195124.98,V,N*5F
19:51:25  $GNTXT,01,01,02,ANTSTATUS=INIT*3B
19:51:26  $GNRMC,195126.00,V,,,,,,,161215,,,N*6B
19:51:26  $GNVTG,,,,,,,,,N*2E
19:51:26  $GNGGA,195126.00,,,,,0,00,99.99,,,,,,*70
19:51:26  $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
19:51:26  $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
19:51:26  $GPGSV,3,1,10,08,17,300,,10,69,316,,14,48,233,,15,20,059,*7C
19:51:26  $GPGSV,3,2,10,18,70,081,,20,08,105,,21,41,170,,22,59,299,*7E
19:51:26  $GPGSV,3,3,10,24,45,081,,27,21,267,*73
19:51:26  $GLGSV,3,1,11,66,28,069,,67,64,001,,68,30,286,,75,04,012,*64
19:51:26  $GLGSV,3,2,11,76,34,058,,77,31,124,,82,36,230,,83,38,305,*62
19:51:26  $GLGSV,3,3,11,84,03,346,,,,,32,,,,32*5B
19:51:26  $GNGLL,,,,,195126.00,V,N*5C
19:51:26  $GNTXT,01,01,02,ANTSTATUS=OK*25
19:51:27  $GNRMC,195127.00,V,,,,,,,161215,,,N*6A
19:51:27  $GNVTG,,,,,,,,,N*2E
19:51:27  $GNGGA,195127.00,,,,,0,00,99.99,,,,,,*71
19:51:27  $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
19:51:27  $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
19:51:27  $GPGSV,3,1,10,08,17,300,,10,69,316,,14,48,233,,15,20,059,*7C
19:51:27  $GPGSV,3,2,10,18,70,081,,20,08,105,,21,41,170,,22,59,299,*7E
19:51:27  $GPGSV,3,3,10,24,45,081,,27,21,267,*73
19:51:27  $GLGSV,3,1,11,66,28,069,,67,64,001,,68,30,286,,75,04,012,*64
19:51:27  $GLGSV,3,2,11,76,34,058,,77,31,124,,82,36,230,,83,38,305,*62
19:51:27  $GLGSV,3,3,11,84,03,346,,,,,30,,,,31*5A
19:51:27  $GNGLL,,,,,195127.00,V,N*5D

Compare to a cold start. The clock signal is gone, and the GxGSV messages are empty. (Also note that the console timestamp is stuck on the last known time.)

19:57:32  $GNTXT,01,01,02,Resetting GNSS*3B
19:57:32  $GNTXT,01,01,02,RF0 dev ok*04
19:57:32  $GNRMC,,V,,,,,,,,,,N*4D
19:57:32  $GNVTG,,,,,,,,,N*2E
19:57:32  $GNGGA,,,,,,0,00,99.99,,,,,,*56
19:57:32  $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
19:57:32  $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
19:57:32  $GPGSV,1,1,00*79
19:57:32  $GLGSV,1,1,00*65
19:57:32  $GNGLL,,,,,,V,N*7A
19:57:32  $GNTXT,01,01,02,ANTSTATUS=INIT*3B
19:57:32  $GNRMC,,V,,,,,,,,,,N*4D
19:57:32  $GNVTG,,,,,,,,,N*2E
19:57:32  $GNGGA,,,,,,0,00,99.99,,,,,,*56
19:57:32  $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
19:57:32  $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
19:57:32  $GPGSV,1,1,00*79
19:57:32  $GLGSV,1,1,00*65
19:57:32  $GNGLL,,,,,,V,N*7A
19:57:32  $GNTXT,01,01,02,ANTSTATUS=OK*25
19:57:32  $GNRMC,,V,,,,,,,,,,N*4D
19:57:32  $GNVTG,,,,,,,,,N*2E
19:57:32  $GNGGA,,,,,,0,00,99.99,,,,,,*56
19:57:32  $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
19:57:32  $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
19:57:32  $GPGSV,1,1,00*79
19:57:32  $GLGSV,1,1,00*65
19:57:32  $GNGLL,,,,,,V,N*7A

If you decide to implement the UBX packet format instead of NMEA, there's a lot of cool, fine-grained data available to us. Poking around in u-center, I can view per-satellite ephemeris / almanac data and validity periods, real-time horizontal and vertical accuracy estimates, and other goodies. It's also more efficient than NMEA text, so you could increase sample rate without hammering the connection.

ghost avatar Dec 16 '15 20:12 ghost

GPS altitude is just plain horrible. It is usually off several hundred feet on the ground, especially at the beginning or initially. I have run my GPS overnight and the altitude is almost never constant.

jamez70 avatar Dec 16 '15 20:12 jamez70

You could also turn off the NMEA messages that you do not want, so slow them down to a slower rate than 10hz. I had done this before with the uBlox GPS

On Wed, Dec 16, 2015 at 2:36 PM, AvSquirrel [email protected] wrote:

@cyoung https://github.com/cyoung - With the existing Stratux code base, you should be able to parse the NMEA messages to see if the receiver is in "warm start" versus "cold start" by the presence of clock signal and almanac data.

Clock data is the first field in the GxRMC and GxGGA messages, and will show the current UTC time in HHMMSS.ss format. The presence of satellite azimuth / elevation data in the GPGSV (GPS/WAAS) and GLGSV (GLONASS) tells you that the receiver still has an almanac.

The data below is warm-start console output from my Neo M8N, after being off for about six hours. The timestamps ahead of the $Gxxxx were appended by the u-center software and wouldn't normally be seen on the RPi. You can see from the GNTXT messages that it takes about two seconds to run through startup and antenna initialization. However, the GNRMC and GNGGA messages contain cached clock data, and the GxGSV messages still hold a list of satellites that the receiver is attempting to track. Previous fix information has been lost / invalidated, as can be seen by the 99.99° lat/lon.

19:51:24 $GNTXT,01,01,02,Resetting GNSS_3B 19:51:24 $GNTXT,01,01,02,RF0 dev ok_04 19:51:25 $GNRMC,195124.98,V,,,,,,,161215,,,N_68 19:51:25 $GNVTG,,,,,,,,,N_2E 19:51:25 $GNGGA,195124.98,,,,,0,00,99.99,,,,,,_73 19:51:25 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:51:25 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:51:25 $GPGSV,3,1,10,08,17,300,,10,69,316,,14,48,233,,15,20,059,_7C 19:51:25 $GPGSV,3,2,10,18,70,081,,20,08,105,,21,41,170,,22,59,299,_7E 19:51:25 $GPGSV,3,3,10,24,45,081,,27,21,267,_73 19:51:25 $GLGSV,3,1,09,66,28,069,,67,64,001,,68,30,286,,75,04,012,_6D 19:51:25 $GLGSV,3,2,09,76,34,058,,77,31,124,,82,36,230,,83,38,305,_6B 19:51:25 $GLGSV,3,3,09,84,03,346,_52 19:51:25 $GNGLL,,,,,195124.98,V,N_5F 19:51:25 $GNTXT,01,01,02,ANTSTATUS=INIT_3B 19:51:26 $GNRMC,195126.00,V,,,,,,,161215,,,N_6B 19:51:26 $GNVTG,,,,,,,,,N_2E 19:51:26 $GNGGA,195126.00,,,,,0,00,99.99,,,,,,_70 19:51:26 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:51:26 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:51:26 $GPGSV,3,1,10,08,17,300,,10,69,316,,14,48,233,,15,20,059,_7C 19:51:26 $GPGSV,3,2,10,18,70,081,,20,08,105,,21,41,170,,22,59,299,_7E 19:51:26 $GPGSV,3,3,10,24,45,081,,27,21,267,_73 19:51:26 $GLGSV,3,1,11,66,28,069,,67,64,001,,68,30,286,,75,04,012,_64 19:51:26 $GLGSV,3,2,11,76,34,058,,77,31,124,,82,36,230,,83,38,305,_62 19:51:26 $GLGSV,3,3,11,84,03,346,,,,,32,,,,32_5B 19:51:26 $GNGLL,,,,,195126.00,V,N_5C 19:51:26 $GNTXT,01,01,02,ANTSTATUS=OK_25 19:51:27 $GNRMC,195127.00,V,,,,,,,161215,,,N_6A 19:51:27 $GNVTG,,,,,,,,,N_2E 19:51:27 $GNGGA,195127.00,,,,,0,00,99.99,,,,,,_71 19:51:27 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:51:27 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:51:27 $GPGSV,3,1,10,08,17,300,,10,69,316,,14,48,233,,15,20,059,_7C 19:51:27 $GPGSV,3,2,10,18,70,081,,20,08,105,,21,41,170,,22,59,299,_7E 19:51:27 $GPGSV,3,3,10,24,45,081,,27,21,267,_73 19:51:27 $GLGSV,3,1,11,66,28,069,,67,64,001,,68,30,286,,75,04,012,_64 19:51:27 $GLGSV,3,2,11,76,34,058,,77,31,124,,82,36,230,,83,38,305,_62 19:51:27 $GLGSV,3,3,11,84,03,346,,,,,30,,,,31_5A 19:51:27 $GNGLL,,,,,195127.00,V,N_5D

Compare to a cold start. The clock signal is gone, and the GxGSV messages are empty. (Also note that the console timestamp is stuck on the last known time.)

19:57:32 $GNTXT,01,01,02,Resetting GNSS_3B 19:57:32 $GNTXT,01,01,02,RF0 dev ok_04 19:57:32 $GNRMC,,V,,,,,,,,,,N_4D 19:57:32 $GNVTG,,,,,,,,,N_2E 19:57:32 $GNGGA,,,,,,0,00,99.99,,,,,,_56 19:57:32 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:57:32 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:57:32 $GPGSV,1,1,00_79 19:57:32 $GLGSV,1,1,00_65 19:57:32 $GNGLL,,,,,,V,N_7A 19:57:32 $GNTXT,01,01,02,ANTSTATUS=INIT_3B 19:57:32 $GNRMC,,V,,,,,,,,,,N_4D 19:57:32 $GNVTG,,,,,,,,,N_2E 19:57:32 $GNGGA,,,,,,0,00,99.99,,,,,,_56 19:57:32 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:57:32 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:57:32 $GPGSV,1,1,00_79 19:57:32 $GLGSV,1,1,00_65 19:57:32 $GNGLL,,,,,,V,N_7A 19:57:32 $GNTXT,01,01,02,ANTSTATUS=OK_25 19:57:32 $GNRMC,,V,,,,,,,,,,N_4D 19:57:32 $GNVTG,,,,,,,,,N_2E 19:57:32 $GNGGA,,,,,,0,00,99.99,,,,,,_56 19:57:32 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:57:32 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:57:32 $GPGSV,1,1,00_79 19:57:32 $GLGSV,1,1,00_65 19:57:32 $GNGLL,,,,,,V,N_7A

If you decide to implement the UBX packet format instead of NMEA, there's a lot of cool, fine-grained data available to us. Poking around in u-center, I can view per-satellite ephemeris / almanac data and validity periods, real-time horizontal and vertical accuracy estimates, and other goodies. It's also more efficient than NMEA text, so you could increase sample rate without hammering the connection.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/pull/148#issuecomment-165231426.

jamez70 avatar Dec 16 '15 20:12 jamez70

These tests do not refer to the gps hooked into stratux, but my own little code.

Note: the "ulitmate gps" from adafruit already has the battery clip on the board, for keeping time and etc. data. It uses a coin battery so should last about 5 years before needing replacement.

I have waited over a week to restart it (with battery in) and it hooked in within 15 seconds (as long as it has sky view. I did opt for the external amplified antenna and it is great!) Then, another week without battery and it hooked in in under a minute.

Be also advised re GPS and tablet apps; a tablet app prior to iFlyGPS performed software smoothing of gps altitude data and was always, always at least 70 feet below actual so the app software includes some kind offset during it's smoothing algorithm.. iFly does not apply an offset, thank the Lord, but I can't tell for sure if they are using an altitude smoothing algorithm or not but I think they are.

I've not tested naviator, avare, or any other tablet app for gps smoothing or offset trouble. I tried during the Garmin 30 day free trial but was stymied by results I was seeing. The Garmin test was last year (2014) and I don't remember details, just the results. This could be relevant during your stratux software development efforts. It's bad juju for us AND the tablet app to both use a smoothing algorithm especially if SBAS is in place.

Skypuppy.

On 12/16/2015 02:35 PM, AvSquirrel wrote:

@cyoung https://github.com/cyoung - With the existing Stratux code base, you should be able to parse the NMEA messages to see if the receiver is in "warm start" versus "cold start" by the presence of clock signal and almanac data.

Clock data is the first field in the GxRMC and GxGGA messages, and will show the current UTC time in HHMMSS.ss format. The presence of satellite azimuth / elevation data in the GPGSV (GPS/WAAS) and GLGSV (GLONASS) tells you that the receiver still has an almanac.

The data below is warm-start console output from my Neo M8N, after being off for about six hours. The timestamps ahead of the $Gxxxx were appended by the u-center software and wouldn't normally be seen on the RPi. You can see from the GNTXT messages that it takes about two seconds to run through startup and antenna initialization. However, the GNRMC and GNGGA messages contain cached clock data, and the GxGSV messages still hold a list of satellites that the receiver is attempting to track. Previous fix information has been lost / invalidated, as can be seen by the 99.99° lat/lon.

|19:51:24 $GNTXT,01,01,02,Resetting GNSS_3B 19:51:24 $GNTXT,01,01,02,RF0 dev ok_04 19:51:25 $GNRMC,195124.98,V,,,,,,,161215,,,N_68 19:51:25 $GNVTG,,,,,,,,,N_2E 19:51:25 $GNGGA,195124.98,,,,,0,00,99.99,,,,,,_73 19:51:25 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:51:25 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:51:25 $GPGSV,3,1,10,08,17,300,,10,69,316,,14,48,233,,15,20,059,_7C 19:51:25 $GPGSV,3,2,10,18,70,081,,20,08,105,,21,41,170,,22,59,299,_7E 19:51:25 $GPGSV,3,3,10,24,45,081,,27,21,267,_73 19:51:25 $GLGSV,3,1,09,66,28,069,,67,64,001,,68,30,286,,75,04,012,_6D 19:51:25 $GLGSV,3,2,09,76,34,058,,77,31,124,,82,36,230,,83,38,305,_6B 19:51:25 $GLGSV,3,3,09,84,03,346,_52 19:51:25 $GNGLL,,,,,195124.98,V,N_5F 19:51:25 $GNTXT,01,01,02,ANTSTATUS=INIT_3B 19:51:26 $GNRMC,195126.00,V,,,,,,,161215,,,N_6B 19:51:26 $GNVTG,,,,,,,,,N_2E 19:51:26 $GNGGA,195126.00,,,,,0,00,99.99,,,,,,_70 19:51:26 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:51:26 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:51:26 $GPGSV,3,1,10,08,17,300,,10,69,316,,14,48,233,,15,20,059,_7C 19:51:26 $GPGSV,3,2,10,18,70,081,,20,08,105,,21,41,170,,22,59,299,_7E 19:51:26 $GPGSV,3,3,10,24,45,081,,27,21,267,_73 19:51:26 $GLGSV,3,1,11,66,28,069,,67,64,001,,68,30,286,,75,04,012,_64 19:51:26 $GLGSV,3,2,11,76,34,058,,77,31,124,,82,36,230,,83,38,305,_62 19:51:26 $GLGSV,3,3,11,84,03,346,,,,,32,,,,32_5B 19:51:26 $GNGLL,,,,,195126.00,V,N_5C 19:51:26 $GNTXT,01,01,02,ANTSTATUS=OK_25 19:51:27 $GNRMC,195127.00,V,,,,,,,161215,,,N_6A 19:51:27 $GNVTG,,,,,,,,,N_2E 19:51:27 $GNGGA,195127.00,,,,,0,00,99.99,,,,,,_71 19:51:27 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:51:27 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:51:27 $GPGSV,3,1,10,08,17,300,,10,69,316,,14,48,233,,15,20,059,_7C 19:51:27 $GPGSV,3,2,10,18,70,081,,20,08,105,,21,41,170,,22,59,299,_7E 19:51:27 $GPGSV,3,3,10,24,45,081,,27,21,267,_73 19:51:27 $GLGSV,3,1,11,66,28,069,,67,64,001,,68,30,286,,75,04,012,_64 19:51:27 $GLGSV,3,2,11,76,34,058,,77,31,124,,82,36,230,,83,38,305,_62 19:51:27 $GLGSV,3,3,11,84,03,346,,,,,30,,,,31_5A 19:51:27 $GNGLL,,,,,195127.00,V,N_5D |

Compare to a cold start. The clock signal is gone, and the GxGSV messages are empty. (Also note that the console timestamp is stuck on the last known time.)

|19:57:32 $GNTXT,01,01,02,Resetting GNSS_3B 19:57:32 $GNTXT,01,01,02,RF0 dev ok_04 19:57:32 $GNRMC,,V,,,,,,,,,,N_4D 19:57:32 $GNVTG,,,,,,,,,N_2E 19:57:32 $GNGGA,,,,,,0,00,99.99,,,,,,_56 19:57:32 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:57:32 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:57:32 $GPGSV,1,1,00_79 19:57:32 $GLGSV,1,1,00_65 19:57:32 $GNGLL,,,,,,V,N_7A 19:57:32 $GNTXT,01,01,02,ANTSTATUS=INIT_3B 19:57:32 $GNRMC,,V,,,,,,,,,,N_4D 19:57:32 $GNVTG,,,,,,,,,N_2E 19:57:32 $GNGGA,,,,,,0,00,99.99,,,,,,_56 19:57:32 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:57:32 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:57:32 $GPGSV,1,1,00_79 19:57:32 $GLGSV,1,1,00_65 19:57:32 $GNGLL,,,,,,V,N_7A 19:57:32 $GNTXT,01,01,02,ANTSTATUS=OK_25 19:57:32 $GNRMC,,V,,,,,,,,,,N_4D 19:57:32 $GNVTG,,,,,,,,,N_2E 19:57:32 $GNGGA,,,,,,0,00,99.99,,,,,,_56 19:57:32 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:57:32 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:57:32 $GPGSV,1,1,00_79 19:57:32 $GLGSV,1,1,00_65 19:57:32 $GNGLL,,,,,,V,N_7A |

If you decide to implement the UBX packet format instead of NMEA, there's a lot of cool, fine-grained data available to us. Poking around in u-center, I can view per-satellite ephemeris / almanac data and validity periods, real-time horizontal and vertical accuracy estimates, and other goodies. It's also more efficient than NMEA text, so you could increase sample rate without hammering the connection.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/pull/148#issuecomment-165231426.

skypuppy avatar Dec 16 '15 21:12 skypuppy

yeah, several gps chips accomodate that.

On 12/16/2015 03:02 PM, jamez70 wrote:

You could also turn off the NMEA messages that you do not want, so slow them down to a slower rate than 10hz. I had done this before with the uBlox GPS

On Wed, Dec 16, 2015 at 2:36 PM, AvSquirrel [email protected] wrote:

@cyoung https://github.com/cyoung - With the existing Stratux code base, you should be able to parse the NMEA messages to see if the receiver is in "warm start" versus "cold start" by the presence of clock signal and almanac data.

Clock data is the first field in the GxRMC and GxGGA messages, and will show the current UTC time in HHMMSS.ss format. The presence of satellite azimuth / elevation data in the GPGSV (GPS/WAAS) and GLGSV (GLONASS) tells you that the receiver still has an almanac.

The data below is warm-start console output from my Neo M8N, after being off for about six hours. The timestamps ahead of the $Gxxxx were appended by the u-center software and wouldn't normally be seen on the RPi. You can see from the GNTXT messages that it takes about two seconds to run through startup and antenna initialization. However, the GNRMC and GNGGA messages contain cached clock data, and the GxGSV messages still hold a list of satellites that the receiver is attempting to track. Previous fix information has been lost / invalidated, as can be seen by the 99.99° lat/lon.

19:51:24 $GNTXT,01,01,02,Resetting GNSS_3B 19:51:24 $GNTXT,01,01,02,RF0 dev ok_04 19:51:25 $GNRMC,195124.98,V,,,,,,,161215,,,N_68 19:51:25 $GNVTG,,,,,,,,,N_2E 19:51:25 $GNGGA,195124.98,,,,,0,00,99.99,,,,,,_73 19:51:25 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:51:25 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:51:25 $GPGSV,3,1,10,08,17,300,,10,69,316,,14,48,233,,15,20,059,_7C 19:51:25 $GPGSV,3,2,10,18,70,081,,20,08,105,,21,41,170,,22,59,299,_7E 19:51:25 $GPGSV,3,3,10,24,45,081,,27,21,267,_73 19:51:25 $GLGSV,3,1,09,66,28,069,,67,64,001,,68,30,286,,75,04,012,_6D 19:51:25 $GLGSV,3,2,09,76,34,058,,77,31,124,,82,36,230,,83,38,305,_6B 19:51:25 $GLGSV,3,3,09,84,03,346,_52 19:51:25 $GNGLL,,,,,195124.98,V,N_5F 19:51:25 $GNTXT,01,01,02,ANTSTATUS=INIT_3B 19:51:26 $GNRMC,195126.00,V,,,,,,,161215,,,N_6B 19:51:26 $GNVTG,,,,,,,,,N_2E 19:51:26 $GNGGA,195126.00,,,,,0,00,99.99,,,,,,_70 19:51:26 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:51:26 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:51:26 $GPGSV,3,1,10,08,17,300,,10,69,316,,14,48,233,,15,20,059,_7C 19:51:26 $GPGSV,3,2,10,18,70,081,,20,08,105,,21,41,170,,22,59,299,_7E 19:51:26 $GPGSV,3,3,10,24,45,081,,27,21,267,_73 19:51:26 $GLGSV,3,1,11,66,28,069,,67,64,001,,68,30,286,,75,04,012,_64 19:51:26 $GLGSV,3,2,11,76,34,058,,77,31,124,,82,36,230,,83,38,305,_62 19:51:26 $GLGSV,3,3,11,84,03,346,,,,,32,,,,32_5B 19:51:26 $GNGLL,,,,,195126.00,V,N_5C 19:51:26 $GNTXT,01,01,02,ANTSTATUS=OK_25 19:51:27 $GNRMC,195127.00,V,,,,,,,161215,,,N_6A 19:51:27 $GNVTG,,,,,,,,,N_2E 19:51:27 $GNGGA,195127.00,,,,,0,00,99.99,,,,,,_71 19:51:27 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:51:27 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:51:27 $GPGSV,3,1,10,08,17,300,,10,69,316,,14,48,233,,15,20,059,_7C 19:51:27 $GPGSV,3,2,10,18,70,081,,20,08,105,,21,41,170,,22,59,299,_7E 19:51:27 $GPGSV,3,3,10,24,45,081,,27,21,267,_73 19:51:27 $GLGSV,3,1,11,66,28,069,,67,64,001,,68,30,286,,75,04,012,_64 19:51:27 $GLGSV,3,2,11,76,34,058,,77,31,124,,82,36,230,,83,38,305,_62 19:51:27 $GLGSV,3,3,11,84,03,346,,,,,30,,,,31_5A 19:51:27 $GNGLL,,,,,195127.00,V,N_5D

Compare to a cold start. The clock signal is gone, and the GxGSV messages are empty. (Also note that the console timestamp is stuck on the last known time.)

19:57:32 $GNTXT,01,01,02,Resetting GNSS_3B 19:57:32 $GNTXT,01,01,02,RF0 dev ok_04 19:57:32 $GNRMC,,V,,,,,,,,,,N_4D 19:57:32 $GNVTG,,,,,,,,,N_2E 19:57:32 $GNGGA,,,,,,0,00,99.99,,,,,,_56 19:57:32 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:57:32 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:57:32 $GPGSV,1,1,00_79 19:57:32 $GLGSV,1,1,00_65 19:57:32 $GNGLL,,,,,,V,N_7A 19:57:32 $GNTXT,01,01,02,ANTSTATUS=INIT_3B 19:57:32 $GNRMC,,V,,,,,,,,,,N_4D 19:57:32 $GNVTG,,,,,,,,,N_2E 19:57:32 $GNGGA,,,,,,0,00,99.99,,,,,,_56 19:57:32 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:57:32 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:57:32 $GPGSV,1,1,00_79 19:57:32 $GLGSV,1,1,00_65 19:57:32 $GNGLL,,,,,,V,N_7A 19:57:32 $GNTXT,01,01,02,ANTSTATUS=OK_25 19:57:32 $GNRMC,,V,,,,,,,,,,N_4D 19:57:32 $GNVTG,,,,,,,,,N_2E 19:57:32 $GNGGA,,,,,,0,00,99.99,,,,,,_56 19:57:32 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:57:32 $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99_2E 19:57:32 $GPGSV,1,1,00_79 19:57:32 $GLGSV,1,1,00_65 19:57:32 $GNGLL,,,,,,V,N_7A

If you decide to implement the UBX packet format instead of NMEA, there's a lot of cool, fine-grained data available to us. Poking around in u-center, I can view per-satellite ephemeris / almanac data and validity periods, real-time horizontal and vertical accuracy estimates, and other goodies. It's also more efficient than NMEA text, so you could increase sample rate without hammering the connection.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/pull/148#issuecomment-165231426.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/pull/148#issuecomment-165238380.

skypuppy avatar Dec 16 '15 21:12 skypuppy

do you thing gpsd would be of any benefit to aid in displaying GPS status to the web tool?

http://www.danmandle.com/blog/getting-gpsd-to-work-with-python/

On Dec 16, 2015, at 3:56 PM, jamez70 [email protected] wrote:

GPS altitude is just plain horrible. It is usually off several hundred feet on the ground, especially at the beginning or initially. I have run my GPS overnight and the altitude is almost never constant.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/pull/148#issuecomment-165236912.

duecedriver avatar Dec 16 '15 21:12 duecedriver

does the RY835 present the fused 6050 imu internal vectors or the raw gyro data.. the 6050 has the option to output both depending on a jumper

On Dec 16, 2015, at 3:56 PM, jamez70 [email protected] wrote:

GPS altitude is just plain horrible. It is usually off several hundred feet on the ground, especially at the beginning or initially. I have run my GPS overnight and the altitude is almost never constant.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/pull/148#issuecomment-165236912.

duecedriver avatar Dec 16 '15 21:12 duecedriver

For serious use of the MPU-6050, Jeff Rowberg has done an excellent job. See his I2C lib: http://www.i2cdevlib.com/devices/mpu6050 http://www.i2cdevlib.com/devices/mpu6050 Or the latest code on github: https://github.com/jrowberg/i2cdevlib/tree/master/Arduino/MPU6050 https://github.com/jrowberg/i2cdevlib/tree/master/Arduino/MPU6050 The FreeIMU library includes the MPU-6050 code from Jeff Rowberg. The FreeIMU library: http://www.varesano.net/projects/hardware/FreeIMU http://www.varesano.net/projects/hardware/FreeIMU To start with the MPU-6050, see the page of InvenSense: http://www.invensense.com/mems/gyro/mpu6050.html http://www.invensense.com/mems/gyro/mpu6050.html

duecedriver avatar Dec 16 '15 21:12 duecedriver

Fee access for developers for the free MPU code librarys that do the secret sauce work for you!!

http://www.invensense.com/developers/login/ http://www.invensense.com/developers/login/

On Dec 16, 2015, at 3:56 PM, jamez70 [email protected] wrote:

GPS altitude is just plain horrible. It is usually off several hundred feet on the ground, especially at the beginning or initially. I have run my GPS overnight and the altitude is almost never constant.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/pull/148#issuecomment-165236912.

duecedriver avatar Dec 16 '15 21:12 duecedriver

Ref: the comments in this thread about GPS altitude being so far off. If that's so, how is it we can fly WAAS LPV approaches? Are you perhaps referring to non-WAAS altitudes? Sorry if this question is off topic.

bkwny avatar Jan 31 '16 11:01 bkwny

Non-WAAS elevations are allowed to be +- 30 meters, IIRC, with outliers even larger than that. And usually are.

On 01/31/2016 05:27 AM, bkwny wrote:

Ref: the comments in this thread about GPS altitude being so far off. If that's so, how is it we can fly WAAS LPV approaches? Are you perhaps referring to non-WAAS altitudes? Sorry if this question is off topic.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/pull/148#issuecomment-177471122.

skypuppy avatar Jan 31 '16 15:01 skypuppy