SERIAL_SUM_PPM channel order not working

Post Reply
User avatar
phenolic
Posts: 81
Joined: Fri Sep 21, 2012 10:31 pm

SERIAL_SUM_PPM channel order not working

Post by phenolic »

I'm using a 9x with ER9X and FrSky D4R-II receiver.

When I use this:

Code: Select all

#define SERIAL_SUM_PPM         ROLL,PITCH,THROTTLE,YAW,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For Robe/Hitec/Futaba

Everything is correct except ROLL and YAW are swapped. In other words when I push the rudder stick it does ROLL in MultiWiiConf and when I push the aileron stick it does YAW.

OK, simple enough to fix, right? Just swap ROLL and YAW. So I use this line:

Code: Select all

#define SERIAL_SUM_PPM         YAW,PITCH,THROTTLE,ROLL,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For er9x default

Now everything is screwed up. The throttle stick does ROLL, the rudder stick does THROTTLE, PITCH works normal, and aileron does YAW. I changed nothing other than the SERIAL_SUM_PPM line. WTF?! :?

User avatar
djrm
Posts: 40
Joined: Wed Feb 15, 2012 11:32 pm
Location: North Yorkshire, UK

Re: SERIAL_SUM_PPM channel order not working

Post by djrm »

I fixed a similar problem to yours by altering the mixes using the er9x configuration menus.
in multiwii conf:
#define SERIAL_SUM_PPM ROLL,PITCH,THROTTLE,YAW,AUX1,AUX2,AUX3,AUX4
in er9x menus:# (for mode2 tx):
ch01 +100%AIL
ch02 +100%ELE
ch03 +100%THR
ch04 +100%RUD
ch05 +100%FULL Switch(ELE)
ch06 +100%P3
ch07 -100%FULL Switch(ID0)
+0%FULL Switch(ID1)
+100%FULL Switch(ID2)
ch08 +100%FULL Switch(AIL)
(values copied from eePe saved values display)

The four aux settings make the front controls work, three switches and a potentiometer.
hth David.

User avatar
phenolic
Posts: 81
Joined: Fri Sep 21, 2012 10:31 pm

Re: SERIAL_SUM_PPM channel order not working

Post by phenolic »

Oh I know I can fix it simply by moving the channels around on the radio but that's not what I'm trying to do. Why isn't MultWii working correctly?

doughboy
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

SERIAL_SUM_PPM channel order not working

Post by doughboy »

If switching roll and yaw did not fix the problem, I highly doubt rearranging the mix will fix it. They do the same thing, it will rearrange the sequence of the pulse. You may try tweaking the timing on ppm sum pin interrupt handler.

By default, a pulse gap >3000us will cause channel to reset to first channel. The interrupt is setup to detect only rising edge and time is calculated from one rising edge to the next.

Do you know the frame size used by frsky? Or actually, if you are using er9x, you can specify the ppm protocol pulse width and frame size. The default value works fine. I think it's 300us pulse width and 20ms frame size. And make sure it is set to 8 channels or however many channels the rx/tx module supports.
Last edited by doughboy on Fri Nov 16, 2012 1:50 am, edited 1 time in total.

User avatar
phenolic
Posts: 81
Joined: Fri Sep 21, 2012 10:31 pm

Re: SERIAL_SUM_PPM channel order not working

Post by phenolic »

doughboy wrote:If switching roll and yaw did not fix the problem, I highly doubt rearranging the mix will fix it. They do the same thing, it will rearrange the sequence of the pulse. You may try tweaking the timing on ppm sum pin interrupt handler.

By default, a pulse gap >3000us will cause channel to reset to first channel. The interrupt is setup to detect only rising edge and time is calculated from one rising edge to the next.

Do you know the frame size used by frsky? Or actually, if you are using er9x, you can specify the ppm protocol pulse width and frame size. The default value works fine. I think it's 300us pulse width and 20ms frame size.


Thanks! Useful information. Actually the D4R-II uses a 18ms frame size on its CPPM output so that may be the problem (there is alternate firmware for 27ms frame size for 8 channels). Especially with 6 channels the sync gap is going to be minimal, possibly less than 3000us. I'm going to test this out.

The default for er9x is 22.5ms frame size but that won't affect the CPPM output on the receiver.
Last edited by phenolic on Fri Nov 16, 2012 1:52 am, edited 1 time in total.

doughboy
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

SERIAL_SUM_PPM channel order not working

Post by doughboy »

I just edited my post.
You can change the ppm protocol setting in er9x, so you may want to try that first.

doughboy
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

SERIAL_SUM_PPM channel order not working

Post by doughboy »

phenolic wrote:
doughboy wrote:If switching roll and yaw did not fix the problem, I highly doubt rearranging the mix will fix it. They do the same thing, it will rearrange the sequence of the pulse. You may try tweaking the timing on ppm sum pin interrupt handler.

By default, a pulse gap >3000us will cause channel to reset to first channel. The interrupt is setup to detect only rising edge and time is calculated from one rising edge to the next.

Do you know the frame size used by frsky? Or actually, if you are using er9x, you can specify the ppm protocol pulse width and frame size. The default value works fine. I think it's 300us pulse width and 20ms frame size.


Thanks! Useful information. Actually the D4R-II uses a 18ms frame size on its CPPM output so that may be the problem (there is alternate firmware for 27ms frame size for 8 channels). Especially with 6 channels the sync gap is going to be minimal, possibly less than 3000us. I'm going to test this out.

The default for er9x is 22.5ms frame size but that won't affect the CPPM output on the receiver.

Ok, if frame size is 18 then you need to make each channel max time less than 2000us. Then change the blank detect time to whatever is left.

So if you set max to 1950us x 8 less 18,000 leaves you 2400. So change the 3000us to 2400 in Rx.ino

User avatar
phenolic
Posts: 81
Joined: Fri Sep 21, 2012 10:31 pm

Re: SERIAL_SUM_PPM channel order not working

Post by phenolic »

doughboy wrote:Ok, if frame size is 18 then you need to make each channel max time less than 2000us. Then change the blank detect time to whatever is left.

So if you set max to 1950us x 8 less 18,000 leaves you 2400. So change the 3000us to 2400 in Rx.ino


Nope, no change. I set all channels to minimum value also, that should create the largest gap possible. Something else is going on. It's like the channel definitions are not mapped to what they are suppose to.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: SERIAL_SUM_PPM channel order not working

Post by copterrichie »

You may want to try changing the following in the Def.h file to FALLING

Code: Select all

#define PPM_PIN_INTERRUPT          attachInterrupt(0, rxInt, FALLING); //PIN 0

User avatar
phenolic
Posts: 81
Joined: Fri Sep 21, 2012 10:31 pm

Re: SERIAL_SUM_PPM channel order not working

Post by phenolic »

copterrichie wrote:You may want to try changing the following in the Def.h file to FALLING

Code: Select all

#define PPM_PIN_INTERRUPT          attachInterrupt(0, rxInt, FALLING); //PIN 0


Nope, no change.

User avatar
phenolic
Posts: 81
Joined: Fri Sep 21, 2012 10:31 pm

Re: SERIAL_SUM_PPM channel order not working

Post by phenolic »

Also, remapping the channels on the TX does fix it. As far as I can tell something is wrong with the MultiWii code.

I'm thinking the definitions do not match what they are called. In other words, ROLL isn't actually the roll channel, YAW isn't yaw, etc.

doughboy
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

SERIAL_SUM_PPM channel order not working

Post by doughboy »

The mix order on er9x must match the order you specified in the define. If you are saying is you got it to work by simply rearranging the mix order, then I'd say you may have multiple defines in your config.h or made some inadvertent change in your code. It should not happen in stock code.

doughboy
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

SERIAL_SUM_PPM channel order not working

Post by doughboy »

phenolic wrote:Also, remapping the channels on the TX does fix it. As far as I can tell something is wrong with the MultiWii code.

I'm thinking the definitions do not match what they are called. In other words, ROLL isn't actually the roll channel, YAW isn't yaw, etc.


I can guarantee you roll is roll and yaw is yaw. Actually the code takes the string in the define as is. So the only way a roll is not a roll is if you defined it more than once.

User avatar
phenolic
Posts: 81
Joined: Fri Sep 21, 2012 10:31 pm

Re: SERIAL_SUM_PPM channel order not working

Post by phenolic »

doughboy wrote:The mix order on er9x must match the order you specified in the define. If you are saying is you got it to work by simply rearranging the mix order, then I'd say you may have multiple defines in your config.h or made some inadvertent change in your code. It should not happen in stock code.


Should not, but it is. This code is straight out of svn (MultiWii_shared). Only change is my config.h and it does not have multiple definitions (attached).
Attachments
config.zip
(17.55 KiB) Downloaded 239 times

User avatar
phenolic
Posts: 81
Joined: Fri Sep 21, 2012 10:31 pm

Re: SERIAL_SUM_PPM channel order not working

Post by phenolic »

OK, I looked at the code. I believe it doesn't work the way that I think was originally intended.

So to make my configuration work I used this order:

Code: Select all

#define SERIAL_SUM_PPM         3,1,0,2,AUX1,AUX2,AUX3,AUX4,8,9,10,11

Which is equivalent to:

Code: Select all

#define SERIAL_SUM_PPM         THROTTLE,PITCH,ROLL,YAW,AUX1,AUX2,AUX3,AUX4,8,9,10,11

But that doesn't mean what you would think. What it says is THROTTLE is on channel 1... but actuality what the code is doing is saying that the ROLL function (the first position in the SERIAL_SUM_PPM array) is mapped to channel 4.

Hmm, I'm too tired to explain it reasonably well. The essence of the problem is that the logic is reversed. Instead of mapping a channel function like ROLL to a channel number, it's mapping a channel number to a function. Maybe that is the intention, I don't know but I know how to map them now after looking at the code. You have to know the order of the "rc" enum to do it though and putting values like THROTTLE, ROLL, etc in the SERIAL_SUM_PPM array doesn't make any sense with the current logic of what the code is actually doing because you want to put channel numbers in there (minus one because of the zero-based array), not function values like ROLL.

doughboy
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

Re: SERIAL_SUM_PPM channel order not working

Post by doughboy »

I see what you are saying.
There are two channel orders here.
1. Multiwii channel order, defined as

Code: Select all

enum rc {
  ROLL,
  PITCH,
  YAW,
  THROTTLE,
  AUX1,
  AUX2,
  AUX3,
  AUX4
};

so ROLL is 0, PITCH is 1, YAW is 2 and THROTTLE is 3.

in SERIAL_SUM_PPM , you assign the actual channel according to the above order
so instead of

Code: Select all

#define SERIAL_SUM_PPM         THROTTLE,PITCH,ROLL,YAW,AUX1,AUX2,AUX3,AUX4,8,9,10,11


you should use

Code: Select all

#define SERIAL_SUM_PPM 2,1,3,0,AUX1,AUX2,AUX3,AUX4,8,9,10,11


which is the same as

Code: Select all

#define SERIAL_SUM_PPM YAW, PITCH, THROTTLE, ROLL, AUX1,AUX2,AUX3,AUX4,8,9,10,11


and you will get the correct mappiing.

So I think the multiwii code is correct, but the usage of SERIAL_SUM_PPM define is a little confusing.
Intuitively, one would think the RX channel 0 is YAW. so to avoid confusion, the LITERAL should not be used in the define.
someone should add this comment on top of SERIAL_SUM_PPM define
//map your RX channel order to MultiWii order
//ROLL, PITCH, YAW, THROTTLE, AUX1, AUX2, AUX3, AUX4
//so if your actual channel order is chan0=throttle,chan1=pitch,chan2=roll,chan3=yaw
//assign roll channel first, pitch channel second, yaw channel third, throttle channel fourth
//#define SERIAL_SUM_PPM 2,1,3,0,AUX1,AUX2,AUX3,AUX4,8,9,10,11

doughboy
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

Re: SERIAL_SUM_PPM channel order not working

Post by doughboy »

or create a new enum as follow

Code: Select all

enum rxchannel {
RXCHAN0,RXCHAN1,RXCHAN2,RXCHAN3,RXCHAN4,RXCHAN5,RXCHAN6,RXCHAN7};


then

Code: Select all

//map your RX channel order to MultiWii order
//ROLL, PITCH, YAW, THROTTLE, AUX1, AUX2, AUX3, AUX4
//so if your actual channel order is chan0=throttle,chan1=pitch,chan2=roll,chan3=yaw
//assign roll channel first, pitch channel second, yaw channel third, throttle channel fourth
//                        ROLL   PITCH     YAW   THROTTLE  AUX1   AUX2    AUX3    AUX4
//#define SERIAL_SUM_PPM RXCHAN2,RXCHAN1,RXCHAN3,RXCHAN0,RXCHAN4,RXCHAN5,RXCHAN6,RXCHAN7,8,9,10,11

doughboy
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

Re: SERIAL_SUM_PPM channel order not working

Post by doughboy »

so if this worked for you

#define SERIAL_SUM_PPM 3,1,0,2,AUX1,AUX2,AUX3,AUX4,8,9,10,11

that means your RX channel - function order is
channel 0 is yaw
channel 1 is pitch
channel 2 is throttle
channel 3 is roll

hence in your first post you said you initially defined it as

#define SERIAL_SUM_PPM ROLL,PITCH,THROTTLE,YAW,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For Robe/Hitec/Futaba
which is
0,1,3,2

you can see second and fourth function matched, which are pitch and throttle in multiwii function order. hence you said roll and yaw are reversed.
but instead of switching first and third, you switch first and fourth.

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: SERIAL_SUM_PPM channel order not working

Post by jevermeister »

multiwii code is correct. I used sum signal with several controllers and had no problem.
U have to rearrange channel order in er9x. to the futaba settings and it works. ;-)
nils

doughboy
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

Re: SERIAL_SUM_PPM channel order not working

Post by doughboy »

Its a little bit convoluted, but I can confirm this is a bug in multiwii code.
phenolic is correc tthat the mapping is reversed.

so lets say you defined SERIAL_SUM_PPM as YAW, PITCH, THROTTLE, ROLL (we'll just do the first 4 for simplicity)
as your channel order. and rcChannel array is initialized as follows
rcChannel[0] = 2 //YAW is 2
rcChannel[1] = 1 //PITCH is 1
rcChannel[2] = 3 // THROTTLE is 3
rcChannel[3] = 0 //ROLL is 0

so interrupt service handler will assign values to
rcValue[0] ->yaw value
rcValue[1]-> pitch value
rcValue[2]=>throttle value
rcValue[3]->roll value


so to get the rcData for THROTTLE channel, we actually need rcValue[2]

RX.ino code to get throttle value is

Code: Select all

uint16_t readRawRC(uint8_t chan) {
  uint16_t data;
  #if defined(SPEKTRUM)
    readSpektrum();
    if (chan < RC_CHANS) {
      data = rcValue[rcChannel[chan]];
    } else data = 1500;
  #else
    uint8_t oldSREG;
    oldSREG = SREG; cli(); // Let's disable interrupts
    data = rcValue[rcChannel[chan]]; // Let's copy the data Atomically
    SREG = oldSREG;        // Let's restore interrupt state
  #endif
  return data; // We return the value correctly copied when the IRQ's where disabled
}


for which if you request data for THROTTLE channel, it will return
rcValue[rcChannel[3]]
which evaluates to rcValue[0]
which is the value for ppm channel 0, and is the value for yaw.
so you can see that you requested data for throttle but got YAW instead.
proof the multiwii code is incorrect.

The fix is actually quite simple. change this

Code: Select all

    data = rcValue[rcChannel[chan]]; // Let's copy the data Atomically


to this

Code: Select all

    data = rcValue[rcChannel[rcChannel[chan]]]; // Let's copy the data Atomically


so in the throttle example, the result will now be

rcValue[rcChannel[rcChannel[3]]]
since rcChannel[3] is 0, which is ROLL then
rcValue[rcChannel[0]]
and rcChannel[0] is 2, which is YAW
so we now get the correct value
rcValue[2]
which is the 3rd ppm channel as defined in SERIAL_SUM_PPM
and is the correct value for throttle

Someone should make this fix in RX.ino, and give the proper warning to define SERIAL_SUM_PPM to the actual RX channel order instead of the current trial and error method to get the right combination.

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: SERIAL_SUM_PPM channel order not working

Post by jevermeister »

Hi,
has this been changed recently? I have no problems in <=2.1...

Nils

doughboy
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

Re: SERIAL_SUM_PPM channel order not working

Post by doughboy »

actually it is really convoluted. I tried a few more combinations and it does work as is for some but not for others. but a fix is needed to make it work for all.

see
viewtopic.php?f=8&t=2756&p=26812#p26812

doughboy
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

Re: SERIAL_SUM_PPM channel order not working

Post by doughboy »

another fix that is consistent with PWM code.

viewtopic.php?f=8&t=2756&p=26815#p26815

doughboy
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

Re: SERIAL_SUM_PPM channel order not working

Post by doughboy »

jevermeister wrote:Hi,
has this been changed recently? I have no problems in <=2.1...

Nils


if you follow my explanation, you can see proof the code does not work for all cases, I used phenolics channel order as example. and the result is exactly what he found out, yaw and roll are reversed.

User avatar
phenolic
Posts: 81
Joined: Fri Sep 21, 2012 10:31 pm

Re: SERIAL_SUM_PPM channel order not working

Post by phenolic »

This one is a little tricky because I'm not sure what the original developers intended. However, to make it work like I think the config describes and keep the same code efficiency it needs a little initialization to remap everything.

Obviously this is not the only way to "fix" this but if you add the following at the beginning of the configureReceiver() function in RX.ino:

Code: Select all

  #if defined(SERIAL_SUM_PPM)
  { // scope to limit memory usage
    uint8_t rcChannelTemp[RC_CHANS];
    for (uint8_t i = 0; i < RC_CHANS; i++)
      rcChannelTemp[rcChannel[i]] = i;

    memcpy((void*)rcChannel, (void*)rcChannelTemp, sizeof(rcChannel));
  }
  #endif // SERIAL_SUM_PPM


Now this line (from my original post):

Code: Select all

#define SERIAL_SUM_PPM         YAW,PITCH,THROTTLE,ROLL,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For er9x default

Works "correctly".

However, now that I know how it works it's not too hard to just specify the channel number instead of using ROLL, PITCH, etc in the SERIAL_SUM_PPM definition so I'm not sure if any of this is necessary.

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: SERIAL_SUM_PPM channel order not working

Post by jevermeister »

in which cases do the problems occur?How come it that nobody reported it yet.I think if there is a bug, we should fix it and not circumvent it. Not all users are smart enough to circumvent this. I would apply the patch if it is save and tested.

nils

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: SERIAL_SUM_PPM channel order not working

Post by copterrichie »

I have seen a number of problems with Sum PPM however, I don't have a clue as to if they are related to this situation. Maybe this problem happens when using more then six channels maybe?

User avatar
phenolic
Posts: 81
Joined: Fri Sep 21, 2012 10:31 pm

Re: SERIAL_SUM_PPM channel order not working

Post by phenolic »

I would guess nobody reports it because I think most people just remap the channels on their TX until it works. As you can see in this thread that has been suggested several times. That's not really a fix though, it's just making it work from the other side.

This particular issue does not have anything to do with the number of channels.

doughboy
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

Re: SERIAL_SUM_PPM channel order not working

Post by doughboy »

I would not recommend this fix, imagine the surprise a user would get if they used trial and error to get the right mapping in config.h, then apply this fix then find out the stick function now are all different.

My last suggested fix, although it looks drastic, is safer because users will be forced to redefine the channel order. Plus it makes the code pattern consistent with how it is done for PWM mode.

phenolic wrote:This one is a little tricky because I'm not sure what the original developers intended. However, to make it work like I think the config describes and keep the same code efficiency it needs a little initialization to remap everything.

Obviously this is not the only way to "fix" this but if you add the following at the beginning of the configureReceiver() function in RX.ino:

Code: Select all

  #if defined(SERIAL_SUM_PPM)
  { // scope to limit memory usage
    uint8_t rcChannelTemp[RC_CHANS];
    for (uint8_t i = 0; i < RC_CHANS; i++)
      rcChannelTemp[rcChannel[i]] = i;

    memcpy((void*)rcChannel, (void*)rcChannelTemp, sizeof(rcChannel));
  }
  #endif // SERIAL_SUM_PPM


Now this line (from my original post):

Code: Select all

#define SERIAL_SUM_PPM         YAW,PITCH,THROTTLE,ROLL,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For er9x default

Works "correctly".

However, now that I know how it works it's not too hard to just specify the channel number instead of using ROLL, PITCH, etc in the SERIAL_SUM_PPM definition so I'm not sure if any of this is necessary.

doughboy
Posts: 252
Joined: Tue Sep 04, 2012 7:20 am

Re: SERIAL_SUM_PPM channel order not working

Post by doughboy »

jevermeister wrote:in which cases do the problems occur?How come it that nobody reported it yet.I think if there is a bug, we should fix it and not circumvent it. Not all users are smart enough to circumvent this. I would apply the patch if it is save and tested.

nils


I evaluated this further, and so far, the only other pattern the existing code will work is if your channel order is
THROTTLE, YAW, PITCH, ROLL. If the rx channel order is the same as multiwii order, that will also work.

it just so happens by accident that the mapping is
0->3
1->2
2->1
3->0

all other combinations actually will not work.

As copterrich said, people just do trial and error until they get the right combination. which come to think of it, is also what I did. :)

if we count only the sticks channel, there are 24 possible combinations, and only two will work on existing code.

User avatar
phenolic
Posts: 81
Joined: Fri Sep 21, 2012 10:31 pm

Re: SERIAL_SUM_PPM channel order not working

Post by phenolic »

doughboy wrote:I would not recommend this fix, imagine the surprise a user would get if they used trial and error to get the right mapping in config.h, then apply this fix then find out the stick function now are all different.


If you're worried about that kind of stuff (and you're not wrong) then I wouldn't change anything at all. That doesn't make it correct but at least it's the same broken. ;)

Like I said, it's no problem for me, I just use the channel numbers instead of ROLL, PITCH, etc. Works fine if you follow the "rc" enum order.

An alternative that would be compatible with existing code might be to introduce a new macro instead of SERIAL_SUM_PPM that works the way it's suppose to.
Last edited by phenolic on Sat Nov 17, 2012 4:04 am, edited 1 time in total.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: SERIAL_SUM_PPM channel order not working

Post by copterrichie »

Personally, I would like to see it fixed. It may hurt in the short run but the overall benefits will justify the means. :)

User avatar
phenolic
Posts: 81
Joined: Fri Sep 21, 2012 10:31 pm

Re: SERIAL_SUM_PPM channel order not working

Post by phenolic »

copterrichie wrote:Personally, I would like to see it fixed. It may hurt in the short run but the overall benefits will justify the means. :)


Yeah but doughboy is right, a change like this could literally causes crashes or dangerous situations like arming unexpectedly. Personally I would introduce a flag or something that makes it work the new way. Otherwise it would work like normal.

You know, something like:

Code: Select all

  #if defined(SERIAL_SUM_PPM) && defined(SERIAL_SUM_PPM_FIX)
  { // scope to limit memory usage
    uint8_t rcChannelTemp[RC_CHANS];
    for (uint8_t i = 0; i < RC_CHANS; i++)
      rcChannelTemp[rcChannel[i]] = i;

      memcpy((void*)rcChannel, (void*)rcChannelTemp, sizeof(rcChannel));
  }
  #endif // SERIAL_SUM_PPM


Not saying my particular patch is the only way to go... Something like this... maybe :)

User avatar
phenolic
Posts: 81
Joined: Fri Sep 21, 2012 10:31 pm

Re: SERIAL_SUM_PPM channel order not working

Post by phenolic »

After having to set this up in a bunch of different combinations I decided that using my patch is way better than trying to manually figure out the channel mapping. I hope this gets fixed at some point, otherwise I'll keep using my patch.

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: SERIAL_SUM_PPM channel order not working

Post by jevermeister »

Will this have an impact on my working config??so can any dev fix it?
nils

User avatar
phenolic
Posts: 81
Joined: Fri Sep 21, 2012 10:31 pm

Re: SERIAL_SUM_PPM channel order not working

Post by phenolic »

jevermeister wrote:Will this have an impact on my working config??so can any dev fix it?


If you have a working config or otherwise don't know what this is then you don't need it. :)

Most people will not need this considering apparently nobody noticed it doesn't work quite right.

pseddon
Posts: 4
Joined: Tue Dec 04, 2012 5:40 pm

Re: SERIAL_SUM_PPM channel order not working

Post by pseddon »

I am new to multiwii and have come up against the serial channel order problem. Not binge a regular Arduino user, and certainly not a coder, I have a simple question about the suggested patch to sort out the ppm_sum_channel order. What/where should the extra lines go to declare RC_CHANS and rcChannelTemp. Sorry to ask such a basic question.

Peter

User avatar
phenolic
Posts: 81
Joined: Fri Sep 21, 2012 10:31 pm

Re: SERIAL_SUM_PPM channel order not working

Post by phenolic »

pseddon wrote:I am new to multiwii and have come up against the serial channel order problem. Not binge a regular Arduino user, and certainly not a coder, I have a simple question about the suggested patch to sort out the ppm_sum_channel order. What/where should the extra lines go to declare RC_CHANS and rcChannelTemp. Sorry to ask such a basic question.


Which version of MultiWii are you using? I can post a patched RX.ino file. Otherwise copy that chunk of code from my message above to the beginning of the configureReceiver() function in RX.ino. Then add this line to your config.h:

Code: Select all

#define SERIAL_SUM_PPM_FIX 1


Be careful with this, I recommend completely disconnecting your ESC's or otherwise physically disable your motors then test in MultiWiiConf to make sure each channel moves with with the correct stick on your radio.

pseddon
Posts: 4
Joined: Tue Dec 04, 2012 5:40 pm

Re: SERIAL_SUM_PPM channel order not working

Post by pseddon »

I am using 2.1. I have entered the code from your previous email and tried to compile it but it came up with those declaration errors.

Thanks for the warning about testing it - I always remove the props when setting up for the first time.

Peter

User avatar
phenolic
Posts: 81
Joined: Fri Sep 21, 2012 10:31 pm

Re: SERIAL_SUM_PPM channel order not working

Post by phenolic »

pseddon wrote:I am using 2.1. I have entered the code from your previous email and tried to compile it but it came up with those declaration errors.


Edit:
See my post below for the correct patch.
Last edited by phenolic on Tue Dec 04, 2012 7:49 pm, edited 1 time in total.

pseddon
Posts: 4
Joined: Tue Dec 04, 2012 5:40 pm

Re: SERIAL_SUM_PPM channel order not working

Post by pseddon »

It doesn't like it.

Errors as per attached,

Peter
Attachments
multiwii21.jpg

User avatar
phenolic
Posts: 81
Joined: Fri Sep 21, 2012 10:31 pm

Re: SERIAL_SUM_PPM channel order not working

Post by phenolic »

pseddon wrote:It doesn't like it.

Errors as per attached


Oh sorry, I wasn't even compiling it myself because since I don't normally use MW 2.1 I forgot to enable SUM_PPM :oops:

Yeah, MultiWii 2.1 doesn't have that RC_CHANS define.

Here is the improved patch that should work with any MultiWii version:

Code: Select all

  #if defined(SERIAL_SUM_PPM) && defined(SERIAL_SUM_PPM_FIX)
  { // scope to limit memory usage
    uint8_t rcChannelTemp[sizeof(rcChannel) / sizeof(rcChannel[0])];
    for (uint8_t i = 0; i < sizeof(rcChannel) / sizeof(rcChannel[0]); i++)
      rcChannelTemp[rcChannel[i]] = i;

      memcpy((void*)rcChannel, (void*)rcChannelTemp, sizeof(rcChannel));
  }
  #endif // SERIAL_SUM_PPM
Attachments
RX.zip
Patched MultiWii 2.1 RX.info
(8.13 KiB) Downloaded 235 times

pseddon
Posts: 4
Joined: Tue Dec 04, 2012 5:40 pm

Re: SERIAL_SUM_PPM channel order not working

Post by pseddon »

Thanks Phenolic, that seems to have done the trick and the serial ppm stream is finally working correctly.

Peter

User avatar
haydent
Posts: 583
Joined: Sun Jun 17, 2012 1:35 am
Location: NSW, AU

Re: SERIAL_SUM_PPM channel order not working

Post by haydent »

bringing this back to life, im now trying to get ppm working due to lrs rx change. it seems this problem is still existent in 2.3 ! changing channel order does not behave as one would expect...

Post Reply