Futaba S.Bus for R7008SB receiver

[13brv3]

Greetings,

I've been depressed ever since I found out that the new R7008SB receiver would not work with all the FC boards that currently support s.bus. It was obvious that Futaba changed something, but we didn't know what, until now

I spent some quality time with a logic analyzer, and compared the output of an older R6203SB receiver which works, to the new R7008SB that doesn't work. I also had to do some research, which was made easy by the mbed folks who documented the original s.bus protocol.

I'm somewhat bleary from staring at this all day, but the good news is that not much changed. The protocol is 25 bytes, including a start and end byte, with data stuffed in the middle. Everything is the same except for the endbyte. That used to be all zeros, but now it seems to change randomly between 4 different patterns.

Seeing as I'm not a programmer, I documented all the results as clearly as I could in the attached pdf file. My hope is that some clever programmer will look at this and realize that they can fix this in less time than it took me to type this post. I'm not sure if that will be the case or not. Can the endbyte be ignored somehow, or can we look for any one of several possible endbytes?

Thanks,
Rusty (desperately wants to use telemetry on his fancy new radio)

Note that the pdf is being updated as changes are made.

[bn999]

[13brv3]

Hi Bill,

Thanks very much for taking a look at this! I will certainly give this a try. It's usually dangerous for me to compile software, but I just installed Crossarm yesterday, and Tortoise SVN client, so I'll be working to get them setup and working today. I've wanted to be able to compile the software for a while, so this works out well.

Standby for updates.

Rusty

[13brv3]

New developments. I updated the pdf file, and will do so again later. What I've found so far is that the 18CH mode has the same 4 endbytes no matter what I do. I also found that I was wrong about how they appeared. They in fact cycle in perfect order for each frame, and two of the bits even forms a 0-3 count, so that makes me feel better.



I've just noticed that the 12CH mode is different, so I'm just starting to look at that.



Rusty

[13brv3]

OK, the FASSTest 12CH mode is actually easier. It's just like the output from the old s.bus receivers, but the endbyte is fixed at 00010000 instead of 00000000.

By my count, there are now 6 possible endbytes. Unfortunately, I can imagine that the R7003SB receiver might generate something different, and if you had a 14SG radio, it's "FASSTest 14CH" mode might be different from the 18CH mode.

Note that I just updated the PDF in the original post with an example of the 12CH protocol. It smokes with a frame every 6.3ms, but it only allows the RX and Ext Bat voltage for telemetry.

Cheers,

Rusty

[bn999]

[bluuu]

I try this soon.

[13brv3]

Thanks Bill! I've spent a bunch of time getting software installed, and figuring out (with lots of help) how to compile the firmware. I had just finished building a version with the original fix, and now I have one built with the new fix. I'll try these tomorrow.

Stay tuned

Rusty

[13brv3]

It works, and I'm officially a happy camper

First, I tried both the 12CH and 18CH mode again with release software, and as before, neither would work with the R7008SB receiver's s.bus output. No surprise here.

Next, I tried the original suggestion that ignores the endbyte, and it works fine with both the 12CH and 18CH mode.

Finally, I tried the later suggestion that checks for the first two and last two bits to be zeros, and that works fine with both 12CH and 18CH modes. I'll leave it here for now, since this sounded like a better solution.

With both the new modes, I noticed that the radio quality stays around 96% on 18CH mode, and is typically 100% on 16CH mode. I've never paid any attention to this with my old PPM solution, so I don't know if that's significant. The 12CH mode fires out frames at 6.3ms intervals, where the 18CH mode is 15ms, so maybe that's the difference.

I ordered an R7003SB receiver this morning, which is the smaller 3 port version. I just have to verify if this works the same, and doesn't add any complications. I wasn't initially interested in this receiver, because it doesn't have a dedicated voltage input port for the battery voltage, but in further reading, it does seem to have the ability to use a normal port as a voltage input, so it could be a better solution overall.

Needless to say, I'm pretty happy at this point. The only problem is that I now have more options to consider. These receivers are really neat, because they can simultaneously output PWM, s.bus, and s.bus2. The 8 port version can output the lower channels, or the upper channels, either with one, or two receivers. The neat thing about this is that I can set it to the upper channels in PWM, then have channels that don't conflicting with the FC functions available directly from the receiver. This will solve my immediate problem of needing a tilt channel for the gimbal.

Thanks again for the assistance on and off the forum. I'm pretty psyched that I've got the ability to compile and build the software for the first time ever, in addition of course to finally being able to use my new radio the way I want to.

Cheers,
Rusty

PS- for the sake of completeness, I also checked an old R6203SB receiver, and it still works fine with the new code change.

[bluuu]

here is some screen shots of my investigation

r7008sb - outputs described on pics

First in 14ch mode, second 12ch.

Sbus and sbus2 signals are the same except additional telemetry frame on sbus2 (in 14ch mode every 4 frames, in 12ch mode every frame).

14ch:

14ch

14ch telemetry

12ch:

12ch