For sure you do not need any extra dtbo’s.
When I’m talking about radio calibration screen I’m in particular referring to Channel monitor, like on a picture:
How you connected your receiver to the board? What is the receiver?
Hello @silentjet ,
Yes sir, that is the screen. I used Mode 1 instead but I received output on the Channel Monitor.
The receiver is connected to PWR/GND on the Servo Headers and then SBus out to the PRU in. PRU in is ecap4, pin 4.
Seth
Those, so far, are my configs.
Also:
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
uname_r=4.19.94-ti-rt-r68
#uuid=
dtb=am335x-boneblue.dtb
###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/<file0>.dtbo
#uboot_overlay_addr1=/lib/firmware/<file1>.dtbo
#uboot_overlay_addr2=/lib/firmware/<file2>.dtbo
#uboot_overlay_addr3=/lib/firmware/<file3>.dtbo
###
###Additional custom capes
#uboot_overlay_addr4=/lib/firmware/BB-I2C1-00A0.dtbo
#uboot_overlay_addr5=/lib/firmware/BB-ADC-00A0.dtbo
#uboot_overlay_addr6=/lib/firmware/BB-UART4-00A0.dtbo
#uboot_overlay_addr7=/lib/firmware/BB-UART2-00A0.dtbo
###
###Custom Cape
#dtb_overlay=/lib/firmware/BB-I2C1-00A0.dtbo
#dtb_overlay=/lib/firmware/BB-UART4-00A0.dtbo
#dtb_overlay=/lib/firmware/BB-ADC-00A0.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
disable_uboot_overlay_emmc=1
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
My receiver is a X8R from FrSky.
Hello Once More @silentjet ,
Seth here. Okay…so. I think me making the cross-compilation on the Ubuntudistro w/ a new toolchain may have had some poor effects for working w/ ArduPilot/ArduCopter-4.1.
Does it even matter what method I use to build the binary/executable?
Seth
P.S. I ask b/c people at the Rant and Rave section to the forums at ArduPilot say:
- I can build on Ubuntu
- It does not matter what build process
Anyway…I was thinking since arm-linux-gnueabihf might have different versioning on Bullseye compared to Buster, making this build on Bullseye would be an issue. I have the same kernels but different images to build upon.
Well, the way how you are getting a binary is up to your comfort 
Just build it with –static flag so that you’ll have no issues related to missing or incorrect versions of some libs. Just use whatever cross compiler you have in your Ubuntu or Debian… (Newer versions are more restrictive though)
As for the version I would suggest staying with the Stable version, which is 4.0.x (4.0.7 I think)
Hello,
Okay so…
I updated the kernel. For what reason, I think blindly. Anyway, I posted a new POST in this forum about setting up /sys/devices/platform/ocp/ocp:P8_15_pinmux/state for input to the PRU onboard the BBBlue am335x.
Seth
P.S. It seems I cannot make this file available via echo.
This is outdated information. As far as I remember you do not need to do this step anymore 
… since quite a while, maybe 3-4 years ^.^
Hello…phew. Nice. I will test now. Thank you for this update.
Seth
Hello,
Well…I am up and running but my WiFi died for some reason. ha.
Seth
P.S. I was thinking. three to four years ago, now I could make some kits w/ these boards and make "Get back to the Chopper" a reality. If I fail more w/out knowledge on why I am failing, I might have to read up on it somewhere. 
:
Anyway…you were right. Everything is up and runnin’ except for Receiver-Transmitter communication.
Receiver-Transmitter communication - that is offtopic here, but what TX are you using? Are the firmwares the same? I assume you are in US, so reflash FCC version of the firmware let’s say 2.1 to both TX and RX side. And make sure you have single solid green light on a receiver side. Obviously you can connect servo to CH1-CH4 of the receiver and then one of the sticks will control it.
Hello,
Yes, that is off topic. I think something is wrong w/ my am335x-boneblue.dts so far. Before building it from the BeagleBoard-DeviceTrees github repo. at https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v4.19.x-ti-overlays/src/arm/am335x-boneblue.dts .
For instance, on line 214 on that file, the .dts file online, it shows the GPIO out as power to the BBBlue Servo Headers.
But…I am not receiving power to the Servo Headers.
Seth
You do not need to compile DTB to make drone fly Everything is here outofthebox. That is for sure. Also unpowered servo is also a good thing, because in most cases (at least when we are talking about RC) you are no intended to use a connector middlepin aka “+”, because usually ESCs are powered separatelly and “you do not want” to have BEC’s voltage unintentionally and it might collide. Even more, the amount of current that can flow is not so big, so for many things it is better to have a separate power source for servos.
Also what I can see from your logs:
RCOutputAioPRU.cpp:SIGBUS error generated
This is a sign that AP was no able to load PRU firmware. And this firmware is responsible for decoding SBUS signal.
Hello,
Okay. So, I need to power the Servo Header but it is not smart to power it this close to other modules. Okay.
Seth
P.S. I will find another resource for powering the Receiver and hopefully this will make it easier on the board and peripherals and onboard modules.
the RCOutputAioPRU.cpp:SIGBUS error generated output in journalctl -xe was due to the 5.4.x --ti-rt-channel kernel not having the option for the rproc PRU instance in /boot/uEnv.txt. I switched back to 4.19.x and it is not an issue/error.
Actually I was powering up my receiver from 3.3V and it was working fine(marked as 1)
But you can have 5V from another connector as well, with a bit of needle work (marked as 2)
Hello,
You are right about the 5v out from the POWER Connector on the BBBlue (#2 in the photo). This has not helped at all so far but it does power on the Receiver. So, this is good news!
I will keep testing.
Seth
P.S. Thank you for your help so far. If you can think of anything else that I might be missing w/ configurations on the BBBlue, please let me know.
It is not about BBBlue, it is about your TX-RX link. As soon as you’ll start moving servo connected directly to receiver from your Radio - you are fine and AP will see it as well.
1 Like
Hello…I will have more time soon. There is a missing link somewhere and I am tracking it down slowly.
Seth
P.S. Sorry for all this letter etiquette. Ha. Anyway, um, should I have to calibrate everything on the QGC source when installing a new binary on the BBBlue, e.g. ESCs and etc?
Hello @silentjet ,
Well…the BBBlue works but it is my config. on the transmitter that needs an adaptation. So, blah. I guess we can consider this fixed.
Seth
P.S. Thank you for providing what info. you gave forthright.
@silver2row @silentjet Do you have any updates on whether or not you ever got an aircraft flying with PX4 on the BBBlue? I am working on setting it up now via the cross compiler build method, have just set up the passwordless SSH access, but am not sure what to do for the toolchain download.
Any updates on your progress or direction to help me get PX4 up and running would be greatly appreciated.
1 Like
It is working fine since ~4 years. There is some technical scope you have to learn and some typical issues you have to overcome, but in general, it’s OK. I was flying a big 1000mm special mission drone with it for 2 years while making research…
1 Like
Seth here. I have not gotten the BBBlue to fly yet w/ ArduPilot or PX4 so far. One reason might be that I did not set up my MP or other autopilot software well enough to handle my set up.
Anyway…in ArduPilot, there are a couple scripts to handle promoting a cross-compile of the build environment.
On your WSL2 instance of Debian or a real Debian machine, perform these steps to publish the binary onto your BBBlue.
In your ~/arducopter directory, use this command.
python3 configure --board=blue --rsync-dest debian@192.168.7.2:/home/debian
This will create the correct way to install your binary. Now, we need to upload it by performing this command but you need to be in the /ardupilot/build/blue/ directory when running the below command.
python3 ../../waf --target bin/arducopter --upload
As you can tell, this will build the binary w/ waf via python3 and then upload the binary to a file on your BBBlue.
Also, I have not gotten to the point where I use the passwordless ssh access. This may in fact be the reason why my BBBlue cannot get up in the air. Who knows?
Seth
P.S. If you figure it out, good. If not, I can only relay the info. I found that has helped me get sort of close to flying the BBBlue. There is something about relays and GPIOs and PWM in the ArduPilot source I have not understood from their repo. on github so far.
Oh!
Here: /ardupilot/Tools/environment_install/install-prereqs-ubuntu.sh is the file that needs altering to handle building the binary for use.