home *** CD-ROM | disk | FTP | other *** search
/ World of Ham Radio 1994 January / AMSOFT_1994.iso / packet / docs / pd198804.doc < prev    next >
Encoding:
Text File  |  1993-12-31  |  89.5 KB  |  2,099 lines

  1. 2-Apr-88 07:10:32-EST,665;000000000000
  2. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 2 Apr 88 07:10-EST
  3. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02027@EDDIE.MIT.EDU>; Sat, 2 Apr 88 05:57:03 EST
  4. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02010@EDDIE.MIT.EDU>; Sat, 2 Apr 88 05:56:42 EST
  5. Received: by ucscc.UCSC.EDU (5.57/1.1)
  6.     id AA18065; Sat, 2 Apr 88 02:58:50 PST
  7. Date: Sat, 2 Apr 88 02:58:50 PST
  8. From: wm6r!wm6r@ucscc.UCSC.EDU
  9. Message-Id: <8804021058.AA18065@ucscc.UCSC.EDU>
  10. Apparently-To: packet-radio@eddie.mit.edu
  11.  
  12. Please add me to the mailing list for usenet ham.packet.
  13. Path:  ucbvax!ucscc!wm6r!packet.
  14. Thank you. John. wm6r!wm6r.
  15.  
  16.  
  17.  2-Apr-88 07:20:09-EST,665;000000000000
  18. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 2 Apr 88 07:20-EST
  19. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02027@EDDIE.MIT.EDU>; Sat, 2 Apr 88 05:57:03 EST
  20. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02010@EDDIE.MIT.EDU>; Sat, 2 Apr 88 05:56:42 EST
  21. Received: by ucscc.UCSC.EDU (5.57/1.1)
  22.     id AA18065; Sat, 2 Apr 88 02:58:50 PST
  23. Date: Sat, 2 Apr 88 02:58:50 PST
  24. From: wm6r!wm6r@ucscc.UCSC.EDU
  25. Message-Id: <8804021058.AA18065@ucscc.UCSC.EDU>
  26. Apparently-To: packet-radio@eddie.mit.edu
  27.  
  28. Please add me to the mailing list for usenet ham.packet.
  29. Path:  ucbvax!ucscc!wm6r!packet.
  30. Thank you. John. wm6r!wm6r.
  31.  
  32.  
  33.  4-Apr-88 15:06:50-EDT,3839;000000000000
  34. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 4 Apr 88 15:06-EDT
  35. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25195@EDDIE.MIT.EDU>; Mon, 4 Apr 88 13:33:15 EDT
  36. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25168@EDDIE.MIT.EDU>; Mon, 4 Apr 88 13:31:56 EDT
  37. Message-Id: <8804041731.AA25168@EDDIE.MIT.EDU>
  38. Received: from amc1 by AMC-HQ.ARPA id ac05428; 4 Apr 88 13:18 EST
  39. Date:     Mon, 4 Apr 88 13:08:19 EST
  40. From: "D. H. Bennett, AMCRM-FTM"  <dbennett%amc1@amc-hq.arpa>
  41. To: packet-radio%eddie.mit.edu@amc-hq
  42. Subject:  Type Stats for USA-PKT File
  43.  
  44.        Recap of USA-PKT.DBF
  45.          As of 04-04-1988
  46.          by K4NGC
  47.  
  48. The  following  is  a computed recap of the
  49. USA-PKT.DBF  file  I maintain. It shows the
  50. number  and type of activities by state. If
  51. you  have  any  changes  to the USA-PKT.DBF
  52. files please address them to K4NGC @ K4NGC.
  53.  
  54. State            PBBS  DIGI  TOTAL  PERCENT
  55. ---------------- ----  ----  -----  -------
  56. Alabama            15    22    37     1.66%
  57. Alaska              6     8    14     0.63%
  58. Arizona            45    17    62     2.79%
  59. Arkansas            9    11    20     0.90%
  60. California        108    89   197     8.86%
  61. Colorado           35    63    98     4.41%
  62. Connecticut         9    17    26     1.17%
  63. Delaware            4     2     6     0.27%
  64. Dist of Columbia    0     2     2     0.09%
  65. Florida            59    66   125     5.62%
  66. Georgia            26    23    49     2.20%
  67. Guam                0     0     0     0.00%
  68. Hawaii              9    11    20     0.90%
  69. Idaho               2     4     6     0.27%
  70. Illinois           23    26    49     2.20%
  71. Indiana            38    53    91     4.09%
  72. Iowa               21    30    51     2.29%
  73. Kansas             11    13    24     1.08%
  74. Kentucky           14    37    51     2.29%
  75. Louisiana          15     5    20     0.90%
  76. Maine              13     1    14     0.63%
  77. Maryland           52    54   106     4.77%
  78. Massachusetts      36    23    59     2.65%
  79. Michigan           35    15    50     2.25%
  80. Minnesota          11     8    19     0.85%
  81. Mississippi        13     4    17     0.76%
  82. Missouri           13    42    55     2.47%
  83. Montana             6     7    13     0.58%
  84. Nebraska           10    16    26     1.17%
  85. Nevada              1    10    11     0.49%
  86. New Hampshire      10    10    20     0.90%
  87. New Jersey         62    35    97     4.36%
  88. New Mexico         15     9    24     1.08%
  89. New York           73    65   138     6.21%
  90. North Carolina     15    21    36     1.62%
  91. North Dakota        6     1     7     0.31%
  92. Ohio               45    31    76     3.42%
  93. Oklahoma           13    22    35     1.57%
  94. Oregon              6     8    14     0.63%
  95. Pennsylvania       45    35    80     3.60%
  96. Puerto Rico         0     0     0     0.00%
  97. Rhode Island        5     5    10     0.45%
  98. South Carolina      7     9    16     0.72%
  99. South Dakota        3     9    12     0.54%
  100. Tennessee          18    19    37     1.66%
  101. Texas              37    15    52     2.34%
  102. Utah                9    24    33     1.48%
  103. Vermont             5     2     7     0.31%
  104. Virginia           31    50    81     3.64%
  105. Virgin Islands      0     0     0     0.00%
  106. Washington         19    20    39     1.75%
  107. West Virginia       8    13    21     0.94%
  108. Wisconsin          23    20    43     1.93%
  109. Wyoming             9    15    24     1.08%
  110.          ----  ----  ----  --------
  111. Total            1104  1118  2223   100.00%
  112.  
  113. The   USA-PKT.DBF  files  is  available  on
  114. CompuServe  to  all who want it. It is also
  115. available on the AMRAD BBS at 703-734-1387.
  116. Its in text and dBase formats.
  117.  
  118. Don Bennett (K4NGC)
  119. 15016 Carlsbad Road
  120. Woodbridge, Va 22193
  121. (Home) 703-670-4773
  122. (Work) 703-274-9355/56
  123. (BBS) 703-680-5970
  124. (CompuServe) 72310,263
  125. (ARPANET) dbennett@amc-hq.arpa
  126.  4-Apr-88 15:13:26-EDT,6433;000000000000
  127. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 4 Apr 88 15:13-EDT
  128. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25172@EDDIE.MIT.EDU>; Mon, 4 Apr 88 13:32:04 EDT
  129. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25140@EDDIE.MIT.EDU>; Mon, 4 Apr 88 13:30:18 EDT
  130. Message-Id: <8804041730.AA25140@EDDIE.MIT.EDU>
  131. Received: from amc1 by AMC-HQ.ARPA id ab05428; 4 Apr 88 13:18 EST
  132. Date:     Mon, 4 Apr 88 13:07:40 EST
  133. From: "D. H. Bennett, AMCRM-FTM"  <dbennett%amc1@amc-hq.arpa>
  134. To: packet-radio%eddie.mit.edu@amc-hq
  135. Subject:  Stats on USA-PKT file by Frequency
  136.  
  137.         Recap of USA-PKT.DBF
  138.           As of 04-04-1988
  139.           by K4NGC
  140.  
  141. The  following  is  a  computed  recap of the USA-
  142. PKT.DBF  file  I maintain. It shows the number and
  143. type  of activities by frequency.  If you have any
  144. changes  to  the  USA-PKT.DBF files please address
  145. them to K4NGC @ K4NGC.
  146.  
  147. Frequency         DIGI     PBBS    TOTAL   PERCENT
  148. ----------------  ----     ----    -----   -------
  149.    7.0910 Mhz        0        1        1     0.04%
  150.    7.0930 Mhz        0       29       29     1.30%
  151.    7.0940 Mhz        0        1        1     0.04%
  152.    7.0970 Mhz        0        3        3     0.13%
  153.    7.9300 Mhz        0        1        1     0.04%
  154.   10.1450 Mhz        0        0        0     0.04%
  155.   10.1473 Mhz        0        1        1     0.72%
  156.   10.1490 Mhz        0       16       16     0.00%
  157.   14.0700 Mhz        0        0        0     0.00%
  158.   14.1030 Mhz        1        5        6     0.27%
  159.   14.1050 Mhz        0        3        3     0.13%
  160.   14.1070 Mhz        0       27       27     1.21%
  161.   14.1090 Mhz        0       21       21     0.94%
  162.   14.1110 Mhz        0       25       25     1.12%
  163.   14.1115 Mhz        0        1        1     0.04%
  164.   14.1490 Mhz        0        1        1     0.04%
  165.   28.1050 Mhz        0        7        7     0.31%
  166.   28.1490 Mhz        0        0        0     0.00%
  167.   28.2750 Mhz        0        1        1     0.04%
  168.   50.0900 Mhz        0        0        0     0.00%
  169.   51.1200 Mhz        4        0        4     0.18%
  170.  144.0100 Mhz        0        0        0     0.00%
  171.  144.1100 Mhz        0        0        0     0.00%
  172.  144.5100 Mhz        1        3        4     0.18%
  173.  144.7600 Mhz        1        1        2     0.09%
  174.  144.9100 Mhz        2        3        5     0.22%
  175.  144.9300 Mhz        2       13       15     0.67%
  176.  144.9500 Mhz        3        5        8     0.36%
  177.  144.9700 Mhz        1       10       11     0.49%
  178.  144.9900 Mhz        2        8       10     0.45%
  179.  145.0000 Mhz        2        0        2     0.09%
  180.  145.0100 Mhz      682      426     1108    49.84%
  181.  145.0300 Mhz       46       57      103     4.63%
  182.  145.0500 Mhz      114      121      235    10.57%
  183.  145.0700 Mhz       53       56      109     4.90%
  184.  145.0900 Mhz       58       75      133     5.98%
  185.  145.1100 Mhz        0        3        3     0.13%
  186.  145.1500 Mhz        0        3        3     0.13%
  187.  145.3300 Mhz        1        0        1     0.04%
  188.  145.3500 Mhz        0        1        1     0.04%
  189.  145.3600 Mhz        4        9       13     0.58%
  190.  145.5100 Mhz        3        1        4     0.18%
  191.  145.5500 Mhz        4        3        7     0.31%
  192.  145.5550 Mhz        1        1        2     0.09%
  193.  145.5700 Mhz        2        4        6     0.27%
  194.  145.5900 Mhz        4        2        6     0.27%
  195.  145.6100 Mhz        1        0        1     0.04%
  196.  145.6500 Mhz        1        1        2     0.09%
  197.  145.6600 Mhz        0        1        1     0.04%
  198.  145.6700 Mhz        5        2        7     0.31%
  199.  145.9300 Mhz        1        0        1     0.04%
  200.  145.9700 Mhz        0        1        1     0.04%
  201.  146.0700 Mhz        0        1        1     0.04%
  202.  146.1300 Mhz        0        1        1     0.04%
  203.  146.1450 Mhz        1        0        1     0.04%
  204.  146.7000 Mhz        0        2        2     0.09%
  205.  146.7300 Mhz        0        1        1     0.04%
  206.  146.7450 Mhz        0        1        1     0.04%
  207.  146.9800 Mhz        1        1        2     0.09%
  208.  147.0100 Mhz        1        0        1     0.04%
  209.  147.4800 Mhz        0        1        1     0.04%
  210.  147.4900 Mhz        2        3        5     0.22%
  211.  147.5400 Mhz        0        2        2     0.09%
  212.  147.5550 Mhz       12        6       18     0.81%
  213.  147.5600 Mhz        1        1        2     0.09%
  214.  147.7000 Mhz        0        1        1     0.04%
  215.  149.0900 Mhz        0        1        1     0.04%
  216.  220.0100 Mhz        0        2        2     0.09%
  217.  220.0600 Mhz        1        0        1     0.04%
  218.  220.4500 Mhz        1        0        1     0.04%
  219.  220.5200 Mhz        0        3        3     0.13%
  220.  220.5300 Mhz        0        0        0     0.00%
  221.  220.5500 Mhz        0        1        1     0.04%
  222.  220.5700 Mhz       20        4       24     1.08%
  223.  220.9500 Mhz        9        1       10     0.45%
  224.  221.0100 Mhz       21       21       42     1.89%
  225.  221.1000 Mhz        1        0        1     0.04%
  226.  221.1100 Mhz        9       34       43     1.93%
  227.  223.4000 Mhz        2        1        3     0.13%
  228.  223.4200 Mhz        1        3        4     0.18%
  229.  223.5000 Mhz        0        1        1     0.04%
  230.  223.5800 Mhz       11       18       29     1.30%
  231.  223.7000 Mhz        0        1        1     0.04%
  232.  433.8000 Mhz        0        1        1     0.04%
  233.  438.0000 Mhz        3        0        3     0.13%
  234.  441.0000 Mhz        5       10       15     0.67%
  235.  441.5000 Mhz        2        2        4     0.18%
  236.  441.9000 Mhz        1        0        1     0.04%
  237.  443.8000 Mhz        3        0        3     0.13%
  238.  445.5500 Mhz        1        0        1     0.04%
  239.  446.0500 Mhz        1        1        2     0.09%
  240.  446.1000 Mhz        0        2        2     0.09%
  241.  446.8000 Mhz        1        9       10     0.45%
  242.  446.8200 Mhz        0        2        2     0.09%
  243.  448.4000 Mhz        2        0        2     0.09%
  244. 1297.5000 Mhz        0        0        0     0.00%
  245.          ------   ------   ------
  246. TOTAL             1118     1104     2223   100.00%
  247.  
  248. The USA-PKT.### files is availble on CompuServe to
  249. all who want it. It is also available on the AMRAD
  250. BBS  at  703-734-1386.   Its  in  text  and  dBASE
  251. formats.
  252.  
  253. Don Bennett (K4NGC)
  254. 15016 Carlsbad Road
  255. Woodbridge, Va 22193
  256. (Home) 703-670-4773
  257. (Work) 703-274-9355
  258. (BBS) 703-680-5970
  259. (CompuServe) 72310,263
  260. (ARPANET) dbennett@amc-hq.arpa
  261.  6-Apr-88 05:52:04-EDT,2562;000000000000
  262. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 6 Apr 88 05:52-EDT
  263. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA14512@EDDIE.MIT.EDU>; Wed, 6 Apr 88 05:06:10 EDT
  264. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA14497@EDDIE.MIT.EDU>; Wed, 6 Apr 88 05:05:30 EDT
  265. Message-Id: <8804060905.AA14497@EDDIE.MIT.EDU>
  266. 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
  267. Date: Wed, 06 Apr 88 11:04:06 MEZ
  268. To: PACKET-RADIO@MIT-EDDIE.MIT.EDU
  269. From: C0033003%DBSTU1.BITNET@CUNYVM.CUNY.EDU
  270. Comment: CROSSNET mail via SMTP@INTERBIT
  271. Return-Receipt-To: C0033003@DBSTU1.BITNET
  272. Subject: what archive for PD software ?
  273.  
  274.  
  275.      NORD><LINK - The northern Germany Packet Radio development Group
  276.      ----------------------------------------------------------------
  277.  
  278. Well, easter holidays are over and we 're glad to be in time.
  279.  
  280.                 THE FIRMWARE
  281.         Compatibel. Portabel. Public Domain.
  282.  
  283. THE  FIRMWARE  is  an upgraded version of the well known WA8DED  2.1  Hostmode
  284. Software for TNC2.  Some bugs have been fixed and some extensions are  instal-
  285. led, and it's available right now.
  286.  
  287. Now is the problem to distribute the software.
  288. We have a hexdump available at the moment ( INTEL - hexdump )
  289. but this one is more than 90 KB long. So I'd like to depose it in an
  290. archive somewhere instead of posting it here. Any suggestions for that ?
  291.  
  292. (*) WA8DED 2.1 Hostmodesoftware, Copyright by Ron Raikes, WA8DED
  293.  
  294.  
  295.               THE NET
  296.         Compatibel. Portabel. Public Domain.
  297.  
  298. We included a further feature in the firmware: The Ident-command has    on 1.3
  299. been upgraded to an Info-command ( but it's still an 'I' ). With this
  300. version you can burn additional info messages into the EPROM ( we use
  301. City, qth-locator, working frequency, responsible SysOP's  callsign).
  302. Furthermore the sysop can post a short info-message ( even from remote)
  303. for everyone who connects the node ( e.g.: NODE DOWN FOR MAINTENANCE
  304. FRIDAY 5 P.M.)
  305.  
  306. This one ( release 0.9 ) could be posted in the next week. But the
  307. question is where or how. It's > 90 KB as a hexdump, source is much
  308. more.
  309.  
  310. THE FIRMWARE and THE NET are
  311.  
  312.    -  free for non-commercial users
  313.    -  ||| public domain source code for non-commercial users |||
  314.       ||| (95% C, 5% Assembler)                              |||
  315.  
  316. 73s de Detlef ( DK4EG )
  317. C0033003 at DBSTU1.BITNET
  318.  
  319. NORD><LINK
  320. c/o Detlef J. Schmidt
  321. Steinbrecherstr.22
  322. D3300 Braunschweig
  323. FRG
  324.  7-Apr-88 15:11:51-EDT,789;000000000000
  325. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 Apr 88 15:11-EDT
  326. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00220@EDDIE.MIT.EDU>; Thu, 7 Apr 88 11:30:18 EDT
  327. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00181@EDDIE.MIT.EDU>; Thu, 7 Apr 88 11:29:48 EDT
  328. Received: by leg.ai.mit.edu; Thu, 7 Apr 88 10:46:52 EDT
  329. Date: Thu, 7 Apr 88 10:46:52 EDT
  330. From: mac@leg.ai.mit.edu (Michael Chepponis)
  331. Message-Id: <8804071446.AA02260@leg.ai.mit.edu>
  332. To: packet-radio@eddie.mit.edu
  333. Subject: NORD><LINK a hoax?
  334.  
  335. I received a piece of BBS mail from Bob, NK8T, saying he thought that the
  336. NORD><LINK P.D. NET/ROM software is a hoax, as he tried to contact the folks
  337. but his mail was returned.
  338.  
  339. Does anybody know if this stuff is real?  Tnx -Mike k3mc
  340.  7-Apr-88 17:47:37-EDT,1503;000000000000
  341. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 Apr 88 17:47-EDT
  342. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA04782@EDDIE.MIT.EDU>; Thu, 7 Apr 88 16:26:11 EDT
  343. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA04778@EDDIE.MIT.EDU>; Thu, 7 Apr 88 16:25:59 EDT
  344. Received: by june.cs.washington.edu (5.52.1/6.13)
  345.     id AA10740; Thu, 7 Apr 88 13:26:47 PDT
  346. Return-Path: <tektronix!orca!leia!tomk@beaver.cs.washington.edu>
  347. Message-Id: <8804072026.AA10740@june.cs.washington.edu>
  348. From: tektronix!orca!leia!tomk@beaver.cs.washington.edu (Tom Kloos)
  349. To: PACKET-RADIO@EDDIE.MIT.EDU
  350. Subject: TAPR 1.1.5 w/KISS EPROM
  351. Keywords: wrong checksum
  352. Date: 6 Apr 88 17:47:28 GMT
  353.  
  354. A few weeks ago I received the 1.1.5 with KISS EPROM for my TNC-2 from
  355. TAPR.  It works great, except that the checksum is displayed as $25
  356. rather than the $85 as claimed by the release notes.  Did TAPR screw up
  357. burning the EPROM or is $25 really correct?  The startup banner
  358. displays a date of 12/14/87 and the Data-I/O checksum is CBC9.  The
  359. release notes are dated 3/8/88.
  360.  
  361. Another note about TAPR.... I received TCP/IP floppies from them at the
  362. end of February.  It was the original 871225.1 release.  Is anyone
  363. sending TAPR the latest and greatest patches as they appear?  Wasn't at
  364. least 871225.4 available by late January?
  365.  
  366. -Tom Kloos, WA7NJK, Tektronix, Wilsonville, Oregon   tomk@leia.GWD.TEK.COM
  367. {ucbvax,decvax,uw-beaver,hplabs,ihnp4,allegra}!tektronix!tekecs!leia!tomk
  368.  
  369.  
  370.  7-Apr-88 23:51:47-EDT,1079;000000000000
  371. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 Apr 88 23:51-EDT
  372. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA12959@EDDIE.MIT.EDU>; Thu, 7 Apr 88 22:42:49 EDT
  373. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA12949@EDDIE.MIT.EDU>; Thu, 7 Apr 88 22:42:27 EDT
  374. Received: by leg.ai.mit.edu; Thu, 7 Apr 88 22:44:31 EDT
  375. Date: Thu, 7 Apr 88 22:44:31 EDT
  376. From: mac@leg.ai.mit.edu (Michael Chepponis)
  377. Message-Id: <8804080244.AA03454@leg.ai.mit.edu>
  378. To: tektronix!orca!leia!tomk@beaver.cs.washington.edu
  379. Cc: PACKET-RADIO@eddie.mit.edu
  380. In-Reply-To: Tom Kloos's message of 6 Apr 88 17:47:28 GMT <8804072026.AA10740@june.cs.washington.edu>
  381. Subject: TAPR 1.1.5 w/KISS EPROM
  382.  
  383. Tom, it is likely that TAPR didn't update their doc; if the TNC works, then
  384. $25 is probably correct.
  385.  
  386. TAPR is updated regularly.  The versions that appear on louie.udel.edu are 
  387. interem ones, and may not be fully debugged.  I do know that another new
  388. major release is planned soon, and I'm sure TAPR will ship that when it becomes
  389. available.
  390.  
  391. Best -Mike k3mc
  392.  8-Apr-88 14:46:29-EDT,4230;000000000000
  393. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 8 Apr 88 14:46-EDT
  394. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25732@EDDIE.MIT.EDU>; Fri, 8 Apr 88 12:15:53 EDT
  395. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25709@EDDIE.MIT.EDU>; Fri, 8 Apr 88 12:15:20 EDT
  396. Message-Id: <8804081615.AA25709@EDDIE.MIT.EDU>
  397. 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
  398. Date: Fri, 08 Apr 88 17:08:43 MEZ
  399. To: PACKET-RADIO@MIT-EDDIE.MIT.EDU
  400. From: C0033003%DBSTU1.BITNET@CUNYVM.CUNY.EDU
  401. Comment: CROSSNET mail via SMTP@INTERBIT
  402. Return-Receipt-To: C0033003@DBSTU1.BITNET
  403. Subject: manual addendum 'TheNet'
  404.  
  405.           NORD><LINK
  406. The northern Germany packet-radio development group
  407.  
  408. Following is the description of the user manual of TheNet. Only the
  409. differences to the original manual are listed.
  410. Remember: Distribution is free for noncommercial applications, but
  411. we're not responsible for any kind of use or the results of any bugs.
  412.  
  413. Further infos will come up the next days and will be posted here.
  414. ---------------------cut here-------------------------------------------
  415.  
  416.  
  417. TheNet Version 1.0                          07-04-88
  418.  
  419. TheNet is fully compatible to NET/ROM (*) version 1.3. The following descrip-
  420. tion contains only the changes for users and sysops.
  421.  
  422. (* NET/ROM is a registered trademark of Software 2000 Inc.)
  423.  
  424. Userinterface
  425. =============
  426.  
  427. The command "IDENT" has been replaced by a new command "INFO".
  428. The digipeater will send:
  429.      1. it's mnemonic identifier and the call
  430.      2. a message contained in the EPROM
  431.      3. a remote programable message
  432.  
  433. Example:
  434.  
  435. BS:DB0FC> NORD><LINK              \
  436. Braunschweig <JO55GH>               \
  437. 5W, GP, 144.675 MHz                   > plain ASCII text in EPROM header
  438. OP: DK4EG @ DK0MAV                  /
  439.                   /
  440. friday 5 p.m. node down for maintenance     > loaded from remote
  441.  
  442.  
  443. All system messages contain no characters with special national meaning (e.g.
  444. 7e HEX).
  445.  
  446.  
  447. Sysop interface:
  448. ================
  449.  
  450. All sysop commands will only work after a successfull execution of "SYSOP".
  451.  
  452. changed commands:
  453. -----------------
  454.  
  455. 1. INFO  (former IDENT)
  456. Store a message of up to 80 characters. Longer input will be truncated.
  457. Minimum length is 1 character. To clear the message you have to input a new
  458. message. A period is sufficient. Only after a coldstart this message will be
  459. cleared. So a power failure is easily detectible.
  460.  
  461. 2. RESET
  462. RESET will do a coldstart. The whole RAM is initialized. All parameters are
  463. taken from EPROM. The INFO message is cleared. The password is taken from
  464. EPROM.
  465. Unlike with NET/ROM there is no argument necessary.
  466.  
  467.  
  468. new commands
  469. ------------
  470.  
  471. 1. HIGH portnumber
  472. Output portnumber is activated (relais engaged, LED on).
  473. Portnumber = 0 activates the CONNECT-LED output, portnumber = 1 the STATUS-
  474. LED output.
  475.  
  476. 2. LOW portnumber
  477. Output portnumber is deactivated (relais disengaged, LED off).
  478. Portnumber = 0 desactivates the CONNECT-LED output, portnumber = 1 the
  479. STATUS-LED output.
  480.  
  481.  
  482. other changes:
  483. -------------
  484.  
  485. 1. TheNet is capable of fullduplex activity. The commands may only be given on
  486. the host terminal. With <ESC> D 0 you switch to halfduplex and with <ESC> D 1
  487. you switch to fullduplex. By a constant in EPROM you decide to send flags
  488. while there is no activity on the transmitter or keep the transmitter quiet.
  489.  
  490. 2. All default parameters are contained in a list at the beginning of the
  491. EPROM. This includes call and mnemonic identifier of the digipeater as well as
  492. the default password. So remote access is possible even after a total power
  493. failure.
  494.  
  495.  
  496.  
  497. If you have further questions or any other comments, feel free to contact
  498.  
  499. NORD><LINK
  500. c/o Hans Georg Giese DF2AU
  501. Hinter dem Berge 5
  502. 3300 Braunschweig
  503. FRG
  504.  
  505. or DK4EG
  506. -----
  507. 73s de Detlef ( DK4EG )
  508. Computing center
  509. University Brunswick
  510.  
  511. C0033003 at dbstu1.bitnet
  512.  C0033003%DBSTU1.BITNET@MITVMA.MIT.EDU
  513.  C0033003%DBSTU1.BITNET@umd2.umd.edu")
  514.  c0033003%dbstu1.bitnet%cunyvm.cuny.edu@BRL.ARPA
  515.  CUNYVM.CUNY.EDU!C0033003%DBSTU1.BITNET@ucbvax.Berkeley.EDU
  516. etc...
  517. 11-Apr-88 17:44:41-EDT,1532;000000000000
  518. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Apr 88 17:44-EDT
  519. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA03130@EDDIE.MIT.EDU>; Mon, 11 Apr 88 16:10:32 EDT
  520. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA01930@EDDIE.MIT.EDU>; Mon, 11 Apr 88 15:30:14 EDT
  521. Received: by BITSY.MIT.EDU (5.45/4.7) id AA28231; Mon, 11 Apr 88 15:31:52 EDT
  522. Date: Mon, 11 Apr 88 15:31:52 EDT
  523. From: Ron M. Hoffmann <hoffmann@BITSY.MIT.EDU>
  524. Message-Id: <8804111931.AA28231@BITSY.MIT.EDU>
  525. To: info-hams@SIMTEL20.ARPA, packet-radio@EDDIE.MIT.EDU
  526. Cc: hoffmann@BITSY.MIT.EDU
  527. Subject: FCC database on CD-ROM
  528.  
  529. The following is reproduced from "CD-ROM REVIEW" March/April 1988,
  530. Page 6, without permission.  News of packet is showing up in the
  531. strangest places!
  532.  
  533. _Hamming it Up_
  534.  
  535.     Two Virginia amateur radio enthusiasts have successfully
  536. transmitted the first CD-ROM database over packet radio.  Jack Speer
  537. of Mineral used his packet station to connect with Jim DeArras in
  538. Richmond (about 40 miles away).  DeArras provided a multiuser PBBS
  539. (packet bulletin board service) and interface software.  Speer, using
  540. an Hitachi 1502S CD-ROM drive, transmitted Buckmaster Publishings's
  541. database of more than 472,000 radio amateurs.  The demo disc was
  542. prepared by another ham, Bill Harlow of PDSC.
  543.  
  544.     Though the Buckmaster disk is not commercially available, hams
  545. can test the CD-ROM by contacting DeArras (WA4ONG-10).  At the PBBS
  546. prompt, type: OS QTH N1BIC followed by a carriage return.
  547.  
  548. via WA2EYC
  549. 11-Apr-88 19:45:16-EDT,15311;000000000000
  550. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Apr 88 19:45-EDT
  551. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA04929@EDDIE.MIT.EDU>; Mon, 11 Apr 88 17:19:20 EDT
  552. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00695@EDDIE.MIT.EDU>; Mon, 11 Apr 88 14:56:53 EDT
  553. Received: by june.cs.washington.edu (5.52.1/6.13)
  554.     id AA12353; Mon, 11 Apr 88 11:01:31 PDT
  555. Return-Path: <mtunx!whuts!homxb!hou2d!n2dsy@RUTGERS.EDU>
  556. Message-Id: <8804111801.AA12353@june.cs.washington.edu>
  557. Date: 7 Apr 88 19:37:26 GMT
  558. From: mtunx!whuts!homxb!hou2d!n2dsy@RUTGERS.edu (G.BEATTIE)
  559. To: PACKET-RADIO@EDDIE.MIT.EDU
  560. Subject: Asynchronous Framing Technique Document File: AFT.DOC
  561. Keywords: AFT, a SLIP alternative
  562.  
  563. Here is the document file that I promised last week describing
  564. the Asynchonous Framing Technique (AFT).  This is only a
  565. framing protocol.  It contains NO state machine, transparency
  566. and error control. 
  567.  
  568. Four files will follow this message(but only in comp.protocols.tcp-ip):
  569.  
  570. 1. AFT.C - a machine independent implementation of the AFT software.
  571. 2. ASYNC.ASM - an MS-DOS device driver to use with AFT.
  572. 3. TEST1.C - a test and demo programme for the AFT software.
  573. 4. Test2.C - another test and demo programme for the AFT software.
  574.  
  575. The file contained in this message is AFT.DOC.
  576.  
  577. If you like what you see here in the document file, go to the
  578. newsgroup "comp.protocols.tcp-ip" and pull the other four files.
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.         Machine Independent Asynchronous Framing Technique (AFT)
  589.  
  590.         Version 1.0, by John Howell (N2FVN), August 7, 1987
  591.  
  592.         This software is in the public domain.  It is provided on an
  593.         'as is' basis without warranty.
  594.  
  595.         This is a portable implementation of the Asynchronous
  596.         Framing Technique for X.25 (X.25/AFT) Revision 2 coded in
  597.         the C language.  AFT is a protocol which allows X.25 style
  598.         framing to be done over an asynchronous communication
  599.         channel.  It allows for detection of the start and end of
  600.         frames, detection of corrupted transmission, and sending of
  601.         frames containing eight bit characters over communication
  602.         links which cannot accept all possible characters.
  603.  
  604.         AFT is intended to be used as a replacement for the X.25
  605.         level two framing technique in cases where synchronous
  606.         communication is not practical.
  607.  
  608.         For more information on X.25/AFT contact:
  609.  
  610.          Research Department
  611.          Hayes Microcomputer Products, Inc.
  612.          705 Westech Drive
  613.          Norcross, Georgia   30092
  614.  
  615.         This implementation of AFT supports all features of revision
  616.         two of the protocol.  A method is provided to select which
  617.         of the possible options are to be used.  The implementation
  618.         has three components:
  619.  
  620.          1) Option Selection
  621.          2) Frame Transmission
  622.          3) Frame Reception
  623.  
  624.         The interface to the user of AFT was chosen to allow use of
  625.         the software in many different environments.  As provided
  626.         this software requires additional machine dependant software
  627.         to provide a full AFT implementation.  The transmit and
  628.         receive routines have been implemented in such a way that
  629.         they may be called either within interrupt service routines
  630.         as characters are sent and received or they may be called
  631.         from non-interrupt routines which fill or empty queues used
  632.         by the software doing the hardware dependant portion of the
  633.         I/O.
  634.  
  635.         This implementation provides no actual routines to do I/O
  636.         since this is highly machine dependant.
  637.  
  638.         In this program the terms bytes and characters are used as
  639.         synonyms for eight bit groups of data which are known as
  640.         octets in X.25.  This program assumes that the
  641.         implementation of type 'char' is an eight bit value.  Also
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.         the type 'int' is assumed to be at least 16 bits in size.
  654.  
  655.         An attempt has been made to only use those features of C
  656.         which are common to nearly all implementations.  This code
  657.         was actually tested using Microsoft C version 4.0.
  658.  
  659.         Some abbreviations used in this program are:
  660.         
  661.          FCS  Frame Check Sequence
  662.          LEN  Length
  663.          OPT  Option
  664.          RX   Receive
  665.          SUB  Substituted
  666.          TX   Transmit
  667.         
  668.  
  669.         
  670.  
  671.         
  672.  
  673.         Interface to External Routines
  674.  
  675.         The following routines make up the interface to the AFT
  676.         implementation.  It is assumed that the user is familiar
  677.         with the C language.
  678.  
  679.         
  680.  
  681.         aft_options(ebdt, transparency_level, suffix_len,
  682.             suffix, max_rx_len)
  683.  
  684.         This routine selects the options to be used for AFT
  685.         communication.  It must be called at least once before any
  686.         other AFT routines are used.  It may be called again later
  687.         to change the previously selected options.  This should only
  688.         be done at a time when no frames are being sent or received.
  689.  
  690.         'ebdt' is a flag (0=false, non-zero=true) which determines
  691.         whether the eight-bit data transparency option is to be used
  692.         on transmit and receive.  The EBDT option should only be
  693.         used in cases where the communication path does not transfer
  694.         the high order bit of characters transparently.  This option
  695.         must be selected identically on both the sending and
  696.         receiving sides of the link.  Use of this feature adds an
  697.         extra 14% overhead to the communications.
  698.  
  699.         'transparency_level' takes on one of three values. Zero
  700.         indicates that basic transparency is to be used.  This
  701.         should be selected when the communication path allows
  702.         transparent transmission of all 256 possible characters. One
  703.         indicates that flow control transparency is to be used.
  704.         This should be selected when the transmission of X-on and X-
  705.         off characters would cause the receiver to perform flow
  706.         control which would prevent them from appearing within
  707.         frames.  Two indicates that control-character transparency
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.         is to be used. This should be selected when the transmission
  720.         path does not allow transparent transmission of some control
  721.         characters.  Each higher numbered option adds more overhead
  722.         to transmitted frames.
  723.  
  724.         'suffix_len' is the length of a string which will be
  725.         appended to each frame when it is sent.  This feature is
  726.         used to provide any extra characters which the receiving
  727.         system may require to recognize the end of an input.  Zero
  728.         should be used when no frame suffix is to be added which is
  729.         the most common case.  The maximum suffix allowed is three
  730.         characters.
  731.  
  732.         'suffix' is a pointer to the actual character string in
  733.         which the suffix is stored.  This is only examined if the
  734.         suffix length is non-zero.  This string may contain up to
  735.         three characters which may each be any value.
  736.  
  737.         'max_rx_len' is the size of the buffer which will be used
  738.         for receiving frames.  This length is used by the receive
  739.         frame routines to prevent storing data past the end of the
  740.         buffer.  Received frames which are too long will be
  741.         discarded.  The receive buffer provided must be at least two
  742.         characters larger than the maximum expected frame size.
  743.         This is required since buffer is used for temporary storage
  744.         of the two character frame check sequence.
  745.  
  746.         
  747.  
  748.         int aft_tx_start(length, buffer)
  749.  
  750.         This is the routine used to do the setup for transmitting a
  751.         frame.  This routine returns a value of zero if a new frame
  752.         cannot be started because a frame is already being sent, or
  753.         a value of one if the request is accepted.  In either case
  754.         this routine returns immediately.  The actual sending of the
  755.         frame is done by aft_tx_char.
  756.  
  757.         'length' is the length of the frame to be sent.  The minimum
  758.         valid frame length is two characters.  The maximum is
  759.         limited only by the restrictions of the C compiler used.
  760.  
  761.         'buffer' is a pointer to the buffer holding the frame to be
  762.         sent.  This buffer should contain only the address, control,
  763.         and information fields for the frame.  The AFT routines will
  764.         generate starting and closing flags, frame check sequence,
  765.         and other characters required for transparency when the
  766.         frame is sent.  AFT will not modify the contents of the
  767.         buffer.  The buffer contents should not be modified by any
  768.         other routines until transmission of the frame is completed
  769.         or an incorrect frame may be sent.
  770.  
  771.         
  772.  
  773.         int aft_tx_char()
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.         This routine is used to obtain the next character to be sent
  786.         in order to transmit a frame.  It returns characters to be
  787.         sent as a value from zero to 255 in the low order byte of
  788.         the returned integer and zero in the high order byte of the
  789.         integer.  Once the final character of the frame has been
  790.         sent the return value will be one in the high order byte and
  791.         a flag character in the low order byte.
  792.  
  793.         This routine is designed to be either used as a non-
  794.         interrupt routine to which is called in a loop to fill an
  795.         outgoing buffer which will be sent by other software or
  796.         called within an interrupt routine when a transmitter buffer
  797.         empty condition occurs to provide the next character to be
  798.         sent.  When used in an interrupt routine the caller may
  799.         ignore the upper byte of the return value.  If this is done
  800.         then the result will be to send continuous flags between
  801.         frames.
  802.  
  803.         
  804.  
  805.         aft_tx_abort()
  806.  
  807.         This routine may be called to cause aft_send_char to abort
  808.         the frame it is currently sending.  A lead-in character is
  809.         sent followed by a flag to indicate that the receiver should
  810.         ignore the frame.  It a frame is not being sent then no
  811.         action is taken.
  812.  
  813.         
  814.  
  815.         int aft_tx_complete()
  816.  
  817.         This routine is intended to be used in cases where
  818.         aft_tx_char is being called during interrupt service.  It
  819.         provides a way for non-interrupt routines to poll for frame
  820.         sending completion. It returns zero if a frame is currently
  821.         being sent or one if no frame is being sent.  A frame is
  822.         considered to be sent once aft_tx_char is about to return
  823.         the frame complete code (0x017E) to its caller.  Instead of
  824.         using this routine aft_tx_char may be easily modified to
  825.         take any desired action when sending of a frame is
  826.         completed.
  827.  
  828.         
  829.  
  830.         int aft_rx_start(buffer)
  831.  
  832.         This routine provides a buffer for the AFT software to use
  833.         to receive a frame into.  This routine returns a value of
  834.         zero if the buffer is not accepted because a receive
  835.         operation is already in progress or a value of one if the
  836.         buffer is accepted.  In either case this routine returns
  837.         immediately to its caller.
  838.  
  839.         'buffer' is a pointer to the buffer into which the frame
  840.  
  841.  
  842.  
  843.  
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.         will be received.  This buffer will be filled one character
  852.         at a time by aft_rx_char as characters for the frame are
  853.         received.  Once the receive operation is completed this
  854.         buffer will hold the received frame address, control, and
  855.         information fields.  All flags, FCS, and extra transparency
  856.         characters will have been removed.
  857.  
  858.         
  859.  
  860.         int aft_rx_char(c)
  861.  
  862.         This routine accepts a received character and adds it to the
  863.         frame being received.  If aft_rx_start has not been called
  864.         to provide a buffer for receive then the first few
  865.         characters of the frame will be saved in a temporary buffer.
  866.         This will prevent loss of data in cases where aft_rx_char is
  867.         being called directly by the receive interrupt service
  868.         routine.  This routine can also be called by a non-interrupt
  869.         routine which obtains the characters from a received
  870.         character queue.  A value of zero is returned if this
  871.         character does not complete a frame.  A non-zero return
  872.         value indicates that the character provided completed the
  873.         received frame.  In this case the value returned is the
  874.         length of the frame which is contained in the receive
  875.         buffer.
  876.  
  877.         If an invalid FCS is received at the end of the frame then
  878.         the frame will be discarded.  A frame of less than two bytes
  879.         will also be discarded.
  880.  
  881.         'c' is the next character received from the communication
  882.         port.
  883.  
  884.         
  885.  
  886.         aft_rx_error()
  887.  
  888.         This routine is called to indicate the occurrence of an
  889.         error condition on the communication line.  Possible
  890.         conditions may be framing error, break received, parity
  891.         error (if in EBDT mode), time out (which is not required for
  892.         AFT), or overrun.  When this routine is called AFT discards
  893.         the frame currently being received and begins searching for
  894.         the start of the next frame.
  895.  
  896.         int aft_rx_complete()
  897.  
  898.         This routine is used in cases where aft_rx_char is being
  899.         called during interrupt service.  It provides a way for non-
  900.         interrupt routines to poll for completion of a receive
  901.         operation.  It returns zero if the receive operation has not
  902.         completed and the received frame length if it has.  After
  903.         this routine returns that a frame has completed then
  904.         aft_rx_start should be called as quickly as possible to
  905.         provide a new receive buffer.  If this is not done in time
  906.  
  907.  
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.         then the next incoming frame may be lost.  Instead of using
  918.         this routine aft_rx_char may be easily modified to take any
  919.         desired action when sending of a frame is completed.
  920.  
  921.  
  922. 11-Apr-88 20:18:57-EDT,17854;000000000000
  923. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Apr 88 20:18-EDT
  924. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA01262@EDDIE.MIT.EDU>; Mon, 11 Apr 88 11:26:52 EDT
  925. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA01243@EDDIE.MIT.EDU>; Mon, 11 Apr 88 11:26:18 EDT
  926. Received: by june.cs.washington.edu (5.52.1/6.13)
  927.     id AA04658; Mon, 11 Apr 88 08:26:33 PDT
  928. Return-Path: <osu-cis!n8emr!gws@EDDIE.MIT.edu>
  929. Message-Id: <8804111526.AA04658@june.cs.washington.edu>
  930. Date: 11 Apr 88 00:42:18 GMT
  931. From: osu-cis!n8emr!gws@EDDIE.MIT.edu (Gary Sanders)
  932. To: PACKET-RADIO@EDDIE.MIT.EDU
  933. Subject: gateway vol 4.12
  934. Distribution: usa
  935.  
  936. Bulletin ID: KC8TW_11150 
  937. Path: W8CQK!AD8I!N8NN!WA8JXM!KC8TW
  938.  
  939.  
  940. =====================================================
  941. >>Relayed from W8CQK packet BBS to N8EMR ham BBS...<<
  942. >>Ham BBS, Columbus,Oh. 614-457-4227 (300/1200,8N1)<<
  943. =====================================================
  944.  
  945. Gateway: The ARRL Packet Radio Newsletter 
  946.  
  947. Stan Horzepa, WA1LOU, Editor
  948.  
  949. Vol. 4, No. 12 March 4, 1988
  950.  
  951. NEW VERSION OF W0RLI PBBS NOW AVAILABLE
  952.  
  953. Version 4.5 of the W0RLI/VE3GYQ Packet Radio Bulletin Board System software
  954. has been released.  It is available from the usual sources or may be
  955. downloaded from the HamNet DL9 Data Library of CompuServe.  If you have
  956. Version 4.4, you need only download the special file MBEXE.ARC to get the
  957. changes.  Others should download RUN45.ARC (the executable code) and
  958. SRC45.ARC (the sources).
  959.  
  960. >from CompuServe's HamNet  (note from N8XX - the latest version is 4.52)
  961.  
  962. AMSAT-TAPR DIGITAL SIGNAL PROCESSING PROJECT UPDATE
  963.  
  964. Steve Sagerian, KA0YRE, of Motorola has really come through for the digital
  965. signal processing (DSP) project.  He arranged for the DSP operations branch
  966. of Motorola to come up with two 56001 EXP kits.  This kit comes with bare
  967. boards, boot ROMS (a debugger, monitor), PALs and several manuals.  Just to
  968. get things rolling in a hurry, they decided to be very generous and throw
  969. in two DSP56001 chips.  This board has a 20.48-MHz clock and processes
  970. 10.25-million instructions per second.  Using the architecture to its
  971. fullest, one could do a 1024-point Fourier transform in 3.48 ms.  Steve and
  972. Bob McGwier, N4HY, will be building up these two units.  We may expect
  973. further support from Motorola as they get applications back from us.  We
  974. wish to thank Motorola, Inc for their generous support.
  975.  
  976. >from Bob McGwier, N4HY, via CompuServe's HamNet
  977.  
  978.  
  979. NEW TAPR OFFICERS ELECTED
  980.  
  981. At the February 21 annual meeting of Tucson Amateur Packet Radio Corp
  982. (TAPR), the following officers were announced as elected by the Board of
  983. Directors: President Andy Freeborn, N0CCZ; Vice President Tom Clark, W3IWI;
  984. and Secretary-Treasurer Scott Loftesness, W3VS.  In addition, an Executive
  985. Committee was appointed by the board to run the day-to-day affairs of the
  986. organization.  The Executive Committee consists of the above three officers
  987. plus Directors Lyle Johnson, WA7GXD, David Toth, VE3GYQ, and Harold Price,
  988. NK6K.
  989.  
  990. >from Scott Loftesness, W3VS via CompuServe's HamNet
  991.  
  992.  
  993. UoSAT-C SPACECRAFT TO BE BUILT AT UNIVERSITY OF SURREY
  994.  
  995. The UoSAT Spacecraft Engineering Research Unit at the University of Surrey
  996. in the United Kingdom is now building a third UoSAT- OSCAR spacecraft -
  997. UoSAT-C. NASA has agreed to provide a launch for UoSAT-C on a DELTA launch
  998. vehicle currently scheduled for late 1988. The DELTA should place UoSAT-C
  999. into a 43-degree- inclination, 500-km circular orbit.
  1000.  
  1001. UoSAT-C will carry experimental engineering, science and communications
  1002. payloads developed in close collaboration between international
  1003. professional engineering and Amateur Radio communities. These payload
  1004. experiments develop further the mission objectives supported by the highly
  1005. successful UoSAT-1 and 2 (UoSAT-OSCAR-9 and UoSAT-OSCAR-11) satellites
  1006. which are still operational after six and four years in orbit,
  1007. respectively. The UoSAT program and series of satellites are intended to
  1008. complement the AMSAT-OSCAR, RS and FUJI-OSCAR Amateur Radio communications
  1009. satellites by providing a space science and engineering facility readily
  1010. available to both amateur and professional experimenters alike, thus,
  1011. generating a greater mutual awareness and collaboration.
  1012.  
  1013. UoSAT-C, like the previous UoSAT missions, will have a strong element of
  1014. international collaboration - specifically with members of AMSAT-UK,
  1015. AMSAT-NA in the United States and Canada, VITA, Quadron, NASA, the British
  1016. National Space Centre and the European Space Agency.
  1017.  
  1018. UoSAT-C Payloads
  1019.  
  1020. o Store-And-Forward Communications
  1021.  
  1022. Since 1983, UoSAT has played a major role in an international collaborative
  1023. project developing cost-effective digital store- and-forward satellite
  1024. communications techniques. The UoSAT-OSCAR- 11 Digital Communications
  1025. Experiment (DCE), funded by the Volunteers In Technical Assistance (VITA)
  1026. and built by VITA/AMSAT volunteers in the US, UK and Canada, provided the
  1027. first operational tests of store-and-forward PACSAT communications within
  1028. the amateur satellite service. Drawing on the operational and engineering
  1029. data gained from the DCE, UoSAT and VITA are developing a high performance
  1030. digital store-and-forward communications payload specially tailored for use
  1031. by inexpensive ground stations. To test this payload, UoSAT-C will carry
  1032. the PACSAT Communications Experiment (PCE). The PCE will be openly
  1033. accessible to radio amateurs operating in the 2-meter and 70-cm bands
  1034. (Mode-J). VITA is seeking additional frequency allocations outside the
  1035. amateur bands to allow limited use of the UoSAT-C PCE by VITA ground
  1036. stations in remote areas to provide technical assistance and disaster
  1037. relief.
  1038.  
  1039. o  Radiation Studies Experiments
  1040.  
  1041. Microprocessor-controlled payloads such as the PCE cannot be built without
  1042. VLSI semiconductors and most recent and affordable VLSI devices have not
  1043. yet been tested for space use. UoSAT-C will host several experimental
  1044. payloads studying the effects of the space radiation environment on VLSI
  1045. devices:
  1046.  
  1047. Cosmic Particle Experiment (CPE), comprising an array of large- area PIN
  1048. diodes, will detect energetic particles which cause single event upsets
  1049. (SEUs) in VLSI circuits (such as high-density RAMs).
  1050.  
  1051. CCD Single Event Upset Experiment (CCD-SEU), comprising an enclosed
  1052. charge-coupled device (CCD) array, will detect energetic cosmic particles
  1053. and evaluate the effect of SEUs on CCD imagers.  This data is of particular
  1054. importance for scientists using sensitive CCDs as star sensors.
  1055.  
  1056. Total Dose Experiment (TDE), using special FETs located around the
  1057. spacecraft, will measure the total radiation dose accumulated by the
  1058. on-board subsystems and payloads. These dose measurements will allow
  1059. engineers to assess the shielding properties of the spacecraft structure
  1060. and to correlate changes in LSI-device power consumption and performance
  1061. with total radiation dose.
  1062.  
  1063. o  Satellite Technology Experiments
  1064.  
  1065. UoSAT-C will carry a range of satellite technology experiments associated
  1066. with power systems, on-board data handling (OBDH), attitude determination,
  1067. control and stabilization (ADCS) and RF modulation.
  1068.  
  1069. o Power
  1070.  
  1071. The spacecraft will be powered from GaAs solar cells and will include
  1072. experimental patches of novel GaAs, InPe and Si solar cells with a variety
  1073. of newly-developed cover-slides. The performance of these cells will be
  1074. monitored throughout the mission as a function of radiation dose. The
  1075. spacecraft on-board computers will constantly monitor and adjust the
  1076. Battery Charge Regulator and Power Conditioning Module to optimize power
  1077. conversion and storage efficiency.
  1078.  
  1079. o On-Board Computers
  1080.  
  1081. UoSAT-C will include several computers. In addition to the primary RCA1802
  1082. on-board computer (OBC-1) running DIARY-type software, there will be a more
  1083. powerful 80C86-based, OBC-2 supporting complex attitude control algorithms
  1084. and spacecraft data networks. Four transputers in a parallel-processing
  1085. array will be available for highly sophisticated on-board image and data
  1086. processing and the PCE will employ an 80C186-family computer to manage
  1087. high-speed communications links and several megabytes of RAM.
  1088.  
  1089. A wide range of memory devices using different technologies and
  1090. architectures will make up a total on-board capacity of around 5 megabytes
  1091. of RAM. The radiation-induced effects on the processors and associated
  1092. memories will be monitored and evaluated throughout the lifetime of the
  1093. spacecraft.  The network of computers on UoSAT-C will make this spacecraft
  1094. the most computationally powerful of its class and will support demanding
  1095. experiments in advanced spacecraft attitude determination and control, data
  1096. communications and image processing.
  1097.  
  1098. o Attitude Determination and Control
  1099.  
  1100. The 43-degree-inclination, non-sun-synchronous nature of the UO-C orbit
  1101. will necessitate the use of new attitude determination and control
  1102. mechanisms to maintain accurate Earth pointing. In addition to more-complex
  1103. attitude control algorithms executed by OBC-2, improved analog and digital
  1104. sun sensors and Earth horizon sensors are being developed at UoS for the
  1105. mission.
  1106.  
  1107. o Digital Signal Processing
  1108.  
  1109. If time and resources permit, a Digital Signal Processing Experiment may be
  1110. included on UO-C to evaluate modulation/demodulation schemes.
  1111.  
  1112. o Modular Construction
  1113.  
  1114. A new concept of highly modular construction has been developed and is
  1115. under test for UoSAT-C. This new, modular structure should result in much
  1116. improved utilization of the available spacecraft envelope, greater ease of
  1117. assembly and integration and allow a more rapid response to future launch
  1118. opportunities.
  1119.  
  1120. For The Users
  1121.  
  1122. Like UO-9 and UO-11, UoSAT-OSCAR-C will support a worldwide user community
  1123. of engineers, scientists, educators and communicators.  If all goes
  1124. according to plan, UO-C will provide spacecraft housekeeping telemetry,
  1125. long-term telemetry surveys, results from on-board experiments, news
  1126. bulletins and communications facilities on a single downlink through
  1127. packet-radio techniques.  We will finalize and publish communications modem
  1128. and protocol details as soon as possible to allow ground stations to equip
  1129. themselves.
  1130.  
  1131. While numerous international teams are already collaborating on UO-C, UoSAT
  1132. is interested in hearing from others interested in possible collaboration,
  1133. especially in the area of user ground station support.
  1134.  
  1135. The UoSAT team are happy to be able to make a public announcement of the
  1136. UoSAT-C mission and we hope that it will contribute to the long history of
  1137. successful and technically important OSCAR and RS missions and maintain the
  1138. tradition of international collaboration in the amateur satellite service.
  1139.  
  1140. >from Dr. Martin Sweeting, G3YJO,
  1141.   Director of Satellite Engineering,
  1142.   University of Surrey
  1143.  
  1144. THE "STAGGERED BACKBONE" NETWORK CONCEPT
  1145.  
  1146. Florida's packet radio network has undergone many evolutionary changes over
  1147. the last several years.  First, there were many individual packeteers
  1148. connecting over long distances on quiet channels.  Then, as more people
  1149. joined in, dedicated digipeaters were pressed into service.  Then came
  1150. switches, the 220-MHz backbone and, most recently, NET/ROM.  At a Southern
  1151. Region Wide Area Networking Symposium, I proposed what I believe will be
  1152. the next evolutionary step in the development of our network.  I call it
  1153. the "Staggered Backbone."
  1154.  
  1155. We knew a long time ago that as the number of users and PBBSs grew, it
  1156. would become impractical to move traffic between portions of the network on
  1157. the same 2-meter RF channels that were shared by the users.  We also knew
  1158. that packeteers in adjacent towns would cause unnecessary interference to
  1159. each other as they all tried to access their local digipeater and hear each
  1160. other.  We, therefore, moved towards an architecture in our network that
  1161. allowed users in a given area (called a Local Area Network, LAN) to reside
  1162. on a different 2-meter channel than their neighbors.  We tied all of the
  1163. LANs together using the 220-MHz band.  This is roughly where the network
  1164. stands today.
  1165.  
  1166. There is still room for improvement.  We have discovered that the same
  1167. problems of "hidden transmitters" (where two stations cannot hear each
  1168. other and, therefore, transmit at the same time) and "hold off" (where a
  1169. station is prevented from transmitting for long periods of time because of
  1170. other traffic) exist on the backbone and cause the same congestion there as
  1171. on 145.010 MHz.  Because the number of stations which access the backbone
  1172. directly is deliberately kept small, the problem is minimized to a certain
  1173. extent, but not eliminated.
  1174.  
  1175. Another problem which confronts the current backbone structure is the issue
  1176. of how to increase its speed in the future.  With all of the nodes on the
  1177. backbone operating at 1200 bauds, speeding things up might require that
  1178. every node upgrade on the same day (an impossible situation) or that some
  1179. nodes move to a different frequency, thus, breaking the backbone.
  1180.  
  1181. The staggered backbone solves many of these problems and has a great
  1182. potential for allowing a significant increase in the overall network
  1183. throughput.  The staggered backbone concept is built upon the fact that
  1184. NET/ROM software allows a three-port or four-port node to be assembled
  1185. quite easily.  Three ports allow the node to operate on three separate
  1186. frequencies (or bands) at the same time and to route packets between them.
  1187.  
  1188. In a network with a staggered backbone, most nodes would consist of three
  1189. TNCs and three transceivers operating on the 144, 220 and 440-MHz bands
  1190. (other bands may be used as appropriate). The 144-MHz port serves the local
  1191. users on a preassigned LAN frequency and connects to the other ports via a
  1192. special serial port cable and diode matrix.  The 220-MHz port handles the
  1193. transfer of information to neighbors in one direction; the 440- MHz port
  1194. handles information going in another direction.  The reason for choosing
  1195. three separate ham bands is to minimize interference between the radios
  1196. without the need for costly tuned cavities and special filters.
  1197.  
  1198. The staggered backbone works best where the network topology is basically
  1199. linear.  Where Y-shaped splits in the network are required, the options are
  1200. to use still another band (eg, 900 MHz) in place of 144 MHz (resulting in a
  1201. dedicated three-port backbone node with no LAN service), construct a
  1202. four-port node (to serve the node plus three backbone frequencies) or to
  1203. stick with the current scheme of having three different background nodes on
  1204. a common frequency (this last option should only be used if the three nodes
  1205. can all hear each other clearly).
  1206.  
  1207. A list of the benefits of using a staggered backbone follow.
  1208.  
  1209. 1.  Since there are only two nodes on any given backbone radio link,
  1210. "hidden transmitter" and "hold off" are completely eliminated from these
  1211. links.  In fact, the only place that packets can collide (besides on the
  1212. LAN) is in the cable that mates the TNCs at the node.  And, since
  1213. communication between TNCs typically runs at 4800 or 9600 bauds and does
  1214. not include TXDELAYS and long DWAITS, the TNCs can recover from collisions
  1215. on the cable very quickly.  Also, all of the TNCs talking on the cable can
  1216. hear each other clearly, so there are no "hidden transmitters" there.
  1217.  
  1218. 2. The speed of any individual link can be increased at any time without
  1219. creating a logistics nightmare.  In fact, whenever two adjacent nodes agree
  1220. that they are prepared to go faster, they can do it at their convenience.
  1221. The only thing that the rest of the network will notice is improved
  1222. performance and some temporary down time while they switch over.
  1223.  
  1224. 3. Backbone nodes can take advantage of directional antenna systems to
  1225. "squirt" all of their signals to a specific neighbor instead of having to
  1226. use omnidirectional antennas or directional antennas with power splitters.
  1227. So, in addition to the improvements gained by having a quieter channel,
  1228. many nodes would see an increased signal strength from their neighbors.
  1229.  
  1230. 4.  Automatic routing table updates managed by the nodes can be trusted
  1231. again.  In many areas, nodes are operating with "permed" tables because of
  1232. NET/ROM's tendency to hear a distant broadcast and add it to a routing
  1233. table as a high quality path.  With less traffic on the same frequency and
  1234. directional antennas in use, the chances of this happening are greatly
  1235. reduced.
  1236.  
  1237. The transition from the current backbone to a staggered backbone is very
  1238. straight forward and, equipment costs aside, could be accomplished in a
  1239. short time.  Many of the nodes along the Florida Gold Coast have made plans
  1240. to proceed along this line; the backbone link from Boca Raton to Hollywood
  1241. will probably be the first to move to 440 MHz on a permanent basis
  1242. sometimes early this year.  We hope that others will join us and continue
  1243. to strive for improvements in the network in all areas.
  1244.  
  1245. >from Bill Piazza, KB4QVY @ W4NVC via FADCA>Beacon
  1246.  
  1247. GATEWAY CONTRIBUTIONS
  1248.  
  1249. Submissions for publication in Gateway are welcome.  You may submit
  1250. material via the US mail to:
  1251.  
  1252.    Gateway
  1253.    Stan Horzepa, WA1LOU
  1254.    75 Kreger Drive
  1255.    Wolcott, CT 06716-2702
  1256.  
  1257. or electronically, via CompuServe to user ID 70645,247.  Via
  1258. telephone, your editor can be reached at 203-879-1348 on evenings
  1259. and weekends, and he can switch a modem on line to receive text
  1260. at 300, 1200, or 2400 bauds.
  1261.  
  1262.  
  1263. REPRODUCTION OF GATEWAY MATERIAL
  1264.  
  1265. Material may be excerpted from Gateway without prior permission,
  1266. provided that the original contributor is credited and Gateway is
  1267. identified as the source.
  1268.  
  1269. -- 
  1270. Gary W. Sanders         {cbosgd|ihnp4}!osu-cis!n8emr!gws
  1271. (cis) 72277,1325        (packet) N8EMR @ W8CQK
  1272. HAM/SWL BBS (HBBS) 614-457-4227.. 300/1200 bps
  1273.  
  1274.  
  1275. 15-Apr-88 20:03:50-EDT,1465;000000000000
  1276. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 15 Apr 88 20:03-EDT
  1277. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA07012@EDDIE.MIT.EDU>; Fri, 15 Apr 88 18:56:19 EDT
  1278. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA07003@EDDIE.MIT.EDU>; Fri, 15 Apr 88 18:56:02 EDT
  1279. Received: by june.cs.washington.edu (5.52.1/6.13)
  1280.     id AA10346; Fri, 15 Apr 88 15:47:03 PDT
  1281. Return-Path: <ll-xn!ames!ucsd!brian@EDDIE.MIT.EDU>
  1282. Message-Id: <8804152247.AA10346@june.cs.washington.edu>
  1283. Date: 14 Apr 88 23:53:22 GMT
  1284. From: ll-xn!ames!ucsd!brian@EDDIE.MIT.edu (Brian Kantor)
  1285. To: PACKET-RADIO@EDDIE.MIT.EDU
  1286. Subject: Re: HK232 RF noise
  1287. Keywords: RF noise, HK232, PK232
  1288. References: <258@gandalf.littlei.UUCP>
  1289. Reply-To: brian@UCSD.edu (Brian Kantor)
  1290.  
  1291. I have not examined the Heath version, but my PK-232 radiated like a
  1292. sonofabitch!  Here's what I did to make it tolerable:
  1293.  
  1294. Star lockwashers under brass screws to hold the cabinet together
  1295.  
  1296. Scrape and polish the cabinet so that the top and bottom made good
  1297. contact.
  1298.  
  1299. Replace DC power feed with a Pi-net RFI feedthrough (looks like a
  1300. feedthrough-bypass capacitor but has more guts inside).
  1301.  
  1302. Bolt the sockets down so that RS232 cable really does get grounded.
  1303.  
  1304. Sprinkle a few bypasses (.001) onto the various lines going to
  1305. transceiver, power supply, etc.
  1306.  
  1307. Stick conductive metal tape over all the unused connector holes.
  1308.  
  1309.     Brian Kantor    WB6CYT  UC San Diego   brian@ucsd.edu
  1310.  
  1311.  
  1312. 16-Apr-88 00:23:41-EDT,991;000000000000
  1313. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Apr 88 00:23-EDT
  1314. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA12938@EDDIE.MIT.EDU>; Fri, 15 Apr 88 23:30:21 EDT
  1315. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA12908@EDDIE.MIT.EDU>; Fri, 15 Apr 88 23:29:55 EDT
  1316. Received: from huey.udel.edu by Louie.UDEL.EDU id aa06869; 15 Apr 88 23:27 EDT
  1317. Date:     Fri, 15 Apr 88 23:25:27 EDT
  1318. From: Mills@UDEL.EDU
  1319. To: Brian Kantor <brian@ucsd.edu>
  1320. Cc: PACKET-RADIO@eddie.mit.edu
  1321. Subject:  Re:  HK232 RF noise
  1322. Message-Id:  <8804152325.aa26778@Huey.UDEL.EDU>
  1323.  
  1324. Brian,
  1325.  
  1326. My PK232 is quiet as a lamb, but my Heath GC1000 clock radiates like a
  1327. banshee. Boy, before all this computer stuff, I could work the microvolts
  1328. right through ten meters. Now, you can use the spurs from the neighbor's
  1329. PC, stereo and watch as beacons for fuxhunts. Try probing near your
  1330. multiplexed frequency display of your radio with a wire connected to the
  1331. antenna jack...
  1332.  
  1333. Dave
  1334. 16-Apr-88 16:59:40-EDT,1954;000000000000
  1335. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Apr 88 16:59-EDT
  1336. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25853@EDDIE.MIT.EDU>; Sat, 16 Apr 88 16:09:33 EDT
  1337. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25849@EDDIE.MIT.EDU>; Sat, 16 Apr 88 16:09:24 EDT
  1338. Received: by june.cs.washington.edu (5.52.1/6.13)
  1339.     id AA04237; Sat, 16 Apr 88 13:08:33 PDT
  1340. Return-Path: <bellcore!faline!thumper!karn@EDDIE.MIT.edu>
  1341. Message-Id: <8804162008.AA04237@june.cs.washington.edu>
  1342. Date: 14 Apr 88 20:03:09 GMT
  1343. From: bellcore!faline!thumper!karn@EDDIE.MIT.edu (Phil R. Karn)
  1344. To: PACKET-RADIO@EDDIE.MIT.EDU
  1345. Subject: Re: HK232 RF noise
  1346. Summary: RS-232 line filters
  1347. Keywords: RF noise, HK232, PK232
  1348. References: <258@gandalf.littlei.UUCP>
  1349.  
  1350. > I purchased and built the Heathkit HK-232 multimode controller last
  1351. > week.  Unfortunately it generates incredible amounts of RF noise,
  1352. > particularly at every MHz from about 40 to 165 MHz.  To make matters
  1353. > worse, this noise radiates primarily from the cable which connects the
  1354. > TNC to the radio.
  1355.  
  1356. Go to a hamfest and get some RS-232 line filters. They consist of male
  1357. and female DB-25 connectors on opposite ends of a small metal housing,
  1358. resembling small "null modems". The pins are connected straight through,
  1359. but each each line is individually bypassed to the case. Often there is
  1360. "finger stock" on the sides of the "D" part of the connector to ensure
  1361. good, continuous ground contact.
  1362.  
  1363. Mount one of these connectors on the back of your PK-232, and make sure
  1364. that the shell is well bonded to the case. Also put one on the back of
  1365. your computer or terminal.  If the RFI is in fact being conducted out
  1366. the serial line and then radiating, this should help the problem
  1367. enormously.
  1368.  
  1369. I picked up a handful of filters at the Timonium MD hamfest for $4.00
  1370. each, the going price. I put them on everything, the back of my PCs, my
  1371. TNCs, modems, etc.
  1372.  
  1373. Phil
  1374.  
  1375.  
  1376. 16-Apr-88 17:02:22-EDT,1689;000000000000
  1377. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Apr 88 17:02-EDT
  1378. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25892@EDDIE.MIT.EDU>; Sat, 16 Apr 88 16:11:53 EDT
  1379. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25886@EDDIE.MIT.EDU>; Sat, 16 Apr 88 16:11:39 EDT
  1380. Received: by june.cs.washington.edu (5.52.1/6.13)
  1381.     id AA04299; Sat, 16 Apr 88 13:10:49 PDT
  1382. From: tektronix!reed!percival!littlei!collier@beaver.cs.washington.edu
  1383. Return-Path: <tektronix!reed!percival!littlei!collier@beaver.cs.washington.edu>
  1384. Message-Id: <8804162010.AA04299@june.cs.washington.edu>
  1385. Date: 13 Apr 88 14:24:36 GMT
  1386. To: PACKET-RADIO@EDDIE.MIT.EDU
  1387. Subject: HK232 RF noise
  1388. Keywords: RF noise, HK232, PK232
  1389.  
  1390. I purchased and built the Heathkit HK-232 multimode controller last
  1391. week.  Unfortunately it generates incredible amounts of RF noise,
  1392. particularly at every MHz from about 40 to 165 MHz.  To make matters
  1393. worse, this noise radiates primarily from the cable which connects the
  1394. TNC to the radio.  Since the local packet frequency is 144.99, the spur
  1395. on 145 MHz pretty much prevents operation with any station less than
  1396. full strength into my receiver.
  1397.  
  1398. Has anyone else dealt with this problem?  The noise is apparently based
  1399. on the 4 MHz Z80 CPU clock.  The local Heathkit store sent the unit back
  1400. to Michigan for "repair".  Needless to say, if I'm out the $280 for the
  1401. TNC, I'll *NEVER* build another Heathkit.  I figured I was safe (*HA*!)
  1402. since this is the same unit that AEA builds, right down to the AEA copyright
  1403. on the circuit board.
  1404.  
  1405. Thanks in advance,
  1406.  
  1407. Collier Chun
  1408. NM7B
  1409. Intel Corporation
  1410. OEM Platforms Operation
  1411. Hillsboro, Oregon
  1412.  
  1413.  
  1414. 17-Apr-88 01:38:25-EDT,1395;000000000000
  1415. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 17 Apr 88 01:38-EDT
  1416. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02812@EDDIE.MIT.EDU>; Sun, 17 Apr 88 00:41:54 EDT
  1417. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02799@EDDIE.MIT.EDU>; Sun, 17 Apr 88 00:41:31 EDT
  1418. Received: from huey.udel.edu by Louie.UDEL.EDU id aa25247; 17 Apr 88 0:23 EDT
  1419. Date:     Sun, 17 Apr 88 0:20:00 EDT
  1420. From: Mills@UDEL.EDU
  1421. To: "Phil R. Karn" <bellcore!faline!thumper!karn@eddie.mit.edu>
  1422. Cc: PACKET-RADIO@eddie.mit.edu
  1423. Subject:  Re:  HK232 RF noise
  1424. Message-Id:  <8804170020.aa05044@Huey.UDEL.EDU>
  1425.  
  1426. Phil,
  1427.  
  1428. Since I have several computers and other hash generators cluttering up the
  1429. shack, I have had to mount a pretty mean spur-control program myself. I first
  1430. tried using shielded cables with unshielded hoods and the shiled grounded at
  1431. one end, but this did not work effectively. I did find that shileded cables
  1432. with metal hoods, the shield bonded to the hoods at each end and the hoods
  1433. securely contacted to the hash-generator case worked very well. I found that,
  1434. if shielded cables are used everywhere and the cabinets and power connections
  1435. are tight, the hash is pretty well controlled. My biggest problem now is a 
  1436. a Heath GC-1000 clock, which leaks hash back up the antenna lead, and the various
  1437. video displays, which radiate right off the screens.
  1438.  
  1439. Dave
  1440. 19-Apr-88 01:42:40-EDT,3917;000000000000
  1441. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 19 Apr 88 01:42-EDT
  1442. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA07062@EDDIE.MIT.EDU>; Tue, 19 Apr 88 00:43:05 EDT
  1443. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA07046@EDDIE.MIT.EDU>; Tue, 19 Apr 88 00:42:32 EDT
  1444. Received: by june.cs.washington.edu (5.52.1/6.13)
  1445.     id AA06534; Mon, 18 Apr 88 21:43:55 PDT
  1446. Return-Path: <hou2d!n2dsy@EDDIE.MIT.edu>
  1447. Message-Id: <8804190443.AA06534@june.cs.washington.edu>
  1448. Date: 18 Apr 88 17:36:16 GMT
  1449. From: hou2d!n2dsy@EDDIE.MIT.edu (G.BEATTIE)
  1450. To: PACKET-RADIO@EDDIE.MIT.EDU
  1451. Subject: RATS Open Systems Environment (ROSE) Forum at the 1988 Dayton Hamvention
  1452. Keywords: RATS ROSE Open Systems OSI ISO CCITT Amateur Radio
  1453.  
  1454.  
  1455.  
  1456.  
  1457.            The Radio Amateur Telecommunications Society
  1458.  
  1459.              206 North Vivyen Street
  1460.  
  1461.               Bergenfield, New Jersey  07621
  1462.  
  1463.  
  1464.                    201-387-8896
  1465.  
  1466.        The Radio Amateur Telecommunications Society (RATS) is proud to present
  1467.  
  1468.           a forum at the 1988 Dayton Hamvention called:
  1469.  
  1470.        ROSE: Open Systems Networking in the RATS Open Systems Environment
  1471.  
  1472.        The talk will focus on the reality of Open Systems
  1473.        Networking in Amateur Radio.  The Society has been involved
  1474.        in the development of mail/file/directory servers and
  1475.        networking software based on international communications
  1476.        standards.
  1477.  
  1478.        Radio Amateurs who are telecommunications professionals or
  1479.        packet radio users will find this talk especially
  1480.        interesting and enlightening, but the novice networker will
  1481.        have no trouble following the presentation.
  1482.  
  1483.        * Software Distribution
  1484.  
  1485.        Currently, the beta version of the ROSE X.25 Packet Switch
  1486.        and the release of the ROSErver/Packet Radio MailBox System
  1487.        are available.  The Society will distribute the latest
  1488.        releases of its software at the session.  Bring 5-1/4 or 3-
  1489.        1/2 inch diskettes for software and documentation.  Remember
  1490.        RATS distributes its software for free!  Come and get it!
  1491.  
  1492.        * Where to Find RATS at Dayton
  1493.  
  1494.        Members of RATS will be present in the PAC-COMM Packet Radio
  1495.        Systems booth (Booth 277/278).  Members will be able to
  1496.        demonstrate and copy software for you to take home and use.
  1497.        Handouts describing our activities and frequencies of
  1498.        operation will be distributed at the packet forum on Friday
  1499.        afternoon from 1-5.  We also are planning to be available
  1500.        for the Packet Get-Together at McNasty's on Saturday
  1501.        evening.
  1502.  
  1503.  
  1504.        The RATS ROSE Forum
  1505.  
  1506.        Time:   9:30 - 11:00
  1507.  
  1508.        Place:  ROOM 1 (check your programme to be sure)
  1509.  
  1510.        The forum will consist of three three 30 minute talks.  Each
  1511.        will explore an aspect of the Open Systems implemented by
  1512.        the Radio Amateur Telecommunications Society (RATS).
  1513.        Questions will be taken by each speaker.
  1514.  
  1515.        Schedule
  1516.  
  1517.        09:30   Review of Open Systems Networks and Protocols
  1518.  
  1519.            - Presented by J. Gordon Beattie, Jr., N2DSY
  1520.  
  1521.          This talk will provide an overview of a network
  1522.          based on Open Systems.  The specific protocols
  1523.          and user services will be defined alone with the
  1524.          network management and planning dependencies found
  1525.          in a cooperative network.
  1526.  
  1527.        10:00   The ROSE X.25 Packet Switch
  1528.  
  1529.            - Presented by Thomas A. Moulton, W2VY
  1530.  
  1531.          This talk will concentrate on the OSI Network Services
  1532.          and how the ROSE X.25 Switch will support the users of
  1533.          "vanilla" AX.25, OSI Applications, TCP/IP and Net/ROM.
  1534.  
  1535.        10:30   The ROSErver Mail, File and Directory Server
  1536.  
  1537.            - Presented by Andrew R. Funk, KB7UV
  1538.  
  1539.          This talk will concentrate on OSI Application Services
  1540.          and how the ROSErver/Packet Radio Mail Box System will
  1541.          provide these services to users and other systems.
  1542.  
  1543.  
  1544. 19-Apr-88 15:48:13-EDT,1638;000000000000
  1545. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 19 Apr 88 15:48-EDT
  1546. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02104@EDDIE.MIT.EDU>; Tue, 19 Apr 88 13:36:21 EDT
  1547. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02087@EDDIE.MIT.EDU>; Tue, 19 Apr 88 13:35:58 EDT
  1548. Received: by june.cs.washington.edu (5.52.1/6.13)
  1549.     id AA03524; Tue, 19 Apr 88 10:37:25 PDT
  1550. Return-Path: <cornell!batcomputer!sun.soe.clarkson.edu!nelson@eddie.mit.edu>
  1551. Message-Id: <8804191737.AA03524@june.cs.washington.edu>
  1552. Date: 19 Apr 88 15:33:59 GMT
  1553. From: cornell!batcomputer!sun.soe.clarkson.edu!nelson@eddie.mit.edu (Russ Nelson)
  1554. To: PACKET-RADIO@EDDIE.MIT.EDU
  1555. Subject: Re: TCP/IP at Dayton and Trenton
  1556. Keywords: TCP IP ARPA Internet KA9Q
  1557. References: <1983@hou2d.UUCP> <1054@thumper.bellcore.com>
  1558. Reply-To: sun.soe.clarkson.edu!nelson@june.cs.washington.edu (Russ Nelson)
  1559.  
  1560. In article <1054@thumper.bellcore.com> karn@thumper.bellcore.com (Phil R. Karn) writes:
  1561. >The KA9Q Internet Protocol Package will also be described and
  1562. >demonstrated at both the Trenton Computer Festival ...
  1563. >The entire package, which includes complete C source code ...
  1564. >I will bring a limited supply of copies, but bring your own blank disks
  1565. >if you want to be sure of getting a copy. ...
  1566.  
  1567. I'll give Phil a few copies of my Turbo C porting kit on 5 1/4 360 K
  1568. disks.
  1569.  
  1570. The porting kit is updated to version 871225.18, and is on clutx.clarkson.edu
  1571. [128.153.4.3] in pub/Ka9q/kit.arc via anonymous ftp.
  1572. -- 
  1573. char *reply-to-russ(int network) {
  1574. if(network == BITNET) return "NELSON@CLUTX";
  1575. else return "nelson@clutx.clarkson.edu"; }
  1576.  
  1577.  
  1578. 19-Apr-88 16:15:38-EDT,2595;000000000000
  1579. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 19 Apr 88 16:15-EDT
  1580. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02142@EDDIE.MIT.EDU>; Tue, 19 Apr 88 13:37:59 EDT
  1581. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA01105@EDDIE.MIT.EDU>; Tue, 19 Apr 88 13:08:38 EDT
  1582. Received: by june.cs.washington.edu (5.52.1/6.13)
  1583.     id AA17025; Tue, 19 Apr 88 07:13:04 PDT
  1584. Return-Path: <bellcore!faline!thumper!karn@EDDIE.MIT.EDU>
  1585. Message-Id: <8804191413.AA17025@june.cs.washington.edu>
  1586. Date: 19 Apr 88 05:59:05 GMT
  1587. From: bellcore!faline!thumper!karn@eddie.mit.edu (Phil R. Karn)
  1588. To: PACKET-RADIO@EDDIE.MIT.EDU
  1589. Subject: TCP/IP at Dayton and Trenton
  1590. Summary: KA9Q TCP/IP software available at Dayton
  1591. Keywords: TCP IP ARPA Internet KA9Q
  1592. References: <1983@hou2d.UUCP>
  1593.  
  1594. The KA9Q Internet Protocol Package will also be described and
  1595. demonstrated at both the Trenton Computer Festival and at the Dayton
  1596. Hamvention.  This package is now estimated to be in the hands of at
  1597. least several thousand people around the world, and it is enjoying
  1598. rapidly increasing popularity on amateur packet radio. It presently
  1599. supports the following proven, industry standard protocols:
  1600.  
  1601. Applications:
  1602.  
  1603.     Telnet - remote login and "chatting"
  1604.     FTP - File transfer (binary or text)
  1605.     SMTP - Mail transfer
  1606.  
  1607. Transport/Session:
  1608.  
  1609.     TCP - Transmission Control Protocol
  1610.     UDP - User Datagram Protocol
  1611.  
  1612. Network:
  1613.  
  1614.     IP - Internet Protocol
  1615.     ICMP - Internet Control Message Protocol
  1616.  
  1617. Link/Subnet:
  1618.  
  1619.     ARP - Address Resolution Protocol
  1620.     Ethernet - 3Com 3C-501 interface driver
  1621.     AX.25 - packet radio (both connected and unconnected modes)
  1622.     SLIP - asynchronous point-to-point links
  1623.  
  1624. The primary machine supported is the IBM PC (and clones). Versions are also
  1625. available for the Apple Macintosh, Commodore Amiga, and UNIX System V.
  1626.  
  1627. The entire package, which includes complete C source code and
  1628. documentation, is copyrighted by myself and others, but it is completely
  1629. FREE for noncommercial use. I encourage you to make copies for your
  1630. friends back home; this minimizes the number of copies I have to make.
  1631.  
  1632. I will bring a limited supply of copies, but bring your own blank disks
  1633. if you want to be sure of getting a copy. The package fits on one
  1634. high-density 1.2 meg 5.25" floppy, two 720K 3.5" floppies, or three 360K
  1635. 5.25" floppies. I should be able to handle all three formats at both
  1636. Trenton and Dayton.
  1637.  
  1638. For those of you with Internet access, you may obtain the package by
  1639. anonymous FTP from louie.udel.edu (10.0.0.96) under /pub/ka9q.
  1640.  
  1641. 73, Phil Karn, KA9Q
  1642.  
  1643.  
  1644. 20-Apr-88 14:07:01-EDT,3806;000000000000
  1645. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 20 Apr 88 14:07-EDT
  1646. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00171@EDDIE.MIT.EDU>; Wed, 20 Apr 88 11:48:55 EDT
  1647. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00113@EDDIE.MIT.EDU>; Wed, 20 Apr 88 11:47:08 EDT
  1648. Received: by tecnet-clemson.arpa (5.52/SMI-3.2)
  1649.     id AA28728; Wed, 20 Apr 88 05:18:25 EST
  1650. Date: Wed, 20 Apr 88 05:18:25 EST
  1651. From: q2mgb@tecnet-clemson.arpa
  1652. Message-Id: <8804201018.AA28728@tecnet-clemson.arpa>
  1653. To: &radio
  1654. Posted: Apr 20 04:57 EST
  1655. Subject: Re: HK232 RF noise
  1656.  
  1657.  
  1658. Subject: radio: Re: HK232 RF noise
  1659.  
  1660. >From: tektronix!reed!percival!littlei!collier@beaver.cs.washington.edu
  1661. > I purchased and built the Heathkit HK-232 multimode controller last
  1662. > week.  Unfortunately it generates incredible amounts of RF noise,
  1663. > particularly at every MHz from about 40 to 165 MHz.  To make matters
  1664. > worse, this noise radiates primarily from the cable which connects the
  1665. > TNC to the radio.
  1666.  
  1667. >Collier Chun
  1668. >NM7B
  1669. >Intel Corporation
  1670. >OEM Platforms Operation
  1671. >Hillsboro, Oregon
  1672.  
  1673. >>From: bellcore!faline!thumper!karn@EDDIE.MIT.EDU (Phil R. Karn)
  1674. >>Go to a hamfest and get some RS-232 line filters. They consist of male
  1675. >>and female DB-25 connectors on opposite ends of a small metal housing,
  1676. >>resembling small "null modems". The pins are connected straight through,
  1677. >>but each each line is individually bypassed to the case. Often there is
  1678. >>"finger stock" on the sides of the "D" part of the connector to ensure
  1679. >>good, continuous ground contact.
  1680.  
  1681. >>From: ll-xn!ames!ucsd!brian@EDDIE.MIT.EDU (Brian Kantor)
  1682. >>Star lockwashers under brass screws to hold the cabinet together
  1683. >>Scrape and polish the cabinet so that the top and bottom made good
  1684. >>contact.
  1685. >>Replace DC power feed with a Pi-net RFI feedthrough (looks like a
  1686. >>Bolt the sockets down so that RS232 cable really does get grounded.
  1687. >>Sprinkle a few bypasses (.001) onto the various lines going to
  1688. >>transceiver, power supply, etc.
  1689. >>Stick conductive metal tape over all the unused connector holes.
  1690.  
  1691. All good suggestions. I'll try to add one more. My problems were from a
  1692. Kantronics KAM and a MFJ-1274B and I found one of the biggest radiators
  1693. of the noise was the power cord (unshielded) to the TNC's. Right up there
  1694. with that was the 232 cable and the cabling to the radio as previously
  1695. noted above. A quick and dirty trick that you can use AFTER you have 
  1696. replaced all wiring with shielded cable and bypassed all signal lines,
  1697. is to run the power line, the 232 cable, and the radio hookup wiring
  1698. through toroidal inductors, one for each of the three above. Run at
  1699. least three (or more) turns of the cable through the toroid. Place the
  1700. toroids as close as possible to the source of the noise. i.e. The TNC.
  1701. Use of ferrite beads on all non-data lines is also recommended. The use
  1702. of ferrite beads on the actual data lines can be hazardous due to roll
  1703. off on the edges of the square waves causing distortion at high baud
  1704. rates. However, running shielded multi-wire cabling though a large 
  1705. toroid will not affect the signals on the internal wires. This will be 
  1706. very effective in choking the RF off the shield and especially off the 
  1707. power wiring. 
  1708.  
  1709. Although it may seem like a lot of work, if you follow all the suggestions
  1710. listed here and above, I can guarantee that your noise will not only be
  1711. reduced to tolerable levels but will be almost completely eliminated. If
  1712. on the OFF CHANCE that you still have a birdie sitting smack dab right
  1713. on top of the frequency you want to use, a LAST DITCH method is to SLIGHTLY
  1714. bump the 4 MHZ clock freq. This should not be done until all the other 
  1715. methods have been attempted.
  1716.  
  1717. Mark Bitterlich
  1718. WA3JPY
  1719. Iwakuni Japan
  1720. q2mgb@tecnet-clemson.arpa
  1721. 20-Apr-88 17:13:26-EDT,2234;000000000000
  1722. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 20 Apr 88 17:13-EDT
  1723. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA05853@EDDIE.MIT.EDU>; Wed, 20 Apr 88 15:26:20 EDT
  1724. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA05833@EDDIE.MIT.EDU>; Wed, 20 Apr 88 15:25:47 EDT
  1725. Message-Id: <8804201925.AA05833@EDDIE.MIT.EDU>
  1726. 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
  1727. Date: Tue, 19 Apr 88 17:43:42 MEZ
  1728. To: PACKET-RADIO@MIT-EDDIE.MIT.EDU
  1729. From: C0033003%DBSTU1.BITNET@CUNYVM.CUNY.EDU
  1730. Comment: CROSSNET mail via SMTP@INTERBIT
  1731. Subject: shipment of TheNet
  1732.  
  1733.           NORD><LINK
  1734. The northern Germany packet-radio development group
  1735.  
  1736. Thanks again to all OMs who supported me with UUENCODE / UUDECODE.
  1737. Unfortunatly this is not a reliable method for transfering files
  1738. over several gateways. I've tried it forward and backward again
  1739. and the files got scrambled after several EBCDIC / ASCII -conversions.
  1740. So I decided to post an INTEL-Hexdump of our TheNet firmware
  1741.  
  1742. We started shipment to all OMs who sent direct mail and included the
  1743. cost for the shipment this week.
  1744.  
  1745. If you're interested to get your copy look in the SIMTEL20 archive.
  1746. I'll depose it there this week but I can't tell how to access it from
  1747. there because there is no link between EARN/BITNET and SIMTEL20 for
  1748. anonymous FTP ( or is there one in the meantime? ).
  1749.  
  1750. All you have to do to make up your EPROM is to produce a header of the
  1751. EPROM ( your DIGI's callsign, ID, default password, etc.) append the
  1752. rest of the binary file and burn it into a 27(C)256. But remember not
  1753. to change the layout of the header, because some store&forward software
  1754. relies on the structure of the header.
  1755.  
  1756. You should keep the release note and the originator sign too. This
  1757. will make it possible to identify any unknown bugs (if there are any).
  1758.  
  1759. 73s de Detlef ( DK4EG )
  1760.  
  1761. Detlef J.Schmidt
  1762. Steinbrecher Str.22
  1763. D3300 Braunschweig
  1764. F.R.G.
  1765.  
  1766. C0033003 at dbstu1.bitnet
  1767.  C0033003%DBSTU1.BITNET@MITVMA.MIT.EDU
  1768.  C0033003%DBSTU1.BITNET@umd2.umd.edu")
  1769.  c0033003%dbstu1.bitnet%cunyvm.cuny.edu@BRL.ARPA
  1770.  CUNYVM.CUNY.EDU!C0033003%DBSTU1.BITNET@ucbvax.Berkeley.EDU
  1771. etc...
  1772. 21-Apr-88 12:04:36-EDT,1215;000000000000
  1773. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 Apr 88 12:04-EDT
  1774. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA03144@EDDIE.MIT.EDU>; Thu, 21 Apr 88 10:36:27 EDT
  1775. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA03135@EDDIE.MIT.EDU>; Thu, 21 Apr 88 10:36:11 EDT
  1776. Received: by june.cs.washington.edu (5.52.1/6.13)
  1777.     id AA18368; Thu, 21 Apr 88 07:36:29 PDT
  1778. Return-Path: <hplabs!hpcea!hpnmd!hpsrla!glenne@UCBVAX.Berkeley.edu>
  1779. Message-Id: <8804211436.AA18368@june.cs.washington.edu>
  1780. Date: 20 Apr 88 14:41:22 GMT
  1781. From: hplabs!hpcea!hpnmd!hpsrla!glenne@UCBVAX.Berkeley.edu (Glenn Elmore)
  1782. To: PACKET-RADIO@EDDIE.MIT.EDU
  1783. Subject: Re: TCP/IP at Dayton and Trenton
  1784. References: <1054@thumper.bellcore.com>
  1785.  
  1786. Phil,
  1787.  
  1788. Your TCP/IP package has also been ported to the Atari ST. I don't have it
  1789. in MY hands yet, but DG2KK has told me he has 12/25/87.4  running fine.
  1790. I am awaiting reiceipt of it and will do my best to disseminate it among the
  1791. ST users I know who are interested. He is also sending me his modified source
  1792. so I should be able to port more current versions myself, as time permits.
  1793.  
  1794. 73, Glenn
  1795.  
  1796. Glenn Elmore -N6GN-
  1797.  
  1798. N6GN @ N6IIU-1
  1799. glenne@hpsrla.HP.COM 
  1800.  
  1801.  
  1802. 21-Apr-88 18:30:04-EDT,2581;000000000000
  1803. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 21 Apr 88 18:30-EDT
  1804. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA13845@EDDIE.MIT.EDU>; Thu, 21 Apr 88 17:29:56 EDT
  1805. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA13829@EDDIE.MIT.EDU>; Thu, 21 Apr 88 17:29:16 EDT
  1806. Message-Id: <8804212129.AA13829@EDDIE.MIT.EDU>
  1807. 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
  1808. Date: Thu, 21 Apr 88 10:43:01 MEZ
  1809. To: PACKET-RADIO@MIT-EDDIE.MIT.EDU
  1810. From: C0033003%DBSTU1.BITNET@CUNYVM.CUNY.EDU
  1811. Comment: CROSSNET mail via SMTP@INTERBIT
  1812. Return-Receipt-To: C0033003@DBSTU1.BITNET
  1813. Subject: posting TheNet
  1814.  
  1815.           NORD><LINK
  1816. The northern Germany packet-radio development group
  1817.  
  1818. This is the 2nd trial to post this info. Maybee there's a big
  1819. black data hole somewhere ( or a sink in the Bermuda triangle? ).
  1820. So here it comes:
  1821.  
  1822. Thanks again to all OMs who supported me with UUENCODE / UUDECODE.
  1823.  
  1824. Unfortunatly this is not a reliable method for transfering files
  1825. over several gateways. I've tried it forward and backward again
  1826. and the files got scrambled after several EBCDIC / ASCII -conversions.
  1827. So I decided to post an INTEL-Hexdump of our TheNet firmware which
  1828. contains only uncritical characters.
  1829.  
  1830. We started shipment of TheNet to all OMs who sent direct mail and
  1831. included the cost for the shipment this week.
  1832.  
  1833. If you're interested to get your copy of TheNet take a look into the
  1834. SIMTEL20 archive. I'll try to depose it there this week but I can't
  1835. tell how to access it from there because there is no link between
  1836. EARN/BITNET and ARPA for anonymous FTP ( or is there one in the
  1837. meantime? ). For european BITNET-users I'll depose the hexdump in
  1838. the archive of FINHUTC.
  1839.  
  1840. All you have to do to make up your EPROM is to produce a header of the
  1841. EPROM ( your DIGI's callsign, ID, default password, etc.) append the
  1842. rest of the binary file and burn it into a 27(C)256. But remember not
  1843. to change the layout of the header, because some store&forward software
  1844. relies on the structure of the header.
  1845.  
  1846. You should keep the release note and the originator sign too. This
  1847. will make it possible to identify any unknown bugs (if there are any).
  1848.  
  1849. 73s de Detlef ( DK4EG )
  1850.  
  1851. Detlef J.Schmidt
  1852. Steinbrecher Str.22
  1853. D3300 Braunschweig
  1854. F.R.G.
  1855.  
  1856. C0033003 at dbstu1.bitnet
  1857.  C0033003%DBSTU1.BITNET@MITVMA.MIT.EDU
  1858.  C0033003%DBSTU1.BITNET@umd2.umd.edu")
  1859.  c0033003%dbstu1.bitnet%cunyvm.cuny.edu@BRL.ARPA
  1860.  CUNYVM.CUNY.EDU!C0033003%DBSTU1.BITNET@ucbvax.Berkeley.EDU
  1861. etc...
  1862. 26-Apr-88 21:22:40-EDT,742;000000000000
  1863. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 26 Apr 88 21:22-EDT
  1864. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00382@EDDIE.MIT.EDU>; Tue, 26 Apr 88 15:54:36 EDT
  1865. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00361@EDDIE.MIT.EDU>; Tue, 26 Apr 88 15:53:45 EDT
  1866. Message-Id: <8804261953.AA00361@EDDIE.MIT.EDU>
  1867. Received: from amc1 by AMC-HQ.ARPA id ac23702; 26 Apr 88 16:46 EDT
  1868. Date:     Tue, 26 Apr 88 15:44:23 EDT
  1869. From: Dbennett%AMC1@amc-hq.arpa
  1870. To: packet-radio%eddie.mit.edu@amc-hq
  1871. Subject:  Question?
  1872.  
  1873. Does anyone know the status of the German NetROM Clone that was to be
  1874. placed in simtel20 download area.  If it already has can some one give
  1875. me the full path name.
  1876.  
  1877. Don Bennett (K4NGC)
  1878. 27-Apr-88 15:56:02-EDT,2921;000000000000
  1879. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 Apr 88 15:56-EDT
  1880. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA27994@EDDIE.MIT.EDU>; Wed, 27 Apr 88 14:34:05 EDT
  1881. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA27976@EDDIE.MIT.EDU>; Wed, 27 Apr 88 14:33:34 EDT
  1882. Message-Id: <8804271833.AA27976@EDDIE.MIT.EDU>
  1883. 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
  1884. Date: Wed, 27 Apr 88 11:34:38 MEZ
  1885. To: PACKET-RADIO@MIT-EDDIE.MIT.EDU
  1886. From: C0033003%DBSTU1.BITNET@CUNYVM.CUNY.EDU
  1887. Comment: CROSSNET mail via SMTP@INTERBIT
  1888. Return-Receipt-To: C0033003@DBSTU1.BITNET
  1889. Subject: TheNet distribution, some hints
  1890.  
  1891.  
  1892.           NORD><LINK
  1893. The northern Germany packet-radio development group
  1894.  
  1895. Meanwhile I've sent the INTEL-hexdump of our TheNet to SIMTEL20. But I
  1896. don't have access to anonymous FTP from our BITNET here so I can't
  1897. check if it's available there. Just try it if you're interested to get
  1898. it.
  1899. If someone would like to distribute it in USA via BITNET just
  1900. give me a short input and I'll send another copy to you. But I don't
  1901. like to send it many times across the atlantic via email because
  1902. that's pretty expensive.
  1903. For european BITNET-users I'll post the file at FINHUTC. I've tried
  1904. it several times befor, but without success. I'll keep on trying.
  1905.  
  1906. We're still working on the source of TheNet to make it look clean,
  1907. especially updating all the comments. It should be available about
  1908. july.
  1909.  
  1910. If you've got your copy of the hexdump it is one of two versions:
  1911.  
  1912. 1st version starts like this
  1913. :10000000C34A010000000000C3407D000000000062
  1914. :10001000C3277D0000000000C3357D000000000004
  1915. :10002000C3377D0000000000C3F27D000000000027
  1916. :.......
  1917. it's about 96kB long.
  1918. This one needs only be chanched for your individual parameters. Then
  1919. burn it into a 27(C)256 plug into a TNC2 an go.
  1920.  
  1921. 2nd version starts like this:
  1922. :20010000C34A010000000000C3407D0000000000C3277D0000000000C3357D000000000075
  1923. :20012000C3377D0000000000C3F27D0000000000C3117D0000000000C3D17C4E4F3144455E
  1924. :2001400020605448454E4554320001006400FF000600050008070A002C0102000600B400B4
  1925. :........
  1926. it's about 78kB (less overhead than version 1.)
  1927. This complete hexdump has to be shifted 100hex downwards, which means
  1928. hexdump-address $100 corresponds to EPROM-address 0. After shifting it
  1929. downwards change your individual parameters and proceed like in the
  1930. 1st version.
  1931.  
  1932. Both versions should be the same, the difference is only in the notation
  1933. of the hexdump.
  1934.  
  1935. Let me know if you run into trouble with it.
  1936.  
  1937. 73s de Detlef ( DK4EG )
  1938.  
  1939. Detlef J.Schmidt
  1940. Steinbrecher Str.22
  1941. D3300 Braunschweig
  1942. F.R.G.
  1943.  
  1944. C0033003 at dbstu1.bitnet
  1945.  C0033003%DBSTU1.BITNET@MITVMA.MIT.EDU
  1946.  C0033003%DBSTU1.BITNET@umd2.umd.edu")
  1947.  c0033003%dbstu1.bitnet%cunyvm.cuny.edu@BRL.ARPA
  1948.  CUNYVM.CUNY.EDU!C0033003%DBSTU1.BITNET@ucbvax.Berkeley.EDU
  1949. etc...
  1950. 28-Apr-88 12:45:14-EDT,1479;000000000000
  1951. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 28 Apr 88 12:45-EDT
  1952. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA21218@EDDIE.MIT.EDU>; Thu, 28 Apr 88 11:04:26 EDT
  1953. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA21177@EDDIE.MIT.EDU>; Thu, 28 Apr 88 11:02:02 EDT
  1954. Message-Id: <8804281502.AA21177@EDDIE.MIT.EDU>
  1955. 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
  1956. Date: Thu, 28 Apr 88 11:56:56 MEZ
  1957. To: PACKET-RADIO@MIT-EDDIE.MIT.EDU
  1958. From: C0033003%DBSTU1.BITNET@CUNYVM.CUNY.EDU
  1959. Comment: CROSSNET mail via SMTP@INTERBIT
  1960. Subject: RFC 987 required
  1961.  
  1962. Hello OMs,
  1963.  
  1964. could someone out in networld be so kind and send me the RFC 987
  1965. proposal|? It's said to describe the PR PBBS recommendations
  1966. ( must be a new one ?|).
  1967.  
  1968. Thanks in advance.
  1969.  
  1970. 73s de Detlef ( DK4EG )
  1971.  
  1972. Detlef J.Schmidt                     Computing Center
  1973. Steinbrecher Str.22                University Brunswick
  1974. D3300 Braunschweig                   ( ye olde one )
  1975. F.R.G.
  1976.  
  1977.  
  1978. C0033003 at dbstu1.bitnet
  1979.  C0033003%DBSTU1.BITNET@MITVMA.MIT.EDU
  1980.  C0033003%DBSTU1.BITNET@umd2.umd.edu
  1981.  c0033003%dbstu1.bitnet%cunyvm.cuny.edu@BRL.ARPA
  1982.  CUNYVM.CUNY.EDU!C0033003%DBSTU1.BITNET@ucbvax.Berkeley.EDU
  1983.  C0033003%DBSTU1.BITNET@CUNYVM.CUNY.EDU
  1984.  C0033003%DBSTU1.BITNET@jvncc.csc.org
  1985.  DBSTU1.BITNET!C0033003@lll-crg.llnl.gov
  1986.  lll-crg!CUNYVM.CUNY.EDU!C0033003%DBSTU1.BITNET
  1987.  lll-crg!DBSTU1.BITNET!C0033003
  1988. etc...
  1989. 28-Apr-88 23:24:17-EDT,1013;000000000000
  1990. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 28 Apr 88 23:24-EDT
  1991. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA09234@EDDIE.MIT.EDU>; Thu, 28 Apr 88 22:14:35 EDT
  1992. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA09221@EDDIE.MIT.EDU>; Thu, 28 Apr 88 22:14:05 EDT
  1993. Received: from huey.udel.edu by Louie.UDEL.EDU id aa08681; 28 Apr 88 22:08 EDT
  1994. Date:     Thu, 28 Apr 88 22:04:49 EDT
  1995. From: Mills@UDEL.EDU
  1996. To: C0033003%DBSTU1.BITNET@cunyvm.cuny.edu
  1997. Cc: PACKET-RADIO@EDDIE.MIT.EDU
  1998. Subject:  Re:  RFC 987 required
  1999. Message-Id:  <8804282204.aa01288@Huey.UDEL.EDU>
  2000.  
  2001. RFC-987 describes the mapping between X.400 and good-ole SMTP mail and
  2002. is by Steve Kille of UCL. If this is what you want and your intent
  2003. is to provide X.400<->SMTP conversion for a PBBS accessable via radio,
  2004. then I am astonished and delighted in that order and would be glad
  2005. to forward the document in a return message.
  2006.  
  2007. O' give me a home/where the buffalos roam/and say it with ASN.1...
  2008.  
  2009. Dave W3HCF
  2010. 29-Apr-88 03:50:35-EDT,536;000000000000
  2011. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 29 Apr 88 03:50-EDT
  2012. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA14438@EDDIE.MIT.EDU>; Fri, 29 Apr 88 03:04:53 EDT
  2013. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA14425@EDDIE.MIT.EDU>; Fri, 29 Apr 88 03:04:28 EDT
  2014. Message-Id: <8804290704.AA14425@EDDIE.MIT.EDU>
  2015. Date: 29 Apr 88 06:55:40 GMT
  2016. From: afaa0438@Buckner-EMH.arpa
  2017. Subject: REmoval from mailing list
  2018. To: packet-radio@eddie.mit.edu
  2019.  
  2020. Please remove us from your mailing list.  Thanks.
  2021.  
  2022. 29-Apr-88 08:46:50-EDT,1144;000000000000
  2023. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 29 Apr 88 08:46-EDT
  2024. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18312@EDDIE.MIT.EDU>; Fri, 29 Apr 88 08:01:39 EDT
  2025. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18304@EDDIE.MIT.EDU>; Fri, 29 Apr 88 08:01:22 EDT
  2026. Message-Id: <8804291201.AA18304@EDDIE.MIT.EDU>
  2027. Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Fri, 29 Apr 88 08:02:26 EDT
  2028. Received: from HWALHW50.BITNET (BOSCH) by MITVMA.MIT.EDU (Mailer X1.25) with
  2029.  BSMTP id 6017; Fri, 29 Apr 88 08:02:22 EDT
  2030. Date:     Fri, 29 Apr 88 13:50 N
  2031. From: <BOSCH%HWALHW50.BITNET@MITVMA.MIT.EDU>
  2032. Subject:  Needed !!
  2033. To: packet-radio@eddie.mit.edu
  2034. X-Original-To:  packet-radio@eddie.mit.edu, BOSCH
  2035.  
  2036. Hello,
  2037.  
  2038. Is there somebody on this net (in or near Holland) who can make me
  2039. very happy with a uuencoded packet radio program called YAPP20.ARC
  2040. for the IBM PC.
  2041.  
  2042. I can't get any response from the listserver in RPICICGE, i tried it
  2043. for more then two weeks.
  2044.  
  2045. Thanks in advance.
  2046.  
  2047. Arnold Bosch (PE1IVQ)
  2048. Agricultural University
  2049. Wageningen, Holland
  2050. address: BOSCH@HWALHW50 or BOSCH@HWALHW5 on bitnet
  2051. 29-Apr-88 12:09:55-EDT,939;000000000000
  2052. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 29 Apr 88 12:09-EDT
  2053. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA21502@EDDIE.MIT.EDU>; Fri, 29 Apr 88 11:14:10 EDT
  2054. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA21492@EDDIE.MIT.EDU>; Fri, 29 Apr 88 11:13:54 EDT
  2055. Message-Id: <8804291513.AA21492@EDDIE.MIT.EDU>
  2056. Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Fri, 29 Apr 88 11:14:52 EDT
  2057. Received: from TAMSIGMA.BITNET (DST7303) by MITVMA.MIT.EDU (Mailer X1.25) with
  2058.  BSMTP id 7543; Fri, 29 Apr 88 11:14:27 EDT
  2059. Date:     Fri, 29 Apr 88 10:11 CDT
  2060. From: <DST7303%TAMSIGMA.BITNET@MITVMA.MIT.EDU> (David Taylor - KA5SLG [696-3877])
  2061. Subject:  remove from list
  2062. To: packet-radio@eddie.mit.edu
  2063. X-Original-To:  packet-radio@eddie.mit.edu, DST7303
  2064.  
  2065. Please remove me from the packet distribution list.  I will be
  2066. graduating and will lose this account.
  2067.  
  2068. Thanks,
  2069. David Taylor
  2070. Texas A&M University
  2071. 29-Apr-88 12:32:44-EDT,1362;000000000000
  2072. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 29 Apr 88 12:32-EDT
  2073. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA21922@EDDIE.MIT.EDU>; Fri, 29 Apr 88 11:39:42 EDT
  2074. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA21894@EDDIE.MIT.EDU>; Fri, 29 Apr 88 11:38:42 EDT
  2075. Message-Id: <8804291538.AA21894@EDDIE.MIT.EDU>
  2076. Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Fri, 29 Apr 88 11:39:29 EDT
  2077. Received: from TAMSIGMA.BITNET (DST7303) by MITVMA.MIT.EDU (Mailer X1.25) with
  2078.  BSMTP id 7648; Fri, 29 Apr 88 11:30:37 EDT
  2079. Date:     Fri, 29 Apr 88 10:20 CDT
  2080. From: <DST7303%TAMSIGMA.BITNET@MITVMA.MIT.EDU> (David Taylor - KA5SLG [696-3877])
  2081. Subject:  KPC-1 to KDK FM 240 interface
  2082. To: packet-radio@eddie.mit.edu
  2083. X-Original-To:  packet-radio@eddie.mit.edu, DST7303
  2084.  
  2085.  
  2086. Does anyone know how to interface a KDK FM 240 to a Kantronics KPC-1?
  2087. I hooked up the cable from the radio to the TNC the "normal" way,
  2088. but the display goes blank everytime the TNC keys the radio. I
  2089. heard that I might need a transistor switch to key this radio.
  2090.  
  2091. Any help would be greatly appreciated.  Please respond directly to my
  2092. account because I have removed myself from the distribution list due
  2093. to my impending graduation (I will lose my account).
  2094.  
  2095. Thanks in advance for the help,
  2096. David Taylor
  2097. Texas A&M University
  2098. DST7303@TAMSIGMA.BITNET
  2099.