Devo7e work

FDR wrote: You put the battery voltage measurement into the stick readout routine, didn't you?
I just wanted to suggest something like that to prevent the need for 2 kind of ADC reading...

we have never done 2 types of ADC reading. The STM32 has a handy scanning ADC, where you tell it which channels to scan and it will automatically read each in sequence. We've always done it that way.

Originally, I would execute the scan once per 5msec. This is how it has been until I started working on the devo12.

The devo12 has a design flaw that results in noise on some ADC channels. To address that I decided to read each channel multiple times and average the result. However, I still want to get one reading each 5msec, so I increased the sample rate such that we were constantly scanning the ADC (the STM32 allows this with no software interaction). I then just run an averaging routine every 5msec. This works well on the devo12, but on the devo 7e/8/10 it has the effect of making the TX voltage reading dependent on the value of the previous ADC (on the Devo8 it was aileron, on the devo7e it was throttle). I believe this happens because there is virtually no current through the voltage-sense pin, and so parasitic current from the ADC can affect the voltage.

I then put in a hack (which didn't work) to try to stabilize the TX voltage, but it resulted in glitches.

The current solution is to (a) slow down the scan rate for the 6/7e/8/10. Since we don't need as much averaging, I can get by with slower sampling and fewer samples on these tx. This drastically reduces the coupling between the stick position and the TX-voltage reading.(b) introduce a 'buffered' read between the last channel data and the tx-voltage. This acts as a shield and removes the rest of the input-stick coupling to the tx voltage.

I've tested on all of the TX I have, and see that I get accurate and stable results without any glitches on each.

Sorry, I misinterpreted the additional ADC read in the sequence, but it was the temp sensor read, which was added just before the voltage read...

MacGyverek wrote: I have few question about Devo 7e.

1. I found a Switch mod on one thread. Please tell me something about configuration. Can I add custom function for all switches?? For example: 1 switch-Flight mode, Next switch-Dual Rate, Next - Throtle hold, Next one - Gyro sensitivity??

Switches can be assigned to any task in Deviation. This is true in both the 'standard' and 'advanced' interface

2. Where can I found a user manual for Deviation software for Devo 7E or Devo 10?? Any screenshot???

The devo10 manual is the same as for devo7e here:
www.deviationtx.com/repository/Documentation/
The 'Standard' interface is not documented, but looks similar to the original Walkera interface.

3. There is any option for rollback to oryginal software (I can't found a Devo7E software on Walkera webage)

Some users have managed to get Walkera to give them the firmware and have used it to roll back. For copyright reasons, it cannot be posted on these forums though.

when you setup a model, you choose which interface to use for it. If you are using models developed by others, than you will get the interface they used.

I played with various methods for the devo12, but never found one that produced better results than a simple average. On the Devo12 we have a lot of noise (more than +/-4bits of noise). On the others it is more like +/-2bits of noise.

I use a 100sample average on the Devo12 and a 10sample average on all other Tx.
On the devo12, the olympic average isn't aggressive enough to have an impact (you really would need to discard the outer 10% of values to make a significant difference. It is likely that a median filter would work well on the devo12, but implementing one is pretty computationally expensive for algorithms I am aware of. For the other Tx, it really isn't necessary.
In any case, the current implementation gives us a noise of less than +/-3 bits which is sufficient for accurate control.

Maybe Kalman filter?
www.den-uijl.nl/electronics/gyro.html

If you are going to use the devo7e, I recommend using the nightlies (or stay current with recent builds).

In any case, wk2601 protocol should work fine in that build as well as the nightlies. Just to be sure, I just verified that it works as expected.

The wk2601 protocol is very odd, and needs a customized config to work with most helis.

Specifically, make sure you are using 'Chan mode = Heli' Then read the documentation for how to configure the gyro channels. While I have a couple Rx, I don't actually have a 2601 heli I can configure so I can't guve further instruction.

Just now I tried change GUI on Emulator emu_devo7e (forth and back) with latest build (a80935a2970e), all works fine.

I think it will be at Night builds tomorrow.

For editing *.ini files you can use any UNIX style text editor.
www.deviationtx.com/forum/3-feedback-que...con-in-ini-file#6344