MW 2.3 sbus problem
MW 2.3 sbus problem
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
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
Re: MW 2.3 sbus problem
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 ?
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
Re: MW 2.3 sbus problem
Yes, I use an external transistor as Inverter.
Re: MW 2.3 sbus problem
thanks, even though easy to make, i have ordered a sbus inverter to try this with
Re: MW 2.3 sbus problem
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.
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.
Re: MW 2.3 sbus problem
Thanks for your input. It makes sense
Re: MW 2.3 sbus problem
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.
Re: MW 2.3 sbus problem
A very simple fix would be in multiwii.cpp line 783
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?
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?
Re: MW 2.3 sbus problem
Plüschi wrote:A very simple fix would be in multiwii.cpp line 783Code: 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 ....
Re: MW 2.3 sbus problem
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
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++;
}
}
Re: MW 2.3 sbus problem
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.
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.
Re: MW 2.3 sbus problem
are you saying tofi that this is what your mod fixes or still needs doing ?
Re: MW 2.3 sbus problem
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.
Re: MW 2.3 sbus problem
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 ?
@ 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 ?
Re: MW 2.3 sbus problem
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.
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.
Re: MW 2.3 sbus problem
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.
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.
Re: MW 2.3 sbus problem
I think it makes sense to check the "FrameLost"-bit in byte 24 too, right?
Re: MW 2.3 sbus problem
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.
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.
Re: MW 2.3 sbus problem
@tofi,
I'm a bad coder ...... but can you give this a chance?
It should wait until the correct syncbyte is found ....
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;
.
.
.
Re: MW 2.3 sbus problem
My variant:
Deleted to avoid confusion. See the zip some posts later.
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.
Re: MW 2.3 sbus problem
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?
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?
Re: MW 2.3 sbus problem
-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?
Re: MW 2.3 sbus problem
Code: Select all
if (sbus[24] != SBUS_ENDCBYTE) continue;
should be
Code: Select all
if (sbus[24] != SBUS_ENDCBYTE) {
spekFrameFlags = 0x00;
continue;
}
Right?
Re: MW 2.3 sbus problem
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 ?
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 ?
Re: MW 2.3 sbus problem
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?
We need to set sbusIndex = 0 when spekFrameFlags changes from 0 to 1. Any clever idea how / where?
Re: MW 2.3 sbus problem
When readsbus() is called?
Re: MW 2.3 sbus problem
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()
This should work then:
Rx.cpp, function readSBus()
Since spekFrameFlags = 0x00; will make the driver flush the buffer
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.
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
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
Re: MW 2.3 sbus problem
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).
as I got my test-board back (it's needed by a friend, but comes back during this week).
Re: MW 2.3 sbus problem
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.
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.
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MW 2.3 sbus problem
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
Re: MW 2.3 sbus problem
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
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
Re: MW 2.3 sbus problem
@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.
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.
Re: MW 2.3 sbus problem
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.
Re: MW 2.3 sbus problem
Hi Cesco,
now (first time ever) it works with Orange RX 9CH (12 channels transmitted).
Thanks, good work.
now (first time ever) it works with Orange RX 9CH (12 channels transmitted).
Thanks, good work.
Re: MW 2.3 sbus problem
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 ?
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 ?
Re: MW 2.3 sbus problem
@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
Obviously spekFrameFlags could be renamed serialRcFrameFlags.
Note we have to do a
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.
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.
Re: MW 2.3 sbus problem
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.
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.
Re: MW 2.3 sbus problem
I have tried to make a diff ...
The spekFrameDone thing is optional
The spekFrameDone thing is optional
- Attachments
-
- MultiWii.zip
- (1.74 KiB) Downloaded 211 times
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MW 2.3 sbus problem
Hi,
inserted in r1648
I hope it's ok
inserted in r1648
I hope it's ok
Re: MW 2.3 sbus problem
Tested both SBUS ans SpekSat and both seem working fine.
Tank You Alex.
Tank You Alex.
Re: MW 2.3 sbus problem
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
Re: MW 2.3 sbus problem
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 ?
do others get the same ? wordering if this is deliberate, or possibly the signal not being translated accurately ?
Re: MW 2.3 sbus problem
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
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
and then since the gap between packets is only 3.3ms adapt line 161 in serial.cpp to 2.5ms
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
Then, there is a new telemetry capable SBUS2 interface.
http://imgur.com/a/aVAbt
And ... sbus on MultiWii doesent work with it
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
Re: MW 2.3 sbus problem
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.
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
Re: MW 2.3 sbus problem
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.
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.
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MW 2.3 sbus problem
I wouls like, but I can apply this patch like this.
where is defined SUMD ?
where is defined SUMD ?
Re: MW 2.3 sbus problem
does sbus work with Frsky X8R reciever ?
Re: MW 2.3 sbus problem
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.
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.
Re: MW 2.3 sbus problem
ezio wrote:does sbus work with Frsky X8R reciever ?
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.