Electronic – UART devices: Baud rates different by a factor

baudrateuart

I have UART devices where I can chose various non-standard speeds, but none of them are matching. There are however some speeds, that are a multiple of the other device's speeds. For instance, I could have the rates 150'000 on the receiving end and and 3'000'000 on the sending device. Communication is only in one direction.

Do you think it is possible to hack something together to have the sending device send every bit multiple times and therefore emulate a slower baud rate? I think I would have to disable all options like start- and stop-bits and implement them manually in my fake protocol, so I can stretch these out as well.

Does anyone have experience with this? Could it possibly work? Or am I missing something?

EDIT: To clarify, I am not hiding anything, the numbers are correct: I actually want to talk to ESCs on a drone that expect either 150'000, 300'000 or 600'000 bits/s (DSHOT protocol). The board/micro controller I want to use to control the ESCs does not support these rates, but it would offer a custom baud rate of 3'000'000 bits/s (= 5 x 600'000). It offers others as well, but none match any DSHOT baudrate nor are they a nice multiple. So simply put, the idea is to send every bit 5 times and thus have the faster rate appear 5x slower. Does that make sense? Hence I would have to implement features like start- and stop-bit myself and have them sent 5x instead of once for example.

Best Answer

Serial data is just a series of 1's and 0's on the wire so it is possible to synthetically make one data stream out of the bits of another by mimicking bit patterns...

https://wp.josh.com/2014/09/03/inside-neouart-tricking-a-serial-port-into-being-a-signal-generator/

But it is usually not as simple as just doubling the sender's baud rate and sending each data bit twice because there usually other bits in the stream besides the data bits like the start, stop, and parity bits.

enter image description here

It is often possible to work around these limitations, but the strategies are specific to your sending hardware (can you change the bits? the framing? the parity? on the fly?) and you application (can you live with not being able to send some data values and instead changing them to nearby values that fit into the allowed patterns?).

If you give more info on your hardware and protocol we can better help brainstorm ideas to get there!