Beaglebone blue sbus connection not visible in gcs, debugging via terminal?

Hardware Linux
,
1

Hi all, I’m on Futaba R3008SB receiver and I’m seeing sbus1 signals on oscilloscope but gcs isn’t receiving any input and receiver is not being detected properly.

Here is my wiring just to verify

sbus_wiring
sbus_wiring1000×1333 410 KB

I’m wondering how I can check if sbus is working from beaglebone linux console, and not the ardupilot? it seems that it’s some serial proto, 10000 baud rate? I’d like to check this first since it could be that I burned the input before using 5v :frowning:

I went through the source and I see
libraries/AP_HAL_Linux/HAL_Linux_Class.cpp

#elif CONFIG_HAL_BOARD_SUBTYPE == HAL_BOARD_SUBTYPE_LINUX_BLUE
static RCInput_Multi rcinDriver{2, new RCInput_AioPRU, new RCInput_RCProtocol(NULL, "/dev/ttyO4")};

so I assume E4 pin 4 is /dev/ttyO4 on beaglebone? I’m not sure how AioPRU works and if it checks for some other ports for sbus…

If the E4 input is burned, can I use some other port for sbus? I’ve read some stuff about inverted signals, will this become relevant if I switch to some other tty? Can I switch via cmdline arguments or params or do I need to edit the source and rebuild?

tnx all!

2

Hi

No, the ttyO4 is one thing - if i not wrong there is a dsm port. The e4 pin send the data to ardupilot using a pru code to read rc input and generate rcoutput.
You can compile ardupilot with ./waf examples and this will generate programs to test rcinpu, rcoutput, baro, ins and etc.

But before any step. Please confirm your kernel version, the content of the uEnv file - mainly the line related to pru, and the content of result for the command /opt/scripts/tools/version.sh
And if there is any beep or signal in the ESCs - to ensure the pru working

3

aha ok, thanks for clarifying!

Yes ESCs work, I can actually fly it via mavlink and wifi

user@beaglebone ~ > uname -a 
Linux beaglebone 4.19.94-ti-rt-r73 #1buster SMP PREEMPT RT Fri Apr 15 21:47:59 UTC 2022 armv7l GNU/Linux

user@beaglebone ~ > cat /boot/uEnv.txt  | grep pru
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_rproc (4.19.x-ti kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
###pru_uio (4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo


user@beaglebone ~ > rc_test_drivers 
Kernel: 4.19.94-ti-rt-r73
BeagleBoard.org Debian Buster IoT Image 2020-04-06
Debian: 10.13

PASSED: gpio 0
PASSED: gpio 1
PASSED: gpio 2
PASSED: gpio 3
PASSED: pwm0
PASSED: pwm1
PASSED: pwm2
PASSED: eqep0
PASSED: eqep1
PASSED: eqep2
PASSED: pru-rproc
PASSED: uart1
PASSED: uart2
PASSED: uart4
PASSED: uart5
PASSED: i2c1
PASSED: i2c2
PASSED: spi
PASSED: LED
PASSED: ADC iio

Currently running on a:
MODEL_BB_BLUE
Robot Control library Version:
1.0.5

user@beaglebone ~ > sudo /opt/scripts/tools/version.sh

git:/opt/scripts/:[]
eeprom:[A335BNLTBLA21736EL000068]
model:[TI_AM335x_BeagleBone_Blue]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 2019.04-00002-g07d5700e21 (Mar 06 2020 - 11:24:55 -0600)]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-g07d5700e21]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblue.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0.bb.org-overlays]
kernel:[4.19.94-ti-rt-r73]
nodejs:[v10.24.0]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]
pkg:[bb-cape-overlays]:[4.14.20210821.0-0~buster+20210821]
pkg:[bb-customizations]:[1.20221108.0-0~buster+20221108]
pkg:[bb-usb-gadgets]:[1.20220816.0-0~buster+20220816]
pkg:[bb-wl18xx-firmware]:[1.20221201.0-0~buster+20221201]
pkg:[kmod]:[26-1]
pkg:[roboticscape]:[0.4.4-git20180608.0-0rcnee0~buster+20180609]:[GOT_REPLACED_BY_NEXT]
pkg:[librobotcontrol]:[1.0.5-git20200715.0-0~buster+20200716]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc admin spi iio docker tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
dmesg | grep remote
[   10.599049] remoteproc remoteproc0: 4a334000.pru is available
[   10.610666] remoteproc remoteproc1: 4a338000.pru is available
[  135.099361] remoteproc remoteproc2: wkup_m3 is available
[  135.191659] remoteproc remoteproc2: powering up wkup_m3
[  135.210802] remoteproc remoteproc2: Booting fw image am335x-pm-firmware.elf, size 217148
[  135.211117] remoteproc remoteproc2: remote processor wkup_m3 is now up
dmesg | grep pru
[   10.599049] remoteproc remoteproc0: 4a334000.pru is available
[   10.599239] pru-rproc 4a334000.pru: PRU rproc node pru@4a334000 probed successfully
[   10.610666] remoteproc remoteproc1: 4a338000.pru is available
[   10.610928] pru-rproc 4a338000.pru: PRU rproc node pru@4a338000 probed successfully
dmesg | grep pinctrl-single
[    1.063437] pinctrl-single 44e10800.pinmux: 142 pins, size 568
dmesg | grep gpio-of-helper
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END

I’ll build the examples now and update here

4

Hi @lshx

In true don’t worry , your pru is working.

I suffered a lot with some r161 receivers.
Could you measure the voltage of the sbus output? The r161 receiver was sending 2,6 volts and the pru/beagle wasn’t understating this as a high level. To do the beagle working with the r161 I used a circuit to generate 3v3. Once your motors is working you have the pru working - and this is the major causes of problems with beagles, but check the voltage level of your receiver for now - and be careful to don’t put more than 3v3 in the beagle input pins .

5

so this receiver has multiple working modes, including a mode in which this sbus1 output behaves like a standard aditional PWM channel using 5v signal, and so I think I pushed 5v into the beagle sbus E4 by mistake before… this is why I was curious to test it the port still works, and potentially use some other port for sbus, or if I’m done with sbus and this board :slight_smile:

pretty sure I’m on 3.3v sbus now, but I will re-verify soon and get back with this info as well

thanks for all the help!

6

wow actually you are right, sbus out is not above 3.3v, will need to build some circuit before figuring out if my port is burned :slight_smile:

scope
scope1000×750 243 KB

7

I made two circuits. One with an i2c shift leveler and other with a 4n25 optocoupler

8

oh, I was planning to just slap a simple transistor there, with receiver sbus on it’s base, am I missing something?

tnx for debugging this with me btw, I wouldn’t have cought the undervoltage