@Dr John,Yep a changing baudrate communication would certainly be slower than a fixed speed, but calculating the values take micro-seconds, no FP math involved.

I did the test with 2 Arduinos - UNO + DUemillanove - so one with a crystal and one with resonator (?) and used for both SW serial (you could have seen this in the code

I did not try a HW serial against the SW serial yet although I did test it with a (19200) HW serial LCD - see earlier post.

This analysis is not final yet as I expect the formulas can be improved a bit for the higher speeds. This can be done by non-linear polynomes at the cost of extra footprint or maybe by slighty tuning the constants in the formulas. Need some time to test (a lot more)

Tweaked the numbers in the spreadsheet to minimize the cumulative relative error. There was a large relative error in the higher baud rates, now the relative error is minimized, while keeping the functions linear

The first fail with new parameters lies about 20 K higher, but other runs started to fail at ~79/80K .

Conclusion for now:The new offsets are definitely better than the previous, but still not good enough to get a fail free software serial up to 115200.TODO: test @8Mhz and @20Mhz (don't have such duinos)

Next test - longer string "the quick brown fox jumps over the lazy dog" (42 chars) sent from A-> B at different speeds starting at 100 baud step size 100.B sends back the number of chars correctly received from start of the string. so when receiving "theXquick brown fox jumps over the lazy dog" the answer would be 3.

Again we see baud rates up to 70K perform 100%, above failing starts...

Would it be possible to write a code that auto calibrates the "magic numbers".

I would imagine using two serial communication links. One link could be the hardware serial port that would send to the slave the baud rate to be tested. Next, at the determined baud rate, the master would send a byte or string that is predetermined. The slave would then adjust the timing variables (within an allowed range) until the string is captured successfully "x" number of times. Lastly, the slave would perhaps save the variable results to EPROM or send to the serial monitor.

Would it be possible to write a code that auto calibrates the "magic numbers".

Definitely, but because the tables existed It was easier to let Excel find them.

In fact you can derive the magic numbers from the protocol. You know that the a data bit has 1/baudrate seconds between the edges. As you can see how much time the machine code takes to read and store a bit you can derive the magic numbers even quite exact for a given baud rate.

The real problem is that you need to find a protocol that works for all given baud rates, so an auto calibrating mode needs a number of known patterns to learn. Best to start with the highest baud rate as this is the most critical one. If you have the basic formula rxbit = CLOCKSPEED/(alpha * baudrate) - beta; you can try all possible combinations for alpha and beta between 1..20 so after 400 bytes you get the ranges for alpha and beta that work. You try the next baud rate and the ranges will decrease until all baudrates done. Then take the middle of the ranges and you're done.

A better faster approach is first find the optimal alpha, the search the optimal beta then alpha again then beta again until same values appear. That will bring you to the optimal value within 50 or so bytes (~10x faster).

Instead of linear search through the ranges you can do a binary search,...

For me the strange thing is the value SEVEN where I expected EIGHT in the formula - 16000000L/(7 * baudrate) - 3; but I did not really investigate 16000000L/(8 * baudrate) + BETA ... => todo list

Hey Rob, I just wanted to say thank you for your research on this. As it turns out I have a need for SoftwareSerial to do 7800 baud to read from a motorcycle ECU->Dash communication link and it sounds like you've solved my problem.

I haven't even begun to think/worry about that yet. Hopefully it just works. Ha!

In all seriousness, I'm literally waiting for FedEx to deliver my 'scope (hopefully Friday) so I'll have a better idea then for what I'm dealing with. I do know that at 9600 baud it seems to kinda-sorta work, but I do seem to be getting some corruption, but that mostly seems to be due to the timing differences from what I can tell/guess. So it appears the line is pretty clean.

That being said, I haven't tried it with the bike actually running yet, so things could get a whole lot noisier once those coils start firing.