Alexinparis wrote:For each item, you just have to select the right number of 8bit var needed and order bits in this order (n AUX, m states): AUX1.1 AUX1.2 ... AUX1.m AUX2.1 ... AUX2.m ... AUXn.m. With the message AUX_COUNT, the aware GUIs will know what to interpret, and the unaware GUIs won't see the difference.
Actually, they will. I thought about such a layout, but it fails once have a different number of states:
Without knowing the proper number of state and channels, the unaware GUI has no chance to notice the misalignment. The existing code resorts to ignoring requests of unaware GUIs if they cannot be fullfilled (channels != 4, states != 3); if both type of GUIs use the same request, the firmware cannot distinguish the two and can just hope for the best.
I consider an unaware GUI must be used only with the 4x3 states, no other combination. The aware GUIs must rely on the MSP_AUX_COUNT first to know how to interpret the message.
This way, every GUI are happy with MSP_BOX messages.
Alexinparis wrote:I consider an unaware GUI must be used only with the 4x3 states, no other combination.
This does work. This is what the compatibility code ensures. But the copter has to distinguish aware and unaware clients from each other - e.g. by different request codes (MSP_BOX vs. MSP_AUX). Blindly delivering the data on MSP_BOX will cause mayhem if an unaware clients connects to a copter not using a 4*3 setup.
copterrichie wrote:Why not offer an er9x patch for the WiiCopter? Many people have these transmitters and have upgraded to er9x.
I'm working on something for the 9x. But it could take a while. The codebase of open9x (where most of the development happens nowadays) is almost twice as big as MultiWii's.
First order of business would be to incorporate tommie's binary protocol into the firmware of the 9x. After that your only limit is the flash size.
copterrichie wrote:Why not offer an er9x patch for the WiiCopter? Many people have these transmitters and have upgraded to er9x.
I'm working on something for the 9x. But it could take a while. The codebase of open9x (where most of the development happens nowadays) is almost twice as big as MultiWii's.
First order of business would be to incorporate tommie's binary protocol into the firmware of the 9x. After that your only limit is the flash size.
That sounds interesting, do you have a link? I would like to follow the progress of your and the 9x developments.
whats the base of this patch? I try to implement it to 2.1 but I think the row numbers and the code are different?!?!?!
You should be able to apply the patch to the latest CVS upstream (_shared). If you want to take the easy road, simply check out the git repository with all changes applied; or you can download the branch with the aux_channel patches applied as ZIP here: https://github.com/wertarbyte/multiwii- ... x_channels If you have any further questions, feel free to visit us at the IRC channel #multiwii at Freenode.
// Read PPM SUM RX Data #if defined(SERIAL_SUM_PPM) void rxInt() { uint16_t now,diff; static uint16_t last = 0; static uint8_t chan = 0;
now = micros(); diff = now - last; last = now; if(diff>3000) chan = 0; else { #if defined(AUX_CHANNELS) if(900<diff && diff<2200 && chan<(AUX_CHANNELS+4)) { //Only if the signal is between these values it is valid, otherwise the failsafe counter should move up #else if(900<diff && diff<2200 && chan<8) { //Only if the signal is between these values it is valid, otherwise the failsafe counter should move up #endif rcValue[chan] = diff; #if defined(FAILSAFE) if(failsafeCnt > 20) failsafeCnt -= 20; else failsafeCnt = 0; // clear FailSafe counter - added by MIS //incompatible to quadroppm #endif } chan++; }
Hm, somehow a lot of stuff got included into your patch, not just the AUX channel improvements. Would you mind joining #multiwii so we can straighten it out a little bit?
I tried to replicate the changes you added to my patchset here; I condensed them a little bit, can you check whether all changes are actually included?