Devo 7E additional analogue controls?

The switch mods to add more switches to the 7E and the deviation updates to support configuring additional switches is coming along great! Can't wait to start adding new controls.

Correct me if I'm wrong, but the switch mod for adding 2 x 3way switches uses a little trickery to scan for more switches then there are I/O pins available. By assigning some of the I/O pins as outputs each switch is 'enabled' and checked independently. So the same input pins can be re-used for each switch. Pretty clever (and typical for multiple switch inputs).

Now, if I take this thought experiment a little further, the stick pots could also be 'selected' with a little circuitry magic.

I've used analogue line switch chips in the past (the electronic version of a mechanical switch). They're cheap, common and easy to use. Really no different than wiring up a mechanical switch (for low power signals), except you can control them electronically with logic level controls. Let's say we split the wiring to one of the stick pots using an analogue line switch chip. Using one of the I/O pins from the transmitter we can then select whether the ADC is reading from the regular stick pot, or from a new 'extra' pot(s) we add ourselves. Deviation would need to be modified to switch the pots and scan the ADC appropriately. I don't know how much of the stick pot scanning and ADC currently happens on chip or in the firmware.

So instead of modding the 7E with two new switches, you could say mod it with a single 3 way switch and new analog turn knob. Or two new analog turn knobs.

Does anyone have any thoughts on this?

I think using an analog mux on the flight sticks would get messy, especially as the sampling is fairly asynchronous from the program.

Using one on the aux channel (does 7e have that?) might work.

But there's a trainer input that is either ppm or serial, right? So what about adding something like an atmega (or arduino mini 3.3v) to scan the extra channels and convert them to a ppm or serial format for the stm32?

The MCU has a lot of analog input pins (the bigger from Devo8 and 12 have 16) so with a good soldering iron and a calm hand you could connect a pot at one of those free pins (PA4 is the only unused ADC pin).
I would highly recommend not to multiplex the stick inputs due to stability of measurement. Also additional inputs are somehow less time critical, I believe. So multiplexing pots at the PA4-line could work reliable.

I didn't realize there were free ADC pin(s) available. No need to interfere with the stick pots when other analog I/O is available.

The STM32F100C8 datasheet (is that the MCU for the 7e?) lists a single ADC unit multiplexed on 10 channels (pins). There should be another 6 unused analogue pins available (after stick pots) no? Hmmm.. Is the battery monitor using one of those pins? Unless they're all connected to ground on the circuit board. Could be tough freeing up pins if so.

Internally the MCU is already selecting analogue lines to sample, controlled by firmware presumably. Reading another un-used ADC channel should be a no brainer. The bigger transmitters (with more analogue controls) are probably already doing this. The unused ADC channels could simply show as 'aux1', 'aux2', etc, in the menu. Maybe enabled in the transmitter ini?

I knew I'd seen that 7E Hardware Connections page before. Darned if I could find it again

The link for the STM32F103RBT6 is wrong. It points to the
STM32F103VC spec sheet (STM32F103xC, STM32F103xD, STM32F103xE).

The proper link for the STM32F103RBT6 is www.st.com/web/catalog/mmc/FM141/SC1169/SS1031/LN1565/PF164487 . Not that there's a whole lot of difference other than the chip pin outs.

So 2 internal ADCs on 16 channels. Looks like there are no direct ADC pins on the chip and all ADC input is configured through the regular I/O pins "alternate function on I/O pin".

PA 0-7, PB 0-1 and PC 0-5 (16 alternate ADC inputs)

If I'm reading the 7E Hardware Connections right, GPIOA 0 and 4 are unused stock?

PhracturedBlue wrote: Note that the way Deviation is coded, you can ony eaily use one ADC and we use ADC1. So use of ADC2 would be very challenging to code.

Hmmm... Looks like PA0 is mapped to ADC_IN_0 and PA4 is mapped to ADC_IN_4.

The data sheet doesn't really spell it out but since this is in the lower 8 ADC inputs and the pots are connected to the higher 8 ADC inputs I would have to assume these connected to the 'other' ADC (2).

I guess, the next question is which is more challenging to code? Use of the second ADC? Or multiplexing the existing ADC with an CMOS analogue switch? It may be easier to mod using a pot wire than trying to connect directly to the chip.

PA0 and PA4 are available to both ADC's. (On the "V" series parts such as used in Devo10 PA0 is also available to ADC3).

Using a external multiplexor with ADC1 would probably be challenging, since it would be hard to coordinate switching the multiplexor with the timing of the conversions and averaging that happens currently. Doing this would probably require going back to the old scheme of using the DMA interrupt to synchronize with the conversions - but you'd still have to worry about not getting any conversions pipelined on the wrong side of when the multiplexor switches. So it's both tricky, and messing with the primary flight controls.

While PB is obviously more familiar with the code than I am, in contrast, I see the fact that only ADC1 is currently used as a potential opportunity to use ADC2 in a way entirely independent of the way the primary flight controls are sampled with ADC1 - such as trying to coordinate it with a multiplexor. But it's still not how I'd approach the problem.

If you can do without either your trainer port, or your throttle hold switch, then you can use either USART1 RX (trainer) or USART3_RX (PC11, throttle hold) as an already wired up channel to inject digital information collected by an additional outboard sampler, such as an ATmega. This might have a tiny bit more latency, but would have the advantage of requiring minimal connection to the existing system - indeed, the trainer plug version could perhaps be done with only software and an external plug-in, veclro-on box.

Has anyone thought about adding an optical rotary encoder wired parallel to the throtthe trim switch in order to get an emulated analog input?