Extra inputs for Devo Tx's

Been reading up on PWM decoding and such. This should work.
In the mean time I'm making up some sound files. Used this online utility . Made a few funny ones.
Also updated my current sketch a few posts above. Figured out switch beeps and pot center beeps, decided I didn't actually like the latter though.
I've got a new set of pots coming. They're smaller which will open back up one of my previous shoulder switch positions. I'll have 8 remaining pins on the Nano and can have 4 free channels in the PPM stream. No idea what I'll use it all for, but I wants it!
Also trying to rough out code for my inbound 128x32 OLED display. I made a little poly carbonate case for it. I'll mount it on the bottom edge of my FPV monitor. I'm going to use the monitor's unused battery bay to house a 3.3v regulator & the i2c .wav board. Also got a tiny set of powered speakers I'll mount up. Frankenstein!

So last week I realized something this arduino method made possible and I have an initial test rig setup (I also have a logic analyzer ordered from Banggood)...

I am using the arduino to decode serial RX data (from a spektrum satellite) and combine that with it's own PPM data (from the 2 POT's I use [all I needed]). What's the goal I'm trying to achieve you ask?
...

Wait for it...
Wireless trainer PLUS the added on channels!


The way it works is this-
arduino hooks to main (instructor) devo just as with this expansion mod (the same arduino already used for the channel expander, not a second)
satellite receiver hooks to arduino (this part was easy as Multiwii already had all the code I needed)
second [student] transmitter (can be devo or ANY spektrum TX) binds to devo's internal sat RX
arduino decodes serial RX data, combines with PPM and sends it out*
Devo see's it all as standard PPM-SUM input and can use it however you program it to


*So far It's only working as a serial RX passthrew [wireless trainer] (I've not yet managed to combine the analog input's AND the serial RX's PPM stream YET (but I fully expect it to work, just as soon as I can get a visual on it all with the logic analyzer).


More to come...


edit: It would probably be easier to use a standard PPM RX for this but as everyone's already pointed out, there is very little room in the 7E and the orange sat is TINY. Yes the arduino would definitely be working less with a standard PPM RX but I'm no where near it's limits (serial RX decode passthrew / output on D13 is compiling to 48% memory) and the voltage and more importantly space requirements are less with the sat.

Instead of an internal solution, I opted to put my extra switches into a box that attaches to the back of the Devo7e. My box provides 2 potentiometers and three 3-way switches through the magic of the Arduino Pro Mini. The box is powered by a single switched 9V battery (with indicator LED) and connects to the Devo7e DSC port.





The advantage to this approach is that this box can be used with ANY TX that has a DSC in jack. However my main motivation is the ability to easily open up the box and add or change the functionality. My first modification will be to remove an existing thumbwheel (Analog port 3) and use a 6-position rotary switch instead.

This box includes:
Arduino Pro Mini ATMega328P 5v/16Mhz (eBay) - note I used the one without the USB port because I already have an FTDI USB-to-serial board
1 x Hammond 1591BSBK project box (112mm x 62mm x 27mm) (Amazon)
2 x 5k Linear Potentiometer (eBay)
3 x On-off-on switch (Radio Shack 275-325)
1 x 3.5mm 2-conductor phono jack (274-248)
1 x micro On-off switch (275-524
1 x 3mm yellow LED
1 x 390ohm 1/4watt resistor
1 x 9v battery connector
1 x 3.5mm 150mm phono cable
industrial strength velcro

The hookups can be soldered pretty quickly. I used a 90 degree pin and AMP connectors since I like to tinker. While it takes up more space, I can easily move switches or attach my programmer to the board.

Deal57 wrote: My first modification will be to remove an existing thumbwheel (Analog port 3) and use a 6-position rotary switch instead.

You going to rig up the switch with resistors and hook to analog pin? That's my backup plan if I run out of inputs.

Awesome stuff going on here!

I am trying out one of the Taranis 6-position switches.
www.alofthobbies.com/6-position.html

They have mixed reviews, but it saves some soldering. I've got a spot for it in my box.

I'm very interested in your voice prompts... It should be a nice enhancement. For my purposes i think it will work ok just telling me the settings on this box, since I'll have telemetry from the quad GCS telling me flight status.

I'm not a big fan of the 6 position rotary switch, since it's hard to know in what position it is at a glance... for folks who already have an Arduino add-on box, would be worth looking into adding 6 pushbuttons and 6 LEDs and build something like this diydrones.com/profiles/blogs/arduino-based-mode-switch (I mean: add the 6 position button/led into the same add-on box, using only one Arduino for everything)

The nice thing about that solution, is also that you can turn on the LED based on the signal being sent by the Arduino (i.e: read buttons, parse what needs to be done, send the right PPM signal for that channel, and turn on the right LED based on the PM signal just sent), making sure that you will never push a button, see the LED on, but still send the wrong value to the model

I agree the button approach makes a lot of sense but I'm not sure how far I want to go with this inexpensive TX! In any case it seems to me the most important part is getting proper feedback about the mode you've just selected. The rotary switch has the disadvantage of passing over perhaps multiple unintended switch positions on the way to the one you want, so you have to build in logic to effectively wait until the switch is really where you want it. Then, as you pointed out, use the actual OUTPUT results to light up the right indicator (which I hope will actually MATCH the mode that "Tower" tells me my APM is in!). The switch is less the issue to me than the correct response by my quad.

Which is why I am working this with an external box. I'm building a matrix of six mode indicators, probably two rows of LEDs or something like that. Fun stuff!

It may look really odd by the time I'm done, but it's a lot quicker than opening up the Devo ... and frankly I'd rather be flying!

Cereal_Killer wrote: arduino hooks to main (instructor) devo just as with this expansion mod (the same arduino already used for the channel expander, not a second)
satellite receiver hooks to arduino (this part was easy as Multiwii already had all the code I needed)
second [student] transmitter (can be devo or ANY spektrum TX) binds to devo's internal sat RX
arduino decodes serial RX data, combines with PPM and sends it out*
Devo see's it all as standard PPM-SUM input and can use it however you program it to.

So what's going on with this?

And I have a question. IIUC, PPM-SUM is the same thing as CPPM, which means that it's a set of PWM pulses framed by a sync pulse. The CPPM Rx's have problems with running out of frame length with to many channels at full value. The FrSky as shipped can only handle 6 channels (5 if your Tx insists on sending at full value safely with an 18ms frame length. There's a firmware upgrade to change the frame length to 27ms to fix that. The OrangeRx x20 Rx's use a 22ms frame length, and only get 9 channels safely even though they advertise 12. How does this affect what you're doing here?

Thats why I do not understand people still developing decoding encoding ppm cppm basically coming form the old FM radio over the air modultaion. Nowadays we should use full digital pipeline and send the values digitally?

Cereal_Killer wrote: What's the goal I'm trying to achieve you ask?
Wait for it...
Wireless trainer PLUS the added on channels!

Following with a little interest; a while ago I buddy-boxed through one of the local field guy's spektrum of some sort, just bound to his TX like it was an RX and he could throw control over to me then snatch it back if need be.

@Fernandez
Agree and disagree...PPM is the standard that keeps the chain together, even in these days.
No ppm, no DSMX, FRSKY, UHF &c exchange modules for other players.
How then the RF chip on the transmitter module communicates with the one at the receiver does not matter.
Look at the toy market and you will see what would happen.
And what about the different FCs for quads and Heli FBL controllers, would they have to learn every RF protocol?

@Deal57
Your antenna mount on the "magic hole" takes my interest. What did you use for it.?

The Thingiverse details are at www.thingiverse.com/make:154699 . I had the piece 3D printed commercially, so it cost about $15. The fit of the antenna RPSMA mount is very tight. I had to carefully file away where needed so I could get the mount up the sleeve into the hole. The mount was an IPX-U.FL to RPSMA pigtail from my favorite cable supplier: www.ebay.com/itm/2-Mini-PCI-IPX-U-FL-to-...0555?var=&hash=item0
Using the U.fl connector allows me to disconnect from the module when I take the Devo 7e back off.

It fits tightly into the square in the back of the Devo7e and I used a bit of CA on the corners to keep it in place.

aMax wrote: @Fernandez
Agree and disagree...PPM is the standard that keeps the chain together, even in these days.
No ppm, no DSMX, FRSKY, UHF &c exchange modules for other players.
How then the RF chip on the transmitter module communicates with the one at the receiver does not matter.
Look at the toy market and you will see what would happen.
And what about the different FCs for quads and Heli FBL controllers, would they have to learn every RF protocol?

How about SPI?

Deal57 wrote: The Thingiverse details are at www.thingiverse.com/make:154699 . I had the piece 3D printed commercially, so it cost about $15. .....................snip

Hey, already saw this yellow one on the web in January, but did not remember where. Thanks.
So it would be possible to have two antenna sockets there and to apply a coaxial termination
dummy load each when not in use. The handle bar protects this area. Great.

Richard96816 wrote:
How about SPI?

That's a hardware interface which is already used by MCU and RF chips. Are all the protocols now the same?

aMax wrote:

Richard96816 wrote:
How about SPI?

That's a hardware interface which is already used by MCU and RF chips. Are all the protocols now the same?

Yup. SPI just specifies byte-level stuff, not how they break out into channels. As such, it needs another protocol layer for this application. That's the level that needs to be reverse engineered to implement a new RF protocol in deviation. CPPM is a channel-level protocol, so you can just drop in a library and it works with everything that does CPPPM.

S-BUS - at least as reverse engineered - seems to be gaining traction with low-end Rx manufacturers, and it's supported on a variety of Fc's. SRXL is an open specification, so preferable, and gaining some traction at the high end (Graupner, microbeast, Spektrum). However, both (and most of the other alternatives I've looked at) want a UART, which causes some people to prefer CPPM.

Wanting to implement an FC from scratch, I'm annoyed that the Arduino CPPM libraries all use the same timer as the servo libraries. I've got no other use for a uart, so may change over to S-BUS. But I'll need an Rx first....

I think S.Bus is more what he was getting at.

There could be many ways to send values digitally indeed s-bus etc. I thought internally deviation was allready full digitall meaning, that thew pots and switches values are digitised, mixed and send as channel values digital over the rf link.. (no ppm encoding decoding)
Minimum jitter and latency. I would even think that digital sending/reading info is more easy than ppm encoding/decoding to digital?

Anyway maybe it is off topic and not relevant.......

Off topic seems to be the norm around here.

But yeah, internally most of the deviation comms are digital, using SPI to talk to each of the rf modules. But each protocol on each chip uses a different way of creating packets of channel values for the rf modules to send. So you start by capturing the SPI data to figure that out. PPM gets used for trainer input/output because that's the protocol the world uses for such.

When you are discussing S.bus and SPI, today aren't you really talking about the "output" side of the Transmitter system, that is, how the TX tells our peripherals (RX, voice prompter, etc.) to work? Can we look just at "input"?

IIUC the "input" side in DeviationTX uses a mix of analog (through an ADC) and digital from whatever control gizmo (mostly analog, pots, switches, sliders, head tracking, etc. AND PPM) that is collecting our movements. PPM on Arduino talking to DeviationTX makes it easy for newbies like me to get in and tinker, and for the most part latency isn't much of an issue. I think it would certainly be nice to have a way to collect those signal digitally in the first place, put them onto a two- or three-wire bus, then have DeviationTX use them for controls. This would reduce latency and increase our processing options. Does such a standard exist in RC yet? I checked the port descriptions for Hitec, Futaba and JR and they use PPM. Is PPM still the pretty much only choice of nearly all the major players for handling any external input?

Are there other options that might be on the leading edge?