- Fri Mar 15, 2013 3:17 pm
#157059
Hi All
This is for those of you who may need to read the binary data stream output from the Venus GPS board with an Arduino.
I couldn't find the information on the net so I worked it out and am reporting it here for what it is worth.
I needed the ECEF-x y and z coordinates to determine the straight line distance between two standard Venus GPS boards without trig.
The units were switched to binary output and were recorded with an OpenLog board onto an SD card.
This stream can also be read by the SkyTraq PC software provided on the Sparkfun site which is good for configuring the board as well.
The binary ECEF coordinates give a more precise description of the data output (0.01 meters) than the ASCII NEMA codes.
I want to average many successive measurements and it is always better to over sample the noise.
The binary data specification provided on the Sparkfun web site, however, did not specify the output format for the binary data stream read by the PC software
which is their Message ID 168 with a payload length of 59 bytes.
It is pretty easy to look at successive byte streams and see the edges of the fields (where the data changes with noise or time from measurement to measurement).
These fields generally match the data as it shows up on my PC screen even though there was one dilution of precision field which was not printed out on the PC screen.
The positive values like the 2-byte GPS Week (1731 at the moment) are read directly as a <hibyte,lowbyte> conversion.
The 4 byte GPS TOW reads to 0.01 seconds and is simply a <hibyte,byte,byte,lowbyte> conversion to an integer divided by 100.
The 4 byte latitude (where I live in North America) is read the same way, a <hibyte,byte,byte,lowbyte> conversion followed by 100.
The negative values for the longitude and the negative value of ecef-y where I live gave me fits for a while.
I finally wrote an Arduino code to simulate the binary stream with the correct checksum as described in the SkyTraq binary code application note.
I played with it until I figured out their (quite straightforward) coding.
For negative values the highest (most significant) bit in the 4-byte field acts as a sign bit but in a way that (newbie) I did not expect.
When that highest bit is set convert that highest bit to 0, convert the remaining bits to a (generally big) integer, subtract 2^(31) and divide by 100 to get meters.
If it is not set the value is positive as discussed above.
in this way <0,0,0,0> -> 0 meters and <0,0,0,1> -> 0.01 meters
Note that incrementing the least significant bit always increases the value of the result (making it less negative if it starts negative) so that highest bit is not a sign.
I like it... it doesn't waste any bits for the restricted data range that the values fall into... no need to be general.
It just took me more time than I would have liked to finally see what was happening.
by the way... I'm using these PPS signal from the two boards for synchronizing two devices separated by kilometers.
when the antennas for the two boards are side-by side the jitter is usually +/- 50 nanoseconds with a tail out to about +/- 70 nanoseconds.
very nice chips which work great with the Sparkfun Mega Pro Mini 3.3V boards and the OpenLog boards
This is for those of you who may need to read the binary data stream output from the Venus GPS board with an Arduino.
I couldn't find the information on the net so I worked it out and am reporting it here for what it is worth.
I needed the ECEF-x y and z coordinates to determine the straight line distance between two standard Venus GPS boards without trig.
The units were switched to binary output and were recorded with an OpenLog board onto an SD card.
This stream can also be read by the SkyTraq PC software provided on the Sparkfun site which is good for configuring the board as well.
The binary ECEF coordinates give a more precise description of the data output (0.01 meters) than the ASCII NEMA codes.
I want to average many successive measurements and it is always better to over sample the noise.
The binary data specification provided on the Sparkfun web site, however, did not specify the output format for the binary data stream read by the PC software
which is their Message ID 168 with a payload length of 59 bytes.
It is pretty easy to look at successive byte streams and see the edges of the fields (where the data changes with noise or time from measurement to measurement).
These fields generally match the data as it shows up on my PC screen even though there was one dilution of precision field which was not printed out on the PC screen.
The positive values like the 2-byte GPS Week (1731 at the moment) are read directly as a <hibyte,lowbyte> conversion.
The 4 byte GPS TOW reads to 0.01 seconds and is simply a <hibyte,byte,byte,lowbyte> conversion to an integer divided by 100.
The 4 byte latitude (where I live in North America) is read the same way, a <hibyte,byte,byte,lowbyte> conversion followed by 100.
The negative values for the longitude and the negative value of ecef-y where I live gave me fits for a while.
I finally wrote an Arduino code to simulate the binary stream with the correct checksum as described in the SkyTraq binary code application note.
I played with it until I figured out their (quite straightforward) coding.
For negative values the highest (most significant) bit in the 4-byte field acts as a sign bit but in a way that (newbie) I did not expect.
When that highest bit is set convert that highest bit to 0, convert the remaining bits to a (generally big) integer, subtract 2^(31) and divide by 100 to get meters.
If it is not set the value is positive as discussed above.
in this way <0,0,0,0> -> 0 meters and <0,0,0,1> -> 0.01 meters
Note that incrementing the least significant bit always increases the value of the result (making it less negative if it starts negative) so that highest bit is not a sign.
I like it... it doesn't waste any bits for the restricted data range that the values fall into... no need to be general.
It just took me more time than I would have liked to finally see what was happening.
by the way... I'm using these PPS signal from the two boards for synchronizing two devices separated by kilometers.
when the antennas for the two boards are side-by side the jitter is usually +/- 50 nanoseconds with a tail out to about +/- 70 nanoseconds.
very nice chips which work great with the Sparkfun Mega Pro Mini 3.3V boards and the OpenLog boards