Nope, if you can connect directly with the serial port, then it is OK.
Ok, so your radio connects to the usb port, and emulate a serial interface.
Then you tries to pull up a ser2net on this to provide network interface. right.
Can mavlink router work on a mesh network? I am routing UDP through a mesh. I am also quite new to all of this, and the smart radio uses Openwrt…which is a non standard debian distribution. I am not sure how to connect the radio to the internet and download a package, how would I get mavlink router onto this radio?
@Eosbandi unfortunately not. I saw it again today. Now when the smart radios are setup to use UDP mavftp doesn’t even work. Have to use TCP for things to act properly.
yeah, if the udp packets are aligned, there was never an issue, its just that the non mavlink aware radios can send like 5 bytes of part of a packet, and MP was screwing up the buffering
@Michael_Oborne Hi Michael. Aaron from Doodle Labs. Thanks for your work on patching Mission Planner. A number of Doodle Labs’ customers have reported that the fix in your latest Beta update solved the MAVLink packet drop issue when used with our radios. Will it be available in your next main release?
yes, it will be in the next main release. there is no plan at the moment for the release, but knowing this i can move it forward a little. but need to tidy up a few pending items first.
Hey @Michael_Oborne, I’ve been running into a similar issue with significant packet loss over UDP. I’m running a similar setup to Evan with a doodle being fed serial and using ser2net to get UDP down. MP is on 1.3.79. I’ll pm you a wireshark capture. I can see that there are some partial packets but I’m not sure how to verify that your MP fix should handle it or if I need to adjust the ser2net setup or other radio settings.
So some confusion but good news on this. I don’t think I changed anything and for the first time with these doodles that have been on a couple of platforms it seems that FTP is working for the param grab and it now takes under 10s. I got the common.xml message wireshark plugin working to see the packets.
There are still a number of UDP packets that the parser plugin doesn’t recognize but everything seems to be working better. Also, the two destination port issue is gone. I may have had MP and mavproxy open. I can send the wireshark capture but I assume the unknown messages are a combination of partial packets which you said MP should be able to handle and messages not in common.xml.
Since I’m not sure what “fixed” it, if (when) the behavior happens again and I can pin down a cause I may be back.
Hi @Michael_Oborne ,
I am also facing similar issue, I see multiple CRC errors in Mission Planner, Link quality fluctuates between 30-60℅. Can you let us know what was the fix…
the max pkt size my telemetry radio can take in 250 bytes.
Right now I am running SITL at one end and sending the data via the Telem-Radios and on another end 2nd Radio is connected to Mission Planner(version 1.3.80).
I debugged further…I had a doubt that my transmited pkt and received pkt has error.
So I basically wrote a simple python code and tested if my transmitted pkt is same as received pkt.
I sent random 250 byte data via uart-1 interface and read back data on uart2 interface and did a compare.
I see there … transmitted pkt and receive via lora are same. So no issues here…
Ran tests with multiple PKT size starting from 64 byte to all the way 250bytes.
Tested with 10,000 pkts also… Results came similar…
7 error and 9993 ok.
So I have ruled out the issue of telemetry module having issue.
However
When my pkt size exceeds 250 bytes Let’s say (254 bytes)[ Telemetry firmware I am running can handle max 250 bytes]
I see the last 4 bytes chopped off and coming as the 1st 4 bytes of the next received pkt.
My telemetry module is Mavlink un-aware… I am posting this as similar issue with Doodle Labs was addressed here…
I tried with different versions of Mission Planner ; latest 1.3.90[zip] this didn’t connect at all…
1.3.80 is what I have installed : this connects quickly does Mavlink ftp @param.pack
1.3.75 does attempt mavlinkftp but shifts to requesting individual sensor data.