Just say NO! to Winlink expansion!

There's lots of pro and con here (53 pages).  I've read all of the posts (skipping the personal attacks) and tried to understand all of them.  Since I'm an admitted "digital dummy", I will also confess that I don't understand the finer technical points of the debate … which has evolved from WinLink/pactorIII to other digital signals.  My opinions represent my limited experience and knowledge of digital signals in general.  My “on-the-air” observations are also reflected here.  
    Here's my position(s) after considering all I’ve read and witnessed.  
1) I'm strongly opposed to "email over ham radio" on any band or mode.  I don't think it belongs in ham radio.  It appears to me to be a purely commercial application and belongs in that arena.  It may have application on our frequencies in emergencies but, should be restricted to  emergencies only.
2) I'm opposed to digital signals in the same band segments with analog signals.  I don't think they can co-exist peacefully.  
3)  I’m opposed to “automated/semi-automated” stations operating anywhere in the ham bands except in designated segments … separate from other modes. The potential for interference is far too great and I don’t believe any software, now available or in development, will be able to detect a “busy” frequency with enough accuracy to prevent interference.  An operator must be present to listen for other signals.  I don’t believe software will ever be as good as the human ear for that task.   To those who would argue with that statement … Show Me (as in demonstrate).  
4)  Digital voice may be the coming “thing” in ham radio but, I don’t think it’s “here” yet … and may not be “here” at all.  I’m not convinced that digital voice is equal to SSB when it comes to “making the contact”.  I worked a DX station last night that was S3.  I doubt digital voice could have made that weak signal contact considering the QSB, QRN, and signal strength.  Don’t bother arguing with me … Show Me (as in demonstrate).  
5)  I don’t think it’s time to re-make the current band plan.  Therefore, I’m opposed to the most recent ARRL band plan proposal and will notify my ARRL regional director.  The number of hams currently involved in digital signal operations does not justify a complete remake/replacement of the current band plan.  Not until participation increases to a level where digital signals out-grow the allotted segments (i.e. significant popularity increase) should we consider altering the band plan.  

One More Thing …. I think I have a solution to the mode compatibility issue.  There’s been a proposal by ARRL to “re-farm” the Novice segments so, rather than make more room for SSB, etc., I suggest that we designate those segments to digital modes.  It will provide more frequencies/space than they have now and solves the problem of interference with analog signals (which are currently far more prevalent & popular).  

No, I didn’t forget about 20 meter or other bands where there are no Novice frequencies.  You guys figure that one out .. my head aches enough already.  

My 3 cents.
Garry
N5GLR

 

n5glr:
"One More Thing …. I think I have a solution to the mode compatibility issue. There’s been a proposal by ARRL to “re-farm” the Novice segments so, rather than make more room for SSB, etc., I suggest that we designate those segments to digital modes. It will provide more frequencies/space than they have now and solves the problem of interference with analog signals (which are currently far more prevalent & popular). "

Nice thought Gary!!!

I'll have to look into this one. If the additional spectrum is needed for EXPERIMENTATION, as the ARRL claims, then you don't need spectrum on every band. Just enough spectrum to meet propagation needs.

If this looks good I'm going to email my director with it.

This is what the ARRL should have done from the beginning - many heads are better than 5 in coming up with viable solutions!

tim ab0wr

 

For some rather obvious reasons, your statement is without merit.

Consider the coding:

If a bit of speech that occupies 0.25 seconds is encoded in a 2400 bps stream, it follows that about 600 bits have relation to that speech. If a bit of speech that occupies 0.25 seconds is encoded in a 600 bps stream, it follows that about 150 bits have relation to that speech.

Consider the impact of a noise burst:

As an EXAMPLE ONLY: The size of an LPC-10 block is 54 bits. If we double that, we have 108 bits. A hit on a DOUBLE block will impact 108/2400 = 0.045 seconds of speech.

From these facts, it is quite evident that decreasing the number of bits DOES NOT increase the size of the "hole" caused by an error - or by a block of errors.

It should also be extremely evident that the size of the "hole" is equal to the size of the block for a burst noise. For a prolonged noise that impacts the recovery, the "hole" is equal to the number of blocks impacted.

OK, all hams are now appliance operators? I don't think so!

I would encourage EVERYONE with an IDEA to investigate a) what voice actually is, b) the critical aspects of voice, c) how voice is NOW encoded, and d) how voice CAN be encoded. The first thing I will advise is to throw ALL existing methods out the window, and to start with a fresh approach.

I am working on an implementation of an idea that I have had for a number of years. It is a radically different approach, but in several years of (very) part-time research, I have seen nothing to indicate that it cannot work.

Some "NEWBIE" ham may have an even better idea. The only thing I can promise is that rubbing one's hands and saying "CAN'T WORK" is a guaranteed mechanism to provide failure.

Reminder:
In the 1800's the nations "most eminent scientists" were agreed that the human body could not withstand a speed in excess of 30 mph. They had brilliant mathematical proofs to back it up. Then a train exceeded 30 mph, and everyone was still alive.

Two points:

1. If everybody had believed the "most eminent scientists", nobody would have tried to go faster than 30. (Thank God no politician outlawed it before someone went faster!)

2. Many of the people who created our most widely utilized and practical inventions/breakthroughs were NEITHER engineers NOR scientists. They were inventive AMATEURS in their field. Edison (drop out and tinkerer). Einstein (patent clerk). Marconi. Hertz. Ad infinitim.

First of all, what part of "reduce the bit rate" was not clear?

Secondly, the "bandwidth" in question (for the modem) is the bandwidth of the input filter for the SINGLE tone or SINGLE tone pair. I can have multiple tones/tone pairs, each with its own input filter.

There will probably be a series of "there first" products before the "there right" products hit the market. The tests on a single ill-conceived product prove nothing.

Good digital voice requires a good voice process, a good protocol, and a good modem. Take away ONE element, and results wil be disappointing. The current product is by a company with an ancillary set of skills in ONE area.

1. If one uses a good modem design, each tone (or tone pair) will have a bandpass filter. That sets the modem SNR.

2. The AVERAGE level of the modem signal is also its PEAK level. The average level of human speech is primarily a function of the VOWEL sounds - which contribute very litttle to intelligibility. At the point where both signals peak at 6 dB (voltage) or 3 dB (power) above the noise, the analog signal will be difficult to impossible to copy, as the CONSONANT sounds - that are ESSENTIAL for intelligibility will become indistinguishable. The modem signal will have a 6 dB SNR at that point.

(The consonant sounds are typically at least 12 dB below the vowel sounds - even in heavily processed speech. For unprocessed speech, expect 16 dB to 25 dB below.)

 

In point of fact, I exactly answered your entire point with highly accurate technical facts from working systems.

In point of fact, I fully expect digital voice on the ham bands to be usable WELL BELOW the noise level within 10 years. The BER rates achieved and the factors cited make that a pretty safe bet.

All we need are some people who want to create a SYSTEM. That means a well-designed modem, a well crafted transmission protocol, and a lower bit-rate algorithm. We can use something like LPC in the short term, but it is NOT a "final answer".

Even with LPC, we can transmit with no significant voicing errors if we develop a decent modem and transmission protocol.

I have given VERY ample free hints in my posts - including a fairly detailed "how to build a modem and protocol" posting in this thread. Someone should have developed a really good idea of both the issues and the solutions by now. (And I can add some data to fill in the blanks for the right people!)


RE: Reduce power

The EXACT argument would be made that these radios cannot possibly support SSTV, RTTY, or SITOR/AMTOR mode B. Gee, the argument must be wrong, because they DO support those modes - and are used in them every single day.

Same EXACT issue. Same EXACT solution. (And LOTS of hams have added a fan to those radios to ensure cool operation in those modes.)

 

wa5ben:
"For some rather obvious reasons, your statement is without merit.  
Consider the coding:
If a bit of speech that occupies 0.25 seconds is encoded in a 2400 bps stream, it follows that about 600 bits have relation to that speech. If a bit of speech that occupies 0.25 seconds is encoded in a 600 bps stream, it follows that about 150 bits have relation to that speech.

Consider the impact of a noise burst:

As an EXAMPLE ONLY:  The size of an LPC-10 block is 54 bits.  If we double that, we have 108 bits.  A hit on a DOUBLE block will impact 108/2400 = 0.045 seconds of speech.
From these facts, it is quite evident that decreasing the number of bits DOES NOT increase the size of the "hole" caused by an error - or by a block of errors.

It should also be extremely evident that the size of the "hole" is equal to the size of the block for a burst noise.  For a prolonged noise that impacts the recovery, the "hole" is equal to the number of blocks impacted."

Larry, if I have an amount of information X to send (i.e. .25 seconds of speech) and in one format I encode that into 600 bits and send it at 2400bps and in the other format I encode the same amount of information into 150 bits and send it at 600bps, then which format has more information per bit?

Which format can better withstand the loss of some of the bits?

In one format I have (.25sec)/(600bits) = 4.2E-4 sec/bit and in the other I have (.25sec)/(150bits) = 1.7E-3 secs/bit

If I lose a double block of 108bits at 2400bps I lose .045 seconds of speech. If I lose a double block of 108 bits at 600bps I lose .18 seconds of speech.

Which one represents the larger "hole" in the speech pattern?

wa5ben:
"OK, all hams are now appliance operators?"

Don't put words in my mouth. I didn't say this. HOWEVER, now that you mention it, just how many hams today have the math skills and have available to them, on an inexpensive basis, the
resources to build digital encoders and associated modems and turn the result into a commercial proposition?

The answer is - very few. If you think enough hams exist that will build compatible equipment from scratch to make digital voice into a real threat to SSB within the next decade then you are not in touch with reality.

wa5ben:"  I don't think so!"

Really? Just what percentage of hams today do you think are running homebuilt SSB transmitters? Or even DSB transmitters. This can be done cheaply and easily yet the majority of hams don't do it. And you think even a small minority will build digital voice encoders and modems from scratch? Wow!

wa5ben:
"I would encourage EVERYONE with an IDEA to investigate a)  what voice actually is, b) the critical aspects of voice, c) how voice is NOW encoded, and d) how voice CAN be encoded.  The first thing I will advise is to throw ALL existing methods out the window, and to start with a fresh approach. "

Sounds good. But it's not something thats going to bear commercial fruit in the near future.

wa5ben:
" am working on an implementation of an idea that I have had for a number of years.  It is a radically different approach, but in several years of (very) part-time research, I have seen nothing to indicate that it cannot work.
Some "NEWBIE" ham may have an even better idea.  The only thing I can promise is that rubbing one's hands and saying "CAN'T WORK" is a guaranteed mechanism to provide failure."

You've just admitted you've been working on it for a number of years. I suspect it won't be any different for most hams.

No one is saying that the research shouldn't be done or even saying that it is impossible. That is just another strawman you have set up so you can knock it down. What we are saying is that the ARRL crying "Wolf! Digital voice is about to take over the phone bands!" is a crock of ....., to put it bluntly.

wa5ben:
"First of all, what part of "reduce the bit rate" was not clear?"

Larry, what part of "I can find nothing that indicates there is anything on the horizon that will allow this." was not clear?

wa5ben:
"Secondly, the "bandwidth" in question (for the modem) is the bandwidth of the input filter for the SINGLE tone or SINGLE tone pair.  I can have multiple tones/tone pairs, each with its own input filter."

Shannon's Law addresses *channel capacity*, not filter width for a single tone. If you want to talk about the channel capacity for a single tone you can do that but don't relate it to the overall bit rate for a combined set of tones.

wa5ben:
"Posted on June 02 2005,20:38
------------------------------------------------------------------------
Quote (ab0wr @ June 01 2005,17:44)
wa5ben:
"The goal is to REDUCE the bit rate.  Reduced bit rate means reduced bandwidth and slower baud rate, which means lower error rates.  It also means lower noise, which means our minimum detectable signal is lower - meaning greater range."
As I've found in my recent research, this also causes bigger holes in the voice when an error DOES occur. That causes problems all of its own.
tim ab0wr
For some rather obvious reasons, your statement is without merit.  
Consider the coding:
If a bit of speech that occupies 0.25 seconds is encoded in a 2400 bps stream, it follows that about 600 bits have relation to that speech.  If a bit of speech that occupies 0.25 seconds is encoded in a 600 bps stream, it follows that about 150 bits have relation to that speech.
Consider the impact of a noise burst:
As an EXAMPLE ONLY:  The size of an LPC-10 block is 54 bits.  If we double that, we have 108 bits.  A hit on a DOUBLE block will impact 108/2400 = 0.045 seconds of speech.
From these facts, it is quite evident that decreasing the number of bits DOES NOT increase the size of the "hole" caused by an error - or by a block of errors.
It should also be extremely evident that the size of the "hole" is equal to the size of the block for a burst noise.  For a prolonged noise that impacts the recovery, the "hole" is equal to the number of blocks impacted.
Quote

You are also making the assumption that there is or will be equipment available very soon that can encode higher amounts of information in the same or lower number of bits that we use today.
tim ab0wr
OK, all hams are now appliance operators?  I don't think so!
I would encourage EVERYONE with an IDEA to investigate a)  what voice actually is, b) the critical aspects of voice, c) how voice is NOW encoded, and d) how voice CAN be encoded.  The first thing I will advise is to throw ALL existing methods out the window, and to start with a fresh approach.
I am working on an implementation of an idea that I have had for a number of years.  It is a radically different approach, but in several years of (very) part-time research, I have seen nothing to indicate that it cannot work.
Some "NEWBIE" ham may have an even better idea.  The only thing I can promise is that rubbing one's hands and saying "CAN'T WORK" is a guaranteed mechanism to provide failure.
Reminder:
In the 1800's the nations "most eminent scientists" were agreed that the human body could not withstand a speed in excess of 30 mph.  They had brilliant mathematical proofs to back it up.  Then a train exceeded 30 mph, and everyone was still alive.  
Two points:
1.  If everybody had believed the "most eminent scientists", nobody would have tried to go faster than 30.  (Thank God no politician outlawed it before someone went faster!)
2.  Many of the people who created our most widely utilized and practical inventions/breakthroughs were NEITHER engineers NOR scientists.  They were inventive AMATEURS in their field.  Edison (drop out and tinkerer).  Einstein (patent clerk).  Marconi.  Hertz. Ad infinitim.
Quote

I can find nothing that indicates there is anything on the horizon that will allow this. The only other option is to decrease the bandwidth used for the same number of bits which, according to the Hartley-Shannon law, requires an increased signal-to-noise ratio because the reciever has to distinguish between an increased number of transmission states. My guess is that you will find that the increase in (S+N)/N is more than the decrease in N you will get from decreased bandwidth.
First of all, what part of "reduce the bit rate" was not clear?
Secondly, the "bandwidth" in question (for the modem) is the bandwidth of the input filter for the SINGLE tone or SINGLE tone pair.  I can have multiple tones/tone pairs, each with its own input filter.
Quote

wa5ben:
"There will probably be a series of "there first" products before the "there right" products hit the market.  The tests on a single ill-conceived product prove nothing."

The tests prove that the ARRL cry "Wolf!" claim is premature.

wa5ben:
"1.  If one uses a good modem design, each tone (or tone pair) will have a bandpass filter.  That sets the modem SNR."

As I said above, Shannon's Law addresses channel capacity. You must consider the RF environment when addressing signal-to-noise ratio. The receiving rf amplifier and IF chain does NOT have bandpass filters narrow enough to filter out each indiviual audio tone, they are based on the entire channel bandwidth. The channel capacity is, therefore, based on the signal-to-noise ratio in the RF portion of the receiver. The noise contribution is from the entire channel bandwidth and the signal strength is the entire signal.

wa5ben:
'2.  The AVERAGE level of the modem signal is also its PEAK level.  The average level of human speech is primarily a function of the VOWEL sounds - which contribute very litttle to intelligibility.  At the point where both signals peak at 6 dB (voltage) or 3 dB (power) above the noise, the analog signal will be difficult to impossible to copy, as the CONSONANT sounds - that are ESSENTIAL for intelligibility will become indistinguishable.  The modem signal will have a 6 dB SNR at that point."

Once again, you are doing what WA0LYK warned you about. Because of the lower power density of speech, you can run amplifiers at a much higher peak power (look up the definition of ICAS ratings sometime) than you can a digital signal where the peak and average are the same. If the digital signal is at a 6db SNR then the SSB signal will quite likely be at a 12db SNR for voice peaks.

I don't agree that the consonants will be indistinguishable. You have the power levels right but I have some graphs from some research that show that broadband noise in the 1800-2500hz range (which is the band where most of the consonant energy will lie) will only drop the articulation recognition percentage to about 60% even with a signal to noise ratio of -12 to -18 db.

That puts the SSB signal at just about the same recognition level as the digital signal you are putting out of the same amplifer at a lower power level because of thermal considerations and ICAS ratings.

wa5ben:
"The EXACT argument would be made that these radios cannot possibly support SSTV, RTTY, or SITOR/AMTOR mode B.  Gee, the argument must be wrong, because they DO support those modes - and are used in them every single day.
Same EXACT issue.  Same EXACT solution.  (And LOTS of hams have added a fan to those radios to ensure cool operation in those modes.)"

No one is saying they can't handle SSTV, RTTY, or anything else. They DO support the modes - EVERY SINGLE DAY --- at a reduced power level.

Everyone that I know who has added fans STILL can't run them at the same power level as SSB. In fact, most of them require the fans to run continuously at 1/4 of the power level because at that drive level the amplifiers are LESS efficient and therefore dump even more heat into the heat sink.

There just ain't no free lunch in the real world, Larry.

tim ab0wr

 

There you go again with deliberate distortion.

This statement is about the coding:

"Consider the coding:
If a bit of speech that occupies 0.25 seconds is encoded in a 2400 bps stream, it follows that about 600 bits have relation to that speech. If a bit of speech that occupies 0.25 seconds is encoded in a 600 bps stream, it follows that about 150 bits have relation to that speech."

This statement is about the impact upon a block:

"Consider the impact of a noise burst:

As an EXAMPLE ONLY: The size of an LPC-10 block is 54 bits. If we double that, we have 108 bits. A hit on a DOUBLE block will impact 108/2400 = 0.045 seconds of speech.
From these facts, it is quite evident that decreasing the number of bits DOES NOT increase the size of the "hole" caused by an error - or by a block of errors.

It should also be extremely evident that the size of the "hole" is equal to the size of the block for a burst noise. For a prolonged noise that impacts the recovery, the "hole" is equal to the number of blocks impacted."

The size of a BLOCK is NOT fixed at 54 or 108 bits. (I thought "EXAMPLE ONLY" was a definite "don't try to mix these oranges with those apples"!

The size of an encodable speech frame is related to the length of the speech sound. Different algorithms assign different lengths, but they all have a direct translation to the length of a sound "package".

In general, they are far less than 1/10 second - and some are very short. The human brain will "supply" coverage of nearly 1/10 second of missing sound - as long as there is not a "pop" to indicate the absence; however, good algorithms "bridge" a corrupted block with the sound from the preceding block.

Clearly, 0.25 second at 2400 bps is 0.25 second at 600 bps. There is no magic 'information per bit" that impacts. The only impact is the block size, as a block corrupted by a factor greater than the automatic error detection and correction can fix will be in error. (Errors of 2 to 5 bits per block may be made recoverable by coding.)

In other words, both formats will suffer EXACTLY the SAME loss if they lose 0.25 second of data. Whether that is 600 bits or 150 bits is immaterial.

 

wa5ben:
"In other words, both formats will suffer EXACTLY the SAME loss if they lose 0.25 second of data. Whether that is 600 bits or 150 bits is immaterial. "

In other words, the entire message you posted was discussing a difference with no difference? ROFL!!!!!

What was your point then!

The fact of the matter is that the bigger you make the bucket the more you lose when the bucket spills. Works for data just like it does for water. You like "word" explanations - here's one for you.

It's like two people moving the same amount of water - one with a 5 gallon bucket that can move at X speed and the other with a gallon bucket that can move at 5X speed. Trip and fall with the 5 gallon bucket and you lose five gallons. Trip and fall with the 1 gallon bucket and you only lose a gallon. You have to lose 5 times as many small buckets as you would big buckets to be equivalent. Random noise is just that - random. Expecting random noise to take out 5 times as many buckets in one situation as in the other doesn't make any sense in a random universe.

Using your analogy would violate Shannon's law. Encoding more and more information into smaller and smaller bandwidths could just continue forever with no limit - except we know that doesn't work.

tim ab0wr

 

This is such severe BS and stupidity that it does not deserve an intelligent answer!

Nonetheless, as a service to those who may be confused by your usual and deliberate distortion:

Algorithms are not buckets. If an algorithm can convey the essential elements to produce voice with good speaker recognition, it matters little how many bits per second (bps) are required. When we want to put the algorithm over a particular medium; however, the bps may become very important.

Given that a lower bit rate allows use of a more simple transmission format (smaller number of decision points), and given that HF is a severe medium that will not support a large number of decision points, it follows that HF needs a smaller number of bist per second.

If I have an algorithm that encodes speech at 600 bps, my frame size (= shortest block of speech) may be 30 to 60 bits - or 1/20 to 1/10 second. If I lose a block, I lose the speech encoded in that block. Nothing more. Nothing less.

If I have an algorithm that encodes speech at 2400 bps, my frame size (= shortest block of speech) may be quite different. If the block size is 54 bits, that is 0.0225 second. If I lose a block, I lose the speech encoded in that block. Nothing more. Nothing less.

The smaller the frame size, the smaller the time segment represented by the frame, and the smaller the time segment lost - BUT, the frame size must be large enough to carry all of the information in a syllable. For that reason, there is a finite lower limit of frame size for a given algorithm. That limit IS directly dependant upon the methodology used by the algorithm -- and IS NOT directly dependant upon the number of bits per second

If I am using an algorithm like LPC-10, I may have a slight impact on 2 more frames, as the voicing may be slightly skewed by the missing frame. (That is fairly easy to correct, and it may be corrected outside of the algorithm.)

(It should also be noted that LPC-10 operates with a block size that is far shorter than a syllable, and that the block size is fixed at 54 bits - regardless of the channel data rate.)

FYI: The LPC-10 algorithm is used at 2400 bps on both military (STU) and commercial (SECTEL) encrypted satellite links, as well as on HF. The STU/SECTEL mode is supported by most notebook sized satellite transceivers.

The point is that you deliberately and knowingly twist all facts so that you can try to appear "smarter" than someone else. Unfortunately, many people CAN read, and they can plainly see the manner in which you deliberately twist and distort. The truly sad thing is that there may be some who are genuinly attempting to learn - and your deliberate and nonsensical distortions make what SHOULD be a very simple topic very convoluted.

Shannon's Law has not been violated. You have, however, violated the law of common sense:

This is VERY obviously NOT what I said - and it is impossible to construe it as such.

If we must reduce ourselves to your "bucket" analogy:

The "buckets" are segments of TIME.

The frame size IN TIME equals the size of the bucket.

One bucket may hold 150 bits BUT it is ONE time segment equal to 0.25 second at 600 bps.

Another bucket may hold 600 bits BUT it is ONE time segment equal to 0.25 second at 2400 bps.

If our carrier trips, he/she spills ONE bucket.

If the carrier causes 4 more carriers to fall, they spill a total of FIVE buckets.

Now, to put this into "real" terms, the smallest POSSIBLE "bucket" is equal to ONE FRAME of the algorithm in use. The actual impact of noise is equal to the number of frames corrupted beyond the capability of the error detection and correction layer to recover.

 

I need to make a slight correction. For "syllable" in the above, please substitute "phoneme". This is correct, and is in line with my previous posts.

I am not sure whether back pain, 0200 CDST, or the medication for the pain (or a combination) is responsible for the obvious misstatement.

 

Skip,
The ARRL "BOTS" [blind obedience] on QRZ are so numerous, I quit discussing it. I will never join this organization who is attempting to destroy CW and ham radio...and the ARRL BOTS I just feel sorry for. No wonder our hobby is dying. With the ARRL on our side, who needs enemies.