Any interest in a serial protocol as well as PPM?

A thought occurred to me today: the RC world is moving away from PPM as a connection protocol, being replaced by S.Bus, SRXL, and others. Maybe we should follow suite? Is there any interest in having an option for using one of those instead of PPM as input on the trainer port?

I expect those of you using arduino's for extra inputs might like it. Especially if we use the serial protocol the multiprotocol module guys are using so there's already arduino code available. I also recall seeing questions about connecting head tracking or LRS or some such hardware that expected to use these kinds of things to the devo.

Jeti Duplex X-Bus please for FBL parameter real-time tuning within transmitter menues: www.deviationtx.com/forum/6-general-disc...-jeti-protocol#47496

So you're saying the ppm input would still be available while doing some sort of serial (hopefully S.BUS) output from somewhere else?

Yes please!

does sbus/sbus2 actually transmit in serial data packets? as i thought the sbus magic was done by the recievers? as in rx gets sent the usual data and then encodes to sbus and shunts it out to the servos? but the transmitter is still using/transmitting pwm?

S.BUS is not implementable well in pure software. It's serial with 100000 bit rate 8E2 BUT inverted! So you can't handle input with USART, and you better not handle 100000 interrupts per second. All hardware uses separate inverter before USART. I implemented it in PSOC 4 - Cypress combination of ARM with a small programmable logic - in this case you don't need an external inverter. Otherwise you need a hardware mod.

SRXL on the other hand is an easy 115200 8N1 fully documented format. As long as your trainer port IN connected to USART RX (not the case for some designs) everything is going to be straightforward. X-Bus B is in fact Multiplex SRXL, I don't know about duplex - is it standard, is it documented.

And answering HappyHarry's question - yes, S,BUS transmits all the channel data - 18 channels, 16 11-bit proportional and 2 binary - in the data packet of 25 bytes. It also can receive up to 31 "slots" of telemetry (S.BUS2). Every device connected to the S.BUS knows its number and picks its data from the packets. Packet is transmitted every 14ms (there is a mode transmitting every 7ms, I'm not sure how to turn it on).

Just a quick idea for what this could be useful for...

ULRS (ultimate LRS) can accept an SBUS input on the ground side (it can also accept PPM but for guys like me the PPM output is not available cause of ppm input). That would make it possible for me to have a direct, wired connection to the ULRS tx instead of having to use a 2.4 -> 433 repeater setup as I do now.

Cereal_Killer wrote: So you're saying the ppm input would still be available while doing some sort of serial (hopefully S.BUS) output from somewhere else?

Yes please!

Not really what I had in mind. The idea was to use the trainer port, as that's the known output pins. it would work like PPM: each serial protocol would show up as an output protocol. The could actually be done without otherwise changing the firmware. The "PPM In" spinner would change to either select a protocol and click it to set channel/stick/extend, or stay what it is now and select a protocol after you click it.

On Walker Tx's, the trainer tx and rx lines are shorted together by the plug, presumably so the stock firmware can detect when the plug is inserted and automatically switch modes. In that condition, you really can't do both input and output at the same time. Once you cut that short, you could do both. You might well be able to do two different protocols, assuming both protocols work properly without the other direction. Hasn't been much call for supporting that with just PPM, but with other options that might change.

Yes, I know about the S.Bus inverted problem. I also know that there's enough hardware that doesn't invert it that you can buy cables to fix the issue. Ideally, we'd support both, but if we can only support one I don't see it as a big deal, and don't see a reason to favor one over the other except that one's "official".

And to address HappyHarry's implied question: the data that deviationTx sends to the rf modules is closer to a serial protocol than PWM. This makes me suspect the RF data is also a serial protocol, but I'm not an RF engineer so can't say for sure. But in any case, the Rx has to translate those into whatever output signal it chooses - SRXL, S.Bus, PWM, CPPM, etc.

victzh wrote: And answering HappyHarry's question - yes, S,BUS transmits all the channel data - 18 channels, 16 11-bit proportional and 2 binary - in the data packet of 25 bytes. It also can receive up to 31 "slots" of telemetry (S.BUS2). Every device connected to the S.BUS knows its number and picks its data from the packets. Packet is transmitted every 14ms (there is a mode transmitting every 7ms, I'm not sure how to turn it on).

thanks for the info, I've been at uni the past few years so I'm not up to date with the recent goings on in the hobby. sounds like a great way of doing things!

thanks mwm, I was more thinking of the data between the rf front end and the rx still being pwm but as victch said above the futaba implimentation does in fact sent serial data to the rx