Hello all,
I have scoured the net only to find the last mention of this issue dating back to march, 2016 (which isn’t long ago) on this very forum.
I am using a Futaba 14SG transmitter with it’s stock R7008SB receiver. As I understand from endless forum reading, this particular one has a slightly different SBUS protocol and therefore it is not recognized by the PX4 autopilot (radio channels are all grey). Every other SBUS receiver reportedly works fine.
I have tested everything basically, the receiver is set to mode B, and the 7 ppm channels work (as well as the 8th channel if set to mode A). Cable is connected between RCIN and 8/SB ports (sbus2 is a telemetry input for the receiver, not an output).
The curious thing is that in this topic:
This guy had changed the sbus.c file in a manner that made it work for people. Tried using it instead and building the code myself but I guess things have changed since 2014, and some header files do not exist anymore so I can’t compile.
So, if it did work at some point in history, why isn’t it working on Ardupilot 3.4? do the developers plan on adding it in anytime soon? I’m just asking because I just bought a 500$ Tx and I’m kind of reluctant to replace it…
Any response would be appreciated,
Thanks in advance.
Steve
I use the T14SG transmitter with it’s stock R7008SB receiver in mode B without any problem on the Pixhawk (never tried a PX4) like a lot of other people using Arduplane and Arducopter.
… is correct. And you didn’t get the wrong orientation (signal / minus) ?
Switch on TX, power R7008SB (green LED ?), plug into PX4, connect and check signals.
I have 0 signal during failsafe (red LED on R7008SB), switching TX on again and everything is fine.
Please check with another device that you really have SBUS out on 8/SB port.
Hey Marc, the R6xxx actually report to work in a few forums. Thanks for the info.
ultrafuge, I did not get the wrong orientation, I use a cable with the extra little thingy on the signal side (which does not allow for reverse connection). Also verified with a normal cable reversed, but this wasn’t the issue.
Double checked with leds and binding.
I actually also tried this on another device I have which supposedly supports SBUS, but its a NAZA M-lite.
At first, I figured there’s a problem with the rx unit, but going through google I ran into the same issue saying that the naza does not support the sbus coming from that specific receiver.
But if you say that this rx with the same tx works for you then I might be getting back to a faulty rx hypothesis (but why would everything work except that, actually??).
Can you or anyone recommend a standalone code (with Arduino maybe) that I can use to verify this? I also have an APM2.6 unit for that matter. Can it be used with that protocol?
I used a DJI A2 for some weeks with R7008SB in the SBUS setup. DJI claims SBUS support for A2 and NAZA M-lite. I have no experience with NAZA.
Search for Arduino + SBUS, there are some projects and a SBUS-library.
Other option would be to find a helicopter pilot. More or less every FBL-unit for a heli talks SBUS. A Thundertiger GT5 explicitly tells you if it sees SBUS, PPM, SUMD, etc.,
IIRC the difference is in the last byte, they send RSSI on this one back and other non Futaba programmers used this byte as marker, therefore the problems.
I found some sbus libraries for arduino but they all require a NOT gate, I think itll be quicker for me to get one of those than another heli. I shall check it in depth.
I’ll be happy to hear about your flying, Marc.
Cheers, Steve
EDIT: I seemed to have a 74LS04 lying around, and a friend had loaned me his pwm-to-ppm/sbus converter. Prognosis:
Px4 unit accepts ppm AND sbus signals coming out of the converter.
Arduino sbus library also accepts the sbus from converter but not from the receiver.
This led me to beleive that there has to be something wrong with the receiver. could it be that the sbus within it is malfunctioning, maybe even floating logic?
So, I printed out the raw (inverted) data coming from the pin, and along with this document: http://forum.autoquad.org/download/file.php?id=2319&sid=b9bf8e54c8231cfb51691db4a3733673
it seems that the output is in fact 25 bytes long, repeats itself, starting with 11110000 and ending with either one of the possible endbytes in a cyclic manner.
So there is an output, just why isn’t it recognized?
Is there a way to tackle this with the developers?
Didn’t want to edit again.
Many videos say that with the futaba 14SG TX it is better to choose 12-channel fasstest link instead of 14 because the 14 is slower and redundant. So I was using 12.
I will declare here that my previous post was correct for 14 channels link only! The 12-ch has an erratic last-byte, with a packet length of 18-20 bytes, seeming randomly (I supposed it isn’t but who cares).
All I needed was to use the 14-CH mode on the TX and the fixed-code works on the PX4.
Again, the 12-CH does not comply with a repeating protocol.
Thanks to everyone who helped, this case is SOLVED.
My Setup: T14SG + R7008SB in mode B connected to Pixhawk 1
Arducopter 3.3.3: works with 12 channel FASSTest and works with 14 channel FASSTest
Arduplane 3.7.1: works with 14 channel FASSTest, does NOT work with 12 channel FASSTest