SoftwareSerial how to set parity and stop bits?

[hmeijdam]

I was reading about the improvements in SoftwareSerial here #26

I understand that it can support any baudrate now, which is what I need.
I am working on generating a (Futaba) SBUS signal, which is 100000 baud, 8 bits, even parity, 2 stop bits and it's inverted.

I can use the hardware serial by using Serial.begin(100000, SERIAL_8E2); but then I need to invert the signal with a transistor.

Software Serial can do the inversion via the creation of this object: SoftwareSerial mySerial(10, 11, 1); // RX, TX, 1 = inverted and then use mySerial.begin(100000);

But then it is 8N1 inverted instead of the rare 8E2 inverted that i need.

Any ideas how I could get the best of both? An inverted 8E2 at 100000 baud with SoftwareSerial?

[jg1uaa]

Sorry for late reply.
I am not clear about Futaba's S.BUS protocol but I think your project needs simply sending data to servo and no need to receive data.

I think adding SoftwareSerial::write() to these modification

• calculate parity
• send parity bit after sent all data bits
• twice last stop bit delay (simply call tunedDelay() two times)

but I am worrying about adding parity bit processing itself makes extra delay.
The value of _tx_delay needs to re-calculate in the worst case.

[hmeijdam]

Thanks for responding to my question. Yes, I need to send 6 RC channels via the Futaba S.BUS protocol to a trainer port of my RC Transmitter. It's part of my Corona project for our RC Model flying club. I am a flight instructor and need to have a wireless connection between the student-transmitter and the teacher transmitter, so that we can keep a safe distance from each other, while doing flight training.
I can envision that only when a second parameter SERIAL_8E2 is present when calling mySerial.begin(100000, SERIAL_8E2) the parity bit processing needs to happen. But I think I see your point that the process of calculation, may be too time consuming and may destroy the baud rate, making it more challenging to achieve.

The Futaba S.Bus protocol looks like it has been designed to be as difficult as it gets, to make it hard for others to use it. It's 10-bit values in 8-bit characters, so there is an overflow of 2 bits to the next character, 4-bits to the one after that..etc.. and then the crazy baudrate, parity and stop bits. O...yes and let's invert it too.