Serial Data (`/dev/ttyACMx`) works unreliably on ResinOS - No problems on Raspbian host

Product support
, ,
1

Our setup can be described as follows:

  • Two measurement devices are connected to a Raspberry 3 via USB Serial connection
  • Serial devices run at 1000000 baud
  • A NodeJS based application is able to read out serial data from the two measurement devices
  • The serial devices are correctly recognised within the application as /dev/ttyACM2 and /dev/ttyACM3

This setup works reliably in the following situations:

  • NodeJS code deployed on Barebone Pi (Raspbian Image)
  • NodeJS deployed using Docker Image (based on Resin docker templates) on Raspbian OS (installed docker)

However, when I try to deploy the application (and hence the image) using a ResinOS on the pi and upload it through Resin.IO it starts working very unreliably. Serial data comes in mixed up, causing the app to be unable to parse incoming data and ultimately no serial data input anymore…

I’m unable to find the root cause of this issue. As the docker image on a Raspbian host device works like a charm, and the physical setup was left unchanged (only switched SD cards) this might be an issue on the underlying ResinOS.

Hopefully someone on this forum can lead me the way how to get this to work reliably on Resin.

Thanks!

5

Could you confirm what version of ResinOS you’re using, we’ve got some notes in our knowledge base that might help with certain versions.

7

Hi,

Using Resin OS 2.0.8+rev1 (dev)

8

Hi, is this a .dev or a .prod image? If it is a .dev, could you use the serial console to login on the host OS and try to check some things? Like look in the kernel ring buffer (dmesg) for eventual errors?

9

Hi,

After some more testing with ResinOS and Rasbian images, we were able to find the root cause of why our application stopped reporting serial events.

At some point the serial device is re-initialised by the OS and the baud is reset to the default baud rate. This was not detected by our application.

Our current solution is to force update the baud and flow control settings after opening the port and when we detect no input for a certain amount of time.

Currently this seems to fix our issues.