Ultimate 7e-256k builds

that's some amazing detective work guys!

@phantom8, good thinking on the test! I used the same method to test the problem on my tx as I was fixing it.

@dc59, I think it should be sorted now (fingers crossed). Try out deviation-devo7e-256-v5.0.0-0056d17 and let us know how it goes.

@silpstream
"deviation-devo7e-256-v5.0.0-0056d17" , excellent ! It works great !
Thanks for your great job.!

@silpstream, great job! Thanks for the quick fix.

In my tx I also wired soldered the mcu pins for the pots, but they are not connected. in the ini file I have not set any pots. am I at risk?

I soldered on each of the adc pins 100pf, capcitor to gnd, at least to minimize chnaces lines to pick up RF.

Guys, thanks very much for helping to get the kinks out of the u7e. Base on the work we've done, I've sent up a pull request to the main brach with the bug fix. I've also updated the files that are in the test build section. The builds I have are based on BRANCH_5.0 (current release branch), but I've included the bug fixed version of the 2016-06-14 nightly as the PR is pending.

If you are using a u7e, I strongly suggest flashing your TX to one of these new files.

Fernandez wrote: In my tx I also wired soldered the mcu pins for the pots, but they are not connected. in the ini file I have not set any pots. am I at risk?

I soldered on each of the adc pins 100pf, capcitor to gnd, at least to minimize chnaces lines to pick up RF.

Good idea on adding a filter cap! Any chance you can post a picture of how it is done?

Not sure about the risk even though you have the cap, but I'd still update to the latest files I just uploaded.

just tested here on stock and 4x3-2x2-2pots and all works as expected, nice work guys

@silpstream
Tested, all works fine with my U7E , thanks a lot.

i've updated the first post with details of the latest build, as SS's pull request isn't merged yet i've also included a build of tonight's nightly with the bugfix code included.

as always if you find any bugs post here or the bugtracker, and enjoy your rc adventures

thanks HH for updating builds.

no worries bud, I know I was a bit tardy this time with the update, i've been working on porting silverxxx's 3d firmware over to the 3d x4 and h8 3d fcb's which took up a lot of my free time, but we're almost there with those

Hi guys, I have been running the latest Silpstream switches mod with 3x2 and 6x2 switches and 2 pot on my u7e and been flying a number of packs and it proves to work fine/reliable for me.
I would like to get it merged to latest build and have the Frsky - X protocol included as I can't fly my other drone? Possibly also the AFHDS 2A of Goebish, that worked also fine for me.

silpstream (yeah i'm good at volunteering other people lol) will have to build that for you atm as I'm currently about 1640miles from my build station, and while I could remote in over my phone it would be tedious and messy

Haha I missed that one, enjoy your holidays!

Consider me volunteered... ;P

Sorry for the wait, I had to send my macbook in for repairs and just got it back. Anyhow I've uploaded new builds for both BRANCH_5.0 and Nightly.

I still need to fix the emulators so, we may need to wait a bit for the PR while I sort that out.

thanks for volunteering bud , and as always thanks for the code that helps take our beloved 7e to the next level!

Thanks guys just loaded the build based on the latest nightly, but without voltage calibrate hardware.ini. and my switches still work, also friky x protocol is back.
I do not know what is the "hardware voltage calibrate" build for 7e and what it addresses, I missed that one?

For the AFHDS Goebish protocol I think is still is in test build state, although it worked perfectly well for me at the time, for now won't use this Rx.
Next step in U7E now will be the voice mod.
.

I've finished with the mods for the emu. I've tested and it works for me. If anyone finds any bug, do let us know. All builds updated in the downloads area.

@Fernandez, the voltage calibration build exposes the values used to for the battery voltage reading. Basically we can measure the battery with a multimeter and compare the readings that the transmitter has. From there we can then tweak the values to hopefully get closer to actual readings. BUT take this with a pinch of salt, our battery ADC readings are somewhat non-linear and PhracturedBlue plotted it to the closest straight line values based on multiple readings as the battery gets drained. You will have to do something similar to improve on that. You could in fact get worse results if it is not done properly. The initial values in the hardware.ini are the default values from PB's calculations.

ah super my volt readout is also slightly off indeed