MW 2.3 sbus problem

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
tofi
Posts: 8
Joined: Sun Sep 29, 2013 2:37 pm

MW 2.3 sbus problem

Post by tofi »

Hello,

I used MW2.2 with futaba sbus without problems last year.
I run now into problems with sbus and FRSKY new X8R Sbus receiver.
The main difference between FRSKY and Futaba is that FRSKY has a frame rate of
9ms on SBUS (Futaba 14ms).

Also on the Taranis Transmitter, unused channels are set to 0%, this is a SBUS channel value of
decimal 992, which produces constant additional sync bytes.

The main problem in MW is:
MW2.3 does not reset the sbus byte counter to zero, when there is a timeout between received bytes.
Synchronization should be done with character timeout.
I think it was just luck, that there were no constant sync bytes with futaba sbus and sbus worked till now.


I have monitored the sbus with a pc tool which also decodes the sbus channel.

----------------
channel 7 and 15 not set to 0%

rxchan<0990 0990 0172 0992 0172 0172 0172 0992 0992 0992 0992 0992 0992 0992 0000 0992
rxsbus<0f de f3 1e 2b c0 c7 0a 56 b0 02 7c e0 03 1f f8 c0 07 3e f0 01 00 7c 00 00

result: rc channels stable in gui
only Byte 0 on sbus is sync byte.

------------------
channel 7 set to 0%
additional sync byte at BYTE 10

rxchan<0990 0990 0258 0990 0172 0172 0992 0992 0992 0992 0992 0992 0992 0992 0000 0992
rxsbus<0f de f3 9e 40 bc c7 0a 56 80 0f 7c e0 03 1f f8 c0 07 3e f0 01 00 7c 00 00

result : rc channels toggle wild in gui


-------------------
channel 15 set to 0%
additional sync byte at BYTE 21

rxchan<0990 0992 0258 0990 0172 0172 0172 0992 0992 0992 0992 0992 0992 0992 0992 0992
rxsbus<0f de 03 9f 40 bc c7 0a 56 b0 02 7c e0 03 1f f8 c0 07 3e f0 81 0f 7c 00 00

result : rc channels toggle wild in gui

I have added debug[3]++ to serial receive interrupt

if (h == serialTailRX[portnum]) {
debug[3]++;
return; // we did not bite our own tail?
}

and have seen that with a frame rate of 9ms the rxbuffer overflows.
I increased Rxbuffer to 128bytes, I got no more buffer overruns,
however it was still possible that the readSbus() function simply synchronized
to the wrong sync byte. This wrong synchronisation was then also stable, it just depended on when receive was started.

I have modified MW2.3 in a way that I made two new files sbus.cpp and sbus.h and put inside
this file a new interrupt routine which handles sbus receive.
I think a circular buffer is not optimal, so I decided to use two rx buffers in ping-pong technique.
Interrupt routine receives in one buffer, while one stable buffer is ready to be read from
function sbusRead().

I' ve made this correction for my Nanowii board, perhaps somebody can have a look at the sbus
receive function.
I did not yet tested my code in flight.

Best regards
T.Fischer
Attachments
sbus.zip
(30.8 KiB) Downloaded 232 times

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

Re: MW 2.3 sbus problem

Post by haydent »

this sounds like you got your head into the problem well. i have this rx too and will test your code with it. thanks for posting !

also are you using / do you need the inverter device mentioned in config.h ?

Code: Select all

    /*******************************    SBUS RECIVER    ************************************/
      /* The following line apply only for Futaba S-Bus Receiver on MEGA boards at RX1 only (Serial 1) or PROMICRO boards.
         You have to invert the S-Bus-Serial Signal e.g. with a Hex-Inverter like IC SN74 LS 04 */
      //#define SBUS
      //#define SBUS_SERIAL_PORT 1
      #define SBUS_MID_OFFSET 988 //SBUS Mid-Point at 1500

tofi
Posts: 8
Joined: Sun Sep 29, 2013 2:37 pm

Re: MW 2.3 sbus problem

Post by tofi »

Yes, I use an external transistor as Inverter.

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

Re: MW 2.3 sbus problem

Post by haydent »

thanks, even though easy to make, i have ordered a sbus inverter to try this with

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: MW 2.3 sbus problem

Post by Plüschi »

The problem is the routine computeRC() handles SBUS and is called only every 20ms. Obviously with 9ms repetition we have a problem. Solution would be to handle SBUS like SPEKSAT. The procedure readSpektrum() is called every 3ms and that is the way to go for SBUS as well. Call readSbus() every loop and make computeRC() only copy the stuff.

Instead of copy data at fixed 20ms it would be better to copy data when data arrives. So we would get rcdata refreshed at 9ms (or whatever the RX cab do) instead of fixed unsynced 20ms. The example how to do this correctly can be found in baseflight.

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

Re: MW 2.3 sbus problem

Post by haydent »

Thanks for your input. It makes sense

Mauronic
Posts: 1
Joined: Tue Dec 31, 2013 8:28 am

Re: MW 2.3 sbus problem

Post by Mauronic »

I will be watching this closely guys, I am very interested in getting my X8R hooked up :) I am not as technical as you guys but let me know if there is anything I can do to help such as testing.

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: MW 2.3 sbus problem

Post by Plüschi »

A very simple fix would be in multiwii.cpp line 783

Code: Select all

 if ((int16_t)(currentTime-rcTime) >0 ) { // 50Hz
    rcTime = currentTime + 20000;
    computeRC();


Change the number 20000 to 8000 (20 ms -< 8ms). This should eliminate the constant buffer overflows when a message is written to buffer 111 times a sec but only read out 50 times a sec. If it works ... bug someone.

Ralph, hope you see this. This could be the cause of your glitches with the orangerx-sbus receiver. Mine works fine because its 22ms sbus, yours glitches because its 11ms sbus. Can you test this?

-ralf-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: MW 2.3 sbus problem

Post by -ralf- »

Plüschi wrote:A very simple fix would be in multiwii.cpp line 783

Code: Select all

 if ((int16_t)(currentTime-rcTime) >0 ) { // 50Hz
    rcTime = currentTime + 20000;
    computeRC();


Change the number 20000 to 8000 (20 ms -< 8ms). This should eliminate the constant buffer overflows when a message is written to buffer 111 times a sec but only read out 50 times a sec. If it works ... bug someone.

Ralph, hope you see this. This could be the cause of your glitches with the orangerx-sbus receiver. Mine works fine because its 22ms sbus, yours glitches because its 11ms sbus. Can you test this?


Sure? The glitches appear if more then 9 channels are specified in the TX,
and only with R910 RX; R620 RX works fine with 12 channels .....

sorry, cannot test yet .... no board avaiible ....

tofi
Posts: 8
Joined: Sun Sep 29, 2013 2:37 pm

Re: MW 2.3 sbus problem

Post by tofi »

Hello,

reading SBUS faster may be an additional improvement, but does not fix
the main problem, that there is no character timeout timer to properly
synchronize to SBUS.
If you have additional syncbytes in the frame, the MW code can still synchronize to the
wrong byte.

Baseflight has this character timeout timer.
Also Baseflight handles sbus receive in usart interrupt and tells
the main loop to read sbus when a new frame is available (not a fixed time).

See Baseflight sbus reveive function

Code: Select all

// Receive ISR callback
static void sbusDataReceive(uint16_t c)
{
    uint32_t sbusTime;
    static uint32_t sbusTimeLast;
    static uint8_t  sbusFramePosition;

    sbusTime = micros();
    if ((sbusTime - sbusTimeLast) > 4000)
        sbusFramePosition = 0;
    sbusTimeLast = sbusTime;
 
    if (sbusFramePosition == 0 && c != SBUS_SYNCBYTE)
        return;

    sbusFrameDone = false; // lazy main loop didnt fetch the stuff
    if (sbusFramePosition != 0)
        sbus.in[sbusFramePosition - 1] = (uint8_t)c;

    if (sbusFramePosition == SBUS_FRAME_SIZE - 1) {
        if (sbus.in[sbusFramePosition - 1] == SBUS_ENDBYTE)
            sbusFrameDone = true;
        sbusFramePosition = 0;
    } else {
        sbusFramePosition++;
    }
}

-ralf-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: MW 2.3 sbus problem

Post by -ralf- »

tofi, you are right,
we've implemented the check for the correct last byte of the s.bus-frame a few month ago, but
the main developers didn't integrate this.
Last edited by -ralf- on Thu Jan 02, 2014 11:32 pm, edited 1 time in total.

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

Re: MW 2.3 sbus problem

Post by haydent »

are you saying tofi that this is what your mod fixes or still needs doing ?

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: MW 2.3 sbus problem

Post by Plüschi »

tofi wrote:reading SBUS faster may be an additional improvement, but does not fix
the main problem


I guess your wrong here. The timing change should work 100% since its the ROOT of the problem.

The character timeout i made in baseflight is nice to have, but you woldnt want to have too much code inside an arduino ISR. You better use the buffer-flag system like they use for speksat. Its a change in program structure i did suggest before, but ...

btw i wrote the baseflight sbus part ... Cesco = me.

tofi
Posts: 8
Joined: Sun Sep 29, 2013 2:37 pm

Re: MW 2.3 sbus problem

Post by tofi »

Hello,

@ haydent
should fix the problems

@Plüschi

I think,
The character timeout is a must have, not nice to have !

if you don't have a character timeout, you can continuously synchronize to the wrong receive byte.
See the following frame.

------------------
channel 7 set to 0%
additional sync byte at BYTE 10

rxchan<0990 0990 0258 0990 0172 0172 0992 0992 0992 0992 0992 0992 0992 0992 0000 0992
rxsbus<0f de f3 9e 40 bc c7 0a 56 80 0f 7c e0 03 1f f8 c0 07 3e f0 01 00 7c 00 00

The MW code can start with byte index 0 at sbus byte position 10 and that is wrong.
This simply depends on the startup condition.
What should reset the sbus index to the correct sbus start byte ?
It always resets the index after 24 bytes, but there is again the wrong byte ?

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: MW 2.3 sbus problem

Post by Plüschi »

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.

tofi
Posts: 8
Joined: Sun Sep 29, 2013 2:37 pm

Re: MW 2.3 sbus problem

Post by tofi »

I think best way is to make a clean solution as you did for baseflight.
Maybe there will be more users with sbus in the future, because the new frsky receivers have sbus an no cppm.
I agree that ISR functions should be as short as possible. I had a look a the isr timing with a scope
and think it's not so critical.
A big problem is to find a good solution for all boards, that is where I have no experience and also cannot test.

-ralf-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: MW 2.3 sbus problem

Post by -ralf- »

I think it makes sense to check the "FrameLost"-bit in byte 24 too, right?

tofi
Posts: 8
Joined: Sun Sep 29, 2013 2:37 pm

Re: MW 2.3 sbus problem

Post by tofi »

Yes, this bit (lost frame) may be used as a warning indication, before failsafe,
I have implemented a failsave and lost frame counter in the usart interrupt, which I used only for debugging.
But this is already a new feature.
With frsky X8R the lost frame counter increased every 2-3 seconds (Tx and Rx on the desk).
With futaba receiver this did not happen.

-ralf-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: MW 2.3 sbus problem

Post by -ralf- »

@tofi,

I'm a bad coder ...... but can you give this a chance?
It should wait until the correct syncbyte is found ....

Code: Select all

#if defined(SBUS)
void  readSBus(){
  #define SBUS_SYNCBYTE 0x0F // Not 100% sure: at the beginning of coding it was 0xF0 !!!
  static uint16_t sbus[25]={0};
  int failsynccnt=0;
  int failsynccnt_tmp=0;
  while(SerialAvailable(SBUS_SERIAL_PORT)){
    int val = SerialRead(SBUS_SERIAL_PORT);
    if(sbusIndex==0 && val != SBUS_SYNCBYTE)
      continue;
    if (failsynccnt_tmp != 0){
      failsynccnt_tmp-=1;
      continue;
    }
    sbus[sbusIndex++] = val;
    if(sbusIndex==25){
      sbusIndex=0;
      if (sbus[24] != 0x0){
        failsynccnt+=1;
        failsynccnt_tmp=failsynccnt;
        continue;     
      }  else {
        failsynccnt=0;
        failsynccnt_tmp=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;
.
.
.

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: MW 2.3 sbus problem

Post by Plüschi »

My variant:

Deleted to avoid confusion. See the zip some posts later.
Last edited by Plüschi on Mon Jan 06, 2014 8:43 pm, edited 2 times in total.

-ralf-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: MW 2.3 sbus problem

Post by -ralf- »

Cesco,

are you sure your solution works with more then 1 syncbytes? If data reading starts
at the wrong byte, the frame is ignored ..... but the next reading starts at exactly
the same (wrong) byte. Right?

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: MW 2.3 sbus problem

Post by Plüschi »

-ralf- wrote:are you sure your solution works with more then 1 syncbytes


You are right.

I forgot to flush the buffer if not (spekFrameFlags == 0x01) or endbyte not correct or ...
someone will find a good solution which i will gladly use.

The important thing is the buffer will not overflow any more. the "read" is done in 2ms intervals instead of 20ms. Sync stays rock stable this way. Data handling is still in fixed 20ms, not nice, but changing would be a bigger thing.

Motivation is down. Why spend a lot of time and effort if this wont be included in shared anyway?

-ralf-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: MW 2.3 sbus problem

Post by -ralf- »

Code: Select all

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


should be

Code: Select all

      if (sbus[24] != SBUS_ENDCBYTE) {
           spekFrameFlags = 0x00;           
           continue;
      }


Right?

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: MW 2.3 sbus problem

Post by Plüschi »

Im not sure this is enough. I ask:

Next time spekFrameFlags comes up we will still read the old data in the buffer ?
Better to flush the buffer, means read until there is nothing left ?
Is there already a flush function or can we make one ?

-ralf-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: MW 2.3 sbus problem

Post by -ralf- »

Does the loop

Code: Select all

  while(SerialAvailable(SBUS_SERIAL_PORT)){


flush the buffer?

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: MW 2.3 sbus problem

Post by Plüschi »

Will sbusIndex be 0 next time spekFrameFlags comes up ? No.

We need to set sbusIndex = 0 when spekFrameFlags changes from 0 to 1. Any clever idea how / where?

-ralf-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: MW 2.3 sbus problem

Post by -ralf- »

When readsbus() is called?

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: MW 2.3 sbus problem

Post by Plüschi »

I did research, and cleverly the buffer is already flushed in the serial driver when spekFrameFlags is set. (my version above where sbus handling is the same as spektrum)

Serial.cpp, function store_uart_in_buf()

Code: Select all

        if (spekInterval > 5000) {  
          serialTailRX[portnum] = 0;   // flush
          serialHeadRX[portnum] = 0; // flush
          spekFrameFlags = 0x01;
        }


This should work then:

Rx.cpp, function readSBus()

Code: Select all

    if(sbusIndex==25){
      sbusIndex=0;
      spekFrameFlags = 0x00;
      if (sbus[24] != SBUS_ENDCBYTE) continue;


Since spekFrameFlags = 0x00; will make the driver flush the buffer :D
The next read will be syncbyte of a new message and sbusIndex will be 0, we are synced :)

It works here, but i only have 22ms SBUS. Can someone test it with 9ms SBUS? See attachment.
Attachments
MultiWii_SBUS.zip
(147.95 KiB) Downloaded 213 times

-ralf-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: MW 2.3 sbus problem

Post by -ralf- »

As you wrote my R910 may have a framelength of 11ms. I'll test the solution as soon
as I got my test-board back (it's needed by a friend, but comes back during this week).

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: MW 2.3 sbus problem

Post by Plüschi »

With 9ms framerate it can write 3*25 = 75 bytes in 20ms. The buffer is 64 bytes, so there will be an overflow.

With 11ms framerate it can only write 2 frames in 20ms so there "should" be no overflow, unless jitter or something else causes it.

When there is an overflow, data will be corrupt, and this may cause loss of sync and then sync on wrong position. Without overflow this wont happen because the first char transmitted-received ever will be sync, and the stuff will then remain locked in sync and never loose a single byte for hours.

The only way to have mis-sync without overflow is to plug in the serial line exactly while a message is transmitted.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MW 2.3 sbus problem

Post by Alexinparis »

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

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: MW 2.3 sbus problem

Post by Plüschi »

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
Posts: 8
Joined: Sun Sep 29, 2013 2:37 pm

Re: MW 2.3 sbus problem

Post by tofi »

@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.

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: MW 2.3 sbus problem

Post by Plüschi »

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-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: MW 2.3 sbus problem

Post by -ralf- »

Hi Cesco,

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

tofi
Posts: 8
Joined: Sun Sep 29, 2013 2:37 pm

Re: MW 2.3 sbus problem

Post by tofi »

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 ?

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: MW 2.3 sbus problem

Post by Plüschi »

@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.
Last edited by Plüschi on Tue Jan 07, 2014 9:20 pm, edited 1 time in total.

-ralf-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: MW 2.3 sbus problem

Post by -ralf- »

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.

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: MW 2.3 sbus problem

Post by Plüschi »

I have tried to make a diff ...

The spekFrameDone thing is optional
Attachments
MultiWii.zip
(1.74 KiB) Downloaded 211 times

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MW 2.3 sbus problem

Post by Alexinparis »

Hi,

inserted in r1648 ;)
I hope it's ok

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: MW 2.3 sbus problem

Post by Plüschi »

Tested both SBUS ans SpekSat and both seem working fine.

Tank You Alex.

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

Re: MW 2.3 sbus problem

Post by haydent »

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

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

Re: MW 2.3 sbus problem

Post by haydent »

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 ?

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: MW 2.3 sbus problem

Post by Plüschi »

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

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: MW 2.3 sbus problem

Post by Plüschi »

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.
Attachments
Sbus_patch.zip
(4.11 KiB) Downloaded 225 times

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: MW 2.3 sbus problem

Post by Plüschi »

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
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MW 2.3 sbus problem

Post by Alexinparis »

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

User avatar
ezio
Posts: 827
Joined: Sun Apr 01, 2012 11:03 pm
Location: Paris
Contact:

Re: MW 2.3 sbus problem

Post by ezio »

does sbus work with Frsky X8R reciever ?

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: MW 2.3 sbus problem

Post by Plüschi »

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-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: MW 2.3 sbus problem

Post by -ralf- »

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.

Post Reply