DSM and SBUS receiver input

[tenchirocom]

I cannot seem to get any Rc signal on either DSM or SBUS.

Your configure instructions were very helpful btw. I've got the 4_19 rt kernel running, and the latest ArduCopter build running. I get the SBUS FD -1 115200 FD -1 message, so I think that is what I need to see. I have tried both the DSM and Quad pin 4. No joy. Any suggestions appreciated.

The receiver is a RadioLink R12DS with sbus enabled linked to an AT10.

Thank you.

[irion7]

I'm running into the same issue with my BBB where I don't seem to get any RC input. I'm using the Quad pin 4 as well. Is this broken with newer versions of ardupilot?

[tenchirocom]

Good evening, Irion7. I never could get DSM or the quad pin to work after quite a bit of experimentation.

What I ultimately ended up doing was making a one-line sourcecode change to ardupilot to use the UART port. 5 I think, right next to the DSM port. However, this is not inverted, so I had to cobble together a little inverter with a 2N2222 transistor and a pullup resistor. I just soldered directly to the leads and sealed it in some heat shrink tubing. Not hard, but you have to build your own Arudpilot firmware and the inverter. If you're into this level of effort, I'll go look up which file I had to modify to enable the port.

[irion7]

I've seen reference to the need to invert the SBUS signal for use on the UART in a few places. I had hoped that it would not be necessary but it appears that perhaps the RCIN on the quadrature pin was only active in a custom build? The docs for 4.0 and greater ardupilot indicate that setting the serial protocol on a UART to 23 causes the RC protocol to be automatically detected. My next attempt was going to be building the UART inverter and setting serial 5 to protocol 23.

Is there an additional code change I will need to get the RCIN working?

Thanks for your help

[tenchirocom]

Here're the diffs. I didn't know about setting uart to 23, so that would probably do it then w/o a rebuild. But if it doesn't work, you only have to worry about the HAL_Linux_Class.cpp changes below. The LED stuff was just to turn on some lights on the aircraft when the transmitter came on and it was ready to fly. So you can ignore that.

diff --git a/libraries/AP_HAL/board/linux.h b/libraries/AP_HAL/board/linux.h
index 9a83d781e7..b17577b5b1 100644
--- a/libraries/AP_HAL/board/linux.h
+++ b/libraries/AP_HAL/board/linux.h
@@ -197,6 +197,7 @@
#elif CONFIG_HAL_BOARD_SUBTYPE == HAL_BOARD_SUBTYPE_LINUX_BLUE
#define HAL_GPIO_A_LED_PIN 66
#define HAL_GPIO_B_LED_PIN 67

• #define HAL_GPIO_C_LED_PIN 98
  #define HAL_GPIO_LED_ON 1
  #define HAL_GPIO_LED_OFF 0
  #define HAL_INS_PROBE_LIST PROBE_IMU_I2C(Invensense, 2, 0x68, ROTATION_NONE)
  diff --git a/libraries/AP_HAL_Linux/HAL_Linux_Class.cpp b/libraries/AP_HAL_Linux/HAL_Linux_Class.cpp
  index 4710f63257..f94e6fdacd 100644
  --- a/libraries/AP_HAL_Linux/HAL_Linux_Class.cpp
  +++ b/libraries/AP_HAL_Linux/HAL_Linux_Class.cpp
  @@ -147,7 +147,8 @@ static RCInput_PRU rcinDriver;
  CONFIG_HAL_BOARD_SUBTYPE == HAL_BOARD_SUBTYPE_LINUX_POCKET
  static RCInput_AioPRU rcinDriver;
  #elif CONFIG_HAL_BOARD_SUBTYPE == HAL_BOARD_SUBTYPE_LINUX_BLUE
  -static RCInput_Multi rcinDriver{2, new RCInput_AioPRU, new RCInput_RCProtocol(NULL, "/dev/ttyO4")};
  +//static RCInput_Multi rcinDriver{2, new RCInput_AioPRU, new RCInput_RCProtocol(NULL, "/dev/ttyO4")};
  +static RCInput_Multi rcinDriver{2, new RCInput_AioPRU, new RCInput_RCProtocol("/dev/ttyO1", "/dev/tty05")};
  #elif CONFIG_HAL_BOARD_SUBTYPE == HAL_BOARD_SUBTYPE_LINUX_NAVIO ||
  CONFIG_HAL_BOARD_SUBTYPE == HAL_BOARD_SUBTYPE_LINUX_ERLEBRAIN2 ||
  CONFIG_HAL_BOARD_SUBTYPE == HAL_BOARD_SUBTYPE_LINUX_BH ||
  diff --git a/libraries/AP_Notify/AP_BoardLED.cpp b/libraries/AP_Notify/AP_BoardLED.cpp
  index 8e137c43e0..236cda9943 100644
  --- a/libraries/AP_Notify/AP_BoardLED.cpp
  +++ b/libraries/AP_Notify/AP_BoardLED.cpp
  @@ -101,6 +101,7 @@ void AP_BoardLED::update(void)
  arm_counter++;
  }
  if (AP_Notify::flags.pre_arm_check) {

•        hal.gpio->write(HAL_GPIO_B_LED_PIN, HAL_GPIO_LED_ON);
         // passed pre-arm checks so slower single flash
         switch(arm_counter) {
             case 0:
  

@@ -119,6 +120,7 @@ void AP_BoardLED::update(void)
break;
}
}else{

•        hal.gpio->write(HAL_GPIO_B_LED_PIN, HAL_GPIO_LED_OFF);
         // failed pre-arm checks so double flash
         switch(arm_counter) {
             case 0:
  

[tenchirocom]

I remember there was some weirdness with how the BBB was mapping tty05 too. Make sure it's there and as the expected file. BTW just to make it easier, this was the important line from the diffs in HAL_Linux_Class.cpp:

From
static RCInput_Multi rcinDriver{2, new RCInput_AioPRU, new RCInput_RCProtocol(NULL, "/dev/ttyO4")};
To
static RCInput_Multi rcinDriver{2, new RCInput_AioPRU, new RCInput_RCProtocol("/dev/ttyO1", "/dev/tty05")};

[irion7]

Just following up here in case anybody else has this issue. I doubled checked that the PRUs on my bbb were being loaded correctly before I made the code changes above. It turns out I was not running the TI version of the beagle bone rt kernel. Once I switched to the ti-rt kernel my radio sbus worked without the inverter without needed any code changes. I have it connected to the quadrature encoder pin 4. I found the rc_test_drivers program from the librobotcontrol library the be helpful in determining that the PRUs worked correctly.