GPS2 Operation

[andycruce]

I am using a GPS2 in conjunction with an IMU brick and a Baro bricklet to record aerobatic aircraft performance.  GPU2 has a specified mimnium update period of 100ms.  When I record data it appears that the GPS doesn't update at that rate.  When flying at 150 kts there are periods of up to 1 sec where the GPS output doesn't change.  I created a test case for only the GPS using both the callback method and the direct access method (getcoordinates).  The direct access method is driven by a high accuracy timing system with resolution in the microsecod range.  Testing the device in a car moving at about 40 mph I found that if I set the update period to 1,000 ms the system mostly recorded a new position every update.  However at a 500ms  update there were many updates where the sensed lat long were the same even though the car was traveling at 40 mph.  As the update rate was increased the problem got worse.

 

Is there something I should be doing differently?  If you want to look into the problem I can share the test software via dropbox.  You will have to have access to VS 2015 to run the software.

 

Andy Cruce

[borg]

Mh, the period settings etc that you can set for the callback do not change the internal update rate of the Bricklet. Internally we will always update with the maximum available rate.

 

The rate should be 10hz. Let me try this out, i will come back to you tomorrow.

[borg]

There is indeed something funny going on with the update rate.

 

It seems like the full 10Hz update rate can't be achieved if SBAS is enabled (https://en.wikipedia.org/wiki/GNSS_augmentation)  . The GPS Bricklet V1.0 did not support SBAS so this was not a problem, but with the new V2.0 we have it enabled by default.

 

I will have to ask the manufacturer how exactly that is meant to work and how we can turn SBAS off to get the higher update rate. We will then have to add API to the Bindings so you can decide for yourself if you want 10Hz update rate or SBAS.

[andycruce]

Thanks for looking into this.  I'll await your reply.

 

Andy Cruce

[borg]

I finally figured out what is going on, took me the whole day!

 

We use SPI to communicate with the GPS IC, but it also supports UART. If you use UART, to get high update rates you have to change a configuration that increases the UART baudraute of the IC.

 

Turns out, if you use SPI you also have to increase the UART baudrate to get a higher update rate, even if you don't use UART at all...

 

Now we get 5Hz update rate with SBAS enabled and 10Hz update rate with SBAS disable, exactly as it is specified in the datasheet .

 

I added API for enabling/disabling SBAS (by default we will keep SBAS enabled, since it increases the position accuracy): https://github.com/Tinkerforge/gps-v2-bricklet/commit/fbe9bb461db9fb8ae876f1e6561fc0f39f813a4d

 

Attached you can find v2.0.2 as well as a version that has SBAS disabled by default. It would be nice if you can test the update rate with these firmwares.

 

I will have a test/log run over the weekend to make sure that everything is still stable etc, if everything works as expected i will release the firmware next Monday.

gps-v2-bricklet-firmware-v2.0.2-beta1.zbin

gps-v2-bricklet-firmware-v2.0.2-beta1-sbas-disabled.zbin

[andycruce]

I believe I got the firmware with the SBAS disabled and ran some of my test software again.  I used the call back method with the rate set to 100ms and some of the call backs were at the 100 ms rate.  A lot weren't.  I assume this is because the GPS is stationary and sometimes there isn't a noise error in the gps position from one call back to the next to trigger the call back.  Hope to get the gps in the plane sometime this week to check how it operates in the air.

 

In my actual data collection system I am using direct calls to the device to collect the data.  Shouldn't be a problem since there isn't much else going on so there isn't an issue with through put.  However, it does allow me to synchronize the gps data collection with the IMU and Baro collection.  One question I have is when I query the gps how old is the position information that is returned?  A 140 mph translates into 205 ft/sec or about 20 ft/100ms.  Is the the uncertainty or when I query the gps will I get a position close to the time I actually query the device?  Also, how much does the SBAS improve the position accuracy?

 

Andy

[borg]

To get the data immediately you can indeed use the callbacks. Just use a callback rate that is well below the 100ms. You will then automatically get a callback with every change that happens to the data.

 

That is something you can't do with getters, since you don't know if the data is 10ms or 80ms if you call a getter (it is somewhere between 0-99ms).

 

Regarding the SBAS accuracy improvement: I don't know. I can only link you to the wikipedia site: https://en.wikipedia.org/wiki/GNSS_augmentation#Satellite-based_augmentation_system. The various region specific SBAS implementations are described there.

 

As far as i can tell we also don't know if a SBAS satellite is currently in sight or not. There is no NMEA message for that unfortunately.

[andycruce]

As I understand it, if I set up a coordinates call back method with a call back time less than 100ms it will be automatically called whenever there are new gps data available.  Does this mean that all the other gps data other than coordinates is also updated?  In the coordinate call back method could I then use the get methods to retrieve things like motion, status, fix, etc and would these have the same time stamp as the coordinate call back results?  The alternate would be to have multiple call back methods which would be messy. 

 

Andy Cruce

[borg]

The other data does not have to change when the coordinates change. For examples the coordinates may change, but the fix and speed stays the same.

 

So to get all of the data at the exact point where it changes, you would indeed need to use callbacks for all.

 

But i think it should be good enough to use the callback for the coordinates and get the rest of the data with a getter. Either in the callback or perhaps just every second or similar in a loop.