From dewayne@warpspeed.com Tue Apr 01 06:27: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 GAA15998 for ; Tue, 1 Apr 1997 06:27:51 -0600 (CST) Received: from [204.118.182.22] (192.160.122.32) by warpspeed.com with ESMTP (Apple Internet Mail Server 1.1.1); Tue, 1 Apr 1997 04:27:36 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 1 Apr 1997 04:27:12 -0800 To: dewayne-net@warpspeed.com (Dewayne's Wireless News List), ss@tapr.org From: Dewayne Hendricks Subject: Metricom Expects to Provide 85K wireless data Metricom Expects to Provide 85K wireless data Source: Business Wire LOS GATOS, Calif.--(BUSINESS WIRE) via Individual Inc. -- Metricom, Inc. (NASDAQ: MCOM) today announced it is developing new technology designed to dramatically increase data speeds on its wireless network. The new technology, code-named Autobahn, will utilize two bands of unlicensed spectrum: the 900 MHz band and the 2.4 GHz band, and will be compatible with the company's existing Ricochet networks. It will provide Ricochet subscribers with up to 85 kbps. of data speeds, and is scheduled to be ready for deployment in 1998. The company also disclosed that it will be exploring the possible purchase of licensed spectrum, to augment its use of unlicensed spectrum and to further enhance Ricochet network performance. In this regard, the company announced that it has filed an application with the Federal Communications Commission to bid on spectrum in the upcoming Wireless Communications Services (WCS) auctions. Bob Dilworth, CEO and Chairman of Metricom, said, "We believe the addition of a limited amount of licensed spectrum to our proprietary, unlicensed spectrum architecture will enable us to further increase the data speeds of our Ricochet networks." He commented that, "Based on the current work of our design teams and on an architecture code-named "Starlite," we believe a combination of unlicensed and licensed spectrum will enable us to offer wireless, wide-area network data speeds of up to 256 kbps." The WCS auction is one of the licensed spectrum opportunities the company is reviewing. "Metricom has refined and successfully commercialized its proprietary Ricochet wireless data network technology over the last five years," said Don Wood, executive vice president of Metricom. "The company now has Ricochet networks installed in three metropolitan areas, including the San Francisco Bay Area, Seattle and Washington D.C., twelve university campuses and eight major airports, and we have over 12,000 Ricochet customers. We understand our target market segments and our customers' needs, and we believe we are uniquely positioned today to meet those needs. Our work on both the Autobahn and Starlite projects has been made possible by our singular focus over the years on data, by Ricochet's unique mesh architecture and microcellular design, and by the experience we have gained from the commercial deployment and marketing of our existing Ricochet network services." The Autobahn product will build upon and be compatible with Metricom's current wireless data network which uses spread-spectrum, frequency-hopping, packet-data technology. Metricom believes that pushing the envelope on speed and performance is key to maintaining the leadership position it has claimed in its category of wireless data communications. About Metricom Metricom, Inc. is a leading provider of wide-area, wireless data communications network solutions with the fastest-growing subscriber rate in its category. The company's Ricochet Products and Services division, headquartered in Los Gatos, California, provides portable and desktop computer users with high-performance, cost-effective wireless access to the Internet, private intranets, local-area networks, e-mail and other online services. The Ricochet service is faster and more affordable than all other portable wireless service alternatives, and is also competitive with traditional phone networks on desktops, from both a performance and price perspective. Ricochet service is currently available in the greater San Francisco Bay Area, Seattle, and Washington, D.C., and on several university campuses and airports throughout the United States. Metricom's Industrial Communications division provides both private networks and communications services to the electric, gas, oil and water industries. The private network solutions are based on Metricom's UtiliNet products which currently serve over 100 installations across the United States. The Industrial Communications services are offered on the same networks providing Ricochet services. Metricom was founded in 1985. The company's stock is traded under the NASDAQ symbol: MCOM. For more information, call 1-800 Go-Wireless or visit Metricom's Web site at http://www.metricom.com . Metricom and Ricochet are registered trademarks of Metricom, Inc. All other trademarks are the property of their respective owners. CONTACT: Metricom | Susan Kohl, 408/399-8198 (public relations) | skohl@metricom.com | Pager 1-800 949-3164 | or | Ann Candalerio, 408/399-8113 (investor relations) | ann@metricom.com [03-31-97 at 09:09 EST, 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 jra1854@tntech.edu Tue Apr 01 10:35:00 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 KAA07519 for ; Tue, 1 Apr 1997 10:34:58 -0600 (CST) Received: from [149.149.39.26] ("port 1954"@cookie-monster.ece.tntech.edu) by tntech.edu (PMDF V5.1-8 #16786) with SMTP id <01IH6S5UYB5K8WXBHW@tntech.edu> for ss@tapr.org; Tue, 1 Apr 1997 10:33:57 CST Date: Tue, 01 Apr 1997 10:33:55 -0600 From: jra1854@tntech.edu (Jeffrey Austen) Subject: Announcement: New Modulation Technique X-Sender: jra1854@gemini.tntech.edu To: ss@tapr.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset="us-ascii" PRESS RELEASE Rickman, TN -- University of Rickman -- Office of Research Scientists at the University of Rickman (Rickman, TN) are once again pressing the frontiers in telecommunication system research. This week the telecommunications research laboratory team has released a new and revolutionary communication system architecture. This architectural concept utilizes a unique combination of several well-known techniques: spread spectrum modulation, data compression algorithms, and advanced modulation and pulse shaping methods. When used individually, each of these techniques has limitations which prevent the complete system from achieving optimum efficiency, however, when combined in certain ways the shortcoming of each individual techniques is overcome by the advantage gained by using a complementary technique. This eliminates the classical restrictions on communications and allows for the achievement of new levels of system throughput. A benchmark system is being prototyped at the UoR. Although all aspects of the system have not yet been completed it is already demonstrating new levels of bandwidth efficiency by combining spread-spectrum (SS), code-division multiple access (CDMA), and Fourier-based pulse shaping technologies. As is well-known, SS and CDMA achieve high performance and channel sharing by spreading out the signal such that it occupies a much larger bandwidth than that which is required to transmit the data. This expansion of bandwidth, mistakenly called the processing gain, is a necessary characteristic of traditional spread-spectrum systems and provides tremendous throughput for a given transmitter power. It, however, causes the signal to occupy much more spectrum than other modulation methods and prevents the sharing of that extremely wide occupied frequency band with other users. The benchmark system eliminates the wasteful bandwidth expansion of SS modulation by adding trellis coded modulation (TCM), M-ary orthogonal signaling and Fourier-based pulse shaping to the basic SS system. These techniques have previously been used effectively in telephone-computer modems to achieve high throughput in a small bandwidth. In the benchmark system these are combined by coding each chip in the spread-spectrum sequence with TCM followed by pulse shaping and then modulating a M-ary modulator with the resultant waveforms. This combination enables the power efficiency of SS and the bandwidth efficiency of TCM and pulse shaping to be achieved simultaneously in one system. The new method, called the fully orthogonal optimal lattice modulation technique, is being released under a patent with conditions similar to the GNU copyright for software. The public release of this system is necessitated by the desire to have it in production in time to be used on the new 5 GHz license-free bands; this royalty-free licensing will allow rapid development and deployment of the GNU fully orthogonal optimal lattice (GNU FOOL) system. Work is proceeding on the integration of data compression algorithms into the system and a prototype was functional at one time. Unfortunately, in a freak laboratory accident in which consumption of excessive quantities of JOLT cola was a contributing factor, the only copy of the data compression source code was accidentally transmitted through the system. The victims are in stable condition and resting well; efforts to recover the software are continuing. News Contact: University of Rickman, Bill Pournell, (615) 555-1212 HOLD FOR RELEASE Release Date: April 1, 1997. From hwm@netcom.com Tue Apr 01 16:05:22 1997 Received: from mm.wd6dod.ampr.org (hwm@netcom8.netcom.com [192.100.81.117]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA15658 for ; Tue, 1 Apr 1997 16:04:56 -0600 (CST) Received: from localhost (by mm.wd6dod.ampr.org (8.7.5/8.6.12) with SMTP id OAA00714 for ; Tue, 1 Apr 1997 14:03:35 -0800 Date: Tue, 1 Apr 1997 14:03:35 -0800 (PST) From: Bob Lorenzini To: ss@tapr.org Subject: Freewave setup - offtopic Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sorry for the offtopic post but I need some pointers to routing multiple W95/Freewave's to linux/Freewave router. Can anyone point me in the right direction? Bob - wd6dod From jeff@mich.com Wed Apr 02 11:04:02 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 LAA10924; Wed, 2 Apr 1997 11:03:57 -0600 (CST) Received: from gw-aerodata.mich.com (gw-aerodata.mich.com [198.108.16.31]) by server1.mich.com (8.8.4/8.8.4) with SMTP id MAA30566; Wed, 2 Apr 1997 12:05:11 -0500 Message-Id: <2.2.32.19970402170259.008eef04@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, 02 Apr 1997 12:02:59 -0500 To: dewayne@warpspeed.com From: Jeff King Subject: Re: [SS:1223] Metricom Expects to Provide 85K wireless data Cc: ss@tapr.org, ss-sta@tapr.org At 06:32 AM 4/1/97 -0600, Dewayne Hendricks wrote: >Metricom Expects to Provide 85K wireless data > > >Source: Business Wire > >LOS GATOS, Calif.--(BUSINESS WIRE) via Individual Inc. -- Metricom, Inc. >(NASDAQ: MCOM) today announced it is developing new technology designed >to dramatically increase data speeds on its wireless network. The new >technology, code-named Autobahn, will utilize two bands of unlicensed >spectrum: the 900 MHz band and the 2.4 GHz band, and will be compatible >with the company's existing Ricochet networks. It will provide Ricochet >subscribers with up to 85 kbps. of data speeds, and is scheduled to be >ready for deployment in 1998. > Dewayne: Any more technical details available? I'm assuming (maybe?) they will be using the 900mhz as a back channel with some sort of full duplex arrangement to help the throughput. It would be interesting to hear a case study of the trials and tribulations Metricom has had in deploying its FH network. Its also odd to note that the move to 85 kbps is characterized as "dramatically increase data speeds on its wireless network". One has to wonder what the present throughput is based on that statement. 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 Wed Apr 02 11:08:44 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 LAA11464 for ; Wed, 2 Apr 1997 11:08:43 -0600 (CST) Received: from gw-aerodata.mich.com (gw-aerodata.mich.com [198.108.16.31]) by server1.mich.com (8.8.4/8.8.4) with SMTP id MAA31069; Wed, 2 Apr 1997 12:10:05 -0500 Message-Id: <2.2.32.19970402170752.0090e120@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, 02 Apr 1997 12:07:52 -0500 To: ss@tapr.org, hwm@netcom.com From: Jeff King Subject: Re: [SS:1225] Freewave setup - offtopic At 04:06 PM 4/1/97 -0600, Bob Lorenzini wrote: > Sorry for the offtopic post but I need some pointers to routing multiple >W95/Freewave's to linux/Freewave router. Can anyone point me in the right >direction? > >Bob - wd6dod > Bob: A little more detail would help. Do you wish to use one freewave radio at the LINUX site (your master)? Or do you wish to use multiple freewaves at the main (linux) router site? One thing I've never had any luck is in getting WIN95 built-in PPP/ winsock to work with the FreeWave's. I've had to use Trumpet Winsock. The native WIN95 winsock PPP expects a modem and doesn't seem to want to work with a direct connect (as the freewave appears). If anyone has had any luck with this I'd like to hear. 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 ronhaley@dgps.com Wed Apr 02 13:42:51 1997 Received: from server.DGPS.COM (dgps.com [165.113.153.6]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA26794 for ; Wed, 2 Apr 1997 13:42:30 -0600 (CST) Received: from DIFFSERV by server.DGPS.COM (NTMail 3.02.07) with ESMTP id fa001071 for ; Wed, 2 Apr 1997 10:34:19 -0800 Received: by DIFFSERV with Microsoft Mail id <01BC3F5A.F63F6E90@DIFFSERV>; Wed, 2 Apr 1997 11:42:37 -0800 Message-ID: <01BC3F5A.F63F6E90@DIFFSERV> From: Ron Haley To: "'ss@tapr.org'" Subject: RE: 1226] Re: Metricom Expects to Provide 85K wireless data Date: Wed, 2 Apr 1997 11:42:32 -0800 Return-Receipt-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BC3F5A.F674D670" ------ =_NextPart_000_01BC3F5A.F674D670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I use the current service, and it generally provides between 14.4 and 28.8 kbps. -----Original Message----- From: Jeff King [SMTP:jeff@mich.com] Sent: Wednesday, April 02, 1997 9:04 AM To: ss@tapr.org Subject: [SS:1226] Re: Metricom Expects to Provide 85K wireless data At 06:32 AM 4/1/97 -0600, Dewayne Hendricks wrote: >Metricom Expects to Provide 85K wireless data > > >Source: Business Wire > >LOS GATOS, Calif.--(BUSINESS WIRE) via Individual Inc. -- Metricom, Inc. >(NASDAQ: MCOM) today announced it is developing new technology designed >to dramatically increase data speeds on its wireless network. The new >technology, code-named Autobahn, will utilize two bands of unlicensed >spectrum: the 900 MHz band and the 2.4 GHz band, and will be compatible >with the company's existing Ricochet networks. It will provide Ricochet >subscribers with up to 85 kbps. of data speeds, and is scheduled to be >ready for deployment in 1998. > Dewayne: Any more technical details available? I'm assuming (maybe?) they will be using the 900mhz as a back channel with some sort of full duplex arrangement to help the throughput. It would be interesting to hear a case study of the trials and tribulations Metricom has had in deploying its FH network. Its also odd to note that the move to 85 kbps is characterized as "dramatically increase data speeds on its wireless network". One has to wonder what the present throughput is based on that statement. 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 | ------------------------------------ ------ =_NextPart_000_01BC3F5A.F674D670 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IiUTAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAYAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAANQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHNzQHRhcHIub3JnAFNN VFAAc3NAdGFwci5vcmcAAAAAHgACMAEAAAAFAAAAU01UUAAAAAAeAAMwAQAAAAwAAABzc0B0YXBy Lm9yZwADABUMAQAAAAMA/g8GAAAAHgABMAEAAAAOAAAAJ3NzQHRhcHIub3JnJwAAAAIBCzABAAAA EQAAAFNNVFA6U1NAVEFQUi5PUkcAAAAAAwAAOQAAAAALAEA6AQAAAB4A9l8BAAAADAAAAHNzQHRh cHIub3JnAAIB918BAAAANQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHNzQHRhcHIub3JnAFNN VFAAc3NAdGFwci5vcmcAAAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAABAAAAAAAAAKRPQEEgAEA PQAAAFJFOiAxMjI2XSBSZTogTWV0cmljb20gRXhwZWN0cyB0byBQcm92aWRlIDg1SyB3aXJlbGVz cyBkYXRhIADCEwEFgAMADgAAAM0HBAACAAsAKgAgAAMAMgEBIIADAA4AAADNBwQAAgALACkAHwAD ADABAQmAAQAhAAAAODJDQkQ2RDNFM0FBRDAxMUIxNkIwMDIwQUYxMTIzQTgAJAcBA5AGAFgOAAAi AAAACwACAAEAAAALACMAAQAAAAMAJgAAAAAACwApAAEAAAADAC4AAAAAAAIBMQABAAAA7gAAAFBD REZFQjA5AAEAAgBMAAAAAAAAADihuxAF5RAaobsIACsqVsIAAG1zcHN0LmRsbAAAAAAATklUQfm/ uAEAqgA32W4AAABFOlxXSU5OVDM1XG91dGxvb2sucHN0ABgAAAAAAAAAegFssgp10BGxVQAgrxEj qKKAAAAAAAAAGAAAAAAAAAB6AWyyCnXQEbFVACCvESOowoAAABAAAACCy9bT46rQEbFrACCvESOo PQAAAFJFOiAxMjI2XSBSZTogTWV0cmljb20gRXhwZWN0cyB0byBQcm92aWRlIDg1SyB3aXJlbGVz cyBkYXRhIAAAAAMANgAAAAAAQAA5AIDfjwGeP7wBHgBwAAEAAAA9AAAAUkU6IDEyMjZdIFJlOiBN ZXRyaWNvbSBFeHBlY3RzIHRvIFByb3ZpZGUgODVLIHdpcmVsZXNzIGRhdGEgAAAAAAIBcQABAAAA FgAAAAG8P54AjdPWy4Oq4xHQsWsAIK8RI6gAAB4AHgwBAAAABQAAAFNNVFAAAAAAHgAfDAEAAAAS AAAAcm9uaGFsZXlAZGdwcy5jb20AAAADAAYQBbTJMwMABxBLBQAAHgAIEAEAAABlAAAASVVTRVRI RUNVUlJFTlRTRVJWSUNFLEFORElUR0VORVJBTExZUFJPVklERVNCRVRXRUVOMTQ0QU5EMjg4S0JQ Uy0tLS0tT1JJR0lOQUxNRVNTQUdFLS0tLS1GUk9NOkpFRkZLSQAAAAACAQkQAQAAABsKAAAXCgAA uRYAAExaRnUZm7yKAwAKAHJjcGcxMjVyMgxgYzEDMAEHC2BukQ4QMDMzDxZmZQ+STwH3AqQDYwIA Y2gKwHOEZXQC0XBycTIAAJIqCqFubxJQIDAB0IUB0DYPoDA1MDQUIfMB0BQQNH0HbQKDAFAD1PsR /xMLYhPhFFATshj0FNCPBxMCgxPwEY4yMzgXVOIgB20gQ0UaBBYxGp3nFEAbrxy1eXIaBA/AEZ2u MR2CHv8DgkcJ0WsaBN8ewSEODlAiLwNzVAhwGgSyNSRPODYlfxy0QgdA/nQN4BoEKKEWbBt4BxMd B943Kv8etyyVIFY5Fk4h6PsslCOINwvCMF0lZiyUJuZ+NxY/KIgslComApEI5jvVCW8wOL9lDjA1 Oeo7Af86vzvJOdQ78jpfPi897T1v5zufOe8QYDI4Q7pE0USP/0WZOdRFwkQvR/9HvUc/RW/9STQ5 DlBMhE3hRgNN4AKCUHN0eWwHkGgJ4HSHAAATUAPwZGN0bAqxwlxQOGFkanVPUAUQ3GdoBUI1cgwB YwnAUEDhAzBzbmV4FzAHsAWwiwDAAnNzAFBzYjIUUNVPQGEaUWsJ4HALkFAfr1CDCGBQcAuAZU+A dldA/wFAUXsMMFJEG5BVIASgC4CmZ0XRUsZiYRcQZAIgn1OAUyZPsFFwWXEgMU8T/w5QVH9Vj1af AFFX3ACgUk7/Wl9bZk8ED8Bcb11/Xo8OUG9Xz2DvYf9bkzMCghMQYz9UQGmBUXBbkCpQV3AgREkB EGF1KkAgUArAYcEJwGFwaCBGAiFUBOkncWktD5A4AUBXEG4T62TvUINiCyByCVBwMhag2XAydzRD IRcAcAHQa1J/UZ9of2mGbbBscAUQAjAtK20QA2E6KRBvdZBTdRRiagWQdHWQRGF0/GU6VAQooW3/ bw9wH3Ev/3I3T6Bbgw4haYFYlg5Qc0/NdF5SV2EXASBIW3EEkP9UBC1xd294f3mPeptW73uflw+Q h1AI0GIKsHQ4Z9p/D1Rj8H2ffqaH4H+wC1B53i9tIHqQCxGAJXNUBBuR/4Evgj+DT3qfcj+JT4pf i2R/dbJ1VHaJMBCNr1Evh4Q5h5F/ko+YgERvY3UHgP8CMAXQbOA34ZaylhCWUI8x/QGAbnYQAGAJ 8GuAmuACAbtTwHwyZQDwmuBPYHA8YKRcdgiQd2sLgGQewP+eggTwB0AQYQFADgCPAltie5/lAhBv BUIXIRLydqBtgwtRdqAgRTpcXHTgem9swW1tEAMQB5CikE2TDeADYHNvAYAgTwEgaw3gndBcpEZF AMADEC59aVB0m7AXEJZQUwGFUnh7AUCc4W5PsDjQpeRsFGPPAyAS8wCABZBsdl+BZLD/DnBTwKhy AZAAIKkCntGbIf8BwahxFuAPcAAAZLAM0AGQ/CAuN/KoaA5QqSIqQJag/6mfqq+rvw/AZLAFga1f rm/tr39sHsBksGytH7HfsuU+KavsJ3Cwv7WfstRiIP4oApG2v6izKKC0b7kvuj//u0+o4C1wvJKp b73/vw+r7P8bkLyfwh/DL8Q/qOAwEMEf/8avx7/IxAr5AzCWD5cfmK1Ye0kgz/ATgHRPsCDdmvBy ONCbMRcQcp6ApICcLCAAcFMAa6AgZwnw1wSQB0CLECAXcG+egAEANQQgYhcgdwnhW9A0LlY00yNG UC6H4GuHoHP4LiAgCoUKhc2EpkLLgj/Ob89/CMFS0lOAEvJia+Rta8qTIF+bYAMQdoHoYX0t3JJP 0CELgCzB/k0HkGQw06Dck9cbzeaA3f+NANhPjp+Pr4Ufhi+HP4hPT9Ek2pZ1UwyCIEoBESACS1ui W1NNVFA6k3YgASBAbQ3gaC4FoPxtXd4/30SMm+B/4Y/in/+Qn9CsDCHapQZgAjDpJDgCDdq0VwmA U0BzZGF5fdMQQRdwAxEToNMQTdA5sDcgOToUQCyATdcWb/K5dbHzvQQQQAGQF3AufQWwZ/a/80F2 BfO96iBT4joOIDI2XX+hdZDdcHfxUeshomB4nkDuMAQgdAZvdNHUYyA4NUsg/wPwONBPgQQg9QCz IetvziL/2A/ZH/Fv0TPXHwGPAp/aQ00KhUGhMBPgOjMscU2gIDQvMS/2ES0T4e4w0xBsAItweVNA gCGc8L/9YduA/yARoHahBOU+/T+v/k//WQv2D05T49BypIDddZBCA1DkEf+RV/9BD07ITE9TI3BB VBMg0xAiQ5+AaWYu3JAoQmBVU0lORfxg9JBJsFJFKSCegLMwSZzw22vABmB1N1EVgGPWcNyQD/0n 0xAWMgv2KE5BU4hEQVH9EUNPTRUg7w2A9QHTIQYwdRZAOODTYucwYP+w5FJvcFuiU0AckO92oDCw BjA4UGfUINSRZ5D9U0BkC/YNge9gowB2kCpg/9PzASDKMFtwgAH/w/CgOUD+ZNSwaWDTYQtx/0ZT QNTw9fmAa9ZwVNHxGxEchxtnd9MQDMDLQC3dMJsQUwBB/ePgb2kQG4DTEDBQ1ADRkPsqUOQAetHB IIDUwNWhHzH/6bAZoOQApICokRx3HuGcITebAHWQ0eI55gCbUEh61yTj0yPR4jLVcUcn1dMU/yPj 1NAigaIAHXE5kBIHMFDH0eDR1CqCbnkn1LBTUPcwYDewW7FSDLEwsKFwIEb91mFJoTAj49RFLUcm J3YAP59gZ4DU0DOg/yErsXVw/w1yDjDWJSVRHpnTFdSwn2B/0fAV4E+AKHEk0RIHHjFkz9QgnVEa UaIQb3mbEwEh//Xx1fAPTQTlCnUL5ghmLHD8IG35gNHBG2IdkhpR+TBzpXDUsGF2pWHpUE+AP30V cCcM4GkgMIDq0FuxKPWlUHnU0D8Y4Sig1CAj4p8E5SpBEVJbwCdFbWgn4P9pINMgJOELUNIQsoHk ITE036PwmxBBUdvBJVFmbEA7AfsxkE+AeATlBSBsoHyAofB/myINgSigB0DR09Hgo9B1fWegcOPg 1nDWrC6C49Bs/1MAKkF1AachLPREE0Mi0hD7HlJPUHU1kSVRRJNngJ+AfzuB00EE7wX/Bw/aQwNx Yv80QB1xH1DUsAx3fEDUsHxBzzaiNgRboh+CRkggSC6A/nNKb0t/TI/aQ0nhDZAZEP80c1MQokHR 4HaQ0dM6MGvR/zHIGiJAkWygU2AxACRxHHa9P/EiHT8eTx9fIGQiF4Z+TwrBT0INgSCAyzHW8Hf/ VmbUQNSgQ9NE5xoiaRNbov9WUlHFypGh4ZshF4Zir1Hy+9aWf7Bni4EzUNas3JNmj9tnfFHFfOl5 aaNBMQANkLvcQvNQeQNgofDUsHxohyPqi9aAUC5P1nBCb+h4IDWM4Tl0wNaAayiEKDiM4Ck0NzGM 0OQ3OPYgIEwVsFuwFVB10xBN0YA0boBtQGsYRstud4kAN5iAIFXLEHag/SgwU2IS1LBpomsmZ390 vz3eGHvbFpzh2+lRxn0AAXiAAAMAEBAAAAAAAwAREAAAAAADAIAQ/////0AABzBA8jvdnT+8AUAA CDBA8jvdnT+8AQsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAA AAAAAEYAAAAAEIUAAAAAAAADAAWACCAGAAAAAADAAAAAAAAARgAAAABShQAAtw0AAB4AJYAIIAYA AAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADguMAADACaACCAGAAAAAADAAAAAAAAARgAAAAAB hQAAAAAAAAsAL4AIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAwgAggBgAAAAAAwAAAAAAA AEYAAAAAEYUAAAAAAAADADKACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4AQYAIIAYAAAAA AMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeAEKACCAGAAAAAADAAAAAAAAARgAAAAA3hQAA AQAAAAEAAAAAAAAAHgBDgAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAB4APQAB AAAABQAAAFJFOiAAAAAAAwANNP03AAAG9A== ------ =_NextPart_000_01BC3F5A.F674D670-- From hwm@netcom.com Wed Apr 02 14:34:18 1997 Received: from mm.wd6dod.ampr.org (hwm@netcom9.netcom.com [192.100.81.119]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA29760 for ; Wed, 2 Apr 1997 14:34:11 -0600 (CST) Received: from localhost (by mm.wd6dod.ampr.org (8.7.5/8.6.12) with SMTP id MAA00103; Wed, 2 Apr 1997 12:32:54 -0800 Date: Wed, 2 Apr 1997 12:32:54 -0800 (PST) From: Bob Lorenzini To: Jeff King cc: ss@tapr.org, hwm@netcom.com Subject: Re: [SS:1225] Freewave setup - offtopic In-Reply-To: <2.2.32.19970402170752.0090e120@mail.mich.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 2 Apr 1997, Jeff King wrote: > A little more detail would help. Do you wish to use one freewave > radio at the LINUX site (your master)? Or do you wish to use multiple > freewaves at the main (linux) router site? There will be one FreeWave/Linux box serving data collection laptops (W95) on a navy base. This brings up something that was bothering me as I have never used PPP for other than point to point and I wonder if it is even capable of point to multipoint. > > One thing I've never had any luck is in getting WIN95 built-in PPP/ > winsock to work with the FreeWave's. I've had to use Trumpet Winsock. > The native WIN95 winsock PPP expects a modem and doesn't seem to > want to work with a direct connect (as the freewave appears). If > anyone has had any luck Thanks for the tip. Much appreciated. Bob - wd6dod From cjeffers@luminet.net Wed Apr 02 16:31:30 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 QAA12852 for ; Wed, 2 Apr 1997 16:31:29 -0600 (CST) Received: from brain-dead.localnet by luminet1 (SMI-8.6/SMI-SVR4) id QAA14838; Wed, 2 Apr 1997 16:30:24 -0600 Message-Id: <1.5.4.32.19970402223110.0068e2bc@luminet.net> X-Sender: cjeffers@luminet.net (Unverified) X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 02 Apr 1997 16:31:10 -0600 To: ss@tapr.org From: Jim Jefferson Subject: Re: Metricom Expects to Provide 85K wireless data >Any more technical details available? I'm assuming (maybe?) they will >be using the 900mhz as a back channel with some sort of full duplex >arrangement to help the throughput. > >It would be interesting to hear a case study of the trials and >tribulations Metricom has had in deploying its FH network. Its >also odd to note that the move to 85 kbps is characterized >as "dramatically increase data speeds on its wireless network". >One has to wonder what the present throughput is based on that >statement. Jeff, I was lucky enough to attend a conference given by the CEO of Metricom at the AAAS meetings this year. I must say that his lecture was excellent! For what I understood it sounded like they ( Metricom ) could guarantee at least 9600Kbs throughput, but the average user got about 33.6Kbs throughput. In the conference center we were in ( big brick building ) we were getting awful throughput I must say. I also wonder what is the cost going to be to transfer over to a new network? 73's de Jim Jefferson KB0THN cjeffers@luminet.net http://www.luminet.net/~cjeffers/ Jim's KB0THN Satellite Page! From taylord@ecn.purdue.edu Wed Apr 02 16:32:41 1997 Received: from atom.ecn.purdue.edu (root@atom.ecn.purdue.edu [128.46.132.94]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA12935 for ; Wed, 2 Apr 1997 16:32:39 -0600 (CST) Received: from [128.46.169.162] (instru1.ecn.purdue.edu [128.46.169.162]) by atom.ecn.purdue.edu (8.8.5/3.8.2moyman) with ESMTP for delivery to "" id RAA22003; Wed, 2 Apr 1997 17:32:30 -0500 (EST) Date: Wed, 2 Apr 1997 17:32:30 -0500 (EST) X-Sender: taylord@128.46.169.94 Message-Id: In-Reply-To: <2.2.32.19970402170259.008eef04@mail.mich.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org From: David G Taylor Subject: Re: [SS:1226] Re: Metricom Expects to Provide 85K wireless data >At 06:32 AM 4/1/97 -0600, Dewayne Hendricks wrote: >>Metricom Expects to Provide 85K wireless data >> >> >>Source: Business Wire >> >>LOS GATOS, Calif.--(BUSINESS WIRE) via Individual Inc. -- Metricom, Inc. >>(NASDAQ: MCOM) today announced it is developing new technology designed >>to dramatically increase data speeds on its wireless network. The new >>technology, code-named Autobahn, will utilize two bands of unlicensed >>spectrum: the 900 MHz band and the 2.4 GHz band, and will be compatible >>with the company's existing Ricochet networks. It will provide Ricochet >>subscribers with up to 85 kbps. of data speeds, and is scheduled to be >>ready for deployment in 1998. >Dewayne: > >Any more technical details available? I'm assuming (maybe?) they will >be using the 900mhz as a back channel with some sort of full duplex >arrangement to help the throughput. > >It would be interesting to hear a case study of the trials and >tribulations Metricom has had in deploying its FH network. Its >also odd to note that the move to 85 kbps is characterized >as "dramatically increase data speeds on its wireless network". >One has to wonder what the present throughput is based on that >statement. >Regards, >------------------------------------ >| Jeff King Aero Data Systems | This is probably Metricom Marketing speaking, with "dramatically increase data speeds" in comparison to 33k or 28k8 data rates on phone lines and/or their Ricochet system which I think is 28kbps max.. ---- (Am cordless; will travel.) --taylord@ecn.purdue.edu From jeff@mich.com Wed Apr 02 17:15:00 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 RAA15366 for ; Wed, 2 Apr 1997 17:14:59 -0600 (CST) Received: from gw-aerodata.mich.com (gw-aerodata.mich.com [198.108.16.31]) by server1.mich.com (8.8.4/8.8.4) with SMTP id SAA03424; Wed, 2 Apr 1997 18:15:45 -0500 Message-Id: <2.2.32.19970402231402.006bccb4@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, 02 Apr 1997 18:14:02 -0500 To: Bob Lorenzini From: Jeff King Subject: Re: [SS:1225] Freewave setup - offtopic Cc: ss@tapr.org, hwm@netcom.com At 12:32 PM 4/2/97 -0800, Bob Lorenzini wrote: > > >On Wed, 2 Apr 1997, Jeff King wrote: > >> A little more detail would help. Do you wish to use one freewave >> radio at the LINUX site (your master)? Or do you wish to use multiple >> freewaves at the main (linux) router site? > > There will be one FreeWave/Linux box serving data collection >laptops (W95) on a navy base. This brings up something that was >bothering me as I have never used PPP for other than point to point >and I wonder if it is even capable of point to multipoint. > No, PPP is not capable of multi-point. However, SLIP is and I have used that in the past with the freewaves. The 'stock' multi-point mode is not very robust in the FreeWave however. You might be able to use the TDMA mode, which is a seperate firmware for the freewave. Also, mode '6' might be of value you to you on the freewaves. It wouldn't support IP out of the box, but it sounds like you don't need these boxes on the net... hence you could just write a ap to service them. Mode 6 allows you to address individial freewave boxes. 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 crlbyer@garlic.com Wed Apr 02 18:23:20 1997 Received: from garlic.com (root@garlic.com [165.227.35.130]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA24227 for ; Wed, 2 Apr 1997 18:23:18 -0600 (CST) Received: from met-122.arc.nasa.gov by garlic.com (8.8.5/4.03) id AAA234556; Thu, 3 Apr 1997 00:23:12 GMT Message-ID: <3342F7FA.32C7@garlic.com> Date: Wed, 02 Apr 1997 16:21:14 -0800 From: Carol Byers Reply-To: crlbyers@garlic.com Organization: no1nos X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1230] Re: Metricom Expects to Provide 85K wireless data References: <1.5.4.32.19970402223110.0068e2bc@luminet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jim Jefferson wrote: > > >Any more technical details available? I'm assuming (maybe?) they will > >be using the 900mhz as a back channel with some sort of full duplex > >arrangement to help the throughput. > > > >It would be interesting to hear a case study of the trials and > >tribulations Metricom has had in deploying its FH network. Its > >also odd to note that the move to 85 kbps is characterized > >as "dramatically increase data speeds on its wireless network". > >One has to wonder what the present throughput is based on that > >statement. > > Jeff, I was lucky enough to attend a conference given by the CEO of Metricom > at the AAAS meetings this year. I must say that his lecture was excellent! > > For what I understood it sounded like they ( Metricom ) could guarantee > at least 9600Kbs throughput, but the average user got about 33.6Kbs throughput. > In the conference center we were in ( big brick building ) we were getting awful > throughput I must say. > > I also wonder what is the cost going to be to transfer over to a new network? > > 73's de > > Jim Jefferson KB0THN > cjeffers@luminet.net > http://www.luminet.net/~cjeffers/ Jim's KB0THN Satellite Page! I have been evaluating this service for the past six months, and find it to be very reliable, good throughput ( 19.2kbps to 28.8 kbps), and very easy to use. We have it setup with an IP Gateway to our networks, and find it to be an excellent service. I believe that they will meet their new speed-goal in 1998. Carol, W9HGI From jeff@mich.com Wed Apr 02 18:28:01 1997 Received: from server1.mich.com (root@server1.mich.com [198.108.16.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA27675 for ; Wed, 2 Apr 1997 18:28:00 -0600 (CST) Received: from gw-aerodata.mich.com (gw-aerodata.mich.com [198.108.16.31]) by server1.mich.com (8.8.4/8.8.4) with SMTP id TAA15357 for ; Wed, 2 Apr 1997 19:28:52 -0500 Message-Id: <2.2.32.19970403002706.00a04388@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, 02 Apr 1997 19:27:06 -0500 To: ss@tapr.org From: Jeff King Subject: Re: [SS:1225] Freewave setup - offtopic At 12:32 PM 4/2/97 -0800, Bob Lorenzini wrote: > > >On Wed, 2 Apr 1997, Jeff King wrote: > >> A little more detail would help. Do you wish to use one freewave >> radio at the LINUX site (your master)? Or do you wish to use multiple >> freewaves at the main (linux) router site? > > There will be one FreeWave/Linux box serving data collection >laptops (W95) on a navy base. This brings up something that was >bothering me as I have never used PPP for other than point to point >and I wonder if it is even capable of point to multipoint. > No, PPP is not capable of multi-point. However, SLIP is and I have used that in the past with the freewaves. The 'stock' multi-point mode is not very robust in the FreeWave however. You might be able to use the TDMA mode, which is a seperate firmware for the freewave. Also, mode '6' might be of value you to you on the freewaves. It wouldn't support IP out of the box, but it sounds like you don't need these boxes on the net... hence you could just write a ap to service them. Mode 6 allows you to address individial freewave boxes. 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 dej@edge.net Wed Apr 02 18:32:37 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 SAA29201 for ; Wed, 2 Apr 1997 18:32:35 -0600 (CST) Received: from sleepy (s22-pm03.tnstate.campus.mci.net [205.219.190.111]) by edge.edge.net (8.7.5/8.7.3) with SMTP id SAA20431 for ; Wed, 2 Apr 1997 18:32:32 -0600 (CST) Message-Id: <3.0.1.32.19970402183222.0068ef38@edge.net> X-Sender: dej@edge.net X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 02 Apr 1997 18:32:22 -0600 To: ss@tapr.org From: Eric Johnson Subject: Re: [SS:1229] Re: Freewave setup - offtopic In-Reply-To: References: <2.2.32.19970402170752.0090e120@mail.mich.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 02:39 PM 4/2/97 -0600, you wrote: >> One thing I've never had any luck is in getting WIN95 built-in PPP/ >> winsock to work with the FreeWave's. I've had to use Trumpet Winsock. >> The native WIN95 winsock PPP expects a modem and doesn't seem to >> want to work with a direct connect (as the freewave appears). If >> anyone has had any luck Check out .. http://www.vt.edu:10021/K/kewells/net/ It is a modem definition file for WIN95 using a direct connection. --Eric ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eric Johnson, N4SCS ! dej@edge.net Research Electronics Inc. ! WWW: http://edge.edge.net/~dej 515 S. Old Kentucky Rd ! REI WWW: http://www.multipro.com/research Cookeville, TN 38501 ! Phone: (615)528-5756 ! Fax: (615)528-7854 ! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From strohs@halcyon.com Wed Apr 02 18:54:46 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 SAA00861 for ; Wed, 2 Apr 1997 18:54:44 -0600 (CST) Received: from chinook.halcyon.com by mail1.halcyon.com (5.65v3.2/1.1.10.5/10Nov96-0444PM) id AA07997; Wed, 2 Apr 1997 16:54:59 -0800 Date: Wed, 2 Apr 1997 16:54:42 -0800 (PST) From: Steve Stroh To: TAPR Spread Spectrum SIG Mailing List Subject: Re: [SS:1223] Metricom Expects to Provide 85K wireless data In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 1 Apr 1997, Dewayne Hendricks wrote: > Metricom Expects to Provide 85K wireless data > > Source: Business Wire > > LOS GATOS, Calif.--(BUSINESS WIRE) via Individual Inc. -- Metricom, Inc. > (NASDAQ: MCOM) today announced it is developing new technology designed > to dramatically increase data speeds on its wireless network. The new > technology, code-named Autobahn, will utilize two bands of unlicensed > spectrum: the 900 MHz band and the 2.4 GHz band, and will be compatible > with the company's existing Ricochet networks. It will provide Ricochet > subscribers with up to 85 kbps. of data speeds, and is scheduled to be > ready for deployment in 1998. > > The company also disclosed that it will be exploring the possible > purchase of licensed spectrum, to augment its use of unlicensed spectrum > and to further enhance Ricochet network performance. In this regard, the > company announced that it has filed an application with the Federal > Communications Commission to bid on spectrum in the upcoming Wireless > Communications Services (WCS) auctions. Perhaps to add some insight to this. George Flammer of Metricom spoke to the Puget Sound Amateur Radio TCP/IP Group about the Ricochet system that had (then) just recently been activated in the Seattle metro area. One of the questions that got asked is isn't it counterproductive to "compete" with your customers by using the same band (902-928 MHz) to communicate between the poletop units? Isn't that "stealing" potential bandwidth away from your customers? George replied Yes, that was a known (potential) issue, and Metricom was looking seriously at making use of a second band for communicating between the poletop units. It seemed to me that the use of a second band was the only way Ricochet would be able to scale to be able to accomodate the customer base of a major city such as Chicago, LA, or NYC. Steve N8GNJ -- Steve Stroh Woodinville, Washington, USA strohs@halcyon.com From jerry@nccn.net Thu Apr 03 01:12:17 1997 Received: from nccn.net (nccn1.nccn.net [205.139.74.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id BAA13450 for ; Thu, 3 Apr 1997 01:12:16 -0600 (CST) Received: from jerry.nccn.net (ppp165.nccn.net [205.139.74.165]) by nccn.net (8.8.3/8.7.3) with SMTP id XAA12256; Wed, 2 Apr 1997 23:13:21 -0800 (PST) Message-ID: <334357A3.493E@nccn.net> Date: Wed, 02 Apr 1997 23:09:23 -0800 From: Jerrold E Gallagher Reply-To: jerry@nccn.net X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: Jeff King CC: ss@tapr.org Subject: Re: Freewave setup - offtopic References: <199704030507.XAA22620@tapr.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ss@tapr.org wrote: > > SS Digest 283 > .... > Date: Wed, 2 Apr 1997 12:32:54 -0800 (PST) > From: Bob Lorenzini > To: Jeff King > Subject: Re: Freewave setup - offtopic > Message-ID: > > On Wed, 2 Apr 1997, Jeff King wrote: > > > A little more detail would help. Do you wish to use one freewave > > radio at the LINUX site (your master)? Or do you wish to use multiple > > freewaves at the main (linux) router site? > > There will be one FreeWave/Linux box serving data collection > laptops (W95) on a navy base. This brings up something that was > bothering me as I have never used PPP for other than point to point > and I wonder if it is even capable of point to multipoint. > > > > > One thing I've never had any luck is in getting WIN95 built-in PPP/ > > winsock to work with the FreeWave's. I've had to use Trumpet Winsock. > > The native WIN95 winsock PPP expects a modem and doesn't seem to > > want to work with a direct connect (as the freewave appears). If > > anyone has had any luck > > Thanks for the tip. Much appreciated. > > Bob - wd6dod > > Date: Wed, 2 Apr 1997 16:54:42 -0800 (PST) > From: Steve Stroh ..... > End of SS Digest 283 > ******************** Somebody, please, forward to WD6DOD and to whomever it may concern: It's just an idea you might try for getting the native WIN95 winsock PPP to work; viz., from the desk top, go into My Computer | Control Panel | Add/Remove Programs and select the WINDOWS SETUP tab in Add/Remove Programs Properties, then select the details box for the Communications []group and check to see that the []Direct Cable Connection box is checked. If it isn't, check it and back out with apply and close to save everything with the "Cable Connection" now active. 'Hope this works, 73, de: Jerrold E Gallagher, K6LYR -- jerry@nccn.net From dewayne@warpspeed.com Thu Apr 03 15:20:12 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 PAA17933 for ; Thu, 3 Apr 1997 15:20:04 -0600 (CST) Received: from [192.160.122.32] by warpspeed.com with ESMTP (Apple Internet Mail Server 1.1.1); Thu, 3 Apr 1997 13:19:57 -0800 Message-Id: In-Reply-To: <2.2.32.19970402170259.008eef04@mail.mich.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 3 Apr 1997 14:19:44 -0700 To: Jeff King From: Dewayne Hendricks Subject: Re: [SS:1223] Metricom Expects to Provide 85K wireless data Cc: ss@tapr.org, ss-sta@tapr.org At 12:02 PM -0500 4/2/97, Jeff King wrote: > >Any more technical details available? I'm assuming (maybe?) they will >be using the 900mhz as a back channel with some sort of full duplex >arrangement to help the throughput. > I don't have anything more to add than what Steve Stroh posted in response to your query. My understanding is that they will use 2.4 GHz for their backbone. You may be interested to know that today, the FCC Commissioner's voted to allow unlimited antenna gain for unlicensed Part 15 spread spectrum devices (Part 15.247) on the 2.4 and 5.8 GHz bands. So the 4 W EIRP limit on those bands is a thing of the past. This will make it a LOT easier to operate such longer range links as Metricom has in mind. Then again, it may also make the amateur radio service a bit less attractive to those who are interested in setting up high-speed Internet links. Time will tell.... >It would be interesting to hear a case study of the trials and >tribulations Metricom has had in deploying its FH network. Its >also odd to note that the move to 85 kbps is characterized >as "dramatically increase data speeds on its wireless network". >One has to wonder what the present throughput is based on that >statement. The only thing that I am aware of in terms of a case study is an old paper from 1993 that was written by Mike Pettus of Metricom (he's a long-time ham) on the technical details of their network. As for the 85 kpbs, well as a current user of their network, if they can do that they are going to have LOTS of very happy customers!! The problem is having to wait until 1988 for it to happen. -- 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 bad@ece.WPI.EDU Thu Apr 03 17:56:15 1997 Received: from ece.WPI.EDU (root@ece.WPI.EDU [130.215.16.20]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id RAA05928 for ; Thu, 3 Apr 1997 17:56:14 -0600 (CST) Received: from cwins3.WPI.EDU (cwins3.WPI.EDU [130.215.16.212]) by ece.WPI.EDU (8.8.3/8.6) with ESMTP id SAA08003 for ; Thu, 3 Apr 1997 18:56:12 -0500 (EST) Received: from localhost (bad@localhost) by cwins3.WPI.EDU (8.8.3/8.6) with SMTP id SAA17908 for ; Thu, 3 Apr 1997 18:56:11 -0500 (EST) X-Authentication-Warning: cwins3.WPI.EDU: bad owned process doing -bs Date: Thu, 3 Apr 1997 18:56:11 -0500 (EST) From: Bernie Doehner To: ss@tapr.org Subject: DC blocks for those of you who have older NCR Wavelan cards Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi: I just bought two Radio Shack CATV DC blocks and swept them on our network analyzer. I was quite surprised when I found the loss to be 0.2-0.25 dB/DC block. So, I'll be using them with my loop yagi to keep the Wavelan cards happy. Best Regards, Bernie NU1S From karn@qualcomm.com Thu Apr 03 23:27:27 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 XAA07659 for ; Thu, 3 Apr 1997 23:27:26 -0600 (CST) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id VAA13186; Thu, 3 Apr 1997 21:26:53 -0800 (PST) Date: Thu, 3 Apr 1997 21:26:53 -0800 (PST) From: Phil Karn Message-Id: <199704040526.VAA13186@servo.qualcomm.com> To: ss@tapr.org In-reply-to: <2.2.32.19970402231402.006bccb4@mail.mich.com> (message from Jeff King on Wed, 2 Apr 1997 17:17:18 -0600 (CST)) Subject: Re: [SS:1232] Re: Freewave setup - offtopic >No, PPP is not capable of multi-point. However, SLIP is and I have >used that in the past with the freewaves. The 'stock' multi-point Eh? Both PPP and SLIP are point-to-point protocols. Phil From jeff@mich.com Fri Apr 04 01:30:25 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 BAA00136 for ; Fri, 4 Apr 1997 01:30:24 -0600 (CST) Received: from gw-aerodata.mich.com (gw-aerodata.mich.com [198.108.16.31]) by server1.mich.com (8.8.4/8.8.4) with SMTP id CAA27821; Fri, 4 Apr 1997 02:31:54 -0500 Message-Id: <2.2.32.19970404072936.00738368@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, 04 Apr 1997 02:29:36 -0500 To: ss@tapr.org, ss@tapr.org From: Jeff King Subject: Re: [SS:1240] Re: Freewave setup - offtopic At 11:42 PM 4/3/97 -0600, Phil Karn wrote: >>No, PPP is not capable of multi-point. However, SLIP is and I have >>used that in the past with the freewaves. The 'stock' multi-point > >Eh? Both PPP and SLIP are point-to-point protocols. > >Phil > PPP will only work point to point. SLIP can be made to work on a multi-drop line (or on a freewave). Try it, it works. I've done it using Livingston port masters, and MAC and PC's running winsock. The spec may not read that way but it can be made to work. 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 jdc@dos.nortel.com Fri Apr 04 06:57:57 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 GAA27260 for ; Fri, 4 Apr 1997 06:57:55 -0600 (CST) 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 HAA00862 for ; Fri, 4 Apr 1997 07:58:24 -0500 (EST) Received: from sun144.humb.nt.com by sunsrvr6.humb.nt.com (4.1/SMI-4.1) id AA01305; Fri, 4 Apr 97 07:57:53 EST From: "James D. Cronin" Message-Id: <9704040757.ZM4774@sun144> Date: Fri, 4 Apr 1997 07:57:52 -0500 In-Reply-To: Dewayne Hendricks "[SS:1238] Re: Metricom Expects to Provide 85K wireless data" (Apr 3, 3:25pm) References: X-Mailer: Z-Mail (3.2.1 15feb95) To: ss@tapr.org Subject: Question on OCI "RF Engine" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii I recently received a blurb on a spread spectrun radio/modem combo for 900 Mhz. They have info on their web page, http://www.ocilawn.com/200-rfe.htm Is this suitable for connection to the header of a TNC-2? Would there be interest in a group purchase? It may be good only for short links, but we have a reasonable number of them in our area, and it would lower frequencies for longer hops. 73..Jim N2VNO From n7oo@goodnet.com Fri Apr 04 09:56:01 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 JAA14978 for ; Fri, 4 Apr 1997 09:56:00 -0600 (CST) Received: from goodguy (n7oo@goodnet.com [207.98.129.1]) by mailque.goodnet.com (8.8.5/8.7.3) with SMTP id IAA04796 for ; Fri, 4 Apr 1997 08:48:21 -0700 (MST) Date: Fri, 4 Apr 1997 08:49:18 -0700 (MST) From: Jack Taylor X-Sender: n7oo@goodguy To: ss@tapr.org Subject: Re: [SS:1239] DC blocks for those of you who have older NCR Wavelan cards In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Bernie, thanks for the tip and what frequency range did you sweep these for? 73 de Jack On Thu, 3 Apr 1997, Bernie Doehner wrote: > Hi: > > I just bought two Radio Shack CATV DC blocks and swept them on our network > analyzer. > > I was quite surprised when I found the loss to be > > 0.2-0.25 dB/DC block. > > So, I'll be using them with my loop yagi to keep the Wavelan cards happy. > > Best Regards, > > Bernie NU1S > > From bad@uhf.wireless.net Fri Apr 04 11:23:09 1997 Received: from uhf.wdc.net (uhf.wdc.net [198.147.74.44]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA23632 for ; Fri, 4 Apr 1997 11:23:06 -0600 (CST) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id MAA07853 for ; Fri, 4 Apr 1997 12:25:09 -0500 (EST) Date: Fri, 4 Apr 1997 12:25:09 -0500 (EST) From: Bernie Doehner To: ss@tapr.org Subject: Re: [SS:1243] Re: DC blocks for those of you who have older NCR Wavelan cards In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Hi Bernie, thanks for the tip and what frequency range did you sweep these > for? > > 73 de Jack > Hi Jack: Sorry!!! Forgot to mention that. 902-928 MHz. And the 0.2-0.25 dB loss is voltage (not power loss) (50 ohm input/output ports). Best Regards, Bernie > > Hi: > > > > I just bought two Radio Shack CATV DC blocks and swept them on our network > > analyzer. > > > > I was quite surprised when I found the loss to be > > > > 0.2-0.25 dB/DC block. > > > > So, I'll be using them with my loop yagi to keep the Wavelan cards happy. > > > > Best Regards, > > > > Bernie NU1S > > > > > > From bm@lynx.ve3jf.ampr.org Fri Apr 04 21:40:55 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 VAA26995 for ; Fri, 4 Apr 1997 21:40:52 -0600 (CST) Received: (from bm@localhost) by lynx.ve3jf.ampr.org (8.6.12/8.6.12) id DAA25906 for ss@tapr.org; Sat, 5 Apr 1997 03:40:34 GMT From: Barry McLarnon VE3JF Message-Id: <199704050340.DAA25906@lynx.ve3jf.ampr.org> Date: Sat, 5 Apr 1997 03:40:33 +0000 (GMT) To: ss@tapr.org Subject: Re: [SS:1244] Re: DC blocks for those of you who have older NCR Wavelan cards In-Reply-To: X-Mailer: Ishmail 1.3.1-961106-linux MIME-Version: 1.0 Content-Type: text/plain Bernie Doehner wrote: > > Hi Bernie, thanks for the tip and what frequency range did you sweep > these > > for? > > > > 73 de Jack > > > > Hi Jack: > > Sorry!!! Forgot to mention that. 902-928 MHz. And the 0.2-0.25 dB > loss is > voltage (not power loss) (50 ohm input/output ports). Say what? Anything expressed in dB is a power ratio, by definition. If you measured voltages, then the loss is 20log(Vout/Vin) dB, assuming that the ports have the same impedance. There's no such thing as "voltage loss" expressed in dB. And wouldn't a CATV widget be 75 ohms, not 50? Cheers, 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 bad@uhf.wireless.net Sat Apr 05 00:04:17 1997 Received: from uhf.wdc.net (uhf.wdc.net [198.147.74.44]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id AAA07458 for ; Sat, 5 Apr 1997 00:04:14 -0600 (CST) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id BAA00546 for ; Sat, 5 Apr 1997 01:04:51 -0500 (EST) Date: Sat, 5 Apr 1997 01:04:50 -0500 (EST) From: Bernie Doehner To: ss@tapr.org Subject: [SS:1239] DC blocks for those of you who have older NCR Wavelan cards In-Reply-To: <199704050123.RAA00410@f33.hotmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Slight correction: The 0.2-0.25 dB/connector is a power loss, not a voltage loss. I appologize for the incorrect statement. Bernie From bad@uhf.wireless.net Sat Apr 05 00:13:55 1997 Received: from uhf.wdc.net (uhf.wdc.net [198.147.74.44]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id AAA09864 for ; Sat, 5 Apr 1997 00:13:49 -0600 (CST) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id BAA00557 for ; Sat, 5 Apr 1997 01:14:26 -0500 (EST) Date: Sat, 5 Apr 1997 01:14:25 -0500 (EST) From: Bernie Doehner To: ss@tapr.org In-Reply-To: <199704050340.DAA25906@lynx.ve3jf.ampr.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > If you measured voltages, then the loss is 20log(Vout/Vin) dB, > assuming that the ports have the same impedance. There's no such > thing as "voltage loss" expressed in dB. Yes yes yes. I thought I had it incorrectly calculated at 10log, but that wasn't the case. > And wouldn't a CATV widget be 75 ohms, not 50? Yes. Impedance bump indeed, but tell that to the early Wavelan designers! We had a rep from Lucent at our wireless networking show last october and he as well as the rep from DEC assured me that the output impedance of the Wavelans and Roamabouts is and has always been 50 ohms (even though they used lossy 75 ohm connectors in the early models). There is also a 2-3 mm. space between the PCB and the F connector on these cards. I can only guess at how much power gets radiated by this gap. I have searched long and hard to try to replace these crummy F connectors with BNC's, but none of the connectors I found came even close in terms of pin spacing/size. Bernie From cjeffers@luminet.net Sun Apr 06 19:27:03 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 TAA04173 for ; Sun, 6 Apr 1997 19:27:01 -0500 (CDT) Received: from brain-dead.localnet by luminet1 (SMI-8.6/SMI-SVR4) id TAA06214; Sun, 6 Apr 1997 19:25:56 -0500 Message-Id: <1.5.4.32.19970407002638.0069cb88@luminet.net> X-Sender: cjeffers@luminet.net (Unverified) X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 06 Apr 1997 19:26:38 -0500 To: ss@tapr.org From: Jim Jefferson Subject: FreeWave Deal? Did the freewave deal fall through? -Jim Jefferson KB0THN cjeffers@luminet.net http://www.luminet.net/~cjeffers/ From n3jly@erols.com Sun Apr 06 23:05:13 1997 Received: from smtp1.erols.com (smtp1.erols.com [205.252.116.101]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id XAA23053 for ; Sun, 6 Apr 1997 23:05:10 -0500 (CDT) Received: from LOCALNAME (col-as12s24.erols.com [207.172.74.168]) by smtp1.erols.com (8.8.5/8.8.5) with SMTP id AAA29046 for ; Mon, 7 Apr 1997 00:05:14 -0400 Date: Mon, 7 Apr 1997 00:05:14 -0400 Message-Id: <199704070405.AAA29046@smtp1.erols.com> X-Sender: n3jly@pop.erols.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org From: Tony McConnell Subject: Re: [SS:1248] FreeWave Deal? yes Jim, it did. At 07:33 PM 4/6/97 -0500, you wrote: >Did the freewave deal fall through? > >-Jim Jefferson KB0THN >cjeffers@luminet.net >http://www.luminet.net/~cjeffers/ > > > From fmcnally@market1.com Tue Apr 08 21:52:38 1997 Received: from explore.market1.com (market1.com [208.129.57.12]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id VAA26017 for ; Tue, 8 Apr 1997 21:52:37 -0500 (CDT) Received: from [208.136.140.132] by explore.market1.com (post.office MTA v1.9.3 **** trial license expired ****) with SMTP id AAA330; Tue, 8 Apr 1997 20:55:28 -0600 Message-Id: <3.0.16.19970408205308.4fef1c08@market1.com> X-Sender: fmcnally@market1.com X-Mailer: Windows Eudora Pro Version 3.0 (16) To: ss@tapr.org From: fmcnally@market1.com (Frank McNally) Subject: Re: [SS:1204] Re: SS:938 & SS:960 Cc: pconner@market1.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 8 Apr 1997 20:55:28 -0600 I do not understand why there has not been more interest by the TAPR group in Randy's offer. I have investigated his page and find it to be very interesting. As a group, we are looking to learn and build SS boxes for ourselves. I believe this is a perfect opportunity for all of us. I hope we are not missing the boat on this one. At 08:17 AM 3/20/97 -0600, you wrote: >Here's a little more ACTION for the SS adventuresome out there in TAPR-land: > >I have posted schematics, PCB files & basic 16C64 microprocessor code up on >my site for some of the SST-1 radio-modem -- for your viewing and >downloading pleasure! > >Take a look at: http://sss-mag.com/whatsnew/nuissue.html#3 > >A BARE PCB for the "Baseband" section of the SST-1 will be available soon at >US$39 each -- see above link for more info. > >BTW, this project was originally dubbed the "VAPOR1" as a play on words -- >it has now become the SST-1, but some of the files still have vapor'ish >names :-) > >73 for now, > >Randy, KC6YJY > > > > From wd5ivd@tapr.org Tue Apr 08 22:50:16 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 WAA29485 for ; Tue, 8 Apr 1997 22:50:13 -0500 (CDT) Message-Id: In-Reply-To: <3.0.16.19970408205308.4fef1c08@market1.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 8 Apr 1997 22:45:47 -0500 To: ss@tapr.org From: "Greg Jones, WD5IVD" Subject: Re: [SS:1250] Re: SS:938 & SS:960 Hi Frank. As I followed up with -- who is willing to take the time and energy to take the proposal and make it into a TAPR project/kit for the members ? If all this is ready to go, then TAPR probably doesn't need to be doing it, but PacComm or someone else should think about doing commercially and making it available. See my messages posted right after Randy's. I don't have the time currently to bird dog the project (numerous issue and hours of work) to making the thing into something that many can access. I have three TAPR projects I am trying to get closure on before Dayton and a dissertation which my Prof is bleeding (in green ink) all over each time she reads it. Who does ? If someone does and is willing to make the commitment to do it, I am more than willing to ask the TAPR board to support someone(s) proposal for doing it within TAPR. I had one comment, but no comments or commitment for someone(s) to do anything with the proposal. Looking forward to maybe someone stepping forward and taking this on ? Cheers -- Greg >I do not understand why there has not been more interest by the TAPR group >in Randy's offer. I have investigated his page and find it to be very >interesting. As a group, we are looking to learn and build SS boxes for >ourselves. I believe this is a perfect opportunity for all of us. I hope >we are not missing the boat on this one. > >At 08:17 AM 3/20/97 -0600, you wrote: >>Here's a little more ACTION for the SS adventuresome out there in TAPR-land: >> >>I have posted schematics, PCB files & basic 16C64 microprocessor code up on >>my site for some of the SST-1 radio-modem -- for your viewing and >>downloading pleasure! >> >>Take a look at: http://sss-mag.com/whatsnew/nuissue.html#3 >> >>A BARE PCB for the "Baseband" section of the SST-1 will be available soon at >>US$39 each -- see above link for more info. >> >>BTW, this project was originally dubbed the "VAPOR1" as a play on words -- >>it has now become the SST-1, but some of the files still have vapor'ish >>names :-) >> >>73 for now, >> >>Randy, KC6YJY >> >> >> >> ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From n3jly@erols.com Wed Apr 09 00:08:52 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 AAA09902 for ; Wed, 9 Apr 1997 00:08:50 -0500 (CDT) Received: from LOCALNAME (col-as4s05.erols.com [207.172.69.5]) by smtp3.erols.com (8.8.5/8.8.5) with SMTP id BAA09519; Wed, 9 Apr 1997 01:08:47 -0400 Date: Wed, 9 Apr 1997 01:08:47 -0400 Message-Id: <199704090508.BAA09519@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:1250] Re: SS:938 & SS:960 Cc: frussle@erols.com At 09:54 PM 4/8/97 -0500, you wrote: >I do not understand why there has not been more interest by the TAPR group >in Randy's offer. I have investigated his page and find it to be very >interesting. As a group, we are looking to learn and build SS boxes for >ourselves. I believe this is a perfect opportunity for all of us. I hope >we are not missing the boat on this one. Frank, I do understand how you feel about Randy's offer. It sounds interesting. I can't speak for TAPR, BUT... my view of the matter is... Randy has offered his design, royalty free, ON A TEMPORARY BASIS. Please understand, I find this a resonable offer, but one with a catch. Can TAPR encourage us all to go forward with a system/format/design that is not going to be in the public domain in the future? The system as Randy described it would deserve consideration. The idea of transmit and receive IFs that would then be transverted to the band of interest is a good idea. There are other ways to design an SS system that is band independant. We have a wonderful opertunity to use Amatuer Radio the way that it has been used in the (unfortunately distant) past. EXPERIMENT!!! Like they say in my daughters favorite tv show "go out there take chances, get messy, Learn something!" I hope that the readers of this SIG as a group are the ones that see the promise of spread spectrum. Not all of us here know which end of a soldering iron is the safe one to grab but.... We can't wait for anyone to hand us the answers. Not Randy. Not Qualcom. Not Harris. Not Motorola/Loral/Freewave et al.... other than Randy I know that whole list would like nothing better than to keep us out of 'their' precious spectrum. Where we are 'primary' but they are the only ones there. I truly hope there are other people out there studying ss. It's not majic! If you really understand how a ssb transmitter does what it does, you can understand how DS ss could work. If you could picture changing the freq really fast on your HT while you transmitted and your friend across town changed his to receive you, that is how FH ss works. Any technique advanced enough looks like magic, but isn't. This is a great opertunity, don't wait for Kenwood to bring it to you. .... I'll now quietly climb off my soapbox. DE N3JLI From kleber@magiclink.com.br Wed Apr 09 01:53:29 1997 Received: from ruby.magiclink.com.br ([200.254.29.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id BAA25736 for ; Wed, 9 Apr 1997 01:53:27 -0500 (CDT) Received: from mach (slip9 [200.254.29.78]) by ruby.magiclink.com.br (8.8.4/8.6.11) with SMTP id EAA31051 for ; Wed, 9 Apr 1997 04:03:27 -0300 Message-ID: <334B3D0E.5A3D@magiclink.com.br> Date: Wed, 09 Apr 1997 03:54:06 -0300 From: Kleber Almeida Reply-To: kleber@magiclink.com.br Organization: Arrow Sistemas X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: ss@tapr.org Subject: Software for calculate microwave/RF links Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello... Where i acquire softwares (shareware or not) in the Internet for calculate radio links ? Thank's a lot !!! From RLANIER@mailb.harris.com Wed Apr 09 08:10:26 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 IAA28146 for ; Wed, 9 Apr 1997 08:10:25 -0500 (CDT) Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special version 2.0) id JAA29315; Wed, 9 Apr 1997 09:10:18 -0400 Received: from ccMail by mailb.harris.com (IMA Internet Exchange 1.04b) id 34b94f70; Wed, 9 Apr 97 09:09:11 -0400 Mime-Version: 1.0 Date: Wed, 9 Apr 1997 09:09:10 -0400 Message-ID: <34b94f70@mailb.harris.com> From: RLANIER@mailb.harris.com (RLANIER) Subject: Response to SS:938 & SS:960 To: ss@tapr.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part I would like to respond to the responses to these threads on the TAPR SS list ... I am quite fed up with everyone talking about what we should do concerning designing and building a spread spectrum system. I have seen numerous times how this list breaks down to discussions about SSTV or RS-422 vs. Ethernet. I submitted a conceptual systems-level design (remember top-down design?) and heard from ONE person! Everyone wants to grip about the details, but will not discuss the overall system and how everything will fit together. I realize most people are very busy (I work 40+ hrs and take engineering courses at the local university), but if this thing is to get off the ground, we have to AGREE on WHAT to DO!!!! Personally, I think what Randy has to offer is the best way to go. Why? Because using his work as a foundation, we can design a system around his work which will practical, educational and FUN! I have abandoned the chipset idea in favor of a modular system, where the individual sections of the system are composed of discreet parts. We can learn a great deal more designing and building this way. Similar to an academic design, except this one will work! Are we going to work together or not? Tony KE4ATO From randyrf@sss-mag.com Wed Apr 09 09:04:44 1997 Received: from nanospace.com (root@nanos1.nanospace.com [205.199.199.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id JAA00983 for ; Wed, 9 Apr 1997 09:04:42 -0500 (CDT) Received: from pa01-01.nanospace.com ([205.199.196.101]) by nanospace.com with smtp id (Smail3.2); Wed, 9 Apr 1997 06:50:09 -0700 (PDT) Date: Wed, 9 Apr 1997 06:50:09 -0700 (PDT) Message-Id: <2.2.16.19970209054810.2ad79aca@sss-mag.com> X-Sender: randyrf@sss-mag.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 1 (Highest) To: ss@tapr.org From: Randy Roberts Subject: Re: [SS:1253] Software for calculate microwave/RF links Dear Kleber & other SS SIG'ers: There is a lot of this sort of shareware available on my home page(s) -- take a look at: http://sss-mag.com/prop.html http://sss-mag.com/swindex.html http://sss-mag.com/eestuff.html and finally http://sss-mag.com/rfstuff.html Enjoy the downloads & feel free to explore our site with nearly 200 pages of useful html info on RF, SS and electronic engineering / Ham stuff! 73 de KC6YJY, Randy Roberts -------------------------------------------------------------------------------- At 01:57 AM 4/9/97 -0500, you wrote: >Hello... > > Where i acquire softwares (shareware or not) in the Internet for >calculate radio links ? > Thank's a lot !!! > > From randyrf@sss-mag.com Wed Apr 09 09:19:54 1997 Received: from nanospace.com (root@nanos1.nanospace.com [205.199.199.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id JAA02240 for ; Wed, 9 Apr 1997 09:19:50 -0500 (CDT) Received: from pa01-01.nanospace.com ([205.199.196.101]) by nanospace.com with smtp id (Smail3.2); Wed, 9 Apr 1997 07:19:46 -0700 (PDT) Date: Wed, 9 Apr 1997 07:19:46 -0700 (PDT) Message-Id: <2.2.16.19970209061746.2ad7ff00@sss-mag.com> X-Sender: randyrf@sss-mag.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 1 (Highest) To: ss@tapr.org From: Randy Roberts Subject: Re: [SS:1251] Re: SS:938 & SS:960 Hi Greg, Frank, et all: I've been following this SIG for several months now & I'm convinced that MOST of the postings here are almost QRM! But this latest message deserves some comment -- so here goes. First, Greg is absolutely correct -- turning the SST-1 into a viable, producible design will take a LOT of HARD WORK! Second, I think Greg is dead wrong about the commercial viability of ANY SS design for Hams! Both Icom & Kenwood have been longtime subscribers to the (old) printed version of SSS -- have you seen anything SS from them yet? You probably won't either, for a good length of time. I think all breakthroughs in Ham Radio's history have been done with non-commerical first itentions -- e.g. SSB, TAPR-1 packet radio, eme, etc. Third, if the initially proposed 3 year free license is too short -- I'll be glad to extend it to 5 or 7 years -- but, today's IC(ASIC & MMIC)-based equipment is usually obsolete in 3 or 4 years anyway -- just like your 3 year old 486-33 PC. Four, Band independent SS - huh? Well it is possible to do just that with some fairly simple Freq. Hopper designs -- all you need is the baseband circuitry to hop a PLL synthesizer for the TX and RX LO and FSK (or GMSK or MSK or ???) modulate it. The rest of the RX is also quite frequency independent -- all you need is a good IF / demodulator and Freq. Hop. / sync circuitry! I DON'T think any DS implementation is bnad independent, however! My general approach and thinking with the SST-1 was to provide for BOTH DS AND FH -- the only practical way to do this is with a COMMON basbeand / IF unit attached to band specific "transverters." Finally, REMEMBER that the ONLY SS Chipset now available with a SECOND SOURCE is the STEL-2000A / Zilog Z87200 !!! Wonder why I picked it? This chipset provides up to 18 dB processing gain AND uses a Fast parallel correlator -- this makes FH sync easy, quick & practical -- along with providing very fast acquisition for DSSS. BTW, I have received quite a few nice comments on this design as well as other offers of various kinds of help from around the world -- just maybe, TAPR should think about teaming up with one or more other international groups to undertake a Ham SS project like the SST-1!!! Let's see some thought out, on track (or SS pertinent) postings here! Any comments / questions / suggestions or requests? 73 de KC6YJY, Randy -------------------------------------------------------------------------------- At 11:13 PM 4/8/97 -0500, you wrote: >Hi Frank. > >As I followed up with -- who is willing to take the time and energy to take >the proposal and make it into a TAPR project/kit for the members ? If all >this is ready to go, then TAPR probably doesn't need to be doing it, but >PacComm or someone else should think about doing commercially and making it >available. > . . . > >Cheers -- Greg > >>I do not understand why there has not been more interest by the TAPR group >>in Randy's offer. I have investigated his page and find it to be very >>interesting. . . >> >>At 08:17 AM 3/20/97 -0600, you wrote: >>>Here's a little more ACTION for the SS adventuresome out there in TAPR-land: >>> >>>I have posted schematics, PCB files & basic 16C64 microprocessor code up on >>>my site for some of the SST-1 radio-modem -- for your viewing and >>>downloading pleasure! >>> >>>Take a look at: http://sss-mag.com/whatsnew/nuissue.html#3 >>> . . . >>> > > >----- >Greg Jones, WD5IVD >Austin, Texas >wd5ivd@tapr.org >http://www.tapr.org/~wd5ivd >----- From wd5ivd@tapr.org Wed Apr 09 10:53:02 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 KAA15147 for ; Wed, 9 Apr 1997 10:53:00 -0500 (CDT) Message-Id: In-Reply-To: <2.2.16.19970209061746.2ad7ff00@sss-mag.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 9 Apr 1997 10:48:33 -0500 To: ss@tapr.org From: "Greg Jones, WD5IVD" Subject: Re: [SS:1256] Re: SS:938 & SS:960 >Hi Greg, Frank, et all: > >I've been following this SIG for several months now & I'm convinced that >MOST of the postings here are almost QRM! But this latest message deserves >some comment -- so here goes. > >First, Greg is absolutely correct -- turning the SST-1 into a viable, >producible design will take a LOT of HARD WORK! There are two projects and probably more with people doing things -- I feel that we will see stuff start to appear in 8-12 months or more as things go down paths. We have to remember that the amateur development hobby cycle is much slower then commercial development. The real push on stuff has started, because of the emphasis placed on development just in the last 12-14 months. I just read Tony's post and can understand his side of things as well, but success requires at least four items: 1. people 2. critical mass of people with certain skills 3. time 4. and money Most of the time to get things done, you have to generate at least 3 of those 4 items yourself. Waiting around and discussing doesn't make it happen. All projects in TAPR happen because someone jumps in and has a desire to see something completed. There is always one person that has to take the point and see something through or fall in -- and even then sometime a project can fail. This is one reason we see some of the same people show up over the years. Once you have done a project, you understand what is required and subsequent projects are easier in some ways. Plus, whatever made the first project successful is probably still in place for later attempts. If someone has a concept for something, getting on this list and discussing it is good, but as I stated over on the HF SIG a week or so ago, will most likely not result in getting anything done. These lists provide good interchange, but have yet to spawn a project. Maybe someone will show me I am wrong and be able to do something. What I typically see is that a discussion on the list generates some small group to then go off and do something and then bring it back to the group at some later time. >Second, I think Greg is dead wrong about the commercial viability of ANY SS >design for Hams! Both Icom & Kenwood have been longtime subscribers to the >(old) printed version of SSS -- have you seen anything SS from them yet? >You probably won't either, for a good length of time. I think all >breakthroughs in Ham Radio's history have been done with non-commerical >first itentions -- e.g. SSB, TAPR-1 packet radio, eme, etc. This is not what I said. Icom and Kenwood don't make amateur radio equipment. They make commercial equipment, that just happens to have a secondary market in amateur radio sales in the US. However, PacComm and several other commercial companies are in a position now to do something with a design that is ready to go. What I said was that it might not make sense for TAPR to do something on a design if it is advanced enough for someone like PacComm to make a finsihed package for the amateur radio community. Having a built and tested unit for amateur radio experimenters is going to be much more successful in terms of number of people playing then having a component level kit or semi-kit. Any type of SS system (RF) is going to have to be much more then just a kit. We probably have about 25% of members within TAPR capable of building and getting fully operational a RF based kit. Thus, a semi-kit with the RF already built and tested has to be seriously examined. Again, maybe I am wrong -- and I hope I am -- that a greater percentage of the membership is in a position to really build RF stuff from component level at 900Mhz or 2.4G. >BTW, I have received quite a few nice comments on this design as well as >other offers of various kinds of help from around the world -- just maybe, >TAPR should think about teaming up with one or more other international >groups to undertake a Ham SS project like the SST-1!!! If someone shows up with a proposal that can then be reviewed, then we have something. There are two projects that will be approaching TAPR in the next month or so for review and possible funding and hopefully we can look at taking on one or both -- but you never know until you see the details and can discuss outcomes with the participants. >Let's see some thought out, on track (or SS pertinent) postings here! Any >comments / questions / suggestions or requests? This would be really welcomed. But this type of stuff doesn't get done by committee. We all have very differing thoughts on design and concept. Just look at the debate of Ethernet vs serial, or some of the others that have happened on the list. That is a weakness of this type of communications, but then again that is the strength as well. The cross-pollination of information and contacts that get many things further along and people thinking and examining their beliefs and reasons for what they had in mind. Just a few personal comments. Greg, WD5IVD ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From sadowski@bellatlantic.net Wed Apr 09 11:30:31 1997 Received: from bamail.agis.net (bamail.agis.net [205.137.48.231]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA16976 for ; Wed, 9 Apr 1997 11:30:29 -0500 (CDT) Received: from traveler (client250-242-102.bellatlantic.net [206.250.242.102]) by bamail.agis.net (8.7.5/8.7.3) with SMTP id MAA11563 for ; Wed, 9 Apr 1997 12:30:27 -0400 (EDT) Message-ID: <334BA541.4323@bellatlantic.net> Date: Wed, 09 Apr 1997 10:18:41 -0400 From: "P.A.Sadowski" X-Mailer: Mozilla 2.02E (Win95; U) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1253] Software for calculate microwave/RF links References: <334B3D0E.5A3D@magiclink.com.br> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I assume Kleber Almeida was interested in link margin calculations? I too am interested in said software - but I'd like it to have "Fresnel Zone" and edge diffraction aspects figured in.... as well as have the answer give me some feedback concerning weather (rain/snow) fading at the freq of interest - and ice accretion loss info (have I asked for everything yet ha ha.) I'd even be willing to attempt the code myself if there were the full set of algorithms available online.... I found some great commercial software for this function.... which used antenna gains... hts above terrain, tx power... terrain, freq etc... but I couldn't afford either commercial package and the terrain data I have (DTED) wasn't an input option anyway (though I believe I could convert DTED into the mesh data structure needed by the commercial software... back to the $$$ problem).... TNX in advance... AH6LS Al Kleber Almeida wrote: > > Hello... > > Where i acquire softwares (shareware or not) in the Internet for > calculate radio links ? > Thank's a lot !!! From sadowski@bellatlantic.net Wed Apr 09 14:54:33 1997 Received: from bamail.agis.net (bamail.agis.net [205.137.48.231]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA05079 for ; Wed, 9 Apr 1997 14:54:32 -0500 (CDT) Received: from traveler (client250-242-101.bellatlantic.net [206.250.242.101]) by bamail.agis.net (8.7.5/8.7.3) with SMTP id PAA12386 for ; Wed, 9 Apr 1997 15:54:30 -0400 (EDT) Message-ID: <334BF4E1.6E37@bellatlantic.net> Date: Wed, 09 Apr 1997 15:58:25 -0400 From: "P.A.Sadowski" X-Mailer: Mozilla 2.02E (Win95; U) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1254] Response to SS:938 & SS:960 References: <34b94f70@mailb.harris.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit RLANIER wrote: > > I would like to respond to the responses to these threads on the TAPR > SS list ... > > I am quite fed up with everyone talking about what we should do > concerning designing and building a spread spectrum system. I have > seen numerous times how this list breaks down to discussions about > SSTV or RS-422 vs. Ethernet. > > I submitted a conceptual systems-level design (remember top-down > design?) and heard from ONE person! Everyone wants to grip about the > details, but will not discuss the overall system and how everything > will fit together. > > I realize most people are very busy (I work 40+ hrs and take > engineering courses at the local university), but if this thing is to > get off the ground, we have to AGREE on WHAT to DO!!!! > > Personally, I think what Randy has to offer is the best way to go. > Why? Because using his work as a foundation, we can design a system > around his work which will practical, educational and FUN! I have > abandoned the chipset idea in favor of a modular system, where the Tony If Randy doesn't require the full blessing of TAPR... maybe "we" just needs to be a group that wants to go ahead and start.... It's not like two different directions (or more) are unheard of within TAPR... example the DSP-93... the Motorola EVM.... and the DSP soundcard effort.... Just a comment... but if a "sub-group" is allowed to go forward with Randy's design.... well at least I can learn from it... count me in. Al AH6LS > individual sections of the system are composed of discreet parts. We > can learn a great deal more designing and building this way. Similar > to an academic design, except this one will work! > > Are we going to work together or not? > > > Tony KE4ATO From randyrf@sss-mag.com Sun Apr 13 12:33:22 1997 Received: from nanospace.com (root@nanos1.nanospace.com [205.199.199.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id MAA05353 for ; Sun, 13 Apr 1997 12:33:19 -0500 (CDT) Received: from pa01-16.nanospace.com ([205.199.196.116]) by nanospace.com with smtp id (Smail3.2); Sun, 13 Apr 1997 10:33:14 -0700 (PDT) Date: Sun, 13 Apr 1997 10:33:14 -0700 (PDT) Message-Id: <2.2.16.19970213093114.4bffc6a6@sss-mag.com> X-Sender: randyrf@sss-mag.com X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 1 (Highest) To: ss@tapr.org From: Randy Roberts Subject: Re: SS:938 & SS:960 QST All You SS Fans out there in SS SIG -land: Please take a look at yet another set of ideas and design concepts for the "ultimate" Ham Radio SS Rig, at: http://sss-mag.com/sst.html Comments, criticisms and even conflicting ideas are welcomed!!! 73 de KC6YJY -- Randy Roberts From srbible@gnatnet.net Sun Apr 13 17:48:49 1997 Received: from rupe.gnatnet.net (root@rupe.gnatnet.net [206.30.198.8]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id RAA05639 for ; Sun, 13 Apr 1997 17:48:46 -0500 (CDT) Received: from avatar.tds.net (dialup36.gnatnet.net [206.30.198.136]) by rupe.gnatnet.net (8.6.13/8.6.12) with SMTP id SAA02303 for ; Sun, 13 Apr 1997 18:49:12 -0400 Message-Id: <1.5.4.32.19970413224838.00665800@gnatnet.net> X-Sender: srbible@gnatnet.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 13 Apr 1997 18:48:38 -0400 To: ss@tapr.org From: "Steven R. Bible" Subject: MY DRAFT Comments on FCC Spread Spectrum Rulemaking Originally posted to vhf@w6yx.stanford.edu and amsat-bb@amsat.org ---------- To: VHFers of the U.S. From: Bill Tynan W3XO Subject: DRAFT of My Proposed Comments on FCC Spread Spectrum Rulemaking Comments on FCCs Notice of Proposed Rulemaking on spread spectrum are due May 5. A copy of the NPRM is availabe on the TAPR Web page. I am posting a DRAFT of the comments I expect to file for anyone who wants to use them in forming their own comments. You may not agree with everything I say, maybe none of it. Nevertheless, everyone seriously interested in the bands above 50 MHz should get comments in by the May 5 date (An original and 4 copies are required). Please do not merely copy my comments. Many comments, all the same, will not carry much weight with the Commission. So, base your comments on mine or don't, but comment. BTW, don't conclude that becasus the FCC NPRM call only for SS above 420 MHz, that the final rules will limit it to these higher frequencies. Many SS proponents will argue that it should be authorized on ALL frequencies above 50 MHz. That is what is allowed in the TAPR STA currently in force. While you are reviewing my comments, if you see any technical, or factual difficulties with them, please let me know as soon as possible. My E-Mail address is biltynan@ktc.com (Note: only one l in bil) 73, Bill Before the Federal Communications Commission Washington, D.C. 20554 In the Matter of ) ) Amendment of Amateur Service ) Rules to Provide For Greater ) WT Docket No.97-12 the Amateur Radio Service to ) Use of Spread Spectrum ) Communication Technologies ) To: The Commission COMMENTS OF WILLIAM A. TYNAN W3XO Background I have been a licensed amateur since 1945, obtaining the call sign W3KMV early 1946. I upgraded to Class A (later called Advanced) in the fall of 1946 and to Extra in the early 1970s. I obtained my present call sign, W3XO in 1976. Throughout those 50 years, my principal interest has been in the bands above 50 MHz. I am currently operational on all bands from 50 to 1296 MHz. For 18 years, from 1975 through 1992, I served as a Contributing Editor of QST Magazine, responsible for the monthly column "The World Above 50 MHz". I was one of the founders of the Radio Amateur Satellite Corporation (AMSAT) and have been serving as its President since late 1991. Introduction I filed reply comments on the proposed liberalization of amateur SS rules as contained in RM-8737 and have reviewed the comments of many of those who took part in that proceeding on both sides. In this document, I will draw on these comments and cite specific references where appropriate. I will also review and update my own comments in that proceeding with information that has come to light since that time; and make specific recommendations based on that information and my own knowledge. Summary I generally support the intent of the Commission's proposed Rule Making contained in this Proceeding - namely liberalizing the rules governing the use of Spread Spectrum (SS) in the Amateur Service. I have always wholeheartedly supported the development of new technologies in and for the Amateur Service and Amateur-satellite Service. I believe that SS may represent a significant vehicle for facilitating improved communication between licensed amateurs, both terrestrially and through amateur satellites. I further believe that the Commission's rules should provide the maximum degree of flexibility for accomplishing this objective, consistent with preserving the viability of current communications capabilities, especially including those associated with various kinds of "weak signal" work, including that through amateur satellites. I contend, that, to promote the development of a variety of SS techniques and not materially impact existing amateur activities, certain provisions must be included in any rules which the Commission may adopt. My views with respect to such provisions will be outlined in these comments, along with supporting technical justification for them. In addition, I believe that, to maximize the flexibility for developing SS techniques for uses other than its apparent advantages in local communication applications, two classes of SS should be defined by the Commission and implemented in any new rules. These will be defined and certain frequency bands suggested for each type. Discussion While SS promises a great deal of benefit of improving amateur and amateur satellite communication, I contend that its unbridled authorization and widespread use, particularly in a wide bandwidth embodiment, has the potential of rendering current techniques, as practiced on the VHF and UHF Amateur bands unusable. As part of their argument that SS offers little or no interference to other modes, SS proponents cite only occasional short lived signals on a specific channel as characteristic of SS interference to other modes.(1), (2) While I acknowledge that this interference scenario may be valid for the case of a single SS station, or even a few such stations; I contend that it is a unrealistic if SS becomes as popular a mode as its proponents obviously hope it will. If that comes to pass, the short bursts of interference referred to in the References, will be repeated by each SS station on the air at the time. If there are, for example one-hundred SS stations on the air in a major metropolitan area, these short bursts of interference will be repeated one-hundred times as often as in the case of a single SS station. Thus, SS interference to other modes could eventually take the form of a continuous "buzz". AS AMSAT and I pointed out (3), SS operation has the potential for raising the noise floor by 50 dB (a factor of TEN-THOUSAND) or more. Some might contend that the potential for having 100 stations operating in an area at a time is small. I contend that this is not necessarily true. A scenario can be envisioned which calls for continuous 24 per day operation of SS stations. Such operation is already present in commercial applications of SS techniques. One example is the Internet connectivity offered by Metricom. Many, who use this service leave their computers and radio transceivers on all the time connected to the Internet through the system. Thus, even when they are not actively using the connection their transceivers are continuously exchanging signals with the local site. While I do not share that view, there is a growing number or licensed amateurs today who feel that inexpensive Internet access should be one of the major "purposes" for Amateur Radio. If such activity gains favor, it is easy to envision local amateur SS links being up continuously, connected to a central station which is connected to the Internet. Even if Internet conectivity does not become a common use for Amateur Radio, various other amateur-only applications such as DX clusterss are likely to employ SS and be active continuously. Many amateurs tody maintian contastant connection with DX clsuters via AX-25 packet radio links. Various reply comments were submitted on RM-8737 stating that AMSAT's calculations on the potential increase in noise floor are wrong. Two claims were made to refute these numbers. One was that the power was in excess of might be expected under "real-world" amateur SS operation. The power level used, is that currently authorized by the Commission for amateur SS operation and the level proposed to be continued by the NPRM. The use of any other scenario would represent shear "guesswork". Nevertheless, even if one were to reduce the power by a factor of one-hundred (to the 1 Watt level), the increase in noise floor would still be 30 dB (a factor of ONE-THOUSAND). The other complaint with the AMSAT approach, was the use of free-space attenuation. I submit that anything other than free-space is unrealistic. While other attenuation models may be applicable to cellular telephone applications and other small terminals located in urban environments, such models are not applicable when applied to "weak signal" amateur stations which characteristically have antennas as high a possible and are generally not located amongst tall buildings. A number of SS proponents participating in RM-8737 made claims that ten years of SS authorization have produced little or no complaints of interference to other modes. I contend that this claim cannot be substantiated for two reasons, the most compelling is that even those proposing further liberalization of SS rules, admit that there has been an extremely small number of amateurs using SS during this period. In addition, there seems to have been a concerted effort to "hide" any operation that did take place. To my knowledge, there have been no tests conducted by SS operators in which non-SS operators were invited to take part. Indeed, I know of at least one prominent weak signal VHF operator in a large West Coast metropolitan area who has repeatedly requested that tests be conducted by SS equipped stations so that he could assess possible interference. All such requests were met with indifference, and even hostility on the part of the SS operators. And no such tests were ever conducted. Another indication of the lack of testing during this over-ten-year period, is the fact that no reports of any such testing has ever been published in magazines of general amateur circulation. I am unaware of any reports published even in specialty periodicals. So, claims that SS will not affect current amateur operation are completely unsubstantiated. Maybe it won't and maybe it will. But, nothing has been proven one way or the other. Contained within the Commission's NPRM is an indication that some apparently informed people believe that SS does represent a threat, even to other SS operation. The NPRM notes that Metricom has urged the Commission to limit amateur SS power in the 900 MHz and 2400 MHz bands to the same levels presently authorized for them and other Part 15 users. While I believe that the Commission should reject any such proposal (an unlicensed service claiming that a licensed service should be limited to the same power restrictions as they), I believe the Metricom statement does indicate that SS may not be as immune to interference, or as unlikely to cause interference, as claimed by the SS advocates. Automatic Power Control The Commission's proposed rule making includes a provision for automatic power control for SS stations running more than 1 Watt. While I support the apparent intent of the proposed rule, to minimize the impact of SS on other types of operation, I contend that automatic power control will not work in the Amateur Service or the Amateur-satellite Service. In fact, I believe that it is prima facie evidence that, even the Commission, believes that SS operation poses an interference threat to other modes. I further contend that requiring the use of automatic power control will have minimal effect on the impact of SS on other modes. As part of my rationale for concluding that automatic power control is unworkable, I cite the comments of several SS proponents. .(4), (5), (6) I believe that there are two principal problems with automatic power control. It may be applicable to terrestrial point-to-point (one-on-one)scenarios, such as encountered in cellular telephony. In this mode the two stations may be able to exchange information on their signal levels and enable the adjustment of transmitter power to achieve acceptable levels. In digital SS systems such as are apparently being envisioned for Amateur Radio, a particular value of Eb/N0 would be established and power regulated to achieve it. But, if the communication is from one station to a number of listening stations ("bulletin mode"),as is often the case in amateur communication, rather than one-on-one, this scheme breaks down no matter how it is implimented. Even in the "one-on-one situation, mandating automatic power control requires a higher degree of equipment standardization than is typical of amateurs. It may even require that all stations participating in the power adjustment process to have equipment from a single manufacturer. Automatic power control also has two obvious problems when used through amateur satellites: 1. Satellite signals often fade, fairly rapidly over quite wide margins due to satellite attitude changes and/or ionospheric effects. At least for high altitude satellites, the delay time between stations can be on the order of 1/4 second. Thus, information on power adjustment may take that long to reach the other station and be acted upon. With fading, this time delay may be enough to render the power control "loop" unstable. (It will always be "hunting" for the appropriate power level, and end up calling for more power when less is required and less when more is needed.) 2. In amateur satellite work, it is good practice for the various users to listen to the satellite downlink signals prior to transmitting. With automatic power control, some participants may not have stations as well equipped as others. A station, not so well equipped, may not be able to hear many signals if the powers of many of the stations operating have been adjusted down to communicate with better equipped stations. The not so-well-equipped stations may be new people just getting started in amateur satellites. The chances of them becoming discouraged when they encounter little activity, is quite high. In addition the specific problems associated with amateur satellite operation, I contend that mandating automatic power control is inconsistent with the objective of making amateur SS rules as flexible as possible. In fact, any such requirement seems to represent the height of inflexibility. It is interesting to note that many of the proponents of SS have made a similar comment. One such comment, already noted, was made by the Navy Post Graduate School. A Proposed Approach for Peaceful Development of SS in the Amateur Service How can the development of SS techniques be encouraged and still prevent potential serious harm being caused to existing modes and the inevitable bad feelings that can result from such harm? I contend that the solution to this dilemma lies in the establishment, in any Rules which the Commission may invoke, of provisions proscribing certain frequency segments for SS operation. In addition, in order to take advantage of the potential capability of SS techniques for long-haul weak signal work, I propose that a narrow band version of SS be defined and authorized. I believe that it should be able to be used more generally throughout the spectrum than the "wideband" version apparently be proposed in the NPRM. Two Kinds of SS The case for the potential utility of a narrowband version of SS was made in a paper presented at the Central States VHF Conference held in Minneapolis in July 1996. Tom Clark W3IWI and Phil Karn KA9Q outlined a possible use of SS techniques for enhancing weak signal communication such as Earth-Moon-Earth or long haul terrestrial. Their presentation convinced me that this application of SS should be accommodated in any new rules which the Commission may adopt. I feel that accomplish this, while not allowing SS operation to materially impact other operation, the Commission should define two types of SS. One type might be called "Broad Band" and the other "Narrow Band". From what I understand, it is the "Broad Band" type of SS that is proposed by those advocating liberalization of SS rules and that the Commission is addressing in this proceeding. Its bandwidth is generally undefined but is certainly wider than conventional modes such as voice FM, AM and SSB. As noted, the "Narrow Band" type of SS might be potentially be very beneficial to weak signal modes, including work through amateur satellites and Earth-Moon-Earth (EME). MY Proposal In light of the above, I propose that a "Narrow Band" version of SS be authorized on all of the bands above 50 MHz so long as the bandwidth of the transmitted signal does not exceed that already authorized on these bands. In my opinion, it should also be permitted for use as satellite downlinks in the 10 meter band. . I further propose that the "Broad Band" version of SS should be authorized only in the following segments: 219 - 220 MHz 435 - 438 MHz* 902 - 928 MHz 1240 - 1290 MHz** 2390 - 2450 MHz All Amateur frequencies above 3300 MHz * In the segment 435 -438 MHz, SS emissions should be confined to that 3 MHz segment and, except for short tests to confirm proper operation of equipment, should only be for the purpose of working through amateur satellites. ** In the segment 1260 - 1270 MHz all SS emissions, except for short tests to confirm proper operation of equipment, should only be for the purpose of working through amateur satellites. While there is weak signal experimentation occurring around 3456 MHz, 5760 MHz, 10368 MHz and at specific frequencies in the higher microwave bands, I have become convinced that amateur SS operation poses little threat to these activities. The principal reason for reaching this conclusion, is the power levels that might be expected to be used in these bands and the effect antenna directivity that is characteristically involved, will materially reduce the probability of interference between SS and other modes. Conclusion I believe that SS operation should be encouraged. I further believe that it may well eventually prove valuable for both terrestrial, amateur satellite and EME work. However, I contend that terrestrial SS operation should not be allowed to interfere with existing amateur and amateur satellite operation. I contend that this is consistent with existing Commission policy in the Amateur Service, and cite, as examples, the fact that voice operation has been limited to certain segments in the HF and VHF amateur bands for many years. In addition, unattended digital operation is restricted to certain small segments of the HF bands and Unattended Beacon Operation is allowed only in small segments of the 10 meter, 6 meter, 2 meter, 1-1/4 meter and 70 cm bands. I recommend that the Commission incorporate these suggestions in formulating new rules designed to foster widespread use of SS among amateur radio operators. I further recommend that the Commission place no greater restrictions on SS use, such as station identification and authorized spreading codes, than it feels is absolutely necessary, and that automatic power control not be required. I contend that such a course will foster growth of SS among amateurs, including those using it in connection with extended range weak signal communication as well as through amateur satellites. In addition I propose that the Commission authorize two types of SS. One that could be termed "Narrow Band" would be authorized anywhere above 50 MHz, as well as a downlink in the 10 Meter Amateur-satellite Service allocation; as long as the transmitted bandwidth does not exceed that already authorized in the particular segment. The other, that could be called "Broad Band", would be authorized anywhere in the segments listed above, with the limitations stated. I believe that this course will allow amateurs to develop SS technology and continue in their historic pursuit of all new technologies as well as their march to higher and higher frequencies. At the same time other valuable amateur operation will be preserved.. RESPECTFULLY SUBMITTED, By_______________________ William A. Tynan W3XO May __, 1997 Mailing Address: HCR5 Box 574-336 Kerrville, TX 78028 E-Mail: biltynan@ktc.com Notes: 1. Reply Comments of Charles M. (Marty) Albert Jr. KC6UFM Paragraph entitled "Additional General Comments. Mr. Albert says in part "Using the 10 millisecond dwell time cited by Buaas, this means that you will miss only ONE-FIFTH of ONE WORD sent. If we assume that the voice transmission lasts 5 minutes and the SS makes a "hit" as often possible...." 2. Reply Comments of Robert A. Buaas, K6KGS 20271 Bancroft Circle Huntington Beach, CA 92646. Mr. Buaas postulates a the following scenario: (His paragraph numbers are included for ease of reference.) (3a)"Use Voice modulation type F3E(conventional NBFM): (3b) Use only Frequency Hopping of the carrier frequency to accomplish the SS function: (3c) Operate within the 450 MHZ repeater spectrum and conventions: receive within the 5 MHZ allocated for repeater receivers and transmit within the 5 MHZ allocated for repeater transmitters: use carrier frequencies aligned with those of current repeaters: this provides 200 discrete receiver and transmitter operating frequencies, each of width 25 Khz (Choosing 20 Khz bandwidths provides an additional 50 hopping channels: this my eventually be operationally desirable, but for the purpose of this model it only complicates the arithmetic for interference assessment. It does not significantly alter the impact of or nature of signal collision): (3d) Dwell on each channel for exactly 10 milliseconds, then hop: (3e) Choose a hopping function which: (3e1) uses every available channel before any reuse. We will call the total time required to use all the channels the "period" of the hopping function (taking (3c) and (3d) together, it is 200- milliseconds) and, (3e2) during one period, selects channels for each use such that the time since the same channels use in the previous period is statistically random: ......." "With the system parameters give above, interference impact evaluation is very straightforward. Parameter 3d is chosen so that SS activity does not activate the noise squelch of NBFM receivers. When the FHSS arrives on an active repeater channel, FM capture rules apply. In the case where the SS station captures the other user, the capture lasts 10 milliseconds in 2000, or for 0.5% of the transmission. This impact is so slight as to be neglected in real operations." 3. AMSAT said in its Reply Comments, "To obtain a measure of the possible interference that could result from only a single spread spectrum station, the following parameters are assumed: Spread spectrum station with an effective power of 100 W ERP = +20 dBW (The power specified in the Docket) If spread over 10 MHZ -50 dBW/Hz Free-space attenuation at 20 km from the spread spectrum station at 432 MHZ = -110 dB Spread spectrum signal at 20 km = -160 dBW/Hz A receiver with a 1 dB NF (common in satellite & weak signal work) = -210 dBW/Hz So the spread spectrum signal could be as much as 50 dB above the noise floor that would exist without it. One can use these calculations to cite other scenarios: For example, if the spread spectrum station had a power of only 1 W ERP, this is 20 dB less, yet the noise floor would still be as much as 30 dB higher because of its presence. Similar calculations for other distances can also be done. For example, the spread spectrum signal would be 20 dB stronger at a 2 km distance. As another example, a 100 W transmitter and 10 dB gain antenna could create 10 dB more interference. Obviously, if the spread spectrum station is in close proximity to the satellite or terrestrial weak signal station, the degradation from the spread spectrum station's operation would be much greater." 4. Reply Comments submitted by the Naval Post Graduate School state in part: "NPS does not agree with the changes proposed to 97.311(g) requiring the addition of "automatic transmitter power control." This is clearly counter to making the spread spectrum mode of communication more flexible and is itself superfluous as noted by Mr. Buaas' reference to 97.313(a). The technical hurdles implied by this rule change are not trivial: and as pertains to space-based stations in particular, would pose an unnecessary burden on the design of the space segment of the communications link." 5. In his Reply Comments, Mr. Charles M. (Marty) Albert, K6UFM, states: "Again, this requirement [automatic power control] that (1) Would be nearly impossible to implement, (2) Would be totally impossible to enforce (3) Would be clearly discriminatory to SS and (4) Serve no clear purpose." 6. In its Comments, TAPR says in part: "Third, TAPR supports the ARRL's proposed change to 97.311(g) which would provide for automatic power control to limit the output power of and SS station to that which is required for communication, when more than one watt of output power is used. TAPR, however differs with ARRL as to just how simple to control the output power of a transmitter, it is quite another matter to make this control automatic and foolproof...." 7. In an unpublished paper presented at the 1996 Central States VHF Conference, Drs. Tomas A. Clark, W3IWI and Phillip Karn, KA9Q outlined the possibility of using SS techniques over a fairly narrow band to enhance the capability for weak signal amateur communication. - Steve, N7HPR (n7hpr@tapr.org) From aeynon@micro.ti.com Mon Apr 14 13:07:59 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 NAA12938 for ; Mon, 14 Apr 1997 13:07:57 -0500 (CDT) Received: from reliant.micro.ti.com ([158.218.63.15]) by dragon.ti.com (8.8.5) with ESMTP id NAA17262; Mon, 14 Apr 1997 13:07:22 -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 NAA29833; Mon, 14 Apr 1997 13:07:18 -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 AAA12006; Mon, 14 Apr 1997 13:07:16 -0500 Message-Id: <2.2.32.19970414180913.0069eddc@pcmail.micro.ti.com> X-Sender: aeyn@pcmail.micro.ti.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Apr 1997 13:09:13 -0500 To: fccinfo@fcc.gov From: "Alan J. Eynon" Subject: Comments on FCC Spread Spectrum Rulemaking, WT Docket No.97-12 Cc: biltynan@ktc.com, ss@tapr.org, aeyn@micro.ti.com 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 DR. ALAN J. EYNON, N3IRL Background ---------- I have been a member of the Amateur Radio service since obtaining an Advanced license in 1991. I have studied spread spectrum communications for over ten years, as a matter of both academic and professional interest. Introduction ------------ I have reviewed the Notice of Proposed Rulemaking and the comments of several individuals regarding the use of power control and band limitations to avoid interfering with existing services in the Amateur Radio bands. I believe that a simpler scheme can be proposed that - in addition to being technically easier and cheaper to implement - would be considerably more straightforward to enforce. Summary ------- I wholeheartedly support the Commission's intent to liberalize the rules governing the use of spread spectrum in the Amateur Radio service. I believe that it is the intent of the Notice of Proposed Rulemaking to accomplish any such liberalization without sacrificing the interests of the extant Amateur Radio services. To this end, the Notice contains provisions for automatic power control, while comments by other users suggest that spread spectrum services should be confined to certain frequency ranges. The former would greatly increase the technical and monetary cost of any such equipment. The latter proposal (1) is misplaced and contrary to the intent that spread spectrum signals should be able to overlay existing signals without causing them interference. I intend to show that the critical factor of any such Rulemaking should be transmitted power spectral density. By tieing the power of the transmitted spread spectrum signal to the bandwidth occupied by that signal, the Commission can satisfy existing Amateur Radio service operators that the new spread spectrum signals will not interfere with their operations. By avoiding the difficulties of implementing an automatic power control scheme, the Commission can lower the technical and monetary barrier to the use of spread spectrum technology in the Amateur Radio service. Discussion ---------- Automatic Power Control: The issue of automatic power control centers around the technical problems of creating a uniform automatic power control scheme which would be effective in all Amateur Radio service scenarios. For instance, one kind of closed loop scheme would have the spread spectrum equipment at both ends of a link would monitor the received signal power and feed that information back to the transmitter. In this way, the transmitter only uses sufficient power to maintain a pre-set bit error rate. Unfortunately, such a scheme would cause grave difficulties in operating over satellite links, as the time delays inherent in such links would tend to make the feedback loop unstable. Given unlimited additional expense, it is not out of the question that a suitably elaborate automatic power control scheme could be devised that would operate in all Amateur Radio service scenarios. However, I contend that such a burden would create an additional barrier to widespread adoption of spread spectrum techniques by Amateur Radio service operators, known for their frugality. One also must question the additional time it would take to agree on a standard for automatic power control, since requiring automatic power control without formal agreement as to how it would be implemented would only create additional dissension within the community of Amateur Radio service operators who wish to experiment with spread spectrum communications. In light of my proposal (below) to control transmitted power spectral density, I find that requirements for automatic power control are a redundant and needless expense. Spectral Partitioning: The comments by AMSAT regarding weak signal operation (2) highlight their concern that unrestricted operation of spread spectrum signals could signficantly degrade their ability to continue working in their current operational modes. Their arguments center on the expected levels of interference such overlaid signals could cause. In the spirit of co-operation that the goal of all Amateur Radio service operators, I believe I speak for all spread spectrum experimenters in stating that it is our goal that our overlaid spread spectrum signals cause no interference with existing Amateur Radio service operations. Rather than sequestering spread spectrum signals to unused portions of the Amateur bands, however, I proposed (3) that power limits can set such that no interference occurs. This will be discussed further in the following section. (1) also goes on to propose that a narrowband form of spread spectrum might be acceptable on all bands above 50 MHz. This runs contrary to the previous argument about power spectral density and likely interference; a spread spectrum signal that utilize narrower bandwidths while maintaining the same power level will necessarily create a signal with a higher power spectral density with an greater likelihood of causing interference. Again, these proposed restrictions would be unnecessary if the Commission were to regulate the power spectral density of the allowed spread spectrum signals. By restricting effective power levels based on the bandwidth of the transmitted signal, the Commission could guarantee that overlaid spread spectrum signals would not infere with established Amateur Radio service operations, without resorting to frequency apartheid. Power Spectral Density Proposal: As I showed in (3), it is possible to work backwards from the most sensitive weak signal Amateur receiver, and determine the maximum effective transmitter power that the spread spectrum operator could use without causing inteference. This would have to be calculated and set for each Amateur Radio band, as receiver characteristics for each band differ. One would also want to regulate the spectral content of the spread spectrum signals, so that their transmitted power is spread as uniformly over their spreading bandwidth. In the direct sequence case, this means that the epoch (repetition) rate of the spreading sequence be no faster than the underlying data rate. For instance, to spread a 5000 bit per second signal over a 10 megaHertz bandwidth would require a spreading sequence running at 5 megachips per second. If that spreading sequence contained less than 1000 chips, it would repeat at a rate greater than 5000 Hertz, and the spectral content of the spread signal would no longer have a smooth and continuous presentation. The resulting discrete spectral elements potentially could create a higher-than-allowable power spectral density, thus causing inteference. Similar arguments concerning the number of carriers used by a frequency hopping system can be made. One would aim for the average power spectral content of a frequency hopping system to be the same as analogous direct sequence signals. Such regulations would also have to include minimum hopping rates (or hop dwell times), in the same fashion that direct sequence systems must have a minimum length spreading sequence. Hybrid systems - if adopted - would be subject to both direct sequence and frequency hopping regulations, in a fashion such that the inclusion of direct sequence spreading of a hopped carrier would ameliorate frequency hopping spectral restrictions in proportion to the spreading factor the direct sequence spreading introduces, and vice versa. Again, the intent would be that any spread signal, no matter what technique it utilized - would have to conform to the same regulation of power spectral density and spectral uniformity. Conclusion ---------- If adopted, a per-band regulation of maxmimum allowable power spectral density has the advantages that it: * does not interfere with established Amateur Radio service oeprations, * requires no further automatic power control measures, * does not restrict operation within the Amateur Radio service bands above HF, * eliminates cumbersome differentiation between different types of spread signals, * is easier to enforce, * would be less expensive to the Amateur community, hence potentially appealing to a larger group of experimenters. RESPECTFULLY SUBMITTED, By_______________________ Alan J. Eynon, N3IRL May 14, 1997 Mailing Address: 5228 Woodlawn Bellaire, TX 77401-3305 E-Mail: aeynon@micro.ti.com Notes: 1. "COMMENTS OF WILLIAM A. TYNAN W3XO / In the Matter of WT Docket No.97-12", as received via e-mail on 14 May 1997. 2. "Comments on the Spread Spectrum Proceedings by Bill Tynon W3XO / In the Matter of RM-8737", as received via e-mail on 10 May 1996. 3. To quote my e-mail of 13 May 1996: "I won't argue with Bill's numbers, but I don't believe their application corresponds to how those of us who design spread systems actually intend to use them. In short, I don't think his receiver's going to see us. Here's why: I prefer to work backwards from Bill's numbers. Let's assume that I, too, have a receiver with a noise floor of -210 dBW/Hz over a 10 MHz reception bandwidth. Let's assume the main lobe of my spread signal fills the 10 MHz. That's a 5 Mchip/sec signal. So far, this is straight from what Bill said. I'm going to assume that I can get 30 dB processing gain from that 5 Mchip/sec signal, so I'm either operating at 5 kbps BPSK, or 10 kbps QPSK. I can normally demodulate a BPSK signal and get a decent bit error rate at an output (despread) SNR of 15 dB. This gives me a processing margin of 15 dB (30 - 15). In other words, my signal can be 15 dB *below* the noise floor of my receiver, and I'll still get enough despread SNR for good BER performance. That's a received signal of -225 dBW/Hz. Assuming the same path loss at 20 km (-110 dB), that means my transmitter power density is -115 dBW/Hz. The signal is spread over 10 MHz (70 dBHz), so my transmitter EIRP must be -45 dBW, or about 32 uW. If I've done the math right, *that's* where I'd be operating, at a level that won't even break the noise floor of Bill's receiver. In fact, that 15 dB processing margin equates to a factor of roughly 30 in signal power, and since signal power is inversely related to the square of the distance, his station can be over 5 times closer (no more than 4 km away), and my spread signal still won't interfere with his receiver. Alternately, there could be 30 of us on the same 10 MHz band, all 20 km from Bill, and he won't detect our presence. Even in the Balt/Wash area, I can't imagine there'll be enough hams doing SS to cause grief. Rather than allocating discrete portions of spectrum for spread operations, wouldn't it be better to open all bands above HF to SS, but as a secondary user on a not-to-interfere basis? Certainly the FCC could set power levels, spreading rates, and suitably long sequences (to provide adequate spectral content for the signal, viz: it wouldn't make sense to use a 15 chip spreading sequence at 5 Mchip/sec, since the spread carrier tones would then be 333 kHz apart) to satisfy even the most discriminating EME and weak signal enthusiasts. And this would also give them access to all the bands, instead of (potentially) blocking portions with needlessly powerful SS transmissions. I encourage further discussion on how both user communities can share the entire spectrum." From crlbyer@garlic.com Mon Apr 14 14:47:52 1997 Received: from garlic.com (root@garlic.com [165.227.35.130]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA18966 for ; Mon, 14 Apr 1997 14:47:49 -0500 (CDT) Received: from met-122.arc.nasa.gov by garlic.com (8.8.5/4.03) id TAA226880; Mon, 14 Apr 1997 19:47:39 GMT Message-ID: <33528950.77A4@garlic.com> Date: Mon, 14 Apr 1997 12:45:20 -0700 From: Carol Byers Reply-To: crlbyers@garlic.com Organization: no1nos X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1255] Re: Software for calculate microwave/RF links References: <2.2.16.19970209054810.2ad79aca@sss-mag.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Randy Roberts wrote: > > Dear Kleber & other SS SIG'ers: > > There is a lot of this sort of shareware available on my home page(s) -- > take a look at: > > http://sss-mag.com/prop.html > http://sss-mag.com/swindex.html > http://sss-mag.com/eestuff.html > and finally http://sss-mag.com/rfstuff.html > > Enjoy the downloads & feel free to explore our site with nearly 200 pages of > useful html info on RF, SS and electronic engineering / Ham stuff! > > 73 de KC6YJY, Randy Roberts > > -------------------------------------------------------------------------------- > > At 01:57 AM 4/9/97 -0500, you wrote: > >Hello... > > > > Where i acquire softwares (shareware or not) in the Internet for > >calculate radio links ? > > Thank's a lot !!! > > > > Hi Randy, Thanks for the great reference sources... Carol From fkaprocki@iag.net Wed Apr 16 13:39:46 1997 Received: from mailhub.iag.net (www2.iag.net [204.27.210.7]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id NAA21176 for ; Wed, 16 Apr 1997 13:39:45 -0500 (CDT) Received: from iag.net (root@shell.iag.net [204.27.210.69]) by mailhub.iag.net (8.8.5/8.8.5) with ESMTP id OAA25837 for ; Wed, 16 Apr 1997 14:47:01 -0400 (EDT) Received: from kaprocki.iag.net (d048.orcy.fl.iag.net [205.245.32.48]) by iag.net (8.8.5/8.8.5) with SMTP id OAA19243 for ; Wed, 16 Apr 1997 14:37:53 -0400 (EDT) Message-Id: <1.5.4.32.19970415204116.006684b4@iag.net> X-Sender: fkaprocki@iag.net (Unverified) X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Apr 1997 16:41:16 -0400 To: ss@tapr.org From: Kaprocki Subject: address change Please change my e-mail address OLD kaprocki@iag.net NEW fkaprocki @iag.net thanks. kk4rw. From jeff@mich.com Fri Apr 18 00:41:11 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 AAA08757 for ; Fri, 18 Apr 1997 00:41:09 -0500 (CDT) Received: from alfalfa.mich.com (alfalfa.mich.com [198.108.18.18]) by server1.mich.com (8.8.4/8.8.4) with SMTP id BAA21091 for ; Fri, 18 Apr 1997 01:41:58 -0400 Message-Id: <2.2.32.19970418053949.0097a4ac@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, 18 Apr 1997 01:39:49 -0400 To: ss@tapr.org From: Jeff King Subject: FAQ on Wavelan board for LINUX? Anyone point me to a FAQ on the WaveLan board under linux? Got the source for linux kernal in which wavelan support is compiled, but still have alot of questions. Anyone have any idea if the wavelan uses a native transport layer or does it just depend on IP for this? I have a lossy link using one of the WaveLan's and thought this might be missing. Thanks ahead of time. 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 Fri Apr 18 00:44: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 AAA09752 for ; Fri, 18 Apr 1997 00:44:32 -0500 (CDT) Received: from alfalfa.mich.com (alfalfa.mich.com [198.108.18.18]) by server1.mich.com (8.8.4/8.8.4) with SMTP id BAA21646 for ; Fri, 18 Apr 1997 01:45:40 -0400 Message-Id: <2.2.32.19970418054331.0070c2b4@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, 18 Apr 1997 01:43:31 -0400 To: ss@tapr.org From: Jeff King Subject: FAQ on Wavelan board for LINUX? Anyone point me to a FAQ on the WaveLan board under linux? Got the source for linux kernal in which wavelan support is compiled, but still have alot of questions. Anyone have any idea if the wavelan uses a native transport layer or does it just depend on IP for this? I have a lossy link using one of the WaveLan's and thought this might be missing. Thanks ahead of time. 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 fred@astro.wnmu.edu Fri Apr 18 03:46:08 1997 Received: from a202.wnmu.edu (a202.wnmu.edu [198.59.153.202]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id DAA02785 for ; Fri, 18 Apr 1997 03:45:58 -0500 (CDT) Received: (from fred@localhost) by a202.wnmu.edu (8.7.1/8.6.9) id NAA00916 for ss@tapr.org; Wed, 16 Apr 1997 13:55:58 -0600 From: Fred Treasure Message-Id: <199704161955.NAA00916@a202.wnmu.edu> Subject: Re: [SS:1266] FAQ on Wavelan board for LINUX? To: ss@tapr.org Date: Wed, 16 Apr 1997 13:55:58 -0600 (MDT) In-Reply-To: <2.2.32.19970418054331.0070c2b4@mail.mich.com> from "Jeff King" at Apr 18, 97 00:45:51 am Content-Type: text > > Anyone point me to a FAQ on the WaveLan board under > linux? Got the source for linux kernal in which wavelan > support is compiled, but still have alot of questions. > Anyone have any idea if the wavelan uses a native transport > layer or does it just depend on IP for this? I have a > lossy link using one of the WaveLan's and thought this > might be missing. > Jeff, I've got some WaveLan links working with Linux. The cards act like regular Ethernet cards - they don't seem to have any special features that would help out with a bad path. I know that some of the other SS choices like the FreeWave radios and older Proxim radios have internal options that enhance their performance when operated in point-to-point links, but WaveLans don't. Fred fred@astro.wnmu.edu From karn@qualcomm.com Fri Apr 18 03:48: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 DAA03149 for ; Fri, 18 Apr 1997 03:48:48 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id BAA08748; Fri, 18 Apr 1997 01:48:17 -0700 (PDT) Date: Fri, 18 Apr 1997 01:48:17 -0700 (PDT) From: Phil Karn Message-Id: <199704180848.BAA08748@servo.qualcomm.com> To: ss@tapr.org In-reply-to: <2.2.32.19970418053949.0097a4ac@mail.mich.com> (message from Jeff King on Fri, 18 Apr 1997 00:42:41 -0500 (CDT)) Subject: Re: [SS:1265] FAQ on Wavelan board for LINUX? Last week at the Memphis IETF I had the opportunity to borrow a Digital Roam About PCMCIA card for my Linux laptop. I'm told this is a clone of a Wavelan. >From what I can see, the link layer in Wavelan is identical to Ethernet with the addition of a 16-bit network ID. If this field is in use, it's stamped on all outbound packets and the receiver only responds to packets with the right network ID. That lets separate networks overlap somewhat in coverage without causing too much confusion. Without a "roaming driver" I had to select one of four base stations by hand, and since the user-level command to do this seemed to be missing I had to do it by loading one of four driver kernel modules with the network IDs hard-coded in. If anybody comes across any of this software for Linux I'd really appreciate it... Phil From bad@uhf.wireless.net Fri Apr 18 07:49:51 1997 Received: from uhf.wdc.net (uhf.radiant.net [206.186.235.44]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id HAA24650 for ; Fri, 18 Apr 1997 07:49:36 -0500 (CDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id IAA06670 for ; Fri, 18 Apr 1997 08:50:13 -0400 (EDT) Date: Fri, 18 Apr 1997 08:50:08 -0400 (EDT) From: Bernie Doehner To: ss@tapr.org Subject: Re: [SS:1268] Re: FAQ on Wavelan board for LINUX? In-Reply-To: <199704180848.BAA08748@servo.qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Without a "roaming driver" I had to select one of four base stations > by hand, and since the user-level command to do this seemed to be > missing I had to do it by loading one of four driver kernel modules "Roaming" only works under Windows with DEC's own driver. It uses a proprietary beaconing protocol. Portland State University (under DARPA funding) wrote their own version (nicknamed "mip") which is supposed to be IETF mobile IP compliant, but this only runs under FreeBSD and uses FreeBSD's tunneling devices. Bernie From bm@lynx.ve3jf.ampr.org Fri Apr 18 14:57:10 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 OAA13501 for ; Fri, 18 Apr 1997 14:57:03 -0500 (CDT) Received: (from bm@localhost) by lynx.ve3jf.ampr.org (8.6.12/8.6.12) id TAA20499 for ss@tapr.org; Fri, 18 Apr 1997 19:56:25 GMT From: Barry McLarnon VE3JF Message-Id: <199704181956.TAA20499@lynx.ve3jf.ampr.org> Date: Fri, 18 Apr 1997 19:56:22 +0000 (GMT) To: ss@tapr.org Subject: Re: [SS:1268] Re: FAQ on Wavelan board for LINUX? In-Reply-To: <199704180848.BAA08748@servo.qualcomm.com> X-Mailer: Ishmail 1.3.1-961106-linux MIME-Version: 1.0 Content-Type: text/plain Phil Karn wrote: > Last week at the Memphis IETF I had the opportunity to borrow a Digital > Roam About PCMCIA card for my Linux laptop. I'm told this is a clone > of a Wavelan. > > From what I can see, the link layer in Wavelan is identical to > Ethernet with the addition of a 16-bit network ID. If this field is in > use, it's stamped on all outbound packets and the receiver only > responds to packets with the right network ID. That lets separate > networks overlap somewhat in coverage without causing too much > confusion. > > Without a "roaming driver" I had to select one of four base stations > by hand, and since the user-level command to do this seemed to be > missing I had to do it by loading one of four driver kernel modules > with the network IDs hard-coded in. If anybody comes across any of > this software for Linux I'd really appreciate it... Somebody at MIT was working on a driver with roaming support - check out http://www.pdos.lcs.mit.edu/~adj/wavelan.html. Looks like this effort is well behind schedule or possibly abandoned, though. With regard to the WaveLAN protocol stack, the 16-bit network ID is actually added at the PHY layer. The frame structure at the MAC layer is identical to IEEE 802.3, but of course the MAC protocol uses CSMA/CA instead of CSMA/CD. There doesn't seem to be anything implemented at the link layer to improve the integrity of the data link (to answer Jeff's question), but hey, if you're fond of kludges, you could always use AX.25. :-) No fooling, it's been done - see http://www.latnet.lv/LATNET/RADIOLink/HTMLDocument.html. 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 karn@qualcomm.com Fri Apr 18 16:40:01 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 QAA00485 for ; Fri, 18 Apr 1997 16:39:58 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id OAA10939; Fri, 18 Apr 1997 14:39:26 -0700 (PDT) Date: Fri, 18 Apr 1997 14:39:26 -0700 (PDT) Message-Id: <199704182139.OAA10939@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: (message from Bernie Doehner on Fri, 18 Apr 1997 07:55:36 -0500 (CDT)) Subject: Re: [SS:1269] Re: FAQ on Wavelan board for LINUX? Many of the Roam About users at IETF last week were running FreeBSD and had a roaming driver specifically for FreeBSD that seemed to work pretty well. I think they got it from Steve Stuart at DEC. Once I figured out what the network ID field was and how it was used, I created four versions of the wavelan_cs.o kernel module, one with each of the four network IDs in use. Then I'd load the appropriate module depending on where I was in the hotel (I had the base stations mapped out). Crude and tedious, but effective. Phil From clearbrook_technical@mindlink.bc.ca Fri Apr 18 18:43:11 1997 Received: from linux.clrtech.com. (t7-15.van.hookup.net [207.102.131.115]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id SAA16324 for ; Fri, 18 Apr 1997 18:43:07 -0500 (CDT) Received: from fk-shop.clrtech.com (fk-shop.clrtech.com [172.17.20.101]) by linux.clrtech.com. (8.6.9/8.6.9) with SMTP id PAA05406 for ; Fri, 18 Apr 1997 15:41:10 -0700 Date: Fri, 18 Apr 1997 15:41:10 -0700 Message-Id: <199704182241.PAA05406@linux.clrtech.com.> X-Sender: clearbrook_technical@linux.clrtech.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: Fred Kehler Subject: Re: [SS:1268] Re: FAQ on Wavelan board for LINUX? Hi Phil, in place of the 'roaming driver' i've been using the 'Wireless extensions' for linux. The iwconfig command lets you change the network ID on the fly and also move the freq in the case of 2.4Ghz cards a handy feature of iwconfig also lets you set the network ID function to 'off' which makes all the wavelan traffic seen by the card visble with tcpdump.... At 03:53 AM 18/04/97 -0500, you wrote: >Last week at the Memphis IETF I had the opportunity to borrow a Digital >Roam About PCMCIA card for my Linux laptop. I'm told this is a clone >of a Wavelan. > >>From what I can see, the link layer in Wavelan is identical to >Ethernet with the addition of a 16-bit network ID. If this field is in >use, it's stamped on all outbound packets and the receiver only >responds to packets with the right network ID. That lets separate >networks overlap somewhat in coverage without causing too much >confusion. > >Without a "roaming driver" I had to select one of four base stations >by hand, and since the user-level command to do this seemed to be >missing I had to do it by loading one of four driver kernel modules >with the network IDs hard-coded in. If anybody comes across any of >this software for Linux I'd really appreciate it... > >Phil > > > > > > > Fred Kehler (ve7ipb) Clearbrook Technical Services Ltd. clearbrook_technical@mindlink.bc.ca. From bad@uhf.wireless.net Fri Apr 18 20:08:35 1997 Received: from uhf.wdc.net (uhf.radiant.net [206.186.235.44]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA08379 for ; Fri, 18 Apr 1997 20:08:29 -0500 (CDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id VAA09552 for ; Fri, 18 Apr 1997 21:09:48 -0400 (EDT) Date: Fri, 18 Apr 1997 21:09:40 -0400 (EDT) From: Bernie Doehner To: ss@tapr.org Subject: Re: [SS:1272] Re: FAQ on Wavelan board for LINUX? In-Reply-To: <199704182241.PAA05406@linux.clrtech.com.> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Hi Phil, > in place of the 'roaming driver' i've been using the 'Wireless extensions' > for linux. The iwconfig command lets you change the network ID on the fly > and also move the freq in the case of 2.4Ghz cards > a handy feature of iwconfig also lets you set the network ID function to > 'off' which makes all the wavelan traffic seen by the card visble with > tcpdump.... Where might I be able to find the source code to iwconfig? Thanks. Bernie From jerryn@ici.net Fri Apr 18 21:20:23 1997 Received: from uhura.ici.net (uhura.ici.net [204.97.252.6]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id VAA26657 for ; Fri, 18 Apr 1997 21:20:21 -0500 (CDT) Received: from nomad (d-ma-fallriver-114.ici.net [207.180.10.123]) by uhura.ici.net (8.8.4/8.8.4) with SMTP id WAA22032 for ; Fri, 18 Apr 1997 22:23:42 -0400 (EDT) Sender: root@uhura.ici.net Message-ID: <33582BAB.58658998@ici.net> Date: Fri, 18 Apr 1997 22:19:23 -0400 From: Jerry Normandin X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.26 i686) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1273] Re: FAQ on Wavelan board for LINUX? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit At any sunsite mirror. I have been using this code for over a year and shared my thoughts about it on this newsgroup. BUT>>>>> Most people here rejected the idea of using a PC and Linux for Wireless Internet Access. Well..........I have 6 nodes running now that are wireless and customers can access the net at speeds of 2MBS by wireless with no airtime charge. All they do is pay for the internet access. Airtime of course is FREE. It's far better and cheaper than accessing the net through baby bells. Linux Rules that's for sure. I've been testing the new wireless router code from MIT with these babys. > > > Hi Phil, > > in place of the 'roaming driver' i've been using the 'Wireless extensions' > > for linux. The iwconfig command lets you change the network ID on the fly > > and also move the freq in the case of 2.4Ghz cards > > a handy feature of iwconfig also lets you set the network ID function to > > 'off' which makes all the wavelan traffic seen by the card visble with > > tcpdump.... > > Where might I be able to find the source code to iwconfig? > > Thanks. > > Bernie From bm@lynx.ve3jf.ampr.org Sat Apr 19 12:53:08 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 MAA21145 for ; Sat, 19 Apr 1997 12:53:04 -0500 (CDT) Received: (from bm@localhost) by lynx.ve3jf.ampr.org (8.6.12/8.6.12) id RAA22228 for ss@tapr.org; Sat, 19 Apr 1997 17:52:42 GMT From: Barry McLarnon VE3JF Message-Id: <199704191752.RAA22228@lynx.ve3jf.ampr.org> Date: Sat, 19 Apr 1997 17:52:42 +0000 (GMT) To: ss@tapr.org Subject: Re: FAQ on Wavelan board for LINUX? In-Reply-To: <199704191719.MAA10744@dns.okc> X-Mailer: Ishmail 1.3.1-961106-linux MIME-Version: 1.0 Content-Type: text/plain This was bounced by the listserver. If you quote a previous message, you must make sure that the quoted text does not contain a Message-Id: header (or at least that the quoted text is delineated by ">" characters or some such). Otherwise, the listserver will reject your message as a duplicate. -Barry ss@tapr.org wrote: > A message with Message-Id: <33582BAB.58658998@ICI.NET> (appearing > in the body) matches entries in the list's .message.ids file. > > The message is included below: > ----------------------------------------------------------------------------- > From ssampson@oklahoma.net Sat Apr 19 12:15:08 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 MAA11568 for ; Sat, 19 Apr 1997 > 12:15:05 -0500 (CDT) > Received: from chalice.site.net by dns.okc (SMI-8.6/SMI-SVR4) > id MAA10744; Sat, 19 Apr 1997 12:19:58 -0500 > Message-Id: <199704191719.MAA10744@dns.okc> > From: "Steve Sampson" > To: > Subject: Re: [SS:1274] SS digest 295 > Date: Sat, 19 Apr 1997 12:10:31 -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 have 6 users on 1 node. > Does that mean I get a gold star to your silver? :-) > > Seriously though, I don't understand why it takes 6 nodes?? > Do you have your antennas pointing in 6 different directions?? > Or, do you have 6 nodes in various parts of town all tied > together via telco or another radio? > > Steve > ------------------------------ > > Date: Fri, 18 Apr 1997 22:19:23 -0400 > From: Jerry Normandin > To: ss@tapr.org > Subject: Re: FAQ on Wavelan board for LINUX? > Message-ID: <33582BAB.58658998@ici.net> > > I have 6 nodes running now that are wireless and customers > can access the net at speeds of 2MBS by wireless with no airtime charge. From jeff@mich.com Sat Apr 19 18:16:40 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 SAA07293 for ; Sat, 19 Apr 1997 18:16:39 -0500 (CDT) Received: from alfalfa.mich.com (alfalfa.mich.com [198.108.18.18]) by server1.mich.com (8.8.4/8.8.4) with SMTP id TAA08102; Sat, 19 Apr 1997 19:17:29 -0400 Message-Id: <2.2.32.19970419231542.00707f28@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, 19 Apr 1997 19:15:42 -0400 To: ss@tapr.org, jerryn@ici.net From: Jeff King Subject: Re: [SS:1274] Re: FAQ on Wavelan board for LINUX? At 09:23 PM 4/18/97 -0500, Jerry Normandin wrote: >At any sunsite mirror. I have been using this code for over a >year and shared my thoughts about it on this newsgroup. BUT>>>>> >Most people here rejected the idea of using a PC and Linux for >Wireless Internet Access. Your kidding, right? A significant number of people (myself included) are using one form of SS or another for wireless internet access. Not sure how you came up with the idea anyone here was rejecting wireless internet access... possibly your confusing this group with BBSSIG or something. >Well..........I have 6 nodes running now >that are wireless and customers can access the net at speeds of 2MBS >by wireless with no airtime charge. Best throughput I've gotten with the Linux WaveLan driver has been 75kbytes/sec. Generally it averages around 50-55kbytes/sec. This is with the 900mhz version of the WaveLan (ISA) into a 10dbi corner reflector. I'd be interested in hearing some more detailed information as to your setup as well as your experinces with the MIT code. 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 Sat Apr 19 18:22: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 SAA08994 for ; Sat, 19 Apr 1997 18:22:24 -0500 (CDT) Received: from alfalfa.mich.com (alfalfa.mich.com [198.108.18.18]) by server1.mich.com (8.8.4/8.8.4) with SMTP id TAA08557; Sat, 19 Apr 1997 19:23:15 -0400 Message-Id: <2.2.32.19970419232127.00706cf8@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, 19 Apr 1997 19:21:27 -0400 To: ss@tapr.org, bm@lynx.ve3jf.ampr.org From: Jeff King Subject: Re: [SS:1270] Re: FAQ on Wavelan board for LINUX? At 03:01 PM 4/18/97 -0500, Barry McLarnon VE3JF wrote: > >With regard to the WaveLAN protocol stack, the 16-bit network ID is actually >added at the PHY layer. The frame structure at the MAC layer is identical to >IEEE 802.3, but of course the MAC protocol uses CSMA/CA instead of CSMA/CD. There >doesn't seem to be anything implemented at the link layer to improve the >integrity of the data link (to answer Jeff's question), but hey, if you're fond >of kludges, you could always use AX.25. :-) No fooling, it's been done - see >http://www.latnet.lv/LATNET/RADIOLink/HTMLDocument.html. > >Barry Thanks Barry. Trying to run appletalk over a WaveLan link, and it seems to need som sort of underlying link layer. 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 bad@uhf.wireless.net Sun Apr 20 10:04:38 1997 Received: from uhf.wdc.net (uhf.wdc.net [198.147.74.44]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id KAA22461 for ; Sun, 20 Apr 1997 10:04:33 -0500 (CDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id LAA17494 for ; Sun, 20 Apr 1997 11:07:00 -0400 (EDT) Date: Sun, 20 Apr 1997 11:06:59 -0400 (EDT) From: Bernie Doehner To: ss@tapr.org Subject: Reed Solomon source code Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Gang: I know there are some coding experts among you (especialy Phil KA9Q). As part of a school homework I am trying to give an overview of FEC, with emphasis on convolutional coding/Viterbi decoding AND Reed Solomon coding. I understand convolutional coding and Viterbi decoding well enough to be explain it (I think), but having lots of trouble with Reed Solomon. On a different (but also a school project), I have to code both convolutional/Viterbi and Reed Solomon coding. I don't have a problem with the former, but with Reed Solomon I do (since I don't even understand it fully). One of my problems, is that none of the 10 books I have on the subject give you an algorithms (pseudocode) presentation of Reed Solomon (they all explain it over GF() and that's where they lose me. It would help me immensely, if I could get my hands on sample C code for implementing Reed Solomon or if someone could point me to a pseudo code description and could help me answer with answering some questions via private email. (None of the profs at school are FEC experts, so I have to look to outside help). THANKS! Bernie nu1s From jeff@mich.com Sun Apr 20 23:50:53 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 XAA29529 for ; Sun, 20 Apr 1997 23:50:51 -0500 (CDT) Received: from alfalfa.mich.com (alfalfa.mich.com [198.108.18.18]) by server1.mich.com (8.8.4/8.8.4) with SMTP id AAA30280; Mon, 21 Apr 1997 00:51:47 -0400 Message-Id: <2.2.32.19970421044953.006b52ec@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, 21 Apr 1997 00:49:53 -0400 To: ss@tapr.org, bm@lynx.ve3jf.ampr.org From: Jeff King Subject: Re: [SS:1270] Re: FAQ on Wavelan board for LINUX? At 03:01 PM 4/18/97 -0500, Barry McLarnon VE3JF wrote: There >doesn't seem to be anything implemented at the link layer to improve the >integrity of the data link (to answer Jeff's question), but hey, if you're fond >of kludges, you could always use AX.25. :-) No fooling, it's been done - see >http://www.latnet.lv/LATNET/RADIOLink/HTMLDocument.html. > >Barry That of course is using JNOS/DOS (the advanced case). Do you think that something like that is possible just using LINUX? Possibly with Allan Coxes ax.25 drivers.... not sure as I haven't played with them. BTW, is that really a kludge? I mean, with no link layer in the WaveLan I'm not sure adding one could be consider a kludge in the negative sense. Its certainly a kludge in the sense (in my opinion) the wavelan should have that already built in. 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 Mon Apr 21 07:33:28 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 HAA12366 for ; Mon, 21 Apr 1997 07:33:27 -0500 (CDT) Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special version 2.0) id IAA15430; Mon, 21 Apr 1997 08:33:18 -0400 Received: from ccMail by mailb.harris.com (IMA Internet Exchange 1.04b) id 35b5e480; Mon, 21 Apr 97 08:32:08 -0400 Mime-Version: 1.0 Date: Mon, 21 Apr 1997 08:32:46 -0400 Message-ID: <35b5e480@mailb.harris.com> From: RLANIER@mailb.harris.com (RLANIER) Subject: Re: [SS:1278] Reed Solomon source code To: ss@tapr.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Hi Bernie, I would really like to see what you come up with. I am very interested in FEC codes, especially appling them to an SS radio project. Let me know what you come up with! Tony KE4ATO ______________________________ Reply Separator _________________________________ Subject: [SS:1278] Reed Solomon source code Author: ss@tapr.org at smtp Date: 4/20/97 10:10 AM Hi Gang: I know there are some coding experts among you (especialy Phil KA9Q). As part of a school homework I am trying to give an overview of FEC, with emphasis on convolutional coding/Viterbi decoding AND Reed Solomon coding. I understand convolutional coding and Viterbi decoding well enough to be explain it (I think), but having lots of trouble with Reed Solomon. On a different (but also a school project), I have to code both convolutional/Viterbi and Reed Solomon coding. I don't have a problem with the former, but with Reed Solomon I do (since I don't even understand it fully). One of my problems, is that none of the 10 books I have on the subject give you an algorithms (pseudocode) presentation of Reed Solomon (they all explain it over GF() and that's where they lose me. It would help me immensely, if I could get my hands on sample C code for implementing Reed Solomon or if someone could point me to a pseudo code description and could help me answer with answering some questions via private email. (None of the profs at school are FEC experts, so I have to look to outside help). THANKS! Bernie nu1s From karn@qualcomm.com Mon Apr 21 20:00: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 UAA17071 for ; Mon, 21 Apr 1997 20:00:21 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id RAA20073; Mon, 21 Apr 1997 17:59:49 -0700 (PDT) Date: Mon, 21 Apr 1997 17:59:49 -0700 (PDT) Message-Id: <199704220059.RAA20073@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: <2.2.32.19970414180913.0069eddc@pcmail.micro.ti.com> (aeynon@micro.ti.com) Subject: Re: [SS:1262] Comments on FCC Spread Spectrum Rulemaking, WT Docket No.97-12 I am just catching up on my email (I was sick the early part of last week, and it's amazing how a thousand messages can pile up in just a few days...) Anyway, it's interesting to see the 97-12 comments claim that automatic power control won't work on satellite channels. I happen to work for a company that has bet quite a bit of money that it can. Qualcomm's Globalstar project is designed to run power-controlled CDMA over the bent-pipe satellite channel. Yes, the increased delay makes it a little harder, but working in our favor is the fact that the satellite channel propagation loss, even for a mobile terminal, is much less variable than the terrestrial channel. Even when there's intermittent blockage from terrain or foliage, the satellite channel is best modeled as a Ricean channel because the direct path dominates. The terrestrial channel, not being generally line of sight, is better modeled as a Rayleigh channel, which is much more variable. Also, since the proposed power-control rule doesn't say anything about the time interval over which the mechanism must operate, there's nothing inherent about the satellite channel that breaks automatic power control. Phil From jeff@mich.com Tue Apr 22 21:39:50 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 VAA21500 for ; Tue, 22 Apr 1997 21:39:49 -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 WAA18387 for ; Tue, 22 Apr 1997 22:40:45 -0400 Message-Id: <2.2.32.19970423023840.00730bc4@mail.mich.com> X-Sender: jeff@mail.mich.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Apr 1997 22:38:40 -0400 To: ss@tapr.org From: Jeff King Subject: Proxim RangeLan2 Hello: Anyone have any field experince with the Proxim rangelan2? How well does it compare to other 2.5ghz products in its performence class. Anyone use the Linux driver for it yet? 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 Apr 23 07:14: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 HAA15135 for ; Wed, 23 Apr 1997 07:14:48 -0500 (CDT) Received: from [204.118.182.22] by warpspeed.com with ESMTP (Eudora Internet Mail Server 1.1.2); Wed, 23 Apr 1997 05:14:46 -0700 X-Sender: dewayne@odo.warpspeed.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Apr 1997 04:57:29 -0700 To: dewayne-net@warpspeed.com (Dewayne's Wireless News List), ss@tapr.org From: Dewayne Hendricks Subject: Bell Labs Unveils 10-Megabit Wireless-Network Technology, Offering Five Times Today's Highest Data-Transmission Capacity Bell Labs Unveils 10-Megabit Wireless-Network Technology, Offering Five Times Today's Highest Data-Transmission Capacity Source: PR Newswire MURRAY HILL, N.J., April 22 /PRNewswire/ via Individual Inc. -- Bell Labs scientists have patented a new technology they call DS/PPM that makes it possible for radio- frequency-based wireless local area networks (LANs) to handle 10 megabits of information per second. That's five times as much data as today's highest- capacity wireless LANs within the bandwidth defined by the upcoming IEEE 802.11 standard. Bell Labs' parent company, Lucent Technologies (NYSE: LU), is a global leader in wireless LANs with its award-winning WaveLAN(R) product line. Current-generation wireless LANs are limited to approximately a 2-megabit (million-bit) per second transmission capacity. The patented DS/PPM (Direct Sequence/Pulse Position Modulation) technology promises robust and reliable wireless data-transmission rates of up to 10 megabits per second. This improvement in bandwidth will allow faster and more reliable wire-free computing throughout buildings and campus environments than is currently available. DS/PPM was invented at Bell Labs by researcher Rajeev Krishnamoorthy, of the Communications Sciences Research division, and Israel Bar-David, now a faculty member of the Technion in Israel. With DS/PPM, users whose need for highly data-intensive applications have kept them deskbound will be able to roam freely within a complex or campus, able to access the Internet and their company's intranet from anywhere on the grounds. Physicians will be able to call up high-resolution X-rays and medical records while next to their patients; manufacturing engineers, to download complex drawings and designs while repairing equipment; auto dealers, to show customers mini-videos on specific cars they wish to buy; emergency-service workers, to photograph and transmit situational information to health agencies immediately -- all from anywhere on their complex or campus, even from across town. Educators will be able to call up color photographs and videos from a central server location and display them on hand-held, portable and desktop computers in classrooms scattered throughout a school site. In fact, a teacher could take a class outside, gather everyone around a portable computer, and augment the curriculum with high-quality interactive, multimedia information transmitted, without wires, from a central location. In addition to the proven strengths of wireless -- flexibility and easy adaptability to locations of all types -- DS/PPM provides several other technological advantages over other wireless systems. Transmitting at the 2.4-gigahertz band, DS/PPM uses DSSS (Direct Sequence Spread Spectrum) technology to maximize resistance to noise and interference as well as ensuring reliability and robustness. DS/PPM will also allow compatibility with the new generation of IEEE 802.11-compatible wireless LANs. "This 10-megabit-per-second technology, using the existing IEEE-defined bands enables high speed within a standard-compliant environment. This is what our customers are asking us for and clearly establishes the superiority of the DSSS modulation scheme over FHSS (Frequency Hopping Spread Spectrum) technology," said Bruce Tuch, director of engineering for Lucent's WaveLAN group. "The new Bell Labs modulation scheme increases to 10 megabits per second the amount of information transmitted, without replacing the underlying DSSS technology." "To achieve the faster rates, Bell Labs researchers have combined QAM (Quadrature Amplitude Modulation) and Pulse Position Modulation," explained Rich Gitlin, Bell Labs vice president, Communications Sciences Research. "These techniques extend the proven technology base used in WaveLAN and other existing DSSS implementations." The research was done at Bell Labs' facility in Utrecht, the Netherlands, which is devoted to wireless data networking. Bell Labs is the research and development arm of Lucent Technologies, whose WaveLAN wireless local-area network product line includes -- in both 915-megahertz and 2.4-gigahertz versions -- the WaveLAN/PCMCIA system for notebook and portable computers, WaveLAN/AT interface for desktop stations, WavePOINT access point, WaveAROUND roaming software, WaveMONITOR site installation program and WaveMODEM wireless modem for OEM products. Additional information about the WaveLAN family is available on the worldwide web at http://www.wavelan.com or by calling 1-800-WAVELAN. Lucent designs, builds and delivers a wide range of public and private networks, communications systems and software, consumer and business telephone systems and microelectronics components. Further information about Lucent Technologies is available on the worldwide web at http://www.lucent.com. Comments From Industry Analysts About Bell Labs - Lucent Technologies DS/PPM Technology "This technology will have a great impact on the industry. It should greatly accelerate the adoption of wireless LANs in enterprises and business environments." -- Veronica Guerrera, DataQuest "Bell Labs has upped the ante. Ten-megabit transmission is phenomenal. It would be great for airlines, among others, with their time-critical situations and need for fast access to information." -- Tom Esperson, Yankee Group "End users and the industry alike have been waiting for solid ten-megabit technology since the beginning of wireless LANs. One of the most attractive features of DS/PPM is that it supports the bandwidth defined within the IEEE 802.11 standard, which neatly addresses the issue of interoperability." -- Virginia Brooks, Aberdeen Group "This new technology will appeal to notebook computer users who require full Ethernet performance as well as mobile access to various applications and files on a departmental LAN." -- Sonina Velasquez, Tech Research Additional Technical Information -- Bell Labs DS/PPM Technology Bell Labs design engineers have developed algorithms and signal-processing techniques that can significantly boost wireless LAN data rates up to 10-Mbps peak rates. The new wireless LAN nodes will be fully backward-compatible with IEEE products that operate at 2- or 1-Mbps rates. A DSSS transmitter operates on an incoming data stream of a certain bit rate per second. The incoming bit stream is typically converted into a symbol stream in which each symbol represents a group of 1, 2 or more bits. Modulation techniques similar to those used in voice-band data modems are used on the symbol stream to generate the transmitted signal. The DSSS transmitter modulates or multiplies each data bit or symbol with a pseudorandom noise sequence, also called a "chip" sequence. This multiplication provides the spreading phenomenon. Lucent's existing WaveLAN products, for example, use DQPSK (differential quadrature phase shift keying) modulation, and the draft IEEE 802.11 standard also specifies DQPSK. In a QPSK or DQPSK modulator, symbols are differentiated by the phase of a sinusoidal wave. Each symbol can be represented by a point in a symbol constellation plotted on a standard Cartesian graph. The so-called I (in-phase) and Q (quadrature phase) axes of the graph actually represent the cosine and sine of the phase angle, respectively. The existing DSSS scheme employs a constant symbol period, and the correlator in the receiver will locate each succeeding symbol exactly one symbol period after the preceding symbol. In operation, a DSSS receiver employs an autocorrelation function that generates a pulse one chip wide when the codeword shifted into the circuit is correlated with a filter matched to the Barker code. The pulse is centered in the symbol period. PPM essentially overlaps some symbol periods, thereby varying the time between consecutive autocorrelation peaks. The new scheme allows the detection of eight distinct pulse positions out of an 11-chip symbol. Moreover, the pulse positioning and correlation is independently implemented on the I and Q channels thereby providing the ability to convey 64 (8*8) distinct information states. When combined with the QPSK capability of two distinct I states and two distinct Q states, PPM yields 256 (64*2*2) possible states or 8 bits/symbol. Therefore, PPM applied to current DSSS technology would yield 8-Mbps peak data rates. Bell Labs intends to further extend the peak data rate by moving to QAM modulation. While QPSK maps two bits to a symbol by only varying phase, QAM can map even more bits into a symbol by varying phase and amplitude in a more complex I/Q constellation. To yield a 10-Mbps peak rate, the Bell Labs scientists adopted a QAM scheme and four distinct states for both I and Q. When combined with PPM, the scheme yields 1024 (64*4*4) possible states or 10 bits/symbol for a 10-Mbps peak rate. SOURCE Lucent Technologies /CONTACT: Donna Cunningham of Bell Labs - Lucent Technologies, 802-482-3748, home: 802-482-2933, or donnac@lucent.com; or Mark Shapiro of Davis-Marrin Communications, 619-573-0736 or dmc@cts.com/ (LU) [04-22-97 at 09:51 EDT, PR Newswire] -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 bad@uhf.wireless.net Mon Apr 28 15:33:17 1997 Received: from uhf.wdc.net (uhf.4d.net [207.137.157.140]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id PAA28666 for ; Mon, 28 Apr 1997 15:33:03 -0500 (CDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id QAA02363 for ; Mon, 28 Apr 1997 16:33:40 -0400 (EDT) Date: Mon, 28 Apr 1997 16:33:39 -0400 (EDT) From: Bernie Doehner To: ss@tapr.org Subject: Re: [SS:1280] Re: Reed Solomon source code In-Reply-To: <35b5e480@mailb.harris.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Hi Bernie, > > I would really like to see what you come up with. I am very interested > in FEC codes, especially appling them to an SS radio project. > > Let me know what you come up with! > > Tony KE4ATO Hi Tony: Sorry for taking so long to answer. I actualy found some sample code for RS (look at http://www.scotweb.com/4i2i/fec.htm), but I certainly don't understand it yet. The good news is I am finishing up my web page on convolutional coding and Viterbi decoding. At least I think I have sufficient understanding for this task. Bernie From karn@qualcomm.com Mon Apr 28 19:00:20 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 TAA19722 for ; Mon, 28 Apr 1997 19:00:16 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id QAA12362; Mon, 28 Apr 1997 16:59:43 -0700 (PDT) Date: Mon, 28 Apr 1997 16:59:43 -0700 (PDT) Message-Id: <199704282359.QAA12362@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: (message from Bernie Doehner on Mon, 28 Apr 1997 15:38:58 -0500 (CDT)) Subject: Re: [SS:1284] Re: Reed Solomon source code Anybody looking for FEC software should see my own web page: On it you will find fast C code for both a Viterbi decoder and a Reed-Solomon decoder, as well as a Fano decoder. It is free for ham radio use. Phil From bad@uhf.wireless.net Mon Apr 28 20:41:03 1997 Received: from uhf.wdc.net (uhf.wdc.net [198.147.74.44]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA26122 for ; Mon, 28 Apr 1997 20:41:00 -0500 (CDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id VAA03324 for ; Mon, 28 Apr 1997 21:41:50 -0400 (EDT) Date: Mon, 28 Apr 1997 21:41:45 -0400 (EDT) From: Bernie Doehner To: ss@tapr.org Subject: Re: [SS:1285] Re: Reed Solomon source code In-Reply-To: <199704282359.QAA12362@servo.qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Anybody looking for FEC software should see my own web page: > > > > On it you will find fast C code for both a Viterbi decoder and a > Reed-Solomon decoder, as well as a Fano decoder. It is free for ham > radio use. > > Phil > Thanks!! Why I didn't ask you earlier is beyond me! 73 Bernie From karn@qualcomm.com Mon Apr 28 22:10:28 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 WAA02161 for ; Mon, 28 Apr 1997 22:10:26 -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 UAA14475 for ; Mon, 28 Apr 1997 20:07:04 -0700 (PDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id UAA12767; Mon, 28 Apr 1997 20:05:12 -0700 (PDT) Date: Mon, 28 Apr 1997 20:05:12 -0700 (PDT) Message-Id: <199704290305.UAA12767@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org Subject: SS ID Hi Guys, A full-blown debate has erupted in my mailbox over the past full days. It started when Bill Tynan posted AMSAT's draft comments to the FCC on the SS NPRM, and I was asked for my reaction. The funny thing about AMSAT's comments is that they were identical to Tynan's personal comments (posted a week earlier) with the name simply changed. And of course Tynan has either ignored or deliberately slanted everything we've said in favor of liberalized SS operation while still claiming to be in favor of innovation. Anyway, some other, more reasonable people have brought up the narrowband ID issue. That is, they'd be more willing to accept SS if they could find an easy way to identify an interfering signal with narrowband equipment. This is a reasonable request. I don't know if we ever really discussed it here, but I am thinking along the following lines. 1. If a SS signal is too weak to cause QRM, there is no need to identify it. 2. If a SS signal is strong enough to QRM a narrowband receiver, then a narrowband ID of equal power spectral density will be copyable. 3. The absolute last thing you want is to periodically stop your SS emission and funnel full power into a narrowband CWID. Even if your SS emission didn't bother anybody, such an ID sure could! So as a goodwill gesture to the satellite and weak signal crowds I'm proposing a rule that above a certain power level (TBD) SS transmissions would have to be IDed with Morse Code at a power spectral density not to exceed that of the SS emission as a whole as measured in a 3Khz (SSB) bandwidth. The rule would allow many different implementations: unbalancing the spreading mixer of a DS system slightly to inject a weak carrier component that could be keyed on and off; injecting keyed CW tones at other RF frequencies; keying a frequency notch out of the spread signal (most easily done with fast frequency hopping by simply gating the transmitter off when it lands in the notch during a key-up interval in the CWID); keying the whole emission off and on (best for highly coded low speed emissions where the interleaver could "ride through" the keyup intervals). There are probably other methods that would work too, and all could be copied in narrowband receivers. Comments? Phil From wd5ivd@tapr.org Mon Apr 28 23:24: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 XAA06867; Mon, 28 Apr 1997 23:24:53 -0500 (CDT) Message-Id: In-Reply-To: <199704290305.UAA12767@servo.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Apr 1997 23:26:23 -0500 To: ss@tapr.org From: "Greg Jones, WD5IVD" Subject: Re: [SS:1287] SS ID Cc: " Tom Clark " >So as a goodwill gesture to the satellite and weak signal crowds I'm >proposing a rule that above a certain power level (TBD) SS >transmissions would have to be IDed with Morse Code at a power >spectral density not to exceed that of the SS emission as a whole as >measured in a 3Khz (SSB) bandwidth. >The rule would allow many different implementations: unbalancing the >spreading mixer of a DS system slightly to inject a weak carrier >component that could be keyed on and off; injecting keyed CW tones at >other RF frequencies; keying a frequency notch out of the spread >signal (most easily done with fast frequency hopping by simply gating >the transmitter off when it lands in the notch during a key-up >interval in the CWID); keying the whole emission off and on (best for >highly coded low speed emissions where the interleaver could "ride >through" the keyup intervals). There are probably other methods that >would work too, and all could be copied in narrowband receivers. > >Comments? Why does it not surprise me that Bill's comments are going to be those of AMSAT. I hope that you have some influence on the AMSAT Board before the filling, but past experience doesn't seem to indicate that much influence Bill on this subject. I sent a set of messages to Tom Clark on this issue in January which he posted to the AMSAT board. Maybe they are aware of the concern I have about the possible damage of poor rules for SS could have on future satellite SS operations. My personal comment is that I couldn't disagree with you more Phil. At best, RM-8737 and Docet 97-12 were some of the poorest written rule making I have seen from the WTB in some time. This is one reason we are having these debates on the issues that should be simple in nature. It comes down to this. Rules that the amateur community gets implemented now -- we are going to have to live with for possibly another 10+ years. Are we willing to have this IDing issue in the rules for years and years that could vastly limit people doing new designs. We need to implement rules that are open. We can't have additions to the rules for special interests within the hobby, just because they are potentially afraid of new technology. Amateur radio changes -- at least it is suppose to if the rules allows change. The things I keep seeing that could be added when we started by trying to simply delete things -- could drastically limit future growth. Maybe this is a tactic by those that just want the status quo for the next ten years when it might not matter to them who is operating. Every time a group has an concern with Spread Spectrum someone shows up with a fix that concerns power limitations. I have a license that says I can operate various power limits. I might as well start tuning up in the weak signal band with wide band amps at 1000 watts. Why don't I ? Because I know that there are other there and it wouldn't be nice. We should not limit the operations of a mode (i.e. second class citizen) all because someone is concerned about bad operating. The rules should be written to benefit those that operate correctly, not limit it because a few could operate poorly. Those are bad rules if we write them to take in account the 1% of the community instead of the 99% of the community. We have rules to handle all the various issues. Having Morse Code IDing is the most ridiculous concept I have heard of on a potentially advanced mode such as Spread Spectrum. We might as well revert back to just running 300 baud on HF. The FCC is ready to allow us the changes we are asking for. If we file comments giving into various special interests that want limitations placed on the technology, then that gives them credence for the FCC to consider during the rules process. We need to ask for all the things we want in the rule making -- in-band IDing, 50Mhz and up, no power limitations and the rest. This is amateur radio, not a commercial service, not Part 15, not anything else. We are back to adding rules to something we started out trying to simplify greatly. This doesn't make sense. Let's stick with deleting rules from Part 97 to open them up, not adding more limitations to what amateur can design and experiment with as a fun, learning, and educational experience. It is time to make Part 97 into rules that fit on a few sheets that are easy to read instead of something that requires a lawyer with a spectrum analyzer to determine if a radio is legal or not. Now on a technical issue -- what about hybrid systems or other methods that people might use ? DS is you example. If I am jumping between bands with a hybrid system -- where do I ID ? Each band hope ? On every band ? Just on the band I am at when the 10 min ID hits ? Can I ID at 300 wpm ? Again -- a simple rule that makes sense on the surface for a few modes of operations might not really fit an entire mode called Spread Spectrum. This again comes down to being something that is agreed upon when systems are being designed, not something defined in the rules. Cheers - Greg, WD5IVD ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From karn@qualcomm.com Tue Apr 29 01:37: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 BAA00266 for ; Tue, 29 Apr 1997 01:37:12 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id XAA13106; Mon, 28 Apr 1997 23:36:39 -0700 (PDT) Date: Mon, 28 Apr 1997 23:36:39 -0700 (PDT) Message-Id: <199704290636.XAA13106@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: (wd5ivd@tapr.org) Subject: Re: [SS:1288] Re: SS ID Okay Greg, you've convinced me. The rules should be as liberal as possible, and we should rely on "best current practice" to set standards for ID, etc. Automatic power control and CWIDs should probably be on the list of "best current practice". BTW, the CWID really isn't that hard to implement, and by the very nature of spread spectrum it wouldn't bother the spread signal. But I agree there could be situations where it's not totally trivial. Phil From jeff@mich.com Tue Apr 29 01:45: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 BAA00597 for ; Tue, 29 Apr 1997 01:45:31 -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 CAA28387 for ; Tue, 29 Apr 1997 02:47:00 -0400 Message-Id: <2.2.32.19970429064429.00735bfc@mail.mich.com> X-Sender: jeff@mail.mich.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Apr 1997 02:44:29 -0400 To: ss@tapr.org From: Jeff King Subject: Re: [SS:1287] SS ID At 10:12 PM 4/28/97 -0500, Phil Karn wrote: > >So as a goodwill gesture to the satellite and weak signal crowds I'm Danger Will Robinson. >Comments? > >Phil I don't make goodwill gestures unless they make technical sense. Most of amateur radio (including the ARRL) doesn't have any vision what-so- ever as to what "amateur radio" could be, just what it has been. I stopped trying to reason with these folks years ago. I'm fully convinced that any growth in amateur radio as a result of SS operations will come from outside the hobby. Not sure if this helps you but I do know you'll never make the weak signal/ repeater/10-4 folks happy. So you might as well just make the rules make sense instead of trying to please people that don't have a clue as to what the future holds. I'd fully agree with Greg on this one. We should stand firm on a reduction of restrictions on SS without regard to those that have a vested interest to keep the status quo. Then again, I'm happy to vote Libertarian year after year even though they never win. Its a decision you have to make yourself. 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 priya@students.itb.ac.id Tue Apr 29 03:40:28 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 DAA05192 for ; Tue, 29 Apr 1997 03:40:24 -0500 (CDT) Received: from localhost (priya@localhost) by students.itb.ac.id (8.8.5/8.7.3) with SMTP id PAA08594; Tue, 29 Apr 1997 15:40:27 +0700 (JVT) Date: Tue, 29 Apr 1997 15:40:27 +0700 (JVT) From: "Basuki E. Priyanto" To: Phil Karn cc: ss@tapr.org Subject: CDMA on sat In-Reply-To: <199704290636.XAA13106@servo.qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII next year i'll met with final project at my campus so i want get a topic about : multiple access CDMA on satellite communication ... actually i want to build a hardware device (prototype, transceiver , etc), i don't know what can i build or what hardware that very necessary , because i'm "a new comer" on spread spectrum . would you like to give me an advice about my final project ? can you tell me some literature to understand about CDMA , spread spectrum , etc ? thanks for everything :) *************************************** Best Regards, BASUKI E. PRIYANTO "Beat Spread Spectrum" Mail:priya@itb.ac.id *************************************** From ronen@netmanage.co.il Tue Apr 29 04:30:51 1997 Received: from nmi-gate.netmanage.co.il (root@nmi-gate.netmanage.co.il [156.27.240.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id EAA07092 for ; Tue, 29 Apr 1997 04:30:49 -0500 (CDT) Received: from ronen.netmanage.co.il (ronen.netmanage.co.il [156.27.241.36]) by nmi-gate.netmanage.co.il (8.6.9/8.6.9) with SMTP id MAA22277 for ; Tue, 29 Apr 1997 12:29:33 +0200 Date: Tue, 29 Apr 97 12:27:02 +0200 From: Ronen Pinchook Subject: Looking for Wireless Lan Info To: ss@tapr.org X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello Can someone point me for company that makes a Wireless lan (or Digital Link) For long range (About 100KM) ???? The Airlan and other SS products Are not Inough Long range for our need We look for a High Speed (1.2 MB or 2MB or better) Back Bone solution For about 100KM Range Please Advice Ronen ------------------------------------------------------ Home of Chameleon , TCP/IP applications for Windows Ronen Pinchook (4Z4ZQ) NetManage Israel, Ltd. Phone: 972-4-8550123 E-Mail: ronen@netmanage.co.il Fax: 972-4-8550122 Time sent:04/29/97 12:27:03 ------------------------------------------------------ From andre_kesteloot@juno.com Tue Apr 29 06:26:23 1997 Received: from x7.boston.juno.com (x7.boston.juno.com [205.231.100.24]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id GAA16678 for ; Tue, 29 Apr 1997 06:26:22 -0500 (CDT) Received: (from andre_kesteloot@juno.com) by x7.boston.juno.com (queuemail) id HUZ08268; Tue, 29 Apr 1997 07:25:35 EDT To: ss@tapr.org Subject: Re: SS ID Message-ID: <19970429.072501.10015.36.andre_kesteloot@juno.com> References: <2.2.32.19970429064429.00735bfc@mail.mich.com> X-Mailer: Juno 1.15 X-Juno-Line-Breaks: 0,2-6,9-11 From: andre_kesteloot@juno.com (Andre V Kesteloot) Date: Tue, 29 Apr 1997 07:25:35 EDT On Tue, 29 Apr 1997 01:50:12 -0500 (CDT) Jeff King writes: [good stuff deleted...] >>Then again, I'm happy to vote Libertarian year after year even >though they never win. Its a decision you have to make yourself. ...which brings back to mind the motto of William of Orange: "Il n'est pas necessaire d'esperer pour entreprendre, ni de reussir pour perseverer". Andre Kesteloot N4ICK. From ssampson@claven.tinker.af.mil Tue Apr 29 09:36:07 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 JAA26624 for ; Tue, 29 Apr 1997 09:36:04 -0500 (CDT) Received: from localhost by othello.tinker.af.mil (AIX 4.1/UCB 5.64/4.03) id AA17382; Tue, 29 Apr 1997 09:36:00 -0500 Sender: ssampson@othello.tinker.af.mil Message-Id: <33660750.59E2@eds.tinker.af.mil> Date: Tue, 29 Apr 1997 09:36:00 -0500 From: Steve Sampson X-Mailer: Mozilla 3.01 (X11; U; AIX 1) Mime-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1292] Looking for Wireless Lan Info References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ronen Pinchook wrote: > > Can someone point me to a company that makes a Wireless lan > (or Digital Link) for long range (About 100KM) 100 kilometers is a problem. Earth curvature and other things come into effect (antenna height, etc). What everyone uses here, is the microwave links. The two best that I can think of who use these, are the Bonneville Power Administration (Oregon) and the USAF. They use 40 mile hops on pretty significant structures. Neither have anything to do with SS, so I'll drop it here. But to get 100 kilometers, you are going to have to go the license route with higher power and structures, or you will have to have about 10 to 20 intermediate hops with unlicensed nodes. Just a guess, no facts. Steve From debgm@intouch.com Tue Apr 29 09:42:59 1997 Received: from intouch2.intouch.com ([163.121.157.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id JAA26893 for ; Tue, 29 Apr 1997 09:42:52 -0500 (CDT) From: debgm@intouch.com Received: from mail.intouch.com by intouch2.intouch.com (SMI-8.6/SMI-SVR4) id QAA07602; Tue, 29 Apr 1997 16:33:43 +0200 Date: Tue, 29 Apr 1997 16:33:43 +0200 Message-Id: <199704291433.QAA07602@intouch2.intouch.com> X-Sender: debgm@intouch.com (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org Subject: Re: [SS:1287] SS ID PLEASE NOTE GROEGER NO LONGER HERE, DELETE THIS ADDRESS DEBGM At 10:12 PM 4/28/97 -0500, you wrote: >Hi Guys, > >A full-blown debate has erupted in my mailbox over the past full days. >It started when Bill Tynan posted AMSAT's draft comments to the FCC on >the SS NPRM, and I was asked for my reaction. > >The funny thing about AMSAT's comments is that they were identical to >Tynan's personal comments (posted a week earlier) with the name simply >changed. And of course Tynan has either ignored or deliberately >slanted everything we've said in favor of liberalized SS operation >while still claiming to be in favor of innovation. > >Anyway, some other, more reasonable people have brought up the >narrowband ID issue. That is, they'd be more willing to accept SS if >they could find an easy way to identify an interfering signal with >narrowband equipment. This is a reasonable request. > >I don't know if we ever really discussed it here, but I am thinking >along the following lines. > >1. If a SS signal is too weak to cause QRM, there is no need to >identify it. > >2. If a SS signal is strong enough to QRM a narrowband receiver, then >a narrowband ID of equal power spectral density will be copyable. > >3. The absolute last thing you want is to periodically stop your SS >emission and funnel full power into a narrowband CWID. Even if your SS >emission didn't bother anybody, such an ID sure could! > >So as a goodwill gesture to the satellite and weak signal crowds I'm >proposing a rule that above a certain power level (TBD) SS >transmissions would have to be IDed with Morse Code at a power >spectral density not to exceed that of the SS emission as a whole as >measured in a 3Khz (SSB) bandwidth. > >The rule would allow many different implementations: unbalancing the >spreading mixer of a DS system slightly to inject a weak carrier >component that could be keyed on and off; injecting keyed CW tones at >other RF frequencies; keying a frequency notch out of the spread >signal (most easily done with fast frequency hopping by simply gating >the transmitter off when it lands in the notch during a key-up >interval in the CWID); keying the whole emission off and on (best for >highly coded low speed emissions where the interleaver could "ride >through" the keyup intervals). There are probably other methods that >would work too, and all could be copied in narrowband receivers. > >Comments? > >Phil > > > > From debgm@intouch.com Tue Apr 29 09:43:06 1997 Received: from intouch2.intouch.com ([163.121.157.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id JAA26916 for ; Tue, 29 Apr 1997 09:43:02 -0500 (CDT) From: debgm@intouch.com Received: from mail.intouch.com by intouch2.intouch.com (SMI-8.6/SMI-SVR4) id QAA07629; Tue, 29 Apr 1997 16:34:18 +0200 Date: Tue, 29 Apr 1997 16:34:18 +0200 Message-Id: <199704291434.QAA07629@intouch2.intouch.com> X-Sender: debgm@intouch.com (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org Subject: Re: [SS:1291] CDMA on sat PLEASE NOTE GROEGER NO LONGER HERE, PLEASE DELETE ADDRESS DEBGM At 03:44 AM 4/29/97 -0500, you wrote: > >next year i'll met with final project at my campus >so i want get a topic about : > >multiple access CDMA on satellite communication ... > >actually i want to build a hardware device (prototype, transceiver , >etc), i don't know what can i build or what hardware that very necessary , >because i'm "a new comer" on spread spectrum . > >would you like to give me an advice about my final project ? > >can you tell me some literature to understand about CDMA , spread spectrum >, etc ? > >thanks for everything >:) > >*************************************** >Best Regards, >BASUKI E. PRIYANTO >"Beat Spread Spectrum" >Mail:priya@itb.ac.id >*************************************** > > > From debgm@intouch.com Tue Apr 29 09:43:13 1997 Received: from intouch2.intouch.com ([163.121.157.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id JAA26940 for ; Tue, 29 Apr 1997 09:43:07 -0500 (CDT) From: debgm@intouch.com Received: from mail.intouch.com by intouch2.intouch.com (SMI-8.6/SMI-SVR4) id QAA07613; Tue, 29 Apr 1997 16:33:59 +0200 Date: Tue, 29 Apr 1997 16:33:59 +0200 Message-Id: <199704291433.QAA07613@intouch2.intouch.com> X-Sender: debgm@intouch.com (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org Subject: Re: [SS:1288] Re: SS ID PLEASE NOTE GOREGER NO LONGER HERE, PLEASE DELETE THIS ADDRESS DEBGM At 11:29 PM 4/28/97 -0500, you wrote: >>So as a goodwill gesture to the satellite and weak signal crowds I'm >>proposing a rule that above a certain power level (TBD) SS >>transmissions would have to be IDed with Morse Code at a power >>spectral density not to exceed that of the SS emission as a whole as >>measured in a 3Khz (SSB) bandwidth. > >>The rule would allow many different implementations: unbalancing the >>spreading mixer of a DS system slightly to inject a weak carrier >>component that could be keyed on and off; injecting keyed CW tones at >>other RF frequencies; keying a frequency notch out of the spread >>signal (most easily done with fast frequency hopping by simply gating >>the transmitter off when it lands in the notch during a key-up >>interval in the CWID); keying the whole emission off and on (best for >>highly coded low speed emissions where the interleaver could "ride >>through" the keyup intervals). There are probably other methods that >>would work too, and all could be copied in narrowband receivers. >> >>Comments? > >Why does it not surprise me that Bill's comments are going to be those of >AMSAT. I hope that you have some influence on the AMSAT Board before the >filling, but past experience doesn't seem to indicate that much influence >Bill on this subject. I sent a set of messages to Tom Clark on this issue >in January which he posted to the AMSAT board. Maybe they are aware of the >concern I have about the possible damage of poor rules for SS could have on >future satellite SS operations. > >My personal comment is that I couldn't disagree with you more Phil. > >At best, RM-8737 and Docet 97-12 were some of the poorest written rule >making I have seen from the WTB in some time. This is one reason we are >having these debates on the issues that should be simple in nature. > >It comes down to this. Rules that the amateur community gets implemented >now -- we are going to have to live with for possibly another 10+ years. >Are we willing to have this IDing issue in the rules for years and years >that could vastly limit people doing new designs. We need to implement >rules that are open. We can't have additions to the rules for special >interests within the hobby, just because they are potentially afraid of new >technology. Amateur radio changes -- at least it is suppose to if the >rules allows change. The things I keep seeing that could be added when we >started by trying to simply delete things -- could drastically limit future >growth. Maybe this is a tactic by those that just want the status quo for >the next ten years when it might not matter to them who is operating. > >Every time a group has an concern with Spread Spectrum someone shows up >with a fix that concerns power limitations. I have a license that says I >can operate various power limits. I might as well start tuning up in the >weak signal band with wide band amps at 1000 watts. Why don't I ? Because >I know that there are other there and it wouldn't be nice. We should not >limit the operations of a mode (i.e. second class citizen) all because >someone is concerned about bad operating. The rules should be written to >benefit those that operate correctly, not limit it because a few could >operate poorly. Those are bad rules if we write them to take in account >the 1% of the community instead of the 99% of the community. > >We have rules to handle all the various issues. Having Morse Code IDing is >the most ridiculous concept I have heard of on a potentially advanced mode >such as Spread Spectrum. We might as well revert back to just running 300 >baud on HF. > >The FCC is ready to allow us the changes we are asking for. If we file >comments giving into various special interests that want limitations placed >on the technology, then that gives them credence for the FCC to consider >during the rules process. We need to ask for all the things we want in the >rule making -- in-band IDing, 50Mhz and up, no power limitations and the >rest. This is amateur radio, not a commercial service, not Part 15, not >anything else. > >We are back to adding rules to something we started out trying to simplify >greatly. This doesn't make sense. Let's stick with deleting rules from >Part 97 to open them up, not adding more limitations to what amateur can >design and experiment with as a fun, learning, and educational experience. > >It is time to make Part 97 into rules that fit on a few sheets that are >easy to read instead of something that requires a lawyer with a spectrum >analyzer to determine if a radio is legal or not. > >Now on a technical issue -- what about hybrid systems or other methods that >people might use ? DS is you example. If I am jumping between bands with >a hybrid system -- where do I ID ? Each band hope ? On every band ? Just >on the band I am at when the 10 min ID hits ? Can I ID at 300 wpm ? Again >-- a simple rule that makes sense on the surface for a few modes of >operations might not really fit an entire mode called Spread Spectrum. >This again comes down to being something that is agreed upon when systems >are being designed, not something defined in the rules. > >Cheers - Greg, WD5IVD > >----- >Greg Jones, WD5IVD >Austin, Texas >wd5ivd@tapr.org >http://www.tapr.org/~wd5ivd >----- > > > > From debgm@intouch.com Tue Apr 29 09:43:30 1997 Received: from intouch2.intouch.com ([163.121.157.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id JAA26976 for ; Tue, 29 Apr 1997 09:43:27 -0500 (CDT) From: debgm@intouch.com Received: from mail.intouch.com by intouch2.intouch.com (SMI-8.6/SMI-SVR4) id QAA07649; Tue, 29 Apr 1997 16:34:41 +0200 Date: Tue, 29 Apr 1997 16:34:41 +0200 Message-Id: <199704291434.QAA07649@intouch2.intouch.com> X-Sender: debgm@intouch.com (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org Subject: Re: [SS:1293] Re: SS ID PLEASE NOTE GROEGER NO LONGER HERE, PLEASE DELETE ADDRESS DEBGM At 06:28 AM 4/29/97 -0500, you wrote: > >On Tue, 29 Apr 1997 01:50:12 -0500 (CDT) Jeff King >writes: >[good stuff deleted...] >>>Then again, I'm happy to vote Libertarian year after year even >>though they never win. Its a decision you have to make yourself. > >..which brings back to mind the motto of William of Orange: "Il n'est >pas necessaire d'esperer pour entreprendre, ni de reussir pour >perseverer". > >Andre Kesteloot N4ICK. > > > From debgm@intouch.com Tue Apr 29 09:43:42 1997 Received: from intouch2.intouch.com ([163.121.157.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id JAA26941 for ; Tue, 29 Apr 1997 09:43:09 -0500 (CDT) From: debgm@intouch.com Received: from mail.intouch.com by intouch2.intouch.com (SMI-8.6/SMI-SVR4) id QAA07636; Tue, 29 Apr 1997 16:34:26 +0200 Date: Tue, 29 Apr 1997 16:34:26 +0200 Message-Id: <199704291434.QAA07636@intouch2.intouch.com> X-Sender: debgm@intouch.com (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org Subject: Re: [SS:1291] CDMA on sat PLEASE NOTE GROEGER NOT HERE, PLEASE DELETE ADDRESS DEBGM At 03:44 AM 4/29/97 -0500, you wrote: > >next year i'll met with final project at my campus >so i want get a topic about : > >multiple access CDMA on satellite communication ... > >actually i want to build a hardware device (prototype, transceiver , >etc), i don't know what can i build or what hardware that very necessary , >because i'm "a new comer" on spread spectrum . > >would you like to give me an advice about my final project ? > >can you tell me some literature to understand about CDMA , spread spectrum >, etc ? > >thanks for everything >:) > >*************************************** >Best Regards, >BASUKI E. PRIYANTO >"Beat Spread Spectrum" >Mail:priya@itb.ac.id >*************************************** > > > From debgm@intouch.com Tue Apr 29 09:44:02 1997 Received: from intouch2.intouch.com ([163.121.157.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id JAA26966 for ; Tue, 29 Apr 1997 09:43:17 -0500 (CDT) From: debgm@intouch.com Received: from mail.intouch.com by intouch2.intouch.com (SMI-8.6/SMI-SVR4) id QAA07644; Tue, 29 Apr 1997 16:34:34 +0200 Date: Tue, 29 Apr 1997 16:34:34 +0200 Message-Id: <199704291434.QAA07644@intouch2.intouch.com> X-Sender: debgm@intouch.com (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org Subject: Re: [SS:1292] Looking for Wireless Lan Info PLEASE NOTE GROEGER NO LONGER HERE, PLEASE DELETE ADDRESS, DEBGM At 04:31 AM 4/29/97 -0500, you wrote: > Hello >Can someone point me for company that makes a Wireless lan (or Digital Link) >For long range (About 100KM) ???? >The Airlan and other SS products Are not Inough Long range for our need >We look for a High Speed (1.2 MB or 2MB or better) Back Bone solution >For about 100KM Range > Please Advice > Ronen > >------------------------------------------------------ > Home of Chameleon , TCP/IP applications for Windows >Ronen Pinchook (4Z4ZQ) >NetManage Israel, Ltd. Phone: 972-4-8550123 >E-Mail: ronen@netmanage.co.il Fax: 972-4-8550122 >Time sent:04/29/97 12:27:03 >------------------------------------------------------ > > > From debgm@intouch.com Tue Apr 29 09:45:38 1997 Received: from intouch2.intouch.com ([163.121.157.5]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id JAA26967 for ; Tue, 29 Apr 1997 09:43:18 -0500 (CDT) From: debgm@intouch.com Received: from mail.intouch.com by intouch2.intouch.com (SMI-8.6/SMI-SVR4) id QAA07625; Tue, 29 Apr 1997 16:34:11 +0200 Date: Tue, 29 Apr 1997 16:34:11 +0200 Message-Id: <199704291434.QAA07625@intouch2.intouch.com> X-Sender: debgm@intouch.com (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org Subject: Re: [SS:1290] Re: SS ID PLEASE NOTE GROEGER NO LONGER HERE, DELETE ADDRESS DEBGM At 01:50 AM 4/29/97 -0500, you wrote: >At 10:12 PM 4/28/97 -0500, Phil Karn wrote: > >> >>So as a goodwill gesture to the satellite and weak signal crowds I'm > >Danger Will Robinson. > >>Comments? >> >>Phil > >I don't make goodwill gestures unless they make technical sense. Most >of amateur radio (including the ARRL) doesn't have any vision what-so- >ever as to what "amateur radio" could be, just what it has been. I >stopped trying to reason with these folks years ago. I'm fully convinced >that any growth in amateur radio as a result of SS operations will come >from outside the hobby. > >Not sure if >this helps you but I do know you'll never make the weak signal/ >repeater/10-4 folks happy. So you might as well just make the rules >make sense instead of trying to please people that don't have a >clue as to what the future holds. > >I'd fully agree with Greg on this one. We should stand firm on >a reduction of restrictions on SS without regard to those that >have a vested interest to keep the status quo. > >Then again, I'm happy to vote Libertarian year after year even >though they never win. Its a decision you have to make yourself. > > >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 n7oo@goodnet.com Tue Apr 29 09:48:49 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 JAA27421 for ; Tue, 29 Apr 1997 09:48:47 -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 HAA02833 for ; Tue, 29 Apr 1997 07:43:09 -0700 (MST) Date: Tue, 29 Apr 1997 07:44:54 -0700 (MST) From: Jack Taylor X-Sender: n7oo@goodguy To: ss@tapr.org Subject: Re: [SS:1287] SS ID In-Reply-To: <199704290305.UAA12767@servo.qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Excellent thoughts, Phil! Would think not just for amateur use, but any ss operation, some way of quickly determining the ID of an interfering transmitting station would be desireable. 73 de Jack From fred@tekdata.com Tue Apr 29 10:49:22 1997 Received: from tekdata.com (pool3-023.wwa.com [207.241.60.152]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id KAA01211 for ; Tue, 29 Apr 1997 10:49:13 -0500 (CDT) Received: from localhost (fred@localhost) by tekdata.com (8.8.5/8.8.5) with SMTP id JAA00920 for ; Tue, 29 Apr 1997 09:53:29 -0500 Date: Tue, 29 Apr 1997 09:53:22 -0500 (CDT) From: RHS Linux User To: ss@tapr.org Subject: Re: [SS:1288] Re: SS ID In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > My personal comment is that I couldn't disagree with you more Phil. > > At best, RM-8737 and Docet 97-12 were some of the poorest written rule > making I have seen from the WTB in some time. This is one reason we are > having these debates on the issues that should be simple in nature. > I agree.. > > Every time a group has an concern with Spread Spectrum someone shows up > with a fix that concerns power limitations. I have a license that says I > can operate various power limits. I might as well start tuning up in the > weak signal band with wide band amps at 1000 watts. Why don't I ? Because > I know that there are other there and it wouldn't be nice. We should not > limit the operations of a mode (i.e. second class citizen) all because > someone is concerned about bad operating. The rules should be written to > benefit those that operate correctly, not limit it because a few could > operate poorly. Those are bad rules if we write them to take in account > the 1% of the community instead of the 99% of the community. > I agree with this too. I wonder how rediculous this makes us look to the FCC. I could be wrong, but from strictly a non-technical point -- and this is the rather emotional point I made to Bill -- the same sort of people who will develop SS technology either already operate the satellites (at least occasionally) or have a healthy respect for them. But instead, AMSAT is acting like the "repeater gods" who think that they should have exclusive of "their" frequencies. Instead of letting good design and free enterprise determine the future of amateur SS, they would rather say, "Not in my backyard". This kind of mentality is REALLY disappointing from a organization technical enough to be able to launch satellites into orbit. This is like if 25 years ago terrestrial operators would have fought ham sats because they might interfere with terrestrial operations! So basically what AMSAT and W3XO is telling us, and Bill actually told me in a personal e-mail correspondance is that they don't trust all of us. Maybe me, maybe Phil because we are degreed engineers, but maybe not someone who just buys a TAPR kit, or "exploitive" commercial ham manufacturers. Does MFJ really exploit the ham community? or Kenwood? I don't know about anyone else out there- I am now a member of the ARRL because I was happy about their support of SS (even with the rules not being too clear on SS, and despite my anti-forced-CW stance), a member of TAPR (because I feel overall they are heading in the right direction) and also AMSAT. I've always supported AMSAT, I like the _Journal_, but I'm worried about the "all eggs in one basket" philosophy with P3D and now I'm downright hot about the SS issue. Maybe it's time I let that particular $30/yr stay in my checkbook.. Fred M. Spinner, KA9VAW fred@tekdata.com From wd5ivd@tapr.org Tue Apr 29 11:06:10 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 LAA02493 for ; Tue, 29 Apr 1997 11:06:08 -0500 (CDT) Message-Id: In-Reply-To: <199704290636.XAA13106@servo.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Apr 1997 10:15:03 -0500 To: ss@tapr.org From: "Greg Jones, WD5IVD" Subject: Re: [SS:1289] Re: SS ID Phil, I read back over my hastily written message and kept wondering what the correct term would be for what I was calling in-band IDing or what I think of as having the ID in the data stream. Would it be called in-band IDing? or would there be a more practical term used in industry for this that I am not familiar with ? Cheers - Greg >Okay Greg, you've convinced me. The rules should be as liberal as possible, >and we should rely on "best current practice" to set standards for ID, >etc. > >Automatic power control and CWIDs should probably be on the list of >"best current practice". BTW, the CWID really isn't that hard to >implement, and by the very nature of spread spectrum it wouldn't >bother the spread signal. But I agree there could be situations where >it's not totally trivial. > >Phil ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From wd5ivd@tapr.org Tue Apr 29 11:06: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 LAA02587 for ; Tue, 29 Apr 1997 11:06:35 -0500 (CDT) Message-Id: In-Reply-To: <33660750.59E2@eds.tinker.af.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Apr 1997 11:05:17 -0500 To: ss@tapr.org From: "Greg Jones, WD5IVD" Subject: Re: [SS:1294] Re: Looking for Wireless Lan Info >Ronen Pinchook wrote: >> >> Can someone point me to a company that makes a Wireless lan >> (or Digital Link) for long range (About 100KM) > >100 kilometers is a problem. Earth curvature and other >things come into effect (antenna height, etc). > >What everyone uses here, is the microwave links. The >two best that I can think of who use these, are the >Bonneville Power Administration (Oregon) and the USAF. >They use 40 mile hops on pretty significant structures. >Neither have anything to do with SS, so I'll drop it here. >But to get 100 kilometers, you are going to have to >go the license route with higher power and structures, or >you will have to have about 10 to 20 intermediate hops >with unlicensed nodes. > >Just a guess, no facts. > Not necessarily, there are projects like Signatron and others that are working on this type of technology. Ronen, two questions that have to be asked, are you limited to a freq band of operations and speed ? If you want high data rates on higher bands you are not going to see it happen in one hop. If you want a lower speed on a lower band the technology might be available now and in the future. Amateur radio operators makes 60 miles work on 440 and other freqs at 9600 and probably even 56K with antennas at 80feet running power of 35watts, but making it work does require height between your locations at the antenna, the use of gain antennas, enough power ot make the stuff talk to each other, and no mountains in the way. Freq selection, height of antenna, transmission power, and several other factors effect making something go 60 miles (100km). Are there any major terrain features in the way ? I would think that at worse you are talking about two 30 mile hops if they are both line of sight. 30 miles is do able now with some of the commericial equipment available in the US and elsewhere if installed and setup correctly for what you are trying to do. The issues of making radios work over distance is complex, but sometime it is the only alternative. Cheers - Greg ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From ssampson@claven.tinker.af.mil Tue Apr 29 13:20:02 1997 Received: from othello.tinker.af.mil (othello.tinker.af.mil [137.240.231.43]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA18878 for ; Tue, 29 Apr 1997 13:19:58 -0500 (CDT) Received: from localhost by othello.tinker.af.mil (AIX 4.1/UCB 5.64/4.03) id AA18594; Tue, 29 Apr 1997 13:19:54 -0500 Sender: ssampson@othello.tinker.af.mil Message-Id: <33663BC9.1CFB@eds.tinker.af.mil> Date: Tue, 29 Apr 1997 13:19:53 -0500 From: Steve Sampson X-Mailer: Mozilla 3.01 (X11; U; AIX 1) Mime-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1303] Re: SS ID References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've read interesting engineering stories, where an RFI problem was investigated, and the source identified. One really good one, was an old barn that had a tin roof, and some other metals, that began arcing in every storm. It completely wiped-out the HF bands for several miles. It would come and go, but finally it was tracked down. The moral of the story, is it did not have a CW ID. So the argument has to be a "fast method of identification." In short, a burst of information, easily decoded. It does not need to be morse. If a decoder can be built for $25 that allows anyone to display what callsigns are using the spectrum, then use that as a compromise. Let's not focus on narrowband morse code. There are many ways to ID, and let's compromise with the highest-tech solution. Who's working on high-tech radio identification? I'm sure the FCC needs a solution in the commercial realm. Steve From aeynon@micro.ti.com Tue Apr 29 14:19:17 1997 Received: from gatekeep.ti.com (news.ti.com [192.94.94.33]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA21635 for ; Tue, 29 Apr 1997 14:19:15 -0500 (CDT) Received: from reliant.micro.ti.com ([158.218.63.15]) by gatekeep.ti.com (8.8.5) with ESMTP id OAA28633 for ; Tue, 29 Apr 1997 14:18:43 -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 OAA25179 for ; Tue, 29 Apr 1997 14:18:42 -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 AAA5785 for ; Tue, 29 Apr 1997 14:18:40 -0500 Message-Id: <3.0.32.19970429142033.006c8184@pcmail.micro.ti.com> X-Sender: aeyn@pcmail.micro.ti.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 29 Apr 1997 14:20:34 -0500 To: ss@tapr.org From: "Alan J. Eynon" Subject: Re: [SS:1306] Re: SS ID Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >The moral of the story, is it did not have a CW ID. An excellent idea! >So the argument has to be a "fast method of identification." >In short, a burst of information, easily decoded. It >does not need to be morse. If a decoder can be built for >$25 that allows anyone to display what callsigns are using >the spectrum, then use that as a compromise. Let's not >focus on narrowband morse code. There are many ways to >ID, and let's compromise with the highest-tech solution. I don't suppose we could settle for something subtle like the spreading sequence itself? For instance, using two 10-stage shift registers (presumably hard-wired with the preferred pair of tabs), it's possible to generate 1025 unique Gold code spreading sequences, essentially by changing the starting fills of the two shift registers. Longer shift registers produce correspondingly larger families of sequences (with generally good cross-correlation properties, I might add). It seems like if the FCC wanted to regulate the use of spread spectrum, it could do so by giving each of us a unique set of fills. This also has the by-product that it makes identification easy. It also requires zero extra hardware on our part. Additionally, it forces us to standardize on a fixed set of shift register taps, which (for DS at least) might aid interoperability. One might argue that by changing fills a truly perverse individual could masquerade as someone else, but then that's just as true of any other form of identification. In fact, a CW or other narrowband form of superimposed ID (being more familiar) might even be easier to corrupt. I don't know; how esoteric can we go before we break the FCC's threshold of tolerance? 73, Alan N3IRL/G0PTH 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 jerryn@ici.net Tue Apr 29 14:21:15 1997 Received: from localhost (d-ma-fallriver-57.ici.net [207.180.10.66]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id OAA21713 for ; Tue, 29 Apr 1997 14:21:13 -0500 (CDT) Received: from nomad by localhost with smtp (Smail3.1.29.1 #58) id m0wMIRy-000VTXC; Tue, 29 Apr 97 15:20 EDT Sender: root@tapr.org Message-ID: <336649FE.712D8CF2@ici.net> Date: Tue, 29 Apr 1997 15:20:30 -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:1294] Re: Looking for Wireless Lan Info X-Priority: 3 (Normal) References: <33660750.59E2@eds.tinker.af.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jerry Replies: Wow 40 miles is a long microwave hope. Those towers must be HUGE! I am getting 26miles out of 100' anteenea hieght and 1 watt out. Note: I am using a high gain preamp and a phased array antennea! Steve Sampson wrote: > > Ronen Pinchook wrote: > > > > Can someone point me to a company that makes a Wireless lan > > (or Digital Link) for long range (About 100KM) > > 100 kilometers is a problem. Earth curvature and other > things come into effect (antenna height, etc). > > What everyone uses here, is the microwave links. The > two best that I can think of who use these, are the > Bonneville Power Administration (Oregon) and the USAF. > They use 40 mile hops on pretty significant structures. > Neither have anything to do with SS, so I'll drop it here. > But to get 100 kilometers, you are going to have to > go the license route with higher power and structures, or > you will have to have about 10 to 20 intermediate hops > with unlicensed nodes. > > Just a guess, no facts. > > Steve From ronen@ronen.netmanage.co.il Tue Apr 29 15:44:55 1997 Received: from ronen.netmanage.co.il (ronen.netmanage.co.il [156.27.241.36]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id PAA25690 for ; Tue, 29 Apr 1997 15:44:52 -0500 (CDT) Date: Tue, 29 Apr 97 23:33:34 EDT Message-Id: <202475@ronen.netmanage.co.il> From: Pinchook Ronen To: ss@tapr.org Subject: Re:Microwave lan for 100 KM X-BBS-Msg-Type: P Let me ask for question All these link I see With Dishes (for example the one that connect between the cellular towers , TV station etc) Dont designed for more then 40-60 Mile ??? (hard for me to belive) If we calculate line of sight losses in 2.4G It can be achived very simply with not so big dish and not so high power Thats What I look for ... Yes , I have Places With mountains 100KM apart line of sight So Only I need that the losses will not be too much or that the power will be strong inough to overcome the path loss We have now from the same places a 9.6K Back Bone Running with a Omnidirectional (in one side) to Beem (at other side) with 5 Watt power (yes thats truth ) and it works full scale no problem) Iit work on the UHF band (433 MHz) I want to Upgrade the Speed to more then 56K I can also tell you that I can hear the 800 MHz Trunking station at hifa from Mobile at Tel-aviv (100KM away) and the trunk use 25Watt So I dont Understand Why cant it be done with Fixed station With Beem on 2.4Ghz I'm looking for that type of radios that will doo the job for me. Please Advice Thanks Forward Ronen - 4Z4ZQ ------------------ Jerry Replies: Wow 40 miles is a long microwave hope. Those towers must be HUGE! I am getting 26miles out of 100' anteenea hieght and 1 watt out. Note: I am using a high gain preamp and a phased array antennea! Steve Sampson wrote: > > Ronen Pinchook wrote: > > > > Can someone point me to a company that makes a Wireless lan > > (or Digital Link) for long range (About 100KM) > > 100 kilometers is a problem. Earth curvature and other > things come into effect (antenna height, etc). > > What everyone uses here, is the microwave links. The > two best that I can think of who use these, are the > Bonneville Power Administration (Oregon) and the USAF. > They use 40 mile hops on pretty significant structures. > Neither have anything to do with SS, so I'll drop it here. > But to get 100 kilometers, you are going to have to > go the license route with higher power and structures, or > you will have to have about 10 to 20 intermediate hops > with unlicensed nodes. > > Just a guess, no facts. > > Steve From n3jly@erols.com Tue Apr 29 15:53:47 1997 Received: from smtp1.erols.com (smtp1.erols.com [205.252.116.101]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id PAA26303 for ; Tue, 29 Apr 1997 15:53:46 -0500 (CDT) Received: from LOCALNAME (col-as9s70.erols.com [207.172.73.214]) by smtp1.erols.com (8.8.5/8.8.5) with SMTP id QAA09729 for ; Tue, 29 Apr 1997 16:54:09 -0400 Date: Tue, 29 Apr 1997 16:54:09 -0400 Message-Id: <199704292054.QAA09729@smtp1.erols.com> X-Sender: n3jly@pop.erols.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org From: Tony McConnell Subject: Re: [SS:1304] Re: SS ID At 11:15 AM 4/29/97 -0500, you wrote: >Phil, I read back over my hastily written message and kept wondering what >the correct term would be for what I was calling in-band IDing or what I >think of as having the ID in the data stream. > >Would it be called in-band IDing? or would there be a more practical term >used in industry for this that I am not familiar with ? > >Cheers - Greg yes in-band idong would be iding in the data payload, as with packet now. 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. how about a continous morse or mcw of the carrier amplitude while in use? say 50%. detectable with a narrow receiver, and wide so that the the id is where 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. tony - n3jli From bad@uhf.wireless.net Tue Apr 29 15:57:37 1997 Received: from uhf.wdc.net (uhf.wdc.net [198.147.74.44]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id PAA26401 for ; Tue, 29 Apr 1997 15:57:31 -0500 (CDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id QAA06840 for ; Tue, 29 Apr 1997 16:58:52 -0400 (EDT) Date: Tue, 29 Apr 1997 16:58:50 -0400 (EDT) From: Bernie Doehner To: ss@tapr.org Subject: Re: [SS:1307] Re: SS ID In-Reply-To: <3.0.32.19970429142033.006c8184@pcmail.micro.ti.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII [...] > it could do so by giving each of us a unique set of fills. > This also has the by-product that it makes identification easy. > It also requires zero extra hardware on our part. Additionally, > it forces us to standardize on a fixed set of shift register > taps, which (for DS at least) might aid interoperability. The general concept sounds great, however this brings to mind something akin to the what power hungry frequency coordinators are doing right now in the frequency domain (I know I am exagerating a bit, but someone will have to do the paper work for registering the spreading codes). Also, how do you propose to identify what spreading code a particular station is using by listening to it with nothing more than a narrowband receiver? > I don't know; how esoteric can we go before we break the FCC's > threshold of tolerance? > I don't know either. Nonetheless the current rules with narrowband ID'ing is pretty silly. Bernie From wd5ivd@tapr.org Tue Apr 29 16:47: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 QAA28747 for ; Tue, 29 Apr 1997 16:47:22 -0500 (CDT) Message-Id: In-Reply-To: <202475@ronen.netmanage.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Apr 1997 16:46:53 -0500 To: ss@tapr.org From: "Greg Jones, WD5IVD" Subject: Re: [SS:1309] Re:Microwave lan for 100 KM You should talk to BreezeCom. They are in you country and might be willing to work with you on what you are doing. Cheers - Greg >Let me ask for question >All these link I see With Dishes (for example the one that connect between >the cellular >towers , TV station etc) >Dont designed for more then 40-60 Mile ??? (hard for me to belive) >If we calculate line of sight losses in 2.4G >It can be achived very simply with not so big dish and not so high power >Thats What I look for ... >Yes , I have Places With mountains 100KM apart line of sight So Only I need >that the losses will not be too much >or that the power will be strong inough to overcome the path loss >We have now from the same places a 9.6K Back Bone >Running with a Omnidirectional (in one side) to Beem (at other side) >with 5 Watt power (yes thats truth ) and it works full scale no problem) >Iit work on the UHF band (433 MHz) >I want to Upgrade the Speed to more then 56K > >I can also tell you that I can hear the 800 MHz Trunking station at hifa >from Mobile at Tel-aviv (100KM away) and the trunk use 25Watt >So I dont Understand Why cant it be done with Fixed station With Beem >on 2.4Ghz >I'm looking for that type of radios that will doo the job for me. > > Please Advice > Thanks Forward > Ronen - 4Z4ZQ >------------------ > >Jerry Replies: > >Wow 40 miles is a long microwave hope. Those towers must be HUGE! > >I am getting 26miles out of 100' anteenea hieght and 1 watt out. > >Note: I am using a high gain preamp and a phased array antennea! > >Steve Sampson wrote: > >> > >> Ronen Pinchook wrote: >> > > >> > > >> > Can someone point me to a company that makes a Wireless lan > >> > (or Digital Link) for long range (About 100KM) > >> > >> 100 kilometers is a problem. Earth curvature and other > >> things come into effect (antenna height, etc). > >> > >> What everyone uses here, is the microwave links. The > >> two best that I can think of who use these, are the > >> Bonneville Power Administration (Oregon) and the USAF. > >> They use 40 mile hops on pretty significant structures. > >> Neither have anything to do with SS, so I'll drop it here. > >> But to get 100 kilometers, you are going to have to > >> go the license route with higher power and structures, or > >> you will have to have about 10 to 20 intermediate hops > >> with unlicensed nodes. > >> > >> Just a guess, no facts. > >> > >> Steve > ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From aeynon@micro.ti.com Tue Apr 29 17:03:26 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 RAA00255 for ; Tue, 29 Apr 1997 17:03:22 -0500 (CDT) Received: from reliant.micro.ti.com ([158.218.63.15]) by dragon.ti.com (8.8.5) with ESMTP id RAA29263 for ; Tue, 29 Apr 1997 17:02:50 -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 RAA14194 for ; Tue, 29 Apr 1997 17:02:50 -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 AAA17954 for ; Tue, 29 Apr 1997 17:02:48 -0500 Message-Id: <3.0.32.19970429170440.006ca664@pcmail.micro.ti.com> X-Sender: aeyn@pcmail.micro.ti.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 29 Apr 1997 17:04:41 -0500 To: ss@tapr.org From: "Alan J. Eynon" Subject: Re: [SS:1311] Re: SS ID Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >[...] >> it could do so by giving each of us a unique set of fills. >> This also has the by-product that it makes identification easy. >> It also requires zero extra hardware on our part. Additionally, >> it forces us to standardize on a fixed set of shift register >> taps, which (for DS at least) might aid interoperability. > >The general concept sounds great, however this brings to mind something >akin to the what power hungry frequency coordinators are doing right now >in the frequency domain (I know I am exagerating a bit, but someone will >have to do the paper work for registering the spreading codes). Hmmm, in the context of my proposal, I believe that every ham's spreading sequence fills should be public domain. Put 'em on a web page. No, better yet, let us check them out from a web page. The paper-lovers can always follow up authenticating the fill requests by mail. I presume that no amateur would need more than a handful (?) of sequences. This might even sooth the operators in whose bands we're proposing to overlay, since they could find out (at a browse) who in their area was using spread spectrum. Depending on location, this - followed up with a few telephone calls - might be enough to determine which spread spectrum transmitter is causing the perceived interference. I also assume that, prior to prosecuting egregious violators, the FCC or local coordinators will have to do the normal direction finding jig and positively identify the source of the interference. Proof of guilt still rests with the prosecution. >Also, how do you propose to identify what spreading code a particular >station is using by listening to it with nothing more than a narrowband >receiver? The only limit within which I was operating was that a relatively inexpensive ($25 was mentioned) device would be all that's needed to make the identification. It seems reasonable that the silicon is already out there (companies like Qualcomm) to brute-force search through the spreading sequence family in a few seconds. Coupled with knowledge of the legitimate operators who have spreading sequences (from that web page I mentioned) and the usual DF fixes, I don't see that enforcement of spread spectrum transmission regulations need be any more difficult than in the narrowband regime. After all, if the spread signal is so stealthy that you can't DF it, then it pretty much goes without saying that it's not causing interference. 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 Tue Apr 29 18:18:08 1997 Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA05229 for ; Tue, 29 Apr 1997 18:18:05 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id QAA15564; Tue, 29 Apr 1997 16:17:34 -0700 (PDT) Date: Tue, 29 Apr 1997 16:17:34 -0700 (PDT) Message-Id: <199704292317.QAA15564@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: (message from Bernie Doehner on Sun, 20 Apr 1997 10:10:53 -0500 (CDT)) Subject: Re: [SS:1278] Reed Solomon source code >One of my problems, is that none of the 10 books I have on the subject >give you an algorithms (pseudocode) presentation of Reed Solomon (they >all explain it over GF() and that's where they lose me. It would Bernie, Unfortunately, there is just no way you can really understand the Reed-Solomon code without understanding arithmetic in finite fields (Galois fields). It's a bit like trying to understand orbital mechanics without knowing trigonometry. I hope my implementation of the RS code in C (which I didn't write from scratch, but merely cleaned up from two other guys) will be of help. But again, the details it won't make much sense unless you have a good understanding of Galois Field arithmetic. Phil From lylej@azstarnet.com Tue Apr 29 20:19:28 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 UAA19948 for ; Tue, 29 Apr 1997 20:19:26 -0500 (CDT) Received: from tomswift (usr1ip28.azstarnet.com [169.197.2.28]) by mailhost.azstarnet.com (8.8.3-p/8.8.5) with SMTP id SAA16632 for ; Tue, 29 Apr 1997 18:18:52 -0700 (MST) Message-Id: <3.0.32.19970429180909.006faea4@pop.azstarnet.com> X-Sender: lylej@pop.azstarnet.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 29 Apr 1997 18:17:26 -0700 To: ss@tapr.org From: Lyle Johnson Subject: Re: SS ID Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" I might as well jump in and show my ignorance :-) I remember when we were facing having to send a CWID in the early days of packet. TAPR's early *system* design called for a station on the "net" to broadcast a message to all TNCs in its "domain" to "..5..4..3..2..1..ID..NOW!" and *ALL* the TNCs would then key up and ID in CW at 20 WPM. This would meet the reglatory requirements, would minimize the communications bandwidth hit, and would point out how ridiculous the requirement was :-) Seems to me that if SS is a recognized mode, IDing in SS is legitmate. We do it on packet, we do it on RTTY, we do it on AMTOR, we even do it on SSB and FM! Anyone feel a need to use CWID on SSB (after all, you might be speaking non-Emglish to the other station)? I think the new rules ought to be as simple and non-restrictive as possible. Good engineering practice and sound system design will be required to make this mode have a reasonable chance at general acceptance. Power control where it makes sense will happen because it makes sense. Stations will ID because (a) they have to comply with rules and (b) how else will you know who the other station is? If hams can figure out the other station's ID to exchange information with that station, then the problem is solved, no? Frankly, I'd like to see the rules say "these bands" and "this maximum overall power" and *perhaps* "this minimum theoretical spreading gain" and "maximum spectral power density" and stop there. Why make it hard, or assume only SS users will wear black hats? Back to RUDAK, Lyle From bad@uhf.wireless.net Tue Apr 29 20:30:19 1997 Received: from uhf.wdc.net (uhf.wdc.net [198.147.74.44]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA20275 for ; Tue, 29 Apr 1997 20:30:13 -0500 (CDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id VAA07836 for ; Tue, 29 Apr 1997 21:31:29 -0400 (EDT) Date: Tue, 29 Apr 1997 21:31:26 -0400 (EDT) From: Bernie Doehner To: ss@tapr.org Subject: Re: [SS:1314] Re: Reed Solomon source code In-Reply-To: <199704292317.QAA15564@servo.qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Phil: > Unfortunately, there is just no way you can really understand the > Reed-Solomon code without understanding arithmetic in finite fields > (Galois fields). It's a bit like trying to understand orbital mechanics > without knowing trigonometry. I agree 110% Still working on that, but the report has to be done before I fully understand GF(). > I hope my implementation of the RS code in C (which I didn't write from > scratch, but merely cleaned up from two other guys) will be of help. Don't we all? :) If worse comes to worse, I'll use it as a black box, but I want to understand the details. > But again, the details it won't make much sense unless you have a good > understanding of Galois Field arithmetic. > At the risk of asking a really dumb question, but is it possible to explain Reed-Solomon in terms of prime fields and not GF()? All 10 of my books on this subject talk about RS over GF(). Thanks again. Bernie From labriola@ix.netcom.com Tue Apr 29 21:28:44 1997 Received: from dfw-ix11.ix.netcom.com (dfw-ix11.ix.netcom.com [206.214.98.11]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id VAA22725 for ; Tue, 29 Apr 1997 21:28:42 -0500 (CDT) Received: (from smap@localhost) by dfw-ix11.ix.netcom.com (8.8.4/8.8.4) id VAA26532 for ; Tue, 29 Apr 1997 21:28:10 -0500 (CDT) Received: from ont-ca11-52.ix.netcom.com(207.93.40.116) by dfw-ix11.ix.netcom.com via smap (V1.3) id sma026506; Tue Apr 29 21:27:57 1997 Message-ID: <3366043B.35E8@ix.netcom.com> Date: Tue, 29 Apr 1997 07:22:51 -0700 From: Don Labriola Reply-To: labriola@ix.netcom.com X-Mailer: Mozilla 3.01Gold (Win16; U) MIME-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1306] Re: SS ID References: <33663BC9.1CFB@eds.tinker.af.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 minutes), then it would not appreciably add to the general noise, but it might be easier to locate the source as the ID would come into the "victim" system in the same manner as the normal signal. An 'inband' ID or omitted hop might not interfere in the same manner as the normal signal, and thus it would still be hard to find the source of problems. Just my $.02 73's de W6QS From karn@qualcomm.com Tue Apr 29 21:28: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 VAA22742 for ; Tue, 29 Apr 1997 21:28:47 -0500 (CDT) Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id TAA15923; Tue, 29 Apr 1997 19:28:17 -0700 (PDT) Date: Tue, 29 Apr 1997 19:28:17 -0700 (PDT) Message-Id: <199704300228.TAA15923@servo.qualcomm.com> From: Phil Karn To: ss@tapr.org In-reply-to: (message from Bernie Doehner on Tue, 29 Apr 1997 20:32:26 -0500 (CDT)) Subject: Re: [SS:1316] Re: Reed Solomon source code Well, prime fields are just one type of Galois field. The more general type of Galois field, and the one used in RS codes, is the "extension" field of the form GF(p^m), where p is prime. Most often, p=2 (which is prime). This is a natural match to binary computers that group binary bits into words. E.g., GF(2^8) is a natural for a byte-oriented machine, which is why this one value is probably used for more real RS implementations than all others combined. One problem with prime fields for RS coding applications is that they're not particularly well suited to binary arithmetic. Each code symbol would have a prime number of valid values, meaning not all possible values of a N-bit word would be valid symbols. So you'd have to pick some usable number of bits such that 2^N is less than the size of the prime field, and waste some of the possible values of each symbol. Not only that, but it's actually much *easier* to implement a code in an extension field such as GF(256) instead of a prime field. Prime fields have the pedagological (teaching) advantage that addition and multiplication in the field are just like ordinary addition and multiplication done modulo the size of the field. But multiplication is a slow operation, and even addition is more complicated than XOR. The analogous operations to addition and multiplication in binary extension fields are much easier to implement, with a twist. Addition is downright trivial -- it's simple exclusive OR. So is subtraction, so adding and subtracting are the same operation -- and can often be cancelled out from the formulas. The twist is that the easiest way to multiply two numbers is to add their logarithms with ordinary arithmetic addition. So you'll see all though my RS code conversions between "polynomial" and "index" (logarithmic) form. Whenever you want to add (or subtract) two GF elements, you convert them to polynomial form (if necessary) with a lookup table and then XOR them. If you want to multiply two elements, you convert them to index (log) form, if necessary, with a complementary lookup table and then add them mod the size of the field. Some RS implementations dispense with index/log form and keep everything in polynomial form. They perform multiplication and exponentiation (which is just repeated multiplication) with lookup tables. This is a good idea for small field sizes. The problem here is that the tables can get rather big when the GF is large. E.g., for GF(256), a very common choice for a RS code, you need a multiplication lookup table of the form unsigned char gfmult[256][256]; You index the table with the two values you want to multiply and the indexed value is the product. The problem is that this is a 64KB table. That's not much RAM by today's standards to be sure, but remember that this thing is going to be competing heavily for on-chip cache space along with everything else the program is doing. So my implementation stuck with the dual polynomial/index representation and a pair of 256-byte lookup conversion tables, which fit nicely into the Pentium cache. Phil From n3jly@erols.com Tue Apr 29 22:09: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 WAA24993 for ; Tue, 29 Apr 1997 22:09:16 -0500 (CDT) Received: from LOCALNAME (col-as2s65.erols.com [207.172.68.137]) by smtp3.erols.com (8.8.5/8.8.5) with SMTP id XAA06307; Tue, 29 Apr 1997 23:09:15 -0400 Date: Tue, 29 Apr 1997 23:09:15 -0400 Message-Id: <199704300309.XAA06307@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:1313] Re: SS ID Cc: frussle@erols.com At 05:08 PM 4/29/97 -0500, you wrote: Additionally, >>> it forces us to standardize on a fixed set of shift register >>> taps, which (for DS at least) might aid interoperability. >> >>The general concept sounds great, however this brings to mind something >>akin to the what power hungry frequency coordinators are doing right now >>in the frequency domain (I know I am exagerating a bit, but someone will >>have to do the paper work for registering the spreading codes). > >Hmmm, in the context of my proposal, I believe that every ham's spreading >sequence fills should be public domain. Put 'em on a web page. No, better >yet, let us check them out from a web page. Remember guys, if everyone has a different spreading code you need that unique code to hear them, fine for dedicated or point to point stuff, but otherwise.... eh. and the idea that it is easy to see something on the air and that it is easy and quick to brute force through to the pn... i don't think so. while any of us know that ss does not totally protect a signal from interception, without real equipment(read big bucks) it is not easy and quick(ask Phil, looking at where he works, he has a good idea how likely we would be at decerning p/n codes off the air). while it's seems likely we need more codes to use, an assigned codes would be an inpediment. it would be good for us to be free to use unique codes, i wouldn't want to be forced to. if we remain stuck with the current rules, amplitude modulate the whole envalope. but wow what a silly idea. but not quite as silly as unique codes. From priya@students.itb.ac.id Tue Apr 29 22:19:40 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 WAA25713 for ; Tue, 29 Apr 1997 22:19:36 -0500 (CDT) Received: from localhost (priya@localhost) by students.itb.ac.id (8.8.5/8.7.3) with SMTP id KAA24640 for ; Wed, 30 Apr 1997 10:19:50 +0700 (JVT) Date: Wed, 30 Apr 1997 10:19:50 +0700 (JVT) From: "Basuki E. Priyanto" To: ss@tapr.org Subject: Re: [SS:1292] Looking for Wireless Lan Info In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII i think there is imposibble to built line of sight communication (LOS) for 100 km ... it can be but you must built very high tower .... path loss is not a little about 40dB .. you have to increase fading margin in this case, increase antenna gain , or increase transmitter power maybe i can give you a suggest from my experience : my site have digital communication with long range (200km) , but it uses 2 repeater between my site and the destination so distance from my site to repeater about 60 km it's high speed communication (T1) -> 2 Mbps maybe my experience can help you ... On Tue, 29 Apr 1997, Ronen Pinchook wrote: > Hello > Can someone point me for company that makes a Wireless lan (or Digital Link) > For long range (About 100KM) ???? > The Airlan and other SS products Are not Inough Long range for our need > We look for a High Speed (1.2 MB or 2MB or better) Back Bone solution > For about 100KM Range > Please Advice > Ronen > > ------------------------------------------------------ > Home of Chameleon , TCP/IP applications for Windows > Ronen Pinchook (4Z4ZQ) > NetManage Israel, Ltd. Phone: 972-4-8550123 > E-Mail: ronen@netmanage.co.il Fax: 972-4-8550122 > Time sent:04/29/97 12:27:03 > ------------------------------------------------------ > > *************************************** Best Regards, BASUKI E. PRIYANTO "Beat Spread Spectrum" Mail:priya@itb.ac.id *************************************** From wd5ivd@tapr.org Tue Apr 29 23:03:31 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 XAA28807; Tue, 29 Apr 1997 23:03:29 -0500 (CDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Apr 1997 23:04:33 -0500 To: " Spread Spectrum ", "TAPR-BB list mailing" From: "Greg Jones, WD5IVD" Subject: TAPR STA Request for Renewal and Activity Report We just put up the STA Activity Report (all 75 pages) and request for renewal letter both submitted to the FCC yesterday (April 28th, 1997). Check http://www.tapr.org/ss/tapr_sta.html We will post something here as soon as we hear about the renewal request. Keep an eye on http://www.tapr.org/ss in May as comments from the upcoming Docket 97-12 first comment period are made available. Cheers - Greg, WD5IVD ----- Greg Jones, WD5IVD Austin, Texas wd5ivd@tapr.org http://www.tapr.org/~wd5ivd ----- From bm@lynx.ve3jf.ampr.org Tue Apr 29 23:24:18 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 XAA00762 for ; Tue, 29 Apr 1997 23:24:13 -0500 (CDT) Received: (from bm@localhost) by lynx.ve3jf.ampr.org (8.6.12/8.6.12) id EAA15500 for ss@tapr.org; Wed, 30 Apr 1997 04:23:53 GMT From: Barry McLarnon VE3JF Message-Id: <199704300423.EAA15500@lynx.ve3jf.ampr.org> Date: Wed, 30 Apr 1997 04:23:53 +0000 (GMT) To: ss@tapr.org Subject: Re: [SS:1315] Re: SS ID In-Reply-To: <3.0.32.19970429180909.006faea4@pop.azstarnet.com> X-Mailer: Ishmail 1.3.1-961106-linux MIME-Version: 1.0 Content-Type: text/plain Lyle Johnson wrote: > Seems to me that if SS is a recognized mode, IDing in SS is legitmate. We > do it on packet, we do it on RTTY, we do it on AMTOR, we even do it on SSB > and FM! Anyone feel a need to use CWID on SSB (after all, you might be > speaking non-Emglish to the other station)? Just so. This is how it is in Canada - you ID in the mode you're using, whether it's SS or anything else. I don't think it's necessary to make all signals on the amateur bands identifiable by casual intercept with a narrowband receiver. Besides, many hams aren't even capable of decoding a CWID. :-) It does make good sense, however, for those experimenting with SS to be open about what they are doing, and to offer assistance to the other users of the bands to help identify and deal with suspected interference problems. Barry (SS enthusiast who can still copy 35 wpm cw... :-) -- 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 gwyn@paccomm.com Wed Apr 30 05:54:47 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 FAA02640 for ; Wed, 30 Apr 1997 05:54:42 -0500 (CDT) Received: from gwyn by paccomm.com with smtp (Smail3.1.29.1 #1) id m0wMX1z-000FSBC; Wed, 30 Apr 97 06:54 EDT Received: by gwyn with Microsoft Mail id <01BC5533.AC9573E0@gwyn>; Wed, 30 Apr 1997 06:56:48 -0400 Message-ID: <01BC5533.AC9573E0@gwyn> From: Gwyn Reedy To: "'ss@tapr.org'" Subject: RE: 1315] Re: SS ID Date: Wed, 30 Apr 1997 06:56:47 -0400 Encoding: 19 TEXT, 42 UUENCODE X-MS-Attachment: WINMAIL.DAT 0 00-00-1980 00:00 Lyle Johnson[SMTP:lylej@azstarnet.com]said: > I remember when we were facing having to send a CWID in the early days of > packet. TAPR's early *system* design called for a station on the "net" to > broadcast a message to all TNCs in its "domain" to > "..5..4..3..2..1..ID..NOW!" and *ALL* the TNCs would then key up and ID in > CW at 20 WPM. This would meet the reglatory requirements, would minimize > the communications bandwidth hit, and would point out how ridiculous the > requirement was :-) That is sort of what goes on in the UK, I'm told. They remain under a requirement to use CWID, so everyone sets it to go off at 30 minutes after the hour. Given the limited accuracy of TNC clocks, they lose about a 2-3 minute slot each hour, but then are done with it. Does no one any good, but fills the regulatory square. begin 600 WINMAIL.DAT M>)\^(C *`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`' ``0`` M`!0```!213H@,3,Q-5T@4F4Z(%-3($E$``(!<0`!````%@````&\554RS-O< M&$"^$1'0CJ0`0 4O_EH```,`!A"+I:^<`P`'$'X"```>``@0`0```&4```!, M64Q%2D](3E-/3E--5% Z3%E,14I 05I35$%23D540T]-4T%)1#I)4D5-14U" M15)72$5.5T5715)%1D%#24Y'2$%624Y'5$]314Y$04-7241)3E1(145!4DQ9 M1$%94T]&4$%#``````(!"1 !````I0,``*$#```R!@``3%I&=9R;+W#_``H! M#P(5`J0#Y 7K`H,`4!,#5 (`8V@*P'-E=.XR!@`&PP*#,@/&!Q,"@\8S`\4" M`'!R<1(@$XBZ-!,-?0J ",\)V3L7CW@R-34"@ J!#;$+8&XP9S$P,Q0@"P-L M:0@Q.# "T6DM,32>- WP#- ;\PM9,38*H T#8'0%D 5 3'EL93 @2F]H`( " M(%M3($U44#IL'B%J0+AA>G,!D 2@$@`N!:!<;5T+1A0B# %C`$ @\G,+<&0Z M"H< !M $D/@@=V@)\"A0 M'D HL!>03"!F`- +@&<@$00@;V8A_25_)H\%0 D*L&-K( $@(%1!F%!2)P0@*W0J0:6<#H/YC!T >,"IP`A %P"J0'[%<=&D"("P0*Q0B'_$B+RH! M+$\M7RYO8@-@863?,= ?L"J!!X$AH&<>0"H1,S'A+_!.0P0@*P%I=/D$(")D M`W$+@#/?-.\U_Z$=TB(N+C4]H#0]H.HS/: R/: Q/: JT#V@<$Y/5R$Z( !P M*G JN$%,3#% *S(X\W<(8#YL*G K,0.@+Z KL'5P_S]#*M,Z;SM_/(\JL"J M!4"A`= @5U!-+])H! #?0'4'@!(`*R,7D&<+8"H0QG(KL!>0<75I)](",!QS M+$:6"X '<&EZ99]"/T-/1%\K,B Q;74#`+0"JRUTCP M'J K8'8$D'D"(!Y ?Q'Q.2%?4UN@+!%;,$61,^]%T$EQ4% 'D6$!@"@Q*S+G M4( (<"_01VE@@"L4&U#727 =P"IQ8U$`<@#0*[#_6R$X\3' %R OD$CA*S$K ML!\7(%^Q`:!00BJ0,BTS_V)U(9 7( 5 *W 1L&.32/#^8E!10.,*P!Y .`#T``0````4```!213H@``````,`#33]-P``G'55 ` end From wpns@world.std.com Wed Apr 30 08:09:59 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 IAA16259 for ; Wed, 30 Apr 1997 08:09:57 -0500 (CDT) Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id JAA09763; Wed, 30 Apr 1997 09:09:56 -0400 (EDT) Received: by world.std.com (5.65c/Spike-2.0) id AA15183; Wed, 30 Apr 1997 09:09:56 -0400 From: wpns@world.std.com (William Smith) Message-Id: <199704301309.AA15183@world.std.com> Subject: SS ID using "positive AM" To: ss@tapr.org Date: Wed, 30 Apr 1997 09:09:55 -0400 (EDT) In-Reply-To: <199704300309.XAA06307@smtp3.erols.com> from "Tony McConnell" at Apr 29, 97 10:13:48 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Tony McConnell sez: >if we remain stuck with the current rules, amplitude modulate the whole >envalope. but wow what a silly idea. but not quite as silly as unique codes. 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 additional QRM won't last long, and it has the side effect of encouraging power control hardware hooks. I use AM CW to ID the output of an FMTV transmitter at 915 MHz, though I just reduce the output power to minimum for a moment, let it revert to normal in a pattern of dits and dahs, leave it at minimum for another moment, then revert to full power again. Works well, narrowband recievers whiuch are hearing a funny QRM hear that QRM doing morse every 5 minutes. Took a couple of hours to build (and a couple of days to code all the fiddly little bits to make it easily programmable and have selectable messages) with a PIC micro. A SS ID wouldn't even have to be morse, it could be AM keyed ASCII data that could be decoded with a $10 box. -- Willie Smith wpns@world.std.com N1JBJ@amsat.org #define NII Information SuperCollider From ssampson@claven.tinker.af.mil Wed Apr 30 08:10:03 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 IAA16256 for ; Wed, 30 Apr 1997 08:09:56 -0500 (CDT) Received: from localhost by othello.tinker.af.mil (AIX 4.1/UCB 5.64/4.03) id AA18010; Wed, 30 Apr 1997 08:09:50 -0500 Sender: ssampson@othello.tinker.af.mil Message-Id: <33674499.41C6@eds.tinker.af.mil> Date: Wed, 30 Apr 1997 08:09:45 -0500 From: Steve Sampson X-Mailer: Mozilla 3.01 (X11; U; AIX 1) Mime-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1309] Re:Microwave lan for 100 KM References: <202475@ronen.netmanage.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pinchook Ronen wrote: [snip] > I want to Upgrade the Speed to more then 56K > > I can also tell you that I can hear the 800 MHz Trunking station at hifa > from Mobile at Tel-aviv (100KM away) and the trunk use 25Watt > So I dont Understand Why cant it be done with Fixed station With Beem > on 2.4Ghz Does the trunking station use 10 - 20 MHz of bandwidth? A better comparison would be a television station. These use about 6 MHz of bandwidth. What's the farthest television station you can watch with a beam? Is it full-quieting (no noise)? Steve From ssampson@claven.tinker.af.mil Wed Apr 30 08:14:58 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 IAA16497 for ; Wed, 30 Apr 1997 08:14:52 -0500 (CDT) Received: from localhost by othello.tinker.af.mil (AIX 4.1/UCB 5.64/4.03) id AA17532; Wed, 30 Apr 1997 08:14:48 -0500 Sender: ssampson@othello.tinker.af.mil Message-Id: <336745C7.167E@eds.tinker.af.mil> Date: Wed, 30 Apr 1997 08:14:48 -0500 From: Steve Sampson X-Mailer: Mozilla 3.01 (X11; U; AIX 1) Mime-Version: 1.0 To: ss@tapr.org Subject: Re: [SS:1311] Re: SS ID References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernie Doehner wrote: > > [...] > > it could do so by giving each of us a unique set of fills. [snip] > The general concept sounds great, however this brings to mind something > akin to the what [phfc] are doing right now > in the frequency domain (I know I am exagerating a bit, but someone will > have to do the paper work for registering the spreading codes). I saw an interview once with an engineer who was on the ethernet protocol team. His comment was, that he wished they never settled on 48 bits. If they had used a larger word, all that registration and address blocks could have been avoided. Plan on something on the order of 128 or greater. Steve From n3jly@erols.com Wed Apr 30 09:47:21 1997 Received: from smtp1.erols.com (smtp1.erols.com [205.252.116.101]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id JAA21806 for ; Wed, 30 Apr 1997 09:47:19 -0500 (CDT) Received: from LOCALNAME (col-as3s40.erols.com [207.172.68.184]) by smtp1.erols.com (8.8.5/8.8.5) with SMTP id KAA20971 for ; Wed, 30 Apr 1997 10:47:50 -0400 Date: Wed, 30 Apr 1997 10:47:50 -0400 Message-Id: <199704301447.KAA20971@smtp1.erols.com> X-Sender: n3jly@pop.erols.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org From: Tony McConnell Subject: Re: [SS:1324] SS ID using "positive AM" At 08:12 AM 4/30/97 -0500, you wrote: >Tony McConnell sez: >>if we remain stuck with the current rules, amplitude modulate the whole >>envalope. but wow what a silly idea. but not quite as silly as unique codes. > >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? follow the thread back, i agree with the idea of am iding, if a narrow copyable id is to be done at all. i really don't think loads of unique codes are a good idea. currently i'm planning on using such a manner on a prototype. using the one output from a 9612 connected to the I port of my qam modulator to cwid on schedule, and the high speed direct digital port Q port for the actual data. this scheme when used in a band where ss is permitted would be legal. is a three dB change in level enough to be readable? 1dB and 2dB deferences can often be sensed, but can't contain much inte From aeynon@micro.ti.com Wed Apr 30 10:54:40 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 KAA28105 for ; Wed, 30 Apr 1997 10:54:38 -0500 (CDT) Received: from reliant.micro.ti.com ([158.218.63.15]) by jester.ti.com (8.8.5) with ESMTP id KAA26913 for ; Wed, 30 Apr 1997 10:54:07 -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 KAA07167 for ; Wed, 30 Apr 1997 10:54:06 -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 AAA28341 for ; Wed, 30 Apr 1997 10:54:04 -0500 Message-Id: <3.0.32.19970430105558.0068bf30@pcmail.micro.ti.com> X-Sender: aeyn@pcmail.micro.ti.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 30 Apr 1997 10:55:58 -0500 To: ss@tapr.org From: "Alan J. Eynon" Subject: SS ID summary Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Just for my own peace of mind, I compiled the following list of identification methods discussed so far: Superimpose on the spread signal -------------------------------- Method: CW keyed carrier or other narrowband superimposed ID signal timed to go off at some regular interval Advantages: * Easy to create * Familiar to narrowband users / requires no special equipment to ID Disadvantages: * Potential to interfere with weak signal users * Past experience (everyone IDs at the same time) is that this is more of an annoying joke Modulate the external characteristics of the spread signal ---------------------------------------------------------- Methods: AM the power of the spread signal to send either ID as either morse or ascii Advantages: * About as easy to create * Consonant with power control * Comprehensible to narrowband users / requires no special equipment to ID Disadvantages: * Still has potential to interfere with weak signal users (anything that could break the threshold of their theoretical most sensitive receiver) * Still requires additional transmitter complexity Internal to the spread signal ----------------------------- Methods: * originator ID# within data packets * unique spreading sequence per amateur Advantages: * Consistent with precedent (ID in the mode you're transmitting) * Requires no additional spread spectrum transmitter complexity * Causes no narrowband interference Disadvantages: * Not accessible to the narrowband users * Requires despreading the signal (which requires knowing the spreading sequence) * Method one requires a complete spread spectrum receiver outfit in order to find the originator ID# in the packet header Also, I'm unclear on what the identifier includes. Is it just the station call sign? Call sign and spreading sequence taps? Does it include transmitter power? Location? Please excuse me if this has been discussed already. 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 Wed Apr 30 11:22:41 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 LAA00373 for ; Wed, 30 Apr 1997 11:22:39 -0500 (CDT) Received: from reliant.micro.ti.com ([158.218.63.15]) by dragon.ti.com (8.8.5) with ESMTP id LAA22073 for ; Wed, 30 Apr 1997 11:22:07 -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 LAA10525 for ; Wed, 30 Apr 1997 11:22:05 -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 AAA693 for ; Wed, 30 Apr 1997 11:22:03 -0500 Message-Id: <3.0.32.19970430112357.006a15f0@pcmail.micro.ti.com> X-Sender: aeyn@pcmail.micro.ti.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 30 Apr 1997 11:23:57 -0500 To: ss@tapr.org From: "Alan J. Eynon" Subject: Re: [SS:1319] Re: SS ID Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >Remember guys, if everyone has a different spreading code you need that >unique code to hear them, fine for dedicated or point to point stuff, but >otherwise.... eh. > >and the idea that it is easy to see something on the air and that it is >easy and quick to brute force through to the pn... i don't think so. >while any of us know that ss does not totally protect a signal from >interception, >without real equipment(read big bucks) it is not easy and quick(ask >Phil, looking at where he works, he has a good idea how likely we >would be at decerning p/n codes off the air). Point taken about operating in spread spectrum. If you don't have a quick way to know what spreading sequence the transmitter is using, you're out of luck. If, however, we can leverage off the commercial CDMA hardware that's already available (and getting cheaper daily), brute force searching 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. I suppose it's a matter of outlook. If you want to reinvent all of the wheels you use, including the spreading sequence acquisition, then (yes!) it's a huge job to contemplate. If you view acquisition as a component you can buy off the shelf, like any other ASIC or discrete device, then the problem is mostly a question of deciding what sorts of sequences we want to use and how best to use the available components. >while it's seems likely we need more codes to use, an assigned codes would >be an inpediment. it would be good for us to be free to use unique codes, >i wouldn't want to be forced to. We currently have a choice between a small number of allowed (regulation) spreading sequences. If this is an impediment, then the opposite approach would be to have a large number of sequences. The largest number of sequences is when we each have our own. But you don't want to be forced to this. I don't understand; is there a "right number" for which you're aiming? Let me lay out one other thing. We all either have worked split frequency or have a general understanding of how it's done. In my view, two spread operators who're working together would do the same thing with their sequences. I transmit using one sequence, you use another. My receiver is "tuned" to your sequence, and yours is "tuned" to mine. It's completely analogous. In fact, since spread signals can overlay one another without causing interference, ideally we'd be using the same chunk of bandwidth and only "tuning" by spreading sequence. If we decide that identification is best accomplished by using an external signal parameter (I favor AM modulation of the spread power), then I think we should include the spreading sequence taps as part of the ID transmission. That way, operators who want to build their own acquisition systems will not have to rely on no brute-force searching the entire spreading sequence family. 73 Alan 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 mark@tetherless.net Wed Apr 30 12:03:35 1997 Received: from bran.pa.tetherless.com (bran.pa.tetherless.com [204.94.180.10]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id MAA02555 for ; Wed, 30 Apr 1997 12:03:33 -0500 (CDT) Date: Wed, 30 Apr 1997 12:03:33 -0500 (CDT) Message-Id: <199704301703.MAA02555@tapr.org> Received: from mark.pa.tetherless.com by bran.pa.tetherless.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id 29MFA84T; Wed, 30 Apr 1997 10:03:34 -0700 X-Sender: mark@bran.pa.tetherless.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ss@tapr.org From: mark@tetherless.net (Mark Oppenheim) Subject: Re: [SS:1325] Re:Microwave lan for 100 KM At 08:12 AM 4/30/97 -0500, Steve Sampson wrote: >Pinchook Ronen wrote: > >[snip] > >> I want to Upgrade the Speed to more then 56K >> >> I can also tell you that I can hear the 800 MHz Trunking station at hifa >> from Mobile at Tel-aviv (100KM away) and the trunk use 25Watt >> So I dont Understand Why cant it be done with Fixed station With Beem >> on 2.4Ghz I work with Spread Spectrum stuff all the time in my "real job" on both the 900, 2400 and 5700 MHz bands. Note that comparing narrowband FM to Hopping or Direct Sequence modulation is like comparing apples and oranges. Despite what many will think (there is a lot of dis-information about resistance to all types of interference that SS supposedly provides) there's a lot of difference between successfully receiving voice transmissions (where your brain is the "modem") and digital (even narrowband ones) over the same media. Multipath, fading, etc can all have detrimental effects depending on what radio and mode you use. The one big problem (outside of the regulatory issues of running excessive power on non-amateur applications) is that as the bandwidth gets wider, the receiver sensitivity drops. This is true even in 56 kb DSY packet radio systems. As I usually point out to trainees, "just do the math" to estimate range. To do this, one has to take into account: Transmitter Power Antenna Cable & filter (if any) losses Antenna Gain Receiver Sensitivity (at 10 -^6 BER) Distance (path loss as a function of operating frequency) For instance at 100 KM at 2.4 GHz, you have a path loss of a whopping 140 dB. Not only do you have to overcome this, but you should also make sure that you have some "fade margin" (signal over and above what you need to overcome your losses) - which is usually at least 15 dB. Most radios that operate from 500 kbps - 2 MBPS have sensitivities of -75 to -85 dBm (based on the BER number above), and the longer the link, there is more chance of interference, and problems with inversion layers, fresnel zones, etc. While the 100 KM link "might" be possible, there's still that sticky regulatory problem (most countries limit ERP to no more than 4 watts), and to get the radio sensitivity where it would need to be, you may have to do some bit rate/distance tradeoffs, and use a lower speed radio. Cheers- Mark ----------------------------------------------------------------------------- Mark Oppenheim Internet: MARK@TETHERLESS.COM Tetherless Access Limited Voice: (408) 523-8518 or 523-8000 930 East Arques Ave. Fax: (408) 523-8001 Fax Sunnyvale, California, 94086-4552 USA Tech Support: SUPPORT@TETHERLESS.COM Visit our WWW site! http://www.tal.net/ From djk@tobit.co.uk Wed Apr 30 16:42:26 1997 Received: from dirku.tobit.co.uk (dirku.demon.co.uk [158.152.30.189]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id QAA29350 for ; Wed, 30 Apr 1997 16:42:23 -0500 (CDT) Received: (qmail 31320 invoked by uid 500); 30 Apr 1997 21:42:08 -0000 Date: Wed, 30 Apr 1997 22:42:07 +0100 (BST) From: Dirk Koopman Reply-To: djk@tobit.co.uk To: ss@tapr.org Subject: Re: [SS:1323] RE: 1315] Re: SS ID In-Reply-To: <01BC5533.AC9573E0@gwyn> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 30 Apr 1997, Gwyn Reedy wrote: > Lyle Johnson[SMTP:lylej@azstarnet.com]said: > That is sort of what goes on in the UK, I'm told. They remain under a > requirement to use CWID, so everyone sets it to go off at 30 minutes after > the hour. Given the limited accuracy of TNC clocks, they lose about a 2-3 > minute slot each hour, but then are done with it. Does no one any good, but > fills the regulatory square. > > This gives me a small opening I think. As it stands at the moment we are required to CW ID every 30 minutes. The reason for this that the RIS (the enforcement branch of our equiv of the FCC) can't understand packet. What is curious about this stance is that in the new ETSI 300-113 European data standard (for 1200 bps !) there is a requirement to ID, but in the mode and protocol specified (ie no CW). Interestingly, although the format of the ID packet is specified, nobody quite seems to know how to fill in the fields - and that includes the RA (our FCC). To move SS forward here in UK requires someone (probably me, since no-one else seems to be much interested) to make a case for it. Now, unfortunately, it seems that the case I have make is almost like a commercial one, ie how will it benefit the human condx, will it interfere, how do we detect it, etc. 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. My specific problems right now are:- 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. 2) how can the RIS detect a transmission and identify where and who it is coming from? 3) how can an amateur determine that he is 'in band'. 4) why is SS not encryption. Specifically how can the RIS check that I not using the mode for unspeakable things? I suspect that the FCC probably have similar concerns. One of the things that regulatory authorities seem to get hung up is that if we use efficient SS, the chances are we won't appear on their $50,000 spectrum analysers/receivers 'cos we are still a number of 10s of db below their noise floor. This seems to give them the willies as we could be transmitting ANYTHING (such as rude comments about their motives :-). 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?). 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. Dirk -- Dirk-Jan Koopman Tel/Fax: +44 1362 696076 Mobile: +44 973 333806 Computer Consultant Email: djk@tobit.co.uk or G1TLH@GB7TLH.#35.GBR.EU "The typewriting machine, when played with expression, is no more annoying than the piano when played by a sister or near relation." --Oscar Wilde From lylej@azstarnet.com Wed Apr 30 21:19:32 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 VAA21643 for ; Wed, 30 Apr 1997 21:19:29 -0500 (CDT) Received: from tomswift (usr13ip28.azstarnet.com [169.197.14.28]) by mailhost.azstarnet.com (8.8.3-p/8.8.5) with SMTP id TAA16962 for ; Wed, 30 Apr 1997 19:18:55 -0700 (MST) Message-Id: <3.0.32.19970430191630.006fc270@pop.azstarnet.com> X-Sender: lylej@pop.azstarnet.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 30 Apr 1997 19:17:29 -0700 To: ss@tapr.org From: Lyle Johnson Subject: Re: SS ID Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" This has become a busy thread! I think it is important to realize that, by *allowing* ID to be done with SS, no one is *precluding* use of narrowband ID techniques. If we are able to operate unfettered in this regard, we can devbise, deploy and refine the best methods; presumably these would be better than if we were *forced* to use some specific method mandated adminstratively rather than technically or operationally. We don't have to design and propose all this by the reply closing date if we are successful in getting the ID issue left out of the rulemaking. Conversely, if we are shackled by a narrowband ID requirement, we need to compress the next ten year's experience into the next couple of days so we can get the "right" method in the rules... Cheers, Lyle