Multiple active RF modules?

The Taranis does 32 channels by having two active RF modules. This makes me wonder if we could do the same thing. I actually have an immediate use for this, but I'm still not up to flying after the knee replacement, so thought I might get some feedback from people who know more about the protocol development than I do.

In looking over the stuff in protocol/spi, it looks like we leave the chips disable most of the time, enabling them on a per-interaction basis, then disabling them when that's done. This is a good start, as we could theoretically talk to more than one chip at a time. It doesn't mean it will work. I can see an number of possible issues.

IIUC, rf module code mostly at least partly out of ISRs. If so, then running multiple RF modules means we have to worry about making sure that we don't try and switch modules when one is already enabled. Also, that we don't lose interrupts when we're talking to one.

Which raises the second issue: can we process things fast enough to do this? If so, how many modules can we use at once?

I can see how the UI would work: just another option on model setup, that selects a second protocol from "None" and the set of protocols that don't need the rf module used by the first protocol. Number of channels for it is an extra protocol option. Or maybe number of channels just becomes a protocol option, though that seems inconvenient for most models.

If this works, the next interesting question is having multiple modules of the same type. For instance, adding a CYRF chip to a current multimodule installation. If we can work out the UI issues, I don't see why not. After that, the question becomes how many we can have active at once.

Wow. What do you need 32 channels for?

Sounds like a good time to re-evaluate or redefine what a channel is. Perhaps an open source receiver to go with our open source transmitters. And a little data compression or data scheduling. I think we discussed this recently.

The dual module approach would probably go together much faster, though. A mostly hardware solution.

Modules should probably be multiplexed in hardware, so it isn't possible to select two at once.

Hi Mike,

great idea.

If you think in that direction, maybe you can even get ANTENNA DIVERSITY up and running on DSMx like DX18, DX9, DX8G2?
But that would probably mean to get rid of the 1st antenna mount and have it layouted top like Spektrum has.
Where and how to put the 2nd antenna?


This is my 9-12 channels thread poll (to get some ideas): www.deviationtx.com/forum/6-general-disc...s-servos-gyros#43598


X-Plus:
Somewhere I read informations about Spektrum X-Plus 8 that there was already some code but not merged into nightly-build and not that much tested??? Need to find threads or links...
Maybe we could get this XPlus8 running (if any developer has X-Plus module) first before thinking about the hard work to get two HF modules running? Or might that be not that hard?
That is the hard part with DeviationTX. A developer even needs to own the more expensive hardware to fully test it...

I am also not too sure if one pilot would even use a modded DEVO transmitter (lack of declaration of conformity >10mw, missing DSMx/FrSkyX conformity, etc.) to fly something a plane that big that requires all that channels??

Thomas

Don't think processor time is an issue, though it'd be interesting to do some measurements. What is the cpu clock frequency anyway? The Devo10 CPU is rated up to 72MHz at 1.25 DMIPS/MHz. Back of the napkin estimate says we're sitting idle most of the time even at half that speed. Could probably do more protocols than modules.

From a slightly different angle, would it be worthwhile to be able to control multiple receivers with a single protocol? You'd have multiple fixed id's in the model. At least the nRF device allows changing the tx address and channel at any time - are the other radios similar? Some other internal state data might need to be maintained for each receiver. Though using multiple modules would probably involve less (or no) work inside the protocols.

FDR wrote: One advantage would be that I could use two cheap 6ch RXs instead of one quite expensive 12ch...

For those interested, this was raised by myself and by mwm over two years ago; sounded like it's theoretically possible but didn't have enough justification to pursue

The real point is not more than 12 (or whatever) channels, it's multiple receivers. In particular, if you want to control a high-end RTF quad (my example is the blade 350Qx) and some kind of payload along the way (i.e. - a camera and gimbal). Blade actually recommends using a second Rx for this. It's actually possible to use two DSM Rx's this way, or a satellite Rx as the second controller. I've never heard of this kind of thing being done with any other protocol, and it has the obvious drawback that the channel numbers don't get mapped before sending to one of the Rx's, so at least one must handle all the channels.

However, there's a bug in the deviation implementation of the DSM protocols that cause some of the Spektrum all-in-one boards to go bonkers if you use more than 7 channels in deviation, and the 350Qx is one of those. So I can't use 12 channels. This is why I want this.

As for the collisions - how bad would that be? First, if we're actually sitting idle most of the time, then they should be extremely rare. And when they do happen - the requirements are soft real time. We already survive dropped packets, this would just add a few more. If telemetry is an issue, that can be turned off on most protocols. Of course, those are also exactly the conditions when you want RSSI information, though we don't currently provide Tx-side RSSI, and AFAIK only FrSky supports it.

FDR wrote:

mwm wrote: However, there's a bug in the deviation implementation of the DSM protocols that cause some of the Spektrum all-in-one boards to go bonkers if you use more than 7 channels in deviation, and the 350Qx is one of those. So I can't use 12 channels. This is why I want this.

Then shouldn't we just need to implement those DSM modes?
If we don't want to implement the reportback of the rx at the binding stage, we can use protocol options for that...

Ok, I'm completely confused - but I haven't really been following the DSM protocol implementation. I'm not sure what the reportback feature is, so don't know if that would fix the problem. I had assumed that the cause of the problem was unknown and nobody had looked at it. After all, there's a trivial workaround that can be used in all but a very few rare cases - like the one I ran into. If the fix is known, the only reason I can think of for not fixing it is that it runs the 7E build out of ram or rom, which might not be helped by making it a protocol option.

Last time I looked - and it has been a while - our DSM implementations worked fine for all the standalone Rx's running spektrum-licensed code, whether you had more than 8 channels or not. Ditto for the OrangeRx & LemonRx re-implementations. It even worked properly some (many? most?) of the AIO boards used on Horizon Hobby products.