From aeynon@micro.ti.com Thu May 01 09:54:31 1997 Received: from jester.ti.com (jester.ti.com [192.94.94.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id JAA20972 for ; Thu, 1 May 1997 09:54:29 -0500 (CDT) Received: from reliant.micro.ti.com ([158.218.63.15]) by jester.ti.com (8.8.5) with ESMTP id JAA18372 for ; Thu, 1 May 1997 09:53:58 -0500 (CDT) Received: from admin2.micro.ti.com (postmaster@admin2.micro.ti.com [158.218.63.17]) by reliant.micro.ti.com (8.8.5/8.8.5) with ESMTP id JAA20835 for ; Thu, 1 May 1997 09:53:57 -0500 (CDT) Received: from aspc0662.micro.ti.com ([158.218.60.85]) by admin2.micro.ti.com (post.office MTA v2.0 0813 ID# 0-11540) with SMTP id AAA19353; Thu, 1 May 1997 09:53:56 -0500 Message-Id: <3.0.32.19970501095550.0069cacc@pcmail.micro.ti.com> X-Sender: aeyn@pcmail.micro.ti.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 01 May 1997 09:55:50 -0500 To: ss@tapr.org From: "Alan J. Eynon" Subject: SS ID Cc: aeyn@micro.ti.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Dirk, >Sight seems to have been lost of the original goal of experimentation. In >order to get SS legalised here, it appears I have to solve all the >problems that have discussed here over the last few days BEFORE any >experimentation can take place. There was only one catch, but that was Catch-22... >1) how can I ENSURE (to be defined by our RA somewhen, and not vouchsafed >to the likes of me until I/we get it wrong) that ANY amateur can 'join >in' an SS QSO. With all due respect to the appropriate authorities, but are they aware that holding a valid license does not ensure that any amateur can join in any QSO in any current valid operating mode? You still have to have the right equipment, propagation conditions, operational elan, etc.. Do we outlaw 30 wpm CW QSOs because some licensed amateurs can only operate at 13? >4) why is SS not encryption. Specifically how can the RIS check that I not >using the mode for unspeakable things? It's not encryption because we're not hiding the data in any way. Perhaps the best way to present this is to say that, instead of transmitting one bit as one bit, spread spectrum transmits one bit as multiple bits (which we call chips, to avoid confusion). That is to say, if we are spreading each bit with (for instance) a 511 chip sequence: data bit: 1 x chips: 1 -1 1 1 -1 1 -1 -1... ------------------------- spread signal: 1 -1 1 1 -1 1 -1 -1... whereas for sending zeroes: data bit: -1 x chips: 1 -1 1 1 -1 1 -1 -1... ------------------------- spread signal: -1 1 -1 -1 1 -1 1 1... all we've done is flip the sequence. It's not as though each bit were getting multiplied by a non-repeating, random, and secret code. >I have heard it said that it is relatively simple to determine a PN >sequence. Perhaps someone knowledgable could fill me/us in as to how this >is achieved (in broad terms) and how much computing power is required (a >future are of experimentation?). Let me break this down into scenarios: A. A legitimate amateur transmission. Chances are good that either the authorities will have the amateur's spreading sequence on record, or it will be one of a small number of valid sequences. They could also monitor the amateur's ID signal and find out what sequence is being used. There shouldn't be any problems in this case. B. Other, illegitimate transmissions. Presumably these transmissions have enough power that they are getting noticed. If someone transmits a genuinely clandestine signal (for whatever nefarious reasons) below the noise, I would argue that by definition it's beyond any sort of regulation the authorities impose on legitimate users. In other words, it make no sense to impose regulations on us (the legitimate users) in an attempt to control the actions of those who desire to operate outside of the law. These sorts of worries are best left to the intelligence agencies. Given that the signal has made itself noticed, the most straightforward way to determine the PN sequence is to demodulate it directly. From the spectral presentation of the signal, you can determine the chipping rate and the rate at which the spreading sequence repeats. That tells you how long the spreading sequence is. If the spread C/N ratio is good enough, you can demodulate the chips themselves, and recover the sequence. Of course, if the sequence is very long, the chance that you'll correctly demodulate all of the chips decays exponentially to zero. And the situation only gets worse at lower C/N ratios. If the sequence is truly a pseudo-noise sequence generated by shift registers, well, there's only so many sequences of a given length. One can test each candidate by a method called sequence estimation. Let's say you know that the spreading sequence has 1023 chips in it. You know that there are (say) 100 different tap point arrangements that generate sequences of this length. You set up your taps for the first generator, demodulate just 10 chips to fill your shift register, and start things going. If it despreads, you did everything correctly. If it doesn't, you either made an error demodulating one (or more) of the chips, or you have the wrong set of tap points. Note that this cuts down on the number of chips you need to demodulate, so the likelihood that you'll make (in this case) 10 decisions correctly is exponentially better than if you had to demodulate all 1023 chips. >Another related idea is to have a mathematically related series of PN >sequences that one could use so you could 'tune' the sequences in a way >analogous to a tuning knob on a conventional transceiver. My maths is not >strong enough to know how feasible (or desirable) this is. Depending on the implementation, this is eminently feasible. For instance, in one of my previous e-mails I mentioned using a Gold code. Gold codes are created by XORing together the outputs of two linear recursive shift registers. The tap points on the two registers have to be specially chosen "preferred pairs", but these have already been discovered and tabulated. Let me give an example. Let's say that (over here) the FCC decided to allow us to use a family of 1023 chip Gold code spreading sequences. It would then standardize on a single set of preferred pair tap points. Taken by themselves, the register with tap point set A generates one 1023 chip sequence, and the other register with the other tap points generates another 1023 chip sequence. So that gives us two possible spreading sequences. If you then allow us to create Gold code sequences by XORing the two sequences together, this gives an additional 1023 possible sequences (differing only in the relative offset of the two original sequences). By adjusting the relative offset of those two shift register generated sequences, an amateur could "tune" through all of the possible Gold code spreading sequences, until the correct sequence is found and the received spread signal despreads. (I know, it's not as easy in practice as the preceding paragraph makes it sound, but at this point we're discussing the concept so everyone understands what is possible.) The length of this e-mail is getting rather forbidding, so I'm going to stop here. I'd be happy to discuss the matter further, though, particularly if there are more questions. 73 Alan Software Development Systems, Stafford, Texas Instruments, +1 281-274-2943 -------------------------------------------------------------------------- "DESTROY 99% OF KNOWN HOUSEHOLD PESTS WITH PRE-SLICED, RUSTPROOF, EASY TO HANDLE, LOW CALORIE SIMPSON'S INDIVIDUAL EMPEROR STRINGETTES, FREE FROM ARTIFICIAL COLORING (AS USED IN HOSPITALS)." -- Monty Python From dewayne@warpspeed.com Fri May 02 10:42:47 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 KAA17790 for ; Fri, 2 May 1997 10:42:44 -0500 (CDT) Received: from [204.118.182.22] by warpspeed.com with ESMTP (Eudora Internet Mail Server 1.1.2); Fri, 2 May 1997 08:42:37 -0700 X-Sender: dewayne@odo.warpspeed.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 2 May 1997 08:42:32 -0700 To: ss@tapr.org, ss-sta@tapr.org From: Dewayne Hendricks Subject: A word on comments for the SS NPRM Comments are due at the FCC for the SS NPRM on Monday. I thought that I would post some information on how to do this and a few other things that come to mind: o Comments are due on or before May 5, 1997, and reply comments are due on or before June 5, 1997. To file formally in this proceeding, you must file an original and four copies of all comments and reply comments. If you want each Commissioner to receive a personal copy of your comments, you must file an original plus nine copies. You should send comments and reply comments to the Office of the Secretary, Frederal Communications Commission, Washington, DC 20554. Refer to WT Docket No. 97-12 at the start of your comments or reply comments. o If you miss the Monday deadline, and you feel that you have something to say on this rulemaking, then file your comments as soon as you can. The FCC is usually quite liberal in accepting late filed comments in amateur radio rulemakings. o TAPR will be filing its comments on this rulemaking on Monday. After Monday, they will be available for examination at the TAPR website . o It is our intention to have all of the comments and reply comments that are filed available for examination on the TAPR website. They will be available as soon as we can get them up there, so please be patient. Finally I'd like to make an editorial comment. In the petition for rulemaking phase of this proceeding (RM-8737), only 15 comments and 17 reply comments were filed. All in all, I'd say a pretty poor expression of interest in this matter by the amateur radio community!!! So, its 'crunch' time people!!!! Time for you to stand up and be counted in Washington on this issue. When this rulemaking is concluded and you find that you don't care for the final spread spectrum rules that come out of it, you'll only have yourselves to blame!! -- Dewayne Chair TAPR Regulatory Affairs Committee -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 wd5ivd@tapr.org Fri May 02 14:16:08 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 OAA10075; Fri, 2 May 1997 14:16:06 -0500 (CDT) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 2 May 1997 14:11:47 -0500 To: ss@tapr.org, "TAPR Spread Sprctrum" From: "Greg Jones, WD5IVD" Subject: Re: [SS:1334] A word on comments for the SS NPRM Very good comments Dewayne. Just to added, there is a format for filing. If you have filed before, then you have a format you like, but for those that want to jump in I'll include an example outline below. Note: I don't provide any words for you to use -- I don't believe in sending out example filings for people to copy and mail in. While the effort is sometime well placed, people seem to just copy it without actually putting it in their own words -- which the FCC sees and sometime just count as one filing instead of many. You have to take the time and learn just a little and write about the issues important to you. That might be power control or power level, the rules that are still in place about detailed logging (don't forget they are still in place and not discussed in the docket), IDing issues, Freq of operations, or many of the others that have been discussed on this list and in the comments of the original rule making. Like Dewayne points out, if you are interested in this mode and the potential for experimenting and developing new systems, are you going to allow 30-50 people -- who are not all in favor of change -- determine what the FCC decides what you can do in our service. If you are looking for a format or how other have done it, there are only about 30+ examples on the TAPR SS web page (http://www.tapr.org/ss/rule_changes.html) regarding the comments and reply comments filed to date. If you are going to file, be sure to look over some of these and get a feel for how people have approached the filing. It is almost as important to file in the correct format as to make your point. This sounds silly -- but think about it. You don't have to write lots of page for a good filing either. Some of the best ones are just a few pages long. What I have below is simple enough. Tell the FCC who you are and a little about yourself and why you are filing. Tell them what you want changed or deleted or added. Then explain why this is the case for each change, delete, or add. Then tell them again what you want changed or deleted or added. Then say sign your name. Cheers - Greg -------- Before the Federal Communications Commission Washington, D. C. 20554 In the Matter of ) WT Docket No. 97-12 ) Amendment of the Amateur Service ) RM-8737 Rules to Provide For ) Greater Use of Spread ) Spectrum Communication ) Technologies ) To: The Commission COMMENTS OF John Q Amateur, Callsign Your Address City, State Zip telephone or e-mail address (optional) February 26, 1996 (the current date :-) Introduction xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx A typically intro explains to the FCC who you are and why you are writing in a few paragraphs. Overview xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx In a few paragraphs say what you are going to outline and reinforce in the discussion section. Discussion xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx This is where you get to really make your case for whatever you are wanting to tell the FCC.Break you points into sections and explain each in detail and give reasons and examples for each. Conclusion xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx State what you are asking for again and conclude. Again, a short section. Say bye and sign, Your Name ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From buaas@wireless.net Fri May 02 17:27:03 1997 Received: from wireless.net (wireless.net [198.253.254.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id RAA24030 for ; Fri, 2 May 1997 17:26:54 -0500 (CDT) Received: (from buaas@localhost) by wireless.net (8.8.5/8.6.12) id PAA26543; Fri, 2 May 1997 15:42:20 -0700 (PDT) Date: Fri, 2 May 1997 15:42:20 -0700 (PDT) From: "Robert A. Buaas" Message-Id: <199705022242.PAA26543@wireless.net> To: ss@tapr.org Subject: my 97-12 Comments Cc: buaas@wireless.net Before the Federal Communications Commission Washington, D.C. 20554 In the Matter of ) WT Docket No.97-12 ) Amendment of Amateur Service ) RM-8737 Rules to Provide For ) Greater Use of Spread ) Spectrum Communication ) Technologies ) To: The Commission COMMENTS OF ROBERT A. BUAAS, K6KGS Background ---------- I have been licensed in the Amateur Radio Service since 1953. I earned my Amateur Extra Class license in 1961, when I was age 17. For most of my lifetime, I have enjoyed the privilege of experimenting with radio communications, a pasttime I truly love. In addition, I hold a Special Temporary Authorization (STA) dated December 27, 1994, that permits experimentation with any Spread Spectrum (SS) technology in all Amateur spectrum above 50 Megahertz. My involvement with Amateur SS dates back to its original contemplation by AMRAD, in whose STA I participated. I have contributed to the development of successful commercial Part-15 SS systems, and I am a charter member in IEEE P802.11 (the Wireless LAN Ethernet Standard development project). Introduction ------------ I view the adoption of the Rules Change contained in the proceeding with considerable dismay. While its claimed goal is to simplify and encourage SS, it in fact would contribute to the reduction or elimination of its use. Precious few of the commenters in this proceeding have any personal practical experience with SS. I find it curious that the spokespeople for the weak-signal interests, particulary Tynan of AMSAT, continue to present their conjectures of doom as fact, without bothering to conduct any realistic tests to validate their claims. Recently, I was invited to speak at the NASA Jet Propulsion Laboratory to Amateurs interested in the current state of affairs in Amateur SS. That opportunity was particularly rewarding, in that some of those same members are responsible for the SS technology used in NASA’s deep space weak-signal communications. The concerns of the FM/repeater community are also unfounded, and I address their situation in the Discussion below. That Commercial interests, particulary Part-15 promoters, seek parity with Amateur operators in the context of this proceeding seems to me to be entirely inappropriate. Metrocom and Symbol Technologies wish to advance their business interests at the expense of Amateur Radio operators opportunity and earned privilege at advancing the State of the Art in Radio Communication. Such is one of the Purposes of the Amateur Radio Service. Part-15 proponents knew and continue to know the Rules and relative priorities of the two Services when they chose to enter the business. Such are the risks of business, and they deserve to abide by their decisions. Summary ------- I urge that Commission turn aside this proposal in favor on one which implements the spirit of the environment provided for participants of the STA(s), to wit, (a) operation in any Amateur bands at 50 MHz and above without restriction, (b) use of any coding and/or modulation technology imaginable, (c) permit “in-mode” identification, and (d) eliminate restrictions, thus providing encouragement for designs that reduce interference. I made the same recommendation in my filings on RM-8737. To date, noone has come forward with any evidence that Amateur SS emissions have interfered with anyone. While I admire the elegance of Phil Karn’s proposal for Automatic Power Control (I enjoyed the several discussions we had during its gestation), and I encourage its use, I cannot agree that the specifics of this proposal belong in the Rules. We already have a provision that says: “Use Minimum Power.” Rules should apply to ALL systems, not just new ones. There are so many violations of this Rule now, I find it entirely inappropriate that only SS should be saddled with a proposal this specific. After all, it is the very nature of the specificity of the current Part 97 Rules for SS that have all but prevented its use. Spectral Partitioning, of the variety practiced currently, also is without merit. What will happen when the day comes that a novel weak- signal application wishes to use the very SS technology now proven for deep space, yet the Rules prevent it use in spectrum reserved for weak- signals? Such Rules have proven to be short sighted. The results of this proceeding will affect Amateur Radio for at least a decade. Few of us have sufficient vision to see that distance into the future. Let history be our guide. Discussion ---------- In this section, I wish to turn some illumination on the subject of conjectured INTERFERENCE to existing operations. This a popular topic, to say the least. I have been the subject of some criticism from those who dispute my claims that properly designed SS system have minimum liklihood of causing interference. Most vocal has been the Repeater Coordination community, yet they have to conduct any independent studies or come forward with documented cases of interference. They certainly have the means and expertise to do their own tests, yet they refuse, and complain all the while. Having once been a Frequency Coordinator, I understand their position, and their frustrations. They have only one degree of freedom, the Frequency Domain, in which to operate. Perhaps they have two, if one considers the Spatial Domain (stations that would otherwise interfere unacceptably, were it not for the distance or terrain that separates them). The degree of freedom they don’t command is the Time Domain. Dealing in the Time Domain requires systems complexity that is currently beyond current Amateur practice. The consequence that Amateur repeaters cannot handle frequency agility has lead to the operational mentality that a Coordinated Repeater “owns” the frequency on which it operates, whether it is IN USE or NOT. Alternative use of its input frequency could mean denial-of-service to authorized repeater users, and thus is defined as INTERFERENCE. Notwithstanding, the Rules are very specific, saying that no Amateur station has any title to any particular frequency. Repeater Owners believe the contrary, and they act like it. Repeater Wars have been fought over single frequencies. What is fundamentally interesting is the NOT part of the notion above. The prevailing attitudes have lead to particularly low levels of spectral utilization in the Amateur VHF and UHF bands. This is obvious to anyone who looks casually but critically at consecutive scans on the face of a spectrum analyzer. On any one scan, there are very few spectral lines representing current usage. The situation is very dynamic, as repeater transmitters activate and deactive at essentially random times in response to the needs of their respective users. Several years ago, when I began designing STA experiments for assessing the coexistance potential in “densely populated” repeater spectrum, I began collecting real-time utilization data, principally for use in simulations, testing the merits of a variety of frequency and time hopping patterns. This data validated my operational experiences that the interference to existing system was negligable. Consider for a moment the age-old question: “Is there sound when a tree falls in the forest, if noone is around to hear it?” The following charts show that very little of the popular repeater spectrum is actually in use at any one instant. Conversely, much is available to time-agile systems on a minimum/non-interference basis. The vertical axis is percentage of total spectrum in use; the horizontal axis are the hours in a day. Predictably, certain times see more activity than others. What is not obvious is the low level of simultaneous demand. These charts show, even for the allegedly densely-populated Los Angeles area (for the most part, each of the 133 146-MHz and the 200 445-MHz repeater channels have multiple coordinations per channel), in the TIME domain, the spectrum utilization is well below ten percent (10%). 146010-147990 445000-449975 10 + 10 + | | * 08 + ** 08 + % | % | * * 06 + * * * 06 + ** * * U | * ** * U | * * ** S 04 + * S 04 + * ** ** E | ** * * * * E | * 02 + * * ** 02 + * |* |* * 00 +----+----+----+----+----+ 00 +----+----+----+----+----+ 0 5 10 15 20 25 0 5 10 15 20 25 HOUR OF DAY HOUR OF DAY The charts contained in Appendix-A further elaborate on these findings. The first set of 24 charts show the contiguous part of the 2-Meter repeater band hour by hour. The presentation is useful in seeing the probability of collision FHSS systems would experience. The vertical axis shows the frequency of occruance; the horizontal axis shows the number of possible collisions. The second set of 24 charts show data taken simultaneously with the 2-meter data, but for the 445-MHz band. These data conclusively show why our experimental systems achieved no measurable impact. THERE WASN’T ANY IMPACT TO BE HAD. Further, this situation is little different elsewhere. It is easy to see why various Commercial interests have launched efforts to reallocate Amateur spectrum to their Service(s). There is some good news here: given that Amateurs would embrace this technology, and rise to the technical challenges it poses (which are not minor), there need never again be denial of service for Amateurs needing to communicate. FH is one of the simplest and easiest SS systems in operation today. Most Amateur VHF/UHF transceivers contain all the elements needed to do FHSS. By design, they are not configured properly, and the software needed to acquire and maintain synchronization is missing. Most also require slight modifications to the Frequency Synthesizer. Of course, if this mode catches on, there will be little need for Frequency Coordinators -—their power and prestige will be gone. Simple public databases on the Internet will serve to negotiate and declare code sequences and timebase references. The examples given here are but few of the many possibilites for coding technology, SS representing a small piece along that continuum. My view is that the Amateur Rules should permit the widest possible interpretation and latitude. Writing Rules requires VISION; we seem to lack the very thing we most need now. Conclusion ---------- Spread Spectrum is a complicated art. Even the simplest SS system designs have been, to date, beyond the technical reach of all but the most advanced Amateurs. Yet, it offers considerable promise, not the least of which is much better spectral utilization than is the current practice. Perhaps more importantly, Amateur Radio is one of few vehicles for encouraging young people into taking up a professional careers in Radio Engineering. Without the freedom to try new ideas, those individuals will turn elsewhere. The Internet is currently a powerful draw. Fewer and fewer radio engineers are entering the field from college. I believe that it is the Commission’s responsibility to nurture this Service, not limit it or contribute to its demise. I urge you to see the detractors in their true light, and adopt the proposal I make in the Summary above. RESPECTFULLY SUBMITTED, By_______________________ Robert A. Buaas, K6KGS May 2, 1997 Mailing Address: 10044 Adams Ave. #108 Huntington Beach, CA 92646 E-Mail: buaas@wireless.net ----------------------------------------------------------------------------- APPENDIX-A 146010-147990 hour-24 146010-147990 hour-01 30 + 30 + | | | * | * | * | % | % | 20 + * 20 +* S | S | A | A | M | M | P | * P | L 10 +* L 10 + * E | E | S | S | | * | | * | * 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 146010-147990 hour-02 146010-147990 hour-03 30 + * 30 + | | | | | | % | % | 20 + 20 + S | S | A | A | M | M | P | P | * L 10 + L 10 + E | E | S | S | | * | | | * 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 146010-147990 hour-04 146010-147990 hour-05 30 + 30 + | | | | | | % | % | 20 + 20 + S | S | A | * A | ** M | M | * P | * P | * * L 10 + L 10 + E | E |** S | * S | * | | | * | * 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 146010-147990 hour-06 146010-147990 hour-07 30 + 30 + | | | | | | % | % | 20 + * 20 + S | * S | * A | * A | * M | M | P | P | ** L 10 + * * L 10 + E | * E | * S |* S | *** | * * | * * | * ** | * ** 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 146010-147990 hour-08 146010-147990 hour-09 30 + 30 + | | | | | | * % | % | 20 + 20 + * S | S | A | A | * M | * * M |* P | P | L 10 + * *** L 10 + E | * * E | * S | * S | | * | ** | ** ** | ** 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 146010-147990 hour-10 146010-147990 hour-11 30 + 30 + | | | | | | % | % | 20 + * 20 + S | S | * A | A | * M | * M | * P | * P | L 10 + ** L 10 + ** * E | * E | * S |* * * S | * | | * | ** | * * 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 146010-147990 hour-12 146010-147990 hour-13 30 + 30 + | | | | | | % | % | 20 + 20 + * S | * S | * * A | * A | M | ** M | * P | P | L 10 + * * L 10 + * E | E | * S | * S | | * | * | * ** |** *** 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 146010-147990 hour-14 146010-147990 hour-15 30 + 30 + | | | | | | % | * % | 20 + * 20 + S | S | A | * A | * M | M | * P | * P | * * * L 10 + * L 10 + E | E | * S | * * S | ** | | * *** | *** | * 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 146010-147990 hour-16 146010-147990 hour-17 30 + 30 + | | | | | | % | % | 20 + 20 + S | * S | A | * A | * M | M | * P | * P | * * * L 10 + * * L 10 + * E | * E | * S | * ** S | * | * |* * | * * | ** 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 146010-147990 hour-18 146010-147990 hour-19 30 + 30 + | | | | | * | % | * % | 20 + 20 + S | * S | A | A | * M | M | * * P | * P | * L 10 + L 10 + * * E |* * E | S | S | * | * | ** * | * | * * 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 146010-147990 hour-20 146010-147990 hour-21 30 + 30 + | | | | | | % | % | 20 + 20 + S | S | A | * A | M | * M | ** P | ** * P | * L 10 + * L 10 + * * E | E | * * * S | * S | * | ** * | * | * * | ** * 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 146010-147990 hour-22 146010-147990 hour-23 30 + 30 + | | * | | * | | % | % | 20 + ** 20 + S | * S | * A | * A | M | M |* P | P | * L 10 + * * L 10 + E | E | S | S | | * | |* * | * 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 445000-449975 hour-24 445000-449975 hour-01 30 + 30 + | * | | |* | | % | % | 20 + 20 + * S | S | A | * A | M | M | P | P | ** L 10 + L 10 + * * E | E | S | * S | | | * | ** | * 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 445000-449975 hour-02 445000-449975 hour-03 30 + 30 + |* | | | | | % | % | 20 + 20 +* S | S | A | A | M | M | P | P | L 10 + L 10 + E | E | S | S | * | * | * | * * | *** 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 445000-449975 hour-04 445000-449975 hour-05 30 + 30 + | | | | | | % | % | 20 + 20 + S | S |* A | A | * M | M | * P | P | L 10 + L 10 + E | * E | ** * S | S | * | * * | *** | * | * 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 445000-449975 hour-06 445000-449975 hour-07 30 + 30 + | | | | | | % | % | 20 + 20 + S | S | A | A | M | M | P | P | * L 10 + ** L 10 + * * * E | * * E | * * S | * S | * * * | ** * ***** ** * | * ** |* ** * *** | ** *** 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 445000-449975 hour-08 445000-449975 hour-09 30 + 30 + | | | | | | % | % | 20 + 20 + S | S | A | A | M | M | * P | * * * P | ** L 10 + * * * L 10 + * E | * E | * ** S | * S | | ** * * | * *** | * *** | ** **** 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 445000-449975 hour-10 445000-449975 hour-11 30 + 30 + | | | | | | % | % | 20 + 20 + S | S | A | A | M | M | ** P | P | L 10 + * * L 10 + * E | * * ** * E | * ** S | * S | ** * ** | ** * ** | |* **** * | * *** 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 445000-449975 hour-12 445000-449975 hour-13 30 + 30 + | | | | | | % | % | 20 + 20 + S | S | A | A | M | M | P | * P | * L 10 + * ** *** L 10 + * * E | * E | * * S | S | *** | ***** | * ** * *** | **** | * * 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 445000-449975 hour-14 445000-449975 hour-15 30 + 30 + | | | | | | % | % | 20 + 20 + S | S | A | A | M | * M | P | P | L 10 + *** L 10 + * * ** E | * * E | * * * * S | * *** S | * * | ** | * * | * ** | * ** 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 445000-449975 hour-16 445000-449975 hour-17 30 + 30 + | | | | | | % | % | 20 + 20 + S | S | A | A | M | M | P | P | * L 10 + * * * L 10 + * E | * * * E | * ** S | * ** * S | *** ** | * ** * | * *** | * ** | * ** 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 445000-449975 hour-18 445000-449975 hour-19 30 + 30 + | | | | | | % | % | 20 + 20 + S | S | A | A | * M | M | P | P | ** L 10 + * * L 10 + * * E | * * * * E | ** * S | * * * S | | **** * | * ** | *** **** * | ** ** 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 445000-449975 hour-20 445000-449975 hour-21 30 + 30 + | | | | | | % | % | 20 + 20 + S | S | A | A | M | M | * P | * * P | ** L 10 + * * L 10 + * E | ** * E | ** * S | ** * S | * * | * * | * * | * * * | ** * 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT 445000-449975 hour-22 445000-449975 hour-23 30 + 30 + | | | | * | | % | % |* 20 + 20 + S | S | A | A | ** M | * * M | P | ** P | L 10 + * L 10 + E | ** E | S | * S | * | * * | ** | ** | ** 00 +----+----+----+----+----+----+ 00 +----+----+----+----+----+----+ 0 5 10 15 20 25 30 0 5 10 15 20 25 30 CARRIERS PRESENT CARRIERS PRESENT From karn@qualcomm.com Fri May 02 17:50:10 1997 Received: from laptop.ka9q.ampr.org (dhcp-855107462.qualcomm.com [129.46.101.144]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id RAA25368 for ; Fri, 2 May 1997 17:50:08 -0500 (CDT) Received: by laptop.ka9q.ampr.org id m0wNPmE-000RurC (Debian Smail-3.2 1996-Jul-4 #2); Fri, 2 May 1997 21:21:42 +0000 (UTC) Message-Id: Date: Fri, 2 May 1997 21:21:42 +0000 (UTC) From: Phil Karn To: ss@tapr.org Reply-To: karn@qualcomm.com In-reply-to: <3.0.32.19970429142033.006c8184@pcmail.micro.ti.com> (aeynon@micro.ti.com) Subject: Re: [SS:1307] Re: SS ID >I don't suppose we could settle for something subtle like the >spreading sequence itself? For instance, using two 10-stage The last thing we want are any hard-coded rules specifying the spreading sequences we can use. That's what we're trying to get away from in this proceeding. Phil From karn@qualcomm.com Fri May 02 17:52:11 1997 Received: from laptop.ka9q.ampr.org (dhcp-855107462.qualcomm.com [129.46.101.144]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id RAA25431 for ; Fri, 2 May 1997 17:52:09 -0500 (CDT) Received: by laptop.ka9q.ampr.org id m0wNQ2M-000Rx1C (Debian Smail-3.2 1996-Jul-4 #2); Fri, 2 May 1997 21:38:22 +0000 (UTC) Message-Id: Date: Fri, 2 May 1997 21:38:22 +0000 (UTC) From: Phil Karn To: ss@tapr.org Reply-To: karn@qualcomm.com In-reply-to: <199704292054.QAA09729@smtp1.erols.com> (message from Tony McConnell on Tue, 29 Apr 1997 15:58:01 -0500 (CDT)) Subject: Re: [SS:1310] Re: SS ID >yes in-band idong would be iding in the data payload, as with packet now. Perhaps we could call it "in-mode" IDing, to emphasize that the ID is sent with the same modulation mode. "In-band" IDing still implies only that the ID is in the same frequency band with the exotic mode. >in a way a narrow band id makes less sense than a wide one. from the >prospective >of the narrow band user, he can't be sure that the id he can hear is the wide >signal that is making him misserable. Not unless the narrow band ID is set such that you're not likely to hear it unless the associated wide band signal is already interfering with you. This is fairly straightforward if you can make assumptions about the RX bandwidths of the narrowband stations that you may interfere with. >how about a continous morse or mcw of the carrier amplitude while in use? say Ordinarily there would be no discrete carrier component in a SS signal. Though you could deliberately inject one, as in my earlier proposal to unbalance the mixer. >the supposed interefernce is. but any narrow slow id becomes silly with the >sort of transmissions that will likely the the use of these radios. This is a good point -- I don't know why I didn't think of it earlier. I guess I was thinking of relatively slow links on the lower bands where QRM is more of an issue. Here transmissions would be fairly lengthy, long enough for a CWID. Phil From karn@qualcomm.com Fri May 02 17:52:43 1997 Received: from laptop.ka9q.ampr.org (dhcp-855107462.qualcomm.com [129.46.101.144]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id RAA25473 for ; Fri, 2 May 1997 17:52:41 -0500 (CDT) Received: by laptop.ka9q.ampr.org id m0wNQUP-000Rx4C (Debian Smail-3.2 1996-Jul-4 #2); Fri, 2 May 1997 22:07:21 +0000 (UTC) Message-Id: Date: Fri, 2 May 1997 22:07:21 +0000 (UTC) From: Phil Karn To: ss@tapr.org Reply-To: karn@qualcomm.com In-reply-to: <3366043B.35E8@ix.netcom.com> (message from Don Labriola on Tue, 29 Apr 1997 21:35:17 -0500 (CDT)) Subject: Re: [SS:1317] Re: SS ID >Just a thought: If the power already has to be controlled, why not >increase the power to ID in CW, etc.,. If this is infrequent (every 10 I am strongly opposed to any suggestion of increasing power just to ID. That is a good way to interfere with your ID even when your regular emission doesn't bother anybody. And as a result, you'll become notorious as that "SS interferer" even if the only thing interfering is your CWID!! Phil From tony@spacey.net Fri May 02 17:56:48 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 RAA25563 for ; Fri, 2 May 1997 17:56:46 -0500 (CDT) Received: from MAX92.SPACEY.NET (MAX92.SPACEY.NET [205.152.52.241]) by surfergirl.spacey.net (8.7.3 Version 1.1 Build 565/8.7.3) with SMTP id HAA00028 for ; Sat, 03 May 1997 07:00:32 -0400 (Eastern Daylight Time) Date: Sat, 03 May 1997 07:00:32 -0400 (Eastern Daylight Time) Message-Id: <199705031100.HAA00028@surfergirl.spacey.net> X-Sender: tony@spacey.net 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 Lanier Subject: SS Questions for Rule Filing Hi all, This ID issue concerning SS has generated alot of responses - at least we're interested in talking about SOMETHING! I have some questions, though, that I would like to ask: if a packet station is causing interference, how is that station supposed to be identified? Can a weak signal guy or a DX'er identify the interfering packet station? I realize that packet sends an ID inside a packet header (so I was told), but do you need a special device to decode it? If this is so, then I see no reason why SS should be treated any different than other modes. We should all follow the minimum power requirement for communication AT ALL TIMES, no matter what modulation method we choose. It makes no sense to use 50W to transmit only 5 miles. And if packet ID's itself within the packet itself, why can't SS ID itself within a SS transmission? I'd also like to know if someone knows of a study comparing the output spectrum of a narrowband transmitter to a SS transmitter, both operating at , say 50 watts? In other words, would a SS system transmitting at 100 watts overpower a narrowband system transmitting at 10 watts, under ideal conditions? Is there a linear relationship to this? I would like to know the answer to these questions before I submit a filing with the FCC. At least this way I don't look like an idiot! Maybe a better requirement than automatic power control would be FEC circuitry. Then the output power could be lowered - that's a form of power control! Tony KE4ATO From wd5ivd@tapr.org Fri May 02 18:39:54 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 SAA05812 for ; Fri, 2 May 1997 18:39:52 -0500 (CDT) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 2 May 1997 18:36:12 -0500 To: ss@tapr.org From: "Greg Jones, WD5IVD" Subject: Re: [SS:1338] Re: SS ID >>yes in-band idong would be iding in the data payload, as with packet now. > >Perhaps we could call it "in-mode" IDing, to emphasize that the ID is sent >with the same modulation mode. "In-band" IDing still implies only that the ID >is in the same frequency band with the exotic mode. Yes. After reading Lyle's and Bob's comments, "in-mode" matches what other modes do (like ATV, Voice, etc) in describing how the ID is handled. I am redefining my term. Greg ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From jeff@mich.com Fri May 02 19:35:31 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 TAA09006; Fri, 2 May 1997 19:35:30 -0500 (CDT) Received: from alfalfa (pm003-18.dialip.mich.com [198.108.16.53]) by server1.mich.com (8.8.4/8.8.4) with SMTP id UAA16339; Fri, 2 May 1997 20:36:17 -0400 Message-Id: <2.2.32.19970503003414.009768a4@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, 02 May 1997 20:34:14 -0400 To: ss-sta@tapr.org, ss@tapr.org From: Jeff King / Kathy King Subject: Re: [SS-STA:357] A word on comments for the SS NPRM Cc: dewayne@warpspeed.com At 10:52 AM 5/2/97 -0500, Dewayne Hendricks wrote: > > Comments are due at the FCC for the SS NPRM on Monday. Due in there hot little hands or postmarked by Monday? If in their hands by Monday, what is the best way to insure this will happen considering it is Friday evening.... FAX or e-mail? By best way, I mean the way that it is taken the most seriously. 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 dewayne@warpspeed.com Fri May 02 19:56:55 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 TAA09814 for ; Fri, 2 May 1997 19:56:52 -0500 (CDT) Received: from [204.118.182.22] by warpspeed.com with ESMTP (Eudora Internet Mail Server 1.1.2); Fri, 2 May 1997 17:56:47 -0700 X-Sender: dewayne@odo.warpspeed.com Message-Id: In-Reply-To: <2.2.32.19970503003414.009768a4@mail.mich.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 2 May 1997 17:52:03 -0700 To: Jeff King / Kathy King , ss-sta@tapr.org, ss@tapr.org From: Dewayne Hendricks Subject: Re: [SS-STA:357] A word on comments for the SS NPRM At 8:34 PM -0400 5/2/97, Jeff King / Kathy King wrote: >At 10:52 AM 5/2/97 -0500, Dewayne Hendricks wrote: >> >> Comments are due at the FCC for the SS NPRM on Monday. > >Due in there hot little hands or postmarked by Monday? If in >their hands by Monday, what is the best way to insure this >will happen considering it is Friday evening.... FAX or e-mail? >By best way, I mean the way that it is taken the most seriously. > It means that your comments have to be at the FCC on Monday. The Commission doesn't take formal comments sent via fax or email at this time. As for the delivery method, I leave that to you. There are still several options available to you that will get your comments to the Commission by Monday. -- 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 lylej@azstarnet.com Fri May 02 21:19:40 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 VAA14791 for ; Fri, 2 May 1997 21:19:39 -0500 (CDT) Received: from tomswift (usr3ip29.azstarnet.com [169.197.4.29]) by mailhost.azstarnet.com (8.8.3-p/8.8.5) with SMTP id TAA08231 for ; Fri, 2 May 1997 19:19:06 -0700 (MST) Message-Id: <3.0.32.19970502191654.00723bac@pop.azstarnet.com> X-Sender: lylej@pop.azstarnet.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 02 May 1997 19:17:40 -0700 To: ss@tapr.org From: Lyle Johnson Subject: Re: [SS:1340] SS Questions for Rule Filing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >>I have some questions, though, that I would like to ask: if a packet station >is causing interference, how is that station supposed to be identified? By the mode it is: packet. >Can a weak signal guy or a DX'er identify the interfering packet station? Yes, with a packet decoder (TNC or equivalent). >I realize that packet sends an ID inside a packet header (so I was told), but >do you need a special device to decode it? Yes, you do. But a packet ID is perfectly legal (see Part 97.119(b)(3)). >If this is so, then I see no reason why SS should be treated any different >than other modes. That seems perfectly logical to me, too. Please comment to the FCC! >We should all follow the minimum power requirement for >communication AT ALL TIMES, no matter what modulation method we choose. Already the *law* for all modes, including SS. See Part 97.313(a). >...Maybe a better requirement than automatic power control would be FEC >circuitry. Then the output power could be lowered - that's a form of power >control! Part 97.313(a) again. Why have any *requirement* beyond this? Let the technical reasons drive the design, not administrative ones. I don't think the proposed automatic power control rule allows amateur roundtables, or broadcasts (like satellite telemetry) or a number of other traditional amateur radio applications. Cheers, Lyle From jeff@mich.com Sat May 03 13:37:41 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 NAA28490 for ; Sat, 3 May 1997 13:37:40 -0500 (CDT) Received: from alfalfa (pm003-23.dialip.mich.com [198.108.16.58]) by server1.mich.com (8.8.4/8.8.4) with SMTP id OAA24920 for ; Sat, 3 May 1997 14:38:50 -0400 Message-Id: <2.2.32.19970503183626.00bc2888@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, 03 May 1997 14:36:26 -0400 To: ss@tapr.org From: Jeff King / Kathy King Subject: reply comments on RM-8737 Anyone have any idea how to locate reply comments to 8737 on the FCC web site? Specifically, I am looking for the ARRL's. They are not on TAPR's site. Did every search I could think of, but no luck. Thanks -Jeff From dewayne@warpspeed.com Sat May 03 15:14:20 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 PAA04736 for ; Sat, 3 May 1997 15:14:17 -0500 (CDT) Received: from [204.118.182.22] by warpspeed.com with ESMTP (Eudora Internet Mail Server 1.1.2); Sat, 3 May 1997 13:14:11 -0700 X-Sender: dewayne@odo.warpspeed.com Message-Id: In-Reply-To: <2.2.32.19970503183626.00bc2888@mail.mich.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 3 May 1997 13:13:31 -0700 To: ss@tapr.org From: Dewayne Hendricks Subject: Re: [SS:1345] reply comments on RM-8737 At 1:39 PM -0500 5/3/97, Jeff King / Kathy King wrote: >Anyone have any idea how to locate reply comments to >8737 on the FCC web site? Specifically, I am looking >for the ARRL's. They are not on TAPR's site. Did every >search I could think of, but no luck. The answer is simple. Those comments are not on the FCC site. The FCC has only been posting comments on their site that have been made available to them in electronic form for selected rulemakings where they had setup a procedure for such submissions. -- 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 karn@qualcomm.com Sun May 04 01:35:11 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 BAA01501 for ; Sun, 4 May 1997 01:35:09 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id XAA01320; Sat, 3 May 1997 23:34:39 -0700 (PDT) Date: Sat, 3 May 1997 23:34:39 -0700 (PDT) Message-Id: <199705040634.XAA01320@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: <199704301309.AA15183@world.std.com> (wpns@world.std.com) Subject: Re: [SS:1324] SS ID using "positive AM" >Why is it silly? A couple of messages back I saw a proposal to >increase the output power (by say 3dB) to ID(*), what's wrong with >that? Increasing the power ensures that the ID is heard, the What about high speed packet SS transmissions? They're not going to be long enough to CWID at any reasonable speed. Phil From karn@qualcomm.com Sun May 04 13:48:23 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 NAA16979 for ; Sun, 4 May 1997 13:48:21 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id LAA12950; Sun, 4 May 1997 11:47:49 -0700 (PDT) Date: Sun, 4 May 1997 11:47:49 -0700 (PDT) Message-Id: <199705041847.LAA12950@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org Subject: My SS comments to the FCC I went ahead and drafted comments of my own to the FCC on the SS NPRM. I Fedexed them out yesterday afternoon, and put them up on my own web page. See You'll probably be happy to see that I officially changed my mind regarding the automatic power control argument. Phil From aeynon@micro.ti.com Sun May 04 14:36:15 1997 Received: from jester.ti.com (jester.ti.com [192.94.94.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA20809 for ; Sun, 4 May 1997 14:36:11 -0500 (CDT) Received: from reliant.micro.ti.com ([158.218.63.15]) by jester.ti.com (8.8.5) with ESMTP id OAA16669 for ; Sun, 4 May 1997 14:35:27 -0500 (CDT) Received: from yeshiva.micro.ti.com (aeynon@yeshiva.micro.ti.com [158.218.60.73]) by reliant.micro.ti.com (8.8.5/8.8.5) with ESMTP id OAA26478; Sun, 4 May 1997 14:35:27 -0500 (CDT) From: "Alan J. Eynon" Received: (from aeynon@localhost) by yeshiva.micro.ti.com (8.8.5/8.8.5) id OAA10735; Sun, 4 May 1997 14:35:25 -0500 (CDT) Date: Sun, 4 May 1997 14:35:25 -0500 (CDT) Message-Id: <199705041935.OAA10735@yeshiva.micro.ti.com> To: ss@tapr.org Subject: Re: SS ID Cc: aeynon@reliant.micro.ti.com Phil has raised some good points: >Perhaps we could call it "in-mode" IDing, to emphasize that the ID is sent >with the same modulation mode. "In-band" IDing still implies only that the ID >is in the same frequency band with the exotic mode. and >The last thing we want are any hard-coded rules specifying the >spreading sequences we can use. That's what we're trying to get >away from in this proceeding. although I have to add that these two goals may be contradictory from a spread spectrum identification point of view. If, for instance, we are allowed to choose our own spreading sequences, then the only way for the authorities to find out which ones we're using would be for us to include the tap points as part of the identification in the packet header. But to get to the packet header, they would have to despread the signal, which implies knowing what the spreading sequence is. As much as they may do it themselves, governments don't take kindly to being put into these Catch-22 situations. It would seem that we can only postulate two scenarios: * In-mode identification, in which case the authorities will want to have some record (or assignment) of what spreading sequences we are using. The in-mode ID could therefore be very brief. * Some form of external identification, in which case the external ID signal would have to indicate what spreading sequence we are using. I believe this coincides with Phil's original proposal to inject a portion of the carrier back into the spread signal. Any in-mode identification also carried by the spread signal would therefore be needed only for data-derived purposes, such as routing. We can't (read "won't be allowed to") have it both ways. 73 Alan From karn@qualcomm.com Mon May 05 02:01:44 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 CAA24812 for ; Mon, 5 May 1997 02:01:38 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id AAA14158; Mon, 5 May 1997 00:01:06 -0700 (PDT) Date: Mon, 5 May 1997 00:01:06 -0700 (PDT) Message-Id: <199705050701.AAA14158@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: <3.0.32.19970430112357.006a15f0@pcmail.micro.ti.com> (aeynon@micro.ti.com) Subject: Re: [SS:1329] Re: SS ID >is not as bad as you think. IS-95 (and Phil can correct me as I'm writing >without my notes in front of me) uses 1024 chip sequences, and the search >silicon brute forces each one in milliseconds. Even assuming that you have >to check the entire 1025 member family of that Gold code I proposed, it >should be do-able in seconds. IS-95 uses a pair of spreading sequences, one short (32768 chips) and one very long (2^41-1). Everybody uses the same sequences, but they're offset from each other in time. You are talking about people who barely understand what a bit is, and you're expecting them to go out and buy or build some special device just so they can decode your transmissions to identify you in case you interfere with them? I think this is rather unlikely. Having started this discussion, I don't really think any form of CWID should be mandatory. Hams have been tracking down unidentified QRM for years, the same will be true if there are problems with SS. Phil From aeynon@micro.ti.com Mon May 05 09:26:30 1997 Received: from jester.ti.com (jester.ti.com [192.94.94.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id JAA21432 for ; Mon, 5 May 1997 09:26:29 -0500 (CDT) Received: from reliant.micro.ti.com ([158.218.63.15]) by jester.ti.com (8.8.5) with ESMTP id JAA15355 for ; Mon, 5 May 1997 09:25:56 -0500 (CDT) Received: from admin2.micro.ti.com (postmaster@admin2.micro.ti.com [158.218.63.17]) by reliant.micro.ti.com (8.8.5/8.8.5) with ESMTP id JAA00317 for ; Mon, 5 May 1997 09:25:55 -0500 (CDT) Received: from aspc0662.micro.ti.com ([158.218.60.85]) by admin2.micro.ti.com (post.office MTA v2.0 0813 ID# 0-11540) with SMTP id AAA14500; Mon, 5 May 1997 09:25:52 -0500 Message-Id: <3.0.32.19970505092745.0069d458@pcmail.micro.ti.com> X-Sender: aeyn@pcmail.micro.ti.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 05 May 1997 09:27:45 -0500 To: ss@tapr.org From: "Alan J. Eynon" Subject: Re: SS ID Cc: aeyn@micro.ti.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sorry if this is a repetition; I've had some mailer difficulties. Phil raises some good points: >Perhaps we could call it "in-mode" IDing, to emphasize that the ID is sent >with the same modulation mode. "In-band" IDing still implies only that the ID >is in the same frequency band with the exotic mode. and >The last thing we want are any hard-coded rules specifying the >spreading sequences we can use. That's what we're trying to get >away from in this proceeding. What I wanted to point out is that these two goals are mutually exclusive. If, by some chance, we were allowed to pick any spreading sequence we wished, and at the same time were only required to use in-mode identification, the authorities then would be faced with the situation where (presumably) the only way to find out what spreading sequence we were using would be to look inside the packet header for the appropriate ID information. To do this, though, they would have to despread the signal - which requires knowing the spreading sequence. As much as they may create them themselves, governments normally don't take kindly to these Catch-22 situations. It would seem that only two scenarios are viable: * In-mode identification, in which case the authorities will want to have our spreading sequences on record, or otherwise limit us to an easily searched small number of sequences. Too, the spreading sequences would likely be a matter of public record, so that any listener with suitable equipment could despread them - just like with the other modes. * External identification, in which the amateur ID and spreading sequence generator tap points can be determined from some narrowband aspect of our signals. I believe this was what Phil was getting at in his earlier posting about reinjecting a portion of the carrier. The in-mode ID, if used, would only be data-driven, e.g. as a packet routing address. You can't (read: "won't be allowed to") have it both ways. 73 Alan P.S. Question: wouldn't an in-mode ID then presume a standard packet header, data rate, link management protocol, etc? Software Development Systems, Stafford, Texas Instruments, +1 281-274-2943 ------------------------------------------------------------------------- "I told you, I'm not allowed to argue unless you've paid!" -- Monty Python From aeynon@micro.ti.com Mon May 05 10:40:37 1997 Received: from dragon.ti.com (dragon.ti.com [192.94.94.61]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id KAA27082 for ; Mon, 5 May 1997 10:40:36 -0500 (CDT) Received: from reliant.micro.ti.com ([158.218.63.15]) by dragon.ti.com (8.8.5) with ESMTP id KAA27562 for ; Mon, 5 May 1997 10:40:03 -0500 (CDT) Received: from admin2.micro.ti.com (postmaster@admin2.micro.ti.com [158.218.63.17]) by reliant.micro.ti.com (8.8.5/8.8.5) with ESMTP id KAA09105 for ; Mon, 5 May 1997 10:39:57 -0500 (CDT) Received: from aspc0662.micro.ti.com ([158.218.60.85]) by admin2.micro.ti.com (post.office MTA v2.0 0813 ID# 0-11540) with SMTP id AAA25136 for ; Mon, 5 May 1997 10:39:47 -0500 Message-Id: <3.0.32.19970505104139.006881b8@pcmail.micro.ti.com> X-Sender: aeyn@pcmail.micro.ti.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 05 May 1997 10:41:40 -0500 To: ss@tapr.org From: "Alan J. Eynon" Subject: Re: [SS:1349] Re: SS ID Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sorry for the repetition; the mailer sat on the first version for over 24 hours - for reasons known only to itself. Software Development Systems, Stafford, Texas Instruments, +1 281-274-2943 -------------------------------------------------------------------------- "Now look, this isn't an argument; it's just contradiction." -- Monty Python From aeynon@micro.ti.com Mon May 05 11:00:33 1997 Received: from dragon.ti.com (dragon.ti.com [192.94.94.61]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA28446 for ; Mon, 5 May 1997 11:00:32 -0500 (CDT) Received: from reliant.micro.ti.com ([158.218.63.15]) by dragon.ti.com (8.8.5) with ESMTP id KAA03341 for ; Mon, 5 May 1997 10:59:57 -0500 (CDT) Received: from admin2.micro.ti.com (postmaster@admin2.micro.ti.com [158.218.63.17]) by reliant.micro.ti.com (8.8.5/8.8.5) with ESMTP id KAA11359 for ; Mon, 5 May 1997 10:59:55 -0500 (CDT) Received: from aspc0662.micro.ti.com ([158.218.60.85]) by admin2.micro.ti.com (post.office MTA v2.0 0813 ID# 0-11540) with SMTP id AAA29633 for ; Mon, 5 May 1997 10:59:54 -0500 Message-Id: <3.0.32.19970505110146.0069daa4@pcmail.micro.ti.com> X-Sender: aeyn@pcmail.micro.ti.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 05 May 1997 11:01:47 -0500 To: ss@tapr.org From: "Alan J. Eynon" Subject: Re: [SS:1350] Re: SS ID Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Phil, Thanks for the IS-95 spreading sequence corrections: >IS-95 uses a pair of spreading sequences, one short (32768 chips) >and one very long (2^41-1). Everybody uses the same sequences, but >they're offset from each other in time. Just out of curiosity, what's the mean acquisition time for the short sequence? >You are talking about people who barely understand what a bit is, and >you're expecting them to go out and buy or build some special device >just so they can decode your transmissions to identify you in case you >interfere with them? I think this is rather unlikely. Oh, I entirely agree. When I jumped in, the context of the discussion (as I understood it) was "what sort of identification schemes could we come up with, given a $20-35 spending cap on the implementation?". I had been slanting my outlook towards the needs of FCC monitoring more than what other amateurs would use. As you mention: >Having started this discussion, I don't really think any form of CWID >should be mandatory. Hams have been tracking down unidentified QRM >for years, the same will be true if there are problems with SS. any spread signal causing interference could still be found by DF. Sorry for any confusion this caused. Ready for next topic on which to violently agree. (^: 73 Alan Software Development Systems, Stafford, Texas Instruments, +1 281-274-2943 -------------------------------------------------------------------------- "DESTROY 99% OF KNOWN HOUSEHOLD PESTS WITH PRE-SLICED, RUSTPROOF, EASY TO HANDLE, LOW CALORIE SIMPSON'S INDIVIDUAL EMPEROR STRINGETTES, FREE FROM ARTIFICIAL COLORING (AS USED IN HOSPITALS)." -- Monty Python From karn@qualcomm.com Mon May 05 17:07: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 RAA26846 for ; Mon, 5 May 1997 17:07:39 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id PAA26578; Mon, 5 May 1997 15:07:07 -0700 (PDT) Date: Mon, 5 May 1997 15:07:07 -0700 (PDT) Message-Id: <199705052207.PAA26578@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: <3.0.32.19970501095550.0069cacc@pcmail.micro.ti.com> (aeynon@micro.ti.com) Subject: Re: [SS:1333] SS ID >If the sequence is truly a pseudo-noise sequence generated by shift >registers, well, there's only so many sequences of a given length. One >can test each candidate by a method called sequence estimation. Let's There's a much easier way: the Massey-Berlekamp algorithm, widely used in decoding Reed-Solomon codes. If the spreading sequence is generated by a linear feedback shift register (LFSR) of length L stages, then the Massey-Berlekamp algorithm can quickly determine the taps and the starting state with a sample of only 2L chips from the sequence. If the taps are already known and only the starting state is to be determined, then only L chips of the sequence are needed. For large values of L, this is obviously a lot shorter than the sequence itself, which is 2^L-1 chips for a maximal length sequence. Phil From wd5ivd@tapr.org Mon May 05 17:53:24 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 RAA29002 for ; Mon, 5 May 1997 17:53:22 -0500 (CDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 5 May 1997 17:55:26 -0500 To: " Spread Spectrum " From: "Greg Jones, WD5IVD" Subject: Docket 97-12 Comments We have started the collection of comments from todays filings on Docket 97-12 on http://www.tapr.org/ss The following (listed below) are now available and we expect more to be made available in the coming weeks. These represent filings that the individuals/groups sent to us directly in electronic format (thanks!). Other selected filings will take time to get up on the web page, because copies must be made in Washington DC by our lawyers, mailed to a volunter who then scans them before being made available on the web page. If you filed on Docket 97-12 and would like your comments or reply comments in the future posted with everyone elses, please send them to wd5ivd@tapr.org Comments on Docket 97-12 available include (as of 5/5/97): Tucson Amateur Packet Radio Corp 5/5/97 Lyle V. Johnson, WA7GXD 5/5/97 Philip R. Karn, Jr, KA9Q 5/5/97 Robert A. Buaas, K6KGS 5/5/97 Central States VHF Society 5/5/97 William A. Tynan, W3XO 5/5/97 Cheers - Greg Jones, WD5IVD President TAPR ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From karn@qualcomm.com Mon May 05 18:47: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 SAA10505 for ; Mon, 5 May 1997 18:47:49 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id QAA26905; Mon, 5 May 1997 16:47:20 -0700 (PDT) Date: Mon, 5 May 1997 16:47:20 -0700 (PDT) Message-Id: <199705052347.QAA26905@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: <199705031100.HAA00028@surfergirl.spacey.net> (message from Tony Lanier on Fri, 2 May 1997 18:08:35 -0500 (CDT)) Subject: Re: [SS:1340] SS Questions for Rule Filing >I'd also like to know if someone knows of a study comparing the output >spectrum of a narrowband transmitter to a SS transmitter, both operating at >, say 50 watts? In other words, would a SS system transmitting at 100 watts >overpower a narrowband system transmitting at 10 watts, under ideal >conditions? Is there a linear relationship to this? The key figure is "power spectral density", which is simply the total transmitter power divided by the bandwidth. If you have a 100W transmitter spreading over 1 MHz, the power spectral density is 100/1e6 = .0001 W/Hz. If you have a 10 W narrowband transmitter operating in 3 KHz, then the power spectral density is .0033 W/Hz, which is 33.3 times or 15.2 dB stronger. So if everything else is the same (path loss, etc), the narrowband signal will still be 15.2 dB stronger than the wideband signal in the narrowband receiver even though the total transmitter power for the wideband signal is 10 dB greater. Phil From karn@qualcomm.com Mon May 05 19:33: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 TAA14364 for ; Mon, 5 May 1997 19:33:47 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id RAA27070; Mon, 5 May 1997 17:33:15 -0700 (PDT) Date: Mon, 5 May 1997 17:33:15 -0700 (PDT) Message-Id: <199705060033.RAA27070@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: <199705041935.OAA10735@yeshiva.micro.ti.com> (aeynon@micro.ti.com) Subject: Re: [SS:1349] Re: SS ID >We can't (read "won't be allowed to") have it both ways. Unless the FCC can be persuaded that any interference problems can be resolved without on-air identification of the interfering signal. This could be done in any number of ways: 1. Conventional DFing (many hams have plenty of experience in tracking down wideband power line noise, which isn't identified). 2. "Offline" coordination and notification schemes, such as simply letting the local ham community know what you're up to in the way of SS transmissions by means of packet bulletins, newsletter articles, meetings, and the like. Phil From karn@qualcomm.com Mon May 05 20:07: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 UAA16583 for ; Mon, 5 May 1997 20:07:02 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id SAA27142; Mon, 5 May 1997 18:06:30 -0700 (PDT) Date: Mon, 5 May 1997 18:06:30 -0700 (PDT) Message-Id: <199705060106.SAA27142@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: <3.0.32.19970505110146.0069daa4@pcmail.micro.ti.com> (aeynon@micro.ti.com) Subject: Re: [SS:1353] Re: SS ID >Just out of curiosity, what's the mean acquisition time for the >short sequence? A few seconds after power on. The phone takes about the same time to turn off the "NO SVC" led as a regular AMPS phone. Every CDMA cell transmits a "pilot" using the same PN sequence, but with a fixed time offset that is maintained by a GPS receiver at each cell. When the mobile phone switches on, it searches the entire 2^15 chip sequence space looking for correlation peaks from the cell pilots. It picks the strongest one and begins tracking it. The searching is done in special hardware that's part of the CDMA mobile station modem chip. Phil From lylej@azstarnet.com Mon May 05 20:22:40 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 UAA17405 for ; Mon, 5 May 1997 20:22:37 -0500 (CDT) Received: from tomswift (usr8ip30.azstarnet.com [169.197.9.30]) by mailhost.azstarnet.com (8.8.3-p/8.8.5) with SMTP id SAA01608 for ; Mon, 5 May 1997 18:22:00 -0700 (MST) Message-Id: <3.0.32.19970505181346.006e67b0@pop.azstarnet.com> X-Sender: lylej@pop.azstarnet.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 05 May 1997 18:20:36 -0700 To: ss@tapr.org From: Lyle Johnson Subject: Re: [SS:1351] Re: SS ID Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >...What I wanted to point out is that these two goals are mutually exclusive. I disagree. If the Amateur is using an unpublished, no-one-can-figure-it-out sequence, then he can't talk to another Amateur station. If he can't communicate with anyone else, what';s the point? On the other hand, if he can communicate with others, then his spreading code must be available easily to other Amateurs -- and thus to the FCC or anyone else who cares to listen in. If you try an dmake a case that this secretive Amateur is sending defense secrets across town to the foreigh embassy, well, he is already outside the law and a regulation requiring him to CWID is also going to be ignored...no? Cheers, Lyle From wd5ivd@tapr.org Mon May 05 23:08: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 XAA28477 for ; Mon, 5 May 1997 23:08:54 -0500 (CDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 5 May 1997 23:05:36 -0500 To: " Spread Spectrum " From: "Greg Jones, WD5IVD" Subject: Docket 97-12 I just added two more comments to the page. Greg ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From aeynon@micro.ti.com Tue May 06 08:40:31 1997 Received: from jester.ti.com (jester.ti.com [192.94.94.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id IAA17368 for ; Tue, 6 May 1997 08:40:29 -0500 (CDT) Received: from reliant.micro.ti.com ([158.218.63.15]) by jester.ti.com (8.8.5) with ESMTP id IAA28310 for ; Tue, 6 May 1997 08:39:57 -0500 (CDT) Received: from admin2.micro.ti.com (postmaster@admin2.micro.ti.com [158.218.63.17]) by reliant.micro.ti.com (8.8.5/8.8.5) with ESMTP id IAA23419 for ; Tue, 6 May 1997 08:39:57 -0500 (CDT) Received: from aspc0662.micro.ti.com ([158.218.60.85]) by admin2.micro.ti.com (post.office MTA v2.0 0813 ID# 0-11540) with SMTP id AAA24614 for ; Tue, 6 May 1997 08:39:54 -0500 Message-Id: <3.0.32.19970506084148.0069804c@pcmail.micro.ti.com> X-Sender: aeyn@pcmail.micro.ti.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 06 May 1997 08:41:48 -0500 To: ss@tapr.org From: "Alan J. Eynon" Subject: Re: SS ID Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >I disagree. If the Amateur is using an unpublished, >no-one-can-figure-it-out sequence, then he can't talk to another Amateur >station. If he can't communicate with anyone else, what';s the point? > >On the other hand, if he can communicate with others, then his spreading >code must be available easily to other Amateurs -- and thus to the FCC or >anyone else who cares to listen in. Okay, I agree that if this coordination is a matter of public record (for instance, via some established procedure - such as announcing it on the local repeater) then the authorities have their basis for monitoring. If you and I were to arrange a spread spectrum test between ourselves without following such procedures, however, it might work perfectly well for us, but no one else would be able to tell what sorts of nefarious things we were sending through the air. While it's true that 99% of the cases where someone wants to know the ID of that #%*~! interfering spread spectrum signal will be other amateurs (where DF would work well enough to isolate the offender), we have to ensure that the FCC (at least in principle) can check on the content of what we're sending. If only to make sure that we're not operating stations for the Republic of Texas. DF techniques by themselves don't relieve us of the responsibility to publicize the spreading sequences we're using. Perhaps the point is overblown, but it's still my opinion that if the FCC isn't given a standard procedure for finding what spreading sequences an amateur is using (for instance, by knowing what repeater to listen to), they're going to insist that the spread tranmission contain some narrowband feature that'll make it clear on-the-air. 73 Alan Software Development Systems, Stafford, Texas Instruments, +1 281-274-2943 -------------------------------------------------------------------------- "DESTROY 99% OF KNOWN HOUSEHOLD PESTS WITH PRE-SLICED, RUSTPROOF, EASY TO HANDLE, LOW CALORIE SIMPSON'S INDIVIDUAL EMPEROR STRINGETTES, FREE FROM ARTIFICIAL COLORING (AS USED IN HOSPITALS)." -- Monty Python From RLANIER@mailb.harris.com Tue May 06 18:28:17 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 SAA12300 for ; Tue, 6 May 1997 18:28:12 -0500 (CDT) Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/ Harris.COM Unix mail relay) id TAA00614; Tue, 6 May 1997 19:28:04 -0400 Received: from ccMail by mailb.harris.com (IMA Internet Exchange 1.04b) id 36fbe380; Tue, 6 May 97 19:26:48 -0400 Mime-Version: 1.0 Date: Tue, 6 May 1997 19:27:17 -0400 Message-ID: <36fbe380@mailb.harris.com> Return-receipt-to: RLANIER@mailb.harris.com (RLANIER) From: RLANIER@mailb.harris.com (RLANIER) Subject: Re: [SS:1356] Re: SS Questions for Rule Filing To: ss@tapr.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part >>I'd also like to know if someone knows of a study comparing the output >>spectrum of a narrowband transmitter to a SS transmitter, both operating at >>, say 50 watts? In other words, would a SS system transmitting at 100 watts >>overpower a narrowband system transmitting at 10 watts, under ideal >>conditions? Is there a linear relationship to this? >The key figure is "power spectral density", which is simply the total >transmitter power divided by the bandwidth. >If you have a 100W transmitter spreading over 1 MHz, the power >spectral density is 100/1e6 = .0001 W/Hz. If you have a 10 W >narrowband transmitter operating in 3 KHz, then the power spectral >density is .0033 W/Hz, which is 33.3 times or 15.2 dB stronger. So >if >everything else is the same (path loss, etc), the narrowband signal will >still be 15.2 dB stronger than the wideband signal in the narrowband >receiver even though the total transmitter power for the wideband signal >is 10 dB greater. >Phil Hi Phil, This is EXACTLY what I was looking for! Thanks! Tony KE4ATO From FortneyJ@ix.netcom.com Wed May 07 01:51:11 1997 Received: from dfw-ix5.ix.netcom.com (dfw-ix5.ix.netcom.com [206.214.98.5]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id BAA25902 for ; Wed, 7 May 1997 01:51:09 -0500 (CDT) Received: (from smap@localhost) by dfw-ix5.ix.netcom.com (8.8.4/8.8.4) id BAA07629; Wed, 7 May 1997 01:50:37 -0500 (CDT) Received: from tok-ca8-49.ix.netcom.com(206.217.149.177) by dfw-ix5.ix.netcom.com via smap (V1.3) id sma007610; Wed May 7 01:50:15 1997 Date: Tue, 6 May 97 23:45:31 PDT From: "Fortney, James T." Sender: fortneyj@tok-ca8-49.ix.netcom.com Subject: RE: [SS:1355] Docket 97-12 Comments To: ss@tapr.org X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I can't find any comments at this address. Where are you hiding them? - JimF K6IYK >We have started the collection of comments from todays filings on Docket >97-12 on http://www.tapr.org/ss > >The following (listed below) are now available and we expect more to be >made available in the coming weeks. These represent filings that the >individuals/groups sent to us directly in electronic format (thanks!). >Other selected filings will take time to get up on the web page, because >copies must be made in Washington DC by our lawyers, mailed to a volunter >who then scans them before being made available on the web page. If you >filed on Docket 97-12 and would like your comments or reply comments in the >future posted with everyone elses, please send them to wd5ivd@tapr.org > > >Comments on Docket 97-12 available include (as of 5/5/97): > > Tucson Amateur Packet Radio Corp 5/5/97 > Lyle V. Johnson, WA7GXD 5/5/97 > Philip R. Karn, Jr, KA9Q 5/5/97 > Robert A. Buaas, K6KGS 5/5/97 > Central States VHF Society 5/5/97 > William A. Tynan, W3XO 5/5/97 > > > >Cheers - Greg Jones, WD5IVD >President TAPR > > >----- >Greg Jones, WD5IVD >Austin, Texas >wd5ivd@tapr.org >http://www.tapr.org/~wd5ivd >----- > > > ------------------------------------- James T. Fortney E-mail: Jim@Fortney.org or: Jim@Fortney.com or: FortneyJ@ix.netcom.com Voice: 805.491.3916 or 1.500.FORTNEY AX.25: K6IYK@K6IYK.#SCA.CA.USA.NOAM MARSAMTS: AAA9CS@AT9TCS.AMARS.DOD FAX: 805.491.0319 Snail: P.O. Box 3419 Camarillo, CA 93011-3419 ------------------------------------- From wd5ivd@tapr.org Wed May 07 02:27: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 CAA26869 for ; Wed, 7 May 1997 02:27:28 -0500 (CDT) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 May 1997 02:20:10 -0500 To: ss@tapr.org From: "Greg Jones, WD5IVD" Subject: Re: [SS:1363] RE: Docket 97-12 Comments Did you try the link called "Spread Spectrum Rule Changes (RM-8737 & Doc. 97-12)" It is the first on at the very top the one that say Updated to the right. Cheers - Greg >I can't find any comments at this address. Where are you hiding them? > >- JimF K6IYK > >>We have started the collection of comments from todays filings on Docket >>97-12 on http://www.tapr.org/ss >> >>The following (listed below) are now available and we expect more to be >>made available in the coming weeks. These represent filings that the >>individuals/groups sent to us directly in electronic format (thanks!). >>Other selected filings will take time to get up on the web page, because >>copies must be made in Washington DC by our lawyers, mailed to a volunter >>who then scans them before being made available on the web page. If you >>filed on Docket 97-12 and would like your comments or reply comments in the >>future posted with everyone elses, please send them to wd5ivd@tapr.org >> >> >>Comments on Docket 97-12 available include (as of 5/5/97): >> >> Tucson Amateur Packet Radio Corp 5/5/97 >> Lyle V. Johnson, WA7GXD 5/5/97 >> Philip R. Karn, Jr, KA9Q 5/5/97 >> Robert A. Buaas, K6KGS 5/5/97 >> Central States VHF Society 5/5/97 >> William A. Tynan, W3XO 5/5/97 >> >> >> >>Cheers - Greg Jones, WD5IVD >>President TAPR >> >> >>----- >>Greg Jones, WD5IVD >>Austin, Texas >>wd5ivd@tapr.org >>http://www.tapr.org/~wd5ivd >>----- >> >> >> > >------------------------------------- >James T. Fortney >E-mail: Jim@Fortney.org > or: Jim@Fortney.com > or: FortneyJ@ix.netcom.com >Voice: 805.491.3916 or 1.500.FORTNEY >AX.25: K6IYK@K6IYK.#SCA.CA.USA.NOAM >MARSAMTS: AAA9CS@AT9TCS.AMARS.DOD >FAX: 805.491.0319 >Snail: P.O. Box 3419 > Camarillo, CA 93011-3419 >------------------------------------- ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From terry@ramar.co.uk Wed May 07 03:28:45 1997 Received: from mailgate.ramar.co.uk (mailgate.ramar.co.uk [195.11.196.158]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id DAA29108 for ; Wed, 7 May 1997 03:28:43 -0500 (CDT) Received: from Connect2 Message Router by mailgate.ramar.co.uk via Connect2-SMTP 4.20A; Wed, 7 May 1997 09:30:34 +0100 Message-ID: <42061C3101EB3300@mailgate.ramar.co.uk> Date: Wed, 7 May 1997 9:29:40 +0100 From: Terry Giles Sender: Terry Giles Return-Receipt-To: Organization: Ramar Technology To: ss@tapr.org Subject: Re: [SS:1354] Re: SS ID MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-disposition: inline Content-transfer-encoding: 7bit X-Mailer: Connect2-SMTP 4.20A MHS/SMF to SMTP Gateway > To: SS@SMTP {ss@tapr.org} > From: KARN@SMTP (Phil Karn) {karn@qualcomm.com} > Reply-to: SS @ SMTP {ss@tapr.org} > Subject: [SS:1354] Re: SS ID > Date: 5-May-97 17:10:05 -0500 > > There's a much easier way: the Massey-Berlekamp algorithm, widely used > in decoding Reed-Solomon codes. > > > > Phil > > Phil I am very interested in fast acqisition schemes for DSSS and would apprecaiate any references you have to the Massey-Berlekamp alorithm. 73 de G4CDY Terry Giles RAMAR Technology Ltd Airport House, Purley Way Surrey CR0 0XZ UK +44 (0) 181 781 1959 +44 (0) 181 781 1958 FAX e-mail terry@ramar.co.uk From n7oo@goodnet.com Wed May 07 12:57:30 1997 Received: from mailque.goodnet.com (mailque.goodnet.com [207.98.129.4]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id MAA16456 for ; Wed, 7 May 1997 12:57:26 -0500 (CDT) Received: from goodguy (n7oo@goodnet.com [207.98.129.1]) by mailque.goodnet.com (8.8.5/8.7.3) with SMTP id KAA27041 for ; Wed, 7 May 1997 10:46:57 -0700 (MST) Date: Wed, 7 May 1997 10:48:55 -0700 (MST) From: Jack Taylor X-Sender: n7oo@goodguy To: ss@tapr.org Subject: Re: [SS:1357] Re: SS ID In-Reply-To: <199705060033.RAA27070@servo.qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 5 May 1997, Phil Karn wrote: > >We can't (read "won't be allowed to") have it both ways. > > Unless the FCC can be persuaded that any interference problems can > be resolved without on-air identification of the interfering signal. > > This could be done in any number of ways: > > 1. Conventional DFing (many hams have plenty of experience in tracking > down wideband power line noise, which isn't identified). > > 2. "Offline" coordination and notification schemes, such as simply > letting the local ham community know what you're up to in the way of > SS transmissions by means of packet bulletins, newsletter articles, > meetings, and the like. > > Phil My observation is that very few hams in this area have the technical capability (or interest) in tracking down ANY interference. There was a time about 15 - 20 years ago, a group got together to localize cable leakage on one of the 2M frequencies, but this was pretty easy to locate as it was a constant carrier. There currently exists intermod interference at a number of mountain-top repeater sites. The solution has been to install PL as a means to reduce the annoyance. The PL approach of course is just a band aid for the real problem. Haven't heard of any effort to find the cause of the intermod, let alone resolve it. As for power line interference, the usual approach is to call the power company and let them investigate. Does anyone have first-hand knowledge of what SS interference sounds like on a narrow-band RX? Would it be of such duration as to open the squelch at co-located repeater sites? Perhaps not a problem if the repeater is PL'ed, but what about when someone with a weak signal (with PL) access's the repeater? Assuming there is no SS ID requirment that's detectable by the narrow band RX, we need to identify what techniques and equipment required by the narrow band group to track down SS QRM. When we are talking in-mode ID'ing in terms of packet and other narrow band modes, aren't we comparing apples to oranges? Is it realistic for concerned narrow-banders to go out and buy the latest wideband technology just so THEY can identify the offending SS QRM? If the shoe is on YOUR foot, would YOU be willing to make this investment? If the costs for doing so were low, you might be willing. But currently we're talking in the kilobuck range for an SS 'monitor'. I didn't see a stampede by the digital HFers to invest that much in the comparably priced HAL PCI-4000 Clover board, when it was introduced. Same is true of the Pactor II modems. Even the lower priced HAL P-38 boards aren't being snapped up by the amateur community. Like any new mode, there's going to be opposition to implimenting it. My view is this opposition would be substantially softened if there's some way of providing an ID that wouldn't impose specialized equipment procurement on the existing narrow band owners. After all, isn't an SS ID "just software"? 73 de Jack From karn@qualcomm.com Wed May 07 16:13:07 1997 Received: from laptop.ka9q.ampr.org ([129.46.236.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA29242 for ; Wed, 7 May 1997 16:13:04 -0500 (CDT) Received: by laptop.ka9q.ampr.org id m0wPAzM-000RwsC (Debian Smail-3.2 1996-Jul-4 #2); Wed, 7 May 1997 17:58:52 +0000 (UTC) Message-Id: Date: Wed, 7 May 1997 17:58:52 +0000 (UTC) From: Phil Karn To: ss@tapr.org In-reply-to: <42061C3101EB3300@mailgate.ramar.co.uk> (message from Terry Giles on Wed, 7 May 1997 03:34:55 -0500 (CDT)) Subject: Re: [SS:1365] Re: SS ID >I am very interested in fast acqisition schemes for DSSS and would >apprecaiate any references you have to the Massey-Berlekamp alorithm. Spread spectrum acquisition is discussed at length in the usual references on spread spectrum (Dixon, Viterbi, etc). The Massey-Berlekamp algorithm is described in most textbooks on coding theory, particularly those that cover the Reed-Solomon code. Lin & Costello and Blahut are two good examples. Phil From aeynon@micro.ti.com Wed May 07 16:24:47 1997 Received: from jester.ti.com (jester.ti.com [192.94.94.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA00138 for ; Wed, 7 May 1997 16:24:45 -0500 (CDT) Received: from reliant.micro.ti.com ([158.218.63.15]) by jester.ti.com (8.8.5) with ESMTP id QAA04770 for ; Wed, 7 May 1997 16:24:14 -0500 (CDT) Received: from admin2.micro.ti.com (postmaster@admin2.micro.ti.com [158.218.63.17]) by reliant.micro.ti.com (8.8.5/8.8.5) with ESMTP id QAA03246 for ; Wed, 7 May 1997 16:24:12 -0500 (CDT) Received: from aspc0662.micro.ti.com ([158.218.60.85]) by admin2.micro.ti.com (post.office MTA v2.0 0813 ID# 0-11540) with SMTP id AAA27607; Wed, 7 May 1997 16:24:11 -0500 Message-Id: <3.0.32.19970507162602.0069ba3c@pcmail.micro.ti.com> X-Sender: aeyn@pcmail.micro.ti.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 07 May 1997 16:26:02 -0500 To: ss@tapr.org, ss@tapr.org From: "Alan J. Eynon" Subject: Re: SS ID Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Jack, >Like any new mode, there's going to be opposition to implimenting it. My >view is this opposition would be substantially softened if there's some >way of providing an ID that wouldn't impose specialized equipment >procurement on the existing narrow band owners. After all, isn't an SS ID >"just software"? I think the gist of one of Phil's ideas was that we could put a CW identifier in the spread spectrum signal, so the ID would be external to the spreading. I also recall that he specified that the power of CW ID be no greater than the power spectral density of the spread signal. This is so that if the spread signal causes no interference, neither will the CW ID, whereas if the spread signal *is* causing detectable interference (such as breaking squelch), then the CW ID should also be detectable with a narrowband receiver. One interesting scenario I see is that these spread signal might be many hundreds of kilohertz (or even several megahertz) wide. The CW carrier only occupies a few hertz. So the spread signal's CW ID might be located quite far away from the poor operator who's receiving the interference, and they're going to have to "feel" their way along the spread signal by ear (it's essentially going to sound like white noise, or a general increase in the background noise of the band) until they hit the CW ID. So even this external ID signal isn't going to make it easy to identify the interferer. 73 Alan From lylej@azstarnet.com Wed May 07 21:38:37 1997 Received: from mailhost.azstarnet.com (root@mailhost.azstarnet.com [169.197.1.8]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id VAA27032 for ; Wed, 7 May 1997 21:38:35 -0500 (CDT) Received: from tomswift (usr13ip54.azstarnet.com [169.197.14.54]) by mailhost.azstarnet.com (8.8.3-p/8.8.5) with SMTP id TAA07515 for ; Wed, 7 May 1997 19:38:26 -0700 (MST) Message-Id: <3.0.32.19970507190614.006e9e10@pop.azstarnet.com> X-Sender: lylej@pop.azstarnet.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 07 May 1997 19:37:01 -0700 To: ss@tapr.org From: Lyle Johnson Subject: Re: SS ID Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Jack, >My observation is that very few hams in this area have the technical >capability (or interest) in tracking down ANY interference... Isn't it reasonable to assume that if people aren't bothered by the interference enough to track it down, then it isn't really bothering them? >There currently exists intermod interference at a number of mountain-top >repeater sites...Haven't heard of any effort to find the cause of the >intermod, let alone resolve it. This is just a case of too many transmitters too close together. It is sad that people put up with it, becasue the sources and casues are usually within a few hundred feet of the site... no DFing required, just decent system engineering and maintenance! >Does anyone have first-hand knowledge of what SS interference sounds like >on a narrow-band RX? Would it be of such duration as to open the squelch >at co-located repeater sites? Perhaps not a problem if the repeater is >PL'ed, but what about when someone with a weak signal (with PL) access's >the repeater? There will be many forms of SS - frequency hoppers, DSSS, combinations, etc. If they are detectable at all, thei "signature" it will depend entirely on the type of SS emission and the type of narrowband receiver (FM? SSB? CW with 100 Hz filter? DSP filter box in audio line?). >Assuming there is no SS ID requirment that's detectable by the narrow band >RX, we need to identify what techniques and equipment required by the >narrow band group to track down SS QRM. I think this is actually pretty easy: 1) the receiver that's experiencing the interference (or another that also experiences it) 2) a directional antenna 3) standard DF techniques then apply. In other words, if it is interfereing with narrowband modes, pretend it is a narrowbnad signal and go find it! There is no equipment or techniques required other than what one would presently use to track down interference. >When we are talking in-mode ID'ing in terms of packet and other narrow >band modes, aren't we comparing apples to oranges? Is it realistic for >concerned narrow-banders to go out and buy the latest wideband technology >just so THEY can identify the offending SS QRM? If I am running weak-signal SSB on 432.1 and hear interference, I need to track it down. Since these are UHF and microwave frequencies, if I am doing weak signal work, I have a directional antenna, so I can start to track it donw with my rotator. I can call a couple of my local buddies to tune in and aim their antennas, too. We'll find the source pretty quickly. >If the shoe is on YOUR foot, would YOU be willing to make this investment? If the costs >for doing so were low, you might be willing. But currently we're talking in >the kilobuck range for an SS 'monitor'. Actually, there is no SS monitor for Amateur SS operation because there is no Amateur SS operation to speak of. If I heard bothersome interference and couldn't identify it (maybe it is SS, maybe it isn't) then I have to go look for it. Like defending a patent, it is up to me to seek out the infringer and advise him of the interference he is causing. I don't run a lot of modes, and can't identify them, but if they bother me it is up to me to find them. In the end, I don't really care *who* they are or what callsign they are using, I care *where* they are so I can track them down. If I am able to communicate with them, then I can ask them directly without tracking them down. But all of this presupposes that there is an army of SS stations *nearby* and they are secret so no one knows they are running SS. >I didn't see a stampede by the digital HFers to invest that much in the >comparably priced HAL PCI-4000 Clover board, when it was introduced. >Same is true of the Pactor II modems. Even the lower priced HAL P-38 >boards aren't being snapped up by the amateur community. I fail to see the connection? I can't copy CLOVER or PACTOR. I didn't choose to buy the equipment. But, what if I choose to only use a 1 Hz CW filter because I am a narrowband mounbounce operator? I can't hear a CLOVER "CWID" (I know it's not required). So, how can I find this station that's interfering with my 1 Hz CW operation? I can't. But, is it fair for me to insist that everyone send CW at 1 Hz so I can identify them? >Like any new mode, there's going to be opposition to implimenting it. My >view is this opposition would be substantially softened if there's some >way of providing an ID that wouldn't impose specialized equipment >procurement on the existing narrow band owners. After all, isn't an SS ID >"just software"? No, it is much more than that. If I have a 1/4 megabit/sec packet link on SS, I can send a lot of information in a millisecond. But, a 20 WPM CWID will take me 3-4 seconds (I have six-character callsign). And that assumes that people operating in UHF and microwave are 20 WPM proficient with CW. Most aren't. And, in fact, many have a license that specifically states they don't know CW. So, a CWID is certainly inappropriate. Let's look at this from another viewpoint. SS is suppsoed to be narrowband "invisible". Let's assume I have a DSSS radio that normally occupies a 20 MHz slice of 2.4 GHz (a likely band for SS operation). First, of course, is that fact that there are almost no narrowband users with which I can interfere. But, more to the point, let's say I decide to send a CWID. Do I raise my power wnough so that any nafrrowband receiver tuned to any portion of that 20 MHZ slice of spectrum can copy me? No, that would force me to create a HUGE amount of potential interference. So, I decide that, since my spectrum is 20 MHz wide, I will send a 20 WPM CWID exactly 4.9152 MHz up from the bottm edge of my occupied spectrum. But, you are a narrowband CW person. How are you going to find my CWID if you are experienceing interference 9.73 MHz down from the top edge of my spectrum slice? The FCC rewquirement to use the minimum bandwidth for the intended communication indicates, that for sending a CWID for a narrowbnad station, I *can't* modulate my entire SS envelope and occupy the whole spectrum slice, I *must* use a carrier that is reasonably pure, etc. You're just not going to be able to find my CWID even if I am required to send it! I think it becomes clear that sending a narrowband ID on a wideband mode just isn't realizable on a practical basis. Let's look at another exmaple. SS is only allowed on UHF and microwave frequencies at present. Any interference is going to be from someone nearby. In the early days, while things are very experiemental, there are only going to be one or two people on the air near any particular other ham, and probably fewer. And, once they get the equipment up and running, they are going to tell anyone who cares to listen what they are doing, to encourage activity because they don't just want to communicate between two stations. (If they do, at these frequencies they are using very directional antennas anyway, so unless you are exactly in their path, AND listening at the instant they are transmitting AND their transmission is somehow interfering with your reception AND the duration of their transission is long enough for you to realize it is even happening [not likely at 2 or 10 megabits/sec, you won't be aware of them anyway, which is much of the ppoint of SS operation -to invisibly share spectrum] you won't be aware of them and they won't be casuing you interference.) Think back to the first days of packet (you were a pioneer in Sierra Vista). We got on the local repeaters, started clubs, called meetings, talked to ham clubs - we ADVERTISED our presence to attract other stations. So, in the early days, we got phone calls from folks who thought the repeater intermod was a packet station. But it wasn't a big deal and people knew who was on the air with packet. They knew who to call if they thought there was a packet "intruder" on "their frequency." If SS ever catches on like pakcet, the same path will be followed. It's always been this way for any new mode on VHF or UHF. And these *ARE* local communications facilities, not HF ionospheric DX stations. After a while, anyone who wanted one could get a TNC for a hundred bucks (or a baycomm modem for $49). When FM was new (I used to operate 2m AM but I won't say how long ago THAT was) you could buy an HR-2 for cheap - or QSY to a non-FM frequency. When SS catches on enough to be even a remote possibility of being a problem, there will be a TAPR or a Hamtronics or some way to get a basic radio for CHEAP. And if SS causes much interference to narrowbnad users, it won't catch on. I just don't see the problem. And I don't see why an SS station should be required to interfere with narrowband stations to send an ID, when the most prevalent cause of narrowband interference from SS users will then be the ID! Another $0.02 :-) Cheers, Lyle > >73 de Jack > > > > > > > > > From lylej@azstarnet.com Wed May 07 21:38:55 1997 Received: from mailhost.azstarnet.com (root@mailhost.azstarnet.com [169.197.1.8]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id VAA27071 for ; Wed, 7 May 1997 21:38:53 -0500 (CDT) Received: from tomswift (usr13ip54.azstarnet.com [169.197.14.54]) by mailhost.azstarnet.com (8.8.3-p/8.8.5) with SMTP id TAA07564 for ; Wed, 7 May 1997 19:38:36 -0700 (MST) Message-Id: <3.0.32.19970507193444.00736b28@pop.azstarnet.com> X-Sender: lylej@pop.azstarnet.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 07 May 1997 19:37:11 -0700 To: ss@tapr.org From: Lyle Johnson Subject: Re: [SS:1368] Re: SS ID Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >One interesting scenario I see is that these spread signal might be >many hundreds of kilohertz (or even several megahertz) wide. The CW >carrier only occupies a few hertz. So the spread signal's CW ID might >be located quite far away from the poor operator who's receiving the >interference, and they're going to have to "feel" their way along the >spread signal by ear (it's essentially going to sound like white noise, >or a general increase in the background noise of the band) until they >hit the CW ID. So even this external ID signal isn't going to make it >easy to identify the interferer. Alan, ANd gthey have to dwell every receiver-IF-filter-width for 10 minutes. AWe are now tuning 500 Hz to 2 kHZ every ten minutes, trying to cvover several MHz. It's easier to just DF the thing! And it's fastert to wait for the next clucb meeting and vote in a measure to buy a foxhunting outfit, and train yourself how to use it (500 Hz/ten minutes = 3 kHz/hr. That's 333.3 hours/MHz, 6666.7 hours for a 20 MHz swath, or 277.8 days. Hope the SS interferer is patient enough to continuoulsy send his CWID every ten minutes for 9 months, because if he doesn't, you have to tune it all over again...). A *perhaps* practical way is to set aside a single CW-width channel on eveyrband on which SS emissions are allowed and have stations on the band send a weak CWID every ten minutes while they are in operation. And, if the mode gets popular, you still have to DF becasue everyone is on the *same* frequency -- and how do you correlate a particular CWID with an SS emission that is likely not coincident -- and if it is data, likely only lasts a millisecond or two anyway? Folks, it just is not technically practical, no matter how good the social arguments, to use a narrowband ID on an SS signal. I think I'm up to $0.06 now :-) Hey, I'm having fun! Cheers, Lyle From hskim@cip-snowwhite.soongsil.ac.kr Wed May 07 22:12:14 1997 Received: from topper.soongsil.ac.kr.soongsil.ac.kr (topper.soongsil.ac.kr [192.245.249.12]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id WAA28920 for ; Wed, 7 May 1997 22:12:08 -0500 (CDT) From: hskim@cip-snowwhite.soongsil.ac.kr Received: from cip-snowwhite.ac.kr (cip-snowwhite.soongsil.ac.kr) by topper.soongsil.ac.kr.soongsil.ac.kr (5.0/SMI-SVR4) id AA01095; Thu, 8 May 1997 11:54:59 +0900 Received: from cip10herb.soongsil.ac.kr by cip-snowwhite.ac.kr (4.1/SMI-4.1) id AA03823; Thu, 8 May 97 11:06:08 KST Received: by cip10herb.soongsil.ac.kr with Microsoft Mail id <01BC5BA8.BDE89160@cip10herb.soongsil.ac.kr>; Thu, 8 May 1997 12:09:55 +0900 Message-Id: <01BC5BA8.BDE89160@cip10herb.soongsil.ac.kr> To: "'ss@tapr.org'" Subject: Give me a info. about multi-user detection Date: Thu, 8 May 1997 12:09:54 +0900 Return-Receipt-To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BC5BA8.BDE89160" ------ =_NextPart_000_01BC5BA8.BDE89160 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Phil Karn [SMTP:karn@qualcomm.com] Sent: Thursday, May 08, 1997 6:14 AM To: ss@tapr.org Subject: [SS:1367] Re: SS ID [=B1=E8=C7=D0=BC=BA] Hello!=20 I'm a graduate school student in Seoul, South Korea I learn CDMA recently. but lack of info.=20 if you will give me information or paper or etc, e-mail to me Thank you very much for reading this ugly mail. bye... ------ =_NextPart_000_01BC5BA8.BDE89160 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IjcDAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAAtQMAAAAAAAC4AAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAQABAAEEkAYAYAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAANQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHNzQHRhcHIub3JnAFNN VFAAc3NAdGFwci5vcmcAAAAAHgACMAEAAAAFAAAAU01UUAAAAAAeAAMwAQAAAAwAAABzc0B0YXBy Lm9yZwADABUMAQAAAAMA/g8GAAAAHgABMAEAAAAOAAAAJ3NzQHRhcHIub3JnJwAAAAIBCzABAAAA EQAAAFNNVFA6U1NAVEFQUi5PUkcAAAAAAwAAOQAAAAALAEA6AQAAAB4A9l8BAAAADAAAAHNzQHRh cHIub3JnAAIB918BAAAANQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHNzQHRhcHIub3JnAFNN VFAAc3NAdGFwci5vcmcAAAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAABAAAAAAAAAKRPQEEgAEA KwAAAEdpdmUgbWUgYSBpbmZvLiBhYm91dCBtdWx0aS11c2VyIGRldGVjdGlvbgBJDwEFgAMADgAA AM0HBQAIAAwACQA2AAQAMAEBIIADAA4AAADNBwUACAAMAAQANQAEACoBAQmAAQAhAAAAMjlEQURE MjI5QUM3RDAxMTk1NkU0NDQ1NTM1NDAwMDAA8QYBA5AGAKwGAAAjAAAACwACAAEAAAALACMAAQAA AAMAJgABAAAACwApAAAAAAADAC4AAAAAAAIBMQABAAAA2gAAAFBDREZFQjA5AAEAAgBKAAAAAAAA ADihuxAF5RAaobsIACsqVsIAAG1zcHN0LmRsbAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxXSU45 NVxvdXRsb29rLnBzdAAYAAAAAAAAAKsXTjJyv9ARlW5ERVNUAACigAAAAAAAABgAAAAAAAAAqxdO MnK/0BGVbkRFU1QAAMKAAAAQAAAAKdrdIprH0BGVbkRFU1QAACsAAABHaXZlIG1lIGEgaW5mby4g YWJvdXQgbXVsdGktdXNlciBkZXRlY3Rpb24AAAADADYAAAAAAEAAOQAAID9NXVu8AR4AcAABAAAA KwAAAEdpdmUgbWUgYSBpbmZvLiBhYm91dCBtdWx0aS11c2VyIGRldGVjdGlvbgAAAgFxAAEAAAAW AAAAAbxbXU03It3aKseaEdCVbkRFU1QAAAAAHgAeDAEAAAAFAAAAU01UUAAAAAAeAB8MAQAAACMA AABoc2tpbUBjaXAtc25vd3doaXRlLnNvb25nc2lsLmFjLmtyAAADAAYQxz2SOAMABxAqAQAAHgAI EAEAAABlAAAALS0tLS1PUklHSU5BTE1FU1NBR0UtLS0tLUZST006UEhJTEtBUk5TTVRQOktBUk5A UVVBTENPTU1DT01TRU5UOlRIVVJTREFZLE1BWTA4LDE5OTc2OjE0QU1UTzpTU0BUQVBSTwAAAAAC AQkQAQAAAHkCAAB1AgAAggMAAExaRnUzlbG7dwAKAQMB9yACpARkAgBjAmgKwHNldDEyOXkDMCdi AFAQQADgEEA4HRAxMgKDAFAO93BycZ4yD28QfxJhDw0wIAcTTQKAfQqACMggOwlvMsw1NQKACoF1 YwBQCwMGYwBBC2BuZzEwM/ozC6QxEOAKsQqECoQLMPBsaTM2AUAZUAFAEjCUb3QFkHQRYSAtHQJ6 TwUQZwuAB0AF0AeQc/hhZ2UdAxqWHGQcMQsTwRxmaS0xNDQBQBuwHRpwMAFADNAgo2IgRpUDYToM g2IVsFBoAxEGSwrAA6BbU01UUMQ6ayMhQHF1B0AFoOhtbS4kUV0alSHQBmATAjAiN1RoCHBzZGGM eSwF0CagIDA4JsCAMTk5NyA2OiCgZRXATSTnVG8iNwQQQCsBkBIwLgWwZyTodWJuahyRIjcjYFMn wBvQNzJdB/BlOgYABfBJRO8erx+6G7QZlDQSYR+DCoFfGVIMMi1GI1ATRGUQ4WPuNxNACZEQhGEs ICKBDECDFbADMTIgSGVsCQAGIQrjCoBJJ20gYfIgCcBhZCQgHIApUBKQZm8G8ClQdHUBAAIwIFcL gAZRCGBsJsBTCGB0JmgjAAWwZWE0FSBsgzeABKFDRE1BIAlwomMlgWx5LhqUYjcQwzgQANBrIG9m NkECEKYuNAUGkCB5CGAgA/BzM8A0wGl2NUAHgDpzcnkAwHRpAiA6QAXACrBw9wSQPTIS4GMmwB5A AMADEfx0bzxBGpQmQABwOjA7cvU8IHInAG0YwDcwPKE4wTs08AuAZz6wItAEIHVnjzkwPEA+gTlW eWUuQvAvL7ccOS+lFkEARRAAAAADABAQAAAAAAMAERADAAAAHgBCEAEAAAABAAAAAAAAAAMAgBD/ ////QAAHMIA0E5pcW7wBQAAIMIA0E5pcW7wBCwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAA AAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMABYAIIAYAAAAAAMAAAAAAAABGAAAA AFKFAACIDgAAHgAlgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOC4wAAMAJoAIIAYA AAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwAvgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAAD ADCACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAMoAIIAYAAAAAAMAAAAAAAABGAAAAABiF AAAAAAAAHgBBgAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4AQoAIIAYAAAAA AMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeAEOACCAGAAAAAADAAAAAAAAARgAAAAA4hQAA AQAAAAEAAAAAAAAAHgA9AAEAAAABAAAAAAAAAAMADTT9NwAAC28= ------ =_NextPart_000_01BC5BA8.BDE89160-- From n3jly@erols.com Wed May 07 23:03:42 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 XAA02046 for ; Wed, 7 May 1997 23:03:39 -0500 (CDT) Received: from LOCALNAME (col-as1s21.erols.com [207.172.128.20]) by smtp2.erols.com (8.8.5/8.8.5) with SMTP id AAA08142 for ; Thu, 8 May 1997 00:03:35 -0400 (EDT) Date: Thu, 8 May 1997 00:03:35 -0400 (EDT) Message-Id: <199705080403.AAA08142@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: Re: [SS:1366] Re: SS ID > Is it realistic for >concerned narrow-banders to go out and buy the latest wideband technology >just so THEY can identify the offending SS QRM? If the shoe is on YOUR >foot, would YOU be willing to make this investment? If the costs for >doing so were low, you might be willing. But currently we're talking in >the kilobuck range for an SS 'monitor'. one could ask- if i don't have a tnc what would i do if being interfered with by packets? today in the US these don't have morse ids. you'd call out for someone with a tnc to decode it for you. i surely would not buy a tnc just to figure out who was interferring with me(but i guess now i know why the local candy store won't take returns). those of us interested in ss are interested in what it can do for us. we don't just need another mode to try, if ss isn't working for the community as a whole then why would any of us want it? now please understand i can't accept unfounded fears on the part of the uniformed to prevent experimentation. but if well planned and executed experiments show it doesn't have a place in amatuer radio, that would be a different matter. i personally believe that it will find a place, one that has been lacking. obtw, in the same letter that the above quote is exerpted from, the question was asked "What would a spread spectrum signal sound like to a narrow receiver?". i'd think that may not be all that easy to answer. the parameters of the transmission would have a great effect on how it would sound. i was playing with a 0dBm dsss signal with 100kcps of p/n on the bench, with this going into a service monitor unattenuated it sounded much like a cellular signaling channel to the ear. normally my service monitor will receive signals off the air to well below -100 dBm, but with 50 dB of attenuation i could not hear the spread signal at all(but if the signal was not spread i could hear it well). amazing to me the pretty picture on the spectrum analyzer looks just like in the books. From wd5ivd@tapr.org Thu May 08 02:35:23 1997 Received: from [192.168.1.2] (knezek2.coe.unt.edu [129.120.111.42]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id CAA28868 for ; Thu, 8 May 1997 02:35:20 -0500 (CDT) Message-Id: In-Reply-To: <199705080403.AAA08142@smtp2.erols.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 May 1997 02:38:39 -0500 To: ss@tapr.org From: "Greg Jones, WD5IVD" Subject: Re: [SS:1372] Re: SS ID >> Is it realistic for >>concerned narrow-banders to go out and buy the latest wideband technology >>just so THEY can identify the offending SS QRM? If the shoe is on YOUR >>foot, would YOU be willing to make this investment? If the costs for >>doing so were low, you might be willing. But currently we're talking in >>the kilobuck range for an SS 'monitor'. > >one could ask- if i don't have a tnc what would i do if being interfered >with by packets? today in the US these don't have morse ids. you'd call out >for someone with a tnc to decode it for you. i surely would not buy a tnc >just >to figure out who was interferring with me(but i guess now i know why the >local >candy store won't take returns). > >those of us interested in ss are interested in what it can do for us. we >don't >just need another mode to try, if ss isn't working for the community as a >whole >then why would any of us want it? now please understand i can't accept >unfounded >fears on the part of the uniformed to prevent experimentation. but if well >planned >and executed experiments show it doesn't have a place in amatuer radio, that >would >be a different matter. i personally believe that it will find a place, one >that has >been lacking. > Which means everyone on this list that feels this way, REALLY MUST comment on this in the reply comments to Docket 97-12. This is our ONLY chance now to get these changed. If the FCC doesn't hear from those that can express these thoughts and the comments filed are equally balanced, then we will end up with rules that will seriously limit experimentation and later implementation of SS within Part 97. Be sure to read over the comments filed and if you see something in those comments that you don't like. File something in the reply comments that just covers that point. Like maybe the issue of logging and keeping the logs for over a year ? or maybe the comments about limiting Spread Spectrum to what someone termed 'narrow band' operating limits. The process at the FCC is a democratic one. Thus, the majority of filings have a voice in what finally happens. Cheers - Greg ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From jeff@mich.com Thu May 08 03:54: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 DAA01366 for ; Thu, 8 May 1997 03:54:45 -0500 (CDT) Received: from alfalfa (pm001-00.dialip.mich.com [198.108.17.124]) by server1.mich.com (8.8.4/8.8.4) with SMTP id EAA23564 for ; Thu, 8 May 1997 04:58:05 -0400 Message-Id: <2.2.32.19970508085341.00744d50@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, 08 May 1997 04:53:41 -0400 To: ss@tapr.org From: Jeff King / Kathy King Subject: Linear translator and DSSS I think I know the answer to this already (yes) but I will ask anyways. Can multiple independent (different PN sequences)DSSS signals pass through a linear translator (i.e. a analog satellite) and be received properly? The assumptions made are the collective energy of all the DSSS stations is not driving the translator into hard limiting. Thanks 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 jeff@mich.com Thu May 08 04:19:54 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 EAA02399 for ; Thu, 8 May 1997 04:19:52 -0500 (CDT) Received: from alfalfa (pm001-00.dialip.mich.com [198.108.17.124]) by server1.mich.com (8.8.4/8.8.4) with SMTP id FAA24658 for ; Thu, 8 May 1997 05:23:13 -0400 Message-Id: <2.2.32.19970508091849.00743338@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, 08 May 1997 05:18:49 -0400 To: ss@tapr.org From: Jeff King / Kathy King Subject: Re: [SS:1346] Re: reply comments on RM-8737 At 03:16 PM 5/3/97 -0500, Dewayne Hendricks wrote: >At 1:39 PM -0500 5/3/97, Jeff King / Kathy King wrote: >>Anyone have any idea how to locate reply comments to >>8737 on the FCC web site? Specifically, I am looking >>for the ARRL's. They are not on TAPR's site. Did every >>search I could think of, but no luck. > > The answer is simple. Those comments are not on the FCC site. The >FCC has only been posting comments on their site that have been made >available to them in electronic form for selected rulemakings where they >had setup a procedure for such submissions. > >-- Dewayne Let me be a bit broader then, I'm interested in seeing the comments, all of the comments before offering a reply. Short of driving to the FCC in Washington, how might one accomplish this? I believe Greg indicated to me the reason the ARRL's reply comments to RM-8737 was not on the TAPR site is that it wasn't scanned in. If you can obtain paper copies, I can scan (OCR) them in for you. Certainly, there is quite a bit to comment on in what I see so far on the TAPR WEB site, I'd just like to make sure I'm seeing it all before I reply. 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 RLANIER@mailb.harris.com Thu May 08 07:14:00 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 HAA16013 for ; Thu, 8 May 1997 07:13:59 -0500 (CDT) Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/ Harris.COM Unix mail relay) id IAA24098; Thu, 8 May 1997 08:13:52 -0400 Received: from ccMail by mailb.harris.com (IMA Internet Exchange 1.04b) id 371c3110; Thu, 8 May 97 08:12:01 -0400 Mime-Version: 1.0 Date: Thu, 8 May 1997 08:13:02 -0400 Message-ID: <371c3110@mailb.harris.com> Return-receipt-to: RLANIER@mailb.harris.com (RLANIER) From: RLANIER@mailb.harris.com (RLANIER) Subject: Quick and Dirty SS ID ?? To: ss@tapr.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Hey guys, Why don't we ID SS by the way it sounds? It seems to me that most modes have a particular "sound" to them (packet and RTTY come to mind). Then why not ID SS by its sound? I've seen on this list a description of SS as a constant "buzz." If so, we can use direction finding equipment and locate the source. If this isn't feasible, why not? Tony KE4ATO From RLANIER@mailb.harris.com Thu May 08 07:37:27 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 HAA16959 for ; Thu, 8 May 1997 07:37:24 -0500 (CDT) Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/ Harris.COM Unix mail relay) id IAA00514; Thu, 8 May 1997 08:37:17 -0400 Received: from ccMail by mailb.harris.com (IMA Internet Exchange 1.04b) id 371c8b20; Thu, 8 May 97 08:36:02 -0400 Mime-Version: 1.0 Date: Thu, 8 May 1997 08:36:46 -0400 Message-ID: <371c8b20@mailb.harris.com> Return-receipt-to: RLANIER@mailb.harris.com (RLANIER) From: RLANIER@mailb.harris.com (RLANIER) Subject: Re: [SS:1373] Re: SS ID To: ss@tapr.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part >Which means everyone on this list that feels this way, REALLY MUST comment >on this in the reply comments to Docket 97-12. This is our ONLY chance now >to get these changed. If the FCC doesn't hear from those that can express >these thoughts and the comments filed are equally balanced, then we will >end up with rules that will seriously limit experimentation and later >implementation of SS within Part 97. >Be sure to read over the comments filed and if you see something in those >comments that you don't like. File something in the reply comments that >just covers that point. Like maybe the issue of logging and keeping the >logs for over a year ? or maybe the comments about limiting Spread >Spectrum to what someone termed 'narrow band' operating limits. >The process at the FCC is a democratic one. Thus, the majority of filings >have a voice in what finally happens. >Cheers - Greg Greg, You bring up a good point: filing comments to the FCC. I was not able to write my comments and mail them to the FCC before the deadline. Can I still reply to 97-12 or do I have to wait? I really want to voice my opinion to the U.S. Government! Tony KE4ATO From dewayne@warpspeed.com Thu May 08 08:28:00 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 IAA19196 for ; Thu, 8 May 1997 08:27:58 -0500 (CDT) Received: from [204.118.182.22] by warpspeed.com with ESMTP (Eudora Internet Mail Server 1.1.2); Thu, 8 May 1997 06:27:54 -0700 X-Sender: dewayne@odo.warpspeed.com Message-Id: In-Reply-To: <371c8b20@mailb.harris.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 May 1997 06:27:37 -0700 To: ss@tapr.org From: Dewayne Hendricks Subject: Re: [SS:1377] Re: SS ID At 7:43 AM -0500 5/8/97, RLANIER wrote: > You bring up a good point: filing comments to the FCC. I was not able > to write my comments and mail them to the FCC before the deadline. Can > I still reply to 97-12 or do I have to wait? You don't have to wait for anything. Just file whatever comments you have as soon as you can. -- 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 jdc@dos.nortel.com Thu May 08 08:51:03 1997 Received: from aslan.dos.nortel.com (aslan.dos.nortel.com [192.7.1.11]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id IAA20516 for ; Thu, 8 May 1997 08:51:01 -0500 (CDT) Received: from sunsrvr6.humb.nt.com (fireside.dos.nortel.com [192.7.1.10]) by aslan.dos.nortel.com (8.8.5/NORTEL-DOS1.0) with SMTP id JAA16168 for ; Thu, 8 May 1997 09:51:58 -0400 (EDT) Received: from sun144.humb.nt.com by sunsrvr6.humb.nt.com (4.1/SMI-4.1) id AA22444; Thu, 8 May 97 09:50:58 EDT From: "James D. Cronin" Message-Id: <9705080950.ZM3433@sun144> Date: Thu, 8 May 1997 09:50:57 -0400 In-Reply-To: RLANIER@mailb.harris.com (RLANIER) "[SS:1377] Re: SS ID" (May 8, 7:43am) References: <371c8b20@mailb.harris.com> X-Mailer: Z-Mail (3.2.1 15feb95) To: ss@tapr.org Subject: Re: Re: SS ID Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Does anybody around here talk about spread spectrum radio? I subscribed to the mailing list expecting to learn something about spread spectrum from those who have used it. Or information on spread spectrum products we could use for our packet systems. Or just stuff that is "good to know." Instead we have a flamefest among a small group of people on spread spectrum IDing. Are there any mailing lists where spread spectrum radio, projects and products are discussed? Or can we possibly talk about that stuff here? 73..Jim N2VNO From hbaker@netcom.com Thu May 08 10:33:41 1997 Received: from netcom19.netcom.com (hbaker@netcom19.netcom.com [192.100.81.132]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA27554 for ; Thu, 8 May 1997 10:33:38 -0500 (CDT) Received: (from hbaker@localhost) by netcom19.netcom.com (8.6.13/Netcom) id IAA13979; Thu, 8 May 1997 08:33:31 -0700 From: hbaker@netcom.com (Henry G. Baker) Message-Id: <199705081533.IAA13979@netcom19.netcom.com> Subject: 2.4 GHz FH wireless lan id's To: ss@tapr.org Date: Thu, 8 May 1997 08:33:30 -0700 (PDT) In-Reply-To: <2.2.32.19970508085341.00744d50@mail.mich.com> from "Jeff King / Kathy King" at May 8, 97 03:58:45 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I was talking with a vendor of 2.4GHz FH wireless LAN hardware at Interop in Los Vegas yesterday, and he told me that a big holdup to using this hw in Japan was their requirement for some sort of ID. Apparently, this same 2.4GHz band is utilized almost world-wide _without_ ID, and only Japan requires some sort of ID. Apparently, this ID issue has not yet been resolved for this band in Japan yet. -- Henry Baker www/ftp directory URL: ftp://ftp.netcom.com/pub/hb/hbaker/home.html From dewayne@warpspeed.com Thu May 08 10:40:16 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 KAA28185 for ; Thu, 8 May 1997 10:40:13 -0500 (CDT) Received: from [204.118.182.22] by warpspeed.com with ESMTP (Eudora Internet Mail Server 1.1.2); Thu, 8 May 1997 08:40:08 -0700 X-Sender: dewayne@odo.warpspeed.com Message-Id: In-Reply-To: <2.2.32.19970508091849.00743338@mail.mich.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 May 1997 08:40:02 -0700 To: ss@tapr.org From: Dewayne Hendricks Subject: Re: [SS:1375] Re: reply comments on RM-8737 At 4:25 AM -0500 5/8/97, Jeff King / Kathy King wrote: >Let me be a bit broader then, I'm interested in seeing the comments, all >of the >comments before offering a reply. Short of driving to the FCC in >Washington, how >might one accomplish this? I believe Greg indicated to me the reason the >ARRL's >reply comments to RM-8737 was not on the TAPR site is that it wasn't scanned >in. >If you can obtain paper copies, I can scan (OCR) them in for you. As has been stated earlier, TAPR will make as many as the comments/reply comments available on our website as soon as we can. We don't guarantee to put all of them up as the effort is limited by the time available of the volunteers who have offered to help in the effort. Thanks for your offer to help, but we have enough people allocated to the effort for the time being. -- 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 hwm@netcom.com Thu May 08 11:07:21 1997 Received: from mm.wd6dod.ampr.org (hwm@netcom22.netcom.com [192.100.81.136]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA29783 for ; Thu, 8 May 1997 11:07:16 -0500 (CDT) Received: from localhost (by mm.wd6dod.ampr.org (8.7.5/8.6.12) with SMTP id JAA00165 for ; Thu, 8 May 1997 09:07:45 -0700 Date: Thu, 8 May 1997 09:07:45 -0700 (PDT) From: Bob Lorenzini To: ss@tapr.org Subject: Re: [SS:1379] Re: Re: SS ID In-Reply-To: <9705080950.ZM3433@sun144> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 8 May 1997, James D. Cronin wrote: > Does anybody around here talk about spread spectrum radio? I subscribed > Instead we have a flamefest among a small group of people on spread spectrum > IDing. Be patient, at the moment we are running up against a deadline for comments on something that could have long lasting negative implications for SS. This is most important at this time. Bob - wd6dod From jeff@mich.com Thu May 08 12:47:26 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 MAA13805 for ; Thu, 8 May 1997 12:47:22 -0500 (CDT) Received: from alfalfa (pm001-31.dialip.mich.com [198.108.17.155]) by server1.mich.com (8.8.4/8.8.4) with SMTP id NAA02981; Thu, 8 May 1997 13:50:45 -0400 Message-Id: <2.2.32.19970508174612.00a6b574@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, 08 May 1997 13:46:12 -0400 To: ss@tapr.org, dewayne@warpspeed.com From: Jeff King / Kathy King Subject: Re: [SS:1381] Re: reply comments on RM-8737 At 10:42 AM 5/8/97 -0500, Dewayne Hendricks wrote: >At 4:25 AM -0500 5/8/97, Jeff King / Kathy King wrote: >>Let me be a bit broader then, I'm interested in seeing the comments, all >>of the >>comments before offering a reply. Short of driving to the FCC in >>Washington, how >>might one accomplish this? I believe Greg indicated to me the reason the >>ARRL's >>reply comments to RM-8737 was not on the TAPR site is that it wasn't scanned >>in. >>If you can obtain paper copies, I can scan (OCR) them in for you. > As has been stated earlier, TAPR will make as many as the >comments/reply comments available on our website as soon as we can. We >don't guarantee to put all of them up as the effort is limited by the time >available of the volunteers who have offered to help in the effort. Thanks >for your offer to help, but we have enough people allocated to the effort >for the time being. > >-- Dewayne Your not understanding my question. I'm *NOT* asking or expecting TAPR to provide me those comments, I'm asking how 'Joe Q. Citizen' can get ahold of them so he/she can make some intelligent reply comments. At this point I'm trying to save the expense/runaround of calling the FCC in Washington on the phone to ask this same question.... and I suspect you know the answer. The reason I volunteered to help TAPR was I thought there wasn't enough manpower based on the missing comments/reply comments on RM-8737. One of the comments were missing, and 7 of the reply comments were missing, including the ARRL's. I appreciate the fact that TAPR is a volunteer organization, none-the-less I think it is important to make comments based on a full and complete set of information. Also, since many of the same players that were involved in RM-8737 are now involved in 97-12, it helps to read the previous reply comments to anticipate comments/reply comments these folks might make. Hence my interest in learning how I can gain access to these in the event TAPR is unable to provide a complete set of comments on the rule making. -Jeff From n3jly@erols.com Thu May 08 13:19:12 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 NAA16131 for ; Thu, 8 May 1997 13:19:11 -0500 (CDT) Received: from LOCALNAME (col-as12s13.erols.com [207.172.130.204]) by smtp3.erols.com (8.8.5/8.8.5) with SMTP id OAA26955 for ; Thu, 8 May 1997 14:19:06 -0400 Date: Thu, 8 May 1997 14:19:06 -0400 Message-Id: <199705081819.OAA26955@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:1379] Re: Re: SS ID Or information on spread spectrum products we >could use for our packet systems. Or just stuff that is "good to know." > >Instead we have a flamefest among a small group of people on spread spectrum >IDing. > >Are there any mailing lists where spread spectrum radio, projects and >products are discussed? Or can we possibly talk about that stuff here? > >73..Jim N2VNO Hello Jim, the tapr website has some good links to start with, www.sss-mag.com is a very informitive on-line magazine about ss. many of the chip manufacturers (motorola, harris, phillips, qualcom, ericson... ad nausium) have special ss chipsets and many have very good discussions and aplication notes on the topic that go well beyond thier specific products. i'm sorry you see some of the discussions here as a flamefest, i don't think the participants of these discussions see it that way. i think what would as a matter of definition prevent these from being called flaming is that it is a discussion of issues, not name calling. the reason we see so many different opinions about any of the issues involved is that we don't really agree on anything. that may sound stupid but the point is that we aren't starting with the same assumptions. what is ss? is it to use as- peer to peer lan? alternating short bursts that sound to a user as full duplex? point to point data or video links? saying what is ss is like saying what is fm. when we each talk about 'SS ID' we are each thinking about a mode/use for ss at that time. but like a group of blind men trying to descibe an elephant, we can't agree, and at times we are all right/wrong for a given use, because we aren't talking about the same thing! But Jim we can't tolerate the use of valuable bandwith for discussion on technical issues about radios and the like(hi,hi...)(well okay it may be fun to discuss some of it) 73 de n3jli From dewayne@warpspeed.com Thu May 08 13:23:32 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 NAA16252 for ; Thu, 8 May 1997 13:23:27 -0500 (CDT) Received: from [204.118.182.22] by warpspeed.com with ESMTP (Eudora Internet Mail Server 1.1.2); Thu, 8 May 1997 11:23:21 -0700 X-Sender: dewayne@odo.warpspeed.com Message-Id: In-Reply-To: <2.2.32.19970508174612.00a6b574@mail.mich.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 May 1997 11:22:59 -0700 To: Jeff King / Kathy King , ss@tapr.org From: Dewayne Hendricks Subject: Re: [SS:1381] Re: reply comments on RM-8737 At 1:46 PM -0400 5/8/97, Jeff King / Kathy King wrote: >Your not understanding my question. I'm *NOT* asking or expecting >TAPR to provide me those comments, I'm asking how 'Joe Q. Citizen' >can get ahold of them so he/she can make some intelligent reply >comments. At this point I'm trying to save the expense/runaround of >calling the FCC in Washington on the phone to ask this same >question.... and I suspect you know the answer. You will find the answer to your question at: -- 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 dewayne@warpspeed.com Thu May 08 14:30:19 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 OAA20175 for ; Thu, 8 May 1997 14:30:16 -0500 (CDT) Received: from [204.118.182.22] by warpspeed.com with ESMTP (Eudora Internet Mail Server 1.1.2); Thu, 8 May 1997 12:29:56 -0800 X-Sender: dewayne@odo.warpspeed.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 May 1997 12:29:53 -0700 To: ss-sta@tapr.org, ss@tapr.org From: Dewayne Hendricks Subject: SS STA Renewed I have just been informed by TAPR's law firm in DC that our SS STA renewal request was just granted today by the FCC. The renewal period is for another six months. -- Dewayne Chair TAPR Regulatory Affairs Committee -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 Thu May 08 15:02:34 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 PAA22024 for ; Thu, 8 May 1997 15:02:30 -0500 (CDT) Received: from alfalfa (pm001-45.dialip.mich.com [198.108.17.169]) by server1.mich.com (8.8.4/8.8.4) with SMTP id QAA18614 for ; Thu, 8 May 1997 16:04:38 -0400 Message-Id: <2.2.32.19970508200017.0074cd38@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, 08 May 1997 16:00:17 -0400 To: ss@tapr.org From: Jeff King / Kathy King Subject: Re: [SS:1385] Re: reply comments on WT 97-12 At 01:32 PM 5/8/97 -0500, Dewayne Hendricks wrote: > > You will find the answer to your question at: > > > >-- Dewayne Yeap. As I originally feared: http://www.fcc.gov/getinfo.html said: (from WT 97-12) >Comments and reply comments will be >available for public inspection during regular business >hours in the FCC Reference Center of the >Federal Communications Commission (Room 239), 1919 M Street, >N. W., Washington, DC 20554. Anybody on the list going to be in Washington D.C.? I'd be willing to scan all the ones in TAPR doesn't already have and post them if someone could copy them and mail them to me. Jeff King P.O. Box 510895 Livonia, MI 48151 -Jeff From dewayne@warpspeed.com Thu May 08 16:00:15 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 QAA27564 for ; Thu, 8 May 1997 16:00:01 -0500 (CDT) Received: from [204.118.182.22] by warpspeed.com with ESMTP (Eudora Internet Mail Server 1.1.2); Thu, 8 May 1997 13:59:56 -0800 X-Sender: dewayne@odo.warpspeed.com Message-Id: In-Reply-To: <2.2.32.19970508200017.0074cd38@mail.mich.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 May 1997 13:59:42 -0700 To: ss@tapr.org From: Dewayne Hendricks Subject: Re: [SS:1387] Re: reply comments on WT 97-12 At 3:03 PM -0500 5/8/97, Jeff King / Kathy King wrote: >Yeap. As I originally feared: > >http://www.fcc.gov/getinfo.html said: (from WT 97-12) > > >Comments and reply comments will be > >available for public inspection during regular business > >hours in the FCC Reference Center of the > >Federal Communications Commission (Room 239), 1919 M Street, > >N. W., Washington, DC 20554. > >Anybody on the list going to be in Washington D.C.? I'd be willing >to scan all the ones in TAPR doesn't already have and post them if >someone could copy them and mail them to me. You seem to have missed this part: >>>> II. How to Follow a Particular Issue (1) If you are searching for a document and have access to the Internet, visit the FCC web site. Look under the bureau you to which you think the document corresponds. If you cannot find the document, e-mail the FCC at fccinfo@fcc.gov or call Sheryl Segal or David Kitzmiller on (202) 418-0260 for assistance. (2) If you can come to the FCC in person, you may visit the FCC Reference Center in Room 239, 1919 M St., NW, Washington, DC. The staff in the Reference Center can help you find the information you are looking for. You may also sign up for a free one-hour training session that will teach you how to use RIPS -- a computer that displays documents related to proceedings. (3) For a fee, International Transcription Service will research, retrieve, and duplicate FCC documents for you. <<<< The operative section for your case is (3). You can pay ITS to get you copies of everything that is filed on this docket. -- 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 karn@qualcomm.com Thu May 08 18:14:07 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 SAA07970 for ; Thu, 8 May 1997 18:14:00 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id QAA09980; Thu, 8 May 1997 16:13:29 -0700 (PDT) Date: Thu, 8 May 1997 16:13:29 -0700 (PDT) Message-Id: <199705082313.QAA09980@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: (message from Jack Taylor on Wed, 7 May 1997 13:12:24 -0500 (CDT)) Subject: Re: [SS:1366] Re: SS ID >My observation is that very few hams in this area have the technical >capability (or interest) in tracking down ANY interference. There was a This may well be true. >There currently exists intermod interference at a number of mountain-top >repeater sites. The solution has been to install PL as a means to reduce Intermod (true intermod -- not simple strong-signal blocking) requires multiple signals plus a nonlinear combining element. This makes it considerably more difficult to track down than a single in-band interferer. >As for power line interference, the usual approach is to call the power >company and let them investigate. Yeah, right. My own experience is different. If you're to have any chance at all, you have to locate it yourself and *then* go to the utility to have them fix it. If you're very lucky, they will. If they have to also locate the interference, forget it. >Does anyone have first-hand knowledge of what SS interference sounds like >on a narrow-band RX? Would it be of such duration as to open the squelch >at co-located repeater sites? Perhaps not a problem if the repeater is Depends mainly on the duty cycle. A continuous SS emission resembles wideband noise, so it would generally *not* open the noise-operated squelch on an FM receiver no matter how strong the signal was, though it may cause the S meter to move. (A 56kb/s WA4DSY emission is sufficiently like a SS signal as far as a NBFM receiver goes, and this is exactly what happens if you tune to one with a typical NBFM receiver.) On a AM or SSB receiver, a sufficiently strong SS signal would raise the audible noise floor and move the S meter. Low duty cycle SS emissions (e.g., high speed packet transmissions) could very likely have transmission lengths that are too short to open squelches. If they were strong enough, they'd sound like very short bursts of wideband noise in a linear (AM or SSB) receiver. >procurement on the existing narrow band owners. After all, isn't an SS ID >"just software"? Maybe yes, maybe no. A low speed SS implementation might well be all in software, but a high speed one would probably do the low-level spreading functions in dedicated hardware. This hardware might require modifications to inject a narrowband CWID. Phil From lylej@azstarnet.com Thu May 08 20:16:23 1997 Received: from mailhost.azstarnet.com (root@mailhost.azstarnet.com [169.197.1.8]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA21804 for ; Thu, 8 May 1997 20:16:21 -0500 (CDT) Received: from tomswift (usr8ip59.azstarnet.com [169.197.9.59]) by mailhost.azstarnet.com (8.8.3-p/8.8.5) with SMTP id SAA09329; Thu, 8 May 1997 18:16:04 -0700 (MST) Message-Id: <3.0.32.19970508175615.006ece60@pop.azstarnet.com> X-Sender: lylej@pop.azstarnet.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 08 May 1997 18:14:39 -0700 To: jdc@dos.nortel.com From: Lyle Johnson Subject: Current Topics Cc: ss@tapr.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Jim, I apologize if you think my comments are flaming. It is certainly not my intent. In order to get SS useful in Amateur radio, apart from STA operation, we need a rules change. Some of us believe strongly that the rules need to be flexible so that there *can* be viable SS Amateur operation. The FCC is in a crucial part of a rulemaking process on this very topic. We are in a just-completed comment period, and now in a 30-day-long opportunity for reply comments, on rules that will determine if there is to be a chance to develop "real" SS gear for the next decade or so. Hence, the concentrated discussions on ID and other regulatory issues that are the present hot topics. If we have rules which severely limit us, we'll have the same SS activity we have now - effectively none, because it is not of sufficient benefit to be worth the trouble. Please bear with us while we discuss the regulatory envirnoment. And feel free to start and contribute to threads about the aspects of SS that interest you. I think you'll find plenty of topics and interesting discussions! Again, my apologies if I have offended you - it was not and is not my intent to "flame", only to constructively discuss these topics. Thank you for reading this! Lyle From wd5ivd@tapr.org Thu May 08 20:47:41 1997 Received: from [192.168.1.2] (knezek2.coe.unt.edu [129.120.111.42]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA23409 for ; Thu, 8 May 1997 20:47:38 -0500 (CDT) Message-Id: In-Reply-To: <371c8b20@mailb.harris.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 May 1997 20:28:46 -0500 To: ss@tapr.org From: "Greg Jones, WD5IVD" Subject: Re: [SS:1377] Re: SS ID You can still send in comments to the original filing date. If they are late, they will probably still be entered in to the record. That should not stop you if you have comments. Anyone can also send in reply comments to the comments filed. You don't have to have been in the original comments. Greg > >>Which means everyone on this list that feels this way, REALLY MUST comment >>on this in the reply comments to Docket 97-12. This is our ONLY chance now >>to get these changed. If the FCC doesn't hear from those that can express >>these thoughts and the comments filed are equally balanced, then we will >>end up with rules that will seriously limit experimentation and later >>implementation of SS within Part 97. > >>Be sure to read over the comments filed and if you see something in those >>comments that you don't like. File something in the reply comments that >>just covers that point. Like maybe the issue of logging and keeping the >>logs for over a year ? or maybe the comments about limiting Spread >>Spectrum to what someone termed 'narrow band' operating limits. > >>The process at the FCC is a democratic one. Thus, the majority of filings >>have a voice in what finally happens. > >>Cheers - Greg > > > Greg, > > You bring up a good point: filing comments to the FCC. I was not able > to write my comments and mail them to the FCC before the deadline. Can > I still reply to 97-12 or do I have to wait? > > I really want to voice my opinion to the U.S. Government! > > Tony KE4ATO > ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From karn@qualcomm.com Thu May 08 22:36:05 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 WAA00180 for ; Thu, 8 May 1997 22:36:02 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id UAA10879; Thu, 8 May 1997 20:35:30 -0700 (PDT) Date: Thu, 8 May 1997 20:35:30 -0700 (PDT) Message-Id: <199705090335.UAA10879@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: <3.0.32.19970507193444.00736b28@pop.azstarnet.com> (message from Lyle Johnson on Wed, 7 May 1997 21:49:27 -0500 (CDT)) Subject: Re: [SS:1370] Re: SS ID >ANd gthey have to dwell every receiver-IF-filter-width for 10 minutes. AWe >are now tuning 500 Hz to 2 kHZ every ten minutes, trying to cvover several >MHz. So just make the CWID continuous. As long as the power spectral density is comparable to the SS emission it is identifying, it won't bother the SS receiver and only a small fraction of the total RF power will be spent on the ID. So why not ID continuously, just like the IDs on C-band satellite uplinks? >Folks, it just is not technically practical, no matter how good the social >arguments, to use a narrowband ID on an SS signal. I disagree, at least for continuous SS emissions (e.g., digital voice transmissions). High speed, low duty cycle packet channels are more of a problem for CW IDs. Phil From karn@qualcomm.com Thu May 08 23:07: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 XAA01790 for ; Thu, 8 May 1997 23:07:35 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id VAA10913; Thu, 8 May 1997 21:07:04 -0700 (PDT) Date: Thu, 8 May 1997 21:07:04 -0700 (PDT) Message-Id: <199705090407.VAA10913@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: <199705080403.AAA08142@smtp2.erols.com> (message from Tony McConnell on Wed, 7 May 1997 23:05:30 -0500 (CDT)) Subject: Re: [SS:1372] Re: SS ID On the topic of "what does a SS emission sound like" I can offer one opportunity. IS-95 CDMA digital cellular is now being deployed rather widely around the US on both the 800 MHz cellular bands and in the new 1.8 GHz PCS bands. Those of you with wideband receivers built before the ECPA went into effect (e.g., the Icom R-7000) or an RF service monitor (e.g., IFR 1200) can hear it. Check with your local cellular or PCS providers to see if CDMA is available in your area. You can also check the CDMA Development Group (CDG) web page, http://www.cdg.org/. The exact frequencies are of course a matter of local carrier choice, but they will adhere to the existing North American allocations. In the regular 800 MHz cellular band, the base stations always transmit in the range 870-895 MHz. (I don't know the PCS frequencies offhand.) Both base and mobile transmissions are 1.25 MHz wide. (The details of the baseband modulation is different for the two directions, but both are ultimately direct sequence spread at the same rate by the same PN codes). They're easiest to hear in AM mode, though SSB will work too. FM (narrow or wide) will *not* work -- the squelch will not open, as the spread signal looks like noise to the noise-activated squelch (though a strong signal may move the S-meter). The signal sounds just like broadband white noise, 1.25 MHz wide. Sometimes I can make out some fine structure in the forward link spectrum. I attribute this to the relatively large amount of power in the pilot, which is an unmodulated carrier spread by the short PN code only. The short PN code repeats rather quickly (2^15 chips at a 1.2288 Mc/s rate -- you figure out the interval) and the ear can actually pick up the repetition interval of this code. (The ear is a remarkably good autocorrelator.) One characteristic of IS-95 CDMA that makes it easy to identify is its very sharp bandpass filtering, to keep the signal from bleeding over into adjacent narrowband AMPS channels. You'll hear a very rapid change in signal level as you tune past either edge of the emission. The specified bandpass filter (implemented as a digital FIR) has a fair amount of in-band ripple. Rapid rolloff and in-band flatness are tradeoffs in filter design, and here rapid rolloff was considered more important. The resulting display on a spectrum analyzer closely resembles the top of Bart Simpson's head. (The in-house slang term at Qualcomm for a composite IS-95 signal is a "bart's head"). The base stations are *far* easier to hear than the mobiles. Although it's possible to also hear the mobile stations transmitting in the 825-850 MHz range, they are transmitting at *much* lower power, with tinier antennas at lower altitudes -- and only when calls are actually up. The only way you're likely to hear one is if you are right next to a CDMA phone that's in a call. CDMA base stations transmit continuously to provide a "pilot reference" for the mobile stations to acquire and track. The base stations must also transmit a continuous paging channel, just like AMPS. In some implementations of IS-95 you may be able to detect a very weak residual carrier at the very center of the emission due to an imperfectly balanced mixer in the PN spreader. This carrier is useful as an accurate frequency reference (assuming you can figure out its nominal frequency) as all timing in a CDMA base station, including carrier oscillators, is referenced to a GPS receiver with a local Rb oscillator. Phil From karn@qualcomm.com Thu May 08 23:25:21 1997 Received: from warlock.qualcomm.com (warlock.qualcomm.com [129.46.52.129]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id XAA02515 for ; Thu, 8 May 1997 23:25:18 -0500 (CDT) Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by warlock.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id VAA08045 for ; Thu, 8 May 1997 21:23:41 -0700 (PDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id VAA10949; Thu, 8 May 1997 21:23:28 -0700 (PDT) Date: Thu, 8 May 1997 21:23:28 -0700 (PDT) Message-Id: <199705090423.VAA10949@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: <2.2.32.19970508085341.00744d50@mail.mich.com> (message from Jeff King / Kathy King on Thu, 8 May 1997 03:58:45 -0500 (CDT)) Subject: Re: [SS:1374] Linear translator and DSSS >Can multiple independent (different PN sequences)DSSS signals pass through >a linear translator (i.e. a analog satellite) and be received properly? The >assumptions made are the collective energy of all the DSSS stations >is not driving the translator into hard limiting. Yes. This is Spread Spectrum Multiple Access, aka Code Division Multiple Access (CDMA). For best results, all of the signals should be of roughly equal power, and the total number of simultaneous signals must not be greater than the processing gain divided by the required Eb/No, with both figures represented as ratios (not dB). Otherwise the mutual interference is too great for the signals to be properly decoded. Also, the sum of many spread signals tends toward a gaussian distribution, which is notorious for having a high peak-to-average power ratio. This makes the transponder design a little more challenging than one intended for simple hard-limited FM. On the other hand, AMSAT has a lot of experience in designing high efficiency linear satellite transponders. Amateur satellites are one of the few satellite systems that still operate in a SCPC (single channel per carrier) mode with analog modulation schemes. Most commercial satellite transponders carry either a single FM or QPSK signal that saturates the transponder, or are TDM (time division multiplexed) among several such signals that each take their turn saturating the transponder, making linearity unimportant. Phil From ssampson@claven.tinker.af.mil Fri May 09 08:54:57 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 IAA20285 for ; Fri, 9 May 1997 08:53:59 -0500 (CDT) Received: from localhost by othello.tinker.af.mil (AIX 4.1/UCB 5.64/4.03) id AA19732; Fri, 9 May 1997 08:52:39 -0500 Sender: ssampson@othello.tinker.af.mil Message-Id: <33732C27.167E@eds.tinker.af.mil> Date: Fri, 09 May 1997 08:52:39 -0500 From: Steve Sampson X-Mailer: Mozilla 3.01 (X11; U; AIX 1) Mime-Version: 1.0 To: ss@tapr.org Subject: Re: Priorities References: <199705082313.QAA09980@servo.qualcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > >Does anyone have first-hand knowledge of what SS interference sounds like > >on a narrow-band RX? > Depends mainly on the duty cycle. A continuous SS emission resembles > wideband noise, so it would generally *not* open the noise-operated > squelch on an FM receiver no matter how strong the signal was, though > it may cause the S meter to move. Forget about interference problems for the moment. 80% of the group has no radio, will not have a radio by 31 December, and will not cause ANY interference. Priority one: Design an effective SS radio Priority two: Make a kit or production units Priority three: worry about other Hams and FCC Steve "Weak Signal Hams are like a woman who wants the left side of the bed" From lylej@azstarnet.com Fri May 09 09:32:10 1997 Received: from mailhost.azstarnet.com (root@mailhost.azstarnet.com [169.197.1.8]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id JAA22071 for ; Fri, 9 May 1997 09:32:08 -0500 (CDT) Received: from tomswift (usr16ip53.azstarnet.com [169.197.17.53]) by mailhost.azstarnet.com (8.8.3-p/8.8.5) with SMTP id HAA11197 for ; Fri, 9 May 1997 07:32:00 -0700 (MST) Message-Id: <3.0.32.19970509070716.006ec24c@pop.azstarnet.com> X-Sender: lylej@pop.azstarnet.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 09 May 1997 07:30:38 -0700 To: ss@tapr.org From: Lyle Johnson Subject: Re: [SS:1392] Re: SS ID Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >So just make the CWID continuous. This means that every SS emitter is now also a guaranteed continuous narrowband emitter? I understand the spectral density - it is going to, in general, be a very WEAK narrowband emission. But it also means that each SS station is now taing up two communication "channels" one SS and one narrowband. This still strikes me as being contrary to what we are trying to achieve -- spectrum sharing with minimal interference. And I suppose it raises the question. Suppose I get an SS radio, but some local guy has a powerful narrowband emission thast is causing me interference. I only have SS gear (can't afford both). Should I not require that he have an SSID that *I* can copy? And, wow! if he has the same spectral density for his SSID that his narrowband station emits... Cheers, Lyle From dewayne@warpspeed.com Fri May 09 12:04:41 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 MAA01785 for ; Fri, 9 May 1997 12:04:35 -0500 (CDT) Received: from [204.118.182.22] by warpspeed.com with ESMTP (Eudora Internet Mail Server 1.1.2); Fri, 9 May 1997 10:04:17 -0700 X-Sender: dewayne@odo.warpspeed.com Message-Id: In-Reply-To: <33732C27.167E@eds.tinker.af.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 9 May 1997 10:03:14 -0700 To: ss@tapr.org From: Dewayne Hendricks Subject: Re: [SS:1395] Re: Priorities At 8:59 AM -0500 5/9/97, Steve Sampson wrote: >Forget about interference problems for the moment. 80% of the >group has no radio, will not have a radio by 31 December, and will >not cause ANY interference. > >Priority one: Design an effective SS radio >Priority two: Make a kit or production units >Priority three: worry about other Hams and FCC I question the order of your priorities. I can assure you that if there isn't a successful conclusion to your priority three, then you can just forget about priorities one and two. -- 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 karn@qualcomm.com Fri May 09 15:25:05 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 PAA22853 for ; Fri, 9 May 1997 15:25:01 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id NAA24160; Fri, 9 May 1997 13:24:18 -0700 (PDT) Date: Fri, 9 May 1997 13:24:18 -0700 (PDT) Message-Id: <199705092024.NAA24160@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: <3.0.32.19970509070716.006ec24c@pop.azstarnet.com> (message from Lyle Johnson on Fri, 9 May 1997 09:38:04 -0500 (CDT)) Subject: Re: [SS:1396] Re: SS ID >>So just make the CWID continuous. >This means that every SS emitter is now also a guaranteed continuous >narrowband emitter? I understand the spectral density - it is going to, in No, only continuous for as long as the SS emitter would otherwise be on the air. As I already said, this doesn't work for very short SS transmissions, e.g., high speed packet. >general, be a very WEAK narrowband emission. But it also means that each >SS station is now taing up two communication "channels" one SS and one >narrowband. This still strikes me as being contrary to what we are trying Not really. For a reasonable processing gain, the "channel capacity" used up by the ID (assuming comparable power spectral density) is much less than that used by the SS emission as a whole. E.g., for a process gain of 20 dB (100:1) and an assumed narrowband bandwidth of 3 Khz for both the CWID and the unspread emission, even a continuous CWID would represent 1% of the composite output power. Less, actually, since the CWID spends much of its time with the key up. >And I suppose it raises the question. Suppose I get an SS radio, but some >local guy has a powerful narrowband emission thast is causing me >interference. I only have SS gear (can't afford both). Should I not If you're smart, you will have designed your SS gear to use frequency hopping with burst error correction -- in which case a single narrowband jammer won't bother you (unless he's so strong as to completely blanket your radio). Phil From lylej@azstarnet.com Fri May 09 18:36:15 1997 Received: from mailhost.azstarnet.com (root@mailhost.azstarnet.com [169.197.1.8]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA12792 for ; Fri, 9 May 1997 18:36:13 -0500 (CDT) Received: from ppp15.mmsi.com (usr12ip40.azstarnet.com [169.197.13.40]) by mailhost.azstarnet.com (8.8.3-p/8.8.5) with SMTP id QAA02434 for ; Fri, 9 May 1997 16:36:09 -0700 (MST) Message-Id: <3.0.32.19970509163436.006f0e8c@pop.azstarnet.com> X-Sender: lylej@pop.azstarnet.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 09 May 1997 16:34:45 -0700 To: ss@tapr.org From: Lyle Johnson Subject: Re: [SS:1398] Re: SS ID Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >Not really. For a reasonable processing gain, the "channel capacity" >used up by the ID (assuming comparable power spectral density) is much >less than that used by the SS emission as a whole. E.g., for a process >gain of 20 dB (100:1) and an assumed narrowband bandwidth of 3 Khz for >both the CWID and the unspread emission, even a continuous CWID would >represent 1% of the composite output power. Less, actually, since the CWID >spends much of its time with the key up. HHHmmm. I wasn't clear, let me try again. Assume I am running an SS real-time voice station. My usage pattern would be very like another voice station. If I am in QSO with one other station, I have a roughly 50% duty cycle. Maybe less than 50%, but significant, and transmitting in bursts of several seconds to several tens of seconds. A nearby ham wants to set up a narrowband QSO with another station. He is nearby and his antenna pattern includes a major lobe of my radiated signal pattern. If I send an ID the whole time my SS transmitter is keyed up, then I am going to effectively deny the other station the use of the narrowband channel on which my ID is being broadcast. He will hear my signal a lot, and will be forced to QSY. Not a problem if there are other narrowband channels to occupy. Might be aproblem in a crowded metro area, might not. But, if I were operating only SS, and not occupyuing that channel with my ID a significant part of the time, then the other station could use the narrowband channel I am not occupying. Thus, I am tying up both a narrowband channel (with my ID) *and* an SS "channel" with my intended communication. Seems wasteful, and in part what we're trying to do -- have co-resident NB and SS operation without minimal mutual interfernece -- is defeated by the ID requirement. Now, let's further assume the NB station set up operation before I did. Unless I also add a narrowband receiver to my SS radio, and carefully tune around and find an apparently unused NB channel for my ID, I am going to cause interference to an already-in-progress QSO with my "continual" ID. And if the band is crowded so that I can't find a "clear channel" to send my NB ID, then I am being forced to not use my SS radio, which I could otherwise use with a negligible amount of potential interference to the crowded NB users. *** I realize that on 2.4 GHz I'm going to have a hard time finding anyone to interfere with, anyway, except Part 15 users (whom I am allowed to interfere with and who aren't allowed to complain). But if we get access to 2 meters, and we're already allowed operation on 70cm which is already "crowded" in some parts of the country (at least, lots of spectrum is warehoused so no one else can warehouse it), the narrowband ID rule is going to cause more trouble than it is going to cure IMHO. Cheers, Lyle From karn@qualcomm.com Fri May 09 21:47: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 VAA22957 for ; Fri, 9 May 1997 21:47:48 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id TAA25237; Fri, 9 May 1997 19:47:17 -0700 (PDT) Date: Fri, 9 May 1997 19:47:17 -0700 (PDT) Message-Id: <199705100247.TAA25237@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: <3.0.32.19970509163436.006f0e8c@pop.azstarnet.com> (message from Lyle Johnson on Fri, 9 May 1997 18:39:35 -0500 (CDT)) Subject: Re: [SS:1399] Re: SS ID >If I send an ID the whole time my SS transmitter is keyed up, then I am >going to effectively deny the other station the use of the narrowband >channel on which my ID is being broadcast. He will hear my signal a lot, No. You missed the critical feature of the narrowband ID, which is that its power spectral density (measured in a typical narrowband bandwidth) is no greater than the power spectral density of my SS emission. In other words, if my CWID interferes with some narrowband station, then so does my entire SS emission! Phil From ssampson@oklahoma.net Fri May 09 22:29:03 1997 Received: from dns.okc (dns.oklahoma.net [208.2.112.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id WAA26070 for ; Fri, 9 May 1997 22:29:01 -0500 (CDT) Received: from chalice.site.net by dns.okc (SMI-8.6/SMI-SVR4) id WAA06903; Fri, 9 May 1997 22:34:12 -0500 Message-Id: <199705100334.WAA06903@dns.okc> From: "Steve Sampson" To: Subject: Re: Priorities Date: Fri, 9 May 1997 22:26:28 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > I question the order of your priorities. I can assure you that if > there isn't a successful conclusion to your priority three, then you can > just forget about priorities one and two. Washington hasn't changed much (despite Vice President Gore's re-invent Government plans). I will bet you a Coke that the rules will have band segments and narrow band morse code ID. If you really want to scare the heck out of the Wireless industry, explain to them our intent to do Morse code all over the 900 MHz band at high power. You then have instantly more votes then the ARRL PAC, and a greater chance of success. But at any rate, several ideas have been proposed on generating narrow band Morse code ID's. It's not a technical problem. If the rules come out (and I lose the Coke) you can do like the TNC-2 did; command it on or off. Get over it. Steve From n3jly@erols.com Sat May 10 00:50:12 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 AAA21519 for ; Sat, 10 May 1997 00:50:11 -0500 (CDT) Received: from LOCALNAME (col-as4s27.erols.com [207.172.128.218]) by smtp3.erols.com (8.8.5/8.8.5) with SMTP id BAA24594 for ; Sat, 10 May 1997 01:50:10 -0400 Date: Sat, 10 May 1997 01:50:10 -0400 Message-Id: <199705100550.BAA24594@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:1400] Re: SS ID At 09:50 PM 5/9/97 -0500, you wrote: >>If I send an ID the whole time my SS transmitter is keyed up, then I am >>going to effectively deny the other station the use of the narrowband >>channel on which my ID is being broadcast. He will hear my signal a lot, > >No. You missed the critical feature of the narrowband ID, which is that >its power spectral density (measured in a typical narrowband bandwidth) >is no greater than the power spectral density of my SS emission. > >In other words, if my CWID interferes with some narrowband station, then >so does my entire SS emission! > >Phil notice what Phil says there, it is important. picture if you will a 3dB attenuator that can be keyed on and off in your ss transmitter. key that attenuator with your morse id. a narrow band receiver that can hear part of the tranmission can hear that change in amplitude, if it uses a mode that is amplitude sensitive(am,ssb...). by listening to the level of the signal go up and down, by ear a skilled operator could copy an id. this is not a seperate/discrete carrier apart from the ss signal, but the signal itself, by manipulating the modulation charactoristics and again, if the narrow band reciever can hear the ss transmission it will here the amplitude moduation at an audio rate of the transmission. that is one view of a narrow id of a ss transmission that can be copied with a narrow receiver. another is .... you are transmitting on some band, with a spreading method that 'evenly' distributes your 1watt transmit power across lets say for the example 100KHz. to id that signal with a discrete narrow band transmission with a similar spectral density let's say you chose ssb voice(for the sake of example) that has a band width of 2KHz(300-2300Hz), it would occupy one fiftieth of the used band width, thus that narrow band id would require one fiftieth of the power of the wide transmission to satisfy a spectral density similar to the transmission that it is identifying. when viewed in this way, it is no more likely to interfer than the ss signal itself. using a narrower mode(cw) could be done with power levels that are inverse to thier bandwidth in relation to the ss signal. remember the blind commitee's elephant? the method that makes the most sense for id purposes really depends on what you are trying to do.(and what they(the fcc) will let us get away with). 73 de n3jli From wd5ivd@tapr.org Sat May 10 01:49:29 1997 Received: from [192.168.1.2] (knezek2.coe.unt.edu [129.120.111.42]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id BAA29143 for ; Sat, 10 May 1997 01:49:25 -0500 (CDT) Message-Id: In-Reply-To: <199705100550.BAA24594@smtp3.erols.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 10 May 1997 01:53:04 -0500 To: ss@tapr.org From: "Greg Jones, WD5IVD" Subject: Re: [SS:1402] Re: SS ID Then again how do we handle FHSS systems ? or what about a hybrid FH DS SS system ? If we have the FHSS system hopping about 10msec ? I guess we could vary the pattern of hopping and present some callsign pattern on the spectrum analyer for the person to see :-) That is if they have an analyzer that sweeps fast enough. As with a lot of amateur radio stuff I read, we are spending countless hours discussing an issue that will happen a very limited amount of time -- that of harmful interference (like less than .01%) and how are we going to track it down for people that are too lazy to probably even notice to begin with. Trust me, if I put something on the air and it interferences with a serious weak signal operator, I can expect they will take the time to figure out the issue and solve it and let me know about it. TAPR, PacComm, or someone else is going to end up producing a unit that is the same for the majority of the user base that want to venture into the area of SS operations. Few experimenters are going to actually build something and if they do and it does interfere with someone -- that is one case in an isolated area. I highly doubt we are going to see even a hundred people build their own systems in the next 5 years from the basics. If the system built interferes, I doubt many are going to want to propagate it locally or nationally. Thus, we might end up with rules that could be hard if not impossible to implement that will be turned off after several years -- just like CW on packet radio. A system that TAPR or someone eventually tries to replicate is going to have to operate functionally correct -- not harmfully interfer with anyone. We need to simply agree that we might be spending our time better designing systems that don't interfere to begin with then focusing on how we plan to ID these same systems that should be built to minimize this issue. As Lyle and others pointed out -- I doubt few people that get on this mode are going to secretly go off and operate. We are going to be looking for others to get on the air operate with us. That means talking it up at club meetings and other events and on the voice repeaters and else where. If anything, we will have the old case of neighbors pointing to our new antenna saying that is what is causing their RFI. I am sure you have all heard that story. "Ham puts up a new tower and installs new beam; however, the ham leaves the coax attached to the bottom of the tower with no connector and doesn't run it inside. About a week later a group of neighbors come over and tell him about their RFI problems and obviously this new tower and antenna is causing the problem. The ham takes them out back and shows them that the coax doesn't even have a connector on it. That convinces most of them, but a few still think the antenna is probably doing it by itself :-) Anyway, the story ends with the good ham doing their best to help locate the RFI that is really causing the problem and everyone is happy in the end. After everything was said and done, these folks had RFI problems for a long time, just that the new technology in obvious view made them think about it and gave them a place to point and talk about." Don't we already have 'interference' (not harmful) on many of our bands -- even the weak signal areas ? Heck, the two operators that can't hear themselves are causing an increase in the noise floor when they operate on the same freq. That was the most meaningful part of the Sheppard thesis -- the worry is not local signals, but the adding up of signals at a distance (stated a little to simple). We face the potential sometime in the future of being this ham in my example. Our new technology (like old stuff) is causing or will cause people to think about what is happening on their bands. I am sure people will point at us and blame all sorts of strange spectrum related activity to our new operations with new equipment. Also, if you ain't filing at the FCC, your voice on here about how things should work have little impact on the eventual rules process. Not to be rude or anything, but we can talk all day -- what we need is simple rules that don't limit a mode of operations we want to experiment with. This is about making the rules be about amatue radio, not about protectionism. While others might believe this is going to be a threat -- there is nothing in the rules that says someone should have a section of the band to themselves to ensure no one every bothering them. If everyone that is talking about the issues, is not filing, then you are missing the point and we could be missing our only opportunity to really have an influence on doing something important. Heck -- I just read a post that someone made that states that maybe the ATV folks need to be protected from SS operations and someone should file that way. If we are not making our points on this issue -- no one else will be. Greg >At 09:50 PM 5/9/97 -0500, you wrote: >>>If I send an ID the whole time my SS transmitter is keyed up, then I am >>>going to effectively deny the other station the use of the narrowband >>>channel on which my ID is being broadcast. He will hear my signal a lot, >> >>No. You missed the critical feature of the narrowband ID, which is that >>its power spectral density (measured in a typical narrowband bandwidth) >>is no greater than the power spectral density of my SS emission. >> >>In other words, if my CWID interferes with some narrowband station, then >>so does my entire SS emission! >> >>Phil >notice what Phil says there, it is important. > >picture if you will a 3dB attenuator that can be keyed on and off in your >ss transmitter. key that attenuator with your morse id. a narrow band >receiver that can hear part of the tranmission can hear that change in >amplitude, if it uses a mode that is amplitude sensitive(am,ssb...). by >listening to the level of the signal go up and down, by ear a skilled >operator could copy an id. this is not a seperate/discrete carrier apart >from the ss signal, but the signal itself, by manipulating the modulation >charactoristics and again, if the narrow band reciever can hear the ss >transmission it will here the amplitude moduation at an audio rate of >the transmission. > >that is one view of a narrow id of a ss transmission that can be copied >with a narrow receiver. > >another is .... > >you are transmitting on some band, with a spreading method that 'evenly' >distributes your 1watt transmit power across lets say for the example >100KHz. to id that signal with a discrete narrow band transmission with >a similar spectral density let's say you chose ssb voice(for the sake of >example) that has a band width of 2KHz(300-2300Hz), it would occupy one >fiftieth of the used band width, thus that narrow band id would require >one fiftieth of the power of the wide transmission to satisfy a spectral >density similar to the transmission that it is identifying. when viewed >in this way, it is no more likely to interfer than the ss signal itself. >using a narrower mode(cw) could be done with power levels that are >inverse to thier bandwidth in relation to the ss signal. > >remember the blind commitee's elephant? > >the method that makes the most sense for id purposes really depends >on what you are trying to do.(and what they(the fcc) will let us get >away with). > >73 de n3jli ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From cornwaab@ednet.ns.ca Sat May 10 13:12:06 1997 Received: from trademart-1.ednet.ns.ca ([142.227.51.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA03285 for ; Sat, 10 May 1997 13:12:04 -0500 (CDT) Received: from iolan15.ednet.ns.ca by trademart-1.ednet.ns.ca (AIX 4.1/UCB 5.64/4.03) id AA28262; Sat, 10 May 1997 15:09:54 -0300 Message-Id: <9705101809.AA28262@trademart-1.ednet.ns.ca> Comments: Authenticated sender is From: "Andrew Cornwall" To: ss@tapr.org Date: Sat, 10 May 1997 17:04:55 +0000 Subject: RE:SS ID Reply-To: cornwaab@ednet.ns.ca Return-Receipt-To: cornwaab@ednet.ns.ca Priority: normal X-Mailer: Pegasus Mail for Windows (v2.01) Hello, I have been following SS-DD thread for only a couple of weeks, so my comments below may have already been covered. A requirement for an ID to accompany SS transmissions seems to me to be necessary for its acceptance and use by radio amateurs. I cannot imagine undertaking SS amateur radio without an ID, but to me the ID is more than just a call sign. The ID would be transmitted in SS over specific frequencies (or control channels) within a band. This is analogous to a calling frequency, and serves somewhat the same purpose. Whether a band has one or more control channels would be determined by experience, perhaps during the STA period. The command channel PNcode, frequency spread, and other parameters would be standardized. At a minimum, all SS transceivers would be equipped to work with the standard structure, on the command channel. In addition to fulfilling an expanded ID function, the standard structure would assure that all SS transceivers can communicate with each other in an emergency, at least over the control channel. An amateur radio transmitter would automatically post information to the command channel at the start of each transmission session, and every few minutes thereafter. More frequent postings may be at the option of the operator. Note that the control channel is not meant to be a primary communications conveyor; instead it announces that communications are occurring elsewhere in the band. The kind of information posted to the calling channel would be the following: - sending station call sign (ID) - contacted station call signs (none if initiating a contact) - frequency where the station's SS communications transmission is occurring, and characteristics of SS communications such as PNcode and other spread parameters, packet structure, data or audio content, data compression type, audio sampling rate and word, etc. (so other amateurs can tune in and monitor the traffic) - Other information: . CQ' or destination station call sign when initiating contact(s) . request for repeater availability . broadcast announcement that a station is available as a repeater . routing to distant stations . emergency communications content . etc. In operation, I can imagine a radio amateur monitoring the control channel for SS activity in the band. On his computer screen would be a list of SS transmitters and the SS characteristics of each transmission. Maybe there is a CQ request at frequency X' using Y' SS characteristics, that is of interest. The radio amateur then highlights the contact information on the screen and clicks-twice, where upon the computer configures the shack's transceiver and peripherals to listen-in and establish contact if desired. The use of the control channel would be mandatory and enforced by government regulation, further the frequency space(s) would be protected by regulation for this purpose. --- Andy / VE1COR cornwaab@ednet.ns.ca From RLANIER@mailb.harris.com Mon May 12 11:16: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 LAA23765 for ; Mon, 12 May 1997 11:16:13 -0500 (CDT) Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/ Harris.COM Unix mail relay) id MAA01565; Mon, 12 May 1997 12:16:00 -0400 Received: from ccMail by mailb.harris.com (IMA Internet Exchange 1.04b) id 37741ea0; Mon, 12 May 97 12:14:34 -0400 Mime-Version: 1.0 Date: Mon, 12 May 1997 12:15:12 -0400 Message-ID: <37741ea0@mailb.harris.com> Return-receipt-to: RLANIER@mailb.harris.com (RLANIER) From: RLANIER@mailb.harris.com (RLANIER) Subject: Re: [SS:1404] RE:SS ID To: ss@tapr.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part >The use of the control channel would be mandatory and >enforced by government regulation, further the frequency >space(s) would be protected by regulation for this >purpose. >--- Andy / VE1COR >cornwaab@ednet.ns.ca If this doesn't have shades of Big Brother, I don't know what does. This SS ID issue is becoming INSANE!!! Why don't we follow the rules: ID every 10 minutes and use the minimum power necessary to communicate? The ID'ing would occur in the modulation format used for transmission. Wouldn't it be asinine to suggest that FM users ID using SSB because someone doesn't have FM equipment? Why does this have to so complicated guys? Tony From Bob_Hunter@ATK.COM Mon May 12 12:34:46 1997 Received: from ATK.COM (nic.ATK.COM [138.64.4.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id MAA08389 for ; Mon, 12 May 1997 12:34:44 -0500 (CDT) Received: from exchange_mn2.atk.com by ATK.COM id MAA03920; Mon, 12 May 1997 12:34:12 -0500 Received: by exchange_mn2.atk.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC5ED0.D323AB70@exchange_mn2.atk.com>; Mon, 12 May 1997 12:34:24 -0500 Message-ID: From: "Hunter, Bob" To: "'ss@tapr.org'" Subject: RE: 1405] RE:SS ID Date: Mon, 12 May 1997 12:34:24 -0500 Return-Receipt-To: X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 32 TEXT Hear hear! >---------- >From: RLANIER@mailb.harris.com[SMTP:RLANIER@mailb.harris.com] >Sent: Monday, May 12, 1997 11:16 AM >To: ss@tapr.org >Subject: [SS:1405] RE:SS ID > > > >The use of the control channel would be mandatory and >>enforced by government regulation, further the frequency >>space(s) would be protected by regulation for this >>purpose. > >>--- Andy / VE1COR >>cornwaab@ednet.ns.ca > > If this doesn't have shades of Big Brother, I don't know what does. > > This SS ID issue is becoming INSANE!!! Why don't we follow the rules: > ID every 10 minutes and use the minimum power necessary to > communicate? > > The ID'ing would occur in the modulation format used for transmission. > Wouldn't it be asinine to suggest that FM users ID using SSB because > someone doesn't have FM equipment? > > Why does this have to so complicated guys? > > Tony > > From dewayne@warpspeed.com Tue May 13 03:39:05 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 DAA00327 for ; Tue, 13 May 1997 03:39:00 -0500 (CDT) Received: from [204.118.182.22] by warpspeed.com with ESMTP (Eudora Internet Mail Server 1.1.2); Tue, 13 May 1997 01:38:56 -0700 X-Sender: dewayne@odo.warpspeed.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 May 1997 01:38:49 -0700 To: ss@tapr.org From: Dewayne Hendricks Subject: Introducing Cylink DataMetro, first wireless remote access router that scales wireless WANs beyond metropolitan areas Note: I thought that I would post this Cylink press release to the list as I felt it represents a significant new product in the Part 15 unlicensed spread spectrum market and that some of you might be interested in hearing about this development. First, take note of the price, which is a LOT higher then I would like to see it for a product with this capability. Second, note that the user is asked to supply a PC to run the Cylink router code. This is a fairly unique twist that I haven't see from other companies in this market before. There is no other info on this product available at this time as Cylink hasn't updated their website yet. -- Dewayne ============================= Introducing Cylink DataMetro, first wireless remote access router that scales wireless WANs beyond metropolitan areas; Cylink DataMetro interconnects LANs at data rates approaching T1 Source: Business Wire SUNNYVALE, Calif.--(BUSINESS WIRE) via Individual Inc. -- Cylink Corporation, a leading provider of wireless communications products, today announced Cylink DataMetro, the first wireless remote access router that connects geographically dispersed networks at up to and beyond metropolitan distances. Cylink DataMetro offers superior price/performance compared to wired and wireless alternatives and supports a diverse range of internetworking applications -- from interbuilding connectivity to specialized industrial wide area networks. Where a wired infrastructure is absent or costly, Cylink DataMetro connects geographically scattered LANs by creating a wireless WAN over which it routes network traffic. With Cylink DataMetro, organizations that operate with dispersed sites, and network service providers with dispersed customers, get needed network connectivity, up to metropolitan distances and beyond (i.e. 30 miles or more). Unlike wireless bridges which simply connect LAN segments into a single logical network, Cylink DataMetro functions at the network layer with IP/IPX routing, permitting the network designer to build large, high performance, manageable networks. "We're excited to leverage our spread spectrum technology into a complete solution for wireless internetworking," said Steve Goldberg, general manager, Cylink Wireless Communications Group. "Many of our customers use our spread spectrum digital microwave radios for network connectivity today. Cylink DataMetro offers a new architecture that will drive the interconnection of region-wide computer networks." Cylink DataMetro supports three topologies -- star, mesh, and point-to-point -- which are implemented with efficient MAC protocols and can be combined in an internetwork. A polled protocol (star topology) provides efficient shared access to the channel even under heavy loading. For small scale networks, a CSMA/CA protocol supports a mesh topology. Clusters of nodes can be connected using a point-to-point protocol when building large scale internetworks. The single-hop node-to-node range is up to 30 miles depending on terrain, antennas, etc., with a multiple hop range extending on the order of a hundred miles. End-to-end SNMP supports management of the radios and the wireless WAN along with the remainder of the enterprise network using industry standard SNMP tools. The result is a manageable network with reach extending to metropolitan, suburban, rural, remote, and isolated areas. Applications of Cylink DataMetro include remote site LAN connectivity and network service dissemination. Organizations with remote offices such as banks, health care networks, government agencies, schools and other service organizations can connect their computing resources. Industrial and manufacturing companies can reliably and cost effectively connect factories, warehouses, and research facilities. Network service providers can distribute Internet, VSAT, and other network services to their customers. "We've seen a need for wireless remote network access solutions for a long time, and Cylink's DataMetro addresses that need handily," said Tom Esperson, director of Mobile Computing and Communications for the Yankee Group of Boston. "DataMetro is a robust and credible alternative to wireless bridges and other wireless remote access technologies. It offer users some unique advantages such as the ability to configure the architecture to support a variety of networking topologies." A WAN built with Cylink DataMetro exploits the tariff-free wireless "infrastructure." A wireless WAN offers a substitute for a wired infrastructure with its associated costly service fees. In areas where a wired infrastructure is absent or underdeveloped, Cylink DataMetro newly enables internetworking. Performance is comparable to commonly used wired WAN connections, approaching T1 speeds with its 1.3 Mbps data rate. The product is rooted in Cylink's industry-leading direct sequence spread spectrum RF platform. Cylink radios are field proven in tens of thousands of installations in the harshest environments and over the most challenging terrain around the world. Cylink's experience as a pioneer in spread spectrum technology brings the most robust performance possible. A user-supplied PC hosts the product through a connection to the PC's parallel printer port. Software includes an installation utility, network drivers, management, and IP/IPX routing. No radio license is required in the U.S. and many other countries, simplifying the network development process compared to licensed microwave. Pricing and availability List price for Cylink DataMetro 1280 (1.28 Mbps) is $3995, and Cylink DataMetro 320 (320 kbps) is $2995. Both models will be available in May, 1997. About Cylink Cylink's Wireless Communications Group is a world leader in fixed outdoor wireless networking infrastructure for voice and data. Additional products include managed and unmanaged digital microwave radio modems which support full-duplex communication at rates of 19.2 kbps to 2.048 Mbps. Cylink (NASDAQ:CYLK), headquartered in Sunnyvale, California, is also a world leader in information security products. Cylink's customers include national and multinational corporations, financial institutions and government organizations. For more information about Cylink and its products, visit the company's web site at www.cylink.com or call the fax-on-demand number 800-735-6614. CONTACT: Edelman Public Relations | Jillian Bargas, 415/968-4033 | JILLIAN_BARGAS@EDELMAN.COM [05-12-97 at 08:00 EDT, Business Wire] -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 wd5ivd@tapr.org Tue May 13 04:24:35 1997 Received: from [192.168.1.2] (knezek2.coe.unt.edu [129.120.111.42]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id EAA02111 for ; Tue, 13 May 1997 04:23:37 -0500 (CDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 May 1997 04:25:31 -0500 To: " Spread Spectrum " From: "Greg Jones, WD5IVD" Subject: To IP stack or to not IP Stack ? There has been some informal discussion recently that centered on the issue of putting an IP stack inside a SS radio ? It would be easy enough to add some additional processor horesepower into the controller, since the controller is already supporting an Ethernet interface and handling the others tasks related to the SS radio. Does one implement an IP stack or do something else to handle the communications between radios ? Cheers - Greg ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From 0007367829@mcimail.com Tue May 13 07:49:03 1997 Received: from gatekeeper2.mcimail.com (gatekeeper2.mcimail.com [192.147.45.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id HAA19473 for ; Tue, 13 May 1997 07:49:02 -0500 (CDT) Received: from mcimail.com ([166.40.135.61]) by gatekeeper2.mcimail.com (8.6.12/8.6.10) with ESMTP id MAA21668; Tue, 13 May 1997 12:54:20 GMT Received: from mcimail.com by dgi0ig.mcimail.com (PMDF V5.0-7 #16896) id <01IITL63OS5C934Q4P@dgi0ig.mcimail.com> for ss@tapr.org; Tue, 13 May 1997 12:50:47 +0000 (GMT) Date: Tue, 13 May 1997 07:50:38 -0500 (EST) From: TJ OBRIEN <0007367829@mcimail.com> Subject: UNSUBSCRIBE To: tapr Message-id: <97051312503821/0007367829PJ2EM@mcimail.com> Content-transfer-encoding: 7BIT Priority: normal From RLANIER@mailb.harris.com Tue May 13 10:06:11 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 KAA27346 for ; Tue, 13 May 1997 10:06:09 -0500 (CDT) Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/ Harris.COM Unix mail relay) id LAA26078; Tue, 13 May 1997 11:06:04 -0400 Received: from ccMail by mailb.harris.com (IMA Internet Exchange 1.04b) id 37883010; Tue, 13 May 97 11:04:33 -0400 Mime-Version: 1.0 Date: Tue, 13 May 1997 11:04:09 -0400 Message-ID: <37883010@mailb.harris.com> Return-receipt-to: RLANIER@mailb.harris.com (RLANIER) From: RLANIER@mailb.harris.com (RLANIER) Subject: Re: [SS:1356] Re: SS Questions for Rule Filing To: ss@tapr.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part >>I'd also like to know if someone knows of a study comparing the output >>spectrum of a narrowband transmitter to a SS transmitter, both operating at >>, say 50 watts? In other words, would a SS system transmitting at 100 watts >>overpower a narrowband system transmitting at 10 watts, under ideal >>conditions? Is there a linear relationship to this? >The key figure is "power spectral density", which is simply the total >transmitter power divided by the bandwidth. >If you have a 100W transmitter spreading over 1 MHz, the power >spectral density is 100/1e6 = .0001 W/Hz. If you have a 10 W >narrowband transmitter operating in 3 KHz, then the power spectral >density is .0033 W/Hz, which is 33.3 times or 15.2 dB stronger. So >if >everything else is the same (path loss, etc), the narrowband signal will >still be 15.2 dB stronger than the wideband signal in the narrowband >receiver even though the total transmitter power for the wideband signal >is 10 dB greater. >Phil Are these calculations taking into consideration the distance between the two transceivers? Obviously, the distance is proportional to the amount of interference. How can I accurately determine the dB strength of a signal based upon its distance from my transceiver, using the above calculations as a reference? I'd also like to know the average output power EME users use. I have be told that some use up to the maximum power level allowed, which is 1500 watts. If this is true, then why isn't there some type of special rule governing EME? After all, 1500 watts will over power ANY weak signal and satellite operator or FM or AM or SSB or reapeater or ... Tony KE4ATO From djk@tobit.co.uk Tue May 13 10:49:19 1997 Received: from 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 KAA00264 for ; Tue, 13 May 1997 10:49:14 -0500 (CDT) Received: (qmail 29819 invoked by uid 500); 13 May 1997 15:49:07 -0000 Date: Tue, 13 May 1997 16:49:07 +0100 (BST) From: Dirk Koopman Reply-To: djk@tobit.co.uk To: ss@tapr.org Subject: Re: [SS:1410] Re: SS Questions for Rule Filing In-Reply-To: <37883010@mailb.harris.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 13 May 1997, RLANIER wrote: > > Are these calculations taking into consideration the distance between > the two transceivers? Obviously, the distance is proportional to the > amount of interference. How can I accurately determine the dB strength > of a signal based upon its distance from my transceiver, using the > above calculations as a reference? > Db is a ratio, no of Db doesn't change just the actual level of volts. > > I'd also like to know the average output power EME users use. I have > be told that some use up to the maximum power level allowed, which is > 1500 watts. If this is true, then why isn't there some type of special > rule governing EME? After all, 1500 watts will over power ANY weak > signal and satellite operator or FM or AM or SSB or reapeater or ... > the 'point' is they are 'pointing' upwards, usually using very high gain antennas, this inherently means that there is comparitively little energy escaping sideways, down or anywhere else but where the moon happens to be. If you are between the beam and the moon (happens sometimes when the moon is low down on the horizon) or else just too close to 1.5Kw you will know about it. -- 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 jerryn@ici.net Tue May 13 20:00:40 1997 Received: from localhost (d-ma-fallriver-71.ici.net [207.180.10.80]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id UAA23472 for ; Tue, 13 May 1997 20:00:36 -0500 (CDT) Received: from nomad by localhost with smtp (Smail3.1.29.1 #58) id m0wRSQA-000VTTC; Tue, 13 May 97 20:59 EDT Sender: root@tapr.org Message-ID: <33790E8E.3EA869D7@ici.net> Date: Tue, 13 May 1997 20:59:58 -0400 From: Jerry Normandin X-Mailer: Mozilla 4.0b3C (X11; I; Linux 2.0.26 i686) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1410] Re: SS Questions for Rule Filing X-Priority: 3 (Normal) References: <37883010@mailb.harris.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jerry Normandin Replies: Man... at the frequencies used now... 902 and 2.4Ghz Spread Spectrum radios your pretty much limited by the curvature of the earth. It does not matter what yourpower output is. You signal is still going to hit the ground. If your at 902Mhz and your antennea is 100feet up and there are no trees in the way your only going to have a 26 mile range. I use a helium blimp on a tether to bounce my signal when I am experimenting. I can get 50 miles on 1 Watt like this. I use a dish antennea of course but I can do it. Also Spread Spectrum's benefits easily outweigh the power spectral density issue! BTW, the blimp's gondola lifts a cheap 386 laptop running Linux and of course a PCMCIA WaveLAN card. Power is provided by NiCADs. What the heck.... it works! Highest altitude on the blimp has been 500ft. You can do a lot with one watt! RLANIER wrote: > > >>I'd also like to know if someone knows of a study comparing the output > >>spectrum of a narrowband transmitter to a SS transmitter, both operating at > >>, say 50 watts? In other words, would a SS system transmitting at 100 watts > >>overpower a narrowband system transmitting at 10 watts, under ideal > >>conditions? Is there a linear relationship to this? > > >The key figure is "power spectral density", which is simply the total > >transmitter power divided by the bandwidth. > > >If you have a 100W transmitter spreading over 1 MHz, the power > >spectral density is 100/1e6 = .0001 W/Hz. If you have a 10 W > >narrowband transmitter operating in 3 KHz, then the power spectral > >density is .0033 W/Hz, which is 33.3 times or 15.2 dB stronger. So > >if > >everything else is the same (path loss, etc), the narrowband signal will > >still be 15.2 dB stronger than the wideband signal in the narrowband > >receiver even though the total transmitter power for the wideband signal > >is 10 dB greater. > > >Phil > > > Are these calculations taking into consideration the distance between > the two transceivers? Obviously, the distance is proportional to the > amount of interference. How can I accurately determine the dB strength > of a signal based upon its distance from my transceiver, using the > above calculations as a reference? > > > I'd also like to know the average output power EME users use. I have > be told that some use up to the maximum power level allowed, which is > 1500 watts. If this is true, then why isn't there some type of special > rule governing EME? After all, 1500 watts will over power ANY weak > signal and satellite operator or FM or AM or SSB or reapeater or ... > > > Tony KE4ATO From karn@qualcomm.com Tue May 13 22:05:22 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 WAA01516 for ; Tue, 13 May 1997 22:05:19 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id UAA23271; Tue, 13 May 1997 20:04:48 -0700 (PDT) Date: Tue, 13 May 1997 20:04:48 -0700 (PDT) Message-Id: <199705140304.UAA23271@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: (message from Dewayne Hendricks on Tue, 13 May 1997 03:40:25 -0500 (CDT)) Subject: Re: [SS:1407] Introducing Cylink DataMetro, first wireless remote access router What's the big deal? Looks like what you already get when you take an IP router (any router) and add a few radios... Phil From karn@qualcomm.com Tue May 13 22:05:57 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 WAA01554 for ; Tue, 13 May 1997 22:05:55 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id UAA23274; Tue, 13 May 1997 20:05:25 -0700 (PDT) Date: Tue, 13 May 1997 20:05:25 -0700 (PDT) Message-Id: <199705140305.UAA23274@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: (wd5ivd@tapr.org) Subject: Re: [SS:1408] To IP stack or to not IP Stack ? >There has been some informal discussion recently that centered on the issue >of putting an IP stack inside a SS radio ? I don't see the point. Leave the IP stack inside the computers and routers, and let the radios do all the lower level stuff. Phil From karn@qualcomm.com Tue May 13 22:16:12 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 WAA01983 for ; Tue, 13 May 1997 22:16:05 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id UAA23284; Tue, 13 May 1997 20:15:34 -0700 (PDT) Date: Tue, 13 May 1997 20:15:34 -0700 (PDT) Message-Id: <199705140315.UAA23284@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: <37883010@mailb.harris.com> (RLANIER@mailb.harris.com) Subject: Re: [SS:1410] Re: SS Questions for Rule Filing Are these calculations taking into consideration the distance between the two transceivers? Obviously, the distance is proportional to the amount of interference. How can I accurately determine the dB strength of a signal based upon its distance from my transceiver, using the above calculations as a reference? The example I gave explicitly stated that the path losses were the same. Obviously if the SS transmitter is much closer to the receiver than the intended narrowband transmitter, then the interference contributed by the SS transmitter will be much greater. I'd also like to know the average output power EME users use. I have be told that some use up to the maximum power level allowed, which is 1500 watts. If this is true, then why isn't there some type of special rule governing EME? After all, 1500 watts will over power ANY weak signal and satellite operator or FM or AM or SSB or reapeater or ... On the lower bands I believe that the full legal limit is common. On the higher bands (23cm and up) I think some operators are limited by how much RF amplification they can afford. Also, the antenna gains increase to where EME with less than legal limit power can work, at least some of the time. I'm not an EMEer, so I can't speak authoritatively. Phil From wd5ivd@tapr.org Tue May 13 22:49:15 1997 Received: from [192.168.1.2] (knezek2.coe.unt.edu [129.120.111.42]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA04200 for ; Tue, 13 May 1997 22:49:11 -0500 (CDT) Message-Id: In-Reply-To: <199705140305.UAA23274@servo.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 May 1997 22:53:18 -0500 To: ss@tapr.org From: "Greg Jones, WD5IVD" Subject: Re: [SS:1414] Re: To IP stack or to not IP Stack ? But why spend an extra $1000+ for the computer to allow you to connect to someone else Phil when we have a $100 (Motorola has an embeded powerpc chip with Ethernet controller integraetd available in low qty numbers for around $70-$80) processor available on the radio that could easily support it ? Then again we are going to have amateurs that will want to try to do this on a XT or 286 machine, or don't have the cash for 16Megs of memory to do what is necessary. Just put Ethernet into it and it does it ? The Ascend box or other ISDN boxes have IP stacks in them ? What is different between them and our application ? Other than the interface between the units. Is just pushing bits between point A and point B enough for the network topology that needs to be supported in different parts of the US ? Do we use IP across the radio links or do we do some type of MAC layer interface is another question for discussion. Cheers - Greg >>There has been some informal discussion recently that centered on the issue >>of putting an IP stack inside a SS radio ? > >I don't see the point. Leave the IP stack inside the computers and routers, >and let the radios do all the lower level stuff. > >Phil ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From dewayne@warpspeed.com Wed May 14 00:35:30 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 AAA22646 for ; Wed, 14 May 1997 00:35:28 -0500 (CDT) Received: from [204.118.182.22] by warpspeed.com with ESMTP (Eudora Internet Mail Server 1.1.2); Tue, 13 May 1997 22:35:25 -0700 X-Sender: dewayne@odo.warpspeed.com Message-Id: In-Reply-To: <199705140304.UAA23271@servo.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 May 1997 22:32:13 -0700 To: ss@tapr.org From: Dewayne Hendricks Subject: Re: [SS:1413] Re: Introducing Cylink DataMetro, first wireless remote access router At 10:08 PM -0500 5/13/97, Phil Karn wrote: >What's the big deal? Looks like what you already get when you take an >IP router (any router) and add a few radios... Its a big deal for companies in the Part 15 market. They've just discovered routers. Bridges were as far as they've gotten for the past several years. -- 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 karn@qualcomm.com Wed May 14 00:40: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 AAA23904 for ; Wed, 14 May 1997 00:40:35 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id WAA23750; Tue, 13 May 1997 22:40:04 -0700 (PDT) Date: Tue, 13 May 1997 22:40:04 -0700 (PDT) Message-Id: <199705140540.WAA23750@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: (wd5ivd@tapr.org) Subject: Re: [SS:1416] Re: To IP stack or to not IP Stack ? Oh god, here we go again on the never-dying theme of "do we make our own special purpose single-board computers or do we use generic PCs?" If you have a need for IP services from your packet radio modem, chances are you have a computer speaking TCP/IP somewhere near it already. So there is no "extra $1000+" for the computer. Phil From wd5ivd@tapr.org Wed May 14 01:26:21 1997 Received: from [192.168.1.2] (knezek2.coe.unt.edu [129.120.111.42]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id BAA29960 for ; Wed, 14 May 1997 01:26:18 -0500 (CDT) Message-Id: In-Reply-To: <199705140540.WAA23750@servo.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 May 1997 01:30:25 -0500 To: ss@tapr.org From: "Greg Jones, WD5IVD" Subject: Re: [SS:1418] Re: To IP stack or to not IP Stack ? Yes -- here it does come again. But let's try to get closure on it this time -- instead of just looking around the sides of the issue. I really want to try to understand your standing on this and maybe it will change the way I see things being implemented. Let me start with one question then. Can we agree that the radio and computer communicate via an Ethernet link. I think we can, but I want to make sure we are going in the same direction here. (PLEASE no debate on serial connections on this thread!! from others). If we have an Ethernet interface on the radio -- what is the best method to get bits between it and the computer ? How does the radio and computer communicate if attached directly or if the radio is setting on a Ethernet network ? Or is it your belief that we will place a dedicated Ethernet card on one computer and that computer acts as the router/bridge to the rest of the network via a second ethernet card ? Let me repeat the question in the first message. How do the radios talk ? IP ? MAC layer ? How do we push bits between radios addressed in such a way they no where they are going. Phil, what do you think the solution to these issues are ? Greg >Oh god, here we go again on the never-dying theme of "do we make our >own special purpose single-board computers or do we use generic PCs?" > >If you have a need for IP services from your packet radio modem, chances >are you have a computer speaking TCP/IP somewhere near it already. So >there is no "extra $1000+" for the computer. > >Phil ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From jeff@mich.com Wed May 14 03:10: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 DAA04984 for ; Wed, 14 May 1997 03:10:38 -0500 (CDT) Received: from alfalfa (pm001-33.dialip.mich.com [198.108.17.157]) by server1.mich.com (8.8.4/8.8.4) with SMTP id EAA14164 for ; Wed, 14 May 1997 04:11:54 -0400 Message-Id: <2.2.32.19970514080922.00bc7bbc@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, 14 May 1997 04:09:22 -0400 To: ss@tapr.org From: Jeff King / Kathy King Subject: Re: [SS:1419] Re: To IP stack or to not IP Stack ? At 01:31 AM 5/14/97 -0500, Greg Jones, WD5IVD wrote: >Let me start with one question then. > >Can we agree that the radio and computer communicate via an Ethernet link. >I think we can, but I want to make sure we are going in the same direction >here. >(PLEASE no debate on serial connections on this thread!! from others). > Why not ISA or PCI? It certainly can (would) be more cost effective then a stand alone ether net box, and frankly, would more closely fit the "ham" cost model (I think) we are striving for. Its also a model most of the Part 15 manufacturers have already addressed. History is a good teacher.... look at the TAPR NCP and the Gracillis box...and then compare there deployment versus open standards such as KA9Q nos based on the ISA/PC standard. I'd focus on the MAC layer and forgo any direct implementations of a IP layer. Another advantage of a ISA/PCI based solution is you don't need a case.... a cost savings not be ignored. >But why spend an extra $1000+ for the computer to allow you to connect to >someone else Phil when we have a $100 (Motorola has an embeded powerpc >chip with Ethernet controller integraetd available in low qty numbers for >around $70-$80) processor available on the radio that could easily support >it ? Then again we are going to have amateurs that will want to try to do >this on a XT or 286 machine, or don't have the cash for 16Megs of memory to >do what is necessary. Do we support the ham with a C-64 also? I just bought 16 megs of memory for $79. I bought a 133mhz 486 MB with PCI/VLB for $99. I think it is counterproductive to try and support the 'XT or 286' equipped amateur when reasonably fast hardware is available for next to nothing. Heck, most XT's/286's would be hard pressed to keep up with T1 rates anyways. I'm not suggest the 'best' environment, but I am suggesting the model that will work the best in the amateur radio based environment. Design some sort of PCI and/or ISA based radio card.... possibly with the radio head remote able, and make it a open standard for both WIN95 and Linux with regards to development tools. Possibly look at the AMD MAC layer chips for the interface between the SS chips and the ISA/PCMCIA bus. Do not underestimate the cost of developing any embedded controller system..... they only make sense when you have very high volumes and a good marketing team, neither of which is likely. I take it the renewed interest is because TAPR got the NSA grant? I don't think the marketplace should be ignored. Almost all dedicated ham radio routers have not been commercial successes. Learn from this and make a building block that someone can either use at home PC or incorporate into a PC/WIN95/UNIX system to make a router. Most hams are only interested in what technology can do for them, not what they can do for the community. You may not like hearing that, but it is reality. Hence, most of your sales will be to the end users NOT the eccentric node operators. Not withstanding, a open expandable product could fulfill both needs. 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 dewayne@warpspeed.com Wed May 14 03:16:10 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 DAA05079 for ; Wed, 14 May 1997 03:16:07 -0500 (CDT) Received: from [204.118.182.22] by warpspeed.com with ESMTP (Eudora Internet Mail Server 1.1.2); Wed, 14 May 1997 01:16:03 -0700 X-Sender: dewayne@odo.warpspeed.com Message-Id: In-Reply-To: <199705140540.WAA23750@servo.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 May 1997 01:14:11 -0700 To: ss@tapr.org From: Dewayne Hendricks Subject: Re: [SS:1418] Re: To IP stack or to not IP Stack ? At 12:47 AM -0500 5/14/97, Phil Karn wrote: >Oh god, here we go again on the never-dying theme of "do we make our >own special purpose single-board computers or do we use generic PCs?" > >If you have a need for IP services from your packet radio modem, chances >are you have a computer speaking TCP/IP somewhere near it already. So >there is no "extra $1000+" for the computer. Exactly!! This is one of the more important aspects of the new Cylink product. It uses a user-supplied PC. However, even given that, its still much too expensive. -- 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 RLANIER@mailb.harris.com Wed May 14 11:16:25 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 LAA07786 for ; Wed, 14 May 1997 11:16:20 -0500 (CDT) Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/ Harris.COM Unix mail relay) id MAA27992; Wed, 14 May 1997 12:16:14 -0400 Received: from ccMail by mailb.harris.com (IMA Internet Exchange 1.04b) id 379e4fd0; Wed, 14 May 97 12:14:53 -0400 Mime-Version: 1.0 Date: Wed, 14 May 1997 12:14:11 -0400 Message-ID: <379e4fd0@mailb.harris.com> Return-receipt-to: RLANIER@mailb.harris.com (RLANIER) From: RLANIER@mailb.harris.com (RLANIER) Subject: Re: [SS:1415] Re: SS Questions for Rule Filing To: ss@tapr.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part >Are these calculations taking into consideration the distance between >the two transceivers? Obviously, the distance is proportional to the >amount of interference. How can I accurately determine the dB >strength of a signal based upon its distance from my transceiver, >using the above calculations as a reference? >The example I gave explicitly stated that the path losses were the same. >Obviously if the SS transmitter is much closer to the receiver than >the intended narrowband transmitter, then the interference contributed >by the SS transmitter will be much greater. >Phil I realized the answer to my question after I posted the message. I'm not sure what I was thinking when I wrote that note. Sorry about that. I suppose my real intent of my EME question was to play devil's advocate: if a EME user builds an antenna that has alot of "leakage" on both sides of the main lobe, this could potentially interfere with weak signal, satellite users, especially if the EME user is pumpimg out 1500 watts. I just curious why the satellite and repeater people haven't complained about that, or have they? Tony KE4ATO From nielsen@primenet.com Wed May 14 12:59:26 1997 Received: from usr06.primenet.com (root@usr06.primenet.com [206.165.5.106]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id MAA22761 for ; Wed, 14 May 1997 12:59:25 -0500 (CDT) Received: from nielsen (nielsen@nielsen.tus.primenet.com [198.68.42.82]) by usr06.primenet.com (8.8.5/8.8.5) with SMTP id KAA16214 for ; Wed, 14 May 1997 10:59:22 -0700 (MST) Date: Wed, 14 May 1997 10:59:33 -0700 (MST) From: Bob Nielsen X-Sender: nielsen@nielsen To: ss@tapr.org Subject: Re: [SS:1422] Re: SS Questions for Rule Filing In-Reply-To: <379e4fd0@mailb.harris.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 14 May 1997, RLANIER wrote: > I suppose my real intent of my EME question was to play devil's > advocate: if a EME user builds an antenna that has alot of "leakage" > on both sides of the main lobe, this could potentially interfere with > weak signal, satellite users, especially if the EME user is pumpimg > out 1500 watts. I just curious why the satellite and repeater people > haven't complained about that, or have they? 1. The antenna is reciprocal, so any significant leakage from the antenna would also result in receiving interference from other signals. Of course sidelobes and spillover are a fact of life that must be dealt with. 2. EME is not likely to be conducted on satellite or repeater frequencies. AFAIK, most EME operators are also considered part of the weak signal community (which is not the same as QRP.) 3. This is getting pretty off-topic. 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 wa4dsy@wa4dsy.radio.org Wed May 14 14:24:25 1997 Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id OAA27560 for ; Wed, 14 May 1997 14:24:17 -0500 (CDT) Received: (from uucp@localhost) by out1.ibm.net (8.6.9/8.6.9) id TAA98300 for ; Wed, 14 May 1997 19:23:59 GMT Message-Id: <199705141923.TAA98300@out1.ibm.net> Received: from wa4dsy-1.wa4dsy.radio.org(208.148.146.146) by out1.ibm.net via smap (V1.3mjr) id smaotoDFW; Wed May 14 19:22:19 1997 From: "Dale Heatherington" To: "ss@tapr.org" Date: Wed, 14 May 97 15:21:42 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:1418] Re: To IP stack or to not IP Stack ? On Wed, 14 May 1997 00:47:17 -0500 (CDT), Phil Karn wrote: >Oh god, here we go again on the never-dying theme of "do we make our >own special purpose single-board computers or do we use generic PCs?" > >If you have a need for IP services from your packet radio modem, chances >are you have a computer speaking TCP/IP somewhere near it already. So >there is no "extra $1000+" for the computer. Trouble is my computer talks PPP, SLIP or ethernet. It's hard to put the data into ax25 frames for 56k (or other) modems. To do it right I need an ax25 NDIS driver for my OS/2 box. Anybody want to write drivers for all the OSes out there? Didn't think so... On the other hand, if the TNC talked SLIP, PPP or ethernet I could hook my computer up with no additional drivers. Right now the only way to get my OS/2 machines tcpip stack on AX25 is via JNOS running in a DOS emulator with it's own private ethernet card connected with coax to an second ethernet card in the same machine talking to OS/2s tcpip stack. This is a major kludge. I could run a separate DOS or Linux machine for this purpose but Linux or DOS isn't my primary OS so an extra machine would be required. What about the new PDAs which have tcpip stacks. Do I have to hook a PDA to a DOS box just to access the ax25/tcpip network? This may be ok for home use but it kinda sucks in a car. In conclusion, the missing link between todays PCs / PDAs and the ax25/tcpip network is a TNC that translates between the two. I want one BAD. -------------------------------------------------- Dale Heatherington, WA4DSY e-mail - daheath@ibm.net Web page - http://www.wa4dsy.radio.org OS/2 Warp 4.0 The worlds finest desktop OS. From RLANIER@mailb.harris.com Wed May 14 15:47:10 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 PAA05322 for ; Wed, 14 May 1997 15:47:08 -0500 (CDT) Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/ Harris.COM Unix mail relay) id QAA11897; Wed, 14 May 1997 16:47:03 -0400 Received: from ccMail by mailb.harris.com (IMA Internet Exchange 1.04b) id 37a24050; Wed, 14 May 97 16:43:49 -0400 Mime-Version: 1.0 Date: Wed, 14 May 1997 16:36:40 -0400 Message-ID: <37a24050@mailb.harris.com> Return-receipt-to: RLANIER@mailb.harris.com (RLANIER) From: RLANIER@mailb.harris.com (RLANIER) Subject: Re: [SS:1423] Re: SS Questions for Rule Filing To: ss@tapr.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part >> I suppose my real intent of my EME question was to play devil's >> advocate: if a EME user builds an antenna that has alot of "leakage" >> on both sides of the main lobe, this could potentially interfere with >> weak signal, satellite users, especially if the EME user is pumpimg >> out 1500 watts. I just curious why the satellite and repeater >people > haven't complained about that, or have they? >1. The antenna is reciprocal, so any significant leakage from the antenna >would also result in receiving interference from other signals. Of course >sidelobes and spillover are a fact of life that must be dealt with. >2. EME is not likely to be conducted on satellite or repeater >frequencies. AFAIK, most EME operators are also considered part of the >weak signal community (which is not the same as QRP.) >3. This is getting pretty off-topic. >Bob The reason I used EME as an example is because it has the *possibility* to interfere with other Amateurs. This is the same arguement the weak signal (QRP) and satellite folks are saying about SS: it can *possibily* interfere with the existing status quo, hence the "not in my back yard" mentality. Its not out of the scope of this discussion to suggest what I did. I'm simply trying to draw a parallel arguement to the SS issues we have been discussing. I think EME users are a breed apart, similar to SS experimenters in their quest to discover new frontiers. I hope to be a part of the first SS EME QSOs someday. Hence my choice of EME. Tony KE4ATO p.s. what does AFAIK stand for? From dewayne@warpspeed.com Wed May 14 16:19:01 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 QAA09141 for ; Wed, 14 May 1997 16:18:56 -0500 (CDT) Received: from [204.118.182.22] by warpspeed.com with ESMTP (Eudora Internet Mail Server 1.1.2); Wed, 14 May 1997 14:18:45 -0700 X-Sender: dewayne@odo.warpspeed.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 May 1997 14:18:41 -0700 To: ss@tapr.org, ss-sta@tapr.org From: Dewayne Hendricks Subject: 97-12 Comments status In case anyone is interested, here is a list of all of the commenters on the SS NPRM, docket 97-12: 220 Spectrum Management Association of S. Cal. American Radio Relay League Buaas, Robert Carpenter, Robert J.: Central States VHF Society Johnson, Lyle Karn, Phil Metricom Part 15 Coalition Soifa, Rapheal TAPR Tynan, William Note that this is a listing of all of the comments that the FCC has logged into their system since the comment deadline passed. If you filed comments on time and don't see your name here, I'd start to get concerned about what happened to them. We now have all of the comments above and will have them up on the TAPR website as soon as we can. I will post an undated list of comments received at the FCC at the end of next week. For those of you who filed comments, pro, con or whatever on the issue, you have our thanks!! -- Dewayne Chair TAPR Regulatory Affairs Committee -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 Wed May 14 19:29:33 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 TAA04108 for ; Wed, 14 May 1997 19:29:31 -0500 (CDT) Received: from alfalfa (pm001-05.dialip.mich.com [198.108.17.129]) by server1.mich.com (8.8.4/8.8.4) with SMTP id UAA08345 for ; Wed, 14 May 1997 20:31:06 -0400 Message-Id: <2.2.32.19970515002817.008cf7b4@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, 14 May 1997 20:28:17 -0400 To: ss@tapr.org From: Jeff King / Kathy King Subject: Re: [SS:1419] Re: To IP stack or to not IP Stack ? At 01:31 AM 5/14/97 -0500, Greg Jones, WD5IVD wrote: >Let me start with one question then. > >Can we agree that the radio and computer communicate via an Ethernet link. >I think we can, but I want to make sure we are going in the same direction >here. >(PLEASE no debate on serial connections on this thread!! from others). > Why not ISA or PCI? It certainly can (would) be more cost effective then a stand alone ether net box, and frankly, would more closely fit the "ham" cost model (I think) we are striving for. Its also a model most of the Part 15 manufacturers have already addressed. History is a good teacher.... look at the TAPR NCP and the Gracillis box...and then compare there deployment versus open standards such as KA9Q nos based on the ISA/PC standard. I'd focus on the MAC layer and forgo any direct implementations of a IP layer. Another advantage of a ISA/PCI based solution is you don't need a case.... a cost savings not be ignored. >But why spend an extra $1000+ for the computer to allow you to connect to >someone else Phil when we have a $100 (Motorola has an embeded powerpc >chip with Ethernet controller integraetd available in low qty numbers for >around $70-$80) processor available on the radio that could easily support >it ? Then again we are going to have amateurs that will want to try to do >this on a XT or 286 machine, or don't have the cash for 16Megs of memory to >do what is necessary. Do we support the ham with a C-64 also? I just bought 16 megs of memory for $79. I bought a 133mhz 486 MB with PCI/VLB for $99. I think it is counterproductive to try and support the 'XT or 286' equipped amateur when reasonably fast hardware is available for next to nothing. Heck, most XT's/286's would be hard pressed to keep up with T1 rates anyways. I'm not suggest the 'best' environment, but I am suggesting the model that will work the best in the amateur radio based environment. Design some sort of PCI and/or ISA based radio card.... possibly with the radio head remote able, and make it a open standard for both WIN95 and Linux with regards to development tools. Possibly look at the AMD MAC layer chips for the interface between the SS chips and the ISA/PCMCIA bus. Do not underestimate the cost of developing any embedded controller system..... they only make sense when you have very high volumes and a good marketing team, neither of which is likely. I take it the renewed interest is because TAPR got the NSA grant? I don't think the marketplace should be ignored. Almost all dedicated ham radio routers have not been commercial successes. Learn from this and make a building block that someone can either use at home PC or incorporate into a PC/WIN95/UNIX system to make a router. Most hams are only interested in what technology can do for them, not what they can do for the community. You may not like hearing that, but it is reality. Hence, most of your sales will be to the end users NOT the eccentric node operators. Not withstanding, a open expandable product could fulfill both needs. 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 tjob@juno.com Wed May 14 19:36:00 1997 Received: from x10.boston.juno.com (x10.boston.juno.com [205.231.101.25]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA04884 for ; Wed, 14 May 1997 19:35:59 -0500 (CDT) From: tjob@juno.com Received: (from tjob@juno.com) by x10.boston.juno.com (queuemail) id UfY08084; Wed, 14 May 1997 20:35:00 EDT To: ss@tapr.org Subject: Subscribe Message-ID: <19970514.203054.11471.0.tjob@juno.com> X-Mailer: Juno 1.15 X-Juno-Line-Breaks: 0 Date: Wed, 14 May 1997 20:35:00 EDT From lylej@azstarnet.com Wed May 14 20:13:31 1997 Received: from mailhost.azstarnet.com (root@mailhost.azstarnet.com [169.197.1.8]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA07102 for ; Wed, 14 May 1997 20:13:30 -0500 (CDT) Received: from ppp15.mmsi.com (usr2ip50.azstarnet.com [169.197.3.50]) by mailhost.azstarnet.com (8.8.3-p/8.8.5) with SMTP id SAA18574 for ; Wed, 14 May 1997 18:13:20 -0700 (MST) Message-Id: <3.0.32.19970514180603.00752e04@pop.azstarnet.com> X-Sender: lylej@pop.azstarnet.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 14 May 1997 18:12:00 -0700 To: ss@tapr.org From: Lyle Johnson Subject: Re: [SS:1426] 97-12 Comments status Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 04:25 PM 5/14/97 -0500, you wrote: > > In case anyone is interested, here is a list of all of the >commenters on the SS NPRM, docket 97-12: >... > We now have all of the comments above and will have them up on the >TAPR website as soon as we can. I look forward to seeing the ones not yet posted so I can write a reply comment. Dewyane, and everyone involved in TAPR's efforts on the regulatory front, my sincere thanks for making it easier for folks like me to participate. Cheers, Lyle From n3jly@erols.com Wed May 14 23:44:18 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 XAA25333 for ; Wed, 14 May 1997 23:44:16 -0500 (CDT) Received: from LOCALNAME (col-as5s30.erols.com [207.172.129.30]) by smtp3.erols.com (8.8.5/8.8.5) with SMTP id AAA05271 for ; Thu, 15 May 1997 00:44:15 -0400 Date: Thu, 15 May 1997 00:44:15 -0400 Message-Id: <199705150444.AAA05271@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: AFAIK? i would guess 'as far as i know' but this is one mans opinion, i could be wrong. see you all in dayton, my flight leaves at ten in the morning(or whenever i get there) From priya@students.itb.ac.id Thu May 15 02:50:47 1997 Received: from students.itb.ac.id (root@students.ITB.ac.id [167.205.22.114]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id CAA25245 for ; Thu, 15 May 1997 02:50:41 -0500 (CDT) Received: from localhost (priya@localhost) by students.itb.ac.id (8.8.5/8.7.3) with SMTP id KAA05889; Thu, 15 May 1997 10:55:27 +0700 (JVT) Date: Thu, 15 May 1997 10:55:27 +0700 (JVT) From: "Basuki E. Priyanto" To: Phil Karn cc: ss@tapr.org Subject: CDMA on satellite communication In-Reply-To: <199704282359.QAA12362@servo.qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII please help me ... could you tell me literature about CDMA for satellite communication thanks .. *************************************** Best Regards, BASUKI E. PRIYANTO "Beat Spread Spectrum" Mail:priya@itb.ac.id *************************************** From RLANIER@mailb.harris.com Thu May 15 07:52:44 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 HAA17470 for ; Thu, 15 May 1997 07:52:43 -0500 (CDT) Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/ Harris.COM Unix mail relay) id IAA04979; Thu, 15 May 1997 08:52:39 -0400 Received: from ccMail by mailb.harris.com (IMA Internet Exchange 1.04b) id 37b06ad0; Thu, 15 May 97 08:50:53 -0400 Mime-Version: 1.0 Date: Thu, 15 May 1997 08:51:15 -0400 Message-ID: <37b06ad0@mailb.harris.com> Return-receipt-to: RLANIER@mailb.harris.com (RLANIER) From: RLANIER@mailb.harris.com (RLANIER) Subject: Re: [SS:1431] CDMA on satellite communication To: ss@tapr.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part >please help me ... >could you tell me literature about CDMA for satellite communication >thanks .. >*************************************** >Best Regards, >BASUKI E. PRIYANTO >"Beat Spread Spectrum" >Mail:priya@itb.ac.id >*************************************** Exactly what do you mean by this? "Beat Spread Spectrum" From ssampson@claven.tinker.af.mil Thu May 15 08:32:42 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 IAA19217 for ; Thu, 15 May 1997 08:32:33 -0500 (CDT) Received: from localhost by othello.tinker.af.mil (AIX 4.1/UCB 5.64/4.03) id AA18010; Thu, 15 May 1997 08:32:30 -0500 Sender: ssampson@othello.tinker.af.mil Message-Id: <337B106E.41C6@eds.tinker.af.mil> Date: Thu, 15 May 1997 08:32:30 -0500 From: Steve Sampson X-Mailer: Mozilla 3.01 (X11; U; AIX 1) Mime-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1427] Re: To IP stack or to not IP Stack ? References: <2.2.32.19970515002817.008cf7b4@mail.mich.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jeff King / Kathy King wrote: > > At 01:31 AM 5/14/97 -0500, Greg Jones, WD5IVD wrote: > > >Let me start with one question then. > > > >Can we agree that the radio and computer communicate via an Ethernet link. > >I think we can, but I want to make sure we are going in the same direction > >here. Most of us were interested in the CrimeWave units. You have the data in front of you for how many people would buy a radio modem configured that way. Ethernet is good also. 1. Who sells embedded IP stacks. 2. What hardware do they require. 3. What is the unit cost. 4. What is the price for an IP black box versus a serial black box. 5. Would you be able to sell IP black box's in numbers that exceed break-even. Options: 1. Contract someone to make a new IP stack for selected hardware. > Why not ISA or PCI? It certainly can (would) be more cost effective > then a stand alone ether net box, and frankly, would more closely > fit the "ham" cost model (I think) we are striving for. Absolutely not. How many Mac users ever bought a PI-2 card. How many people bought external devices versus internal devices. From wpns@world.std.com Thu May 15 10:39:34 1997 Received: from europe.std.com (europe.std.com [199.172.62.20]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id KAA26827 for ; Thu, 15 May 1997 10:39:33 -0500 (CDT) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id LAA18592; Thu, 15 May 1997 11:39:30 -0400 (EDT) Received: by world.std.com (5.65c/Spike-2.0) id AA21317; Thu, 15 May 1997 11:39:29 -0400 From: wpns@world.std.com (William Smith) Message-Id: <199705151539.AA21317@world.std.com> Subject: Re: [SS:1433] Re: To IP stack or to not IP Stack ? To: ss@tapr.org Date: Thu, 15 May 1997 11:39:29 -0400 (EDT) In-Reply-To: <337B106E.41C6@eds.tinker.af.mil> from "Steve Sampson" at May 15, 97 08:37:00 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Steve Sampson sez: >1. Contract someone to make a new IP stack > for selected hardware. What about a port of KA9Q? A SMOP, right? -- Willie Smith wpns@world.std.com N1JBJ@amsat.org #define NII Information SuperCollider From jeff@mich.com Thu May 15 11:10: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 LAA29388 for ; Thu, 15 May 1997 11:10:41 -0500 (CDT) Received: from alfalfa (pm001-14.dialip.mich.com [198.108.17.138]) by server1.mich.com (8.8.4/8.8.4) with SMTP id MAA21265 for ; Thu, 15 May 1997 12:12:36 -0400 Message-Id: <2.2.32.19970515160929.00a481ac@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, 15 May 1997 12:09:29 -0400 To: ss@tapr.org From: Jeff King / Kathy King Subject: Re: [SS:1433] Re: To IP stack or to not IP Stack ? At 08:37 AM 5/15/97 -0500, Steve Sampson wrote: >Jeff King / Kathy King wrote: > >> Why not ISA or PCI? It certainly can (would) be more cost effective >> then a stand alone ethernet box, and frankly, would more closely >> fit the "ham" cost model (I think) we are striving for. > >Absolutely not. How many Mac users ever bought a PI-2 card. You'll never design a unit that will make everyone happy. The Mac people can drop the card in a LINUX box. The market is WIN95 and Linux, sorry if that makes MAC/C-64/Amiga/Atari/Timex people unhappy, but thats market realities. Anyways, don't the new Macs have a PCI bus? I think a good education on creeping featurism is to review the mail list TNC-TNG. This thread is mimicking that list. >How >many people bought external devices versus internal devices. Lots. Just compare internal modem sales vs. external. Oh, did I forget to mention, I think any realistic future for amateur radio spread spectrum will come from outside the hobby. That's not to belittle any of those involved now, its just SS is a extremely small segment of the service. Hence I don't think those purchasing a unit will be hobbled by the black box mentality. I think as far as market segment goes, a internal PCI vs external ethernet solution would be identical as far as sales in the ham radio market. Then you need to look at R&D/manufacturing costs as well as ongoing development. The internal solution clearly is the more cost effective solution. It also has the significant advantage of being programmable in-system, with user obtainable development tools. Any embedded controller based system will require a ICE (In Circuit Emulator) for development. Take a look at what happened to TAPR-TNC1 development when access was lost to the ICE for it. The internal solution will have lower up front costs and can have ongoing development done by the end users. Hence the internal solution is more likely to happen and prosper in the long term in the amateur radio market. The only market that could afford the additional cost of the embedded ethernet solution would be the Part 15 wireless ISP field. And I strongly suspect those that advocate a embedded solution have this market in mind. Possibly the additional development costs could be born by these users and it would certainly get the volumes up. But of course, this whole discussion is moot anyways. My design's target is PC-104/ISA and TAPR's NSF design will most likely be based on whatever the PI's decide they want to do. And you'll do whatever you think is is best for your application. 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 cjeffers@luminet.net Thu May 15 11:18:14 1997 Received: from luminet1 (luminet1.luminet.net [204.248.112.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA00184 for ; Thu, 15 May 1997 11:18:11 -0500 (CDT) Received: from luminet1.luminet.net by luminet1 (SMI-8.6/SMI-SVR4) id LAA01570; Thu, 15 May 1997 11:17:00 -0500 Date: Thu, 15 May 1997 11:17:00 -0500 (CDT) From: Jim Jefferson To: ss@tapr.org Subject: Re: IP Stack In-Reply-To: <337B106E.41C6@eds.tinker.af.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Why not ISA or PCI? It certainly can (would) be more cost effective > > then a stand alone ether net box, and frankly, would more closely > > fit the "ham" cost model (I think) we are striving for. > > Absolutely not. How many Mac users ever bought a PI-2 card. How > many people bought external devices versus internal devices. I agree 100% with this. I don't really care about the MacOS users but we need to consider internal vs external. You can't put an PCI card into a laptop or a Sparc. Now if we went with ethernet there is hardware already avaible. It would be simple to put an $20 ethernet card in a computer and then connect it to the radio/modem/router. Ethernet will be around for a long while also... -Jim Jefferson KB0THN cjeffers@luminet.net http://www.luminet.net/~cjeffers/ From RLANIER@mailb.harris.com Thu May 15 12:13:52 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 MAA04402 for ; Thu, 15 May 1997 12:13:51 -0500 (CDT) Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/ Harris.COM Unix mail relay) id NAA19173; Thu, 15 May 1997 13:13:46 -0400 Received: from ccMail by mailb.harris.com (IMA Internet Exchange 1.04b) id 37b43f40; Thu, 15 May 97 13:12:20 -0400 Mime-Version: 1.0 Date: Thu, 15 May 1997 13:12:05 -0400 Message-ID: <37b43f40@mailb.harris.com> Return-receipt-to: RLANIER@mailb.harris.com (RLANIER) From: RLANIER@mailb.harris.com (RLANIER) Subject: Re: [SS:1436] Re: IP Stack To: ss@tapr.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Here we go again ... ______________________________ Reply Separator _________________________________ Subject: [SS:1436] Re: IP Stack Author: ss@tapr.org at smtp Date: 5/15/97 11:23 AM > Why not ISA or PCI? It certainly can (would) be more cost effective > > then a stand alone ether net box, and frankly, would more closely > > fit the "ham" cost model (I think) we are striving for. > > Absolutely not. How many Mac users ever bought a PI-2 card. How > many people bought external devices versus internal devices. I agree 100% with this. I don't really care about the MacOS users but we need to consider internal vs external. You can't put an PCI card into a laptop or a Sparc. Now if we went with ethernet there is hardware already avaible. It would be simple to put an $20 ethernet card in a computer and then connect it to the radio/modem/router. Ethernet will be around for a long while also... -Jim Jefferson KB0THN cjeffers@luminet.net http://www.luminet.net/~cjeffers/ From ge@hpsadr2.sr.hp.com Thu May 15 13:03:15 1997 Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.219]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id NAA15930 for ; Thu, 15 May 1997 13:02:59 -0500 (CDT) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel3.hp.com with ESMTP (8.7.5/8.7.3) id LAA27153 for ; Thu, 15 May 1997 11:02:53 -0700 (PDT) Received: from hpsadr2.sr.hp.com (n6gn.sr.hp.com) by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA289379371; Thu, 15 May 1997 11:02:53 -0700 Received: by hpsadr2.sr.hp.com (1.37.109.16/15.5+ECS 3.3) id AA088309371; Thu, 15 May 1997 11:02:51 -0700 From: Glenn Elmore Message-Id: <199705151802.AA088309371@hpsadr2.sr.hp.com> Subject: soapbox de n6gn To: ss@tapr.org Date: Thu, 15 May 1997 11:02:50 -0800 (PDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit At the risk of continuing the thread past its usefulness, I'll use the question about SS and EME users to support the following thoughts. /* ascend soapbox */ I confess, I am a former amateur EME operator. In the mid '80s prior to delving into higher speed digital radio hardware I built and operated a 432 MHz EME station over 2-3 years and several EME contests. The transmitter ran about 650 watts output to a homebrew 24' stressed parabola. There are pictures of this antenna on the "antenna page": http://www.tapr.org/~n6gn/antenna/antenna.html The station made many contacts with 4-5 continents and was capable of hearing its own echos on SSB when conditions were good. In addition to this two-way EME I also successfully monitored 1296 MHz activity with a smaller homebrew dish. The station was located in Santa Rosa, CA about 50-80 miles north of the San Francisco Bay area which had a moderate amount of terrestrial activity on those bands. However, to my knowledge, there was never a QRM/congestion problem of any kind. In fact, the gain of a skyward-pointed EME dish is intentionally low toward the side (horizon) and back (earth). If this were not so, the system noise temperature would have been degraded by terra firma which is ~290 Kelvin. Comparing the rise in noise floor when the an EME antenna is pointed toward the horizon or ground with what it is when the antenna is pointed toward a "cold" spot in the sky is actually one of the best proofs of system performance EME operators use. With the very weak signals and tight link budgets of EME it is extremely helpful to have a way to know that the reason you don't hear anything "isn't you". Low sidelobes and good front/back antennas are part of EME. Even copying other local EME stations running very high power isn't as easy as might be thought. Since both stations are typically working each other off the sides of their antennas which have considerable front/side ratio, even with high power signals aren't all that strong. On many occasions I have mistaken a local EME station (~50 miles away) for a signal off the moon because signals were so weak. On the few occasions when I did point the dish at local terrestrial stations, signal strengths were indeed impressive. But even from a distance as large as the 50+ miles Santa Rosa is from most of the active community, antenna directivity was such that it wasn't possible to even *copy* all stations without moving the antenna. Terrestrial path losses combined with antenna patterns just don't allow the "band obliterating" signals that you might think. From my experience I would say that a good tropospheric duct tends to generate a lot more RF than EME stations. It sure generates a lot more interest! Whether signals are SS or narrow, my experience even with high power levels and large ERPs is that small signals predominate. From most amateur locations I believe that the largest signals come from transmitters which run relatively low power and low gain antennas (like repeaters). It's possible to find exceptions to this but I think that this is what predominates. /* begin generalization */ So, amid all this speculation and discussion about narrow versus SS operation, IDing and QRM it is my opinion that there is a lot more fear of the unknown than there is experiential content. I've previously made the assertion that in the amateur environment getting *enough* signal over terrestrial paths to support high information content communications is a much bigger problem than QRM or congestion, or even mode/coding/FEC etc. See http://www.tapr.org/~n6gn/dcc/problem.html But, very likely, as large as this problem is, it is small compared to the political/social problem of convincing amateurs to share their resources. Along with the wide/narrow coexistence topic there has been a lot of discussion on this list about interfaces to SS hardware, wishlists for an amateur SS radio and opinions of what "someone" ought to build. It seems to me that "someone" is us. I'm trying to do my part. If those who are interested in seeing amateur SS progress don't pursue the skills and resources necessary to design and develop physical layer (radio) hardware and enlist the help of others who have these skills then we can count on such progress not occuring. I don't believe that the few remaining amateur manufacturers will lead the way in this. If amateurs don't build the hardware then we must adapt someone else's. I question the potential for great contribution, extension to the state of the art or differentiation from existing commercial networks that can result from this approach. If this is still about amateur radio, I think we had better get our collective hands dirty and design/develop *radio*. This is inextricably tied to regulatory, interface, and other higher layer issues but it rests on real, physical hardware. Those who are attracted to and excited by the potential for information age applications and uses for the hobby but who don't have the "RF" experience need to make alliances with other amateurs who do, share the excitement and work together. We need each other's strengths and we must collaborate to succeed. /* end generalization */ /* descend from soapbox */ Glenn Elmore n6gn amateur IP: glenn@SantaRosa.ampr.org Internet: ge@sr.hp.com |--------------- N6GN's Higher Speed Packet WWW Page -------------------| | | | http://www.tapr.org/~n6gn/index.html | | | |-----------------------------------------------------------------------| From n4cnw@ibm.net Thu May 15 13:09:24 1997 Received: from out2.ibm.net (out2.ibm.net [165.87.201.252]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA16648 for ; Thu, 15 May 1997 13:09:22 -0500 (CDT) Received: (from uucp@localhost) by out2.ibm.net (8.6.9/8.6.9) id SAA41261 for ; Thu, 15 May 1997 18:09:21 GMT Received: from murphree.atl.bna.boeing.com(129.172.141.59) by out2.ibm.net via smap (V1.3mjr) id smaMvoDFW; Thu May 15 18:09:15 1997 Message-ID: <337B52CA.3427@ibm.net> Date: Thu, 15 May 1997 14:15:38 -0400 From: Mike Murphree X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1435] Re: To IP stack or to not IP Stack ? References: <2.2.32.19970515160929.00a481ac@mail.mich.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jeff King / Kathy King wrote: > You'll never design a unit that will make everyone happy. The Mac people > can drop the card in a LINUX box. The market is WIN95 and Linux, sorry > if that makes MAC/C-64/Amiga/Atari/Timex people unhappy, but thats > market realities. Anyways, don't the new Macs have a PCI bus? > I think a good education on creeping featurism is to review the mail > list TNC-TNG. This thread is mimicking that list. This thread also does not appear to be making any more progress than the TNC-TNG list did either. There were *way* too many conflicting interests to accomplish *anything*. But for what, it's worth I wouldn't go for an internal solution. There is too much trouble already in getting extra cards to work in Plug-N-Pray systems. If I use ethernet, I only need one I/O address and IRQ for what could be thousands of controllers, for serial ports (or possibly plug-in cards) I need one for *each* controller. > Oh, did I > forget to mention, I think any realistic future for amateur radio > spread spectrum will come from outside the hobby. That's not to > belittle any of those involved now, its just SS is a extremely > small segment of the service. Hence I don't think those purchasing > a unit will be hobbled by the black box mentality. Possibly more for economic reasons than technical... I can't afford to go out and buy a Sun UltraSPARC, Mentor Graphics DA and QuickHDL, and FPGA programmers for home use and the company takes a dim view of me using the ones at work for anything personal these days. > development. The internal solution clearly is the more cost > effective solution. It also has the > significant advantage of being programmable in-system, with user > obtainable development tools. > > Any embedded controller based system > will require a ICE (In Circuit Emulator) for development. Take a look > at what happened to TAPR-TNC1 development when access was lost to the > ICE for it. The internal solution will have lower up front costs and > can have ongoing development done by the end users. Hence the > internal solution is more likely to happen and prosper in the long > term in the amateur radio market. Things have changed a great deal since those days. Lots of processors have their own flavor of internal debug port capability now. A wealth of free GNU development software also exists for many of the same processors. This was mentioned on TNC-TNG a long time ago but seemed to fall on deaf ears. Somewhere, I have seen a web page with an HC11 processor (granted underpowered) on a board with an accompanying ethernet chip... This was *not* an expensive design. It also had the capability of being operated with any computer with an ethernet port. > The only market that could > afford the additional cost of the embedded ethernet solution would be the > Part 15 wireless ISP field. And I strongly suspect those that advocate > a embedded solution have this market in mind. Possibly the additional > development costs could be born by these users and it would certainly > get the volumes up. Not at all... I'd like to see *less* commercial involvement since I can point to 3 or 4 ham related projects that have been moved into commercial production at prices that are way out of reason. > But of course, this whole discussion is moot anyways. My design's target > is PC-104/ISA and TAPR's NSF design will most likely be based on whatever > the PI's decide they want to do. And you'll do whatever you think is > is best for your application. Yeah, it's getting plumb silly just like it did on the TNC-TNG list almost 2 years ago now. 73 Mike N4CNW From cjeffers@luminet.net Thu May 15 13:56:49 1997 Received: from luminet1 (luminet1.luminet.net [204.248.112.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA19645 for ; Thu, 15 May 1997 13:56:46 -0500 (CDT) Received: from luminet1.luminet.net by luminet1 (SMI-8.6/SMI-SVR4) id NAA07255; Thu, 15 May 1997 13:55:40 -0500 Date: Thu, 15 May 1997 13:55:40 -0500 (CDT) From: Jim Jefferson To: ss@tapr.org Subject: Internal vs External In-Reply-To: <37b43f40@mailb.harris.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Isn't it more important to actually get something going before we debate of this subject though? I'm a no-nothing in terms of this sort of thing but wouldn't line drivers (not the right name but...) be supporting hardware? Maybe we could come up with a box where we plug the ISA card in and it comes out as an ethernet port... Keep everyone happy Anyhow lets worry about the task at hand. -Jim Jefferson KB0THN cjeffers@luminet.net From karn@qualcomm.com Thu May 15 18:51:34 1997 Received: from laptop.ka9q.ampr.org (ra4000-p63.qualcomm.com [129.46.54.143]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA18472 for ; Thu, 15 May 1997 18:51:28 -0500 (CDT) Received: by laptop.ka9q.ampr.org id m0wRsQZ-000Rw0C (Debian Smail-3.2 1996-Jul-4 #2); Thu, 15 May 1997 04:46:07 +0000 (UTC) Message-Id: Date: Thu, 15 May 1997 04:46:07 +0000 (UTC) From: Phil Karn To: ss@tapr.org In-reply-to: <379e4fd0@mailb.harris.com> (RLANIER@mailb.harris.com) Subject: Re: [SS:1422] Re: SS Questions for Rule Filing I suppose my real intent of my EME question was to play devil's advocate: if a EME user builds an antenna that has alot of "leakage" on both sides of the main lobe, this could potentially interfere with weak signal, satellite users, especially if the EME user is pumpimg out 1500 watts. I just curious why the satellite and repeater people haven't complained about that, or have they? This is quite true. It hasn't been a problem so far because the EME users tend to stay in a small dedicated part of the band so they won't bother anybody else. If they begin to use wider modes, they'll have to be more careful. Phil From lfry@mindspring.com Thu May 15 20:50:33 1997 Received: from brickbat8.mindspring.com (brickbat8.mindspring.com [207.69.200.11]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA26878 for ; Thu, 15 May 1997 20:50:30 -0500 (CDT) Received: from glory (user-37kb8l3.dialup.mindspring.com [207.69.162.163]) by brickbat8.mindspring.com (8.8.5/8.8.5) with SMTP id VAA25737 for ; Thu, 15 May 1997 21:50:28 -0400 (EDT) Message-Id: <2.2.32.19970516015421.003863a0@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, 15 May 1997 21:54:21 -0400 To: ss@tapr.org From: "Lee W. Fry" Subject: Re: [SS:1437] Re: IP Stack A big problem is always line loss from the transceiver to the antenna. If the transceiver has a twisted pair ethernet interface, then it can be way out there where the antenna is. All we need is a way to get DC power to it. One way would be to use unused pairs from a four pair cable. Means we need to pay attention to environmental specs though to use it like this. One problem with putting an IP stack in it is you need a way to administer it. Things like telling it what it's address is, routes, etc. Could be done in-band (SMTP, or how about it having it's own http server like some of the new printers?), out-of-band (with a serial port) or even with some kind of local entry device (anything from dip switches to a LCD display with a menu driven entry system. AS many point out, if it is a PCI/ISA/whatever card, you can certainly wrap a cheap computer around it or use the one you have. Be kinda hard to put it up there on the tower though. Lee - AA0JP From jeff@mich.com Thu May 15 22:34:36 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 WAA04127 for ; Thu, 15 May 1997 22:34:34 -0500 (CDT) Received: from alfalfa (pm001-41.dialip.mich.com [198.108.17.165]) by server1.mich.com (8.8.4/8.8.4) with SMTP id XAA29570 for ; Thu, 15 May 1997 23:36:40 -0400 Message-Id: <2.2.32.19970516033321.008ffb2c@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, 15 May 1997 23:33:21 -0400 To: ss@tapr.org From: Jeff King / Kathy King Subject: Re: [SS:1442] Re: IP Stack At 08:56 PM 5/15/97 -0500, Lee W. Fry wrote: > >AS many point out, if it is a PCI/ISA/whatever card, you can certainly wrap >a cheap computer around it or use the one you have. Be kinda hard to put it >up there on the tower though. > >Lee - AA0JP > You don't. You have a remote mounted pre-amp/amp just like all the amsat folks have used for years as well as most of the Part 15 consultants use. Or you have the RF head remote mountable. Or you bite the bullet and use something a bit better then RG-58 for your feedline. 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 marty@trucom.com Fri May 16 00:49:06 1997 Received: from thepit.trucom.com (root@thepit.trucom.com [199.217.237.251]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id AAA27770; Fri, 16 May 1997 00:49:03 -0500 (CDT) Received: from MAIN (dialup2.trucom.com [199.217.237.101]) by thepit.trucom.com (8.6.12/8.6.10) with SMTP id AAA13331; Fri, 16 May 1997 00:49:30 -0500 Message-Id: <1.5.4.32.19970516054857.0069a7b8@mail.trucom.com> X-Sender: marty@mail.trucom.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 May 1997 00:48:57 -0500 To: packet-pbbs@qsl.net, aprssig@tapr.org, bbssig@tapr.org, hfsig@tapr.org, netsig@tapr.org, ss@tapr.org From: Marty Albert Subject: HAmPS Home Page This message is to announce the new Heartland AMateur Packet Society (HAmPS) Home Page located at URL: http://www.geocities.com/CapeCanaveral/Lab/7067 HAmPS is a group that facilitates packet radio network development with a focus on operations in the Heartland of the United States. Membership is FREE and open to all interested parties. Please drop by the HAmPS Home Page for more information. Take Care & 73 Marty Albert - marty@trucom.com Amateur Radio: KC6UFM@KC6UFM.#SEMO.MO.USA.NOAM Heartland Internet Services ******************************************* Interested in Amateur Radio? http://www.trucom.com/ppages/marty ******************************************* From ssampson@cool.site.net Fri May 16 09:10:12 1997 Received: from cool.site.net ([204.87.241.225]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id JAA11417 for ; Fri, 16 May 1997 09:10:08 -0500 (CDT) Received: from chalice.site.net (chalice.site.net [204.87.241.226]) by cool.site.net (8.8.5/8.8.5) with SMTP id JAA30009 for ; Fri, 16 May 1997 09:09:47 -0500 Message-ID: <337C6A83.57E7@cool.site.net> Date: Fri, 16 May 1997 09:09:07 -0500 From: Steve Sampson X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: IP Stack Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kathy King wrote: > I think a good education on creeping featurism is to review the mail > list TNC-TNG. This thread is mimicking that list. I agree. Go read that junk, it has all been said before. I think Greg has the right idea, press on. As for how you would control an IP Black box? You would do it like the Telnet Servers do it. Add an ARP entry into your table with the Ethernet address label on the back of the unit. Then add an IP address and hostname into your hosts or DNS, and then ping the unit. The unit detects it's Ethernet address and grabs the IP address offered. Steve From darnell@binmedia.com Fri May 16 11:11:54 1997 Received: from gumby.binmedia.com ([204.140.236.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA20951 for ; Fri, 16 May 1997 11:11:52 -0500 (CDT) Received: from [206.117.173.2] by gumby.binmedia.com (post.office MTA v1.9.3 ID# 0-12756) with SMTP id AAA122 for ; Fri, 16 May 1997 09:05:22 -0700 Subject: Re: [SS:1445] Re: IP Stack Date: Fri, 16 May 97 09:11:59 -0700 x-mailer: Claris Emailer 2.0, March 15, 1997 From: darnell@binmedia.com (Darnell Gadberry) To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <19970516160522002.AAA122@[206.117.173.2]> On 5/16/97 Steve Sampson wrote: >As for how you would control an IP Black box? You would do it >like the Telnet Servers do it. Add an ARP entry into your table >with the Ethernet address label on the back of the unit. Then add >an IP address and hostname into your hosts or DNS, and then >ping the unit. The unit detects it's Ethernet address and grabs >the IP address offered. > Phar Lap Eoftware publishes an embedded Win32 compatible operating system called Realtime ETS. Since it is Win32 compatible you can use any of the popular PC C/C++ development systems to write code. Additionally, It features a complete TCP/IP stack, PPP drivers, Ethernet drivers, and a HTTP (Web) server. Plus, the whole thing fits in < 256 Kb! It supports 80286 or better Intel processors. The software development kit is priced at $4,995 and the per-unit licenses in our quantities would be somewhere around $8 - $12 per unit. - darnell gadberry ke6ucl binaryMedia Communications darnell@binmedia.com From jeff@mich.com Fri May 16 12:13:34 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 MAA26509 for ; Fri, 16 May 1997 12:13:32 -0500 (CDT) Received: from alfalfa (pm001-44.dialip.mich.com [198.108.17.168]) by server1.mich.com (8.8.4/8.8.4) with SMTP id NAA29428 for ; Fri, 16 May 1997 13:15:51 -0400 Message-Id: <2.2.32.19970516171217.0090f894@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, 16 May 1997 13:12:17 -0400 To: ss@tapr.org From: Jeff King Subject: Re: [SS:1445] Re: IP Stack At 09:12 AM 5/16/97 -0500, Steve Sampson wrote: >Jeff King wrote: > >> I think a good education on creeping featurism is to review the mail >> list TNC-TNG. This thread is mimicking that list. > >I agree. Go read that junk, it has all been said before. > >I think Greg has the right idea, press on. > >Steve You say you understand what I am saying Steve, but I don't think so. I believe a short history lesson is in order for you to help you understand my point. TNC-TNG started with a simple premise.... to extend the software of the TNC2 to be more friendly to computers that can talk SLIP. Then creeping featurism entered the frey... ultimately ending up (almost) exactly were we are now. A 'free standing' IP blackbox with a integrated radio talking ethernet. And you know what, it never got built and much more sadly, the creeping featurism discouraged those that actually were working on extending the capabilities of the TNC2. One should attempt to learn from history and not continue to go down the same meaningless path. Am I saying a stand alone ethernet/radio IP router box is a bad idea? Of course not (although I think it should be 100baseT, not 10baseT). What I am saying, is I believe it is beyond the capabilities of a ad-hoc group of amateurs. How many on this mailing list have taken a product COMPLETELY from design concept, coding, PCB layout, production and on to sales? How many are will to volunteer their time and equipment to make it so? I'm not talking about your college project or something you do as a hobby. I'm talking about something you did as a entrepreneur or at a small company. I know I could count the people that have done this (on this list) on one hand, and I don't think anyone in that group has chosen to comment yet. And frankly, while I have taken my product designs completely through the cycle, I don't think I would be willing to contribute significant amounts of my time and resources for free. I firmly believe in the KISS principle, as long as it makes sense. While my PCI/ISA suggestion is not the most elegant, it can be made to suit every concern I have seen here. More importantly, it fits the bulk of the market- place as is, its simpler to make and is more scalable. TAPR's present revenues come off of royalties and kit sales. Hence given what I know about TAPR, it seems to me TAPR should target items that have a chance of selling more then 50 pieces. Now that could all change in a heartbeat, as I have no idea if TAPR got the NSF grant as Greg didn't comment on that. With that kind of seed money, people could be paid to develop a IP switch/blackbox. And from what little I understand, the proposed NSF grant is a radio device for the general purpose market, hence the volume would be there to support a affordable end user price. But of course, unless someone from TAPR cares to confirm or deny the above, all this is hearsay. What say Greg? Beyond that, the point (or at least my point) is to suggest something that at least has a chance of being a commercial success in the HAM RADIO marketplace (note I am not including the PART15 marketplace). What is lacking in the HAM RADIO marketplace is a spread spectrum radio. We already have ethernet IP routers in the form of LINUX/KA9Q NOS as well as a significant software labor pool enhancing that software. Focus on what we really need instead of a utopia that may not make financial sense. Understanding that, if you still want to yadda yadda yadda about the perfect widget, then have at it. As much as everyone wants to ignore it, the marketplace does rule. 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 ssampson@cool.site.net Fri May 16 12:32:32 1997 Received: from cool.site.net ([204.87.241.225]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id MAA05535 for ; Fri, 16 May 1997 12:32:30 -0500 (CDT) Received: from chalice.site.net (chalice.site.net [204.87.241.226]) by cool.site.net (8.8.5/8.8.5) with SMTP id MAA03342 for ; Fri, 16 May 1997 12:32:30 -0500 Message-ID: <337C99E1.47F7@cool.site.net> Date: Fri, 16 May 1997 12:31:13 -0500 From: Steve Sampson X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: IP Stacks -- Pacific Softworks Home Page Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Embedded TCP/IP, PPP, etc, for typical chipsets: http://www.pacificsw.com/ From ssampson@cool.site.net Fri May 16 15:47:06 1997 Received: from cool.site.net ([204.87.241.225]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id PAA16808 for ; Fri, 16 May 1997 15:47:04 -0500 (CDT) Received: from chalice.site.net (chalice.site.net [204.87.241.226]) by cool.site.net (8.8.5/8.8.5) with SMTP id PAA09035 for ; Fri, 16 May 1997 15:47:04 -0500 Message-ID: <337CC775.54B7@cool.site.net> Date: Fri, 16 May 1997 15:45:41 -0500 From: Steve Sampson X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1447] Re: IP Stack References: <2.2.32.19970516171217.0090f894@mail.mich.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jeff King wrote: > > You say you understand what I am saying Steve, but I don't think so. I believe > a short history lesson is in order for you to help you understand my point. > TNC-TNG started with a simple premise.... to extend the software of the > TNC2 to be more friendly to computers that can talk SLIP. Then creeping > featurism entered the frey... ultimately ending up (almost) exactly were > we are now. A 'free standing' IP blackbox with a integrated radio talking > ethernet. And you know what, it never got built and much more sadly, the > creeping featurism discouraged those that actually were working on extending > the capabilities of the TNC2. One should attempt to learn from history > and not continue to go down the same meaningless path. My writing style evidently puts people off, but I am not a know-it-all, far from it. My background as a Ham is limited. My bottom line in any message, is a simple analysis of what's going on. I can be easily swayed on technology, because my company, and my work surrounds that which was designed and built 5 - 10 years ago. You're right, I missed your point. I think Greg [please correct me if I'm wrong] is starting out with an idea of a black box high speed modem (voice and data). TNC-TNG on the other hand started out as a TNC-2 replacement. I see it as two ends of the spectrum (no pun intended). Therefore I only point out that black boxes are best left black boxes and not have a Bus architecture. Then you have to decide how to interface the black box. Suffice to say, ethernet is the standard. Laptops are being built with PCMCIA cards now. In the end, the SS modem should be a PCMCIA card. Until then, an asynchronous serial PCMCIA card is about the same cost as an ethernet PCMCIA card. Plus all the Unix and Windows, and Mac stuff out there. It's just an observation, not a position. Steve From jerryn@ici.net Fri May 16 22:09:52 1997 Received: from localhost (d-ma-fallriver-39.ici.net [207.180.10.48]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id WAA17038 for ; Fri, 16 May 1997 22:09:48 -0500 (CDT) Received: from nomad by localhost with smtp (Smail3.1.29.1 #58) id m0wSZrr-000VTTC; Fri, 16 May 97 23:09 EDT Sender: root@tapr.org Message-ID: <337D2157.7E8E2048@ici.net> Date: Fri, 16 May 1997 23:09:11 -0400 From: Jerry Normandin X-Mailer: Mozilla 4.0b3C (X11; I; Linux 2.0.26 i686) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1442] Re: IP Stack X-Priority: 3 (Normal) References: <2.2.32.19970516015421.003863a0@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jerry Replies: Why all the fuss? I use a NECWaveLAn card, drive 100 ft. of LRM400 cable, have a 25dB bilateral amplifier mounted right on the Linear Phased Array Antennea. I can do 26 miles (only limited by the curve of the earth!) No need for 100 Watts.. this is all done at 10 Watts. We all know how low the Spectral Power Density is.. we are talking low power! I use the Linux Operating System and my fixed/mobile router code. Lee W. Fry wrote: > > A big problem is always line loss from the transceiver to the antenna. If > the transceiver has a twisted pair ethernet interface, then it can be way > out there where the antenna is. All we need is a way to get DC power to it. > One way would be to use unused pairs from a four pair cable. > > Means we need to pay attention to environmental specs though to use it like > this. > > One problem with putting an IP stack in it is you need a way to administer > it. Things like telling it what it's address is, routes, etc. Could be > done in-band (SMTP, or how about it having it's own http server like some of > the new printers?), out-of-band (with a serial port) or even with some kind > of local entry device (anything from dip switches to a LCD display with a > menu driven entry system. > > AS many point out, if it is a PCI/ISA/whatever card, you can certainly wrap > a cheap computer around it or use the one you have. Be kinda hard to put it > up there on the tower though. > > Lee - AA0JP From jerryn@ici.net Fri May 16 22:16:51 1997 Received: from localhost (d-ma-fallriver-39.ici.net [207.180.10.48]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id WAA17370 for ; Fri, 16 May 1997 22:16:46 -0500 (CDT) Received: from nomad by localhost with smtp (Smail3.1.29.1 #58) id m0wSZyb-000VTTC; Fri, 16 May 97 23:16 EDT Sender: root@tapr.org Message-ID: <337D22F9.A9B93B17@ici.net> Date: Fri, 16 May 1997 23:16:09 -0400 From: Jerry Normandin X-Mailer: Mozilla 4.0b3C (X11; I; Linux 2.0.26 i686) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1441] Re: SS Questions for Rule Filing X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All I need is 10 Watts per hop. The spectral power density is low since we are using Spread Spectrum. No need for 1800 watts... shit, what are you going to talk to... some mole uderground? There is a limit... the curve of the earth? even at 1800 Watts at 100' you are only going to get 26 miles or so! You need height.... not power! I would like to push 10 Watts off of my tethered blimp at 500' and have someone else do the same in Bermuda.... I bet it will work (I am in New England .. by the east coast) Phil Karn wrote: > > I suppose my real intent of my EME question was to play devil's > advocate: if a EME user builds an antenna that has alot of "leakage" > on both sides of the main lobe, this could potentially interfere with > weak signal, satellite users, especially if the EME user is pumpimg > out 1500 watts. I just curious why the satellite and repeater people > haven't complained about that, or have they? > > This is quite true. It hasn't been a problem so far because the EME users > tend to stay in a small dedicated part of the band so they won't bother > anybody else. If they begin to use wider modes, they'll have to be > more careful. > > Phil From karn@qualcomm.com Fri May 16 22:44:17 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 WAA18929 for ; Fri, 16 May 1997 22:44:14 -0500 (CDT) Received: by laptop.ka9q.ampr.org id m0wSRLv-000Rw0C (Debian Smail-3.2 1996-Jul-4 #2); Fri, 16 May 1997 18:03:39 +0000 (UTC) Message-Id: Date: Fri, 16 May 1997 18:03:39 +0000 (UTC) From: Phil Karn To: priya@students.itb.ac.id CC: ss@tapr.org In-reply-to: (priya@students.itb.ac.id) Subject: Re: CDMA on satellite communication >could you tell me literature about CDMA for satellite communication This is a pretty broad subject (pun intended). A good general reference is the IEEE reprint "Multiple Access Communications". It came out in 1991 or so. It has a good section on spread spectrum. Phil From jeff@mich.com Sat May 17 10:35: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 KAA23595 for ; Sat, 17 May 1997 10:34:59 -0500 (CDT) Received: from alfalfa (pm001-27.dialip.mich.com [198.108.17.151]) by server1.mich.com (8.8.4/8.8.4) with SMTP id LAA00457 for ; Sat, 17 May 1997 11:37:50 -0400 Message-Id: <2.2.32.19970517153352.008bb0f0@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, 17 May 1997 11:33:52 -0400 To: ss@tapr.org From: Jeff King / Kathy King Subject: Re: [SS:1451] Re: SS Questions for Rule Filing Jerry: EME stands for Earth Moon Earth. The 'hop' these folks are trying to cover is 500,000+ miles (2X times the distance to the moon) which allows them to talk to the opposite ends of the earth (up to 12,000 miles). The moon is not a very good reflector, hence the need for such high power/erp. -Jeff At 10:31 PM 5/16/97 -0500, Jerry Normandin wrote: >All I need is 10 Watts per hop. The spectral power density is low >since we are using Spread Spectrum. No need for 1800 watts... shit, >what are you going to talk to... some mole uderground? There is a >limit... the curve of the earth? even at 1800 Watts at 100' you are >only going to get 26 miles or so! You need height.... not power! > >I would like to push 10 Watts off of my tethered blimp at 500' >and have someone else do the same in Bermuda.... I bet it will work >(I am in New England .. by the east coast) > > >Phil Karn wrote: >> >> I suppose my real intent of my EME question was to play devil's >> advocate: if a EME user builds an antenna that has alot of "leakage" >> on both sides of the main lobe, this could potentially interfere with >> weak signal, satellite users, especially if the EME user is pumpimg >> out 1500 watts. I just curious why the satellite and repeater people >> haven't complained about that, or have they? >> >> This is quite true. It hasn't been a problem so far because the EME users >> tend to stay in a small dedicated part of the band so they won't bother >> anybody else. If they begin to use wider modes, they'll have to be >> more careful. >> >> Phil > > From djk@tobit.co.uk Mon May 19 03:47:53 1997 Received: from 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 DAA03936 for ; Mon, 19 May 1997 03:47:41 -0500 (CDT) Received: (qmail 26937 invoked by uid 500); 19 May 1997 08:47:25 -0000 Date: Mon, 19 May 1997 09:47:25 +0100 (BST) From: Dirk Koopman Reply-To: djk@tobit.co.uk To: ss@tapr.org Subject: Re: [SS:1446] Re: IP Stack In-Reply-To: <19970516160522002.AAA122@[206.117.173.2]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 16 May 1997, Darnell Gadberry wrote: > On 5/16/97 Steve Sampson wrote: > > >As for how you would control an IP Black box? You would do it > >like the Telnet Servers do it. Add an ARP entry into your table > >with the Ethernet address label on the back of the unit. Then add > >an IP address and hostname into your hosts or DNS, and then > >ping the unit. The unit detects it's Ethernet address and grabs > >the IP address offered. > > > > Phar Lap Eoftware publishes an embedded Win32 compatible operating system > called Realtime ETS. Since it is Win32 compatible you can use any of the > popular PC C/C++ development systems to write code. Additionally, It > features a complete TCP/IP stack, PPP drivers, Ethernet drivers, and a > HTTP (Web) server. Plus, the whole thing fits in < 256 Kb! It supports > 80286 or better Intel processors. > > The software development kit is priced at $4,995 and the per-unit > licenses in our quantities would be somewhere around $8 - $12 per unit. > Being an old skin-flint and this being amateur radio I would have thought something like Xinu or RTEMS would have been more appropriate. They are free, available in source and have a stack. Someone has said that the reason things haven't been done is because we are trying to do too much at once. The trouble is I think what people are actually looking for is the new 'killer' TNC which will do for SS what the TNC2 did for packet. The problem is that IS just that much harder because people's expectations have been increased both by use of tncs and the internet. They don't want (and most can't) "fiddle" with the technology, it beyond most of them - not just from a software or modem hardware point of view but also more basically on the RF side. How many people on this list has any serious test gear for bands above 70cms and (as I have no choice) especially bands above 1000Mhz. What it then comes down to (unfortunately) is a black box. The only way this is likely to happen is if some competant volunteer can find the time to do it. That means taking time out from the (similar) job they are already probably doing and (probably) convincing themselves that this could be a commercial success or failing that, a technology learning tool that at least pays most of the direct costs in producing it. Having done this sort of thing in past, I realise it ain't quick or cheap - but neither need it be prohibitively expensive. -- 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 frussle@erols.com Mon May 19 14:54:37 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 OAA25426 for ; Mon, 19 May 1997 14:54:34 -0500 (CDT) Received: from col-as6s02.erols.com (col-as6s02.erols.com [207.172.129.65]) by smtp2.erols.com (8.8.5/8.8.5) with SMTP id PAA13518 for ; Mon, 19 May 1997 15:54:16 -0400 (EDT) From: frussle@erols.com (Jake Brodsky) To: ss@tapr.org Subject: Re: [SS:1454] Re: IP Stack Date: Mon, 19 May 1997 19:52:25 GMT Organization: Cyberflight Inc. Wannabe Message-ID: <3381996b.21098554@smtp.erols.com> References: In-Reply-To: X-Mailer: Forte Agent 1.0/32.390 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Allow me to introduce myself. I'm the other guy that Tony, N3JLI, is working with on building a spread spectrum radio. I've been lurking on and off for some time on the SS mail list. Tony e-mails me the interesting stuff. But lately, I thought I'd rejoin the list to see what's new for myself. I have an observation to make: /* BEGIN SOAPBOX */ Toward the end of that wonderfully funny series of books Douglas Adams wrote, beginning with "The Hitch-Hiker's Guide to the Galaxy," there was a scene where all the humans crash-landed on pre-historic Earth. These humans were the folks who couldn't lead nor do anything particularly useful in their society: The bureaucrats, advertising executives, lawyers, and so on. Those who survived the crash landing on earth were suffering from cold and starvation. They knew they needed warmth and food. They had heard of this thing called "fire." So they did market research on "fire." =20 What was this fire thing? How should it be sold? Should it be inserted nasally? Would anyone want a pocket fire? Who should use fire? Should it be licensed? These were the sort of things they couldn't decide. They spent weeks and weeks in committee like this until eventually they devolved to near savagery and those few surviving earthlings re-discovered fire. Doesn't this sound like the great interface debate for a spread spectrum radio? Does anyone arguing this issue know enough to actually build this interface? Does anyone have a working spread spectrum radio? =46rankly this debate got old several months ago when I first signed up. I thought the folks who were pursuing this secondary issue would have gotten over it by now. I was wrong. Were this a newsgroup, I'd have made up a kill filter long ago. Please folks, leave the interface issue alone until someone actually has a working radio. =20 Then I'll care. /* END SOAPBOX */ 73, Jake Brodsky, AB3A mailto:frussle@erols.com "Beware of the massive impossible!" From wd5ivd@tapr.org Mon May 19 15:58:51 1997 Received: from [128.83.113.132] (slip-a-7.ots.utexas.edu [128.83.113.71]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id PAA00293 for ; Mon, 19 May 1997 15:58:47 -0500 (CDT) Message-Id: In-Reply-To: <2.2.32.19970515160929.00a481ac@mail.mich.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 May 1997 15:20:42 -0500 To: ss@tapr.org From: "Greg Jones, WD5IVD" Subject: Re: [SS:1435] Re: To IP stack or to not IP Stack ? >My design's target is PC-104/ISA When can you post more about your approach Jeff ? Cheers - Greg ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From jeff@mich.com Mon May 19 22:08:30 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 WAA02298; Mon, 19 May 1997 22:08:28 -0500 (CDT) Received: from alfalfa (pm001-14.dialip.mich.com [198.108.17.138]) by server1.mich.com (8.8.4/8.8.4) with SMTP id XAA16381; Mon, 19 May 1997 23:12:27 -0400 Message-Id: <2.2.32.19970520030725.00963a00@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: Mon, 19 May 1997 23:07:25 -0400 To: ss@tapr.org, wd5ivd@tapr.org From: Jeff King Subject: Re: [SS:1456] Re: To IP stack or to not IP Stack ? At 04:04 PM 5/19/97 -0500, Greg Jones, WD5IVD wrote: >>My design's target is PC-104/ISA > >When can you post more about your approach Jeff ? > >Cheers - Greg Not to much to post.... I'm considering taking the Harris reference design for PCMCIA and moving it over to PC/104 (ISA is quite similar). This is for a commercial design for one of my customers, so I'll have to see about making it available for hobbyists, but if it happens this should be possible. They (harris) use the AMD radio MAC layer chip, which supposedly will work on either the ISA or PCMCIA buss. Nice thing about it is the WIN95 drivers are already written. Needless to say, there is not a whole lot original here. First I need to finish up a PC/104 automotive power supply design, but that should be wrapped up in the next week or two. Right now I am using Xircom (Now Netwave) PCMCIA 2.5ghz frequency hopping SS modems. The application is for downloading GPS data from city (transit) buses when the buses come near the bus terminal. I've got about 300 deployed so far. With the Xircom's I need to buy a PC/104 to PCMCIA adapter in addition to the cost of the Xircom. Hence my interest in a direct PC/104 interface. The Xircom's only have about a 1/4 mile range, mostly due to there low power (25mw) and integral antenna. I'd of course make a external antenna connector and see about running a bit more power. Likely I'd put the amp right at the antenna. And yes, power control is part of any design I do. I believe that it is standard (or at least the ability) is also standard with the Harris chip set. Ran across a interesting module today, a potted 386SX with ISA, IDE, Floppy, 512K flash, 2meg dram, 2 serial, 1 parallel all on a module about 2"X2" running at 40mhz. Claim that you can use standard development tools. Price at 1000piece qty's was $104 each. You need to drop some ethernet glue chips on its ISA buss for what you want, but might make a good crossover product that in its "canned" mode could serve the educational community while allowing enough hooks for continued development/expansion for the amateur radio side. BTW, it also included a embedded DOS and BIOS with no additional royalties. I left the ad off site (and can't remember the name) but they are supposed to send me more info. 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 RLANIER@mailb.harris.com Thu May 22 09:31:42 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 JAA24467 for ; Thu, 22 May 1997 09:31:40 -0500 (CDT) Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/ Harris.COM Unix mail relay) id KAA26439; Thu, 22 May 1997 10:31:35 -0400 Received: from ccMail by mailb.harris.com (IMA Internet Exchange 1.04b) id 38458730; Thu, 22 May 97 10:30:11 -0400 Mime-Version: 1.0 Date: Thu, 22 May 1997 10:28:23 -0400 Message-ID: <38458730@mailb.harris.com> Return-receipt-to: RLANIER@mailb.harris.com (RLANIER) From: RLANIER@mailb.harris.com (RLANIER) Subject: [HFSIG:2113] Negative SNR, SS and FEC. To: ss@tapr.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part These questions were posed on the HFSIG mail list. I thought someone on this list might be able to answer his questions. Tony ______________________________ Forward Header __________________________________ Subject: [HFSIG:2113] Negative SNR, SS and FEC. Author: hfsig@tapr.org at smtp Date: 5/22/97 2:12 AM Does someone have the time to explain the following in layman's terms:(or perhaps in undergrad maths :-) 1. It is said that a spread spectrum system can work at negative SNR's. How does this tie in with Shannons Limit of -1.6dB ? 2. What is the difference between spread spectrum process gain and coding gain that one can obtain from say Viterbi FEC ? Just wondering, the SETI thread has made me think about it. Danie From hbaker@netcom.com Thu May 22 12:02:35 1997 Received: from netcom23.netcom.com (hbaker@netcom23.netcom.com [192.100.81.137]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id MAA04094 for ; Thu, 22 May 1997 12:02:34 -0500 (CDT) Received: (from hbaker@localhost) by netcom23.netcom.com (8.6.13/Netcom) id KAA24585; Thu, 22 May 1997 10:02:27 -0700 From: hbaker@netcom.com (Henry G. Baker) Message-Id: <199705221702.KAA24585@netcom23.netcom.com> Subject: Re: [SS:1458] [HFSIG:2113] Negative SNR, SS and FEC. To: ss@tapr.org Date: Thu, 22 May 1997 10:02:26 -0700 (PDT) In-Reply-To: <38458730@mailb.harris.com> from "RLANIER" at May 22, 97 09:40:06 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Does someone have the time to explain the following in layman's > terms:(or perhaps in undergrad maths :-) > > 1. It is said that a spread spectrum system can work at negative SNR's. > How does this tie in with Shannons Limit of -1.6dB ? SS systems utilize waveforms that have low correlations with other SS waveforms, and also noise. If you are willing to use very long sequences and accumulate over a very long time, you can pull the signal out of a lot of noise. In fact, GPS receivers do this all the time. Don't try to read too much into Shannon's channel equation, but look to the reasoning in the proof -- it gives far more insight than the equation. > 2. What is the difference between spread spectrum process gain and > coding gain that one can obtain from say Viterbi FEC ? As Dixon says, redundant error correction codes are a very mild form of SS. Turning this around, the coding people have long studied the properties of 'random' codes, since the algebra people had trouble coming up with synthetic codes of really big minimum distances between code-words. So the ideas are really very similar, and there is a continuum between redundancy codes and SS codes. -- Henry Baker www/ftp directory URL: ftp://ftp.netcom.com/pub/hb/hbaker/home.html From jra1854@tntech.edu Thu May 22 15:51:39 1997 Received: from tntech.edu (gemini.tntech.edu [149.149.11.7]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id PAA26577; Thu, 22 May 1997 15:51:36 -0500 (CDT) Received: from [149.149.39.26] ("port 2018"@cookie-monster.ece.tntech.edu) by tntech.edu (PMDF V5.1-8 #16786) with SMTP id <01IJ6C2BN2S28WWGVB@tntech.edu>; Thu, 22 May 1997 15:50:01 CDT Date: Thu, 22 May 1997 15:49:59 -0600 From: jra1854@tntech.edu (Jeffrey Austen) Subject: Re: [SS:1458] [HFSIG:2113] Negative SNR, SS and FEC. X-Sender: jra1854@gemini.tntech.edu To: ss@tapr.org Cc: hfsig@tapr.org, RLANIER@mailb.harris.com (RLANIER) Message-id: MIME-version: 1.0 Content-type: text/plain; charset="us-ascii" >Does someone have the time to explain the following in layman's >terms:(or perhaps in undergrad maths :-) > >1. It is said that a spread spectrum system can work at negative SNR's. >How does this tie in with Shannons Limit of -1.6dB ? Both are correct. The confusion arises because they refer to two different measurements. Shannon's limit states that reliable communication can be obtained with Eb/No >= -1.6 dB. Eb is the energy per data bit (before error correction coding -- coding may make the bit or symbol rate in the channel different than the actual data rate) and No is the noise power spectral density. SNR is signal to noise ratio, that is signal power divided by noise power. Eb/No is related to SNR by the data rate and the effective noise bandwidth. The following relates SNR to Eb/No. Ps is signal power and Pn is noise power. (The noise power spectral density is assumed to be constant.) Ps Bit Rate Eb -- = --------- X -- Pn Bandwidth No In a spread-spectrum system the same power is spread out over a much larger bandwidth. From the above it can be seen that if the bandwidth is increased by a factor of one-hundred that the SNR will decrease by the same amount. Thus the SNR can be negative while Eb/No is positive. >2. What is the difference between spread spectrum process gain and >coding gain that one can obtain from say Viterbi FEC ? Process gain and coding gain are different things. Process gain is a measure of the amount of "spreading" which is done to the signal. It is directly related to the interference rejection capabilities. If the channel is ideal (additive white Gaussian noise, no interference, no fading) process gain does absolutely nothing towards better error rates. However, in a real channel (with interference, fading, etc.) process gain does help mitigate some of the effects and therefore does help the error rate as compared to a non-spread system. Coding gain is obtained from adding redundancy to the message sent. >Just wondering, the SETI thread has made me think about it. Sounds interesting. Looking at how communication system have evolved over the past few decades makes me wonder how we expect to receive whatever type of modulation the ETIs decide to send! Jeff, k9ja P.S. I'm currently not on HFSIG and will not see followups to this message from that group. --- Jeffrey Austen | Tennessee Technological University jra1854@tntech.edu | Box 5004 +1 615 372 3485 | Cookeville Tennessee 38505 U.S.A. From N5RG@aol.com Fri May 23 11:38:01 1997 Received: from emout11.mail.aol.com (emout11.mx.aol.com [198.81.11.26]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA11220 for ; Fri, 23 May 1997 11:37:59 -0500 (CDT) From: N5RG@aol.com Received: (from root@localhost) by emout11.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0) id MAA28980 for ss@tapr.org; Fri, 23 May 1997 12:37:25 -0400 (EDT) Date: Fri, 23 May 1997 12:37:25 -0400 (EDT) Message-ID: <970523123721_909984250@emout11.mail.aol.com> To: ss@tapr.org Subject: SS IF bandwidth SS Experts: I have been trying to understand how a spread spectrum signal is received. I have been wondering what is the best kind of IF amplifier for SS. For example, assume that a data bit was sent by spreading it such that it was sent at 8 different frequencies over the length of time required to send that bit. It seems to me if a receiver were tuned to one of these frequencies that it would see a pulse appearing at random intervals. The optimum IF response would be a pulse amplifer tuned such that it matched the characteristics of the pulse. The bandwidth would have to be wide to allow the pulse to pass through. But in a SS receiver the frequency the receiver is tuned to hops around to follow the transmitted frequency. In this case, it seems to me that a narrow IF bandwidth could be used if the signal coming to the IF was phase coherant so that the ringing in the IF amplifier filters would continue to be reinforced by the signal feeding it. It also seem to me to be quite a trick to keep the signal feeding the IF phase coherant as the frequency hops around. Most likely the SS receiver does not work the way I have invisioned above but works in some manner I have not thought of. If so, how does it work? 73, Roy W7IDM, ex N5RG From marty@trucom.com Sun May 25 22:18:47 1997 Received: from thepit.trucom.com (root@thepit.trucom.com [199.217.237.251]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id WAA27189; Sun, 25 May 1997 22:18:44 -0500 (CDT) Received: from MAIN (dialup24.trucom.com [199.217.237.123]) by thepit.trucom.com (8.6.12/8.6.10) with SMTP id WAA13522; Sun, 25 May 1997 22:18:41 -0500 Message-Id: <1.5.4.32.19970526031835.006744b0@mail.trucom.com> X-Sender: marty@mail.trucom.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 25 May 1997 22:18:35 -0500 To: bbssig@tapr.org, netsig@tapr.org, ss@tapr.org From: Marty Albert Subject: Is SS The Solution For High Speed Packet Networks? Hello, Folks: I have a feeling that I may catch a lot of flames for this one from the SS crowd, but... I've done a lot of reading and testing the past year or so and was wondering if I am the only person who does not see Spread Spectrum (SS hereafter) to be the answer for high speed, high bandwidth packet networks. Now, don't get me wrong... I fully support the continued experiments with SS that may lead to something valuable, but I am talking about real world, here and now applications. After doing a lot of research, it has become clear to me that SS suffers from several major problems for practical use in a large network... (1) There are no fully documented systems using SS that are cost effective that I have found. (2) Most of the SS systems I have looked at require a lot of tweaking to get them to work, often meaning a near re-engineering of the system for each link. (3) None of the real experts doing SS development (I am not one of them!) seem to be willing to develop a simple, reproducible SS system that can be used right now. Based on what I have actually seen of packet networks and on what I have read other people say about their local networks, I think that most high speed packet networks fall into one of the following classes: (A) There ain't one. (B) The network is broken to some extent or another, often due to lack of repairs and/or updates. (C) The network is 10 or more years out of date, still relying on old, slow links (sometimes 9600 bps, often 1200 bps). So, what we really need is a "Plug And Play" network solution. SS does not, at this time, offer such ease of set up and operation. It may at some point in the future, but not now. There are several options out there now, but one of the best that I have seen in terms of documentation and the ability to be reproduced is the system being used in Slovenia. (see http://lois.kud-fp.si/hamradio/packet.html for more information) The Slovenian network uses high speed radio modems to allow speeds up to 1.2 Mbps. All of the shematics, PCB layouts, etc. are fully available. The fine folks there that are involved with the project are also very willing to help and answer questions. It is worth noting that the Slovenian system uses simple techniques that are both time tested and understandable by, I suspect, most Hams. Again, don't get the wrong idea here... I am not saying that the Slovenian system is better than SS, just that it is much easier to impliment and it is available now. A pair of 1.2 Mbps Slovenian style radio modems can be built in less than a week for less than $100.00. My experiements with SS took 6 weeks and nearly $200.00 to get working and they were still not right and only 56 Kbps. I would encourage those doing SS development to continue to do so, but to perhaps shift the focus to real world applications. We need clear, reproducible designs that are simple to build, install, set up and operate. And, perhaps even more important in the packet world where $$$ are hard to come by, we also need something that is inexpensive. So, in closing, those interested in packet networking should take a close look at the Slovenian system (URL above) before jumping on the SS bandwagon. It just seems that I am the only person out there who is not in love with SS as the solution for high speed packet. Take Care & 73 Marty Albert - marty@trucom.com Amateur Radio: KC6UFM@KC6UFM.#SEMO.MO.USA.NOAM ************************************************ Interested in Amateur Radio? http://www.trucom.com/ppages/marty ************************************************ HAmPS Coordinator http://www.geocities.com/CapeCanaveral/Lab/7067 ************************************************ From wa4dsy@wa4dsy.radio.org Mon May 26 11:05:43 1997 Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA04934 for ; Mon, 26 May 1997 11:05:41 -0500 (CDT) Received: (from uucp@localhost) by out1.ibm.net (8.6.9/8.6.9) id QAA464333 for ; Mon, 26 May 1997 16:05:40 GMT Message-Id: <199705261605.QAA464333@out1.ibm.net> Received: from wa4dsy-1.wa4dsy.radio.org(208.148.146.146) by out1.ibm.net via smap (V1.3mjr) id sma%M0C92; Mon May 26 16:05:05 1997 From: "Dale Heatherington" To: "ss@tapr.org" Date: Mon, 26 May 97 12:05:00 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:1462] Is SS The Solution For High Speed Packet Networks? On Sun, 25 May 1997 22:22:59 -0500 (CDT), Marty Albert wrote: >Again, don't get the wrong idea here... I am not saying that the Slovenian >system is better than SS, just that it is much easier to impliment and it is >available now. A pair of 1.2 Mbps Slovenian style radio modems can be built >in less than a week for less than $100.00. My experiements with SS took 6 >weeks and nearly $200.00 to get working and they were still not right and >only 56 Kbps. At the risk of describing commonly known facts and getting off the topic of SS I'll add my 2 cents worth. Lets not forget the WA4DSY 56KB modems which are available assembled and tested. You need only add a transverter (Downeast Microwave) and a PI2 card (Ottawa). This is plug and play. Although it isn't as fast as the Slovenian system it only takes 100khz channels. A bit regenerator is built in for easy implementation of computerless full duplex mtn. top repeaters (we have 2 in Atlanta). A forward error correction EPROM is available. This email and all access to my web server pass through 5 modems on the way to/from the ISP over a 35 mile path (includes 2 bit repeaters, 222 mhz and 440mhz). I can hit the ISP via one bit repeater but I use both to keep tabs on the systems operation. This system is rock solid and trouble free. I suppose I should publish something on the implimentation of this system... There is an external TX clock input to allow connecting two modems back to back which enables linking 2 or more FDX bit repeaters without a computer. One of the Atlanta sites is configured this way. It has a 440/445 mhz FDX bit repeater linked to a 222/223 mhz simplex 56k modem/transverter configured to talk to the other mtn top FDX bit repeater. In short, they work as a single FDX bit repeater with access from either the 440 band or 222 band. During the past 23 days the web server reports it has sent 135 megabytes in 12,732 transactions. The OS/2 PI card driver reports 774,800 TX frames and 695,175 RX frames during this time. Now, back the the normal SS topics. -------------------------------------------------- Dale Heatherington, WA4DSY e-mail - daheath@ibm.net Web page - http://www.wa4dsy.radio.org OS/2 Warp 4.0 The worlds finest desktop OS. From N5RG@aol.com Mon May 26 11:15:15 1997 Received: from emout12.mail.aol.com (emout12.mx.aol.com [198.81.11.38]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA05519 for ; Mon, 26 May 1997 11:15:14 -0500 (CDT) From: N5RG@aol.com Received: (from root@localhost) by emout12.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0) id MAA08424 for ss@tapr.org; Mon, 26 May 1997 12:14:43 -0400 (EDT) Date: Mon, 26 May 1997 12:14:43 -0400 (EDT) Message-ID: <970526121441_587598288@emout12.mail.aol.com> To: ss@tapr.org Subject: Re: [SS:1462] Is SS The Solution For High Speed Packet Networks? Marty: I have been hearing about SS for several years now and have been trying to understand how it works. I have learned that it does have some very marvelous properties and has some important benefits. But not without complications such as the requirement for extremely accurate clocks. Some organizations such as the U.S. Army consider the benefits worth the considerable expense of solving the complications and can raise the money to pay for the required solutions. >From what I have seem, Amateur Radio is a different kind of operation. For something to be successful it has to be either very inexpensive or offer some very great benefit. Perhaps the last great change in the way of doing things happened in the 1960's when Hams converted from AM to SSB. It seems to me that one reason this worked was that Hams like to talk and SSB helped them talk better while at the same time producing smaller radios by getting rid of those big heavy modulation transformers. The next great innovation was the FM repeater. This was largely made possible by the availability of cheap surplus commercial radios. If it had been necessary for Hams to develop their own FM radios from scratch, the FM revolution would have taken a lot longer or perhaps never happened. Packet Radio seems to be kind of a fringe operation in Amateur Radio. Quite a few Hams have given it a try as an alternative to talking. And a few have have made packet their primary interest. But talking still seems to be the most popular use of Amateur Radio. Perhaps digital radio will not really take off until it is used as the basis of a network used for talking. This would have the benefit of making the network useful for all kinds of things besides talking such as exchanging pictures to explain what we are talking about, etc, etc. Then we would really be getting someplace! I am not sure what the best way to achieve such a network is. Should it be based upon narrowband high speed data channels such as those beginning to be used for the new Digital Television system (scheduled to replace the current analog system by 2006), or should it be based upon digital cellular telephones using spread spectrum techniques that have been converted to operate in the Ham bands? Or what??? 73, Roy W7IDM, ex N5RG, W5PAG From wb9mjn@wb9mjn.ampr.org Mon May 26 14:56:54 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 OAA25617 for ; Mon, 26 May 1997 14:51:21 -0500 (CDT) Received: from wb9mjn-1.ampr.org by wb9mjn.ampr.org (JNOS1.10i) with SMTP id AA14164 ; Mon, 26 May 97 13:22:21 UTC Message-ID: <3389E8C1.5F38@wb9mjn.ampr.org> Date: Mon, 26 May 1997 14:47:14 -0500 From: Don Lemke Reply-To: wb9mjn%wb9mjn.ampr.org@uugate.aim.utah.edu Organization: Ant-Panel Products X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: ss@tapr.org Subject: Re:[SS:1462] Is SS The Solution For High Speed Packet Networks? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Marty, At first, I thought allot the way u do. I was thinking along the lines of the Slovenian radios, but on 3.3 Ghz, and 2 MB. I was thinking about doing Differential PSK. Its quick and dirty. The demodulation uses a mixer in a similar fashion to a Quadrature FM detector. But instead of a 90 degree phase shift, it uses a 1 bit delay line. There s a problem with the Slovenian radios for USA application. The modulation quality would not be legal in the US, I believe. Also, a 1.2 MB PSK signal is as wide as one of the two 1.2 Ghz data allocations. So, that would leave only two channels, or 1 full duplex channel. Unless we ignored weak signal, FM and ATV allocations. I imagine the Slovenians are taking the view that 1.2 Ghz is useless for these applications, for the average Slovenian ham. And have carved up the band for Digital so that the average ham gets great advantage from the band while not being directly on it. A great thing to do, but a good way to start a turf war in the USA. The Slovenian radios have allot of good points too. They are cheap. There s no need for double conversion Transverter, as with the WA4DSY modem (which is a clearly superior modulation), and thus allot of RF expense is cut out of the total package. Then the Internet explosion happened. 1.2 Mb links are great, but it was not going to do , if the drop into somebodies QTH was still only 56 KB, and 6 or 700 bucks. I even had problem here, out of my apartment, with 9600 baud and delay spread effects of Multipath. Delay spread is the big problem. I was shocked when i realised that i was seeing packets lost due to delay spread, at a mere 9600 baud. I solved the problem with a unidirectional antenna. But even so, it points out what is going to be an even bigger problem at megabaud rates. A Metropolitan network will need megabaud into the home qth, to be viable. Even if the average thruput required is 100 s of KB, the need for high burst rates for all those fun applications, is going to be there. Direct Sequence Spread Spectrum with digital matched filter is a great tool for solving this problem. DSSS with the digital matched filter (DMF) can lock up in one symbol time. The extra bandwidth of the signal allows for this, while still limiting the noise bandwith to that of the information bandwidth. But, right now there s not enuf processing gain, available cheap. What is available cheap is 18 dB processing gain (STEL2000a). Its safe to have more than this, say something like 25 dB, to keep equal amplitude secondary path signals down out of the modem capture range, in the home qth application. Unidirectional antennas can easily provide an extra 13 dB of multipath rejection. Many of the other issues u bring up are RF networking enviorment issues. They are best handled by a new way of doing the MAN (metropolitan area network). We now have organisations that build cellular style networks. If a link goes down, technical people from the organisation have to go fix it. I think this is great stuff, but its the wrong way to do things, now. First off, the link gear is too low a level of production to be economic. Even if it is excruciatingly cheap compared to professional gear doing the same job. The cost of the link gear is either in time to make it, or money to buy it (if its plug and play). Either way, there are not many spares, usually. This results in an unreliable network. With the Internet explosion, users have higher expectations. 33.6, or 56 KB at least. To get such thruput, the RF network raw data rate has to be allot more, and the more hops out from an internet gateway, the more the data rate has to be. While, it would be easy to make a 56 KB access packet network , in the pattern we have now, the goal is to have 10 s of people in a metropolitan area with that level of thruput. Even a successful club would have a hard time keeping such a network on-air , even if they could afford to put it in. Allot of political packet people say we need to get money out of the users. That s simpler said than done. If we had the $20 /month from people, that ISP s get, things would be easier. But, lets face it, that is not going to happen. ISP s will get that money, more readily, than we, because they have the familiar, reliable, user funded Telephone company gaurunteeing connectivity. The DDMA/WAN (directivity division multiple access/wide area network) (also known as the "Flying Saucer Net") addresses this. Its a DSSS/DMF radio, and an azimuthal scanning antenna. The antenna scans looking for RTS (Request to Send) 'ing stations, and then answers those. A packet comes in, it goes up to the level three, and then back out to the radio with a direction towards the next network partner in-line towards the destination. Each user, if he wants in on this, buys and installs his own radio. The local organisation priorities are shifted to education, applications and support, rather than network building and maintenance. The manpower available at local ham clubs can readily do the education and support jobs, typically. Its tuff to get people to do the network building and maintenance, as well as sites that can be accessed by the technical people without the primary site representative. Allot of stuff doesn t get done, because one guy can t make it, even if two or three are available. Opertunistic situations are also eliminated. Which is deadly to an volunteer workforce getting anything done. With DDMA/WAN thruput is maximised in the time-bandwidth-area resource, by tight directive beams, and sending packets to the closest neighbor towards the destination, with minimun power to do that link level hop. This minimises area used, per transmission, and also minimises the number non-participating stations overlapped by that area-time-bandwidth being used. With this system, participants are paying for what they use, thru the radio gear. There s enuf production level on the link/user gear to be viable, since they are one in the same. Reliability is enhanced, because megabaud link is at every user location, and rerouting becomes readily doable. Its economic, because one does not need a point to point antenna, and seperate feedline for each neighbor (thanks to the scanning antenna technology). The delay spread problem is dealt with by the directional antenna, as best as can be done. Kinda look at this way, If we have to use directional antenna to do high data rates, then we need to make the directional antenna the network. The azimuthal scan antenna is the economic result of making the directional antenna the network. The DSSS/DMF radio is the result of the need for fast lock-up. As a network changes, one does not need a new antenna for a new direction. Just a new bearing to command the antenna to. A network of this type can start with two guys who want to do something like CUSEEME, teleconferencing. And grow as others like what they see, and put on their own stations. No need for in-depth planning, other than for the individuals to judge if they will be in range. Versus the cellular model, which needs a sizable group of people to support the high cost central site. I see SS as a neccassary tool for High Speed Packet networking. I came to this opinion, thru experience, and the discussions that led to the DDMA/WAN concept. Originally, the only value I saw to SS, was that a DSSS/DMF off the shelf chip, could lock up in one symbol time, with out any noise bandwidth increase. This is neet, of itself, but not all that needed, until u try to do a home based megabaud network. U know, ATT Long Lines ran multimegabaud microwave links, with out any SS, for years and years. But they did have the advantage of megabuck sites and antennas. The radio technology to do this has become quite cheap in this past decade. But, the physics of the microwave path remains the same. SS is probably the only way to get the megabaud into the home qth that is not on mounted on a tower, on the best high ground around. So, I guess, the question is not really one of SS for High Speed data or not, but do u want to do ur network the way they have been in the past, or to do it by something resembling the DDMA-WAN way? Where the network is grown, rather than built. I personally cannot see the way things have been done, even in places where that way has been successful, continuing for a long time. The Internet's popularity changes it all. If we continue building ATT style links, and drops, without any way of funding it, we will loose out to people doing that, with funding. If we build DDMA-WAN radio/antenna , we have a chance of growing networks that will be omni-useful to all hams, and supported and installed by all hams. Just as the any ham would throw on a SSB HF station, now. -- 73, Don. AMPRNet : wb9mjn@wb9mjn.ampr.org[44.72.98.19] Internet: wb9mjn%wb9mjn.ampr.org@uugate.aim.utah.edu Finger: wb9mjn@wb9mjn.ampr.org From srbible@gate.net Mon May 26 16:43:28 1997 Received: from osceola.gate.net (root@osceola.gate.net [199.227.0.18]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA02809 for ; Mon, 26 May 1997 16:43:16 -0500 (CDT) Received: from avatar.gate.net (kngga2-20.gate.net [207.36.2.20]) by osceola.gate.net (8.8.5/8.6.12) with SMTP id RAA54708 for ; Mon, 26 May 1997 17:43:12 -0400 Message-Id: <3.0.1.32.19970526174256.006946f0@pop.gate.net> X-Sender: srbible@pop.gate.net X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 26 May 1997 17:42:56 -0400 To: ss@tapr.org From: "Steven R. Bible" Subject: [from UO-22] Spread Spectrum QRM? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" I picked this off of UO-22 this morning (Monday, May 26, 1997). - Steve, N7HPR --------------------[UO-22:60811]-------------------- From: GB7LAN To: ALL SATGAT Subject: SATGEN 426 Spread Spectrum QRM Keywords: AMSAT SATGEN ---------------------------------------- SB AMSAT @ AMSAT < GM4IHJ $SGEN426 Satgen426 Spread Spectrum QRM R:970523/0548 @:GB7SAN.#78.GBR.EU Satgen426 Spread Spectrum QRM ? by GM4IHJ (BID SGEN426) 24 May 97 There are two basic ways to modulate a radio signal with information. You can use narrow band modulation as with systems like SSB, PSK and even FM. Restricting the signal to a relatively narrow band of frequencies but using a lot of power in the narrow sidebands. Or you can spread the signal out thinly like jam in a sandwich, covering 500 KHz or more of bandwidth but spreading out the power distribution so that the power in each few KHz is ( or should be ) very low. Spread Spectrum modulation of signals has been around for a very long time, but the arrival of digital systems has suddenly given it much greater prominence. It is being proposed in some quarters for amateur radio use, and it has already appeared in several military systems and is being canvassed for many forthcoming commercial systems. Not least amongst its "qualities" , is the suggestion that it can easily share with (overlay), existing systems of modulation without ill effect to them or itself. Is this true ? Recent experience suggests it is not. One of the earliest examples of the worldwide use of spread spectrum occured in the late 1970s and early 1980s, when the Soviets were conducting Killer satellite tests. Far from being covert, the signals were very obvious. Stretching over 500 KHz of bandwith in the radio amateur 2m band they produced a forest of carriers roughly 1.5 KHz apart dopplering across the band at considerable signal strength at any receiver in the satellites footprint. They were a nuisance but they never became frequent enough to constitute a major problem. Unfortunately modern spread spectrum systems introduced unannounced, are already apparently going a long way towards ruining the 70 cm amateur band and its adjacent spectrum over the British Isles. The signals appear to come from the masts of the high power UHF stations which radiate the 5 channels of the UK terrestrial television service. But the signals are clearly not a product or cross modulation artifact of the TV signals. They appear to be totally separate military or government traffic. As seen on a spectrum analyser 14 kms from one of the TV masts, the noise level background appears to rise +10dB over a band of frequencies which stretches all across 430 to 440 MHz and some way beyond at either end. The signals are apparently being radiated from several widely separated TV masts in various parts of the UK, and they are destroying radio amateur low signal strength experimental work such as Moonbounce, Mars vehicle tracking, Sporadic E, Meteor Scatter, FAI and Auroral studies, over a wide arc of bearing. Transmission power appears to be several Kilowatts and the signals seems to be data with pseudo random noise modulation. This British experience is salutory. Clearly "Sharing" bands with authorities who operate in this way is an impossibility. The Spread spectrum takes over the whole band, blatantly ignoring other band users. A situation which becomes highly significant in view of the recent suggestions that radio amateurs accept sharing with spread spectrum users on several of their bands, as presently being discussed by at least one national authority. 73 de GM4IHJ@GB7SAN or gm4ihj@branegan.demon.co.uk + /EX From jerryn@ici.net Mon May 26 20:52:51 1997 Received: from localhost (d-ma-newbedford-17.ici.net [207.180.13.26]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id UAA26540 for ; Mon, 26 May 1997 20:52:48 -0500 (CDT) Received: from nomad by localhost with smtp (Smail3.1.29.1 #58) id m0wWBQt-000VTRC; Mon, 26 May 97 21:52 EDT Sender: root@tapr.org Message-ID: <338A3E4F.12A8232C@ici.net> Date: Mon, 26 May 1997 21:52:15 -0400 From: Jerry Normandin X-Mailer: Mozilla 4.0b3C (X11; I; Linux 2.0.29 i686) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1462] Is SS The Solution For High Speed Packet Networks? X-Priority: 3 (Normal) References: <1.5.4.32.19970526031835.006744b0@mail.trucom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jerry Normandin replies: I am very interested in the slovian approach... can you forward me the schmatics or a URL? That costs less then a Wavelan card that's for sure! What protocol do you run? AX.25?? Marty Albert wrote: > > Hello, Folks: > > I have a feeling that I may catch a lot of flames for this one from the SS > crowd, but... > > I've done a lot of reading and testing the past year or so and was wondering > if I am the only person who does not see Spread Spectrum (SS hereafter) to > be the answer for high speed, high bandwidth packet networks. > > Now, don't get me wrong... I fully support the continued experiments with SS > that may lead to something valuable, but I am talking about real world, here > and now applications. > > After doing a lot of research, it has become clear to me that SS suffers > from several major problems for practical use in a large network... > > (1) There are no fully documented systems using SS that are cost effective > that I have found. > > (2) Most of the SS systems I have looked at require a lot of tweaking to get > them to work, often meaning a near re-engineering of the system for each link. > > (3) None of the real experts doing SS development (I am not one of them!) > seem to be willing to develop a simple, reproducible SS system that can be > used right now. > > Based on what I have actually seen of packet networks and on what I have > read other people say about their local networks, I think that most high > speed packet networks fall into one of the following classes: > > (A) There ain't one. > > (B) The network is broken to some extent or another, often due to lack of > repairs and/or updates. > > (C) The network is 10 or more years out of date, still relying on old, slow > links (sometimes 9600 bps, often 1200 bps). > > So, what we really need is a "Plug And Play" network solution. SS does not, > at this time, offer such ease of set up and operation. It may at some point > in the future, but not now. > > There are several options out there now, but one of the best that I have > seen in terms of documentation and the ability to be reproduced is the > system being used in Slovenia. (see > http://lois.kud-fp.si/hamradio/packet.html for more information) > > The Slovenian network uses high speed radio modems to allow speeds up to 1.2 > Mbps. All of the shematics, PCB layouts, etc. are fully available. The fine > folks there that are involved with the project are also very willing to help > and answer questions. > > It is worth noting that the Slovenian system uses simple techniques that are > both time tested and understandable by, I suspect, most Hams. > > Again, don't get the wrong idea here... I am not saying that the Slovenian > system is better than SS, just that it is much easier to impliment and it is > available now. A pair of 1.2 Mbps Slovenian style radio modems can be built > in less than a week for less than $100.00. My experiements with SS took 6 > weeks and nearly $200.00 to get working and they were still not right and > only 56 Kbps. > > I would encourage those doing SS development to continue to do so, but to > perhaps shift the focus to real world applications. We need clear, > reproducible designs that are simple to build, install, set up and operate. > > And, perhaps even more important in the packet world where $$$ are hard to > come by, we also need something that is inexpensive. > > So, in closing, those interested in packet networking should take a close > look at the Slovenian system (URL above) before jumping on the SS bandwagon. > > It just seems that I am the only person out there who is not in love with SS > as the solution for high speed packet. > > Take Care & 73 > > Marty Albert - marty@trucom.com > Amateur Radio: KC6UFM@KC6UFM.#SEMO.MO.USA.NOAM > > ************************************************ > Interested in Amateur Radio? > http://www.trucom.com/ppages/marty > ************************************************ > HAmPS Coordinator > http://www.geocities.com/CapeCanaveral/Lab/7067 > ************************************************ From wd5ivd@tapr.org Mon May 26 21:45:53 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 VAA01607 for ; Mon, 26 May 1997 21:45:51 -0500 (CDT) Message-Id: In-Reply-To: <338A3E4F.12A8232C@ici.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 May 1997 21:50:13 -0500 To: ss@tapr.org From: "Greg Jones, WD5IVD" Subject: Re: [SS:1467] Re: Is SS The Solution For High Speed Packet Networks? >Jerry Normandin replies: > >I am very interested in the slovian approach... can you forward me the >schmatics or >a URL? That costs less then a Wavelan card that's for sure! >What protocol do you run? AX.25?? > It was all published in the last ARRL/TAPR 15th Digital Communications Conference. Matjaz Vidmar, S53MV, published two papers this last year. Lyle Johnson was responsible for getting Matjaz to get publish his work. See: http://www.tapr.org/tapr/html/cnc15.html 13cm PSK Transceiver for 1.2Mbit/s Packet Radio by Matjaz Vidmar, S53MV Abstract: This paper describes the design of a 13cm 1.2Mbit/s PSK transceiver for packet radio by Matjaz Vidmar, S53MV. Includes: schematics, layout, figures, and experimental results. 23cm PSK packet-radio RTX for 1.2Mbit/s user access by Matjaz Vidmar, S53MV Abstract: This paper describes the design of a 23cm 1.2Mbit/s user access RTX by Matjaz Vidmar, S53MV. Includes: schematics, layout, figures, and experimental results. As I tell people each year -- if you can't attend the DCC each year you should at least get a copy of the proceedings. I am always going back and referring to papers published in the past. If you can attend -- the DCC is a lot of fun and there is always a lot to discuss in the way of new approaches by people. The 1997 DCC is in Baltimore in Oct. http://www.tapr.org/dcc Cheers - Greg P.S. Anyone interested in digital communications is invited to submit a paper for publication in the Conference Proceedings. Presentation at the Conference is not required for publication. If you know of someone who is doing great things with digital communications, be sure to personally tell them about this! Papers are due by ** August 20th, 1997 **, and should be submitted to Maty Weinberg, ARRL, 225 Main Street, Newington, CT 06111 or via the Internet to lweinberg@arrl.org. Information on paper submission guidelines are available on-line. ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From marty@trucom.com Mon May 26 22:05:51 1997 Received: from thepit.trucom.com (root@thepit.trucom.com [199.217.237.251]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id WAA03093 for ; Mon, 26 May 1997 22:05:44 -0500 (CDT) Received: from MAIN (dialup25.trucom.com [199.217.237.124]) by thepit.trucom.com (8.6.12/8.6.10) with SMTP id WAA22517 for ; Mon, 26 May 1997 22:05:54 -0500 Message-Id: <1.5.4.32.19970527030540.00681444@mail.trucom.com> X-Sender: marty@mail.trucom.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 May 1997 22:05:40 -0500 To: ss@tapr.org From: Marty Albert Subject: Re: [SS:1464] Re: Is SS The Solution For High Speed Packet Networks? At 11:19 05/26/97 -0500, Roy W7IDM wrote: >Marty: > >I have been hearing about SS for several years now and have been trying >to understand how it works. I have learned that it does have some very >marvelous properties and has some important benefits. But not without >complications such as the requirement for extremely accurate clocks. >Some organizations such as the U.S. Army consider the benefits worth >the considerable expense of solving the complications and can raise the >money to pay for the required solutions. SS does some great things now and has the potential, I believe, to do even more in the future. That is one small part of the problem, as I see it... We need solutions NOW. At this time, we keep hearing little "tid bits" about various projects that people are working on, some sound good, some not (nothing unusal there). But, getting information on how to actually use these ideas in real world applications is slow to come. What information there is needs someone with the knowledge to re-engineer the system and the $$$ for the seemingly big money that SS takes. >From what I have seem, Amateur Radio is a different kind of operation. >For something to be successful it has to be either very inexpensive or offer >some very great benefit. I'm not sure that inexpensive and great benefits are mutually exclusive... After all, as in your examples, SSB and FM both offer benefits over plain vanilla AM, but they are both less expensive to impliment. One could argue that this was not true back in the early days of SSB and FM (frankly, I don't know... I wasn't there) but SS has been used in the military and commercial markets for a long time now. Costs should be down on specialized devices to some extent. >Packet Radio seems to be kind of a fringe operation in Amateur Radio. >Quite a few Hams have given it a try as an alternative to talking. And a few >have have made packet their primary interest. But talking still seems to be >the most popular use of Amateur Radio. > >Perhaps digital radio will not really take off until it is used as the basis >of a network used for talking. This would have the benefit of making the >network useful for all kinds of things besides talking such as exchanging >pictures to explain what we are talking about, etc, etc. Then we would >really be getting someplace! You may have hit upon something here, Roy... I have never thought about it from this particular angle... Given enough bandwidth, digital voice is no problem... Even at 56 Kbps it is possible (the quality is not too great, but it's not all that bad). This needs some more thought time! >I am not sure what the best way to achieve such a network is. Should it >be based upon narrowband high speed data channels such as those beginning >to be used for the new Digital Television system (scheduled to replace >the current analog system by 2006), or should it be based upon digital >cellular telephones using spread spectrum techniques that have been >converted to operate in the Ham bands? Or what??? That is my question, too... Each has some interesting possibilities, advantages, and disadvantages... Narrowband imposes limits on throughput. In fact, your throughput is a function of bandwidth, so this is universal. SS holds a lot of promise, but we need something now. Wideband can be done now and done cheap. There are a few legal issues to look at in some bands as well as bandplan issues that would need to be addressed. >73, Roy W7IDM, ex N5RG, W5PAG Take Care & 73 Marty Albert - marty@trucom.com Amateur Radio: KC6UFM@KC6UFM.#SEMO.MO.USA.NOAM ************************************************ Interested in Amateur Radio? http://www.trucom.com/ppages/marty ************************************************ HAmPS Coordinator http://www.geocities.com/CapeCanaveral/Lab/7067 ************************************************ From marty@trucom.com Mon May 26 22:28:25 1997 Received: from thepit.trucom.com (root@thepit.trucom.com [199.217.237.251]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id WAA04034 for ; Mon, 26 May 1997 22:28:21 -0500 (CDT) Received: from MAIN (dialup25.trucom.com [199.217.237.124]) by thepit.trucom.com (8.6.12/8.6.10) with SMTP id WAA22705 for ; Mon, 26 May 1997 22:28:32 -0500 Message-Id: <1.5.4.32.19970527032818.0068637c@mail.trucom.com> X-Sender: marty@mail.trucom.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 May 1997 22:28:18 -0500 To: ss@tapr.org From: Marty Albert Subject: Re: [SS:1467] Re: Is SS The Solution For High Speed Packet Networks? At 21:01 05/26/97 -0500, you wrote: >Jerry Normandin replies: > > > > > >I am very interested in the slovian approach... can you forward me the >schmatics or >a URL? That costs less then a Wavelan card that's for sure! >What protocol do you run? AX.25?? > http://lois.kud-fp.si/hamradio/packet.html for more information) The testing that I am doing is using JNOS with normal AX.25 Note that much of the SLovenian system can't legally be used full time in the US due to the bandwidth. (the 70cm WBFM for example) Take Care & 73 Marty Albert - marty@trucom.com Amateur Radio: KC6UFM@KC6UFM.#SEMO.MO.USA.NOAM ************************************************ Interested in Amateur Radio? http://www.trucom.com/ppages/marty ************************************************ HAmPS Coordinator http://www.geocities.com/CapeCanaveral/Lab/7067 ************************************************ From marty@trucom.com Mon May 26 22:28:25 1997 Received: from thepit.trucom.com (root@thepit.trucom.com [199.217.237.251]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id WAA04033 for ; Mon, 26 May 1997 22:28:19 -0500 (CDT) Received: from MAIN (dialup25.trucom.com [199.217.237.124]) by thepit.trucom.com (8.6.12/8.6.10) with SMTP id WAA22702 for ; Mon, 26 May 1997 22:28:28 -0500 Message-Id: <1.5.4.32.19970527032814.00691b00@mail.trucom.com> X-Sender: marty@mail.trucom.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 May 1997 22:28:14 -0500 To: ss@tapr.org From: Marty Albert Subject: Re: [SS:1465] Re:Is SS The Solution For High Speed Packet Networks? At 14:59 05/26/97 -0500, Don WB9MJN wrote: >Hi Marty, > > At first, I thought allot the way u do. I was thinking along the >lines of the Slovenian radios, but on 3.3 Ghz, and 2 MB. I was thinking >about doing Differential PSK. Its quick and dirty. The demodulation uses >a mixer in a similar fashion to a Quadrature FM detector. But instead of >a 90 degree phase shift, it uses a 1 bit delay line. Actually, I ran the other way... For a long time, I was on the SS bandwagon, but have decided that SS may not be the way to go from a practical standpoint. > There s a problem with the Slovenian radios for USA application. >The modulation quality would not be legal in the US, I believe. I too had some concerns til I put the spectrum analyzer on one of the units... Actually looks pretty good! >Also, a >1.2 MB PSK signal is as wide as one of the two 1.2 Ghz data allocations. >So, that would leave only two channels, or 1 full duplex channel. Unless >we ignored weak signal, FM and ATV allocations. I imagine the Slovenians >are taking the view that 1.2 Ghz is useless for these applications, for >the average Slovenian ham. And have carved up the band for Digital so >that the average ham gets great advantage from the band while not being >directly on it. A great thing to do, but a good way to start a turf war >in the USA. Possibly... The use of 23cm seems to very geographical. Around here, the nearest 23cm radio is over 100 miles away! Where I lived in CA, there were almost as many folks on 23cm as on 2m. Go figure. > The Slovenian radios have allot of good points too. They are >cheap. There s no need for double conversion Transverter, as with the >WA4DSY modem (which is a clearly superior modulation), and thus allot of >RF expense is cut out of the total package. The WA4DSY is a great system, although limited to 56 Kbps and outragiously priced. (I have seen the older "GRAPES" versions modified for a little more than 256 Kbps) The big problem I see with the WA4DSY system is the price... You're looking at nearly $1,000.00 per station to get the thing on the air. Frankly, that is rediculous. > Then the Internet explosion happened. 1.2 Mb links are great, but >it was not going to do , if the drop into somebodies QTH was still only >56 KB, and 6 or 700 bucks. I even had problem here, out of my apartment, >with 9600 baud and delay spread effects of Multipath. Delay spread is >the big problem. I was shocked when i realised that i was seeing packets >lost due to delay spread, at a mere 9600 baud. I solved the problem with >a unidirectional antenna. But even so, it points out what is going to be >an even bigger problem at megabaud rates. A Metropolitan network will >need megabaud into the home qth, to be viable. Even if the average >thruput required is 100 s of KB, the need for high burst rates for all >those fun applications, is going to be there. Direct Sequence Spread >Spectrum with digital matched filter is a great tool for solving this >problem. I agree... SS does potentially offer a solution. But we need inexpensive, reproducible information made widely available. Without that, all the wonderful theory and research will just gather dust. > DSSS with the digital matched filter (DMF) can lock up in one >symbol time. The extra bandwidth of the signal allows for this, while >still limiting the noise bandwith to that of the information bandwidth. >But, right now there s not enuf processing gain, available cheap. What >is available cheap is 18 dB processing gain (STEL2000a). Its safe to >have more than this, say something like 25 dB, to keep equal amplitude >secondary path signals down out of the modem capture range, in the home >qth application. Unidirectional antennas can easily provide an extra 13 >dB of multipath rejection. Are there any plans or details available for such a system that is ready to go on the air? > Many of the other issues u bring up are RF networking enviorment >issues. They are best handled by a new way of doing the MAN >(metropolitan area network). We now have organisations that build >cellular style networks. If a link goes down, technical people from the >organisation have to go fix it. I think this is great stuff, but its the >wrong way to do things, now. First off, the link gear is too low a level >of production to be economic. Even if it is excruciatingly cheap >compared to professional gear doing the same job. The cost of the link >gear is either in time to make it, or money to buy it (if its plug and >play). Either way, there are not many spares, usually. This results in >an unreliable network. > > With the Internet explosion, users have higher expectations. >33.6, or 56 KB at least. To get such thruput, the RF network raw data >rate has to be allot more, and the more hops out from an internet >gateway, the more the data rate has to be. While, it would be easy to >make a 56 KB access packet network , in the pattern we have now, the >goal is to have 10 s of people in a metropolitan area with that level of >thruput. Even a successful club would have a hard time keeping such a >network on-air , even if they could afford to put it in. > > Allot of political packet people say we need to get money out of >the users. That s simpler said than done. If we had the $20 /month from >people, that ISP s get, things would be easier. But, lets face it, that >is not going to happen. ISP s will get that money, more readily, than >we, because they have the familiar, reliable, user funded Telephone >company gaurunteeing connectivity. Not sure if comparing packet to the Internet is either valid or fair... Most packet users I know have totally different expectations for packet than they do for their Internet connection. A couple of the reasonable complaints that packet users do have are: Why should it take a week or more to get a message across country? Why should it take 3 hours to download a 50K file? > The DDMA/WAN (directivity division multiple access/wide area >network) (also known as the "Flying Saucer Net") addresses this. Its a >DSSS/DMF radio, and an azimuthal scanning antenna. The antenna scans >looking for RTS (Request to Send) 'ing stations, and then answers those. >A packet comes in, it goes up to the level three, and then back out to >the radio with a direction towards the next network partner in-line >towards the destination. Each user, if he wants in on this, buys and >installs his own radio. The local organisation priorities are shifted to >education, applications and support, rather than network building and >maintenance. The manpower available at local ham clubs can readily do >the education and support jobs, typically. Its tuff to get people to do >the network building and maintenance, as well as sites that can be >accessed by the technical people without the primary site >representative. Allot of stuff doesn t get done, because one guy can t >make it, even if two or three are available. Opertunistic situations are >also eliminated. Which is deadly to an volunteer workforce getting >anything done. > > With DDMA/WAN thruput is maximised in the time-bandwidth-area >resource, by tight directive beams, and sending packets to the closest >neighbor towards the destination, with minimun power to do that link >level hop. This minimises area used, per transmission, and also >minimises the number non-participating stations overlapped by that >area-time-bandwidth being used. > > With this system, participants are paying for what they use, >thru the radio gear. There s enuf production level on the link/user gear >to be viable, since they are one in the same. Reliability is enhanced, >because megabaud link is at every user location, and rerouting becomes >readily doable. Its economic, because one does not need a point to point >antenna, and seperate feedline for each neighbor (thanks to the scanning >antenna technology). The delay spread problem is dealt with by the >directional antenna, as best as can be done. Kinda look at this way, If >we have to use directional antenna to do high data rates, then we need >to make the directional antenna the network. The azimuthal scan antenna >is the economic result of making the directional antenna the network. >The DSSS/DMF radio is the result of the need for fast lock-up. As a >network changes, one does not need a new antenna for a new direction. >Just a new bearing to command the antenna to. > > > A network of this type can start with two guys who want to do >something like CUSEEME, teleconferencing. And grow as others like what >they see, and put on their own stations. No need for in-depth planning, >other than for the individuals to judge if they will be in range. Versus >the cellular model, which needs a sizable group of people to support the >high cost central site. Is this really a good idea? For all practical purposes, this eliminates any sort of an organized network that is available in emergencies, one of the prime reasons we even have the badns in the first place. > I see SS as a neccassary tool for High Speed Packet networking. >I came to this opinion, thru experience, and the discussions that led to >the DDMA/WAN concept. Originally, the only value I saw to SS, was that a >DSSS/DMF off the shelf chip, could lock up in one symbol time, with out >any noise bandwidth increase. This is neet, of itself, but not all that >needed, until u try to do a home based megabaud network. U know, ATT >Long Lines ran multimegabaud microwave links, with out any SS, for years >and years. But they did have the advantage of megabuck sites and >antennas. The radio technology to do this has become quite cheap in this >past decade. But, the physics of the microwave path remains the same. SS >is probably the only way to get the megabaud into the home qth that is >not on mounted on a tower, on the best high ground around. I tend to be very practical in my approach to ths problem... At the rate things are going, we not have packet to worry about networking unless some of the problems are fixed soon. > So, I guess, the question is not really one of SS for High Speed >data or not, but do u want to do ur network the way they have been in >the past, or to do it by something resembling the DDMA-WAN way? Where >the network is grown, rather than built. I personally cannot see the way >things have been done, even in places where that way has been >successful, continuing for a long time. The Internet's popularity >changes it all. If we continue building ATT style links, and drops, >without any way of funding it, we will loose out to people doing that, >with funding. If we build DDMA-WAN radio/antenna , we have a chance of >growing networks that will be omni-useful to all hams, and supported and >installed by all hams. Just as the any ham would throw on a SSB HF >station, now. Again, I'm not sure... As you point out, SS is probably the way to get very high speeds into the user's house, but how far away from that in time? 6 months? A year? I believe that to provide reliable, predictable emergency services, there must be some sort of organized network, perhaps something that users can access, but this may pose a few problems as well, especially in high population areas where you could have hundreds (maybe more) of users jumping on at once. >73, Don. Take Care & 73 Marty Albert - marty@trucom.com Amateur Radio: KC6UFM@KC6UFM.#SEMO.MO.USA.NOAM ************************************************ Interested in Amateur Radio? http://www.trucom.com/ppages/marty ************************************************ HAmPS Coordinator http://www.geocities.com/CapeCanaveral/Lab/7067 ************************************************ From wb9mjn@wb9mjn.ampr.org Tue May 27 11:13:09 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 LAA01072 for ; Tue, 27 May 1997 11:08:28 -0500 (CDT) Received: from wb9mjn-1.ampr.org by wb9mjn.ampr.org (JNOS1.10i) with SMTP id AA14179 ; Tue, 27 May 97 09:39:36 UTC Message-ID: <338B061B.53D4@wb9mjn.ampr.org> Date: Tue, 27 May 1997 11:04:43 -0500 From: Don Lemke Reply-To: wb9mjn%wb9mjn.ampr.org@uugate.aim.utah.edu Organization: Ant-Panel Products X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: ss@tapr.org Subject: Re:Is SS The Solution For High Speed Packet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Again Marty, I first started thinking about the user to user type network, when I realised that we were not going to get the clubs to put on a user access network at microwave. Our local club has done allot, but one of its failings, is that it never brought 9600 baud to the masses. And, even thinking about megabaud to users was unreasonable fairy-tale waste of time to the club. We in packet, have developed a momentum. And that momentum is holding us back. We are kinda like GM in the late 70 s. And along came the Japanese, or should i say the Internet. Im not sure where u are Marty, but i think ur in western Mo. On the drive down to Dallas for the CNC year before last, we drove thru the Ozarks. What a wonderful land of Microwave paths! The rolling hills are perfect for being able to do economical high baud rate links. I m sure Cheap megabaud links are doable there, without SS. But, where does that leave the rest of us? So, how do we get around the momentum, the lack of hills, the lack of critical mass? Any microwave data networking system can be made scalable, that s how. Make it work from the start, for a network of 2 people, or 4, or 16, or 256, and so on. Because, to start, only 2 people are going to try it. Microwaves and Megabaud are too technically "big" to switch too, without a good teathing period. And, then if it works, it grows on its own, with individual users doing the work. Rather than overloaded technical designees. That was the germ that got me into the discussions that led to DDMA/WAN idea. > I agree... SS does potentially offer a solution. But we need inexpensive, > reproducible information made widely available. Without that, all the > wonderful theory and research will just gather dust. Well, we all contribute what we can. My strengths, as I see it, is in congealing the technical communities goals and concerns into a technical system design. I ve been doing this for some years, in amateur packet radio. I know i can t do it all, if i could, i would just do it. But I do think I m good at the brain storming side of the technical system design. I hope my vision of the DDMA/WAN is of benefit. > Are there any plans or details available for such a system that is ready to > go on the air? I m not real strong in modern circuit board fabrication. I certainly do not have the resources to do SSOP surface mount. A rework machine for this level of fabrication is on the order of $3000. A rework machine would be something that would be needed to assemble prototypes. Modern economical radios are all built around this size of chip. I would have no problem with the Slovenian Radios. I have built up 3 of the DF9IC 1.2 Ghz full duplex radios, which are very similar, but lower data rate. I can do modern antennas. BTW, the Ham Panel 440 is working well making contacts via the MIR FM repeater from the apartment, here, as well as sending u these emails, hi. > Not sure if comparing packet to the Internet is either valid or fair... Most > packet users I know have totally different expectations for packet than they > do for their Internet connection. A couple of the reasonable complaints that > packet users do have are: > Why should it take a week or more to get a message across country? > > Why should it take 3 hours to download a 50K file? I m really not comparing packet to the internet. More like to to the Internet access providers. Ham Radio networks cannot compete with the Internet's capacity to support millions of users simultaneously. But we should support our own usership, accessing resources from the Internet. What are we going to do with a fast network, ignore all the things from the Internet? No, users will want Internet activities, as well as ham. Indeed your first complaint is basically solved by the Email model of mail transport thru Internet gateways. Any technical group that holds themselves off the Internet has more to loose, than to gain. The Slovenians used a web page to get the word out on their radio. This is another good example of why we need Internet connectivity and TCPIP standardisation. > Is this really a good idea? For all practical purposes, this eliminates any > sort of an organized network that is available in emergencies, one of the > prime reasons we even have the badns in the first place. Not really. Just because the equipment is different, does not mean people can t organise it for any particular purpose. We also have other primary Ham Radio purposes that justify the DDMA/WAN. That of technical expermentation, and training. Its not apparent that a cellular style ham packet network will work better in emergencies, than a DDMA/WAN. My opinion is that the DDMA/WAN will do better, because its more distributed. If lightning takes out a cellular style site, there is a big hole in the network. If lightning takes out a DDMA/WAN site, there is a little hole. In an earthquake, the DDMA/WAN antenna can reorient automatically, if the original bearing changes. For DDMA/WAN to work, each user needs to leave it on 24 hours a day. There s more resources available, when something happens. Shorter ranges of the DDMA/WAN increase the acceptable bearing displacement, as well. This is a simplification, of course. I guess what ur trying to get at is that the central funding organisation, the Ham Packet Club, can act to provide for the emergency capability goal. Yea, maybe. If its still around. If everybody who uses the network pays dues. On ur final comments. Cellular style Ham packet networks rarely have predictable coverage, in the face of storms. This is because the money was spent on the basic capability, and there wasn t much left over. With the DDMA/WAN, the individuals pay to play, but also get something tangible to sell, if they don t want to play anymore. This way, more money gets put into the network. And the more money in a network, the more reliable it will be. In the DDMA/WAN case, its because there are more radios out there, turned on. In the Celluar style case, if the money is spent, its on cavities and grounding. But if there is no money, there is no reliability. The reliability problem comes down to providing the general ham population something they want, so they will spend on it. There is no reason that people using DDMA/WAN hardware can not organise themselves to do the emergency mission. DDMA/WAN is the superior technigue in high population/high demand areas, because it milks every last megabaud-second, out of the time-bandwidth-area resource. So, if everybody did get on, at once, it would be very hard to overload the DDMA/WAN network. A typical cellular style ham system (non-ss), on the other hand would be easy to overload, because the access is at tens of kilobaud. Whereas the DDMA/WAN has megabaud right into every qth. Each DDMA/WAN qth could throw on access for mobiles and oportunistic situations, on 9600, whatever, with a few hundred milliwatts, to cover his neighborhood. I can t see the emergency mission as our primary go/nogo decision maker. We are here to push the envelope, not to be sure the network can survive an act of God. I appologise to the group for typing as much as I have about emergency trade-offs. If the a high speed packet network is built, then it will be up to emergency clubs in Ham Radio to make it robust for their purposes. Our purpose is to make it happen in the first place, and we should not be sidetracked , as we have in the past, by trying to make sure one all the missions in Ham Radio are fetted by our efforts. -- 73, Don. AMPRNet : wb9mjn@wb9mjn.ampr.org[44.72.98.19] Internet: wb9mjn%wb9mjn.ampr.org@uugate.aim.utah.edu Finger: wb9mjn@wb9mjn.ampr.org From wa4dsy@wa4dsy.radio.org Tue May 27 12:29:07 1997 Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id MAA11942 for ; Tue, 27 May 1997 12:29:05 -0500 (CDT) Received: (from uucp@localhost) by out1.ibm.net (8.6.9/8.6.9) id RAA62441 for ; Tue, 27 May 1997 17:28:57 GMT Message-Id: <199705271728.RAA62441@out1.ibm.net> Received: from wa4dsy-1.wa4dsy.radio.org(208.148.146.146) by out1.ibm.net via smap (V1.3mjr) id smaVAEDmb; Tue May 27 17:28:29 1997 From: "Dale Heatherington" To: "ss@tapr.org" Date: Tue, 27 May 97 13:28:15 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:1471] Re:Is SS The Solution For High Speed Packet On Mon, 26 May 1997 22:33:47 -0500 (CDT), Marty Albert wrote: >The WA4DSY is a great system, although limited to 56 Kbps and outragiously >priced. (I have seen the older "GRAPES" versions modified for a little more >than 256 Kbps) The big problem I see with the WA4DSY system is the price... >You're looking at nearly $1,000.00 per station to get the thing on the air. >Frankly, that is rediculous. Hams don't seem to value digital gear like they do SSB and FM. I see Kenwood HF rigs priced from $1820.00 to $3200.00 in my HRO catalog. I see a Yaesu FT-1000D for $4099!! I imagine a few will connect $500 transverters to these rigs so they can work satellite or weak signal UHF. They also will spend $300 to $600 for an FM HT and between $350 and $700 for moble FM radios. These HTs and moble radios don't last too long either. Some hams I know buy a new HT about every 3 or 4 years. The most expensive part of a 'DSY 56k station is the transverter if you buy it new. Ironically the transverter is the simplest and lowest tech part. I suspect the reason for the high price is the fact that they are hand-made to order. Would a cheap transverter make 56k more popular? How cheap would it have to be? FYI --56k prices -- $350 56K modem $435 New transverter (used as low as $150) $125 PI2 Card -------- $910 Total Considering the performance and what other ham gear sells for I don't think this is unreasonable. The cost could be reduced if someone would design and manufacture a cheaper transverter. There no reason it should cost much more than a linear power amp. It could also be installed inside the modems case since there's room for another 7x7 inch pc board in there. Any RF jocks up to the challenge? -------------------------------------------------- Dale Heatherington, WA4DSY e-mail - daheath@ibm.net Web page - http://www.wa4dsy.radio.org OS/2 Warp 4.0 The worlds finest desktop OS. From marty@trucom.com Tue May 27 19:13:31 1997 Received: from thepit.trucom.com (root@thepit.trucom.com [199.217.237.251]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id TAA15464 for ; Tue, 27 May 1997 19:13:28 -0500 (CDT) Received: from MAIN (dialup23.trucom.com [199.217.237.122]) by thepit.trucom.com (8.6.12/8.6.10) with SMTP id TAA31996 for ; Tue, 27 May 1997 19:13:43 -0500 Message-Id: <1.5.4.32.19970528001322.0068d620@mail.trucom.com> X-Sender: marty@mail.trucom.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 May 1997 19:13:22 -0500 To: ss@tapr.org From: Marty Albert Subject: Re: [SS:1472] Re:Is SS The Solution For High Speed Packet At 11:16 05/27/97 -0500, Don WB9MJN wrote: >Hi Again Marty, > > > I first started thinking about the user to user type network, >when I realised that we were not going to get the clubs to put on a user >access network at microwave. Our local club has done allot, but one of >its failings, is that it never brought 9600 baud to the masses. And, >even thinking about megabaud to users was unreasonable fairy-tale waste >of time to the club. > > We in packet, have developed a momentum. And that momentum is >holding us back. We are kinda like GM in the late 70 s. And along came >the Japanese, or should i say the Internet. Good comparison, actually... Sad, but good! > Im not sure where u are Marty, but i think ur in western Mo. On >the drive down to Dallas for the CNC year before last, we drove thru the >Ozarks. What a wonderful land of Microwave paths! The rolling hills are >perfect for being able to do economical high baud rate links. I m sure >Cheap megabaud links are doable there, without SS. But, where does that >leave the rest of us? I'm in SEMO... Not quite as high of hills as the "True Ozark" areas, but still has a lot of good paths to consider. > So, how do we get around the momentum, the lack of hills, the >lack of critical mass? Any microwave data networking system can be made >scalable, that s how. Make it work from the start, for a network of 2 >people, or 4, or 16, or 256, and so on. Because, to start, only 2 people >are going to try it. Microwaves and Megabaud are too technically "big" >to switch too, without a good teathing period. And, then if it works, it >grows on its own, with individual users doing the work. Rather than >overloaded technical designees. That was the germ that got me into the >discussions that led to DDMA/WAN idea. Again, we need something very soon. Here in MO, we have the MOAmPS 9600 "Backbone" that has been more or less under development for at least 4 years. It is still not made from St. Louis to Kansas City with any reasonable reliability or speed. Why? From talking to several people in the areas that the MOAmPS system serves (I live about 100 miles from the nearest point), there seem to be several major problems... (NOTE: this info is from people who live where the backbone is actually at and I have no experience directly with this) * The backbone is not open... That is, it can only be used for "approved" traffic types. * It is very hard to get approval to connect "spurs" to the backbone. * It was 10+ years out of date when started. The first issue seems to be, at least here in SEMO, the big problem. We have some Hams who hate some of the digital services so badly that they get a bit, well, crazy. Had one fellow a few years back (now SK) who would allow only keyboard to keyboard contacts of one hop through his nodes (he had 6 of them). (ie I connect to the node then to you... NOT to another node then on to another station!) Anyway... This has lead to a lot of segregation of services and, hence, the people themselves. The APRS folks up in Kansas City are even developing (or trying to) their own backbone system for APRS traffic. In rural areas like this one (only 14,000 people in the county and about 8-9 Hams), there is no way that multiple networks would be supported. Surrounding counties are not much different, so we are looking at an area here perhaps 125 miles by 100 miles where ONE network will need to carry the load. While perhaps not the best solution for areas with higher populations of Hams, in areas like this, it seems that there would need to be a planned network to ensure coverage and operation for emergency use. > > I agree... SS does potentially offer a solution. But we need >inexpensive, >> reproducible information made widely available. Without that, all the >> wonderful theory and research will just gather dust. > > > Well, we all contribute what we can. My strengths, as I see >it, is in congealing the technical communities goals and concerns into a >technical system design. I ve been doing this for some years, in amateur >packet radio. I know i can t do it all, if i could, i would just do it. >But I do think I m good at the brain storming side of the technical >system design. I hope my vision of the DDMA/WAN is of benefit. To get something out that is usable in a practical sense, as opposed to a neat gizmo, I agree that it will need to be some sort of team effort. Myself, I don't know, or care for that matter, what form the final system will take. I can, however, see some of the qualities that it will need to have... 1) Inexpensive. Homebrew is fine as long as no very unusual skills (or what-ever) are needed to build the thing. 2) Widely available, free or at copy cost, documentation and details. 3) Some group (probably informal) willing to help those working with the system. 4) As high of speed and bandwidth as possible to eliminate redundant networks. 5) Easy to extend. >> Are there any plans or details available for such a system that is ready to >> go on the air? > > > I m not real strong in modern circuit board fabrication. I >certainly do not have the resources to do SSOP surface mount. A rework >machine for this level of fabrication is on the order of $3000. A rework >machine would be something that would be needed to assemble prototypes. >Modern economical radios are all built around this size of chip. I would >have no problem with the Slovenian Radios. I have built up 3 of the >DF9IC 1.2 Ghz full duplex radios, which are very similar, but lower data >rate. I can do modern antennas. BTW, the Ham Panel 440 is working well >making contacts via the MIR FM repeater from the apartment, here, as >well as sending u these emails, hi. I would see more of a one-off approach... That's like the Paccomm version of the new GRAPES modems... From my best estimate, there is only about $80.00 worth of parts there (buying as needed vs bulk prices) and, as a rough estimate, perhaps an hour of machine labor. The thing sells for $350.00. The only thing that the average Ham probably couldn't do is the 4 layer PCB. Not a big deal... Design it like the original GRAPES modem on multiple boards. Just about anyone can do double sided boards. For SS and other advanced goodies (DSP?), as long as the code for the chips is available (see above), most folks can get EPROMS burned. as time passes, PIC and other programmers are also getting cheaper. One of the places where I buy chips has one of the fancy programmers (I think it will program chips that haven't been invented yet!) and will program any chip you buy from them for $1.00 if you have the code on an IBM or Mac disk. >> Not sure if comparing packet to the Internet is either valid or fair... Most >> packet users I know have totally different expectations for packet than they >> do for their Internet connection. A couple of the reasonable complaints that >> packet users do have are: >> Why should it take a week or more to get a message across country? >> >> Why should it take 3 hours to download a 50K file? > > > I m really not comparing packet to the internet. More like to to >the Internet access providers. Ham Radio networks cannot compete with >the Internet's capacity to support millions of users simultaneously. >But we should support our own usership, accessing resources from the >Internet. That I can buy... Problem is, we can't do that now. The 9600 bps "backbones" can't do it. A 56 Kbps might do it (close in, anyway). > What are we going to do with a fast network, ignore all the >things from the Internet? No, users will want Internet activities, as >well as ham. Indeed your first complaint is basically solved by the >Email model of mail transport thru Internet gateways. Any technical >group that holds themselves off the Internet has more to loose, than to >gain. The Slovenians used a web page to get the word out on their radio. >This is another good example of why we need Internet connectivity and >TCPIP standardisation. I agree... Even if, for legal reasons, we can't allow indiscriminate "Surfin'", the Internet allows for things like: World wide DX Clusters; World Wide Chat servers; Store and forward message routing; and more. I won't get into the NAmbia vs NOrth AMerica issue... :) >> Is this really a good idea? For all practical purposes, this eliminates any >> sort of an organized network that is available in emergencies, one of the >> prime reasons we even have the badns in the first place. > > > Not really. Just because the equipment is different, does not >mean people can t organise it for any particular purpose. We also have >other primary Ham Radio purposes that justify the DDMA/WAN. That of >technical expermentation, and training. > > Its not apparent that a cellular style ham packet network will >work better in emergencies, than a DDMA/WAN. My opinion is that the >DDMA/WAN will do better, because its more distributed. If lightning >takes out a cellular style site, there is a big hole in the network. If >lightning takes out a DDMA/WAN site, there is a little hole. In an >earthquake, the DDMA/WAN antenna can reorient automatically, if the >original bearing changes. For DDMA/WAN to work, each user needs to leave >it on 24 hours a day. There s more resources available, when something >happens. Shorter ranges of the DDMA/WAN increase the acceptable bearing >displacement, as well. This is a simplification, of course. Perhaps... I need to look a little more the DDMA/WAN style of operation, but I can see huge holes in areas (like entire counties or states) where we not be able to reach just because no one has wanted to set up a system yet. There would need to be ways to "get around" the holes. > I guess what ur trying to get at is that the central funding >organisation, the Ham Packet Club, can act to provide for the emergency >capability goal. Yea, maybe. If its still around. If everybody who uses >the network pays dues. heh! Not the local ARC here! We had to turn off the repeater autopatch cause we can't afford the phone bills! > On ur final comments. Cellular style Ham packet networks rarely >have predictable coverage, in the face of storms. This is because the >money was spent on the basic capability, and there wasn t much left >over. With the DDMA/WAN, the individuals pay to play, but also get >something tangible to sell, if they don t want to play anymore. This >way, more money gets put into the network. And the more money in a >network, the more reliable it will be. In the DDMA/WAN case, its because >there are more radios out there, turned on. In the Celluar style case, >if the money is spent, its on cavities and grounding. But if there is no >money, there is no reliability. The reliability problem comes down to >providing the general ham population something they want, so they will >spend on it. Again, I need to look at this some more. > There is no reason that people using DDMA/WAN hardware can not >organise themselves to do the emergency mission. > > DDMA/WAN is the superior technigue in high population/high demand >areas, because it milks every last megabaud-second, out of the >time-bandwidth-area resource. So, if everybody did get on, at once, it >would be very hard to overload the DDMA/WAN network. A typical cellular >style ham system (non-ss), on the other hand would be easy to overload, >because the access is at tens of kilobaud. Whereas the DDMA/WAN has >megabaud right into every qth. Each DDMA/WAN qth could throw on access >for mobiles and oportunistic situations, on 9600, whatever, with a few >hundred milliwatts, to cover his neighborhood. Yep... I can see how this will work in high population areas, but what about the low population areas? Are we looking at "LANs" using DDMA systems connected together with more conventional very high speed backbones? > I can t see the emergency mission as our primary go/nogo decision >maker. We are here to push the envelope, not to be sure the network can >survive an act of God. I appologise to the group for typing as much as I >have about emergency trade-offs. If the a high speed packet network is >built, then it will be up to emergency clubs in Ham Radio to make it >robust for their purposes. Our purpose is to make it happen in the first >place, and we should not be sidetracked , as we have in the past, by >trying to make sure one all the missions in Ham Radio are fetted by our >efforts. I agree that no one of the missions can dictate the entire system, but we need to think about them before things get built. If it is left up to the emergency groups to make the network robust, what needs to be done, if anything, now to allow them to be able to do that later? Again, I am taking a results oriented approach to all of this... As I said above, the final form that a system takes is really of little, if any, real importance at this time. I doubt that anyone involved in digital modes would argue that the system is broke. It seems that it is broke nearly to the point of being beyond repair. Perhaps, in any event, this is the time to simply rebuild as opposed to fixing. In areas like where I am, there really is no network, so what-ever we end up with will be a fresh start. We don't have to worry about keeping something running while we build a new system. What is important, however, is to have something that works. A few of the other qualities I think the system will need were listed above. Maybe SS is the answer, but when will the answer come? Take Care & 73 Marty Albert - marty@trucom.com Amateur Radio: KC6UFM@KC6UFM.#SEMO.MO.USA.NOAM ************************************************ Interested in Amateur Radio? http://www.trucom.com/ppages/marty ************************************************ HAmPS Coordinator http://www.geocities.com/CapeCanaveral/Lab/7067 ************************************************ From marty@trucom.com Tue May 27 19:53:29 1997 Received: from thepit.trucom.com (root@thepit.trucom.com [199.217.237.251]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id TAA17157 for ; Tue, 27 May 1997 19:53:27 -0500 (CDT) Received: from MAIN (dialup23.trucom.com [199.217.237.122]) by thepit.trucom.com (8.6.12/8.6.10) with SMTP id TAA32319 for ; Tue, 27 May 1997 19:53:42 -0500 Message-Id: <1.5.4.32.19970528005321.00675bc8@mail.trucom.com> X-Sender: marty@mail.trucom.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 May 1997 19:53:21 -0500 To: ss@tapr.org From: Marty Albert Subject: Re: [SS:1473] Re:Is SS The Solution For High Speed Packet At 12:31 05/27/97 -0500, Dale WA4DSY wrote: >Hams don't seem to value digital gear like they do SSB and FM. >I see Kenwood HF rigs priced from $1820.00 to $3200.00 in my HRO >catalog. I see a Yaesu FT-1000D for $4099!! I imagine a few will >connect $500 transverters to these rigs so they can work satellite or >weak signal UHF. They also will spend $300 to $600 for an FM HT and between >$350 and $700 for moble FM radios. These HTs and moble radios >don't last too long either. Some hams I know buy a new HT about every 3 or 4 years. You are 100%+ right, Dale! Not sure why this is, but it sure is so. >The most expensive part of a 'DSY 56k station is the transverter if you buy >it new. Ironically the transverter is the simplest and lowest tech part. I suspect >the reason for the high price is the fact that they are hand-made to order. >Would a cheap transverter make 56k more popular? How cheap would >it have to be? Good question... Just off the top of my head, I would say that if an entire station for 56 Kbps could be put together for < $500.00, it would probably be in the ball park for "normal" users. See below. On the other hand, I can buy a Part 15 device that gives me 128 Kbps for a little more $$$ than the ~$1,000.00 current cost. Of course, I would need to make a few "modifications" (like new antenna connectors and such) to save a few $$ by using my own cables (as opposed to their $200.00 50' jobs!) and using homebrew antennas (vs their $200 13 element Yagi!). >Considering the performance and what other ham gear sells for I >don't think this is unreasonable. The cost could be reduced if >someone would design and manufacture a cheaper transverter. >There no reason it should cost much more than a linear power amp. >It could also be installed inside the modems case since there's room >for another 7x7 inch pc board in there. Any RF jocks up to the challenge? I think that, to an extent, the problem is two-fold... You can get a 1200 bps TNC for about $100 (give or take a little) and hook that to your $600.00 dual band Whiz-Bang HT and your $5000.00 Pentium Pro 200 Video Game... er Computer (couldn't resist!) and be on the air. I know several users (local here in SEMO) who have said that they would spend what-ever was needed to get higher speed IF the network supported it... Problem is, the "network", and I use the term VERY loosely, here is 1200 bps TheNET nodes. The real problem is to make it inexpensive for those building the network. The work we are (just starting) doing here in SEMO on the network looks like we will need (assuming 23cm) about 12 backbone nodes to get the inital coverage needed. Final coverage will probably bring the total to about 20 nodes. If we estimate $1,000.00 for each node ($910.00 from your total plus a cheap computer for the SCC card and to run the node software, or some sort of stand alone node computer), this is $20,000.00. Frankly, it ain't gonna happen, at least not here. Maybe if we could talk Paccomm into giving us about 20 systems for PR... :) But, there is another problem in this particular QTH, and I suspect many others as well... We are talking about a large area (more than 10,000 square miles) of low population (both public and Ham) density. It is not unusual to have paths of 60 miles between places where a LAN would make sense to serve a "cluster" of Hams. I think that the 56 Kbps speed would be marginal, at best. I have been thinking more along the lines of 256 Kbps as a minimum, with even faster preferred. Frankly, I don't know where all this will end up... All I know is that there is a problem to solve. Take Care & 73 Marty Albert - marty@trucom.com Amateur Radio: KC6UFM@KC6UFM.#SEMO.MO.USA.NOAM ************************************************ Interested in Amateur Radio? http://www.trucom.com/ppages/marty ************************************************ HAmPS Coordinator http://www.geocities.com/CapeCanaveral/Lab/7067 ************************************************ From lylej@azstarnet.com Tue May 27 21:27:03 1997 Received: from mailhost.azstarnet.com (root@mailhost.azstarnet.com [169.197.1.8]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id VAA22126 for ; Tue, 27 May 1997 21:27:02 -0500 (CDT) Received: from ppp15.mmsi.com ([169.197.15.13]) by mailhost.azstarnet.com (8.8.5/8.8.5) with SMTP id TAA25491 for ; Tue, 27 May 1997 19:26:54 -0700 (MST) Message-Id: <3.0.32.19970527191959.007309dc@pop.azstarnet.com> X-Sender: lylej@pop.azstarnet.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 27 May 1997 19:26:54 -0700 To: ss@tapr.org From: Lyle Johnson Subject: Re: [SS:1469] Re: Is SS The Solution For High Speed Packet Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >Given enough bandwidth, digital voice is no problem... Even at 56 Kbps it is >possible (the quality is not too great, but it's not all that bad). This >needs some more thought time! Don't the CDMA cell phones use a variable speed vocoder and run at maximum 9600 bit/sec? Cheers, Lyle From wd5ivd@tapr.org Wed May 28 20:59:54 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 UAA13366 for ; Wed, 28 May 1997 20:59:52 -0500 (CDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 May 1997 21:04:23 -0500 To: " Spread Spectrum " From: "Greg Jones, WD5IVD" Subject: Comments on Docket 97-12 We have continued to add comments to Docket 97-12 to the web page. We have about three more to add. http://www.tapr.org/ss Cheers - Greg ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From bm@lynx.ve3jf.ampr.org Wed May 28 21:29:46 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 VAA15286 for ; Wed, 28 May 1997 21:29:39 -0500 (CDT) Received: (from bm@localhost) by lynx.ve3jf.ampr.org (8.6.12/8.6.12) id CAA30078 for ss@tapr.org; Thu, 29 May 1997 02:29:20 GMT From: Barry McLarnon VE3JF Message-Id: <199705290229.CAA30078@lynx.ve3jf.ampr.org> Date: Thu, 29 May 1997 02:29:19 +0000 (GMT) To: ss@tapr.org Subject: Re: [SS:1473] Re:Is SS The Solution For High Speed Packet In-Reply-To: <199705271728.RAA62441@out1.ibm.net> X-Mailer: Ishmail 1.3.1-961106-linux MIME-Version: 1.0 Content-Type: text/plain "Dale Heatherington" wrote: > > FYI > --56k prices -- > $350 56K modem > $435 New transverter (used as low as $150) > $125 PI2 Card > -------- > $910 Total You can lop a bit more off that total, since the PI2 is now available as a semi-kit for $60 - you need to find the parts not included in the kit, though. On another topic more in the SS vein, has anybody come across a product called WaveRider? Check out http://www.chli.mwc.net/products/index.html. They claim to be able to do up to 10 Mbps using SS in the 900 MHz ISM band. To get 10 Mbps throughput and stay within a 26 MHz bandwidth while maintaining a minimum of 10 dB processing gain (as required under Part 15) ain't too easy - it would a DSSS system that provides 5 bps/Hz- 32QAM, maybe. This doesn't sound too robust in a multipath environment, but they're claiming 18 km PTP and 7 km omnidirectional range. They're pitching this as a product to allow ISPs to hook up customers by wireless. The modem specs contain some real techno-babble, for instance: Maximum Signal-to-Noise Ratio: >100db below ambient noise level Beats me what the heck that means, if anything. The whole thing smacks of vaporhardware... anybody know different? 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 jeff@mich.com Thu May 29 02:36:21 1997 Received: from server1.mich.com (server1.mich.com [198.108.16.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id CAA21399 for ; Thu, 29 May 1997 02:36:20 -0500 (CDT) Received: from alfalfa (pm001-21.dialip.mich.com [198.108.17.145]) by server1.mich.com (8.8.5/8.8.5) with SMTP id DAA17270 for ; Thu, 29 May 1997 03:37:31 -0400 Message-Id: <2.2.32.19970529073443.00995cfc@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, 29 May 1997 03:34:43 -0400 To: ss@tapr.org From: Jeff King / Kathy King Subject: Re: [SS:1478] Re:Is SS The Solution For High Speed Packet At 09:31 PM 5/28/97 -0500, Barry McLarnon VE3JF wrote: >On another topic more in the SS vein, has anybody come across a product called >WaveRider? Check out http://www.chli.mwc.net/products/index.html. They claim >to be able to do up to 10 Mbps using SS in the 900 MHz ISM band. To get 10 >Mbps throughput and stay within a 26 MHz bandwidth while maintaining a minimum >of 10 dB processing gain (as required under Part 15) ain't too easy - it would >a DSSS system that provides 5 bps/Hz- 32QAM, maybe. This doesn't sound too >robust in a multipath environment, but they're claiming 18 km PTP and 7 km >omnidirectional range. They're pitching this as a product to allow ISPs to >hook up customers by wireless. The modem specs contain some real techno-babble, >for instance: > >Maximum Signal-to-Noise Ratio: >100db below ambient noise level > >Beats me what the heck that means, if anything. The whole thing smacks of >vaporhardware... anybody know different? > >Barry > They (waverider) were pitching franchises about a year or so ago on comp.std.wireless.... Never replied to my queries as to more specifics on there product. My impression of it was the same as yours. I'll look at it again. -Jeff From karn@qualcomm.com Thu May 29 03:06: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 DAA23261; Thu, 29 May 1997 03:06:51 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id BAA26416; Thu, 29 May 1997 01:06:19 -0700 (PDT) Date: Thu, 29 May 1997 01:06:19 -0700 (PDT) Message-Id: <199705290806.BAA26416@servo.qualcomm.com> From: Phil Karn To: hfsig@tapr.org, ss@tapr.org In-reply-to: (message from Danie Brynard on Thu, 22 May 1997 02:12:21 -0500 (CDT)) Subject: Re: [HFSIG:2113] Negative SNR, SS and FEC. >1. It is said that a spread spectrum system can work at negative SNR's. >How does this tie in with Shannons Limit of -1.6dB ? The other responders have answered this well, so I'll just reiterate that SNR and Eb/N0 are not the same thing; they're related by a factor equal to the bit rate divided by the bandwidth. For a spread system, the SNR in the full spread bandwidth is much lower than the Eb/N0. *No* system, spread or not, can operate at a Eb/N0 < -1.6 dB. >2. What is the difference between spread spectrum process gain and >coding gain that one can obtain from say Viterbi FEC ? Both process gain and coding gain can lower the required SNR in the RF channel bandwidth, because both have the effect of spreading the signal energy over a wider bandwidth. But only coding gain can lower the required Eb/N0 (but never below -1.6 dB). Phil From buaas@wireless.net Thu May 29 12:55:22 1997 Received: from wireless.net (wireless.net [198.253.254.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id MAA17403 for ; Thu, 29 May 1997 12:55:17 -0500 (CDT) Received: (from buaas@localhost) by wireless.net (8.8.5/8.6.12) id LAA17595 for ss@tapr.org; Thu, 29 May 1997 11:10:54 -0700 (PDT) Date: Thu, 29 May 1997 11:10:54 -0700 (PDT) From: "Robert A. Buaas" Message-Id: <199705291810.LAA17595@wireless.net> To: ss@tapr.org Subject: Re: [SS:1478] Re:Is SS The Solution For High Speed Packet Barry-- after reading the web page: http://www.chli.mwc.net/products/index.html, I decided to look these guys up in the InterNIC database, since the webpage did not provide any links. What I found was: Major Wireless Communications Inc. (MWC2-DOM) PO Box 538 Salmon Arm, BC V1E 4N6 Salmon Arm, BC V1E 4N6 Canada Domain Name: MWC.NET Administrative Contact: Antoine, Rick (RA1267) rick@JETSTREAM.NET (250) 832-0911 (FAX) 250) 832-0062 Technical Contact, Zone Contact: Grant, Stephen (SG618) steve@JETSTREAM.NET 604) 8320911 Billing Contact: Grant, Stephen (SG618) steve@JETSTREAM.NET 604) 8320911 Looks like we have some countrymen of yours, albiet just outside Vancouver, may or may not be producing vapor!! Reading the "datasheets" suggests a mixture of numbers. Getting 20mbps on 902-928, given what I know about FCC 15.247, pretty much lets them outside this section. I'd be very interested to learn if they have FCC Type Approval, and if so, what the number is. I suspect they are not answering the phone, to answer questions... best regards/bob K6KGS From dewayne@warpspeed.com Thu May 29 15:25:22 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 PAA27340 for ; Thu, 29 May 1997 15:25:19 -0500 (CDT) Received: from [204.118.182.22] by warpspeed.com with ESMTP (Eudora Internet Mail Server 1.1.2); Thu, 29 May 1997 13:25:15 -0700 X-Sender: dewayne@odo.warpspeed.com Message-Id: In-Reply-To: <199705291810.LAA17595@wireless.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 May 1997 13:12:15 -0700 To: ss@tapr.org From: Dewayne Hendricks Subject: Re: [SS:1481] Re:Is SS The Solution For High Speed Packet At 12:58 PM -0500 5/29/97, Robert A. Buaas wrote: >Looks like we have some countrymen of yours, albiet just outside >Vancouver, may or may not be producing vapor!! Reading the >"datasheets" suggests a mixture of numbers. Getting 20mbps on >902-928, given what I know about FCC 15.247, pretty much lets them >outside this section. I'd be very interested to learn if they >have FCC Type Approval, and if so, what the number is. I did a search of the FCC's Part 15 certification database and didn't find any equipment authorizations for "Major Wireless Communications Inc.". It looks like 'vaporware' to me also. -- 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 mailnet@listcleanup.com Thu May 29 19:54:41 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 TAA21059 for ; Thu, 29 May 1997 19:54:40 -0500 (CDT) Received: from bill.listcleanup.com ([206.228.62.71]) by edge.edge.net (8.7.5/8.7.3) with SMTP id TAA24829 for ; Thu, 29 May 1997 19:54:37 -0500 (CDT) Message-Id: <199705300054.TAA24829@edge.edge.net> From: mailnet To: Date: Thu, 29 May 1997 19:56:56 Reply-To: mailnet@listcleanup.com Errors-To: mailnet@listcleanup.com X-URL: http://www.listcleanup.com X-htttp: //www.listcleanup.com: http://www.listcleanup.com X-Mailer: NetMailer v1.0 (http://www.alphasoftware.com/netmailer) [D.R-DF96DCFB1A4B8A89BBCBAAA] Subject: July 1st Resource Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Most businesses are unaware of the new July 1st USPS regulation requiring all first class mail to be move update certified or lose valuable postage discounts. MAILnet Services has built a web site to make compliance totally automated with NCOA processing at http://www.listcleanup.com NCOA Telephone Append Data Enhancement note: you were chosen to receive this message because of your affiliation with the industry. If this reached you by mistake, please excuse or forward this postal regulation to the person in your organization who handles your databases and postal compliance. From wd5ivd@tapr.org Thu May 29 21:48:34 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 VAA27907 for ; Thu, 29 May 1997 21:48:28 -0500 (CDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 May 1997 21:52:59 -0500 To: " Spread Spectrum " From: "Greg Jones, WD5IVD" Subject: Comments to Docket 97-12 Steve Bible finsihed entering the last of the comments we have -- so the page is pretty much up to date. Don't forget the reply comment period is coming quickly. No excuses for not filing on the reply comments this time around. It could be as little as the filing that Robert Brown filed. You can simply state that you support certain aspect of the various comments made or against those that you think shouldn't be in the rules. Cheers - Greg ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From karn@qualcomm.com Thu May 29 23:01:13 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 XAA02491 for ; Thu, 29 May 1997 23:01:11 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id VAA10609; Thu, 29 May 1997 21:00:39 -0700 (PDT) Date: Thu, 29 May 1997 21:00:39 -0700 (PDT) Message-Id: <199705300400.VAA10609@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: <970523123721_909984250@emout11.mail.aol.com> (N5RG@aol.com) Subject: Re: [SS:1461] SS IF bandwidth >For example, assume that a data bit was sent by spreading it such that it >was sent at 8 different frequencies over the length of time required to send >that bit. It seems to me if a receiver were tuned to one of these This assumes "fast frequency hopping". There's also slow frequency hopping ("slow" in the sense that the hop rate is slower than the data rate) and direct sequence, where the carrier doesn't hop at all. >that bit. It seems to me if a receiver were tuned to one of these >frequencies >that it would see a pulse appearing at random intervals. The optimum IF But the receiver isn't tuned to a fixed frequency, it hops to follow the transmitter -- as you later point out. >Most likely the SS receiver does not work the way I have invisioned above >but works in some manner I have not thought of. The method you have assumed, fast frequency hopping, is actually quite rare in practice. As far as I know, it is used mainly in military anti-jam environments where hopping must be very fast to defeat an intelligent jammer that listens to see where you are, jams that frequency, then listens again to see where you've gone next (follow-and-jam). If you can hop faster than the propagation delay to the jammer, you can defeat this particularly strategy. This feature comes at a high price, namely a substantial "noncoherent combining loss" because of the noncoherent phase transition caused by each hop. For this reason it is generally impossible to maintain a carrier phase reference with fast frequency hopping, so you have to use less efficient (higher Eb/No) modulation schemes like FSK that can withstand rapid signal phase changes. Furthermore, if the hop rate is faster than the data rate, you have to accumulate the energy for each data bit noncoherently from hop to hop, which results in a further loss of energy. The same thing happens when you layer a FEC code on top of a noncoherent scheme like FSK and you make the FEC code rate too low. The Eb/No requirements start to rise again. Most commercial frequency hoppers are slow hoppers, meaning the hop rate is relatively slow compared to the data rate. This avoids the noncoherent combining losses involved in hopping faster than the data rate. If the hop rate is slow enough (and the channel cooperates) you can sometimes use a coherent modulation scheme. As long as you use enough coding and interleaving (i.e., it has to span many hops) you will still have plenty of resistance to narrowband interference. Phil From bm@lynx.ve3jf.ampr.org Thu May 29 23:37:50 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 XAA04902 for ; Thu, 29 May 1997 23:37:47 -0500 (CDT) Received: (from bm@localhost) by lynx.ve3jf.ampr.org (8.6.12/8.6.12) id EAA31880 for ss@tapr.org; Fri, 30 May 1997 04:37:26 GMT From: Barry McLarnon VE3JF Message-Id: <199705300437.EAA31880@lynx.ve3jf.ampr.org> Date: Fri, 30 May 1997 04:37:26 +0000 (GMT) To: ss@tapr.org Subject: Re: [SS:1482] Re:Is SS The Solution For High Speed Packet In-Reply-To: X-Mailer: Ishmail 1.3.1-961106-linux MIME-Version: 1.0 Content-Type: text/plain Dewayne Hendricks wrote: > At 12:58 PM -0500 5/29/97, Robert A. Buaas wrote: > >Looks like we have some countrymen of yours, albiet just outside > >Vancouver, may or may not be producing vapor!! Reading the > >"datasheets" suggests a mixture of numbers. Getting 20mbps on > >902-928, given what I know about FCC 15.247, pretty much lets them > >outside this section. I'd be very interested to learn if they > >have FCC Type Approval, and if so, what the number is. > > I did a search of the FCC's Part 15 certification database and > didn't find any equipment authorizations for "Major Wireless Communications > Inc.". > It looks like 'vaporware' to me also. How about Inficom (www.inficom.com)? They claim to be able to do 25.6 Mbps in the 902-928 band under Part 15. There are some remarkable similarities to the WaveRider stuff - data rates that stretch credibility, similar bogus-sounding specs in their product data (see the "Infilink ATM Wireless Modem"), and from what I've heard, if you try to buy their hardware, they try to sell you a franchise instead. They're also based in the PNW (something in the water over there? :-). 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 strohs@halcyon.com Fri May 30 01:03:17 1997 Received: from mail1.halcyon.com (mail1.halcyon.com [206.63.63.40]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id BAA21148 for ; Fri, 30 May 1997 01:03:15 -0500 (CDT) Received: from chinook.halcyon.com by mail1.halcyon.com (5.65v3.2/1.1.10.5/10Nov96-0444PM) id AA21071; Thu, 29 May 1997 23:04:03 -0700 Date: Thu, 29 May 1997 23:03:13 -0700 (PDT) From: Steve Stroh To: ss@tapr.org Subject: Re: [SS:1486] Re:Is SS The Solution For High Speed Packet In-Reply-To: <199705300437.EAA31880@lynx.ve3jf.ampr.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 29 May 1997, Barry McLarnon VE3JF wrote: > How about Inficom (www.inficom.com)? They claim to be able to do 25.6 Mbps > in the 902-928 band under Part 15. There are some remarkable similarities > to the WaveRider stuff - data rates that stretch credibility, similar > bogus-sounding specs in their product data (see the "Infilink ATM Wireless > Modem"), and from what I've heard, if you try to buy their hardware, they > try to sell you a franchise instead. They're also based in the PNW (something > in the water over there? :-). > > Barry More like greed trying to seek out venture capital. There's a lot of wireless activity in the Seattle area. Some of the Puget Sound Amateur Radio TCP/IP group got wind of Inficom a couple of years ago. At least one of the principals there is known to some members of the group as having at best a loose grasp of reality when it comes to wireless data. We've asked to get a couple of units to experiment with and we've been told Uh... we're not QUITE ready yet... but soon. Their claims are so preposterous that if even remotely true that they would have put the rest of the wireless modem industry out of business. Steve N8GNJ -- Steve Stroh Woodinville, Washington, USA strohs@halcyon.com From karn@qualcomm.com Fri May 30 01:36:17 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 BAA27283 for ; Fri, 30 May 1997 01:36:15 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id XAA11091; Thu, 29 May 1997 23:35:45 -0700 (PDT) Date: Thu, 29 May 1997 23:35:45 -0700 (PDT) Message-Id: <199705300635.XAA11091@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: <3.0.32.19970527191959.007309dc@pop.azstarnet.com> (message from Lyle Johnson on Tue, 27 May 1997 21:28:34 -0500 (CDT)) Subject: Re: [SS:1476] Re: Is SS The Solution For High Speed Packet >Don't the CDMA cell phones use a variable speed vocoder and run at maximum >9600 bit/sec? Originally, yes. Many carriers wanted better voice quality, so we implemented "Rate Set 2", where the four frame sizes are each increased by 50%. I.e., the peak data rate is now 14.4 kb/s, minus overhead. This is comparable to the (fixed) 13kb/s rate of the GSM vocoder, though we still win by having a variable rate. BTW, Rate Set 2 was implemented by simply increasing the FEC convolutional code rates, e.g., from rate 1/2 to 3/4 on the forward link. The symbol and chip rates remain the same. Phil From dewayne@warpspeed.com Fri May 30 05:47:24 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 FAA07439 for ; Fri, 30 May 1997 05:47:20 -0500 (CDT) Received: from [204.118.182.22] by warpspeed.com with ESMTP (Eudora Internet Mail Server 1.1.2); Fri, 30 May 1997 03:47:14 -0700 X-Sender: dewayne@odo.warpspeed.com Message-Id: In-Reply-To: <199705300437.EAA31880@lynx.ve3jf.ampr.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 May 1997 03:47:03 -0700 To: ss@tapr.org From: Dewayne Hendricks Subject: Re: [SS:1486] Re:Is SS The Solution For High Speed Packet At 11:43 PM -0500 5/29/97, Barry McLarnon VE3JF wrote: >How about Inficom (www.inficom.com)? They claim to be able to do 25.6 Mbps >in the 902-928 band under Part 15. There are some remarkable similarities >to the WaveRider stuff - data rates that stretch credibility, similar >bogus-sounding specs in their product data (see the "Infilink ATM Wireless >Modem"), and from what I've heard, if you try to buy their hardware, they >try to sell you a franchise instead. They're also based in the PNW (something >in the water over there? :-). Ah yes, Inficom. They've been around for about three years, but I have yet to see them produce a product that works as they claim. I've even offered to come up to their facility to see their equipment in operation and got put off with various excuses. I did a check of the FCC certification database for them and they also have no Part 15 equipment authorizations on record. BTW, the FCC's database is available on the Web. If you ever want to do a check on a company's equipment authorizations or type acceptance on record, then just point your browser to: . -- 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 frussle@erols.com Fri May 30 09:28:24 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 JAA24751 for ; Fri, 30 May 1997 09:28:21 -0500 (CDT) Received: from col-as7s60.erols.com (col-as7s60.erols.com [207.172.129.187]) by smtp2.erols.com (8.8.5/8.8.5) with SMTP id KAA17916 for ; Fri, 30 May 1997 10:28:18 -0400 (EDT) From: frussle@erols.com (Jake Brodsky) To: ss@tapr.org Subject: Data Radio Design Date: Fri, 30 May 1997 14:26:15 GMT Organization: Cyberflight Inc. Wannabe Message-ID: <338ec493.819200@smtp.erols.com> X-Mailer: Forte Agent 1.0/32.390 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Tony, N3JLI, and I have decided to take a step backward and concentrate on building a high speed data radio. Although we have ideas for analog use of DS Spread Spectrum (as a sort of time domain linear transponder), we have decided that most of the SS radio design difficulties can be addressed with the design of a data radio.=20 So we're focusing our efforts on a simple four state QAM radio. It is loosely patterned after the Mini-R2 and T2 designs that Rick Campbell, KK7B, described in QST around 1993 and 1994. We have added a pair of limiters, a Costas Loop for steering the LO, and are working on a Manchester encoder and decoder for the scrambling.=20 Those of you who are familiar with the Slovinian data radios may notice some similarities. Although we've been playing with prototypes around this concept for the last six months, we only became aware of their design last week. It seems we aren't the only ones pursuing this concept. =20 Anyway, our initial data rate is around 1 MBPS at 52 MHz, with the clocking derived from the LO. Note: we are NOT going on the air with this. In fact, we are thinking about moving this design directly to 2.3 GHz. The only reason we're on 52 MHz is because we had considered using a very similar design for the SS STA, and because there were some aspects about this band which made our initial prototype easier to construct. =20 Three issues are cropping up: First, can anyone give us a reference on how critical the 90 degree phase shift is? I ask this because with higher data rates it is more and more difficult to maintain an accurate 90 degree phase shift across the entire band width. =20 Currently, we're using the phase shift network described in the SPRAT Technical Cartoons #1 and #2. This is a reasonably wide band quadrature bridge. However, it has limits. We're using this bridge at 52 MHz in our prototype. At bandwidths of four or five MHz, I don't foresee many problems; however, I'm not sure how it may perform at wider bandwidths. (I'm thinking about possible experiments we can conduct if nobody comes up with a reference) Second, what kind of transmit harmonic filters can we use? Can I use a third or fifth order Butterworth filter without too much concern over group delay distortion? How about second order IMD filters for the receiver? How about data rate filters? Or, as an alternative, does anyone have practical suggestions the average ham could use to compensate for group delay? Third, for the eventual day when we use this platform for QAM spread spectrum, does anyone have suggestions for doing a Hilbert transform on the pseudo-noise? This is partly related to the first issue because if we can allow for some slop in the phase accuracy, then a simple delay line or phase shift network might suffice. =20 Thoughts? Jake Brodsky, AB3A mailto:frussle@erols.com "Beware of the massive impossible!" From N5RG@aol.com Fri May 30 10:48:36 1997 Received: from emout05.mail.aol.com (emout05.mx.aol.com [198.81.11.96]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id KAA00251 for ; Fri, 30 May 1997 10:48:34 -0500 (CDT) From: N5RG@aol.com Received: (from root@localhost) by emout05.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0) id LAA28739 for ss@tapr.org; Fri, 30 May 1997 11:48:02 -0400 (EDT) Date: Fri, 30 May 1997 11:48:02 -0400 (EDT) Message-ID: <970530114802_1523509935@emout05.mail.aol.com> To: ss@tapr.org Subject: Re: [SS:1485] Re: SS IF bandwidth Phil: Thanks for the info. The most important thing I have learned from your response is that I don't understand how SS works. If I want to figure it out I am going to have to do a lot more study. The ARRL book has been recommended to me as being a good place to start. > Most commercial frequency hoppers are slow hoppers, meaning the hop > rate is relatively slow compared to the data rate. This avoids the > noncoherent combining losses involved in hopping faster than the data > rate. If the hop rate is slow enough (and the channel cooperates) you > can sometimes use a coherent modulation scheme. As long as you use > enough coding and interleaving (i.e., it has to span many hops) you > will still have plenty of resistance to narrowband interference. 73, Roy W7IDM, ex N5RG, W5PAG From gwyn@paccomm.com Fri May 30 11:45:51 1997 Received: from paccomm.com (paccomm.com [163.125.30.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA03129 for ; Fri, 30 May 1997 11:45:46 -0500 (CDT) Received: from gwyn by paccomm.com with smtp (Smail3.1.29.1 #1) id m0wXUoF-000FQLC; Fri, 30 May 97 12:45 EDT Received: by gwyn with Microsoft Mail id <01BC6CF7.65C59220@gwyn>; Fri, 30 May 1997 12:45:47 -0400 Message-ID: <01BC6CF7.65C59220@gwyn> From: Gwyn Reedy To: "'ss@tapr.org'" Subject: RE: 1475] Re:Is SS The Solution For High Speed Packet Date: Fri, 30 May 1997 12:45:45 -0400 Encoding: 38 TEXT, 51 UUENCODE X-MS-Attachment: WINMAIL.DAT 0 00-00-1980 00:00 Ref comments in two messages from Marty Albert: Disclaimer 1: I heartily encourage amateur construction projects. Just because my company makes 'things' I do not discourage others from rolling their own. Disclaimer 2: I do not assume Marty was complaining about the price PacComm charges, merely that the total package ends up costing too much. ---------- From: Marty Albert[SMTP:marty@trucom.com] Sent: Tuesday, May 27, 1997 3:18 PM To: ss@tapr.org Subject: [SS:1474] Re:Is SS The Solution For High Speed Packet I would see more of a one-off approach... That's like the Paccomm version of the new GRAPES modems... From my best estimate, there is only about $80.00 worth of parts there (buying as needed vs bulk prices) and, as a rough estimate, perhaps an hour of machine labor. The thing sells for $350.00. The only thing that the average Ham probably couldn't do is the 4 layer PCB. Not a big deal... Design it like the original GRAPES modem on multiple boards. Just about anyone can do double sided boards. ---------- From: Marty Albert[SMTP:marty@trucom.com] Sent: Tuesday, May 27, 1997 3:59 PM To: ss@tapr.org Subject: [SS:1475] Re:Is SS The Solution For High Speed Packet Maybe if we could talk Paccomm into giving us about 20 systems for PR... :) begin 600 WINMAIL.DAT M>)\^(C 0`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$(@ <` M& ```$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`0V ! `"`````@`"``$$ MD 8`] ````$````,`````P``, ,````+``\.``````(!_P\!````-0`````` M``"!*Q^DOJ,0&9UN`-T!#U0"`````'-S0'1A<'(N;W)G`%--5% ```,P`0````P```!S``P` M+0`M``4`8@$!"8 !`"$```!!,D4W-C!%,34V1#9$,#$Q.$5!-# P-# P-3)& M1D4U00`:!P$#D 8`2 8``!0````+`",```````,`)@``````"P`I```````# M`"X```````,`-@``````0 `Y`*" A^L8;;P!'@!P``$````V````4D4Z(#$T M-S5=(%)E.DES(%-3(%1H92!3;VQU=&EO;B!&;W(@2&EG:"!3<&5E9"!086-K M970````"`7$``0```!8````!O&T8ZFOA8.@%UE81T(ZD`$ %+_Y:```>`!X, M`0````,```!-4P``'@`?# $````2````5VEN9&]W6X````# M``80;_"$\0,`!Q#S`P``'@`($ $```!E````4D5&0T]-345.5%-)3E173TU% M4U-!1T531E)/34U!4E1904Q"15)4.D1)4T-,04E-15(Q.DE(14%25$E,645. M0T]54D%'14%-051%55)#3TY35%)50U1)3TY04D]*14-44TI54P`````"`0D0 M`0```*,$``"?! ``+@D``$Q:1G4AB W0_P`*`0\"%0*D`^0%ZP*#`% 3`U0" M`&-H"L!S971N,@8`!L,"@S(/?Q"',^,#Q0(`<')Q$B '$P*#-C0#QA68-12\ M$X]F-ET637T*@ C/"=D[&T\R/#4U`H *@0VQ"V!N9Q@Q,#,4H L#;&DQY#0T M`M%I+1\S#- ?,W<+512B# %C`$ '\ W (#T%H&T'@ (P!" +@"!TB'=O( >! M C5 -@;!\0%QY0(H F8&D%P&]W;MXN)(P* M^R#I)6DR)B(L%=IA!!!U!X CI7P-0/>="Q0!T HT #0:R=2"?!R9 0@ M=7 AP2A +C-O^R*Q*'!H+PTO'Q[O'_T78O Q-B M/I466=6(I$DL?0@-#$%,A21 T-S1=(8$Z2>L&007P5#4A4P;P-. H MHD)&!;%(:6=H!@!P;0G@9#6B*R!T.Q\\)#@V,#RO,%\@)C$BH'5LOU- $? J M,06P+1$AL&$M(-AN92U8H%BQ<"CA`-#O.A!9\%&1)[ G!" \4"L@YS4#-;$A MTB!V+6$HHEB@#R^%-1)9``?@1U)!4/9%!? $8FTI4%H!0+(J0O\D,"FA7N$' M<">Q-J M0B=PKP0`6.$FP32T)%4P+E5 _R^%(J `(%+@6*$OL2(Q7\3P*&)U M>31S!"!9``F 35,Q=@0@8S!L:S5$27A4$-"W2E@3BQ0+X58T&)2P"P`=29P;%GR1 >04L #H&G_!4!:IP6P4L + M@#?Q74I8X?TYT6PFH M0)W &X L1*5#_+X4I@S2T*L%8\2' `Y$L$?\L$$ZP M=0$`D&0"=3PO>#_+_RCA)\ H@#Z/38]ZMT"_>HK_0@]#'T0O?)][`D8/?O]' MK_E(M34Y24^#'TKO?PY,?]^(CX.H3K^*_U!7-5#_4@_S4Q]4+C,V5D<9<@P! M>L;?+X5(,20P(E AL'=W$5?#7S?A9*!;-@N -\ @; Fri, 30 May 1997 13:28:12 -0500 (CDT) Received: from MAIN (dialup14.trucom.com [199.217.237.113]) by thepit.trucom.com (8.6.12/8.6.10) with SMTP id NAA29350 for ; Fri, 30 May 1997 13:28:51 -0500 Message-Id: <1.5.4.32.19970530182808.0069be7c@mail.trucom.com> X-Sender: marty@mail.trucom.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 May 1997 13:28:08 -0500 To: ss@tapr.org From: Marty Albert Subject: Re: [SS:1490] Data Radio Design At 09:36 05/30/97 -0500, you wrote: >Tony, N3JLI, and I have decided to take a step backward and >concentrate on building a high speed data radio. Although we have >ideas for analog use of DS Spread Spectrum (as a sort of time domain >linear transponder), we have decided that most of the SS radio design >difficulties can be addressed with the design of a data radio. >Thoughts? Good news, Jake! If you need a real world beta-test area... :) Take Care & 73 Marty Albert - marty@trucom.com Amateur Radio: KC6UFM@KC6UFM.#SEMO.MO.USA.NOAM ************************************************ Interested in Amateur Radio? http://www.trucom.com/ppages/marty ************************************************ HAmPS Coordinator http://www.geocities.com/CapeCanaveral/Lab/7067 ************************************************ From gwyn@paccomm.com Fri May 30 16:14:41 1997 Received: from paccomm.com (paccomm.com [163.125.30.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id QAA26020 for ; Fri, 30 May 1997 16:14:34 -0500 (CDT) Received: from gwyn by paccomm.com with smtp (Smail3.1.29.1 #1) id m0wXZ0P-000FQLC; Fri, 30 May 97 17:14 EDT Received: by gwyn with Microsoft Mail id <01BC6D1C.F86F8020@gwyn>; Fri, 30 May 1997 17:14:45 -0400 Message-ID: <01BC6D1C.F86F8020@gwyn> From: Gwyn Reedy To: "'ss@tapr.org'" Subject: RE: 1474] Re:Is SS The Solution For High Speed Packet Date: Fri, 30 May 1997 17:14:42 -0400 Encoding: 56 TEXT, 64 UUENCODE X-MS-Attachment: WINMAIL.DAT 0 00-00-1980 00:00 ---------- From: Marty Albert[SMTP:marty@trucom.com] Said: I would see more of a one-off approach... That's like the Paccomm version of the new GRAPES modems... From my best estimate, there is only about $80.00 worth of parts there (buying as needed vs bulk prices) and, as a rough estimate, perhaps an hour of machine labor. The thing sells for $350.00. The only thing that the average Ham probably couldn't do is the 4 layer PCB. Not a big deal... Design it like the original GRAPES modem on multiple boards. Just about anyone can do double sided boards. ___________________________________________________________________ I started to comment on this message before, but hit the send button prematurely. Disclaimers: 1. I favor hams doing design and group construction, etc. 2. I did not take Marty's comment about the cost of components as a 'dig.' Why does $80 of parts sell for $349? I just get worried that folk don't understand the basics of business economics, and while I'm here putting in 60 hours a week for about $10 per hour folks reading your message will think I'm getting rich from overpricing the products. The actual parts cost is about $110 (remember case, etc.) Then there is royalty to the designer (WA4DSY) Labor for purchasing, receiving, assembly, test, and shipping (more like 5 or more hours labor, not one) Overhead - sales, engineering, rent, insurance, taxes, utilities, advertising, warranty, etc. You wouldn't believe the tax and insurance cost for the workforce. Profit - maybe one of these days! My rule of thumb is to take parts cost and multiply by 3 to get amateur retail price. Sometimes you can do a little better, sometimes worse. Like I said - I don't feel threatened by 'do it yourself' projects, but it must be a labor of love, because for all the nights and weekends spent doing it oneself, one could work part-time at a 7-11 for an equivalent amount of time and just buy the finished product. Guess I should have been an economics teacher. Gwyn Reedy, W1BEL PacComm Packet Radio Systems gwyn@paccomm.com http://www.paccomm.com begin 600 WINMAIL.DAT M>)\^(BT5`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$(@ <` M& ```$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`0V ! `"`````@`"``$$ MD 8`] ````$````,`````P``, (````+``\.``````(!_P\!````-0`````` M``"!*Q^DOJ,0&9UN`-T!#U0"`````'-S0'1A<'(N;W)G`%--5% ```,P`0````P```!S``T` M`0`O``4`.0$!"8 !`"$````Q,T4X-C!%,34V1#9$,#$Q.$5!-# P-# P-3)& M1D4U00`,!P$#D 8`C @``!0````+`",```````,`)@``````"P`I```````# M`"X```````,`-@``````0 `Y`*"]DGT^;;P!'@!P``$````V````4D4Z(#$T M-S1=(%)E.DES(%-3(%1H92!3;VQU=&EO;B!&;W(@2&EG:"!3<&5E9"!086-K M970````"`7$``0```!8````!O&T^?8OA8.@;UE81T(ZD`$ %+_Y:```>`!X, M`0````,```!-4P``'@`?# $````2````5VEN9&]W6X````# M``80'8))J0,`!Q!-!@``'@`($ $```!E````+2TM+2TM+2TM+4923TTZ34%2 M5%E!3$)%4E133510.DU!4E190%1254-/34-/35-!240Z25=/54Q$4T5%34]2 M14]&04].12U/1D9!4%!23T%#2%1(05133$E+151(15!!0T-/30`````"`0D0 M`0```.<&``#C!@``1PL``$Q:1G4$V-;I_P`*`0\"%0*D`^0%ZP*#`% 3`U0" M`&-H"L!S971N,@8`!L,"@S(/?Q"',^,#Q0(`<')Q$B '$P*#EC0#QA68-19/ M9C84O*$&L'-T96T"@'T*@(L(SPG9.QK?,C4U`H '"H$-L0M@;F16 ;&($D(!T6U--5% Z`, A)O% M=')U!:!M+ETH@5T+1A2B# %C`$ @XRH@!A!I9#H*APMD%V)'# $@Y@J%22!W M"&!L9&0@$?!E( 1@&N @$&]F(&$M\&YE+9LN`"X1<"#A`-!H+B]09"!4$P!1!CY0>0*2X@;F0U`#D!+C"Q`V!U9V@*A32(< 20[1' <#L! M`Z!H"&$M\@#!WF@+@"V0"V &X'(O020,(!#0B]P3NY*YU*=311-@0` M<'DN4>]#L .11%%$4'4"8"V0`)#?.6)*GPLH*8E095]2SU/?_U3O5>U0;RE< M+/ 9H";A.7'^=$1@,,()\ 5 ,6$_`00@_0>!4KV5O5$O00`8PMA!X 1X"J6,2]P_2SA M9D)P!;$1P#-01$$XPK<-L$=C.J$@"< (8'!#L;\`@"A2-* "(#4`$@!C+W#M M5O4R+W L\&0J<#)0(0#],$!A,"$FTR_16;8V!#!2[P6@-%$N`2B!<"Y1`C [ M`44[`B=D<&1-F$WB#]B/[78-#D_7?PL\&I-HD+ _P5 M-S$(@5EA0?("$#GQ1%#]1!)U.K Q(0&07)$P4D-@_0"08S61+A XD "0+F $ M$;L%D62P;7 1.M%`#R2/41N0@0@&N#^861P.-%.8#UQ6K8#\&LA_S\".@!R8FTQQ'P8T0I>]A:0C5%`V!Y/P= )P%9@3!2871%02A7H$$T1%-9 M?\9,/F+;/[-R\'(1L7"A9S4`&N#Y.E!I=H2C.0`1\ ;0-=!W-0$T07&D(MB-C #$$>P")!QDNYD,1$T MH(24=PK C1$G`'UC15D(8"T$1!(G4!Z@9?\Q$#!#C8%ATXS79M0_PC!2W3=$IB>,$$D#4`L8.C+@$:<#$06Y$%D'YA3: MD'2C=^,R04:0:/]GXG'2=&%< M@6KA/*!:`6$4_T>Q+E&DXC4`3G,M(Y/B-[/.+9VB+B!-P2 W'S J$.-THP.@ M97%UA3"+0682_P1@;O!G$ZTD7)%LXSB1,$-_'Q #`(;@.7%ZU6.75O5'_PI0 M!!%8X3U1+4$1P)&!)U!_@&&N4G$FAC$O(0207>U'-'=Y`Z!2.4&&$5; Sat, 31 May 1997 09:49:56 -0500 (CDT) Received: from fperkins.onramp.net (ppp10-35.ftwotx.onramp.net [206.50.209.35]) by mailhost.onramp.net (8.8.5/8.8.5) with SMTP id JAA28059 for ; Sat, 31 May 1997 09:49:54 -0500 (CDT) Message-ID: <33903A3B.53D7@mailhost.onramp.net> Date: Sat, 31 May 1997 09:48:27 -0500 From: Frank & Sue Perkins Reply-To: fperkins@OnRamp.NET Organization: Personal E-Mail X-Mailer: Mozilla 3.0 (Win95; U) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1488] Re: Is SS The Solution For High Speed Packet References: <199705300635.XAA11091@servo.qualcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Phil Karn wrote: > > >Don't the CDMA cell phones use a variable speed vocoder and run at maximum > >9600 bit/sec? > > Originally, yes. Many carriers wanted better voice quality, so we > implemented "Rate Set 2", where the four frame sizes are each > increased by 50%. I.e., the peak data rate is now 14.4 kb/s, minus > overhead. This is comparable to the (fixed) 13kb/s rate of the GSM > vocoder, though we still win by having a variable rate. > > BTW, Rate Set 2 was implemented by simply increasing the FEC > convolutional code rates, e.g., from rate 1/2 to 3/4 on the forward > link. The symbol and chip rates remain the same. > > Phil I had lunch with Kent WA5VJB Thursday. He brough in his Qualcomm PCS phone for a listen. Very good quality voice ... inside with low "S-meter" indication. This digital stuff works. Time to get this into amateur projects. We have a team of 4 guys in Dallas doing a spread design now ... not much e-mail, just the real thing. Frank WB5IPM From dinod@deltanet.com Sat May 31 12:02:16 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 MAA29770 for ; Sat, 31 May 1997 12:02:15 -0500 (CDT) Received: from dino (anx-ana1137.deltanet.com [204.254.68.137]) by mail2.deltanet.com (8.8.5/8.8.5) with SMTP id KAA07313 for ; Sat, 31 May 1997 10:01:46 -0700 (PDT) Message-Id: <3.0.1.32.19970531100159.006c799c@mail.deltanet.com> X-Sender: dinod@mail.deltanet.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Sat, 31 May 1997 10:01:59 -0700 To: ss@tapr.org From: Dino Darling Subject: Re: [SS:1495] Re: Is SS The Solution For High Speed Packet In-Reply-To: <33903A3B.53D7@mailhost.onramp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 09:56 AM 5/31/97 -0500, Frank wrote: >I had lunch with Kent WA5VJB Thursday. He brough in his Qualcomm PCS >phone for a listen. Very good quality voice ... inside with low >"S-meter" indication. This digital stuff works. Time to get this into >amateur projects. We have a team of 4 guys in Dallas doing a spread >design now ... not much e-mail, just the real thing. > >Frank WB5IPM Thanks Frank! Keep us posted! You Texas guys always have to be first...:-) Dino...dinod@deltanet.com "A REAL friend stabs you in the FRONT!" From wd5ivd@tapr.org Sat May 31 22:38:23 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 WAA25986; Sat, 31 May 1997 22:37:52 -0500 (CDT) Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 31 May 1997 22:42:08 -0500 To: " AMSAT BB Mail Group " From: "Greg Jones, WD5IVD" Subject: Re: SS Cc: MOON-NET@VM.STLAWU.EDU, "David G.L. Anderson" , Clifford Buttschardt , " Spread Spectrum " Then again maybe not. Based on the message I can't see any evidence to say that it is Spread Spectrum communications or not. I would be interested in seeing the data captured, maybe David can put it on a web site or something to retrieve. Possibly our friendly military users in the UK are just using a wide-band 'spread', higher-power communications technique of some sort which may or may not be Spread Spectrum communications. Then again they might just be running 100,000 watts as well. Which wouldn't make it a good example of what amateur radio would want to or could implement. As to the issue of taking it. If they are the military -- you probably have to. I wouldn't base the condemnation of an entire amateur mode on what the military does with technology. Before long you will have SS on amateur satellites, so let's not kill the mode just yet. Then in regards to the weak signal issues, if you read the stuff TAPR has been publishing, TAPR plans on implementing systems that stay off the 'by agreement' weak signal areas. In most cases we are talking about very small segments of the bands and typically at one end or the other. It isn't hard at all to stay off them. However, where the disagreement for the most comes in the US is that some want these issues written into the rules and not just agreed upon. FCC Docket 97-12 is currently in the reply comments stage. What we (the US amateur community) receive from the FCC in the next year or two on the SS rule making will influence what is created, experimented with, and eventually becomes available for the next decade or more in our radio community. If you want to see the comments filed in May, check http://www.tapr.org/ss. Reply comment deadline is coming very quick. As to the 'first' concrete evidence of interference due to spread spectrum communications -- there are plenty of poorly designed, badly implemented systems and plenty of military systems to look at and show problems with for the last twenty years. I wouldn't call this a first example. Almost all the Part 15 stuff having only a little above 10db process gain is a good place to start looking in some implementations. Look at what your cordless phone on 900Mhz looks like. If this is really a Spread Spectrum signal (not just a spread signal) then it wouldn't be the first military or commercial implementation that does what you think it is doing. The difference is that amateurs can implement the mode correctly, because we don't plan on selling it to 30 million consumers. Amateurs can stay off of agreed upon areas. We can't ban or drastically limit amateur radio experimentation and development because we can point to existing poor designs. In the political/legal climate of todays amateur radio -- it wouldn't surprise me if SSB was a new mode then someone would comment that it needed to have a CW ID ;-) ;-) (just kidding.) The mode of Spread Spectrum is all about the art of continuing experimentation and innovations within the amateur radio community. If we stop amateur radio from developing and implementing new modes of operations to protect small communities within the population, then we might as well expect things like what was proposed by the CBO (Congressional Budget Office) two weeks ago -- assign various bands including the US amateur radio segments to a management group to determine its best utilization. Something to think about before we start limiting experimentation and development within the hobby. Please let's be a little more scientific about these things and a little less emotional. Cheers - Greg, WD5IVD >Clifford Buttschardt wrote on AMSAT-BB list: > >David. This is the first example of concrete interference due to spread >spectrum. Knowing your acumen at the VHF's I do hope that we pay >attention and ask further questions about this matter! Cliff K7RR > > >On Sat, 31 May 1997, David G.L. Anderson wrote on AMSAT-BB list: > >> The SS problem is already here in the UK on 70cms (as pointed out by John >> GM4IHJ), not by amateurs but another 'user'. I have 10dB of white noise >> right across the 430-440MHz band and beyond on a certain beam heading. >> Note this is not amateur SS but government/military SS. >> >> Spectrum analysis plots are available to anyone interested.(I don't think I >> am giving away any secrets to show what looks like white noise). If the >> intention was to make these transmissions undetectable then they chose the >> wrong frequency band! - Just as the Soviets did with their Killer >> Satellites a few years ago when they 'hid' them on 2 metres. >> >> As well as opposing possible future wideband SS Amateur pollution in the >> weak signal parts of the bands, we should all be pushing our Radio >> Societies to complain about the EXISTING degradation of the weak signal >> sections of one of our primary UHF bands by non-amateur SS before we find >> that we have no weak signals to hear. >> >> Or do we just lie back and take it? >> >> 73 >> >> >> >> >> >> >> >> + ---------------------------+ >> | David Anderson GM4JJJ | >> | gm4jjj@amsat.org | >> +----------------------------+ >> ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From nielsen@primenet.com Sat May 31 22:58:44 1997 Received: from usr03.primenet.com (root@usr03.primenet.com [206.165.5.103]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA26893 for ; Sat, 31 May 1997 22:58:42 -0500 (CDT) Received: from nielsen.tus.primenet.com (nielsen@nielsen.tus.primenet.com [198.68.42.82]) by usr03.primenet.com (8.8.5/8.8.5) with SMTP id UAA00249 for ; Sat, 31 May 1997 20:58:40 -0700 (MST) Date: Sat, 31 May 1997 20:58:38 -0700 (MST) From: Bob Nielsen X-Sender: nielsen@nielsen.tus.primenet.com To: ss@tapr.org Subject: Re: SS (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This showed up on amsat-bb and might be of interest to those on this list. 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 ---------- Forwarded message ---------- Date: Sat, 31 May 1997 18:17:08 -0700 (PDT) From: Clifford Buttschardt To: "David G.L. Anderson" Cc: MOON-NET@VM.STLAWU.EDU, amsat-bb@amsat.org Subject: Re: SS David. This is the first example of concrete interference due to spread spectrum. Knowing your acumen at the VHF's I do hope that we pay attention and ask further questions about this matter! Cliff K7RR On Sat, 31 May 1997, David G.L. Anderson wrote: > The SS problem is already here in the UK on 70cms (as pointed out by John > GM4IHJ), not by amateurs but another 'user'. I have 10dB of white noise > right across the 430-440MHz band and beyond on a certain beam heading. > Note this is not amateur SS but government/military SS. > > Spectrum analysis plots are available to anyone interested.(I don't think I > am giving away any secrets to show what looks like white noise). If the > intention was to make these transmissions undetectable then they chose the > wrong frequency band! - Just as the Soviets did with their Killer > Satellites a few years ago when they 'hid' them on 2 metres. > > As well as opposing possible future wideband SS Amateur pollution in the > weak signal parts of the bands, we should all be pushing our Radio > Societies to complain about the EXISTING degradation of the weak signal > sections of one of our primary UHF bands by non-amateur SS before we find > that we have no weak signals to hear. > > Or do we just lie back and take it? > > 73 > > > > > > > > + ---------------------------+ > | David Anderson GM4JJJ | > | gm4jjj@amsat.org | > +----------------------------+ >