Categories
other thoughts

Little Endian

[Yesterday run: 3.4 miles]

I’ve been all projecty and working on various stuff recently.  One of the things I’ve been playing with is trying to get some software to read the output of the GPS in my GPS disciplined oscillator.

I have a Windows program from Trimble which works fine.  But I was thinking about putting a BeagleBone or Arduino into the GPSDO and have it show interesting information on a little LCD, like the current GPS time and date.  I could even have it act as an NTP server to tell all of my other computers what the correct time/date is.

To do that, I need to now how to read the TSIP protocol coming from the GPS in that box.

I have the TSIP line routed to the front of the box, and I’ve been playing with this BeagleBone (white) running Debian Linux.  I can get to the data, so far so good.

I have two software packages that claim to be able to talk TSIP: gpsd, a GPS daemon program and ntpd, the NTP time server program.  Neither of them is successful in translating the TSIP coming from this thing.

So I dug around into the TSIP protocol information a bit.  And I was able to get some binary data from the serial port on the BBW  (beaglebone white) and put it in a file.  Using the ‘od’ command I can show the hexadecimal values of the data.  It was looking oh so close to the patterns I would expect, but something was not quite right.

Then I discovered that every pair of bytes is swapped.  !   This is a known thing in the computer world called “endian”.  You have your Big Endian computers and your Little Endian computers.  It has to do with the way the CPU fetches bytes from memory.  If it does one byte at a time, no problem.  But if it does multiple bytes at a time, some CPUs fetch the “high” byte first and some the “low” byte first.  As an example, pretend you have a number like  23,456 and your computer can put 3 digits in each memory hole.  So it puts 023 in one hole and 456 in another.  Some computers put 023 in hole number 5 and 456 in hole number 6.  Others put 023 in 6 and 456 in 5.  When these computers swap data they have to know which thing to send first.  I know that isn’t a very useful example.  Anyway…

I used this command:

dd if=/dev/ttyO2 of=gps.data conv=swab

which swaps the bytes around.  Now the gps data in the file gps.data actually looks pretty good.  I don’t know if the numbers are right, but the packet begin and end points make sense.

Ok, so where is this going wrong?  Is the GPS sending stuff to me in swapped order  (I think so), or is the serial port on the BBW doing this (seems unlikely)?  A mystery.  I may have to get another computer running linux and hook it up and see if I get the same effect.

I think I may be able to set up a named pipe (a file that passes data through) and have the dd command read from the serial port, swap the bytes and send it to the named pipe, kind of an inline translator.  Then I can point the ntpd program at the other end of the translator and see if it works.  Unfortunately that would be a one-way/read-only thing.  If it tries to write to the gps it will fail.

Later…

I tried the named pipe thing, that didn’t work.  But I was able to whip together a small program to parse the data from the GPS and it is working fine.  So, no endian problem after all.  Very strange.  I think maybe my “od” command was fooling me somehow.  The parser is working fine and I can see the data from the GPS just great.