WBT-200 Comms Protocol
From Hexten
The serial port parameters for both Bluetooth and serial over USB should be set as follows:
| Baud rate | 9600 |
|---|---|
| Parity | None |
| Data bits | 8 |
| Stop bits | 1 |
A typical conversation between the WBT-200 and computer looks like this
>> $PFST,FIRMWAREVERSION << $PFST,FIRMWAREVERSION,WBT200,3,31,6090,R2*77 >> $PFST,NORMAL << $PFST,NORMAL,*02 >> $PFST,READLOGGER << $PFST,READLOGGER,*17 << 0xFFFF, <length>, 0xFFFF << (length + 1) * 12 or 16 bytes of data << ==== >> $PFST,NORMAL << $PFST,NORMAL,*02
Commands and responses are terminated by a CR/LF pair ("\r\n" in C syntax).
Contents |
[edit] Protocol
In general when it receives a $PFST command the gps echoes a response that starts with the same string. If you don't get the matching response retry a few times and then report an error. Remember that although the gps uses Bluetooth or USB it's really a serial device. That means that you should build a bit of fudge into any code that talks to the device. In particular set generous timeouts and have your code retry commands that the gps doesn't acknowledge.
In normal operation the WBT-200 streams NMEA data continually. You may have to ignore quite a lot of NMEA data after sending the first $PFST command. The GPSBabel code skips up to 50 lines of data from the gps looking for the $PFST,FIRMWAREVERSION response.
[edit] Data format
The ==== in the conversation above represents a block of binary data, the size of which depends on the data format being used. More on this below.
The 16 bit length field - sandwiched between two 16 bit words that are always 0xFFFF - is the number of records minus 1. So if there are 100 records the value here will be 99.
In v1 format each record is three 32 bit words (i.e. 12 bytes) in little endian format:
time, latitude, longitude
In v2 format each record is four 32 bit words (16 bytes):
time, latitude, longitude, altitude
[edit] Time format
The time word uses packed fields as follows:
| Bits | Meaning | Range | Comment |
|---|---|---|---|
| 0-5 | second | 0-59 | |
| 6-11 | minute | 0-59 | |
| 12-16 | hour | 0-23 | |
| 17-21 | month day | 1-31 | |
| 22-25 | month | 1-12 | Month number |
| 26-31 | year | 0-63 | Year - 2000 |
[edit] Latitude, longitude format
The latitude and longitude fields are the decimal value multipled 10,000,000 so to get the floating point value divide the integer by ten million.
If the decoded latitude is >= 100 or <= -100 this point marks the start of a new track.
[edit] Altitude format
Version 2 format includes the altitude for each point. This is stored as the decimal altitude in metres multiplied by 10. To get the floating point altitude in metres divide this value by ten.
[edit] Junk after data
Once the WBT-200 has sent all the data it sends the following string: "##### Receive logger complete #####\n". Note that, unlike most responses, this string is terminated only by a linefeed character (ASCII 10).
After the data transfer send $PFST,NORMAL and skip anything else the gps sends until it replies with a $PFST,NORMAL acknowledge.
[edit] Format Sensing
So how do you know which data format the device is using? You can probably tell from the firmware version number but not knowing how the version numbering might change in the future I didn't fancy building in a dependency on that.
So the gpsbabel code looks at the <length> field and uses that to calculate the amount of data in v1 format it'd have to read from the device. It then reads that much data and attempts to decode it. If it gets decoding errors it assumes that it actually has data in v2 format - so it reads the additional bytes from the device (v2 data is larger) and tries to decode the whole block as v2 format.
This approach typically works fine as long as you have at least two points in memory. For a single point (a rare occurance) this heuristic will mis-detect V1 format - so the altitude will be missing even if it's available from the device.
[edit] WBT 201
Note that the WBT-201 uses a completely different command set.
