Ted Rappaport and others may have perfectly legitimate concerns concerning the use of the Winlink suite of applications, but to voice dissent regarding the FCC’s attempt to remove the silly 300 baud data HF speed limit due to what an application may or may not be doing, is not appropriate given the different nature of an application layer and data/physical layer in the communication hierarchy.
What follows are my comments to the FCC concerning WTB 16-239…
I agree with the FCC’s proposals outlined in the FCC WT Docket No. 16-239 (FCC-16-96A1.pdf) document as this only effects issues in the equivalent Data Link and Physical Network layers (aka Modems and Transceivers) of communication in the amateur radio bands and removes the baud rate limit nonsense. The ambitious invitation to innovate with reasonable constraints imposed by 97.309(a)(4)…
“(4) An amateur station transmitting a RTTY or data emission using a digital code specified in this paragraph may use any technique whose technical characteristics have been documented publicly, such as CLOVER, G-TOR, or PacTOR, for the purpose of facilitating communications.”
…and left unchanged in the FCC’s proposal is sufficiently broad to provide ample opportunity for ground breaking DSP based modems using, for example, PACTOR 4 modulation to operate legally in the USA upon complying with the documentation requirements. It remains to be seen if proprietary portions kept as trade secrets comply with 97.309(a)(4), but so long as the raw data streams between the modems can be copied by a third party with the same brand or type of modem, the requirement to not obscure data is achieved.
I respectfully request the FCC to consider adding 97.309(b) to the proposed 97.307(3) to read…
“(3) A RTTY or data emission using a specified digital code listed in § 97.309(a) of this part may be transmitted. A RTTY, data or multiplexed emission using an unspecified digital code under the limitations listed in § 97.309(b) of this part also may be transmitted, provided the bandwidth does not exceed 600 Hz.”
…to incentivize proprietary innovation for new shortwave radio digital communication techniques by industry. Competition in this unique product space is woefully inadequate and the above rule proposal will help stimulate such development.
Concerning Winlink:
There are many complaints concerning the use of Applications that may encode the data streams outside the Data Link and Physical layers. The Winlink suite of programs are an often cited example. The complainants’ point is very well taken, but their frequent efforts to blend an encoding/encryption problem of the application data stream with the modem/radio system that passes it, unnecessarily burdens the modulation method addressed by 16-239. It is my opinion what an application does to allegedly obscure the meaning of a stream of data has nothing whatsoever to do with the data emission techniques be it CLOVER, PACTOR(1,2,3,4), Robust Packet or good ol’ AX.25.
Thanks for your take on this. If I read it correctly, you advocate removing the Baud Rate limit, but imposing a limit in Bandwidth to 600 Hz. That seems very reasonable. I think the concern of many is that the current recommendation appears to support the introduction of unlimited-bandwidth emissions in the traditionally narrow-bandwidth CW/Data portion of the HF Ham Bands. I am not opposed to removing baud-rate limits, but there needs to be protection of a portion of the Bands for CW and narrow-band data modes.
Perhaps we should reconsider alignment of Band portions for signals with similar Bandwidths, instead of the end use (voice or data) of the signals. After all, everything including voice is moving toward digital. At some point, it will all be Bits.
The FCC isn't making it easy, but if you follow the winding path of restrictions set by reference to other mode limitations you will see they say unlimited bandwidth for only a short list of approved/published/etc. modes. I wanted to open this up to completely experimental and, yes, profit driven, modes, but with the 500-600 Hz limit. So unlimited bandwidth for the elsewhere limited list of modes, and 500-600 Hz for anything at all. I think I said 500 Hz on the actual FCC application because of a typo, but you get the point.
Of course my larger point is to not mix Layers 7 and 1 into the broader demonization of Winlink. There are responsible ways to use broad bandwidth digital modes… especially when it can finish the transfer faster and then stay out of the way for a good while. Think of it as TDMA in super slo-mo… something stunningly ignored by some in the anti Winlink parade. I'd rather not see one application's alleged abuse of the digital landscape needlessly demonize the mode used during the data transfers. It's quite unfair to the modem designers be it SCS or open-source soundcard techniques. I have no dog in the hunt for Winlink. They can fight their own fights. Consider me a "mode warrior."