Demonstrating best practices that you invite other people to follow requires that you properly recognize the existing best practices. And if they are conflicting then you need to say why you picked one over the other.
When you do this you set a bar for other people to join the discussion--they will need to show examples rather than asserting the color for your bike shed.
The Snapchat Pixy was an amazing drone that we loved in my family. And sad to hear that ALL of them are now recalled for fire risk.
If you missed this chapter in the drone world, Pixy was a fun yellow and very simple flying selfie machine. It had just a mode dial and a go button. My three-year-old (and anybody's) had no problem using it and having fun.
So sad to see this erased from history. And I don't know anything like it.
Can you imagine the US Treasury saying "Um, we made a deal with Blackrock and they bought all our treasuries. It's an exclusive deal and we're not letting anyone else buy treasuries now. Oh and p.s. the price is secret."
Thanks for your interest. If you have any advice on other instructions or M1 optimizations, I'd love to hear.
My first thought is to synchronize effort of the 8 CPU and maybe even the 8 GPU. That's +12dB right there. We have a multithreaded implementation in the project already.
Just chiming in to note that "1) if your air-gapped computer has malware that can do this, you've already lost" is a problem specific to this implementation.
Other implementations exist (related work, not in 2.4G band) where it is not necessary to install malware to make measurable transmissions.
For example (shilling) https://fulldecent.github.io/system-bus-radio/ allows to broadcast just by loading a web page. And, importantly, this is an attack vector that is reasonable to execute offline (i.e. connected to a local network with HTTP services, but not the internet).