home *** CD-ROM | disk | FTP | other *** search
Text File | 1993-12-31 | 89.5 KB | 2,099 lines |
- 2-Apr-88 07:10:32-EST,665;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 2 Apr 88 07:10-EST
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02027@EDDIE.MIT.EDU>; Sat, 2 Apr 88 05:57:03 EST
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02010@EDDIE.MIT.EDU>; Sat, 2 Apr 88 05:56:42 EST
- Received: by ucscc.UCSC.EDU (5.57/1.1)
- id AA18065; Sat, 2 Apr 88 02:58:50 PST
- Date: Sat, 2 Apr 88 02:58:50 PST
- From: wm6r!wm6r@ucscc.UCSC.EDU
- Message-Id: <8804021058.AA18065@ucscc.UCSC.EDU>
- Apparently-To: packet-radio@eddie.mit.edu
-
- Please add me to the mailing list for usenet ham.packet.
- Path: ucbvax!ucscc!wm6r!packet.
- Thank you. John. wm6r!wm6r.
-
-
- 2-Apr-88 07:20:09-EST,665;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 2 Apr 88 07:20-EST
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02027@EDDIE.MIT.EDU>; Sat, 2 Apr 88 05:57:03 EST
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02010@EDDIE.MIT.EDU>; Sat, 2 Apr 88 05:56:42 EST
- Received: by ucscc.UCSC.EDU (5.57/1.1)
- id AA18065; Sat, 2 Apr 88 02:58:50 PST
- Date: Sat, 2 Apr 88 02:58:50 PST
- From: wm6r!wm6r@ucscc.UCSC.EDU
- Message-Id: <8804021058.AA18065@ucscc.UCSC.EDU>
- Apparently-To: packet-radio@eddie.mit.edu
-
- Please add me to the mailing list for usenet ham.packet.
- Path: ucbvax!ucscc!wm6r!packet.
- Thank you. John. wm6r!wm6r.
-
-
- 4-Apr-88 15:06:50-EDT,3839;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 4 Apr 88 15:06-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25195@EDDIE.MIT.EDU>; Mon, 4 Apr 88 13:33:15 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25168@EDDIE.MIT.EDU>; Mon, 4 Apr 88 13:31:56 EDT
- Message-Id: <8804041731.AA25168@EDDIE.MIT.EDU>
- Received: from amc1 by AMC-HQ.ARPA id ac05428; 4 Apr 88 13:18 EST
- Date: Mon, 4 Apr 88 13:08:19 EST
- From: "D. H. Bennett, AMCRM-FTM" <dbennett%amc1@amc-hq.arpa>
- To: packet-radio%eddie.mit.edu@amc-hq
- Subject: Type Stats for USA-PKT File
-
- Recap of USA-PKT.DBF
- As of 04-04-1988
- by K4NGC
-
- The following is a computed recap of the
- USA-PKT.DBF file I maintain. It shows the
- number and type of activities by state. If
- you have any changes to the USA-PKT.DBF
- files please address them to K4NGC @ K4NGC.
-
- State PBBS DIGI TOTAL PERCENT
- ---------------- ---- ---- ----- -------
- Alabama 15 22 37 1.66%
- Alaska 6 8 14 0.63%
- Arizona 45 17 62 2.79%
- Arkansas 9 11 20 0.90%
- California 108 89 197 8.86%
- Colorado 35 63 98 4.41%
- Connecticut 9 17 26 1.17%
- Delaware 4 2 6 0.27%
- Dist of Columbia 0 2 2 0.09%
- Florida 59 66 125 5.62%
- Georgia 26 23 49 2.20%
- Guam 0 0 0 0.00%
- Hawaii 9 11 20 0.90%
- Idaho 2 4 6 0.27%
- Illinois 23 26 49 2.20%
- Indiana 38 53 91 4.09%
- Iowa 21 30 51 2.29%
- Kansas 11 13 24 1.08%
- Kentucky 14 37 51 2.29%
- Louisiana 15 5 20 0.90%
- Maine 13 1 14 0.63%
- Maryland 52 54 106 4.77%
- Massachusetts 36 23 59 2.65%
- Michigan 35 15 50 2.25%
- Minnesota 11 8 19 0.85%
- Mississippi 13 4 17 0.76%
- Missouri 13 42 55 2.47%
- Montana 6 7 13 0.58%
- Nebraska 10 16 26 1.17%
- Nevada 1 10 11 0.49%
- New Hampshire 10 10 20 0.90%
- New Jersey 62 35 97 4.36%
- New Mexico 15 9 24 1.08%
- New York 73 65 138 6.21%
- North Carolina 15 21 36 1.62%
- North Dakota 6 1 7 0.31%
- Ohio 45 31 76 3.42%
- Oklahoma 13 22 35 1.57%
- Oregon 6 8 14 0.63%
- Pennsylvania 45 35 80 3.60%
- Puerto Rico 0 0 0 0.00%
- Rhode Island 5 5 10 0.45%
- South Carolina 7 9 16 0.72%
- South Dakota 3 9 12 0.54%
- Tennessee 18 19 37 1.66%
- Texas 37 15 52 2.34%
- Utah 9 24 33 1.48%
- Vermont 5 2 7 0.31%
- Virginia 31 50 81 3.64%
- Virgin Islands 0 0 0 0.00%
- Washington 19 20 39 1.75%
- West Virginia 8 13 21 0.94%
- Wisconsin 23 20 43 1.93%
- Wyoming 9 15 24 1.08%
- ---- ---- ---- --------
- Total 1104 1118 2223 100.00%
-
- The USA-PKT.DBF files is available on
- CompuServe to all who want it. It is also
- available on the AMRAD BBS at 703-734-1387.
- Its in text and dBase formats.
-
- Don Bennett (K4NGC)
- 15016 Carlsbad Road
- Woodbridge, Va 22193
- (Home) 703-670-4773
- (Work) 703-274-9355/56
- (BBS) 703-680-5970
- (CompuServe) 72310,263
- (ARPANET) dbennett@amc-hq.arpa
- 4-Apr-88 15:13:26-EDT,6433;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 4 Apr 88 15:13-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25172@EDDIE.MIT.EDU>; Mon, 4 Apr 88 13:32:04 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25140@EDDIE.MIT.EDU>; Mon, 4 Apr 88 13:30:18 EDT
- Message-Id: <8804041730.AA25140@EDDIE.MIT.EDU>
- Received: from amc1 by AMC-HQ.ARPA id ab05428; 4 Apr 88 13:18 EST
- Date: Mon, 4 Apr 88 13:07:40 EST
- From: "D. H. Bennett, AMCRM-FTM" <dbennett%amc1@amc-hq.arpa>
- To: packet-radio%eddie.mit.edu@amc-hq
- Subject: Stats on USA-PKT file by Frequency
-
- Recap of USA-PKT.DBF
- As of 04-04-1988
- by K4NGC
-
- The following is a computed recap of the USA-
- PKT.DBF file I maintain. It shows the number and
- type of activities by frequency. If you have any
- changes to the USA-PKT.DBF files please address
- them to K4NGC @ K4NGC.
-
- Frequency DIGI PBBS TOTAL PERCENT
- ---------------- ---- ---- ----- -------
- 7.0910 Mhz 0 1 1 0.04%
- 7.0930 Mhz 0 29 29 1.30%
- 7.0940 Mhz 0 1 1 0.04%
- 7.0970 Mhz 0 3 3 0.13%
- 7.9300 Mhz 0 1 1 0.04%
- 10.1450 Mhz 0 0 0 0.04%
- 10.1473 Mhz 0 1 1 0.72%
- 10.1490 Mhz 0 16 16 0.00%
- 14.0700 Mhz 0 0 0 0.00%
- 14.1030 Mhz 1 5 6 0.27%
- 14.1050 Mhz 0 3 3 0.13%
- 14.1070 Mhz 0 27 27 1.21%
- 14.1090 Mhz 0 21 21 0.94%
- 14.1110 Mhz 0 25 25 1.12%
- 14.1115 Mhz 0 1 1 0.04%
- 14.1490 Mhz 0 1 1 0.04%
- 28.1050 Mhz 0 7 7 0.31%
- 28.1490 Mhz 0 0 0 0.00%
- 28.2750 Mhz 0 1 1 0.04%
- 50.0900 Mhz 0 0 0 0.00%
- 51.1200 Mhz 4 0 4 0.18%
- 144.0100 Mhz 0 0 0 0.00%
- 144.1100 Mhz 0 0 0 0.00%
- 144.5100 Mhz 1 3 4 0.18%
- 144.7600 Mhz 1 1 2 0.09%
- 144.9100 Mhz 2 3 5 0.22%
- 144.9300 Mhz 2 13 15 0.67%
- 144.9500 Mhz 3 5 8 0.36%
- 144.9700 Mhz 1 10 11 0.49%
- 144.9900 Mhz 2 8 10 0.45%
- 145.0000 Mhz 2 0 2 0.09%
- 145.0100 Mhz 682 426 1108 49.84%
- 145.0300 Mhz 46 57 103 4.63%
- 145.0500 Mhz 114 121 235 10.57%
- 145.0700 Mhz 53 56 109 4.90%
- 145.0900 Mhz 58 75 133 5.98%
- 145.1100 Mhz 0 3 3 0.13%
- 145.1500 Mhz 0 3 3 0.13%
- 145.3300 Mhz 1 0 1 0.04%
- 145.3500 Mhz 0 1 1 0.04%
- 145.3600 Mhz 4 9 13 0.58%
- 145.5100 Mhz 3 1 4 0.18%
- 145.5500 Mhz 4 3 7 0.31%
- 145.5550 Mhz 1 1 2 0.09%
- 145.5700 Mhz 2 4 6 0.27%
- 145.5900 Mhz 4 2 6 0.27%
- 145.6100 Mhz 1 0 1 0.04%
- 145.6500 Mhz 1 1 2 0.09%
- 145.6600 Mhz 0 1 1 0.04%
- 145.6700 Mhz 5 2 7 0.31%
- 145.9300 Mhz 1 0 1 0.04%
- 145.9700 Mhz 0 1 1 0.04%
- 146.0700 Mhz 0 1 1 0.04%
- 146.1300 Mhz 0 1 1 0.04%
- 146.1450 Mhz 1 0 1 0.04%
- 146.7000 Mhz 0 2 2 0.09%
- 146.7300 Mhz 0 1 1 0.04%
- 146.7450 Mhz 0 1 1 0.04%
- 146.9800 Mhz 1 1 2 0.09%
- 147.0100 Mhz 1 0 1 0.04%
- 147.4800 Mhz 0 1 1 0.04%
- 147.4900 Mhz 2 3 5 0.22%
- 147.5400 Mhz 0 2 2 0.09%
- 147.5550 Mhz 12 6 18 0.81%
- 147.5600 Mhz 1 1 2 0.09%
- 147.7000 Mhz 0 1 1 0.04%
- 149.0900 Mhz 0 1 1 0.04%
- 220.0100 Mhz 0 2 2 0.09%
- 220.0600 Mhz 1 0 1 0.04%
- 220.4500 Mhz 1 0 1 0.04%
- 220.5200 Mhz 0 3 3 0.13%
- 220.5300 Mhz 0 0 0 0.00%
- 220.5500 Mhz 0 1 1 0.04%
- 220.5700 Mhz 20 4 24 1.08%
- 220.9500 Mhz 9 1 10 0.45%
- 221.0100 Mhz 21 21 42 1.89%
- 221.1000 Mhz 1 0 1 0.04%
- 221.1100 Mhz 9 34 43 1.93%
- 223.4000 Mhz 2 1 3 0.13%
- 223.4200 Mhz 1 3 4 0.18%
- 223.5000 Mhz 0 1 1 0.04%
- 223.5800 Mhz 11 18 29 1.30%
- 223.7000 Mhz 0 1 1 0.04%
- 433.8000 Mhz 0 1 1 0.04%
- 438.0000 Mhz 3 0 3 0.13%
- 441.0000 Mhz 5 10 15 0.67%
- 441.5000 Mhz 2 2 4 0.18%
- 441.9000 Mhz 1 0 1 0.04%
- 443.8000 Mhz 3 0 3 0.13%
- 445.5500 Mhz 1 0 1 0.04%
- 446.0500 Mhz 1 1 2 0.09%
- 446.1000 Mhz 0 2 2 0.09%
- 446.8000 Mhz 1 9 10 0.45%
- 446.8200 Mhz 0 2 2 0.09%
- 448.4000 Mhz 2 0 2 0.09%
- 1297.5000 Mhz 0 0 0 0.00%
- ------ ------ ------
- TOTAL 1118 1104 2223 100.00%
-
- The USA-PKT.### files is availble on CompuServe to
- all who want it. It is also available on the AMRAD
- BBS at 703-734-1386. Its in text and dBASE
- formats.
-
- Don Bennett (K4NGC)
- 15016 Carlsbad Road
- Woodbridge, Va 22193
- (Home) 703-670-4773
- (Work) 703-274-9355
- (BBS) 703-680-5970
- (CompuServe) 72310,263
- (ARPANET) dbennett@amc-hq.arpa
- 6-Apr-88 05:52:04-EDT,2562;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 6 Apr 88 05:52-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA14512@EDDIE.MIT.EDU>; Wed, 6 Apr 88 05:06:10 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA14497@EDDIE.MIT.EDU>; Wed, 6 Apr 88 05:05:30 EDT
- Message-Id: <8804060905.AA14497@EDDIE.MIT.EDU>
- Received: from DBSTU1.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 6534; Wed, 06 Apr 88 05:06:30 EDT
- Date: Wed, 06 Apr 88 11:04:06 MEZ
- To: PACKET-RADIO@MIT-EDDIE.MIT.EDU
- From: C0033003%DBSTU1.BITNET@CUNYVM.CUNY.EDU
- Comment: CROSSNET mail via SMTP@INTERBIT
- Return-Receipt-To: C0033003@DBSTU1.BITNET
- Subject: what archive for PD software ?
-
-
- NORD><LINK - The northern Germany Packet Radio development Group
- ----------------------------------------------------------------
-
- Well, easter holidays are over and we 're glad to be in time.
-
- THE FIRMWARE
- Compatibel. Portabel. Public Domain.
-
- THE FIRMWARE is an upgraded version of the well known WA8DED 2.1 Hostmode
- Software for TNC2. Some bugs have been fixed and some extensions are instal-
- led, and it's available right now.
-
- Now is the problem to distribute the software.
- We have a hexdump available at the moment ( INTEL - hexdump )
- but this one is more than 90 KB long. So I'd like to depose it in an
- archive somewhere instead of posting it here. Any suggestions for that ?
-
- (*) WA8DED 2.1 Hostmodesoftware, Copyright by Ron Raikes, WA8DED
-
-
- THE NET
- Compatibel. Portabel. Public Domain.
-
- We included a further feature in the firmware: The Ident-command has on 1.3
- been upgraded to an Info-command ( but it's still an 'I' ). With this
- version you can burn additional info messages into the EPROM ( we use
- City, qth-locator, working frequency, responsible SysOP's callsign).
- Furthermore the sysop can post a short info-message ( even from remote)
- for everyone who connects the node ( e.g.: NODE DOWN FOR MAINTENANCE
- FRIDAY 5 P.M.)
-
- This one ( release 0.9 ) could be posted in the next week. But the
- question is where or how. It's > 90 KB as a hexdump, source is much
- more.
-
- THE FIRMWARE and THE NET are
-
- - free for non-commercial users
- - ||| public domain source code for non-commercial users |||
- ||| (95% C, 5% Assembler) |||
-
- 73s de Detlef ( DK4EG )
- C0033003 at DBSTU1.BITNET
-
- NORD><LINK
- c/o Detlef J. Schmidt
- Steinbrecherstr.22
- D3300 Braunschweig
- FRG
- 7-Apr-88 15:11:51-EDT,789;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 Apr 88 15:11-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00220@EDDIE.MIT.EDU>; Thu, 7 Apr 88 11:30:18 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00181@EDDIE.MIT.EDU>; Thu, 7 Apr 88 11:29:48 EDT
- Received: by leg.ai.mit.edu; Thu, 7 Apr 88 10:46:52 EDT
- Date: Thu, 7 Apr 88 10:46:52 EDT
- From: mac@leg.ai.mit.edu (Michael Chepponis)
- Message-Id: <8804071446.AA02260@leg.ai.mit.edu>
- To: packet-radio@eddie.mit.edu
- Subject: NORD><LINK a hoax?
-
- I received a piece of BBS mail from Bob, NK8T, saying he thought that the
- NORD><LINK P.D. NET/ROM software is a hoax, as he tried to contact the folks
- but his mail was returned.
-
- Does anybody know if this stuff is real? Tnx -Mike k3mc
- 7-Apr-88 17:47:37-EDT,1503;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 Apr 88 17:47-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA04782@EDDIE.MIT.EDU>; Thu, 7 Apr 88 16:26:11 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA04778@EDDIE.MIT.EDU>; Thu, 7 Apr 88 16:25:59 EDT
- Received: by june.cs.washington.edu (5.52.1/6.13)
- id AA10740; Thu, 7 Apr 88 13:26:47 PDT
- Return-Path: <tektronix!orca!leia!tomk@beaver.cs.washington.edu>
- Message-Id: <8804072026.AA10740@june.cs.washington.edu>
- From: tektronix!orca!leia!tomk@beaver.cs.washington.edu (Tom Kloos)
- To: PACKET-RADIO@EDDIE.MIT.EDU
- Subject: TAPR 1.1.5 w/KISS EPROM
- Keywords: wrong checksum
- Date: 6 Apr 88 17:47:28 GMT
-
- A few weeks ago I received the 1.1.5 with KISS EPROM for my TNC-2 from
- TAPR. It works great, except that the checksum is displayed as $25
- rather than the $85 as claimed by the release notes. Did TAPR screw up
- burning the EPROM or is $25 really correct? The startup banner
- displays a date of 12/14/87 and the Data-I/O checksum is CBC9. The
- release notes are dated 3/8/88.
-
- Another note about TAPR.... I received TCP/IP floppies from them at the
- end of February. It was the original 871225.1 release. Is anyone
- sending TAPR the latest and greatest patches as they appear? Wasn't at
- least 871225.4 available by late January?
-
- -Tom Kloos, WA7NJK, Tektronix, Wilsonville, Oregon tomk@leia.GWD.TEK.COM
- {ucbvax,decvax,uw-beaver,hplabs,ihnp4,allegra}!tektronix!tekecs!leia!tomk
-
-
- 7-Apr-88 23:51:47-EDT,1079;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 Apr 88 23:51-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA12959@EDDIE.MIT.EDU>; Thu, 7 Apr 88 22:42:49 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA12949@EDDIE.MIT.EDU>; Thu, 7 Apr 88 22:42:27 EDT
- Received: by leg.ai.mit.edu; Thu, 7 Apr 88 22:44:31 EDT
- Date: Thu, 7 Apr 88 22:44:31 EDT
- From: mac@leg.ai.mit.edu (Michael Chepponis)
- Message-Id: <8804080244.AA03454@leg.ai.mit.edu>
- To: tektronix!orca!leia!tomk@beaver.cs.washington.edu
- Cc: PACKET-RADIO@eddie.mit.edu
- In-Reply-To: Tom Kloos's message of 6 Apr 88 17:47:28 GMT <8804072026.AA10740@june.cs.washington.edu>
- Subject: TAPR 1.1.5 w/KISS EPROM
-
- Tom, it is likely that TAPR didn't update their doc; if the TNC works, then
- $25 is probably correct.
-
- TAPR is updated regularly. The versions that appear on louie.udel.edu are
- interem ones, and may not be fully debugged. I do know that another new
- major release is planned soon, and I'm sure TAPR will ship that when it becomes
- available.
-
- Best -Mike k3mc
- 8-Apr-88 14:46:29-EDT,4230;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 8 Apr 88 14:46-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25732@EDDIE.MIT.EDU>; Fri, 8 Apr 88 12:15:53 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25709@EDDIE.MIT.EDU>; Fri, 8 Apr 88 12:15:20 EDT
- Message-Id: <8804081615.AA25709@EDDIE.MIT.EDU>
- Received: from DBSTU1.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 7983; Fri, 08 Apr 88 12:16:49 EDT
- Date: Fri, 08 Apr 88 17:08:43 MEZ
- To: PACKET-RADIO@MIT-EDDIE.MIT.EDU
- From: C0033003%DBSTU1.BITNET@CUNYVM.CUNY.EDU
- Comment: CROSSNET mail via SMTP@INTERBIT
- Return-Receipt-To: C0033003@DBSTU1.BITNET
- Subject: manual addendum 'TheNet'
-
- NORD><LINK
- The northern Germany packet-radio development group
-
- Following is the description of the user manual of TheNet. Only the
- differences to the original manual are listed.
- Remember: Distribution is free for noncommercial applications, but
- we're not responsible for any kind of use or the results of any bugs.
-
- Further infos will come up the next days and will be posted here.
- ---------------------cut here-------------------------------------------
-
-
- TheNet Version 1.0 07-04-88
-
- TheNet is fully compatible to NET/ROM (*) version 1.3. The following descrip-
- tion contains only the changes for users and sysops.
-
- (* NET/ROM is a registered trademark of Software 2000 Inc.)
-
- Userinterface
- =============
-
- The command "IDENT" has been replaced by a new command "INFO".
- The digipeater will send:
- 1. it's mnemonic identifier and the call
- 2. a message contained in the EPROM
- 3. a remote programable message
-
- Example:
-
- BS:DB0FC> NORD><LINK \
- Braunschweig <JO55GH> \
- 5W, GP, 144.675 MHz > plain ASCII text in EPROM header
- OP: DK4EG @ DK0MAV /
- /
- friday 5 p.m. node down for maintenance > loaded from remote
-
-
- All system messages contain no characters with special national meaning (e.g.
- 7e HEX).
-
-
- Sysop interface:
- ================
-
- All sysop commands will only work after a successfull execution of "SYSOP".
-
- changed commands:
- -----------------
-
- 1. INFO (former IDENT)
- Store a message of up to 80 characters. Longer input will be truncated.
- Minimum length is 1 character. To clear the message you have to input a new
- message. A period is sufficient. Only after a coldstart this message will be
- cleared. So a power failure is easily detectible.
-
- 2. RESET
- RESET will do a coldstart. The whole RAM is initialized. All parameters are
- taken from EPROM. The INFO message is cleared. The password is taken from
- EPROM.
- Unlike with NET/ROM there is no argument necessary.
-
-
- new commands
- ------------
-
- 1. HIGH portnumber
- Output portnumber is activated (relais engaged, LED on).
- Portnumber = 0 activates the CONNECT-LED output, portnumber = 1 the STATUS-
- LED output.
-
- 2. LOW portnumber
- Output portnumber is deactivated (relais disengaged, LED off).
- Portnumber = 0 desactivates the CONNECT-LED output, portnumber = 1 the
- STATUS-LED output.
-
-
- other changes:
- -------------
-
- 1. TheNet is capable of fullduplex activity. The commands may only be given on
- the host terminal. With <ESC> D 0 you switch to halfduplex and with <ESC> D 1
- you switch to fullduplex. By a constant in EPROM you decide to send flags
- while there is no activity on the transmitter or keep the transmitter quiet.
-
- 2. All default parameters are contained in a list at the beginning of the
- EPROM. This includes call and mnemonic identifier of the digipeater as well as
- the default password. So remote access is possible even after a total power
- failure.
-
-
-
- If you have further questions or any other comments, feel free to contact
-
- NORD><LINK
- c/o Hans Georg Giese DF2AU
- Hinter dem Berge 5
- 3300 Braunschweig
- FRG
-
- or DK4EG
- -----
- 73s de Detlef ( DK4EG )
- Computing center
- University Brunswick
-
- C0033003 at dbstu1.bitnet
- C0033003%DBSTU1.BITNET@MITVMA.MIT.EDU
- C0033003%DBSTU1.BITNET@umd2.umd.edu")
- c0033003%dbstu1.bitnet%cunyvm.cuny.edu@BRL.ARPA
- CUNYVM.CUNY.EDU!C0033003%DBSTU1.BITNET@ucbvax.Berkeley.EDU
- etc...
- 11-Apr-88 17:44:41-EDT,1532;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Apr 88 17:44-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA03130@EDDIE.MIT.EDU>; Mon, 11 Apr 88 16:10:32 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA01930@EDDIE.MIT.EDU>; Mon, 11 Apr 88 15:30:14 EDT
- Received: by BITSY.MIT.EDU (5.45/4.7) id AA28231; Mon, 11 Apr 88 15:31:52 EDT
- Date: Mon, 11 Apr 88 15:31:52 EDT
- From: Ron M. Hoffmann <hoffmann@BITSY.MIT.EDU>
- Message-Id: <8804111931.AA28231@BITSY.MIT.EDU>
- To: info-hams@SIMTEL20.ARPA, packet-radio@EDDIE.MIT.EDU
- Cc: hoffmann@BITSY.MIT.EDU
- Subject: FCC database on CD-ROM
-
- The following is reproduced from "CD-ROM REVIEW" March/April 1988,
- Page 6, without permission. News of packet is showing up in the
- strangest places!
-
- _Hamming it Up_
-
- Two Virginia amateur radio enthusiasts have successfully
- transmitted the first CD-ROM database over packet radio. Jack Speer
- of Mineral used his packet station to connect with Jim DeArras in
- Richmond (about 40 miles away). DeArras provided a multiuser PBBS
- (packet bulletin board service) and interface software. Speer, using
- an Hitachi 1502S CD-ROM drive, transmitted Buckmaster Publishings's
- database of more than 472,000 radio amateurs. The demo disc was
- prepared by another ham, Bill Harlow of PDSC.
-
- Though the Buckmaster disk is not commercially available, hams
- can test the CD-ROM by contacting DeArras (WA4ONG-10). At the PBBS
- prompt, type: OS QTH N1BIC followed by a carriage return.
-
- via WA2EYC
- 11-Apr-88 19:45:16-EDT,15311;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Apr 88 19:45-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA04929@EDDIE.MIT.EDU>; Mon, 11 Apr 88 17:19:20 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00695@EDDIE.MIT.EDU>; Mon, 11 Apr 88 14:56:53 EDT
- Received: by june.cs.washington.edu (5.52.1/6.13)
- id AA12353; Mon, 11 Apr 88 11:01:31 PDT
- Return-Path: <mtunx!whuts!homxb!hou2d!n2dsy@RUTGERS.EDU>
- Message-Id: <8804111801.AA12353@june.cs.washington.edu>
- Date: 7 Apr 88 19:37:26 GMT
- From: mtunx!whuts!homxb!hou2d!n2dsy@RUTGERS.edu (G.BEATTIE)
- To: PACKET-RADIO@EDDIE.MIT.EDU
- Subject: Asynchronous Framing Technique Document File: AFT.DOC
- Keywords: AFT, a SLIP alternative
-
- Here is the document file that I promised last week describing
- the Asynchonous Framing Technique (AFT). This is only a
- framing protocol. It contains NO state machine, transparency
- and error control.
-
- Four files will follow this message(but only in comp.protocols.tcp-ip):
-
- 1. AFT.C - a machine independent implementation of the AFT software.
- 2. ASYNC.ASM - an MS-DOS device driver to use with AFT.
- 3. TEST1.C - a test and demo programme for the AFT software.
- 4. Test2.C - another test and demo programme for the AFT software.
-
- The file contained in this message is AFT.DOC.
-
- If you like what you see here in the document file, go to the
- newsgroup "comp.protocols.tcp-ip" and pull the other four files.
-
-
-
-
-
-
-
-
-
- Machine Independent Asynchronous Framing Technique (AFT)
-
- Version 1.0, by John Howell (N2FVN), August 7, 1987
-
- This software is in the public domain. It is provided on an
- 'as is' basis without warranty.
-
- This is a portable implementation of the Asynchronous
- Framing Technique for X.25 (X.25/AFT) Revision 2 coded in
- the C language. AFT is a protocol which allows X.25 style
- framing to be done over an asynchronous communication
- channel. It allows for detection of the start and end of
- frames, detection of corrupted transmission, and sending of
- frames containing eight bit characters over communication
- links which cannot accept all possible characters.
-
- AFT is intended to be used as a replacement for the X.25
- level two framing technique in cases where synchronous
- communication is not practical.
-
- For more information on X.25/AFT contact:
-
- Research Department
- Hayes Microcomputer Products, Inc.
- 705 Westech Drive
- Norcross, Georgia 30092
-
- This implementation of AFT supports all features of revision
- two of the protocol. A method is provided to select which
- of the possible options are to be used. The implementation
- has three components:
-
- 1) Option Selection
- 2) Frame Transmission
- 3) Frame Reception
-
- The interface to the user of AFT was chosen to allow use of
- the software in many different environments. As provided
- this software requires additional machine dependant software
- to provide a full AFT implementation. The transmit and
- receive routines have been implemented in such a way that
- they may be called either within interrupt service routines
- as characters are sent and received or they may be called
- from non-interrupt routines which fill or empty queues used
- by the software doing the hardware dependant portion of the
- I/O.
-
- This implementation provides no actual routines to do I/O
- since this is highly machine dependant.
-
- In this program the terms bytes and characters are used as
- synonyms for eight bit groups of data which are known as
- octets in X.25. This program assumes that the
- implementation of type 'char' is an eight bit value. Also
-
-
-
-
-
-
-
-
-
-
-
- the type 'int' is assumed to be at least 16 bits in size.
-
- An attempt has been made to only use those features of C
- which are common to nearly all implementations. This code
- was actually tested using Microsoft C version 4.0.
-
- Some abbreviations used in this program are:
-
- FCS Frame Check Sequence
- LEN Length
- OPT Option
- RX Receive
- SUB Substituted
- TX Transmit
-
-
-
-
-
-
- Interface to External Routines
-
- The following routines make up the interface to the AFT
- implementation. It is assumed that the user is familiar
- with the C language.
-
-
-
- aft_options(ebdt, transparency_level, suffix_len,
- suffix, max_rx_len)
-
- This routine selects the options to be used for AFT
- communication. It must be called at least once before any
- other AFT routines are used. It may be called again later
- to change the previously selected options. This should only
- be done at a time when no frames are being sent or received.
-
- 'ebdt' is a flag (0=false, non-zero=true) which determines
- whether the eight-bit data transparency option is to be used
- on transmit and receive. The EBDT option should only be
- used in cases where the communication path does not transfer
- the high order bit of characters transparently. This option
- must be selected identically on both the sending and
- receiving sides of the link. Use of this feature adds an
- extra 14% overhead to the communications.
-
- 'transparency_level' takes on one of three values. Zero
- indicates that basic transparency is to be used. This
- should be selected when the communication path allows
- transparent transmission of all 256 possible characters. One
- indicates that flow control transparency is to be used.
- This should be selected when the transmission of X-on and X-
- off characters would cause the receiver to perform flow
- control which would prevent them from appearing within
- frames. Two indicates that control-character transparency
-
-
-
-
-
-
-
-
-
-
-
- is to be used. This should be selected when the transmission
- path does not allow transparent transmission of some control
- characters. Each higher numbered option adds more overhead
- to transmitted frames.
-
- 'suffix_len' is the length of a string which will be
- appended to each frame when it is sent. This feature is
- used to provide any extra characters which the receiving
- system may require to recognize the end of an input. Zero
- should be used when no frame suffix is to be added which is
- the most common case. The maximum suffix allowed is three
- characters.
-
- 'suffix' is a pointer to the actual character string in
- which the suffix is stored. This is only examined if the
- suffix length is non-zero. This string may contain up to
- three characters which may each be any value.
-
- 'max_rx_len' is the size of the buffer which will be used
- for receiving frames. This length is used by the receive
- frame routines to prevent storing data past the end of the
- buffer. Received frames which are too long will be
- discarded. The receive buffer provided must be at least two
- characters larger than the maximum expected frame size.
- This is required since buffer is used for temporary storage
- of the two character frame check sequence.
-
-
-
- int aft_tx_start(length, buffer)
-
- This is the routine used to do the setup for transmitting a
- frame. This routine returns a value of zero if a new frame
- cannot be started because a frame is already being sent, or
- a value of one if the request is accepted. In either case
- this routine returns immediately. The actual sending of the
- frame is done by aft_tx_char.
-
- 'length' is the length of the frame to be sent. The minimum
- valid frame length is two characters. The maximum is
- limited only by the restrictions of the C compiler used.
-
- 'buffer' is a pointer to the buffer holding the frame to be
- sent. This buffer should contain only the address, control,
- and information fields for the frame. The AFT routines will
- generate starting and closing flags, frame check sequence,
- and other characters required for transparency when the
- frame is sent. AFT will not modify the contents of the
- buffer. The buffer contents should not be modified by any
- other routines until transmission of the frame is completed
- or an incorrect frame may be sent.
-
-
-
- int aft_tx_char()
-
-
-
-
-
-
-
-
-
-
-
- This routine is used to obtain the next character to be sent
- in order to transmit a frame. It returns characters to be
- sent as a value from zero to 255 in the low order byte of
- the returned integer and zero in the high order byte of the
- integer. Once the final character of the frame has been
- sent the return value will be one in the high order byte and
- a flag character in the low order byte.
-
- This routine is designed to be either used as a non-
- interrupt routine to which is called in a loop to fill an
- outgoing buffer which will be sent by other software or
- called within an interrupt routine when a transmitter buffer
- empty condition occurs to provide the next character to be
- sent. When used in an interrupt routine the caller may
- ignore the upper byte of the return value. If this is done
- then the result will be to send continuous flags between
- frames.
-
-
-
- aft_tx_abort()
-
- This routine may be called to cause aft_send_char to abort
- the frame it is currently sending. A lead-in character is
- sent followed by a flag to indicate that the receiver should
- ignore the frame. It a frame is not being sent then no
- action is taken.
-
-
-
- int aft_tx_complete()
-
- This routine is intended to be used in cases where
- aft_tx_char is being called during interrupt service. It
- provides a way for non-interrupt routines to poll for frame
- sending completion. It returns zero if a frame is currently
- being sent or one if no frame is being sent. A frame is
- considered to be sent once aft_tx_char is about to return
- the frame complete code (0x017E) to its caller. Instead of
- using this routine aft_tx_char may be easily modified to
- take any desired action when sending of a frame is
- completed.
-
-
-
- int aft_rx_start(buffer)
-
- This routine provides a buffer for the AFT software to use
- to receive a frame into. This routine returns a value of
- zero if the buffer is not accepted because a receive
- operation is already in progress or a value of one if the
- buffer is accepted. In either case this routine returns
- immediately to its caller.
-
- 'buffer' is a pointer to the buffer into which the frame
-
-
-
-
-
-
-
-
-
-
-
- will be received. This buffer will be filled one character
- at a time by aft_rx_char as characters for the frame are
- received. Once the receive operation is completed this
- buffer will hold the received frame address, control, and
- information fields. All flags, FCS, and extra transparency
- characters will have been removed.
-
-
-
- int aft_rx_char(c)
-
- This routine accepts a received character and adds it to the
- frame being received. If aft_rx_start has not been called
- to provide a buffer for receive then the first few
- characters of the frame will be saved in a temporary buffer.
- This will prevent loss of data in cases where aft_rx_char is
- being called directly by the receive interrupt service
- routine. This routine can also be called by a non-interrupt
- routine which obtains the characters from a received
- character queue. A value of zero is returned if this
- character does not complete a frame. A non-zero return
- value indicates that the character provided completed the
- received frame. In this case the value returned is the
- length of the frame which is contained in the receive
- buffer.
-
- If an invalid FCS is received at the end of the frame then
- the frame will be discarded. A frame of less than two bytes
- will also be discarded.
-
- 'c' is the next character received from the communication
- port.
-
-
-
- aft_rx_error()
-
- This routine is called to indicate the occurrence of an
- error condition on the communication line. Possible
- conditions may be framing error, break received, parity
- error (if in EBDT mode), time out (which is not required for
- AFT), or overrun. When this routine is called AFT discards
- the frame currently being received and begins searching for
- the start of the next frame.
-
- int aft_rx_complete()
-
- This routine is used in cases where aft_rx_char is being
- called during interrupt service. It provides a way for non-
- interrupt routines to poll for completion of a receive
- operation. It returns zero if the receive operation has not
- completed and the received frame length if it has. After
- this routine returns that a frame has completed then
- aft_rx_start should be called as quickly as possible to
- provide a new receive buffer. If this is not done in time
-
-
-
-
-
-
-
-
-
-
-
- then the next incoming frame may be lost. Instead of using
- this routine aft_rx_char may be easily modified to take any
- desired action when sending of a frame is completed.
-
-
- 11-Apr-88 20:18:57-EDT,17854;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Apr 88 20:18-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA01262@EDDIE.MIT.EDU>; Mon, 11 Apr 88 11:26:52 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA01243@EDDIE.MIT.EDU>; Mon, 11 Apr 88 11:26:18 EDT
- Received: by june.cs.washington.edu (5.52.1/6.13)
- id AA04658; Mon, 11 Apr 88 08:26:33 PDT
- Return-Path: <osu-cis!n8emr!gws@EDDIE.MIT.edu>
- Message-Id: <8804111526.AA04658@june.cs.washington.edu>
- Date: 11 Apr 88 00:42:18 GMT
- From: osu-cis!n8emr!gws@EDDIE.MIT.edu (Gary Sanders)
- To: PACKET-RADIO@EDDIE.MIT.EDU
- Subject: gateway vol 4.12
- Distribution: usa
-
- Bulletin ID: KC8TW_11150
- Path: W8CQK!AD8I!N8NN!WA8JXM!KC8TW
-
-
- =====================================================
- >>Relayed from W8CQK packet BBS to N8EMR ham BBS...<<
- >>Ham BBS, Columbus,Oh. 614-457-4227 (300/1200,8N1)<<
- =====================================================
-
- Gateway: The ARRL Packet Radio Newsletter
-
- Stan Horzepa, WA1LOU, Editor
-
- Vol. 4, No. 12 March 4, 1988
-
- NEW VERSION OF W0RLI PBBS NOW AVAILABLE
-
- Version 4.5 of the W0RLI/VE3GYQ Packet Radio Bulletin Board System software
- has been released. It is available from the usual sources or may be
- downloaded from the HamNet DL9 Data Library of CompuServe. If you have
- Version 4.4, you need only download the special file MBEXE.ARC to get the
- changes. Others should download RUN45.ARC (the executable code) and
- SRC45.ARC (the sources).
-
- >from CompuServe's HamNet (note from N8XX - the latest version is 4.52)
-
- AMSAT-TAPR DIGITAL SIGNAL PROCESSING PROJECT UPDATE
-
- Steve Sagerian, KA0YRE, of Motorola has really come through for the digital
- signal processing (DSP) project. He arranged for the DSP operations branch
- of Motorola to come up with two 56001 EXP kits. This kit comes with bare
- boards, boot ROMS (a debugger, monitor), PALs and several manuals. Just to
- get things rolling in a hurry, they decided to be very generous and throw
- in two DSP56001 chips. This board has a 20.48-MHz clock and processes
- 10.25-million instructions per second. Using the architecture to its
- fullest, one could do a 1024-point Fourier transform in 3.48 ms. Steve and
- Bob McGwier, N4HY, will be building up these two units. We may expect
- further support from Motorola as they get applications back from us. We
- wish to thank Motorola, Inc for their generous support.
-
- >from Bob McGwier, N4HY, via CompuServe's HamNet
-
-
- NEW TAPR OFFICERS ELECTED
-
- At the February 21 annual meeting of Tucson Amateur Packet Radio Corp
- (TAPR), the following officers were announced as elected by the Board of
- Directors: President Andy Freeborn, N0CCZ; Vice President Tom Clark, W3IWI;
- and Secretary-Treasurer Scott Loftesness, W3VS. In addition, an Executive
- Committee was appointed by the board to run the day-to-day affairs of the
- organization. The Executive Committee consists of the above three officers
- plus Directors Lyle Johnson, WA7GXD, David Toth, VE3GYQ, and Harold Price,
- NK6K.
-
- >from Scott Loftesness, W3VS via CompuServe's HamNet
-
-
- UoSAT-C SPACECRAFT TO BE BUILT AT UNIVERSITY OF SURREY
-
- The UoSAT Spacecraft Engineering Research Unit at the University of Surrey
- in the United Kingdom is now building a third UoSAT- OSCAR spacecraft -
- UoSAT-C. NASA has agreed to provide a launch for UoSAT-C on a DELTA launch
- vehicle currently scheduled for late 1988. The DELTA should place UoSAT-C
- into a 43-degree- inclination, 500-km circular orbit.
-
- UoSAT-C will carry experimental engineering, science and communications
- payloads developed in close collaboration between international
- professional engineering and Amateur Radio communities. These payload
- experiments develop further the mission objectives supported by the highly
- successful UoSAT-1 and 2 (UoSAT-OSCAR-9 and UoSAT-OSCAR-11) satellites
- which are still operational after six and four years in orbit,
- respectively. The UoSAT program and series of satellites are intended to
- complement the AMSAT-OSCAR, RS and FUJI-OSCAR Amateur Radio communications
- satellites by providing a space science and engineering facility readily
- available to both amateur and professional experimenters alike, thus,
- generating a greater mutual awareness and collaboration.
-
- UoSAT-C, like the previous UoSAT missions, will have a strong element of
- international collaboration - specifically with members of AMSAT-UK,
- AMSAT-NA in the United States and Canada, VITA, Quadron, NASA, the British
- National Space Centre and the European Space Agency.
-
- UoSAT-C Payloads
-
- o Store-And-Forward Communications
-
- Since 1983, UoSAT has played a major role in an international collaborative
- project developing cost-effective digital store- and-forward satellite
- communications techniques. The UoSAT-OSCAR- 11 Digital Communications
- Experiment (DCE), funded by the Volunteers In Technical Assistance (VITA)
- and built by VITA/AMSAT volunteers in the US, UK and Canada, provided the
- first operational tests of store-and-forward PACSAT communications within
- the amateur satellite service. Drawing on the operational and engineering
- data gained from the DCE, UoSAT and VITA are developing a high performance
- digital store-and-forward communications payload specially tailored for use
- by inexpensive ground stations. To test this payload, UoSAT-C will carry
- the PACSAT Communications Experiment (PCE). The PCE will be openly
- accessible to radio amateurs operating in the 2-meter and 70-cm bands
- (Mode-J). VITA is seeking additional frequency allocations outside the
- amateur bands to allow limited use of the UoSAT-C PCE by VITA ground
- stations in remote areas to provide technical assistance and disaster
- relief.
-
- o Radiation Studies Experiments
-
- Microprocessor-controlled payloads such as the PCE cannot be built without
- VLSI semiconductors and most recent and affordable VLSI devices have not
- yet been tested for space use. UoSAT-C will host several experimental
- payloads studying the effects of the space radiation environment on VLSI
- devices:
-
- Cosmic Particle Experiment (CPE), comprising an array of large- area PIN
- diodes, will detect energetic particles which cause single event upsets
- (SEUs) in VLSI circuits (such as high-density RAMs).
-
- CCD Single Event Upset Experiment (CCD-SEU), comprising an enclosed
- charge-coupled device (CCD) array, will detect energetic cosmic particles
- and evaluate the effect of SEUs on CCD imagers. This data is of particular
- importance for scientists using sensitive CCDs as star sensors.
-
- Total Dose Experiment (TDE), using special FETs located around the
- spacecraft, will measure the total radiation dose accumulated by the
- on-board subsystems and payloads. These dose measurements will allow
- engineers to assess the shielding properties of the spacecraft structure
- and to correlate changes in LSI-device power consumption and performance
- with total radiation dose.
-
- o Satellite Technology Experiments
-
- UoSAT-C will carry a range of satellite technology experiments associated
- with power systems, on-board data handling (OBDH), attitude determination,
- control and stabilization (ADCS) and RF modulation.
-
- o Power
-
- The spacecraft will be powered from GaAs solar cells and will include
- experimental patches of novel GaAs, InPe and Si solar cells with a variety
- of newly-developed cover-slides. The performance of these cells will be
- monitored throughout the mission as a function of radiation dose. The
- spacecraft on-board computers will constantly monitor and adjust the
- Battery Charge Regulator and Power Conditioning Module to optimize power
- conversion and storage efficiency.
-
- o On-Board Computers
-
- UoSAT-C will include several computers. In addition to the primary RCA1802
- on-board computer (OBC-1) running DIARY-type software, there will be a more
- powerful 80C86-based, OBC-2 supporting complex attitude control algorithms
- and spacecraft data networks. Four transputers in a parallel-processing
- array will be available for highly sophisticated on-board image and data
- processing and the PCE will employ an 80C186-family computer to manage
- high-speed communications links and several megabytes of RAM.
-
- A wide range of memory devices using different technologies and
- architectures will make up a total on-board capacity of around 5 megabytes
- of RAM. The radiation-induced effects on the processors and associated
- memories will be monitored and evaluated throughout the lifetime of the
- spacecraft. The network of computers on UoSAT-C will make this spacecraft
- the most computationally powerful of its class and will support demanding
- experiments in advanced spacecraft attitude determination and control, data
- communications and image processing.
-
- o Attitude Determination and Control
-
- The 43-degree-inclination, non-sun-synchronous nature of the UO-C orbit
- will necessitate the use of new attitude determination and control
- mechanisms to maintain accurate Earth pointing. In addition to more-complex
- attitude control algorithms executed by OBC-2, improved analog and digital
- sun sensors and Earth horizon sensors are being developed at UoS for the
- mission.
-
- o Digital Signal Processing
-
- If time and resources permit, a Digital Signal Processing Experiment may be
- included on UO-C to evaluate modulation/demodulation schemes.
-
- o Modular Construction
-
- A new concept of highly modular construction has been developed and is
- under test for UoSAT-C. This new, modular structure should result in much
- improved utilization of the available spacecraft envelope, greater ease of
- assembly and integration and allow a more rapid response to future launch
- opportunities.
-
- For The Users
-
- Like UO-9 and UO-11, UoSAT-OSCAR-C will support a worldwide user community
- of engineers, scientists, educators and communicators. If all goes
- according to plan, UO-C will provide spacecraft housekeeping telemetry,
- long-term telemetry surveys, results from on-board experiments, news
- bulletins and communications facilities on a single downlink through
- packet-radio techniques. We will finalize and publish communications modem
- and protocol details as soon as possible to allow ground stations to equip
- themselves.
-
- While numerous international teams are already collaborating on UO-C, UoSAT
- is interested in hearing from others interested in possible collaboration,
- especially in the area of user ground station support.
-
- The UoSAT team are happy to be able to make a public announcement of the
- UoSAT-C mission and we hope that it will contribute to the long history of
- successful and technically important OSCAR and RS missions and maintain the
- tradition of international collaboration in the amateur satellite service.
-
- >from Dr. Martin Sweeting, G3YJO,
- Director of Satellite Engineering,
- University of Surrey
-
- THE "STAGGERED BACKBONE" NETWORK CONCEPT
-
- Florida's packet radio network has undergone many evolutionary changes over
- the last several years. First, there were many individual packeteers
- connecting over long distances on quiet channels. Then, as more people
- joined in, dedicated digipeaters were pressed into service. Then came
- switches, the 220-MHz backbone and, most recently, NET/ROM. At a Southern
- Region Wide Area Networking Symposium, I proposed what I believe will be
- the next evolutionary step in the development of our network. I call it
- the "Staggered Backbone."
-
- We knew a long time ago that as the number of users and PBBSs grew, it
- would become impractical to move traffic between portions of the network on
- the same 2-meter RF channels that were shared by the users. We also knew
- that packeteers in adjacent towns would cause unnecessary interference to
- each other as they all tried to access their local digipeater and hear each
- other. We, therefore, moved towards an architecture in our network that
- allowed users in a given area (called a Local Area Network, LAN) to reside
- on a different 2-meter channel than their neighbors. We tied all of the
- LANs together using the 220-MHz band. This is roughly where the network
- stands today.
-
- There is still room for improvement. We have discovered that the same
- problems of "hidden transmitters" (where two stations cannot hear each
- other and, therefore, transmit at the same time) and "hold off" (where a
- station is prevented from transmitting for long periods of time because of
- other traffic) exist on the backbone and cause the same congestion there as
- on 145.010 MHz. Because the number of stations which access the backbone
- directly is deliberately kept small, the problem is minimized to a certain
- extent, but not eliminated.
-
- Another problem which confronts the current backbone structure is the issue
- of how to increase its speed in the future. With all of the nodes on the
- backbone operating at 1200 bauds, speeding things up might require that
- every node upgrade on the same day (an impossible situation) or that some
- nodes move to a different frequency, thus, breaking the backbone.
-
- The staggered backbone solves many of these problems and has a great
- potential for allowing a significant increase in the overall network
- throughput. The staggered backbone concept is built upon the fact that
- NET/ROM software allows a three-port or four-port node to be assembled
- quite easily. Three ports allow the node to operate on three separate
- frequencies (or bands) at the same time and to route packets between them.
-
- In a network with a staggered backbone, most nodes would consist of three
- TNCs and three transceivers operating on the 144, 220 and 440-MHz bands
- (other bands may be used as appropriate). The 144-MHz port serves the local
- users on a preassigned LAN frequency and connects to the other ports via a
- special serial port cable and diode matrix. The 220-MHz port handles the
- transfer of information to neighbors in one direction; the 440- MHz port
- handles information going in another direction. The reason for choosing
- three separate ham bands is to minimize interference between the radios
- without the need for costly tuned cavities and special filters.
-
- The staggered backbone works best where the network topology is basically
- linear. Where Y-shaped splits in the network are required, the options are
- to use still another band (eg, 900 MHz) in place of 144 MHz (resulting in a
- dedicated three-port backbone node with no LAN service), construct a
- four-port node (to serve the node plus three backbone frequencies) or to
- stick with the current scheme of having three different background nodes on
- a common frequency (this last option should only be used if the three nodes
- can all hear each other clearly).
-
- A list of the benefits of using a staggered backbone follow.
-
- 1. Since there are only two nodes on any given backbone radio link,
- "hidden transmitter" and "hold off" are completely eliminated from these
- links. In fact, the only place that packets can collide (besides on the
- LAN) is in the cable that mates the TNCs at the node. And, since
- communication between TNCs typically runs at 4800 or 9600 bauds and does
- not include TXDELAYS and long DWAITS, the TNCs can recover from collisions
- on the cable very quickly. Also, all of the TNCs talking on the cable can
- hear each other clearly, so there are no "hidden transmitters" there.
-
- 2. The speed of any individual link can be increased at any time without
- creating a logistics nightmare. In fact, whenever two adjacent nodes agree
- that they are prepared to go faster, they can do it at their convenience.
- The only thing that the rest of the network will notice is improved
- performance and some temporary down time while they switch over.
-
- 3. Backbone nodes can take advantage of directional antenna systems to
- "squirt" all of their signals to a specific neighbor instead of having to
- use omnidirectional antennas or directional antennas with power splitters.
- So, in addition to the improvements gained by having a quieter channel,
- many nodes would see an increased signal strength from their neighbors.
-
- 4. Automatic routing table updates managed by the nodes can be trusted
- again. In many areas, nodes are operating with "permed" tables because of
- NET/ROM's tendency to hear a distant broadcast and add it to a routing
- table as a high quality path. With less traffic on the same frequency and
- directional antennas in use, the chances of this happening are greatly
- reduced.
-
- The transition from the current backbone to a staggered backbone is very
- straight forward and, equipment costs aside, could be accomplished in a
- short time. Many of the nodes along the Florida Gold Coast have made plans
- to proceed along this line; the backbone link from Boca Raton to Hollywood
- will probably be the first to move to 440 MHz on a permanent basis
- sometimes early this year. We hope that others will join us and continue
- to strive for improvements in the network in all areas.
-
- >from Bill Piazza, KB4QVY @ W4NVC via FADCA>Beacon
-
- GATEWAY CONTRIBUTIONS
-
- Submissions for publication in Gateway are welcome. You may submit
- material via the US mail to:
-
- Gateway
- Stan Horzepa, WA1LOU
- 75 Kreger Drive
- Wolcott, CT 06716-2702
-
- or electronically, via CompuServe to user ID 70645,247. Via
- telephone, your editor can be reached at 203-879-1348 on evenings
- and weekends, and he can switch a modem on line to receive text
- at 300, 1200, or 2400 bauds.
-
-
- REPRODUCTION OF GATEWAY MATERIAL
-
- Material may be excerpted from Gateway without prior permission,
- provided that the original contributor is credited and Gateway is
- identified as the source.
-
- --
- Gary W. Sanders {cbosgd|ihnp4}!osu-cis!n8emr!gws
- (cis) 72277,1325 (packet) N8EMR @ W8CQK
- HAM/SWL BBS (HBBS) 614-457-4227.. 300/1200 bps
-
-
- 15-Apr-88 20:03:50-EDT,1465;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Apr 88 20:03-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA07012@EDDIE.MIT.EDU>; Fri, 15 Apr 88 18:56:19 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA07003@EDDIE.MIT.EDU>; Fri, 15 Apr 88 18:56:02 EDT
- Received: by june.cs.washington.edu (5.52.1/6.13)
- id AA10346; Fri, 15 Apr 88 15:47:03 PDT
- Return-Path: <ll-xn!ames!ucsd!brian@EDDIE.MIT.EDU>
- Message-Id: <8804152247.AA10346@june.cs.washington.edu>
- Date: 14 Apr 88 23:53:22 GMT
- From: ll-xn!ames!ucsd!brian@EDDIE.MIT.edu (Brian Kantor)
- To: PACKET-RADIO@EDDIE.MIT.EDU
- Subject: Re: HK232 RF noise
- Keywords: RF noise, HK232, PK232
- References: <258@gandalf.littlei.UUCP>
- Reply-To: brian@UCSD.edu (Brian Kantor)
-
- I have not examined the Heath version, but my PK-232 radiated like a
- sonofabitch! Here's what I did to make it tolerable:
-
- Star lockwashers under brass screws to hold the cabinet together
-
- Scrape and polish the cabinet so that the top and bottom made good
- contact.
-
- Replace DC power feed with a Pi-net RFI feedthrough (looks like a
- feedthrough-bypass capacitor but has more guts inside).
-
- Bolt the sockets down so that RS232 cable really does get grounded.
-
- Sprinkle a few bypasses (.001) onto the various lines going to
- transceiver, power supply, etc.
-
- Stick conductive metal tape over all the unused connector holes.
-
- Brian Kantor WB6CYT UC San Diego brian@ucsd.edu
-
-
- 16-Apr-88 00:23:41-EDT,991;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Apr 88 00:23-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA12938@EDDIE.MIT.EDU>; Fri, 15 Apr 88 23:30:21 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA12908@EDDIE.MIT.EDU>; Fri, 15 Apr 88 23:29:55 EDT
- Received: from huey.udel.edu by Louie.UDEL.EDU id aa06869; 15 Apr 88 23:27 EDT
- Date: Fri, 15 Apr 88 23:25:27 EDT
- From: Mills@UDEL.EDU
- To: Brian Kantor <brian@ucsd.edu>
- Cc: PACKET-RADIO@eddie.mit.edu
- Subject: Re: HK232 RF noise
- Message-Id: <8804152325.aa26778@Huey.UDEL.EDU>
-
- Brian,
-
- My PK232 is quiet as a lamb, but my Heath GC1000 clock radiates like a
- banshee. Boy, before all this computer stuff, I could work the microvolts
- right through ten meters. Now, you can use the spurs from the neighbor's
- PC, stereo and watch as beacons for fuxhunts. Try probing near your
- multiplexed frequency display of your radio with a wire connected to the
- antenna jack...
-
- Dave
- 16-Apr-88 16:59:40-EDT,1954;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Apr 88 16:59-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25853@EDDIE.MIT.EDU>; Sat, 16 Apr 88 16:09:33 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25849@EDDIE.MIT.EDU>; Sat, 16 Apr 88 16:09:24 EDT
- Received: by june.cs.washington.edu (5.52.1/6.13)
- id AA04237; Sat, 16 Apr 88 13:08:33 PDT
- Return-Path: <bellcore!faline!thumper!karn@EDDIE.MIT.edu>
- Message-Id: <8804162008.AA04237@june.cs.washington.edu>
- Date: 14 Apr 88 20:03:09 GMT
- From: bellcore!faline!thumper!karn@EDDIE.MIT.edu (Phil R. Karn)
- To: PACKET-RADIO@EDDIE.MIT.EDU
- Subject: Re: HK232 RF noise
- Summary: RS-232 line filters
- Keywords: RF noise, HK232, PK232
- References: <258@gandalf.littlei.UUCP>
-
- > I purchased and built the Heathkit HK-232 multimode controller last
- > week. Unfortunately it generates incredible amounts of RF noise,
- > particularly at every MHz from about 40 to 165 MHz. To make matters
- > worse, this noise radiates primarily from the cable which connects the
- > TNC to the radio.
-
- Go to a hamfest and get some RS-232 line filters. They consist of male
- and female DB-25 connectors on opposite ends of a small metal housing,
- resembling small "null modems". The pins are connected straight through,
- but each each line is individually bypassed to the case. Often there is
- "finger stock" on the sides of the "D" part of the connector to ensure
- good, continuous ground contact.
-
- Mount one of these connectors on the back of your PK-232, and make sure
- that the shell is well bonded to the case. Also put one on the back of
- your computer or terminal. If the RFI is in fact being conducted out
- the serial line and then radiating, this should help the problem
- enormously.
-
- I picked up a handful of filters at the Timonium MD hamfest for $4.00
- each, the going price. I put them on everything, the back of my PCs, my
- TNCs, modems, etc.
-
- Phil
-
-
- 16-Apr-88 17:02:22-EDT,1689;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Apr 88 17:02-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25892@EDDIE.MIT.EDU>; Sat, 16 Apr 88 16:11:53 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25886@EDDIE.MIT.EDU>; Sat, 16 Apr 88 16:11:39 EDT
- Received: by june.cs.washington.edu (5.52.1/6.13)
- id AA04299; Sat, 16 Apr 88 13:10:49 PDT
- From: tektronix!reed!percival!littlei!collier@beaver.cs.washington.edu
- Return-Path: <tektronix!reed!percival!littlei!collier@beaver.cs.washington.edu>
- Message-Id: <8804162010.AA04299@june.cs.washington.edu>
- Date: 13 Apr 88 14:24:36 GMT
- To: PACKET-RADIO@EDDIE.MIT.EDU
- Subject: HK232 RF noise
- Keywords: RF noise, HK232, PK232
-
- I purchased and built the Heathkit HK-232 multimode controller last
- week. Unfortunately it generates incredible amounts of RF noise,
- particularly at every MHz from about 40 to 165 MHz. To make matters
- worse, this noise radiates primarily from the cable which connects the
- TNC to the radio. Since the local packet frequency is 144.99, the spur
- on 145 MHz pretty much prevents operation with any station less than
- full strength into my receiver.
-
- Has anyone else dealt with this problem? The noise is apparently based
- on the 4 MHz Z80 CPU clock. The local Heathkit store sent the unit back
- to Michigan for "repair". Needless to say, if I'm out the $280 for the
- TNC, I'll *NEVER* build another Heathkit. I figured I was safe (*HA*!)
- since this is the same unit that AEA builds, right down to the AEA copyright
- on the circuit board.
-
- Thanks in advance,
-
- Collier Chun
- NM7B
- Intel Corporation
- OEM Platforms Operation
- Hillsboro, Oregon
-
-
- 17-Apr-88 01:38:25-EDT,1395;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 17 Apr 88 01:38-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02812@EDDIE.MIT.EDU>; Sun, 17 Apr 88 00:41:54 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02799@EDDIE.MIT.EDU>; Sun, 17 Apr 88 00:41:31 EDT
- Received: from huey.udel.edu by Louie.UDEL.EDU id aa25247; 17 Apr 88 0:23 EDT
- Date: Sun, 17 Apr 88 0:20:00 EDT
- From: Mills@UDEL.EDU
- To: "Phil R. Karn" <bellcore!faline!thumper!karn@eddie.mit.edu>
- Cc: PACKET-RADIO@eddie.mit.edu
- Subject: Re: HK232 RF noise
- Message-Id: <8804170020.aa05044@Huey.UDEL.EDU>
-
- Phil,
-
- Since I have several computers and other hash generators cluttering up the
- shack, I have had to mount a pretty mean spur-control program myself. I first
- tried using shielded cables with unshielded hoods and the shiled grounded at
- one end, but this did not work effectively. I did find that shileded cables
- with metal hoods, the shield bonded to the hoods at each end and the hoods
- securely contacted to the hash-generator case worked very well. I found that,
- if shielded cables are used everywhere and the cabinets and power connections
- are tight, the hash is pretty well controlled. My biggest problem now is a
- a Heath GC-1000 clock, which leaks hash back up the antenna lead, and the various
- video displays, which radiate right off the screens.
-
- Dave
- 19-Apr-88 01:42:40-EDT,3917;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 19 Apr 88 01:42-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA07062@EDDIE.MIT.EDU>; Tue, 19 Apr 88 00:43:05 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA07046@EDDIE.MIT.EDU>; Tue, 19 Apr 88 00:42:32 EDT
- Received: by june.cs.washington.edu (5.52.1/6.13)
- id AA06534; Mon, 18 Apr 88 21:43:55 PDT
- Return-Path: <hou2d!n2dsy@EDDIE.MIT.edu>
- Message-Id: <8804190443.AA06534@june.cs.washington.edu>
- Date: 18 Apr 88 17:36:16 GMT
- From: hou2d!n2dsy@EDDIE.MIT.edu (G.BEATTIE)
- To: PACKET-RADIO@EDDIE.MIT.EDU
- Subject: RATS Open Systems Environment (ROSE) Forum at the 1988 Dayton Hamvention
- Keywords: RATS ROSE Open Systems OSI ISO CCITT Amateur Radio
-
-
-
-
- The Radio Amateur Telecommunications Society
-
- 206 North Vivyen Street
-
- Bergenfield, New Jersey 07621
-
-
- 201-387-8896
-
- The Radio Amateur Telecommunications Society (RATS) is proud to present
-
- a forum at the 1988 Dayton Hamvention called:
-
- ROSE: Open Systems Networking in the RATS Open Systems Environment
-
- The talk will focus on the reality of Open Systems
- Networking in Amateur Radio. The Society has been involved
- in the development of mail/file/directory servers and
- networking software based on international communications
- standards.
-
- Radio Amateurs who are telecommunications professionals or
- packet radio users will find this talk especially
- interesting and enlightening, but the novice networker will
- have no trouble following the presentation.
-
- * Software Distribution
-
- Currently, the beta version of the ROSE X.25 Packet Switch
- and the release of the ROSErver/Packet Radio MailBox System
- are available. The Society will distribute the latest
- releases of its software at the session. Bring 5-1/4 or 3-
- 1/2 inch diskettes for software and documentation. Remember
- RATS distributes its software for free! Come and get it!
-
- * Where to Find RATS at Dayton
-
- Members of RATS will be present in the PAC-COMM Packet Radio
- Systems booth (Booth 277/278). Members will be able to
- demonstrate and copy software for you to take home and use.
- Handouts describing our activities and frequencies of
- operation will be distributed at the packet forum on Friday
- afternoon from 1-5. We also are planning to be available
- for the Packet Get-Together at McNasty's on Saturday
- evening.
-
-
- The RATS ROSE Forum
-
- Time: 9:30 - 11:00
-
- Place: ROOM 1 (check your programme to be sure)
-
- The forum will consist of three three 30 minute talks. Each
- will explore an aspect of the Open Systems implemented by
- the Radio Amateur Telecommunications Society (RATS).
- Questions will be taken by each speaker.
-
- Schedule
-
- 09:30 Review of Open Systems Networks and Protocols
-
- - Presented by J. Gordon Beattie, Jr., N2DSY
-
- This talk will provide an overview of a network
- based on Open Systems. The specific protocols
- and user services will be defined alone with the
- network management and planning dependencies found
- in a cooperative network.
-
- 10:00 The ROSE X.25 Packet Switch
-
- - Presented by Thomas A. Moulton, W2VY
-
- This talk will concentrate on the OSI Network Services
- and how the ROSE X.25 Switch will support the users of
- "vanilla" AX.25, OSI Applications, TCP/IP and Net/ROM.
-
- 10:30 The ROSErver Mail, File and Directory Server
-
- - Presented by Andrew R. Funk, KB7UV
-
- This talk will concentrate on OSI Application Services
- and how the ROSErver/Packet Radio Mail Box System will
- provide these services to users and other systems.
-
-
- 19-Apr-88 15:48:13-EDT,1638;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 19 Apr 88 15:48-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02104@EDDIE.MIT.EDU>; Tue, 19 Apr 88 13:36:21 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02087@EDDIE.MIT.EDU>; Tue, 19 Apr 88 13:35:58 EDT
- Received: by june.cs.washington.edu (5.52.1/6.13)
- id AA03524; Tue, 19 Apr 88 10:37:25 PDT
- Return-Path: <cornell!batcomputer!sun.soe.clarkson.edu!nelson@eddie.mit.edu>
- Message-Id: <8804191737.AA03524@june.cs.washington.edu>
- Date: 19 Apr 88 15:33:59 GMT
- From: cornell!batcomputer!sun.soe.clarkson.edu!nelson@eddie.mit.edu (Russ Nelson)
- To: PACKET-RADIO@EDDIE.MIT.EDU
- Subject: Re: TCP/IP at Dayton and Trenton
- Keywords: TCP IP ARPA Internet KA9Q
- References: <1983@hou2d.UUCP> <1054@thumper.bellcore.com>
- Reply-To: sun.soe.clarkson.edu!nelson@june.cs.washington.edu (Russ Nelson)
-
- In article <1054@thumper.bellcore.com> karn@thumper.bellcore.com (Phil R. Karn) writes:
- >The KA9Q Internet Protocol Package will also be described and
- >demonstrated at both the Trenton Computer Festival ...
- >The entire package, which includes complete C source code ...
- >I will bring a limited supply of copies, but bring your own blank disks
- >if you want to be sure of getting a copy. ...
-
- I'll give Phil a few copies of my Turbo C porting kit on 5 1/4 360 K
- disks.
-
- The porting kit is updated to version 871225.18, and is on clutx.clarkson.edu
- [128.153.4.3] in pub/Ka9q/kit.arc via anonymous ftp.
- --
- char *reply-to-russ(int network) {
- if(network == BITNET) return "NELSON@CLUTX";
- else return "nelson@clutx.clarkson.edu"; }
-
-
- 19-Apr-88 16:15:38-EDT,2595;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 19 Apr 88 16:15-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02142@EDDIE.MIT.EDU>; Tue, 19 Apr 88 13:37:59 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA01105@EDDIE.MIT.EDU>; Tue, 19 Apr 88 13:08:38 EDT
- Received: by june.cs.washington.edu (5.52.1/6.13)
- id AA17025; Tue, 19 Apr 88 07:13:04 PDT
- Return-Path: <bellcore!faline!thumper!karn@EDDIE.MIT.EDU>
- Message-Id: <8804191413.AA17025@june.cs.washington.edu>
- Date: 19 Apr 88 05:59:05 GMT
- From: bellcore!faline!thumper!karn@eddie.mit.edu (Phil R. Karn)
- To: PACKET-RADIO@EDDIE.MIT.EDU
- Subject: TCP/IP at Dayton and Trenton
- Summary: KA9Q TCP/IP software available at Dayton
- Keywords: TCP IP ARPA Internet KA9Q
- References: <1983@hou2d.UUCP>
-
- The KA9Q Internet Protocol Package will also be described and
- demonstrated at both the Trenton Computer Festival and at the Dayton
- Hamvention. This package is now estimated to be in the hands of at
- least several thousand people around the world, and it is enjoying
- rapidly increasing popularity on amateur packet radio. It presently
- supports the following proven, industry standard protocols:
-
- Applications:
-
- Telnet - remote login and "chatting"
- FTP - File transfer (binary or text)
- SMTP - Mail transfer
-
- Transport/Session:
-
- TCP - Transmission Control Protocol
- UDP - User Datagram Protocol
-
- Network:
-
- IP - Internet Protocol
- ICMP - Internet Control Message Protocol
-
- Link/Subnet:
-
- ARP - Address Resolution Protocol
- Ethernet - 3Com 3C-501 interface driver
- AX.25 - packet radio (both connected and unconnected modes)
- SLIP - asynchronous point-to-point links
-
- The primary machine supported is the IBM PC (and clones). Versions are also
- available for the Apple Macintosh, Commodore Amiga, and UNIX System V.
-
- The entire package, which includes complete C source code and
- documentation, is copyrighted by myself and others, but it is completely
- FREE for noncommercial use. I encourage you to make copies for your
- friends back home; this minimizes the number of copies I have to make.
-
- I will bring a limited supply of copies, but bring your own blank disks
- if you want to be sure of getting a copy. The package fits on one
- high-density 1.2 meg 5.25" floppy, two 720K 3.5" floppies, or three 360K
- 5.25" floppies. I should be able to handle all three formats at both
- Trenton and Dayton.
-
- For those of you with Internet access, you may obtain the package by
- anonymous FTP from louie.udel.edu (10.0.0.96) under /pub/ka9q.
-
- 73, Phil Karn, KA9Q
-
-
- 20-Apr-88 14:07:01-EDT,3806;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 20 Apr 88 14:07-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00171@EDDIE.MIT.EDU>; Wed, 20 Apr 88 11:48:55 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00113@EDDIE.MIT.EDU>; Wed, 20 Apr 88 11:47:08 EDT
- Received: by tecnet-clemson.arpa (5.52/SMI-3.2)
- id AA28728; Wed, 20 Apr 88 05:18:25 EST
- Date: Wed, 20 Apr 88 05:18:25 EST
- From: q2mgb@tecnet-clemson.arpa
- Message-Id: <8804201018.AA28728@tecnet-clemson.arpa>
- To: &radio
- Posted: Apr 20 04:57 EST
- Subject: Re: HK232 RF noise
-
-
- Subject: radio: Re: HK232 RF noise
-
- >From: tektronix!reed!percival!littlei!collier@beaver.cs.washington.edu
- > I purchased and built the Heathkit HK-232 multimode controller last
- > week. Unfortunately it generates incredible amounts of RF noise,
- > particularly at every MHz from about 40 to 165 MHz. To make matters
- > worse, this noise radiates primarily from the cable which connects the
- > TNC to the radio.
-
- >Collier Chun
- >NM7B
- >Intel Corporation
- >OEM Platforms Operation
- >Hillsboro, Oregon
-
- >>From: bellcore!faline!thumper!karn@EDDIE.MIT.EDU (Phil R. Karn)
- >>Go to a hamfest and get some RS-232 line filters. They consist of male
- >>and female DB-25 connectors on opposite ends of a small metal housing,
- >>resembling small "null modems". The pins are connected straight through,
- >>but each each line is individually bypassed to the case. Often there is
- >>"finger stock" on the sides of the "D" part of the connector to ensure
- >>good, continuous ground contact.
-
- >>From: ll-xn!ames!ucsd!brian@EDDIE.MIT.EDU (Brian Kantor)
- >>Star lockwashers under brass screws to hold the cabinet together
- >>Scrape and polish the cabinet so that the top and bottom made good
- >>contact.
- >>Replace DC power feed with a Pi-net RFI feedthrough (looks like a
- >>Bolt the sockets down so that RS232 cable really does get grounded.
- >>Sprinkle a few bypasses (.001) onto the various lines going to
- >>transceiver, power supply, etc.
- >>Stick conductive metal tape over all the unused connector holes.
-
- All good suggestions. I'll try to add one more. My problems were from a
- Kantronics KAM and a MFJ-1274B and I found one of the biggest radiators
- of the noise was the power cord (unshielded) to the TNC's. Right up there
- with that was the 232 cable and the cabling to the radio as previously
- noted above. A quick and dirty trick that you can use AFTER you have
- replaced all wiring with shielded cable and bypassed all signal lines,
- is to run the power line, the 232 cable, and the radio hookup wiring
- through toroidal inductors, one for each of the three above. Run at
- least three (or more) turns of the cable through the toroid. Place the
- toroids as close as possible to the source of the noise. i.e. The TNC.
- Use of ferrite beads on all non-data lines is also recommended. The use
- of ferrite beads on the actual data lines can be hazardous due to roll
- off on the edges of the square waves causing distortion at high baud
- rates. However, running shielded multi-wire cabling though a large
- toroid will not affect the signals on the internal wires. This will be
- very effective in choking the RF off the shield and especially off the
- power wiring.
-
- Although it may seem like a lot of work, if you follow all the suggestions
- listed here and above, I can guarantee that your noise will not only be
- reduced to tolerable levels but will be almost completely eliminated. If
- on the OFF CHANCE that you still have a birdie sitting smack dab right
- on top of the frequency you want to use, a LAST DITCH method is to SLIGHTLY
- bump the 4 MHZ clock freq. This should not be done until all the other
- methods have been attempted.
-
- Mark Bitterlich
- WA3JPY
- Iwakuni Japan
- q2mgb@tecnet-clemson.arpa
- 20-Apr-88 17:13:26-EDT,2234;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 20 Apr 88 17:13-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA05853@EDDIE.MIT.EDU>; Wed, 20 Apr 88 15:26:20 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA05833@EDDIE.MIT.EDU>; Wed, 20 Apr 88 15:25:47 EDT
- Message-Id: <8804201925.AA05833@EDDIE.MIT.EDU>
- Received: from DBSTU1.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 7313; Wed, 20 Apr 88 15:05:49 EDT
- Date: Tue, 19 Apr 88 17:43:42 MEZ
- To: PACKET-RADIO@MIT-EDDIE.MIT.EDU
- From: C0033003%DBSTU1.BITNET@CUNYVM.CUNY.EDU
- Comment: CROSSNET mail via SMTP@INTERBIT
- Subject: shipment of TheNet
-
- NORD><LINK
- The northern Germany packet-radio development group
-
- Thanks again to all OMs who supported me with UUENCODE / UUDECODE.
- Unfortunatly this is not a reliable method for transfering files
- over several gateways. I've tried it forward and backward again
- and the files got scrambled after several EBCDIC / ASCII -conversions.
- So I decided to post an INTEL-Hexdump of our TheNet firmware
-
- We started shipment to all OMs who sent direct mail and included the
- cost for the shipment this week.
-
- If you're interested to get your copy look in the SIMTEL20 archive.
- I'll depose it there this week but I can't tell how to access it from
- there because there is no link between EARN/BITNET and SIMTEL20 for
- anonymous FTP ( or is there one in the meantime? ).
-
- All you have to do to make up your EPROM is to produce a header of the
- EPROM ( your DIGI's callsign, ID, default password, etc.) append the
- rest of the binary file and burn it into a 27(C)256. But remember not
- to change the layout of the header, because some store&forward software
- relies on the structure of the header.
-
- You should keep the release note and the originator sign too. This
- will make it possible to identify any unknown bugs (if there are any).
-
- 73s de Detlef ( DK4EG )
-
- Detlef J.Schmidt
- Steinbrecher Str.22
- D3300 Braunschweig
- F.R.G.
-
- C0033003 at dbstu1.bitnet
- C0033003%DBSTU1.BITNET@MITVMA.MIT.EDU
- C0033003%DBSTU1.BITNET@umd2.umd.edu")
- c0033003%dbstu1.bitnet%cunyvm.cuny.edu@BRL.ARPA
- CUNYVM.CUNY.EDU!C0033003%DBSTU1.BITNET@ucbvax.Berkeley.EDU
- etc...
- 21-Apr-88 12:04:36-EDT,1215;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 Apr 88 12:04-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA03144@EDDIE.MIT.EDU>; Thu, 21 Apr 88 10:36:27 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA03135@EDDIE.MIT.EDU>; Thu, 21 Apr 88 10:36:11 EDT
- Received: by june.cs.washington.edu (5.52.1/6.13)
- id AA18368; Thu, 21 Apr 88 07:36:29 PDT
- Return-Path: <hplabs!hpcea!hpnmd!hpsrla!glenne@UCBVAX.Berkeley.edu>
- Message-Id: <8804211436.AA18368@june.cs.washington.edu>
- Date: 20 Apr 88 14:41:22 GMT
- From: hplabs!hpcea!hpnmd!hpsrla!glenne@UCBVAX.Berkeley.edu (Glenn Elmore)
- To: PACKET-RADIO@EDDIE.MIT.EDU
- Subject: Re: TCP/IP at Dayton and Trenton
- References: <1054@thumper.bellcore.com>
-
- Phil,
-
- Your TCP/IP package has also been ported to the Atari ST. I don't have it
- in MY hands yet, but DG2KK has told me he has 12/25/87.4 running fine.
- I am awaiting reiceipt of it and will do my best to disseminate it among the
- ST users I know who are interested. He is also sending me his modified source
- so I should be able to port more current versions myself, as time permits.
-
- 73, Glenn
-
- Glenn Elmore -N6GN-
-
- N6GN @ N6IIU-1
- glenne@hpsrla.HP.COM
-
-
- 21-Apr-88 18:30:04-EDT,2581;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 Apr 88 18:30-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA13845@EDDIE.MIT.EDU>; Thu, 21 Apr 88 17:29:56 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA13829@EDDIE.MIT.EDU>; Thu, 21 Apr 88 17:29:16 EDT
- Message-Id: <8804212129.AA13829@EDDIE.MIT.EDU>
- Received: from DBSTU1.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 2454; Thu, 21 Apr 88 17:30:43 EDT
- Date: Thu, 21 Apr 88 10:43:01 MEZ
- To: PACKET-RADIO@MIT-EDDIE.MIT.EDU
- From: C0033003%DBSTU1.BITNET@CUNYVM.CUNY.EDU
- Comment: CROSSNET mail via SMTP@INTERBIT
- Return-Receipt-To: C0033003@DBSTU1.BITNET
- Subject: posting TheNet
-
- NORD><LINK
- The northern Germany packet-radio development group
-
- This is the 2nd trial to post this info. Maybee there's a big
- black data hole somewhere ( or a sink in the Bermuda triangle? ).
- So here it comes:
-
- Thanks again to all OMs who supported me with UUENCODE / UUDECODE.
-
- Unfortunatly this is not a reliable method for transfering files
- over several gateways. I've tried it forward and backward again
- and the files got scrambled after several EBCDIC / ASCII -conversions.
- So I decided to post an INTEL-Hexdump of our TheNet firmware which
- contains only uncritical characters.
-
- We started shipment of TheNet to all OMs who sent direct mail and
- included the cost for the shipment this week.
-
- If you're interested to get your copy of TheNet take a look into the
- SIMTEL20 archive. I'll try to depose it there this week but I can't
- tell how to access it from there because there is no link between
- EARN/BITNET and ARPA for anonymous FTP ( or is there one in the
- meantime? ). For european BITNET-users I'll depose the hexdump in
- the archive of FINHUTC.
-
- All you have to do to make up your EPROM is to produce a header of the
- EPROM ( your DIGI's callsign, ID, default password, etc.) append the
- rest of the binary file and burn it into a 27(C)256. But remember not
- to change the layout of the header, because some store&forward software
- relies on the structure of the header.
-
- You should keep the release note and the originator sign too. This
- will make it possible to identify any unknown bugs (if there are any).
-
- 73s de Detlef ( DK4EG )
-
- Detlef J.Schmidt
- Steinbrecher Str.22
- D3300 Braunschweig
- F.R.G.
-
- C0033003 at dbstu1.bitnet
- C0033003%DBSTU1.BITNET@MITVMA.MIT.EDU
- C0033003%DBSTU1.BITNET@umd2.umd.edu")
- c0033003%dbstu1.bitnet%cunyvm.cuny.edu@BRL.ARPA
- CUNYVM.CUNY.EDU!C0033003%DBSTU1.BITNET@ucbvax.Berkeley.EDU
- etc...
- 26-Apr-88 21:22:40-EDT,742;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 26 Apr 88 21:22-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00382@EDDIE.MIT.EDU>; Tue, 26 Apr 88 15:54:36 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00361@EDDIE.MIT.EDU>; Tue, 26 Apr 88 15:53:45 EDT
- Message-Id: <8804261953.AA00361@EDDIE.MIT.EDU>
- Received: from amc1 by AMC-HQ.ARPA id ac23702; 26 Apr 88 16:46 EDT
- Date: Tue, 26 Apr 88 15:44:23 EDT
- From: Dbennett%AMC1@amc-hq.arpa
- To: packet-radio%eddie.mit.edu@amc-hq
- Subject: Question?
-
- Does anyone know the status of the German NetROM Clone that was to be
- placed in simtel20 download area. If it already has can some one give
- me the full path name.
-
- Don Bennett (K4NGC)
- 27-Apr-88 15:56:02-EDT,2921;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 Apr 88 15:56-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA27994@EDDIE.MIT.EDU>; Wed, 27 Apr 88 14:34:05 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA27976@EDDIE.MIT.EDU>; Wed, 27 Apr 88 14:33:34 EDT
- Message-Id: <8804271833.AA27976@EDDIE.MIT.EDU>
- Received: from DBSTU1.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 6751; Wed, 27 Apr 88 14:35:29 EDT
- Date: Wed, 27 Apr 88 11:34:38 MEZ
- To: PACKET-RADIO@MIT-EDDIE.MIT.EDU
- From: C0033003%DBSTU1.BITNET@CUNYVM.CUNY.EDU
- Comment: CROSSNET mail via SMTP@INTERBIT
- Return-Receipt-To: C0033003@DBSTU1.BITNET
- Subject: TheNet distribution, some hints
-
-
- NORD><LINK
- The northern Germany packet-radio development group
-
- Meanwhile I've sent the INTEL-hexdump of our TheNet to SIMTEL20. But I
- don't have access to anonymous FTP from our BITNET here so I can't
- check if it's available there. Just try it if you're interested to get
- it.
- If someone would like to distribute it in USA via BITNET just
- give me a short input and I'll send another copy to you. But I don't
- like to send it many times across the atlantic via email because
- that's pretty expensive.
- For european BITNET-users I'll post the file at FINHUTC. I've tried
- it several times befor, but without success. I'll keep on trying.
-
- We're still working on the source of TheNet to make it look clean,
- especially updating all the comments. It should be available about
- july.
-
- If you've got your copy of the hexdump it is one of two versions:
-
- 1st version starts like this
- :10000000C34A010000000000C3407D000000000062
- :10001000C3277D0000000000C3357D000000000004
- :10002000C3377D0000000000C3F27D000000000027
- :.......
- it's about 96kB long.
- This one needs only be chanched for your individual parameters. Then
- burn it into a 27(C)256 plug into a TNC2 an go.
-
- 2nd version starts like this:
- :20010000C34A010000000000C3407D0000000000C3277D0000000000C3357D000000000075
- :20012000C3377D0000000000C3F27D0000000000C3117D0000000000C3D17C4E4F3144455E
- :2001400020605448454E4554320001006400FF000600050008070A002C0102000600B400B4
- :........
- it's about 78kB (less overhead than version 1.)
- This complete hexdump has to be shifted 100hex downwards, which means
- hexdump-address $100 corresponds to EPROM-address 0. After shifting it
- downwards change your individual parameters and proceed like in the
- 1st version.
-
- Both versions should be the same, the difference is only in the notation
- of the hexdump.
-
- Let me know if you run into trouble with it.
-
- 73s de Detlef ( DK4EG )
-
- Detlef J.Schmidt
- Steinbrecher Str.22
- D3300 Braunschweig
- F.R.G.
-
- C0033003 at dbstu1.bitnet
- C0033003%DBSTU1.BITNET@MITVMA.MIT.EDU
- C0033003%DBSTU1.BITNET@umd2.umd.edu")
- c0033003%dbstu1.bitnet%cunyvm.cuny.edu@BRL.ARPA
- CUNYVM.CUNY.EDU!C0033003%DBSTU1.BITNET@ucbvax.Berkeley.EDU
- etc...
- 28-Apr-88 12:45:14-EDT,1479;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 28 Apr 88 12:45-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA21218@EDDIE.MIT.EDU>; Thu, 28 Apr 88 11:04:26 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA21177@EDDIE.MIT.EDU>; Thu, 28 Apr 88 11:02:02 EDT
- Message-Id: <8804281502.AA21177@EDDIE.MIT.EDU>
- Received: from DBSTU1.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 1129; Thu, 28 Apr 88 11:03:07 EDT
- Date: Thu, 28 Apr 88 11:56:56 MEZ
- To: PACKET-RADIO@MIT-EDDIE.MIT.EDU
- From: C0033003%DBSTU1.BITNET@CUNYVM.CUNY.EDU
- Comment: CROSSNET mail via SMTP@INTERBIT
- Subject: RFC 987 required
-
- Hello OMs,
-
- could someone out in networld be so kind and send me the RFC 987
- proposal|? It's said to describe the PR PBBS recommendations
- ( must be a new one ?|).
-
- Thanks in advance.
-
- 73s de Detlef ( DK4EG )
-
- Detlef J.Schmidt Computing Center
- Steinbrecher Str.22 University Brunswick
- D3300 Braunschweig ( ye olde one )
- F.R.G.
-
-
- C0033003 at dbstu1.bitnet
- C0033003%DBSTU1.BITNET@MITVMA.MIT.EDU
- C0033003%DBSTU1.BITNET@umd2.umd.edu
- c0033003%dbstu1.bitnet%cunyvm.cuny.edu@BRL.ARPA
- CUNYVM.CUNY.EDU!C0033003%DBSTU1.BITNET@ucbvax.Berkeley.EDU
- C0033003%DBSTU1.BITNET@CUNYVM.CUNY.EDU
- C0033003%DBSTU1.BITNET@jvncc.csc.org
- DBSTU1.BITNET!C0033003@lll-crg.llnl.gov
- lll-crg!CUNYVM.CUNY.EDU!C0033003%DBSTU1.BITNET
- lll-crg!DBSTU1.BITNET!C0033003
- etc...
- 28-Apr-88 23:24:17-EDT,1013;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 28 Apr 88 23:24-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA09234@EDDIE.MIT.EDU>; Thu, 28 Apr 88 22:14:35 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA09221@EDDIE.MIT.EDU>; Thu, 28 Apr 88 22:14:05 EDT
- Received: from huey.udel.edu by Louie.UDEL.EDU id aa08681; 28 Apr 88 22:08 EDT
- Date: Thu, 28 Apr 88 22:04:49 EDT
- From: Mills@UDEL.EDU
- To: C0033003%DBSTU1.BITNET@cunyvm.cuny.edu
- Cc: PACKET-RADIO@EDDIE.MIT.EDU
- Subject: Re: RFC 987 required
- Message-Id: <8804282204.aa01288@Huey.UDEL.EDU>
-
- RFC-987 describes the mapping between X.400 and good-ole SMTP mail and
- is by Steve Kille of UCL. If this is what you want and your intent
- is to provide X.400<->SMTP conversion for a PBBS accessable via radio,
- then I am astonished and delighted in that order and would be glad
- to forward the document in a return message.
-
- O' give me a home/where the buffalos roam/and say it with ASN.1...
-
- Dave W3HCF
- 29-Apr-88 03:50:35-EDT,536;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 29 Apr 88 03:50-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA14438@EDDIE.MIT.EDU>; Fri, 29 Apr 88 03:04:53 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA14425@EDDIE.MIT.EDU>; Fri, 29 Apr 88 03:04:28 EDT
- Message-Id: <8804290704.AA14425@EDDIE.MIT.EDU>
- Date: 29 Apr 88 06:55:40 GMT
- From: afaa0438@Buckner-EMH.arpa
- Subject: REmoval from mailing list
- To: packet-radio@eddie.mit.edu
-
- Please remove us from your mailing list. Thanks.
-
- 29-Apr-88 08:46:50-EDT,1144;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 29 Apr 88 08:46-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18312@EDDIE.MIT.EDU>; Fri, 29 Apr 88 08:01:39 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18304@EDDIE.MIT.EDU>; Fri, 29 Apr 88 08:01:22 EDT
- Message-Id: <8804291201.AA18304@EDDIE.MIT.EDU>
- Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Fri, 29 Apr 88 08:02:26 EDT
- Received: from HWALHW50.BITNET (BOSCH) by MITVMA.MIT.EDU (Mailer X1.25) with
- BSMTP id 6017; Fri, 29 Apr 88 08:02:22 EDT
- Date: Fri, 29 Apr 88 13:50 N
- From: <BOSCH%HWALHW50.BITNET@MITVMA.MIT.EDU>
- Subject: Needed !!
- To: packet-radio@eddie.mit.edu
- X-Original-To: packet-radio@eddie.mit.edu, BOSCH
-
- Hello,
-
- Is there somebody on this net (in or near Holland) who can make me
- very happy with a uuencoded packet radio program called YAPP20.ARC
- for the IBM PC.
-
- I can't get any response from the listserver in RPICICGE, i tried it
- for more then two weeks.
-
- Thanks in advance.
-
- Arnold Bosch (PE1IVQ)
- Agricultural University
- Wageningen, Holland
- address: BOSCH@HWALHW50 or BOSCH@HWALHW5 on bitnet
- 29-Apr-88 12:09:55-EDT,939;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 29 Apr 88 12:09-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA21502@EDDIE.MIT.EDU>; Fri, 29 Apr 88 11:14:10 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA21492@EDDIE.MIT.EDU>; Fri, 29 Apr 88 11:13:54 EDT
- Message-Id: <8804291513.AA21492@EDDIE.MIT.EDU>
- Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Fri, 29 Apr 88 11:14:52 EDT
- Received: from TAMSIGMA.BITNET (DST7303) by MITVMA.MIT.EDU (Mailer X1.25) with
- BSMTP id 7543; Fri, 29 Apr 88 11:14:27 EDT
- Date: Fri, 29 Apr 88 10:11 CDT
- From: <DST7303%TAMSIGMA.BITNET@MITVMA.MIT.EDU> (David Taylor - KA5SLG [696-3877])
- Subject: remove from list
- To: packet-radio@eddie.mit.edu
- X-Original-To: packet-radio@eddie.mit.edu, DST7303
-
- Please remove me from the packet distribution list. I will be
- graduating and will lose this account.
-
- Thanks,
- David Taylor
- Texas A&M University
- 29-Apr-88 12:32:44-EDT,1362;000000000000
- Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 29 Apr 88 12:32-EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA21922@EDDIE.MIT.EDU>; Fri, 29 Apr 88 11:39:42 EDT
- Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA21894@EDDIE.MIT.EDU>; Fri, 29 Apr 88 11:38:42 EDT
- Message-Id: <8804291538.AA21894@EDDIE.MIT.EDU>
- Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Fri, 29 Apr 88 11:39:29 EDT
- Received: from TAMSIGMA.BITNET (DST7303) by MITVMA.MIT.EDU (Mailer X1.25) with
- BSMTP id 7648; Fri, 29 Apr 88 11:30:37 EDT
- Date: Fri, 29 Apr 88 10:20 CDT
- From: <DST7303%TAMSIGMA.BITNET@MITVMA.MIT.EDU> (David Taylor - KA5SLG [696-3877])
- Subject: KPC-1 to KDK FM 240 interface
- To: packet-radio@eddie.mit.edu
- X-Original-To: packet-radio@eddie.mit.edu, DST7303
-
-
- Does anyone know how to interface a KDK FM 240 to a Kantronics KPC-1?
- I hooked up the cable from the radio to the TNC the "normal" way,
- but the display goes blank everytime the TNC keys the radio. I
- heard that I might need a transistor switch to key this radio.
-
- Any help would be greatly appreciated. Please respond directly to my
- account because I have removed myself from the distribution list due
- to my impending graduation (I will lose my account).
-
- Thanks in advance for the help,
- David Taylor
- Texas A&M University
- DST7303@TAMSIGMA.BITNET
-