Lots of no-name or DIY drones use flight controller running a BetaFlight [1] firmware, which is open source and quite hackable. If you want low-level real-time programmatic control (like manipulating servos, lights or camera), that is most likely the easiest way. There is also ArduPilot [2] firmware, which is focused more on the high-level control (like managing GPS waypoints and autonomous takeoff/landing).
In both cases you can piggyback your control signals using standard radio or use serial port via dedicated wireless bridge.
It's probably the wrong place in the stack to implement this, these are very low-cost commodity microcontrollers running the firmware and the design of flight controller software is focused on time guarantees and reliability.
With the exception of low-cost consumer drones, most larger drones have at least a "Flight Controller" (embedded MCU handling guidance, navigation, and control) and a "Flight Computer" (Higher level *nix based computer running autonomy software), and the flight computer is IMO a more appropriate place to put this.
You could encrypt any Mavlink or proprietary protocol at the application layer if you're using an IP link, or you could also just rely on the telemetry radio to perform encryption between the drone and your ground station.
BetaFlight doesn't deal with over-the-air bits, it just receives PWM/PPM/S-Bus/whatever signals your receiver provides. There is no point to have encryption in firmware, because connection between RX and FC is hardwired and can be trusted.
Lack of OTA frames encryption, as far as I can tell, is mostly due to legacy reasons. In DYI FPV there are only couple of transmission standards, most of them using 2.4GHz FHSS or some CC2500 clone so you can mix-and-match transmitters and receivers as you wish. If you use custom TX/RX devices, you are pretty much locked in to that specific vendor. Also, designing a nice transmitter UX-wise requires quite a different skillset than designing nice transmitter RF-wise, so manufacturers tend to choose off-the-shelf RF modules.
The threat model for most FPV pilots (either hobbyists or people in Ukraine) doesn't really include hijacking of the air link. It's trivial to just shoot something down with interference, sometimes inadvertently.
Pretty much everyone in FPV is now using ExpressLRS, which is an open protocol. If you want an encrypted air link, then the best option I'm aware of is the proprietary TBS Crossfire protocol.
Betaflight doesn't really care about what Radio receiver you're using - as long as it can talk to it over uart (/SPI) via one of its supported protocols like crsf, ibus, sbus etc..
If you really want encryption, you can simply use a PiZero that talks CRSF to Betaflight and has an encrypted channel to your ground station over 4G LTE/Wifi/Wfb-ng/what not.
But if you're dealing with 4G and PiZero, might as well use Ardupilot + mavlink. Those tools already support this use case much better.
Betaflight is more of a proximity racing drone kind of use case. Only recently did it's GPS return to home functionality got some improvements.
Crossfire supports encryption.
Mainline ELRS can't add encryption support because the whole idea of ELRS was to reduce LoRa packet size to the bare minimum needed for 4 full res channels + a bit extra for arming and time multiplexed aux channels. There's some discussion on protocol security and scope here [0].
I'm sure these days there are multiple LoRa based links (independent and ELRS forks) that support authenticated encryption.
I think ciphering is not always allowed on remote control hobbyist bands. Some jurisdictions allow stronger radio output in exchange for such restrictions.
That and lack of demand. Most people are nice, key management is PITA, losing expensive toy from a crypto library bug is going to be frustrating.
WPA2 should be still strong enough for most purposes too(threat_model != CIA).
> people who blindly click OK on every pop up are not representative of your typical user
You could unbias the data by including the metric determining how long did it took them to click "Ok" and whether they actually reviewed the data before agreeing.
Same here on using lsyncd and restic. Curious about the LVM+rsync method for nightly? My two cents: ReaR (Relax and Recover) for Linux for raw moving servers has saved me a couple of times.
Is the drum rotating smoothly at constant RPM, or is it stopping briefly (using gears [1] similar to those found in analog movie projector) when hammers hit the paper to prevent them from tearing it?
the drum or similarly the chains used on the hammer printers were in constant motion.
I am just old enough that I had to repair both types at the beginning of my career. Although typically rebranded Data Products and other OEMs, which I am probably wrong but vaguely remember being a supplier for the DEC L20?(maybe). But different than this printer.
To these hammer action printer, the ribbon and the paper weren't even a consideration.
If you have a Newton's cradle, put a piece of paper between the inner balls and it will still mostly work if you release a single ball.
The high speed drum printers they typically had to rotate twice for each line (at minimum) so a 600lpm printer would have the drum rotating at about 1200rpm.
If you look at the video posted in another comment, you can see the ragged vertical alignment of the chars. IIRC that is why IBM preferred chains in their hammer printers, because the human eye was more forgiving of vertical misalignment compared to the vertical misalignment that was a natural result of the mechanical differences.
It looks like a regular line printer where the drum keeps spinning. See wikipedia:
>Because the drum carrying the letterforms (characters) remains in constant motion, the strike-and-retreat action of the hammers has to be very fast. https://en.wikipedia.org/wiki/Line_printer
In both cases you can piggyback your control signals using standard radio or use serial port via dedicated wireless bridge.
[1] https://github.com/betaflight/betaflight
[2] https://ardupilot.org/