Problems connecting to VOXL2 with Doodle Radio on SDK 1.0 and 1.1, but not 0.9.5

John Nomikos

Good afternoon,

In the last month, I have been integrating doodle radios onto the VOXL2. There is one problem that is always consistent. Whenever I connect to the VOXL2 with the doodle radio on SDK 1.0 or 1.1, the connection will fail to complete. It will start connecting, freeze in the middle, take like 10 extra seconds, and then give "Parameters failed to download" errors on QGC. Sometimes it will successfully connect, but it takes minutes, and after it does, MAVLink appears to be very "choppy". As an example, if I move the VOXL2 around, the compass indicator will show it moving, but it is super laggy.

On QGC when I go to application settings -> Mavlink, I observe that the messages sent and received constantly freeze every second. The loss rate is only around 3% though.

This issue does not appear on 0.9.5. This issue also does not appear on 1.0 or 1.1 if I switch from using voxl-mavlink-server to mavlink-router (well the download stopping on QGC after taking too long does not appear. But it still takes forever to load up on QGC using mavlink-router).

This issue appears to be specific to doodle radios. I do not see similar problems when using a Microhard or WIFI adapter.

Moreover, this problem happens regardless of the bitrate between the radios. I've observed 30-50 mbps bitrate between the radios with a stable video stream, and still connection issues.

I know this problem isn't related to the bitrate being too high, because I've successfully connected to the VOXL2 via ethernet with no issues.

I did not observe any errors on voxl-mavlink-server or voxl-vision-hub. I also have the default configuration settings with both, but have toyed around a bit to try to see if this is a configuration issue.

I have observed this issue both with and without an external flight controller. The consistent thing is the doodle radio being in the equation and MAVLink being "choppy". My instinct is that the doodle is causing the issues here, but I am not sure because 0.9.5 works well. It loads up super fast when I am on 0.9.5 and MAVLink does not appear choppy.

Here is my voxl-mavlink-server config on 0.9.5:

/**
 * voxl-mavlink-server Configuration File
 * UART fields are for APQ8096 VOXL1 or QRB5165 VOXL2 with external fc
 * UDP fields are for PX4 on SDSP on QRB5165 only
 * External FC field is for QRB5165 only. Set to true to enable UART
 * communication to an external flight controller, otherwise a UDP interface
 * will be started to talk to voxl-px4 on localhost which is the default behavior.
 *
 */
{
	"px4_uart_bus":	1,
	"px4_uart_baudrate":	921600,
	"udp_port_to_px4":	14556,
	"udp_port_from_px4":	14557,
	"external_fc":	false
}

Here is it on 1.1.0

/**
 * voxl-mavlink-server Configuration File
 *
 * primary_static_gcs_ip & secondary_static_gcs_ip
 *    These configure voxl-mavlink-server to automatically try to connect to
 *    up to two known static GCS units. Set to empty or NULL if you don't want
 *    to use this and you want the GCS to initialize the connection instead.
 *    Note the default IP for the primary link is 192.168.8.10 which is the
 *    first IP that VOXL DHCP serves when connecting in wifi softap mode.
 *
 *
 * Settings for running voxl-px4 on SLPI:
 * onboard_port_to_autopilot   - UDP port to send high-rate onboard data to SLPI
 * onboard_port_from_autopilot - UDP port to receive high-rate onboard data from SLPI
 * gcs_port_to_autopilot       - UDP port to send normal-rate gcs data to SLPI
 * gcs_port_from_autopilot     - UDP port to receive normal-rate gcs data from SLPI
 *
 * Settings for running an external autopilot connected via UART:
 * en_external_uart_ap       - set to true to enable an external flight controller
 * autopilot_uart_bus        - uart bus, default 1 for VOXL2 
 * autopilot_uart_baudrate   - default 921600
 * en_external_fc_timesync   - enable responding to timesync messages
 *                                   (enabled by default)
 * en_external_ap_heartbeat  - enable automatic sending of heartbeat
 * gcs_timeout_s - time without heartbeat to consider GCS disconnected
 *
 * udp_mtu - maximum transfer unit for UDP packets back to GCS. voxl-mavlink-server
 *           will bundle up backets for the GCS into a single UDP packet with 
 *           a maxium size of this. This saves network traffic drastically.
 *           Set to 0 to disable this feature and send one UDP packet per msg.
 *
 *
 * External FC field is for QRB5165 only. Set to true to enable UART
 * communication to an external flight controller, otherwise a UDP interface
 * will be started to talk to voxl-px4 on localhost which is the default behavior.
 * Select UART port 1 to go through the legacy B2B connector, that's the port exposed by the
 * M0125 and M0141 accessory boards. Use port 12 to go through the ESC port (J18).
 *
 */
{
	"primary_static_gcs_ip":	"192.168.8.10",
	"secondary_static_gcs_ip":	"192.168.8.11",
	"onboard_port_to_autopilot":	14556,
	"onboard_port_from_autopilot":	14557,
	"gcs_port_to_autopilot":	14558,
	"gcs_port_from_autopilot":	14559,
	"en_external_uart_ap":	false,
	"autopilot_uart_bus":	1,
	"autopilot_uart_baudrate":	921600,
	"en_external_ap_timesync":	1,
	"en_external_ap_heartbeat":	1,
	"udp_mtu":	4000,
	"gcs_timeout_s":	4.5
}

The annoying thing is that OCCASIONALLY, on SDK 1.0 and above, it connects fine on QGC without stalling. So it is really hard for me to tell if this is a radio problem or a VOXL2 problem. Moreover, I've observed this problem on every doodle I've worked on.

Vinny

HI @John-Nomikos
I'm only providing some extra Hardware Integration insight here just in case... I still think we need SW to respond here since you have identified clear breaking points... but there are two key things that are required for Doodle radios to work properly along with the SW (I am writing this since you expressed a common issue on all doodle radios):

Lots of power on 5V. The radio really needs to have a 10W+ source. We provide some cable options for these connections, but if you are powering your doodle separately, make sure your 5V is capable of a solid 10W (or more). Not all ModalAI ports can work here, but we have some (please see the VBUS table lower down): https://docs.modalai.com/expansion-design-guide/#usb-expansion-over-j3--j5
Distance ... you cannot have two doodle radios too close to each other for a coms link.. they must be at least 6-10 meters away from each other to maintain a reliable link.. otherwise they just end up saturating each other. This is direct guidance from their integration guides and we've seen it in our testing as well, so our test team knows to be as far apart as they can when indoors, and at least that 10-ish meters for outdoor testing.

Hope that helps improve your testing regardless of the SW issues you raised.

Chase Riley

@John-Nomikos Take a look at my topic I posted a while back. Your issue seems similar to the one I was having. @James-Strawson response was able to fix my issue.

https://forum.modalai.com/topic/2731/slow-connection-to-qgc-and-missing-params-due-to-timeout-with-doodle-labs-radios?_=1703799939124

John Nomikos

@Chase-Riley

Thank you so much, that forum post basically describes the exact same issues I was running into. Going to test it out soon and see if that fix works on my end.

Yeah we always used attenuators and/or had long range. And I've tested this with like 5 different doodle radios and they all gave the same results

Chase Riley

@John-Nomikos Let me know if it fixes your issue.

teddy.zaremba

Hi,
Thanks for the tip @Chase-Riley. Unfortunately, we tried udp_mtu with values equal to 200, 300, 500, 600, 1000, and 2000 on voxl sdk 1.1.2 with no luck. We also tried with antennas attenuators and testing distances up to 10m.

Chase Riley

@teddy-zaremba I was running 1.0 when I was experiencing this issue. I can speak for newer SDKs.