"adapt Keychain Pro" GPS logger and linux or Mac

Hi,


I have a "adapt keychain pro", which is a nice and small GPS
bluetooth-device and logger.


For the "bluetooth" aspect, the device works fine, but the problem is
that the software for the logger (which extracts logfiles from the
device and converts them into a standard file-format) is only available
for windows.


So, no mac, no linux, no java. Just plain windows executable. :-(


So, I ran the application in a windows "virtual box" and ran "usbmon" on
the linux host, so I could monitor the have a look at the traffic
going over the USB-wire and I found out this:

- the communication happens over a USB "serial port" service; the same
service used for the communication to the GPS NMEA communication.

- The commands to retrieve the data from the logger is in binary format.

The communication starts with the PC sending out this:


All PC to logger communications seams to start with these three bytes
"A0A100" and send with these two: "0D0A"


Return traffic then looks something like this:

(Again the "A0A100" in the beginning and the "0D0A" at the end.


Question:
Does this ring a bell to somebody? Is this some kind of standard also
used in other devices? Any documentation?

Or does this look like something completely unknown?




Any help appriciated.


Cheerio! Kr. Bonne.

Kristoff Bonne wrote:

Surely you don't need us to tell you that the 0D0A is otherwise known as
carriage-return/line-feed. (But possibly not that they are always in that
order because the carriage took a finite time to return to the left margin
during which the line feed is performed. If they were reversed then the next
character could be printed part way across the new line while the carriage
was still in motion.)

But it seems a bit eccentric to terminate a binary stream with traditional
text terminators...

Mike.
--
If reply address is invalid, remove spurious "@" and substitute "plus"
where needed.

Hi Mike,


Mike Coon schreef:


I guess it's just a quick hack. That way, they use the same record
seperator both "string" as "binary" transfer so you can use the same
piece of code.

And using a 2-byte record-seperator is good enough to to transfer binary
content without much fuss.


I've sent an email to the support-guys but -for the time being- no reply
yet. :-(

Kristoff Bonne wrote:

Ah, yes, that was what must have been in my mind below conscious level! If
the sequence 0D0A appears in the binary stream (assuming it is that degree
of binary) then it will look like a terminator. This is the sort of thing
that leads to the awkward "DLE-stuffing" used in the Garmin proprietary
protocol, despite their use of a data-length byte.

You didn't repeat the original text (and I can't be bothered to retrieve it)
but perhaps there is some other termination mechanism too, such as a length
byte?

Mike.
--
If reply address is invalid, remove spurious "@" and substitute "plus"
where needed.

Just a guess from a very limited set of data but it looks to me like
the fourth byte (or possibly the third and fourth byte if it's a
16-bit value, little-endian) is the message length. This would work
if the length is for all the bytes after the length byte and not
including the last three bytes. The last two are a CR/LF terminator
as already stated; maybe the other byte is a some sort of checksum?