I have made cronTab script checking whether or not RPI is online, and if necessary re-connects 4G network.
This is working, but i have one issue after wwan0 network is re-initiated, I’m not receiving APM UDP Telemetry data…
If i do the same test with only using Eth0 and just unplug/plug Ethernet cable, telemetry are instantly received to GCS.
I don’t know what’s happening behind the scene, but it seems like after wwan0 is going down or re-initiated, APM try to send data packets to eth0 even though no Ethernet cable is connected.
- Is there a way of restart APM UDP stream without killing the main program?
- Where does the APM UDP stream goes if connection is lost?
- Is there some kind of re-routing i can do?
Any advice is much appreciated.
Have a look at mavproxy. It is much more flexible than the APM startup options. You can specify multiple telemetry links for one vehicle and distribute the telemetry through multiple --out statements. You can also start/restart it without touching the APM. I use it like this:
APMCopter-quad -A udp:127.0.0.1:14550
this puts out the telemetry to localhost on port 14550
then I start mavproxy with:
mavproxy.py --master=127.0.0.1:14550 --out=udpin:0.0.0.0:14550 --out=/dev/ttyUSB0,57600
it gets the telemetry from localhost and puts it out over a listening UDP connection to anyone who asks for it (missionplanner UDPCI option) and also uses 3dr radio connected to usb as a backup.
I do not know what happens to UDP telemetry, if the connection is lost. APM displays “connection refused” until mavproxy is started.
Thx for the info.
I believe mavproxy requires allot of CPU (based on my previously test with mavproxy), and i cannot afford that, I need all the juice i can get.
I think this may work.
If i outputs telemetry to localhost as @schuermannsebastian suggested, then i can use udp_redirect from 127.0.0.1:14550 to GCS_IP:14550. When re-initiated wwan0 i can restart udp_Redirect. This would probably work.
I did as described above, worked flawlessly.