Do you like my hacking? If so, please consider leaving something in the
Fediverse (Mastodon etc): @Sprite_tm@social. spritesmods.com
Lets take a look at yer olde average TTL-level-using serial port, as that's what the ones at debugging connectors and microcontrollers usually are. The Tx-line of these are high when idle. When a byte is sent, the signal will go low for one bit-time (the startbit) and then will go low or high according to the bits in the byte being sent, every bit taking again one bit-time. Finally, the level will go high again for at least one bit-time (the stopbit).
Now, how are we going to detect the baudrate out of that? Usually, autobaud-routines will ask the user to type a certain character, like a capital U, which has the nice property of having 5 low-periods which are all exactly one bit-time long: measure these lengths and figuring out the baudrate (which is 1/bittime) is a piece of cake. It does depend a lot on that very first character that's sent, though: if that is, for example, a space, the first low level on the line lasts not one but 6 bit-times, which would mean the estimation of the bitrate would be off by a factor of 6.
To solve this problem, I decided on making my autobaud-routine a bit more extensive: The code measures not just the first length of time the signal is low, but a number of them. After that's done, the measurements get sorted lowest to highest. The probability of the lowest measurement equalling one bit-time is high, so we use that as a rough number to figure out how many bit-times the rest of the measurements are. As soon as we're done with that, we can output quite a good estimate of the real bit-time by averaging the measurements divided by the amount of bits they encompass.
After figuring out the baudrate, in theory it would still be necessary to figure out details like the amount of stop-bits, the parity (if any), how many databits there are, etc. In practice, this nowadays doesn't really matter that much: the first guess of 8 data bits, no parity and 1 stopbit will be correct 90% of the time. That's why I decided not to auto-detect these parameters; assuming them to be 8n1 will, in practice, work just fine