MW 2.3 sbus problem

Alexinparis · Post by **Alexinparis** » Mon Jan 06, 2014 6:05 pm

Plüschi wrote:I agree for a good solution the char timout is a must have.
But for a quick fix timing change (and ralphs endbyte check) should do.

Considering the difficulty and hostility i experienced introducing small patches for tarduino i'm all about quick fixes now.

Hi,

Believe me, there is no hostility on my side to modify any part of the SBUS code.
what is difficult for me is to have a clear contribution with no side effect given the fact I don't own SBUS and don't plan to.

could you make a diff like this with what you think is the last code ?
viewtopic.php?f=8&t=4425&start=10#p45112

Plüschi · Post by **Plüschi** » Mon Jan 06, 2014 6:58 pm

I am waiting for a confirmation from tofi or anyone having the 9ms receiver that this "latest code"
download/file.php?id=2611
does work glitch free. I only have 11ms and 22ms SBUS receivers.

Btw im too stupid to make diff utility work, and i havent installed svn

tofi · Post by **tofi** » Mon Jan 06, 2014 11:41 pm

@plüschi

I just have a question. Why you just ignore my code proposal, without having a look at it ?
Whats wrong with this code ?

I have started testing your code this evening. It takes some time since I have to integrate your changes in the default MW2.3 code with my configuration. Your code has additional changes in some files which are not relevant to sbus.
I have some problems at the moment, that if ch1 (throttle) goes high , the main loop hangs for some time, but this may be another problem.
More results will follow.

Plüschi · Post by **Plüschi** » Tue Jan 07, 2014 12:29 am

tofi wrote:Whats wrong with this code ?

Nothing wrong. I am convinced it works. Also beautifully written.
It doesent use the existing multiwii serial drivers and buffers. This might be a downer.

I did try to convince you that reading the thing out faster is better than stacking the stuff up in buffers. Like you convinced me the char timeout is necessary. Since there is an existing implementation doing just that (speksat) i did simply adapt the speksat stuff.

Lets collaborate.

-ralf- · Post by **-ralf-** » Tue Jan 07, 2014 3:16 pm

Hi Cesco,

now (first time ever) it works with Orange RX 9CH (12 channels transmitted).
Thanks, good work.

tofi · Post by **tofi** » Tue Jan 07, 2014 7:28 pm

Hello,

seems to work if we have no problems on sbus,

some questions

if get a timeout, the receive buffer is flushed but sbusIndex is not reset.
This means, sbus[] may contain some data and receives the bytes from the new packet till 25.
If then the last byte, which is in the middle of the new sbus frame is also zero,
wrong data is converted.
Also two sbus packets are corrupted.

If the irq flushes the buffer between SerialAvailable() and SerialRead(), does SerialRead return any usefull data ?

Plüschi · Post by **Plüschi** » Tue Jan 07, 2014 8:02 pm

@tofi
Thanks for test. I assume sbus link is 100% trouble free, glitches only happening at startup.

@ralph
Thanks for info. I did test my R800 in 11ms mode and no glitches with old sbus driver.
What is the glitch you see with r920 and old driver?

Here a better way to call sbus / speksat / computerc from the main loop

Code: Select all

............
  #if defined(SPEKTRUM)
    if (spekFrameFlags == 0x01) readSpektrum();
  #endif
  #if defined(SBUS)
    if (spekFrameFlags == 0x01) readSBus();
  #endif

  #if defined(SPEKTRUM) || defined(SBUS)
  if ((spekFrameDone == 0x01) || ((int16_t)(currentTime-rcTime) >0 )) { 
    spekFrameDone = 0x00;
  #else
  if ((int16_t)(currentTime-rcTime) >0 ) { // 50Hz
  #endif
    rcTime = currentTime + 20000; // test
    computeRC();
..........

Obviously spekFrameFlags could be renamed serialRcFrameFlags.

Note we have to do a

Code: Select all

spekFrameDone = 0x01;

in sbus ans speksat driver if valid message is received.

Failsavecode is not affected with my orangerx since they switch to 22ms framerate when in failsave, means the 20ms timeout will trigger. No idea what original futaba or frsky does.

-ralf- · Post by **-ralf-** » Tue Jan 07, 2014 8:11 pm

Cesco,

with old driver there are massive glitches on all channels, when TX transmits more
then 8 channels (TGY 9XR). Transmitting only 8 channels results in a stable S.Bus-readout.

I thought it's rx-related, because R620 runs stable with 12 channels and old driver.

Plüschi · Post by **Plüschi** » Wed Jan 08, 2014 5:20 pm

I have tried to make a diff ...

The spekFrameDone thing is optional

Alexinparis · Post by **Alexinparis** » Thu Jan 09, 2014 11:52 pm

Hi,

inserted in r1648

I hope it's ok

Plüschi · Post by **Plüschi** » Fri Jan 10, 2014 3:15 am

Tested both SBUS ans SpekSat and both seem working fine.

Tank You Alex.

haydent · Post by **haydent** » Sat Feb 15, 2014 9:55 am

Alexinparis wrote:Hi,

inserted in r1648
I hope it's ok

havent flied this, but just in the gui the sbus bit is working with me with a taranis x8r.

note though there are changes in the code since r1648 that make the choice in config.h of a custom SBUS port actually work (other than #1)

thanks everyone

haydent · Post by **haydent** » Mon Feb 17, 2014 2:01 am

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 Feb 17, 2014 9:59 pm

Today i got a Futaba T14SG transmitter with R7008SB receiver. This is FASSTest and not the older FASST. No idea what this name stands for. I think choosing Fastest or Hott as protocol name is retarded.

And ... sbus on MultiWii doesent work with it :cry:

The endbyte is 0x08 instead of the expected 0x00 in 12 channel mode, and the endbyte varies (is not constant) in 14 channel mode. Fuuuu....

I have not found any hints what this endbyte means. My proposition is to not check the endbyte at all. Remove the line 310 in rx.cpp

Code: Select all

      if (sbus[24] != SBUS_ENDBYTE) continue;

and then since the gap between packets is only 3.3ms adapt line 161 in serial.cpp to 2.5ms

Code: Select all

if (spekInterval > 2500) {

and it works fine.

I hooked up my usbee analizer and found there are stopbit errors with the standard settings. SBUS has even parity bit. This has to be set in serial.cpp serialopen(). It does work without parity since nobody watches for stopbit errors but its not "clean". This sets 8bit even parity in serial.cpp, serialopen "mega" ifdef port 1

Code: Select all

UCSR1C  = (1<<UCSZ11)|(1<<UCSZ10)|(1<<UPM01)|(1<<USBS0);

Then, there is a new telemetry capable SBUS2 interface.
http://imgur.com/a/aVAbt

Plüschi · Post by **Plüschi** » Sat Feb 22, 2014 8:31 am

Attached a patch for the new sbus timing of the Fasstest protocol.
Version1 "as is now" disregarding the parity and 2 stopbits as used for sbus. Nobody cares bout parity.
Version2 "UGLY as Hell" respecting parity and 2 stopbits as used for sbus.

I think there should be a cleanup in rx.cpp stuff. It makes no sense defining 12 channels for ppm-sum, and it makes no sense defining 18 channels for sbus. Lets limit ppmsum to 8, and the serial protocols to 12.

Plüschi · Post by **Plüschi** » Thu Feb 27, 2014 1:00 pm

Update:

I have flown the Fasstest SBUS ont T14SG and R7008SB receiver int "12 ch fast" mode last days. I did use baseflight version with parity + 2 stopbits. No problems at all. Flies nicely.

Alexinparis · Post by **Alexinparis** » Sun Mar 02, 2014 4:43 pm

I wouls like, but I can apply this patch like this.
where is defined SUMD ?

ezio · Post by **ezio** » Sun Mar 02, 2014 5:56 pm

does sbus work with Frsky X8R reciever ?

Plüschi · Post by **Plüschi** » Sun Mar 02, 2014 6:23 pm

Yes EZIO that should work. You need a signal inverter.
Like this:
http://abusemark.com/store/index.php?ma ... ucts_id=39
Or this:
http://www.hobbyking.com/hobbyking/stor ... Cable.html

Alex just leave SUMD as is, wont disturb. Later maybe you implement the SUMD receiver too? I did submit a patch somewhere.

-ralf- · Post by **-ralf-** » Sun Mar 02, 2014 6:55 pm

ezio wrote:does sbus work with Frsky X8R reciever ?

Yes, works perfekt ..... or better :lol:

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.

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 169 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