/dev/ttyACM0 data problem


5 posts
by oceaneng1 » Wed Jun 20, 2012 3:09 pm
Hello,
I've been using my desktop (Ubuntu 11.10 , 3.0.0-21-generic #35-Ubuntu SMP Fri May 25 17:57:41 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux) to record a data stream from an external GPS using:
Code: Select all
timelimit -t3 -T4 cat /dev/ttyACM0 > data.bin


When I look at the file (GHex) I see a string like the following:
... 0xB5 0x62 0x01 0x12 0x24 0x00 0x70 ...

If I connect the GPS to the pi, issue the same timelimit command, I get the following:
... 0xB5 0x62 0x01 0x24 0x00 0x70 ...

None of the 0x12 characters are recorded (in the entire stream!). Anyone have any ideas what is going on? Unfortunately, the 0x12 characters are part of an important data message identifier and I can't ignore them.

Thanks for any suggestions.
Posts: 3
Joined: Wed Jun 20, 2012 3:02 pm
by gordon@drogon.net » Wed Jun 20, 2012 5:05 pm
oceaneng1 wrote:Hello,
I've been using my desktop (Ubuntu 11.10 , 3.0.0-21-generic #35-Ubuntu SMP Fri May 25 17:57:41 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux) to record a data stream from an external GPS using:
Code: Select all
timelimit -t3 -T4 cat /dev/ttyACM0 > data.bin


When I look at the file (GHex) I see a string like the following:
... 0xB5 0x62 0x01 0x12 0x24 0x00 0x70 ...

If I connect the GPS to the pi, issue the same timelimit command, I get the following:
... 0xB5 0x62 0x01 0x24 0x00 0x70 ...

None of the 0x12 characters are recorded (in the entire stream!). Anyone have any ideas what is going on? Unfortunately, the 0x12 characters are part of an important data message identifier and I can't ignore them.

Thanks for any suggestions.


Have you turned off the GETTY process that normally runs on the line? Also turn off the console messages...

See the /etc/intitab for the getty line, and see /boot/cmdline.txt for the console output.

0x12 is dec 18 is Control-R which is nothing too special though...

Possibly not the best way to read the serial port though, but writing a little program isn't that hard. Surprised the GPS is outputting binary in that way and not standard NMEA codes (which are printable ascii) or is it one of the ones that have been re-flashed to provide high-speed data in a binary format?


-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1421
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by oceaneng1 » Wed Jun 20, 2012 5:52 pm
Thanks for the suggestions. Will give them a try. I'm using a u-blox NEO-6. It does output the standard NMEA strings, but I've configured it to output the binary u-blox navigation messages as well.
Posts: 3
Joined: Wed Jun 20, 2012 3:02 pm
by jojopi » Wed Jun 20, 2012 6:30 pm
oceaneng1 wrote:None of the 0x12 characters are recorded (in the entire stream!).
0x12 is ^R, which is the default value for "rprnt", the input character that reprints the current input buffer (and is discarded in the process). If you want to read arbitrary data on a serial line it is essential to disable the kernel's handling of input control characters (aka canonical input processing):
Code: Select all
stty -icanon -F /dev/ttyACM0
There may be other settings that need changing.
User avatar
Posts: 1861
Joined: Tue Oct 11, 2011 8:38 pm
by oceaneng1 » Wed Jun 20, 2012 6:58 pm
Code: Select all
stty -icanon -F /dev/ttyACM0


That did the trick. Thanks very much.
Posts: 3
Joined: Wed Jun 20, 2012 3:02 pm