Running into problems with serial over USB

[edwar64896]

I am connecting a device (sound devices audio field recorder) to my RPI via a USB serial interface.

I am using libserialport to manage the serial device abstraction, a C library to do the required decoding, SWIG to abstract the library and nodejs/javascript to actually do the user interfacing.

I am running into problems with the serial device where the device appears to be dropping bytes from the datastream. This is causing a checksum failure. I am pretty sure that the device is sending the correct data, but I will have to do some additional troubleshooting to be 100% sure of this.

I am wondering if there are any known issues with rpi3b+ and serial/usb interfacing?

To give an example, a 17 byte timecode stream starts:

A5 F3 0E 14 0F 29 0F 00 00 00 ....

but every now and again the 4th byte (0x14) is missing. We only get 16 bytes and the checksum fails....

A5 F3 0E <14 - this is missing> 0F 29 0F 00 00 00 ....

This is a bit of a showstopper at the moment. Any advice would be much appreciated.

i'm running on an RPi3B+

[PeterO]

First thought, have you put the tty into raw mode ?

PeterO

[edwar64896]

"...put the tty into raw mode"...

Not sure what you mean by this.

I have a serial device which I am accessing using libserialport. There are two functions sp_read and sp_write which allow me to send and receive data over the chosen port.

what would putting the tty into raw mode do for me?

[PeterO]

"...put the tty into raw mode"...

Not sure what you mean by this.

I have a serial device which I am accessing using libserialport. There are two functions sp_read and sp_write which allow me to send and receive data over the chosen port.

what would putting the tty into raw mode do for me?

I have no idea what libserialport offers, so maybe check libserailport's documentation for any mention of "raw" ?

PeterO

[edwar64896]

Why would a serial port need to have a concept of "raw". I can understand why a terminal display might do, but why a serial port?

[edwar64896]

This is a quote from libserialport doc...

Code: Select all

 
 * The first is that Unix traditionally provides a wide range of functionality
 * for dealing with serial devices at the OS level; this is exposed through the
 * termios API and dates to the days when serial terminals were common. If your
 * code relies on many of these facilities you will need to adapt it, because
 * libserialport provides only a raw binary channel with no special handling.
 

[edwar64896]

OK update....

I have recompiled all the salient code for OSX and I am getting absolutely zero errors on the serial device in question, so there is something up with the RPi.

I suspect something to do with the kernel scheduling affecting the USB/Serial interface, or possibly the serial emulation driver?

Any suggestions?

[pfletch101]

Why would a serial port need to have a concept of "raw". I can understand why a terminal display might do, but why a serial port?

Digging back into the recesses of my memory regarding the days when I had to deal with minicomputers and serial terminals, and looking at the OP's original problems, I wonder if the source device is expecting the Pi's serial port to implement some form of flow control - either ^Q/^S, or using hardware handshaking between the port's control lines.

[Joel_Mckay]

We did a pre-configured Raspbian Stretch fork to solve several issues with machine interfacing:
https://sourceforge.net/projects/microm ... pberry-pi/

Specifically, some versions of Gnome's Wifi manager will probe for modems during Arduino programming etc.
You have to add some module setup tweaks to the USB-to-serial chip VIDs to tell it to not do that.

Also, the native UART on the pi is usually mapped to the bluetooth module, and the soft port replaced mapping on the i/o header was setup to be notoriously error prone at high baud rates when CPU frequency throttling is active.

Let me know if it helps =)
J