ad: M2Ant-1

Does FCC permit General+ to do "non-MORSE" CW?

Discussion in 'Working Different Modes' started by N4VDI, May 11, 2021.

Tags:
ad: L-HROutlet
ad: l-rl
ad: abrind-2
ad: MessiPaoloni-1
ad: HRDLLC-2
ad: L-MFJ
ad: Left-3
ad: L-Geochron
ad: Left-2
  1. K1APJ

    K1APJ Premium Subscriber QRZ Page

    first harmonic?
     
  2. N4VDI

    N4VDI Ham Member QRZ Page

    @K1APJ, Whoops. That's what happens when you post late at night, from your phone, in bed. :oops:
     
  3. N6YWU

    N6YWU Ham Member QRZ Page

    Not in theory. In practice.

    You can already use a single GPIO pin on a Raspberry Pi as a CW or WSPR transmitter. TAPR and qrpguys sell circuit boards with filters to clean up the 1-bit digital output for a reasonably clean (e.g. non-awful) signal on the 20M, 30M, or 40M bands. PiCW is on GitHub: https://github.com/JamesP6000/PiCW . TAPR boards: https://tapr.org/product/wspr/ .

    I've already used PiCW to send computer generated OOK Morse Code CW from a Pi 3B to a Pi 4 on 20 meters. The receiver Pi 4 had a direct-sampling RTL-SDR V3 plugged in and was running a Morse Code decoder program.

    WSPR from the Pi 3B to the Pi 4 also works, but I tested that digital mode with a more sensitive (and more expensive) Airspy HF+ SDR plugged into the Raspberry Pi 4 for receive.
     
  4. AC0GT

    AC0GT Ham Member QRZ Page

    I agree that Morse Code is Morse code but not all OOK is Morse code. The example was given earlier that there's another OOK mode called Feld-Hell. Is Feld-Hell Morse code? If it is then Technician license holders can use Feld-Hell on 40 meters. There's going to be some superficial overlap but that doesn't make them identical. We could define a new OOK mode that overlaps with Morse code but if the overlap is large enough then we just have Morse code and there's no added value to users.
     
  5. AC0GT

    AC0GT Ham Member QRZ Page

    I see the "sneaky" idea as an option one could consider, be "sneaky", or don't, or develop both ideas and let the users decide which they like more.

    One thing I'm seeing as likely is that given that there's so many IMC characters in the alphabet that there may be a coincidental overlap on what is created and what already exists in IMC.

    If there's enough superficial similarity with IMC then someone is going to get "sneaky" with it.
     
  6. AC0GT

    AC0GT Ham Member QRZ Page

    The need for a more complex interface is only needed in some cases. I was thinking of a CW transmitter and a USB SDR receiver. To transmit one only needs to figure out how to close that switch. There will be a need to do so at a meaningful rate, which may or may not be trivial. The interface for receive is a solved problem, it just plugs into USB.

    If someone has a newer model radio with a USB port then the radio interface is just software. It's a solved problem.

    If one has their computer and radio already set up for digital modes then it's just software. There will be a need for an interface but my point is that it's a solved problem.

    It is possible to decode with the built in microphone on one's smartphone or laptop, the speaker on the radio, and an otherwise quiet room. Adjust some knobs, place the radio and computer closely, and it might work. I did a bit of experimenting with that today and it didn't work so well. I'll experiment more later but it could work.

    The use of OOK for a digital mode simplifies the interface. For many cases it's already a solved problem. With OOK the need for matching the transmit audio, or even connecting it, is removed. That likely removes a common cause of ground loops.

    I'll admit it may not be a large gain on simplifying things, but the simplicity is not just in the computer interface, it's also in the transmitter. I'm probably missing something important. If so then at least it's no worse than current modes.

    The decode by ear option should not be taken seriously. It's an idea to argue that if it's possible to decode by ear then it's A1A like IMC and therefore fits the definition of what's legal for Novice and Technician. It's not necessarily to "sneak" this by the FCC. It's to demonstrate that the rules as they are now on Technician privileges are not keeping up with technology and therefore need changes.
     
  7. N6YWU

    N6YWU Ham Member QRZ Page

    You don't even need a USB port or audio cable.

    I sell a MorseDecoder app in Apple's iOS App store (shameless plug). Lots of people have reported using the app to get very successful decodes (of the computer generated W1AW code practice broadcasts, etc.) just by holding their iPhone up near their radio's speaker. (One does have to be very careful about ambient noise plus room echo or other reflection/reverb off the walls and other hard surfaces, which can destroy the S/N ratio, often a lot more than RF noise from the radio.)

    If you don't have an iPhone, VE3NEA distributes an Android version of CW Skimmer.

    Or you can also use an electric guitar adapter (or similar simple circuit) to plug an audio cable from the radio into a mobile phone TRRS jack. The cable does increase reliability, but isn't necessary in the minimal case.
     
  8. N6YWU

    N6YWU Ham Member QRZ Page

    If you go beyond the ITU specified Morse Code character set, there are a lot of other Morse Code encodings used by various other countries for CW radio communication. The Wikipedia page references Spanish, Greek, Hebrew, Russian, Japanese, Korean and Chinese code extensions.
     
    AC0GT likes this.
  9. NQ1B

    NQ1B Ham Member QRZ Page

    It's heavily mode-dependent. Modes such as MT63 have enough redundancy and error correction to usually work by holding a computer mic up to a radio speaker, or a computer speak up to a radio mic. We've seen this done over the air.

    Modes like 8PSK, on the other hand, forget it. These modes have much more effective communication bandwidth relative to the signal bandwidth, but are very sensitive to anything less than a perfect signal. We haven't even had good luck with them on VHF simplex radio paths with hard-wired audio interfaces.

    There is a smartphone app available that a ham used at a digital modes presentation. He was in the audience when I was a presenter. When I would play a short audio clip to demonstrate what a particular mode sounded like to the ear, he whipped out his phone and the app could sometimes decode the example audio clip, sometimes not. I don't know what app he used, but it shows that it is possible under good conditions.
     
  10. AC0GT

    AC0GT Ham Member QRZ Page

    While true this is using the IMC characters to send a code that may or may not be easily decoded by a human. Because of this it may no longer fit the definition of IMC under the law. We keep going over this and I don't expect this can be answered until we know exactly what the code looks like, and even then it's up to the FCC to decide if this is allowed.

    The question on if this is allowed for General and up has been answered, as far as we can tell the FCC is not opposed to uses of CW for non-IMC data so long as the method of translation is documented publicly. The question on if this is allowed for Technician and Novice will depend on this being limited to the IMC character set, and it would appear that some extensions to that set is allowed so long as it meets the standard of being documented publicly. I doubt we are going to answer that here so I suggest it best to move on, find a code that works, then we can continue that debate. If we get to the point of using it on the air then I expect that will get the attention of the FCC and they will act on it. Or not. The FCC may simply not care and let us decide.

    I agree. The ease of the radio to computer interface will be dependent on the details of the mode.

    I see three kinds of common hardware set up for this.

    The first solution that comes to mind is what @N4VDI envisioned, the use of a simple kit radio to send OOK data. I'll extend this to include any hardware built for CW only, such as something many decades old. This older transmitter might have been built as a kit or mass produced as a finished product. Reception would then be by another kit, another older CW only receiver, or quite likely (due to the ease of use and low cost) USB SDR receivers. Other receive options are variations of the next two options.

    The second option I see is some kind of kit to interface a SSB radio to a computer. These have been popular for something like 40 or 50 years, going back to 8 bit computers like the C64. The cost and complexity has varied but this is a solved problem that works for many modes, including CW/IMC, so I believe we can all expect that no matter what this proposed mode looks like in the end these same kind of interfaces will work.

    The third option is the increasingly popular SDR transceivers with a USB port. Enough said? It's a software problem after that. Perhaps not entirely trivial of a problem but something that removes a need for any more hardware.

    I mention the option of putting the microphone of a computer to the speaker of the receiver as a demonstration of this being a solved problem. USB SDR receivers capable of receiving CW on HF cost how much? $50? Less than that? After that it's just plugging it into a smartphone or whatever to run the decoding software. Anyone wanting to experiment with digital modes will have this hardware. Anyone new to this that has a radio and a computer is unlikely to need to invest more than $100 in new hardware.

    So, yes, this will be mode dependent. We both saw this work under ideal conditions so that's enough to prove the point. If that's not sufficient then there's running a wire to the computer. If that introduces issues of gain, ground loops, or whatever then there's optocouplers, isolation transformers, and so on.

    I'm still thinking that use of OOK offers an advantage over existing PSK and FSK modes by simplifying the hardware. It may not be much, it just has to be enough to gain a sustainable user base.
     

Share This Page