That's what should work for the ardupilot. I'm probably getting the Dronecell in the spring, i'll write back here about how it works.
Today, I did three flights with Dronecell telemetry.
Currently, APM did not init it, I started the UDP connection using another electronics, then hot-connected it to APM, and flew.
If a competent, good programmer with APM knowledge would help - we could get this integrated into APM.
ok - who can add code to make APM send some lines of text during boot, to configure Dronecell, before the port is used for telemetry ?
order should not be very important, since MAVLink does contain checksum/integrity verification.
Order is absolutely critical. Unless lots of re-try logic has been implemented in the GCS sending packets out of order will not work...at all. Checksum does not fix the order in which data is sent and I highly doubt the APM or the GCS have this logic fully implemented. TCP is clearly the right way to go if you want bi-directional data. If it's just flowing from the plane to the ground then UDP will work fine.
in one packet - one parameter could be set - next packet could ask back a readout of that parameter - unless sent==current, resend - VERY simple logic that GCS could easily do,
You are right. Very simple logic. Very complicated to implement. You'll need to look at the code for the GCS and for the ArduPilot to confirm this has all been implemented or else you're in for a LOT of extra coding. It's incredibly easy to say. It's very complicated to code as you have to add timeouts for everything. Every command that gets sent you have to send it and then start a timer and wait for a reply. If nothing arrives in a pre-defined period of time, then you have to ask again. Then you have to deal with two packets that arrive with the same data since you've now asked twice. Timeouts for every command that's sent, lots of extra coding to handle packets out of order.
There is no reason to do it UDP instead of TCP.
"There is no reason to do it UDP instead of TCP."
Yes, there is. - GPRS have limited capacity, there's no need to resend all telemetry (position etc) packets all the time - if last position, altitude, heading,battery voltage is lost, no reason to resend it - that information is old already.
Also, TCP connection is more sensitive to really crappy GPRS connection, and takes more packets to establish, while UDP ... just send it... if you get thru 1 of 3 TCP packets - you lose connection soon, (retransmission will take slow down even more) - if you get thru 1 of 3 UDP packets, you can still see get some information.
Sure - I could make TCP just as easy, but then the Planner should get support to act as an TCP server too, (it's currently only a client)
Then be prepared. MAVlink is a bi-direction protocol. Packets out of order will most likely be handled poorly and may cause a crash in the program. TCP is the right way to do it. As long as you know you're taking the very real risk of crashing your GCS...and possibly your autopilot....go for it. Your GCS crashes, you re-start it and then the autopilot is possibly bogged down with downloading parameters for the next few minutes? Clearly not worth the risk.
ok, besides criticizing what I did - you did not even check if the APM or GCS does a sanity check for incoming data ?
besides, I log to home - not sending data from GCS to AP - simply because I mostly use it to log - not fly by it - yet.
That's up to you. I'm just pointing out your mistake. Good luck!