A customer had a line-of-sight vehicle they wanted to control over-the-horizon, and there were a huge number of challenges to overcome. It's the sort of meaty problem I love to get into:
The manufacturer, in an early meeting at their site with business and technical staff, said it couldn't be done. Latency would be too high and the controls would be too confusing for the operator if they couldn't see the vehicle.
The command and control system was designed to be connected via serial cable to the transmitter. We wanted to separate these things by an arbitrary number of miles.
Satellite technology in the early 2000s required substantial power to do anything more than a few hundred kilobits per second. I wanted to do vehicle control in one direction and video for situational awareness in the other.
During initial live testing , I found the vehicle firmware tagged all outgoing video with a TTL of 1, so it couldn't be forwarded
I couldn't make any modification to the target vehicle at all, and could only add software to the operator station, which was running an out-of-date version of windows.
I learned a lot more than I ever wanted about streaming video, serial protocols, beneficial persistent man-in-the-middle attacks, packetizing serial data as TCP/IP, satellite tracking and control, linux tools for networking and for in-flight manipulation of UDP packets, battery control of power-hungry devices not designed to be run off battery, inrush current, ground planes, and things that degrade satellite equipment or transmissions. On the non-technical side, I got lots of practice talking about technical plans, challenges, SOPs and accomplishments with executives, project leads, field supervisors, and operations personnel.
In the end, after design, lab testing, field testing and acceptance testing by the customer, it worked beautifully. I'm keeping the details off the internet for lots of reasons.
Some of the work is covered under US Patent 10407136B1