Just say NO! to Winlink expansion!

Thank you Tim. You put my words into mathematical precision! This was the point I was making without precision .

While all of this technical stuff is great, the question remains and someone just hit the nail on the head. This proposal suggests we need more flexibility and it is provided, but there are some glaring omissions and I've brought them to my director's attention. Those who are ARRL members should get involved. These people need to hear how we feel and know our concerns. We can say no to this proposal or work to make it right. The choice is yours.

Ken

 

ae1x:
"While all of this technical stuff is great, the question remains and someone just hit the nail on the head. This proposal suggests we need more flexibility and it is provided, but there are some glaring omissions and I've brought them to my director's attention. Those who are ARRL members should get involved. These people need to hear how we feel and know our concerns. We can say no to this proposal or work to make it right. The choice is yours."

Ken,

WA0LYK has a proposal that makes a lot of sense. I've asked him to poste it here on this thread or as a new topic.

It has to do with setting up the bands using the necessary bandwidth FCC emission indicator. Necessary bandwidth won't force strict regulations on actual rf footprints but will give a good way to segragate the sub-bands. That will minimize FCC involvement in interference complaints, will provide relief for content restrictions, and will not require waiver after waiver for specific modes.

There are some things left to be done such as deciding on maximum necessary bandwidth limitations (so we don't get 20khz FM signals on 75m) and laying out sub-bands for automatic (both full and semi) operation.

I really think it is a step forward and I hope WA0LYK can find a champion in the power structure at the ARRL to carry it forward.

tim ab0wr

 

Since Tim asked me to post this I am including what I have written to send to my director.

I want to let you know that I can not support the elimination of mode segregation and replacing it with a proposed "occupied bandwidth" regulatory plan at this time. There are many reasons for this and I will discuss them below. However, I would first like to recommend another alternative to the current ARRL bandwidth petition -- using the necessary bandwidth term from emission designators as a limit to describe frequency segments. I believe this recommendation will reduce regulation, reduce the costs of FCC enforcement, and reduce the cost of future regulation changes should new digital techniques require marginally wider bandwidths.

This alternative would use the first term of emission designators. ITU defined emission designators are a somewhat new means of defining emission types and have been accepted/implemented by the FCC. Some good definitions are at http://wireless.fcc.gov/services/ind&bus/licensing/emission.html. The use of technically accurate definitions such as these would make the amateur community and the ARRL appear much more professional to the FCC. As many amateurs are not familar with emission designators, an added benefit would be the education of the amateur community about these conventions.

The first term of emission designators is known as the "necessary bandwidth" of the emission being used. There are mathematical calculations, well defined by the FCC and the ITU, required to determine the necessary bandwidth. They are not based upon measurements, which have a high dollar cost, but only upon the published operating characteristics of any given emission.

The necessary bandwidth notation is somewhat unique. It consists of four characters where H = Hertz and K = kHz. Some examples are:

60H0 - 60.0 Hz (used for PSK31 - 60H0J2B)
375H - 375 Hz (used for Pactor II - 375HJ2D)
2K20 - 2.20 kHz (used for Pactor III - 2K20J2D)
2K70 - 2.70 kHz (used for digital voice - 2K70J2E)
3K00 - 2.70 khz (used for analog voice - 2K70J3E)

These were taken from a document at the NTIA web site: http://ntiacsd.ntia.doc.gov/ussg1/uswp1a/WP 1A Documents/2004_10_Meeting/R03-WP1A-C-0031!!MSW-E.doc.

The ARRL proposed petition attempts to define the band segments using what is known as the "occupied bandwidth" which describes a transmitters RF footprint. For example, when running analog voice, the necessary bandwidth could be defined as 2.70 kHz in the emission designator, while the occupied bandwidth of the transmitter would be limited to 3.00 kHz. Limiting the occupied bandwidth makes it necessary to measure the transmitter using a well defined technique such as a two tone test and making sure the RF footprint fits into a well defined emissions mask, i.e. no emissions above -26 db at 3.00 kHz.

A proposed plan with two segments, using necessary bandwidths, could say something like "From here to there all modes whose emission designator has a necessary bandwidth less than or equal to 2.5 kHz, and from here1 to there1 all modes whose emission designator has a necessary bandwidth greater than 2.5 kHz". CW can be allowed anywhere by modifying the exemption in 97.305(a) to say "CW (____A1A)". A total bandwidth limit can be specified as "no emissions whose necessary bandwidth is greater than 9K00 (9 kHz). Subsequent voluntary bandplans can use any or all of the last three characters to limit transmissions to certain characteristics and band segments.

The invention of new emission types would only require the calculation of the necessary bandwidth to determine which part of the band they belong to. The calculations required to determine the necessary bandwidth are well defined by the FCC and the ITU. No FCC intervention would be required to implement a new emission type which reduces the regulatory burden and costs.

 

I think this represents a reasonable starting point. I see some issues, but they are minor.

 

Hey Guys!

Look at this:

WINLINK THROUGHPUT

From http://www.winlink.org/status CMBO traffic:

Winlink.org/status

1669 characters/message
2.33 minutes/message = 140 sec/message

HF Average Message Size (Characters) = 1669
HF Average Minutes Air Time Per Message = 2.33

Therefore Average seconds per message = 2.33 x 60 = 140 seconds

1669 characters per message /140 seconds per message = 12 char/sec throughput

From: http://winlink.org/Presentations/RFfootprints.PDF

Pactor III = 225 ch/sec
Pactor II = 50 ch/sec
RDFT = 97 ch/sec
Pactor I = 20 ch/sec
HF Packet = 37 ch/sec
psk31 = 4 ch/sec
mt63 = 20 ch/sec

92% of Winklink traffic is on Pactor III.

Therefore (roughly), actual throughput, including overhead and repeat requests, of Pactor III, for the average 2.3 minute email, is *only* 12/.92= 13 ch/sec !!!

Are my calculations correct???

 

Skip,

looks to me like the following:

Pactor 1 = 20 char/sec
Pactor 3 = 255 char/sec

therefore p3 = 13p1  (approx)

lets assume worst case that 92% of the 1669 total chars are
p3 and 8% are p1.

1669 * .92 = 1535
1669 * .08 =  133

Let's call base throughput with p1  =   T
                    throughput with p3  = 13T

  (1535/13T)  +  (133/T)   =  140

  (1535/13T)  +   (1729/13T)   = 140

  (1/13T) (1535 + 1729)  = 140

   (3264)  =  (140) * (13T)   =  1820T

   T  = (3264/1820)   =   1.8

  13T  =   23

Looks to me like the effective throughput of Pactor3 is  23 char/sec.

tim ab0wr

 

I should have also pointed out that a good set of CW ops can pass traffic consistently at 25wpm. Thats just about 2 char/sec.

Using Winlinks own RF footprint calculations we get for:
p3 = 23 char/sec
cw =  2 char/sec

 p3 rf footprint =      (2400hz)/(23char/sec)  =   104  hz-sec

 cw rf footprint =      (250 hz)/(2 char/sec)   =    125 hz-sec

Woo-hoo!!

Does pactor 3 really provide that much of an advantage or does it just SOUND like it when listening?

tim ab0wr

 

I think requests for repeats and some error checking has to be added to the CW speed, or that of any non-ARQ modes.

 

I should have also pointed out that a good set of CW ops can pass traffic consistently at 25wpm. Thats just about 2 char/sec.

Using Winlinks own RF footprint calculations we get for:
p3 = 23 char/sec
cw =  2 char/sec

 p3 rf footprint =      (2400hz)/(23char/sec)  =   104  hz-sec

 cw rf footprint =      (250 hz)/(2 char/sec)   =    125 hz-sec

Woo-hoo!!

Does pactor 3 really provide that much of an advantage or does it just SOUND like it when listening?

tim ab0wr

 

Skip,

looks to me like the following:

Pactor 1 = 20 char/sec
Pactor 3 = 255 char/sec

therefore p3 = 13p1  (approx)

lets assume worst case that 92% of the 1669 total chars are
p3 and 8% are p1.

1669 * .92 = 1535
1669 * .08 =  133

Let's call base throughput with p1  =   T
                    throughput with p3  = 13T

  (1535/13T)  +  (133/T)   =  140

  (1535/13T)  +   (1729/13T)   = 140

  (1/13T) (1535 + 1729)  = 140

   (3264)  =  (140) * (13T)   =  1820T

   T  = (3264/1820)   =   1.8

  13T  =   23

Looks to me like the effective throughput of Pactor3 is  23 char/sec.

tim ab0wr

 

It seems my reply got lost. Anyway, just in case, here it is again...

Thanks for the additional calculations, Tim!

Probably most non-Pactor3 stations are Pactor2, not Pactor1. Anyway, the initial Pactor3 link is in Pactor1, then it tests different speed levels of Pactor3, as I understand it.

Using Pactor3 is far away from its raw data rate, and even that of Pactor2, isn't it! This is the point.

Anyway, I think most of the speed advantage that Winlink *thinks* Pactor3 gives (for its 5x greater bandwidth) is not realizable over the typical 2 minute email, but would show up better over a 10 minute image transfer. The use of Pactor3 for 2 minute emails is an absolute waste of bandwidth for little actual speed gain, and, since Winlink is a store-and-forward system anyway, even an extra minute or so in upload or download time for a 2 minute email is nothing compared to the actual average upload to download and reading elapsed time, which may be many minutes or even hours. The NTS/NTSD proposed specification for WL2K is one hour!

Therefore, it make sense to me to provide for only enough space for 24 500 Hz-wide Pactor-II channels, and one Pactor-III channel, and let Winlink figure out what is best for them. In any case, using Pactor-II or Pactor-III will show little difference in overall delivery time for the average 2 minute email.

It all boils down to deciding what amount of spectrum would be fair to allocate to all unattended operations, since there is a limited amount available for everyone. For Winlink to want access to ALL of it, as they wish, is just bad management, especially since they are currently able to function perfectly well in 10 kHz per band, except on 40m, where it is only 5 kHz, and they could just use Pactor2 there. As Winlink represents much less-than-1% of the US ham population, how can more than the 3.8% already available in the sub-bands for unattended operations be justified?

If the average email is 2 minutes, two Winlink stations time-sharing a single frequency would have a maximum wait of 2 minutes for a clear channel. Three would have a *maximum* wait of only 4 minutes, I believe. Statistically, you can probably show what the average wait would be for 4 or 5 time-sharing a single frequency. I tried, using the Erlang B calculator, but did not know what to assume for the arrival rate.

In each case, the spectrum need drops from half for two time-sharing, to 1/3 for three time-sharing, to 1/4 for four time-sharing, as the average wait time increases as more share the same channel. Seems to me that the sub-bands already provide for several times the spectrum needed for all of Winlink, HF Packet, and Winlink/Emcomm, if reasonable time-sharing is practiced.

I see no reason why the ARRL should ignore this, especially since Winlink has already said three times that they are running 92% in the current sub-bands using Pactor3!

 

Remember when computers had only 8k of memory?
Remember when a good word processing program was written in less than 32k?

We don't see that anymore.  Everything with computers is larger.  We all need a min of 40 gigs of hard drive, we all need an absolute min of 512k of memory.  

My problem with winlink is that they probably will not have that much growth in numbers, but if not kept in check, they certainly could have an enormous need of band space.  Our bandspace is limited, email attachments and their file sizes are not limited.  I'm sure they could limit it, but there are no guarantees. We could very well be giving more spectrum to fewer users as they develop more uses for winlink, and it would all be under the guise of "advancing the radio art".

 

In 1995, the FCC determined that 3.8% of the amateur radio HF spectrum was appropriate for unattended emissions over 500 Hz in width. Since then, no new spectrum has been added to HF except for 60 meters.

I think there is no justification to increasing that percentage just because someone wants it, since it will just take away from everyone else who has no interest in remote email RF access, "messaging", or higher-speed data transfer on HF, Winlink or otherwise.

Since Winlink is a store-and-forward service, even the increased raw speed of Pactor3 over Pactor2 has little impact on the overall time to delivery of a message.

You are right - things must be kept in check, and the FCC has done a good job so far, in my opinion!

Most hams prefer voice input over keyboard or key input, so I think the most useful advances for ham radio will come in the area of digital voice, not enhanced messaging or store-and-forward services.

If speech recognition were more error-free, so it could be used real-time, my own DigiTalk program for the blind would be able to communicate by computer voice in only 125 Hz bandwidth at normal speaking speeds. It can already "speak" PSK31 and PSK63 at near-normal speed.

So, even narrowband "voice" communications is right around the corner, and could make all the phone bands less crowded.

 

Mike,

I agree that this is not advancing the radio art.

What I see is WL2k is marketing this service through its web-site to boaters. They even explain how to get an amateur radio license. My problem with this group of users is that they are just that users and not amateurs.

Ken

 

kh6ty:
"I think requests for repeats and some error checking has to be added to the CW speed, or that of any non-ARQ modes"

This is based on a clear frequency with good signals. I know from experience as an NCS on the Region 10 cw net that sending a lot of messages at 25wpm can be done with very few repeats and error checking. In fact, I used 25wpm for just that reason, you can send at 30wpm but the effective throughput can actually be less because of errors and repeats. 25wpm is pretty error free.

That is one of the flaws with the RF footprint measurement, it doesn't provide much in the way of measuring operation in less than ideal conditions. It would be interesting to see some experimentation of P3 and CW on a noisy summer night on 80m. I wonder if the up-change to P3 would even take place on some nights that we still pass CW messages.

kh6ty:
"Therefore, it make sense to me to provide for only enough space for 24 500 Hz-wide Pactor-II channels, and one Pactor-III channel, and let Winlink figure out what is best for them. In any case, using Pactor-II or Pactor-III will show little difference in overall delivery time for the average 2 minute email."

Skip, you have a much better handle on traffic efficiency that most of the so-called "experts" do. Faster is not always better. There are so many other considerations that have to be taken into account. The higher the overhead for a faster mode, the longer it takes for the speed to make up for the overhead. Overhead on a CW net is pretty minimal. I can have two people check in and can have them off-freq passing traffic in just a couple of seconds when the band is clear of noise and qrm. It would be interesting to know exactly how long the testing and training takes for moving from Pactor 1 to Pactor 3 on a clear channel. I know with Pactor 1 that the continual moving between the 100baud ascii to 100baud compressed to 200 baud ascii to 200baud compressed adds significant overhead. It goes up and then down and then up and then down as the noise and qrm and propagation changes on the channel. Each change takes time. And you are exactly right. On short transmissions, this adds significantly to the total time spent. There are days where it would be faster to just stick it in 100baud ascii and leave it there when there are only one or two messages per session with the NTSD hub.

If I were writing the Winlink 2000 code, or the airmail code, it would be tempting to add an algorithm which would actually look at the size of the transmission and would apply a metric to see if using P3 would be worth it. If the transmission time using P2 were less than 2 minutes, force the modem to use P2.

kh6ty:
"If the average email is 2 minutes, two Winlink stations time-sharing a single frequency would have a maximum wait of 2 minutes for a clear channel. Three would have a *maximum* wait of only 4 minutes, I believe. Statistically, you can probably show what the average wait would be for 4 or 5 time-sharing a single frequency. I tried, using the Erlang B calculator, but did not know what to assume for the arrival rate."

That's why I keep saying we need some forecasts from Winlink as to what the existing offered load is and what the expected load will be. They should be able to write Perl script quite easily which would pull the past offered load from their email servers using time stamps on the email. You could use curve fitting software to forecast future load modified by the number of new users coming on board each month.

The fact that they won't do this is interesting. There could be several reasons. Perhaps they don't want to give possible competitors a feel for just how much demand there actually is. Perhaps they just want to keep it shrouded in mystery so no one can actually pin them down and they can keep asking for more spectrum hoping if they build it they will come. Perhaps the actual load isn't really that high and they don't want anyone to know. Maybe they don't know how to write the software to analyze the message headers on their email servers. Maybe they are using Windows email servers and Windows won't let them access the email headers to get the information.

Who knows!

tim ab0wr