I have several questions about the 3DR radios that I was hoping some developers might be able to answer to facilitate my thesis research...
 The 3DR wiki says 8 parameters must be the same for two 3DR radios to communicate, but I cannot find a fixed possible parameter value for two of these parameters (firmware version & LBT_RSSI)... can there be an infinite possible values for these parameters?
 I've tried using AT commands in the Linux terminal to change the values of these parameters, but I am getting no response at all from the 3DR ground-module... what are the proper Linux terminal commands (or other process, e.g. bash scripting) to modify individual parameters of the 3DR (USB) ground module?? Here's what I tried that elicited no response from the 3DR ground-module:
user@linux:~/MAVProxy# stty < /dev/ttyUSB0
speed 57600 baud; line = 0;
min = 0; time = 0;
-brkint -icrnl -imaxbel
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke
user@linux:~/MAVProxy# echo "+++" > /dev/ttyUSB0
user@linux:~/MAVProxy# echo "ATi" > /dev/ttyUSB0
user@linux:~/MAVProxy# echo "ATI" > /dev/ttyUSB0
user@linux:~/MAVProxy# echo "ATi5" > /dev/ttyUSB0
user@linux:~/MAVProxy# echo "ATI5" > /dev/ttyUSB0
user@linux:~/MAVProxy# echo "ATi+++" > /dev/ttyUSB0
 Could a 3DR ground-module be used to manually broadcast a heartbeat message? (e.g. using the the 3DR radio as an interface for Scapy to broadcast the MAVLink heartbeat message with rapidly changing & widely varying GPS data)
I would immensely appreciate answers to any/all of these, is it will greatly aid in conducting my experiments... THANKS!
I'd recommend you install and use mavproxy on Linux. Do this:
apt-get install python-pip
pip install pymavlink mavproxy
The to connect to the radios use:
mavproxy --baudrate 57600 --master /dev/serial/by-id/FTDI* --setup
then use +++ followed by enter to get the OK prompt
and follow the rest of the commands from the docs
Re your other questions. Firmware version is a 32 bit number, so 4 billion possible values. LBT_RSSI can only be in the range 0 to 255.
The 3DR radios are point to point, and don't currently have the concept of a broadcast.
THANKS Tridge!!! Your answers help a lot with my calculations.
Just FYI — on my system the USB ground module doesn't begin with "FTDI" in the "/dev/serial/by-id/" directory, it begins with "usb"... fortunately I know my way around linux so I easily corrected the syntax using "/dev/ttyusb0" to make it work; I just mention it in case some one else comes along and tried the exact instruction you provided and wonders why it didn't work.
 Perhaps "broadcast" was the wrong word to use then... (question rephrased) Could a 3DR USB "ground" module be used to manually transmit a heartbeat message? or is only the "air" module configured to do that? If it is possible, how would one go about transmitting a heartbeat MAVLink message from the "ground" module??
Thanks again for your time & assistance!!
Any idea why MAVproxy won't load the map module? I receive the following error message:
Unable to load module map: No module named cv2.cv
you need to install the python-opencv package.
Thanks again, Tridge! I've been using MAVProxy a lot (you're right — it's awesome)... but I've run into a confusing problem I hoped you could help me resolve...
The end goal is to monitor the latency of the network. I thought I could accomplish this by modifying your MAVProxy script — I added the following function after your "cmd_link(args)" function:
sec = 0
while sec < 900:
print(time.strftime("%Y-%m-%d %H:%M:%S", time.gmtime()))
sec = sec + 1
except KeyboardInterrupt as k:
print ("[+]Ending Data-link Monitor")
except Exception as e:
print("[!]An exception has occurred",e)
print ("[-]Unknown exit reason")
And I added the command option "monitor" from the menu displayed when the user types "help" in MAVProxy. It "works" to an extent... here's the differences between monitoring the data-link manually and monitoring it through the automated script (function above):
Notice how the number of packets steadily increases AND the packet loss (number & %) occasionally changes...
Notice how, when using my "cmd_monitor()" function (via the "monitor" command) EACH VALUE remains constant... [wtf?]
Just to show it's not always the same values, here's another run using the function:
See? Different times, different # of packets, different # of packets lost & % loss, but all constant.
How can I fix my function to get it to report the latency (via "link" command) every second for 15 minutes? Or, do you know of a better way to accomplish my goal of monitoring the network latency?
[FYI— I'm doing this so I can quantitatively compare the latency when MAVLink is not secure to when authenticated encryption is used]
Thanks for your help! So far it's been quite fruitful, but I'm having trouble in the APM code now for which I hoped you might have some guidance:
WHERE (and how) would you modify the APM code to perform an XOR on the message payload immediately following message receipt & preceding message transmission??
I thought only "mavlink_helpers.h" would have to be modified in the function
MAVLINK_HELPER void _mav_finalize_message_chan_send(mavlink_channel_t chan, uint8_t msgid, const char *packet, uint8_t length) [line 132]
for encryption, and in the function
MAVLINK_HELPER uint8_t mavlink_parse_char(uint8_t chan, uint8_t c, mavlink_message_t* r_message, mavlink_status_t* r_mavlink_status) [line 407]
for decryption... am I wrong?
The aforementioned changes can be viewed in the modified version of the file I pasted here. Again, the goal is to have the message payload XORd "in flight" (so the APM & Mission Planner would XOR it back to readable form upon receipt for processing). I'm still awaiting feedback on the required cahnges to Mission Planner from Michael Oborne (here). THANKS!!!