ARRL report - No Consensus Reached for FCC on “Symbol Rate” Issues

Discussion in 'Ham Radio Discussions' started by W0PV, Jul 17, 2019.

ad: L-HROutlet
ad: l-rl
ad: Left-3
ad: Subscribe
ad: L-MFJ
ad: Left-2
ad: abrind-2
  1. KY5U

    KY5U Subscriber QRZ Page

    You know, I saw this picture in a 4-wheeler ad and it immediately made me think of the small group clambering for bandwidth:


    Do you see it? The entire landscape defaced so two guys could go fast in their 4-wheeler. The potential hundreds who could otherwise hike, camp, or just sight-see a fairly pristine wilderness screwed for these guys' ability to speed around.
    K0IDT likes this.
  2. K0IDT

    K0IDT Ham Member QRZ Page

    If you know the early history of amateur radio, at least in the US, amateur spectrum was seen as analogous to a "national park". I can't find the reference just now, but it's out there in print.
  3. KY5U

    KY5U Subscriber QRZ Page

    Thanks. I will look too.
  4. NN4RH

    NN4RH Premium Subscriber QRZ Page


    QST January 1995, Page 106. "The Amateur National Park". Op-Ed by Dale L Bodkin.
    WE4E, K0IDT, W6EM and 1 other person like this.
  5. DL6MAA

    DL6MAA Ham Member QRZ Page

    My version of LZHUF is a SERIAL approach, much different from previously available versions.
    To my knowledge, it is the first software that allows "on the fly" decoding of LZHUF compressed messages.

    Of course, a "standard table" in the firmware could easily be adopted - but regarding pure Huffman coding,
    you need different tables for most languages, especially if you want to exploit the second order entropy
    (mutual dependencies of letters).
    For guys who want to commit frequent and severe abuse of the (email) system, it makes not much of a
    difference if 30 % or 60 % of a message can be monitored (due to technical obstacles) - both figures
    are far too high for this kind of "users".

    In my opinion, LZHUF is a good tradeoff between "readability" and efficiency of compression...

    73 de Peter
  6. DL6MAA

    DL6MAA Ham Member QRZ Page

    Yes, that reminds me of Sisyphus. ;)
    Some statements that are valid for standard compression schemes like ZIP (often combining compression and a
    CRC), do not apply to LZHUF. LZHUF is much more benign - first John, KX4O, has demonstrated that - and then
    I also had to correct some too general assumptions regarding LZHUF.
    KX4O likes this.
  7. DL6MAA

    DL6MAA Ham Member QRZ Page

    Lee, you always talk of "single bits" - implying that a single static will destroy the message.
    All modern systems use strong FEC in their radio packets, so you will receive an error-free packet,
    or no packet. LZHUF can be read up to the point when the first radio PACKET is missed.
    Average Winlink emails are quite short and most times only consist of a few radio packets.
    On a good channel missing a packet will never happen. It is only a question of SNR and
    fading - even short dropouts of the signal do not matter. Have you ever used PACTOR?
    Diversity is only a possible way of still improving monitoring of LZHUF. A single RX monitoring
    station is sufficient, in my opinion, at least if it only is about "eavesdropping" but not about
    "perfect copy".

    73's de Peter
  8. W6EM

    W6EM Ham Member QRZ Page

    I certainly do not object to your right to differ in opinion. Again, I spoke in generalities. You chose to post specific strings, etc. I didn't do that because it wasn't necessary. My point was the similarity between a form of dynamic compression and simple encryption. Who cares if it's Huffman, Markoff, whatever.

    It is the approach. How that you go about it. Would I call up your hospital and say that you shouldn't practice medicine because you made or received a phone call
    Thank you, Peter for your reply. Not a PACTOR user. Perhaps too much credit given by me and others to Muething's comments about perfect copy being needed and the inability of others who tried to monitor. Then again, they weren't using LZHUF at the time either.

    For monitors, diversity would be difficult to coordinate. Effort might be more than the average person would be willing to put out. But, capturing most, but not all would still be a lot better than now. That is, if sound card modems with the monitoring software you are developing could hold a candle to your products.

    Perhaps with the short length of most messages as you say, and the soon to increase baud rate throughput, things would be of less concern with no compression.

    I also heard that Sailmail software does not compress, but relies on use of your modem line by line compression method. How does that compare to the Winlink approach? Better throughput in lower SNR situations? Or, did I get that wrong?
  9. W6EM

    W6EM Ham Member QRZ Page

    Thanks. In my filing, it was meant to be a generalization, not a precise description. Only a fundamental concept of purely a Huffman approach. And, I can understand that "e" may not be the most often used letter in other languages, so a fixed or static tree might not be so good when applied to other languages.

    How it was/is all assembled together and combined with other concepts I did not know. Only that drops in process of reception caused corruption after that point. Which you said was mostly due to the application. My question about Sailmail's approach, if a correct assumption on my part, should yield much superior monitoring results if only packet by packet compression (your approach) is applied.
  10. W6EM

    W6EM Ham Member QRZ Page

    Real time, in process decoding will be very, very important for VM's to be able to do efficient monitoring. The "batch" approach after the fact wouldn't be that useful except for really dedicated "snoops." Somewhat embarrassing to have to "X" out credit card numbers, phone numbers and bank account numbers for Winlink abuser traffic that was used as examples. Hopefully, word will get around that it's not "private" anymore.......

Share This Page