Adding channels to the Bayang protocol?

Sounds very cool to me. Thumbs up!

So, I guess we go for a new one.

So far we have 4 analog main channels + 5 (minimum 3) pid channels (8bit) + digital switches - whatever is left

Channel hopping - I guess we should include it

telemetry should be same packet format, just different header, that should be easy to figure out

So, we need to come up with the rest of it. I have seen posted the H8 protocol is nothing special, is there any cool stuff that we could add to this one?

Is there really a need for more then 4 channels?

Yes, 2-3 bytes for TX id, 2 bytes per channel 12 channels. CRC is provided by packet structure, it's OK to use only this.

For quadcopter there is probably no need for more than 4 channels, but usually it pays to design a bit ahead - you never know where this design is going to be used in 10 years

So, 3(tx id) + 1(packet type) + 24 = 28 packet length. I don't know, for some reason nobody uses packets this long. May be error free transmission probability for such a long packet is not very high.

I like what S-FHSS is doing - they have packet subtypes - even packets transmit first 4 channels, odd - next 4; and there is space for extension - you can always add packets 3 and 4 - there is space for it.
They also pack the values peculiarly, we can avoid this. With minimal packing (12-bit values) and 4:4:4 channels schema packet length would be 3+1+6 = 10 bytes. With 6:6 - 3+1+9=13.

I also like how HiSky handles FH sequence - it passes it along the TX id explicitly, no formula in RX to use, just write it down.

Yes, actually, it might be a good idea to reduce the packet lenght. The software spi takes a while, and 28 bytes is looong
Also , the pids are not very dynamic, and there is no point sending them full rate. maybe send them 1 in 10 or so. Would have to be a number not a multiple of the rf channels, so it does not end up on a dead channel all the time. Also , i'd like throttle duplicated between packets for failsafe purposes if its convenient. Or maybe a bit could be set if throttle is under 10%.

Well, you guys write the tx, and i'll see if I can make an rx that works for it... Or you could do both if you feel like it.

Also, I found some xn297 registers that work for the higher channels on the radio side.

I'd say most modern quads want five channels - four flight control + 1 "FC Mode" channel. Sure, you can cram the last state into bits in the other four, but you then have to turn those into channels to in the mixer in order to use them, so why bother? And many will want up to three more full-resolution channels for controlling a gimbal, though only the devo12 can really take advantage of that.

We've talked about custom NRF-based protocols before. I think the end result was using the channel area to control channel size. Say half the channels are full size, 1/4th of whats left are 4 bits, 1/4th are 2 bits, and 1/2 is one bits (most common option).

FWIW, the CFLIE and YD717 protocols have telemetry in the source, but it's not enabled in the nightly build for some reason.

So what's the maximum data payload available without sacrificing speed/latency?

And is it possible to make the unused channels configurable (enable/disable) at the model file?

ok i'll look at yd717 and CFLY.

I actually was thinking 4 rf channels, sorry, I was ambiguous.

Theoretical limit is pretty high. 5ms per packet means every packet should not be longer than 1Mbps x 5e-3s = 5000 bits. With overhead you realistically will have 2000 bits every 5ms. Each channel is no more than 12 bits. So you can have around 167 channels before there will be physically no place to put them. So, you can have 83 control channels and 62 16-bit telemetry channels. If your speed is 250kbit/s, divide by 4.

I have a tiny 12 channel DSMX receiver on a CJMCU, of which 7 channels are used. Are the other channels taking up bandwidth? Does it matter?


(Orange R111xn satellite, with Devo 7e.)

No.

As we just saw, the concept of "channel" is overloaded here. While there are RF channels, in the context of RC transmitters it's really used to count the number of remote devices that can be controlled. Possibly they used to be the same (I re-entered RC stuff after digital became common, and didn't get into the technical stuff earlier), but they aren't any more.

In most (all to date?) rc protocols, all channels values are sent every frame, in "channel number" order. So you get channel 1, followed by channel 2, etc. Robotics and wired protocols use a "command" structure. Instead of sending a specific set of values, you either send a device selector and a value for it, or you have a command structure where the command implies the device(s) to control. Since some of these protocols use words on a unicode line as the protocol, the number of devices you can control is essentially unlimited.

I've been thinking that for a modern RC system, some kind of hybrid approach would be nice. Since flight controls and the like might be changing nearly continuously, send those channels in the traditional RC format in every frame. Maybe negotiate the number at bind time. Then follow them with 0 or more commands in that frame. That would allow you to have hundreds or even thousands of devices - or "channels" - without having to worry about the frame length.

The downside is that RC protocols aren't 100% reliable. That needs to be dealt with. The protocol needs to include some form of ACK and a behavior to make sure commands get through in spite of dropped frames, and that either missed or repeated commands don't cause problems.

Good stuff, mwm.

Sending only data that has changed might be helpful. Could add to reliability.

Error correction might be possible. Though, that would add complexity.

Could take the simpler route to get something flying and add accoutrements later. Perhaps stub out for enhancements in the key areas. Get the basic structure tested, then go from there. Add better error correction, etc., later.

Love the extensibility idea. Especially if you could control it from the model file. That would really take advantage of Deviation's abilities.

That's what Frsky does. The D protocols send 8 or 16 channel values every frame and also have a byte stream to transfer data packets. The rx->tx telemetry packets have RSSI and AD1 (and AD2 for D8) in "channels". The s.port and hub telemetry is returned in the byte stream. I posit at least the D16 protocol also has a forward (tx to rx) byte stream in packet bytes 22-27 because it's required for these to be possible.

The byte stream is nice for telemetry because of the number of sensors and values to be communicated. As victzh pointed out there are plenty of individual bits available for just turning things on and off (without the delay of byte stream decoding). As mwm noted communication errors in the rf link will affect the byte stream data more severely than the channels sent every frame.

IMHO the protocol needs to fit the application. Plenty of room for plain old "channels" to support PID tuning and gimbal control and on/off bits. Will the H8 be sending back such a variety of telemetry that a streaming protocol is needed?

since the 32k processors have been replaced with 16k ones in the latest H8 board iteration, I will have to limit the complexity in order to save flash. So it's only going to be battery and rx rate, basically only a few bytes.

It's hard to believe so little protocols use telemetry, with the 2.4 transceiver chips in use now it's only a matter of implementing the software. Even the cheap toy tx's that have a buzzer would only need a software change to make it beep on battery low.

Be nice to find another cheap quad with more than 16K flash.

Some of the potential of re-flashed toy quads fades without it.

What about sending configuration data during bind? Like PIDs, etc. Put them into the model file and they get sent on each bind. Anything that begins with the magic string gets sent ...
Receiver looks for 'PID' in it's list of items and assigns the given values at each bind. Same FC board and firmware works in various frames with minor changes to the model file. No more reprogramming and reflashing for each aircraft. Possibly saving data in flash ...

It would maybe be a way to confirm what PID numbers are in the FC, if they could be sent back by telemetry and displayed on the Devo screen. Just a thought.