From rlanier@su102s.ess.harris.com Mon Mar 03 07:51:51 1997 Received: from ess.harris.com (su15a.ess.harris.com [130.41.1.251]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id HAA08140 for ; Mon, 3 Mar 1997 07:51:49 -0600 (CST) Received: from losalamos.ess.harris.com (su102s.ess.harris.com [130.41.13.101]) by ess.harris.com (8.8.5/8.8.5) with SMTP id IAA10391 for ; Mon, 3 Mar 1997 08:51:45 -0500 (EST) Received: from Muskegon.com.gasd102 by losalamos.ess.harris.com (4.1/SMI-4.1) id AA02803; Mon, 3 Mar 97 08:51:44 EST Received: by Muskegon.com.gasd102 (SMI-8.6/SMI-SVR4) id IAA21172; Mon, 3 Mar 1997 08:51:42 -0500 Date: Mon, 3 Mar 1997 08:51:42 -0500 From: rlanier@su102s.ess.harris.com (Tony Lanier) Message-Id: <199703031351.IAA21172@Muskegon.com.gasd102> To: ss@tapr.org Subject: SS Design X-Sun-Charset: US-ASCII Am I the only person who wants to do a group SS design? Since I don't live near TAPR (or any other high-tech group), this is the only why I can participate. I assumed that there would be a discussion over the weekend, but nothing. Does anyone still want to do this? Tony KE4ATO From dewayne@warpspeed.com Mon Mar 03 10:26:19 1997 Received: from warpspeed.com (odo.warpspeed.com [204.118.182.20]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id KAA16295 for ; Mon, 3 Mar 1997 10:26:17 -0600 (CST) Received: from [204.118.182.22] by warpspeed.com with ESMTP (Apple Internet Mail Server 1.1.1); Mon, 3 Mar 1997 08:26:15 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 3 Mar 1997 08:25:44 -0800 To: ss@tapr.org, ss-sta@tapr.org From: Dewayne Hendricks Subject: Spread Spectrum Rule Change NPRM release by FCC Today the FCC released the NPRM for the Spread Spectrum Rule changes to Part 97: IN THE MATTER OF AMENDMENT OF THE AMATEUR SERVICE RULES TO PROVIDE FOR GREATER USE OF SPREAD SPECTRUM COMMUNICATION TECHNOLOGIES. Proposed to amend amateur rules to authorize amateur stations to make greater use of SS type emmission technologies. Dkt No.: WT- 97-12. Action by the Commission. Adopted: January 9, 1997. by NPRM. (FCC No. 97-10). WTB -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dewayne Hendricks, WA8DZP ! AOL: HENDRICKS Warp Speed Imagineering ! Internet: dewayne@warpspeed.com 43730 Vista Del Mar ! Packet Radio: WA8DZP @ K3MC.#NOCAL.CA.USA.NOAM Fremont, CA 94539-3204 ! WWW: Fax: (510) 770-9854 ! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From beltrani@hawaii.edu Mon Mar 03 22:10:59 1997 Received: from relay1.Hawaii.Edu (root@relay1.Hawaii.Edu [128.171.3.53]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id WAA19823 for ; Mon, 3 Mar 1997 22:10:53 -0600 (CST) Received: from uhunix4.its.Hawaii.Edu ([128.171.44.54]) by relay1.Hawaii.Edu with SMTP id <586892(1)>; Mon, 3 Mar 1997 18:06:34 -1000 Received: from localhost by uhunix4.its.Hawaii.Edu with SMTP id <216719(3)>; Mon, 3 Mar 1997 18:10:32 -1000 Date: Mon, 3 Mar 1997 18:10:30 -1000 From: Paul A Beltrani X-Sender: beltrani@uhunix4 Reply-To: beltrani@pixi.com To: ss@tapr.org Subject: Re: [SS:1054] SS Design In-Reply-To: <199703031351.IAA21172@Muskegon.com.gasd102> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 3 Mar 1997, Tony Lanier wrote: > Am I the only person who wants to do a group SS design? Since > I don't live near TAPR (or any other high-tech group), this > is the only why I can participate. I assumed that there would > be a discussion over the weekend, but nothing. > > Does anyone still want to do this? I am interested in building something to meet the following design goals (in no particular order): 1) User application independent. 2) Band independent 3) Programmable to allow for experimentation 4) Short development time so we can take advantage of the STA 5) Reasonable cost (The next 8 lines need to be viewed with a fixed width font) Something like the "SS Box" in this diagram: [App Box]<-Data I/O->[SS Box]<-IF I/O->[Transverter]->Ant Out ^ ^ | +-------; Tue, 4 Mar 1997 13:10:04 -0600 (CST) Received: from mne (ANNEX-3.SLIP.ECE.CMU.EDU [128.2.236.3]) by cmu1.acs.cmu.edu (8.8.2/8.7.3) with SMTP id OAA15674 for ; Tue, 4 Mar 1997 14:09:39 -0500 Message-Id: <1.5.4.32.19970304190926.00663da0@gauss.ece.cmu.edu> X-Sender: ettus@gauss.ece.cmu.edu X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 04 Mar 1997 14:09:26 -0500 To: ss@tapr.org From: Matt Ettus Subject: Ground-Up Spread Spectrum On the subject of designing our own SS system I think that designing our own is the only way to go. Relying on eval boardas or cutting apart other designs is expensive and destined to be reliant on their technology. This past summer, I designed a 900MHz SS modem for a commercial application. It could be built on a 5x7 PCB, and was not layout critical except for the RF section. Total cost was about $100 in production (~1000) quantity. There is no reason we couldn't do something similar with all of the RF ICs and SS ICs currently available. I would suggest that anyone interested look at the Cylink home page (I think its www.cylink.com, but check Yahoo). They make about 6 different chips for doing DS SS at bit rates of 1200 to 2Mbit/s, with chip rates up to 32 per bit. The chips also start for very low prices ($12 for the slow ones), and handle most of the SS stuff. They can be programmed by a simple microcontroller (we used a 68HC05). 73 Matt Ettus N2MJI From dewayne@warpspeed.com Tue Mar 04 13:19:11 1997 Received: from warpspeed.com (WA8DZP@odo.warpspeed.com [204.118.182.20]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id NAA02933 for ; Tue, 4 Mar 1997 13:19:08 -0600 (CST) Received: from [204.118.182.22] by warpspeed.com with ESMTP (Apple Internet Mail Server 1.1.1); Tue, 4 Mar 1997 11:18:18 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 4 Mar 1997 11:17:46 -0800 To: ss@tapr.org, ss-sta@tapr.org From: Dewayne Hendricks Subject: News on SS NPRM The FCC released the long awaited NPRM on "Amendement of the Amateur Service Rules to Provide For Greater Use of Spread Spectrum Communication Technologies", FCC 97-10 yesterday. If the FCC doesn't post the NPRM up on their website in the next serveral days, then TAPR will see that its posted on our website. The last time I checked this morning, it still wasn't available from the FCC website. If you're interested in just what the rule changes the FCC is proposing to Part 97 for spread spectrum, they are word for word the same language that the ARRL proposed in their petition, RM-8737 (available on the TAPR website). Comments are due on May 5, 1997 and reply comments are due June 5, 1997. -- Dewayne -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dewayne Hendricks, WA8DZP ! AOL: HENDRICKS Warp Speed Imagineering ! Internet: dewayne@warpspeed.com 43730 Vista Del Mar ! Packet Radio: WA8DZP @ K3MC.#NOCAL.CA.USA.NOAM Fremont, CA 94539-3204 ! WWW: Fax: (510) 770-9854 ! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From wb9mjn@wb9mjn.ampr.org Tue Mar 04 13:56:32 1997 Received: from wb9mjn.ampr.org (wb9mjn.ampr.org [44.72.98.19]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA04413 for ; Tue, 4 Mar 1997 13:55:01 -0600 (CST) From: wb9mjn@wb9mjn.ampr.org Date: Tue, 04 Mar 97 13:26:18 UTC Message-Id: <12948@wb9mjn.ampr.org> To: ss@tapr.org Subject: Re: [SS:1056] Re: SS Design In-Reply-To: your message of Mon Mar 03 22:12:18 1997 Hi Paul, I have some comments on ur lineup. What u have proposed is somewhat expensive. If the data i/o and control i/o were done virtually over a Ethernet port, the hardware costs would be allot less there, and the programing would be about the same, hopefully. I would not use a Transverter. They are very expensive. The SS box should do analog I/Q to a "Data Radio". Optional parallel and/or one wire serial I/Q would be nice too. Some Data Radio line ups want one wire data, and in- ternally they split it out into parallel, before aplying it to a D/A. SO, maybe a better solution would be analog/one wire digital I/Q, switch select- able, with an optional external parrallel Data I/Q converter. 73, Don. Mailbox : WB9MJN @ N9HSI.IL.USA.NA AMPRNet : wb9mjn@wb9mjn.ampr.org[44.72.98.19] Internet: wb9mjn%wb9mjn.ampr.org@uugate.aim.utah.edu From beltrani@hawaii.edu Tue Mar 04 19:51:29 1997 Received: from relay1.Hawaii.Edu (root@relay1.Hawaii.Edu [128.171.3.53]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id TAA23433 for ; Tue, 4 Mar 1997 19:51:27 -0600 (CST) Received: from uhunix4.its.Hawaii.Edu ([128.171.44.54]) by relay1.Hawaii.Edu with SMTP id <587435(8)>; Tue, 4 Mar 1997 15:47:04 -1000 Received: from localhost by uhunix4.its.Hawaii.Edu with SMTP id <216726(9)>; Tue, 4 Mar 1997 15:50:53 -1000 Date: Tue, 4 Mar 1997 15:50:50 -1000 From: Paul A Beltrani X-Sender: beltrani@uhunix4 Reply-To: beltrani@pixi.com To: ss@tapr.org Subject: Re: [SS:1059] Re: SS Design In-Reply-To: <12948@wb9mjn.ampr.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 4 Mar 1997 wb9mjn@wb9mjn.ampr.org wrote: > I have some comments on ur lineup. What u have proposed is somewhat > expensive. Thanks for the feedback. > If the data i/o and control i/o were done virtually over a Ethernet > port, the hardware costs would be allot less there, and the programing would > be about the same, hopefully. 1) I disagree on the expense. I think a simple RS232 interface much would be much cheaper to design/implement than developing an Ethernet interface. 2) Ethernet implies a PC or network interface. This confilicts with goal #1 Not everyone is interested in data networks. Some may want to use this device for voice communications. For those who are into networks, it would be a simpler matter to use existing software and connect this to a serial port or PI card. The truely hardcore could devlop an ethernet or isa interface. > > I would not use a Transverter. They are very expensive. The SS box should > do analog I/Q to a "Data Radio". Optional parallel and/or one wire serial > ... Works for me. My point in the diagram was to show modularity and band independence. A "data radio" interface instead of an IF would be fine. - Paul, AH6NU From dinod@deltanet.com Wed Mar 05 02:28:03 1997 Received: from mail2.deltanet.com (mail2.deltanet.com [199.171.190.56]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id CAA21742 for ; Wed, 5 Mar 1997 02:28:01 -0600 (CST) Received: from dino (anx-ana2162.deltanet.com [204.254.68.162]) by mail2.deltanet.com (8.8.4/8.8.4) with SMTP id AAA19993 for ; Wed, 5 Mar 1997 00:28:39 -0800 (PST) Message-Id: <1.5.4.32.19970305082754.00680a40@mail.deltanet.com> X-Sender: dinod@mail.deltanet.com (Unverified) X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 05 Mar 1997 00:27:54 -0800 To: ss@tapr.org From: Dino Darling Subject: Spread Spectrum Talk >X-From_: scdcc-owner@smartlink.net Tue Mar 4 19:45 PST 1997 >From: schermer@ix.netcom.com >Date: Tue, 4 Mar 1997 21:43:40 -0600 (CST) >To: scdcc@smartlink.net >Cc: buass@wireless.net >Subject: Spread Spectrum Talk >Sender: owner-SCDCC@smartlink.net >Reply-To: SCDCC@smartlink.net >Content-Length: 606 > >Announcement Announcement Announcement > > > >The SCDCC will be sponsoring a discussion by Robert A.. Buaas, K6KGS, >on Spread Spectrum Digital communication. The talk will be held at Jun's >Electronics on Sat March 22, 1997 10:30 AM. He will discuss the theory >behind spread spectrum, its benefits, and its implications on frequency utilization. >K6KGS has held a STA from the FCC for over five years. He is also working under >TAPR STA.. More details of the talk will be given in future announcements. >All are invited to attend. Further details will follow. > >73, >Bob, kk6rd >Chairman SCDCC > > > > > Dino...dinod@deltanet.com From wb9mjn@wb9mjn.ampr.org Wed Mar 05 02:29:32 1997 Received: from wb9mjn.ampr.org (wb9mjn.ampr.org [44.72.98.19]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id CAA21761 for ; Wed, 5 Mar 1997 02:29:24 -0600 (CST) From: wb9mjn@wb9mjn.ampr.org Date: Wed, 05 Mar 97 01:52:09 UTC Message-Id: <12959@wb9mjn.ampr.org> To: ss@tapr.org Subject: Re: [SS:1060] Re: SS Design In-Reply-To: your message of Tue Mar 04 19:52:12 1997 Hi Paul, Really don t see how a RS-232 port makes thinks easier for Voice com- munication. For Voice, some sorta in-box manually operated controls is the ideal. And these controls are much more expensive to develope than either the ethernet, or RS-232. The ethernet is cheaper, since both functions can be rolled into one port. Rather than having the cost of two ports, and the software developement to handle both ports simultaneously, flawlessly. It would be a higher up front thing, but rolled into many units, there should be a payback. Altho, this idea might work with a parrallel port as well. As has been done in some of the European packet networking hardware. A bidirectional parallel port would have enuf capacity for control and moderate data rates. Somebody should double check me on that statement, tho! The thing is, that RS-232 seems cheap, but RS-232 is not really going to do the job above a couple hundred KB/s, in a standard computer. Then u need the PI-card, and the higher performance differential drivers. So, is there really a savings with RS-232 ? Or is it just a path to shifting the bucks into a PC interface card that is of limited production? By using a ethernet card, even if its a dedicated one for the interface to the SS box, there is production volume that brings the PC side of things down. On voice, one might dispense with real time control altogether, and have a prom to set spreading, hopping, and center frequency. And just connect a microphone to it.  73, Don. Mailbox : WB9MJN @ N9HSI.IL.USA.NA AMPRNet : wb9mjn@wb9mjn.ampr.org[44.72.98.19] Internet: wb9mjn%wb9mjn.ampr.org@uugate.aim.utah.edu From karn@laptop.ka9q.ampr.org Wed Mar 05 13:13:12 1997 Received: from laptop.ka9q.ampr.org ([166.147.64.150]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id NAA20601 for ; Wed, 5 Mar 1997 13:13:08 -0600 (CST) Received: by laptop.ka9q.ampr.org id m0w2Dh3-000RxcC (Debian Smail-3.2 1996-Jul-4 #2); Wed, 5 Mar 1997 02:13:05 -0800 (PST) Message-Id: Date: Wed, 5 Mar 1997 02:13:05 -0800 (PST) From: Phil Karn To: ss@tapr.org In-reply-to: <12959@wb9mjn.ampr.org> Subject: Re: [SS:1062] Re: SS Design I also argue for Ethernet. It's the "rs-232 of the '90s". The interfaces (chips and complete boards) are now universally available very cheap, the chips are much easier to talk to (especially since just about every operating system comes with built-in drivers) and of course it's far faster than RS-232. 10BaseT can be used in a simple 4-wire point-to-point mode, or with a hub it can handle many party-lined devices. Easier to transmit around the house too, given that 10Base T is already differentially encoded, while RS-232 is not. I'm continually amazed at how many people keep trying to turn RS-232 into something like Ethernet (only much slower) to "save money", just as they keep trying to turn NOS into UNIX now that Linux is around... Phil From beltrani@hawaii.edu Wed Mar 05 14:26:40 1997 Received: from relay1.Hawaii.Edu (root@relay1.Hawaii.Edu [128.171.3.53]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id OAA24506 for ; Wed, 5 Mar 1997 14:26:30 -0600 (CST) Received: from uhunix4.its.Hawaii.Edu ([128.171.44.54]) by relay1.Hawaii.Edu with SMTP id <587525(3)>; Wed, 5 Mar 1997 10:22:05 -1000 Received: from localhost by uhunix4.its.Hawaii.Edu with SMTP id <216719(9)>; Wed, 5 Mar 1997 10:26:09 -1000 Date: Wed, 5 Mar 1997 10:26:04 -1000 From: Paul A Beltrani X-Sender: beltrani@uhunix4 Reply-To: beltrani@pixi.com To: ss@tapr.org Subject: Re: [SS:1063] Re: SS Design In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 5 Mar 1997, Phil Karn wrote: > I also argue for Ethernet. It's the "rs-232 of the '90s". The > interfaces (chips and complete boards) are now universally available > very cheap, the chips are much easier to talk to (especially since > ... > I'm continually amazed at how many people keep trying to turn RS-232 > into something like Ethernet (only much slower) to "save money", just > as they keep trying to turn NOS into UNIX now that Linux is around... Personally, I like Ethernet. I use it to network my Win95, SolarisX86 and Linux machines at home. However I suggested RS-232/RS422 to meet the "User application independent" design goal. Not everyone is into data networks. - Paul From beltrani@hawaii.edu Wed Mar 05 14:33:52 1997 Received: from relay1.Hawaii.Edu (root@relay1.Hawaii.Edu [128.171.3.53]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id OAA25055 for ; Wed, 5 Mar 1997 14:33:48 -0600 (CST) Received: from uhunix4.its.Hawaii.Edu ([128.171.44.54]) by relay1.Hawaii.Edu with SMTP id <587688(5)>; Wed, 5 Mar 1997 10:29:28 -1000 Received: from localhost by uhunix4.its.Hawaii.Edu with SMTP id <216755(7)>; Wed, 5 Mar 1997 10:33:35 -1000 Date: Wed, 5 Mar 1997 10:33:30 -1000 From: Paul A Beltrani X-Sender: beltrani@uhunix4 Reply-To: beltrani@pixi.com To: ss@tapr.org Subject: Re: [SS:1062] Re: SS Design In-Reply-To: <12959@wb9mjn.ampr.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 4 Mar 1997 wb9mjn@wb9mjn.ampr.org wrote: > Really don t see how a RS-232 port makes thinks easier for Voice com- > munication. For Voice, some sorta in-box manually operated controls is the > ideal. And these controls are much more expensive to develope than either > the ethernet, or RS-232. Quick example Microphone --> CoDec chip --> serial data out --> SS Box Speaker <-- Audio Amp <-- CoDec chip <-- serial data in <-- SS Box Simple and cheap. My guess is << $50 for the Audio/Codec stuff. > The ethernet is cheaper, since both functions can be rolled into one > port. Rather than having the cost of two ports, and the software developement > to handle both ports simultaneously, flawlessly. It would be a higher up > front thing, but rolled into many units, there should be a payback. You may be correct at an economy of scale level, but I am not sure there is even enough interest to make developing a prototype worthwhile. (Other than for the fun of it) Also, what I was suggesting does not require simultaneous control of two ports. In fact, it does not even require two ports. (See below) > ... > The thing is, that RS-232 seems cheap, but RS-232 is not really going to > do the job above a couple hundred KB/s, in a standard computer. Then u need > the PI-card, and the higher performance differential drivers. So, is there > really a savings with RS-232 ? Or is it just a path to shifting the bucks > into a PC interface card that is of limited production? > ... You are correct. Let me respond to those points. 1) RS-232 IS speed limited. However an RS-422 interface for the data side will allow a chip like the Zilog Z8700 to operate at up to 2Mbps. We have not really talked about how fast we would expect this SS Box to be. It is not much of a benefit to talk to the box at 10Mbps if it can not process the data that quickly. 2) True, you need a PI or similar interface to drive such an interface. 3) Yes, you would be shifting the cost of a "High Speed" interface outside the SS Box. However, I was more interested in developing a piece of hardware so people could begin experimenting with SS quickly. If you are a network person and want speed, you could begin by setting up a 1024Kbps RS-232 link and then work on developing a fast interface. It would be simple to include connections for the experimenter to bypass the RS-232/RS-422 interface. > On voice, one might dispense with real time control altogether, and have > a prom to set spreading, hopping, and center frequency. And just connect a > microphone to it.  Based on your comment farther up about the need to "to handle both ports simultaneously, flawlessly." and this paragraph, I think we have a different idea about what I meant by a programming port. I am NOT suggesting real-time control of the the SS Box or real-time debugging. I was suggesting a way a way to preprogram parameters as you suggested and then let the device run. It was more of a conceptual block of the diagram. In fact, it may be reasonable to use only one I/O port and simply switch between "programming mode" and "run mode". Personally, I like Ethernet. However I am trying to keep in mind that not everyone who is interested in SS is interested in data networks. Is the rest of the list interested in this thread? - Paul, AH6NU From wd5ivd@tapr.org Wed Mar 05 14:37:59 1997 Received: from [208.134.134.40] ([208.134.134.40]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA25323; Wed, 5 Mar 1997 14:37:55 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Mar 1997 14:38:07 -0600 To: "TAPR-BB list mailing", " Spread Spectrum " From: "Greg Jones, WD5IVD" Subject: FCC Releases WT Docket 97-12 http://www.tapr.org/ss and ftp://ftp.tapr.org/tapr/ss now contains a pdf version of FCC WT Docket No. 97-12. WT Docket No. 97-12 Notice of Proposed Rule Making regarding Amendment of the Amateur Service Rules to Provide For Greater Use of Spread Spectrum Communications Technologies was released March 3rd, 1997. 3/5/97 From wd5ivd@tapr.org Wed Mar 05 15:02:47 1997 Received: from [208.134.134.40] ([208.134.134.40]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id PAA26408; Wed, 5 Mar 1997 15:02:44 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Mar 1997 15:02:58 -0600 To: " Spread Spectrum ", "TAPR-BB list mailing" From: wd5ivd@tapr.org Subject: ARLB012 FCC proposes changes in spread spectrum regs SB QST @ ARL $ARLB012 ARLB012 FCC proposes changes in spread spectrum regs ZCZC AG12 QST de W1AW ARRL Bulletin 12 ARLB012 >From ARRL Headquarters Newington CT March 5, 1997 To all radio amateurs SB QST ARL ARLB012 ARLB012 FCC proposes changes in spread spectrum regs Responding to a petition for rulemaking from the ARRL, the FCC has proposed in WT Docket 97-12 to adopt changes in its Amateur Service rules governing spread spectrum. In spread spectrum the energy of the transmitted signal is distributed among several synchronized frequencies within a band and reassembled at the receiving end. This reduces power density and duration of a transmission on a particular frequency and lets spread spectrum almost invisibly share the same spectrum with users of other, narrowband modes. Spread spectrum also provides for improved communication under poor signal-to-noise conditions and in selective fading and multipath environments, and the ability to accommodate more communication channels operating simultaneously in the same spectrum. The League's December 1995 petition asked the FCC to relax its rules to give Amateur Radio more opportunities to contribute to the development of spread spectrum techniques. Specifically, the League sought to have the FCC relax restrictions on spreading sequences and asked for greater flexibility in spreading modulation. In response, the FCC now has proposed to drop rules restricting amateur stations to transmitting only frequency-hopping and direct-sequencing spreading techniques. As requested by the League, the FCC also has proposed to require automatic power control for spread spectrum transmitters, to ensure use of the minimum power level needed to carry out communication. The FCC also went along with the League's request to permit brief test transmissions using spread spectrum and to allow international spread spectrum communications between amateurs in the US and those in countries that allow hams to use spread spectrum. The current rules allow only domestic communication. The use of spread spectrum techniques was first approved for Amateur Radio in 1985 for bands above 225 MHz and at power levels up to 100 watts, and there has been some experimental amateur operation since then. The FCC also has authorized Special Temporary Authority (STA) in some instances to allow broader SS experimentation. Since spread spectrum was introduced in the Amateur Radio service, commercial spread spectrum applications have been developed, including personal communication services, remote meter reading and position locating. But, the League had argued that rules limitations held back further spread spectrum experimentation. No changes are proposed in the frequency bands where spread spectrum is permitted. The FCC said the rule amendments would ''increase spectrum efficiency and allow amateur operators to contribute to technological advances.'' Comments on the NPRM in WT Docket 97-12 are due May 5, with reply comments due June 5. NNNN /EX From wtba@eci-esyst.com Wed Mar 05 15:13:55 1997 Received: from eci-esyst.com (callisto.eci-esyst.com [205.129.215.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id PAA27277 for ; Wed, 5 Mar 1997 15:13:54 -0600 (CST) Received: by eci-esyst.com (4.1/SMI-4.1) id AA28969; Wed, 5 Mar 97 16:13:09 EST Received: from www.eci-esyst.com(198.135.69.2) by callisto.eci-esyst.com via smap (V1.3) id sma028962; Wed Mar 5 16:12:51 1997 Received: from callisto (rodney.eci.esys.com) by eci.esys.com (4.1/SMI-4.1) id AA00843; Wed, 5 Mar 97 16:08:31 EST Received: from qmgate.eci-esyst.com by callisto (4.1/SMI-4.1) id AA29672; Wed, 5 Mar 97 16:11:50 EST Message-Id: Date: 5 Mar 1997 16:09:26 -0500 From: "Bill Bard" Subject: Re: SS Design To: ss@tapr.org X-Mailer: Mail*Link SMTP-QM 4.0.0 Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; Name="Message Body" Content-Transfer-Encoding: quoted-printable I would vote for a non-Ethernet solution. If Ethernet parts are that cheap, someone could then design a board which provides the ethernet interface and those that want it could get that interface card. My SS design would utilize a microprocessor that would use either RS-232 or RS-422/423 to interface with the SS modem. Bill Bard wd4ixi@amsat.org From rlanier@su102s.ess.harris.com Wed Mar 05 17:00:28 1997 Received: from ess.harris.com (su15a.ess.harris.com [130.41.1.251]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id RAA04557 for ; Wed, 5 Mar 1997 17:00:26 -0600 (CST) Received: from losalamos.ess.harris.com (su102s.ess.harris.com [130.41.13.101]) by ess.harris.com (8.8.5/8.8.5) with SMTP id SAA16113 for ; Wed, 5 Mar 1997 18:00:21 -0500 (EST) Received: from Muskegon.com.gasd102 by losalamos.ess.harris.com (4.1/SMI-4.1) id AA21376; Wed, 5 Mar 97 18:00:22 EST Received: by Muskegon.com.gasd102 (SMI-8.6/SMI-SVR4) id SAA25455; Wed, 5 Mar 1997 18:00:18 -0500 Date: Wed, 5 Mar 1997 18:00:18 -0500 From: rlanier@su102s.ess.harris.com (Tony Lanier) Message-Id: <199703052300.SAA25455@Muskegon.com.gasd102> To: ss@tapr.org Subject: Re: [SS:1068] Re: SS Design X-Sun-Charset: US-ASCII > From ss@tapr.org Wed Mar 5 17:03:02 1997 > Date: Wed, 5 Mar 1997 15:20:12 -0600 (CST) > Originator: ss@tapr.org > From: "Bill Bard" > To: ss@tapr.org > Subject: [SS:1068] Re: SS Design > X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas > X-Comment: Tucson Amateur Packet Radio Spread Spectrum > Content-Transfer-Encoding: quoted-printable > > I would vote for a non-Ethernet solution. If Ethernet parts are that > cheap, someone could then design a board which provides the ethernet > interface and those that want it could get that interface card. > > My SS design would utilize a microprocessor that would use either RS-232 > or RS-422/423 to interface with the SS modem. > > Bill Bard > wd4ixi@amsat.org > This is a good reason for having a modular radio. Whoever wants RS-232, use it. If you want Ethernet, then use that. Maybe a way around this is to have the SS radio/modem operate in slow mode (data rate < 250kbps) for those who want to use rs-232 and fast mode (data rate > 250kbps) for those who want to use Ethernet. Using a microprocessor to control this (and the radio) would simplify this. The next hurdle: FREQUENCY ???? Tony KE4ATO From beltrani@hawaii.edu Wed Mar 05 18:03:33 1997 Received: from relay1.Hawaii.Edu (root@relay1.Hawaii.Edu [128.171.3.53]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id SAA08331 for ; Wed, 5 Mar 1997 18:03:31 -0600 (CST) Received: from uhunix4.its.Hawaii.Edu ([128.171.44.54]) by relay1.Hawaii.Edu with SMTP id <587850(1)>; Wed, 5 Mar 1997 13:58:36 -1000 Received: from localhost by uhunix4.its.Hawaii.Edu with SMTP id <216750(2)>; Wed, 5 Mar 1997 14:02:43 -1000 Date: Wed, 5 Mar 1997 14:02:39 -1000 From: Paul A Beltrani X-Sender: beltrani@uhunix4 Reply-To: beltrani@pixi.com To: ss@tapr.org Subject: Re: [SS:1069] Re: SS Design In-Reply-To: <199703052300.SAA25455@Muskegon.com.gasd102> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 5 Mar 1997, Tony Lanier wrote: > ... > > interface and those that want it could get that interface card. > > > > My SS design would utilize a microprocessor that would use either RS-232 > > > ... > This is a good reason for having a modular radio. Whoever wants RS-232, use it. > If you want Ethernet, then use that. Maybe a way around this is to have the SS > radio/modem operate in slow mode (data rate < 250kbps) for those who want to use > rs-232 and fast mode (data rate > 250kbps) for those who want to use Ethernet. That is why I suggested a programming port/option. Experiment and configure as much as you like. > Using a microprocessor to control this (and the radio) would simplify this. > > The next hurdle: FREQUENCY ???? > I would recommend leaving that up to the user. - Paul Beltrani, AH6NU From beltrani@hawaii.edu Wed Mar 05 18:12:16 1997 Received: from relay1.Hawaii.Edu (root@relay1.Hawaii.Edu [128.171.3.53]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id SAA08944 for ; Wed, 5 Mar 1997 18:12:15 -0600 (CST) Received: from uhunix4.its.Hawaii.Edu ([128.171.44.54]) by relay1.Hawaii.Edu with SMTP id <587778(5)>; Wed, 5 Mar 1997 14:07:57 -1000 Received: from localhost by uhunix4.its.Hawaii.Edu with SMTP id <216742(7)>; Wed, 5 Mar 1997 14:12:05 -1000 Date: Wed, 5 Mar 1997 14:11:59 -1000 From: Paul A Beltrani X-Sender: beltrani@uhunix4 Reply-To: beltrani@pixi.com To: ss@tapr.org Subject: Z87200 SS TRx Eval Board Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I just received a price on the Zilog Z87200 eval board of aprox $700 U.S. I am waiting for a price on just the chip. Links to info on the chip and evail board @ http://www.pixi.com/~beltrani/ss.html. - Paul Beltrani, AH6NU From dhoyer@frontiercorp.com Wed Mar 05 19:43:40 1997 Received: from node1.frontiernet.net (node1.frontiernet.net [205.232.174.11]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA14091 for ; Wed, 5 Mar 1997 19:43:39 -0600 (CST) From: dhoyer@frontiercorp.com Received: from ccm.frontiercorp.com (ccm.frontiercorp.com [204.168.13.16]) by node1.frontiernet.net (8.8.5/8.8.2) with SMTP id TAA69968 for ; Wed, 5 Mar 1997 19:37:10 -0500 Received: from ccMail by ccm.frontiercorp.com (ccMail Link to SMTP R6.00.01) id AA857608629; Wed, 05 Mar 97 19:37:20 -0500 Message-Id: <9703058576.AA857608629@ccm.frontiercorp.com> X-Mailer: ccMail Link to SMTP R6.00.01 Date: Wed, 05 Mar 97 18:34:42 -0500 To: Subject: Re: [SS:1065] Re: SS Design MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-Printable >>>>Is the rest of the list interested in this thread? Yes, I am! Absolutely! Dan KA9VMI ______________________________ Reply Separator ________________________= _________ Subject: [SS:1065] Re: SS Design Author: at INTERNET Date: 3/5/97 2:41 PM On Tue, 4 Mar 1997 wb9mjn@wb9mjn.ampr.org wrote: > Really don t see how a RS-232 port makes thinks easier for Voice = com-=20 > munication. For Voice, some sorta in-box manually operated controls i= s the=20 > ideal. And these controls are much more expensive to develope than ei= ther=20 > the ethernet, or RS-232.=20 Quick example Microphone --> CoDec chip --> serial data out --> SS Box Speaker <-- Audio Amp <-- CoDec chip <-- serial data in <-- SS Box Simple and cheap. My guess is << $50 for the Audio/Codec stuff. > The ethernet is cheaper, since both functions can be rolled into = one=20 > port. Rather than having the cost of two ports, and the software deve= lopement=20 > to handle both ports simultaneously, flawlessly. It would be a higher= up > front thing, but rolled into many units, there should be a payback. You may be correct at an economy of scale level, but I am not sure ther= e=20 is even enough interest to make developing a prototype worthwhile. (Oth= er=20 than for the fun of it) Also, what I was suggesting does not require=20= =0Asimultaneous control of two ports. In fact, it does not even require= two=20 ports. (See below) > ...=20 > The thing is, that RS-232 seems cheap, but RS-232 is not really g= oing to=20 > do the job above a couple hundred KB/s, in a standard computer. Then = u need=20 > the PI-card, and the higher performance differential drivers. So, is = there > really a savings with RS-232 ? Or is it just a path to shifting the b= ucks=20 > into a PC interface card that is of limited production? > ... You are correct. Let me respond to those points. 1) RS-232 IS speed limited. However an RS-422 interface for the data s= ide=20 will allow a chip like the Zilog Z8700 to operate at up to 2Mbps. We h= ave=20 not really talked about how fast we would expect this SS Box to be. It= is=20 not much of a benefit to talk to the box at 10Mbps if it can not proces= s=20 the data that quickly. 2) True, you need a PI or similar interface to drive such an interface.= 3) Yes, you would be shifting the cost of a "High Speed" interface outs= ide=20 the SS Box. However, I was more interested in developing a piece of=20= =0Ahardware so people could begin experimenting with SS quickly. If yo= u are=20 a network person and want speed, you could begin by setting up a 1024Kb= ps=20 RS-232 link and then work on developing a fast interface. It would be=20= =0Asimple to include connections for the experimenter to bypass the=20 RS-232/RS-422 interface. > On voice, one might dispense with real time control altogether, a= nd have=20 > a prom to set spreading, hopping, and center frequency. And just conn= ect a > microphone to it. =7F=7F=7F=7F =20 Based on your comment farther up about the need to "to handle both port= s=20 simultaneously, flawlessly." and this paragraph, I think we have a=20 different idea about what I meant by a programming port. I am NOT=20 suggesting real-time control of the the SS Box or real-time debugging. = I=20 was suggesting a way a way to preprogram parameters as you suggested an= d=20 then let the device run. It was more of a conceptual block of the=20 diagram. In fact, it may be reasonable to use only one I/O port and=20= =0Asimply switch between "programming mode" and "run mode". Personally, I like Ethernet. However I am trying to keep in mind that = not everyone who is interested in SS is interested in data networks. Is the rest of the list interested in this thread? - Paul, AH6NU =2E = From dhoyer@frontiercorp.com Wed Mar 05 20:11:47 1997 Received: from node1.frontiernet.net (node1.frontiernet.net [205.232.174.11]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA15501 for ; Wed, 5 Mar 1997 20:11:45 -0600 (CST) From: dhoyer@frontiercorp.com Received: from ccm.frontiercorp.com (ccm.frontiercorp.com [204.168.13.16]) by node1.frontiernet.net (8.8.5/8.8.2) with SMTP id UAA49074 for ; Wed, 5 Mar 1997 20:24:09 -0500 Received: from ccMail by ccm.frontiercorp.com (ccMail Link to SMTP R6.00.01) id AA857611447; Wed, 05 Mar 97 20:24:20 -0500 Message-Id: <9703058576.AA857611447@ccm.frontiercorp.com> X-Mailer: ccMail Link to SMTP R6.00.01 Date: Wed, 05 Mar 97 19:18:47 -0500 To: Subject: Re: [SS:1063] Re: SS Design MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit The most popular thing I have seen to do with ethernet type device interface is to set up a terminal or telnet mode to program the device. e.g. you would telnet into the SS hardware with any TCPIP telnet program for configuration. This could be done transparently while the unit is up and operational. However, the big "NOTE" here is that all of these devices have had an auxiliary RS-232 interface for "out-of-band" programming in addition to the ethernet interface. Personally I like the RS-232 idea for simple async links, but there is going to be a bandwidth problem for people wanting to run high speed data. (some 5GHz systems are already up in the 10Mbps range for xfer rates) I think what needs to be done is a through analysis of the proposed requirements/features needed before we look at technology solutions for the problem. Once this is set, then we won't be shooting at a moving features target, and we can determine the hardware design from there. The bottom line is: "What do we want to do with this litte box when we're done building it?" As I see it the main things we are considering so far for requirements are: Transmission types: - Voice - Low speed data (probably async under 512Kbps) - High speed data (probably over 2 Mbps) Possible Interfaces: - Audio - RS-232 - Ethernet - RS-422 - Fiber? - Maybe a control panel programming mode on an LCD menu? Range - Short range <20 Miles - Medium range >20 <100 - Long range >100 SS Chipset - WHOS? Suggestions/Preferences? CPU - uController? - full blown computer on board? - software driven from a PC? No/minimal onboard cpu? Hopping - DSSS - FHSS Frequency Spectrum - 900MHz - 2 GHz - 5 GHz - 10 GHz - Higher? - Lower? Standards - Do we follow any? If so which ones? - Data => 802.11 for WANs? - Voice => I don't know if there are any... - Do we create some? What else needs to be considered? Flexibility is paramount! The initial system design needs to be dynamic, using *CURRENT* technology or even future(-read, non mainstream yet), with a target goal in mind of what the end product needs to be after testing is complete! I suspect that the initial designs will be anything but cheap, but the final product is where you can compress everything learned in the development process into a relatively inexpensive package. Think about it - how the heck was the TNC-1 designed and implemented? I didn't mean to rattle on so long, but I just got started, and all of this stuff just kind of spilled out of me. It seems to me that answering these questions will tell us what we need to build. Cheers, Dan KA9VMI - My 2.0112452 cents worth. (Pentium lookup error) ______________________________ Reply Separator _________________________________ Subject: [SS:1063] Re: SS Design Author: at INTERNET Date: 3/5/97 1:19 PM I also argue for Ethernet. It's the "rs-232 of the '90s". The interfaces (chips and complete boards) are now universally available very cheap, the chips are much easier to talk to (especially since just about every operating system comes with built-in drivers) and of course it's far faster than RS-232. 10BaseT can be used in a simple 4-wire point-to-point mode, or with a hub it can handle many party-lined devices. Easier to transmit around the house too, given that 10Base T is already differentially encoded, while RS-232 is not. I'm continually amazed at how many people keep trying to turn RS-232 into something like Ethernet (only much slower) to "save money", just as they keep trying to turn NOS into UNIX now that Linux is around... Phil From jerryn@ici.net Wed Mar 05 20:23:35 1997 Received: from localhost (d-ma-fallriver-102.ici.net [207.180.10.111]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id UAA16378 for ; Wed, 5 Mar 1997 20:23:29 -0600 (CST) Received: from nomad by localhost with smtp (Smail3.1.29.1 #58) id m0w2Sp7-000VWTC; Wed, 5 Mar 97 21:22 EST Sender: root@tapr.org Message-ID: <331E2A61.5AE2F2D9@ici.net> Date: Wed, 05 Mar 1997 21:22:25 -0500 From: Jerry Normandin X-Mailer: Mozilla 4.0b2 (X11; I; Linux 2.0.26 i686) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1064] Re: SS Design X-Priority: 3 (Normal) References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Paul A Beltrani wrote: > > On Wed, 5 Mar 1997, Phil Karn wrote: > > > I also argue for Ethernet. It's the "rs-232 of the '90s". The > > interfaces (chips and complete boards) are now universally available > > very cheap, the chips are much easier to talk to (especially since > > ... > > I'm continually amazed at how many people keep trying to turn RS-232 > > into something like Ethernet (only much slower) to "save money", just > > as they keep trying to turn NOS into UNIX now that Linux is around... > > Personally, I like Ethernet. I use it to network my Win95, SolarisX86 and > Linux machines at home. However I suggested RS-232/RS422 to meet the > "User application independent" design goal. Not everyone is into data > networks. > > - Paul I don't know about you but wireless internet access is my goal. I am pulling it off now with the NEC Wavelan Card. I would love to get a bulk purchase going. I would like to get the cards for $200.00 each. Anyone here have time to set up a bulk purchase? From karn@laptop.ka9q.ampr.org Wed Mar 05 20:25:13 1997 Received: from laptop.ka9q.ampr.org (ra4000-p65.qualcomm.com [129.46.54.145]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA16439 for ; Wed, 5 Mar 1997 20:25:11 -0600 (CST) Received: by laptop.ka9q.ampr.org id m0w2Sfu-000RxcC (Debian Smail-3.2 1996-Jul-4 #2); Wed, 5 Mar 1997 18:12:54 -0800 (PST) Message-Id: Date: Wed, 5 Mar 1997 18:12:54 -0800 (PST) From: Phil Karn To: ss@tapr.org Reply-To: karn@qualcomm.com In-reply-to: (message from Paul A Beltrani on Wed, 5 Mar 1997 14:41:07 -0600 (CST)) Subject: Re: [SS:1065] Re: SS Design >1) RS-232 IS speed limited. However an RS-422 interface for the data side >will allow a chip like the Zilog Z8700 to operate at up to 2Mbps. We have >not really talked about how fast we would expect this SS Box to be. It is >not much of a benefit to talk to the box at 10Mbps if it can not process >the data that quickly. And where do I get an RS-422 interface for my laptop? How much do they cost? 10BaseT PCMCIA cards are now not much above $100 retail in the big computer stores. ISA Ethernet cards are dirt cheap. 10BaseT can be used in a point-to-point mode over twisted pair cable (one pair in each direction). And because those pairs are differential (like 422) I can run substantial distances. And I'm not limited to talking to just one device at a time with Ethernet. Suppose you give me a device with an RS-232 port. My laptop only has one such port. I may use it with a TNC, or a CDMA or CDPD cellular packet modem. Or I may need it for my Delorme Tripmate GPS receiver. These other uses all preclude using it with your RS-232 interface at the same time unless I go out and buy a PCMCIA card to get additional serial ports (which brings up the fact that I only have two slots on this machine) Or, of course, I kludge up some sort of RS-232 diode matrix a la the old TNC 2 NET/ROM interconnects, then write some special driver software to do CSMA on the diode matrix bus. All this to avoid using a cheap, fast, widely available, thoroughly understood, reliable and versatile technology, namely Ethernet? Sounds entirely in keeping with the history of amateur packet radio to me... :-) Phil From karn@laptop.ka9q.ampr.org Wed Mar 05 20:26:01 1997 Received: from laptop.ka9q.ampr.org (ra4000-p65.qualcomm.com [129.46.54.145]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA16471 for ; Wed, 5 Mar 1997 20:25:58 -0600 (CST) Received: by laptop.ka9q.ampr.org id m0w2STz-000RxbC (Debian Smail-3.2 1996-Jul-4 #2); Wed, 5 Mar 1997 18:00:35 -0800 (PST) Message-Id: Date: Wed, 5 Mar 1997 18:00:35 -0800 (PST) From: Phil Karn To: ss@tapr.org Reply-To: karn@qualcomm.com In-reply-to: (message from Paul A Beltrani on Wed, 5 Mar 1997 14:31:41 -0600 (CST)) Subject: Re: [SS:1064] Re: SS Design >Personally, I like Ethernet. I use it to network my Win95, SolarisX86 and >Linux machines at home. However I suggested RS-232/RS422 to meet the >"User application independent" design goal. Not everyone is into data >networks. Eh? Who says Ethernet is limited to "data networking"? It can handle packetized speech, audio and even video just fine, thank you... Phil From jerryn@ici.net Wed Mar 05 20:27:57 1997 Received: from localhost (d-ma-fallriver-102.ici.net [207.180.10.111]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id UAA16540 for ; Wed, 5 Mar 1997 20:27:54 -0600 (CST) Received: from nomad by localhost with smtp (Smail3.1.29.1 #58) id m0w2StN-000VWTC; Wed, 5 Mar 97 21:26 EST Sender: root@tapr.org Message-ID: <331E2B68.189E0FD4@ici.net> Date: Wed, 05 Mar 1997 21:26:49 -0500 From: Jerry Normandin X-Mailer: Mozilla 4.0b2 (X11; I; Linux 2.0.26 i686) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1063] Re: SS Design X-Priority: 3 (Normal) References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Phil Karn wrote: > > I also argue for Ethernet. It's the "rs-232 of the '90s". The > interfaces (chips and complete boards) are now universally available > very cheap, the chips are much easier to talk to (especially since > just about every operating system comes with built-in drivers) and of > course it's far faster than RS-232. 10BaseT can be used in a simple > 4-wire point-to-point mode, or with a hub it can handle many > party-lined devices. Easier to transmit around the house too, given > that 10Base T is already differentially encoded, while RS-232 is not. > > I'm continually amazed at how many people keep trying to turn RS-232 > into something like Ethernet (only much slower) to "save money", just > as they keep trying to turn NOS into UNIX now that Linux is around... > > Phil Why not? Linux is powerfull and cheap to implement. instead of dreaming I have three wireless router hop points up running linux and they are accessable to any laptop, PC , or computer running a NEC Wavelan device that has permissions to log in. It works! And I get 1.6MB/Sec transfer rates on ftp. From beltrani@hawaii.edu Wed Mar 05 23:59:25 1997 Received: from relay1.Hawaii.Edu (root@relay1.Hawaii.Edu [128.171.3.53]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id XAA29968 for ; Wed, 5 Mar 1997 23:59:22 -0600 (CST) Received: from uhunix4.its.Hawaii.Edu ([128.171.44.54]) by relay1.Hawaii.Edu with SMTP id <587156(3)>; Wed, 5 Mar 1997 19:55:06 -1000 Received: from localhost by uhunix4.its.Hawaii.Edu with SMTP id <216745(5)>; Wed, 5 Mar 1997 19:59:08 -1000 Date: Wed, 5 Mar 1997 19:59:05 -1000 From: Paul A Beltrani X-Sender: beltrani@uhunix4 Reply-To: beltrani@pixi.com To: ss@tapr.org Subject: Re: [SS:1076] Re: SS Design In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 5 Mar 1997, Phil Karn wrote: > >Personally, I like Ethernet. I use it to network my Win95, SolarisX86 and > >Linux machines at home. However I suggested RS-232/RS422 to meet the > >"User application independent" design goal. Not everyone is into data > >networks. > > Eh? > > Who says Ethernet is limited to "data networking"? It can handle packetized > speech, audio and even video just fine, thank you... Packetized speech, audio and even video are data. Ethernet is a data networking medium. It was designed to work with computer (data) networks. I agree there are many instances where Ethernet is the more appropriate technology and I do not want to get hung up with the semantics of this discussion. My point was, a serial interface would be more "multipurpose". Part of the problem with trying to design a multipurpose device is, for some of those purposes your design will not be optimal. For example, we could try to pack this gizmo into a PCMCIA card to fit your laptop but those with out such ports would be left out. However, almost every PC has a serial port. Of course that is speed limited and you may want to use your only serial port for something else. My design goal, for the purpose of this discussion, was to develop a simple "block" that people could use to build upon. If this gets any farther than the discussion stage, would you be interested in working on an Ethernet interface to more generic SS block? - Paul From tenney@think.org Thu Mar 06 02:07:43 1997 Received: from think.org (gateway.think.org [206.14.80.187]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id CAA13300 for ; Thu, 6 Mar 1997 02:07:40 -0600 (CST) Received: from [207.33.187.4] by think.org with smtp (Smail3.1.29.1 #57) id m0w2RqQ-000OO1C; Thu, 6 Mar 97 01:19 GMT Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 6 Mar 1997 00:07:51 -0800 To: ss@tapr.org From: "Glenn S. Tenney KOTJ" Subject: Re: SS Design At 10:01 PM -0800 3/5/97, Paul A Beltrani wrote: >My point was, a serial interface would be more "multipurpose". I believe that we need a modern, current, off-the-shelf solution for data networking. Ethernet is clearly the choice. A serial interface would not be more multipurpose. On the contrary, a serial interface would provide far less functionality and expandability for a modern data network... it is speed and distance limitted where ethernet is not. Now, if what you want developed is a nice way to do keyboard to keyboard at 9600 baud... then serial is the way to go. I want to find ways to do multi megabit data networking. --- Glenn Tenney KOTJ Fantasia Systems Inc. tenney@think.org http://www.think.org/ Voice: (415) 574-3420 Fax: (415) 574-0546 Ham radio: AA6ER From beltrani@hawaii.edu Thu Mar 06 03:25:56 1997 Received: from relay1.Hawaii.Edu (root@relay1.Hawaii.Edu [128.171.3.53]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id DAA15486 for ; Thu, 6 Mar 1997 03:25:54 -0600 (CST) Received: from uhunix4.its.Hawaii.Edu ([128.171.44.54]) by relay1.Hawaii.Edu with SMTP id <587399(8)>; Wed, 5 Mar 1997 23:21:33 -1000 Received: from localhost by uhunix4.its.Hawaii.Edu with SMTP id <216732(9)>; Wed, 5 Mar 1997 23:25:38 -1000 Date: Wed, 5 Mar 1997 23:25:35 -1000 From: Paul A Beltrani X-Sender: beltrani@uhunix4 Reply-To: beltrani@pixi.com To: ss@tapr.org Subject: Re: [SS:1079] Re: SS Design In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 5 Mar 1997, Glenn S. Tenney KOTJ wrote: > At 10:01 PM -0800 3/5/97, Paul A Beltrani wrote: > >My point was, a serial interface would be more "multipurpose". > > I believe that we need a modern, current, off-the-shelf solution for data > networking. Ethernet is clearly the choice. A serial interface would not > ... > 9600 baud... then serial is the way to go. I want to find ways to do multi > megabit data networking. I agree, if all you are interested in is the single purpose of networking. This would be a good time to see what people would be interested in using this vaporware box for. If the vast majority have networks in mind, then it makes sense to design for that. - Paul From lfry@mindspring.com Thu Mar 06 05:43:43 1997 Received: from camel6.mindspring.com (camel6.mindspring.com [204.180.128.212]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id FAA19120 for ; Thu, 6 Mar 1997 05:43:42 -0600 (CST) Received: from glory (mule1.mindspring.com [204.180.128.167]) by camel6.mindspring.com (8.8.5/8.7.3) with SMTP id GAA32566 for ; Thu, 6 Mar 1997 06:43:39 -0500 (EST) Message-Id: <2.2.32.19970306114546.003b9b60@mindspring.com> X-Sender: lfry@mindspring.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 06 Mar 1997 06:45:46 -0500 To: ss@tapr.org From: "Lee W. Fry" Subject: Re: SS Design Paul, AH6NU wrote in [SS:1065]: > >Personally, I like Ethernet. However I am trying to keep in mind that >not everyone who is interested in SS is interested in data networks. > >Is the rest of the list interested in this thread? > Apparently they are. Personally I like Ethernet too, but Paul is right, there are other people out there who don't want to have to network a computer with their radio just to send voice. Maybe we should decide we don't care about them. dhoyer@frontiercorp.com wrote in [SS:1073] >I think what needs to be done is a through analysis of the proposed >requirements/features needed before we look at technology solutions for the >problem. Once this is set, then we won't be shooting at a moving features >target, and we can determine the hardware design from there. The bottom line >is: "What do we want to do with this litte box when we're done building it?" I agree. We can throw alternate designs against the wall all day long, but how about some discussion about what we want to accomplish. It seems that the majority of interest is in high speed networks with a plug and play solution at a fraction of the cost of commercial part 15.247 devices. Sort of a current technology TNC. I guess that's to be expected since TAPR is into "Packet Radio". So if that's what everybody wants then let's go for it whole hog. I say we should forget about building a radio that can be used to prove that SS can share 6M, 2M, 220, and 440 spectrum with existing users, or make more efficient use of existing spectrum. We addressed that in our STA, but no one seems interested in it. We should let the FM, weak signal, and SSB users defend "their" spectrum from the commercial interests who have monetary gain in establishing that SS can co-exist there. Let's go for 900MHz and above and elbow our way in there beside the other users in overlapping and nearby unlicensed WLAN spectra. We can use technology developed for their applications but blow their performace away with our superior ERP because of our licensed status. Then we can build a network with multi-megabit throughput. I suspect though that it will be grossly under-used because of the content/origination verification restrictions we face. Would we be better off forgeting our licensed status and build a lower performance or higher cost (more nodes) unlicensed semi-private ampr net for unrestricted access the Internet? That's apparently what Jerry Normandin wants in [SS:1074]. Lee W. Fry AA0JP lfry@mindspring.com See my Part 15 Spread Spectrum Device Compendium at: http://www.mindspring.com/~lfry/part15.htm From lfry@mindspring.com Thu Mar 06 05:57:48 1997 Received: from camel6.mindspring.com (camel6.mindspring.com [204.180.128.212]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id FAA19561 for ; Thu, 6 Mar 1997 05:57:46 -0600 (CST) Received: from glory (mule1.mindspring.com [204.180.128.167]) by camel6.mindspring.com (8.8.5/8.7.3) with SMTP id GAA11569 for ; Thu, 6 Mar 1997 06:57:45 -0500 (EST) Message-Id: <2.2.32.19970306115951.003ccea0@mindspring.com> X-Sender: lfry@mindspring.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 06 Mar 1997 06:59:51 -0500 To: ss@tapr.org From: "Lee W. Fry" Subject: WT Docket No. 97-12 - Hollow Victory? Looks like we have done it to ourselves now. The PRM submitted by ARRL and supported by FCC contains provisions that will kill the possibility of easily leveraging off of commercial devices for our efforts. The killers are automatic transmitter power control and retention of the station ID requirements. As far as I know, none of the chipset solutions currently available for SS applications in 900MHz or 2.4 GHz can support these requirements. The only way I see out of this is to propose that as long as ERP doesn't exceed part 15.247 limits then no control would be required, and go in for eliminating the Station ID requirements. Not too satisfactory, because then we might as well be operating under part 15 and not worrying about content. Lee W. Fry AA0JP lfry@mindspring.com See my Part 15 Spread Spectrum Device Compendium at: http://www.mindspring.com/~lfry/part15.htm From magne@radar.no Thu Mar 06 07:30:16 1997 Received: from ghosthost.radar.no (magne@ghosthost.radar.no [194.143.115.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id HAA23032 for ; Thu, 6 Mar 1997 07:30:04 -0600 (CST) Received: (from magne@localhost) by ghosthost.radar.no (8.6.12/8.6.9) id OAA18328; Thu, 6 Mar 1997 14:29:47 +0100 Date: Thu, 6 Mar 1997 14:29:45 +0100 (MET) From: Magne Mahre To: ss@tapr.org Subject: Re: [SS:1081] Re: SS Design In-Reply-To: <2.2.32.19970306114546.003b9b60@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 6 Mar 1997, Lee W. Fry wrote: > Let's go for 900MHz and above and elbow our way in there beside the other > users in overlapping and nearby unlicensed WLAN spectra. If the decision is that one's going to put all the RF-parts into the project (and not base oneself on transverters), may I suggest that one settle for a frequency band allocated to the amateur service in a larger area than just region 2 ? Region 1 has the following allocations: 432-438 1240-1300 2300-2450 3400-3500 5650-5850 10250-10500 24000-24050 .. .. --Magne / la1bfa From lfry@wdl.lmco.com Thu Mar 06 07:45:58 1997 Received: from wdl1.wdl.lmco.com (wdl1.wdl.lmco.com [137.249.32.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id HAA23781 for ; Thu, 6 Mar 1997 07:45:57 -0600 (CST) Received: from wdl.marble.litc.lockheed.com by wdl1.wdl.lmco.com (SMI-8.6/WDL-5.0) id FAA14416; Thu, 6 Mar 1997 05:45:55 -0800 Message-Id: <2.2.32.19970306134827.008c81b4@wdl1.wdl.lmco.com> X-Sender: lfry@wdl1.wdl.lmco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 06 Mar 1997 08:48:27 -0500 To: ss@tapr.org From: "Lee W. Fry" Subject: Interface Requirements Let's assume we are talking about a data radio. Independent of host architecture. Says it is not ISA or PCMCIA bus, or bi-directional parallel port. Even though these are relatively open standards, what about hooking it to your old Sun SPARC? At least 500 foot drive distance. To minimize transmission line losses mount the whole thing at the antenna on the tower on the hill. Might also be nice if DC power could be run through the same interface. Throughput of at least 2 Mbps, with growth to 10 Mbps. 2 Mbps is what's supported by the current crop of 2.4 GHz systems. Some vendors are getting 4 Mbps at 5 GHz. Plug and Play with Windows 3.1, 95, NT, OS2, Linux, BSD, and other *NIX inter-networking applications. To me, this means if it is ethernet, it looks like a tcp/ip router. If it's serial, I can use anything from dumb terminal to PPP across it. Any more? Lee, AA0JP From efbrya@acxiom.com Thu Mar 06 08:18:35 1997 Received: from gatekeeper.acxiom.com (gatekeeper.acxiom.com [204.180.98.3]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id IAA25526 for ; Thu, 6 Mar 1997 08:18:34 -0600 (CST) Received: from gatekeeper.acxiom.com (daemon@localhost) by gatekeeper.acxiom.com (8.7.2/8.7.2) with ESMTP id IAA08954 for ; Thu, 6 Mar 1997 08:18:38 -0600 (CST) Received: from po-conway-1.conway.acxiom.com ([135.110.1.202]) by gatekeeper.acxiom.com (8.7.2/8.7.2) with SMTP id IAA08946 for ; Thu, 6 Mar 1997 08:18:37 -0600 (CST) Received: by po-conway-1.conway.acxiom.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC2A06.C4705DC0@po-conway-1.conway.acxiom.com>; Thu, 6 Mar 1997 08:17:01 -0600 Message-ID: From: efbrya - Eric Bryan To: "'ss@tapr.org'" Subject: RE: 1080] Re: SS Design Date: Thu, 6 Mar 1997 08:16:13 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't think it would be that hard to do both. It would be nice to have a serial port for debugging, monitoring, parameter setting, and tuning anyway. Eric Bryan efbrya@acxiom.com > >>This would be a good time to see what people would be interested in using >>this vaporware box for. If the vast majority have networks in mind, >>then it makes sense to design for that. > > > From efbrya@acxiom.com Thu Mar 06 08:25:46 1997 Received: from gatekeeper.acxiom.com (gatekeeper.acxiom.com [204.180.98.3]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id IAA25849 for ; Thu, 6 Mar 1997 08:25:45 -0600 (CST) Received: from gatekeeper.acxiom.com (daemon@localhost) by gatekeeper.acxiom.com (8.7.2/8.7.2) with ESMTP id IAA09296 for ; Thu, 6 Mar 1997 08:25:50 -0600 (CST) Received: from po-conway-1.conway.acxiom.com ([135.110.1.202]) by gatekeeper.acxiom.com (8.7.2/8.7.2) with SMTP id IAA09292 for ; Thu, 6 Mar 1997 08:25:49 -0600 (CST) Received: by po-conway-1.conway.acxiom.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC2A07.C5D79970@po-conway-1.conway.acxiom.com>; Thu, 6 Mar 1997 08:24:13 -0600 Message-ID: From: efbrya - Eric Bryan To: "'ss@tapr.org'" Subject: RE: 1081] Re: SS Design Date: Thu, 6 Mar 1997 08:22:18 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >>I say we should forget about building a radio that can be used to prove that >>SS can share 6M, 2M, 220, and 440 spectrum with existing users, or make more >>efficient use of existing spectrum. We addressed that in our STA, but no I am interested in these lower freq. just to get greater range with out having to find places to stick repeaters all over the countryside. I want to do 200 mile hops at a minimum. Lower frequencies are also easier to find parts for (at least it seems that way to me). Eric Bryan efbrya@acxiom.com > > From wb9mjn@wb9mjn.ampr.org Thu Mar 06 08:37:05 1997 Received: from wb9mjn.ampr.org (wb9mjn.ampr.org [44.72.98.19]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id IAA26419 for ; Thu, 6 Mar 1997 08:36:17 -0600 (CST) From: wb9mjn@wb9mjn.ampr.org Date: Thu, 06 Mar 97 07:46:51 UTC Message-Id: <12999@wb9mjn.ampr.org> To: ss@tapr.org Subject: Re: [SS:1081] Re: SS Design In-Reply-To: your message of Thu Mar 06 05:50:05 1997 <2.2.32.19970306114546.003b9b60@mindspring.com> Hi Everybody (!) A modular box makes allot of sense. But a box that needs to be re- done, because it does not have the guts to do the job, isn t really modular. That s probably the best reason to just do a ethernet port for all control, and data i/o. Its one thing, instead of 2, with all the performance thats needed. We DO have a UDP/IP stack laying around that can be made to work for control. We DO have a TCP/IP stack for the data communication. So, the software job is well along, right now. I think the objection to the Ethernet is mostly because people want to attach a microphone to a stand-alone radio, without needing a computer. So, does it make sense to put an analog port on the SS exciter module? The bits from the codec would come thru the cpu, and be spliced in with data com bits, if any. This way, simultaneous voice/data could be done. Or just stand-alone voice too. This is kinda messy tho. And the more I think about it, Its just not worth the extra comglomeration of hardware parts. We need to look down the future here. We can load up the box with lots of things we think it will need, or we can cut it just what it will need, with the forsight that the bulky stuff will get smaller. Indeed, a Ethernet microphone can t be that hard, right ? Sure, nobody has done things this way before. But nobody is doing a modular SS exciter either. All the other projects are somewhat ap- plication specific. So, I guess the crux of the issue here, is that altho, its allot more money in the speaker mic, is this going to a future trend, that we start, or is it a bad idea? Another way might be to put the Ethernet Speaker Mic guts into the SS exciter, and hang it off the Ethernet internally. What makes this all thinkable, is that we have NOS, and (i think) we can put surface mount dedicated computers into things the size of hand held mi- crophones. That is, technology has developed a whole bunch. Sure, one can use the full duplex speaker phone in a computer to do this same thing, but for a non-computer networking application, a Ethernet Speaker Mic, might work out too. Is this not what you were proposing with RS-232, only ether- netted, Paul? 73, Don. Mailbox : WB9MJN @ N9HSI.IL.USA.NA AMPRNet : wb9mjn@wb9mjn.ampr.org[44.72.98.19] Internet: wb9mjn%wb9mjn.ampr.org@uugate.aim.utah.edu From lylej@azstarnet.com Thu Mar 06 08:43:20 1997 Received: from mailhost.azstarnet.com (mailhost.azstarnet.com [169.197.1.8]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id IAA26678 for ; Thu, 6 Mar 1997 08:43:19 -0600 (CST) Received: from tomswift (usr2ip46.azstarnet.com [169.197.3.46]) by mailhost.azstarnet.com (8.8.3-p/8.8.5) with SMTP id HAA25758 for ; Thu, 6 Mar 1997 07:37:10 -0700 (MST) Message-Id: <3.0.32.19970306074137.0071c15c@pop.azstarnet.com> X-Sender: lylej@pop.azstarnet.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 06 Mar 1997 07:41:50 -0700 To: ss@tapr.org From: Lyle Johnson Subject: Re: [SS:1082] WT Docket No. 97-12 - Hollow Victory? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Lee, >The killers are automatic transmitter power control... >...As far as I know, none of the chipset solutions currently available for SS >applications in 900MHz or 2.4 GHz can support these requirements. The Harris PRISM chipset has an ADC that measures incoming signals and this measurement is available in a register. It also supports, I beleive, stepped power output levels. This is from memory, the Harris apps guy was in my office last week for a couple hours and I may have forgottern something (I'm not at work as I write this). Anyway, one can look at BER or retries or ??? and then set the power level by the processor that must be embedded in this widget anyhow. Automatic power control isn't a big deal IMHO -- heck, even the HF guys use it (clover and the like) :-) >and retention >of the station ID requirements. I'm sure there is a way to solve this, too... Cheers, Lyle From hwm@netcom.com Thu Mar 06 09:11:57 1997 Received: from mm.wd6dod.ampr.org (hwm@netcom21.netcom.com [192.100.81.135]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id JAA28182 for ; Thu, 6 Mar 1997 09:11:51 -0600 (CST) Received: from localhost (by mm.wd6dod.ampr.org (8.7.5/8.6.12) with SMTP id HAA00214 for ; Thu, 6 Mar 1997 07:13:41 -0800 Date: Thu, 6 Mar 1997 07:13:41 -0800 (PST) From: Bob Lorenzini To: ss@tapr.org Subject: Re: [SS:1075] Re: SS Design In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I agree with all those advocating an ethernet interface and would like to stress two points. It makes remoting the unit close to the ant much easier and all OS's can talk IP over ethernet. No need for those who do not run linux to learn unix. Bob - wd6dod From rero@cbmsmail.cb.lucent.com Thu Mar 06 09:43:36 1997 Received: from cbgw2.lucent.com (cbgw2.lucent.com [192.20.239.134]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id JAA29886 for ; Thu, 6 Mar 1997 09:43:30 -0600 (CST) Received: from cbemg.cb.lucent.com by cbig2.firewall.lucent.com (SMI-8.6/EMS-L sol2) id KAA01300; Thu, 6 Mar 1997 10:42:11 -0500 Received: from cbemg.UUCP by cbemg.cb.lucent.com (4.1/EMS-L gis) id AA24659; Thu, 6 Mar 97 10:46:01 EST Date: 6 Mar 97 10:43:00 -0500 To: "ss" Received: from cbmsmail.cb.lucent.com by cbmsmail.cb.lucent.com; Thu, 6 Mar 1997 10:43 EST Received: by cbmsmail.cb.lucent.com with Microsoft Mail id <331EE610@cbmsmail.cb.lucent.com>; Thu Mar 06 10:43 EST 1997 From: "Rochford, Richard E." Original-To: "ss" Subject: RE: 1085] RE: 1080] Re: SS Design Interfaces Original-Date: Thu Mar 06 10:43 EST 1997 Message-Id: <331EE610@cbmsmail.cb.lucent.com> Encoding: 15 TEXT X-Mailer: Microsoft Mail V3.0 Content-Type: text If you are looking for faster data rates, (digital including speech, text, video etc.), ethernet is a way to go. However, this implies there is some other interface, RS232 etc. i.e. a console port, which is needed to administer the ethernet interface. I currently work on a product with an ethernet interface and no console port, requiring us to use a default IP address and come up with an elaborate method of burning the MAC address. Obtaining and assigning MAC addresses is an other administrative chore which has to be centralized somewhere for a project like this. Richard E. Rochford WB7RPH r.e.rochford@lucent.com From BARRON@liant.com Thu Mar 06 10:08:43 1997 Received: from jumpgate.liant.com (jumpgate.liant.com [204.7.182.3]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA01698 for ; Thu, 6 Mar 1997 10:08:38 -0600 (CST) Received: (from mail@localhost) by jumpgate.liant.com (8.6.12/8.6.9) id KAA16620; Thu, 6 Mar 1997 10:23:35 -0600 Received: from rmc.liant.com(138.52.3.2) by jumpgate.liant.com via smap (V1.3) id sma016616; Thu Mar 6 10:23:27 1997 Received: from rm1.liant.com by rmc.liant.com (4.1/SMI-4.1) id AA08187; Thu, 6 Mar 97 10:10:46 CST Received: from RM1/MAILQUEUE by rm1.liant.com (Mercury 1.21); 6 Mar 97 10:10:46 CDT Received: from MAILQUEUE by RM1 (Mercury 1.21); 6 Mar 97 10:10:38 CDT From: "Robert Barron" Organization: Liant Software Corporation (Austin) To: ss@tapr.org Date: Thu, 6 Mar 1997 10:10:28 -0600 CST Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: [SS:1082] WT Docket No. 97-12 - Hollow Victory? Reply-To: barron@liant.com Cc: lfry@mindspring.com Priority: normal X-Mailer: Pegasus Mail v3.22 Message-Id: <44AE0207A4@rm1.liant.com> Lee Fry wrote: > Looks like we have done it to ourselves now. > > The PRM submitted by ARRL and supported by FCC contains provisions that will > kill the possibility of easily leveraging off of commercial devices for our > efforts. The killers are automatic transmitter power control and retention > of the station ID requirements. > > As far as I know, none of the chipset solutions currently available for SS > applications in 900MHz or 2.4 GHz can support these requirements. > > The only way I see out of this is to propose that as long as ERP doesn't > exceed part 15.247 limits then no control would be required, and go in for > eliminating the Station ID requirements. Not too satisfactory, because then > we might as well be operating under part 15 and not worrying about content. The ARRL proposal (RM-8737) states that automatic power control be implemented for systems which run more that 1W of power. Since all Part 15 devices (to the best of my knowledge) run 1W or less this rule should not hinder Hams at all. The ID requirement, on the other hand, will require some solution, either regulatory (which will take a long time - see how long it took the FCC to turn the proposal into a NPRM) or technical (I think I once saw someone offer up a solution to "key" up the SS radio like a CW rig). And even if we limit ourselves to 1W then we still have some benefits to being Amateurs. Part 15 has an ERP limitation that we do not. So I guess we get something for the restrictive rules under which we have to live (content, ID, first forwarding, etc.). 73, Robert Barron, KA5WSS barron@liant.com Liant Software Corporation Hook 'Em Horns! From mciminer@jazz.jpl.nasa.gov Thu Mar 06 10:15:44 1997 Received: from eis-net-001.jpl.nasa.gov (eis-net-001.jpl.nasa.gov [137.78.57.19]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id KAA02007 for ; Thu, 6 Mar 1997 10:15:43 -0600 (CST) Received: from jazz.Jpl.Nasa.Gov (jazz.jpl.nasa.gov [128.149.63.58]) by eis-net-001.jpl.nasa.gov (8.7.5/8.7.3) with SMTP id IAA21945 for ; Thu, 6 Mar 1997 08:15:36 -0800 (PST) Received: by jazz.Jpl.Nasa.Gov (4.1/SMI-4.1+DXRs2.3) id AA10287; Thu, 6 Mar 97 08:13:45 PST Date: Thu, 6 Mar 97 08:13:45 PST From: mciminer@jazz.jpl.nasa.gov (Michael Ciminera) Message-Id: <9703061613.AA10287@jazz.Jpl.Nasa.Gov> To: ss@tapr.org Subject: Re: [SS:1082] WT Docket No. 97-12 - Hollow Victory? Oh boy, > Looks like we have done it to ourselves now. > > The PRM submitted by ARRL and supported by FCC contains provisions that will > kill the possibility of easily leveraging off of commercial devices for our > efforts. The killers are automatic transmitter power control Yeah, no kidding. The complications of SNR/BER determination, minimum ERP calculation and power control implementation are something HAM usage would rather NOT be forced to do.. Can this be undone? mike wc6a From N5RG@aol.com Thu Mar 06 10:42:26 1997 Received: from emout03.mail.aol.com (emout03.mx.aol.com [198.81.11.94]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id KAA03499 for ; Thu, 6 Mar 1997 10:42:20 -0600 (CST) From: N5RG@aol.com Received: (from root@localhost) by emout03.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0) id LAA19001 for ss@tapr.org; Thu, 6 Mar 1997 11:41:47 -0500 (EST) Date: Thu, 6 Mar 1997 11:41:47 -0500 (EST) Message-ID: <970306114146_851659732@emout03.mail.aol.com> To: ss@tapr.org Subject: Re: [SS:1068] Re: SS Design > I would vote for a non-Ethernet solution. If Ethernet parts are that > cheap, someone could then design a board which provides the ethernet > interface and those that want it could get that interface card. > The latest JDR catalog lists Ethernet cards for $29.95. Why not take advantage of them? They transmit packets. 73, Roy W7IDM, ex N5RG From fred@tekdata.com Thu Mar 06 10:59:43 1997 Received: from tekdata.com (pool11-005.wwa.com [206.222.42.38]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA04489 for ; Thu, 6 Mar 1997 10:59:35 -0600 (CST) Received: (from fred@localhost) by tekdata.com (8.6.12/8.6.12) id KAA06827; Thu, 6 Mar 1997 10:50:04 -0600 Date: Thu, 6 Mar 1997 10:50:03 -0600 (CST) From: "Fred M. Spinner" To: ss@tapr.org Subject: Re: [SS:1062] Re: SS Design In-Reply-To: <12959@wb9mjn.ampr.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 5 Mar 1997 wb9mjn@wb9mjn.ampr.org wrote: > > Hi Paul, > > Really don t see how a RS-232 port makes thinks easier for Voice com- > munication. For Voice, some sorta in-box manually operated controls is the > ideal. And these controls are much more expensive to develope than either > the ethernet, or RS-232. > > The ethernet is cheaper, since both functions can be rolled into one > port. Rather than having the cost of two ports, and the software developement > to handle both ports simultaneously, flawlessly. It would be a higher up > front thing, but rolled into many units, there should be a payback. > > Altho, this idea might work with a parrallel port as well. As has been > done in some of the European packet networking hardware. A bidirectional > parallel port would have enuf capacity for control and moderate data rates. > Somebody should double check me on that statement, tho! It could work.. this is how (portable, non-SCSI) Zip drives work. > > The thing is, that RS-232 seems cheap, but RS-232 is not really going to > do the job above a couple hundred KB/s, in a standard computer. Then u need > the PI-card, and the higher performance differential drivers. So, is there > really a savings with RS-232 ? Or is it just a path to shifting the bucks > into a PC interface card that is of limited production? The new "USB" port coudl be useful as well. Its supposed to run at up to 2MBPS I think... But then again that won't help people with all but the newest of machines..I agree with Don on the ethernet card. RS-232 interfaces cant even handle ISDN speeds well. Why design something new with a bottle neck in place from the beginning? From fred@tekdata.com Thu Mar 06 10:59:53 1997 Received: from tekdata.com (pool11-005.wwa.com [206.222.42.38]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA04518 for ; Thu, 6 Mar 1997 10:59:44 -0600 (CST) Received: (from fred@localhost) by tekdata.com (8.6.12/8.6.12) id LAA06867; Thu, 6 Mar 1997 11:02:13 -0600 Date: Thu, 6 Mar 1997 11:02:13 -0600 (CST) From: "Fred M. Spinner" To: ss@tapr.org Subject: Re: [SS:1065] Re: SS Design In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 5 Mar 1997, Paul A Beltrani wrote: > > > On Tue, 4 Mar 1997 wb9mjn@wb9mjn.ampr.org wrote: > > > Really don t see how a RS-232 port makes thinks easier for Voice com- > > munication. For Voice, some sorta in-box manually operated controls is the > > ideal. And these controls are much more expensive to develope than either > > the ethernet, or RS-232. > > Quick example > Microphone --> CoDec chip --> serial data out --> SS Box > Speaker <-- Audio Amp <-- CoDec chip <-- serial data in <-- SS Box > why do you need rs-232 for this.. how about a simple TTL level serial port in addition to a ethernet NIC? > Simple and cheap. My guess is << $50 for the Audio/Codec stuff. > Why not build this onto the board. You can always socket the codecs and have the option to leave them off the boards??? > > The ethernet is cheaper, since both functions can be rolled into one > > port. Rather than having the cost of two ports, and the software developement > > to handle both ports simultaneously, flawlessly. It would be a higher up > > front thing, but rolled into many units, there should be a payback. > > You may be correct at an economy of scale level, but I am not sure there > is even enough interest to make developing a prototype worthwhile. (Other > than for the fun of it) Also, what I was suggesting does not require > simultaneous control of two ports. In fact, it does not even require two > ports. (See below) I tell you what: I'd only build one if it included a ethernet port. I have multiple computers and the concept of having it hooked to only one via a serial port is really not workable. > > > ... > > The thing is, that RS-232 seems cheap, but RS-232 is not really going to > > do the job above a couple hundred KB/s, in a standard computer. Then u need > > the PI-card, and the higher performance differential drivers. So, is there > > really a savings with RS-232 ? Or is it just a path to shifting the bucks > > into a PC interface card that is of limited production? > > ... EXACTLY>... > > You are correct. Let me respond to those points. > 1) RS-232 IS speed limited. However an RS-422 interface for the data side > will allow a chip like the Zilog Z8700 to operate at up to 2Mbps. We have > not really talked about how fast we would expect this SS Box to be. It is > not much of a benefit to talk to the box at 10Mbps if it can not process > the data that quickly. Geeze.. $200 for an Z8700 interface card vs $20 for an ethernet card... makes sense to me.. (NOT)...:) Fred KA9VAW fred@tekdata.com From ssampson@claven.tinker.af.mil Thu Mar 06 11:43:59 1997 Received: from othello.tinker.af.mil (othello.tinker.af.mil [137.240.231.43]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA08081 for ; Thu, 6 Mar 1997 11:43:45 -0600 (CST) Received: from localhost by othello.tinker.af.mil (AIX 4.1/UCB 5.64/4.03) id AA11514; Thu, 6 Mar 1997 11:43:08 -0600 Sender: ssampson@othello.tinker.af.mil Message-Id: <331F022C.794B@eds.tinker.af.mil> Date: Thu, 06 Mar 1997 11:43:08 -0600 From: Steve Sampson Organization: TRW Space & Electronics X-Mailer: Mozilla 3.01 (X11; U; AIX 1) Mime-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1091] Re: Morse ID at 20 WPM amidst 2 MBps data References: <44AE0207A4@rm1.liant.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert Barron wrote: > > Lee Fry wrote: > > Looks like we have done it to ourselves now. > > > The ARRL proposal (RM-8737) states that automatic power control > be implemented for systems which run more that 1W of power. This is completely acceptable. Everyone shake their (FCC, ARRL) hand, say "good job", and "just do it." Just slip them a note that says kill the ID requirement. If they leave the ID requirement in, then it's a failure, I'll go part 15 or 95 :-) Steve From jeff@mich.com Thu Mar 06 11:49:43 1997 Received: from server1.mich.com (root@server1.mich.com [198.108.16.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA08710 for ; Thu, 6 Mar 1997 11:49:41 -0600 (CST) Received: from gw-aerodata.mich.com (gw-aerodata.mich.com [198.108.16.60]) by server1.mich.com (8.8.4/8.8.4) with SMTP id MAA01535 for ; Thu, 6 Mar 1997 12:53:50 -0500 Message-Id: <2.2.32.19970306174908.007271ec@mail.mich.com> X-Sender: jeff@mail.mich.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 06 Mar 1997 12:49:08 -0500 To: ss@tapr.org From: Jeff King Subject: Re: [SS:1088] Re: WT Docket No. 97-12 - Hollow Victory? At 08:49 AM 3/6/97 -0600, Lyle Johnson wrote: >Lee, > >>The killers are automatic transmitter power control... >>...As far as I know, none of the chipset solutions currently available for SS >>applications in 900MHz or 2.4 GHz can support these requirements. > >The Harris PRISM chipset has an ADC that measures incoming signals and this I think automatic power control is both a good idea and technically doable. I DO however have a problem with it being mandated by law when SS is the ONLY service in amateur radio in which it is being mandated. BTW, the Zilog hopper chip also supports power control. So the ARRL is saying that amateurs that run SS are to stupid to use the the minimum power required to make communications? (as required by law). So all those DX'ers that are running kilowatts don't need automatic power control? Or the local 2metre repeater that is running 400 watts shouldn't use automatic power control? Automatic power control is technically possible for almost every modulation mode. I have a serious problem with SS being singled out by the ARRL, in particular with legal regulations. >Anyway, one can look at BER or retries or ??? and then set the power level >by the processor that must be embedded in this widget anyhow. Automatic >power control isn't a big deal IMHO -- heck, even the HF guys use it >(clover and the like) :-) Yeap, they use automatic power control because it makes sense. And gosh, they don't even need the government telling them to do it! I guess those spread spectrum folks are just to stupid to realize the advantages of power control. Gotta get the goverment involved to keep the threat of SS to amateur radio under control. > >>and retention >>of the station ID requirements. > >I'm sure there is a way to solve this, too... > Yeap, any thoughts on commenting on the NPRM? Best way to solve that one would be to remove it (i.e. put the ID in the data stream) Or is it to late? I must have been asleep at the switch if I missed the above two points Lee raised. -Jeff wb8wka From fred@tekdata.com Thu Mar 06 11:58:12 1997 Received: from tekdata.com (pool11-029.wwa.com [206.222.42.62]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA09018 for ; Thu, 6 Mar 1997 11:58:03 -0600 (CST) Received: (from fred@localhost) by tekdata.com (8.6.12/8.6.12) id LAA06945; Thu, 6 Mar 1997 11:22:49 -0600 Date: Thu, 6 Mar 1997 11:22:49 -0600 (CST) From: "Fred M. Spinner" To: ss@tapr.org cc: ss@tapr.org Subject: Re: [SS:1083] Re: SS Design In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 6 Mar 1997, Magne Mahre wrote: > > > On Thu, 6 Mar 1997, Lee W. Fry wrote: > > > Let's go for 900MHz and above and elbow our way in there beside the other > > users in overlapping and nearby unlicensed WLAN spectra. > > If the decision is that one's going to put all the RF-parts into the > project (and not base oneself on transverters), may I suggest that one > settle for a frequency band allocated to the amateur service in a larger area > than just region 2 ? > > Region 1 has the following allocations: > > 432-438 > 1240-1300 > 2300-2450 > 3400-3500 > 5650-5850 > 10250-10500 > 24000-24050 > the 1.2 Ghz band, 2.4 GHZ band and 3.4 GHz bands are do able without too many exotic parts. We are in the process of getting stripped of our 2.4 GHz band... maybe something like in the 2420 MHz area would be good.. maybe we could save that band. I've been kicking around the idea of running like 115+ KBPS non-SS simple, high bandwidth FSK on this band. The funny thing is that we could do this now, it'd be legal, it'd be faster than most people's current, the bandwidth is available... but we fear microwaves. Something like a really simple interface at 2M or 70CM could be a mod/demod for a transverter, or even better something directly at the frequency could be made to do this rather inexpensively. Hell, it might even be possible to make an interface from 10-base-T to modulate a setup for 10 MBPS links up on the higher microwave bands. (This would simplify computer interfaces a tad bit, don't you think??) Why not, whats 20 or 30 MHz of spectrum in a band that has 500 MHZ that no one uses? Fred M. Spinner, KA9VAW fred@tekdata.com From fred@tekdata.com Thu Mar 06 11:58:19 1997 Received: from tekdata.com (pool11-029.wwa.com [206.222.42.62]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA09055 for ; Thu, 6 Mar 1997 11:58:13 -0600 (CST) Received: (from fred@localhost) by tekdata.com (8.6.12/8.6.12) id LAA06920; Thu, 6 Mar 1997 11:05:33 -0600 Date: Thu, 6 Mar 1997 11:05:33 -0600 (CST) From: "Fred M. Spinner" To: ss@tapr.org Subject: Re: [SS:1075] Re: SS Design In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 5 Mar 1997, Phil Karn wrote: > >1) RS-232 IS speed limited. However an RS-422 interface for the data side > >will allow a chip like the Zilog Z8700 to operate at up to 2Mbps. We have > >not really talked about how fast we would expect this SS Box to be. It is > >not much of a benefit to talk to the box at 10Mbps if it can not process > >the data that quickly. > > And where do I get an RS-422 interface for my laptop? How much do > they cost? You can get converters from the balanced RS-422 to the RS-232.. but I think the lack of speed ability of the RS-232 on your laptop is the real problem... We use B&B electronics ones when our customers have to run a serial line several hundred feet. They cost about $60 a side.. still more $$$ than an ethernet card. > From jeff@mich.com Thu Mar 06 11:59:37 1997 Received: from server1.mich.com (root@server1.mich.com [198.108.16.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA09106 for ; Thu, 6 Mar 1997 11:59:34 -0600 (CST) Received: from gw-aerodata.mich.com (gw-aerodata.mich.com [198.108.16.60]) by server1.mich.com (8.8.4/8.8.4) with SMTP id NAA02740 for ; Thu, 6 Mar 1997 13:03:45 -0500 Message-Id: <2.2.32.19970306175902.008fba9c@mail.mich.com> X-Sender: jeff@mail.mich.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 06 Mar 1997 12:59:02 -0500 To: ss@tapr.org From: Jeff King Subject: Re: [SS:1091] Re: WT Docket No. 97-12 - Hollow Victory? At 10:14 AM 3/6/97 -0600, Robert Barron wrote: >Lee Fry wrote: >> Looks like we have done it to ourselves now. clip > >The ARRL proposal (RM-8737) states that automatic power control >be implemented for systems which run more that 1W of power. Since >all Part 15 devices (to the best of my knowledge) run 1W or less >this rule should not hinder Hams at all. Yeah, OK. Why even run under part 97 then? WAY to much liability. Do you think they made this proposal not being aware of this? >And even if we limit ourselves to 1W then we still have some >benefits to being Amateurs. Part 15 has an ERP limitation that we >do not. So I guess we get something for the restrictive rules under >which we have to live (content, ID, first forwarding, etc.). > >73, > >Robert Barron, KA5WSS barron@liant.com >Liant Software Corporation Hook 'Em Horns! The only thing we get for the restrictive rules we live under is a decaying service. The rules should be reduced and liberalized to reflect present day society, not some ozzy and harriet 1950's view of amateur radio. -Jeff wb8wka From rlanier@su102s.ess.harris.com Thu Mar 06 13:24:07 1997 Received: from ess.harris.com (su15a.ess.harris.com [130.41.1.251]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id NAA14634 for ; Thu, 6 Mar 1997 13:24:05 -0600 (CST) Received: from losalamos.ess.harris.com (su102s.ess.harris.com [130.41.13.101]) by ess.harris.com (8.8.5/8.8.5) with SMTP id OAA26818 for ; Thu, 6 Mar 1997 14:23:58 -0500 (EST) Received: from Muskegon.com.gasd102 by losalamos.ess.harris.com (4.1/SMI-4.1) id AA14953; Thu, 6 Mar 97 14:23:59 EST Received: by Muskegon.com.gasd102 (SMI-8.6/SMI-SVR4) id OAA26057; Thu, 6 Mar 1997 14:23:55 -0500 Date: Thu, 6 Mar 1997 14:23:55 -0500 From: rlanier@su102s.ess.harris.com (Tony Lanier) Message-Id: <199703061923.OAA26057@Muskegon.com.gasd102> To: ss@tapr.org Subject: Data Interfaces X-Sun-Charset: US-ASCII Is there any reason why we CAN NOT have a data interface module for the SS box? For example, can we spec the data rate coming out of the SS box at say 1Mbps, but then rate buffer the data to a slower rate (using a FIFO) for those who want to develop a RS-232/RS-422 interface module? The data moving through the SS box will need to be set at a constant rate, just the data moving to and from it can vary. Tony KE4ATO From rlanier@su102s.ess.harris.com Thu Mar 06 13:30:11 1997 Received: from ess.harris.com (su15a.ess.harris.com [130.41.1.251]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id NAA14833 for ; Thu, 6 Mar 1997 13:30:09 -0600 (CST) Received: from losalamos.ess.harris.com (su102s.ess.harris.com [130.41.13.101]) by ess.harris.com (8.8.5/8.8.5) with SMTP id OAA26910 for ; Thu, 6 Mar 1997 14:30:05 -0500 (EST) Received: from Muskegon.com.gasd102 by losalamos.ess.harris.com (4.1/SMI-4.1) id AA15038; Thu, 6 Mar 97 14:30:05 EST Received: by Muskegon.com.gasd102 (SMI-8.6/SMI-SVR4) id OAA26060; Thu, 6 Mar 1997 14:30:02 -0500 Date: Thu, 6 Mar 1997 14:30:02 -0500 From: rlanier@su102s.ess.harris.com (Tony Lanier) Message-Id: <199703061930.OAA26060@Muskegon.com.gasd102> To: ss@tapr.org Subject: Re: [SS:1098] Re: SS Design X-Sun-Charset: US-ASCII > the 1.2 Ghz band, 2.4 GHZ band and 3.4 GHz bands are do able without too > many exotic parts. We are in the process of getting stripped of our > 2.4 GHz band... maybe something like in the 2420 MHz area would be good.. > maybe we could save that band. > > Fred M. Spinner, KA9VAW > fred@tekdata.com > > This is the reason why we need a modular radio. Whoever wants to go microwave, go do it! If and when we can do HF, then do HF. If for any other reason, we (or anyone else) can't seem to agree on the band of choice. Tony KE4ATO From jmorriso@bogomips.com Thu Mar 06 14:50:54 1997 Received: from orange.ConcordPacific.Com (orange.ConcordPacific.com [204.239.26.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id OAA20519 for ; Thu, 6 Mar 1997 14:50:51 -0600 (CST) Received: from bogomips.com (root@bogomips.com [206.108.196.1]) by orange.ConcordPacific.Com (8.6.12/8.6.12) with SMTP id MAA22468 for ; Thu, 6 Mar 1997 12:51:17 -0800 Received: by bogomips.com (Linux Smail3.1.29.1 #3) id m0w2k86-000TwZC; Thu, 6 Mar 97 12:51 PST Message-Id: From: jmorriso@bogomips.com (John Paul Morrison) Subject: Re: [SS:1083] SS digest 258 To: ss@tapr.org Date: Thu, 6 Mar 1997 12:51:10 -0800 (PST) In-Reply-To: from "ss@tapr.org" at Mar 6, 97 07:39:09 am X-Bogomips: 33.55 Content-Type: text > > Date: Wed, 5 Mar 1997 02:13:05 -0800 (PST) > From: Phil Karn > To: ss@tapr.org > Subject: Re: SS Design > Message-ID: > > I also argue for Ethernet. It's the "rs-232 of the '90s". The > interfaces (chips and complete boards) are now universally available > very cheap, the chips are much easier to talk to (especially since > just about every operating system comes with built-in drivers) and of > course it's far faster than RS-232. 10BaseT can be used in a simple > 4-wire point-to-point mode, or with a hub it can handle many > party-lined devices. Easier to transmit around the house too, given > that 10Base T is already differentially encoded, while RS-232 is not. > > I'm continually amazed at how many people keep trying to turn RS-232 > into something like Ethernet (only much slower) to "save money", just > as they keep trying to turn NOS into UNIX now that Linux is around... Linux? Can we quote you as an endorser of Linux, coming from a BSD guy? :-) But anyway, I saw Alan Cox the Linux network code designer talking about your sound blaster code with FEC coding. Does this code exist for NOS or Linux? (I know the soundblaster code and viterbi code exist separately, but are they rolled into one device now?) What's interesting about Linux, and I don't mean to plug it in a partisan way, is that people have written all sorts of interesting networking protocols into it, and also support for some ham radio hardware. Stuff like AX.25, NetROM, Rose (X.25 plp for packet radio), even IPX, Appletalk. There's also DecNet, X.25 and 802.3 LLC and bridging. Hardware such as TNCs, PI cards, Baypacs etc. And now there is a sound card driver in Linux that is supposed to do 1200, 4800 and 9600bps packet radio. I don't think it does FEC but that would be interesting to experiment with. The driver might do fax and rtty but I'm not sure if that's done yet. I've seen a few comments on this list about building hardware and it resembles some of the flurry of excitement on the TNC-The Next Generation list, which went nowhere. A lot of people (myself included) were interested in designing and building a neat new box with all sorts of features. But that fizzled. I realized that even if a fancy box were built, it would have to go through numerous hardware revisions (it's expensive to beta test HARDware), and the software would be where it all falls apart, because it takes time and money to port a complex program to a new box, or to write it from scratch. I've come round to your thinking of using a generic PC to do all the DSP and coding. It's far easier to leverage the PC software (ie Linux or the GCC version of NOS/TNOS) to control a new device. IF a 386 with a soundblaster can replace a traditional multiport 1200/9600bps TNC, then a 486 or Pentium could do spread spectrum or something else. There's also free software that does Iphone like features, multicast audio etc. So a PC could do voice or video as well not just "data" networking. Ascend and Cisco can take Motorola 68EN360's, ethernet, serial, flash and dram and sell little remote access routers for $1000 or less because they have the sales volume to make the hardware prices cheaper and to amortize the programming development over many other products that use the same software. Hams can't build anything that fancy AND that cheap. > Phil > > --------------------------------------------------------------------------- BogoMIPS Research Labs -- bogosity research & simulation -- VE7JPM -- jmorriso@bogomips.com ve7jpm@ve7jpm.ampr.org jmorriso@ve7ubc.ampr.org --------------------------------------------------------------------------- From dhoyer@frontiercorp.com Thu Mar 06 16:09:56 1997 Received: from node1.frontiernet.net (node1.frontiernet.net [205.232.174.11]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA25099 for ; Thu, 6 Mar 1997 16:09:53 -0600 (CST) From: dhoyer@frontiercorp.com Received: from ccm.frontiercorp.com (ccm.frontiercorp.com [204.168.13.16]) by node1.frontiernet.net (8.8.5/8.8.2) with SMTP id QAA26712 for ; Thu, 6 Mar 1997 16:14:38 -0500 Received: from ccMail by ccm.frontiercorp.com (ccMail Link to SMTP R6.00.01) id AA857670848; Thu, 06 Mar 97 16:14:52 -0500 Message-Id: <9703068576.AA857670848@ccm.frontiercorp.com> X-Mailer: ccMail Link to SMTP R6.00.01 Date: Thu, 06 Mar 97 11:49:52 -0500 To: Subject: Re: [SS:1088] Re: WT Docket No. 97-12 - Hollow Victory? MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I don't know if anyone else put this up here, but here's the Harris web site for the Prism chipset: http://www.semi.harris.com/PRISM.html Dan KA9VMI ______________________________ Reply Separator _________________________________ Subject: [SS:1088] Re: WT Docket No. 97-12 - Hollow Victory? Author: at INTERNET Date: 3/6/97 8:49 AM Lee, >The killers are automatic transmitter power control... >...As far as I know, none of the chipset solutions currently available for SS >applications in 900MHz or 2.4 GHz can support these requirements. The Harris PRISM chipset has an ADC that measures incoming signals and this measurement is available in a register. It also supports, I beleive, stepped power output levels. This is from memory, the Harris apps guy was in my office last week for a couple hours and I may have forgottern something (I'm not at work as I write this). Anyway, one can look at BER or retries or ??? and then set the power level by the processor that must be embedded in this widget anyhow. Automatic power control isn't a big deal IMHO -- heck, even the HF guys use it (clover and the like) :-) >and retention >of the station ID requirements. I'm sure there is a way to solve this, too... Cheers, Lyle From stever@a.crl.com Thu Mar 06 18:02:32 1997 Received: from bryce.ampr.org (A113019.sna1.as.crl.com [168.75.113.19]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA01764 for ; Thu, 6 Mar 1997 18:02:28 -0600 (CST) Received: (from stever@localhost) by bryce.ampr.org (8.7.4/8.7.3) id QAA23253; Thu, 6 Mar 1997 16:55:25 -0800 Date: Thu, 6 Mar 1997 16:55:24 -0800 (PST) From: "Steven M. Ruiz" X-Sender: stever@bryce.ampr.org To: ss@tapr.org Subject: Re: [SS:1095] Re: SS Design In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 6 Mar 1997, Fred M. Spinner wrote: > > Geeze.. $200 for an Z8700 interface card vs $20 for an ethernet card... > makes sense to me.. (NOT)...:) > Geeze yourself, I purchase my ethernet cards for $14.00 each in single quantity and even less for bulk purchases or 5 or more. :) The point is value per dollar. If on board processing for voice, video, frequency control, etc. is needed there are Single Board Computers (SBC's) that are pleny cheap and powerfull enough to do the job. The SBC's can be built into the SS box or connected via ethernet (RG-58) cabling. This keeps with the idea of modularity. Steve, KN6XQ From lfry@mindspring.com Thu Mar 06 18:14:46 1997 Received: from mule0.mindspring.com (mule0.mindspring.com [204.180.128.166]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA02427 for ; Thu, 6 Mar 1997 18:14:45 -0600 (CST) Received: from glory (user-168-121-136-107.dialup.mindspring.com [168.121.136.107]) by mule0.mindspring.com (8.8.4/8.8.4) with SMTP id TAA145460 for ; Thu, 6 Mar 1997 19:14:43 -0500 Message-Id: <2.2.32.19970307001702.003dde80@mindspring.com> X-Sender: lfry@mindspring.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 06 Mar 1997 19:17:02 -0500 To: ss@tapr.org From: "Lee W. Fry" Subject: Re: [SS:1088] Re: WT Docket No. 97-12 - Hollow Victory? At Thu, 6 Mar 1997 08:49:17 -0600 (CST), Lyle Johnson wrote in [SS:1088]: >Anyway, one can look at BER or retries or ??? and then set the power level >by the processor that must be embedded in this widget anyhow. Automatic >power control isn't a big deal IMHO -- heck, even the HF guys use it >(clover and the like) :-) I am sure that there is a reasonable way to modulate power too. But the actual wording of the ARRL proposed rule is: The transmitter power output must not exceed 100 W under any circumstances. If more than 1 W is used, automatic transmitter control shall limit output power to that which is required for the communication. This shall be determined by use of the ratio, measured at the receiver, of the received energy per user data bit (Eb) to the sum of the received power spectral densities of noise (No) co-channel interference (Io). Average transmitter power over 1 W shall automatically adjusted to maintain an Eb/(No+Io) ratio of no more than 23 db at the intended receiver . I am not smart enough about the theory to figure out how to transform the BER the Prism chip measures or higher level protocol metrics like retries into the ARRL power metric (Eb/(No+Io) < 23 db). Robert Buaas in his comments on the PRM said " the hardware needed to control power output is simple, the algorithms required to determine how to dynamically adjust the hardware are not" I believe him. How about it anybody? Is the conversion from BER (or anything else available from available chip sets) to Eb/(No+Io) simple and is it implemented in any of the transceiver interfaces available? Lee W. Fry AA0JP lfry@mindspring.com See my Part 15 Spread Spectrum Device Compendium at: http://www.mindspring.com/~lfry/part15.htm From lylej@azstarnet.com Thu Mar 06 19:02:57 1997 Received: from mailhost.azstarnet.com (mailhost.azstarnet.com [169.197.1.8]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA04558 for ; Thu, 6 Mar 1997 19:02:54 -0600 (CST) Received: from tomswift (usr15ip48.azstarnet.com [169.197.16.48]) by mailhost.azstarnet.com (8.8.3-p/8.8.5) with SMTP id RAA12538 for ; Thu, 6 Mar 1997 17:56:45 -0700 (MST) Message-Id: <3.0.32.19970306175938.00736c08@pop.azstarnet.com> X-Sender: lylej@pop.azstarnet.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 06 Mar 1997 18:01:25 -0700 To: ss@tapr.org From: Lyle Johnson Subject: Re: [SS:1097] Re: WT Docket No. 97-12 - Hollow Victory? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >I think automatic power control is both a good idea and technically >doable. I DO however have a problem with it being mandated by law >when SS is the ONLY service in amateur radio in which it is being >mandated. BTW, the Zilog hopper chip also supports power control. My old copy of the FCC Ruklebook , part 97.313(a) reads "An amateur station must use th eminimum transmitter power necessary to carry out the desired communications." So, we're all obligated under law to do this. SS just requires it to be automatic. Since these are processor-controlled systems anyway, this is no big deal to do. We can spend a lot of energy arguing, or we can spend some energy implementing. If you are against it, why not just write in your reply comments that 97.313 already mandates this so the requirement is redundant and it shouldn't be in the new SS regs. >Yeap, any thoughts on commenting on the NPRM? Best way to solve that >one would be to remove it (i.e. put the ID in the data stream) Or >is it to late? I must have been asleep at the switch if I missed >the above two points Lee raised. Yep, that is what I would argue for. We did this successfully with packet years ago when CWID was a requirement. Our technical solution was going to be to have a central node tell everyone on channel to send CWID ...NOW and all stations would key up and do it then :-) Now, with cheap GPS, we can just do it on the GPS second interval that satisifes the FCC :-) Or, since we have power control mandated, we can just modulate the carrier above the low-thereshold for SS communications and superimpose the CWID over the transmission (but if data is moving fast, we'll have to send a LONG file to last enough time to get the ID in :-) Cheers, Lyle From jerryn@ici.net Thu Mar 06 20:24:19 1997 Received: from localhost (d-ma-fallriver-85.ici.net [207.180.10.94]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id UAA08985 for ; Thu, 6 Mar 1997 20:24:16 -0600 (CST) Received: from nomad by localhost with smtp (Smail3.1.29.1 #58) id m0w2pJN-000VTfC; Thu, 6 Mar 97 21:23 EST Sender: root@tapr.org Message-ID: <331F7C0D.50A42891@ici.net> Date: Thu, 06 Mar 1997 21:23:09 -0500 From: Jerry Normandin X-Mailer: Mozilla 4.0b2 (X11; I; Linux 2.0.26 i686) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1089] Re: SS Design X-Priority: 3 (Normal) References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Bob Lorenzini wrote: > > I agree with all those advocating an ethernet interface and would like > to stress two points. It makes remoting the unit close to the ant much > easier and all OS's can talk IP over ethernet. No need for those who do > not run linux to learn unix. > > Bob - wd6dod Just because I talk IP with my Linux box over the DOES NOT MEAN YOU MUS AS WELL!!!!!!!!!! AS LONG AS YOU FOLLOW the SAME IP Protocol you will hear me!!!!!!!!!!!!!!! Stick to the standards... I don't care what interface you are using I will hear you!!!!!!!!! So enough of the pissing contest allready. From jerryn@ici.net Thu Mar 06 20:28:54 1997 Received: from localhost (d-ma-fallriver-85.ici.net [207.180.10.94]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id UAA09175 for ; Thu, 6 Mar 1997 20:28:52 -0600 (CST) Received: from nomad by localhost with smtp (Smail3.1.29.1 #58) id m0w2pNv-000VTfC; Thu, 6 Mar 97 21:27 EST Sender: root@tapr.org Message-ID: <331F7D27.1B9F5AAC@ici.net> Date: Thu, 06 Mar 1997 21:27:51 -0500 From: Jerry Normandin X-Mailer: Mozilla 4.0b2 (X11; I; Linux 2.0.26 i686) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1093] Re: SS Design X-Priority: 3 (Normal) References: <970306114146_851659732@emout03.mail.aol.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii N5RG@aol.com wrote: > > > > I would vote for a non-Ethernet solution. If Ethernet parts are that > > cheap, someone could then design a board which provides the ethernet > > interface and those that want it could get that interface card. > > > > The latest JDR catalog lists Ethernet cards for $29.95. Why not take > advantage of them? They transmit packets. > > 73, Roy W7IDM, ex N5RG You are correct my friend. many people don't realize how much power an ethernet card has. I was just playing around one day and noticed if I connect the ground to the ground plane of the antennea and the signal to a 3" dipole I could actually transmit!!!!!!!!!!!!!!!!!!!!!!!! Granted I only was able to get about 3 feet of range if we make a billateral amplifier we may be able to make a cheap cheap cheap wireless card. All we need to do is slap a Spectrum Analyzer on a NE2000 Card... check out the characteristics of the typical coxial output. By the way forgot to mention I had a 25Ohm load between the antennea and ground. From ssampson@othello.tinker.af.mil Thu Mar 06 20:30:08 1997 Received: from othello.tinker.af.mil (othello.tinker.af.mil [137.240.231.43]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id UAA09290 for ; Thu, 6 Mar 1997 20:30:07 -0600 (CST) Received: by othello.tinker.af.mil (AIX 4.1/UCB 5.64/4.03) id AA16718; Thu, 6 Mar 1997 20:30:05 -0600 Date: Thu, 6 Mar 1997 20:30:05 -0600 From: ssampson@othello.tinker.af.mil (Steve Sampson) Message-Id: <9703070230.AA16718@othello.tinker.af.mil> To: ss@tapr.org Subject: Re: ID Requirements That's a good point about ID and power control. Is there anything illegal about sending the ID at -90 dBm?? Steve "Power control--Good Good" "Narrow Band ID--Bad Bad" From rdcole@mindspring.com Thu Mar 06 20:30:35 1997 Received: from camel6.mindspring.com (camel6.mindspring.com [204.180.128.212]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA09335 for ; Thu, 6 Mar 1997 20:30:32 -0600 (CST) Received: from roncole (mule1.mindspring.com [204.180.128.167]) by camel6.mindspring.com (8.8.5/8.7.3) with ESMTP id VAA04071 for ; Thu, 6 Mar 1997 21:30:30 -0500 (EST) Message-ID: <331F7DE7.30A0@mindspring.com> Date: Thu, 06 Mar 1997 20:31:04 -0600 From: Ron Cole X-Mailer: Mozilla 4.0b2 (Win95; I) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1099] Re: SS Design X-Priority: 3 (Normal) References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Fred M. Spinner wrote: On Wed, 5 Mar 1997, Phil Karn wrote: > >1) RS-232 IS speed limited. However an RS-422 interface for the data side > >will allow a chip like the Zilog Z8700 to operate at up to 2Mbps. We have > >not really talked about how fast we would expect this SS Box to be. It is > >not much of a benefit to talk to the box at 10Mbps if it can not process > >the data that quickly. > > And where do I get an RS-422 interface for my laptop? How much do > they cost? You can get converters from the balanced RS-422 to the RS-232.. but I think the lack of speed ability of the RS-232 on your laptop is the real problem... All of the Serial ports RS-232 or RS-422 are just too slow. I think the only way to proceed is with a Ethernet port. Don't think in Packet Radio TNC or Phone Modem terms, think of a Network IP Router. That connects networks together. Via Radio. Ether net technology is just too cheep no to use it. The target for a 1st generation SS radio should be something around 2Mbps. Ron Cole N5HYH From hbaker@netcom.com Thu Mar 06 21:38:30 1997 Received: from netcom3.netcom.com (hbaker@netcom3.netcom.com [192.100.81.103]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id VAA13848 for ; Thu, 6 Mar 1997 21:38:26 -0600 (CST) Received: (from hbaker@localhost) by netcom3.netcom.com (8.6.13/Netcom) id TAA28254; Thu, 6 Mar 1997 19:38:20 -0800 From: hbaker@netcom.com (Henry G. Baker) Message-Id: <199703070338.TAA28254@netcom3.netcom.com> Subject: Re: [SS:1109] Re: SS Design To: ss@tapr.org Date: Thu, 6 Mar 1997 19:38:20 -0800 (PST) Cc: hbaker@netcom.com In-Reply-To: <331F7D27.1B9F5AAC@ici.net> from "Jerry Normandin" at Mar 6, 97 08:37:22 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > You are correct my friend. many people don't realize how much power an > ethernet card has. > I was just playing around one day and noticed if I connect the ground to > the ground plane > of the antennea and the signal to a 3" dipole I could actually > transmit!!!!!!!!!!!!!!!!!!!!!!!! > Granted I only was able to get about 3 feet of range if we make a > billateral amplifier we may > be able to make a cheap cheap cheap wireless card. > All we need to do is slap a Spectrum Analyzer on a NE2000 Card... check > out the characteristics > of the typical coxial output. > By the way forgot to mention I had a 25Ohm load between the antennea and > ground. On a less whimsical note, what about a totally software SS scheme. The idea is to use a computer to generate the signals necessary -- perhaps on a parallel port, with perhaps a final cap and/or coil filter before putting it onto an antenna. Maybe one could only get a few MHz this way, and perhaps only a relatively low data rate, but the price would also be miniscule. -- Henry Baker www/ftp directory URL: ftp://ftp.netcom.com/pub/hb/hbaker/home.html From jeff@mich.com Thu Mar 06 22:26:46 1997 Received: from server1.mich.com (root@server1.mich.com [198.108.16.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA16711 for ; Thu, 6 Mar 1997 22:26:45 -0600 (CST) Received: from gw-aerodata.mich.com (gw-aerodata.mich.com [198.108.16.60]) by server1.mich.com (8.8.4/8.8.4) with SMTP id XAA05597 for ; Thu, 6 Mar 1997 23:27:35 -0500 Message-Id: <2.2.32.19970307042611.006e1e18@mail.mich.com> X-Sender: jeff@mail.mich.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 06 Mar 1997 23:26:11 -0500 To: ss@tapr.org From: Jeff King Subject: Re: [SS:1107] Re: WT Docket No. 97-12 - Hollow Victory? At 07:04 PM 3/6/97 -0600, Lyle Johnson wrote: > >>I think automatic power control is both a good idea and technically >>doable. I DO however have a problem with it being mandated by law >>when SS is the ONLY service in amateur radio in which it is being >>mandated. BTW, the Zilog hopper chip also supports power control. > >My old copy of the FCC Ruklebook , part 97.313(a) reads "An amateur station >must use th eminimum transmitter power necessary to carry out the desired >communications." > >So, we're all obligated under law to do this. SS just requires it to be >automatic. Since these are processor-controlled systems anyway, this is no >big deal to do. We can spend a lot of energy arguing, or we can spend some >energy implementing. Who is arguing? We already agree power control is a good idea. You miss my point completely however. Why do you support a specific rule for automatic power control for SS systems and not for narrowband systems? This sets a precedent of holding SS users to a higher standard then narrowband users. By your own admission, automatic power control on SS (or any mode for that matter) is easy.... why do we need government regulations to tell us to do something that simply makes sense? Do the clover users on HF (which you earlier mentioned) need government regulations to implement power control? My point is (and I think most in the SS-STA would agree) is that spread spectrum is a legitimate amateur RF emission. I've (almost) exclusively operated spread spectrum for the last 2 years. In fact, this is how this message is getting to you now. I'd not have ANY objection to some form of automatic power control for amateur radio emissions... I do have a problem of SS being singled out as the only emission that this is required for. I think this sets a precedent we don't want to agree to. If there is some sort of long term plan here to introduce automatic power control to amateur radio, let me know as I'm not aware of it. Remember, narrowband emissions can easily wipe out DSSS signals. Power control for narrowband emitters would help SS out also. > >If you are against it, why not just write in your reply comments that >97.313 already mandates this so the requirement is redundant and it >shouldn't be in the new SS regs. As I said, it should either be in the AMATEUR regs for all emissions or not at all. I see absolutely no reason why Spread Spectrum should be singled out in this regard. I'd like to get some feedback from this group first, but yes, I do plan on commenting. Thanks -Jeff wb8wka --------- "Power control for _ALL_ amateur emissions --Good Good" "Narrow Band ID--Bad Bad" From lfry@mindspring.com Fri Mar 07 05:56:57 1997 Received: from mule0.mindspring.com (mule0.mindspring.com [204.180.128.166]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id FAA13803 for ; Fri, 7 Mar 1997 05:56:55 -0600 (CST) Received: from glory (user-168-121-136-107.dialup.mindspring.com [168.121.136.107]) by mule0.mindspring.com (8.8.4/8.8.4) with SMTP id GAA39028 for ; Fri, 7 Mar 1997 06:56:50 -0500 Message-Id: <2.2.32.19970307115926.003e0bdc@mindspring.com> X-Sender: lfry@mindspring.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 07 Mar 1997 06:59:26 -0500 To: ss@tapr.org From: "Lee W. Fry" Subject: Ethernet Interface There seems to be plenty of interest in having a box that looks like an IP router, connected by twisted pair ethernet. Such a box could certainly be based on an ISA architecture computer with a plug-in ethernet card and radio interfaced by any number of means including ISA or PCMCIA plug-in, parallel port or serial. As amatter of fact many of the commercial WLAN access points are just that, a computer with ethernet and radio cards. However, I don't think Phil wants to carry a computer around to hook to his laptop and I don't want to mount one on my tower (if I even had one). So what we want to look at is something like the ISDN routers that are available now. A desktop modem sized box with an IP router front end and in our case, an RF modem on the back end. I hope that when Phil started talking about using ethernet he was visualizing a router, and not just writing our own drivers to send data packets over the ethernet wire. If one objective is to operate in a Windows environment on the host, It would seem like to me that any approach that required something like a shim below the Winsock level would cause the radio to not be able to coexist in a Windows box with standard networking to other ethernet hosts. Does anybody around have any knowledge of the technology used to implement the IP router function in devices such as the Ascend ISDN router? Is there a chip set? Lee W. Fry AA0JP lfry@mindspring.com See my Part 15 Spread Spectrum Device Compendium at: http://www.mindspring.com/~lfry/part15.htm From zeus@myth.demon.co.uk Fri Mar 07 07:53:21 1997 Received: from myth.demon.co.uk (myth.demon.co.uk [158.152.20.217]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id HAA20140 for ; Fri, 7 Mar 1997 07:53:15 -0600 (CST) Date: Fri, 07 Mar 1997 12:56:53 GMT From: zeus@myth.demon.co.uk (Mike Cowgill) Reply-To: zeus@myth.demon.co.uk Message-Id: <2165@myth.demon.co.uk> To: ss@tapr.org Subject: Confused? (I am) X-no-archive: yes X-Mailer: PCElm 1.10 beta 3 Lines: 15 I've obviously not been paying enough attention (nothing new there) because I am confused over this Ethernet thing. Is the idea just to use Ethernet as a direct data source/sink to/from the keyer and correlator, or just to use it as a data pipe to a controller? If it is a direct source then there are obvious problems with varying data rate etc. If it is as a data pipe, then isn't this a bit premature? The usual way of developing this sort of stuff (or at least the way I developed stuff like GPS/Glonass receivers) is using a PC/AT breadboard for digital control (an 8255 or whatever) and DMA data pump, moving over to a local processor control (and arguments about data feed) when you get the basic system working. Mike P.S. How about a SCSI feed? From hwm@netcom.com Fri Mar 07 10:08:21 1997 Received: from mm.wd6dod.ampr.org (hwm@netcom4.netcom.com [192.100.81.107]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id KAA27334 for ; Fri, 7 Mar 1997 10:08:09 -0600 (CST) Received: from localhost (by mm.wd6dod.ampr.org (8.7.5/8.6.12) with SMTP id IAA00233 for ; Fri, 7 Mar 1997 08:09:05 -0800 Date: Fri, 7 Mar 1997 08:09:05 -0800 (PST) From: Bob Lorenzini To: ss@tapr.org Subject: Re: [SS:1108] Re: SS Design In-Reply-To: <331F7C0D.50A42891@ici.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 6 Mar 1997, Jerry Normandin wrote: > Bob Lorenzini wrote: > > > > I agree with all those advocating an ethernet interface and would like > > to stress two points. It makes remoting the unit close to the ant much > > easier and all OS's can talk IP over ethernet. No need for those who do > > not run linux to learn unix. > > > > Bob - wd6dod > Just because I talk IP with my Linux box over the DOES NOT MEAN YOU MUS > AS WELL!!!!!!!!!! > > AS LONG AS YOU FOLLOW the SAME IP Protocol you will hear > me!!!!!!!!!!!!!!! > Stick to the standards... I don't care what interface you are using I > will hear you!!!!!!!!! > So enough of the pissing contest allready. I think you missunderstood what I was trying to say or perhaps I did not make myself clear. I have nothing against linux. If you had checked my header you would have noticed that it came from linux. In fact it was sent over RF between two linux boxes. Much of the hostility toward linux comes from the fact that we linux users in our enthusiasm over a great operating system become so envangelical that we offend others. Rereading your comments, I'am not sure what your complaint is. My point was that a ss-box with an ethernet interface would talk to any OS. I suspect that many of those who are interested in SS don't want to learn unix system administration in order to experiment with high speed networking. Bob - wd6dod From RLANIER@mailb.harris.com Fri Mar 07 10:30:38 1997 Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.104.14]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA28171 for ; Fri, 7 Mar 1997 10:30:36 -0600 (CST) Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special version 2.0) id LAA28498; Fri, 7 Mar 1997 11:30:27 -0500 Received: from ccMail by mailb.harris.com (IMA Internet Exchange 1.04b) id 32042280; Fri, 7 Mar 97 11:28:24 -0500 Mime-Version: 1.0 Date: Fri, 7 Mar 1997 11:26:11 -0500 Message-ID: <32042280@mailb.harris.com> From: RLANIER@mailb.harris.com (RLANIER) Subject: Re: [SS:1115] Confused? (I am too!!) To: ss@tapr.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part I thought the whole idea of the TAPR/SS list/whoever SS modem/radio/whatever was to develop a spread spectrum device that would be a launching platform for development in other areas, similar to the DSP-93 device. We also seem to be focusing on the details of one aspect of the device. This is not a good method for top-down design. We have to develop a set of requirements/features and then go from there. However, the requirements/features need to be general, not specific, but flexable enough to allow experimentation by a large group of hams. That is why I keep emphasizing a modular design. If designed correctly, the SS device can be whatever you want it to be, with the correct modules in place. Arguing about ethernet/rs-232 isn't moving us any closer to our goal, which I thought was to develop a working SS device within the given timeframe. We'll never meet that at the rate we are going. Tony KE4ATO ______________________________ Reply Separator _________________________________ Subject: [SS:1115] Confused? (I am) Author: ss@tapr.org at smtp Date: 3/7/97 7:54 AM I've obviously not been paying enough attention (nothing new there) because I am confused over this Ethernet thing. Is the idea just to use Ethernet as a direct data source/sink to/from the keyer and correlator, or just to use it as a data pipe to a controller? If it is a direct source then there are obvious problems with varying data rate etc. If it is as a data pipe, then isn't this a bit premature? The usual way of developing this sort of stuff (or at least the way I developed stuff like GPS/Glonass receivers) is using a PC/AT breadboard for digital control (an 8255 or whatever) and DMA data pump, moving over to a local processor control (and arguments about data feed) when you get the basic system working. Mike P.S. How about a SCSI feed? From darnell@binmedia.com Fri Mar 07 10:49:36 1997 Received: from gumby.binmedia.com ([204.140.236.100]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id KAA29222 for ; Fri, 7 Mar 1997 10:49:34 -0600 (CST) Received: from [206.117.173.2] by gumby.binmedia.com (post.office MTA v1.9.3 ID# 0-12756) with SMTP id AAA45 for ; Fri, 7 Mar 1997 08:42:56 -0800 Subject: Re: [SS:1114] Ethernet Interface Date: Fri, 7 Mar 97 08:49:36 -0800 x-mailer: Claris Emailer 1.1 From: darnell@binmedia.com (Darnell Gadberry) To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <19970307164256022.AAA45@[206.117.173.2]> On 3/7/97 Lee W. Fry Wrote: >There seems to be plenty of interest in having a box that looks like an IP >router, connected by twisted pair ethernet. > >Such a box could certainly be based on an ISA architecture computer with a >plug-in ethernet card and radio interfaced by any number of means including >ISA or PCMCIA plug-in, parallel port or serial. As amatter of fact many of >the commercial WLAN access points are just that, a computer with ethernet >and radio cards. > >However, I don't think Phil wants to carry a computer around to hook to his >laptop and I don't want to mount one on my tower (if I even had one). So >what we want to look at is something like the ISDN routers that are >available now. A desktop modem sized box with an IP router front end and in >our case, an RF modem on the back end. > >I hope that when Phil started talking about using ethernet he was >visualizing a router, and not just writing our own drivers to send data >packets over the ethernet wire. If one objective is to operate in a Windows >environment on the host, It would seem like to me that any approach that >required something like a shim below the Winsock level would cause the radio >to not be able to coexist in a Windows box with standard networking to other >ethernet hosts. > >Does anybody around have any knowledge of the technology used to implement >the IP router function in devices such as the Ascend ISDN router? Is there >a chip set? > I am sending this message from a PowerMacintosh 7600 connected to my home LAN which is connected to the MCI T1 Internet connection in my office via a Pipeline 75 ISDN router. The Ascend Pipeline family of ISDN routers (P25, P50,P75, P130) are based on Motorola MC68302 or MC68EN360 microprocessors. Both devices are basically 68020 CPU cores with an enhanced RISC multichannel communications co-processor. As a matter of fact, most current IP routers that cost less than $5,000 are based on the MC68EN360. (Except products from Cisco.) Several years ago, the U.S. Army contracted a company called OAR systems to produce a Real Time operating system with TCP/IP support. The result of that contract was a product called RTEMS. RTEMS supports a wide variety of processors and comes with a complete GNU C development environment. The Army makes RTEMS available to the public FREE OF CHARGE as part of a DOD sponsored technology eschange problem. I believe that RTEMS would serve quite nicely as the software core for a simple IP router. RTEMS supports development in C as well as ADA. You can find more detials on RTEMS at: http://lancelot.gcs.redstone.army.mil/rtems.html The RTEMS C language documentation can be downloaded from: ftp://lancelot.gcs.redstone.army.mil/pub/rtems/releases/current/c/rtems-c_d oc.tgz I like to would propose the development of a standard TAPR CPU platform with RTEMS support and RIP routing added to the RTEMS kernel. The hardware could be based upon either the MC68EN302 or MC68EN360 CPU. I would be willing to work on porting the kernel or helping develop a prototype hardware implementation. Thoughts? - darnell gadberry ke6ucl Phonica / binaryMedia Communications DSP Applications, Data Communications and Embedded control stuff darnell@binmedia.com From RLANIER@mailb.harris.com Fri Mar 07 13:16:06 1997 Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.104.14]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA08008 for ; Fri, 7 Mar 1997 13:16:04 -0600 (CST) Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special version 2.0) id OAA07965; Fri, 7 Mar 1997 14:15:57 -0500 Received: from ccMail by mailb.harris.com (IMA Internet Exchange 1.04b) id 32069370; Fri, 7 Mar 97 14:15:03 -0500 Mime-Version: 1.0 Date: Fri, 7 Mar 1997 14:04:06 -0500 Message-ID: <32069370@mailb.harris.com> From: RLANIER@mailb.harris.com (RLANIER) Subject: Confused? (So am I !!) To: ss@tapr.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part I thought the whole idea of the TAPR/SS list/whoever SS modem/radio/whatever was to develop a spread spectrum device that would be a launching platform for development in other areas, similar to the DSP-93 device. We also seem to be focusing on the details of one aspect of the device. This is not a good method for top-down design. We have to develop a set of requirements/features and then go from there. However, the requirements/features need to be general, not specific, but flexable enough to allow experimentation by a large group of hams. That is why I keep emphasizing a modular design. If designed correctly, the SS device can be whatever you want it to be, with the correct modules in place. Arguing about ethernet/rs-232 isn't moving us any closer to our goal, which I thought was to develop a working SS device within the given timeframe. We'll never meet that at the rate we are going. Tony KE4ATO From rero@cbmsmail.cb.lucent.com Fri Mar 07 15:09:55 1997 Received: from algw2.lucent.com (algw2.lucent.com [205.147.213.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id PAA13986 for ; Fri, 7 Mar 1997 15:09:52 -0600 (CST) Received: from cbemg.cb.lucent.com by alig2.firewall.lucent.com (SMI-8.6/EMS-L sol2) id QAA09707; Fri, 7 Mar 1997 16:05:42 -0500 Received: from cbemg.UUCP by cbemg.cb.lucent.com (4.1/EMS-L gis) id AA16838; Fri, 7 Mar 97 16:06:47 EST Date: 7 Mar 97 16:02:00 -0500 To: "ss" Received: from cbmsmail.cb.lucent.com by cbmsmail.cb.lucent.com; Fri, 7 Mar 1997 16:03 EST Received: by cbmsmail.cb.lucent.com with Microsoft Mail id <332082B7@cbmsmail.cb.lucent.com>; Fri Mar 07 16:03 EST 1997 From: "Rochford, Richard E." Original-To: "ss" Subject: RE: 1113] Re: WT Docket No. 97-12 - Hollow Victory? Original-Date: Fri Mar 07 16:02 EST 1997 Message-Id: <332082B7@cbmsmail.cb.lucent.com> Encoding: 95 TEXT X-Mailer: Microsoft Mail V3.0 Content-Type: text Power control on any SS system is critical. This especially true for systems using multiple sequences on the same carrier. I feel power control for SS systems is implied. The technology exists today to make power control possible for other modes but it is very difficult to go back and make this a requirement. The killer is the ID requirement. The process of identifying would generate more interference than the SS signals them selves. There has to be a way around this. Perhaps just logging the SS information would be enough. RE Rochford WB7RPH ---------- At 07:04 PM 3/6/97 -0600, Lyle Johnson wrote: > >>I think automatic power control is both a good idea and technically >>doable. I DO however have a problem with it being mandated by law >>when SS is the ONLY service in amateur radio in which it is being >>mandated. BTW, the Zilog hopper chip also supports power control. > >My old copy of the FCC Ruklebook , part 97.313(a) reads "An amateur station >must use th eminimum transmitter power necessary to carry out the desired >communications." > >So, we're all obligated under law to do this. SS just requires it to be >automatic. Since these are processor-controlled systems anyway, this is no >big deal to do. We can spend a lot of energy arguing, or we can spend some >energy implementing. Who is arguing? We already agree power control is a good idea. You miss my point completely however. Why do you support a specific rule for automatic power control for SS systems and not for narrowband systems? This sets a precedent of holding SS users to a higher standard then narrowband users. By your own admission, automatic power control on SS (or any mode for that matter) is easy.... why do we need government regulations to tell us to do something that simply makes sense? Do the clover users on HF (which you earlier mentioned) need government regulations to implement power control? My point is (and I think most in the SS-STA would agree) is that spread spectrum is a legitimate amateur RF emission. I've (almost) exclusively operated spread spectrum for the last 2 years. In fact, this is how this message is getting to you now. I'd not have ANY objection to some form of automatic power control for amateur radio emissions... I do have a problem of SS being singled out as the only emission that this is required for. I think this sets a precedent we don't want to agree to. If there is some sort of long term plan here to introduce automatic power control to amateur radio, let me know as I'm not aware of it. Remember, narrowband emissions can easily wipe out DSSS signals. Power control for narrowband emitters would help SS out also. > >If you are against it, why not just write in your reply comments that >97.313 already mandates this so the requirement is redundant and it >shouldn't be in the new SS regs. As I said, it should either be in the AMATEUR regs for all emissions or not at all. I see absolutely no reason why Spread Spectrum should be singled out in this regard. I'd like to get some feedback from this group first, but yes, I do plan on commenting. Thanks -Jeff wb8wka --------- "Power control for _ALL_ amateur emissions --Good Good" "Narrow Band ID--Bad Bad" Power control on any SS system is critical. This especially true for systems using multiple sequences on the same carrier. I feel power control for SS systems is implied. The technology exists today to make power control possible for other modes but it is very difficult to go back and make this a requirement. The killer is the ID requirement. The process of identifying would generate more interference than the SS signals them selves. There has to be a way around this. Perhaps just logging the SS information would be enough. RE Rochford WB7RPH From jbloom@arrl.org Fri Mar 07 16:01:45 1997 Received: from mgate.arrl.org (root@mgate.arrl.org [205.217.201.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id QAA16116 for ; Fri, 7 Mar 1997 16:01:43 -0600 (CST) Received: from smtp_gw by mgate.arrl.org with smtp (Smail3.1.29.1 #9) id m0w37hu-0004rHC; Fri, 7 Mar 97 17:01 EST Message-Id: Priority: urgent Date: Fri, 7 Mar 1997 17:00:00 -0500 From: "Bloom, Jon, KE3Z" Subject: RE: 1097] Re: WT Docket No. 97-12 - Holl To: "'ss@tapr.org'" X-Mailer: Worldtalk (NetConnex V4.00a)/MIME > From: Jeff King[SMTP:jeff@mich.com] > At 08:49 AM 3/6/97 -0600, Lyle Johnson wrote: > >Lee, > > > >>The killers are automatic transmitter power control... > >>...As far as I know, none of the chipset solutions currently available for SS > >>applications in 900MHz or 2.4 GHz can support these requirements. > > > >The Harris PRISM chipset has an ADC that measures incoming signals and this > > I think automatic power control is both a good idea and technically > doable. I DO however have a problem with it being mandated by law > when SS is the ONLY service in amateur radio in which it is being > mandated. BTW, the Zilog hopper chip also supports power control. > > So the ARRL is saying that amateurs that run SS are to stupid to use > the the minimum power required to make communications? (as required > by law). No, I think what is being said is that adding automatic power control to still-to-be-designed SS systems is technically feasible, wouldn't be particularly burdensome, and is a Good Thing. Also, a vastly overpowered SS system has greater potential for causing harmful interference to existing users than a vastly overpowered narrowband system; thus it's more important to maintain power control. If you feel that adding automatic power control to SS designs would be an excessive burden, is technically infeasible or is a Bad Thing, by all means, make your point in written comments to the FCC. That's what the comment period is for. > So all those DX'ers that are running kilowatts don't need > automatic power control? Or the local 2metre repeater that is running > 400 watts shouldn't use automatic power control? > > Automatic power control is technically possible for almost every > modulation mode. I have a serious problem with SS being singled > out by the ARRL, in particular with legal regulations. Technically possible, perhaps, but quite burdensome for old-fashioned narrowband voice systems. And requiring automatic power control for such systems would mean retrofitting a *lot* of existing equipment. Maybe if amateurs were starting with a blank sheet of paper for those modes, like they are for SS, automatic power control *would* be a requirement. Who knows? > >Anyway, one can look at BER or retries or ??? and then set the power level > >by the processor that must be embedded in this widget anyhow. Automatic > >power control isn't a big deal IMHO -- heck, even the HF guys use it > >(clover and the like) :-) > > Yeap, they use automatic power control because it makes sense. And gosh, > they don't even need the government telling them to do it! I guess those > spread spectrum folks are just to stupid to realize the advantages of > power control. Gotta get the goverment involved to keep the threat of > SS to amateur radio under control. There is nothing in these proposed rules that implies anything about the intelligence, morals or habits of SS proponents or anyone else. Trying to cast the NPRM in that light is just muddying the waters. If you have solid technical or operational arguments against (or for) aspects of the NPRM, please do comment to the FCC. Jon -- Jon Bloom, KE3Z jbloom@arrl.org From dkelly@hiwaay.net Fri Mar 07 19:18:09 1997 Received: from nexgen.hiwaay.net (max1-91.HiWAAY.net [208.147.145.91]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA27262 for ; Fri, 7 Mar 1997 19:18:06 -0600 (CST) Received: from nexgen (localhost [127.0.0.1]) by nexgen.hiwaay.net (8.8.5/8.8.4) with ESMTP id VAA11693 for ; Thu, 6 Mar 1997 21:20:06 -0600 (CST) Message-Id: <199703070320.VAA11693@nexgen.hiwaay.net> X-Mailer: exmh version 1.6.9 8/22/96 To: ss@tapr.org From: dkelly@hiwaay.net Subject: Re: [SS:1090] RE: 1085] RE: 1080] Re: SS Design Interfaces In-reply-to: Message from "Rochford, Richard E." of "Thu, 06 Mar 1997 10:00:04 CST." <331EE610@cbmsmail.cb.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Mar 1997 21:20:06 -0600 Sender: dkelly@nexgen.hiwaay.net Rochford, Richard E. writes: > > If you are looking for faster data rates, (digital including speech, > text, video etc.), ethernet is a way to go. However, this implies there > is some other interface, RS232 etc. i.e. a console port, which is needed > to administer the ethernet interface. > > I currently work on a product with an ethernet interface and no console > port, requiring us to use a default IP address and come up with an > elaborate method of burning the MAC address. > > Obtaining and assigning MAC addresses is an other administrative chore > which has to be centralized somewhere for a project like this. I've thought about this a lot in the past and concluded about the cheapest easiest quickest way to do ethernet on a design like this is to adopt something like an NE2000 ISA ethernet card as your "ethernet chip". At about $20 each in onesies you solve lots of problems. Such as registering a block of ethernet addresses. And the regulatory issues for non-amateur gear. But the problem is once one decides to put an ISA card in there somewhere, somebody pops up and insists, "lets do it all on a PC and use *NOS". -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From jeff@mich.com Fri Mar 07 21:32:55 1997 Received: from server1.mich.com (root@server1.mich.com [198.108.16.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id VAA06089 for ; Fri, 7 Mar 1997 21:32:53 -0600 (CST) Received: from gw-aerodata.mich.com (gw-aerodata.mich.com [198.108.16.60]) by server1.mich.com (8.8.4/8.8.4) with SMTP id WAA13692 for ; Fri, 7 Mar 1997 22:34:15 -0500 Message-Id: <2.2.32.19970308033222.0071663c@mail.mich.com> X-Sender: jeff@mail.mich.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 07 Mar 1997 22:32:22 -0500 To: ss@tapr.org From: Jeff King Subject: Power control with Part 15 gear Given some thought to the requirement for power control within the new SS NPRM. Specifically, the Part 15 SS equipment I now can operate under the TAPR SS-STA at higher power levels but won't be able to if the NPRM goes through. I'm sure most in this group are in the same boat as the majority of Part 15 equipment doesn't implement power control. The FreeWave is the most well suited for power control as it can both measure signal strength, noise level have 10 levels of transmit power. The two problems are that you only can control the FreeWave "inband" via the existing RS-232 line (after hitting reset!) and the second (biggest) problem is they don't appear to want to work with the amateur community. The other unit I've done some work with is the NCR/ATT/Lucent WaveLan board. With the Linux Driver you can pull some interesting stats while the board is working covering signal strength, noise and I believe S/N. However, to the best of my knowledge, you can't do power control with it. OK if you want to run less then 1 watt but what if you wanted to run up to 10 watts or so with a antenna amplifier. This has the added benefit of allowing you to get away with higher loss cables like LMR-400. Had a idea and wanted to run it by the group. What if you developed a remote power amp that you could control the gain? Many 900mhz bricks have a external pin to set gain level. A simple micro controller with a DAC converter could drive this pin and the LINUX box could talk to the microcontroller over a serial link. Not the most elegant solution but would allow you to use existing WaveLan boards with amps under the NPRM. The MicroController code would be trivial (One of the things I do for a living). -Jeff wb8wka From jeff@mich.com Fri Mar 07 23:12:55 1997 Received: from server1.mich.com (root@server1.mich.com [198.108.16.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id XAA11435; Fri, 7 Mar 1997 23:12:52 -0600 (CST) Received: from gw-aerodata.mich.com (gw-aerodata.mich.com [198.108.16.60]) by server1.mich.com (8.8.4/8.8.4) with SMTP id AAA23975; Sat, 8 Mar 1997 00:14:15 -0500 Message-Id: <2.2.32.19970308051220.008c0db4@mail.mich.com> X-Sender: jeff@mail.mich.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 08 Mar 1997 00:12:20 -0500 To: ss@tapr.org, ss-sta@tapr.org From: Jeff King Subject: Re: [SS:1121] RE: 1097] Re: WT Docket No. 97-12 - Holl At 04:01 PM 3/7/97 -0600, Bloom, Jon, KE3Z wrote: > > >No, I think what is being said is that adding automatic power control to >still-to-be-designed SS systems is technically feasible, wouldn't be >particularly burdensome, and is a Good Thing. OK. That's fair enough. What about the already existing Part 15 equipment that exists and that some of us are currently using under the TAPR-STA? Will we be grandfathered? >Also, a vastly overpowered >SS system has greater potential for causing harmful interference to >existing users than a vastly overpowered narrowband system; thus it's >more important to maintain power control. So far we don't disagree. A vastly overpowered narrowband system can cause quite a bit of interference to a DSSS system, especially with many of the low process gain chipsets that are on the market. BTW, speaking of overpowered, the rules set the limit at 100watts which is only 20db over the non-automatic power control limit of 1 watt. And I'd hazard to guess not very many will run much over 10watts on 900mhz and above as it becomes quite costly. So we really are only talking 10db of protection. Seems to me power control should apply all the way down to microwatts if its really going to be effective. Earlier I Said: >> From: Jeff King >> I think automatic power control is both a good idea and technically >> doable. I DO however have a problem with it being mandated by law >> when SS is the ONLY service in amateur radio in which it is being >> mandated. BTW, the Zilog hopper chip also supports power control. >> Then you said: > >If you feel that adding automatic power control to SS designs would be an >excessive burden, is technically infeasible or is a Bad Thing, by all >means, make your point in written comments to the FCC. That's what the >comment period is for. Read what I already said. I don't think its a excessive burden at all to add power control to ANY equipment. I just think its very hypocritical to only require it on amateur SS equipment. Either RF power control is a good idea for all of amateur radio, or its not. There is no technical middle ground here. > >> So all those DX'ers that are running kilowatts don't need >> automatic power control? Or the local 2metre repeater that is running >> 400 watts shouldn't use automatic power control? >> >> Automatic power control is technically possible for almost every >> modulation mode. I have a serious problem with SS being singled >> out by the ARRL, in particular with legal regulations. > >Technically possible, perhaps, but quite burdensome for old-fashioned >narrowband voice systems. And requiring automatic power control for such >systems would mean retrofitting a *lot* of existing equipment. Maybe if >amateurs were starting with a blank sheet of paper for those modes, like >they are for SS, automatic power control *would* be a requirement. Who >knows? Hmmmm... "quite burdensome for old-fashioned narrowband voice systems"? So what?! This is SUPPOSED to be a technical service. Power control either makes sense or it doesn't. The mode shouldn't matter at all. Technically, I don't care if its a burden or not. With this kind of logic we'd still be allowing spark on the bands. Let me steal some of your words and make a proposal...... >"No, I think what is being said is that adding automatic power >control to still-to-be-designed SS systems" (^delete SS systems, insert: ^NARROWBAND systems ) >"is technically feasible, wouldn't be particularly burdensome, >and is a Good Thing." Note I replaced Spread Spectrum with NARROWBAND. Since you wish to mandate automatic power control for new spread spectrum designs, how about we mandate power control for NEW narrowband radios? That will shut me up. We can grandfather the existing narrowband users. >There is nothing in these proposed rules that implies anything about the >intelligence, morals or habits of SS proponents or anyone else. Trying to >cast the NPRM in that light is just muddying the waters. If you have >solid technical or operational arguments against (or for) aspects of the >NPRM, please do comment to the FCC. > >Jon > -- >Jon Bloom, KE3Z >jbloom@arrl.org Jon, I'm sure I'm coming off like a Bull in a China Shop, but I think the NPRM is hypocritical to require power control for SS users while not at least suggesting power control for other users of the band (be they narrowband amateur or Part 15 SS). I by and large support the NPRM with one exception, I think for fixed point to point links, were the signal strength is constant 99%+ of the time, the provisions of automatic power control should be waved AS LONG AS the power is MANUALLY set to conform with the NPRM formula. This would allow existing Part 15 designs to be leveraged into Part 97 operation at higher (if need be) power levels. However, for ad hoc SS networks, I fully support and embrace automatic power control. Please don't have the illusion that "if we build it, they will come". How many 219-220mhz radios exist?? We HAVE TO BE ABLE to leverage existing Part 15 radios into our service to make this work. The movers and shakers at first are going to use these hopped up Part 15 radios to do point to point links. We want them to run these radios under Part 97 rules, not Part 15 rules. There has to be some latitude in the rules for point to point links.... possibly a solution for compliance would be to either require automatic power control OR require the link be coordinated. In case you don't know it, the majority of Part 15 radios don't allow automatic power control. One question, I do have some comments regarding aspects of the NPRM I'd like to make to the FCC. However, do I risk upsetting the chance of the NPRM going through if I do? I can be (believe it or not!) somewhat pragmatic and I think what is offered, is quite good. I'd like to see power control phased into all of amateur radio as well as Part 15 devices we share the bands with. I don't want to upset the apple cart by suggesting this in comments on the NPRM. Regards, -Jeff King wb8wka Via a 902-928mhz frequency hopping 173KBPS spread spectrum link ------------- Regards, ------------------------------------ | Jeff King Aero Data Systems | | jeff@mich.com P.O. Box 510895 | | (810)471-1787 Livonia, MI 48151 | |F(810)471-0279 United States | ------------------------------------ From lfry@mindspring.com Sat Mar 08 06:10:23 1997 Received: from mule0.mindspring.com (mule0.mindspring.com [204.180.128.166]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id GAA03978 for ; Sat, 8 Mar 1997 06:10:21 -0600 (CST) Received: from glory (user-168-121-136-107.dialup.mindspring.com [168.121.136.107]) by mule0.mindspring.com (8.8.4/8.8.4) with SMTP id HAA72102 for ; Sat, 8 Mar 1997 07:10:15 -0500 Message-Id: <2.2.32.19970308121317.0036c180@mindspring.com> X-Sender: lfry@mindspring.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 08 Mar 1997 07:13:17 -0500 To: ss@tapr.org From: "Lee W. Fry" Subject: Re: [SS:1118] Re: Ethernet Interface At 10:51 AM 3/7/97 -0600, darnell gadberry ke6ucl wrote in [SS:1118]: > >I like to would propose the development of a standard TAPR CPU platform >with RTEMS support and RIP routing added to the RTEMS kernel. The >hardware could be based upon either the MC68EN302 or MC68EN360 CPU. I >would be willing to work on porting the kernel or helping develop a >prototype hardware implementation. > > >Thoughts? > Thanks. So far, the only suggestion on an embedded controller. I can't believe that with all the talk of TCP/IP/HTTP everywhere, including your TV, microwave oven and maybe even your HF rig that such a product won't drop out of the commercial sky. I poked around in comp.realtime via Deja News and found a fair amount of discussion about TCP/IP stacks for embedded controllers. It looks like there were people working on a RTEMS stack last fall. Also there was an interesting suggestion on using the AMD Lance ethernet controller behind a non-EN 68C. Is there a version of 68C with an imbedded PCI bus? How about the suggestion from David Kelly N4HHE, dkelly@hiwaay.net in [SS:1122]to use a off the shelf ethernet card? The newer PCI ethernet cards are small enough to use as a daughter card, especially with the bracket stripped off. Anyway, it sounds like an embedded ethernet controller is a project in itself. Also, there might be interest from other communities. Just another random thought: The controller could also implement in-band control for managing transmit power and station ID. Then we would need SNMP also. Lee W. Fry AA0JP lfry@mindspring.com See my Part 15 Spread Spectrum Device Compendium at: http://www.mindspring.com/~lfry/part15.htm From w9ddd@tapr.org Sat Mar 08 07:43:38 1997 Received: (from w9ddd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id HAA08603; Sat, 8 Mar 1997 07:43:38 -0600 (CST) Date: Sat, 8 Mar 1997 07:43:37 -0600 (CST) From: John Koster To: ss@tapr.org Subject: Re: [SS:1125] Re: Ethernet Interface In-Reply-To: <2.2.32.19970308121317.0036c180@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 8 Mar 1997, Lee W. Fry wrote: > At 10:51 AM 3/7/97 -0600, darnell gadberry ke6ucl wrote in [SS:1118]: > > > >I like to would propose the development of a standard TAPR CPU platform > >with RTEMS support and RIP routing added to the RTEMS kernel. The stuff deleted > > Is there a version of 68C with an imbedded PCI bus? How about the suggestion > from David Kelly N4HHE, dkelly@hiwaay.net in [SS:1122]to use a off the shelf > ethernet card? The newer PCI ethernet cards are small enough to use as a > daughter card, especially with the bracket stripped off. > As a matter of fact I saw an advert. the other day for an evaulation board for the Coldfire from Motorla that did exactly that. (Well almost, it looked like an ISA ethernet card, not PCI) I don't have the details yet, but it appeared there was also a asynch. serial port as well. > > the rest deleted John, W9DDD@tapr.org From cape.net@surfergirl.spacey.net Sat Mar 08 11:50:15 1997 Received: from surfergirl.spacey.net (SPACEY.NET [205.152.52.3]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA20454 for ; Sat, 8 Mar 1997 11:50:13 -0600 (CST) From: cape.net@surfergirl.spacey.net Received: from MAX20.SPACEY.NET (MAX20.SPACEY.NET [205.152.52.169]) by surfergirl.spacey.net (8.7.3 Version 1.1 Build 565/8.7.3) with SMTP id MAA00016 for ; Sat, 08 Mar 1997 12:50:43 -0500 (Eastern Standard Time) Date: Sat, 08 Mar 1997 12:50:43 -0500 (Eastern Standard Time) Message-Id: <199703081750.MAA00016@surfergirl.spacey.net> X-Sender: tony@spacey.net (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org Subject: Preliminary Design I have come up with a preliminary design of the SS box. I have tried to make it as generic as possible, without including un-necessary details. My idea is to get an idea of the overall design and how the pieces of the puzzle will fit together. I don't won't to lose sight of the forest for the trees, if you know what I mean. \/ | | +---------+ +---------+ +-----------+ | | | | | | |<---- Voice +-----| RF |<-->| SS |<-->| DATA |<>--- Ethernet | Section | | Section | | Interface |<>--- RS-232/RS-422 | | | | | | +---------+ +---------+ +-----------+ Obviously, there is more to the system than this, but it is a start. I feel that with a system such as this, all persons interested in the design can be happy. The only 'grey' area is the interfacing between the SS and DATA Interface sections. How is the data transfer going to handled? I feel that the SS section should have a constant data rate. Only the data rates to and from the DATA Interface section should be varied. The RF section could have all circuitry for translating the data into the RF spectrum and would also contain the interfacing to the antennae. It would also have the IF circuitry, automatic power control interfacing (to the SS section), AGC, and other stuff I can't think of right now. The SS section would do spreading/de-spreading, modulation/demodulation, FEC, PN generation, DS-FH-hybrid control (to RF section?). The DATA Interface would contain rate buffers (FIFOs) for data transfer (for slow mode interfaces such as rs-232), ADCs for voice, interfacing for a front panel (if desired). There is a great deal of planning that would need to go into a project of this magnitude. The above is a starting point. The only thing left to do is decide on how the major blocks are going to connect to each other. Tony KE4ATO From darnell@binmedia.com Sat Mar 08 12:04:25 1997 Received: from gumby.binmedia.com ([204.140.236.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id MAA21097 for ; Sat, 8 Mar 1997 12:04:24 -0600 (CST) Received: from [206.117.173.2] by gumby.binmedia.com (post.office MTA v1.9.3 ID# 0-12756) with SMTP id AAA66 for ; Sat, 8 Mar 1997 09:57:46 -0800 Subject: Re: [SS:1125] Re: Ethernet Interface Date: Sat, 8 Mar 97 10:04:25 -0800 x-mailer: Claris Emailer 1.1 From: darnell@binmedia.com (Darnell Gadberry) To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <19970308175746606.AAA66@[206.117.173.2]> On 3/8/97 at 4:14 AM Lee w. Fry wrote: > >At 10:51 AM 3/7/97 -0600, darnell gadberry ke6ucl wrote in [SS:1118]: >> >>I like to would propose the development of a standard TAPR CPU platform >>with RTEMS support and RIP routing added to the RTEMS kernel. The >>hardware could be based upon either the MC68EN302 or MC68EN360 CPU. I >>would be willing to work on porting the kernel or helping develop a >>prototype hardware implementation. >> > >Thanks. So far, the only suggestion on an embedded controller. I can't >believe that with all the talk of TCP/IP/HTTP everywhere, including your TV, >microwave oven and maybe even your HF rig that such a product won't drop out >of the commercial sky. We have used VxWorks, QNX and pSOS in our commercial embedded designs. Each of these Real-Time operating systems has a COMPLETE TCP/IP implementation. Adding AX.25 and RIP routing would be a VERY simple task. Additionally, each of three of the OSs that I just mentioned offer an embedded HTTP server as part of their runtime package. Unfortunately, we paid $14,000 for our VxWorks development system and approximately $28 per unit for the runtime license. So that solution might not be the most cost effective. I strongly urge all of the software savvy folks on this thread to take a close look at RTEMS. I believe that I would work very nicely as the core OS for virtually any communications related box that we might want to implement. >I poked around in comp.realtime via Deja News and found a fair amount of >discussion about TCP/IP stacks for embedded controllers. It looks like >there were people working on a RTEMS stack last fall. There is a guy in my office who has a copy of the RTEMS TCP/IP stack. I will try and get my hands on the code, take a look at the implementation and report back on what I find. I will be putting an RTEMS page up on my site some time next week. >Also there was an interesting suggestion on using the AMD Lance ethernet controller behind a >non-EN 68C. The Lance is a really messy, low-performance, first-generation Ethernet controller. Certainly not something that I would use for a current design. >Is there a version of 68C with an imbedded PCI bus? No. >How about the suggestion from David Kelly N4HHE, dkelly@hiwaay.net in [SS:1122]to use a off >the shelf ethernet card? Why. Most current generation ethernet controller chips will talk to an Intel 80XXX or Motorola MC68XXX CPU with little or no glue logic. >The newer PCI ethernet cards are small enough to use as a >daughter card, especially with the bracket stripped off. See previous comment. Ethernet chips are now REALLY cheap. The single piece book price of the Fujitsu MB8XXX 10Base-T controller is around $13.50. Obviously, if we go to a distributor and make a low 1000's purchase commitment that price could drop considerably. Add another $8 bucks for the requisite transformer and other 10Base-T interface junk and you are done. Further, ISA is MUCH easier to implement in an embedded design. For the 68K family it typically takes a pair of 16V8 GALs and a couple of bi-directional bus buffers. If you use one of the embedded 80XX86 family parts you get the ISA bus for free. PCI has some VERY stringent timing requirements which make it very costly to implement in on a small scale. And besides, at the actual speeds we are discussing adding a PCI bus would be like killing a bug with a bazooka. > >Anyway, it sounds like an embedded ethernet controller is a project in >itself. Also, there might be interest from other communities. > >Just another random thought: The controller could also implement in-band >control for managing transmit power and station ID. Then we would need SNMP >also. There is a complete public domain SNMP MIB and agent package available for free with the FreeBSD source package from U.C. Berkeley. --------- Context switch. This has been a fairly interesting discussion. However, I think that we have become mired in the minute details of the implementation. What we should do is to create a 5,000 foot level specification of what the box should do and then worry about the implementation details once we have figured out what we really want to accomplish. Just a thought... - darnell gadberry ke6ucl Phonica / binaryMedia darnell@binmedia.com From stannard@alaska.net Sat Mar 08 15:40:41 1997 Received: from calvino.alaska.net (root@calvino.alaska.net [206.149.65.3]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id PAA00567 for ; Sat, 8 Mar 1997 15:40:29 -0600 (CST) Received: from mailhost.alaska.net (hom-p1-31.alaska.net [206.149.72.31]) by calvino.alaska.net (8.8.0/8.7.3) with SMTP id MAA23505 for ; Sat, 8 Mar 1997 12:40:07 -0900 (AKST) Message-Id: <199703082140.MAA23505@calvino.alaska.net> From: stannard@alaska.net (John Stannard - KL7JL) Date: Sat, 08 Mar 97 12:28:03 -0900 To: ss@tapr.org Subject: Re: [SS:1086] RE: 1081] Re: SS Design In-Reply-To: , on 03/06/97 at 08:27 08, efbrya - Eric Bryan said: >>>I say we should forget about building a radio that can be used to prove that >>>SS can share 6M, 2M, 220, and 440 spectrum with existing users, or make more >>>efficient use of existing spectrum. We addressed that in our STA, but no > I am interested in these lower freq. just to get greater range with out >having >to find places to stick repeaters all over the countryside. I want to do >200 mile hops at a minimum. Hear, hear! Even some of us "appliance operators" have an interest in USING Spread Spectrum, and except for the "major" cities in Alaska, the microwave bands are not going to make it up here in the Bush for networking. My CLOSEST tcp/ip neighbor is 135 miles away in Kodiak--across the water. We currently have a packet link on 6m--soon a voice link as well. I'd love to see something high-speed between Homer and Kodiak, but in previous tests, 2m and 440 can't make the trip. Topology has a great influence on what we do here in Alaska...try to not leave us out when considering options. Lower frequencies are also easier to find parts for (at >least it seems >that way to me). >Eric Bryan >efbrya@acxiom.com >> >> 73, John -- --------------------------------------------------------------------- stannard@alaska.net (John Stannard - KL7JL) Reg. MR/2ICE User #524 I've been telling them for years: "SCSI is *not* SCUZZY, it's SEXY!" Disclamer: Appliance Operator; using packet since 1986, using tcp/ip since 1987...not EVEN a programmer. :-( --------------------------------------------------------------------- From wb9mjn@wb9mjn.ampr.org Sat Mar 08 18:46:50 1997 Received: from wb9mjn.ampr.org (wb9mjn.ampr.org [44.72.98.19]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id SAA09040 for ; Sat, 8 Mar 1997 18:46:31 -0600 (CST) From: wb9mjn@wb9mjn.ampr.org Date: Sat, 08 Mar 97 18:13:33 UTC Message-Id: <13094@wb9mjn.ampr.org> To: ss@tapr.org Subject: Re: [SS:1129] RE: 1081] Re: SS Design In-Reply-To: your message of Sat Mar 08 15:42:58 1997 <199703082140.MAA23505@calvino.alaska.net> Hi John, The longest distance working packet link that we have had on the air here in the Chicagoland area was on 1.2 ghz. It was 76 miles. It was dead solid. One antenna was at 1200 feet agl, the other was at aroung 500 agl. Where Ground level (gl) was actually the middle of Lake Michigan. Clearly, with a mountain/valley altitude variation , typically allot more than 1200 feet, ur going to be able to go allot farther. So don t count out microwaves, simply because of range. Due to the physics of the problem microwaves may just be what ur looking for! Below 1 Ghz, its tuff to get a first fresnel clearance. A grazing path incures about 20 dB extra path loss than a free space path. A First Fresnel clearance path has 6 dB gain (that s right, 6 dB LESS loss) than free space. The high the frequency, the less the required clearance of the center of the path, to have a first fresnel path. Indeed, on 220, the first fresnel clearance between 2 450 foot high antennas, over smooth earth, is only about 14 miles. That is, the distance for first fresnel clearance. On 10 Ghz, a 30 mile path only needs a small fraction of that clearance (on the order of 30 feet). Its this magic , which lets u run flea power on microwaves, and cover tremendous distances. Combine this with antenna gain, and u can run megabaud at tremendous distances! 73, Don. Mailbox : WB9MJN @ N9HSI.IL.USA.NA AMPRNet : wb9mjn@wb9mjn.ampr.org[44.72.98.19] Internet: wb9mjn%wb9mjn.ampr.org@uugate.aim.utah.edu From zeus@myth.demon.co.uk Sat Mar 08 20:04:04 1997 Received: from myth.demon.co.uk (myth.demon.co.uk [158.152.20.217]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id UAA12624 for ; Sat, 8 Mar 1997 20:03:51 -0600 (CST) Date: Sun, 09 Mar 1997 01:34:09 GMT From: zeus@myth.demon.co.uk (Mike Cowgill) Reply-To: zeus@myth.demon.co.uk Message-Id: <2166@myth.demon.co.uk> To: ss@tapr.org Subject: Modular SS X-no-archive: yes X-Mailer: PCElm 1.10 beta 3 Lines: 18 After seeing various OS's mentioned, how come nobody has seized on to Linux and is running with it? It is free, has full network support (TCP/IP at kernel level) and has an embedded version which is actively being maintained. It also runs off both 80x86 and 680x0 should you desire it. It would also mean that you can develop the control software and hardware on your usual PC, leaving the niceties of communications until the difficult stuff is done. When all is finished (are they ever?) you build a small diskless PC (plenty of cheap support chipsets), re-compile it and burn it on to EEPROM. Should you desire it it would be trivial to move the interface to 100Mb/s, Ultra and Fast SCSI or whatever, the drivers are already there written, as is audio and video compression, all the usual Internet higher level support (a modem with native X-windows interface...) If you wanted to integrate Codecs for analogue use then fair enough, but I would prefer to concentrate on a pure digital design in the first instance. Mike. From jerryn@ici.net Sat Mar 08 21:04:01 1997 Received: from uhura.ici.net (uhura.ici.net [204.97.252.6]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id VAA15868 for ; Sat, 8 Mar 1997 21:03:56 -0600 (CST) Received: from nomad (d-ma-fallriver-51.ici.net [207.180.10.60]) by uhura.ici.net (8.8.4/8.8.4) with SMTP id WAA13707 for ; Sat, 8 Mar 1997 22:00:24 -0500 (EST) Sender: root@uhura.ici.net Message-ID: <33222864.685B20A4@ici.net> Date: Sat, 08 Mar 1997 22:03:00 -0500 From: Jerry Normandin X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.26 i686) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1130] RE: 1081] Re: SS Design References: <13094@wb9mjn.ampr.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jerry Normandin Replies: At last, someone with a post that knows what they are talking about! wb9mjn@wb9mjn.ampr.org wrote: > > Hi John, > > The longest distance working packet link that we have had on the air > here in the Chicagoland area was on 1.2 ghz. It was 76 miles. It was dead > solid. > > One antenna was at 1200 feet agl, the other was at aroung 500 agl. Where > Ground level (gl) was actually the middle of Lake Michigan. > > Clearly, with a mountain/valley altitude variation , typically allot > more than 1200 feet, ur going to be able to go allot farther. > > So don t count out microwaves, simply because of range. Due to the physics > of the problem microwaves may just be what ur looking for! > > Below 1 Ghz, its tuff to get a first fresnel clearance. A grazing path > incures about 20 dB extra path loss than a free space path. A First Fresnel > clearance path has 6 dB gain (that s right, 6 dB LESS loss) than free space. > The high the frequency, the less the required clearance of the center of the > path, to have a first fresnel path. Indeed, on 220, the first fresnel clearance > between 2 450 foot high antennas, over smooth earth, is only about 14 miles. > That is, the distance for first fresnel clearance. On 10 Ghz, a 30 mile path > only needs a small fraction of that clearance (on the order of 30 feet). > > Its this magic , which lets u run flea power on microwaves, and cover > tremendous distances. Combine this with antenna gain, and u can run megabaud > at tremendous distances! > > 73, Don. > > Mailbox : WB9MJN @ N9HSI.IL.USA.NA > AMPRNet : wb9mjn@wb9mjn.ampr.org[44.72.98.19] > Internet: wb9mjn%wb9mjn.ampr.org@uugate.aim.utah.edu From coccpce@mailbox.nauta.it Sun Mar 09 02:50:45 1997 Received: from mail.nauta.it (root@tamata.NAUTA.IT [194.21.179.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id CAA09511 for ; Sun, 9 Mar 1997 02:50:40 -0600 (CST) Received: from coccpce.nauta.it (coccpce.nauta.it [194.21.180.3]) by mail.nauta.it (8.6.12/8.6.9) with SMTP id JAA13172 for ; Sun, 9 Mar 1997 09:50:23 +0100 Message-ID: <3322F823.6EC3@mailbox.nauta.it> Date: Sun, 09 Mar 1997 09:49:23 -0800 From: Stefano Coccon Organization: P.C.E. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1127] Preliminary Design References: <199703081750.MAA00016@surfergirl.spacey.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cape.net@surfergirl.spacey.net wrote: > > I have come up with a preliminary design of the SS box. I have tried to make > it as generic as possible, without including un-necessary details. My idea > is to get an idea of the overall design and how the pieces of the puzzle > will fit together. I don't won't to lose sight of the forest for the trees, > if you know what I mean. Dear Tony, this is the first practical synthesis I have seen; I agree with you. > > \/ > | > | +---------+ +---------+ +-----------+ > | | | | | | |<---- Voice > +-----| RF |<-->| SS |<-->| DATA |<>--- Ethernet > | Section | | Section | | Interface |<>--- RS-232/RS-422 > | | | | | | > +---------+ +---------+ +-----------+ > > Obviously, there is more to the system than this, but it is a start. I feel > that with a system such as this, all persons interested in the design can be > happy. The only 'grey' area is the interfacing between the SS and DATA > Interface sections. How is the data transfer going to handled? I feel that > the SS section should have a constant data rate. Only the data rates to and > from the DATA Interface section should be varied. > > The RF section could have all circuitry for translating the data into the > RF spectrum and would also contain the interfacing to the antennae. It would > also have the IF circuitry, automatic power control interfacing (to the SS > section), AGC, and other stuff I can't think of right now. The SS section > would do spreading/de-spreading, modulation/demodulation, FEC, PN > generation, DS-FH-hybrid control (to RF section?). The DATA Interface would > contain rate buffers (FIFOs) for data transfer (for slow mode interfaces > such as rs-232), ADCs for voice, interfacing for a front panel (if desired). > This is an interesting point. Basically we are dealing with a synchronous (or virtually synchronous) data channel whose rate, including the synchronization data overhead, is some percentage lower than the maximum system's transfer rate. The need of a FIFO, of course is also required to compensate some poor transmission conditions; its size is an interesting parameter. > There is a great deal of planning that would need to go into a project of > this magnitude. The above is a starting point. The only thing left to do is > decide on how the major blocks are going to connect to each other. > > Tony KE4ATO The steps that should be followed in the development of the 'THING' are, according to your blocks, from right to left. I have divided the whole system into three loops: - the final system itself - synchronous data loop (short loop 'A') - scrambled data loop (short loop 'B' \/ | +---------+ +---------+ +-----------+ | | | | | | |<---- Voice +-----| RF |<--->| SS |<--->| DATA |<>--- Ethernet | Section | | | Section | | | Interface |<>--- RS-232/RS-422 | | | | | | | | +---------+ | +---------+ | +-----------+ | | | | | | | Short loop | Short loop | 'B' | 'A' | | | | \/ | | | +---------+ | +---------+ | +-----------+ | | | | | | | | |<---- Voice +-----| RF |<--->| SS |<--->| DATA |<>--- Ethernet | Section | | Section | | Interface |<>--- RS-232/RS-422 | | | | | | +---------+ +---------+ +-----------+ The first practical step is to point out the specifications for the short loop 'A'. After the specifications are stated, it is possible for different groups to develop also compatible blocks and to test their performances and, if they wish, also to exchange the informations at shematics file level. Selection of the SS section is the second step to do; different chip sets can be evaluated. What it is interesting is the possibility to include, between the SS section and the RF section, a bidirectional optical link. Saluti. Stefano-IV3URK From dkelly@hiwaay.net Sun Mar 09 18:05:54 1997 Received: from nexgen.hiwaay.net (max2-156.HiWAAY.net [208.147.145.156]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA20152 for ; Sun, 9 Mar 1997 18:05:51 -0600 (CST) Received: from nexgen (localhost [127.0.0.1]) by nexgen.hiwaay.net (8.8.5/8.8.4) with ESMTP id UAA20020 for ; Sat, 8 Mar 1997 20:28:58 -0600 (CST) Message-Id: <199703090228.UAA20020@nexgen.hiwaay.net> X-Mailer: exmh version 1.6.9 8/22/96 To: ss@tapr.org From: dkelly@hiwaay.net Subject: Re: [SS:1128] Re: Ethernet Interface In-reply-to: Message from darnell@binmedia.com (Darnell Gadberry) of "Sat, 08 Mar 1997 12:13:28 CST." <19970308175746606.AAA66@[206.117.173.2]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Mar 1997 20:28:57 -0600 Sender: dkelly@nexgen.hiwaay.net Darnell Gadberry replied: > > >Also there was an interesting suggestion on using the AMD Lance ethernet > controller behind a >non-EN 68C. > > The Lance is a really messy, low-performance, first-generation Ethernet > controller. Certainly not something that I would use for a current design. The current generation of LANCE? I'd agree the original 7990 would be a bear to use but AMD appears to have done a lot of work on their PCnetISA and PCnetPCI (think thats their new names) versions. Even included SCSI on the same chip. OTOH I priced the cheapest modern LANCE a year or so ago at $55 each/100's. Too pricey. Today, Those Whose Opinions I Hold In High Regard recommend DEC 21x40 based PCI ethernet cards starting at $40. > >Is there a version of 68C with an imbedded PCI bus? > > No. > > >How about the suggestion from David Kelly N4HHE, dkelly@hiwaay.net in > [SS:1122]to use a off >the shelf ethernet card? > > Why. Most current generation ethernet controller chips will talk to an > Intel 80XXX or Motorola MC68XXX CPU with little or no glue logic. An off-the-shelf ethernet card has cleared FCC emissions testing. And hopefully UL-type tests also too. The actual ethernet interface presents a non-trivial RF problem. Most chip manufacturers provide a cookbook PCB layout but that layout is very generous with the space it occupies. > Ethernet chips are now REALLY cheap. The single piece book price of the > Fujitsu MB8XXX 10Base-T controller is around $13.50. Obviously, if we go > to a distributor and make a low 1000's purchase commitment that price > could drop considerably. Add another $8 bucks for the requisite > transformer and other 10Base-T interface junk and you are done. And you are right up there with a no-brainer $20 NE2000 card. The NE2000 is bigger but a lot less hassle. May I suggest integrating ethernet on the second generation system? And lets not worry about 100baseT yet? > Further, ISA is MUCH easier to implement in an embedded design. For the > 68K family it typically takes a pair of 16V8 GALs and a couple of > bi-directional bus buffers. If you use one of the embedded 80XX86 family > parts you get the ISA bus for free. PCI has some VERY stringent timing > requirements which make it very costly to implement in on a small scale. > And besides, at the actual speeds we are discussing adding a PCI bus > would be like killing a bug with a bazooka. I tend to agree. I'd love to have the problem of *needing* to redesign because we've exceeded ISA's bandwidth with our RF solution. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From karn@qualcomm.com Tue Mar 11 18:10:31 1997 Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA10164 for ; Tue, 11 Mar 1997 18:10:28 -0600 (CST) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id QAA13825; Tue, 11 Mar 1997 16:09:56 -0800 (PST) Date: Tue, 11 Mar 1997 16:09:56 -0800 (PST) From: Phil Karn Message-Id: <199703120009.QAA13825@servo.qualcomm.com> To: ss@tapr.org In-reply-to: <331EE610@cbmsmail.cb.lucent.com> (rero@cbmsmail.cb.lucent.com) Subject: Re: [SS:1090] RE: 1085] RE: 1080] Re: SS Design Interfaces >If you are looking for faster data rates, (digital including speech, >text, video etc.), ethernet is a way to go. However, this implies there >is some other interface, RS232 etc. i.e. a console port, which is needed >to administer the ethernet interface. No it doesn't. There are many ways to initialize a device with an Ethernet port but no serial port. It's especially easy if the device comes programmed with a unique Ethernet hardware address, as it should. But even if it doesn't, there are ways around this. A while back I bought a 3rd party Ethernet interface for my HP laser printer. I configured the whole thing through the Ethernet; no serial port was involved. It was nice not to have to hook up a temporary RS-232 cable just to initialize the device. I use RS-232 so seldom these days that dealing with it has become a real pain. I never seem to have the right cable, or one that's long enough, or one with the right gender connectors, or with the right type of connector (DB-25 vs DB-9), or one with (or without) a null modem built in, etc. RS-232 must die. Phil From karn@qualcomm.com Tue Mar 11 18:13:08 1997 Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA10260 for ; Tue, 11 Mar 1997 18:13:06 -0600 (CST) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id QAA13833; Tue, 11 Mar 1997 16:12:35 -0800 (PST) Date: Tue, 11 Mar 1997 16:12:35 -0800 (PST) From: Phil Karn Message-Id: <199703120012.QAA13833@servo.qualcomm.com> To: ss@tapr.org In-reply-to: <44AE0207A4@rm1.liant.com> (BARRON@liant.com) Subject: Re: [SS:1091] Re: WT Docket No. 97-12 - Hollow Victory? >The ARRL proposal (RM-8737) states that automatic power control >be implemented for systems which run more that 1W of power. Since >all Part 15 devices (to the best of my knowledge) run 1W or less >this rule should not hinder Hams at all. Right. The 1W threshold was put there specifically to grandfather existing Part 15.247 devices, which are all limited to 1W. This is actually quite a bit of power, especially when efficient modulation and coding is used in combination with reasonably good antennas. Phil From karn@qualcomm.com Tue Mar 11 19:15:33 1997 Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA13436 for ; Tue, 11 Mar 1997 19:15:31 -0600 (CST) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id RAA13940; Tue, 11 Mar 1997 17:14:56 -0800 (PST) Date: Tue, 11 Mar 1997 17:14:56 -0800 (PST) From: Phil Karn Message-Id: <199703120114.RAA13940@servo.qualcomm.com> To: ss@tapr.org In-reply-to: (jmorriso@bogomips.com) Subject: Re: [SS:1103] Re: SS digest 258 John Paul Morrison writes... >Linux? Can we quote you as an endorser of Linux, coming from a BSD >guy? :-) Sure. I've been running it on my laptop for some months now. I originally tried FreeBSD, but I could never get it to work with my PCMCIA cards (the kernel panicked at attach time). Linux still has its nits, especially on laptops, but at least it can be massaged to work reasonably well. I still run BSDI on my home system, because stability and availability is paramount there. But it is really falling behind Linux in support of new features. Linux is really getting quite impressive. >But anyway, I saw Alan Cox the Linux network code designer talking >about your sound blaster code with FEC coding. Does this code >exist for NOS or Linux? (I know the soundblaster code and viterbi >code exist separately, but are they rolled into one device now?) I can't speak for what anyone might have done with my code, but so far I have only built the core modules for a Viterbi decoder and related items. Much work remains to be done to build a complete, working modem, not to mention the new link layer protocol that will be needed. >I've come round to your thinking of using a generic PC to do all >the DSP and coding. It's far easier to leverage the PC software (ie >Linux or the GCC version of NOS/TNOS) to control a new device. IF >a 386 with a soundblaster can replace a traditional multiport >1200/9600bps TNC, then a 486 or Pentium could do spread spectrum >or something else. There's also free software that does Iphone like >features, multicast audio etc. So a PC could do voice or video as >well not just "data" networking. Exactly. And if this year's PCs are too slow or too expensive to do what you want, just wait a while. >Ascend and Cisco can take Motorola 68EN360's, ethernet, serial, flash >and dram and sell little remote access routers for $1000 or less >because they have the sales volume to make the hardware prices cheaper >and to amortize the programming development over many other products >that use the same software. Hams can't build anything that fancy >AND that cheap. Bingo! From karn@qualcomm.com Tue Mar 11 20:27:41 1997 Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA18833 for ; Tue, 11 Mar 1997 20:27:38 -0600 (CST) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id SAA14055; Tue, 11 Mar 1997 18:27:06 -0800 (PST) Date: Tue, 11 Mar 1997 18:27:06 -0800 (PST) From: Phil Karn Message-Id: <199703120227.SAA14055@servo.qualcomm.com> To: ss@tapr.org In-reply-to: <2.2.32.19970307042611.006e1e18@mail.mich.com> (message from Jeff King on Thu, 6 Mar 1997 22:29:33 -0600 (CST)) Subject: Re: [SS:1113] Re: WT Docket No. 97-12 - Hollow Victory? >You miss my point completely however. Why do you support a specific rule >for automatic power control for SS systems and not for narrowband systems? Narrowband and spread systems are fundamentally different. A narrowband FDM scheme is perfectly orthogonal; that is, you can (in theory) make a filter that accepts one signal while perfectly rejecting all others. Not so for spread spectrum. Spread signals are not perfectly orthogonal. A receiver (spread or narrowband) can reject an undesired signal by only the amount of the processing gain, which is the ratio of the spread bandwidth to the unspread bandwidth. This creates the famous "near-far problem", and it can *only* be solved by transmitter power control. Look at it another way. There are two dimensions to spectrum consumption: bandwidth and power. In exchange for relaxing constraints on the former, it is reasonable to accept constraints on the latter -- especially since it leaves us well ahead on the deal. Digital modulation, especially with strong coding, has a strong threshold effect. There is simply nothing to be gained by running more power than necessary (unlike linear analog schemes where cranking up your signal always makes it sound just a little bit better.) Running excessive power in a digital system is like turning up the stove when the water in the pot is already boiling -- it doesn't make the spaghetti cook any faster. It just wastes gas and heats up the kitchen. We are going to have enough trouble dealing with the rabid opposition to spread spectrum among the repeater, weak signal and satellite crowd even *with* the proposed requirement for automatic transmitter power control. Phil From jeff@mich.com Tue Mar 11 20:28:01 1997 Received: from server1.mich.com (root@server1.mich.com [198.108.16.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA18851 for ; Tue, 11 Mar 1997 20:27:58 -0600 (CST) Received: from gw-aerodata.mich.com (gw-aerodata.mich.com [198.108.16.60]) by server1.mich.com (8.8.4/8.8.4) with SMTP id VAA12662; Tue, 11 Mar 1997 21:30:35 -0500 Message-Id: <2.2.32.19970312022719.0083fe54@mail.mich.com> X-Sender: jeff@mail.mich.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Mar 1997 21:27:19 -0500 To: ss@tapr.org, ss@tapr.org From: Jeff King Subject: Re: [SS:1136] Re: WT Docket No. 97-12 - Hollow Victory? At 06:22 PM 3/11/97 -0600, Phil Karn wrote: >>The ARRL proposal (RM-8737) states that automatic power control >>be implemented for systems which run more that 1W of power. Since >>all Part 15 devices (to the best of my knowledge) run 1W or less >>this rule should not hinder Hams at all. > >Right. The 1W threshold was put there specifically to grandfather >existing Part 15.247 devices, which are all limited to 1W. Hi Phil: Not many (none?) Part 15 devices currently implement power control. Hence the only advantage of using a Part 15 device under Part 97 rules is going to be the ability to run higher antenna gains. At that point I say, why bother? Just run them Part 15 and worry alot less. I don't think Jerry would disagree either on that statement. > >This is actually quite a bit of power, especially when efficient >modulation and coding is used in combination with reasonably good >antennas. > >Phil > I'm glad you (I think) agree that 1 watt is quite a bit of power and that it also needs to fall under the provision of power control as well. I've run 173KBPS SS links over 12 miles using only 10mw. In the bay area MetriCom is saturating the various cities with "pole top" 900mhz frequency hoppers. To the best of my knowledge, no power control is being implemented. While these are Part 15 devices, and as such limited to "only" 1 watt, the potential here is tremendous for interference to other users of the band. This is true by the shear number of these 1 watt stations. Even if MetriCom is implementing power control, the majority (all?) Part 15 manufacturers are not. I'd hazard to guess the ratio on 900mhz of Part 15 vs. Ham emitters is >3000:1. Power control for ad hoc networks is needed, REGARDLESS of the transmitter power, be it 1 watt, 10 milliwatts or 100 watts. To set a arbitrary cutoff of 1 watt clearly is NOT a technical decision but a political one. Most amateurs are going to be hard pressed to generate more then 10 watts on 2.4ghz giving only a 10 db margin of protection for "automatic" power control as contrasted with a 1 watt "manual" emitter. Put that 1 watt into a 30db gain parabolic dish and you'll have 1000 watts ERP. Automatic power control should either apply to all users and modes with no arbitrary cutoff level or we shouldn't have it at all. There have been no documented cases of amateur spread spectrum operators running excessive power while there are numerous cases of narrow band operators running excessive power. To only mandate automatic power control for amateur spread spectrum while closing your eyes to the violations of the narrow band operators is hypocritical. I don't buy the arguments of others that narrow band automatic power control is not technically, or "politically" possible. Older equipment could be grand fathered. I don't expect change to happen overnight, but change will happen. Its up to us now to make sure that SS isn't given the shaft, with regards to any rule makings. Phil, I'm sure your more aware of what back room "dealings" went on with RM-8737 then I am, so I'll need to defer to you on this. I just think automatic power control for ad hoc networks is a good thing, at all power levels. I don't think amateur spread spectrum should be the only mode in which automatic power control is mandated by law. To me, this is a all or nothing question. Possibly you know why this compromise was made, but I think its a mistake to single out spread spectrum only. Regards, -Jeff wb8wka From rw@txcc.net Tue Mar 11 21:12:32 1997 Received: from mail.txcc.net (mail.txcc.net [205.218.183.156]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id VAA21752 for ; Tue, 11 Mar 1997 21:12:29 -0600 (CST) Received: from port9.txcc.net (port9.txcc.net [205.218.183.139]) by mail.txcc.net (8.7.5/8.7.1) with SMTP id WAA10810 for ; Tue, 11 Mar 1997 22:12:08 -0600 Received: by port9.txcc.net with Microsoft Mail id <01BC2E60.C1420A00@port9.txcc.net>; Tue, 11 Mar 1997 21:11:15 -0600 Message-ID: <01BC2E60.C1420A00@port9.txcc.net> From: Ralph Ward To: "'ss@tapr.org'" Subject: RE: 1137] Re: SS digest 258 Date: Tue, 11 Mar 1997 21:08:33 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BC2E60.C149AB20" ------ =_NextPart_000_01BC2E60.C149AB20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stupid question time! Is there a PSK modem for the soundblaster that will run on an old 486? Have one of those, but can't afford to buy a DSP-93 or etc. Thanks. Ralph Ward KB5UAA -----Original Message----- From: Phil Karn [SMTP:karn@qualcomm.com] Sent: Tuesday, March 11, 1997 7:19 PM To: ss@tapr.org Subject: [SS:1137] Re: SS digest 258 John Paul Morrison writes... >Linux? Can we quote you as an endorser of Linux, coming from a BSD >guy? :-) Sure. I've been running it on my laptop for some months now. I originally tried FreeBSD, but I could never get it to work with my PCMCIA cards (the kernel panicked at attach time). Linux still has its nits, especially on laptops, but at least it can be massaged to work reasonably well. I still run BSDI on my home system, because stability and availability is paramount there. But it is really falling behind Linux in support of new features. Linux is really getting quite impressive. >But anyway, I saw Alan Cox the Linux network code designer talking >about your sound blaster code with FEC coding. Does this code >exist for NOS or Linux? (I know the soundblaster code and viterbi >code exist separately, but are they rolled into one device now?) I can't speak for what anyone might have done with my code, but so far I have only built the core modules for a Viterbi decoder and related items. Much work remains to be done to build a complete, working modem, not to mention the new link layer protocol that will be needed. >I've come round to your thinking of using a generic PC to do all >the DSP and coding. It's far easier to leverage the PC software (ie >Linux or the GCC version of NOS/TNOS) to control a new device. IF >a 386 with a soundblaster can replace a traditional multiport >1200/9600bps TNC, then a 486 or Pentium could do spread spectrum >or something else. There's also free software that does Iphone like >features, multicast audio etc. So a PC could do voice or video as >well not just "data" networking. Exactly. And if this year's PCs are too slow or too expensive to do what you want, just wait a while. >Ascend and Cisco can take Motorola 68EN360's, ethernet, serial, flash >and dram and sell little remote access routers for $1000 or less >because they have the sales volume to make the hardware prices cheaper >and to amortize the programming development over many other products >that use the same software. Hams can't build anything that fancy >AND that cheap. Bingo! ------ =_NextPart_000_01BC2E60.C149AB20 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+Ig8DAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAYAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAANQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHNzQHRhcHIub3JnAFNN VFAAc3NAdGFwci5vcmcAAAAAHgACMAEAAAAFAAAAU01UUAAAAAAeAAMwAQAAAAwAAABzc0B0YXBy Lm9yZwADABUMAQAAAAMA/g8GAAAAHgABMAEAAAAOAAAAJ3NzQHRhcHIub3JnJwAAAAIBCzABAAAA EQAAAFNNVFA6U1NAVEFQUi5PUkcAAAAAAwAAOQAAAAALAEA6AQAAAB4A9l8BAAAADAAAAHNzQHRh cHIub3JnAAIB918BAAAANQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHNzQHRhcHIub3JnAFNN VFAAc3NAdGFwci5vcmcAAAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAABAAAAAAAAAKRPQEEgAEA HAAAAFJFOiAxMTM3XSBSZTogU1MgZGlnZXN0IDI1OABQBwEFgAMADgAAAM0HAwALABUACAAhAAIA IgEBIIADAA4AAADNBwMACwAVAAYAMwACADIBAQmAAQAhAAAAODlBMUVGQjA1MDlBRDAxMUJBQ0I0 NDQ1NTM1NDAwMDAA/wYBA5AGAAgPAAAhAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAA AAADAC4AAAAAAAMANgAAAAAAQAA5AEBKUKuSLrwBHgBwAAEAAAAcAAAAUkU6IDExMzddIFJlOiBT UyBkaWdlc3QgMjU4AAIBcQABAAAAFgAAAAG8LpKqubDvoYqaUBHQustERVNUAAAAAB4AHgwBAAAA BQAAAFNNVFAAAAAAHgAfDAEAAAAMAAAAcndAdHhjYy5uZXQAAwAGEKlW+PIDAAcQnwcAAB4ACBAB AAAAZQAAAFNUVVBJRFFVRVNUSU9OVElNRUlTVEhFUkVBUFNLTU9ERU1GT1JUSEVTT1VOREJMQVNU RVJUSEFUV0lMTFJVTk9OQU5PTEQ0ODY/SEFWRU9ORU9GVEhPU0UsQlVUQ0FOVEFGRk8AAAAAAgEJ EAEAAADzCwAA7wsAADAYAABMWkZ1RcA9yQMACgByY3BnMTI1cjIMYGMxAzABBwtgbpEOEDAzMw8W ZmUPkk8B9wKkA2MCAGNoCsBzhGV0AtFwcnEyAACSKgqhbm8SUCAwAdCFAdA2D6AwNTA0FCHzAdAU EDR9B20CgwBQA9T7Ef8TC2IT4RRQE7IY9BTQrwcTAoACkQjmOwlvMBrf+mUOMDUcCh0hHN8d6Rv0 /x4SHH8gTyANH48dvxwPEGD8Mjgl2ibxJq8nuRv0J+K/Jk8qHyndKV8njytUOQ5QHy6kMAEoIzAA AoJzdHnqbAeQaAngdAAAE1AD8FBkY3RsCrFcMlhhmGRqdTFwBRBnaAVCOxYyDAFjCcAyYAMwc258 ZXgXMAewBbAAwAJzc7EAUHNiMhRQMWBhE/D0XGsJ4HALkDI/MqMIYOsykAuAZTGgdjlgAUAzm78M MDRkKAA3QASgC4BnJ/HpNOZiYRcQZAIgNaA1Rucx0DOQO5EgMTEzDlA2n/83rzi/AFE5/ACgNG48 fz2G/zEkD8A+jz+fQK8OUDnvQw/bRB89szMCghMQYzZgS6GTM5A9sHRpOZAgRAEQqGF1bAVAUArA YQnA4GFwaCBGAiE2JCVA6GZpLQ+QOAFAOTBQM+tHDzKjYgsgcglQUlIWoNlSUnc0JUEXAHAB0E1y fzO/Sp9Lpk/QTpAFEAIwLUNPMANhOiBUb1ewUyh1YmoFkHRXsERh6HRlOjYkNk//UQ9SH/9TL1Q5 McA9ow4hS6E6tg5Qm1VvVn5SOYEXASBIPZH7BJA2JDdZb1p/W49cnTkPL12/D5BpcAjQYgqwdDj/ SfoPVEYQX79gxmoAYdALULx5L09AXLALEWJFczYk/ygAYz9kT2VfXK9UT2tfbG/vbXVX0ld0WKk5 b78zPwMwHWmzOXOfdK96oERvY/51B4ACMAXQTwAaAXjSeDD3eHBxUQGAblgwAGAJ8E2g730AAgE1 4F5SZQDwfQAxgJJwHoBcdgiQd2sLgP5ka0CAogTwB0AQYQFADgDvcSI9goIFAhBvBUIXIRLyDVjA bQtRWMAgQzpc6lxXAG9O4W1PMAMQB5BNhLBNDeADYHNvAYAgrk8BIA3gf/BchmZFAMD1AxAuS3B0 fdAXEHhwNSHtZ3J4AUB/AW4x0BrwiAQ9TjRjAyAS8wCABZBsdv9BoUbQDnA14IqSAZAAIIsi/4Dx fUEBwYqRFuAPcAAARtDzDNABkCAuGhKKiA5Qi0L/TnB4wIu/jM+N3w/ARtAFgbePf5CPkZ9sa0BG 0GyPP/uT/5UFKY4MJUCS35e/lPT4YiAoApGY34rTWVCWj/+bT5xfnW+LAGMQnrKLj6Af/6Evjgwo AJ6/pD+lT6ZfiwD/eACjP6jPqd+q5Ar5AzB4L4N5P3rNe1N0dXA1EdZxClAxcGkCICBN0AeAqiEK hUkEIHSJMiCVUPBQU0sgBGKFMH9xtYL6IIYQdX8QAmBLQFjAttJVWLAgA/BsAyByt1AgD7RxA5EG 8DUgNDg2P7ogYkBhTfECILoRZrWBURNhLCBiZ1AggZBuOicFQGEBIAWwNSB0bwW7AXm14URTUC05 TjO40AXAFyBjLgqFVPmUoWtzvYavpLBvsX8FQCx7UgdATxFXbaJLQvA1VUFBCoW+fWdwraI/v2/A fwjBNPI1oBLyYmvmbb5ArMIgX32AAxBYoehhfS3Ikk+yQQuAB0DnBdAHkEZQZ2XIk757sAb/Yv1v IMRPcL9xz2c/aE9pX79qb7NExpZXcwyCTpBoAxEGSwrAA6BbU01UUHQ6a9XhQLQQB0AFoG30bS7X EV3KP8tEbrvMf//Nj86fcr+yzAwhxqUGYAIwF9UkGiLGtFS0IWRhedu68H2AchbQPfAxuvAv8CA5 NyA3OnzBUE3fvnbe+VfR3/0EEEABkBdw+i4FsGfi39+BWCXf/dYgwlPicDEzN11hwVfxnwXwPbDJ wDFwRWA1ONev/7BCxA/FH92vs1PDH+uf7K/xwUNKb2gDoE6gTmAF0O8FsAUQhhADoHcFEFjAvlCT 9ADCrD5MC4B1eLmwekMDkXcTgLQQg0ATgHn/CGC14AQgA5F/AQWwFxAFwH+6cfUjuvDXET3CA1K1 4UI0U0T0pme8YLmwOi2uKcKsWBAa8C61UCdN8W5iCeG4kjuCIE3AuNJt57xwC2AFMG9wtqOGEAeA +7ZBAjBoBCDwQfthCoUFsP/JBG0wtJAIgTUgV3AJ4PkRfbr0SfghTmA1IDVgYfEgr8nABUD8obwh dwWwa7hBB7gA/PEKhVBDTUNJ7kG7QQsg9rAotvI7UtBw/iATMQ3gRqA1ILghWLAMkPvhobSiKftg 9SO3IE3QuHH3FuD2sE3AcwqFrTAIQLrw+/PggGBjGdH/8bRx/TQJAf+7ErghMaC3ofySu1H7wbZA /0tAyaK8AwLSCGUa8EtAEOD/1VD/8fXQuHD0LQFQB5S4op/5EQFQ/NS6sP4Bc3m3sb5tuvFYUE5Q E3GssWKHkO9NwLxxfxC14HaHgRJFCGV/FoAFgYURt0ECgYky+2BC/7shC3EUMQ2B/+JOQLhwPcJf +9DVkBLRBzTrMXOzwHDvGoH/BrqANWB3tqA9kLOw/xrwvlAXZhX3AjFN0D3R1tDv88H8kIQgGaFz TeH0LhVyXfbQeW2Q4UEPYWEZMEF7atGEgG8HcLbyBzQ1YHT/AtMBcLZw6XDz4OmQNWC20ffW8IDh 5cY+1VDP0fZS/cIft1G7ALeVIEMDI0ZFQ/8gMjuR+2B88PPgtYEUMSBCn/SmNXDzUINQtrJOT+lg 670h9SUoAVBr/qG27yA0/xLCgKC3wRJQ7v/wD/EfwUP+PiBDJmRLUBRiWMBtMAqF/7XBtZG8cIXw uHAAUVchvDDfujK2cICghqD+kj/6Nirv3yv/wK0O97tUCUFhAwC2sv53uBIdsboy+FBJwgfwTfF/ S3Ej1f0BIEK69IYQFnFy/w73ODNLgP/xuxCHkBTj+CG/tcG2UU5gJSG2spVQVioUvyCBIEI9ERLR AJCEQmQTxvuEARnBTY8gTyAC0wCQh3H/rKC8EzhlvCOHkAYB+CKEMN+DkLrhAtJFMrZTLAhmg0H/ vCF9MrRjtwEZEtABAwDrEP55PiHlcINAfQC5QLf5C+H/S+BLYEtg9C77g9dhhHCF8P8i4rwhInMl Ub4wTIL3kXmw/xbClVDJwCDhhxAD8bwSYIB/teC4cPSmKGK8sRKzJIZJ/HQnPNEIoQshgLC20bww /9BChRDJwChTTHGGEm2RhHCeKICw9Ku9EihiR0MkYE9h8rRi95EnAS9UJwEp/7wSAXCvIDBBteEZ EjFE+2HyRiGXIDO5kAMUlVAorP/20QCQhDExgZVQ7YDRobRS1clBbYoBaRg5Pl7A0gB4Lzk20gDS UPawVGBD37rwtZG48blyvRJQRNJ9IP8BZUzR3OANgQYACULtgH0g//Sm/bVKshbgBWB00PtgvgD/ iUFPEdbwOfIAkVEYuAN08P0lIUnBwLoy0AAFIPSmGVb/uvBaM4GQ6cGJ8CSgvDC9Us/fkEzhTGJd x3ZvMXK9Ie+AoLZwTOEIVj4OMkRD7VLsICLhIAZwIh+2JLLCrKxFeAaAM7B5+2BBEtH+abqCFDFG MAigTxEEAPax9y/CgzC3IGwoMbbCbjF1cP+AYKygHEFMlAhlNxP2YnZg/68guvBpk3ZgC3GVUDcQ hWHd9C5BgYB/ARKzQ/NQAXB/C5MGcAUg8wG8IDBBlVA28DhFTjNboE8QCRG1kl8fwbrw91EJgbrw ZreRaP8hlxLR26CFIRLCe/C4cRJx/zOwSbGEEPYiBoCGoOUgScL7t8E81CTR8r0ShXH2sPSmfxGm L/M4MyhjgaH2sGdwbP9dkEGTh3B08ShiB/CC8FFj/+VwhxElgYJxCVA6RnhDQQHzFJGs4Gl6UJRG cYUC+FP/MUEFYP1wRMK40AHyh3AdwP+40LWSRmI8kDOgaHe4A30l/x5BEPJRNftgueA/oLtFQeXP HcBgNLgDFoBuYwOGc3BcTkS39IDT9C1CFsFvP7TmruDHFnOyx/i+dn0AA4+xj/AAAwAQEAAAAAAD ABEQAQAAAAMAgBD/////QAAHMEB/U26SLrwBQAAIMEB/U26SLrwBCwABgAggBgAAAAAAwAAAAAAA AEYAAAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAA4AIIAYAAAAA AMAAAAAAAABGAAAAAFKFAAC3DQAAHgAEgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAA OC4wAAMABYAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwAGgAggBgAAAAAAwAAAAAAAAEYA AAAADoUAAAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMACIAIIAYAAAAAAMAA AAAAAABGAAAAABiFAAAAAAAAHgAJgAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAA AB4ACoAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeAAuACCAGAAAAAADAAAAA AAAARgAAAAA4hQAAAQAAAAEAAAAAAAAAHgA9AAEAAAAFAAAAUkU6IAAAAAADAA00/TcAACmS ------ =_NextPart_000_01BC2E60.C149AB20-- From dewayne@warpspeed.com Tue Mar 11 21:31:28 1997 Received: from warpspeed.com (WA8DZP@odo.warpspeed.com [204.118.182.20]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id VAA23045 for ; Tue, 11 Mar 1997 21:31:25 -0600 (CST) Received: from [204.118.182.22] by warpspeed.com with ESMTP (Apple Internet Mail Server 1.1.1); Tue, 11 Mar 1997 19:29:59 -0800 Message-Id: In-Reply-To: <2.2.32.19970312022719.0083fe54@mail.mich.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Mar 1997 19:28:29 -0800 To: ss@tapr.org From: Dewayne Hendricks Subject: Re: [SS:1139] Re: WT Docket No. 97-12 - Hollow Victory? At 8:34 PM -0600 3/11/97, Jeff King wrote: >In the bay area MetriCom is saturating the various cities with >"pole top" 900mhz frequency hoppers. To the best of my knowledge, >no power control is being implemented. While these are Part 15 >devices, and as such limited to "only" 1 watt, the potential here >is tremendous for interference to other users of the band. This >is true by the shear number of these 1 watt stations. Even if >MetriCom is implementing power control, the majority (all?) >Part 15 manufacturers are not. I'd hazard to guess the ratio on >900mhz of Part 15 vs. Ham emitters is >3000:1. Metricom implements and uses auto power control in both their pole top and end-user devices. -- Dewayne -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dewayne Hendricks, WA8DZP ! AOL: HENDRICKS Warp Speed Imagineering ! Internet: dewayne@warpspeed.com 43730 Vista Del Mar ! Packet Radio: WA8DZP @ K3MC.#NOCAL.CA.USA.NOAM Fremont, CA 94539-3204 ! WWW: Fax: (510) 770-9854 ! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From jeff@mich.com Tue Mar 11 22:37:14 1997 Received: from server1.mich.com (root@server1.mich.com [198.108.16.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA26768 for ; Tue, 11 Mar 1997 22:37:12 -0600 (CST) Received: from gw-aerodata.mich.com (gw-aerodata.mich.com [198.108.16.60]) by server1.mich.com (8.8.4/8.8.4) with SMTP id XAA14708 for ; Tue, 11 Mar 1997 23:38:05 -0500 Message-Id: <2.2.32.19970312043631.00869ddc@mail.mich.com> X-Sender: jeff@mail.mich.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Mar 1997 23:36:31 -0500 To: ss@tapr.org From: Jeff King Subject: Re: [SS:1138] Re: WT Docket No. 97-12 - Hollow Victory? At 08:31 PM 3/11/97 -0600, Phil Karn wrote: >>You miss my point completely however. Why do you support a specific rule >>for automatic power control for SS systems and not for narrowband systems? > >Narrowband and spread systems are fundamentally different. A narrowband >FDM scheme is perfectly orthogonal; that is, you can (in theory) make >a filter that accepts one signal while perfectly rejecting all others. I understand they are different. I also understand even commercial interests do power control on narrowband signals for frequency re-use. Your analog narrowband analog cell phone does power control. Power control is a good thing even for narrowband emissions. > >Not so for spread spectrum. Spread signals are not perfectly >orthogonal. A receiver (spread or narrowband) can reject an undesired >signal by only the amount of the processing gain, which is the ratio >of the spread bandwidth to the unspread bandwidth. This creates the >famous "near-far problem", and it can *only* be solved by transmitter >power control. I think you made my point for power control of narrow band transmitters. > >Look at it another way. There are two dimensions to spectrum >consumption: bandwidth and power. In exchange for relaxing constraints >on the former, it is reasonable to accept constraints on the latter -- >especially since it leaves us well ahead on the deal. Digital >modulation, especially with strong coding, has a strong threshold >effect. There is simply nothing to be gained by running more power >than necessary (unlike linear analog schemes where cranking up your >signal always makes it sound just a little bit better.) > >Running excessive power in a digital system is like turning up the >stove when the water in the pot is already boiling -- it doesn't make >the spaghetti cook any faster. It just wastes gas and heats up the >kitchen. Why doesn't this same analogy apply to narrowband users as well? I think you misunderstood my point Phil. I'm _NOT_ saying power control is bad for digital systems, as you seem to think. I'm questioning the hypocrisy of mandating it by law for only one amateur mode. Heck Phil, look at the comments you filed on the NPRM. You said: "In particular, the amateur service has all but ignored the RF power dimension, giving little more than lip service to the requirement to run only the minimum power required to maintain communications" My assumption here is you are referring to narrowband emissions. Is this correct? If so, you are making a clear point to not only have power control in wide band but also in narrowband modes. > >We are going to have enough trouble dealing with the rabid opposition >to spread spectrum among the repeater, weak signal and satellite crowd >even *with* the proposed requirement for automatic transmitter power >control. > >Phil Well, and I think this is the whole point. We need to cowtow to the ignorant masses, right? Automatic power control simply makes sense, to mandate it by law for amateur SS while not requiring it for Part 15 SS emissions and amateur narrowband emissions, at best, is hypocrisy. But if this is the only way to get it through, then I guess so be it. -Jeff From karn@qualcomm.com Tue Mar 11 23:24:49 1997 Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id XAA29616 for ; Tue, 11 Mar 1997 23:24:47 -0600 (CST) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id VAA14380; Tue, 11 Mar 1997 21:24:16 -0800 (PST) Date: Tue, 11 Mar 1997 21:24:16 -0800 (PST) From: Phil Karn Message-Id: <199703120524.VAA14380@servo.qualcomm.com> To: ss@tapr.org In-reply-to: <2.2.32.19970308051220.008c0db4@mail.mich.com> (message from Jeff King on Fri, 7 Mar 1997 23:15:13 -0600 (CST)) Subject: Re: [SS:1124] RE: 1097] Re: WT Docket No. 97-12 - Holl >OK. That's fair enough. What about the already existing Part 15 equipment >that exists and that some of us are currently using under the TAPR-STA? >Will we be grandfathered? Yes. The 1W limit for non-power-controlled equipment matches the 1W limit under Part 15.247. >So far we don't disagree. A vastly overpowered narrowband system can >cause quite a bit of interference to a DSSS system, especially with >many of the low process gain chipsets that are on the market. Not to mention what it will do to narrowband systems trying to share the same spectrum. We are already having enough trouble trying to convince the weak-signal, repeater and satellite guys that SS can coexist even with mandatory power control. >BTW, speaking of overpowered, the rules set the limit at 100watts which >is only 20db over the non-automatic power control limit of 1 watt. And >I'd hazard to guess not very many will run much over 10watts on 900mhz >and above as it becomes quite costly. So we really are only talking >10db of protection. Seems to me power control should apply all the >way down to microwatts if its really going to be effective. You have a point here. The 1W limit, as I said, was to grandfather Part 15.247 devices. But it's my opinion that it was a mistake to not require automatic transmitter power control in the Part 15 rules. The result is a rather badly polluted 902 MHz band. I'm hoping that ham radio can avoid repeating the mistakes of the Part 15 world. >Jon, I'm sure I'm coming off like a Bull in a China Shop, but I think the NPRM >is hypocritical to require power control for SS users while >not at least suggesting power control for other users of the band (be >they narrowband amateur or Part 15 SS). I by and large support the NPRM with As I said in another message, there is a fundamental difference between narrowband and SS operation that makes power control mandatory for SS even if it's merely desirable for narrowband. Phil From jeff@mich.com Wed Mar 12 01:43:01 1997 Received: from server1.mich.com (root@server1.mich.com [198.108.16.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id BAA14165 for ; Wed, 12 Mar 1997 01:42:59 -0600 (CST) Received: from gw-aerodata.mich.com (gw-aerodata.mich.com [198.108.16.60]) by server1.mich.com (8.8.4/8.8.4) with SMTP id CAA32753 for ; Wed, 12 Mar 1997 02:43:59 -0500 Message-Id: <2.2.32.19970312074222.006e1d00@mail.mich.com> X-Sender: jeff@mail.mich.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Mar 1997 02:42:22 -0500 To: ss@tapr.org From: Jeff King Subject: Re: [SS:1143] RE: 1097] Re: WT Docket No. 97-12 - Holl At 11:29 PM 3/11/97 -0600, Phil Karn wrote: >>BTW, speaking of overpowered, the rules set the limit at 100watts which >>is only 20db over the non-automatic power control limit of 1 watt. And >>I'd hazard to guess not very many will run much over 10watts on 900mhz >>and above as it becomes quite costly. So we really are only talking >>10db of protection. Seems to me power control should apply all the >>way down to microwatts if its really going to be effective. > >You have a point here. The 1W limit, as I said, was to grandfather >Part 15.247 devices. But it's my opinion that it was a mistake to not >require automatic transmitter power control in the Part 15 rules. The >result is a rather badly polluted 902 MHz band. I'm hoping that ham >radio can avoid repeating the mistakes of the Part 15 world. Phil: Please note power control is not required for ham systems running under 1 watt as the NPRM reads now. While I understand that the 1W was to grandfather Part 15.247, there really is no point to this. Other then token amateur operations, no one in there right mind would want to operate them under Part 97. Just to much liability... or at least that's my opinion. Also, don't forget a narrowband ID is required under the NPRM. This kinda rules out most off the shelf Part 15 equipment anyways. If we indeed want to do it right, _AND_ we feel that we need the government to mandate it, we should require auto power control for all amateur SS emissions above, lets say 100 micro watts (0.0001 watt). The point here is 1 watt is to high of a cap. Power control on digital SS systems, as Lyle pointed out, is a trivial matter. As you pointed out, we should avoid the mistakes of the Part 15 world. I'm not convinced we need, or it is even wise to have government mandated automatic power rules and equations for amateur SS. None- the-less I understand the desirability of automatic power control for radio systems. -Jeff wb8wka From jeff@mich.com Wed Mar 12 01:46:56 1997 Received: from server1.mich.com (root@server1.mich.com [198.108.16.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id BAA14264 for ; Wed, 12 Mar 1997 01:46:55 -0600 (CST) Received: from gw-aerodata.mich.com (gw-aerodata.mich.com [198.108.16.60]) by server1.mich.com (8.8.4/8.8.4) with SMTP id CAA00287 for ; Wed, 12 Mar 1997 02:47:55 -0500 Message-Id: <2.2.32.19970312074618.006efac8@mail.mich.com> X-Sender: jeff@mail.mich.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Mar 1997 02:46:18 -0500 To: ss@tapr.org From: Jeff King Subject: Re: [SS:1141] Re: WT Docket No. 97-12 - Hollow Victory? At 09:33 PM 3/11/97 -0600, Dewayne Hendricks wrote: >At 8:34 PM -0600 3/11/97, Jeff King wrote: >>In the bay area MetriCom is saturating the various cities with >>"pole top" 900mhz frequency hoppers. To the best of my knowledge, >>no power control is being implemented. > Metricom implements and uses auto power control in both their pole >top and end-user devices. > >-- Dewayne > Thanks Dewayne, I wasn't sure about this. Its interesting to note that they are not required to do this under Part 15, but chose to. -Jeff From lfry@mindspring.com Wed Mar 12 05:31:06 1997 Received: from camel6.mindspring.com (camel6.mindspring.com [204.180.128.212]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id FAA22627 for ; Wed, 12 Mar 1997 05:31:04 -0600 (CST) Received: from glory (mule0.mindspring.com [204.180.128.166]) by camel6.mindspring.com (8.8.5/8.8.5) with SMTP id GAA20594 for ; Wed, 12 Mar 1997 06:31:02 -0500 (EST) Message-Id: <2.2.32.19970312113345.0033bd18@mindspring.com> X-Sender: lfry@mindspring.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Mar 1997 06:33:45 -0500 To: ss@tapr.org From: "Lee W. Fry" Subject: Eb/(No+Io) Well, there has been a lot of discussion pro and con for power control in other modes and at what threshold it should be required. However, I still don't know the answer to the question I posed in [SS:1106]: Is the conversion from BER (or anything else available from available chip sets) to Eb/(No+Io) simple and is it implemented in any of the transceiver interfaces available? We simply can't comply with the proposed rule allowing us to exceed 1 watt if we can't implement the Eb/(No+Io) measurement. The chips I know about give a analog "Received Signal Strength Indicator" or a BER. How do you equate those measurements to Eb/(No+Io)? Lee W. Fry AA0JP lfry@mindspring.com See my Part 15 Spread Spectrum Device Compendium at: http://www.mindspring.com/~lfry/part15.htm From ssampson@claven.tinker.af.mil Wed Mar 12 08:23:02 1997 Received: from othello.tinker.af.mil (othello.tinker.af.mil [137.240.231.43]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id IAA00683 for ; Wed, 12 Mar 1997 08:23:00 -0600 (CST) Received: from localhost by othello.tinker.af.mil (AIX 4.1/UCB 5.64/4.03) id AA16014; Wed, 12 Mar 1997 08:22:55 -0600 Sender: ssampson@othello.tinker.af.mil Message-Id: <3326BC3E.41C6@eds.tinker.af.mil> Date: Wed, 12 Mar 1997 08:22:55 -0600 From: Steve Sampson Organization: TRW Space & Electronics X-Mailer: Mozilla 3.01 (X11; U; AIX 1) Mime-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1145] Re: WT Docket No. 97-12 - Hollow Victory? References: <2.2.32.19970312074618.006efac8@mail.mich.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jeff King wrote: > > At 09:33 PM 3/11/97 -0600, Dewayne Hendricks wrote: > > Metricom implements and uses auto power control in both their pole > >top and end-user devices. > > > Thanks Dewayne, I wasn't sure about this. Its interesting to note that > they are not required to do this under Part 15, but chose to. It's not a technical or do-gooder thing, it's an investment. Marketing says they want to sell xxxx accounts, engineering responds with a way to do this, + a little slop. If they used no power control: marketing would fail, the stock would fail, and investors would go away. Big business doesn't plan anything for the short term. They also would not tolerate a bunch of choo-choo era morse code ID's every 10 minutes in the middle of their fricking channel :-) Steve "reading my marketing 101 notes" From dewayne@warpspeed.com Wed Mar 12 09:04:41 1997 Received: from warpspeed.com (odo.warpspeed.com [204.118.182.20]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id JAA02941 for ; Wed, 12 Mar 1997 09:04:38 -0600 (CST) Received: from [204.118.182.22] by warpspeed.com with ESMTP (Apple Internet Mail Server 1.1.1); Wed, 12 Mar 1997 07:04:35 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Mar 1997 07:04:06 -0800 To: dewayne-net@warpspeed.com (Dewayne's Wireless News List), ss@tapr.org, ss-sta@tapr.org From: Dewayne Hendricks Subject: George Gilder on CDMA In the latest edition of 'Forbes ASAP', George Gilder has an article with his views on CDMA technology, entitled "Telecosm and Beyond: Over The Paradigm Cliff". Check it out at: -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dewayne Hendricks, WA8DZP ! AOL: HENDRICKS Warp Speed Imagineering ! Internet: dewayne@warpspeed.com 43730 Vista Del Mar ! Packet Radio: WA8DZP @ K3MC.#NOCAL.CA.USA.NOAM Fremont, CA 94539-3204 ! WWW: Fax: (510) 770-9854 ! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From wb9mjn@wb9mjn.ampr.org Wed Mar 12 09:12:17 1997 Received: from wb9mjn.ampr.org (wb9mjn.ampr.org [44.72.98.19]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id JAA03277 for ; Wed, 12 Mar 1997 09:12:10 -0600 (CST) From: wb9mjn@wb9mjn.ampr.org Date: Wed, 12 Mar 97 08:47:25 UTC Message-Id: <13127@wb9mjn.ampr.org> To: ss@tapr.org Subject: Re: [SS:1146] Eb/(No+Io) In-Reply-To: your message of Wed Mar 12 05:32:22 1997 <2.2.32.19970312113345.0033bd18@mindspring.com> Hi Lee, The direct way to determine Eb/(No+Io) is to measure the errors in a test transmission of known period, of a PRN sequence. K9NG published a paper on using PRN sequences to measure Bit Error rates a year or two after his modem paper. The technigue can be directly carried over to spread spectrum , at the tail end of all processing. 73, Don. Mailbox : WB9MJN @ N9HSI.IL.USA.NA AMPRNet : wb9mjn@wb9mjn.ampr.org[44.72.98.19] Internet: wb9mjn%wb9mjn.ampr.org@uugate.aim.utah.edu From wb9mjn@wb9mjn.ampr.org Wed Mar 12 09:15:58 1997 Received: from wb9mjn.ampr.org (wb9mjn.ampr.org [44.72.98.19]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id JAA03435 for ; Wed, 12 Mar 1997 09:15:03 -0600 (CST) From: wb9mjn@wb9mjn.ampr.org Date: Wed, 12 Mar 97 08:50:13 UTC Message-Id: <13129@wb9mjn.ampr.org> To: ss@tapr.org Subject: Re: [SS:1146] Eb/(No+Io) In-Reply-To: your message of Wed Mar 12 05:32:22 1997 <2.2.32.19970312113345.0033bd18@mindspring.com> Hi again Lee, In spread spectrum there is an additional way to determine Eb/(No+Io). One can compare the the narrow band despread power, and the narrow band spread signal powers, before and after the despreading device. This is neccassarily a technigue requiring wideband IF amplification, or momentary disabling of the despreading function. 73, Don. Mailbox : WB9MJN @ N9HSI.IL.USA.NA AMPRNet : wb9mjn@wb9mjn.ampr.org[44.72.98.19] Internet: wb9mjn%wb9mjn.ampr.org@uugate.aim.utah.edu From jeff@mich.com Wed Mar 12 10:15:39 1997 Received: from server1.mich.com (root@server1.mich.com [198.108.16.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id KAA06736 for ; Wed, 12 Mar 1997 10:15:36 -0600 (CST) Received: from gw-aerodata.mich.com (gw-aerodata.mich.com [198.108.16.60]) by server1.mich.com (8.8.4/8.8.4) with SMTP id LAA08178; Wed, 12 Mar 1997 11:16:45 -0500 Message-Id: <2.2.32.19970312161459.00882a1c@mail.mich.com> X-Sender: jeff@mail.mich.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Mar 1997 11:14:59 -0500 To: ss@tapr.org, ss@tapr.org From: Jeff King Subject: Re: [SS:1146] Eb/(No+Io) At 05:32 AM 3/12/97 -0600, Lee W. Fry wrote: >Is the conversion from BER (or anything else available from available chip >sets) to Eb/(No+Io) simple and is it implemented in any of the transceiver >interfaces available? > >We simply can't comply with the proposed rule allowing us to exceed 1 watt >if we can't implement the Eb/(No+Io) measurement. The chips I know about >give a analog "Received Signal Strength Indicator" or a BER. How do you >equate those measurements to Eb/(No+Io)? > >Lee W. Fry AA0JP Then Don said: >Hi Lee, > > The direct way to determine Eb/(No+Io) is to measure the errors in a >test transmission of known period, of a PRN sequence. > > K9NG published a paper on using PRN sequences to measure Bit Error rates >a year or two after his modem paper. > > > The technigue can be directly carried over to spread spectrum , at the >tail end of all processing. Hi Lee: Don didn't answer your question. I've already said to much on SS-SIG to point this out, but you may want to bring it up if you don't get the right answer. While many of the existing off the shelf chip sets give you a BER, I'm not sure if any give Eb/(No+Io). This being the case, the rules might stifle any adaptation of these existing chip sets into amateur SS gear. However, I'd hazard to guess you could equate the chip sets BER or merit figure over to Eb/(No+Io) using a lookup table. You would need to manually chart it out so it wouldn't be for the faint at heart. The good news (I think) is if the chip manufacturers see a market, I'd bet they would be willing to do this. Regards, ------------------------------------ | Jeff King Aero Data Systems | | jeff@mich.com P.O. Box 510895 | | (810)471-1787 Livonia, MI 48151 | |F(810)471-0279 United States | ------------------------------------ From nielsen@primenet.com Wed Mar 12 11:37:47 1997 Received: from usr10.primenet.com (root@usr10.primenet.com [206.165.5.110]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA12198 for ; Wed, 12 Mar 1997 11:37:46 -0600 (CST) Received: from primenet.com (root@mailhost02.primenet.com [206.165.5.53]) by usr10.primenet.com (8.8.5/8.8.5) with ESMTP id KAA29186 for ; Wed, 12 Mar 1997 10:37:42 -0700 (MST) Received: from MAILER-DAEMONielsen.tus.primenet.com (nielsen.tus.primenet.com [198.68.42.82]) by primenet.com (8.8.5/8.8.5) with ESMTP id KAA17002 for ; Wed, 12 Mar 1997 10:37:36 -0700 (MST) Received: from localhost (nielsen@localhost) by MAILER-DAEMONielsen.tus.primenet.com (8.7.6/8.7.3) with SMTP id KAA02302 for ; Wed, 12 Mar 1997 10:37:35 -0700 X-Authentication-Warning: nielsen.tus.primenet.com: nielsen owned process doing -bs Date: Wed, 12 Mar 1997 10:37:35 -0700 (MST) From: Bob Nielsen X-Sender: nielsen@nielsen.tus.primenet.com Reply-To: nielsen@primenet.com To: ss@tapr.org Subject: Re: [SS:1143] RE: 1097] Re: WT Docket No. 97-12 - Holl In-Reply-To: <199703120524.VAA14380@servo.qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 11 Mar 1997, Phil Karn wrote: > As I said in another message, there is a fundamental difference between > narrowband and SS operation that makes power control mandatory for SS > even if it's merely desirable for narrowband. It's more than just desirable (but rarely observed): 97.313 Transmitter power standards (a) An amateur station must use the minimum transmitter power necessary to carry out the desired communications. Bob ---- Bob Nielsen Internet: nielsen@primenet.com Tucson, AZ AMPRnet: w6swe@w6swe.ampr.org AX.25: w6swe@wb7tls.az.usa.noam http://www.primenet.com/~nielsen From karn@qualcomm.com Wed Mar 12 22:16:53 1997 Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA16927 for ; Wed, 12 Mar 1997 22:16:51 -0600 (CST) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id UAA18380; Wed, 12 Mar 1997 20:16:09 -0800 (PST) Date: Wed, 12 Mar 1997 20:16:09 -0800 (PST) From: Phil Karn Message-Id: <199703130416.UAA18380@servo.qualcomm.com> To: ss@tapr.org In-reply-to: <2.2.32.19970312022719.0083fe54@mail.mich.com> (message from Jeff King on Tue, 11 Mar 1997 20:34:21 -0600 (CST)) Subject: Re: [SS:1139] Re: WT Docket No. 97-12 - Hollow Victory? >Not many (none?) Part 15 devices currently implement power control. >Hence the only advantage of using a Part 15 device under Part >97 rules is going to be the ability to run higher antenna gains. >At that point I say, why bother? Just run them Part 15 and worry >alot less. I don't think Jerry would disagree either on that >statement. Agreed here too. >Power control for ad hoc networks is needed, REGARDLESS of the >transmitter power, be it 1 watt, 10 milliwatts or 100 watts. To >set a arbitrary cutoff of 1 watt clearly is NOT a technical >decision but a political one. Most amateurs are going to be Bingo. IS-95 CDMA power control has a dynamic range on the order of 80dB. In fact, max power output of a typical portable is only 300mW, into a rotten antenna. If it were necessary for the rule changes to pass, I'd be willing to go along with *lowering* the 1W grandfather limit for no power control -- at least for the bands where existing Part 15 equipment isn't of use (e.g., 6m-70cm). I also agree that it would be nice to require automatic power control in narrowband systems, but this is politically untenable right now. Also, power control is just not *quite* as essential in a narrowband system as it is in a SS system. Perhaps if we can show how well power control works with spread spectrum, things may change. By the way, I think I can take credit for the power control rule, plus the Eb/(N0+I0) limit formulation. I originally suggested it to the Future Systems Committee, who suggested it to the ARRL Board, who in turn suggested it to the FCC. So I guess I deserve whatever kudos and brickbats are forthcoming here. Phil From karn@qualcomm.com Wed Mar 12 22:33:19 1997 Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA17841 for ; Wed, 12 Mar 1997 22:33:16 -0600 (CST) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id UAA18414; Wed, 12 Mar 1997 20:32:44 -0800 (PST) Date: Wed, 12 Mar 1997 20:32:44 -0800 (PST) From: Phil Karn Message-Id: <199703130432.UAA18414@servo.qualcomm.com> To: ss@tapr.org In-reply-to: <2.2.32.19970312074222.006e1d00@mail.mich.com> (message from Jeff King on Wed, 12 Mar 1997 01:44:41 -0600 (CST)) Subject: Re: [SS:1144] RE: 1097] Re: WT Docket No. 97-12 - Holl >If we indeed want to do it right, _AND_ we feel that we need the >government to mandate it, we should require auto power control for all >amateur SS emissions above, lets say 100 micro watts (0.0001 watt). >The point here is 1 watt is to high of a cap. Power control on >digital SS systems, as Lyle pointed out, is a trivial matter. As >you pointed out, we should avoid the mistakes of the Part 15 world. I wouldn't call power control exactly "trivial" (the particular power control scheme used in IS-95 was one of its most important contributions to the SS art). But it's certainly doable, especially since the rules don't specify any particular time constant. I just don't want to make the dynamic range requirement *too* wide, as that can be quite a challenge; attaining *really* low power levels can take some pretty thorough design. If you're not careful, you end up emitting far more energy from the radio than from the antenna! Still, I expect that any SS designs we actually field will power control well below the 1W level. After all, if you're going to do power control at all, you might as well do it reasonably right. Phil From karn@qualcomm.com Wed Mar 12 22:46:32 1997 Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA18609 for ; Wed, 12 Mar 1997 22:46:29 -0600 (CST) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id UAA18435; Wed, 12 Mar 1997 20:45:58 -0800 (PST) Date: Wed, 12 Mar 1997 20:45:58 -0800 (PST) From: Phil Karn Message-Id: <199703130445.UAA18435@servo.qualcomm.com> To: ss@tapr.org In-reply-to: <2.2.32.19970312113345.0033bd18@mindspring.com> (lfry@mindspring.com) Subject: Re: [SS:1146] Eb/(No+Io) >We simply can't comply with the proposed rule allowing us to exceed 1 watt >if we can't implement the Eb/(No+Io) measurement. The chips I know about >give a analog "Received Signal Strength Indicator" or a BER. How do you >equate those measurements to Eb/(No+Io)? There are several ways to measure Eb/(No+IO): 1. In the demodulator. The details depend on the precise modulation method. It is generally possible to compute the mean-square difference between the incoming signal and a locally regenerated copy made from the best estimate of the incoming signals. This gives you an estimate of the No+Io. You already know the total incoming energy. From these figures and the data rate you can estimate Eb/(No+Io). 2. In the FEC decoder. Viterbi or Fano decoder metrics, or Fano decoder 'effort' (branches searched per data bit) measurements can be converted to Eb/(N0+I0) estimates fairly easily based on the known properties of the code and decoder. 3. After FEC, e.g., in the ARQ algorithm. If you know your modulation + FEC requires, say, Eb/N0= 6 dB to produce error free data, then you simply crank down the power until you start getting errors, then come back up a little. You'll still be far under the limit. Remember that you don't actually have to *measure* Eb/(N0+I0), you simply need to design the system so that you stay under the limit in practice, on average. It's just like the existing power limit. Staying under it is the important thing. *How* you do it is up to you. You may choose to measure it, or you may instead choose to design your system so that it inherently stays under the limit. In the present case, Eb/No = 23 dB is a *very* generous figure that can be met with almost any uncoded modulation scheme, reasonably implemented. I hope real implementations will do much better in practice; 6 dB is entirely achievable, even on a Rayleigh fading channel. Phil From wd5ivd@tapr.org Wed Mar 12 23:45:20 1997 Received: from [208.134.134.40] ([208.134.134.40]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id XAA23838 for ; Wed, 12 Mar 1997 23:45:18 -0600 (CST) Message-Id: In-Reply-To: <199703130445.UAA18435@servo.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Mar 1997 23:45:45 -0600 To: ss@tapr.org From: "Greg Jones, WD5IVD" Subject: Re: [SS:1155] Re: Eb/(No+Io) The question becomes Phil -- why put a higher level of measure to this mode then any other mode requires ? Granted that we will design good systems and for those systems to work correctly power control will be a major design criteria, but as you and Tom Clark pointed out in your paper at the Central States VHF meeting there could be instances where power control is not practical....such as EME....or maybe SS gets used to communicate to the amateur Mars mission ? 1 watt probably isn't enough for either for those modes ? Wouldn't you want to transmit the minimum amount of power needed up to the allowable limit within the hobby for the type of communications happening. Which Bob Nielson and some others have pointed is already covered in the rules. When we ask for rules such as power control based on a formula as currently defined in the rule making are we not doing what we were trying to undo in the first place. That of removing constraints to allow more flexibility for experimentation and learning (removal of sequences and the like) -- but now we are adding new rules which might further limit what people can experiment with. Although it is simple to see that the reason 1 watt and auto-power control is in there is as a bone to the Part 15 groups that see amateurs running more power as a threat to what they are doing. FCC hopes to make them happy -- but I think we can all agree that the Part 15 groups are going to be making a lot of negative comments to the docket. Meaning -- we all have to be sure to file our own comments in support of the change! Power control is important, but does it need to be specifically mentioned in the SS section of the rules ? If SS is to be considered a mode like any other, we need to treat it the same as we handle other types within the rules and other modes are required to follow. There are plenty of rules in place already that concern power levels. I think a more pressing issue will concern getting in-band ID accepted via the data stream transmitted. Just like packet and any of the othe digital modes (a majority of the HF digital modes). Having to add a CW ID to the signal is what the world is trying to get away from -- right ? Comment should really be made to allow an ID to be transmitted in the data stream and as long as that spec is available (just like all the newer HF digital modes) it should be legal to do so. There is no difference between transmitting SS or some modulation on HF, VHF, or UHF when it comes to identification. Place the callsign every ten minutes in a packet and keep on going. Could even add LAT/LON to the ID to help with locating the signal. Also, of a more pressing issue is the frequency coverage. There will be demand to use SS systems below what the current rules allow. I think we can agree on that ? If we don't ask for this mode to have full access to the bands like any other mode -- it might be years to allow SS on bands below the current ones authorized. While many might think this bad -- we might desperately need SS on 2, 219-220, and other freqs in the next 5 years to fend off those that say we don't utilize those bands and would want to take them over. Based on the fact that we occupy, but don't really utilize the billion of dollars of freqs we have access to. Three key points in the rule making that should be of greatest concern are the freq issue, id'ing issue, and power limitations set in the rules. Cheers - Greg ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From jeff@mich.com Wed Mar 12 23:58:09 1997 Received: from server1.mich.com (root@server1.mich.com [198.108.16.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id XAA24909 for ; Wed, 12 Mar 1997 23:58:03 -0600 (CST) Received: from gw-aerodata.mich.com (gw-aerodata.mich.com [198.108.16.60]) by server1.mich.com (8.8.4/8.8.4) with SMTP id AAA10846; Thu, 13 Mar 1997 00:59:22 -0500 Message-Id: <2.2.32.19970313055719.008480a0@mail.mich.com> X-Sender: jeff@mail.mich.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Mar 1997 00:57:19 -0500 To: karn@qualcomm.com, ss@tapr.org From: Jeff King Subject: Re: [SS:1153] Re: WT Docket No. 97-12 - Hollow Victory? At 10:20 PM 3/12/97 -0600, Phil Karn wrote: >If it were necessary for the rule changes to pass, I'd be willing to >go along with *lowering* the 1W grandfather limit for no power control >-- at least for the bands where existing Part 15 equipment isn't of use >(e.g., 6m-70cm). At the risk of beating a dead horse (which I'm sure I've done time and time over by now), I do need to remind you that due to the requirements of a narrowband CW ID, no Part 15 equipment will be grandfathered that can't do a CW ID. While I'm sure the dedicated experimenter can rig something up, most won't bother and will just operate them under Part 15. I see no reason to compromise (grandfather) on the NPRM when the compromise will do us little good. If we are going to make a law to require automatic power control, it might as well be for something that is of some value. 20 db is not enough, especially considering the upper limit of 100watts. >By the way, I think I can take credit for the power control rule, plus >the Eb/(N0+I0) limit formulation. I originally suggested it to the >Future Systems Committee, who suggested it to the ARRL Board, who in >turn suggested it to the FCC. So I guess I deserve whatever kudos and >brickbats are forthcoming here. > >Phil I'd be interested in reading about power control theory in more detail. Do you have any recommendations on texts? Thanks -Jeff From karn@qualcomm.com Thu Mar 13 00:04:45 1997 Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id AAA26494 for ; Thu, 13 Mar 1997 00:04:40 -0600 (CST) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id WAA18669; Wed, 12 Mar 1997 22:04:03 -0800 (PST) Date: Wed, 12 Mar 1997 22:04:03 -0800 (PST) From: Phil Karn Message-Id: <199703130604.WAA18669@servo.qualcomm.com> To: jeff@mich.com CC: ss@tapr.org In-reply-to: <2.2.32.19970313055719.008480a0@mail.mich.com> (message from Jeff King on Thu, 13 Mar 1997 00:57:19 -0500) Subject: Re: [SS:1153] Re: WT Docket No. 97-12 - Hollow Victory? >I'd be interested in reading about power control theory in more detail. >Do you have any recommendations on texts? Well, there's Viterbi's textbook on CDMA. Addison-Wesley is the publisher. Phil From fred@tekdata.com Thu Mar 13 11:02:48 1997 Received: from tekdata.com (vh1-038.wwa.com [205.243.70.39]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA29026 for ; Thu, 13 Mar 1997 11:02:41 -0600 (CST) Received: (from fred@localhost) by tekdata.com (8.6.12/8.6.12) id KAA15934; Thu, 13 Mar 1997 10:22:00 -0600 Date: Thu, 13 Mar 1997 10:21:59 -0600 (CST) From: "Fred M. Spinner" To: ss@tapr.org Subject: Re: [SS:1153] Re: WT Docket No. 97-12 - Hollow Victory? In-Reply-To: <199703130416.UAA18380@servo.qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > >Power control for ad hoc networks is needed, REGARDLESS of the > >transmitter power, be it 1 watt, 10 milliwatts or 100 watts. To > >set a arbitrary cutoff of 1 watt clearly is NOT a technical > >decision but a political one. Most amateurs are going to be > > Bingo. IS-95 CDMA power control has a dynamic range on the order of 80dB. > In fact, max power output of a typical portable is only 300mW, into > a rotten antenna. > > If it were necessary for the rule changes to pass, I'd be willing to > go along with *lowering* the 1W grandfather limit for no power control > -- at least for the bands where existing Part 15 equipment isn't of use > (e.g., 6m-70cm). > > I also agree that it would be nice to require automatic power control > in narrowband systems, but this is politically untenable right now. > Also, power control is just not *quite* as essential in a narrowband > system as it is in a SS system. > > Perhaps if we can show how well power control works with spread > spectrum, things may change. > How is the power control going to apply in systems that are not point to point? Maybe I'm confused but if there is a "broadcast" mode or "multipoint" mode available, then isn't one receiving station going to need more power from the transmitter than the other? (except for the special case where the signals are the same, of course..) Isn't there the possibility that the power control might make monitoring the SS communications by the FCC and other 3rd parties more difficult? I guess then the "minimum" power would be for the farthest station? Fred M. Spinner, KA9VAW fred@tekdata.com From fields@svpal.org Thu Mar 13 12:11:50 1997 Received: from svpal.svpal.org (fields@svpal.svpal.org [204.118.32.56]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id MAA03636 for ; Thu, 13 Mar 1997 12:11:48 -0600 (CST) Received: (from fields@localhost) by svpal.svpal.org (8.7.5/8.7.3) id KAA16597; Thu, 13 Mar 1997 10:10:38 -0800 (PST) Date: Thu, 13 Mar 1997 10:10:37 -0800 (PST) From: Julian Fields Subject: Re: [SS:1148] George Gilder on CDMA To: ss@tapr.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Interesting article. He claims 3 to 6 times the information carrying capacity for cell telephones. Assuming the requirement for dead space between channels in FDMA would account for 20% and another 20% due to dead space in TDMA, this would give a 40% increase, not 3 to 6 times. Where does the further improvment come from? I guess you can have frequency reuse from neighboring cells whereas analog cannot use the same frequency in physically adjacent cells due to interference in analog. On the negative side, CDMA has already spread it's interference to 10, 100, or millions of times the minimum required spectrum. So, where does 3 to 6 improvement come from? On Wed, 12 Mar 1997, Dewayne Hendricks wrote: > In the latest edition of 'Forbes ASAP', George Gilder has an > article with his views on CDMA technology, entitled "Telecosm and Beyond: > Over The Paradigm Cliff". Check it out at: > From kevin.jessup@mail.mei.com Thu Mar 13 13:56:23 1997 Received: from meipws.mis.mei.com (meipws.mis.mei.com [151.186.40.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id NAA01101 for ; Thu, 13 Mar 1997 13:56:21 -0600 (CST) Received: from caffeine (caffeine.isdn.mei.com) by meipws.mis.mei.com (PMDF V5.0-5 #5043) id <01IGGFHUI6GW8ZIO9H@meipws.mis.mei.com> for ss@tapr.org; Thu, 13 Mar 1997 13:51:08 -0600 (CST) Date: Thu, 13 Mar 1997 13:54:04 -0600 From: Kevin Jessup Subject: Re: [SS:1160] Re: George Gilder on CDMA X-Sender: jessupkp@meipws.mis.mei.com To: ss@tapr.org Message-id: <01IGGFHUM74Y8ZIO9H@meipws.mis.mei.com> MIME-version: 1.0 X-Mailer: Windows Eudora Version 2.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thanks for the pointer to Gilder's article. In case others have not stopped in at Qualcomm's site for a while, there are a couple of articles responding to recent criticism of CDMA. For what it's worth... by Ira Brodsky November 18, 1996 issue of Network World http://www.qualcomm.com/cdmatech/sink.html Perhaps this was already mentioned. I've been away from the SS sig for a while. n9sqb kevin.jessup@mail.mei.com sr software engineer marquette medical systems http://www.mei.com From rmccabe@sprintmail.com Thu Mar 13 14:02:25 1997 Received: from mailgate22 (mailgate22-hme0.a001.sprintmail.com [205.137.196.54]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id OAA01271 for ; Thu, 13 Mar 1997 14:02:24 -0600 (CST) Received: by mailgate22 (SMI-8.6/SMI-SVR4) id MAA11838; Thu, 13 Mar 1997 12:01:45 -0800 Received: from sdn-ts-007mokcitp04.dialsprint.net(206.133.161.119) by mailfep3-hme1 via smap (KC5.24) id Q_10.1.1.8/Q_27056_1_33285d24; Thu Mar 13 12:01:40 1997 Message-ID: <33285EE9.3545@sprintmail.com> Date: Thu, 13 Mar 1997 14:09:13 -0600 From: "Robert P. McCabe" X-Mailer: Mozilla 2.01E (Win95; U) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1157] Re: WT Docket No. 97-12 - Hollow Victory? References: <2.2.32.19970313055719.008480a0@mail.mich.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Jeff King wrote: > > At 10:20 PM 3/12/97 -0600, Phil Karn wrote: > > >If it were necessary for the rule changes to pass, I'd be willing to > >go along with *lowering* the 1W grandfather limit for no power control > >-- at least for the bands where existing Part 15 equipment isn't of use > >(e.g., 6m-70cm). > > At the risk of beating a dead horse (which I'm sure I've done time and > time over by now), I do need to remind you that due to the requirements > of a narrowband CW ID, no Part 15 equipment will be grandfathered that > can't do a CW ID. While I'm sure the dedicated experimenter can rig > something up, most won't bother and will just operate them under > Part 15. I see no reason to compromise (grandfather) on the NPRM > when the compromise will do us little good. If we are going to make a > law to require automatic power control, it might as well be for something > that is of some value. 20 db is not enough, especially considering the > upper limit of 100watts. > > >By the way, I think I can take credit for the power control rule, plus > >the Eb/(N0+I0) limit formulation. I originally suggested it to the > >Future Systems Committee, who suggested it to the ARRL Board, who in > >turn suggested it to the FCC. So I guess I deserve whatever kudos and > >brickbats are forthcoming here. > > > >Phil > > I'd be interested in reading about power control theory in more detail. > Do you have any recommendations on texts? > > Thanks > > -JeffRe: Tx Power Control for SS While SS Tx power control may be relatively simple on 2 party full duplex RF paths, that have an established power control protocol, with relatively stable path losses things can be more complex in other situations. For example: a. Mobile Applications. How often does one adjust power levels to compensate for varying path losses? Is a full duplex path needed so that the sending end can be notified that received levels are too high or low? b. What power does one use on an initial transmission? c. If three or more parties were involved with a connection the power control protocol would have to look for the receiving station with the lowest received signal level. What if this round table included a number of mobiles? d. Since the receiving station must transmit the measured Eb/ (NO + IO), this automatic power control essentially prohibits one way broadcasts unless broadcasting station power is under 1 watt. e. How can the FCC monitor or enforce this rule? Since this has to be automatic there has to be a standard way of doing this. Who establishes the standard? Will existing equipment be grandfarthered? It raises an interesting legal question as to who is responsible. If it was just a limit on power output clearly it would be the transmitting operator. However, in this case, to meet the requirement at least two parties are involved. f. The Notice of Proposed Rule Making (Docket 97-12) simply states that “Average transmitter power over 1 W shall be automatically adjusted to maintain an Eb/ (NO + IO) ratio of no more than 23 dB at the intended receiver”. There is no specification of the time period used to calculate the average, how often the receiving station has to make the measurements or if the receiving station has to notify the sending station immediately or on its next transmission. A lot of unanswered questions. It looks to me that we should ask the FCC to hold off on the power control requirement until these issues are investigated and some consensus can be developed in the amateur community. Note that comments from interested parties on this NPRM must be filed with the FCC on or before May 5, 1997. Bob McCabe W8JWK From jeff@mich.com Thu Mar 13 15:49:14 1997 Received: from server1.mich.com (root@server1.mich.com [198.108.16.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id PAA07590 for ; Thu, 13 Mar 1997 15:49:12 -0600 (CST) Received: from gw-aerodata.mich.com (gw-aerodata.mich.com [198.108.16.60]) by server1.mich.com (8.8.4/8.8.4) with SMTP id QAA05948; Thu, 13 Mar 1997 16:37:29 -0500 Message-Id: <2.2.32.19970313213509.00733430@mail.mich.com> X-Sender: jeff@mail.mich.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Mar 1997 16:35:09 -0500 To: "Robert A. Buaas" From: Jeff King Subject: Re: WaveLAN Cc: ss@tapr.org Bob: Also forwarding this on to ss-sig as it might be of some interest to those with WaveLans. {Bob's response to my question about a problem I thought I had with one of the WaveLan boards I had bought in the surplus buy 6-7 months ago. At 12:20 PM 3/8/97 -0800, Robert A. Buaas wrote: >Hi Jeff-- > >does your antenna system short the center conductor to the shield? >There's a current path there, used to switch the pin diodes in >the diversity antenna. If you have a short, it's been known to >blow up the card.... I have no info on what actually happens, >but I did hear negative results. > .. >have a nice weekend. looked like bad weather up your way. condolances. > >best regards/bob > Bob: Solved the problem and thought you might be interested in what I found. Your suggestion was what helped me find the problem. My antennas are DC open circuits. The antennas were corner reflectors made by Olde Colorado Antennas out of Denver. 10dbi gain fed with about 75 feet of LMR-400. Distance I was trying to cover was only about 0.3 of a mile. Both cards are in Linux systems with WaveLan support compiled into the kernel. First day I installed the link they worked like a champ. Next day it didn't work. Some-one had tarred up the roof on one end of the link, so I assumed they damaged the coax. Replaced it and still didn't work. Brought cards together and they worked fine with back of the set antennas. Did a flood ping with my bird wattmeter hooked up to each respective card, one card showed lower output. So, I ordered another card at (yuck) full list to replace the suspect card. Still didn't work. After receiving your message, I talked with David at Olde Antenna and he told me his corner reflectors were DC open circuits. OK, that shot that theory down... On a lark, I hooked up the DC ohmmeter to the site where I had installed the new coax the previous day. I read a DC resistance of 300 ohms. On the end of the link where the coax was a bit older (it had been up about 7 days) I read a DC resistance of 50 ohms. Very strange. I climbed up the roof, took the antenna down, and measured it.... open circuit just as David had told me it would be. But the coax measured between 75-50 ohms DC resistance. Both coax s were tested when I made them in my shop and didn't exhibit any shorts or opens what-so-ever. The connectors were N type and were used but in good shape. The telling thing about the whole incident was the newer coax (less time installed on the Wavelan) had a HIGHER short resistance (300) then the coax that had been on a longer period of time (50). The resistive shorts appeared to be in the rooftop connectors on both ends. Both rooftop connectors had been previous sealed with heat shrink boots and hot glue melt. What I believe happened was that since the WaveLan puts a DC voltage on the COAX, this caused plating to occur across the coax/connector. Note that it was quite humid/moist when I installed both of these. When first installed, the links worked fine but failed after a while. The solder I used was standard rosin, not the water soluble type. I've replaced both connectors and installed DC blocks at both of the wavelan boards. The link has worked fine now for three days. Just thought I'd pass that along. Looks like its a good idea to install DC blocks on Wavelan boards, or so it appears to me. -Jeff wb8wka From djk@tobit.co.uk Thu Mar 13 16:07:01 1997 Received: from dirku.tobit.co.uk (dirku.demon.co.uk [158.152.30.189]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id QAA08663 for ; Thu, 13 Mar 1997 16:06:57 -0600 (CST) Received: (qmail 18427 invoked by uid 500); 13 Mar 1997 22:06:27 -0000 Date: Thu, 13 Mar 1997 22:06:27 +0000 (GMT) From: Dirk Koopman Reply-To: djk@tobit.co.uk To: ss@tapr.org Subject: shannon limits Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This may not appear to be on subject, but in a funny way it may at least interesting if not directly relevant, anyway... As some of you may have noticed US robotics have introduced a modem which appears to able to achieve information transfer speeds of 57600 bps in one direction and (AFAIK) back channel speeds of 14400 bps. Now add to the undoubted existence of modems capable of 33600 bps in both directions - where does this put the Shannon limit for a phone line (qv ANY channel) which is I believe a TOTAL max data rate of 30000 bps? Confused of Dereham (Norfolk, UK) -- Dirk-Jan Koopman Tel/Fax: +44 1362 696076 Mobile: +44 973 333806 Computer Consultant Email: djk@tobit.co.uk or G1TLH@GB7TLH.#35.GBR.EU "The typewriting machine, when played with expression, is no more annoying than the piano when played by a sister or near relation." --Oscar Wilde From wa4dsy@wa4dsy.radio.org Thu Mar 13 18:37:13 1997 Received: from wa4mei.radio.org (wa4mei.radio.org [206.28.192.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id SAA16174 for ; Thu, 13 Mar 1997 18:37:11 -0600 (CST) Received: by wa4mei.radio.org (/\==/\ Smail3.1.28.1 #28.8) id ; Thu, 13 Mar 97 19:37 EST Message-Id: From: "Dale Heatherington" To: "ss@tapr.org" Date: Thu, 13 Mar 97 19:37:06 Reply-To: "Dale Heatherington" Priority: Normal X-Mailer: Dale Heatherington's Registered PMMail 1.53 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [SS:1164] shannon limits On Thu, 13 Mar 1997 16:10:57 -0600 (CST), Dirk Koopman wrote >As some of you may have noticed US robotics have introduced a modem which >appears to able to achieve information transfer speeds of 57600 bps in one >direction and (AFAIK) back channel speeds of 14400 bps. Now add to the >undoubted existence of modems capable of 33600 bps in both directions - >where does this put the Shannon limit for a phone line (qv ANY channel) >which is I believe a TOTAL max data rate of 30000 bps? If found guilty of violating physical laws I hope they will be severly punished. No, really. I think they depend on some small percentage of phone lines being better than average to support 56k. Most users will not get that kind of throughput. -------------------------------------------------- Dale Heatherington, WA4DSY e-mail - wa4dsy@wa4dsy.radio.org e-mail - daheath@ibm.net (in case the first one doesn't work) Web page - http://www.wa4dsy.radio.org OS/2 Warp 4.0 The worlds finest desktop OS. From karn@qualcomm.com Thu Mar 13 20:33:04 1997 Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA21334 for ; Thu, 13 Mar 1997 20:33:00 -0600 (CST) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id SAA22137; Thu, 13 Mar 1997 18:32:28 -0800 (PST) Date: Thu, 13 Mar 1997 18:32:28 -0800 (PST) From: Phil Karn Message-Id: <199703140232.SAA22137@servo.qualcomm.com> To: ss@tapr.org In-reply-to: (fred@tekdata.com) Subject: Re: [SS:1159] Re: WT Docket No. 97-12 - Hollow Victory? >How is the power control going to apply in systems that are not point >to point? Maybe I'm confused but if there is a "broadcast" mode or This is the one valid concern I've heard so far. The logical answer is to say that the limit applies at the intended receiver where the signal is the weakest. Having said that, I should point out that traditional broadcasting has always been rather wasteful of spectrum, and that broadcasting with spread spectrum is even more so. It would be much more efficient to multicast to that subset of stations who actually want to hear your broadcast, and to build a spanning tree on top of store-and-forward links between neighboring nodes. The Internet MBONE works much in this way. So even in a SS "broadcasting" environment, power control would (or should) still be important. Phil From karn@qualcomm.com Thu Mar 13 21:45:10 1997 Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id VAA25019 for ; Thu, 13 Mar 1997 21:45:08 -0600 (CST) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id TAA22327; Thu, 13 Mar 1997 19:44:37 -0800 (PST) Date: Thu, 13 Mar 1997 19:44:37 -0800 (PST) From: Phil Karn Message-Id: <199703140344.TAA22327@servo.qualcomm.com> To: ss@tapr.org In-reply-to: (message from Julian Fields on Thu, 13 Mar 1997 12:14:20 -0600 (CST)) Subject: Re: [SS:1160] Re: George Gilder on CDMA >Assuming the requirement for dead space between >channels in FDMA would account for 20% and another >20% due to dead space in TDMA, this would give >a 40% increase, not 3 to 6 times. Where does the >further improvment come from? The improvements come from a variety of sources. Eliminating guard bands and times is only part of it. Another is the variable rate vocoder that's easy to implement in CDMA, difficult or impossible in TDMA and FDMA. The typical voice user only speaks 40% of the time, so this yields an additional 2:1 improvement. But the big gain comes from the 1:1 cellular frequency reuse pattern that CDMA makes possible. FM requires a C/I (carrier to interference) ratio of at least 17dB for decent performance, which in practice means a 7:1 reuse pattern (only 1/7 of the total channels are used in any one cell). In some difficult areas, even worse ratios have to be used. But CDMA can operate with a *negative* C/I of about 6 - 22 = -16 dB. +6 dB is the approximate Eb/N0 requirement of the modulation and coding scheme in fading, and 22 dB is the process gain of the spreading. I.e., you can maintain a +6dB Eb/N0 at the demodulator for a C/I ratio of -16 dB or better. This is what allows you to reuse the same 1.25 MHz frequency channel in every cell, and it's the single biggest factor in CDMA's capacity gain. Phil From karn@qualcomm.com Thu Mar 13 22:14:34 1997 Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA26388 for ; Thu, 13 Mar 1997 22:14:32 -0600 (CST) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id UAA22369; Thu, 13 Mar 1997 20:14:01 -0800 (PST) Date: Thu, 13 Mar 1997 20:14:01 -0800 (PST) From: Phil Karn Message-Id: <199703140414.UAA22369@servo.qualcomm.com> To: ss@tapr.org In-reply-to: <33285EE9.3545@sprintmail.com> (rmccabe@sprintmail.com) Subject: Re: [SS:1162] Re: WT Docket No. 97-12 - Hollow Victory? >a. Mobile Applications. How often does one adjust power levels to >compensate for varying path losses? Is a full duplex path needed so >that the sending end can be notified that received levels are too high >or low? IS-95 CDMA uses two methods in combination: an open-loop scheme (looking at the receiver AGC) and a closed loop scheme (the cell sends delta-mod power up/down commands to the mobile at an 800 Hz rate). This is sufficient for freeway speeds on the 1.9 GHz PCS bands. I note that for packet data applications, the power control doesn't have to be so fast if you send large packets and code and interleave over the whole packet. Bursts of noise and interference (e.g., caused by imperfect power control) that are "short" compared to the packet will be corrected by the decoder. >b. What power does one use on an initial transmission? An estimate based on the open-loop (AGC) measurement. >c. If three or more parties were involved with a connection the power >control protocol would have to look for the receiving station with the >lowest received signal level. What if this round table included a >number of mobiles? True. As I said in an earlier message this afternoon, transmitting simultaneously to all receivers is not necessarily the most efficient way to go, especially if those receivers are sparsely distributed. >d. Since the receiving station must transmit the measured Eb/ (NO + IO), >this automatic power control essentially prohibits one way broadcasts >unless broadcasting station power is under 1 watt. No, it only says that the power must be controlled so that the Eb/(No+Io) limits are not exceeded. It doesn't say that there has to be explicit feedback, though that's certainly one way to implement it. >e. How can the FCC monitor or enforce this rule? Since this has to be How does the FCC monitor or enforce any rule? (I think it's safe to say that today, they don't). Seriously, it's one of those things where if one isolated person doesn't comply but doesn't cause any trouble, nothing is likely to happen. But if somebody causes real problems, or if non-complying equipment becomes widespread, the FCC (not to mention the rest of the amateur community) will hear about it. >f. The Notice of Proposed Rule Making (Docket 97-12) simply states that >“Average transmitter power over 1 W shall be automatically adjusted to >maintain an Eb/ (NO + IO) ratio of no more than 23 dB at the intended >receiver”. There is no specification of the time period used to >calculate the average, how often the receiving station has to make the >measurements or if the receiving station has to notify the sending >station immediately or on its next transmission. This was deliberately omitted, because I wanted to make sure there was enough flexibility to cover varying circumstances (such as the mobile operation). Clearly, if you implement a system that has power control, the time constant will be a parameter that can be tuned. And I can't conceive of a system design that would create much of an incentive to cheat on this parameter. Phil From karn@qualcomm.com Thu Mar 13 22:48:37 1997 Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA28507 for ; Thu, 13 Mar 1997 22:48:35 -0600 (CST) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id UAA22572; Thu, 13 Mar 1997 20:48:03 -0800 (PST) Date: Thu, 13 Mar 1997 20:48:03 -0800 (PST) From: Phil Karn Message-Id: <199703140448.UAA22572@servo.qualcomm.com> To: ss@tapr.org In-reply-to: (message from Dirk Koopman on Thu, 13 Mar 1997 16:10:57 -0600 (CST)) Subject: Re: [SS:1164] shannon limits >where does this put the Shannon limit for a phone line (qv ANY channel) >which is I believe a TOTAL max data rate of 30000 bps? Obviously a "phone line" has a Shannon limit above 30,000 bps. You have to define what you mean by "phone line". If you mean only the wire pair between your house and the telephone company, the capacity is potentially much greater than this. ISDN uses 1985 technology to routinely transmit 144 kb/s (two 64kb/s B-channels, a 8kb/s D-channel and a 8kb/s hardware control and framing channel) full duplex (i.e., 144 kb/s each way, simultaneously) over single copper telephone pairs up to 18,000' long. T-1 line drivers have done 1.5 Mb/s over pairs up to 5000-6000' since the early 1960s. And ADSL, if it ever arrives, promises several megabits/sec, depending on distance. So if by "phone line" you mean a conventional *dialup voice* connection, the bottleneck is not in the access line, but at the central office. In nearly all modern digital switches the signals on the access line are digitized at 64kb/s as soon as they enter the switch, and they are switched and transmitted digitally at this rate. So obviously *any* modem designed for use over such a circuit could not possibly achieve a unidirectional throughput greater than 64kb/s (compression does not count). The recently developed USR and Motorola high speed modems come awfully close to this 64kb/s limit through some good trickery, but they don't exceed it. Phil From karn@qualcomm.com Thu Mar 13 22:54:35 1997 Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA28869 for ; Thu, 13 Mar 1997 22:54:32 -0600 (CST) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id UAA22582; Thu, 13 Mar 1997 20:54:01 -0800 (PST) Date: Thu, 13 Mar 1997 20:54:01 -0800 (PST) From: Phil Karn Message-Id: <199703140454.UAA22582@servo.qualcomm.com> To: ss@tapr.org In-reply-to: (wd5ivd@tapr.org) Subject: Re: [SS:1156] Re: Eb/(No+Io) >could be instances where power control is not practical....such as >EME....or maybe SS gets used to communicate to the amateur Mars mission ? >1 watt probably isn't enough for either for those modes ? Power control is entirely practical in EME. Why shouldn't it be? It *is* true that the 100W limit may become an obstacle in deep space communications. I'd like to see a waiver of this limit, particularly for deep space operations where the ranging ability of SS is especially useful. >Wouldn't you want to transmit the minimum amount of power needed up to the >allowable limit within the hobby for the type of communications happening. >Which Bob Nielson and some others have pointed is already covered in the >rules. Which are honored mainly in the breach. >Power control is important, but does it need to be specifically mentioned >in the SS section of the rules ? If SS is to be considered a mode like any I agree, this is still a good question. The real issue is whether we need it to get the consent of the weak-signal, repeater and satellite guys. You know how hard this has been even with the proposed power control requirement. If you think you can get the FCC to approve the SS rules *without* the power control requirement, do so by all means. >I think a more pressing issue will concern getting in-band ID accepted via >the data stream transmitted. Just like packet and any of the othe digital I agree. At the very least, if we must ID, it should not interfere when the SS signal itself would not. >Also, of a more pressing issue is the frequency coverage. There will be >demand to use SS systems below what the current rules allow. I think we Yes. Given that the current NPRM proposes no additional SS bands, the original concession of proposing automatic power control doesn't buy us much, does it? How about a compromise -- no automatic power control required on 70cm and up (where SS is already legal) but it is required for SS on the lower bands. And since there is no Part 15 equipment for those bands, there would be no need for a 1W grandfather limit -- which is arguably too generous anyway. Phil From dej@edge.net Thu Mar 13 23:38:06 1997 Received: from edge.edge.net (root@edge.edge.net [199.0.68.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id XAA01690 for ; Thu, 13 Mar 1997 23:38:04 -0600 (CST) Received: from sleepy (s25-pm02.tnstate.campus.mci.net [205.219.190.84]) by edge.edge.net (8.7.5/8.7.3) with SMTP id XAA02487 for ; Thu, 13 Mar 1997 23:38:01 -0600 (CST) Message-Id: <1.5.4.32.19970314053300.006c293c@edge.net> X-Sender: dej@edge.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Mar 1997 23:33:00 -0600 To: ss@tapr.org From: Eric Johnson Subject: Re: shannon limits At 06:40 PM 3/13/97 -0600, you wrote: >On Thu, 13 Mar 1997 16:10:57 -0600 (CST), Dirk Koopman wrote > >>As some of you may have noticed US robotics have introduced a modem which >>appears to able to achieve information transfer speeds of 57600 bps in one >>direction and (AFAIK) back channel speeds of 14400 bps. Now add to the >>undoubted existence of modems capable of 33600 bps in both directions - >>where does this put the Shannon limit for a phone line (qv ANY channel) >>which is I believe a TOTAL max data rate of 30000 bps? > >If found guilty of violating physical laws I hope they will be severly punished. > >No, really. I think they depend on some small percentage of phone lines >being better than average to support 56k. Most users will not get that kind >of throughput. It based upon the fact that the service provider must have digital lines (ie T1 or ISDN) feeding a bank of 'DIGITAL' modems (oxymoron?). This makes your local loop the only analog circuit. The distortions in a single digital/analog conversion can be better compensated for than an analog/digital/analog signal conversion. So in effect they are changing the S/N ratio in Shannon's equation. Whenever you think it is as fast as it will go they change the rules. The December 96 IEEE Communications magazine has the details. Most users should expect speeds at about 48k. --Eric dej@edge.net From wd5ivd@tapr.org Fri Mar 14 01:29:48 1997 Received: from [208.134.134.40] ([208.134.134.40]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id BAA14056 for ; Fri, 14 Mar 1997 01:29:43 -0600 (CST) Message-Id: In-Reply-To: <199703140454.UAA22582@servo.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Mar 1997 01:28:24 -0600 To: ss@tapr.org From: "Greg Jones, WD5IVD" Subject: Re: [SS:1170] Re: Eb/(No+Io) Hi Phil. >>Power control is important, but does it need to be specifically mentioned >>in the SS section of the rules ? If SS is to be considered a mode like any > >I agree, this is still a good question. The real issue is whether we >need it to get the consent of the weak-signal, repeater and satellite >guys. You know how hard this has been even with the proposed power >control requirement. If you think you can get the FCC to approve the >SS rules *without* the power control requirement, do so by all means. Well, it is going to depend on the many of us that filed before and those that can get involved now making sure that we file well written and informed comments and future reply comments making the points regarding expanded freq operations, IDing issues, and power control. The FCC will then look over all the comments. As can be seen in the current docket, the well written technical comments filed -- by many of the group here -- went to make up the current wording. Those comments that seemed xenophobic in nature were added to the record, but didn't truly effect the current wording in the docket presented. I believe that the comments filed by those against SS as a mode by other elements of the hobby itself (strange -- but that is another topic for discussion) would have still been filed the same way with or without the power control issues being included. Power is just one point on the ranges of issues regarding their fear of this mode. The wording about Eb/No which came from the FutSys meeting in Dallas at the DCC and later discussion was in the ARRL request and the current Docket. Those against SS for the most part don't care about the technical issues -- they just don't want the mode given expandability to be made into a real operational mode. Power control is in the docket as a bone to the Part 15 companies and to a lesser extent some within the amateur community in reagrds to potential interference that may or may not ever be generated. >>I think a more pressing issue will concern getting in-band ID accepted via >>the data stream transmitted. Just like packet and any of the othe digital > >I agree. At the very least, if we must ID, it should not interfere when >the SS signal itself would not. > >>Also, of a more pressing issue is the frequency coverage. There will be >>demand to use SS systems below what the current rules allow. I think we > >Yes. Given that the current NPRM proposes no additional SS bands, the >original concession of proposing automatic power control doesn't buy us >much, does it? > With docket 97-12, this is our opportunity to get everything we need or want on the table. These being the Freq issue (50Mhz and up at least), the ability to ID in-band in the data stream, and the issue involved with power control. In regards to power control. I guess my only concern is the setting of some arbitrary limit. Things change and this is suppose (in theory) to be an experimental hobby. If we set power control limits in the rules now, we will have them for a long time. Are we REALLY sure what we are getting in the rules is what we REALLY want ? While there might be no problems with the limits set, there might be serious problems encountered in 5 years that would then not be able to be gotten around. Trying to change the rules on this issue in a few years will not be an option. What does "(g) The transmitter power output must not exceed 100 W under any circumstances. If more than 1 W is used, automatic transmitter control shall limit output power to that which is required for the communication. This shall be determined by use of the ratio, measured at the receiver, of the received energy per user data bit (Eb) to the sum of the received power spectral densities of noise (No) and co-channel interference (Io). Average transmitter power over 1 W shall be automatically adjusted to maintain an Eb/(No+Io) ratio of no more than 23 db at the intended receiver . " mean in communications systems we could make operational tomorrow ? Will this add additional cost to something that AMRAD, AMSAT, or TAPR might do as to make it not cost effective to implement to allow amateurs to get involved in some common project -- although another means of power control could be implemented that works as well, but wouldn't meet the rules as outlined ? Does this mean that we will be limited to certain technology (hardware implementations) which implements what we need to determine this -- but what happens in 2-5 years when the technology move forwards to such an extent (single chip solutions for commercial applications) that we might not have access to the information anymore to make this work ? and can't afford to get custom stuff rolled to implement what we need. The problem we seem to have in amateur radio whenever there is a rulemaking process to try to simplify the rules -- we get more rules added. We need to have the simplest rules possible so as to allow the greatest flexibility in the hobby for what people want to design and experiment with. Having the greatest flexibility in the rules will stop people like yourself, Jeff, or even myself from saying -- we could always abandon Part 97 for some other rules area ? Right ? Hasn't the restricition imposed by various parts of the rules caused this to be said ? Why limit us now when we have the chance to make things simple again and to help advance a major area of the hobby's potential future ? We are changing for the most part from a communicators hobby back into more of a technical, experimental, and skilled operational hobby over the next ten years. I have written a lot in the PSR about my feelings on this issue -- so I will not take up bandwidth here -- but the point being that any rules we ask for need to be the simplest possible so that they are the most flexible in the future. The FCC has stated that they plan on issuing fewer and fewer STAs in the future. Getting the current TAPR STA was a long process with a lot of resistance in some parts of the FCC as to it be granted. Part 5 rules are being re-written in order to make it more flexible, but will the eventual rules changes be of benefit to our hobby ? I don't know, because a lot of it is being focused on commercial operational flexibility for testing systems. We better not depend on STAs or other mechanisms in the future to be able to implement systems that are required to expand our hobby. >How about a compromise -- no automatic power control required on 70cm and >up (where SS is already legal) but it is required for SS on the lower >bands. And since there is no Part 15 equipment for those bands, there >would be no need for a 1W grandfather limit -- which is arguably too >generous anyway. Okay. Let's think about this. Why have an above 1 watt power control limit in one part of the spectrum and not the other ? If anything, we agree to the above 1 watt requires power control of some fashion, but why not drop the technical specification on how that power control is determined. If we are transmitting above 1 watt then the radio must have a way to control the power output as to try to use the minimum amount of power to maintain communications. Maybe we just need to ask for power control above 1 watt on bands where the unlicensed Part 15 devices operate ? That would limit the biggest threat (as seen by the Part 15 companies) -- that of amateurs getting Part 15 equipment and jacking the power up without any power control. Isn't that one of the biggest worries from the commercial sector? I can't see them being worried about the number of amateurs that might ever get operational with this mode on their spectrum. Nothing we could do can ever compare to the ever increasing noise and interference problem they are generating for themselves with there own equipment. I can just see in a year or two that TAPR or someone else comes out with a radio that implements something and we get ambushed by the amateur radio appointed 'legal' community, because we do implement power control, but the implementation could be challenged as not strickly following the rules as they are currently put forward. The issue on power control becomes this. We agree that we want power control, but does it indeed need to be in the rules covering SS modes by itself. If SS as a mode must have power control limits then every other mode in amatuer radio should be required to meet the same technical requirements. If it has to be in the rules (for whatever reasons -- to keep people happy, to be a good sharing partner, etc), then does it need to be specified to the extent of technical wording we have in the current rules. Maybe just asking for power control above 1 watt be implemented with the purpose of reducing output power to its minimum and therefore reducing potential interference to other users sharing the same spectrum area ? If we make the unlicensed Part 15 companies happy and then rule making is probably okay -- although personally I don't think any amount of power control is going to make them happy either. Part 15 systems are operating at the bare minimum -- 10-15db processing gain...right ? Any additional signal presence is going to be a problem to some of these systems. One reason they are having problems with each other more then any other service already operating in the same spectrum. They don't want to see more flexible amateur spread spectrum rules, because that will make many of the bands we are under utilizing more attractive for us to implement systems on. The reason being that many of the Part 15 devices really hurt traditional modes we like to use... but if we implement quality SS systems then we shouldn't be bothered by them or us bothering them, thus making certain bands more attractive then they are now. As to power control on other amateur freqs, why ? We have rules that govern interference and power issues. Our license doesn't guarantee us an operating mode or frequency -- does it ? It just allows us to operate different modes on different bands as a hobby. What we want to make sure is that we design systems that are friendly in whatever environments they are operating -- one reason modes and operating practices have changed over time. My last words -- I promise :-) If we implement rules to restrict the people that abide by the rules -- no matter if the restrictions are technically feasible or not -- those that are going to break them will break them no matter what the rules said. They are already breaking the rules, why limit the folks that try their best to follow the spirit of amateur radio, by having additional rules that just say what is already in other parts of the rules ? Thus, the rules need to think about those that are going to build good systems no matter what the rules say, without limiting how that is accomplished beyond general guidelines. Lots to think about. Cheers - Greg ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From djk@tobit.co.uk Fri Mar 14 02:47:41 1997 Received: from dirku.tobit.co.uk (dirku.demon.co.uk [158.152.30.189]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id CAA16702 for ; Fri, 14 Mar 1997 02:47:36 -0600 (CST) Received: (qmail 20672 invoked by uid 500); 14 Mar 1997 08:47:07 -0000 Date: Fri, 14 Mar 1997 08:47:07 +0000 (GMT) From: Dirk Koopman Reply-To: djk@tobit.co.uk To: ss@tapr.org Subject: Re: [SS:1169] Re: shannon limits In-Reply-To: <199703140448.UAA22572@servo.qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 13 Mar 1997, Phil Karn wrote: > >where does this put the Shannon limit for a phone line (qv ANY channel) > >which is I believe a TOTAL max data rate of 30000 bps? > [snip] > So if by "phone line" you mean a conventional *dialup voice* > connection, the bottleneck is not in the access line, but at the > central office. In nearly all modern digital switches the signals on > the access line are digitized at 64kb/s as soon as they enter the > switch, and they are switched and transmitted digitally at this rate. > So obviously *any* modem designed for use over such a circuit could > not possibly achieve a unidirectional throughput greater than 64kb/s > (compression does not count). > Yes, but... a) I thought they were still deliberately limiting AF bandwidth to 300-2700 Hz. Is this still actually the case? (I understood it was). b) as these modems are analog, Nyquist - he say - need at least two samples per cycle to reproduce waveform. What is the underlying baud rate used on these systems? > The recently developed USR and Motorola high speed modems come awfully > close to this 64kb/s limit through some good trickery, but they don't > exceed it. Although the underlying baud rate won't be anything like 32K baud (which definitely wouldn't go thru the analog filters), at first sight 57.6Kbps * 2 = 115.2Kbps (which I know isn't the correct way of looking at it), but I still can't work out how I really should look at it. Not that I shall use one as I am going over to ISDN (invented by BT and then, as usual for Britain, abandoned for others to notice how useful it was!) because I can't be bothered to wait ANOTHER 20 seconds (over and above the 20 odds seconds I currently wait) for the modem to decide that it only wants to connect at 21600 bps... (the Teles ISDN cards in a Linux box work REALLY well, < 3 seconds from dial to full PPP set up @ 64 or 128 Kbps and only STG 79 here which probably means $79 in the US (http://www.teles.de)). But I still would like to know HOW it is done (all commercial secrets kept). Still confused of Dereham.. -- Dirk-Jan Koopman Tel/Fax: +44 1362 696076 Mobile: +44 973 333806 Computer Consultant Email: djk@tobit.co.uk or G1TLH@GB7TLH.#35.GBR.EU "The typewriting machine, when played with expression, is no more annoying than the piano when played by a sister or near relation." --Oscar Wilde From mac@wireless.com Fri Mar 14 03:16:51 1997 Received: from ns1.culver.net (mac@ns1.culver.net [206.13.40.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id DAA19407 for ; Fri, 14 Mar 1997 03:16:49 -0600 (CST) Received: (from mac@localhost) by ns1.culver.net (8.6.12/8.6.12) id BAA19694; Fri, 14 Mar 1997 01:07:29 -0800 Date: Fri, 14 Mar 1997 01:07:29 -0800 (PST) From: Mike Cheponis X-Sender: mac@ns1.culver.net To: ss@tapr.org Subject: Re: [SS:1169] Re: shannon limits In-Reply-To: <199703140448.UAA22572@servo.qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 13 Mar 1997, Phil Karn wrote: > The recently developed USR and Motorola high speed modems come awfully > close to this 64kb/s limit through some good trickery, but they don't > exceed it. Indeed! In fact, a friend says that telco steals the LSB of one of the 8-bit u-law-coded audio samples periodically for signalling, so the Absolute Max data rate through the PSTN is < 64,000 b/s. But to consider what a feat this is, consider that these USR and Motorola modems have to become essentially _inverse_ u-law codecs! They have to carefully probe the channel to measure the codec responses! It's awesome, really... ...until you realize that this DSP MIP-fest is needed because, for whatever reason, the US PSTN is still delivering _analog_ lines from the CO to your home/business, even as everything else in the phone system is digital...sad... ---------------- But, since this list is supposed to be for SS, let me pose this question to the group: How do we obey the power limits proposal in a "broadcast" type SS usage, for example, sending bulletins or with an SS repeater? In the case of the repeater, do we set the power level of the repeater to be high enough for the weakest user in a roundtable? (Else he won't hear what's being repeated!) What do you do when you send "CQ" on SS? Turn the wick up to 100 W and then backoff when somebody answers? --------- And how do you implement my favorite SS application, the Promiscuous Radio: You set a "bit vector" of the kinds of things in which you are interested into your SS radio. For example, you want to talk with (or perhaps more generally, communicate with - because it can be voice, data, video, 3D projection, shared Virtual Reality, etc...) people who are interested in SS EME, 24 GHz contesting, and backpacking, but NOT in HF phone contests or basketweaving...etc. Now, you want to send a "Buddy CQ" from your SS radio with your bit vector, and you want to have your "Enhanced Bit-Vector Squelch" open when a person with the suitable XOR of your and his/her bit vectors is within communications range. (Of course, there may need to be further exchanges between the radios before the paired squelches open, just to do further qualification, as in a hierarchy, but this is just a detail...) So am I allowed to pump 100W into a big antenna during these "Buddy CQ" calls? ----------- I don't have answers, I'm hoping some of our esteemed list members do! 73 -Mike K3MC From RLANIER@mailb.harris.com Fri Mar 14 08:35:22 1997 Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.104.14]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id IAA01831 for ; Fri, 14 Mar 1997 08:35:19 -0600 (CST) Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special version 2.0) id JAA26103; Fri, 14 Mar 1997 09:35:11 -0500 Received: from ccMail by mailb.harris.com (IMA Internet Exchange 1.04b) id 32961f20; Fri, 14 Mar 97 09:34:26 -0500 Mime-Version: 1.0 Date: Fri, 14 Mar 1997 09:33:06 -0500 Message-ID: <32961f20@mailb.harris.com> From: RLANIER@mailb.harris.com (RLANIER) Subject: Confused - again! To: ss@tapr.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Why do we get such a strong response about something that has nothing to do the SS design? I'm refering to the discussion about the Shannon limit using phone line modems. If we are ever going to met the deadline, lets discuss a real, working SS design - one that ALL hams of all technical levels can appreciate. Tony KE4ATO From djk@tobit.co.uk Fri Mar 14 09:33:18 1997 Received: from dirku.tobit.co.uk (dirku.demon.co.uk [158.152.30.189]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id JAA04782 for ; Fri, 14 Mar 1997 09:33:15 -0600 (CST) Received: (qmail 22786 invoked by uid 500); 14 Mar 1997 15:32:40 -0000 Date: Fri, 14 Mar 1997 15:32:40 +0000 (GMT) From: Dirk Koopman Reply-To: djk@tobit.co.uk To: ss@tapr.org Subject: Re: [SS:1175] Confused - again! In-Reply-To: <32961f20@mailb.harris.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 14 Mar 1997, RLANIER wrote: > Why do we get such a strong response about something that has nothing > to do the SS design? I'm refering to the discussion about the Shannon > limit using phone line modems. > > If we are ever going to met the deadline, lets discuss a real, working > SS design - one that ALL hams of all technical levels can appreciate. > > Tony KE4ATO I received this quote in the very next e-mail just after the above. I wonder whether it is a portent or just a delicious coincidence: "Propose to any Englishman any principle or any instrument, however admirable, and you will observe that the whole effort of the English mind is directed to find a difficulty, a defect or an impossibility in it. If you speak to him of a machine for peeling a potato, he will pronounce it impossible; if you peel it before his eyes, he will declare it useless because it will not slice a pinapple." - Charles Babbage. Dirk -- Dirk-Jan Koopman Tel/Fax: +44 1362 696076 Mobile: +44 973 333806 Computer Consultant Email: djk@tobit.co.uk or G1TLH@GB7TLH.#35.GBR.EU "The typewriting machine, when played with expression, is no more annoying than the piano when played by a sister or near relation." --Oscar Wilde From fred@tekdata.com Fri Mar 14 10:41:17 1997 Received: from tekdata.com (vh1-022.wwa.com [205.243.70.23]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA09310 for ; Fri, 14 Mar 1997 10:41:11 -0600 (CST) Received: (from fred@localhost) by tekdata.com (8.6.12/8.6.12) id KAA18750; Fri, 14 Mar 1997 10:43:06 -0600 Date: Fri, 14 Mar 1997 10:43:05 -0600 (CST) From: "Fred M. Spinner" To: ss@tapr.org Subject: Re: [SS:1173] Re: shannon limits In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII As far as the USR 56K modems go: three short comments. USR States: 1. A typical 33.6KBs modem is actually an asymmetrical device, it switches the direction of the pipe depending on demand. So according to USR (3com?) this is how you can pump the 33.6 KB/s over the line. 2. The ISP (or transmitting?) end of the 56K link has to be a digital line, like a T-1 or ISDN. The ISP modem is pure digital, like was stated before this raises the effective S/N in that direction in Shannon's law.. 3. In USR's advertising they state "the modems are capable of 56K thruput, but due to current FCC regulation they are limited to 53K" Caveat Emptor.. Fred M. Spinner, KA9VAW fred@tekdata.com From n3jly@erols.com Fri Mar 14 12:48:39 1997 Received: from smtp1.erols.com (smtp1.erols.com [205.252.116.101]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id MAA16992 for ; Fri, 14 Mar 1997 12:48:37 -0600 (CST) Received: from LOCALNAME (col-as5s48.erols.com [207.172.73.48]) by smtp1.erols.com (8.8.5/8.8.5) with SMTP id NAA15865 for ; Fri, 14 Mar 1997 13:49:16 -0500 Date: Fri, 14 Mar 1997 13:49:16 -0500 Message-Id: <199703141849.NAA15865@smtp1.erols.com> X-Sender: n3jly@pop.erols.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org From: Tony McConnell Subject: Re: [SS:1174] Re: shannon limits >Indeed! In fact, a friend says that telco steals the LSB of one of the 8-bit >u-law-coded audio samples periodically for signalling, so the Absolute Max >data rate through the PSTN is < 64,000 b/s. the LSB is robbed every 8th sample in a system that uses SF(such as D4). in an ESF system that bit is not robbed. 8,000 samples per second, 8 bits per sample, 64,000 bps, one DS0 in Extended Super Frame. From morganb@inetport.com Fri Mar 14 16:12:20 1997 Received: from admin.inetport.com (inetport.com [206.64.12.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA29706 for ; Fri, 14 Mar 1997 16:12:18 -0600 (CST) Received: from mail.inetport.com (as01_17.inetport.com [206.64.12.97]) by admin.inetport.com (8.7.5/8.7.3) with SMTP id QAA25790 for ; Fri, 14 Mar 1997 16:13:39 -0600 (CST) Date: Fri, 14 Mar 1997 16:13:39 -0600 (CST) Message-Id: <199703142213.QAA25790@admin.inetport.com> X-Sender: morganb@inetport.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org From: morganb@inetport.com (Robert B. Morgan) Subject: Re: CWID, Pwr rulemaking IN reply to Greg and Phil, on Power control and CW ID philosophy, also to Mike C. on broadcast mode power control. Upon proofreading, it was so lengthy I split it into 3 parts, this is part 1 and is continued to 2 other files. This chunk is the CWID topic. Possibly this verbage may be useful later on in making up official rulemaking comments, that is one of the thoughts I had in mind in putting this into print. > >>I agree. At the very least, if we must ID, it should not interfere when >>the SS signal itself would not. U beat me to it. I was going to raise the question the other day, as to how much more interference would be generated by the CWID itself, presuming that it would be some sort of narrowband emission in the middle of some SS activity. (Tongue in cheek, I would also ask if it had to follow the existing rule of minimum power to maintain the desired communication. Since it has little or no value, ramp it down about 90 db) >From a practical standpoint, what is the purpose of the CW ID? Presumably it would be to inform someone that an amateur was lurking about on the freq. When in the narrowband environment, like AX25 in the early days, a listener could observe the CWID and possibly correlate it to the presence of a packet signal about the same strength, freq, chirp characteristics, antenna direction, etc, and possibly conclude that the packet signal belonged to the station transmitting the CW ID, since it came from the same transmitter and probably the same modulator, particularly if it was implemented as AFSK. In the SS environment, there will be little or no correlation between a presumed narrowband CWID and whatever SS is being sent. In the case of the chipset radios, it probably wouldn't even be coming from the same transmitter. So what's the value, other than to transmit a narrowband ID? And then accept the added interference it causes. (Really it just sounds like a roadblock to us). On a cost/benefit analyis, it would appear to fail for total lack of any conceivable benefits, and at a conceivable added cost of adding parallel narrowband transmitters to the SS gear, while reducing throughput. Related question: who is going to be listening for it? Probably nobody. For that matter one might be hard pressed to even find a radio for some of these frequencies that included an audio chain and speaker that would recover conventional analog modulation that could copy CW, and then you have to worry about format: A1, F2, etc.... And I won't even touch the question as to how many CW ops we may have nowadays that could read it. Maybe if we get stuck with it, we can transmit it at 115kB or whatever, computers can copy CW if programmed to do so. We have been down this road before. I ran CWID on my TNC1 for awhile. I don't recall of hearing of a single instance where it was found to be useful to anyone at anytime, ever. It certainly took extra work to implement. It certainly did interrupt routine higher speed packet during the time it was being transmitted. I think we have to draw on this history as an argument to delete this requirement. I think that our response to this issue has to be based on 1) history of its use in the AX25 environment and 2) cost/benefit. This isn't to say that identification isn't necessary. It ought to be a part of the datastream, as we now think of it on packet or any other mode. If you can intrepret the modulation, you ought to be able to recover an ID. If you can't intrepret the modulation, then either you don't even know it is there in the background and don't have any reason to investigate it, or you are undergoing such an extreme case of QRM that you need to locate it as an interference source. Amateurs have various techniques to locate interference. Most of the good ones are best suited to narrowband sources, SS direction finding is not really developed in the amateur bands. I was hoping to make this one of my goals under the STA, but the infrastructure hasn't got off the ground. Frankly, if I had to "locate" a Freewave, I would probably have to be in the same room with it. I did perform antenna range testing with one, but it had to be locked in the continuous transmit mode to do so, at which time I could "locate" it within the back yard. Good SS really is unobtrusive. I think that is how we have to sell it. As for actually being able to copy in-stream ID, which I think would be desireable for amateur uses, I suspect it may be difficult to eavesdrop with the common chipsets that may be available, since they are aimed at a mass market of private communications. Unless you know the spreading codes at the least, you won't be able to recover the modulation. So even here, we have to be careful about requiring it be available. If we can't find economical means of doing it, how can we write rules to require it? Continued next msg with power issues. Bob Morgan WB5AOH Austin Texas morganb@admin.inetport.com From morganb@inetport.com Fri Mar 14 16:12:25 1997 Received: from admin.inetport.com (inetport.com [206.64.12.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA29727 for ; Fri, 14 Mar 1997 16:12:22 -0600 (CST) Received: from mail.inetport.com (as01_17.inetport.com [206.64.12.97]) by admin.inetport.com (8.7.5/8.7.3) with SMTP id QAA25799 for ; Fri, 14 Mar 1997 16:13:44 -0600 (CST) Date: Fri, 14 Mar 1997 16:13:44 -0600 (CST) Message-Id: <199703142213.QAA25799@admin.inetport.com> X-Sender: morganb@inetport.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org From: morganb@inetport.com (Robert B. Morgan) Subject: Re: power control rulemaking Continued from last msg, re: Greg and Phil's conversation, (2/3) Now for power control, and I would like to make the case for a very broad rule, preferably keeping the existing rule we have now, the minimum power necessary rule. Personally I think that the existing power control rule is sufficient for regulatory purposes. Certainly I favor the use of auto power control where it is appropriate. I have seen lots of cases on 9600b packet in trying to keep trunks on dedicated channels operational, during band openings throughput actually gets worse, and power control would probably help. > >With docket 97-12, this is our opportunity to get everything we need or >want on the table. These being the Freq issue (50Mhz and up at least), the >ability to ID in-band in the data stream, and the issue involved with power >control. > >In regards to power control. I guess my only concern is the setting of >some arbitrary limit. Things change and this is suppose (in theory) to be >an experimental hobby. If we set power control limits in the rules now, we >will have them for a long time. Are we REALLY sure what we are getting in >the rules is what we REALLY want ? While there might be no problems with >the limits set, there might be serious problems encountered in 5 years that >would then not be able to be gotten around. Trying to change the rules on >this issue in a few years will not be an option. > >What does "(g) The transmitter power output must not exceed 100 W under any >circumstances. If more than 1 W is used, automatic transmitter control >shall limit output power to that which is required for the communication. As for 100W, and assuming terrestrial or near-earth satellite uses, I have no problem with a 100W limit. But there are amateurs who engage in EME, and maybe some of them might want to use SS, at least in light of the ranging capabilities and possibly to take advantage of some processing gain. What conceivable objection could there be to an exemption for deep space (lunar and beyond) SS up to the 1 KW limit, as long as directional antennas are used that are pointed out to space? (That probably means rule language specifying antenna pattern and elevation or something). Most if not all of these folks already employ the largest arrays in use now. This also might raise an issue of a new application that hasn't been seen too much: amateur terrestrial radar. (I knew at least one ham about 25 years ago that did acquire some surplus radar gear with the intention of using it as such-I don't know that outcome). >The problem we seem to have in amateur radio whenever there is a rulemaking >process to try to simplify the rules -- we get more rules added. We need >to have the simplest rules possible so as to allow the greatest flexibility >in the hobby for what people want to design and experiment with. Well said. Why do we keep coming up with restrictions on ourselves? Every other lobbyist writes suggested rules with as many loopholes as imaginable. >>How about a compromise -- no automatic power control required on 70cm and >>up (where SS is already legal) but it is required for SS on the lower >>bands. And since there is no Part 15 equipment for those bands, there >>would be no need for a 1W grandfather limit -- which is arguably too >>generous anyway. > > >Okay. Let's think about this. Can we write a rule that makes sense that will require auto power control if and where technically feasible at the time of design of the equipment in use? Possibly relating to all uses, not just SS? And refrain from further technical details? (And I have little comments on the abuses that might exist on 20M SSB DX, other than to say that we have a rule requiring minimum power already). > >Why have an above 1 watt power control limit in one part of the spectrum >and not the other ? > >If anything, we agree to the above 1 watt requires power control of some >fashion, but why not drop the technical specification on how that power >control is determined. If we are transmitting above 1 watt then the radio >must have a way to control the power output as to try to use the minimum >amount of power to maintain communications. > >Maybe we just need to ask for power control above 1 watt on bands where the >unlicensed Part 15 devices operate ? That would limit the biggest threat >(as seen by the Part 15 companies) -- that of amateurs getting Part 15 >equipment and jacking the power up without any power control. Isn't that >one of the biggest worries from the commercial sector? I can't see them >being worried about the number of amateurs that might ever get operational >with this mode on their spectrum. Nothing we could do can ever compare to >the ever increasing noise and interference problem they are generating for >themselves with there own equipment. Sounds good on the surface. The scary thought that popped into my mind when I read it is that suppose we require part 97 to include auto power control wherever part 15 is present. Let that appear in the rules for a year or two, and probably without any adverse consequences. Then along comes some equipment manufacturer's lobby, and proposes some new part 15 systems, and lo and behold they cover every existing amateur band from 160 to light. At that point we might have our whole part 97 effectively closed down for good, stolen right out from under us. So lets be extremely careful. >I can just see in a year or two that TAPR or someone else comes out with a >radio that implements something and we get ambushed by the amateur radio >appointed 'legal' community, because we do implement power control, but the >implementation could be challenged as not strickly following the rules as >they are currently put forward. If we don't write technical requirements, they can't be challenged, at least from a technical standpoint. The "minimum necessary" rule can still work. Obviously some implementations will perform better than others. Those that work better will probably be better accepted. Maybe the really bad implementations would fall into disfavor and would be used less. The "minimum necessary" rule, for the most part, puts the burden of proof of a power abuse violation on an outside observer, not the operator. Hard and fast rules, aside from being inflexible in the face of advances in technology, tend to put the burden of proof on the operator, and may tend to require continual upgrades or modifications, or maybe obsolesences, as technology improves. >If we implement rules to restrict the people that abide by the rules -- no >matter if the restrictions are technically feasible or not -- those that >are going to break them will break them no matter what the rules said. >They are already breaking the rules, why limit the folks that try their >best to follow the spirit of amateur radio, by having additional rules that >just say what is already in other parts of the rules ? Well put. As was pointed out earlier, the FCC isn't enforcing much of anything, at least after the rulemaking and equipment design and approval stage (i.e. field enforcement). That is the old story of the lowest common denominator politics at work: penalize the majority for the ill deeds of some few, where what might be needed is to penalize or correct the ill deeds. I will butt heads with that type of politics to my last day on earth. Anyhow it is stupid to write more rules in response to the violations of existing rules that have not been enforced, but could have been. If it was illegal, then it was illegal whether or not it is made "more" illegal. My considered opinion is to keep the existing rule we have on power control: run the minimum necessary to maintain the desired communication. Unless we can come up with some creative and foolproof language, I wouldn't want to specify any means. This is one field where technology will always outpace rulemaking, and we don't have the funds to routinely support rulemaking lobbying, so we will be stuck with whatever we ask for and receive. Bob Morgan WB5AOH Austin Texas morganb@admin.inetport.com From morganb@inetport.com Fri Mar 14 16:12:29 1997 Received: from admin.inetport.com (inetport.com [206.64.12.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA29746 for ; Fri, 14 Mar 1997 16:12:28 -0600 (CST) Received: from mail.inetport.com (as01_17.inetport.com [206.64.12.97]) by admin.inetport.com (8.7.5/8.7.3) with SMTP id QAA25808 for ; Fri, 14 Mar 1997 16:13:49 -0600 (CST) Date: Fri, 14 Mar 1997 16:13:49 -0600 (CST) Message-Id: <199703142213.QAA25808@admin.inetport.com> X-Sender: morganb@inetport.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org From: morganb@inetport.com (Robert B. Morgan) Subject: Re: broadcast mode power control Now some thoughts on broadcast, etc issued on power control, quoted from: Mike Cheponis >How do we obey the power limits proposal in a "broadcast" type SS usage, >for example, sending bulletins or with an SS repeater? > >In the case of the repeater, do we set the power level of the repeater to >be high enough for the weakest user in a roundtable? (Else he won't hear >what's being repeated!) I don't know any other mechanisms, except that which has already been mentioned of intermediate repeating. Possibly a really, really good broadcast mode power control algorithm would be able to trade off higher power vs. intermediate repeats to the weaker users. More practical would be the existing approach of the weaker station manually specifying a repeater, assuming that the protocol provides the mechanism. A decent system on a repeater or hub, serving for instance 5 users, ought to be running separate power control with each user, if it is sending (and duplicating) point to point data to each. But if it is a broadcast method, it obviously has to provide the power necessary to reach the user experiencing the most loss or noise level. Of course, note the tradeoff between running more average power on a broadcast method, vs the additional time required with multiple point to point links sending, and duplicating data, or vs intermediate repeats. As a few of us have already discovered in using the STA Freewave radios, BROADCAST modes are going to perform much different than the point to point modes, and our experience so far has been that there is a LOT of improvement required in this area. They really didn't work worth a hoot. This issue is one of them. (The Freewave radios didn't implement power control as far as I could see on the wattmeter-scope. At 400 mW they probably weren't forced to, aside from the issue of it being desireable at most times). Since hams use broadcast modes like CQ's and roundtables, and quite a few legitimate net uses need broadcast modes, like files of common interest, network routing, etc., we want to leave room in our rules to provide for their use. These rules simply must NOT be written with point-to-point mechanisms in mind, since point to point mechanisms are inherently unsuited to broadcast type modes. The governing factor must be to minimize interference and facilitate communications, not just implement point to point algorithms. Broadcast modes are probably of more use to amateurs than the general clientale of commercial SS, but it isn't exclusive to us. However this is an area where we might be able to make original contributions to the state of the SS art. There is a lot of room for improvement here. > >What do you do when you send "CQ" on SS? Turn the wick up to 100 W and then >backoff when somebody answers? Under the existing rule of running the minimum power to maintain communications, that is how I intrepret it under some circumstances. Almost any scheme I can imagine, including existing amateur practice using manual means that we have been used to for years, suggests that if there are signals on the band, and your CQ isn't responded to with 1W, then try 10, or 100, or 1000. If the band was dead, then it takes one CQ by somebody, for anybody to notice that the band has come back to life, so everybody hops back on the air. There are probably some open loop means of power control, but most algorithms have to be based on the principle of turning it up high enough to establisn contact (usually a shorter duration process) and making measurements and adjusting based on those measurements. The "better" ones are probably going to continue the adjustment process on every transmission, where it really counts during the high duty cycle part of the file fransfers and the like. Most digital CQ's are by nature going to be extremely short transmissions, just the bare minimum to get the transmitter on the air, and allow the sync mechanisms to work, and send a little bit of ID data. They aren't exactly large file transfers. It ought to be remembered that the undesireable effects of interference are manifested by interference over time. The shorter and less frequent the transmission, the less QRM it causes. I can certainly confirm that aspect experimentally from a qualitative viewpoint from playing with the Freewave radios a little. >So am I allowed to pump 100W into a big antenna during these "Buddy CQ" calls? I would certainly think so, unless we write language to the contrary. There is one more fly in the ointment: multipath. If present, more power does no good. You simply are competing with your own signal. The algorithms that measure Eb/No+Io had better be capable of spotting the difference, else they will just ramp up to max and stick there. I suspect that this problem has been solved already, we just have to remember to use algorithms that have solved it. It never enters into our old voice analogies of amateur operating. It only adversely affects data, and maybe ATV. Remember, the FCC doesn't do much monitoring any more. The person that is in the best position to judge as to how much power to run is the operator himself. Or better still his auto-power control algorithm. Any other outside observer isn't subject to the same set of conditions (i.e. the FCC monitoring van parked out front might not be measuring the QRM caused remotely by a neighbors cordless phone or leaky microwave oven that is causing our hypothetical operator's algorithm to have to turn up the juice to overcome it). There isn't going to be any field enforcement unless it is an extreme case, first because they are about out of that business, and second because you need good proof to disprove the operators judgement. Bob Morgan WB5AOH Austin Texas morganb@admin.inetport.com From karn@qualcomm.com Fri Mar 14 18:00:51 1997 Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA06391 for ; Fri, 14 Mar 1997 18:00:48 -0600 (CST) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id QAA26972; Fri, 14 Mar 1997 16:00:17 -0800 (PST) Date: Fri, 14 Mar 1997 16:00:17 -0800 (PST) From: Phil Karn Message-Id: <199703150000.QAA26972@servo.qualcomm.com> To: ss@tapr.org In-reply-to: <199703141849.NAA15865@smtp1.erols.com> (message from Tony McConnell on Fri, 14 Mar 1997 12:49:03 -0600 (CST)) Subject: Re: [SS:1178] Re: shannon limits >the LSB is robbed every 8th sample in a system that uses SF(such as D4). in an >ESF system that bit is not robbed. >8,000 samples per second, 8 bits per sample, 64,000 bps, one DS0 in Extended >Super Frame. This is why 56kb/s became such a popular data rate in the US for leased lines. Rather than figure out which samples have their high order bits robbed, you just toss *all* of the high order bits, leaving 7 bits of each byte for data. 7/8 * 64kbps = 56 kbps. Even with unknown bit robbing phasing you could get back at least part of the difference between 56 and 64kbps by using FEC that treats the robbed bits as errors and corrects them. Phil From rtg@nuge.com Fri Mar 14 22:51:55 1997 Received: from lindy.nuge.com (rtg@p110.a.aa.ic.net [152.160.123.110]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA24948 for ; Fri, 14 Mar 1997 22:51:54 -0600 (CST) Received: from localhost (rtg@localhost) by lindy.nuge.com (8.7.6/8.7.3) with SMTP id AAA07990 for ; Sat, 15 Mar 1997 00:24:01 -0500 X-Authentication-Warning: lindy.nuge.com: rtg owned process doing -bs Date: Sat, 15 Mar 1997 00:24:01 -0500 (EST) From: Richard Green To: ss@tapr.org Subject: Re: [SS:1179] Re: CWID, Pwr rulemaking In-Reply-To: <199703142213.QAA25790@admin.inetport.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 14 Mar 1997, Robert B. Morgan wrote: > ... I was hoping to make this one > of my goals under the STA, but the infrastructure hasn't got off the > ground. Frankly, if I had to "locate" a Freewave, I would probably have > to be in the same room with it. I did perform antenna range testing with > one, but it had to be locked in the continuous transmit mode to do so, > at which time I could "locate" it within the back yard. Good SS really > is unobtrusive. I think that is how we have to sell it. It can be done... I seem to remember an article many years ago in the AMRAD journal, back when they were experimenting with FHSS, about an SS hidden transmitter hunt they held in the D.C. area. The local FCC field office sent some of their field engineers to join in the fun, and they won it hands down! So much for the amateurs 'leading the technology'. The FCC boys had no trouble finding the hop codes and sync'ing clocks, even though they started the chase with less information about the target than the club members had been given! Richard Green Ann Arbor, MI From jeff@mich.com Sat Mar 15 00:04:13 1997 Received: from server1.mich.com (root@server1.mich.com [198.108.16.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id AAA01716 for ; Sat, 15 Mar 1997 00:04:11 -0600 (CST) Received: from gw-aerodata.mich.com (gw-aerodata.mich.com [198.108.16.60]) by server1.mich.com (8.8.4/8.8.4) with SMTP id BAA21828; Sat, 15 Mar 1997 01:05:10 -0500 Message-Id: <2.2.32.19970315060328.00d5c2ac@mail.mich.com> X-Sender: jeff@mail.mich.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 15 Mar 1997 01:03:28 -0500 To: ss@tapr.org, ss@tapr.org From: Jeff King Subject: Re: [SS:1183] Re: CWID, Pwr rulemaking At 10:55 PM 3/14/97 -0600, Richard Green wrote: > It can be done... I seem to remember an article many years ago in the >AMRAD journal, back when they were experimenting with FHSS, about an SS >hidden transmitter hunt they held in the D.C. area. The local FCC field >office sent some of their field engineers to join in the fun, and they won >it hands down! So much for the amateurs 'leading the technology'. The >FCC boys had no trouble finding the hop codes and sync'ing clocks, even >though they started the chase with less information about the target than >the club members had been given! > >Richard Green >Ann Arbor, MI > Hiya Rick! You can find references to these tests in the ARRL spread spectrum compendium. Look on pages 7-6, 8-8 and 8-26. One of the complaints the FCC agents had was they would have taken less then 25 minutes to find them if traffic had not been so heavy! One might want to mention these tests in filings on the NPRM in objection to the CWID. -Jeff From lfry@mindspring.com Sat Mar 15 06:26:26 1997 Received: from mule0.mindspring.com (mule0.mindspring.com [204.180.128.166]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id GAA20902 for ; Sat, 15 Mar 1997 06:26:25 -0600 (CST) Received: from glory (user-168-121-136-107.dialup.mindspring.com [168.121.136.107]) by mule0.mindspring.com (8.8.5/8.8.4) with SMTP id HAA52710 for ; Sat, 15 Mar 1997 07:26:23 -0500 Message-Id: <2.2.32.19970315122929.00387e94@mindspring.com> X-Sender: lfry@mindspring.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 15 Mar 1997 07:29:29 -0500 To: ss@tapr.org From: "Lee W. Fry" Subject: Re: [SS:1181] Re: broadcast mode power control To continue the thought process: One of the potential applications that could be implemented in spread spectrum is a replacement for the existing channelized narrow-band FM repeater systems used by amateur operators today. Such a system would operate similar to the existing FM NB repeaters, but be implemented with SS. "Channelization" would be implemented by use of orthogonal spreading codes. An example of such a system could probably be easily prototyped today using 900MHZ SS cordless phone components. The proposed automatic power control requirement would not allow the operation of such a system. The existing FM repeater systems operate under the minimum necessary power ruling. They correctly presume the power required is that needed to provide adequate signal strength in their coverage area. Operating this way, if there are only near-by users, they are using more power than would be required by the rules. However, there may be a distant third user, at the limits of the coverage, hidden from the near-by users, wanting to join the exchange, so power must be sufficient to provide adequate signal strength at his location so the distant operator knows when to transmit. The voice repeater system is CDMA in the sense that the operator detects carrier and keys up when it is gone. However, in the proposed ruling, transmit power is dependent on received signal strength. In the example above, if the repeater were using only enough power to maintain communications with the near-by operators, the distant operator would not be able to detect the on-going exchange and could interfere with it when he transmits. Therefore, a more workable ruling would be to not add a new rule governing SS modes, but to allow SS modes to operate under the existing minimum power necessary rule. Lee W. Fry AA0JP lfry@mindspring.com See my Part 15 Spread Spectrum Device Compendium at: http://www.mindspring.com/~lfry/part15.htm From n5owk@n5owk.ampr.org Sat Mar 15 09:12:31 1997 Received: from n5owk.ampr.org (n5owk.ampr.org [44.78.4.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id JAA28099 for ; Sat, 15 Mar 1997 09:12:27 -0600 (CST) From: n5owk@n5owk.ampr.org Date: Sat, 15 Mar 97 08:10:24 CST Message-Id: <495@n5owk.ampr.org> To: ss@tapr.org Subject: Designing Repeaters in SS Lee has an interesting point there about the current FM NB repeater. It is sure to be a comment in someones reply to the FCC. But I don't favor that design at all. I'm somewhat surprised that with the cheap components available now, even the "damned" paging systems still keep that model. They synchronize those carriers to mere Hz, and link them all together so they cover the whole state with the same data. Just a complete waste of spectrum. With a couple hundred milliwatts the same task can be performed. Using the cellular model, the pager could announce its position (ramp up in power till someone replies). But the Ham repeater was obsolete in the early 80's when trunking was deployed. Real people don't waste spectrum like that anymore. Only a socialist or a communist would favor such a system (the society as a whole pays for the spectrum, so the elite can access for free). There's nothing wrong with a communist or a socialist, but I made a pretty good living killing them in the post-Vietnam wars :-) We're talking very high bandwidth. Undreamed-of bandwidth. To channelize a high power SS radio and continue the low bandwidth model is sheer lunacy. I should be able to put an antenna on the roof, and the device negotiate and resolv a map. This map, using cheap memory could develop a two-dimensional view of the cell. A large city being a large database, a small city producing a small database. The algorithm is to find the smallest number of hops using the least amount of power (some level of latency is completely acceptable). Going one step further, there are probably 10 sites that can reach everyone in the cell (derived through an embedded algorithm) that can easily multicast anything. So for the Party-Line(tm) paradigm of a Ham repeater, it could be duplicated at 1/100th the power. Steve From morganb@inetport.com Sat Mar 15 14:37:15 1997 Received: from admin.inetport.com (inetport.com [206.64.12.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA15948 for ; Sat, 15 Mar 1997 14:37:13 -0600 (CST) Received: from mail.inetport.com (as01_43.inetport.com [206.64.12.123]) by admin.inetport.com (8.7.5/8.7.3) with SMTP id OAA25936 for ; Sat, 15 Mar 1997 14:38:45 -0600 (CST) Date: Sat, 15 Mar 1997 14:38:45 -0600 (CST) Message-Id: <199703152038.OAA25936@admin.inetport.com> X-Sender: morganb@inetport.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org From: morganb@inetport.com (Robert B. Morgan) Subject: Re: CWID, Pwr rulemaking >At 10:55 PM 3/14/97 -0600, Richard Green wrote: > >> It can be done... I seem to remember an article many years ago in the >>AMRAD journal, back when they were experimenting with FHSS, about an SS >>hidden transmitter hunt they held in the D.C. area. The local FCC field >>office sent some of their field engineers to join in the fun, and they won >>it hands down! So much for the amateurs 'leading the technology'. The >>FCC boys had no trouble finding the hop codes and sync'ing clocks, even >>though they started the chase with less information about the target than >>the club members had been given! >> >>Richard Green >>Ann Arbor, MI >> > >Hiya Rick! > >You can find references to these tests in the ARRL spread spectrum >compendium. Look on pages 7-6, 8-8 and 8-26. One of the complaints >the FCC agents had was they would have taken less then 25 minutes >to find them if traffic had not been so heavy! > >One might want to mention these tests in filings on the NPRM in >objection to the CWID. > >-Jeff That's an outstanding example of what can be done with SS. My original example of locating a Freewave in the back yard, was of course done with a narrowband receiver, not any kind of programmable FH gear. (And this very comparison graphically shows again how unobtrusive SS can be made to work, unless you are equipped to receive it, you don't). Sort of makes your mouth water, if you had the programmable chipsets, and the programming, and the hop selection choices on the fly, or probably automated investigation of what was being transmitted by all the SS flying through the air. Once you have that, then of course you can create the actual geographical map of where they all are. What more does one need? Try that with a CW id. That is a LOT less locatable, although it works. (Recall the comparison of a modulated radio wave to a marked yardstick, with the high rates we are looking at with SS, distance measurement gets pretty good indeed. Using a CW ID to identify and presumably track down a station with a datarate that low won't get you much, and to do a good job of ranging it would take lots more work.) I don't have anything against CW, but this isn't an application for it. This thing is just a paradigm out of place. Maybe it is left over from some of the commercial repeater/pager ID stuff, or what I don't know, but it is narrowband technology, and it is at odds within wideband technology. Mixing the two doesn't do anything except add to a mess. I guess maybe someone needs to demo it for the record, while we have a little time under the STA, or in the comments/reply of the rulemaking? 73 de Bob WB5AOH Robert Morgan Austin Texas morganb@admin.inetport.com From lfry@mindspring.com Sat Mar 15 15:36:56 1997 Received: from mule0.mindspring.com (mule0.mindspring.com [204.180.128.166]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id PAA18931 for ; Sat, 15 Mar 1997 15:36:54 -0600 (CST) Received: from glory (user-168-121-136-107.dialup.mindspring.com [168.121.136.107]) by mule0.mindspring.com (8.8.5/8.8.4) with SMTP id QAA82758 for ; Sat, 15 Mar 1997 16:36:51 -0500 Message-Id: <2.2.32.19970315214007.00377458@mindspring.com> X-Sender: lfry@mindspring.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 15 Mar 1997 16:40:07 -0500 To: ss@tapr.org From: "Lee W. Fry" Subject: Re: [SS:1186] Designing Repeaters in SS At 09:14 AM 3/15/97 -0600, in [SS:1186] Steve wrote an interesting ops concept for a SS system. I believe we can hypothesize all sorts of very nice operational concepts with really big benefits. However, keep in mind that the early implementation will have to rely on existing silicon. That's why I used the simple cordless phone derived example. I believe we would be lucky if the US amateur radio service represented enough of a market that someone would develop new silcon just to build devices to meet our rules and operational concepts. Therefore I believe that we must have rules that allow us to use silicon developed for existing commercial SS applications such as cordless phones, part 15.247 WLANS and perhaps the new National Unlicensed Information Infrastructure (I hope I got that acronym right), because anything else is too complex to economically develop and market. I think the only way we could get a unique ham product would be if all countries adopted identical rules. Perhaps then a Kenwood, ICOM, or Yaesu would build something using custom silicon. I don't think that will happen soon. Lee W. Fry AA0JP lfry@mindspring.com See my Part 15 Spread Spectrum Device Compendium at: http://www.mindspring.com/~lfry/part15.htm From darnell@binmedia.com Sat Mar 15 18:22:11 1997 Received: from gumby.binmedia.com ([204.140.236.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA28649 for ; Sat, 15 Mar 1997 18:22:09 -0600 (CST) Received: from [206.117.173.2] by gumby.binmedia.com (post.office MTA v1.9.3 ID# 0-12756) with SMTP id AAA94 for ; Sat, 15 Mar 1997 16:15:08 -0800 Subject: Re: [SS:1188] Re: Designing Repeaters in SS Date: Sat, 15 Mar 97 16:22:11 -0800 x-mailer: Claris Emailer 1.1 From: darnell@binmedia.com (Darnell Gadberry) To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <19970316001508106.AAA94@[206.117.173.2]> On 3/15/97, Lee W. Fry AAOJP wrote: > >At 09:14 AM 3/15/97 -0600, in [SS:1186] Steve wrote >an interesting ops concept for a SS system. > >I believe we can hypothesize all sorts of very nice operational concepts >with really big benefits. However, keep in mind that the early >implementation will have to rely on existing silicon. That's why I used the >simple cordless phone derived example. > >I believe we would be lucky if the US amateur radio service represented >enough of a market that someone would develop new silcon just to build >devices to meet our rules and operational concepts. > >Therefore I believe that we must have rules that allow us to use silicon >developed for existing commercial SS applications such as cordless phones, >part 15.247 WLANS and perhaps the new National Unlicensed Information >Infrastructure (I hope I got that acronym right), because anything else is >too complex to economically develop and market. > >I think the only way we could get a unique ham product would be if all >countries adopted identical rules. Perhaps then a Kenwood, ICOM, or Yaesu >would build something using custom silicon. I don't think that will happen >soon. > > >Lee W. Fry AA0JP >lfry@mindspring.com >See my Part 15 Spread Spectrum Device Compendium at: >http://www.mindspring.com/~lfry/part15.htm > Lee, My engineering company (3 individuals) has built custom silicon for customer projects using our own money. With the current generation of development tools it is not rocket science, nor does it require a NASA sized budget to create VERY complex VLSI designs. Take a look at the MOSIS service homepage : http://www.mosis.org. MOSIS is a US Government supported, University operated (USC), IC fabrication service. They will fabricate silicon for anyone. Starting at $680 per run for packaged devices. Once you have created a successful design using the MOSIS service, you can take your CIF (A standard IC design interchange format) file to any of several dozen IC foundries who would be happy to make chips for you. Some of them would even make as few as 50 devices. I think it is important for us not to limit our options because of perceived barriers. Just a thought... - darnell gadberry ke6ucl binaryMedia Communications darnell@binmedia.com From mne@cmu.edu Sun Mar 16 12:15:33 1997 Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id MAA27996 for ; Sun, 16 Mar 1997 12:15:32 -0600 (CST) Received: from mne (ANNEX-6.SLIP.ECE.CMU.EDU [128.2.236.6]) by cmu1.acs.cmu.edu (8.8.2/8.7.3) with SMTP id NAA07871 for ; Sun, 16 Mar 1997 13:15:29 -0500 Message-Id: <1.5.4.32.19970316181502.0069d834@gauss.ece.cmu.edu> X-Sender: ettus@gauss.ece.cmu.edu X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 16 Mar 1997 13:15:02 -0500 To: ss@tapr.org From: Matt Ettus Subject: Wireless Ethernet comments A lot of people have been talking about using wireless ethernet DS modems. Also, people have commented on them not using power control, so why should we. DS Wireless ethernet is NOT CDMA, it is only DSSS. This means that every unit uses the same spreading sequence. Only one unit may transmit at a time, thus no need for power control, unless you have adjacent cells. DS SS is wasteful of spectrum if one does not use CDMA. Wireless ethernet uses a 11 chip spreading code, thus wasting 11 times the bandwidth necessary. If CDMA was used, more users could transmit at the same time, and the would be no waste. I think it is pointless to base anything on wireless ethernet, as it is wasteful, old technology, and not standardized. If we truly want to use spread spectrum properly, that implies we use CDMA as well, and that implies we do something custom. Matt N2MJI From wd5ivd@tapr.org Sun Mar 16 16:55:38 1997 Received: from [208.134.134.40] ([208.134.134.40]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA13472 for ; Sun, 16 Mar 1997 16:55:35 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 16 Mar 1997 16:50:38 -0600 To: " Spread Spectrum " From: "Greg Jones, WD5IVD" Subject: Another Power Control 97.311 as proposed If the proposed rules say this: 97.311 SS emission types. (a) SS emission transmissions by an amateur station are authorized only for communications between points within areas where the amateur service is regulated by the FCC and between an area where the amateur service is regulated by the FCC and an amateur station in another country that permits such communications. SS emission transmissions must not be used for the purpose of obscuring the meaning of any communication. (b) A station transmitting SS emissions must not cause harmful interference to stations employing other authorized emissions, and must accept all interference caused by stations employing other authorized emissions. (c) Reserved. (d) Reserved. (e) ***** (f) ***** (g) The transmitter power must not exceed 100 W under any circumstances. If more than 1 W is used, automatic transmitter control shall limit output power to that which is required for the communication. This shall be determined by the use of the ratio, measured at the receiver, of the received energy per user data bit (Eb) to the sum of the received power spectral densities of noise (N0) and co-channel interference (I0). Average transmitter power over 1 W shall be automatically adjusted to maintain an Eb/ (N0 + I0) ratio of no more than 23 dB at the intended receiver . ---- which 97.311(b) is the key, and we include the existing rules about using minimum power for communications, do we need the power control rules 97.311(g) on top of all that as well ? This says that we probably need to stay away from the lower parts of the bands (i.e. bandplanning) where weak signal work is happening -- unless we can show a designed system doesn't interfer with these operations. If the people who follow the rules follow 97.311(b) and the other rules which are already on the book, is there anything stopping us from asking for 50Mhz and above becuase we can't interfere with people if we follow the rules (like we are suppose to in the spirit of amateur radio). Isn't 97.311(g) redudent in scope ? Maybe I am missing something here ? Just thinking (or in this case writing) out loud. Cheers - Greg ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From n3jly@erols.com Mon Mar 17 00:07:31 1997 Received: from smtp2.erols.com (smtp2.erols.com [205.252.116.102]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id AAA15279 for ; Mon, 17 Mar 1997 00:07:28 -0600 (CST) Received: from LOCALNAME (col-as1s36.erols.com [207.172.69.36]) by smtp2.erols.com (8.8.5/8.8.5) with SMTP id BAA28031 for ; Mon, 17 Mar 1997 01:07:25 -0500 (EST) Date: Mon, 17 Mar 1997 01:07:25 -0500 (EST) Message-Id: <199703170607.BAA28031@smtp2.erols.com> X-Sender: n3jly@pop.erols.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org From: Tony McConnell Subject: NPRM... in a way doesn't this statement of power controll assume that the path or conditions is known? are they saying we can only use this for point to point work? and meet that criteria? let's include in each of our transmissions a reciptiant in East BF Egypt, and when he can tell us to QRP, we will. This is one man opinion, I could be wrong. N3JLI From wb9mjn@wb9mjn.ampr.org Mon Mar 17 09:05:58 1997 Received: from wb9mjn.ampr.org (wb9mjn.ampr.org [44.72.98.19]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id JAA09189 for ; Mon, 17 Mar 1997 09:05:35 -0600 (CST) From: wb9mjn@wb9mjn.ampr.org Date: Mon, 17 Mar 97 08:33:47 UTC Message-Id: <13240@wb9mjn.ampr.org> To: ss@tapr.org Subject: Re: [SS:1191] Another Power Control 97.311 as proposed In-Reply-To: your message of Sun Mar 16 16:59:46 1997 Hi Greg, Yes, that s right, in a closed loop situation. When both station s know of each other's presence, no problem. Just follow the non-interferance rules. Power control makes sense in the open loop situation. When one or more stations are unaware of the other's presence, or specific circumstance. One cannot know who is listening to what when, and where from, all the time, of course. The 1 watt limit still gives us advantage over Part 15, which have a 4 watt ERP limitation. So, there really is no worry about being competitive with Part 15, with the power limitations. NB ID'ing is the BIG issue, I think. It neccassitates a backward looking, and unfair (nobody else has to id in a mode other than they operate on), and interferance generating (the narrowband ID may be more interferance than the SS signal itself!) practice. And as others have pointed out, the FCC can track down any SS signal, no problem. So, have the supposed reason for it, is un- founded. Make that "half the supposed reason".  From n3jly@erols.com Mon Mar 17 20:42:03 1997 Received: from smtp3.erols.com (smtp3.erols.com [205.252.116.103]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA21623 for ; Mon, 17 Mar 1997 20:42:02 -0600 (CST) Received: from LOCALNAME (col-as21s02.erols.com [207.172.78.146]) by smtp3.erols.com (8.8.5/8.8.5) with SMTP id VAA21016 for ; Mon, 17 Mar 1997 21:41:56 -0500 Date: Mon, 17 Mar 1997 21:41:56 -0500 Message-Id: <199703180241.VAA21016@smtp3.erols.com> X-Sender: n3jly@pop.erols.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org From: Tony McConnell Subject: narrow band id... yes this requirement is a pain. how about sending a 9600 binary phase shift keyed ax.25 packet. it can't take that long. From djk@tobit.co.uk Tue Mar 18 04:21:07 1997 Received: from dirku.tobit.co.uk (dirku.demon.co.uk [158.152.30.189]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id EAA19128 for ; Tue, 18 Mar 1997 04:20:59 -0600 (CST) Received: (qmail 10251 invoked by uid 500); 18 Mar 1997 10:20:28 -0000 Date: Tue, 18 Mar 1997 10:20:28 +0000 (GMT) From: Dirk Koopman Reply-To: djk@tobit.co.uk To: ss@tapr.org Subject: Re: [SS:1194] narrow band id... In-Reply-To: <199703180241.VAA21016@smtp3.erols.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 17 Mar 1997, Tony McConnell wrote: > yes this requirement is a pain. > Here in the UK, I am struggling a bit to see if our equiv of the FCC (the RA) will licence SS. One of the problems that I face is the ID; how and what should it be. Unlike the US, ax25 packet here has to CW ID every 30 minutes so it is more difficult to escape. Unfortunately it is also difficult to justify an argument along the lines of "well it is just too hard", as a CW keyer isn't a very complex device! Just because it means adding a little bit of extra logic to a nice commercial chipset that one has slung together probably will cut no ice with anyone. One thing you could argue is that you would not really require much power. In fact it is likely that you would only be causing any noticable interference in the near field (which is where an SS signal is most easily detected) and therefore you need only ID in such a way as to be easily detectable there (or a little bit beyond). 1/2mW every 30 minutes? Less? One of the other things concerning the RA is how does one publish or otherwise acquire the spreading codes and modes of people communicating in a band; in other words how does one "join in" with an existing "conversation". I currently see no satisfactory way of doing this. One of the possible uses of ID is to promulgate things like "my PN sequence, mode" etc, but this then means higher power for longer. Dirk -- Dirk-Jan Koopman Tel/Fax: +44 1362 696076 Mobile: +44 973 333806 Computer Consultant Email: djk@tobit.co.uk or G1TLH@GB7TLH.#35.GBR.EU "The typewriting machine, when played with expression, is no more annoying than the piano when played by a sister or near relation." --Oscar Wilde From djk@tobit.co.uk Tue Mar 18 07:43:27 1997 Received: from dirku.tobit.co.uk (dirku.demon.co.uk [158.152.30.189]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id HAA25902 for ; Tue, 18 Mar 1997 07:43:24 -0600 (CST) Received: (qmail 11242 invoked by uid 500); 18 Mar 1997 13:42:52 -0000 Date: Tue, 18 Mar 1997 13:42:52 +0000 (GMT) From: Dirk Koopman Reply-To: djk@tobit.co.uk To: ss@tapr.org Subject: Single Guassian Pulses Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Some time ago I read an article on web about "single guassian pulses", I no longer have the URL, but I believe it came from this sig. It appears that it is legal in the UK to use 'pulse' modulation, nobody that I know does (or has ever, in the recent past), but could this be an interesting mode to work on? It does seem to be a fairly extreme form of SS after all, if it is single and gausian, a pulse has infinite bandwidth (if I remember my theory correctly). The article described roughly what was going in that it had a GPS syncronised correlating detector on a direct modulation receiver. It essentially sampled a short time before and after a reference time to determine 0 or 1. It also seems to produce very reasonable ranges for not much power (>10Km for a few milliwatts). Not being a hardware man, but having a fair amount of software experience with GPS, xntp etc, it strikes me that, if you want something simple to construct, this might be a better way forward than looking at either DS or FH + I suspect it is already licenced. Any views? -- Dirk-Jan Koopman Tel/Fax: +44 1362 696076 Mobile: +44 973 333806 Computer Consultant Email: djk@tobit.co.uk or G1TLH@GB7TLH.#35.GBR.EU "The typewriting machine, when played with expression, is no more annoying than the piano when played by a sister or near relation." --Oscar Wilde From hbaker@netcom.com Tue Mar 18 10:26:34 1997 Received: from netcom16.netcom.com (root@netcom16.netcom.com [192.100.81.129]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA04500 for ; Tue, 18 Mar 1997 10:26:31 -0600 (CST) Received: (from hbaker@localhost) by netcom16.netcom.com (8.6.13/Netcom) id IAA17793; Tue, 18 Mar 1997 08:22:50 -0800 From: hbaker@netcom.com (Henry G. Baker) Message-Id: <199703181622.IAA17793@netcom16.netcom.com> Subject: Re: [SS:1196] Single Guassian Pulses To: ss@tapr.org Date: Tue, 18 Mar 1997 08:22:49 -0800 (PST) Cc: hbaker@netcom.com, djk@tobit.co.uk In-Reply-To: from "Dirk Koopman" at Mar 18, 97 07:49:12 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Some time ago I read an article on web about "single guassian pulses", I > no longer have the URL, but I believe it came from this sig. > > It appears that it is legal in the UK to use 'pulse' modulation, nobody > that I know does (or has ever, in the recent past), but could this be an > interesting mode to work on? > > It does seem to be a fairly extreme form of SS after all, if it is single > and gausian, a pulse has infinite bandwidth (if I remember my theory > correctly). You may be referring to Pulson's 'time-hopping' impulse modulation system. Yes, it is wide-band, and yes, it does work -- I've seen their lab in Huntsville, Alabama. I've had trouble posting to the ss mailing list, so perhaps you can do it for me? The URL is http://206.161.232.178/pulson/ -- Henry Baker www/ftp directory URL: ftp://ftp.netcom.com/pub/hb/hbaker/home.html From djk@tobit.co.uk Tue Mar 18 11:40:28 1997 Received: from dirku.tobit.co.uk (dirku.demon.co.uk [158.152.30.189]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA08601 for ; Tue, 18 Mar 1997 11:40:25 -0600 (CST) Received: (qmail 12422 invoked by uid 500); 18 Mar 1997 17:39:57 -0000 Date: Tue, 18 Mar 1997 17:39:57 +0000 (GMT) From: Dirk Koopman Reply-To: djk@tobit.co.uk To: ss@tapr.org Subject: Re: [SS:1197] Re: Single Guassian Pulses In-Reply-To: <199703181622.IAA17793@netcom16.netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 18 Mar 1997, Henry G. Baker wrote: > > Some time ago I read an article on web about "single guassian pulses", I > > no longer have the URL, but I believe it came from this sig. > > > > It appears that it is legal in the UK to use 'pulse' modulation, nobody > > that I know does (or has ever, in the recent past), but could this be an > > interesting mode to work on? > > > > It does seem to be a fairly extreme form of SS after all, if it is single > > and gausian, a pulse has infinite bandwidth (if I remember my theory > > correctly). > > You may be referring to Pulson's 'time-hopping' impulse modulation system. > Yes, it is wide-band, and yes, it does work -- I've seen their lab in > Huntsville, Alabama. > Yes, that's the one. Now according to my licence I can output up to 400watts of pulse position modulated pulses. That should cause a small stur in the EME segment... When I started there used to be p.r.f which now doesn't seem to apply (mind you, if I remember correctly I could use 25Kw peak power, but that is going back a looooong way). I would be happy with few mW, pulson seems to imply this would be undetectable out of the very small near field. It looks a comparitively simply scheme, is it worth looking at? Dirk -- Dirk-Jan Koopman Tel/Fax: +44 1362 696076 Mobile: +44 973 333806 Computer Consultant Email: djk@tobit.co.uk or G1TLH@GB7TLH.#35.GBR.EU "The typewriting machine, when played with expression, is no more annoying than the piano when played by a sister or near relation." --Oscar Wilde From hbaker@netcom.com Tue Mar 18 14:40:19 1997 Received: from netcom6.netcom.com (hbaker@netcom6.netcom.com [192.100.81.114]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id OAA17144 for ; Tue, 18 Mar 1997 14:40:17 -0600 (CST) Received: (from hbaker@localhost) by netcom6.netcom.com (8.6.13/Netcom) id MAA00357; Tue, 18 Mar 1997 12:40:09 -0800 From: hbaker@netcom.com (Henry G. Baker) Message-Id: <199703182040.MAA00357@netcom6.netcom.com> Subject: Re: [SS:1198] Re: Single Guassian Pulses To: ss@tapr.org Date: Tue, 18 Mar 1997 12:40:09 -0800 (PST) Cc: hbaker@netcom.com, djk@tobit.co.uk In-Reply-To: from "Dirk Koopman" at Mar 18, 97 11:46:54 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > I would be happy with few mW, pulson seems to imply this would be > undetectable out of the very small near field. It looks a comparitively > simply scheme, is it worth looking at? Yes. The system I saw is invisible to nearly all types of test equipment more than a few meters away. The pulses have to have picosecond accuracy, tho, which requires an order of magnitude better timing accuracy than is readily available. -- Henry Baker www/ftp directory URL: ftp://ftp.netcom.com/pub/hb/hbaker/home.html From zsolt@direct.ca Tue Mar 18 17:47:19 1997 Received: from orb.direct.ca (root@orb.direct.ca [199.60.229.5]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id RAA27282 for ; Tue, 18 Mar 1997 17:47:16 -0600 (CST) Received: from cirmos.ci.ca (van-as-09a04.direct.ca [204.174.245.4]) by orb.direct.ca (8.8.3/8.8.0) with SMTP id PAA23109 for ; Tue, 18 Mar 1997 15:46:54 -0800 (PST) Date: Tue, 18 Mar 1997 16:59:44 -0800 (PST) From: George Cserenyi X-Sender: zsolt@cirmos.ci.ca Reply-To: George Cserenyi To: ss@tapr.org Subject: Re: Progress on Clover (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I'd like to submit this message to the ss group for further clarification and comments. George ve7ciz ---------- Forwarded message ---------- Date: Tue, 18 Mar 1997 13:59:57 -0600 From: Greg Blakely To: George Cserenyi Cc: tnos-topics@lantz.com, cap-ndrn@cap.af.mil Subject: Re: Progress on Clover Greg Blakely wrote: > > 3. Someone at CAP national said that they had heard that HAL had come up > with a new "Spread-Spectrum" card that would be quite a bit faster than > the existing one, and that the code was almost identical to the old > stuff, > just an added command or two. > George Cserenyi wrote: > >> Does clover use "Spread-Spectrum", or how is this related to >> the subject : Re: Progress on Clover ? >> I'm not sure that "Spread Spectrum" is EXACTLY the right word to use, but what it amounts to is that, currently, Clover uses a number of subchannels (either 6 or 8, I believe) when tuned to a certain frequency. The signal is varied in pitch on all those sub-channels, using up a certain bandwidth. 1.5 kHz, I think... They are planning to go to a new concept of using the whole bandwidth for one "super-channel", thereby improving the throughput. Not having talked directly with HAL about this, I am not sure exactly how many subchannels they have now, nor exactly what the bandwidth is, but you get the idea. > > Who is "CAP national" BTW? > Good question. And I shouldn't use abbreviations when I know I'm dealing in relative obscurities. CAP stands for Civil Air Patrol, who, along with MARS, uses Clover technology and AX25 packet to keep their Nationwide Packet system tied together. What has happened at CAP is that traffic has fallen off drastically on packet, since everyone now seems to have Internet addresses. But, being an Emergency-Services organization, there is a reluctance to rely too heavily on the Publicly Switched Telephone Network. TNOS provides a great opportunity to meld Internet and Packet, and still provide a survivability should parts of the PSTN go down. -Greg- kb0tdf@kb0tdf.ampr.org mn0045@mn0045.mnwg.ncr.cap.gov From wd5ivd@tapr.org Tue Mar 18 18:10:40 1997 Received: from [208.134.134.40] ([208.134.134.40]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA28685 for ; Tue, 18 Mar 1997 18:10:38 -0600 (CST) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Mar 1997 18:11:09 -0600 To: ss@tapr.org From: "Greg Jones, WD5IVD" Subject: Re: [SS:1200] Re: Progress on Clover (fwd) The real experts on what HAL is doing are over on the HF SIG. Migth want to ask over there as well. Figure in several years DSP, HF, and SS SIGs will all being doing the same things. Cheers - Greg >Hi, > I'd like to submit this message to the ss group >for further clarification and comments. >George >ve7ciz > >---------- Forwarded message ---------- >Date: Tue, 18 Mar 1997 13:59:57 -0600 >From: Greg Blakely >To: George Cserenyi >Cc: tnos-topics@lantz.com, cap-ndrn@cap.af.mil >Subject: Re: Progress on Clover > >Greg Blakely wrote: >> >> 3. Someone at CAP national said that they had heard that HAL had come up >> with a new "Spread-Spectrum" card that would be quite a bit faster than >> the existing one, and that the code was almost identical to the old >> stuff, >> just an added command or two. >> >George Cserenyi wrote: >> >>> Does clover use "Spread-Spectrum", or how is this related to >>> the subject : Re: Progress on Clover ? >>> >I'm not sure that "Spread Spectrum" is EXACTLY the right word to use, >but what it amounts to is that, currently, Clover uses a number of >subchannels (either 6 or 8, I believe) when tuned to a certain >frequency. The signal is varied in pitch on all those sub-channels, >using up a certain bandwidth. 1.5 kHz, I think... > >They are planning to go to a new concept of using the whole bandwidth >for one "super-channel", thereby improving the throughput. > >Not having talked directly with HAL about this, I am not sure exactly >how many subchannels they have now, nor exactly what the bandwidth is, >but you get the idea. >> >> Who is "CAP national" BTW? >> >Good question. And I shouldn't use abbreviations when I know I'm >dealing in relative obscurities. CAP stands for Civil Air Patrol, who, >along with MARS, uses Clover technology and AX25 packet to keep their >Nationwide Packet system tied together. > >What has happened at CAP is that traffic has fallen off drastically on >packet, since everyone now seems to have Internet addresses. But, being >an Emergency-Services organization, there is a reluctance to rely too >heavily on the Publicly Switched Telephone Network. TNOS provides a >great opportunity to meld Internet and Packet, and still provide a >survivability should parts of the PSTN go down. > >-Greg- >kb0tdf@kb0tdf.ampr.org >mn0045@mn0045.mnwg.ncr.cap.gov ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From denis.brzan@guest.arnes.si Wed Mar 19 18:09:38 1997 Received: from kanin.arnes.si (kanin.arnes.si [193.2.1.66]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id SAA16863 for ; Wed, 19 Mar 1997 18:09:35 -0600 (CST) Received: from razor.arnes.si by kanin.arnes.si with SMTP using DNS (PP) id <26379-0@kanin.arnes.si>; Thu, 20 Mar 1997 01:09:02 +0100 Received: from suddbrza (ppp5-kp3.arnes.si [193.2.30.43]) by razor.arnes.si (8.8.5/8.8.5) with ESMTP id AAA11357 for ; Thu, 20 Mar 1997 00:08:47 GMT Message-Id: <199703200008.AAA11357@razor.arnes.si> From: DENIS BRZAN To: ss Subject: Re: [SS:1201] SS digest 271 Date: Thu, 20 Mar 1997 01:14:10 +0100 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BC34CC.03F51F60" Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format. ------=_NextPart_000_01BC34CC.03F51F60 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Spet nekaj po¹te od S57NBD 73!! ---------- > From: ss@tapr.org > To: ss@tapr.org > Subject: [SS:1201] SS digest 271 > Date: 19. marec 1997 23:50 > > SS Digest 271 > > Topics covered in this issue include: > > 1) Re: Progress on Clover (fwd) > by George Cserenyi > 2) Re: Progress on Clover (fwd) > by "Greg Jones, WD5IVD" > > ---------------------------------------------------------------------- > > Date: Tue, 18 Mar 1997 16:59:44 -0800 (PST) > From: George Cserenyi > To: ss@tapr.org > Subject: Re: Progress on Clover (fwd) > Message-ID: > > Hi, > I'd like to submit this message to the ss group > for further clarification and comments. > George > ve7ciz > > ---------- Forwarded message ---------- > Date: Tue, 18 Mar 1997 13:59:57 -0600 > From: Greg Blakely > To: George Cserenyi > Cc: tnos-topics@lantz.com, cap-ndrn@cap.af.mil > Subject: Re: Progress on Clover > > Greg Blakely wrote: > > > > 3. Someone at CAP national said that they had heard that HAL had come up > > with a new "Spread-Spectrum" card that would be quite a bit faster than > > the existing one, and that the code was almost identical to the old > > stuff, > > just an added command or two. > > > George Cserenyi wrote: > > > >> Does clover use "Spread-Spectrum", or how is this related to > >> the subject : Re: Progress on Clover ? > >> > I'm not sure that "Spread Spectrum" is EXACTLY the right word to use, > but what it amounts to is that, currently, Clover uses a number of > subchannels (either 6 or 8, I believe) when tuned to a certain > frequency. The signal is varied in pitch on all those sub-channels, > using up a certain bandwidth. 1.5 kHz, I think... > > They are planning to go to a new concept of using the whole bandwidth > for one "super-channel", thereby improving the throughput. > > Not having talked directly with HAL about this, I am not sure exactly > how many subchannels they have now, nor exactly what the bandwidth is, > but you get the idea. > > > > Who is "CAP national" BTW? > > > Good question. And I shouldn't use abbreviations when I know I'm > dealing in relative obscurities. CAP stands for Civil Air Patrol, who, > along with MARS, uses Clover technology and AX25 packet to keep their > Nationwide Packet system tied together. > > What has happened at CAP is that traffic has fallen off drastically on > packet, since everyone now seems to have Internet addresses. But, being > an Emergency-Services organization, there is a reluctance to rely too > heavily on the Publicly Switched Telephone Network. TNOS provides a > great opportunity to meld Internet and Packet, and still provide a > survivability should parts of the PSTN go down. > > -Greg- > kb0tdf@kb0tdf.ampr.org > mn0045@mn0045.mnwg.ncr.cap.gov > > > ------------------------------ > > Date: Tue, 18 Mar 1997 18:11:09 -0600 > From: "Greg Jones, WD5IVD" > To: ss@tapr.org > Subject: Re: Progress on Clover (fwd) > Message-ID: > > The real experts on what HAL is doing are over on the HF SIG. Migth want > to ask over there as well. > > Figure in several years DSP, HF, and SS SIGs will all being doing the same > things. > > Cheers - Greg > > >Hi, > > I'd like to submit this message to the ss group > >for further clarification and comments. > >George > >ve7ciz > > > >---------- Forwarded message ---------- > >Date: Tue, 18 Mar 1997 13:59:57 -0600 > >From: Greg Blakely > >To: George Cserenyi > >Cc: tnos-topics@lantz.com, cap-ndrn@cap.af.mil > >Subject: Re: Progress on Clover > > > >Greg Blakely wrote: > >> > >> 3. Someone at CAP national said that they had heard that HAL had come up > >> with a new "Spread-Spectrum" card that would be quite a bit faster than > >> the existing one, and that the code was almost identical to the old > >> stuff, > >> just an added command or two. > >> > >George Cserenyi wrote: > >> > >>> Does clover use "Spread-Spectrum", or how is this related to > >>> the subject : Re: Progress on Clover ? > >>> > >I'm not sure that "Spread Spectrum" is EXACTLY the right word to use, > >but what it amounts to is that, currently, Clover uses a number of > >subchannels (either 6 or 8, I believe) when tuned to a certain > >frequency. The signal is varied in pitch on all those sub-channels, > >using up a certain bandwidth. 1.5 kHz, I think... > > > >They are planning to go to a new concept of using the whole bandwidth > >for one "super-channel", thereby improving the throughput. > > > >Not having talked directly with HAL about this, I am not sure exactly > >how many subchannels they have now, nor exactly what the bandwidth is, > >but you get the idea. > >> > >> Who is "CAP national" BTW? > >> > >Good question. And I shouldn't use abbreviations when I know I'm > >dealing in relative obscurities. CAP stands for Civil Air Patrol, who, > >along with MARS, uses Clover technology and AX25 packet to keep their > >Nationwide Packet system tied together. > > > >What has happened at CAP is that traffic has fallen off drastically on > >packet, since everyone now seems to have Internet addresses. But, being > >an Emergency-Services organization, there is a reluctance to rely too > >heavily on the Publicly Switched Telephone Network. TNOS provides a > >great opportunity to meld Internet and Packet, and still provide a > >survivability should parts of the PSTN go down. > > > >-Greg- > >kb0tdf@kb0tdf.ampr.org > >mn0045@mn0045.mnwg.ncr.cap.gov > > > ----- > Greg Jones, WD5IVD > Austin, Texas > wd5ivd@tapr.org > http://www.tapr.org/~wd5ivd > ----- > > > > ------------------------------ > > End of SS Digest 271 > ******************** ------=_NextPart_000_01BC34CC.03F51F60 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable

Spet nekaj po=B9te
od S57NBD = 73!!

----------
> From: ss@tapr.org
> To: = ss@tapr.org
> Subject: [SS:1201] SS digest 271
> = Date: 19. marec 1997 23:50
>
> =     SS Digest 271
>
> = Topics covered in this issue include:
>
>   1) = Re: Progress on Clover (fwd)
> by George Cserenyi <zsolt@direct.ca>
>   2) Re: Progress on Clover = (fwd)
> by "Greg Jones, WD5IVD" <wd5ivd@tapr.org>
>
> = ---------------------------------------------------------------------->
> Date: Tue, 18 Mar 1997 16:59:44 -0800 (PST)
> From: = George Cserenyi <zsolt@direct.ca>
> To: ss@tapr.org
> = Subject: Re: Progress on Clover (fwd)
> Message-ID: <Pine.LNX.3.95.970318165334.16426A-100000@cirmos.ci.c= a>
>
> Hi,
> I'd = like to submit this message to the ss group
> for further = clarification and comments.
> George
> ve7ciz
> =
> ---------- Forwarded message ----------
> Date: Tue, 18 = Mar 1997 13:59:57 -0600
> From: Greg Blakely <webmaster@mnwg.ncr.cap.gov>
> To: George Cserenyi <zsolt@direct.ca>
> Cc: tnos-topics@lantz.com, = cap-ndrn@cap.af.mil
> Subject: Re: Progress on Clover
> =
> Greg Blakely <webmaster@mnwg.ncr.cap.gov> wrote:
> >
> > 3. Someone at = CAP national said that they had heard that HAL had come up
> > = with a new "Spread-Spectrum" card that would be quite a bit = faster than
> > the existing one, and that the code was almost = identical to the old
> > stuff,
> > just an added = command or two.
> >
> George Cserenyi wrote:
> > =  
> >> Does clover use "Spread-Spectrum", or = how is this related to
> >> the subject : Re: Progress on = Clover ?
> >>
> I'm not sure that "Spread = Spectrum" is EXACTLY the right word to use,
> but what it = amounts to is that, currently, Clover uses a number of
> = subchannels (either 6 or 8, I believe) when tuned to a certain
> = frequency.  The signal is varied in pitch on all those = sub-channels,
> using up a certain bandwidth.  1.5 kHz, I = think...
>
> They are planning to go to a new concept of = using the whole bandwidth
> for one "super-channel", = thereby improving the throughput.  
>
> Not having = talked directly with HAL about this, I am not sure exactly
> how = many subchannels they have now, nor exactly what the bandwidth = is,
> but you get the idea.
> >
> > Who is = "CAP national" BTW?
> >
> Good question. =  And I shouldn't use abbreviations when I know I'm
> dealing = in relative obscurities.  CAP stands for Civil Air Patrol, = who,
> along with MARS, uses Clover technology and AX25 packet to = keep their
> Nationwide Packet system tied together. =  
>
> What has happened at CAP is that traffic has = fallen off drastically on
> packet, since everyone now seems to = have Internet addresses.  But, being
> an Emergency-Services = organization, there is a reluctance to rely too
> heavily on the = Publicly Switched Telephone Network.  TNOS provides a
> great = opportunity to meld Internet and Packet, and still provide a
> = survivability should parts of the PSTN go down.
>
> = -Greg-
> kb0tdf@kb0tdf.ampr.org
> mn0045@mn0045.mnwg.ncr.cap.gov
>
>
> = ------------------------------
>
> Date: Tue, 18 Mar 1997 = 18:11:09 -0600
> From: "Greg Jones, WD5IVD" <wd5ivd@tapr.org>
> To: ss@tapr.org
> = Subject: Re: Progress on Clover (fwd)
> Message-ID: = <v03020707af54df60c3e0@[208.134.134.40]>
>
> The real = experts on what HAL is doing are over on the HF SIG.  Migth = want
> to ask over there as well.
>
> Figure in = several years DSP, HF, and SS SIGs will all being doing the same
> = things.
>
> Cheers - Greg
>
> >Hi,
> = > I'd like to submit this message to the ss group
> = >for further clarification and comments.
> >George
> = >ve7ciz
> >
> >---------- Forwarded message = ----------
> >Date: Tue, 18 Mar 1997 13:59:57 -0600
> = >From: Greg Blakely <webmaster@mnwg.ncr.cap.gov>
> >To: George Cserenyi <zsolt@direct.ca>
> >Cc: tnos-topics@lantz.com, = cap-ndrn@cap.af.mil
> >Subject: Re: Progress on Clover
> = >
> >Greg Blakely <webmaster@mnwg.ncr.cap.gov> wrote:
> >>
> >> 3. = Someone at CAP national said that they had heard that HAL had come = up
> >> with a new "Spread-Spectrum" card that = would be quite a bit faster than
> >> the existing one, and = that the code was almost identical to the old
> >> = stuff,
> >> just an added command or two.
> = >>
> >George Cserenyi wrote:
> >>
> = >>> Does clover use "Spread-Spectrum", or how is this = related to
> >>> the subject : Re: Progress on Clover = ?
> >>>
> >I'm not sure that "Spread = Spectrum" is EXACTLY the right word to use,
> >but what it = amounts to is that, currently, Clover uses a number of
> = >subchannels (either 6 or 8, I believe) when tuned to a = certain
> >frequency.  The signal is varied in pitch on = all those sub-channels,
> >using up a certain bandwidth. =  1.5 kHz, I think...
> >
> >They are planning to = go to a new concept of using the whole bandwidth
> >for one = "super-channel", thereby improving the throughput.
> = >
> >Not having talked directly with HAL about this, I am = not sure exactly
> >how many subchannels they have now, nor = exactly what the bandwidth is,
> >but you get the idea.
> = >>
> >> Who is "CAP national" BTW?
> = >>
> >Good question.  And I shouldn't use = abbreviations when I know I'm
> >dealing in relative = obscurities.  CAP stands for Civil Air Patrol, who,
> = >along with MARS, uses Clover technology and AX25 packet to keep = their
> >Nationwide Packet system tied together.
> = >
> >What has happened at CAP is that traffic has fallen off = drastically on
> >packet, since everyone now seems to have = Internet addresses.  But, being
> >an Emergency-Services = organization, there is a reluctance to rely too
> >heavily on = the Publicly Switched Telephone Network.  TNOS provides a
> = >great opportunity to meld Internet and Packet, and still provide = a
> >survivability should parts of the PSTN go down.
> = >
> >-Greg-
> >kb0tdf@kb0tdf.ampr.org
> >mn0045@mn0045.mnwg.ncr.cap.gov
>
>
> -----
> Greg Jones, = WD5IVD
> Austin, Texas
> wd5ivd@tapr.org
> = http://www.tapr.org/~wd5ivd
> -----
>
>
>
> = ------------------------------
>
> End of SS Digest = 271
> ********************

<= /html> ------=_NextPart_000_01BC34CC.03F51F60-- From barefeet@ns.awanet.com Thu Mar 20 08:04:33 1997 Received: from ns.awanet.com (root@awanet.com [205.216.78.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id IAA03363 for ; Thu, 20 Mar 1997 08:04:31 -0600 (CST) Received: from tom (tom.awanet.com [205.216.78.16]) by ns.awanet.com (8.7.4/8.6.9) with SMTP id IAA09061 for ; Thu, 20 Mar 1997 08:13:01 -0600 (CST) Message-Id: <1.5.4.16.19970320130316.2d5fc044@ns.awanet.com> X-Sender: barefeet@ns.awanet.com X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Mar 1997 08:03:16 -0500 To: ss@tapr.org From: "thomas w. barefoot" Subject: [SS:816] Unlicensed National Information Infrastructure By Report and Order FCC 97-005 January 9, 1997 the FCC has created a home for the NII. See http://www.fcc.gov/oet/headline/et96-102/ for details. Quoting some selected paragraphs from 97-005: "By this action, we amend Part 15 of our rules to make available 300 megahertz of spectrum at 5.15-5.35 GHz and 5.725-5.825 GHz for use by a new category of unlicensed equipment, called Unlicensed National Information Infrastructure ("U-NII") devices." "The Commission has determined that the public interest is best serviced by increasing the maximum peak power limit as follows: 50 mW peak transmitter output power with up to 6 dBi antenna gain (equates to 200 mW EIRP) permitted in the 5.15-5.25 GHz band; 250 mW peak transmitter output power with up to 6 dBi antenna gain (equates to 1 W EIRP) permitted in the 5.25-5.35 GHz band; and 1 W peak transmitter output power with up to 6 dBi antenna gain (equates to 4 W EIRP) permitted in the 5.725-5.825 GHz band. In addition, to permit manufacturers flexibility in designing U-NII equipment, the Commission will permit the use of higher directional antenna gain provided there is a corresponding reduction in transmitter output power of one dB for every dB that the directional antenna gain exceeds 6 dBi. Also, U-NII use of the 5.15-5.25 GHz band is restricted to indoor operations only. Further, this action adopts a power spectral density ("PSD") requirement for U-NII devices that would require that the maximum power be spread across of bandwidth of at least 20 megahertz. This PSD requirement will ensure that U-NII devices spread its signal energy evenly across the band and encourages the use of this spectrum by wideband high data rate applications, but permits non-wideband operations at reduced powers. These increased power limits will permit U-NII equipment manufacturers, many of which may be small businesses, more flexibility to develop products to meet market demands." "The Commission has now concluded that the proposed LBT spectrum etiquette could delay deployment of U-NII devices and hinder innovation in the development of these devices. Rather, the Commission has concluded that simple technical rules, such as PSD limits and out-of-band emission requirements, should be sufficient to ensure spectrum sharing between incumbent operations and new U-NII devices. The Commission declined to adopt a spectrum etiquette, any channelization plan, or a minimum modulation efficiency requirement because such requirements may preclude certain technologies or some of the many different concepts envisioned by U-NII proponents. We believe this action will benefit small entities by permitting these entities to develop innovative equipment to meet market demands without having to follow protocols governing use of the spectrum. " Lee W. Fry lfry@wdl.lmco.com From barefeet@ns.awanet.com Thu Mar 20 08:04:37 1997 Received: from ns.awanet.com (root@awanet.com [205.216.78.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id IAA03397 for ; Thu, 20 Mar 1997 08:04:34 -0600 (CST) Received: from tom (tom.awanet.com [205.216.78.16]) by ns.awanet.com (8.7.4/8.6.9) with SMTP id IAA09085 for ; Thu, 20 Mar 1997 08:13:05 -0600 (CST) Message-Id: <1.5.4.16.19970320130320.3e7f3454@ns.awanet.com> X-Sender: barefeet@ns.awanet.com X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Mar 1997 08:03:20 -0500 To: ss@tapr.org From: "thomas w. barefoot" Subject: [SS:974] Re: SS:938 & SS:960 Here's a little more ACTION for the SS adventuresome out there in TAPR-land: I have posted schematics, PCB files & basic 16C64 microprocessor code up on my site for some of the SST-1 radio-modem -- for your viewing and downloading pleasure! Take a look at: http://sss-mag.com/whatsnew/nuissue.html#3 A BARE PCB for the "Baseband" section of the SST-1 will be available soon at US$39 each -- see above link for more info. BTW, this project was originally dubbed the "VAPOR1" as a play on words -- it has now become the SST-1, but some of the files still have vapor'ish names :-) 73 for now, Randy, KC6YJY From barefeet@ns.awanet.com Thu Mar 20 08:05:52 1997 Received: from ns.awanet.com (root@awanet.com [205.216.78.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id IAA03586 for ; Thu, 20 Mar 1997 08:05:50 -0600 (CST) Received: from tom (tom.awanet.com [205.216.78.16]) by ns.awanet.com (8.7.4/8.6.9) with SMTP id IAA09406 for ; Thu, 20 Mar 1997 08:14:21 -0600 (CST) Message-Id: <1.5.4.16.19970320130436.3e7f01a0@ns.awanet.com> X-Sender: barefeet@ns.awanet.com X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Mar 1997 08:04:36 -0500 To: ss@tapr.org From: "thomas w. barefoot" Subject: [SS:1043] Wide Band Gain Antenna... Hi All, This is related to SS, but not specifically about SS. So, please excuse the variation from the list's primary interest, please, please, hi. This week I finished up a 1270 Mhz , 8 dBd antenna, which covers the whole 1270 band with 1.6 or better VSWR. Please do not take this as a final spec, but a typical number. The final spec , could be better, but it may be worse. This antenna fits in 12 by 9 inch enclosure similar to the Ham/LAN Panel 915 antennas. If we multiply by 3, we end up with 36 by 18. Which would be the size of a 440 whole band antenna, with 2:1 or better VSWR. Yep, the whole band, with 8dBd! 420 to 450 Mhz. This is significantly better than colinear antenna bandwidths. Its is similar to multiple bay full wave loop antennas, but with out the reliability problems of corporate coaxial feeds. Now, how does this effect SS? Welp, yagis, and colinears are the type of antennas used at user stations. A multiple bay full wave loop antenna, is a bit of a large expense. Additionally, this prototype can be operated in horizontal polarisation, with a azimuthal beamwidth of the order of 70 de- grees. Multiple bay full wave loop antennas, can have the loops turned hor0 izontal, but they loose the reflection off the mast. Thus reguiring modi- fication to add a reflector mast boom at each point of the mast where there is an element. Horizontal, good F/B ratio, and gain, might be away to do SS on 440. It would attenuate most of the FM. And the F/B ratio could be put to good use keeping TV transmitters out of receivers. With the whole band for spreading, it would also keep the processing gain maximised, resulting in a minimun in- terferance to other modes. And, of course, on 1270, this antenna fills a gap. A small gain antenna, for SS users, covering the whole band. Most yagi s in this band have trouble covering the whole band. F9FT sells yagi s for the high side, and low side seperately. 60 Mhz, spread 56 KB is 28 dB processing gain. 73, Don. Mailbox : WB9MJN @ N9HSI.IL.USA.NA AMPRNet : wb9mjn@wb9mjn.ampr.org[44.72.98.19] Internet: wb9mjn%wb9mjn.ampr.org@uugate.aim.utah.edu From barefeet@ns.awanet.com Thu Mar 20 08:05:55 1997 Received: from ns.awanet.com (root@awanet.com [205.216.78.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id IAA03621 for ; Thu, 20 Mar 1997 08:05:53 -0600 (CST) Received: from tom (tom.awanet.com [205.216.78.16]) by ns.awanet.com (8.7.4/8.6.9) with SMTP id IAA09449 for ; Thu, 20 Mar 1997 08:14:24 -0600 (CST) Message-Id: <1.5.4.16.19970320130439.3e7fb722@ns.awanet.com> X-Sender: barefeet@ns.awanet.com X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Mar 1997 08:04:39 -0500 To: ss@tapr.org From: "thomas w. barefoot" Subject: [SS:1057] Ground-Up Spread Spectrum On the subject of designing our own SS system I think that designing our own is the only way to go. Relying on eval boardas or cutting apart other designs is expensive and destined to be reliant on their technology. This past summer, I designed a 900MHz SS modem for a commercial application. It could be built on a 5x7 PCB, and was not layout critical except for the RF section. Total cost was about $100 in production (~1000) quantity. There is no reason we couldn't do something similar with all of the RF ICs and SS ICs currently available. I would suggest that anyone interested look at the Cylink home page (I think its www.cylink.com, but check Yahoo). They make about 6 different chips for doing DS SS at bit rates of 1200 to 2Mbit/s, with chip rates up to 32 per bit. The chips also start for very low prices ($12 for the slow ones), and handle most of the SS stuff. They can be programmed by a simple microcontroller (we used a 68HC05). 73 Matt Ettus N2MJI From barefeet@ns.awanet.com Thu Mar 20 08:05:57 1997 Received: from ns.awanet.com (root@awanet.com [205.216.78.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id IAA03628 for ; Thu, 20 Mar 1997 08:05:55 -0600 (CST) Received: from tom (tom.awanet.com [205.216.78.16]) by ns.awanet.com (8.7.4/8.6.9) with SMTP id IAA09453 for ; Thu, 20 Mar 1997 08:14:25 -0600 (CST) Message-Id: <1.5.4.16.19970320130440.3e7f7272@ns.awanet.com> X-Sender: barefeet@ns.awanet.com X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Mar 1997 08:04:40 -0500 To: ss@tapr.org From: "thomas w. barefoot" Subject: [SS:1058] News on SS NPRM The FCC released the long awaited NPRM on "Amendement of the Amateur Service Rules to Provide For Greater Use of Spread Spectrum Communication Technologies", FCC 97-10 yesterday. If the FCC doesn't post the NPRM up on their website in the next serveral days, then TAPR will see that its posted on our website. The last time I checked this morning, it still wasn't available from the FCC website. If you're interested in just what the rule changes the FCC is proposing to Part 97 for spread spectrum, they are word for word the same language that the ARRL proposed in their petition, RM-8737 (available on the TAPR website). Comments are due on May 5, 1997 and reply comments are due June 5, 1997. -- Dewayne -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dewayne Hendricks, WA8DZP ! AOL: HENDRICKS Warp Speed Imagineering ! Internet: dewayne@warpspeed.com 43730 Vista Del Mar ! Packet Radio: WA8DZP @ K3MC.#NOCAL.CA.USA.NOAM Fremont, CA 94539-3204 ! WWW: Fax: (510) 770-9854 ! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From barefeet@ns.awanet.com Thu Mar 20 08:05:57 1997 Received: from ns.awanet.com (root@awanet.com [205.216.78.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id IAA03626 for ; Thu, 20 Mar 1997 08:05:55 -0600 (CST) Received: from tom (tom.awanet.com [205.216.78.16]) by ns.awanet.com (8.7.4/8.6.9) with SMTP id IAA09456 for ; Thu, 20 Mar 1997 08:14:25 -0600 (CST) Message-Id: <1.5.4.16.19970320130440.3e7fa4dc@ns.awanet.com> X-Sender: barefeet@ns.awanet.com X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Mar 1997 08:04:40 -0500 To: ss@tapr.org From: "thomas w. barefoot" Subject: [SS:1059] Re: SS Design Hi Paul, I have some comments on ur lineup. What u have proposed is somewhat expensive. If the data i/o and control i/o were done virtually over a Ethernet port, the hardware costs would be allot less there, and the programing would be about the same, hopefully. I would not use a Transverter. They are very expensive. The SS box should do analog I/Q to a "Data Radio". Optional parallel and/or one wire serial I/Q would be nice too. Some Data Radio line ups want one wire data, and in- ternally they split it out into parallel, before aplying it to a D/A. SO, maybe a better solution would be analog/one wire digital I/Q, switch select- able, with an optional external parrallel Data I/Q converter. 73, Don. Mailbox : WB9MJN @ N9HSI.IL.USA.NA AMPRNet : wb9mjn@wb9mjn.ampr.org[44.72.98.19] Internet: wb9mjn%wb9mjn.ampr.org@uugate.aim.utah.edu From barefeet@ns.awanet.com Thu Mar 20 08:05:59 1997 Received: from ns.awanet.com (root@awanet.com [205.216.78.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id IAA03659 for ; Thu, 20 Mar 1997 08:05:57 -0600 (CST) Received: from tom (tom.awanet.com [205.216.78.16]) by ns.awanet.com (8.7.4/8.6.9) with SMTP id IAA09495 for ; Thu, 20 Mar 1997 08:14:28 -0600 (CST) Message-Id: <1.5.4.16.19970320130443.3e7f986e@ns.awanet.com> X-Sender: barefeet@ns.awanet.com X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Mar 1997 08:04:43 -0500 To: ss@tapr.org From: "thomas w. barefoot" Subject: [SS:1066] FCC Releases WT Docket 97-12 http://www.tapr.org/ss and ftp://ftp.tapr.org/tapr/ss now contains a pdf version of FCC WT Docket No. 97-12. WT Docket No. 97-12 Notice of Proposed Rule Making regarding Amendment of the Amateur Service Rules to Provide For Greater Use of Spread Spectrum Communications Technologies was released March 3rd, 1997. 3/5/97 From barefeet@ns.awanet.com Thu Mar 20 08:06:03 1997 Received: from ns.awanet.com (root@awanet.com [205.216.78.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id IAA03691 for ; Thu, 20 Mar 1997 08:06:00 -0600 (CST) Received: from tom (tom.awanet.com [205.216.78.16]) by ns.awanet.com (8.7.4/8.6.9) with SMTP id IAA09516 for ; Thu, 20 Mar 1997 08:14:31 -0600 (CST) Message-Id: <1.5.4.16.19970320130446.3e7f9620@ns.awanet.com> X-Sender: barefeet@ns.awanet.com X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Mar 1997 08:04:46 -0500 To: ss@tapr.org From: "thomas w. barefoot" Subject: [SS:1147] Re: WT Docket No. 97-12 - Hollow Victory? Jeff King wrote: > > At 09:33 PM 3/11/97 -0600, Dewayne Hendricks wrote: > > Metricom implements and uses auto power control in both their pole > >top and end-user devices. > > > Thanks Dewayne, I wasn't sure about this. Its interesting to note that > they are not required to do this under Part 15, but chose to. It's not a technical or do-gooder thing, it's an investment. Marketing says they want to sell xxxx accounts, engineering responds with a way to do this, + a little slop. If they used no power control: marketing would fail, the stock would fail, and investors would go away. Big business doesn't plan anything for the short term. They also would not tolerate a bunch of choo-choo era morse code ID's every 10 minutes in the middle of their fricking channel :-) Steve "reading my marketing 101 notes" From wd5ivd@tapr.org Thu Mar 20 10:11:33 1997 Received: from [208.134.134.40] ([208.134.134.40]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id KAA12929; Thu, 20 Mar 1997 10:11:27 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Mar 1997 10:00:50 -0600 To: "TAPR-BB list mailing", " Spread Spectrum ", " TAPR Board " From: "Greg Jones, WD5IVD" Subject: Steve Bible, N7HPR, on Ham Radio and More TAPR's very own Steve Bible, N7HPR, will be a guest on Len Winkler's Ham Radio & More Show Sunday March 30th at 2300 UTC. The topic will be the New SPREAD SPECTRUM Plan. Ham Radio & More Show information: http://www.goodnet.com/~lenwink/hrm.htm To listen to past Ham Radio & More Shows via Real Audio (Sponsored by TAPR): http://www.tapr.org/hrm The Ham Radio & More Show airs LIVE each Sunday at 6:00pm ET, (2300 utc), on: - many local commercial stations throughout the country, (See http://www.goodnet.com/~lenwink/affil~1.htm for listing) - WWCR Shortwave, 5.070 MHz, and - RealAudio at: http://www.AudioNet.com/radio/business/kbnp (Thanks KBNP) Also available tape delayed via WWCR Shortwave on Mondays, at 1000 utc on 3.210 MHz, and Sundays at 0600 utc on 5.070 MHz. ---------------------------------------------------------------------------- Tucson Amateur Packet Radio 8987-309 E Tanque Verde Rd #337 * Tucson, Az * 85749-9399 * 817-383-0000 ---------------------------------------------------------------------------- e-mail: TAPR@TAPR.ORG ftp: ftp.tapr.org web: ---------------------------------------------------------------------------- From dinod@deltanet.com Thu Mar 20 17:51:43 1997 Received: from mail2.deltanet.com (mail2.deltanet.com [199.171.190.56]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id RAA12422; Thu, 20 Mar 1997 17:51:37 -0600 (CST) Received: from dino (anx-ana4227.deltanet.com [204.254.68.227]) by mail2.deltanet.com (8.8.5/8.8.5) with SMTP id PAA29538; Thu, 20 Mar 1997 15:51:59 -0800 (PST) Message-Id: <1.5.4.32.19970320235121.006909ac@mail.deltanet.com> X-Sender: dinod@mail.deltanet.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Mar 1997 15:51:21 -0800 To: tapr-tnc@tapr.org From: Dino Darling Subject: 1997 ARRL/TAPR DCC Announcement - forwarded message from Greg Jones Cc: netsig@tapr.org, ss@tapr.org > >1997 ARRL and TAPR Digital Communications Conference >October 10-12, 1997 >Baltimore, Maryland (minutes from BWI airport) > >Web: http://www.tapr.org/dcc With respect to TAPR and its members, Maryland is too far! What ever happened to La Vegas? Why not Dayton (not the same time as the Dayton Hamvention!)? Dayton is at least central to the US packet community. I understand there are many good Digital Operators on the east coast and Maryland will serve them well, but it is expensive for us on the left coast! Dino Darling...KC6RIX TAPR Member #3685 / ARRL Member dinod@deltanet.com From wd5ivd@tapr.org Thu Mar 20 18:27:55 1997 Received: from [208.134.134.40] ([208.134.134.40]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA14080 for ; Thu, 20 Mar 1997 18:27:53 -0600 (CST) Message-Id: In-Reply-To: <1.5.4.32.19970320235121.006909ac@mail.deltanet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Mar 1997 18:28:12 -0600 To: ss@tapr.org From: "Greg Jones, WD5IVD" Subject: Re: [SS:1212] 1997 ARRL/TAPR DCC Announcement - forwarded message from Greg Dino, as has been stated from the beginning of the joint meeting process between the ARRL and TAPR, the location of the DCC moves from East Coast to West Coast. Texas '95, Washington '96, now Maryland in '97. Next year a site in the central part of the US will be picked, the year after that it will be in the West again, and then back to the East coast. Thus, someone last year was probably saying this same thing about Washington state who lived on the East coast. In this fashion, if you don't want to fly -- and BWI is not all the expensive to get in and out of -- then you pass on this year and wait for it to move a little closer until it gets back around to your part of the US. Most of us just budget that is is going to cost money to fly to it no matter where it is and every year the airfare is different anyways -- not dependent on distance. This is a fair solution to all TAPR and ARRL members alike who want to attend the conference. Air fare is cheap. I flew from DFW to BWI for $175 a month ago. OUt of all the airports in that part of the US, BWI has some of the best prices for getting in and out of. If you made reservations now -- while the prices are still in flux you might find a pretty low cost ticket....or like many us -- use those advantage miles. As to Las Vegas. Seattle was the replacement for Las Vegas in 1996. As was reported in the PSR last year, after checking on hotel locations and availability for Las Vegas, ARRL and TAPR couldn't afford to hold the conf there. If we had wanted to hold the conf in the middle of the week, they were all setup to afford what we could meet, but holding the conf on the weekend in Las Vegas was not possible. Meeting space was a full price on the weekends. If you want it local, the best solution is to become a local co-host. Cheers - Greg >> >>1997 ARRL and TAPR Digital Communications Conference >>October 10-12, 1997 >>Baltimore, Maryland (minutes from BWI airport) >> >>Web: http://www.tapr.org/dcc > >With respect to TAPR and its members, Maryland is too far! What ever >happened to La Vegas? Why not Dayton (not the same time as the Dayton >Hamvention!)? Dayton is at least central to the US packet community. > >I understand there are many good Digital Operators on the east coast and >Maryland will serve them well, but it is expensive for us on the left >coast! > >Dino Darling...KC6RIX >TAPR Member #3685 / ARRL Member >dinod@deltanet.com ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From wd5ivd@tapr.org Fri Mar 21 12:57:56 1997 Received: from [208.134.134.40] ([208.134.134.40]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id MAA25374; Fri, 21 Mar 1997 12:57:27 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Mar 1997 12:55:31 -0600 To: "TAPR-BB list mailing", " Spread Spectrum " From: wd5ivd@tapr.org Subject: [FCCREG:587] More on the 5.8 GHz U-NII band matters Latest news as of 8AM PST, Mar. 21, 1997, on the 5725-5875 Mhz. potential reallocation and related matters -- To those of you on the Pacific Division 5725 - 5875 MHz Alert List --- As you will recall, in January 1997, the FCC issued a Report and Order on Docket 96-102 dealing with the 5.8 GHz Amateur Band and adjacent spectrum. At that time, I sent you a six part message with the details of the Report and Order from the FCC. Early in March, 1997, three Petitions for Reconsideration on Docket 96-102 were submitted to the FCC. The following is a brief description of the contents of the three petitions obtained from an article in the trade press: Manufacturers Ask for Changes in Unlicensed 'NII' Device Rules In petitions for reconsideration filed last week, Apple Computer, Inc., Hewlett-Packard Co., and the Wireless Information Networks Forum, Inc. (WINForum) urged the FCC to modify its recent order in Engineering and Technology docket 96-102 to allow more highly directional antennas and greater power levels for certain unlicensed devices. In its order, the Commission had designated 300 megahertz of spectrum in the 5 gigahertz band for unlicensed NII (national information infrastructure) devices to be used for low-power data communications. The FCC had divided the U-NII band into three segments: indoor communications, medium-range communications, and somewhat longer-range 'community networks' that would allow wireless connections to Internet service providers. The FCC has not yet authorized any U-NII equipment for sale to the public. In its petition for reconsideration, Apple asked the Commission to consider permitting the use of more highly directional antennas for U-NII devices. The agency could take up that request when it considers a similar issue for unlicensed spread-spectrum devices in another proceeding (engineering and Technology docket 96-8), Apple suggested. The "core question of whether the use of more highly directional antennas will increase, or instead reduce, objectionable interference to others sharing the 5725-5850 MHz band can best be addressed if all relevant attributes of both spread-spectrum and U-NII devices are 'on the table' at the same time," it said. The Commission also should allow the use of directional antennas for the medium-range U-NII band, Apple argued. While the 1-watt power limit for that segment is "adequate to permit the creation of longer-reach community networks," the U-NII rules allow only lower-range omnidirectional antennas in the middle segment. Such a restriction will "frustrate the ability of manufacturers and users seeking to create community networks," Apple said. It urged the FCC to increase the permissible power density in the upper and middle U-NII segments to permit U-NII links to support data rates at the T-1 level, and even faster, over distances exceeding the "several kilometers" allowed by the Commission's rules. Hewlett-Packard asked the FCC to raise the permitted power level in the lowest U-NII segment from 200 milliwatts to 1 watt. This would "promote international harmonization" of technical standards for unlicensed 5 GHz devices, permit manufacturers to design products suitable for both U.S. and European markets, and "make possible the development of more robust and longer-range U-NII devices" in this segment, Hewlett-Packard said. WINForum, a trade association representing manufacturers of unlicensed devices, commended the FCC for making U-NII products available for "multimedia systems." But it said that in a few respects, the technical regulations adopted by the Commission "may unnecessarily restrict design flexibility and ... impair the capabilities of these devices." WINForum asked the FCC (1) to permit the operation of U-NII devices across boundaries between the lower and middle-band segments, (2) to delete frequency-stability requirements, (3) to clarify U-NII signal-measurement techniques, and (4) to make a variety of other technical rule changes and clarifications. To date, I have only been able to obtain the complete text of the Apple Petition for Reconsideration: Before the FEDERAL COMMUNICATIONS COMMISSION Washington, D.C. 20554 In the Matter of ) ) Amendment of the Commission's Rules to ) ET Docket No. 96-102 Provide for Operation of Unlicensed NII ) RM-8648 Devices in the 5 GHz Frequency Range ) RM-8653 PETITION FOR RECONSIDERATION Apple Computer, Inc. ("Apple") hereby respectfully requests that the Federal Communications Commission ("Commission" or "FCC") reconsider in three respects its recent Report and Order in the above-referenced proceeding.[1] First, Apple requests that the Commission expedite its consideration of whether to permit the use of more highly directional antennas for transmitters using the uppermost portion (5725-5825 MHz) of the Unlicensed National Information Infrastructure ("U-NII") band.[2] Second, Apple requests that the Commission amend the antenna directionality rules for the middle U-NII sub-band (5250-5350 MHz). Finally, Apple requests that the Commission amend the peak power spectral density ("PSD") limit for U-NII devices operating in the 5250-5350 MHz sub-band to 125mW/MHz and amend the PSD limit for U-NII devices operating in the 5725-5825 MHz sub-band to 1 Watt in 2 MHz, rather than 1 Watt in 20 MHz.[3] i. the commission should expedite its consideration of whether to permit u-nii devices operating in the 5725- 5825 mhz band to use more highly directional transmit antennas. Apple is one of the original proponents of unlicensed U- NII devices.[4] In addition to supporting generally the need for a high bandwidth unlicensed band in the 5 GHz range, Apple has been one of the principal advocates for the creation of unlicensed longer-distance "community networks." As such, Apple was pleased that the Commission has come to recognize the importance of community networks in helping to meet the communications needs of educational institutions, libraries, health care providers, and others,[5] and that the Report and Order therefore adopted power limits and other rules that will make possible at least a limited community networking function in a portion of the U-NII band.[6] In the Report and Order, the Commission recognized that it may be appropriate to further accommodate community networking by permitting U-NII devices operating in the 5725-5825 MHz band to use more highly directional antennas than are permitted under the current rules.[7] The power and antenna directionality rules adopted for U-NII devices operating in the 5725-5825 MHz band are identical to those that currently apply to spread spectrum Part 15 devices operating in the 5725-5850 MHz band.[8] In a separate proceeding, however, the Commission is considering whether to permit 5 GHz spread spectrum devices to use more highly directional transmit antennas.[9] As a result, the Commission stated in the Report and Order that, if it decides in the other proceeding to permit the use of higher gain directional transmitting antennas for spread spectrum operations, it may consider in a separate rulemaking similar action for U-NII devices operating in the 5725-5825 MHz band. Apple urges the Commission to consider in tandem, rather than seriatim, whether to increase the permitted antenna gain for both spread spectrum and U-NII systems operating in the 5725-5825 MHz band. Were the Commission to proceed as discussed in the Report and Order _ first deciding whether to increase antenna gain for spread spectrum systems, and only then deciding whether to increase antenna gain for U-NII systems _ its process would delay unnecessarily the potential introduction of beneficial longer range U-NII devices. There are compelling policy reasons why the Commission should consider simultaneously the permissible antenna gain for spread spectrum and 5725-5825 MHz U-NII devices. Indeed, Apple first noted the interplay between the spread spectrum and U-NII proceedings seven months ago when it filed comments in ET Docket No. 96-9. First, the core question of whether the use of more highly directional antennas will increase _ or instead reduce _ objectionable interference to others sharing the 5725-5850 MHz band can best be addressed if all relevant attributes of both spread spectrum and U-NII devices are "on the table" at the same time. Second, several commenters in this proceeding _ including WINForum, Microsoft, and Motorola _ already have addressed why the Commission should adopt and maintain parallel rules for spread spectrum and U- NII devices operating in the 5725-5825 MHz band. Third, the record in this proceeding already contains an extensive discussion of the need for longer distance community networks, as well as of the potential for interference between U-NII systems that employ directional antennas and other users of the 5725-5825 MHz band. As a result of the above, there is no need for the Commission to start a new proceeding or to defer, until after a decision has been issued in the spread spectrum proceeding, its consideration of whether to permit higher gain antennas for U-NII devices operating in the 5725-5825 MHz band. Either such approach would force parties to duplicate much of the record that already exists in this proceeding, thereby wasting the Commission's resources and those of the public, as well as effectively guarantee that the introduction of longer range U-NII devices would be delayed by a year or more. II. the commission also promptly should consider whether to permit the use of more highly directional transmit antennas in the 5250-5350 MHz band. The arguments supporting the use of directional transmit antennas are as applicable to the middle U-NII band (5250-5350 MHz) as they are to the upper U-NII band (5725-5825 MHz). The one watt power limit for the middle band, by itself, is adequate to permit the creation of longer-reach community networks. The current rules, however, penalize directionality beyond that of a 6 dBi (essentially omnidirectional) antenna and, as a result, will frustrate the ability of manufacturers and users seeking to create community networks within this sub-band. As Apple and others previously have discussed in this proceeding, the Commission should encourage, rather than penalize, the use of more highly directional transmit antennas. To do so, the Commission should amend the antenna directionality rules for 5250-5350 MHz U-NII devices at the same time that it amends the antenna directionality rules for 5725-5825 MHz U-NII devices and spread spectrum devices. Specifically, the Commission should replace its current rule (which requires a dB-for-dB back-off in transmit power for antennas with a directional gain of more than 6 dBi) with a rule requiring a back-off of 1 dB in power for each 3 dB of antenna gain in excess of 6 dBi. Alternately, the Commission could apply the same directionality rules to the middle U-NII band that it adopts for the upper U-NII band and for spread spectrum devices. iii. the commission should amend the psd limits applicable to the middle and upper u-nii sub-bands by basing the psd limits on a 2 mhz rather than a 20 mhz bandwidth. In the Report and Order, the Commission imposed peak PSD limits for each of the U-NII band segments. In the middle U-NII band, a limit of 12.5 mW/MHz for an antenna gain of 6 dBi was adopted; for the upper U-NII band, a limit of 50 mW/MHz for an antenna gain of 6 dBi was adopted.[10] The Commission adopted its U-NII PSD rules in large part to encourage the use of the U-NII bands for the broadband operations for which they are intended.[11] While Apple recognizes the role the U-NII band will play in making available very high speed, short range communications, the rules governing the band should not be so strict that they make it impossible for U-NII devices also to satisfy the longer distance, somewhat lower bandwidth needs of those who will rely on community networks. At this stage in the deployment of "wideband" services, an ISDN data rate (56 kbps) is a luxury for many, and a T1 (1.544 Mbps) unlicensed capability represents a major advance over the data rates that currently are available over wired networks only at very high monthly costs _ if at all _ to most individuals and organizations. Community networks must be able to provide T1 data rates over reasonable distances if they are to meet the immediate and near-term needs of many users, including rural schools, hospitals, and libraries. As a result, the Commission should amend its PSD rules so as to make it more feasible for U-NII links in the middle and upper portions of the U-NII band to support T1 and faster data rates over distances exceeding "several kilometers."[12] Power density is, of course, a major determinant of the distances that can be achieved for line-of-sight paths. Under the spread spectrum rules, designers are free to respond to market forces, making tradeoffs between distance (as represented by the signal-to-noise ratio produced as a result of a PSD) and data rate (or bandwidth). Under the U-NII rules, these tradeoffs are not permitted: distance is essentially fixed, independent of bandwidth, because manufacturers must reduce their power (and hence achievable distance) in tandem with any reduction in bandwidth. This disparity not only violates the goal of functional and technological parity for U-NII devices vis-a-vis other unlicensed devices operating in the 5 GHz range.[13] In addition _ and even more importantly _ it will make it more difficult for U-NII devices to provide the bandwidths, T1 and up, at the distances that community networks will require. Accordingly, the Commission should modify the PSD limit for U-NII devices operating in the 5725-5825 MHz band from 1 Watt in 20 MHz (50 mW/MHz) to 1 Watt in 2 MHz, or 500 mW/MHz. This change not only will ensure that U-NII devices are able to provide communications to those who are bypassed by other technologies, but also will create some degree of technological and distance-reaching parity between U-NII devices and spread spectrum devices at benchmark T1 data rates. In addition, the Commission should modify the PSD limit for U-NII devices operating in the 5250-5350 MHz band from 0.250 Watts in 20 MHz (12.5 mW/MHz) to 0.250 Watts in 2 MHz, or 125 mW/MHz. CONCLUSION For the reasons stated herein, Apple respectfully requests that the FCC promptly consider whether to permit the use of more highly directional antennas by U-NII devices operating in the middle and upper U-NII sub-bands, and amend the peak PSD limits for U-NII devices operating in these sub- bands. Respectfully submitted, APPLE COMPUTER, INC. /s/ James F. Lovette James F. Lovette Principal Scientist, Network Outreach Apple Research Laboratories Apple Computer, Inc. One Infinite Loop, MS: 301-3E Cupertino, California 95014 (408) 974-1418 jlovette@apple.com niiband- feedback@research.apple.com OF COUNSEL Henry Goldberg Mary J. Dent Goldberg, Godles, Wiener & Wright 1229 Nineteenth Street, N.W. Washington, D.C. 20036 (202) 429-4900 March 3, 1997 _______________________________ [1] Amendment of the Commission's Rules to Provide for Operation of Unlicensed NII Devices in the 5 GHz Frequency Range, Report and Order, ET Docket No. 96-102, FCC 97-5 (released Jan. 9, 1997). [2] On February 13, 1997, Apple submitted a letter to the Office of Engineering and Technology in which it urged the Commission not to defer its consideration of whether to permit the use of more highly directional antennas by U-NII transmitters using the 5725-5825 MHz band, but rather to consider this question as part of the instant proceeding and, at most, to request additional comment on the narrow question of whether the U-NII rules should be changed to reflect any changes in the spread spectrum rules. In order to avoid any claim that Apple's letter did not provide an adequate basis for the Commission to expedite its consideration of the use of highly directional transmit antennas by U-NII devices, and in the event that the Commission would prefer to address this issue as part of its reconsideration process rather than through a request for additional comments, Apple is including this request in its Petition for Reconsideration. [3] The Report and Order permits U-NII devices operating in the upper band to employ a peak PSD of 50 mW/MHz for an antenna gain of 6 dBi. Report and Order at 49. This corresponds to a PSD of 1 Watt in 20 MHz for an antenna gain of 6 dBi. [4] Id. at 2. [5] Id. at 18. [6] Id. at 46. [7] Id. at 47. [8] Id. at 46. While the power and directionality rules are the same for U-NII and spread spectrum systems, U-NII devices are subject to much stricter PSD limits than are spread spectrum systems operating under 47 C.F.R. 15.247. As discussed below, this limits the capabilities of U-NII devices vis-a-vis spread spectrum devices, and this disparity should be addressed by the Commission. [9] Id. at 47 (citing ET Docket No. 96-8). [10] Id. at 49. [11] Id. U-NII devices are defined as providing "wideband, high data rate" communications. 47 C.F.R. 15.403 (a). [12] See id. at 46 (stating that the power limits adopted for U-NII devices operating in the upper band will provide community networks with a typical range of several kilometers, and that longer-range communications could be possible in rural and other areas with a low interference environment). [13] Unlike U-NII devices, frequency hopping spread spectrum devices are subject to no limits on minimum bandwidth or maximum PSD; for example, a frequency hopping device that can convey T1-rate data in 1 MHz can utilize a PSD of 1 Watt/MHz (1000 mW/MHz), 13 dB greater than (or 20 times) the PSD limit for a U-NII device operating in the upper U-NII sub-band and 80 times the PSD limit for a U-NII device operating in the middle U-NII sub-band. Frequency hopping devices offering still lower data rates and bandwidths can utilize even higher PSDs. For example, to convey the rates achieved by new-generation telephone modems, 56 kbps, a frequency hopping systems could use an on-channel RF bandwidth of 100 kHz; and the PSD could then be 10 Watts/MHz. Direct sequence spread spectrum systems also have an advantage over U-NII systems in this regard: for example, a direct sequence system conveying a 2 MHz data channel with a processing gain of 10 dB can offer a signal- to-noise ratio (after de-spreading) equivalent to that provided by a signal utilizing a PSD of 500 mW/MHz, 10 dB greater than (or 10 times) the PSD limit for a U-NII device operating in the upper U-NII sub-band and 40 times the PSD limit for a U-NII device operating in the middle U-NII sub- band. This information came from Dewayne Hendricks, WA8DZP, Pacific Division Assistant Director, member of ARRL Future Systems Committee, and Chairman of TAPR Regulatory Committee. Editing and conversion of the original WP document was done by Glen Lokke, KE6NBO and relayed to me. Many thanks to Dewayne and Glen for all their work! I am continuing to try to develop machine readable versions of the other two Petitions for Reconsideration. I have been promised hard copy of all three documents from ARRL HQ. I plan to convert the hard copy of the WINForum and HP petitions to machine readable when they arrive and forward them to you. At the moment I have no idea of what the FCC will do with these petitions, nor any time schedule. It is my understanding that the ARRL plans to comment on the Apple Petition. If you would like to participate in preparing input to the ARRL Comments, please send the information to me for forwarding to ARRL HQ. In addition, you may wish to comment to the FCC directly. Please copy me on any direct comments to the FCC. I continue to hope that this bulletin, previous bulletins, the text of ET Docket 96-102 as well as all the other information will be up on the ARRL Pacific Division Home Page on WWW --- (address http://www.pdarrl.org/). That process is suffering some "growing pains", but I hope that we will work our way through them soon. See also the ARRL Home Page at http://www.arrl.org/ and select "Band Threat News". For those of you who wish to get the information concerning NII/SUPERNet Docket (ET Docket No. 96-102) directly from the FCC Web site --- Here are the URL's: Text version (without footnotes and special formatting): WordPerfect version (with footnotes and special formatting): More details will be sent to the Pacific Division 5725-5875 MHz Alert List and, hopefully, posted on the Pacific Division Home Page as soon as they are known. Any thoughts on any of this by anyone would be appreciated! Contact Brad Wyatt, K6WR, ARRL Pacific Division Director at k6wr@arrl.org or (408) 395-2501 if you can help in any way. 73, Brad Wyatt K6WR ARRL Pacific Division Director From davek@komacke.com Sat Mar 22 13:26:59 1997 Received: from sydney.komacke.com (root@sjx-ca13-11.ix.netcom.com [199.182.128.171]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id NAA20172 for ; Sat, 22 Mar 1997 13:26:56 -0600 (CST) Received: from musty.kobie.komacke.com (musty.kobie.komacke.com [192.168.2.2]) by sydney.komacke.com (8.7.6/8.7.3) with SMTP id LAA12941 for ; Sat, 22 Mar 1997 11:26:46 -0800 Message-Id: <3.0.1.32.19970322112638.006aed88@sydney> X-Header1: Finger for my PGP key X-Sender: davepost@sydney X-Mailer: Windows Eudora Pro Version 3.0.1 beta 14 (32) Date: Sat, 22 Mar 1997 11:26:38 -0800 To: ss@tapr.org From: Dave Koberstein Subject: Re: [SS:1190] Wireless Ethernet comments In-Reply-To: <1.5.4.32.19970316181502.0069d834@gauss.ece.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Good point. FHSS wireless ethernet doesn't suffer from this problem to quite the same magnitude. This is the reason most (if not all) wireless enet manufactures have introduced or are introducing FHSS products on 2.4 GHz. Not that this info changes the approach hams should take to the STA. Just thought you'd like to know. > ----------- At 12:23 PM 3/16/97 -0600, you wrote: > A lot of people have been talking about using wireless ethernet DS >modems. Also, people have commented on them not using power control, so why >should we. > > DS Wireless ethernet is NOT CDMA, it is only DSSS. This means that >every unit uses the same spreading sequence. Only one unit may transmit at >a time, thus no need for power control, unless you have adjacent cells. > > DS SS is wasteful of spectrum if one does not use CDMA. Wireless >ethernet uses a 11 chip spreading code, thus wasting 11 times the bandwidth >necessary. If CDMA was used, more users could transmit at the same time, >and the would be no waste. > > I think it is pointless to base anything on wireless ethernet, as it >is wasteful, old technology, and not standardized. If we truly want to use >spread spectrum properly, that implies we use CDMA as well, and that implies >we do something custom. > > Matt > N2MJI > > -------------------- End of Original ---------------------------------- ____________________________________________________________ Dave Koberstein keep in touch: davek@komacke.com / http://www.komacke.com work: davek@proxim.com / http://www.proxim.com ham internet: n9dk@n9dk.ampr.org [44.4.12.172] (ax.25/PBBS: n9dk@w6yx.#nocal.ca.usa.noam) From wd5ivd@tapr.org Sun Mar 23 14:05:30 1997 Received: from [208.134.134.40] ([208.134.134.40]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA05827; Sun, 23 Mar 1997 14:04:57 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 23 Mar 1997 14:05:32 -0600 To: "APRS SIG list mailing", " DSP-93 Build ", "HF SIG list mailing", "NETSIG list mailing", "BBS SIG list mailing", " TAPR/AMSAT DSP ", "TAPR-BB list mailing", TAPR Regional Freq , " tapr-tnc ", " Spread Spectrum " From: "Greg Jones, WD5IVD" Subject: TAPR Board Election -- Don't forget to vote! TAPR Board of Directors Elections --------------------------------- If you are a member of TAPR, don't forget to take the time to vote! We have four people running for three places, so it could be your vote that determines who is on the TAPR Board of Directors. Deadline for balloting is March 30th, 1997. This year, members of TAPR can vote either by mail in ballot or over the Internet using the world wide web. Check your PSR on how to submit your vote via the web. Don't lose your PSR, because you will need information contained on your mail label. If you have problems using the web system, contact Dorothy at the office and we can look into the issue. PSRs were mailed on March 5th, so all members should have them by now. If you have not received your PSR, call or send e-mail to the office and request a ballot be sent or request the necessary information to allow you to ballot using the on-line Web page. **** DEADLINE March 30th! **** ---------------------------------------------------------------------------- Tucson Amateur Packet Radio 8987-309 E Tanque Verde Rd #337 * Tucson, Az * 85749-9399 * 817-383-0000 ---------------------------------------------------------------------------- e-mail: TAPR@TAPR.ORG ftp: ftp.tapr.org web: ---------------------------------------------------------------------------- From lpthomas@winning-edge.com Tue Mar 25 15:41:00 1997 Received: from kc.winning-edge.com (root@kc.winning-edge.com [205.217.148.245]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id PAA22589 for ; Tue, 25 Mar 1997 15:40:57 -0600 (CST) Received: from lpthomas.winning-edge.com (lpthomas.winning-edge.com [205.217.148.247]) by kc.winning-edge.com (8.6.12/8.6.9) with SMTP id PAA14930 for ; Tue, 25 Mar 1997 15:38:05 -0600 Message-Id: <2.2.32.19970325213801.00cc9454@winning-edge.com> X-Sender: lpthomas@winning-edge.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Mar 1997 15:38:01 -0600 To: ss@tapr.org From: "Larry P. Thomas WA0GWA" Subject: Still Alive ! Have not seen any activity on this SIG since 3/23/97. My site was off a little this weekend ... wondering if I got bumped off the SIG for inability to be reached! Later Larry ----------------------------------------------------------------------- Larry P. Thomas wa0gwa voice : 1 913 888-0282 Krell Technologies fax : 1 913 782-9359 8960 Bond pager : 1 816 989-HELP Overland Park, KS 66214-1764 e-mail : lpthomas@winning-edge.com www : http://www.krell.com ----------------------------------------------------------------------- From wd5ivd@tapr.org Thu Mar 27 22:11:37 1997 Received: from [208.134.134.40] ([208.134.134.40]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA12846; Thu, 27 Mar 1997 22:11:34 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Mar 1997 22:12:24 -0600 To: "TAPR-BB list mailing" From: "Greg Jones, WD5IVD" Subject: Steve Bible, N7HPR, on Ham Radio and More Cc: " Spread Spectrum " Just as a reminder.... TAPR's very own Steve Bible, N7HPR, will be a guest on Len Winkler's Ham Radio & More Show Sunday March 30th at 2300 UTC. The topic will be the New SPREAD SPECTRUM Plan. Ham Radio & More Show information: http://www.goodnet.com/~lenwink/hrm.htm To listen to past Ham Radio & More Shows via Real Audio (Sponsored by TAPR): http://www.tapr.org/hrm The Ham Radio & More Show airs LIVE each Sunday at 6:00pm ET, (2300 utc), on: - many local commercial stations throughout the country, (See http://www.goodnet.com/~lenwink/affil~1.htm for listing) - WWCR Shortwave, 5.070 MHz, and - RealAudio at: http://www.AudioNet.com/radio/business/kbnp (Thanks KBNP) Also available tape delayed via WWCR Shortwave on Mondays, at 1000 utc on 3.210 MHz, and Sundays at 0600 utc on 5.070 MHz. ---------------------------------------------------------------------------- Tucson Amateur Packet Radio 8987-309 E Tanque Verde Rd #337 * Tucson, Az * 85749-9399 * 817-383-0000 ---------------------------------------------------------------------------- e-mail: TAPR@TAPR.ORG ftp: ftp.tapr.org web: ---------------------------------------------------------------------------- ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From bm@lynx.ve3jf.ampr.org Fri Mar 28 21:06:39 1997 Received: from lynx.ve3jf.ampr.org (lynx.ve3jf.ampr.org [44.135.96.100]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id VAA26624 for ; Fri, 28 Mar 1997 21:06:32 -0600 (CST) Received: (from bm@localhost) by lynx.ve3jf.ampr.org (8.6.12/8.6.12) id DAA14698 for ss@tapr.org; Sat, 29 Mar 1997 03:06:08 GMT From: Barry McLarnon VE3JF Message-Id: <199703290306.DAA14698@lynx.ve3jf.ampr.org> Date: Sat, 29 Mar 1997 03:06:08 +0000 (GMT) To: ss@tapr.org Subject: Re: [SS:1217] Still Alive ! In-Reply-To: <2.2.32.19970325213801.00cc9454@winning-edge.com> X-Mailer: Ishmail 1.3.1-961106-linux MIME-Version: 1.0 Content-Type: text/plain "Larry P. Thomas WA0GWA" wrote: > Have not seen any activity on this SIG since 3/23/97. My site was off a > little this weekend ... wondering if I got bumped off the SIG for inability > to be reached! You won't get bumped off for transient mail problems - you have to be a persistent offender. :-) The recent quietude probably has something to do with March Break, n'est-ce pas? Barry -- Barry McLarnon VE3JF/VA3TCP | Internet: bm@hydra.carleton.ca Ottawa Amateur Radio Club | AMPRnet: bm@lynx.ve3jf.ampr.org Packet Working Group | Web: http://hydra.carleton.ca From labriola@ix.netcom.com Sat Mar 29 19:32:29 1997 Received: from [208.134.134.40] ([208.134.134.40]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA07257; Sat, 29 Mar 1997 19:32:27 -0600 (CST) X-Sender: wd5ivd@tapr.org Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Mar 1997 09:31:34 -0600 To: " Spread Spectrum ", "NETSIG list mailing" From: Don Labriola (by way of Greg Jones, WD5IVD) Subject: 10 Ghz data link web page All, The Tech Bench Elmers group in Southern California has added a page for our data link project. We will be tracking our progress through it. Any inputs or developments that you would like to share would be greatly appreciated! The page is: http://www.geocities.com/SiliconValley/2775/ Look under 10Ghz data link.... 73's de W6QS - Don Labriola From wd5ivd@tapr.org Sun Mar 30 22:55:56 1997 Received: from [208.134.134.40] ([208.134.134.40]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA02495; Sun, 30 Mar 1997 22:55:53 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 30 Mar 1997 22:56:57 -0600 To: "TAPR-BB list mailing", " Spread Spectrum " From: "Greg Jones, WD5IVD" Subject: Steve Bible's HRM Show on-line Cc: " TAPR Board " TAPR's very own Steve Bible, N7HPR, was a guest on Len Winkler's Ham Radio & More Show Sunday March 30th at 2300 UTC. The topic was the New SPREAD SPECTRUM Plan. If you were not able to hear the show, it is now available on-line. To listen to the show you can visit either: http://www.tapr.org/ss or http://www.tapr.org/hrm ---------------------------------------------------------------------------- Tucson Amateur Packet Radio 8987-309 E Tanque Verde Rd #337 * Tucson, Az * 85749-9399 * 817-383-0000 ---------------------------------------------------------------------------- e-mail: TAPR@TAPR.ORG ftp: ftp.tapr.org web: ---------------------------------------------------------------------------- From n3jly@erols.com Mon Mar 31 12:02:37 1997 Received: from smtp3.erols.com (smtp3.erols.com [205.252.116.103]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id MAA19523 for ; Mon, 31 Mar 1997 12:02:35 -0600 (CST) Received: from LOCALNAME (col-as16s60.erols.com [207.172.76.60]) by smtp3.erols.com (8.8.5/8.8.5) with SMTP id NAA27030 for ; Mon, 31 Mar 1997 13:01:54 -0500 Date: Mon, 31 Mar 1997 13:01:54 -0500 Message-Id: <199703311801.NAA27030@smtp3.erols.com> X-Sender: n3jly@pop.erols.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org From: Tony McConnell Subject: Re: [SS:1221] Steve Bible's HRM Show on-line At 10:59 PM 3/30/97 -0600, you wrote: >TAPR's very own Steve Bible, N7HPR, was a guest on Len Winkler's Ham Radio >& More Show Sunday March 30th at 2300 UTC. The topic was the New SPREAD >SPECTRUM Plan. do we have a plan? that may sound silly, but do we?