MW 2.3 sbus problem

ezio · Post by **ezio** » Sun Mar 02, 2014 7:29 pm

thanks

It doesn't matter which serial port I connect the receiver to ?

For 16 channels I have to have Taranis

and unfortunately I still use 6 channel radio.

-ralf- · Post by **-ralf-** » Sun Mar 02, 2014 8:57 pm

I use the cheap Turnigy 9XR with FrSky XJT-module .... no problem .....

You can (and have to) specify the serial port in config.h

haydent · Post by **haydent** » Sun Mar 02, 2014 10:41 pm

bringing this back up again, anybody else ? (im using x8r too)

haydent wrote:been playing around with this a little more in gui, and i notice i only get travel from 1090 to 1909 yet without sbus i get 1000-2000

do others get the same ? wordering if this is deliberate, or possibly the signal not being translated accurately ?

Plüschi · Post by **Plüschi** » Mon Mar 03, 2014 3:22 pm

Im sure you can scale SBUS to match exactly 1000 to 2000 for your transmitter. But will it be 1000 to 2000 on my T14SG then? And will it match my Devo12 and orangerx R620? NO it wont. So why worry?

If you want to make a "taranis scaling" version yourself, do it. But i think its nonsense. Up your throws if you really need 1000 to 2000. Or better, as long as its outside 1100 to 1900 DONT MESS.

I would worry about your "1090 to 1909". That is not symmetrical around 1500. There is sometfing wrong here :mrgreen:

haydent · Post by **haydent** » Tue Mar 04, 2014 12:04 am

so currently my settings are on nuetral/default, so you are saying i should just adjust my throw so i get a symetrical swing ?

Plüschi · Post by **Plüschi** » Tue Mar 04, 2014 9:01 am

Up your throws to get ABOUT 1050 to 1950. Dont worry about the rest.

Be aware SBUS already gives you 4 times greater resolution than ppmsum or discrete channels are able to do on multiwii.

haydent · Post by **haydent** » Tue Mar 04, 2014 10:40 am

thanks! ill try that out

Plüschi · Post by **Plüschi** » Sun Mar 09, 2014 2:09 am

I did receive my taranis today and yes, sbus range on the X8R is quite a bit less that ppmsum range on the DR4. Upping throw does fix it nicely. You get finer control with bigger throw, so im totally OK with that.

BUT my center is way off at 1486 instead of 1500. Did you change "#define offset" or did you change the transmitter setting?
OT: does your taranis also scream "telemnetry lost - telemetry recovered" when receiver is near to transmitter? I hate that.

haydent · Post by **haydent** » Sun Mar 09, 2014 4:02 am

i have not tried to adjust mine as discussed yet. i too get telemetry thing you mention. thought it might be related to antenna null point ?

Plüschi · Post by **Plüschi** » Mon Mar 10, 2014 11:57 am

@Alex
Nice idea on where to put the SBUS parity + stopbit init. Thanks for changing the sbus stuff.

wareck · Post by **wareck** » Wed Mar 12, 2014 10:14 am

Hi everyones
I read there that we can use OrangeRx with sbus ?
But I'm searching since two days, and don't find how I must proceed to use it ?

Can someone can helps me ?

Olivier

Plüschi · Post by **Plüschi** » Wed Mar 12, 2014 4:00 pm

Depends if your orangerx has sbus or not. Many do have, even the cheapo R620. You connect the inverter cable to the sbus port and the other end to a serial rx port.

BUT
Dsm2 receivers like the R620 are not very good. Mine DID make lots of dropouts in a plane or copter. Even if such a dropout is only 5 sec long its not really usable. Maybe using a SAT and the R620 for some redundancy makes things a little better. If you can use the DSMX orangerx stuff. I do use this (7 or more channels over sbus):
http://www.hobbyking.com/hobbyking/stor ... sion_.html

superevan · Post by **superevan** » Thu May 01, 2014 7:53 pm

Does anybody know if its possible to feed Sbus in to the MWC but then output any extra channels for things like gimbal pitch/roll, camera switcher, lights, things like that not related to or reliant on MWC?

I have a Corona 7ch Sbus compatible Rx, but when using Sbus I can squeeze all 10 channels out of it. Only problem is I need those last 3 channels for functions not relating to the MWC so I'd need to extract and pass them through the output pins of the MWC if possible. Unless there's a better way to do this.

I'm pretty new to Multiwii and merely have my tricopter in the air. Now I just want to simplify wiring and loose some weight

haydent · Post by **haydent** » Fri May 02, 2014 12:52 am

someone else was asking about this too. im not sure how close it currently is to doing this but its totally possible.

sounds like a good excuse for you to learn the basics of arduino and mwc ?

superevan · Post by **superevan** » Fri May 02, 2014 8:56 pm

haydent wrote:someone else was asking about this too. im not sure how close it currently is to doing this but its totally possible.

sounds like a good excuse for you to learn the basics of arduino and mwc ?

You know, you're right. I guess it's time for some tutorials!

JohnB · Post by **JohnB** » Mon Jun 09, 2014 8:02 pm

Plüschi wrote:I did receive my taranis today and yes, sbus range on the X8R is quite a bit less that ppmsum range on the DR4. Upping throw does fix it nicely. You get finer control with bigger throw, so im totally OK with that.

BUT my center is way off at 1486 instead of 1500. Did you change "#define offset" or did you change the transmitter setting?
OT: does your taranis also scream "telemnetry lost - telemetry recovered" when receiver is near to transmitter? I hate that.

I have found that both Taranis and Futaba do not have SBUS data that matches the actual transmit pulse width. The SBUS data value is 75% of the actual pulse width (captured data on a logic analyzer and manually decoded it). I discovered this working on the Open FlightStab airplane firmware (RCGroups) for the Orange RX3S.

I am now playing with some Quads using MultiWii 2.3 and I see the same issue I had to fix in Open FlightStab.

My solution was to add some code at the end of the readSBus routine after the comment //jrb SBUS adjust

Code: Select all

void  readSBus(){
  #define SBUS_SYNCBYTE 0x0F // Not 100% sure: at the beginning of coding it was 0xF0 !!!
  static uint16_t sbus[25]={0};
  
  while(SerialAvailable(1)){
    int val = SerialRead(1);
    if(sbusIndex==0 && val != SBUS_SYNCBYTE)
      continue;
    sbus[sbusIndex++] = val;
    if(sbusIndex==25){
      sbusIndex=0;
      rcValue[0]  = ((sbus[1]|sbus[2]<< 8) & 0x07FF)/2+SBUS_MID_OFFSET;
      rcValue[1]  = ((sbus[2]>>3|sbus[3]<<5) & 0x07FF)/2+SBUS_MID_OFFSET; 
      rcValue[2]  = ((sbus[3]>>6|sbus[4]<<2|sbus[5]<<10) & 0x07FF)/2+SBUS_MID_OFFSET; 
      rcValue[3]  = ((sbus[5]>>1|sbus[6]<<7) & 0x07FF)/2+SBUS_MID_OFFSET; 
      rcValue[4]  = ((sbus[6]>>4|sbus[7]<<4) & 0x07FF)/2+SBUS_MID_OFFSET; 
      rcValue[5]  = ((sbus[7]>>7|sbus[8]<<1|sbus[9]<<9) & 0x07FF)/2+SBUS_MID_OFFSET;
      rcValue[6]  = ((sbus[9]>>2|sbus[10]<<6) & 0x07FF)/2+SBUS_MID_OFFSET; 
      rcValue[7]  = ((sbus[10]>>5|sbus[11]<<3) & 0x07FF)/2+SBUS_MID_OFFSET; // & the other 8 + 2 channels if you need them
      //The following lines: If you need more than 8 channels, max 16 analog + 2 digital. Must comment the not needed channels!
      rcValue[8]  = ((sbus[12]|sbus[13]<< 8) & 0x07FF)/2+SBUS_MID_OFFSET; 
      rcValue[9]  = ((sbus[13]>>3|sbus[14]<<5) & 0x07FF)/2+SBUS_MID_OFFSET; 
      rcValue[10] = ((sbus[14]>>6|sbus[15]<<2|sbus[16]<<10) & 0x07FF)/2+SBUS_MID_OFFSET; 
      rcValue[11] = ((sbus[16]>>1|sbus[17]<<7) & 0x07FF)/2+SBUS_MID_OFFSET; 
      rcValue[12] = ((sbus[17]>>4|sbus[18]<<4) & 0x07FF)/2+SBUS_MID_OFFSET; 
      rcValue[13] = ((sbus[18]>>7|sbus[19]<<1|sbus[20]<<9) & 0x07FF)/2+SBUS_MID_OFFSET; 
      rcValue[14] = ((sbus[20]>>2|sbus[21]<<6) & 0x07FF)/2+SBUS_MID_OFFSET; 
      rcValue[15] = ((sbus[21]>>5|sbus[22]<<3) & 0x07FF)/2+SBUS_MID_OFFSET; 
      // now the two Digital-Channels
      if ((sbus[23]) & 0x0001)       rcValue[16] = 2000; else rcValue[16] = 1000;
      if ((sbus[23] >> 1) & 0x0001)  rcValue[17] = 2000; else rcValue[17] = 1000;

      // Failsafe: there is one Bit in the SBUS-protocol (Byte 25, Bit 4) whitch is the failsafe-indicator-bit
      #if defined(FAILSAFE)
      if (!((sbus[23] >> 3) & 0x0001))
        {if(failsafeCnt > 20) failsafeCnt -= 20; else failsafeCnt = 0;}   // clear FailSafe counter
      #endif
      
      //jrb SBUS adjust
       // For some reason the SBUS data provides only about 75% of the actual RX output pulse width
       // Adjust the actual value by +/-25%.  Sign determined by pulse width above or below center
       uint8_t adj_index;
       for(adj_index=0; adj_index<16; adj_index++)
       {
          if (rcValue[adj_index] < MIDRC)
            rcValue[adj_index] -= (MIDRC - rcValue[adj_index]) >> 2;      
          else   
            rcValue[adj_index] += (rcValue[adj_index] - MIDRC) >> 2;
       }               
     }
  }        
}

The loop is hard coded to do 16 channels. I am new to MultiWii and did not find a define for the number of supported channels so I hard coded it to 16. If the is a "number of channels" define, it should be used instead of the hard coded 16.

When using this modification the pulse width I measure at the receiver Outputs (FrSky X8R and Futaba R6208SB) on my scope (Tektronix MDO4054-6) matches the pulse widths displayed in the MultiWiiConf GUI as it should.

I am now able to Arm/Disarm the motors with the rudder stick without doing strange things in the Taranis to increase the pulse width range.

I also noticed that the frames are Even Parity with 2 stop bits. I see that has already been fixed using your patch.

John

PS - I am using SBUS_MID_OFFSET 1006 for the Taranis

haydent · Post by **haydent** » Tue Jun 10, 2014 5:11 am

thank you very much or your detailed investigation and submission. I hope this can be integrated as promptly as possible.

edit, and i noticed you signed up just to post this, double thanks !!! and welcome

JohnB · Post by **JohnB** » Tue Jun 10, 2014 9:41 pm

Happy to help.

John

haydent wrote:thank you very much or your detailed investigation and submission. I hope this can be integrated as promptly as possible.

edit, and i noticed you signed up just to post this, double thanks !!! and welcome

haydent · Post by **haydent** » Sat Jun 21, 2014 9:09 am

haydent wrote:bringing this back up again, anybody else ? (im using x8r too)

haydent wrote:been playing around with this a little more in gui, and i notice i only get travel from 1090 to 1909 yet without sbus i get 1000-2000

do others get the same ? wordering if this is deliberate, or possibly the signal not being translated accurately ?

JohnB wrote:Happy to help.
John

with your new code John, i now get perfect full swing from 1000 to 2000 !
http://www.multiwii.com/forum/viewtopic.php?f=8&t=4425&p=52458#p52004

thanks again, i will try and help to get this merged.

JohnB · Post by **JohnB** » Mon Jul 07, 2014 6:45 pm

-ralf- wrote:
Yes, works perfekt ..... or better

Bind the X8R as second receiver ..... and you can use channel 9 to 16 direkt at
the receiver and channel 1 to 8 via s.bus.

Has anyone done this successfully with 16 channels of SBUS data.

I have a Taranis setup to send 16 channels of data to an X8R receiver configured to output channels 9-16 on the servo connectors. The plan was to use the first 8 channels with MultiWii and the second 8 channels as normal servo outputs.

When this is done, a very strange thing happens. The channel display in the GUI changes, it appears that the first three channels are no longer used and everything is moved by 3 channels. It appears that for some reason the channels are being remapped.

The TX is setup with the following channel order:
1 - Throttle
2 - Aileron
3 - Elevator
4 - Rudder
5 - AUX1
6 - AUX2
7 - AUX3
8 - AUX4

The only place I see any channel mapping is in rx.cpp around line 31. The mapping does not match what my TX is sending, but in 8 channel mode everything works fine. I have verified my channel order with a logic analyzer.

I have a logic analyzer connected to the SBUS output of the receiver and the only thing different between 8 channel and 16 channel operation is that the last 8 channels now contain valid data instead of all zeros. I could not find anyplace in MultiWii where the data fror channels 9-16 was actually used, but just in case I modified the the code in rx.cpp to force the last 8 channels to be 988 (default SBUS offset). That did not alter the problem.

Something is going on with MultiWii to force this funny operation but I have no idea what.

This same thing happens on 2 different systems using the same model transmitter, receiver and Flight Controller.

The flight controller being used is ATMega 2560 based and can be seen here:
http://witespyquad.gostorego.com/flight-controllers/multiwii-pro-ez3-0-black-flight-controller-w-gps-option-276.html

I have attached 3 screen shots that will help display the problem. Ignore the difference between the GPS and the MAG settings. I cleared the EEPROM just in case some data from old versions of the firmware left some junk. I have not calibrated the MAG since the clear (too many cables and scope probes connected to rotate the Quad on all three axis). I have the same problem when the MAG is calibrated.

The first screen shot shows the output of the GUI with only the RX and FC powered on. This allows us to to see the default setting from the FC when no SBUS data is present.

: TX Off, all modes cleared in MultiWii

This screen shot shows the output of the GUI after the TX has been turned on and the RX is sending SBUS data. All outputs are correct and follow the stick movements as they should.

: TX Powered On

This screen shows what happens once a mode has been selected. In this case I forced Angle mode. The mode selected does not matter, almost anything that is selected will cause the problem. Note that the first 3 channels have been forced to 1000. The throttle is now on the YAW channel, Aileron on AUX 1, Elevator on AUX2 and Rudder on AUX3. Also note that the values are not correct for AUX1, AUX2 & AUX 3, they should be around 1500 but they are not. The values will change as the sticks are moved but do not have the full range of travel.

When the TX is set to only send 8 channels, everything is back to normal.

: TX On, Angle Mode Forced

Any thoughts?

John

UPDATE
Taranis will allow any number of channels up to 16. I found that all values work except for 15 and 16. The unused channels will be set to 0 (by the X8R SBUS generator) and then have the SBUS_MID_OFFSET value added (1006 in my case) before being placed into rcValue[chan]. Still not clear to me why a value > 1006 in rcValue[14] and/or rcValue[15] breaks things.

No longer a big issue as only 9 channels are currently need, but it makes you wonder.

Plüschi · Post by **Plüschi** » Mon Jul 21, 2014 6:32 pm

JohnB why dont you put that into a simpler format without the if ?

example (untested, but you will get the idea, and SBUS_OFFSET must be made smaller):

Code: Select all

      uint16_t val;
      val = (sbus[1]|sbus[2]<< 8) & 0x07FF;
      rcValue[0] = (val >> 1) + (val >> 3) + SBUS_OFFSET;
      val = (sbus[2]>>3|sbus[3]<<5) & 0x07FF;
      rcValue[1] = (val >> 1) + (val >> 3) + SBUS_OFFSET;
      val = (sbus[3]>>6|sbus[4]<<2|sbus[5]<<10) & 0x07FF;
      rcValue[2] = (val >> 1) + (val >> 3) + SBUS_OFFSET;
      val = (sbus[5]>>1|sbus[6]<<7) & 0x07FF;
      rcValue[3] = (val >> 1) + (val >> 3) + SBUS_OFFSET;
      val = (sbus[6]>>4|sbus[7]<<4) & 0x07FF;
      rcValue[4] = (val >> 1) + (val >> 3) + SBUS_OFFSET;
      val = (sbus[7]>>7|sbus[8]<<1|sbus[9]<<9) & 0x07FF;
      rcValue[5] = (val >> 1) + (val >> 3) + SBUS_OFFSET;
      val = (sbus[9]>>2|sbus[10]<<6) & 0x07FF;
      rcValue[6] = (val >> 1) + (val >> 3) + SBUS_OFFSET;
      val = (sbus[10]>>5|sbus[11]<<3) & 0x07FF;
      rcValue[7] = (val >> 1) + (val >> 3) + SBUS_OFFSET;

And same thing for spektrum?

Then bug alex a lot ... the idea is good

JohnB · Post by **JohnB** » Tue Jul 22, 2014 12:27 am

Plüschi wrote:JohnB why dont you put that into a simpler format without the if ?

I tried to make the fix easy to add without modifying the existing code, just adding new code. It is not clear to me that your code will work as it is necessary to make all values below the center position smaller and all values above the center position larger.

Plüschi wrote:And same thing for spektrum?

Then bug alex a lot ... the idea is good

No changed required for Spektrum. The transmitted data is not being scaled in the receiver so all is well.

Futuba requires that the transmitted S.BUS data be scaled for some reason - maybe to be compatible with the servo hardware. Since we are not driving servos and using the value as a count in microseconds, it is necessary to remove the scaling.

John

Plüschi · Post by **Plüschi** » Tue Jul 22, 2014 12:33 pm

JohnB wrote:It is not clear to me that your code will work

Sbus values are from 0 to 2000 OR 0 to 2048 , cant remember.

Sbus total range is 0 to 2000.
Sbus useful range is 200 to 1800.
New SbusOffset will be 875
Calculation: sbus/2 + sbus/8 + offset = servo value
Low pos = 200 -> 100 + 25 + 875 = 1000 us
Mid pos = 1000 -> 500 + 125 + 875 = 1500 us
High pos = 1800 -> 900 + 225 + 875 = 2000 us

Sbus total range is 0 to 2048.
Sbus useful range is 224 to 1824.
New SbusOffset will be 860
Calculation: sbus/2 + sbus/8 + offset = servo value
Low pos = 224 -> 112 + 28 + 860 = 1000 us
Mid pos = 1024 -> 512 + 128 + 860 = 1500 us
High pos = 1824 -> 912 + 228 + 860 = 2000 us

JohnB wrote:No changed required for Spektrum.

Speksat has the same issue needing 125% throws.

JohnB · Post by **JohnB** » Tue Jul 22, 2014 4:15 pm

I had not noticed that you were changing the SBUS_MID_OFFSET value. Doing that will allow all modifications to be additions.

I still prefer to have the scaling completely independent from the primary calculations, this allows the scaling code to be surrounded with #if defined (ZZZ) and #endif and setting ZZZ in config.h to enable/disable scaling.

Spektrum data is not scaled, it is coming right out of the RF stage of the receiver before the decoder. The data you read is the actual transmitted data packets.

Spektrum defaults all travel limits to 100% but to make the travel comparable to other systems, the limits must be set to 125%. DX8 systems and higher (not sure about DX7) allow the travel to be set as high 150%.

These are the pulse width measurements taken directly (Tektronix MDO4054-6 scope) from the aileron output of an AR8000 RX receiving data from a DX8 transmitter.

Travel, Minimum, Maximum
100%, 1120us, 1895us
125%, 1989us, 1025us
150%, 930us, 2088us

S.BUS values do not come directly from the RF section of the RX, they come out of the S.BUS signal generator in the decoder section of the RX. It is the S.BUS signal generator that is doing the scaling as it serializes the transmitted data.

I discovered all of this while working on the firmware for Open FlightStab (I did the Spektrum and S.BUS support). I was testing with FrSky X8R and Orange R800X receivers (both of which do standard single PPM and S.BUS). Both system were setup to generate pulse widths in the 1000us to 2000us range. I had tested both of these system in standard single PPM per channel mode. When I started to debug the S.BUS code I noticed all of my input pulses were not the same with as they were in single PPM mode.

I assumed that there was a design error in the S.BUS logic as I could capture the S.BUS data on a logic analyzer and the counts did not match the transmitted data. I sent a not to FrSky and they replied that their design followed the Futaba specifications (which I do not have). I then purchase a Futaba 14 channel T8FG and R6208SB and found, that indeed, the S.BUS data did not match the TX data. That is when I added the scaling function to OFS. When I started playing with a Multi Rotor using MultiWii and saw the same issue so I added the scaling routine to rx.cpp.

John

Plüschi wrote:
JohnB wrote:It is not clear to me that your code will work

Sbus values are from 0 to 2000 OR 0 to 2048 , cant remember.

Sbus total range is 0 to 2000.
Sbus useful range is 200 to 1800.
New SbusOffset will be 875
Calculation: sbus/2 + sbus/8 + offset = servo value
Low pos = 200 -> 100 + 25 + 875 = 1000 us
Mid pos = 1000 -> 500 + 125 + 875 = 1500 us
High pos = 1800 -> 900 + 225 + 875 = 2000 us

Sbus total range is 0 to 2048.
Sbus useful range is 224 to 1824.
New SbusOffset will be 860
Calculation: sbus/2 + sbus/8 + offset = servo value
Low pos = 224 -> 112 + 28 + 860 = 1000 us
Mid pos = 1024 -> 512 + 128 + 860 = 1500 us
High pos = 1824 -> 912 + 228 + 860 = 2000 us

JohnB wrote:No changed required for Spektrum.

Speksat has the same issue needing 125% throws.

Plüschi · Post by **Plüschi** » Tue Jul 22, 2014 6:22 pm

I did notice a lot of new people have trouble upping the throw on their transmitter. Speksat - microquad forums are full of "it wont arm" because throws are to small (pocketquad forum on rcgroups). To make it easier your thing without multiplication would be a "nice to have" as default for speksat, moving away one roadblock for new mwii users. Pro users could then #undefine XXX and get the full resolution.

I did not know about the sbus thing. Weird. I have a R800X (i use the OrangeRx DSMX 3Ch S.BUS) and a R7008SB (T14SG) but failed to notice the difference. Basically we need different scaling for futabe / frsky and orangerx, is that right?

JohnB · Post by **JohnB** » Tue Jul 22, 2014 8:00 pm

@Plüschi

The manufactures percentage values are not standard, each one does as they see fit. It is a shame that they don't use pulse width (in microseconds) instead of a percentage.

I do my testing with Spektrum (DX8 & DX18 and an assortment of Spektrum RX's), Orange Receivers, Futaba (T8FG with R6208SB) and FrSky (Taranis and X8R). The Taranis is the only transmitter I have that allows me to see pulse width in microseconds in addition a percentage. If I other transmitters I own have the capability to display pulse width in microseconds, I have not found the proper menu yet (entirely possible).

John

haydent · Post by **haydent** » Wed Jul 23, 2014 1:21 am

this is great you can understand each other, when we get it worked out, i have another member with commit access who can add it to mw shared.

Plüschi · Post by **Plüschi** » Thu Jul 24, 2014 11:36 am

My stuff is attached. I am not too happy about the fixed scaling increment.
A better sbus system involving packed records (let the compiler figure out the bit shifts) can be copied from baseflight. No speed increase but .. its beautiful

JohnB · Post by **JohnB** » Thu Jul 24, 2014 10:22 pm

My goal in proposing this change for SBUS pulse width scaling was to have the pulse widths decoded by MultiWii match the transmitted pulse widths and the pulse widths measured at the receiver servo outputs.

Since the scaling performed by the SBUS generator in the receiver is fixed, I see not need to have variable scaling.

I also don't see any need to modify the Spektrum path as the pulse widths being decoded by MultiWii already match the transmitted pulse widths and the pulse widths measured at the receiver servo outputs.

I have added a #define to config.h to enable/disable the SBUS scaling. See attached zip file.

John

JRB Proposed SBUS changes.zip: (1.64 KiB) Downloaded 253 times

Alexinparis · Post by **Alexinparis** » Mon Jul 28, 2014 11:19 pm

So what is the consensus ?
Plüschi : are you convinced spektrum does not need this because the scaling here is not at the same place ?
JohnB: I don't see any reason to make it optional via #define

JohnB · Post by **JohnB** » Mon Jul 28, 2014 11:37 pm

It is a minimal change to make it optional (3 lines of code - 1 in config.h and 2 in rx.cpp). It makes no difference to me, I always use it with S.BUS.

The only reason to make it optional is for people that are already using S.BUS with the current MW 2.3 code and have adjusted TX travel limits to compensate for the scaling. If the default is set to not include scaling then they will never notice a change with a newer version of MW.

I found this issue while adding S.Bus and Spektrum support to Open FlightStab on RCGroups. I measured both Spektrum and S.BUS on a scope comparing the software decoded values with the actual RX servo output values measuring with a Tektronix MDO4054-6 scope. Spektrum matches without change, S.Bus requires scaling. Open FlightStab currently incorporates the S.Bus scaling as does the version of MultiWii 2.3 that I use on my Quad.

John

Alexinparis wrote:So what is the consensus ?
Plüschi : are you convinced spektrum does not need this because the scaling here is not at the same place ?
JohnB: I don't see any reason to make it optional via #define

Plüschi · Post by **Plüschi** » Tue Jul 29, 2014 12:05 am

I think consensus is "do it for sbus".
I also say "do it for speksat", while john says "dont do for speksat".

Resoning behind doing that for speksat is the copter will NOT arm if you dont UP the throws, whis IS a problem for newbies. Same as for SBUS.

@John
> Spektrum ... the pulse widths being decoded by MultiWii already match the transmitted pulse widths

How can you know this if the transmitter does not tell you the " transmitted pulse width" ?
I remember back in ver 2.2 days GregEgan already used spek scaling in his pocketquad fork. There must be a reason.

JohnB · Post by **JohnB** » Tue Jul 29, 2014 12:22 am

The reason people have problem with Spektrum is because the default travels in the TX are 100%. To get normal travel found in other vendor systems from a Spektrum TX, travel must be set to 125%.

The Spektrum RX is not doing anything to scale TX values, the TX is just not setup properly.

If you scale the Spektrum and the user sets the TX to 150% travel, a large part of the stick range will be lost because MW, by default, limits the pulse range to 1000us - 2000us.

If there is a desire to scale Spektrum, that is OK with me. I just don't think it is needed.

I don't fly with Spektrum Serial because the Satellites RX were never designed for primary RX operation. In fact some of the TX data is not received by the Satellites, it is only seen by the primary. In additions Spektrum serial does not have any fail safe, if you use Spektrum it is important to enable Fail safe in MultiWii.

I do fly with Spektrum TX's (both DX8 and DX18) in addition to a Taranis. When I use my Spekrum TX's, I use OrangeRX R800x receivers with SBUS. I only use the Spektrum Satellites for testing my firmware to make sure it works - never flew with one.

John

Plüschi wrote:I think consensus is "do it for sbus".
I also say "do it for speksat", while john says "dont do for speksat".

Resoning behind doing that for speksat is the copter will NOT arm if you dont UP the throws, whis IS a problem for newbies. Same as for SBUS.

JohnB · Post by **JohnB** » Tue Jul 29, 2014 12:52 am

Plüschi wrote:I think consensus is "do it for sbus".
I

I agree with that statement.

I don't really care how it is implemented or if Spektrum is scaled or not. We need it for S.Bus.

John

haydent · Post by **haydent** » Tue Jul 29, 2014 7:19 am

i can see the need for both, but personally only need sbus as well. how about 2 seperate patches with seperate config options in their respective rx sections ?

JohnB · Post by **JohnB** » Tue Jul 29, 2014 1:00 pm

Plüschi wrote:@John
> Spektrum ... the pulse widths being decoded by MultiWii already match the transmitted pulse widths

How can you know this if the transmitter does not tell you the " transmitted pulse width" ?
I remember back in ver 2.2 days GregEgan already used spek scaling in his pocketquad fork. There must be a reason.

The normal user cannot tell. I have captured the data between the RF section of the receiver and the decoder section with a logic analyzer and manually decoded them. (This is almost the same as the data found on the Satellite signal wire except that it contains additional data including resolution [1024/2048]). When you are looking at the data stream coming out of the RF section you are looking at the data from the transmitted packets.

The pulse widths out of the RX servo connectors match the serial data from the RF section. No scaling is done in the receiver decoder section.

You can verify this by connecting a scope to the trainer jack on the back of the Transmitter. The signal there is CPPM and you can measure the times between the leading edges of the negative pulses. The Spektrum CPPM order is Throttle, Aileron, Elevator, Rudder, Gear, Flaps or Aileron 2.

I can't think of a good reason why one would scale the Spektrum data.

John

JohnB · Post by **JohnB** » Tue Jul 29, 2014 1:10 pm

My last attachment provides what you desire for S.BUS. The code provided (without the conditional to include it) is what I use in my version of MultiWii 2.3 and Open FlightStab distributions since March 2014.

There are many ways to implement the scaling and if a different implementation is found to be a better solution, that is fine with me. Let's just get it done.

Plüschi will have to provide the changes he thinks best for Spektrum.

John

haydent wrote:i can see the need for both, but personally only need sbus as well. how about 2 seperate patches with seperate config options in their respective rx sections ?

haydent · Post by **haydent** » Wed Jul 30, 2014 12:24 am

thanks John, your thoroughness is great !

haydent · Post by **haydent** » Fri Aug 01, 2014 12:27 pm

Tested out your sbus code again John and seems fine still. I have corrected an unrelated sbus + lcd conf bug.

Configuration via lcd has its own loop while viewing separate to everything else. Problem is it was not reading sbus data as part of that, only spektrum and standard. Therefore once inside the menu, no stick input is recognised.

:idea:

This Fix corrects that.

RX.cpp replace readRawRC function with the following

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;
  #elif defined(SBUS)
    readSBus();
    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
}

LCD.cpp
change:

Code: Select all

#if defined(SPEKTRUM)
      readRawRC(1); delay(44); // For digital receivers like Spektrum, SBUS, and Serial, to ensure that an "old" frame does not cause immediate exit at startup. 
    #endif

To:

Code: Select all

    #if defined(SPEKTRUM) || defined(SBUS)
      readRawRC(1); delay(44); // For digital receivers like Spektrum, SBUS, and Serial, to ensure that an "old" frame does not cause immediate exit at startup. 
    #endif

( Also there is another bug which i have not looked into that if you page through the telemetry screens fast it will lock up the rx component and stop decoding the sbus correctly )

JohnB · Post by **JohnB** » Fri Aug 01, 2014 5:31 pm

haydent wrote:Tested out your sbus code again John and seems fine still. I have corrected an unrelated sbus + lcd conf bug.

Do you have the ability to test sbus with 15 or 16 channels? There is some sort of problem doing that with the current firmware, see my previous post. I tried it with the original 2.3 release code and the problem did not exist there.

No problems detected with 14 channels or less. I don't think this will bother many people but I am curious if this problem is unique to me using a Taranis and X8R.

John

haydent · Post by **haydent** » Sat Aug 02, 2014 12:50 am

yes i have taranis/x8r and rigol dso if needed. ill have a go, never tried > 8

haydent · Post by **haydent** » Sat Aug 02, 2014 1:56 am

JohnB wrote:
haydent wrote:Tested out your sbus code again John and seems fine still. I have corrected an unrelated sbus + lcd conf bug.

Do you have the ability to test sbus with 15 or 16 channels? There is some sort of problem doing that with the current firmware, see my previous post. I tried it with the original 2.3 release code and the problem did not exist there.

No problems detected with 14 channels or less. I don't think this will bother many people but I am curious if this problem is unique to me using a Taranis and X8R.

John

so how do i test 16 channels in MW when the gui only shows 8 ? or did you have some other method in mind ?

JohnB · Post by **JohnB** » Sat Aug 02, 2014 1:57 am

That's what I tested with. If I set the Taranis to 15 or 16 channels the channels change order in the GUI. Anything less than 15 channels works fine.

John

haydent wrote:yes i have taranis/x8r and rigol dso if needed. ill have a go, never tried > 8

haydent · Post by **haydent** » Sat Aug 02, 2014 1:59 am

so how do i test 16 channels in MW when the gui only shows 8 ? or did you have some other method in mind ?

Plüschi · Post by **Plüschi** » Sat Aug 02, 2014 3:42 pm

Code: Select all


debug[0] = rcValue[12];
debug[1] = rcValue[13];
debug[2] = rcValue[14];
debug[3] = rcValue[15];

JohnB · Post by **JohnB** » Sat Aug 02, 2014 4:09 pm

haydent wrote:so how do i test 16 channels in MW when the gui only shows 8 ? or did you have some other method in mind ?

The failure can be seen in the GUI. Something is happening to the decode of the sbus channels. Channel 1 is moving to channel 3, channel 2 is moving to channel 4 etc. The good news is this was found with ground testing. This would have been a disaster in the air.

A user posted the problem on another forum. He wanted to use channel 9 (channel 1 on his X8R after binding for channels 9-16) to control something on his quad. When he did the bind the Taranis was configured for 16 channel transmit.

After doing this he noticed all of the channels in the GUI moved by 2, throttle became pitch etc.

This is the link to his original post http://www.rcgroups.com/forums/showthread.php?t=1874276&page=324#post28775542

I was able to duplicate the problem but is was not obvious to me what was going on. I looked at the sbus data coming out of the X8R and it was correct and the frame rate was always 9ms for every different number of Taranis transmitted channels, it is not a TX or RX problem the best I can tell. I described what I saw a few posts above this one, this is the link to that post
http://www.multiwii.com/forum/viewtopic.php?f=8&t=4425&view=unread&sid=bc87a2843794301fb6a0e9d569edec14#p53090

I duplicated it again today only this time the setting of option switches made no difference at all. When the receiver was turned on and the GUI connected the channel data was correct for a few seconds then as soon as all of the firmware initialization was completed, the channels jumped to the wrong positions.

I tested with Taranis configuration from 9 to 16 channels, all worked except for 15 and 16.

Since the original poster only needed 9 channels he set the Taranis to 9 and everything worked without incident.

Try the firmware you normally use on one of your boards and see if it fails. Don't spend a lot of time on this, just see if it fails.

I have also tested on an HK MultiWii & MegaPirate AIO board with the MultiWii original Jan 9,2014 release with the only changes being in config.h and my scaling code added to rx.cpp. I cannot make this board fail with 15 or 16 channels transmitted.

While gathering the above information for you I noticed that the source code being used for the Blacked Mag board (the one that has the failure) is older MultiWii code, all of the files are dated Dec 2, 2013. The source being used for the HK board has files dated as new as Jan 9,2014. This could be an old bug that has been since been fixed. More research required.

John

Alexinparis · Post by **Alexinparis** » Sat Aug 02, 2014 10:31 pm

Hi,

I've just committed the mod suggested by JohnB.
With no option (permanent mod)
I think current SBUS users will have to look carefully at the change mod in next version.

From what I understand, I see no reason to make post scale treatment on spektrum system.
The fact users have to increase the travel range in the tx to reach [1000-2000] us is common for every system and spektrum is in the same case as standard or ppm rx on this point.

haydent · Post by **haydent** » Sun Aug 03, 2014 1:11 am

Alexinparis wrote:Hi,

I've just committed the mod suggested by JohnB.
With no option (permanent mod)
I think current SBUS users will have to look carefully at the change mod in next version.

From what I understand, I see no reason to make post scale treatment on spektrum system.
The fact users have to increase the travel range in the tx to reach [1000-2000] us is common for every system and spektrum is in the same case as standard or ppm rx on this point.

Thanks Alex ! can you commit this fix too: viewtopic.php?f=8&t=4425&p=54178#p54127 (posted above, it seems sbus has never worked with lcd config)

haydent · Post by **haydent** » Sun Aug 03, 2014 2:24 am

Plüschi wrote:

Code: Select all


debug[0] = rcValue[12];
debug[1] = rcValue[13];
debug[2] = rcValue[14];
debug[3] = rcValue[15];

just wondering if there was a native way already i had not noticed. thanks. i made a modified version of the gui that shows all 16 channels:
http://dev.httech.com.au/download/Multi ... hannel.zip

haydent · Post by **haydent** » Sun Aug 03, 2014 2:36 am

JohnB wrote:
The failure can be seen in the GUI. Something is happening to the decode of the sbus channels. Channel 1 is moving to channel 3, channel 2 is moving to channel 4 etc. The good news is this was found with ground testing. This would have been a disaster in the air.

John

i had no problem, i copied my aileron channel to all channels 5-16 and had them all working at once fine