Sometimes, it maybe makes sense to get the Mavlink telemetry not from the wbc, but to inject it from another source like TBS Crossfire. Especially when TBS finally publishes the V3.8 for Crossfire, the will be a built-in possibility to get the Mavlink data from Crossfire via WIFI and UDP, even if you do not have the “Full Crossfire TX”, since all other Crossfire Modules (Lite) have a wifi module build in.
One possible example is:
Steps:
Activate the WIFI hotspot of OpenHD. Since the builtin wifi modules of Crossfire (or some other solutions like my own Raspi0-Bridge or ESP32 mav2pt bridge) only can use 2,4GHz, take care that your WBS uplink works at 5,8GHz or use channels seperated as far as possible from another).
HOTSPOT_CHANNEL=Y
Configure your Mavlink bridge to broadcast on port 14560 (not to conflict with the “standard” Mavlink UDP port 14550). This may not be absolutely necessary in your configuration, but let’s do so. Of course, your port has to fit to the udp4-recv: parameter of socat, see below.
Now, set the telemtry parameters in OpenHD: TELEMETRY_TRANSMISSION=external EXTERNAL_TELEMETRY_SERIALPORT_GROUND_BAUDRATE=57600 EXTERNAL_TELEMETRY_SERIALPORT_GROUND=/dev/ttyCrossfire (the name of this virtual port is arbitrary, of course)
Change the file /usr/local/share/wifibroadcast-scripts/global_functions.sh and add something to the function in function get_telemetry_settings : if [ "$TELEMETRY_TRANSMISSION" == "external" ]; then if [ "$EXTERNAL_TELEMETRY_SERIALPORT_GROUND" == "/dev/ttyCrossfire" ]; then if [ ! -e $EXTERNAL_TELEMETRY_SERIALPORT_GROUND ]; then nice socat -d -d pty,link=/dev/ttyCrossfire,raw,echo=0 udp4-recv:14560 > /dev/null 2>&1 & fi fi fi
Add to in /usr/local/share/wifibroadcast-scripts/osd_rx_functions.sh:
below the line ps -ef | nice grep "cat /var/run/openhd/telemetryfifo3" | nice grep -v grep | awk '{print $2}' | xargs kill -9
add ps -ef | nice grep "cat /var/run/openhd/telemetryfifo6" | nice grep -v grep | awk '{print $2}' | xargs kill -9
(I’m not shure if this step is absolutely necessary, but I had some strange effects without this)
Setup your Mavlink wifi bridge to connect to the OpenHD wifi hotspot. Now, your Mavlink bridge (or Crossfire module) should send the mavlink telemetry to OpenHD.
At the moment, this is only a one way direction communication. With this little patch, OpenHD only receives telemetry, but is not able to send anything back to air. Let me know if you need this changed.
silly question, but why don’t you (seeing as you’re already using a pi with 2.4ghz wifi built in) just connect to the crossfire AP using that then open a connection to the module by looking for its UDP broadcast.
That is actually the better way to do it. as that’s how the wifi bridge in the crossfire was designed to be used. connect to the AP, listen for the mavlink heartbeat, reply to the heartbeat, get the data.
I can’t see how you are “automatically” getting the mavlink data from the crossfire in there without connecting to the UDP port of the crossfire ?
I‘m very sorry, I do not understand you at the moment. The goal of this litte patch was to inject the external Mavlink into Open.HDs telemetry message queues.
basically the way the crossfire mavlink works (which is what i’m trying to do myself) is you connect to the AP in the module, or connect the module to an existing AP (which is fine) and then the module starts sending out a UDP broadcast on port 8888. you reply to that broadcast with a mavlink heartbeat and then it starts sending you the mavlink data.
i’m new to open HD - heck i can’t even get it to see my usb camera yet, but all i’m after is a ground pi that can pull in mavlink data from the crossfire. the video i get other ways
The purpose is, to get the mavlink into the pipe-and-microservice structure of Open.HD. Where the Mavlink comes from, is variable.
Open.HD out-of-the-box suppoert Mavlink from wifibroadcast itself, and this works VERY well. I use the OpenHD Mavlink communication on several UAVs, even without any video. Is does a stable and reliable bidirectional Mavlink communication with 115k with a fairly good range.
Then, OpenHD supports a external Mavlink source via UART. But of with UDP, that’s the cause for my little patch. I use it in special cases, because my OpenHD installation also routes the telemetry to my tracker. On some UAVs I have just Crossfire and still analog video, but my tracker has a a PI4 inside and I use an simple 3 way switch and the different configuration profiles to change the config:
In my case, I use Crossfire full TX and I have a small PI0 that connects Crossfires’s Bluetooth to wifi. I still use the 3.75 version, because the new 4.0 has to many issues in my tests.
