Me, personally, I would like to see the bands filled to capacity and it be common/everyday that ordinary people use 2m/70cm data modes for things besides DX’ing.
Here's an example: I was in an amateur rocketry group. One of our primary telemetry connections was wifi; 802.11b channel 1 is in an amateur band. We used directional antennas on the ground, cylindrical patch antennas on the rocket, and 1W of power (which is why we needed amateur licenses, to exceed the standard 100mW for wifi) and we could reliably communicate via standard IP while the rocket was a long distance away and breaking the sound barrier. The ESSID was one of our callsigns.
Our standard telemetry protocol was unencrypted packets, because ham radio. But a common need while debugging the rocket on the launchpad was to SSH in (it ran Linux). So our options were:
- Use something obsolete with much worse UX, like telnet.
- Use SSH and try to convince it to run without encryption, an option which is a bad idea for every other use case and which modern SSH rightfully refuses to contemplate.
- Use SSH with published keys, and hope that suffices to meet the spirit of the regulation.
- Add some complexity to the system to reduce power level while on the pad so that we weren't actually using a ham license.
- Safe the engines, go out to the pad a mile away, and hook up to the wired umbilical for debugging.
Removing the encryption restriction would allow using standard SSH and similar systems.
Leaving aside the question of whether a 3 meter tall rocket that breaks the sound barrier is a "model craft", that just says "The control signals are not considered codes or ciphers intended to obscure the meaning of the communication.". It's not completely unambiguous that SSH and other protocols qualify as "control signal" (they were not used to control the "craft" itself), nor whether they qualify as "telemetry" per 47 CFR § 97.217. This exception unambiguously gives a pass for control protocols that aren't obvious to observers on the frequency, but not necessarily for communication protocols that are actually encrypted.
Those statutes might provide the necessary exception but that's not unambiguous.
Yes unfortunately "model craft" is not defined anywhere in Part 97 that I can find.
I can't say I understand the rest of the first paragraph - Part 97 doesn't actually ban encryption, just "codes or ciphers intended to obscure the meaning of the communication", from which "telecommand of model craft" is specifically exempted.
I'm not as familiar with the Part 15 rules - do they allow high gain antennas? Since this case is about stationary command and control, I wonder if lower power + high gain wifi antennas at both ends would close the link.
I'm saying that "control signals" and "telemetry" also aren't clearly defined, and while dedicated protocols like those used to control an RC airplane are clearly "control signals", it's not obvious if SSH-over-IP-over-wifi to poke around and debug an avionics system counts as either "control signals" or "telemetry". You could make a case that it is, but it seems much closer to the line and not obviously permitted.
> Since this case is about stationary command and control
It's not; this was the same system used while the rocket was in motion, and part of the point of using the same system was to make sure it's working before launching.
> I wonder if lower power + high gain wifi antennas at both ends would close the link
We were using high-gain antennas already, and IIRC that didn't suffice within the 100mW power limit.
I've always wanted to make a ssh-telnet hybrid that sends data plaintext but with an authentication mechanism so that commands get sent in the clear, to meet the requirement that it's not encrypted, while the authentication layer prevents others from spoofing commands.
thinking about it, presharing keys and then using gpg to authenticate the message should work. just need client and server programs to make it convenient.
I'd be pretty tempted to use 70cm for some business uses if it were legal. Good range and cheap tx/rx PCBs readily available. However I'd end up using 20kb/s of data 24/7 over a large range. Can't have very many people doing that or there's no bandwidth left.
This is also the absolute worst nightmare of all the ragchew/gout-net types. The thing is [opens SDR waterfall] 70cm/2m is a wall of blue occasionally punctuated by a lonely repeater kerchunk so I'm not sure what's driving the fear.
In fact, the most reliable traffic is the one narrow APRS frequency full of generally indecipherable digital packets from all the proprietary over-landing rigs.
My inspiration has been this video: https://www.youtube.com/watch?v=dMZ8mawceuk (Building a Linux Packet Node) and inspired me to buy a used Kenwood TM-D700 to operate a packet node station.
I think something like that coupled with something like https://hamwan.org/ to route high-bandwidth traffic could be a great combo, almost like an adaptive bandwidth.
The 2m/70cm bands wouldn't be that useful for data. They are 4MHz and 30MHz (in US) wide. By comparison, Wifi is 20MHz, LTE is 1.4-20 MHz. The bandwidth wouldn't be that high for general use.
One place that extra space would be useful is for digital walkie-talkies, as an expansion of FRS.
