Having worked with a lot of instrumentation and control stuff, I really, really like RS-232. It just works. I made the mistake on one project to go all USB, and it was a complete nightmare. Basically, anything you can think of went wrong, from USB controllers maxing out on number of devices (despite the number of devices being a mere fraction of the allowed devices in the USB spec), devices causing other devices not to work if on the same hub, devices disconnecting, etc. I couldn't even get manufacturers to tell me how many USB devices their USB controller supported. I often had to use tools like USB Device Tree Viewer (https://www.uwe-sieber.de/usbtreeview_e.html) to understand what was going on. There was another USB debug tool that I used that I've forgotten the name of (maybe USBDeview). And if USB devices disconnect, the only way to guarantee getting back to them is to restart the OS process, which makes your software very fragile. Same thing with cameras with USB vs something like Camera Link. A camera's USB driver crashing would make you restart your entire program, making it very hard to build systems. Camera Link, another serial protocol, also just works.

RS-232 and RS-485 are just so reliable. The higher voltage of +/-12V makes it more resilient to noise, and the protocols are just simple. It isn't the fastest around, but it can still be pretty fast depending on how the protocols are implemented.

> I really, really like RS-232. It just works.

Well... as long as everyone has their configuration correctly hand-configured. As the video states, RS-232 doesn't have any way to transmit a clock. So if one end is talking 9600 baud and another wants to talk at, say, 56000 baud, then... no it doesn't just work.

With a buffer, it's probably pretty easy to guess the baud rate. Similar to encoding guessers for strings or the CSV.sniffer in Python standard library.

https://github.com/chardet/chardet

https://docs.python.org/3/library/csv.html#csv.Sniffer