OpenIPC S30KQ telemetry_tx exception

[lida2003]

It's weird, S30KQ+8812AU(2W), it seems that telemetry_tx process crashed. 80% chance telemetry_tx process crashed, I have tested about 10 rounds. so it will fail most of time.

Have anyone met this before?

https://www.youtube.com/watch?v=0OCi0GjeCTA

PS: https://github.com/svpcom/wfb-ng/discussions/396

[aepkolol]

I have the exact same issue. Mavlink telemetry sends fine, until the GCS makes a connection, then within 30 seconds I get disconnected from the flight controller. wfb-cli shows no mavlink packets are being received from the drone, but video and tunnel are fine. As a one way telem link, it works fine, its only when its bidirectional.

With a onboard computer connected directly to another 8812eu wifi chip running pure wfb-ng on both sides, it seems fine. It's only when openIPC is the middleman (In this case, running a runcam wifilink on the drone)

That being said, SOMETIMES it works and doesn't crash within 30 seconds. I've had it on for a little while working fine, but more than 9 times out of 10, its a crash.

I'll try and get some logs off the wifilink the next time I'm connected to it via ethernet.

[Ablenking]

新版本mavlink走隧道(tunnel, ip based)，以前的wfb-cli 将无法分析监听mavlink消息

[lida2003]

@Ablenking So what conclusion of the issue above. And what's final decision of mavlink telemetry, as I didn't see any feedback from OpenIPC dev, https://github.com/OpenIPC/firmware/pull/1715

[tipoman9]

@lida2003 and @Ablenking. Two way mavlink is tricky, you need to properly configure the forwarding on the air unit. I tested mavfwd only in one way mavlink mode. On the ground wfb_ng creates a wfb_tx + wfb_rx pair and binds them to a single UDP socket to emulate two way UDP connection. You need to manually setup this on the camera, but instead of a UDP socket, you need to share the UART. mavfwd can't to this when using parsing for packet aggregation AFAIK. Maybe mavrouterd can , but you need to test.

[aepkolol]

I actually traced down where the bug was the other day and "fixed" it here

https://github.com/OpenIPC/firmware/blob/master/general/package/wifibroadcast-ng/files/wifibroadcast

	if [ "$router" = "mavfwd" ]; then
		mavfwd -b 115200 -c 8 -p 100 -a 15 -t -m /dev/"$serial" \
			-o 127.0.0.1:"$port_tx" -i 127.0.0.1:"$port_rx" > /dev/null &
	else

Changed to

	if [ "$router" = "mavfwd" ]; then
		mavfwd -b 115200 -a 15 -m /dev/"$serial" \
			-o 127.0.0.1:"$port_tx" -i 127.0.0.1:"$port_rx" > /dev/null &
	else

I don't know if it was the SoC temp injections or the RC channel stuff I removed that fixed it, I didn't troubleshoot it that well. I just removed those flags and it stopped crashing. Just edit the that portion of the wifibroadcast script when you ssh into the module.

[lida2003]

I don't know if it was the SoC temp injections or the RC channel stuff I removed that fixed it, I didn't troubleshoot it that well.

• https://github.com/OpenIPC/mavfwd/blob/master/README.md

Also, mavfwd can monitor the mavlink RC _CHANNELS package, and call the script channels.sh (located at /usr/bin or /usr/sbin) passing the channel number and its value to it when changing as $1 and $2 parameters. An example of channels.sh is present.

This allows for controlling the camera via the Remote Control Transmitter

Usage: mavfwd [OPTIONS]
-m --master      Local MAVLink master port (%s by default)
-b --baudrate    Serial port baudrate (%d by default)
-o --out         Remote output port (%s by default)
-i --in          Remote input port (%s by default)
-c --channels    RC Channel to listen for commands (0 by default) and call channels.sh
-w --wait        Delay after each command received(2000ms defaulr)
-a --aggregate   Aggregate packets in frames (1 no aggregation, 0 no parsing only raw data forward) (%d by default) 
-f --folder      Folder for file mavlink.msg (default is current folder)
-p --persist     How long a channel value must persist to generate a command - for multiposition switches (0ms default)
-t --temp        Inject SoC temperature into telemetry(HiSilicon and SigmaStart supported)
-j --wfb         Reports wfb_tx dropped packets as Mavlink messages. wfb_tx console must be redirected to <temp>/wfb.log
-v --verbose     Display each packet, default not       
--help         Display this help