The serial data is buffered, and sent as fast as possible. If the data is not being handled as fast as possible on the other end, you have no choice but to apply that ugly band-aid on the Arduino end.
Thanks for the reply!
When connecting the receiving controller to a FUTABA receiver (instead to my arduino), it decodes the data OK, so I doubt the problem is at the receiving controller...
endrew:
Thanks for the reply!
When connecting the receiving controller to a FUTABA receiver (instead to my arduino), it decodes the data OK, so I doubt the problem is at the receiving controller...
It isn't clear what you are changing.
Are you changing the device that is receiving that data?
bperrybap:
It isn't clear what you are changing.
Are you changing the device that is receiving that data?
I have programmed an arduino to replace a FUTABA receiver. The Futaba receiver sends serial data (SBUS) to a pixhawk. The pixhawk reads the data from the futaba reciever OK, but it reads the data from the arduino only when I add delays...
Is this explanation clearer?
Thanks!
CtrlAltElite:
What happens when you reduce the delay to, say, 100 microseconds?
endrew:
I have programmed an arduino to replace a FUTABA receiver. The Futaba receiver sends serial data (SBUS) to a pixhawk. The pixhawk reads the data from the futaba reciever OK, but it reads the data from the arduino only when I add delays...
Is this explanation clearer?
Yes much.
It is starting to sound like it is possible that FUTABA transmits the data slower than the Arduino and the pixhawk can't keep up when the Arduino is transmitting.
It could also be that there is a potential slight baud rate mismatch and the bit framing slips after some number of characters to the point where the data is no longer properly framed.
A slight delay between characters would prevent that from happening as it is essentially adding extra stop bits.
I'm with CtrlAltElite, but I'd use a logic analyzer to see a long stretch of the actual signal timing.
That will show everything.
The SBUS uses 25 bytes with 100k baudrate and 8E2. That burst of data is transmitted every 7ms or every 14ms.
The Arduino uses the most common 8N1. There will be a parity fail and the stopbit problem.
The stopbit can be seen as a pause between the bytes, a little idle time. That's why it is accepted when you create more idle time between the bytes with a delay.
The SBUS uses 25 bytes with 100k baudrate and 8E2. That burst of data is transmitted every 7ms or every 14ms.
The Arduino uses the most common 8N1. There will be a parity fail and the stopbit problem.
The stopbit can be seen as a pause between the bytes, a little idle time. That's why it is accepted when you create more idle time between the bytes with a delay.