1

I'm in a situation where we are hooking up to a device that may speak a variety of different baud rates depending on model. Some of which may be non-standard, like 10000, but that's another problem for another day.

Ideally I could use Qt to auto detect the baud rate, but from my research that's likely not possible for a few reasons, which I'm okay with. However, is there any native Linux based method to auto detect the baud rate of the connected device? Even a 3rd party open source application could suffice.

While-E
  • 1,527
  • 2
  • 20
  • 37
  • Try to iterate over all posibilities sending some ping packet and see at which baudrate you can read it back from device. – Jeka May 30 '18 at 14:16
  • 1
    This was my fallback solution. Unfortunately there's some limit of missed coms before the device assumes there's nothing there and stop trying. Regardless, I will likely have to go down this route. – While-E May 30 '18 at 15:01
  • How the device is connected? for serial device I think [this is related](https://serverfault.com/questions/30516/how-to-determine-the-baud-rate-of-a-serial-port?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa) – Mohammad Kanan May 30 '18 at 19:27

1 Answers1

2

Linux serial drivers don't support autobauding, because most hardware doesn't support it, because there's no agreement on how it might work. It's highly application-specific.

If you're using FTDI serial adapters, then most of them support the bit-bang mode, and you should use them as a digital oscilloscope in such a mode to get a bitstream that's very easy to autobaud on.

On other devices, the simplest way towards autobauding is to set the device to 2-3x the highest baudrate you expect, then treat the input data like a chunked digital oscilloscope, taking account of error bits, and use heuristics to detect the baud rate. It will succeed in a surprising number of cases, but you must get the statistical model of the data source right. I don't know of any pre-canned solutions for that.

Some additional kernel support could be had to better timestamp the input from the UART (whether hardware or USB) and thus decrease the uncertainity in your data and thus the number of samples you need to take to detect baud.

Some of which may be non-standard, like 10000, but that's another problem for another day.

No biggie. I figured it out 16 years ago :) This is the answer you're looking for. If you think that the API is sick as in very, very sick, then you'd be right.

Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313