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

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

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

    K0UO Platinum Subscriber Platinum Subscriber QRZ Page

    All I can add is when the FCC sent 20wpm code to me for amateur licensing it was MORSE.
    The same when I took my Commercial

    AE0Q likes this.
  2. AC0GT

    AC0GT Ham Member QRZ Page

    I'm not sure if I mentioned this already, I don't recall doing so and a quick search didn't bring up, but if I did then I'll just emphasize the point. I do agree with the points made earlier on how a variable length character brings a natural and inherent "compression" to any sent text but error correction on a variable length character is very very difficult. I can recall a conversation with one of my computer engineering professors where he mentioned working on error correction on a variable length coding system and this is currently PhD level stuff. Maybe someone can figure this out but writing that up could get you a doctorate in math or engineering at a university.

    The math gets complicated real quick but the most basic problem is keeping time. If each character is the same length then a lost bit, or in this case "dit", can throw off the decoding until the computer can find something that is unambiguously a complete and error free character. If every character is the same length then an error in one character will not corrupt the next. If the timing is lost then each character offers a means to get timing back, especially with something like a start or stop bit on each bit string that represents a character.

    Using an unmodified IMC and then adding an error correction string behind it is going to be some difficult math to tackle. One modification that can help is spacing the IMC characters such that an "e" takes the same time to send as "0" (zero), or whatever the longest prosign one would want to send might be. That of course destroys the "compression". One method of error correction is to send everything 2 or 3 times. Sending 2 times and if the 2 don't match then 1 or both have an error, that gives error detection. Sending 3 times with a match in 2 of 3 has a high probability of detecting the error and correcting it. If none of the 3 match then the error can be detected but no unambiguous correction is possible.

    As many people that use IMC will point out the Mark 1 Mod 0 brain can detect and correct a great many errors in IMC, those from errors in sending and those from noise and fading. Modern computers with spelling and grammar check can offer this same FEC with plain English text. As we have all no doubt have experience with these systems, I have no doubt because you are using one such system now to read my comment, the quality of this FEC can be lacking.

    I don't believe I'm repeating too much here. The main point is that I had a subject matter expert telling me that error detection and correction on variable length codes is far from trivial. Rather than trying to think up some error detection, with or with out correction, it's likely just better to send everything more than once.

    We've discussed the option of different variations on the theme to add optional behavior. By using OOK as the underlying modulation the backward compatible "fallback" mode is by default IMC.
  3. AF7TS

    AF7TS Ham Member QRZ Page

    You've made a good point about the math of FEC on variable length characters. My partial counterpoint:

    If you are seeking the 'optimum' FEC code on variable length characters, then you are looking at some hard math. But if you are willing to accept less than optimal use of bandwidth for the sake of ease of use, then you can use much simpler math.

    As I've described before, you can represent IMC as a simple bit stream. A 'dit' is '10', a 'dah' is '1110' between letters you add '00' to get 3 '0's in a row. Between words you add '000000' to get 7 '0's in a row.

    Set a fixed 'frame size' of so many 1s or 0s, and then you could use an existing FEC technique for that frame size.

    For example you could have a frame size of 247 bits, which could represent 61 'E's or 11 '0's coded in IMC. Add 8 parity bits (which would not be in IMC) and you've 'protected' your fixed frame using a standard Hamming code. Represent your 8 parity bits as a string of alternating I's and T's, and you need 32 bits but now your text and your parity check are all valid IMC.

    N6YWU likes this.
  4. AC0GT

    AC0GT Ham Member QRZ Page

    That sounds logical at least on the surface. I'm smelling hints of PSK31 and Ethernet frames. If you are building a frame for some kind of parity check and/or error correction at the end then you'd likely need a header to give the starting point for the math at the end, including length of the frame, and maybe the type of the frame if we are going to have some optional features. If the header includes a to and from field then it's looking a lot more like an Ethernet frame.
  5. N4VDI

    N4VDI Ham Member QRZ Page

    I concur that trying to deal with variable-length symbols is really hard.

    Hell, even dealing with the brief loss of state from a single-bit drop-out in MFM will basically derail your decoding until the next unambiguous '1' bit (with a low-high or high-low transition halfway), because without knowing the value and end-state of the previous bit, you can't discern whether the next pair of bit-states are valid or not.

    When I worked on it on Saturday night, I ended up marking subsequent bits as 'unknown' until I finally hit an unambiguous '1'... then worked backwards as far as I could to determine which of the previous (provisionally-unknown) bits were plausible given what I then knew about the following bit high/low states. It helped, though... I went from having a single drop-out cascade into 3-4 lost bits in a row, to usually recovering at least the last bit before the next one.

    Illustrative example. Each +/- means "no carrier" or "carrier", and each pair of them, interpreted in the context of the surrounding states, encodes a binary 0 or 1. The leading number in parentheses and +/- indicates the state of the carrier at the end of that bit:

    (0+)--++---+= 00001
    (0-)--++---+ = 0???1 when I parse forward, but 0?001 after I backtrack.
    (1+)++--+++- = 10101
    (1-)++--+++- = 1???1 when I parse forward, but 1?001 after I backtrack

    With variable-length symbols, I would have been completely dead in the water for several bits after losing the first. At least with constant-length symbols, I could backtrack to re-establish context since I knew where the boundaries were supposed to be, even though I couldn't SEE them, and knew at least one of the observed states was corrupt. If I lost my context AND sense of time, I would have lost quite a few more bits from even a single bit of fading/noise.

    Of course, my present algorithm is still being excessively optimistic about the likely correctness OF the next-observed 1-bit (defined by a low-high or high-low midpoint transition), but with variable-length symbols, it only gets worse from there.

    Now, one possible compromise to mangle Morse a little bit in a way that would make it very unpleasant and difficult for humans to copy, but make it easier for machines: reduce the ratio from 1:3 to 1:2, then pad the silence between dots and dashes so that BOTH dots AND dashes occupy three "ticks" apiece

    dot = high, low, low (short tone, long silence)

    dash = high, high, low (long tone, short silence)

    This is basically the encoding method used by things like common wireless temperature & humidity sensors. I've seen it called "biphase mark-space" in a few places, but it honesly seems to be a coding scheme that everyone recognizes... but nobody actually knows the proper canonical name for it (Wikipedia itself vaguely dances around the topic within several related articles related to line coding, with at least one article I recall that had a waveform image that appeared to flat-out contradict the adjacent paragraph describing it).
  6. NQ1B

    NQ1B Ham Member QRZ Page

    We're discussing an easy-to-implement, robust mode in this thread. Why make it harder by using variable-length symbols? Just decide what length you need and pad everything to that length.
    AC0GT likes this.
  7. N6YWU

    N6YWU Ham Member QRZ Page

    The dot times are not variable length. Just make sure a dash is exactly 3 dot times using standard Morse Code timing, etc. The framing header or trailer can include the packet length in dots with it's own FEC. Then FEC all the dot windows.
  8. AF7TS

    AF7TS Ham Member QRZ Page

    Good point, the whole reason for this project is to keep things simple.

    The counter argument is that using 'variable length symbols' might make the entire project easier.

    I read N4DVI's project as a simple, robust keyboard to keyboard mode that uses OOK. Making IMC or Varicode part of that mode _might_ be enabling if using such permits use of existing tools. Or it might make the project more difficult. Hell, maybe the best approach is to use OOK as the physical layer for blog standard packet radio, and then put FEC on top of that. That would permit the use of lots of existing software work. Since N4DVI is doing the actual work, in the end it is their call.

    I _hope_ that my idea flinging in this discussion is providing useful input, but admit that this is a fun hobby and I am a novice in every aspect of real experience (despite what the FCC might think.)


Share This Page