GPS assist load in development #148
Conversation
|
current_14d.alp - which file is this? api link |
|
I have a Beagle USB protocol analyzer somewhere around here, I'll sniff the bus and see what is sent. |
|
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? |
|
Use this commit..I verified that it is uploaded |
|
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. |
|
@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. |
|
@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. |
|
1m34s to write the whole alp |
|
@AvSquirrel - thanks for the info. Do you know of a definitive way to tell which mode my unit is starting up in? |
|
Does this code work at all? On Wed, Dec 16, 2015 at 12:26 PM, cyoung [email protected] wrote:
|
|
Be advised: in the real world, GPS altitude is ROUTINELY off by as much On 12/16/2015 12:26 PM, cyoung wrote:
|
|
@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. 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.) 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. |
|
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. |
|
You could also turn off the NMEA messages that you do not want, so slow On Wed, Dec 16, 2015 at 2:36 PM, AvSquirrel [email protected]
|
|
These tests do not refer to the gps hooked into stratux, but my own Note: the "ulitmate gps" from adafruit already has the battery clip on I have waited over a week to restart it (with battery in) and it hooked Be also advised re GPS and tablet apps; a tablet app prior to iFlyGPS I've not tested naviator, avare, or any other tablet app for gps Skypuppy. On 12/16/2015 02:35 PM, AvSquirrel wrote:
|
|
yeah, several gps chips accomodate that. On 12/16/2015 03:02 PM, jamez70 wrote:
|
|
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/
|
|
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
|
|
For serious use of the MPU-6050, Jeff Rowberg has done an excellent job. |
|
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/
|
|
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. |
|
Non-WAAS elevations are allowed to be +- 30 meters, IIRC, with On 01/31/2016 05:27 AM, bkwny wrote:
|
This is in development. Could you help test it please? I just want you to see it to see if it works for you.