INFO MissionPlanner.MAVLinkInterface - Access denied

Hi All,

I am trying to connect to a cube blue using a doodle labs smart radio. I am able to connect, but I cannot pull parameters or waypoints. I get this message when i look at the debug console for mission planner:

INFO MissionPlanner.MAVLinkInterface -
Access denied

Has anyone seen this before? Am I missing something simple here?


Doodle radios are not simple devices. They are full, self contained MIMO radios running linux. First you have to be sure that the configuration of your radios is good. Take out pixhawk and MP from the equation. Use a usb/serial converter on the flight side and a terminal emu (like PuTTY) on the ground side. This way you can put both radios into the same computer. If you have solid two way comm, then go back to pixhawk and MP.

I ended up figuring it out. Ser2net doesn’t like when you have 2 ip addresses on the same subnet.

1 Like

Hi, I got a doodlelabs I’m trying to get to communicate with my Autpilot. would you mind sharing how you set up the device? I have tried setting the serial port on the doodlelabs with UDP, port 14550, baud 115k, and same in Ardupilot, but I’m not able to connect to it.

@Oyvin Sure thing. First thing you should do is update your radio to the latest firmware. Then under the “serial configuration” tab you should be able to configure the settings to enable UDP. Can you post a screenshot of your latest config?

Thanks, I’m on the latest doodlelabs firmware. Here’s the config

Awesome. So the way I got it connected that way was to set it to Unicast Client - then where it says “Host IP address” simply put the ip address of the computer you’re using. Then in mission planner just type in the port and hit connect. It should work. You also might need to put in a firewall exception for that traffic.

When you put it that way, it makes sense that I should put it as a client instead of server. Thanks, I’ll try that tomorrow and see how it goes

So, I got the serial link working and can connect to the autopilot through mission planner and qgc, but the parameter read is really slow. Is there a way to fix this? I saw you mentioned something about several addresses on the same subnet. Im using,, etc on my devices. Is that a problem?

1 Like

Hi , were you able to improve the parameter read speed ?

After discussing this with doodlelabs tech support, setting the baud rate to 921600 seems to work best. For qgc, it is pretty fast, but mission planner is still a bit slow. Doodlelabs doesn’t know why, and say it could be something with how mission planner reads the parameters

Hi, do you know how to transmit commands and data from an SBC like raspberry pi 4 to the smart radio? Or between two smart radios? I read the documents of doodle labs, but didn’t find any examples.

Hi, I’m having trouble getting my doodle radios working with a Cube Orange running Ardupilot and QGC. This is just about the only thread I’ve found that deals with this hardware, so I figured I could ask. I’m using the radios for simultaneous video stream and C&C, and can confirm I have a stable connection as I am receiving video at 1080p60 in QGC over RTSP. I had been able to establish a connection between QGC and my AP previously, using UDP Client setup on ser2net using /dev/ttyACM0 at port 14550 and baud rate of 57600 on both ends, however, I was only able to view the AP’s heartbeat when disconnected from USB, no other parameters, and received a ‘vehicle 1 did not respond to request for parameters’ message each time I untethered the bird. I attempted to follow some suggestions in this thread, namely increasing the baud rate to 921600 on both ends, and now I am unable to connect to the vehicle at all. my UDP connection in QGC works with no errors or warnings, but my AP does not appear. After switching back to the original baud rate, I am still unable to connect to the AP over the air. If anyone has any ideas I would greatly appreciate the help.

Hey mason, go ahead and update the doodle radio to the latest firmware. Disable all your ser2net stuff (conf file and what not) and use doodle labs new firmware and UI to use their socat config stuff. Post back on here if you have some issues.

Hey Evan, I updated to the latest firmware release (August 2021) and am now able to see the heartbeat and timesync signals on QGC again. I received the same ‘Vehicle 1 did not respond to request for parameters’ message upon connection. Oddly enough, this is with the vehicle param SERIAL1_BAUD set to 115k and the radio baud set to 57k. Setting the radio baud to 115k in this state causes connection to be lost completely with the ground station.

What device are you having socat connect to? Did you add a firewall port exception for the port Youre forwarding the radio data out of? Wanna share a screenshot of your socat config page and your firewall rules table.

I was able to get the baudrate up to 921600 on both ends and achieve the same partial connection as before - just needed to reboot the AP before serial baudrate changes took effect. Even at this high baudrate, I’m still seeing the same message. Due to my current bench setup it would be difficult for me to get a screengrab of me socat config page, but I’ll list the settings I have here:
Socat Enabled
role: Unicast Client
Transport: UDP
Host IP Address:
Port: 14500
Baudrate of tty: 921600
Device: /dev/ttyACM0
My whole communications and device structure is as follows:
QGC on host PC running Ubuntu 20.04 (IP, connected via ethernet to one Doodle radio.
Jetson Nano connected via ethernet to a second Doodle radio running DHCP Server. This radio is connected via UART to the Pixhawk’s TELEM1 port. There is an active video stream over RTSP using gstreamer from the Jetson to QGC. Running arp -a on the DHCP Server radio lists all 3 other devices’ IP addresses, as well as
I have (what I believe is) the correct firewall exception made for any UDP on port 14500, from any host in wan to any router IP on this device, allowing input.

I’m curious why your device is ttyACM and not uart0 ? On all my radios I’ve used the uart port on the doodle radio. Is that an option in your drop down?

Also - you should be able to just type the IP address of the radio into any web browser on the network? I’m also curious why that wouldnt be an option.

The difficulty is more in getting the image to this forum - I’m running this desktop in a workspace with no ethernet connection nearby, so uploading it means I have to move the desktop back and forth. I’m going to flash the AP with a different firmware for which I need internet, so I’ll upload when I do that. In previous iterations of the integration I had set it to /dev/ttyACM0 to try to fix something, but neither serial connection allows for parameter download. For both configurations, the MavLink message loss rate begins at 16% before evening out to 6% as time goes on. It’s very possible that this issue is not related to the radios themselves or their configurations, and I will continue to test and try to identify the source of the problem.

Gotcha. Another thing you can do to simplify it - take all of your networking out of it. Just Ethernet directly to the doodle radio connected to the autopilot (make sure you’re plugging into the eth0 port - whichever one the 10.x.x.x network is on) and initiate an autopilot connection that way.

Also make sure ser2net isn’t still enabled and doing stuff with your serial connections. As a sanity check.