Devo-10: 12 Channel Barrier

Is there anyway Deviation can create more than 12 channels for the Devo-10 or is it limited by the hardware? I'm using SBUS to a PixHawk and have run out. Now it's time to make hard choices.

How many channels could you get max on a CC2500 on FrSkyX protocol?

The internal CYRF module probably is max 12CH??

there's code available on here for 16ch dsm so I don't think it's a devo issue, more a protocol frame length issue

After posting this question I found THIS .

10.6. Protocol: DSMX

The DSMX protocol is used to control many Spektrum™ and JR™, as well as other models using this protocol. While the DSMX protocol can support up to 14 channels, Deviation is currently limited to a maximum of 12.

I guess this is called Spektrum XPlus: www.deviationtx.com/forum/protocol-devel...annels-for-dsm2-dsmx

Frsky X has 16 channels and also Flysky AHHDS 2A, 14channels, so yes there are protocol with more than 12 channels.
I also thought that somehow deviation was limited to 12, so is that true?

current builds are limited to 12, but that's a programming limitation not a hardware one, if you read the thread linked by thomas you will be able to find the required code changes

As far as I can tell it's a matter of one define - you can set as many channels as your MCU can bear (probably Devo 7E is the limiting factor).

See deviation/src/target/devo10/target_defs.h NUM_OUT_CHANNELS. It is set to 12 now, it should be just a matter of changing it.

There are two other possible issues beyond just changing the #define in deviationTx. First is that there may be a bug in deviationTx that such a change uncovers (well, I'd say it's a bug, but given that it works now, maybe not). Second is that the protocol supports the extra channels in the same format as the earlier ones. Some protocols tweak the formats as you get to higher-numbered protocols.

Which actually brings up a third issue. The protocol code may need to be changed to copy values for the extra channels into the outgoing packets.

If someone is interested in actually testing such, I'd be happy to provide a build for a Tx with a specific protocol tweaked.

@mwm,
I'd be happy to test such a build.

mwm wrote: Which actually brings up a third issue. The protocol code may need to be changed to copy values for the extra channels into the outgoing packets.

I think for FrskyX you'd just need to change the value returned by the PROTOCMD_NUMCHAN case. Probably should be 16 anyway, but never checked if values greater than NUM_OUT_CHANNELS would cause problems.

lasakro wrote: @mwm,
I'd be happy to test such a build.

What transmitter and what protocol? I don't have anything an Rx to test with, I'm just offering to build one for someone who can but can't do the build.

Sorry about that. I thought we received instant email notifications when we subscribe to a thread here but I guess I can't find where to turn it on.

Devo 10, DSMX please sir. Thanks.

I'll check back more frequently, I promise.

Ok, I've tried to attach it, but that doesn't always work. If not, I'll do something else.

This is a Devo10 build based on the 5.0 release. If you're running that, you can just install the dfu. If not, use the 5.0 release file system with this. Nightly build file systems might work, but I'd rather not introduce extra variables. Which is also why I used 5.0 release.

I've bumped the overall max channels to 16, because that's where we are heading. However, the DSMX code only had obvious places for 2 extra channels, so you get 14 channels for it. This was done blind, so I had to guess about where they would go, and Spektrum may have taken things in a completely different direction, so don't be surprised if it doesn't work at all.

After making sure your original 12 channels still work, try them both at once. I may have cross-connected them.

And I did learn something: there's more that has to change than just the NUM_OUT_CHANNELS define for the Tx. The datalog stuff has to change a bit as well. PBR set things up so that changing the datalog format breaks the build, so the version number gets updated.

Great, thanks.

1) I was running 5.0
2) Installed dfu from above.
3) Now in Mixer only channels 1 and 2 configured. 3-12 are all set to none.
4) Reloaded current model file, no change.
5) Loaded different file, no change. Not reading model files.
6) Configured manually in mixer ch's 3 and 4 as Thr & Rud.
7) Configured manually in mixer ch's 5-14 all Simple and Src=Aux4.
Eight) All 14 channels on Devo 10 Mixer Page, as a group, responded as programmed. Didn't check 1 for 1.
9) In Mission Planner ch's 1-8 responded as programmed.
10) Scope on ch's 9-14: 9-11 responded as programmed, 12-14 were dead (Flat line, no PWM).

Let me know when you have another one to try.

Please ignore everything above about not reading model files and setting their mixers to none. I had made a change adding what I thought would be a comment line [comment] under the [channelXX] line and that didn't go as anticipated. I'm going to try [channel10_camera_select] instead. Doesn't seem to like spaces i that field.

Post on another thread prompted me to revisit this for FrskyX. Test builds here (19a6cca) .

I haven't updated the datalog code yet so please don't use that feature. Tested with t8sg and XSR receiver SBUS output. All 16 channels worked fine. Channel monitor screen worked as expected. Haven't tested other features.

thanks for the link hexfet and that's for the details! i really appreciate all the help. i'm new and i might be having questions, do you mind if i would ask you them? thanks!

This site is the place to ask questions. Someone generally answers Start a new topic if you're changing subject.

Test builds are updated (3880781). Updated the datalog version, and the conversion utility to support 16 channels. Tested the datalog with 16 channels. Recording and conversion both worked fine.

Test builds are updated (3026970). Protocol Flysky AFHDS protocol max channel limit increased to 14. I don't have a way to test this change.