Adding channels to the Bayang protocol?

Aloha,

With the new open firmware available for various small quads, H8 mini, CG023, Floureon H101, etc., was wondering how hard it might be to add a channel or two to the Bayang protocol to expand these quads capabilities. Remote PID tuning is one current interest. (These boards transplant readily into other frames, so tuning is a recurring issue.)

Could the Bayang protocol accommodate another channel or two?

Thanks.

I may be wrong but
I think the firmware on the quads needs work for that not the transmitter.
So I think you should ask silverxxx (i'm assuming you're talking about his firmware) about this possibility
And yes that sounds very awesome
Keep us updated.
And if im wrong someone please correct me

Why specifically Bayang? If you have control over both ends - flight controller and TX you can introduce any protocol with any number of channels. Bayang is not that good - it uses only 4 radio frequencies for frequency hopping, it's not resilient enough.

victzh wrote: Why specifically Bayang? If you have control over both ends - flight controller and TX you can introduce any protocol with any number of channels. Bayang is not that good - it uses only 4 radio frequencies for frequency hopping, it's not resilient enough.

Thanks for the insight. Bayang (H8 mini) and EachineX4 (CG023) are the protocols he's used so far. He's also adapted the Floureon H101 (Bayang.) I think he just finished the CG023 and it can select either of those protocols. I've been using the H8 FC for a bit, mostly transplanted to a Bayangtoys X9, which flies very nicely, level and acro modes. Nice to learn acro on a cheap expendable quad. It's a nice controller. He just started working on the DHD D1 nano, I think.

The H8 has plenty of memory, 32K, twice what it currently needs. So it seems like a good choice for further expansion. Bad news is the manufacturer is switching processors on it.

Silverxxx is the maestro. He doesn't have a Deviated xmitter. Yet. It's just where he's gotten the necessary information to code his receiver protocols. He has put a few things into his code for those of us that do have Deviated xmitters.

I think he's somewhat aware of the awesomeness of controlling both ends. He seems to think Deviation is a bit more limited than it is though. That's why I'm here asking about expanding protocols.

Expanding Bayang would be a good start. Suggestions of better protocols might be helpful too. He's the maestro. I'm just collecting information and ideas.

Deviation model files give the impression you can increase the number of channels just by declaring a larger number. But I'm not sure the protocol code (or timing) doesn't impose limits of its own.

Thanks.

Timing can always be an issue. The protocol encoding is also an issue - if the channel numbers show up in the sent packets, then the channel numbers have to fit in a field. Both of those are inherent in the protocol, and not something that could be fixed with better Tx firmware.

Each of the protocols in Deviation has a limit on maximum number of channels. That's generally imposed by the protocol as above, or by how it was reverse engineered - we didn't have anything that used more channels to look at for the encoding, and also no reason to add them.

There's also a global limit of 12 transmitted channels. That looks like raising it is simply a matter of changing a single define in the source, but it really ought to be tested to make sure no one has done something that depends on it elsewhere.

No, your impression is unfortunately wrong. Every protocol is defined in particular by the packet format. Bayang's packet is full - no place to add another channel.

He is interested He's especially interested in adding telemetry to H8.

Hey guys silverxxx here.
Thanks for your replies, I would like to add telemetry at least.

I was thinking of keeping the h8 protocol (modified) mainly because the quad could autodetect the protocol. This would save some flash imo, on the other hand, simpler protocols like the cg023 save about 1K anyway.

Why is there a need for interrupts? I usually set the radio to rx after tx is finished, and poll 1ms before tx'ing again. I guess the devo might do things differently. Anyway, it can be done in whichever way.

What would be a good way/protocol? You guys have seen a lot of them.
I think it probably needs hopping, even if it would be simpler without it.
A tx sum or crc because sometimes they receive garbage

Also, can the devo send independent trims?

Trims - do you need them for PID tuning? Deviation has 12 channels to pass to the protocol code, all configurable so that you can edit values directly. So you use 4 channels for direct flight control, if you don't have any other controls - lights or whatever - you have 8 more channels you can use in the protocol as you wish. Even 12 is not the limit - it's a constant, so probably Deviation can be easily extended just by recompilation.

Silverxxx is used to a number of one-bit channels. It might help to spell out number of channels and their resolution limits.

I think an easy way to transfer telemetry data would be in payload bytes of auto-acknowledge packets. You don't have to worry about switching the aircraft nrf to tx mode at all. Configure AA mode and put the telemetry data in the AA payload buffer and it's automatically transferred the next time a packet is received from the tx. The transmitter picks it up by watching for acknowledge received and reading the data so it never has to be switched to rx mode. After processing the received packet from the tx the receiver puts new telemetry data in the AA buffer so it will be ready and waiting for the next packet exchange.

One downside is that telemetry would be dependent on receiving packets from the tx rather than the aircraft transmitting independently. And no protocols currently implement this so it would be new code.

Recommend leaving retransmits off on the tx - if an AA packet is missed just go on to the next packet.

Nice idea, we should try doing this. Is it my impression or telemetry code is really complicated? It should be very much like channels from the point of view of the protocols, shouldn't it? You take a value from channel, encode it pass in a packet, got telemetry value from a packet decode it, put in telemetry channel. You should not take care how it's displayed as you don't care where values come from in your channels. There is mixer for it, and there should be telemetry routing code not unlike mixer.

About the trims, I was thinking, the firmware has level+acro mode, acro mode needs no trims, because the gyro calibration ensures zero drift. But in level mode you need trims. With separate trims, I could apply them in level only. Right now I just discard them. ( they are dynamic trims)

But right now, if you trim in level mode on the main channels, it will drift in acro.

About AA, this is xn297 , I'm not sure about compatibility with AA on nrf24.

I'm not sure how to implement pid tuning. I guess sending the pids at bind? Or maybe a special packet could update them while flying?
There are 5 pid numbers. The question is, is it possible to enter numbers somewhere on the devo, and have them sent?

I think we should do telemetry first, and worry about pids later. And also, thanks for your offer to help. It's going to be different to code the receiver without the tx, but should be possible

You are right about AA, unfortunately.

It is definitely possible to edit numbers and send them as channels, not at the beginning, but all the time as regular channels.

Different trims for different flight modes - I'm not sure it's currently possible but it's nice idea.

Not sure about it, but as I checked the code last evening, I think I saw that only a few ( a few = 6) bits were used in the packet[2]and packet[3] bytes. I understand that could present compatibility problems, but perhaps those bits could be used to transfer some additional data ?

I really think that if you start modifying the protocol as you keep both ends of it - TX and RX - you better either use something more suitable or introduce your own reasonable protocol which you don't need to find bits for your data.

Concerning the trims: The are definately possible to make flight-mode dependant with Deviation.

Concerning the PID tuning: If it really would be possible to type in a PID number in Deviation and,send it to the quad, that would be by far the best way to tune PIDs!!

Concerning Telemetry: Would be very nice, I think the first nrf based protocol with telemetry?