Hi Ardupilot folks! we are developing new satellite datalink systems for the Ardupilot ecosystem. To optimize the systems we need your inputs and idea on how it should work and integrated. This is not SBD based, so the dial triggering is important to save money. Here the show description:
Looking forward to you inputs and discussions!
-Jarno
Hello Jarno,
That is an interesting product for anyone interested in long range flight outside of 4G-5G coverage and particular as a redundancy system on a C2 BVLOS configuration.
I have one question:
Is the Bandwidth of 2.4Kbps bidirectional is the absolute limit of the system?
Regards
@stephendade it might be worth looking into this a little
@stephendade it might be worth looking into this a little
Yes, I’m quite interested! I’m planning to add native Iridium support to ArduPilot and I’ve been looking for a decent module to use.
Looking forward to you inputs and discussions!
A few questions from me:
@ppoirier Hi, sorry for the late replay, didn’t got any notification.
Yes, the limit is 2.4Kbps bidirectional. The later system based on CERTUS is 20Kbit in uplink and 80Kbit in downlink. It would be better vice versa, but this is what we get 
Even with 20Kbit, a CIF or QCIF video with 3fps will be possible. Better than nothing.
@stephendade The module is the 9523 transceiver, so SBD service is an available, however useless with the dial up capabilities of the 9523. Adding native support in Ardupilot for the 9523 is not so easy but possible. What is missing in the Ardupilot/PX4 code is the right way to trigger the high latency messages when low latency link is lost. Actually the GCS is triggering it, complete useless and non sense. The best way should be either a PWM output used as a 3.3V high level, so we can trigger the dial up, or enable high latency messages on Telem2, so we can dial up as soon the messages are visible. A big issue of the high latency messages: there is MAVLink System ID!! (or I did’t have seen it). This results in no native forwarding of multiple vehicles without the need to write e dedicated protocol and a parser in the data center.
To use the system, you can use:
The VPN is between the RUDICS Gateway and our Listener (IPSEC).
What is missing in the Ardupilot/PX4 code is the right way to trigger the high latency messages when low latency link is lost
This should be doable in ArduPilot
@khancyr That would be fantastic. How we should proceed?
P.S. what would be very helpful is a MAVLink player on Windows, Mac or Linux. Very simple tool:
mavproxy should be the closest from this
Most people I’ve spoken to would prefer to trigger the SATCOM system whilst still within low-latency range, to confirm the SATCOM link is working before going out of low-latency range.
Something like a custom Lua script would work well here to detect loss of low-latency link and connect the SATCOM system if not already stated.
Can we trigger the dial up by sending commands over the Telem port? I assume it’s some AT command string?
The system and component ID are there. See Overview · MAVLink Developer Guide
Have you looked at the https://mavlink.io/en/services/high_latency.html? It’s not yet implemented in ArduPilot, but I hope to do so this year. Ideally, you would be able to use this service as-is.
For reference, ArduPilot uses roughly 900 bytes/sec (so 7.2kbit/sec) at a streamrate of 1, where as it uses 73 bytes/sec (so 0.6 kbit/sec) in High Latency mode. This should give you a feel of the telemetry requirements of ArduPilot.
I’m looking forward to the Certus system too 
@stephendade “Most people I’ve spoken to would prefer to trigger the SATCOM system whilst still within low-latency range, to confirm the SATCOM link is working before going out of low-latency range.”
This is configurable in Ardupilot with the “Explicit Handover” (High Latency Protocol · MAVLink Developer Guide). However how it really works, I don’t know.
From my feeling, MAVLink never was made for a real satellite link, as all projects are SBD and not dial up based. Dial up can be Direct IP using a Linux CC, point-to-point or RUDICS.
Lua script and so one is too complicated. The system must work autonomously for a real plug & play operation, this is what we aim for. The beySAT-LCC require a Linux CC with dialing scripts, the beySAT-MCU integrates a ESP32 that will manage all the magics.
As we aim for a FC agnostic system, triggering can be done using a high level signal or UART listening. The issue is it should work with Ardupilot and PX4 out of the box, what makes it really challenging. There is no way to set a PWM trigger on RC lost or to send the RC signal strength via PWM, so we can trigger at a specific signal. The GCS must be eliminated! The switch between the links must be made by the air unit. Using the GCS is from our point of view a non sense. Why should the GCS trigger between the links? What is the reason? All this could be very easy if the logic behind has been analyzed on how link switching should be made. And this is the Air unit.
The system and component ID is not present in the high latency protocol (Messages (common) · MAVLink Developer Guide), or is it in the “custom_mode” bytes?
To made the systems working out of the box with every MAVLink based FC, the best is to read the standard MAVLink stream, parse it into our SERaero-SAT protocol, send it down, do all the routing and blablabla stuff and reparse it into a standard MAVLink stream. All the other stuff is a fix hammer screwdriver way of trying to make it to work. Same with the Crossfire Passthrough… a nightmare!
Systems should be plug & play to let the operators and manufacturers to focus on its core business.
MAVLink between Ardupilot and PX4 is different in some ways, ridiculous!
The aim is for 100 bytes/sec with different classes of messages. I guess this discussions are very important and interesting as it gives us a real view of what you guys are looking for and we will you stay focused on your core business. Our goal is to deliver to you a plug & play system, from the air to the ground, and this is very challenging. It will be a mix of open source (MAVProxy) and closed source environments. Price is important, but reliability and easy to use more important.
another option for this would be mavlink-router.
It can already done routing and filtering, so it would need some adaptation for high latency and add log reader.
By recording what kind of log are you speaking off ? dataflash one (full log from the FCU) or Tlog (telemetry log)
But the main issue there is you want a software that does 2 really different things : routing and and log management.
We already got plenty options for routing, and that isn’t that hard to write another one : point 1 and 3
For point 2, that is something really different, and I think you should have another software that read and send back the data from a log.
The High Latency Protocol is not implemented in ArduPilot at this time. I do plan to implement it though. In terms of Explicit Handover, my thoughts are that sending a MAV_CMD_CONTROL_HIGH_LATENCY command on the low-latency link would tell ArduPilot to start emitting telemetry on any marked “High Latency” telemetry ports. It would not include any specific commands to initialise the satellite modem - that would be a additional piece of work.
SBD is the more popular, due to the modems and datarate expenses being (relatively) low. I have seen some setups using Direct IP though. Depends on the user requirements
RUDICS would be quite nice, as it does eliminate the messenging complexities of SBD and has a higher datarate.
That is not the whole packet, that’s just the payload within a MAVLink packet. If you look at Overview · MAVLink Developer Guide, you’ll see the payload field. This is where the HIGH_LATENCY2 message is packed into. You’ll also see the system and component ID fields (sysid and compid) there too.
May be I wrote something wrong. There is no need for logging.
Mavlink-router could also be used, good point. The way RUDICS works, we need to identify each system AND operator to allow to distinguish the streams coming from different air devices. The most easiest way is to use the SIMs phone number. This could be integrated in the low-latency message and configured via QGC or MP. Or we add this inside the beySAT and inject it into the stream. Doing this way, we can’t use the standard “UART Bridge Mode” where the beySAT act as a transparent bridge device between the AP and the ground mavlink-router. There are some points do define.
Ah, ok, so the high-latency message is part of the mavlink message payload. Ok, got it!
You mentioned AT commands. After thinking about it it seems a good way to interact with the beySAT. We could integrate some AT commands to listen and start what required. This implicit a modification in the AP code, lets say as a beySAT-MCU driver, similar done for the 9602 device. What do you think?
In this driver then we could add the ability to insert the SIM phone number and use it in the high-latency messages.
We need to think about the ground part. Is internet coming from a LTE/WiFi/Ethernet or via satellite, like Inmarsat BGAN, or beySAT? Maps consumes a lot of data, so this has to be kept in mind or offload maps should be used instead.
I very like our conversation as it shows what you really need 
I am a bit lost with all your terms, RUBICS, BeySAt, beySAT-MCU, ?
Do you have some documentation with some diagrams on how the system works ?
Yes, that’s a good way to do it.
All GCS’s should be able to cache maps for offline mode. In 99% of cases, the GCS will have a LTE/Wifi/Ethernet connection to the Internet though.
I should also clarify that the HIGH_LATENCY2 message is not the only MAVLink message that will be sent over the high latency link. There may be other messages sent through too. Also note that the GCS may send commands to the vehicle (mode changes, for example).
Yes, sorry!
RUDICS: Router-based Unrestricted Digital Interworking Connectivity Solution. This is the protocol agnostic dial up solution so no TCP/IP and PPP stack needed and saves its overhead = more payload. This works for microcontroller. On the ground side there is a RUDICS server that accepts each air units call so multiple concurrent communications are possible on a bidirectional way. Here we need to implement the “magic” to distinguish each remote vehicle and to send the MAVLink streams out to the respect owner.
beySAT: our Iridium satcom solution
beySAT-LCC: USB carrier board to connect the modem to a Linux companion computer and can dial direct into the internet. No RUDICS Service needed, this is optional.
beySAT-MCU: Microcontroller carrier board to connect the PX4 direct on the modem. Here you just trigger the dial command and send data. Data can be plain or AES128 encrypted (on roadmap). RUDICS Services mandatory.
May be it is worth to keep the standard MAVLink messages and parse it into the MCU, so it will work on any system? And on the AP just to implement the “driver” to communicate with the beySAT for triggering and signal strength request and other high level stuff?
Yes, that would work nicely.