So sorry John ..... of course you are right .....
we were supposed to have read and understood the contents of part 97 ..... I guess I must have forgotten the part that demanded we also memorize it verbatim with all it's technical terms and specs. I must be the one to admit it, I am the one that forgot some pieces of it .... could you remind me again about where that rule was located? .... HiHi In all seriousness, I was simply trying to illustrate a point that seemed to be misleading in the discussion. As I read the discussion, and indeed I could have missed some posts, but it appeared some were alluding that the maximum baud rate was 300 PERIOD, which as you have so expertly pointed out is quite untrue ..... Thank you for the clarification, however these limits still seem to fly in the face of such things as EZPal and a few others, especially when operating on customary HF frequencies around 20 meters (14.233 - 14.237 khz) .... Thanks again --- In digitalradio@yahoogroups.com, "John B. Stephensen" <kd6...@...> wrote: > > According to the terms of our licenses, each of us is supposed to have read > and understood part 97 of the FCC rules and regulations. Here's a summary of > the upper limits for RTTY/data emissions in 97.305 and 97.307 as I read it: > > 1.8-24.99 MHz: 300 baud with 1 kHz shift or facsimile with 500 Hz maximum > bandwidth > 28-29.7 MHz: 1200 baud with 1 kHz shift or facsimile with 500 Hz maximum > bandwidth > 50-144 MHz: 19,200 baud, 20 kHz bandwidth > 219-220 MHz: 100 kHz bandwidth > 222-450 MHz: 56,000 baud, 100 kHz bandwidth > 1240+ MHz: no limits > > The facsimile in HF rtty/data segments exception was put in recently to allow > the use of Hellschreiber. There are no data rate (bits per second) > limitations on any frequency and no bandwidth limitations on HF except for > fax. > > For phone/image emssions the rules are different. For 1.8-148 and 222-225 MHz > non-phone emissions are limited to the bandwidth of communications-quality > phone emissions of same modulation type. Given the maximum bandwdths used for > each mode in the past, this presumably means less than 3.4 kHz for SSB, 10 > kHz for AM/ISB and 30 kHz for FM. Note that image includes B7W, B8W and B9W > (ISB) emissions that can contain any combination of rtty, data, phone and > image. There are no baud rate limits. There are no limits at all for 420 MHz > and above, except that emissions must stay within the band. > > 73, > > John > KD6OZH > > ----- Original Message ----- > From: John > To: digitalradio@yahoogroups.com > Sent: Thursday, October 29, 2009 21:50 UTC > Subject: [digitalradio] Re: Why would anyone > > > Maybe I am growing a little bit confused here ..... > > As I follow this thread, am I hearing that there is a flat limit of 300 > baud in all aspects of amateur radio? > > First, can't we use 1200 baud in certain cases, such as above 2 meters? > > Second, how do we correlate the 300 baud limit when we use such tools as > EZPal and other file transfer programs/protocols? > > Am I to understand that these are working at a maximum symbol change rate > of 300 baud? > > guess I better do a whole lot more reading because this is getting quite > complex now .... > > > --- In digitalradio@yahoogroups.com, "John B. Stephensen" <kd6ozh@> wrote: > > > > The baud rate limit applies but this means 300 symbol changes per second > on > > each subcarrier. The number of subcarriers and the number of bits per > > subcarrier is not limited. The ARRL regulation by bandwidth proposal was > a > > better method than the current regulation by content rules but was > opposed > > by too many people. > > > > 73, > > > > John > > KD6OZH > > > > ----- Original Message ----- > > From: Charles Brabham > > To: digitalradio@yahoogroups.com > > Sent: Thursday, October 29, 2009 13:02 UTC > > Subject: Re: [digitalradio] Why would anyone > > > > > > John: > > > > Do the rules specify that there is no baudrate limit upon FDM modes? > > > > The fact that they are mentioned does not necessarily imply that they are > > not intended to fall under the 300 baud restriction. > > >
