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

  1. 2-Jan-90 17:34:00-MST,10283;000000000000
  2. Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
  3. Date: Tue,  2 Jan 90 17:19:17 MST
  4. From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
  5. Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  6. Subject: PACKET-RADIO Digest V89 #1
  7. To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  8.  
  9. PACKET-RADIO Digest         Tue,  2 Jan 90       Volume 89 : Issue    1
  10.  
  11. Today's Topics:
  12.              Computers for packet
  13.          Ham radio names and routing (3 msgs)
  14. Making things more difficult than necessary (was: Tasco TNC info) (2 msgs)
  15.               Sorry for mangled articles
  16.               tasco rom: thanks.
  17.                  TEST
  18. ----------------------------------------------------------------------
  19.  
  20. Date: 2 Jan 90 09:43:20 GMT
  21. From: mcsun!ukc!stl!stc!praxis!newton!mikec@uunet.uu.net  (Michael Chace)
  22. Subject: Computers for packet
  23. Message-ID: <MIKEC.90Jan2094320@hilbert.praxis.co.uk>
  24.  
  25. Hello All,
  26.  
  27. I'm considering changing computers, the main use of which is for packet
  28. and S/W development.
  29.  
  30. I have a limited budget so a PC with a hard disk is out of the question.
  31.  
  32. That leaves perhaps the Atari (520 & 1040) and Amiga.
  33.  
  34. Any information on these machines for Packet would be appreciated as would
  35. experience with the KA9Q TCP/IP package.
  36.  
  37. Thanks & 73
  38.  
  39. Mike
  40. ****
  41.  
  42. .............................................................................
  43. | ARPA   :  mikec@praxis.co.uk                   | Michael Chace            |
  44. | JANET  :  mikec@uk.co.praxis                   | PraXis Electronic Design |
  45. | UUCP   :  ...!uunet!mcvax!ukc!praxis!mikec     | The New Church           |
  46. |                                                | Henry Street             |
  47. | Phone  :  (44) [0]225 444700                   | Bath  Avon               |
  48. | AX25   :  G6DHU @ G6DHU-2 or G6DHU @ GB7IMB    | BA1 1PX           UK     |
  49. .............................................................................
  50.  
  51. ------------------------------
  52.  
  53. Date: 2 Jan 90 17:28:00 GMT
  54. From: zaphod.mps.ohio-state.edu!wuarchive!texbell!splut!jay@tut.cis.ohio-state.edu  (Jay "you ignorant splut!" Maynard)
  55. Subject: Ham radio names and routing
  56. Message-ID: <6287#.@splut.conmicro.com>
  57.  
  58. In the referenced message, John, KD7UW, writes a lot of common sense.
  59.  
  60. All I can add is: Bravo!
  61.  
  62. -- 
  63. Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
  64. jay@splut.conmicro.com       (eieio)| adequately be explained by stupidity.
  65. {attctc,bellcore}!texbell!splut!jay +----------------------------------------
  66.               Only sick people need drugs.
  67.  
  68. ------------------------------
  69.  
  70. Date: 2 Jan 90 17:26:10 GMT
  71. From: pacbell!tandem!kevinr@ames.arc.nasa.gov  (Kevin J. Rowett)
  72. Subject: Ham radio names and routing
  73. Message-ID: <1990Jan2.172610.8764@tandem.com>
  74.  
  75. In article <2910002@hpubvwa.NSR.HP.COM> johnh@hpubvwa.NSR.HP.COM (John Hays) writes:
  76. >The problem I see with this whole discussion is the presumption that
  77. >one set of standards must be applied to all similar problems.  The
  78.  
  79. Not necessarly, just SANITY!
  80.  
  81. >people in the BBS world have chosen to build a routing system that looks
  82. >like domain names.  They are not domain names, they are routes ... this
  83.  
  84. AND they've used SOURCE ROUTING, without considering the pitfalls!
  85.  
  86. >group have decided on a STANDARD of their own design and implementation.
  87. >It is a STANDARD because it has been generally accepted by the writers
  88. >of PBBS software, it allows for interopability of Packet Bulletin Board
  89. >Systems.  It may not be a standard by the measuring stick of the
  90. >INTERNET or OSI crowd, but it is as valid a standard as your telephone
  91. >number (which incidently is Geographic and a routing system) ...
  92.  
  93. Just because it's a STD, doesn't mean it's good, or intelligent.  Cited
  94. was the telephone numbering scheme.  Implied is the goodness of that
  95. "plan".  Goodness is in the eyes of the beholder.  The telephone
  96. numbering plan is just great for phone companies, but for users it
  97. frankly is "user-UNfriendly".  Why is it desirable from a user perspective
  98. to have SOURCE ROUTING!  WHy can't I dial a friends god given SSN and
  99. have telco locate the instrument my friend currently happens to be bound
  100. to?
  101.  
  102. >
  103. >The problem I see with the RELIGIOUS position of some of the posters is
  104. >that it denies that there might be other solutions.
  105.  
  106. The implication here is that because the poster is fanatical ( spelled
  107. RELIGIOUS), the poster should be denied 1st amendment rights as well.
  108. Seems circular reasoning.
  109.  
  110. >So lets get off of pointing fingers and get on with development in our
  111. >own areas of interest and let the better solutions "rise to the top."
  112.  
  113. Excellent idea.  Do we want source routing or not? Can we build an
  114. AMPRNET without resorting to source routing?
  115.  
  116. >
  117. >BTW for the purposes of mail routing it should be easy enough to create
  118. >a subdomain "pbbs.ampr.org" if we can set our Religious points-of-view
  119. >aside.
  120.  
  121. NAMEs are DESTINATIONS only!
  122.  
  123. N6RCE
  124.  
  125. ------------------------------
  126.  
  127. Date: 1 Jan 90 00:49:02 GMT
  128. From: hp-pcd!hplsla!hpubvwa!johnh@hplabs.hp.com  (John Hays)
  129. Subject: Ham radio names and routing
  130. Message-ID: <2910002@hpubvwa.NSR.HP.COM>
  131.  
  132. The problem I see with this whole discussion is the presumption that
  133. one set of standards must be applied to all similar problems.  The
  134. people in the BBS world have chosen to build a routing system that looks
  135. like domain names.  They are not domain names, they are routes ... this
  136. group have decided on a STANDARD of their own design and implementation.
  137. It is a STANDARD because it has been generally accepted by the writers
  138. of PBBS software, it allows for interopability of Packet Bulletin Board
  139. Systems.  It may not be a standard by the measuring stick of the
  140. INTERNET or OSI crowd, but it is as valid a standard as your telephone
  141. number (which incidently is Geographic and a routing system) ...
  142.  
  143. The problem I see with the RELIGIOUS position of some of the posters is
  144. that it denies that there might be other solutions.
  145.  
  146. It is much like the battles going on in the Computer industry now, there
  147. is one camp who promotes STANDARDS by limiting options (one O/S kernal,
  148. one RISC chip implementation, one User Interface definition), and one
  149. that says STANDARDS are for interopability but with choices (O/S
  150. interface specs such as POSIX, Networking definitions, Multiple CPU
  151. Architectures, etc.)
  152.  
  153. So lets get off of pointing fingers and get on with development in our
  154. own areas of interest and let the better solutions "rise to the top."
  155.  
  156. BTW for the purposes of mail routing it should be easy enough to create
  157. a subdomain "pbbs.ampr.org" if we can set our Religious points-of-view
  158. aside.
  159. [ Would maybe look like:
  160. kd7uw%nc7f.ut.usa.na@gateway.pbbs.ampr.org 
  161. ]
  162. Well 73 --- John KD7UW
  163.  
  164. ------------------------------
  165.  
  166. Date: 1 Jan 90 03:40:51 GMT
  167. From: zaphod.mps.ohio-state.edu!swrinde!emory!stiatl!rsiatl!jgd@tut.cis.ohio-state.edu  (John G. De Armond)
  168. Subject: Making things more difficult than necessary (was: Tasco TNC info)
  169. Message-ID: <1004@rsiatl.UUCP>
  170.  
  171. In article <10676@ucsd.Edu> brian@ucsd.edu (Brian Kantor) writes:
  172. >Or if you want to have your cake and eat it too, just solder the kiss
  173. >prom humping on top of the manufacturer's prom with all the pins except
  174. >the chip select soldered together.  Run the chip select from the board 
  175. >out to the wiper of a SPDT switch, and two wires back to the proms, and
  176. >you have front panel control of which prom you're using.
  177.  
  178. And, if you do the same thing to the RAM, use a DPDT switch and use the other 
  179. side to switch the CS line on the RAM, you can even save your AX25 setup 
  180. parameters.  
  181.  
  182. we've been running 'em like this for years around here.
  183.  
  184. TIP:  To solder the piggyback chip in place, coat the inside of each leg
  185. with surface mount flux-solder paste, mount and sweat in place with either
  186. hot air (prefered) or a quick swipe with a soldering iron.  Be sure to
  187. bend the CS lead up, of course.
  188.  
  189. John
  190.  
  191.  
  192. -- 
  193. John De Armond, WD4OQC                     | The Fano Factor - 
  194. Radiation Systems, Inc.     Atlanta, GA    | Where Theory meets Reality.
  195. emory!rsiatl!jgd          **I am the NRA** | 
  196.  
  197. ------------------------------
  198.  
  199. Date: 31 Dec 89 17:33:23 GMT
  200. From: brian@ucsd.edu  (Brian Kantor)
  201. Subject: Making things more difficult than necessary (was: Tasco TNC info)
  202. Message-ID: <10676@ucsd.Edu>
  203.  
  204. Or if you want to have your cake and eat it too, just solder the kiss
  205. prom humping on top of the manufacturer's prom with all the pins except
  206. the chip select soldered together.  Run the chip select from the board 
  207. out to the wiper of a SPDT switch, and two wires back to the proms, and
  208. you have front panel control of which prom you're using.
  209.  
  210. Yeah, yeah, it voids the warrantee.  Duh.
  211.     - Brian
  212.  
  213. ------------------------------
  214.  
  215. Date: 27 Dec 89 03:38:32 GMT
  216. From: usenet.ins.cwru.edu!mailrus!jarvis.csri.toronto.edu!torsqnt!tmsoft!mshiels@tut.cis.ohio-state.edu  (Michael A. Shiels)
  217. Subject: Sorry for mangled articles
  218. Message-ID: <ipgea721f@tmsoft.uucp>
  219.  
  220. Due to a slight configuration problem my site (masnet.uucp) which gateways
  221. for canremote.uucp has caused a couple of articles to reappear with mangled
  222. headers.  The problem was corrected but not before a few articles got out
  223. of my hands. Sorry for any confusion caused.  IT HAS BEEN FIXED!!
  224.  
  225. Michael A. Shiels
  226.  
  227. ------------------------------
  228.  
  229. Date: 31 Dec 89 18:30:53 GMT
  230. From: cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!watserv1!watmath!ria!uwovax!31002_1650@tut.cis.ohio-state.edu
  231. Subject: tasco rom: thanks.
  232. Message-ID: <4587.259e0a0d@uwovax.uwo.ca>
  233.  
  234. I have downloaded the rom i{age and it works great.  KISS mode is now
  235. running.  Thanks for the info.
  236.  
  237. de VE3PZR.
  238.  
  239. ------------------------------
  240.  
  241. Date: 26 Dec 89 16:33:00 GMT
  242. From: usc!cs.utexas.edu!jarvis.csri.toronto.edu!torsqnt!tmsoft!masnet!canremote!stephen.woo@ucsd.edu  (STEPHEN WOO)
  243. Subject: TEST
  244. Message-ID: <89122703183701@masnet.uucp>
  245.  
  246. This is a test on Dec 26, 1989 to see if this e-mail will reach me at 
  247. espinc.
  248. ---
  249.  * Via ProDoor 3.1R 
  250.  
  251. ------------------------------
  252.  
  253. End of PACKET-RADIO Digest V89 Issue #1
  254. ***************************************
  255.  3-Jan-90 05:17:45-MST,11275;000000000000
  256. Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
  257. Date: Wed,  3 Jan 90 05:15:07 MST
  258. From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
  259. Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  260. Subject: PACKET-RADIO Digest V90 #2
  261. To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  262.  
  263. PACKET-RADIO Digest         Wed,  3 Jan 90       Volume 90 : Issue    2
  264.  
  265. Today's Topics:
  266.                 AX25 Protocol
  267.                DOSGATE vs. CTTY
  268.      Hierarchical addressing in packet radio, how to use (2 msgs)
  269.   Making things more difficult than necessary (was: Tasco TNC info)
  270.             SOFTWARE AND HARDWARE FOR RBBS
  271. ----------------------------------------------------------------------
  272.  
  273. Date: 1 Jan 90 19:50:45 GMT
  274. From: attctc!mjbtn!raider!root@tut.cis.ohio-state.edu  (Bob Reineri)
  275. Subject: AX25 Protocol
  276. Message-ID: <164@raider.MFEE.TN.US>
  277.  
  278. Could some kind soul out there mail me the specs for the AX.25 protocol, or
  279. point me to where I could download them ?? 
  280.  
  281. Thanks in advance, and best wishes for 1990.
  282.  
  283. Bob, N4CDO
  284. -- 
  285. * RaiderNet Public Access    *Middle Tenn's Unix Gateway*   Murfreesboro, TN *
  286. * Data:(615)896-8716 896-7905 Voice:(615)684-4490 Mail:PO Box 2371 Zip 37133 *
  287. * Domain: root@raider.MFEE.TN.US UUCP: uunet!knuth!raider!root   HAM: N4CDO  *
  288.  
  289. ------------------------------
  290.  
  291. Date: 2 Jan 90 15:36:24 GMT
  292. From: mirror!necntc!necis!rbono@CS.BU.EDU  (Rich Bono)
  293. Subject: DOSGATE vs. CTTY
  294. Message-ID: <1199@necis.UUCP>
  295.  
  296. In article <8912280805.AA17199@ucbvax.Berkeley.EDU>, FTPAM1@ALASKA.BITNET writes:
  297. > As a matter of curiosity, what's the difference between DOSGATE
  298. > and the DOS command CTTY?  They both seem to do the same thing
  299. > with the same limitations.
  300.  
  301.     There is a subtle difference, (actually a couple of differences).
  302.  
  303. The DOS CTTY command poses several problems when used with packet:
  304.  
  305.    1) DOS always echos the users keystrokes, this will cause problems
  306.     as the user 'sees' his characters echoed back to him with the
  307.     'nominal' packet delays.
  308.  
  309.    2) DOS is not aware of when a user is connected or disconnected. Or
  310.     that there is any reason to know this at all.
  311.  
  312.    3) The CTTY command completly (sp?) redirects the console to the remote
  313.        port.  The 'SYSOP' has no idea what the remote user is doing.
  314.  
  315.    4) The CTTY command must be used to return control to the local console.
  316.  
  317.  
  318. DOSGATE solves these problems.  It (by design) does not try to be another
  319. commercial package for remotely running the PC via a modem (like REMOTEPC,
  320. or similar packages that allow remote use of the PC including graphics, etc).
  321. It is designed with AX.25 packet in mind to allow *any* remote user (without
  322. special software or hardware of any kind at the remote end) to make use of
  323. the DOSGATE system.
  324.  
  325.   1) DOSGATE 'absorbs' DOS's echoing of the users keystrokes.
  326.  
  327.   2) DOSGATE is aware of when a user connects and disconnects, setting
  328.       environment variables so that programs that need the information can
  329.       'know' who the current user is.  This also allows certain housekeeping
  330.       chores to be done, like returning the current directory to 'root' and
  331.       ending any currently running program incase a user starts a program
  332.       and then disconnects.
  333.  
  334.   3) DOSGATE 'parallels' the console with the remote user.  This allows the
  335.      'SYSOP' to see what the remote user is doing, and maintain control over
  336.      the actions, or offer help to a user who is having trouble.
  337.  
  338.   4) The local console under DOSGATE is *always* in control.  The remote user
  339.      can be disabled or enabled at will.
  340.  
  341. Although DOSGATE can be used without a TNC (it can be used with just a dumb
  342. terminal in a remote location, or through a modem), it was designed with
  343. (AX.25) packet radio in mind.   It (by design) does not attempt to make
  344. *all* programs usable remotely.  By not requiring (SP?) any special terminal
  345. software, or hardware at the remote end, anyone who can access the packet net
  346. can run the DOSGATE system.  The limitating factor in this is *ALL* software
  347. to be used on the DOSGATE system must do all its I/O through DOS INT 21h
  348. calls... and should be limited to TEXT only (7 bit ASCII) programs.  This will
  349. allow anyone to use the software.  Alas, most software for the PC these days
  350. doesn't use the DOS I/O, and uses BIOS or direct hardware accesses.  So I
  351. have been converting many interesting programs to 'C' where I can control
  352. the application.
  353.  
  354.    Hope this answers your questions.  If you have access to the (AX.25)
  355. packet net, connect to node 'SNH' and then connect to NM1D-2 (in Derry, NH)
  356. to see what I have done with my DOSGATE station as a simple example
  357. of what can be accomplished.
  358.  
  359.    I answered this to the net because I have had several queries of this type
  360. and thought the information would be useful to many of you.
  361.  
  362.      * Where is your nearest DOSGATE???? *
  363.  
  364.         Rich (NM1D)
  365.  
  366.  
  367.  
  368. -- 
  369.  /**************************************************************************\
  370.  * Rich Bono (NM1D)    If I could only 'C' forever!!    rbono@necis.nec.com * 
  371.  * (508) 635-6300          NEC Technologies Inc.                NM1D@WB1DSW * 
  372.  \**************************************************************************/
  373.  
  374. ------------------------------
  375.  
  376. Date: 3 Jan 90 03:31:36 GMT
  377. From: cs.utexas.edu!oakhill!val!ben@tut.cis.ohio-state.edu  (Ben Thornton)
  378. Subject: Hierarchical addressing in packet radio, how to use
  379. Message-ID: <1990Jan3.033136.2666@val.com>
  380.  
  381. bdale@col.hp.com (Bdale Garbee) writes:
  382.  
  383. >This is an unrealistic request.  I think Brian is being a bit harsh, but in
  384. >the long run, he's right.  It would have been *so* much better for the creative
  385. >energy that has been expended inventing the HF routing scheme and putting it
  386. >to use to have been focussed on, say, building better automated routing
  387. >mechanisms for NET.  
  388.  
  389. >The ham radio community, and the packet radio neighborhood, are far too small
  390. >for us to be able to afford fragmentation and survive.  We ought to be working
  391. >on how to work together, instead of pissing on each other...
  392.  
  393. The same thing could be said about the use of NET/ROM.  I think it would have
  394. been better to install IP routers instead.  Now that the NET/ROM networks
  395. have been installed, it will be that much harder to change over.
  396. -- 
  397.  
  398. Ben Thornton             packet:  WD5HLS @ KB5PM   Internet:  ben@val.com
  399. Video Associates Labs      uucp:  ...!cs.utexas.edu!val!ben
  400. Austin, TX              fidonet:  1:382/40 - The Antenna Farm BBS
  401.  
  402. ------------------------------
  403.  
  404. Date: 3 Jan 90 03:43:57 GMT
  405. From: cs.utexas.edu!oakhill!val!ben@tut.cis.ohio-state.edu  (Ben Thornton)
  406. Subject: Hierarchical addressing in packet radio, how to use
  407. Message-ID: <1990Jan3.034357.2755@val.com>
  408.  
  409. jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes:
  410.  
  411. >Brian has a religious fervor about his idea of how domain naming and
  412. >routing should be done. It's unrealistic for him to expect others who do
  413. >not share his fervor to do things his way, especially when his way won't
  414. >work without the full network, or large portions of it, are in place,
  415. >but the other way will (and does) work. This is no different from the
  416. >production code vs. neat hack argument: production code works, neat
  417. >hacks may not. Hams want something that works, and don't care how
  418. >technically pure it is.
  419.  
  420. From the point of view of the end user the difference between a 'neat hack'
  421. and 'production code' is often not all that obvious.  Therefore, I
  422. move that we get away from that terminology.  If the word 'production'
  423. is supposed to connote 'bug free' or 'small number of minor bugs', then
  424. this is a misuse of the term; many commercial works of 'production'
  425. code have found their way to the end user.  
  426.  
  427. Or is the term 'production' supposed to connote 'paid for' :-) ?
  428.  
  429. -- 
  430.  
  431. Ben Thornton             packet:  WD5HLS @ KB5PM   Internet:  ben@val.com
  432. Video Associates Labs      uucp:  ...!cs.utexas.edu!val!ben
  433. Austin, TX              fidonet:  1:382/40 - The Antenna Farm BBS
  434.  
  435. ------------------------------
  436.  
  437. Date: Saturday, 30 December 1989  15:58-MST
  438. From: winter@apple.com (Patty Winter)
  439. Subject: Making things more difficult than necessary (was: Tasco TNC info)
  440. Message-ID: <KPETERSEN.12555178856.BABYL@WSMR-SIMTEL20.ARMY.MIL>
  441.  
  442. In article <7238@dtseng.UUCP> rps@dtseng.UUCP (Robert P. Scott) writes:
  443. >In article <4390094@col.hp.com>, bdale@col.hp.com (Bdale Garbee) writes:
  444. >>     I just go through the
  445. >>     auto-baud routine, then type 'kiss on' followed by 'restart', and it's
  446. >>     in KISS mode until you cycle power on the TNC.
  447. >I'm curious why you go through this procedure rather than making KISS mode
  448. >the default.  Not knowing this TNC I'm wondering if this is not possible.
  449.  
  450. All this talk about having to set KISS defaults, MFJ TNCs popping out of
  451. KISS mode, and the like really has me wondering whether some hams aren't
  452. making packet radio more difficult than necessary.
  453.  
  454. I've been running a modified (I substituted a KISS PROM for the original one)
  455. TAPR TNC-2 with the KA9Q TCP/IP program for nearly two years now. It just
  456. sits there and purrs along day after day. If I want to check out what's
  457. happening on a local PBBS or the DX Packet Cluster, I just dial up another
  458. frequency on my radio and make the necessary connection. When I'm done,
  459. I disconnect and dial back to the TCP/IP channel.
  460.  
  461. Sure, I can't receive AMTOR or WEFAX or RTTY, but I'm happily using
  462. both TCP/IP and AX.25 packet, which is all I wanted in the first place. 
  463. With my little ol' 1-megabyte Macintosh Plus, I'm running NET, BM, and 
  464. TeachText (a simple text editor) all at once under MultiFinder. Within 
  465. NET itself, I have one window to control the program, one for Trace, 
  466. and one for Log if I want it. (Newer versions of NET for the Mac allow
  467. even more windows.)
  468.  
  469. So take this as a vote for a back-to-the-basics TNC-2 with a KISS PROM!
  470. It's cheap, and as far as I'm concerned, it sure does the job.
  471.  
  472.  
  473. 73,
  474. Patty
  475.  
  476. -- 
  477. ***************************************************************************** 
  478. Patty Winter N6BIS                        INTERNET: winter@apple.com
  479. AMPR.ORG: [44.4.0.44]                     UUCP: {decwrl,nsc,sun}!apple!winter
  480. ***************************************************************************** 
  481.  
  482. ------------------------------
  483.  
  484. Date: Tue, 2 Jan 90 22:03 EST
  485. From: "D.RODMAN" <OOPDAVID@ubvmsc.cc.buffalo.edu>
  486. Subject: SOFTWARE AND HARDWARE FOR RBBS
  487.  
  488. As a new subscriber to I-PACRAD, I am impressed at the level of information
  489. passed on this list.  Here is a simple question from a packet neophyte, but
  490. it is hoped that any answer will be serious and substantive.
  491.  
  492. Would someone pass their suggestions for hardware (IBM) and software that
  493. will interface with a 2 meter data controller allowing me to run an RBBS
  494. that will allow me to send some of the I-PACRAD packett info to the local
  495. boys.  Kindly be as specific as possible and all information is greatly
  496. appreciated.
  497.  
  498. Thank you.
  499.  
  500. Dave - KN2M 
  501. BITNET: OOPDAVID@UBVMS
  502. OMNET: D.RODMAN/OMNET
  503.  
  504. ------------------------------
  505.  
  506. End of PACKET-RADIO Digest V90 Issue #2
  507. ***************************************
  508.  4-Jan-90 21:26:33-MST,17850;000000000000
  509. Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
  510. Date: Thu,  4 Jan 90 21:15:10 MST
  511. From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
  512. Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  513. Subject: PACKET-RADIO Digest V90 #3
  514. To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  515.  
  516. PACKET-RADIO Digest         Thu,  4 Jan 90       Volume 90 : Issue    3
  517.  
  518. Today's Topics:
  519.               A location is not a route.
  520.             Apple ][ and packet switching
  521.              BBS Network Routing.
  522.          Ham radio names and routing (2 msgs)
  523. Making things more difficult than necessary (was: Tasco TNC info) (2 msgs)
  524.                Names and Routes
  525.            Strange DIGI operation needed...
  526.                 TAPR catalog?
  527.      Tasco TNC info request (was: kiss for heath pocket packet?)
  528. ----------------------------------------------------------------------
  529.  
  530. Date: 4 Jan 90 01:08:27 GMT
  531. From: zephyr.ens.tek.com!tektronix!sequent!mntgfx!hanko@beaver.cs.washington.edu  (Hank Oredson @ APD x1325)
  532. Subject: A location is not a route.
  533. Message-ID: <1990Jan4.010827.9454@mentor.com>
  534.  
  535. Note that the "BBS net" addresses are not routes, but locations.
  536. Routing takes place at the individual servers, and can be based
  537. on any of the location information, or on the addresses.
  538. OR.USA.NA  is a location, and does not say anything about
  539. how one could GET there, but just where it is located.
  540.  
  541.    ...  Hank  - w0rli
  542.  
  543. ------------------------------
  544.  
  545. Date: 4 Jan 90 20:35:53 GMT
  546. From: rti!ntpdvp1!davel@mcnc.org  (Dave Livingston)
  547. Subject: Apple ][ and packet switching
  548. Message-ID: <329@ntpdvp1.UUCP>
  549.  
  550. Several of us have been considering the idea of putting my apple ][c up as
  551. a packet bbs. Anyone have any suggestions as to what software they have
  552. seen used?  
  553.  
  554. thanks in advance,
  555.  
  556.  
  557. Dave Livingston                            Standard Disclaimer Applies
  558. Northern Telecom - DMS-10
  559. Research Triangle Park, NC
  560. EMAIL ...!uunet!mcnc!rti!ntpdvp1!davel
  561. 919/992-3322
  562.  
  563. ------------------------------
  564.  
  565. Date: 4 Jan 90 21:47:59 GMT
  566. From: zephyr.ens.tek.com!tektronix!sequent!mntgfx!hanko@beaver.cs.washington.edu  (Hank Oredson @ APD x1325)
  567. Subject: BBS Network Routing.
  568. Message-ID: <1990Jan4.214759.9633@mentor.com>
  569.  
  570.   I've seen a great deal of mis-information recently
  571.   concerning how routing is handled in the "bbs net".
  572.  
  573.   Mostly the folks talking about how  it is done do not
  574.   appear to understand  the process very well.  Some of
  575.   them claim to have  a better technique.  To those who
  576.   know a better  way to  do it,  please tell me about it.
  577.   If there IS a better way, it will be implemented within
  578.   a few weeks, and will replace the techniques now in use.
  579.  
  580.   i.e. don't tell me I did it wrong unless you are
  581.   prepared to tell me how to do it right.
  582.   
  583.   There is no "source routing" done in the "bbs net".
  584.  
  585.        a LOCATION is not a ROUTE
  586.        an ADDRESS is not a ROUTE
  587.  
  588.   The fact that I'm in OR.USA.NA tells you nothing about
  589.   how to get here, it just tells you where you want to
  590.   end up when you DO get here. There may be many routes
  591.   that satisfy the destination location from any given
  592.   source location.  The routing is done at each host in
  593.   whatever route is used.  Each host will normally have
  594.   many different routes to chose from when attempting to
  595.   satisfy a given destination location.  In one sense,
  596.   you could say that ARP is distributed throughout the
  597.   network, and uses local information to solve local route
  598.   problems.
  599.  
  600.   Remember also that each human has a unique ADDRESS (their
  601.   callsign) and that ADDRESS is attached to a LOCATION via
  602.   the WP process and database.  There is nothing here at all
  603.   that speaks to the problem of ROUTING.  Only the problem
  604.   of LOCATING has been addressed, ROUTING cannot be solved
  605.   until LOCATING has been solved first. 
  606.  
  607.   In the "bbs net" world, each individual is identified as:
  608.  
  609.   USER_ADDRESS@HOST_ADDRESS.LOCATION 
  610.  
  611.  
  612.    ...  Hank - w0rli
  613.  
  614. ------------------------------
  615.  
  616. Date: 3 Jan 90 17:11:48 GMT
  617. From: pacbell!tandem!kevinr@ames.arc.nasa.gov  (Kevin J. Rowett)
  618. Subject: Ham radio names and routing
  619. Message-ID: <1990Jan3.171148.13647@tandem.com>
  620.  
  621. In article <6287#.@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes:
  622. >
  623. >In the referenced message, John, KD7UW, writes a lot of common sense.
  624.  
  625. Jay, What's the "common sense" that you speak of in SOURCE ROUTING?
  626.  
  627. The quickest problem to point out is what happens to your traffic
  628. when one of the routers in the path goes away?  And how do you discover
  629. the new path?
  630.  
  631. N6RCE
  632.  
  633. ------------------------------
  634.  
  635. Date: 3 Jan 90 21:26:45 GMT
  636. From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hp.com  (Bdale Garbee)
  637. Subject: Ham radio names and routing
  638. Message-ID: <4390105@col.hp.com>
  639.  
  640. >The problem I see with this whole discussion is the presumption that
  641. >one set of standards must be applied to all similar problems.
  642.  
  643. I may have implied this, but it certainly wasn't my intent.  The concern I
  644. have, which I feel is worthy of an "overriding concern" label, is that we the
  645. amateur packet radio community are small enough in number, that our progress
  646. is likely to be substantially delayed if we insist on reinventing the wheel
  647. over and over again, instead of looking around to see what is good, and 
  648. relatively available, before we jump in and "invent a new standard".
  649.  
  650. It's pretty clear that there are times when nothing out there is good enough,
  651. and we need to do something different.  The RSPF definition strikes me as a 
  652. good example of this.  But, in general, the PBBS community is plagued by the
  653. same problems that I saw while participating in the Fidonet community, etc.  A
  654. bunch of folks with no experience and relatively little visibility to existing
  655. knowledge about how other folks have done things are far too quick to go off
  656. and invent something new... typically reiterating the same series of stumbles
  657. and falls that others have already suffered.
  658.  
  659. To me, at least, the argument about nameservers is moot.  If you come down to
  660. it, building a nameserver from the existing specs would probably have been an
  661. easier job than designing and implementing the BBS routing mechanism?
  662.  
  663. >The problem I see with the RELIGIOUS position of some of the posters is
  664. >that it denies that there might be other solutions.
  665.  
  666. It's unfortunate that we frequently fuzz the distinction between well-reasoned
  667. thought and religion.  I'm quite guilty of it, I admit.  In many cases, such
  668. as Brian's, I think it comes from answering the same question two-too-many 
  669. times...  The real failing, I think, is that somehow even though we call 
  670. ourselves "communicators", we do a really poor job of communicating.  Both on
  671. the part of those "in the know" who don't work hard enough to spread the word,
  672. and on the part of the general ham community, which is notorious for being
  673. more interested in "doing it my way" than in researching existing alternatives.
  674.  
  675. Sigh.
  676.  
  677. >BTW for the purposes of mail routing it should be easy enough to create
  678. >a subdomain "pbbs.ampr.org" if we can set our Religious points-of-view
  679. >aside.
  680.  
  681. >kd7uw%nc7f.ut.usa.na@gateway.pbbs.ampr.org 
  682.  
  683. We've talked about this few times.  But it really does work just as well to
  684. do 
  685.  
  686.     kd7uw%nc7f.ut.usa.na@nn2z.ampr.org
  687.  
  688. or equivalent for now, where nn2z is an advertised gateway for the local 
  689. community.  The only reason to create a '.pbbs.ampr.org' pseudo-subdomain 
  690. would be to allow constructs of the form
  691.  
  692.     kd7uw@nc7f.ut.usa.na.pbbs.ampr.org
  693.  
  694. There's a better way to do it.  Since a gateway ought to be able to map from
  695. a callsign to a route, all the SMTP user should have to do is:
  696.  
  697.     kd7uw@nc7f.pbbs.ampr.org
  698.  
  699. with the gateway understanding that the way to get to nc7f.pbbs.ampr.org is
  700. via the PBBS network with the full h-address.
  701.  
  702. I'd almost be willing to accept that, but in reality there's no reason for
  703. the 'pbbs', as I don't want to have to care, and MX records ought to be able
  704. to point mail for 'nc7f.ampr.org' to the closest SMTP/PBBS gateway, and the
  705. gateway again should be keying in on the callsign.  So, as far as I'm 
  706. concerned, 
  707.  
  708.     kd7uw@nc7f.ampr.org
  709.  
  710. This is as good as it gets if we treat you as a user of the nc7f system.
  711.  
  712. If you'll allow me to really dream, why can't I just send mail to you as 
  713.  
  714.     john@kd7uw.ampr.org
  715.  
  716. and let my blooming nameserver recognize that your mail should be routed to
  717. nc7f.ampr.org, etc?  With proper software, nc7f would know that he's a service
  718. provider for you, and that when he sees mail for 'user@kd7uw.ampr.org', that
  719. he's expected to dump it into kd7uw's mailbox.  Sendmail gets paid to do this
  720. kind of stuff on my systems all the time...
  721.  
  722. This brings us back, I believe, to exactly what Brian was complaining about
  723. to start with.  In the Internet community, is is recognized that an address is
  724. not a route, and therefore a separate "envelope" is maintained by SMTP for each
  725. "letter" being sent.  The address on the envelope is subject to being 
  726. manipulated as part of the mail routing process, in much the same way that the
  727. USPO frequently stamps a "forward to" address on an envelope, except that with
  728. electronic mail the stamps tend to be the rule and not the exception.  The
  729. problem with the BBS community's approach, to me at least, is that by not
  730. recognizing this distinction, they're making it necessary for the sender to 
  731. know more about the actual destination than he should have to, and making it
  732. more difficult to rationally design software to remove that burden. 
  733.  
  734. Sure, what they have works.  But it's not general enough to withstand efforts
  735. at "internetworking".  And, just as the Fidonet community moved from a flat
  736. address space to a net/host pair, to zone:net/host triples to whatever they
  737. are doing now, the PBBS community's requirements *will* change, and they aren't
  738. taking advantage of *existing* knowledge to help insure that they'll be able to
  739. make those changes gracefully.
  740.  
  741. I'm all for originality and freedom of expression, but this strikes me as a 
  742. painful waste of a limited resource... packet radio software manpower!
  743.  
  744. Oops.  I got religious again... /o\
  745.  
  746. 73 - Bdale
  747.  
  748. ------------------------------
  749.  
  750. Date: 4 Jan 90 18:04:01 GMT
  751. From: rochester!rit!cci632!cb@louie.udel.edu  (Just another hired gun (n2hkd))
  752. Subject: Making things more difficult than necessary (was: Tasco TNC info)
  753. Message-ID: <32944@cci632.UUCP>
  754.  
  755. In article <10676@ucsd.Edu> brian@ucsd.edu (Brian Kantor) writes:
  756. >Or if you want to have your cake and eat it too, just solder the kiss
  757. >prom humping on top of the manufacturer's prom with all the pins except
  758. ^^^^^^^^^^^^^^^^^^^^^^
  759. >the chip select soldered together.  Run the chip select from the board 
  760. >out to the wiper of a SPDT switch, and two wires back to the proms, and
  761. >you have front panel control of which prom you're using.
  762.  
  763. Please note that there are manufacturers out there have have made piggy
  764. back sockets for ram and rom parts. If you use those then all you have to
  765. do is connect those (of the socket, not the prom) two chip selects to
  766. a switch as Brian suggested. This allows for easy prom upgrade....
  767.  
  768. I don't have my data books handy or I'd leave you with a part number, sorry.
  769.  
  770. -- 
  771.  
  772. email:   cb@cci632  or !rochester!kodak!n2hkd!curtis  
  773. Curtis Braun, N2HKD, Computronics, PO Box 1002 Fairport NY, 14450  
  774.  
  775. ------------------------------
  776.  
  777. Date: 3 Jan 90 21:28:54 GMT
  778. From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hp.com  (Bdale Garbee)
  779. Subject: Making things more difficult than necessary (was: Tasco TNC info)
  780. Message-ID: <4390106@col.hp.com>
  781.  
  782. >So take this as a vote for a back-to-the-basics TNC-2 with a KISS PROM!
  783. >It's cheap, and as far as I'm concerned, it sure does the job.
  784.  
  785. Patty, I agree.  The problem is that Heath/Tasco don't provide a KISS-only
  786. EPROM for the "pocket packet", and it's too cute to ignore.  :-)  And to me,
  787. at least, since it's one of many TNC's in the shack, it just isn't worth
  788. writing a variant of the TNC-2 firmware to handle the CTC baud rate generation
  789. and differing addresses in the Toshiba Z80 monster-chip...
  790.  
  791. Bdale
  792.  
  793. ------------------------------
  794.  
  795. Date: 3 Jan 90 10:47:43 GMT
  796. From: cs.utexas.edu!samsung!aplcen!wb3ffv!gvdgpc!gvdg@tut.cis.ohio-state.edu  (Gerard J van der Grinten PA0GRI)
  797. Subject: Names and Routes
  798. Message-ID: <290@gvdgpc.UUCP>
  799.  
  800. Happy New Year to all.
  801. Well , it seems (as Brian writes, also in the tcp-group) that
  802. Names and Routes are still intermixed.
  803.           Please Note: 
  804. Names are NO Routes.
  805.           Also NOTE:
  806. Routes are no Names.
  807. The domain stuff uses NAMES. Still a flat name-space and indeed having its 
  808. problems incorporated BUT HAMS live with inperfect solutions. 
  809. (If it was perfect it would not be hammish).
  810. On the PBBS side CALL@PBBS.COUNTRY.STATE.WORLD.UNIVERSE is not a NAME but 
  811. (SURPRISE.....) a route. Yes, a ROUTE. We as pbbs user have to tell the
  812. system where it has to go to. 
  813. Please do not mix those XX@YY's with XX@YY's . They look the same but are not. 
  814. Please note the similarity wit STAMPS. 
  815. STAMPS look the same but old stamps have no value to a mailman and new stamps 
  816. have no value(yet) for a collector. Yet both are stamps and look, feel and
  817. (yes) even are the same. 
  818. For every one connected to (a part of) the Internet , NAMES are unique and
  819. a route to them can be found trough servers ( i.e. NAMESERVERS). Once you are 
  820. on your own( i.e. outside and not connected to the Internet) , No one can tell
  821. you how to get "there".
  822.  And those telling that an IP address has no routing info in it has to
  823. rethink.... Look at 44.137.x.x and YOU KNOW that you have to cross the atlantic 
  824.  to reach it. (it does not give a direct beam reading but close.) 
  825. Lets al start this new decade with saying together: 
  826. NAMES are NO ROUTES.   (but dammed handy if used that way).
  827. Regards, gerard.
  828.  
  829. ------------------------------
  830.  
  831. Date: Thu, 4 Jan 90 08:50:03 PST
  832. From: elmquist@nips.ssesco.com
  833. Subject: Strange DIGI operation needed...
  834. Message-ID: <9001041450.AA00503@nips.ssesco.com>
  835.  
  836. I have a need for a strange kind of DIGIpeater operation and I'm
  837. wondering if it can be done with "off-the-shelf" TNCs and firmware.
  838.  
  839. I would like a TNC on 2m to have the callsign N0JCF (ie, no SSID).
  840. I would like a TNC on 70cm to have the callsign N0JCF-x (any SSID
  841. will do).  Both of these TNCs are together at a site remote from
  842. my QTH.  At my QTH I have a third TNC with callsign N0JCF-y (you
  843. supply another SSID).  Now for the tricky part:
  844.  
  845. I would like a user on 2m to be able to connect to N0JCF and then
  846. be automatically (without further keystrokes) be connected across
  847. the 70cm link to the TNC at my QTH.  The TNC at my QTH should
  848. see this as a new connection..(ie, signal any PBBS software that
  849. a user has just connected).  The 2m user can then interact with
  850. any PBBS software...and if he should disconnect, then the whole
  851. link will be broken down and ready for another connect.
  852.  
  853. Am I making any sense?  What's the point?  well, I want to get
  854. the 2m packet stuff away from the QTH where I am trying to do
  855. weak signal 2m SSB and OSCAR stuff.  Moving all of the packet
  856. to 70cm (or maybe 902) would eliminate the desense I am getting
  857. from the 2m packet transmitter.  The majority of my packet buddies
  858. are all on 2m and I'd like the connection process to my station
  859. to be as simple as possible (ie, connecting to DIGI, issueing
  860. another connect request to me is a drag...and they won't talk
  861. to me anymore.)
  862.  
  863. Anyone know of a way this could be accomplished? I'm not fully
  864. up to speed on how NET/ROM or TheNet works...but maybe it
  865. has an autoconnect mode like I am describing...
  866.  
  867. 73, Chris  N0JCF
  868.  
  869.  
  870. ------------------------------
  871.  
  872. Date: 3 Jan 90 21:31:47 GMT
  873. From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hp.com  (Bdale Garbee)
  874. Subject: TAPR catalog?
  875. Message-ID: <4390107@col.hp.com>
  876.  
  877. >Just wondering if there is a TAPR catalog available that would list
  878. >the projects they currently have available.  If so, does anyone have
  879. >a phone number or address they should be contacted at--?
  880.  
  881. Join TAPR, which is cheap, and will get you a subscription to PSR, the 
  882. newsletter.  Each of the last several issues have had a catalog/orderform
  883. thingy in them, which would solve your problem nicely.  All of the funds above
  884. and beyond those required to publish the newsletter go into TAPR research
  885. projects...
  886.  
  887.     TAPR
  888.     PO Box 12925
  889.     Tucson, AZ  85732
  890.     (602) 323-1710
  891.  
  892. 73 - Bdale, N3EUA -- TAPR VP
  893.  
  894. ------------------------------
  895.  
  896. Date: 3 Jan 90 20:47:02 GMT
  897. From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hp.com  (Bdale Garbee)
  898. Subject: Tasco TNC info request (was: kiss for heath pocket packet?)
  899. Message-ID: <4390104@col.hp.com>
  900.  
  901. >>     I just go through the
  902. >>     auto-baud routine, then type 'kiss on' followed by 'restart', and it's
  903. >>     in KISS mode until you cycle power on the TNC.
  904. >I'm curious why you go through this procedure rather than making KISS mode
  905. >the default.  Not knowing this TNC I'm wondering if this is not possible.
  906.  
  907. If someone gives me step-by-step instructions, I might.  I only use the tiny
  908. TNC when I'm portable, and that's not very often, so the effort to understand
  909. (again, it's been a long time) how non-KISS TNC's work well enough to make the
  910. bleeping thing do what I want has seemed excessive.
  911.  
  912. What I really want, but won't spend the time to do since I have a ROM that
  913. pretty much does the right thing, is a KISS-only ROM for the tiny....
  914.  
  915. I *always* run KISS mode when forced to use a TNC.  Period.
  916.  
  917. Bdale
  918.  
  919. ------------------------------
  920.  
  921. End of PACKET-RADIO Digest V90 Issue #3
  922. ***************************************
  923.  6-Jan-90 05:23:36-MST,13502;000000000000
  924. Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
  925. Date: Sat,  6 Jan 90 05:15:24 MST
  926. From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
  927. Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  928. Subject: PACKET-RADIO Digest V90 #4
  929. To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  930.  
  931. PACKET-RADIO Digest         Sat,  6 Jan 90       Volume 90 : Issue    4
  932.  
  933. Today's Topics:
  934.              BBS Network Routing.
  935.               dsy modem article
  936.                 FTPable G8BPQ?
  937.                Grapes on Duplex Repeat
  938.              header compression in ka9q?
  939.          Information on TNC boards requested.
  940.   Making things more difficult than necessary (was: Tasco TNC info)
  941.                RF Tight Boxes (2 msgs)
  942.            Strange DIGI operation needed...
  943.                What is HAMSTER?
  944. ----------------------------------------------------------------------
  945.  
  946. Date: 5 Jan 90 19:12:19 GMT
  947. From: eru!luth!sunic!sics.se!sics.se!klemets@bloom-beacon.mit.edu  (Anders Klemets)
  948. Subject: BBS Network Routing.
  949. Message-ID: <KLEMETS.90Jan5201219@shai.sics.se>
  950.  
  951. Hank W0RLI writes:
  952. > To those who know a better  way to  do it,  please tell me about it.
  953.  
  954. Ok, here goes. The routing designators are currently parsed from left to
  955. right. This causes JA1KSO.42.JPN.AS to match wild-card ZIP codes, such
  956. as 42*. You solve the problem by stating that all fields below the state
  957. or province level should be prefixed by a #-sign. This makes the whole
  958. scheme look like a kludge!
  959.  
  960. You can work around this problem by making the BBS aware of its own full
  961. hierarchical location. Then just parse the routing designators from the
  962. right to the left, instead of the other way around.
  963. Suppose you are W0BBS.NOCAL.CA.US.NA. If you get a message for
  964. K1BBS.SOCAL.CA.US.NA your parser should not bother about the right-most fields
  965. that are common to both addresses. The BBS would first search the forwarding
  966. file for entries matching K1BBS and K1BBS.SOCAL. If no matching entry is
  967. found, the left-most field is stripped off. In this example the fwd file would
  968. be searched for SOCAL.
  969.  
  970. If the same BBS as in the previous example gets a message for JA1KSO.42.JPN.AS
  971. the forwarding file would first be searched for the full address, or if that
  972. fails the BBS would try to find 42.JPN.AS, JPN.AS, and finally only AS.
  973.  
  974. Incomplete addresses can also be handled appropriately. In the example above,
  975. a message for W0XX.42 would be treated as W0XX.42.CA.US.NA since 42 does
  976. not match any known state, country or continent designator.
  977.  
  978. As an aside, the users of BBS-systems should demand that mail to foreign
  979. stations should be sent to the right gateway even if no routing information
  980. at all is supplied. It is miserable that a BBS user should have to help
  981. the computer with the mapping of prefixes to country and continent designators.
  982. Computers should help us, and not the other way around. A good start would
  983. be by letting the BBS derive any country and continent designators it needs
  984. by looking at a prefix table. The prefix table would not take more than a
  985. few kilobytes of disk space if it is encoded properly, and would seldom need
  986. to be changed.
  987.  
  988. 73, Anders
  989. --
  990. klemets@sics.se  /  SM0RGV
  991.  
  992. ------------------------------
  993.  
  994. Date: 5 Jan 90 10:39:57 GMT
  995. From: zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!phil@tut.cis.ohio-state.edu
  996. Subject: dsy modem article
  997. Message-ID: <30600028@ux1.cso.uiuc.edu>
  998.  
  999. I looked for the HR article about the WA4DSY modem and could not find it.
  1000. Can someone point me to where it is?
  1001.  
  1002. --Phil Howard, KA9WGN--
  1003. <phil@ux1.cso.uiuc.edu>
  1004.  
  1005. ------------------------------
  1006.  
  1007. Date: 3 Jan 90 14:14:57 GMT
  1008. From: mitel!sce!cognos!dgbt!barry@uunet.uu.net  (Barry McLarnon DGBT/DIP)
  1009. Subject: FTPable G8BPQ?
  1010. Message-ID: <1344@dgbt.uucp>
  1011.  
  1012. From article <14564@orstcs.CS.ORST.EDU>, by batesm@mist.CS.ORST.EDU (Mike Bates):
  1013. >   Where can a person FTP the latest release of the
  1014. >   G8BPQ software?
  1015.  
  1016. Try tomcat.gsfc.nasa.gov [128.183.10.100].  The latest 'n greatest (3.53)
  1017. is available there now.
  1018.  
  1019. >   Also, any ideas when the software will be available on ROM?
  1020.  
  1021. Nope, but I didn't get the impression from the latest release notes that
  1022. this was high on his priority list just now.
  1023.  
  1024. >   Thanks Mike Bates, KF7DQ
  1025. >   batesm@mist.cs.orst.edu
  1026. >   KF7DQ@KA7VQD
  1027.  
  1028. Barry VE3JF
  1029.  
  1030. -- 
  1031. Barry McLarnon    Communications Research Center    Ottawa, ON   Canada
  1032. UUCP: ...utzoo!bnr-vpa!bnr-rsc!dgbt!barry   INTERNET:  barry@dgbt.crc.dnd.ca
  1033. Compu$erve: 71470,3651     Packet radio:  VE3JF @ VE3JF
  1034.  
  1035. ------------------------------
  1036.  
  1037. Date: 5 Jan 90 00:20:15 GMT
  1038. From: usc!cs.utexas.edu!helps!bongo!julian@apple.com  (julian macassey)
  1039. Subject: Grapes on Duplex Repeat
  1040. Message-ID: <288@bongo.UUCP>
  1041.  
  1042. Late last year someone on this newsgroup mentioned that they had 
  1043. a repeater running the GRAPES 56KB packet modem. Details were 
  1044. supposed to be forthcoming. Any news on the horizon?
  1045.  
  1046. Yours
  1047. -- 
  1048. Julian Macassey, n6are  julian@bongo.info.com  {ucla-an!denwa!bongo!julian
  1049. N6ARE@K6IYK (Packet Radio) n6are.ampr.org [44.16.0.81] voice (213) 653-4495
  1050.  
  1051. ------------------------------
  1052.  
  1053. Date: 5 Jan 90 19:11:07 GMT
  1054. From: wuarchive!zaphod.mps.ohio-state.edu!samsung!shadooby!umich!itivax!b-tech!zeeff@decwrl.dec.com  (Jon Zeeff)
  1055. Subject: header compression in ka9q?
  1056. Message-ID: <98JF4@b-tech.uucp>
  1057.  
  1058. Has anyone put VanJacobson's header compression code into the ka9q net.exe
  1059. software (either version)?  It seems like a big win for slip links.
  1060.  
  1061. -- 
  1062. Jon Zeeff       zeeff@b-tech.ann-arbor.mi.us  or b-tech!zeeff
  1063.  
  1064. ------------------------------
  1065.  
  1066. Date: 5 Jan 90 22:19:40 GMT
  1067. From: shelby!cascade!faheem@decwrl.dec.com  (Faheem Akram)
  1068. Subject: Information on TNC boards requested.
  1069. Message-ID: <1333@cascade.Stanford.EDU>
  1070.  
  1071. An article entitled "Starter Packet" in the November issue of CQ explains how 
  1072. to get started in Packet Radio.  It gives information on many things but there
  1073. is nothing in the way of a recommendation of a suitable TNC board.  The only 
  1074. thing I could gather from the article in this respect is that there is 
  1075. something called a TAPR-2 which also has many clones.  I would appreciate
  1076. if any who have experience with packet radio will provide me some 
  1077. answers to the following questions.
  1078. 1.  What is TAPR-2?
  1079. 2.  What is a suitable TNC board that can be plugged into an IBM PC-XT?
  1080.     Is there a survey article that reviews a bunch of TNC boards and if
  1081.     so can you please provide me the reference?
  1082. 3. Is a modem also needed besides the TNC board or is the modem on the
  1083.    TNC board?
  1084. 4. I have used the Procomm software with my modem.  Besides Procomm, there
  1085.    are others viz. BOBCOM,MFJCOMM,MFJXER,PACFILE,PACPRO,PTP, and YAPP listed
  1086.    in the above mentioned article.  Again is there a survey article covering 
  1087.    and comparing these programs? If so please give me the reference. If not,
  1088.    which one is reasonbly priced and good.  Or is Procomm sufficient?
  1089.  
  1090.     My thanks in advance.
  1091. Sincerely,
  1092.  
  1093. Faheem Akram
  1094.  
  1095. ------------------------------
  1096.  
  1097. Date: 4 Jan 90 14:37:06 GMT
  1098. From: mitel!sce!cognos!dgbt!barry@uunet.uu.net  (Barry McLarnon DGBT/DIP)
  1099. Subject: Making things more difficult than necessary (was: Tasco TNC info)
  1100. Message-ID: <1345@dgbt.uucp>
  1101.  
  1102. From article <1004@rsiatl.UUCP>, by jgd@rsiatl.UUCP (John G. De Armond):
  1103. > In article <10676@ucsd.Edu> brian@ucsd.edu (Brian Kantor) writes:
  1104. >>Or if you want to have your cake and eat it too, just solder the kiss
  1105. >>prom humping on top of the manufacturer's prom with all the pins except
  1106. >>the chip select soldered together.  Run the chip select from the board 
  1107. >>out to the wiper of a SPDT switch, and two wires back to the proms, and
  1108. >>you have front panel control of which prom you're using.
  1109. > And, if you do the same thing to the RAM, use a DPDT switch and use the other 
  1110. > side to switch the CS line on the RAM, you can even save your AX25 setup 
  1111. > parameters.  
  1112. > we've been running 'em like this for years around here.
  1113. > TIP:  To solder the piggyback chip in place, coat the inside of each leg
  1114. > with surface mount flux-solder paste, mount and sweat in place with either
  1115. > hot air (prefered) or a quick swipe with a soldering iron.  Be sure to
  1116. > bend the CS lead up, of course.
  1117.  
  1118. Or, yet another possibility: To avoid messy soldering (on the EPROM, at
  1119. least), obtain a 27C512 and copy your original ROM into one half of the
  1120. 64K address space, and KISS into the other half.  Then use the switch as
  1121. a ROM select by changing the state of the A14 line.
  1122.  
  1123. But I still like Patty's solution the best!  :-)
  1124.  
  1125. > John
  1126.  
  1127. Barry
  1128.  
  1129. -- 
  1130. Barry McLarnon    Communications Research Center    Ottawa, ON   Canada
  1131. UUCP: ...utzoo!bnr-vpa!bnr-rsc!dgbt!barry   INTERNET:  barry@dgbt.crc.dnd.ca
  1132. Compu$erve: 71470,3651     Packet radio:  VE3JF @ VE3JF
  1133.  
  1134. ------------------------------
  1135.  
  1136. Date: 5 Jan 90 00:33:22 GMT
  1137. From: samsung!uakari.primate.wisc.edu!uwm.edu!cs.utexas.edu!helps!bongo!julian@think.com  (julian macassey)
  1138. Subject: RF Tight Boxes
  1139. Message-ID: <289@bongo.UUCP>
  1140.  
  1141.     Back in the old days when FETs had not been invented and you had 
  1142. to use tubes if you wanted high impedance circuitry, finding an 
  1143. RF tight box was easy. Back then, pipe tobacco came in metal 
  1144. boxes and many items were distributed in tin plate containers. 
  1145. Brits may recall "OXO tins". Nowadays, boxes sold or used as 
  1146. containers are all plastic - handy to store stuff or build non 
  1147. crit circuits - useless for RF shielding. 
  1148.  
  1149.     What I need is a source of "free" RF tight boxes. Hamtronics 
  1150. will sell me a 7 X 8 X 2 (ins) box for $30! This is about the 
  1151. size of an OXO tin and they came free if you purchased all the 
  1152. bouillon cubes inside them. The Hamtronics box is aluminium and 
  1153. hard to solder to, the OXO tin was tinplate.
  1154.  
  1155.     Any ideas out there?
  1156. -- 
  1157. Julian Macassey, n6are  julian@bongo.info.com  {ucla-an!denwa!bongo!julian
  1158. N6ARE@K6IYK (Packet Radio) n6are.ampr.org [44.16.0.81] voice (213) 653-4495
  1159.  
  1160. ------------------------------
  1161.  
  1162. Date: 5 Jan 90 21:42:39 GMT
  1163. From: amdcad!positron!brian@ucbvax.Berkeley.EDU  (Brian McMinn)
  1164. Subject: RF Tight Boxes
  1165. Message-ID: <28643@amdcad.AMD.COM>
  1166.  
  1167. In article <289@bongo.UUCP> julian@bongo.UUCP (julian macassey) writes:
  1168. |       What I need is a source of "free" RF tight boxes.
  1169.  
  1170. Around about Christmas time each year, you can get tins of butter
  1171. cookies.  Most of the tins are round :-(, but some cookies (especially
  1172. Scottish Shortbread -- YUM!) come in relatively square tins.  Sizes
  1173. range, but 8" x 8" x 2" is about average.  They are usually made of
  1174. tin plated steel.  I've never used one as an RF shield, but I have
  1175. turned them over and "air boarded" simple circuits on them.
  1176.  
  1177. Air boarding:  Didja ever notice that them little components come with
  1178. 2 to 3 centimeter leads on 'em?  Well, them ain't leads, thems just
  1179. real short wires!  Air boarding is 3-d breadboarding without the
  1180. breadboard.  (You just solder the leads together.)  (UGH!)
  1181.  
  1182.     Brian
  1183.     Brian McMinn            brian@neptune.AMD.COM
  1184.     Advanced Micro Devices  N5PSS
  1185.     Austin, Texas           1-(512)-462-5389
  1186.  
  1187. ------------------------------
  1188.  
  1189. Date: 6 Jan 90 03:00:56 GMT
  1190. From: n8emr!gws@tut.cis.ohio-state.edu  (Gary Sanders)
  1191. Subject: Strange DIGI operation needed...
  1192. Message-ID: <1399@n8emr.UUCP>
  1193.  
  1194. In article <9001041450.AA00503@nips.ssesco.com> elmquist@NIPS.SSESCO.COM writes:
  1195. >I have a need for a strange kind of DIGIpeater operation and I'm
  1196. >wondering if it can be done with "off-the-shelf" TNCs and firmware.
  1197. >
  1198. >I would like a TNC on 2m to have the callsign N0JCF (ie, no SSID).
  1199. >I would like a TNC on 70cm to have the callsign N0JCF-x (any SSID
  1200. >will do).  Both of these TNCs are together at a site remote from
  1201. >my QTH.  At my QTH I have a third TNC with callsign N0JCF-y (you
  1202. >supply another SSID).  Now for the tricky part:
  1203.  
  1204.     Well I think you can do the 2 freq gateway with only one
  1205. standard tnc, A couple of guys around here have had gateways running
  1206. from 220(novice band ) to 2 meter pbbs frequency. Although not the
  1207. best way to manage spectrum space it will work.
  1208.  
  1209.  
  1210. 2 meter speaker out -\            /- 2 meter mic in
  1211.               ==== TNC ===
  1212. 70 cm   speaker out -/            \- 70cm mic in
  1213.  
  1214.     anyone digipeating through either side will be digited
  1215. on the both sides of the gateway.. One TNC, one callsign 2 freq,
  1216. no additional operator intervention aside from a normal digipeat
  1217. command.
  1218.  
  1219.     73......
  1220.  
  1221.  
  1222.  
  1223. -- 
  1224. Gary W. Sanders (gws@n8emr or ...!osu-cis!n8emr!gws), 72277,1325
  1225. N8EMR @ W8CQK (ip addr) 44.70.0.1 [Ohio AMPR address coordinator]
  1226. HAM/SWL/SCANNER BBS (1200/2400/PEP) 614-457-4227
  1227. Voice: 614-457-4595 (eves/weekends)
  1228.  
  1229. ------------------------------
  1230.  
  1231. Date: 5 Jan 90 16:24:15 GMT
  1232. From: usc!cs.utexas.edu!natinst!rpp386!puzzle!khijol!erc@apple.com  (Edwin R. Carp)
  1233. Subject: What is HAMSTER?
  1234. Message-ID: <887@khijol.UUCP>
  1235.  
  1236. What is HAMSTER?  I assume it's a BBS.  What's the phone number/login sequence?
  1237.  
  1238. Thanks for any information.
  1239.  
  1240. Anybody know of any other BBS's, especially in Texas, that have radio mod info?
  1241. -- 
  1242. Ed Carp                 N7EKG/5 (28.3-28.5)     uunet!cs.utexas.edu!khijol!erc
  1243. Austin, Texas           (512) 832-5884          "Good tea.  Nice house." - Worf
  1244. ***   Did you know that Barbie Benton PLAYS THE PIANO??  Quite well, too!   ***
  1245.  
  1246. ------------------------------
  1247.  
  1248. End of PACKET-RADIO Digest V90 Issue #4
  1249. ***************************************
  1250.  8-Jan-90 10:23:53-MST,10800;000000000000
  1251. Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
  1252. Date: Mon,  8 Jan 90 10:15:52 MST
  1253. From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
  1254. Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  1255. Subject: PACKET-RADIO Digest V90 #5
  1256. To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  1257.  
  1258. PACKET-RADIO Digest         Mon,  8 Jan 90       Volume 90 : Issue    5
  1259.  
  1260. Today's Topics:
  1261.               A location is not a route.
  1262.              BBS Network Routing.
  1263.          Ham radio names and routing (2 msgs)
  1264.              KA9Q TCP/IP package
  1265.                Routing Question
  1266.            Strange DIGI operation needed...
  1267.              WA4DSY Duplex Repeater Info
  1268. ----------------------------------------------------------------------
  1269.  
  1270. Date: 5 Jan 90 05:41:56 GMT
  1271. From: hp-pcd!hplsla!hpubvwa!johnh@hplabs.hp.com  (John Hays)
  1272. Subject: A location is not a route.
  1273. Message-ID: <2910004@hpubvwa.NSR.HP.COM>
  1274.  
  1275. How true, Hank...
  1276.  
  1277. I didn't know you landed at mentor.
  1278.  
  1279. John Hays KD7UW
  1280.  
  1281. ------------------------------
  1282.  
  1283. Date: 8 Jan 90 08:49:04 GMT
  1284. From: eru!luth!sunic!mcsun!ukc!axion!news@bloom-beacon.mit.edu  (Brian Lloyd)
  1285. Subject: BBS Network Routing.
  1286. Message-ID: <1990Jan8.084904.28352@axion.bt.co.uk>
  1287.  
  1288. From article <KLEMETS.90Jan5201219@shai.sics.se>, by klemets@sics.se (Anders Klemets):
  1289. > As an aside, the users of BBS-systems should demand that mail to foreign
  1290. > stations should be sent to the right gateway even if no routing information
  1291. > at all is supplied. It is miserable that a BBS user should have to help
  1292. > the computer with the mapping of prefixes to country and continent designators.
  1293. > Computers should help us, and not the other way around. A good start would
  1294. > be by letting the BBS derive any country and continent designators it needs
  1295. > by looking at a prefix table. The prefix table would not take more than a
  1296. > few kilobytes of disk space if it is encoded properly, and would seldom need
  1297. > to be changed.
  1298. > 73, Anders
  1299. There is some software which is now widely used in the UK and is spreading
  1300. to Europe which does this, and is written by yours truly. If no routing
  1301. information other than the destination BBS is given when a user sends a 
  1302. message, the BBS looks up a file on disk and adds as much information as it
  1303. can. As a bare minimum, it can work out that a G callsign needs .GBR.EU
  1304. added, a W, K, A etc needs .USA.NA added, etc. Further details can be
  1305. added to the lookup file as necessary.
  1306.     Brian
  1307. ###########################################################################
  1308. What? No silicon heaven? Ludicrous! Where would all the calculators go?
  1309. Brian Lloyd,                           # Via e-mail : blloyd@axion.bt.co.uk
  1310. RT3152, Rm G44, SSTF,                  # Via Packet : G1NNA @ GB7NNA.GBR.EU
  1311. British Telecom Research Labs,         # By Phone   : +44 (0)473 646650
  1312. Martlesham Heath, Ipswich, Suffolk. IP5 7RE
  1313.  
  1314. ------------------------------
  1315.  
  1316. Date: 5 Jan 90 05:51:58 GMT
  1317. From: hp-pcd!hplsla!hpubvwa!johnh@hplabs.hp.com  (John Hays)
  1318. Subject: Ham radio names and routing
  1319. Message-ID: <2910005@hpubvwa.NSR.HP.COM>
  1320.  
  1321. Sorry about the weird sentence structure and possible spelling and
  1322. punctuation errors in the last posting.  VI is a little choppy when my
  1323. 2400 baud modem is connected to a local host and then runs through PEP
  1324. at 9600 baud to a remote host.
  1325.  
  1326. John
  1327.  
  1328. ------------------------------
  1329.  
  1330. Date: 5 Jan 90 05:36:40 GMT
  1331. From: hp-pcd!hplsla!hpubvwa!johnh@hplabs.hp.com  (John Hays)
  1332. Subject: Ham radio names and routing
  1333. Message-ID: <2910003@hpubvwa.NSR.HP.COM>
  1334.  
  1335. I have been reading all of this talk about "source routing" evils
  1336. and so on.
  1337.  
  1338. I am a user of both NOS and MSYS1.06 at my shack (as well as BSD4.3
  1339. IP ala Domain/OS) ...
  1340.  
  1341. In my NOS config I have several statements like
  1342.  
  1343. route add 44.70.0.0/16 n4pcr 1
  1344.  
  1345. (same on my Msys IP side of hings)
  1346.  
  1347. For BBS "H" routing I have statements like
  1348.  
  1349. "IL" in route table for nc7f (the next PBBS east of me) ...
  1350.  
  1351. n4pcr probably has some route statement to some other host for
  1352. "44.70.0.0" ... and so on.
  1353.  
  1354. nc7f sends "IL" traffic to a station colorado or to an HF gateway ... I
  1355. don't know and I don't really care.
  1356.  
  1357. So if I want to SMTP or Telnet etc. to someone in ILlinois, it goes
  1358. through a routed station in the Chicago area ... I know the first HOP
  1359. in the path ... but not the rest, nor should I need to know or care.
  1360.  
  1361. If I want to send a piece of traffic or bulletin to IL ... I can 
  1362. address it to "DEST@CALLSIGN" which gets converted to
  1363. "DEST@CALLSIGN.IL.USA.NA" and once it leaves my station I don't know how
  1364. or care how it is delivered (I just want it delivered)....  I can also
  1365. list the "IL" destination on several host routes and it will be sent by
  1366. the first available  (have I hard time in NOS in figuring out how to do
  1367. this.. anyone worked it out N4PCR-1 NET/ROM only shows up occasionally
  1368. [via a wormhole in california somewhere]) ....
  1369.  
  1370. SO WHAT'S THE BIG DIFFERENCE?
  1371.  
  1372. I like IP better because it is a standard I can use to connect to real
  1373. computers (like my Apollo Unix box) but I am able to move a lot more
  1374. information (today) to remote sites using the BBS "H" forwarding system.
  1375.  
  1376. I think there is room for both.
  1377.  
  1378. Also, my comments concerning the "RELGIOUSITY" of certain individuals is
  1379. not meant to "deny them first amendment rights", it is that this
  1380. attitude has created a dictatorship of the "AMPR.ORG" domain and Network
  1381. "44"  ... This dictatorial attitude prevents any democratic aproach to
  1382. the question of subdomains, administrative subnetworks which can use
  1383. geography for pragmatic reasons (eventhough you see geographic subnets
  1384. in internets all the time), summary decisions to allocate less that full
  1385. byte subnets without user input, etc.  (I found the DIETY, MOTHER, and
  1386. ADDRESS analogy very telling).
  1387.  
  1388. I have a dream of someday "AMPRNET" becoming a network whose policies
  1389. are not dictated but openly discussed by representatives of all the
  1390. services which fall under the Amateur Packet Radio umbrella and that
  1391. various needs can be met through an open process.  I would say that a
  1392. majority of users just want Email and Bulletin services, lets make the
  1393. path easy between them and those who want the higher services of
  1394. networks like IP.
  1395.  
  1396. 73 es CUL,
  1397. John KD7UW
  1398. kd7uw@kd7uw.ut.usa.na (44.40.1.3)
  1399. hays@apollo.hp.com
  1400.  
  1401. ------------------------------
  1402.  
  1403. Date: 6 Jan 90 16:32:00 GMT
  1404. From: modcomp!dan@uunet.uu.net
  1405. Subject: KA9Q TCP/IP package
  1406. Message-ID: <97400001@modcomp>
  1407.  
  1408. I'm looking for the KA9Q TCP/IP package for the Amiga or IBM/PC. 
  1409. I'd appreciate any tips, pointers, etc. on how to find it. 
  1410.  
  1411. -73- de Dan, N4IXP
  1412.  
  1413. 305 977 1558
  1414.  
  1415. ------------------------------
  1416.  
  1417. Date: 8 Jan 90 05:06:26 GMT
  1418. From: zephyr.ens.tek.com!tekig5!dwightj@uunet.uu.net  (Dwight L. Johnson)
  1419. Subject: Routing Question
  1420. Message-ID: <5318@tekig5.PEN.TEK.COM>
  1421.  
  1422. --------------------------
  1423. Hi All,
  1424.  
  1425.    I recently bought a packet radio board for my computer and would like to
  1426. know how to route messages from Santa Rosa, CA. to Hillsboro, OR. and visa-
  1427. versa.  I would appreciate any help as I am as green as green gets.
  1428.  
  1429. Thanx in advance, Roy Harder N6HJT, Santa Rosa, CA.
  1430. Phone: 1-707-538-5756
  1431.  
  1432. ------------------------------
  1433.  
  1434. Date: 7 Jan 90 04:52:38 GMT
  1435. From: brian@ucsd.edu  (Brian Kantor)
  1436. Subject: Strange DIGI operation needed...
  1437. Message-ID: <10860@ucsd.Edu>
  1438.  
  1439. Paralleling the speakers of two receivers into one TNC just about
  1440. guarantees that you'll run into hidden-station collisions.  You can
  1441. resolve this by having one receiver have priority over the other
  1442. (i.e., it mutes the other receiver), but that still causes problems.
  1443.  
  1444. I think your problem is better solved by having a remote-base - that is,
  1445. you have a 444 MHz link from your station to the 2m radio, and a 449 MHz
  1446. link back from the 2m radio to your station.  You can do this with a
  1447. total of three TNCs if you want the link to be all digital, or you can
  1448. do it with just one if you want the link to be audio.  Add some smarts
  1449. at the remote site and you can even have the distant 2m radio be
  1450. frequency-agile.
  1451.  
  1452. Remote bases like this are real common in So California, although not
  1453. for the reasons you want to do it.  The first one is reputed to have
  1454. gone on the air in 1956 or thereabouts, so it's not exactly a new idea.
  1455. There are more than 500 of them in Los Angeles and points south.
  1456.     - Brian
  1457.  
  1458. ------------------------------
  1459.  
  1460. Date: Sat, 6 Jan 90 19:08:27 EST
  1461. From: DYUILL@CARLETON.CA
  1462. Subject: WA4DSY Duplex Repeater Info
  1463. Message-ID: <900106.20051647.010645@CU.CP6>
  1464.  
  1465. Julian Macassey Writes:
  1466. >someone on this newsgroup mentioned that they had a repeater running the
  1467. >GRAPES 56KB packet modem. Any details?
  1468.  
  1469. The packet working group here in Ottawa has assembled and tested a repeater
  1470. based on the DSY modem. It uses a regenerative design, ie: after down
  1471. conversion from 220Mhz to 28Mhz on the repeater input the signal is fed
  1472. into the DSY modem for demodulation, the synchronous output from the modem
  1473. is fed into a shift register which is used to buffer the data as the modem
  1474. uses seperate clocks for the modulator/demodulator. After buffering the
  1475. data is sent back out to the modulator, the 28Mhz modem output is up
  1476. converted to 70cm (10w) and voila| The advantage to our design is that we
  1477. "siphon off" the bits after demodulation so we can feed them to our IP
  1478. router/gateway/nameserver/network wonder object thereby allowing us to
  1479. have a node at our repeater site without investing in another DSY modem.
  1480. Also, operating split band eliminates the need for a duplexer and the
  1481. carrier detect in the modem comes in handy for keying the repeaters xmiter.
  1482. I understand that Phil Karn is working on a linear translator which of
  1483. course does not require a DSY modem at the repeater site. It also may
  1484. reduce the chance of packet collisions.
  1485. While a regenerative design does increase the chance of packet collisions
  1486. by introducing additional time for carrier detect through the repeater,
  1487. early tests show that no increase in txd is required over a half duplex
  1488. DSY modem. Also the full duplex design of the repeater will allow some
  1489. clever programmer to write a driver for NET that checks for packet
  1490. collisions in real time, which should make up for the slower carrier
  1491. detect.
  1492. Write to Barry, VE3JF for information on his design of the regeneration
  1493. shift register. All the rest of it is pretty much off the shelf..
  1494. Well you DO need to assemble the modem from a kit..
  1495. Our site visit for installing all of the above is tomorrow. User testing
  1496. to follow.
  1497. --dy
  1498. Doug Yuill, VE3OCU@VE3F, Ottawa or DYUILL@CARLETON.CA
  1499.  
  1500. ------------------------------
  1501.  
  1502. End of PACKET-RADIO Digest V90 Issue #5
  1503. ***************************************
  1504.  9-Jan-90 10:56:50-MST,7638;000000000000
  1505. Mail-From: KPETERSEN created at  9-Jan-90 10:52:24
  1506. Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
  1507. Date: Tue,  9 Jan 90 10:52:24 MST
  1508. From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
  1509. Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  1510. Subject: PACKET-RADIO Digest V90 #6
  1511. To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  1512.  
  1513. PACKET-RADIO Digest         Tue,  9 Jan 90       Volume 90 : Issue    6
  1514.  
  1515. Today's Topics:
  1516.              BBS Network Routing.
  1517.               dsy modem article
  1518.            Problem with Pk-232 MBX upgrade
  1519.             REMOTE STATION CONTROL
  1520.               Used PK-232 Price?
  1521.               What is HAMSTER? (2 msgs)
  1522. ----------------------------------------------------------------------
  1523.  
  1524. Date: 8 Jan 90 17:15:00 GMT
  1525. From: pacbell!tandem!kevinr@ames.arc.nasa.gov  (Kevin J. Rowett)
  1526. Subject: BBS Network Routing.
  1527. Message-ID: <1990Jan8.171500.5201@tandem.com>
  1528.  
  1529. In article <1990Jan4.214759.9633@mentor.com> hanko@mentor.com (Hank Oredson @ APD x1325) writes:
  1530. >
  1531. >  Remember also that each human has a unique ADDRESS (their
  1532. >  callsign) and that ADDRESS is attached to a LOCATION via
  1533. >  the WP process and database.  There is nothing here at all
  1534. >  that speaks to the problem of ROUTING.  Only the problem
  1535. >  of LOCATING has been addressed, ROUTING cannot be solved
  1536. >  until LOCATING has been solved first. 
  1537. >
  1538. >  In the "bbs net" world, each individual is identified as:
  1539. >  USER_ADDRESS@HOST_ADDRESS.LOCATION 
  1540. >
  1541. >
  1542. >   ...  Hank - w0rli
  1543.  
  1544.  
  1545. COULD someone please clarify the difference (in terms of 
  1546. how it affects BBSs) between a LOCATION and an ADDRESS?
  1547.  
  1548. Understanding this seems fundamental to why
  1549.  
  1550. K3MC.CA.NA is necessary over just 'K3MC'.  Although so
  1551. Mike can have more than one thing, I'd allow bbs.K3MC.ampr.org.
  1552.  
  1553. N6RCE
  1554.  
  1555. ------------------------------
  1556.  
  1557. Date: 8 Jan 90 17:30:44 GMT
  1558. From: pacbell!tandem!kevinr@ames.arc.nasa.gov  (Kevin J. Rowett)
  1559. Subject: dsy modem article
  1560. Message-ID: <1990Jan8.173044.5328@tandem.com>
  1561.  
  1562. In article <30600028@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu writes:
  1563. >
  1564. >I looked for the HR article about the WA4DSY modem and could not find it.
  1565. >Can someone point me to where it is?
  1566. >
  1567. >--Phil Howard, KA9WGN--
  1568. ><phil@ux1.cso.uiuc.edu>
  1569.  
  1570.  
  1571. The Oct '89 issue of 73 had a EXCELLENT article on the DSY modems
  1572. by Phil.  If you get one, please pay particular attention to his
  1573. note about the clock recovery fix.
  1574.  
  1575. N6RCE
  1576.  
  1577. ------------------------------
  1578.  
  1579. Date: 8 Jan 90 22:27:33 GMT
  1580. From: cs.utexas.edu!samsung!sol.ctr.columbia.edu!sdsu!ucselx!sunstroke.sdsu.edu!amagnet@tut.cis.ohio-state.edu  (Andrew Magnet)
  1581. Subject: Problem with Pk-232 MBX upgrade
  1582. Message-ID: <4270@ucselx.sdsu.edu>
  1583.  
  1584. I just installed my MBX upgrade and now have problems connecting
  1585. to other stations.  It will let me connect (sometimes) but it
  1586. doesn't let me stay connected very long i.e., it disconnects me
  1587. within 2 minutes.  I changed the custom command from $A015 to $A014
  1588. because someone said it worked for them.  Well, neither work
  1589. for me.  Now the lights on the front start flashing and then I get
  1590. a RS-232 link broken message.  Sometimes it lets me run the software
  1591. and other times it tells me that there is no link.  This even
  1592. happens when I don't even touch the keyboard...it will happen by
  1593. itself within 5 minutes of bootup.
  1594.  
  1595. I'm running my Pk-232(MBX) with a IBMPC-XT with the PC-PAKRATT
  1596. software.  It worked fine for about a year without problems
  1597. before the upgrade was installed.  Also, I did not install
  1598. the battery that came with the upgrade.
  1599.  
  1600. Can anyone help me that may have had a similar problem?
  1601.  
  1602. Respond to amagnet@sunstroke.sdsu.edu
  1603.  
  1604. TNX
  1605. Andy Magnet (N6OSR)
  1606.  
  1607. ------------------------------
  1608.  
  1609. Date: Tue, 9 Jan 90 08:29 EST
  1610. From: "D.RODMAN" <OOPDAVID@ubvmsc.cc.buffalo.edu>
  1611. Subject: REMOTE STATION CONTROL
  1612.  
  1613. Would anyone have experience with use of packet, telephone or microwave
  1614. link to control an HF station by computer at a remote location?
  1615.  
  1616. Thanks and 73,
  1617. Dave
  1618.  
  1619. ------------------------------
  1620.  
  1621. Date: 9 Jan 90 00:43:02 GMT
  1622. From: zephyr.ens.tek.com!tekcrl!tekgvs!jans@uunet.uu.net  (Jan Steinman)
  1623. Subject: Used PK-232 Price?
  1624. Message-ID: <6631@tekgvs.LABS.TEK.COM>
  1625.  
  1626. (Reply bounced.)
  1627.    ----- Transcript of session follows -----
  1628. <<< RCPT To:<charlie%oakhill@cs.utexas.edu>
  1629. <<< DATA
  1630. 550 <charlie%oakhill@cs.utexas.edu>... Host unknown
  1631.  
  1632.    ----- Unsent message follows -----
  1633. Posted-Date: Mon,  8 Jan 90 10:45:35 PST
  1634. Received-Date: Mon, 8 Jan 90 17:05:10 CST
  1635. Received: from RUTGERS.EDU by cs.utexas.edu (5.59/1.46)
  1636.     id AA04031; Mon, 8 Jan 90 17:05:10 CST
  1637. Received: from ogicse.UUCP by rutgers.edu (5.59/SMI4.0/RU1.3/3.05) with UUCP 
  1638.     id AA16227; Mon, 8 Jan 90 18:05:01 EST
  1639. Received: by cse.ogi.edu
  1640.     (5.61+IDA_1.2.8+OGI_1.5.named/IDA-1.2.8+OGI_1.9.1.1) id AA14723; Mon, 8 Jan 90 
  1641. 14:15:47 -0800 Received: by tektronix.TEK.COM (5.51/7.1)
  1642.     id AA01195; Mon, 8 Jan 90 11:00:55 PST
  1643. Received: by tekirl.labs.tek.com (5.51/7.1)
  1644.     id AA08036; Mon, 8 Jan 90 06:45:22 PST
  1645. Received: by stammer.LABS.TEK.COM (5.17/6.24)
  1646.     id AA02926; Mon, 8 Jan 90 10:45:36 PST
  1647. From: jans@stammer.labs.tek.com (Jan Steinman)
  1648. Message-Id: <9001081845.AA02926@stammer.LABS.TEK.COM>
  1649. Date: Mon,  8 Jan 90 10:45:35 PST
  1650. To: oakhill!charlie@cs.utexas.edu (Charlie Thompson)
  1651. Subject: Re: Used PK-232 Price?
  1652. In-Reply-To: Your Message of 6 Jan 90 04:07:31 GMT
  1653.  
  1654.  
  1655. <Does anybody know what a used PK-232 goes for? Is $200 too much?  What about  
  1656. PK-FAX?  what's the price for this software (used version).>
  1657.  
  1658. I just bought one for $200, which I thought fair.  Ask about the ROM version.   
  1659. The oldest ones don't have FAX, older ones don't have NAVTEX, the brand new  
  1660. ones have MBOX.
  1661.  
  1662. Be careful about PK-FAX.  It won't run on my GRiD 100% compatible, and may not  
  1663. work on others.
  1664.  
  1665.                                Jan Steinman - N7JDB
  1666.                     Tektronix Electronic Systems Laboratory
  1667.                     Box 500, MS 50-370, Beaverton, OR 97077
  1668.                         (w)503/627-5881 (h)503/657-7703
  1669.  
  1670.                                Jan Steinman - N7JDB
  1671.                     Tektronix Electronic Systems Laboratory
  1672.                     Box 500, MS 50-370, Beaverton, OR 97077
  1673.                         (w)503/627-5881 (h)503/657-7703
  1674.  
  1675. ------------------------------
  1676.  
  1677. Date: 8 Jan 90 01:39:13 GMT
  1678. From: cs.utexas.edu!wuarchive!uwm.edu!rpi!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!phil@tut.cis.ohio-state.edu
  1679. Subject: What is HAMSTER?
  1680. Message-ID: <30600029@ux1.cso.uiuc.edu>
  1681.  
  1682. Originally from MBramwel@business.uwo.CA
  1683.  
  1684. > The mods database is now available through the internet.
  1685. >
  1686. > IP address:  129.100.22.100    HAMSTER.business.uwo.ca
  1687. >
  1688. > If you want to post a file, please email it to me.
  1689. >
  1690. > A separate copy is stored on the IBM 4381 for mail users, therefore
  1691. > I need to know if a new file comes in.
  1692. >
  1693. > Enjoy, let me know if you have any problems.
  1694.  
  1695. --Phil Howard, KA9WGN--
  1696. <phil@ux1.cso.uiuc.edu>
  1697.  
  1698. ------------------------------
  1699.  
  1700. Date: 8 Jan 90 14:41:10 GMT
  1701. From: sun-barr!newstop!texsun!texbell!uudell!natinst!rpp386!puzzle!khijol!erc@lll-winken.llnl.gov  (Edwin R. Carp)
  1702. Subject: What is HAMSTER?
  1703. Message-ID: <922@khijol.UUCP>
  1704.  
  1705. In article <30600029@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu writes:
  1706. >
  1707. >> IP address:  129.100.22.100    HAMSTER.business.uwo.ca
  1708.  
  1709. Yes, but is it available via uucp/dialup?
  1710. -- 
  1711. Ed Carp                 N7EKG/5 (28.3-28.5)     uunet!cs.utexas.edu!khijol!erc
  1712. Austin, Texas           (512) 832-5884          "Good tea.  Nice house." - Worf
  1713. ***   Did you know that Barbie Benton PLAYS THE PIANO??  Quite well, too!   ***
  1714.  
  1715. ------------------------------
  1716.  
  1717. End of PACKET-RADIO Digest V90 Issue #6
  1718. ***************************************
  1719.  9-Jan-90 22:18:34-MST,12675;000000000000
  1720. Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
  1721. Date: Tue,  9 Jan 90 22:15:11 MST
  1722. From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
  1723. Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  1724. Subject: PACKET-RADIO Digest V90 #7
  1725. To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  1726.  
  1727. PACKET-RADIO Digest         Tue,  9 Jan 90       Volume 90 : Issue    7
  1728.  
  1729. Today's Topics:
  1730.                 AX25 Protocol
  1731.          Ham radio names and routing (2 msgs)
  1732.   Making things more difficult than necessary (was: Tasco TNC info)
  1733.           PBBS forwarding via dialup modem?
  1734.                  Stolen radio
  1735.            Updates to NOS 900105 from Russ and me.
  1736. ----------------------------------------------------------------------
  1737.  
  1738. Date: 9 Jan 90 23:07:11 GMT
  1739. From: shlump.nac.dec.com!koning.dec.com!koning@decwrl.dec.com  (Paul Koning)
  1740. Subject: AX25 Protocol
  1741. Message-ID: <7335@shlump.nac.dec.com>
  1742.  
  1743. In article <164@raider.MFEE.TN.US>, root@raider.MFEE.TN.US (Bob Reineri)
  1744. writes:
  1745.  
  1746. > Could some kind soul out there mail me the specs for the AX.25 protocol, or
  1747. > point me to where I could download them ?? 
  1748.  
  1749. You can buy it from ARRL for a few dollars.  Have fun, and don't trip over the
  1750. bugs in the spec...
  1751.  
  1752.     paul, ni1d
  1753.  
  1754. ------------------------------
  1755.  
  1756. Date: 9 Jan 90 22:02:05 GMT
  1757. From: zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!splut!jay@tut.cis.ohio-state.edu  (Jay "you ignorant splut!" Maynard)
  1758. Subject: Ham radio names and routing
  1759. Message-ID: <ZC-:A1@splut.conmicro.com>
  1760.  
  1761. In article <1990Jan3.171148.13647@tandem.com> kevinr@tandem (Kevin J. Rowett) writes:
  1762. >In article <6287#.@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes:
  1763. >>In the referenced message, John, KD7UW, writes a lot of common sense.
  1764. >Jay, What's the "common sense" that you speak of in SOURCE ROUTING?
  1765. >The quickest problem to point out is what happens to your traffic
  1766. >when one of the routers in the path goes away?  And how do you discover
  1767. >the new path?
  1768.  
  1769. As has been pointed out here and on tcp-group, WB5BBW@HOU.TX.USA.NA is
  1770. not a route, it's a location. All it says is that WB5BBW is in Houston,
  1771. which is in Texas, which is in USA, which is in North America. It says
  1772. nothing about how to get the message to any of those geographic
  1773. locations.
  1774.  
  1775. The common sense I was referring to was the part about how we should
  1776. drop the religious objections and get on with making things work well.
  1777.  
  1778. -- 
  1779. Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
  1780. jay@splut.conmicro.com       (eieio)| adequately be explained by stupidity.
  1781. {attctc,bellcore}!texbell!splut!jay +----------------------------------------
  1782.    "There is no doubt I should be tarred and feathered." - Richard Sexton
  1783.  
  1784. ------------------------------
  1785.  
  1786. Date: 9 Jan 90 00:25:28 GMT
  1787. From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hp.com  (Bdale Garbee)
  1788. Subject: Ham radio names and routing
  1789. Message-ID: <4390108@col.hp.com>
  1790.  
  1791. >SO WHAT'S THE BIG DIFFERENCE?
  1792.  
  1793. The big difference is that in NET/NOS, we acknowledge that the static 'route'
  1794. command is a poor substitute for an automatic routing protocol.  It is clear
  1795. from the syntax that naming and routing information are separate entities.  And
  1796. when RSPF/RIP/Whatever begin to enjoy wide use for route generation between
  1797. IP switches, the only thing an end user station will need to do is to insert
  1798. a 'route add default ax0 <local_switch_name>', and everything else will be
  1799. automagic.  
  1800.  
  1801. The point has been made elsewhere that the BBS H addressing isn't actually
  1802. source routing, but is a combination of a flat address (the callsign part of
  1803. the "hostname"), and geographic routing hints (the .CO.USA.NA part).  The
  1804. confusion, and in large part the concern within the IP world, is that 
  1805. addressing and routing are separate issues, and the dot-notation syntax makes
  1806. this appear to be a pseudo-domain-name, which it's not, and a concern that
  1807. the folks building BBS software really understand the distinction between
  1808. addressing/naming and providing routing hints.
  1809.  
  1810. W9NK (I think) has made an interesting proposal on tcp-group that is being
  1811. looked at, which would change the syntax of addresses on the PBBS side, and
  1812. clarify the distinction between the flat address space callsign, and the
  1813. routing hints.  I think it's likely that some change from the dot-notation will
  1814. likely be addopted by the PBBS authors, eventually.
  1815.  
  1816. I don't think what they're doing is *wrong*, it's just misleading, and in many
  1817. ways a less than optimal solution.
  1818.  
  1819. >Also, my comments concerning the "RELGIOUSITY" of certain individuals is
  1820. >not meant to "deny them first amendment rights", it is that this
  1821. >attitude has created a dictatorship of the "AMPR.ORG" domain and Network
  1822. >"44"  ... This dictatorial attitude prevents any democratic aproach to
  1823. >the question of subdomains, administrative subnetworks which can use
  1824. >geography for pragmatic reasons (eventhough you see geographic subnets
  1825. >in internets all the time), summary decisions to allocate less that full
  1826. >byte subnets without user input, etc.  (I found the DIETY, MOTHER, and
  1827. >ADDRESS analogy very telling).
  1828.  
  1829. Hmmm.  It may be "very telling", but it avoids the basic issue, which is that
  1830. religion is being confused with experience.  Unfortunately, and at the root
  1831. of the real problem, is that the "in crowd" in AMPR.ORG have had to answer the
  1832. same questions about geographic routing 1e6 times in the last couple of years,
  1833. as new users come online and get wild ideas in their heads, and become
  1834. confused about the issues of addressing and routing, after reading well-meant
  1835. articles and papers by folks in the amateur packet community who do not have
  1836. much depth of experience building real internetworked systems.
  1837.  
  1838. This is unfortunate, but strikes me as more of a communication problem than a
  1839. "dictatorship"... The attitudes of individuals may get to seem "dictatorial"
  1840. at times, but I think it's more out of boredom from explaining the same thing
  1841. for the n'th time than any real reflection of attitude.
  1842.  
  1843. >I would say that a
  1844. >majority of users just want Email and Bulletin services, lets make the
  1845. >path easy between them and those who want the higher services of
  1846. >networks like IP.
  1847.  
  1848. Agreed.  And believe it or not, this exact wish is often at the root of
  1849. complaints about the PBBS H address syntax and semantics.  It generates a lot
  1850. of confusion, and in some ways makes generating reasonable gateways and 
  1851. reasonable addressing rules harder for both sides...  
  1852.  
  1853. Bdale
  1854.  
  1855. ------------------------------
  1856.  
  1857. Date: 9 Jan 90 00:27:03 GMT
  1858. From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hp.com  (Bdale Garbee)
  1859. Subject: Making things more difficult than necessary (was: Tasco TNC info)
  1860. Message-ID: <4390109@col.hp.com>
  1861.  
  1862. >Or, yet another possibility: To avoid messy soldering (on the EPROM, at
  1863. >least), obtain a 27C512 and copy your original ROM into one half of the
  1864. >64K address space, and KISS into the other half.  Then use the switch as
  1865. >a ROM select by changing the state of the A14 line.
  1866.  
  1867. Le Huh?
  1868.  
  1869. The KISS for the u21 that I made available is a copy of all the functionality
  1870. provided in the standard firmware, plus KISS ala the TAPR 1.1.6 w/KISS EPROM.
  1871.  
  1872. It is *not* KISS-only, and as such, there's no need for piggybacking, or
  1873. anything!
  1874.  
  1875. Bdale
  1876.  
  1877. ------------------------------
  1878.  
  1879. Date: Tue, 9 Jan 90 23:04:51 PST
  1880. From: elmquist@nips.ssesco.com
  1881. Subject: PBBS forwarding via dialup modem?
  1882. Message-ID: <9001100505.AA01654@nips.ssesco.com>
  1883.  
  1884. Just wondering if any of the PBBS packages (RLI, MBL, AA4RE, etc) have any
  1885. provisions for forwarding traffic via dialup modem?  I guess it would work
  1886. something like UUCP.  We have a problem here in Mpls/St. Paul..in that
  1887. most of our outside world traffic comes and goes through a connection
  1888. called the "Gofar Hole".
  1889.  
  1890. This Gofar Hole is a piggy back connection
  1891. on top of a private corporate network.  A TNC in MSP is connected to
  1892. the sio line of Sun...the Sun talks to another Sun in Maryland via the
  1893. network...and the sio of that Sun is connected to another TNC which
  1894. finally puts the stuff on the air.  Both TNCs are NET/ROM'd.
  1895.  
  1896. This all sounds great except that the link is down more often than
  1897. it is up.  It's not a high priority for the people who own the
  1898. Suns and the network...to restart the processes that keep the AX.25
  1899. traffic moving...  consequently, we don't get any new packet traffic
  1900. for days and days.  The most frusterating part for me is not getting
  1901. AMSAT bulletins.  When we finally get them--  they are weeks, sometimes
  1902. a month old!
  1903.  
  1904. What I would like is a fall back connection via dialup modem.  If
  1905. the PBBS determines that forwarding via the Gofar Hole (or worm hole
  1906. of your choice) is failing...  then it will dial the other PBBS on
  1907. the phone.  If we were really smart, we'd compress the traffic using
  1908. .ARC or .ZIP techniques and then use MNP on the link for reliability
  1909. and speed.
  1910.  
  1911. I work for a modem company--  hence v.32 9600 baud modems for
  1912. each end are feasable.
  1913.  
  1914. Any ideas? flames?    Chris   N0JCF
  1915.  
  1916.  
  1917. ------------------------------
  1918.  
  1919. Date: 9 Jan 90 19:47:31 GMT
  1920. From: cs.utexas.edu!usc!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!phil@tut.cis.ohio-state.edu  (Phil Howard)
  1921. Subject: Stolen radio
  1922. Message-ID: <1990Jan9.194731.19118@ux1.cso.uiuc.edu>
  1923.  
  1924. Kenwood HF transceiver model TS-440S (with general coverage receive)
  1925. S/N 7060175
  1926. Stolen during breakin of Synton ARC station between Jan 5 and Jan 8 1990.
  1927.  
  1928. Features installed:
  1929.     AT-440 auto antenna tuner
  1930.     YK-88S 2.1 khz SSB filter
  1931.     YK-88C 500 hz CW filter
  1932.     10 hz display mod
  1933.  
  1934. If you find this radio, contact local police or:
  1935.     University of Illinois Police
  1936.     Officer Frost
  1937.     Case I90-0031
  1938.     Phone 217-333-1216
  1939.  
  1940. Phil Howard, KA9WGN
  1941. 217-384-4934
  1942. 217-244-6246
  1943. phil@ux1.cso.uiuc.edu
  1944. uiucuxc!ux1!phil
  1945. --
  1946.  
  1947. --Phil Howard, KA9WGN--
  1948. <phil@ux1.cso.uiuc.edu>
  1949.  
  1950. ------------------------------
  1951.  
  1952. Date: 9 Jan 90 15:08:35 GMT
  1953. From: aplcen!wb3ffv!gvdgpc!gvdg@uunet.uu.net  (Gerard J van der Grinten PA0GRI)
  1954. Subject: Updates to NOS 900105 from Russ and me.
  1955. Message-ID: <292@gvdgpc.UUCP>
  1956.  
  1957. This version is a combination of Phil's work, from Russel Nelson and PA0GRI.
  1958. Phils mods include tracing into a file (trace interface tracelevel [file])
  1959. If file is not given output is redirected to the screen.
  1960. From Russel Nellson are his mods as contained in diffs.arc.
  1961. They include:
  1962. a)
  1963. Arcnet support where arcnet uses the packet driver interface.
  1964. b)
  1965. The fcntl control call and command.asm mods. This makes NOS run through when
  1966. shell escaping to DOS as a tsr. (no smtp hangs anymore. Even trace goes on)
  1967. c)
  1968. Interprosess comunication via int 0x2f (for rlogin client)
  1969. d)
  1970. Logging of MKDir and RMDir commands.
  1971. e)
  1972. If you have a anonymous account in your ftpusers file any user name will be
  1973. accepted and mapped into the anonymous account. (seems not "everybody" knows
  1974. anonymous account, In europe guest is used in net/nos often)
  1975. f)
  1976. The JOINed disk (if used) is found and statused if a dir is done on the joined
  1977. drive.
  1978. g)
  1979. Multiple directorys can be accessed on the same level. Normaly there is a 
  1980. root directory. In ftpusers it is like "anonymous * /dir1;/dir2 1"
  1981. (directorys are separated by ; and no "white space" is alowed.
  1982. h)
  1983. A net.rc (aka .netrc) file is supported for ftp access to other machines.
  1984. This auto logins you to the destined machine.
  1985. Format is "system username password" . Note that it all is clear text.
  1986. net.rc lives in the root directory.
  1987. i)
  1988. I did not find the rlogin client so that is not added but some hooks are
  1989. in place.
  1990. j)
  1991. Tar backup feature! If you specify 'recv direct/tar/*.* than all files
  1992. in direct are tarred into one destination file. This is great to backup
  1993. a single directory into (onto) another system. I did not encounter speed
  1994. degradation in backing up my NOS directory onto my UNIX system via ethernet.
  1995. On a destination /tar/ read it should expand the tar file again.
  1996. a)
  1997. From PA0GRI the domain mods are included.
  1998. b)
  1999. autoexec.net is called autoexec.nos to make a difference on people using
  2000. both NET and NOS and dont want to switch between configuration files.
  2001.  
  2002. I uploaded nosadd.arc and nosgri30.exe to flash.bellcore.com in the files
  2003. /pub/nosadd.arc and /pub/nosgri30.exe . nosadd.arc contains all changed files
  2004. against nosv30tc.arc (phil's nos.arc 900105)
  2005. Also on wb3ffv and gvdgpc bbs systems both files are uploaded.
  2006. Note: nosv30 is phil's 900105 release.
  2007. Regards. gerard.
  2008.  
  2009. ------------------------------
  2010.  
  2011. End of PACKET-RADIO Digest V90 Issue #7
  2012. ***************************************
  2013. 12-Jan-90 18:24:51-MST,12054;000000000000
  2014. Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
  2015. Date: Fri, 12 Jan 90 18:15:49 MST
  2016. From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
  2017. Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  2018. Subject: PACKET-RADIO Digest V90 #8
  2019. To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  2020.  
  2021. PACKET-RADIO Digest         Fri, 12 Jan 90       Volume 90 : Issue    8
  2022.  
  2023. Today's Topics:
  2024.               A location is not a route.
  2025.           can't reach <dug@kd4nc.gatech.edu>
  2026.                 Duplex Repeat
  2027.                Grapes on Duplex Repeat
  2028.              Ham radio names and routing
  2029.           PBBS forwarding via dialup modem?
  2030.               PK-88 RFI problems
  2031.           Unix/KA9Q pty support for outgoing telnet
  2032.                What is HAMSTER?
  2033. ----------------------------------------------------------------------
  2034.  
  2035. Date: 5 Jan 90 05:11:24 GMT
  2036. From: dsl.pitt.edu!pitt!w2xo!durham@PT.CS.CMU.EDU  (Jim Durham)
  2037. Subject: A location is not a route.
  2038. Message-ID: <119@w2xo.UUCP>
  2039.  
  2040. W0RLI Writes:
  2041.  
  2042. > Note that the "BBS net" addresses are not routes, but locations.
  2043. > Routing takes place at the individual servers, and can be based
  2044. > on any of the location information, or on the addresses.
  2045. > OR.USA.NA  is a location, and does not say anything about
  2046. > how one could GET there, but just where it is located.
  2047. >    ...  Hank  - w0rli
  2048.  
  2049. I think Hank hit the nail on the head. I have been wondering how one
  2050. could apply the term "source routing" to the W6XXX.CA.US.NA type
  2051. scheme. A "source routing", scheme as I understand it, is to specify
  2052. the entire path , as is done on Usenet (foobar!nerdley!fonzy!..etc).
  2053.  
  2054. The ham packet network is not a network in the same sense as the
  2055. Internet. It is a "bucket brigade". The decision that needs to be
  2056. made at each BBS is, in the case of a destination address that is
  2057. not directly reachable, "which 'next node' do I send this to?". 
  2058. Which way do I "pass the bucket". Knowing the geographical location
  2059. of the destination drives this decision. Given the poor connectivity
  2060. of the network, the only other solution would appear to be maintaining
  2061. a "nameserver" at each BBS, which is the way things were originally
  2062. done. This is a pain in the wazoo.. 
  2063.  
  2064. -73
  2065. Jim, w2xo
  2066.  
  2067. ------------------------------
  2068.  
  2069. Date: 12 Jan 90 10:39:39 GMT
  2070. From: cs.utexas.edu!uwm.edu!rpi!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!phil@tut.cis.ohio-state.edu
  2071. Subject: can't reach <dug@kd4nc.gatech.edu>
  2072. Message-ID: <30600030@ux1.cso.uiuc.edu>
  2073.  
  2074. Sorry for posting this, but I need a different E-mail address for someone
  2075. who frequents this newsgroup.  I am trying to send mail to Doug Drye KD4NC
  2076. at the address he gives of "kd4nc.gatech.edu".  Mail bounces apparently
  2077. due to an error in a mailer near his end.  Doug, here are the symptoms:
  2078.  
  2079.    > From MAILER-DAEMON@gatech.edu Thu Jan 11 20:17:18 1990
  2080.    > Received: from gatech.edu by ux1.cso.uiuc.edu with SMTP
  2081.    >    (5.61+/IDA-1.2.8) id AA15273; Thu, 11 Jan 90 20:16:57 -0600
  2082.    > Received: by gatech.edu (5.58/GATECH-8.6)
  2083.    >    id AA11203 for phil@ux1.cso.uiuc.edu; Thu, 11 Jan 90 21:14:58 EST
  2084.    > Date: Thu, 11 Jan 90 21:14:58 EST
  2085.    > From: MAILER-DAEMON@gatech.edu (Mail Delivery Subsystem)
  2086.    > Subject: Returned mail: Service unavailable
  2087.    > Message-Id: <9001120214.AA11203@gatech.edu>
  2088.    > To: <phil@ux1.cso.uiuc.edu>
  2089.    > Status: R
  2090.    > 
  2091.    >    ----- Transcript of session follows -----
  2092. >>>> >>> HELO gatech.edu
  2093. >>>> <<< 553 gatech.edu I refuse to talk to myself
  2094. >>>> 554 <dug@kd4nc.gatech.edu>... Service unavailable: Bad file number
  2095.  
  2096. Seems like an error in the gatech.edu mailer.
  2097.  
  2098.    > 
  2099.    >    ----- Unsent message follows -----
  2100.    > Received: from ux1.cso.uiuc.edu by gatech.edu (5.58/GATECH-8.6)
  2101.    >    id AA11142 for ; Thu, 11 Jan 90 21:09:19 EST
  2102.    > Received: by ux1.cso.uiuc.edu
  2103.    >    (5.61+/IDA-1.2.8) id AA14139; Thu, 11 Jan 90 20:10:19 -0600
  2104.    > Date: Thu, 11 Jan 90 20:10:19 -0600
  2105.    > From: Phil Howard KA9WGN <phil@ux1.cso.uiuc.edu>
  2106.    > Message-Id: <9001120210.AA14139@ux1.cso.uiuc.edu>
  2107.    > To: dug@kd4nc.gatech.edu
  2108.    > Subject: Re: WA4DSY
  2109.  
  2110. ------------------------------
  2111.  
  2112. Date: 10 Jan 90 06:37:08 GMT
  2113. From: swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!stiatl!rsiatl!kd4nc!dug@ucsd.edu  (Doug Drye KD4NC)
  2114. Subject: Duplex Repeat
  2115. Message-ID: <3400@kd4nc.UUCP>
  2116.  
  2117. julian@bongo.UUCP (julian macassey) writes:
  2118.  
  2119.  
  2120. >Late last year someone on this newsgroup mentioned that they had 
  2121. >a repeater running the GRAPES 56KB packet modem. Details were 
  2122. >supposed to be forthcoming. Any news on the horizon?
  2123.  
  2124. You may not be referring to us, Julian.. Since I don't recall any promised
  2125. publication of details...but anyway......
  2126.  
  2127. GRAPES has three KA9Q switches "Mountaintop" interconnected with 56K modems 
  2128. here in N. Ga.. All of them have 1200 baud channels (most more that one).
  2129. These switches make up the production AX.25 and TCP/IP network
  2130. (Net/Rom will be integrated soon (Thanks, Dan)) for N. Ga. We are not
  2131. building a parallel network for IP.
  2132.  
  2133. One of the switches has a full duplex 1200 baud repeater for the LAN.
  2134.  
  2135. I'm sorry to say that a full duplex 56K LAN is still on our "wish list",
  2136. since our kit and switch building activities have taken up most of the
  2137. energy needed to build the necessary hardware.
  2138. The switches we have are running simplex 56K.
  2139.  
  2140. I'd be happy to answer any questions on our setup, if it's of any interest
  2141. to you..   I'd also like to hear about others who have production switches
  2142. and/or 56K on the air full time especially Full Duplex.
  2143.  
  2144. 73's
  2145. Doug
  2146.  
  2147.  
  2148. -- 
  2149. Doug Drye KD4NC
  2150.  
  2151. ------------------------------
  2152.  
  2153. Date: 8 Jan 90 15:27:15 GMT
  2154. From: mitel!sce!cognos!dgbt!barry@uunet.uu.net  (Barry McLarnon DGBT/DIP)
  2155. Subject: Grapes on Duplex Repeat
  2156. Message-ID: <1347@dgbt.uucp>
  2157.  
  2158. From article <288@bongo.UUCP>, by julian@bongo.UUCP (julian macassey):
  2159. > Late last year someone on this newsgroup mentioned that they had 
  2160. > a repeater running the GRAPES 56KB packet modem. Details were 
  2161. > supposed to be forthcoming. Any news on the horizon?
  2162.  
  2163. I confess, 'twas I.  Sorry for the delay, but the info is now in the mail
  2164. to you and a few others who requested it.
  2165.  
  2166. 73, Barry VE3JF
  2167.  
  2168. -- 
  2169. Barry McLarnon    Communications Research Center    Ottawa, ON   Canada
  2170. UUCP: ...utzoo!bnr-vpa!bnr-rsc!dgbt!barry   INTERNET:  barry@dgbt.crc.dnd.ca
  2171. Compu$erve: 71470,3651     Packet radio:  VE3JF @ VE3JF
  2172.  
  2173. ------------------------------
  2174.  
  2175. Date: 12 Jan 90 12:30:51 GMT
  2176. From: usc!wuarchive!texbell!splut!jay@ucsd.edu  (Jay "you ignorant splut!" Maynard)
  2177. Subject: Ham radio names and routing
  2178. Message-ID: <MT.:P.@splut.conmicro.com>
  2179.  
  2180. In article <1990Jan11.164732.18479@tandem.com> kevinr@tandem (Kevin J. Rowett) writes:
  2181. >>As has been pointed out here and on tcp-group, WB5BBW@HOU.TX.USA.NA is
  2182. >I'd not seen this syntax.  Is WB5BBW a user and HOU the host? Or is
  2183. >WB5BBW a host?  If so, who's the user?   
  2184.  
  2185. I screwed up; I should have said K5ZC@WB5BBW.TX.USA.NA.
  2186. That said, it's STILL a location, not a route. It says nothing at all
  2187. except that WB5BBW is in Texas, and nothing at all about how that
  2188. message is to get to Texas.
  2189.  
  2190. Yes, WB5BBW is unique.
  2191. Unfortunately, the only ways to know that WB5BBW is in Texas are 1) have
  2192. the user, who knows it already, tell the computer about it; 2) store a
  2193. database potentially the size of the Callbook online to look it up; or
  2194. 3) have the BBS contact a nameserver elsewhere that has the huge
  2195. database on it. The nameserver doesn't exist. I haven't seen anyone
  2196. volunteering to write it, nor have I seen anyone volunteering to
  2197. manually maintain the huge list involved. Until the nameserver exists,
  2198. and is the same production quality as the rest of the BBS software, it
  2199. won't get used, reducing the available solutions to 1) and 2) above. 1)
  2200. is much easier for everyone concerned, and works just fine.
  2201.  
  2202. If you have religious objections to what you see as source routing, then
  2203. don't complain - come up with the software that will fix it.
  2204.  
  2205. -- 
  2206. Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
  2207. jay@splut.conmicro.com       (eieio)| adequately be explained by stupidity.
  2208. {attctc,bellcore}!texbell!splut!jay +----------------------------------------
  2209.    "There is no doubt I should be tarred and feathered." - Richard Sexton
  2210.  
  2211. ------------------------------
  2212.  
  2213. Date: Wed, 10 Jan 90 07:37:30 PST
  2214. From: "Roy Engehausen" <ENGE@IBM.COM>
  2215. Subject: PBBS forwarding via dialup modem?
  2216. Message-ID: <9001100505.AA01654@nips.ssesco.com>
  2217.  
  2218. AA4RE PBBS version 2.8 has provision for a modem line and will forward
  2219. via that port.
  2220.  
  2221.  
  2222. ------------------------------
  2223.  
  2224. Date: 10 Jan 90 18:14:36 GMT
  2225. From: henry.jpl.nasa.gov!elroy.jpl.nasa.gov!jpl-devvax!jenkins@ames.arc.nasa.gov  (Steve Jenkins)
  2226. Subject: PK-88 RFI problems
  2227. Message-ID: <6763@jpl-devvax.JPL.NASA.GOV>
  2228.  
  2229. Hardware:       AEA PK-88, battery powered, out of warranty
  2230.  
  2231. Problem:        With no cables except power connected, the PK-88
  2232.         generates enough RF on 145.01 to open the squelch on
  2233.         my Kenwood TH-215A (squelch set to max; duck) about
  2234.         30 feet away.  Using scan mode on the 215A, I found
  2235.         a strong peak at 145.01 and another at 147.465; both
  2236.         are definitely generated by the PK-88.  It's done this
  2237.         since it was new; I didn't have time to mess with it
  2238.         until now.
  2239.  
  2240. Tried:          ensuring good chassis-to-case connections (case is metal)
  2241.         grounding chassis to outlet ground (no really good
  2242.             RF ground nearby)
  2243.         checking .1 mf bypass capacitor at DC input (seems OK)
  2244.  
  2245. Not yet tried:  ferrite beads on the power cable
  2246.         shielding power cable (It's AEA's cable....)
  2247.  
  2248. Suggestions:    by email please;  I'll summarize.
  2249.  
  2250. Thanks:         in advance
  2251.  
  2252. -- 
  2253. Steve Jenkins N6UNI                     jenkins@jpl-devvax.jpl.nasa.gov
  2254. Caltech/Jet Propulsion Laboratory       (818) 354-0162
  2255.  
  2256. ------------------------------
  2257.  
  2258. Date: 12 Jan 90 14:32:07 GMT
  2259. From: mailrus!b-tech!zeeff@tut.cis.ohio-state.edu  (Jon Zeeff)
  2260. Subject: Unix/KA9Q pty support for outgoing telnet
  2261. Message-ID: <-H83MB@b-tech.uucp>
  2262.  
  2263. I'm running the ka9q software on a unix system w/o tcp/ip support (Sys V).  
  2264. I'd like to get it to run a outgoing telnet session to a pty port(s) 
  2265. instead of the console.  In other words, I'd like to get the ka9q 
  2266. software to read and write the telnet i/o to a pty port instead of the 
  2267. terminal that initiated the session (sort of the reverse of the pty 
  2268. support already in place).  The result would be that I could run 
  2269. kermit or cu on the other end of the pty and get a login: prompt.  
  2270.  
  2271. Perhaps it could be generalized to the point where the ka9q session 
  2272. code wasn't used at all and the systems windowing code (X11 or virtual 
  2273. consoles) was used for each session.  
  2274.  
  2275. Any ideas before I start hacking the session code?
  2276.  
  2277. -- 
  2278. Jon Zeeff       zeeff@b-tech.ann-arbor.mi.us  or b-tech!zeeff
  2279. -- 
  2280. Jon Zeeff       zeeff@b-tech.ann-arbor.mi.us  or b-tech!zeeff
  2281.  
  2282. ------------------------------
  2283.  
  2284. Date: 10 Jan 90 12:00:21 GMT
  2285. From: n8emr!gws@tut.cis.ohio-state.edu  (Gary Sanders)
  2286. Subject: What is HAMSTER?
  2287. Message-ID: <1404@n8emr.UUCP>
  2288.  
  2289. In article <922@khijol.UUCP> erc@khijol.UUCP (Edwin R. Carp) writes:
  2290. >In article <30600029@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu writes:
  2291. >>> IP address:  129.100.22.100    HAMSTER.business.uwo.ca
  2292. >Yes, but is it available via uucp/dialup?
  2293. >-- 
  2294. >Ed Carp                N7EKG/5 (28.3-28.5)     uunet!cs.utexas.edu!khijol!erc
  2295.  
  2296. If its not, you can get the same files from my dialup BBS.. I grabbed
  2297. all of the mods files a few weeks ago... you can xmodem,ymodem,kermit 
  2298. them out.
  2299.  
  2300.         73
  2301.  
  2302.  
  2303.  
  2304.  
  2305.  
  2306.  
  2307. -- 
  2308. Gary W. Sanders (gws@n8emr or ...!osu-cis!n8emr!gws), 72277,1325
  2309. N8EMR @ W8CQK (ip addr) 44.70.0.1 [Ohio AMPR address coordinator]
  2310. HAM/SWL/SCANNER BBS (1200/2400/PEP) 614-457-4227  614-895-2552 (after 1/12/90)
  2311. Voice: 614-457-4595 (eves/weekends)               614-895-2553 (after 1/12/90)
  2312.  
  2313. ------------------------------
  2314.  
  2315. End of PACKET-RADIO Digest V90 Issue #8
  2316. ***************************************
  2317. 12-Jan-90 20:20:54-MST,13115;000000000000
  2318. Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
  2319. Date: Fri, 12 Jan 90 20:15:29 MST
  2320. From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
  2321. Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  2322. Subject: PACKET-RADIO Digest V90 #9
  2323. To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  2324.  
  2325. PACKET-RADIO Digest         Fri, 12 Jan 90       Volume 90 : Issue    9
  2326.  
  2327. Today's Topics:
  2328.               A location is not a route.
  2329.          BBS Source code & KISS specification needed
  2330.              Digicom cartridge confusion
  2331.          packet radio (X.25) in aviation band
  2332.           PBBS forwarding via dialup modem?
  2333.               PK-88 RFI problems
  2334.              TAPR Annual Meeting
  2335. ----------------------------------------------------------------------
  2336.  
  2337. Date: 11 Jan 90 17:02:03 GMT
  2338. From: amdahl!pacbell!tandem!kevinr@ames.arc.nasa.gov  (Kevin J. Rowett)
  2339. Subject: A location is not a route.
  2340. Message-ID: <1990Jan11.170203.18601@tandem.com>
  2341.  
  2342. In article <119@w2xo.UUCP> durham@w2xo.UUCP (Jim Durham) writes:
  2343. >W0RLI Writes:
  2344. >
  2345. >> Note that the "BBS net" addresses are not routes, but locations.
  2346. >> Routing takes place at the individual servers, and can be based
  2347. >> on any of the location information, or on the addresses.
  2348. >> OR.USA.NA  is a location, and does not say anything about
  2349. >> how one could GET there, but just where it is located.
  2350. >> 
  2351. >>    ...  Hank  - w0rli
  2352. >
  2353. >I think Hank hit the nail on the head. I have been wondering how one
  2354. >could apply the term "source routing" to the W6XXX.CA.US.NA type
  2355. >scheme. A "source routing", scheme as I understand it, is to specify
  2356. >the entire path , as is done on Usenet (foobar!nerdley!fonzy!..etc).
  2357.  
  2358. If isn't W6XXX.ca.us.na source routing, then W6XXX should be sufficent,
  2359. right?  Source routing is defined as the originator describing the
  2360. path to reach a location.
  2361.  
  2362. In the about case, we've tried to "qualify" the name with a path
  2363. as well.  Yes, I know some would argue that .ca.us.na is a "location",
  2364. but how does a location differ from an "address"?
  2365.  
  2366. >
  2367. >The ham packet network is not a network in the same sense as the
  2368. >Internet. It is a "bucket brigade". The decision that needs to be
  2369. >made at each BBS is, in the case of a destination address that is
  2370. >not directly reachable, "which 'next node' do I send this to?". 
  2371. >Which way do I "pass the bucket". Knowing the geographical location
  2372. >of the destination drives this decision. Given the poor connectivity
  2373.  
  2374. Which, in the example above, was obtained from the originator of the
  2375. message.
  2376.  
  2377. >of the network, the only other solution would appear to be maintaining
  2378. >a "nameserver" at each BBS, which is the way things were originally
  2379. >done. This is a pain in the wazoo.. 
  2380.  
  2381. I agree at the present data rates and physical layer protocols,
  2382. connectivity isn't the best, but a number of Hams are working to radically
  2383. alter that situation.  WHEN that comes about, the nameserver idea will
  2384. be practical, and the benefits will be obvious.
  2385.  
  2386. N6RCE
  2387.  
  2388. ------------------------------
  2389.  
  2390. Date: 11 Jan 90 20:19:00 GMT
  2391. From: pixar!matt@ucbvax.Berkeley.EDU  (Matthew Martin)
  2392. Subject: BBS Source code & KISS specification needed
  2393. Message-ID: <8526@pixar.UUCP>
  2394.  
  2395.     Greetings to the net!  I would like to know if the source code
  2396. for any of the popular BBS software packages (like RLI, MBL and AA4RE)
  2397. is available.  I also would like a quick pointer to information about
  2398. KISS - in particular, a specification or detailed info about the commands,
  2399. etc.  If this is published anywhere (proceedings of ARRL Computer Networking
  2400. Conference ???), a simple citation will do.
  2401.  
  2402.     We desire to set up a packet system in Marin County for RACES.  It
  2403. would be nice to make this system as automatic and user-friendly (gack!) as
  2404. possible.  Ultimately, a PC clone attached to a TNC & radio would be the
  2405. basic hardware.  The software would present to the user an editor for 
  2406. message origination, and once the message was edited, it would be send to
  2407. its destination right away.  Incoming messages would be printed immediately,
  2408. without the need to list messages from a BBS, selecting your messages for
  2409. printing.  All the user need do is enter messages, and once entered the user
  2410. would not have to mess with the mechanics of the packet transfer.  Incoming
  2411. traffic is as simple as checking for printout on the printer.
  2412.  
  2413.     I don't suppose such a system already exists??  Reply via e-mail,
  2414. and I will summarize to the net.  Many thanks!
  2415.  
  2416. ----
  2417. Matt Martin     ....!ucbvax!pixar!matt
  2418.  N6LQB
  2419.  
  2420. ------------------------------
  2421.  
  2422. Date: 12 Jan 90 00:34:37 GMT
  2423. From: masscomp!ocpt!tsdiag!ka2qhd!w2up@think.com  (Barry Kutner W2UP)
  2424. Subject: Digicom cartridge confusion
  2425. Message-ID: <90@ka2qhd.UUCP>
  2426.  
  2427. There has been some confusion about my Digicom cartridge (DIGICART).
  2428. The DIGICART replaces the software ONLY. Its advantages include
  2429. autobooting and ability to store parameters to the cartridge (both
  2430. almost instantaneous). A Digicom modem is still needed for packet
  2431. operation. Any questions can be referred to me here or via US mail.
  2432. 73/Barry, W2UP
  2433.  
  2434. ------------------------------
  2435.  
  2436. Date: 11 Jan 90 20:01:34 GMT
  2437. From: philmtl!philabs!briar.philips.com!rfc@uunet.uu.net  (Robert Casey;6282;3.57;$0201)
  2438. Subject: packet radio (X.25) in aviation band
  2439. Message-ID: <73453@philabs.Philips.Com>
  2440.  
  2441. copied from packet:
  2442. From: ka2raf@nn2z.ampr.org (Chris Crosby)
  2443. To: swls@allbbs
  2444. Subject: Packet in Aviation Bands
  2445.  
  2446.                PACKET IN AVIATION BAND
  2447.              By Dave Sweigert
  2448.  
  2449. What you hear on 131.55 is packet radio.  Aeronautical Radio maintains
  2450. 200 ground stations around the country that feed into a giant X.25
  2451. computer network.  Ever wonder where the flight attendant gets arriving
  2452. gate info minutes before you land ?  Via a terminal in the cockpit.
  2453. Data such as engine tempature, winds aloaft, etc is downlinked via this
  2454. network.  All 200 stations operate on 131.55.  For more info write:
  2455.  
  2456.  Industry Activities
  2457.   ARINC
  2458.  Radio Operations, Bldg 2
  2459.  2551 Riva Road
  2460.  Annapolis, MD  21403
  2461.  
  2462. They may send you some
  2463. interesting brocherures.
  2464.  
  2465. A few (airline company)freqs which I have tentatively identified:
  2466.  
  2467. 129.2   American Airlines
  2468. 129.5   Delta
  2469. 130.65  Military Airlift Command
  2470. 130.7   Eastern
  2471. 129.625 TWA
  2472. 131.925 Federal Express
  2473.  
  2474.  
  2475. Enclosed are some airline company channels used in the Chicago area.
  2476. Activity can also be heard on ARINC's MAC channel.
  2477.  
  2478. Air France/aka Aeronautical Radio, company channel, transportation
  2479. [Chicago] ___________  129.0250____KFI9 (others) 
  2480. Air-Medic One, company channel, medical transportation
  2481. [location?]_________  131.1500____call? (others) 
  2482. American Airlines/aka Aeronautical Radio, company channel, aircraft
  2483. maintenance, transportation
  2484. [Chicago]___________  130.2500____KSG7      (B.  Parnass)
  2485. British Airways/aka Aeronautical Radio, company channel
  2486. [Chicago]___________  131.1000____KFB8 (others) 
  2487. Delta Airlines/aka Aeronautical Radio, company channel
  2488. [Chicago]___________  129.6000____WCD4 (others)
  2489. Eastern Airlines/aka Aeronautical Radio, company channel
  2490. [Chicago]___________  128.8500____KEB5 (others)
  2491. Jetstream/aka Aeronautical Radio, company channel, airline transportation
  2492. [Chicago]___________  128.8500____KEB5
  2493.  
  2494. -----------------------------------------------------------------------------
  2495.     New address is: PO Box 1286 Lakewood, NJ 08701 or KA2RAF@NN2Z
  2496.  
  2497.  [ Suns @10am on 7240 LSB, The ANARC Listeners' Net - DC to Light and MORE! ]
  2498.                  0435z, 1568 msgs, #13610 last @KD6TH-4 MailBox>
  2499.  
  2500. ------------------------------
  2501.  
  2502. Date: 12 Jan 90 03:20:48 GMT
  2503. From: zaphod.mps.ohio-state.edu!wuarchive!texbell!ark!lrark!argate!richard@tut.cis.ohio-state.edu  (Richard Duncan)
  2504. Subject: PBBS forwarding via dialup modem?
  2505. Message-ID: <14@argate.UUCP>
  2506.  
  2507. In article <9001100505.AA01654@nips.ssesco.com>, elmquist@NIPS.SSESCO.COM writes:
  2508. > Just wondering if any of the PBBS packages (RLI, MBL, AA4RE, etc) have any
  2509. > provisions for forwarding traffic via dialup modem?  I guess it would work
  2510. > something like UUCP.  We have a problem here in Mpls/St. Paul..in that
  2511. > most of our outside world traffic comes and goes through a connection
  2512. > called the "Gofar Hole".
  2513.  -deleted-
  2514. > Any ideas? flames?    Chris   N0JCF
  2515.  
  2516. We are using telco/uucp to forward between three systems here in the
  2517. Little Rock area.  I have written a RLI, et all, compatible PBBS on
  2518. my Xenix 286 and also interfaced into ka9q's net software.  
  2519.  
  2520. Forwarding works fine, but the actual transfer is handled by the
  2521. mail rather than the PBBS doing the actual calling.  Why worry about
  2522. functions that are already there.
  2523.  
  2524. I also have several users that use uucp mail to send and receive packet
  2525. mail through my system.  Incoming packet messages are automaticly mailed
  2526. via uucp to the destination.  Mail coming in via uucp is checked and then
  2527. flagged for the PBBS to pick it up and send out via packet.  This has
  2528. allowed several people to communicate via packet without having access.
  2529.  
  2530. Am interested in experimenting more with mail forwarding via uucp to
  2531. areas not normally covered easily by normal packet routes.
  2532. :------------------------------------------------------------------:
  2533. : Richard Duncan  WD5B           Packet:  WD5B @ WD5B.AR.USA.NA    :
  2534. : Little Rock, AR                uucp:    501/568-6809 (2400/1200) :
  2535. : UUCP:    ...!texbell!ark!lrark!argate!{richard|unetadm}          :
  2536. :------------------------------------------------------------------:
  2537.  
  2538. ------------------------------
  2539.  
  2540. Date: 11 Jan 90 22:30:35 GMT
  2541. From: att!cbnewsj!kfr@ucbvax.Berkeley.EDU  (k.redden)
  2542. Subject: PK-88 RFI problems
  2543. Message-ID: <3333@cbnewsj.ATT.COM>
  2544.  
  2545. In article <6763@jpl-devvax.JPL.NASA.GOV> jenkins@jpl-devvax.JPL.NASA.GOV (Steve Jenkins) writes:
  2546. > Hardware:     AEA PK-88, battery powered, out of warranty
  2547. > Problem:      With no cables except power connected, the PK-88
  2548. >               generates enough RF on 145.01 to open the squelch on
  2549. >               my Kenwood TH-215A (squelch set to max; duck) about
  2550. >               30 feet away.  
  2551. > Steve Jenkins N6UNI                   jenkins@jpl-devvax.jpl.nasa.gov
  2552. > Caltech/Jet Propulsion Laboratory     (818) 354-0162
  2553.  
  2554. I was talking to AEA customer service today about a different problem, and
  2555. I told them about the subject posting. Since many others may have the 
  2556. problem, I'm posting my reply so all can see.
  2557.  
  2558. AEA says the clock on the PK-88 does indeed put out a birdie on 145.01, but
  2559. they do have a mod you can make to fix the situation. The clock frequency is
  2560. controlled by C38, a 33 pF capacitor. If you change this to an 82 pF cap
  2561. (use a silver mica cap), it will lower the clock frequency enough to move
  2562. the birdie out of the packet band.
  2563.  
  2564. If you have any trouble, call Ryan at AEA customer service at 206 775-7373.
  2565.  
  2566. Good Luck,
  2567.  
  2568. Kevin Redden, WB2ZLF
  2569. AT&T Bell Labs, Lincroft NJ
  2570.  
  2571. ------------------------------
  2572.  
  2573. Date: 10 Jan 90 21:27:57 GMT
  2574. From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hpl.hp.com  (Bdale Garbee)
  2575. Subject: TAPR Annual Meeting
  2576. Message-ID: <4390110@col.hp.com>
  2577.  
  2578. From:    Andy Freeborn N0CCZ <ucsd.edu!winfree!andy>
  2579. Subject: TAPR Annual Meeting
  2580.  
  2581.  
  2582. ANNUAL TAPR MEETING - TUCSON AZ - SATURDAY AND SUNDAY - FEBRUARY 24th - 25th
  2583.  
  2584. The TAPR annual meeting will be held at the Inn At The Airport, 7060 South 
  2585. Tucson Boulevard, Tucson AZ, 85706. The Inn is a very short distance from the 
  2586. airport terminal, walking distance if you're so inclined. Special rates for 
  2587. the meeting are $49.00 for either one or two in a room. Breakfast is included 
  2588. as well as a late afternoon cocktail hour. Our room block will be released on 
  2589. February 9, 1990 so get your reservations in prior to that date. Call 1-800-
  2590. 772-3847 if outside Arizona, 602 746-0271 if in Arizona, or write the above 
  2591. address. Cite The TAPR Conference to assure rates. 
  2592.     
  2593. There will be a registration fee of $20.00. This fee will help to defray 
  2594. meeting costs plus lunch and private dinner at the hotel. Since breakfast and 
  2595. cocktail hour are provided to those staying at the hotel the overall cost is 
  2596. quite nominal. The Sunday session should be completed by noon or shortly 
  2597. thereafter for those planning return travel on Sunday afternoon. 
  2598.     
  2599. Networking, that's the packet radio buzzword for the early '90s. And that 
  2600. will be one of the main topics at the 1990 TAPR annual meeting. Equally 
  2601. exciting will be discussions by members of the Microsat team describing and 
  2602. graphically displaying the construction, pre/launch and launch activity of 
  2603. the Microsats and their UoSAT cousins. 
  2604.  
  2605. Expect to see many of the manufacturers of packet equipment present with 
  2606. displays and demos. Some have already contacted TAPR for arrangements. All 
  2607. the new TAPR kits will be shown and discussed. 
  2608.     
  2609. Those wishing to be on the speaking agenda should advise the TAPR office as 
  2610. soon as possible. The Sunday session should be concluded near or shortly 
  2611. after noontime for those planning afternoon departures. 
  2612.      
  2613.  
  2614.  
  2615. ------------------------------
  2616.  
  2617. End of PACKET-RADIO Digest V90 Issue #9
  2618. ***************************************
  2619. 12-Jan-90 22:21:51-MST,14066;000000000000
  2620. Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
  2621. Date: Fri, 12 Jan 90 22:15:38 MST
  2622. From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
  2623. Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  2624. Subject: PACKET-RADIO Digest V90 #10
  2625. To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  2626.  
  2627. PACKET-RADIO Digest         Fri, 12 Jan 90       Volume 90 : Issue   10
  2628.  
  2629. Today's Topics:
  2630.         Amateur packet radio on space shuttle
  2631.              Ham radio names and routing
  2632.               hapn card-TNC info wanted
  2633.   Making things more difficult than necessary (was: Tasco TNC info)
  2634.                packet in Poland
  2635.           PBBS forwarding via dialup modem?
  2636.                Update to NOS 900105 (2)
  2637. ----------------------------------------------------------------------
  2638.  
  2639. Date: 10 Jan 90 23:45:14 GMT
  2640. From: vsi1!wyse!mips!prls!philabs!briar.philips.com!rfc@apple.com  (Robert Casey;6282;3.57;$0201)
  2641. Subject: Amateur packet radio on space shuttle
  2642. Message-ID: <73297@philabs.Philips.Com>
  2643.  
  2644. copied from packet:
  2645.  
  2646.  Msg# TSF  Size #Rd Date/Time MsgID        From   To
  2647.  14046 BF   2493   2 0103/0437 29730_W3IWI  W3IWI  ALL@NYNET
  2648.   Sb: SAREX2 - Packet on the Space Shuttle
  2649.  
  2650. Note: Packet Radio is a computer communications mode of Amateur Radio.
  2651.  
  2652.   PACKET BID: 29730_W3IWI
  2653.  
  2654.   1990 is going to be a vintage year for amateur packet radio in space.
  2655.   This month will see the launch of the four AMSAT Microsats plus two
  2656.   UoSATS (look for @AMSAT bulletins on you local BBS). 
  2657.  
  2658.   Then in late April one of our MDC area astronauts, Ron Parise, WA4SIR
  2659.   will fly on the Shuttle Columbia in mission STS-35. Ron will be carrying
  2660.   2M packet radio hardware with him -- a modified HK-21 TNC, a Motorola HT,
  2661.   a window-mounted antenna and a Grid lap-top computer.
  2662.  
  2663.   The TNC will be carrying special software -- an updated version of the
  2664.   SAREX "Robot" that would have flown in 1986 had not the Challenger 
  2665.   disaster happened.
  2666.  
  2667.   The "Robot" software is an automatic QSO machine. You connect to the
  2668.   robot, you are given a serial number, and as soon as you ack the number,
  2669.   the Robot disconnects and enters the QSO into the log. As many as nine
  2670.   simultaneous QSOs can be going on. If the robot hears you, whether or not
  2671.   you make a full two-way QSO, that information is entered into a second
  2672.   log.
  2673.  
  2674.   You and the world know immediately if you had a QSO or were heard, because
  2675.   periodically the robot sends out beacons. A beacon addressed to QSL> lists
  2676.   the two-way QSO's and the serial number, and a beacon adddressed to QRZ>
  2677.   lists the stations heard.
  2678.  
  2679.   In addition, the robot has an additional beacon (called the Metabeacon) 
  2680.   addressed to QST> which has up to 7 frames of up to 255 characters/frame
  2681.   (i.e. about 1.7 kbytes). This is intended to serve as a longer general
  2682.   information beacon into which Ron can put mission status information.
  2683.  
  2684.   N2WX and I have worked hard this past weekend to get a "beta" version of
  2685.   the flight TNC software working, and we are ready to test it. The SAREX
  2686.   goodies are now operating from here under the call W3IWI-5 (alias SAREX)
  2687.   on 145.05 using the same radio as the 145.05 W3IWI BBS port. The QST, QSL 
  2688.   and QRZ beacons fire every 5 minutes.
  2689.  
  2690.   Please give the software a shot. Try to crash it! It is a lot better to
  2691.   it die now than in flight!
  2692.  
  2693.   73, Tom
  2694.   0450z, 1726 msgs, #14100 last @KD6TH-4 MailBox>
  2695.  
  2696. ------------------------------
  2697.  
  2698. Date: 11 Jan 90 16:47:32 GMT
  2699. From: amdahl!pacbell!tandem!kevinr@ames.arc.nasa.gov  (Kevin J. Rowett)
  2700. Subject: Ham radio names and routing
  2701. Message-ID: <1990Jan11.164732.18479@tandem.com>
  2702.  
  2703. In article <ZC-:A1@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes:
  2704. >In article <1990Jan3.171148.13647@tandem.com> kevinr@tandem (Kevin J. Rowett) writes:
  2705. >>In article <6287#.@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes:
  2706. >>>In the referenced message, John, KD7UW, writes a lot of common sense.
  2707. >>Jay, What's the "common sense" that you speak of in SOURCE ROUTING?
  2708. >>The quickest problem to point out is what happens to your traffic
  2709. >>when one of the routers in the path goes away?  And how do you discover
  2710. >>the new path?
  2711. >
  2712. >As has been pointed out here and on tcp-group, WB5BBW@HOU.TX.USA.NA is
  2713.  
  2714. I'd not seen this syntax.  Is WB5BBW a user and HOU the host? Or is
  2715. WB5BBW a host?  If so, who's the user?   
  2716.  
  2717. If HOU.TX.USA.NA is really the name of a location that will accept
  2718. mail for people living in the location named, then that's really nice to
  2719. have. Neat.
  2720.  
  2721. BUT, it's still source routing!
  2722.  
  2723. We must recognize the difference between the name of an entity and
  2724. the address of an entity.  For example kevinr@tandem.com is really only
  2725. a name, although it does have some element of source routing in it.  Consider
  2726. that it should (perhpas) be used only for traffic relating to the business
  2727. of my employer.  kevin@N6RCE is another name for the same entity, but again
  2728. has the same element of source routing in it.  I hope never to get anything
  2729. but AR related traffic there.
  2730.  
  2731. However, you'll note that in neither case, is it really necessary to
  2732. specify my geographic location by the originator of the message.
  2733. kevin@N6RCE is unique. Adding .norcal.usa.na.planetearth doesn't make it
  2734. anymore unique.
  2735.  
  2736. However, I agree it would be nice to find out a route to that location.
  2737. And the originator may have a good idea.  Dan Frnak (WN9K) had a very good
  2738. idea along these lines.  His suggested syntax is:
  2739.  
  2740. user@host [state=CA,bbs=3Yota,nettype=IP]
  2741.  
  2742. With the things in [] being optional, and the types of things similiar to
  2743. what we have now...
  2744.  
  2745. Think about some of the non-electronic mechanisms in use today that are and
  2746. aren't source-routing and how well they work.
  2747.  
  2748. The US Postal service (and UPS) is source routing. As is the phone company.
  2749. Check cashing isn't.  How would it do, if every time you gave a check to the
  2750. grocery store, you had to tell them how to find your bank to present that
  2751. check for payment.  The store's bank presents it to the Fed, who looks at the
  2752. ABA transit number and finds an adjacency to forward it in the right direction.
  2753.  
  2754.  
  2755. N6RCE
  2756.  
  2757. ------------------------------
  2758.  
  2759. Date: 11 Jan 90 13:33:05 GMT
  2760. From: mcsun!sunic!tut!kannel!junki@uunet.uu.net  (Juha Nurmela)
  2761. Subject: hapn card-TNC info wanted
  2762. Message-ID: <1187@kannel.lut.fi>
  2763.  
  2764. yana:
  2765.  
  2766.  
  2767. I have a couple of questions about the HAPN card-TNC (TNC?).
  2768.  
  2769.  
  2770. 1)      Is the software for it in public domain, and if it is,
  2771.     from where could I obtain the bits? Particularly
  2772.     sources would be appreciated. What is the postal address
  2773.     of HAPN?
  2774.  
  2775.     (I know, I'm greedy.)
  2776.  
  2777. 2)      Does the 8273 do the FCS stuff? Does it send flags (not
  2778.     just one!) after keying PTT and before actually sending
  2779.     the frame? What the "standard" TNC is supposed to do in
  2780.     this time?
  2781.  
  2782. 3)      Does hapn use the p-persistence (persistance?) scheme?
  2783.  
  2784. 4)      And finally: Is there any reason why 89 ka9q doesn't
  2785.     have hapn-support compiled to net.exe? (Of course I
  2786.     can always compile it in, but I hate to torture my PC :-).
  2787.  
  2788. That's it. I counted 10 question marks. Thanks in advance for any
  2789. advice. Happy new decade, from
  2790.  
  2791. juha nurmela, oh5nxo
  2792. junki@kannel.lut.fi     <- has nothing to do with drugs.
  2793.              (check your finnish-english dictionary)
  2794.  
  2795. ------------------------------
  2796.  
  2797. Date: 10 Jan 90 04:07:22 GMT
  2798. From: dtseng!rps@decvax.dec.com  (Robert P. Scott)
  2799. Subject: Making things more difficult than necessary (was: Tasco TNC info)
  2800. Message-ID: <7239@dtseng.UUCP>
  2801.  
  2802. RE:  Using KISS only ROM's.
  2803.  
  2804. I find the idea of throwing away functionality offensive.  It's sort of
  2805. like throwing away compatibility to save 5 cents per component; nudge,
  2806. nudge, wink, wink...
  2807.  
  2808. RE:  Kludging in both ROM's piggyback.
  2809.  
  2810. I don't mind voiding the "90-day-but-that-doesn't-include-software" paper.
  2811. And I have to admit that I didn't go look at the schematics, but.
  2812. The described method may also cause design rule violations; fan-out for one.  
  2813. Yeah, yeah, it's picky but a 1->n ROM piggyback board would seem to be a better
  2814. answer.  (Actually, throwing the whole thing out and starting over sounds
  2815. like more fun.  All I have to do is find some company to foot the bill.  heh,
  2816. heh, heh...)
  2817.  
  2818.  
  2819. -- 
  2820. Robert P. Scott | DTS Engineering, Inc. | {decvax,zinn}!dtseng!rps
  2821. Nothing could be finer than some green wallet liner....
  2822.  
  2823. ------------------------------
  2824.  
  2825. Date: 10 Jan 90 23:41:45 GMT
  2826. From: vsi1!wyse!mips!prls!philabs!briar.philips.com!rfc@apple.com  (Robert Casey;6282;3.57;$0201)
  2827. Subject: packet in Poland
  2828. Message-ID: <73296@philabs.Philips.Com>
  2829.  
  2830. copied from packet:
  2831.  
  2832.  Msg# TSF  Size #Rd Date/Time MsgID        From   To
  2833.  13306 BF   1149   2 1222/1914 3343_SK6SA   SP9VU  POLAND@NYNET
  2834.   Sb: Poland packet start
  2835.   PACKET BID: 3343_SK6SA
  2836.  
  2837.   [ the following arrived a bit garbled at W3IWI and has been edited to make
  2838.     it more readible ]
  2839.  
  2840.     In SP efforts of the polish packet radio initiative group have brought
  2841.     long desired result.
  2842.  
  2843.     Special licences have been issued to 7 hams- 
  2844.     SP5DED  SP4LVG SP9VU SP5ALV  SP5GTJ  SP3CAI AND SP4KM. 
  2845.     Operation will start 24.DEC.89. After an experimental period further
  2846.     permits 
  2847.     are expected. Cu on packet.  Lucjan SP9VU
  2848.     --- GXQ v3.52b
  2849.     1504z, 1531 msgs, #13341 last @KD6TH-4 MailBox>
  2850.  
  2851. ------------------------------
  2852.  
  2853. Date: 11 Jan 90 08:13:52 GMT
  2854. From: mcsun!ukc!axion!news@uunet.uu.net  (Brian Lloyd)
  2855. Subject: PBBS forwarding via dialup modem?
  2856. Message-ID: <1990Jan11.081352.9247@axion.bt.co.uk>
  2857.  
  2858. From article <9001100505.AA01654@nips.ssesco.com>, by elmquist@NIPS.SSESCO.COM:
  2859. > Just wondering if any of the PBBS packages (RLI, MBL, AA4RE, etc) have any
  2860. > provisions for forwarding traffic via dialup modem? 
  2861.  
  2862. Two BBSs in the UK which are a long way apart and have no good route
  2863. between them export their mail to a separate directory, where a small
  2864. telephone BBS program can get at it. The mail is then forwarded over the
  2865. phone by the other program, and imported back by the PBBS at the other end.
  2866. As far as I know this works well, and avoids the need for telephone modem
  2867. support in the PBBS program which most people probably won't need.
  2868.  
  2869. > Any ideas? flames?    Chris   N0JCF
  2870.  
  2871.     Brian G1NNA
  2872.  
  2873. ###########################################################################
  2874. Brian Lloyd,                           # Via e-mail : blloyd@axion.bt.co.uk
  2875. RT3152, Rm G44, SSTF,                  # Via Packet : G1NNA @ GB7NNA.GBR.EU
  2876. British Telecom Research Labs,         # By Phone   : +44 (0)473 646650
  2877. Martlesham Heath, Ipswich, Suffolk. IP5 7RE
  2878.  
  2879. ------------------------------
  2880.  
  2881. Date: 10 Jan 90 14:53:19 GMT
  2882. From: zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!wb3ffv!gvdgpc!gvdg@tut.cis.ohio-state.edu  (Gerard J van der Grinten PA0GRI)
  2883. Subject: Update to NOS 900105 (2)
  2884. Message-ID: <293@gvdgpc.UUCP>
  2885.  
  2886. This version is a combination of Phil's work, from Russell Nelson and PA0GRI.
  2887. Phils mods include tracin into a file (trace interface tracelevel [file])
  2888. If file is not given output is redirected to the screen.
  2889. From Russell Nelson are his mods as contained in diffs.arc.
  2890. They include:
  2891. a)
  2892. Arcnet support where arcnet uses the packet driver interface.
  2893. b)
  2894. The fcntl control call and command.asm mods. This makes NOS run through when
  2895. shell escaping to DOS as a tsr. (no smtp hangs anymore. Even trace goes on)
  2896. c)
  2897. Interprosess comunication via int 0x2f (for rlogin client)
  2898. d)
  2899. Logging of MKDir and RMDir commands.
  2900. e)
  2901. If you have a anonymous account in your ftpusers file any user name will be
  2902. accepted and mapped into the anonymous account. (seems not "everybody" knows
  2903. anonymous account, In europe guest is used in net/nos often)
  2904. f)
  2905. The JOINed disk (if used) is found and statused if a dir is done on the joined
  2906. drive.
  2907. g)
  2908. Multiple directorys can be accessed on the same level. Normaly there is a 
  2909. root directory. In ftpusers it is like "anonymous * /dir1;/dir2 1"
  2910. (directorys are separated by ; and no "white space" is alowed.
  2911. h)
  2912. A net.rc (aka .netrc) file is supported for ftp access to other machines.
  2913. This auto logins you to the destined machine.
  2914. Format is "system username password" . Note that it all is clear text.
  2915. net.rc lives in the root directory.
  2916. i)
  2917. I did not find the rlogin client so that is not added but some hooks are
  2918. in place.
  2919. j)
  2920. Tar backup feature! If you specify 'recv direct/tar/*.* than all files
  2921. in direct are tarred into one destination file. This is great to backup
  2922. a single directory into (onto) another system. I did not encounter speed
  2923. degradation in backing up my NOS directory onto my UNIX system via ethernet.
  2924. On a destination /tar/ read it should expand the tar file again.
  2925. a)
  2926. From PA0GRI the domain mods are included. (domain 3.2)
  2927. b)
  2928. autoexec.net is called autoexec.nos to make a difference on people using
  2929. both NET and NOS and dont want to switch between configuration files.
  2930. c)
  2931. A message is given when the default autoexec file is not found.
  2932. d)
  2933. domain search during autoexec startup is limited to the local machine.
  2934. e)
  2935. A domain server (series) is tried 4 times before giving up. If a server went
  2936. down the probe to it was infinite and the system unusable due to lockup.
  2937. (symptom: if typed "route add unknown ax0" the search went on infinite and
  2938. only a reboot would give back a promt (whatever type).
  2939.  
  2940. I uploaded nosadd.arc and nosgri30.exe to flash.bellcore.com in the files
  2941. /pub/nosadd.arc and /pub/nosgri30.exe . nosadd.arc contains all changed files
  2942. against nosv30tc.arc (phil's nos.arc 900105)
  2943. Also on wb3ffv and gvdgpc bbs systems both files are uploaded.
  2944. Note: nosv30 is phil's 900105 release.
  2945. Regards. gerard.
  2946. (on the nosadd.arc file trace.h and iface.h were missing, sorry.
  2947.  They are present now)
  2948. (sorry for the mis-spelling of Russell Nelson's name.)
  2949.  
  2950. ------------------------------
  2951.  
  2952. End of PACKET-RADIO Digest V90 Issue #10
  2953. ****************************************
  2954. 13-Jan-90 14:24:43-MST,14903;000000000000
  2955. Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
  2956. Date: Sat, 13 Jan 90 14:15:38 MST
  2957. From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
  2958. Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  2959. Subject: PACKET-RADIO Digest V90 #11
  2960. To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  2961.  
  2962. PACKET-RADIO Digest         Sat, 13 Jan 90       Volume 90 : Issue   11
  2963.  
  2964. Today's Topics:
  2965.         [rec.ham-radio.packet] G8BPQ software
  2966.          A location is not a route. (2 msgs)
  2967.             ka9q tcp/ip amiga ???
  2968.   Making things more difficult than necessary (was: Tasco TNC info)
  2969.           PBBS forwarding via dialup modem? (2 msgs)
  2970. ----------------------------------------------------------------------
  2971.  
  2972. Date: 11 Jan 90 03:44:07 GMT
  2973. From: zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!zardoz!stanton!donegan@tut.cis.ohio-state.edu  (Steven P. Donegan)
  2974. Subject: [rec.ham-radio.packet] G8BPQ software
  2975. Message-ID: <3868@stanton.UUCP>
  2976.  
  2977. In article <10557@stag.math.lsa.umich.edu>, barry@dgbt.uucp (Barry McLarnon DGBT/DIP) writes:
  2978. > >   Also, any ideas when the software will be available on ROM?
  2979. For this, and any other software that is ROMable, I would be happy to arrange
  2980. for a burning for you. I can erase and program EPROMs of just about any size
  2981. and will do so for the price of 1$ per ROM if you supply the EPROM and postage
  2982. in both directions. This applies to software which has the author's permission
  2983. to be ROMd only of course. Since this is such a low fee I hope it will not
  2984. engender any flames about commercialism(I don't think I'll be able to make
  2985. any profit on this in other words). If you object to this blatant profiteering
  2986. keep your comments to yourself :-)
  2987. -- 
  2988. Steven P. Donegan (stanton!donegan)   (714)-863-7998; Voice Mail
  2989. Area Telecommunications Engineer      (714)-894-2246; uucp(300-2400)
  2990. Corporate Telecommunications Services (714)-897-3621; uucp(300-19200 PEP)
  2991. Western Digital Corporation                           ogin: nuucp word: \r
  2992. The opinions expressed here are mine, not Western Digital's.
  2993.  
  2994. ------------------------------
  2995.  
  2996. Date: 13 Jan 90 02:09:02 GMT
  2997. From: dsl.pitt.edu!pitt!w2xo!durham@pt.cs.cmu.edu  (Jim Durham)
  2998. Subject: A location is not a route.
  2999. Message-ID: <120@w2xo.UUCP>
  3000.  
  3001. In article <1190Jan11.170203.18601@tandem.com> kevin@tandem.com (Kevin J.
  3002.  Rowett) writes:
  3003. > In article <119@w2xo.UUCP> durham@w2xo.UUCP (Jim Durham) writes:
  3004. > >W0RLI Writes:
  3005. > >
  3006. > >> Note that the "BBS net" addresses are not routes, but locations.
  3007. > >> Routing takes place at the individual servers, and can be based
  3008. > >> on any of the location information, or on the addresses.
  3009. > >> OR.USA.NA  is a location, and does not say anything about
  3010. > >> how one could GET there, but just where it is located.
  3011. > >> 
  3012. > >>    ...  Hank  - w0rli
  3013. > >
  3014. > >I think Hank hit the nail on the head. I have been wondering how one
  3015. > >could apply the term "source routing" to the W6XXX.CA.US.NA type
  3016. > >scheme. A "source routing", scheme as I understand it, is to specify
  3017. > >the entire path , as is done on Usenet (foobar!nerdley!fonzy!..etc).
  3018. > If isn't W6XXX.ca.us.na source routing, then W6XXX should be sufficent,
  3019. > right?  Source routing is defined as the originator describing the
  3020. > path to reach a location.
  3021. > In the about case, we've tried to "qualify" the name with a path
  3022. > as well.  Yes, I know some would argue that .ca.us.na is a "location",
  3023. > but how does a location differ from an "address"?
  3024.   In thinking about this "location" business further, I remain convinced
  3025. that is is not "source routing", as a *path* must be specified for true
  3026. "source routing". However, on further relection, I *do* see a problem
  3027. which could be best expressed as a violation of the principle of
  3028. "letting the *network* do the *work*".
  3029.  
  3030.   I think what a lot of people are saying is that the *user* should only
  3031. have to know the *name* of the entity receiving mail. If W6XXX.NOCAL.USA.NA
  3032. suddenly moves to *Maine*, what becomes of mail addressed to the above
  3033. address/location ? If the mail were addressed only to W6XXX, it would only
  3034. be necessary for the nameservers of the network to be re-educated by
  3035. some routing exchange protocol in order for the mail to be correctly
  3036. delivered. The user would not need to know of the change.
  3037.  
  3038. > >
  3039. > >The ham packet network is not a network in the same sense as the
  3040. > >Internet. It is a "bucket brigade". The decision that needs to be
  3041.  
  3042.     (stuff deleted)...
  3043. > I agree at the present data rates and physical layer protocols,
  3044. > connectivity isn't the best, but a number of Hams are working to radically
  3045. > alter that situation.  WHEN that comes about, the nameserver idea will
  3046. > be practical, and the benefits will be obvious.
  3047.   What we really need to weigh carefully is that in using the "location"
  3048. scheme, we are really putting the onus on the user to make up for
  3049. inadequacies in the network. Is this a case of pragmatism, or is it
  3050. a case of a quick and dirty fix ? I want to think about this some more!
  3051.  
  3052. > N6RCE
  3053.  
  3054. -73
  3055. Jim, W2XO
  3056.  
  3057. ------------------------------
  3058.  
  3059. Date: 13 Jan 90 14:01:58 GMT
  3060. From: brian@ucsd.edu  (Brian Kantor)
  3061. Subject: A location is not a route.
  3062. Message-ID: <11033@ucsd.Edu>
  3063.  
  3064. W6ABC@W6ZZZ.SAN.CA.USA is *** NOT *** a source route.  It is a
  3065. hostname/address ("W6ZZZ") with appended routing hints ("SAN.CA.USA")
  3066. which the systems forwarding the message are free to disregard.
  3067.  
  3068. The entire problem, in my opinion, is that the string on the right hand
  3069. side of the "@" looks like an internet domain address and is therefore
  3070. confusing.  The idea, method, and semantics of the W0RLI addresses are
  3071. not a problem.  It is just their appearance.
  3072.  
  3073. Someone (Dan Frank?) has suggested altering this to a more X.400-style
  3074. of address, something like
  3075.     W6ABC@W6ZZZ{city=SAN,state=CA,country=USA}
  3076. which preserves PRECISELY the same meaning as the current W0RLI address
  3077. string.  I have a problem with the verbosity of such an address but the
  3078. idea is good.  It has the great advantage that parts of a location
  3079. (=routing hint) string can be omitted and the rest still parsed quite
  3080. easily.  (As in X.400, the "city", "state", etc can be abbreviated so
  3081. that you don't have type the whole thing.
  3082.  
  3083. It would also cause a considerable ripple in the network were we to
  3084. convert to Dan's scheme, although the W0RLI BBS software could be
  3085. modified to accept either but only emit the {} version, which would
  3086. ease the pain of transition.  I think it would be an ideal solution for
  3087. a network such as the W0RLI BBSs which are hosted on machines too small
  3088. to contain a complete routing table for the entire network - and for
  3089. which no method exists for disseminating such a routing table even if
  3090. one existed.
  3091.  
  3092. In the short term, perhaps it would be better to replace either the
  3093. first or all of the dots (".") in the W0RLI address string with some
  3094. other character - for example, a virgule ("/").  A W0RLI-to-internet mail
  3095. gateway could easily parse on that and separate the routing hints from
  3096. the hostname quite easily.  I can even envision such building a routing
  3097. table from observed BBS traffic, much as Dave Mills suggested in his
  3098. "wiretap" routing paper a few years ago.  Such a routing table would be
  3099. of great use in going the opposite way in an internet-to-W0RLI mail gateway.
  3100.     - Brian
  3101.  
  3102. ------------------------------
  3103.  
  3104. Date: 13 Jan 90 18:29:23 GMT
  3105. From: zaphod.mps.ohio-state.edu!usc!samsung!aplcen!haven!sayshell.umd.edu!louie@tut.cis.ohio-state.edu  (Louis A. Mamakos)
  3106. Subject: ka9q tcp/ip amiga ???
  3107. Message-ID: <1990Jan13.182923.16875@haven.umd.edu>
  3108.  
  3109. A version of the KA9Q TCP/IP code is available for anonymous FTP from
  3110. SAYSHELL.UMD.EDU.  It is a port of the the NOS 890830 version; as I
  3111. speak, er, type, I'm doing a port of the NOS 900105 version, which
  3112. should also be available soon.  Look for a file in /pub directory
  3113. called amiganos.zoo.
  3114.  
  3115. This is not a "production" release of the KA9Q code.  The code base
  3116. that I am porting from has not yet been released either, and no
  3117. documentation has been prepared.  I am more interested in having
  3118. people *test* it, rather than use it as production quality software.
  3119. Idealy, you should already have some expierence with the NOS code.
  3120.  
  3121. The distribution is in ZOO format, and includes all the sources
  3122. necessary to build it.  You will need Lattice C 5.04 to compile it,
  3123. and a system with a hard disk.  On my system (A2000, 1M memory, A2090
  3124. controller, medium speed 30MB hard disk), it takes a little over an
  3125. hour to compile and link all of the modules.
  3126.  
  3127. Before anyone asks, no, I can't mail copies of this to people.  If you
  3128. can't FTP it, you're out of luck.  The "release" version will likely
  3129. appear on a Fish Disk and probably also be available from TAPR, along
  3130. with the PC version.  Don't look for the release version for the Amiga
  3131. until after the PC/MSDOS version since that's the porting base.
  3132.  
  3133. louie WA3YMH
  3134.  
  3135. ------------------------------
  3136.  
  3137. Date: 11 Jan 90 18:28:04 GMT
  3138. From: mitel!sce!cognos!dgbt!barry@uunet.uu.net  (Barry McLarnon DGBT/DIP)
  3139. Subject: Making things more difficult than necessary (was: Tasco TNC info)
  3140. Message-ID: <1348@dgbt.uucp>
  3141.  
  3142. From article <4390109@col.hp.com>, by bdale@col.hp.com (Bdale Garbee):
  3143. >>Or, yet another possibility: To avoid messy soldering (on the EPROM, at
  3144. >>least), obtain a 27C512 and copy your original ROM into one half of the
  3145. >>64K address space, and KISS into the other half.  Then use the switch as
  3146. >>a ROM select by changing the state of the A14 line.
  3147. > Le Huh?
  3148. > The KISS for the u21 that I made available is a copy of all the functionality
  3149. > provided in the standard firmware, plus KISS ala the TAPR 1.1.6 w/KISS EPROM.
  3150. > It is *not* KISS-only, and as such, there's no need for piggybacking, or
  3151. > anything!
  3152.  
  3153. Huh yourself.  In spite of the Subject line, this thread diverged some time
  3154. ago into a discussion of alternate firmwares for the generic TNC-2.  The issue
  3155. is that the KISS in the combined firmware like 1.1.6 and variants sometimes
  3156. gives problems, viz: popping out of KISS mode, not responding to 'param ax0
  3157. 255', etc.  Hardware switching of modes adds a degree of robustness, when
  3158. there is a KISS-only implementation.  Another consideration is that there are
  3159. some KISS-only variants, such as JKISS by G8BPQ, which appear to have some
  3160. improvements over the standard K3MC release, and piggybacking gives you a
  3161. way of trying them out.
  3162.  
  3163. > Bdale
  3164.  
  3165. Barry
  3166. -- 
  3167. Barry McLarnon    Communications Research Center    Ottawa, ON   Canada
  3168. UUCP: ...utzoo!dciem!nrcaer!dgbt!barry  INTERNET: barry@dgbt.crc.dnd.ca
  3169. CI$: 71470,3651    PBBS: VE3JF@VE3JF    AMPRnet: barry@bbs.ve3jf [44.135.96.6]
  3170.  
  3171. ------------------------------
  3172.  
  3173. Date: 13 Jan 90 02:55:29 GMT
  3174. From: dsl.pitt.edu!pitt!w2xo!durham@pt.cs.cmu.edu  (Jim Durham)
  3175. Subject: PBBS forwarding via dialup modem?
  3176. Message-ID: <121@w2xo.UUCP>
  3177.  
  3178. > In article <9001100505.AA01654@nips.ssesco.com>, elmquist@NIPS.SSESCO.COM writes:
  3179. > > Just wondering if any of the PBBS packages (RLI, MBL, AA4RE, etc) have any
  3180. > > provisions for forwarding traffic via dialup modem?  I guess it would work
  3181. >  -deleted-
  3182. > > 
  3183. > > Any ideas? flames?    Chris   N0JCF
  3184. > We are using telco/uucp to forward between three systems here in the
  3185. > Little Rock area.  I have written a RLI, et all, compatible PBBS on
  3186. > my Xenix 286 and also interfaced into ka9q's net software.  
  3187. > Forwarding works fine, but the actual transfer is handled by the
  3188. > mail rather than the PBBS doing the actual calling.  Why worry about
  3189. > I also have several users that use uucp mail to send and receive packet
  3190. > mail through my system.  Incoming packet messages are automaticly mailed
  3191.   (stuff deleted) 
  3192. > Am interested in experimenting more with mail forwarding via uucp to
  3193. > : Richard Duncan  WD5B           Packet:  WD5B @ WD5B.AR.USA.NA    :
  3194.  
  3195. I also am running my own PBBS code under Unix SYSV. I am running KA9Q
  3196. as an AX25, Net/Rom and TCP/IP "front end" for my PBBS. The PBBS is
  3197. simply an ordinary Unix Process which can be run from either KA9Q,
  3198. a local terminal or from the telephone modem. In the "local mode", you
  3199. simply run the bbs program as you would any program.. ie; "xobbs w2xo"
  3200. would bring up the bbs and identify the user's call. Another system
  3201. could call in, bring up the bbs with it's call, and send mail just
  3202. as if it were logged in "over the air". By sending the usual "F>" at
  3203. the end of the session, reverse forwarding would be initiated and
  3204. all mail for the calling bbs would be sent. Of course, the usual Unix
  3205. login: and password: gauntlet would have to be passed to get to the
  3206. Unix command prompt initially. I have not written anything to initiate
  3207. telephone forwarding, as I really hadn't thought of doing this until
  3208. I saw N0JCF's article, but it should be pretty straight-forward to
  3209. write an litte "daemon" process to do telephone forwarding inititation.
  3210.  
  3211. IMHO, it would be a lot easier to do what you want, Chris, with
  3212. Unix or Xenix than with DOS, if only so that your system could
  3213. answer the phone any time a call came in from another system. This
  3214. would be tough to do without multi-tasking, at least.
  3215.  
  3216. Incidentally, I also have a UUCP to PBBS mail gateway in both directions
  3217. operating as well as a Usenet News function in the PBBS.
  3218.  
  3219. I am interested in hearing of anyone else who is doing work
  3220. with Unix or Xenix based PBBS systems.
  3221.  
  3222. -73
  3223. Jim, W2XO   (W2XO @ W2XO)
  3224.  
  3225. ------------------------------
  3226.  
  3227. Date: 11 Jan 90 18:56:55 GMT
  3228. From: mcsun!ukc!axion!vision!davel@uunet.uu.net  (Dave Lockwood)
  3229. Subject: PBBS forwarding via dialup modem?
  3230. Message-ID: <867@vision.UUCP>
  3231.  
  3232. In article <9001100505.AA01654@nips.ssesco.com> elmquist@NIPS.SSESCO.COM writes:
  3233. >Just wondering if any of the PBBS packages (RLI, MBL, AA4RE, etc) have any
  3234. >provisions for forwarding traffic via dialup modem?
  3235.  
  3236. W0RLI claims to have it (10.3 was the last I saw) and AA4RE again. Of the two,
  3237. I'd prefer the latter from what I've seen (I ran a PBBS for a couple of
  3238. years :-).
  3239.  
  3240. Incidentally, whatever happened to WA7MBL?
  3241.  
  3242. -- 
  3243. --------------------------------------------------------------------------------
  3244.  * I I               Dave Lockwood                 These opinions are shareware.
  3245.  * II             Technical Consultant             If you like them, send $10...
  3246.  * I *   *
  3247.  *  **  *          davel@vision.UUCP               VisionWare Ltd,
  3248.  * * * *   ...!uunet!mcsun!ukc!vision!davel        Leeds Business Park,
  3249.  **  **           +44-532-522020 X2439             Leeds, LS27 0JG,
  3250.  *   *                                             United Kingdom
  3251. VISIONWARE DOS/UNIX Integration
  3252. --------------------------------------------------------------------------------
  3253.  
  3254. ------------------------------
  3255.  
  3256. End of PACKET-RADIO Digest V90 Issue #11
  3257. ****************************************
  3258. 14-Jan-90 12:19:45-MST,10171;000000000000
  3259. Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
  3260. Date: Sun, 14 Jan 90 12:15:47 MST
  3261. From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
  3262. Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  3263. Subject: PACKET-RADIO Digest V90 #12
  3264. To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  3265.  
  3266. PACKET-RADIO Digest         Sun, 14 Jan 90       Volume 90 : Issue   12
  3267.  
  3268. Today's Topics:
  3269.               hapn card-TNC info wanted
  3270.            Looking for Latest WA7MBL PBBS Software
  3271.           PBBS forwarding via dialup modem?
  3272.                Radar-detector detector
  3273.             Radar detectors on 3cm
  3274.               Removal of R: lines needed
  3275.                Routes, Names, Locations
  3276.              WA4DSY Duplex Repeater Info
  3277. ----------------------------------------------------------------------
  3278.  
  3279. Date: 13 Jan 90 01:46:13 GMT
  3280. From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hpl.hp.com  (Bdale Garbee)
  3281. Subject: hapn card-TNC info wanted
  3282. Message-ID: <4390113@col.hp.com>
  3283.  
  3284. >4)     And finally: Is there any reason why 89 ka9q doesn't
  3285. >       have hapn-support compiled to net.exe? (Of course I
  3286. >       can always compile it in, but I hate to torture my PC :-).
  3287.  
  3288. Simple.  When I compiled in all of the drivers that were available, the binary
  3289. got to be *very* large.  Since the HAPN (and other) cards are not so popular,
  3290. it seemed like a good tradeoff to compile in the minimum set that most folks
  3291. would want, and leave the rest available to anyone willing to recompile...
  3292.  
  3293. Particularly given that one person in an area can do the recompile and share
  3294. the binary with friends, this seemed like a good idea.
  3295.  
  3296. Bdale, N3EUA
  3297.  
  3298. ------------------------------
  3299.  
  3300. Date: 13 Jan 90 20:07:11 GMT
  3301. From: hp-pcd!hpspkla!dubner@hplabs.hpl.hp.com  (Joseph L. Dubner)
  3302. Subject: Looking for Latest WA7MBL PBBS Software
  3303. Message-ID: <4640001@hpspkla.spk.hp.com>
  3304.  
  3305. A local ham packet BBS SysOp (AH6AA) is running the WA7MBL verison 5.12
  3306. PBBS software and asked me to try to find version 5.13 for him.  Is this
  3307. version available?  Can anyone give me a pointer to it in an E-mailable or
  3308. ftp-able form?
  3309.  
  3310. Thanks and 73,
  3311. Joe, K7JD
  3312.  
  3313.  
  3314. --------------------------------------------------------------------
  3315. Joe Dubner  K7JD  |  H-P Spokane Division   |  dubner@hpspkla.HP.COM
  3316.           |  Spokane, WA  99220     |  (509) 921-3514
  3317. --------------------------------------------------------------------
  3318.  
  3319. ------------------------------
  3320.  
  3321. Date: 13 Jan 90 01:44:13 GMT
  3322. From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hpl.hp.com  (Bdale Garbee)
  3323. Subject: PBBS forwarding via dialup modem?
  3324. Message-ID: <4390112@col.hp.com>
  3325.  
  3326. This is done a lot in Japan... mostly with IP nodes, by periodically dialing
  3327. up a slip link, and doing an 'smtp kick'.  The timer functionality added to
  3328. NET in Japan makes this pretty automatable.
  3329.  
  3330. Bdale
  3331.  
  3332. ------------------------------
  3333.  
  3334. Date: 13 Jan 90 19:33:36 GMT
  3335. From: usc!cs.utexas.edu!natinst!rpp386!puzzle!khijol!erc@ucsd.edu  (Edwin R. Carp)
  3336. Subject: Radar-detector detector
  3337. Message-ID: <1011@khijol.UUCP>
  3338.  
  3339. In article <22286@usc.edu> kjh@pollux.usc.edu (Kenneth J. Hendrickson N8DGN) writes:
  3340.  
  3341. >I wonder if amateur radio operators are exempt from this foolishness?  I
  3342. >am active on the 3 cm band, and I do in fact use modified radar
  3343. >detectors.  I use them both for test equipment and communications
  3344. >transcievers.  Ontario may loose my tourist dollars with their little
  3345. >ploy.
  3346.  
  3347. Would you post details?  Sounds interesting for point-to-point high-speed
  3348. packet, control links, etc. for next to nothing!
  3349. -- 
  3350. Ed Carp                 N7EKG/5 (28.3-28.5)     uunet!cs.utexas.edu!khijol!erc
  3351. Austin, Texas           (512) 832-5884          "Good tea.  Nice house." - Worf
  3352.  
  3353. ------------------------------
  3354.  
  3355. Date: 14 Jan 90 05:31:34 GMT
  3356. From: zaphod.mps.ohio-state.edu!usc!pollux.usc.edu!khendric@tut.cis.ohio-state.edu  (Kenneth J. Hendrickson N8DGN)
  3357. Subject: Radar detectors on 3cm
  3358. Message-ID: <22304@usc.edu>
  3359.  
  3360. In article <1011@khijol.UUCP> erc@khijol.UUCP (Edwin R. Carp) writes:
  3361. >>I wonder if amateur radio operators are exempt from this foolishness?  I
  3362. >>am active on the 3 cm band, and I do in fact use modified radar
  3363. >>detectors.  I use them both for test equipment and communications
  3364. >>transcievers.
  3365. >Would you post details?  Sounds interesting for point-to-point high-speed
  3366. >packet, control links, etc. for next to nothing!
  3367.  
  3368. Move the cavity down into the amateur band by changing the setting on
  3369. the tuning screw that protrudes into the cavity.  An exsiting rig with
  3370. an IF strip tuned to a known frequency (or tunable) is useful here.
  3371. Remove any wires going to the Gunn diode, and replace them with a
  3372. regulated power supply capable of being modulated.  Modulating the power
  3373. supply voltage to the Gunn diode will both AM and FM the Gunn diode.
  3374. Hook up an IF strip (perhaps with preamplifiers) to the mixer diode in
  3375. the cavity.  Add a good antenna, get a friend on 3cm, point it at him,
  3376. and QSO.  Wideband FM is exceptionally easy to get going, and provides
  3377. very reasonable performance.
  3378.  
  3379. ------------------------------
  3380.  
  3381. Date: 14 Jan 90 16:30:36 GMT
  3382. From: zaphod.mps.ohio-state.edu!wuarchive!swbatl!texbell!ark!lrark!argate!richard@tut.cis.ohio-state.edu  (Richard Duncan)
  3383. Subject: Removal of R: lines needed
  3384. Message-ID: <15@argate.UUCP>
  3385.  
  3386. This is addressed directly to PBBS writers particularly and users
  3387. in general.  Is the requirement still there for each PBBS to add
  3388. a message received line (R:)?
  3389.  
  3390. While I am not proposing the elimination of being able to trace
  3391. a message, I am concerned about the amount of network time this
  3392. information is taking.  We have all seen mail with 20+ lines of
  3393. R:'s and only 5 lines of text.  There has been a lot of concern
  3394. about routing, but little addressing of the problem once a route
  3395. is established - getting it there.
  3396.  
  3397. I just took a quick look (using wc and grep) of 383 messages here
  3398. on my system.  The 383 messages had 11167 lines of text.  Of those
  3399. 11167 lines, 3754 lines were R: tracings.  That is 33%.  This is
  3400. not completely accurate as this assumes all lines are the same
  3401. length, which they are not.  I would venture to guess that the
  3402. average actual text lines are SHORTER than the R: lines, thus
  3403. making the percentage of required transmit time higher.
  3404.  
  3405. Don't you think this is too much?  I, again, can envision the need
  3406. for tracing, but a simple callsign would suffice as in reading a
  3407. message.
  3408.  
  3409. Is the full R: line really required for anything other than ego?
  3410.  
  3411. Is reducing to a single string of calls not sufficient to start
  3412. a trace if required?
  3413.  
  3414. Would it not be nice to have 33% (plus or minus) more time available
  3415. for getting actual text across?
  3416.  
  3417. :------------------------------------------------------------------:
  3418. : Richard Duncan  WD5B           Packet:  WD5B @ WD5B.AR.USA.NA    :
  3419. : Little Rock, AR                BBS:     501/568-6809 (2400/1200) :
  3420. : UUCP:    ...!texbell!ark!lrark!argate!{richard|unetadm}          :
  3421. :------------------------------------------------------------------:
  3422.  
  3423. ------------------------------
  3424.  
  3425. Date: 13 Jan 90 01:17:53 GMT
  3426. From: zephyr.ens.tek.com!tektronix!sequent!mntgfx!hanko@uunet.uu.net  (Hank Oredson @ APD x1325)
  3427. Subject: Routes, Names, Locations
  3428. Message-ID: <1990Jan13.011753.927@mentor.com>
  3429.  
  3430.   Thought some of this had already been stomped out,
  3431.   but I see by the recent comments from n6rce that
  3432.   it has not.  To take the specific example:
  3433.   W6XXX.ca.us.na  ..  which should actually be
  3434.   W6XXX.CA.USA.NA
  3435.   The ONLY thing the originator supplies is the
  3436.   W6XXX
  3437.   The software, using the cached information from
  3438.   the global name server, automatically appends
  3439.   .CA.USA.NA
  3440.   which indeed is a LOCATION, which is USED as if
  3441.   it were ROUTING HINTS.
  3442.  
  3443.   There ain't no source routing going on here folks.
  3444.  
  3445.   Of course, the system is flexible.  One COULD supply
  3446.   the whole thing as the originator.\
  3447.  
  3448.   "But wait, there's more!"
  3449.  
  3450.   The originator probably did NOT supply even the W6XXX.
  3451.   He probably only supplied the destination USER callsign,
  3452.   N6ZZZ, and allowed the software to look up that users
  3453.   host (W6XXX), and that hosts location (CA.USA.NA).
  3454.  
  3455.   Since we have unique personal addresses, all of this
  3456.   is possible (now, working), with much more to come later.
  3457.  
  3458.   "But wait, there's more!"
  3459.  
  3460.   Once we have such a database (and we have it, NOW),
  3461.   we could choose to store other things in it.  We do.
  3462.   We store QTH, zip code, handle, and information relating
  3463.   to the management of the data.  Why not store other things?
  3464.   Simple: no one has asked.  We COULD store the users IP
  3465.   address, for example, and thus be able to look up user 
  3466.   given address or address given user, etc.
  3467.  
  3468.   The system works.  The system is in phase 3 of a 5 phase
  3469.   development process.  The system supports over 10,000
  3470.   hosts, and over 75,000 users.  The system runs in over
  3471.   100 countries.  The system beats the US post office to
  3472.   all 50 states. Gee ... it ain't perfect.  Got a better one?
  3473.  
  3474.    ...  Hank - w0rli
  3475.  
  3476. ------------------------------
  3477.  
  3478. Date: 13 Jan 90 01:43:02 GMT
  3479. From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hpl.hp.com  (Bdale Garbee)
  3480. Subject: WA4DSY Duplex Repeater Info
  3481. Message-ID: <4390111@col.hp.com>
  3482.  
  3483. >The advantage to our design is that we
  3484. >"siphon off" the bits after demodulation so we can feed them to our IP
  3485. >router/gateway/nameserver/network wonder object thereby allowing us to
  3486. >have a node at our repeater site without investing in another DSY modem.
  3487.  
  3488. This is a big win for a lot of sites, but it's worth pointing out that it's
  3489. not uncommon for the best location for the switch to be in a different place
  3490. than the best location for the local repeater...
  3491.  
  3492. >All the rest of it is pretty much off the shelf..
  3493.  
  3494. What are you guys using for the up and down converters?  We're talking about
  3495. building something nearly identical here in Colorado Springs, and I'm 
  3496. interested in your choice of RF pieces.
  3497.  
  3498. Bdale
  3499.  
  3500. ps:  Barry, thanks for the schemo... it arrived fine.
  3501.  
  3502. ------------------------------
  3503.  
  3504. End of PACKET-RADIO Digest V90 Issue #12
  3505. ****************************************
  3506. 16-Jan-90 21:33:15-MST,10815;000000000000
  3507. Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
  3508. Date: Tue, 16 Jan 90 21:15:11 MST
  3509. From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
  3510. Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  3511. Subject: PACKET-RADIO Digest V90 #13
  3512. To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  3513.  
  3514. PACKET-RADIO Digest         Tue, 16 Jan 90       Volume 90 : Issue   13
  3515.  
  3516. Today's Topics:
  3517.               A location is not a route
  3518.          BBS Source code & KISS specification needed
  3519.              G1NNA code via FTP?
  3520.              Mailbox source code
  3521.   Making things more difficult than necessary (was: Tasco TNC info)
  3522.              More DSY Modem Info
  3523.           New newsgroup rec.ham-radio.amsat?
  3524.               PK-88 RFI problems
  3525.               pk232 fax program.
  3526.              Re: Radar-detector detector
  3527.           Unix/KA9Q pty support for outgoing telnet
  3528. ----------------------------------------------------------------------
  3529.  
  3530. Date: Mon, 15 Jan 90 18:36:53 PST
  3531. From: "Roy Engehausen" <ENGE@IBM.COM>
  3532. Subject: A location is not a route
  3533. Message-ID: <011590.183522.enge@ibm.com>
  3534.  
  3535. I think we are arguing over semantics.  Call the X6XXX.CA.USA.NA
  3536. whatever you wish.  In the absence of name servers, we had to do
  3537. something.  This implementation is working pretty good and getting
  3538. better each day as more people start to use it.
  3539.  
  3540. When the servers get running to where we can obtain reliable data in a
  3541. few seconds, I will be happy consign the .CA.USA.NA to the waste bin.
  3542.  
  3543. As far as alternate proposals, where were they when the paper was
  3544. blank?  The PBBS people have been working on this for over a year.
  3545. There are over 20 authors of packet mailbox software on all continents
  3546. making coordination of difficult but this is what we came up with.
  3547. Now is not the time to start over from ground-zero.  If there are
  3548. proposals on how to integrate the PBBS addressing with AMPR.ORG, I am
  3549. listening.
  3550.  
  3551. Roy, AA4RE
  3552.  
  3553.  
  3554. ------------------------------
  3555.  
  3556. Date: 15 Jan 90 22:35:46 GMT
  3557. From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hpl.hp.com  (Bdale Garbee)
  3558. Subject: BBS Source code & KISS specification needed
  3559. Message-ID: <4390115@col.hp.com>
  3560.  
  3561. >I also would like a quick pointer to information about
  3562. >KISS - in particular, a specification or detailed info about the commands,
  3563. >etc.  If this is published anywhere (proceedings of ARRL Computer Networking
  3564. >Conference ???), a simple citation will do.
  3565.  
  3566. This was in the 6th or 7th ARRL conf proceedings, and is an appendix to 
  3567. userman.txt in the KA9Q documentation.
  3568.  
  3569. > I don't suppose such a system already exists??  Reply via e-mail,
  3570. > and I will summarize to the net.  Many thanks!
  3571.  
  3572. This functionality would be fairly easy for someone to add to the KA9Q
  3573. package.
  3574.  
  3575. Bdale
  3576.  
  3577. ------------------------------
  3578.  
  3579. Date: 16 Jan 90 00:19:52 GMT
  3580. From: mcsun!sunic!tut!ousrvr!news@uunet.uu.net  (Ari Husa OH8NUP)
  3581. Subject: G1NNA code via FTP?
  3582. Message-ID: <SO-LURU.90Jan16022326@stekt.oulu.fi>
  3583.  
  3584. I would still like to give the G1NNA BBS a try. I am especially
  3585. interested in the packing feature.
  3586.  
  3587. So, what's the deal? Can I FTP it from somewhere or not?
  3588.  
  3589.     Luru
  3590. --
  3591.  
  3592.     ///   Ari Husa OH8NUP         so-luru@stekt.oulu.fi
  3593.     o-o                    --... ...--
  3594.      o    Ham Radio Operators Do It In Higher Frequency
  3595.  
  3596. ------------------------------
  3597.  
  3598. Date: Mon, 15 Jan 90 18:39:23 PST
  3599. From: "Roy Engehausen" <ENGE@IBM.COM>
  3600. Subject: Mailbox source code
  3601. Message-ID: <011590.183657.enge@ibm.com>
  3602.  
  3603. I think that source code is available for only two programs.  CBBS and
  3604. AA4RE BB.  For the latter, KB7TV handles distribution for a nominal
  3605. sum.  The code is not for the faint hearted since its about 40,000
  3606. lines of Turbo Pascal and takes up about 2MB on your disk when you
  3607. compile it.
  3608.  
  3609. Roy, AA4RE
  3610.  
  3611. ------------------------------
  3612.  
  3613. Date: 15 Jan 90 22:30:58 GMT
  3614. From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hpl.hp.com  (Bdale Garbee)
  3615. Subject: Making things more difficult than necessary (was: Tasco TNC info)
  3616. Message-ID: <4390114@col.hp.com>
  3617.  
  3618. >Huh yourself.  In spite of the Subject line, this thread diverged some time
  3619. >ago into a discussion of alternate firmwares for the generic TNC-2.
  3620.  
  3621. Ok, missed that.
  3622.  
  3623. >piggybacking gives you a way of trying them out.
  3624.  
  3625. Ok.  That's valid.  I'd do it differently (I swap ROM's in my TNC's routinely
  3626. to try out new bits, so it doesn't bother me), but your point is made.
  3627.  
  3628. Bdale
  3629.  
  3630. ------------------------------
  3631.  
  3632. Date: Tue, 16 Jan 90 11:58:22 EST
  3633. From: DYUILL@CARLETON.CA
  3634. Subject: More DSY Modem Info
  3635. Message-ID: <900116.12460790.052874@CU.CP6>
  3636.  
  3637. Bdale writes:
  3638.         >What are you guys using for up/down converters?
  3639. After experimenting on 220Mhz using point to point links we wanted to
  3640. maintain our investment in the Microwave Modules transverters we bought.
  3641. 70cm receive converters from Microwave Modules cost about $75 so we went
  3642. with those. A used 70cm transverter for the xmit side of the repeater
  3643. left us with only a 220Mhz receiver converter to buy.
  3644. We had to go with Advanced Receiver Research for the repeaters 220Mhz
  3645. receive converter after Microwave Modules could not come through with
  3646. anything for 220Mhz. A.R.R. is beter quality but requires a seperate
  3647. pre-amp, guess what else A.R.R. makes?
  3648. The repeater seems to be working well, although we are having a problem
  3649. with dcd falsing at the user end. It seems we have enough intermod that
  3650. some kind of bandpass filtering will be required by users living near
  3651. pager sites.
  3652. BTW, we are using a 2 cavity bandpass filter on the repeater input.
  3653. I observe no falsing of the repeater dcd.
  3654. We are using a Cushcraft 4 pole for 220 and a really nice 11.5db omni
  3655. made by Diamond for 70cm which we bought from RF parts of San Marcos, CA.
  3656. Having the extra gain at the ant. really helps make up for the 10w
  3657. output of the transverter.
  3658. Regarding switch vs repeater sites:
  3659. I guess if you can run copper from your repeater to your switch you
  3660. could use 4 wire line tranceivers. This may not be practical for you
  3661. mountain dud's!
  3662. --dy
  3663. Doug Yuill VE3OCU@VE3JF.ONT.CAN.CA or DYUILL@CARLETON.CA
  3664.  
  3665. ------------------------------
  3666.  
  3667. Date: 14 Jan 90 21:23:01 GMT
  3668. From: zephyr.ens.tek.com!tektronix!sequent!brians@uunet.uu.net  (Brian Sheets)
  3669. Subject: New newsgroup rec.ham-radio.amsat?
  3670. Message-ID: <27737@sequent.UUCP>
  3671.  
  3672. With the upcomming launch of the microsats as well as the present
  3673. group of oscar/amsat guys in the air is there enough intrest on the net
  3674. to warrent a new group for oscar/amsat users?
  3675.  
  3676.  
  3677. -- 
  3678. Brian Sheets KA7KDX         _  /|                   "I'll be back"
  3679. 5544 N Burrage.             \`o_O'             
  3680. Portland Or. 97217            ( ) Aachk!        - Arnold Schwarzenegger,
  3681. 503-526-4091                   U   Phft!         Any movie he's been in.     
  3682.  
  3683. ------------------------------
  3684.  
  3685. Date: 16 Jan 90 23:55:52 GMT
  3686. From: jupiter!karn@bellcore.com  (Phil R. Karn)
  3687. Subject: PK-88 RFI problems
  3688. Message-ID: <19022@bellcore.bellcore.com>
  3689.  
  3690. In article <3333@cbnewsj.ATT.COM> kfr@cbnewsj.ATT.COM (k.redden,lz,) writes:
  3691. >AEA says the clock on the PK-88 does indeed put out a birdie on 145.01, but
  3692. >they do have a mod you can make to fix the situation. The clock frequency is
  3693. >controlled by C38, a 33 pF capacitor. If you change this to an 82 pF cap
  3694. >(use a silver mica cap), it will lower the clock frequency enough to move
  3695. >the birdie out of the packet band.
  3696.  
  3697. That's called "sweeping the dirt under the rug". I agree that this may
  3698. be the most expedient thing to do here, but computer RFI has long been a
  3699. pet peeve of mine. Perhaps the Taiwanese who build PC clones can be
  3700. partially excused, but digital hardware designers who build products
  3701. intended specifically for use with radio transceivers ought to know
  3702. better by now. Over and over again they'll design a new product without
  3703. any advance consideration to RFI, and after they build the prototype
  3704. they never fail to be surprised at how much crap it emits. Then they'll
  3705. kludge up a test version that barely squeaks by the FCC Class B
  3706. requirements. Even if the production models are as good, Class B is
  3707. simply not good enough for an Oscar-class amateur station. And then it's
  3708. up to us consumers to live with the problem or to try to fix it.  Over
  3709. the past week I've almost worn out my electric drill removing paint from
  3710. the interiors of various cabinets in my shack to improve electrical
  3711. contact when they're closed.
  3712.  
  3713. I don't mean to single out AEA here; ALL of the amateur TNC
  3714. manufacturers are guilty of being more concerned about fancy cabinet
  3715. paint jobs and picking connectors that shave a few pennies off their
  3716. manufacturing costs than they are about building a RFI-clean product.
  3717. The only exception I know of is Hadron, which packages PACCOMM TNC-200
  3718. boards in Tempested boxes for the military. Unfortunately, I can't
  3719. afford one.
  3720.  
  3721. Perhaps the FCC ought to revise its Class B requirements to match those
  3722. of Tempest. I bet we'd see some innovative, low cost RF shielding
  3723. techniques appear real fast! :-)
  3724.  
  3725. Phil
  3726.  
  3727. ------------------------------
  3728.  
  3729. Date: Tue, 16 Jan 1990 10:11 EDT
  3730. From: Mark Bramwell   519 661-3714 <watmath!ria.ccs.uwo.ca!business.uwo.ca!MBramwel@uunet.UU.NET>
  3731. Subject: pk232 fax program.
  3732. Message-ID: <9001161521.AA22301@ria.ccs.uwo.ca>
  3733.  
  3734. I recently purchased a pk232 mbx and also got the pc pakratt and pk fax
  3735. program.  When I run the pkfax, it gives an error about the hardware
  3736. not supporting fax.  This is the lastest pk232, however, do I need a special
  3737. pkfax version?  If so, what is the date of the software?
  3738.  
  3739.  
  3740. de VE3PZR.
  3741.  
  3742. ------------------------------
  3743.  
  3744. Date: 15 Jan 90 22:40:30 GMT
  3745. From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hpl.hp.com  (Bdale Garbee)
  3746. Subject: Re: Radar-detector detector
  3747. Message-ID: <4390117@col.hp.com>
  3748.  
  3749. See the 12/89 issue of Ham Radio magazine, the article by N6GN and N6RCE...
  3750.  
  3751. Bdale
  3752.  
  3753. ------------------------------
  3754.  
  3755. Date: 15 Jan 90 22:37:57 GMT
  3756. From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hpl.hp.com  (Bdale Garbee)
  3757. Subject: Unix/KA9Q pty support for outgoing telnet
  3758. Message-ID: <4390116@col.hp.com>
  3759.  
  3760. >I'm running the ka9q software on a unix system w/o tcp/ip support (Sys V).  
  3761.  
  3762. Anders Klemets at SICS has gotten NOS running under sysVr3 using shared memory
  3763. and semaphores in such a way that the protocol modules and interface I/O are
  3764. separate processes, and you have user commands to do things, ala BSD.
  3765.  
  3766. I think his net address is klemets@sics.se, his bits are certainly available
  3767. from the machine sics.se with anonymous FTP.  Not sure what revs of sysV it is
  3768. likely to work under, though.
  3769.  
  3770. Bdale
  3771.  
  3772. ------------------------------
  3773.  
  3774. End of PACKET-RADIO Digest V90 Issue #13
  3775. ****************************************
  3776. 18-Jan-90 10:31:33-MST,9666;000000000000
  3777. Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
  3778. Date: Thu, 18 Jan 90 10:15:15 MST
  3779. From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
  3780. Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  3781. Subject: PACKET-RADIO Digest V90 #14
  3782. To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  3783.  
  3784. PACKET-RADIO Digest         Thu, 18 Jan 90       Volume 90 : Issue   14
  3785.  
  3786. Today's Topics:
  3787.         Dual-band HTs: recommendations/comments sought
  3788.      EPROM vs EEPROMs (or how to have your cake and eat it also)
  3789.             FIXMAIL 1.06 released!
  3790.              PK-88 RFI problems (2 msgs)
  3791.               pk232 fax program.
  3792.             Sick TAPR Board, Advice Needed
  3793. ----------------------------------------------------------------------
  3794.  
  3795. Date: 17 Jan 90 21:07:36 GMT
  3796. From: young@ee.ecn.purdue.edu  (Mike Young)
  3797. Subject: Dual-band HTs: recommendations/comments sought
  3798. Message-ID: <14182@pur-ee.UUCP>
  3799.  
  3800.     I am on the brink of blowing some Christmas money on (probably) a
  3801. 2m/440 HT. Under consideration are the Yaesu FT470, Icom IC32AT or 24AT,
  3802. Kenwood TH75A, and the Alinco DJ500T. (Have I missed any???) I hereby solicit,
  3803. invite, and otherwise open the floor to any and all comments, recommendations,
  3804. warnings, experiences, or (yes, even) horror stories related to any of these
  3805. rigs, their respective manufacturers, or the dealerships at which they were
  3806. purchased.
  3807.  
  3808.     A little background: I intend to use the rig for general yakking thru
  3809. the local 2m repeaters (and soon the 440 repeater...);  I suspect I will
  3810. eventually stick an antenna up at home and get into packet too.
  3811.  
  3812.     A hearty thanks in advance to all respondents. Mail responses to me,
  3813. or post if you think appropriate. I might be coaxed into posting a summary of
  3814. responses after I make the purchase :-)
  3815.  
  3816.                         Mike Young KA9HZE
  3817.                         Purdue University EE Dept.
  3818.                         W. Lafayette IN  47907
  3819.  
  3820.                         young@ecn.purdue.edu
  3821.                         ...!pur-ee!young
  3822.  
  3823. ------------------------------
  3824.  
  3825. Date: Wed, 17 Jan T  14:12:23 -0800
  3826. From: Dana Myers <lcc!dana@seas.ucla.edu>
  3827. Subject: EPROM vs EEPROMs (or how to have your cake and eat it also)
  3828. Message-ID: <9001172224.AA06577@elrond.locus.com>
  3829.  
  3830.    I've been building various microcontroller based gadgets over the last year.
  3831. For the sake of simplicity, they just use ROM based software rather than
  3832. having RAM and a monitor and a serial port and a monitor and downloading.
  3833.  
  3834.    I couldn't bring myself to buy an EPROM programmer and a tubeful of
  3835. 2764s. The programmer is > $200 (I don't have an XT clone with a bus - I
  3836. have a bus-less portable and can't use the $150 bus programmers). An
  3837. ultraviolet eraser is at least $25 or $30. The turnaround time on any given
  3838. EPROM is 45 minutes or more. So, yeah, you keep a handful and cycle through
  3839. them. What a hassle.
  3840.  
  3841.    You can get a 2864 EEPROM which will plug right into a 2764 socket. Program-
  3842. ming them is close to trivial - in one of my micro- controllers (one that does
  3843. have RAM and a monitor and a serial port) I use a spare socket and a short
  3844. program which does the write/data poll sequence required. An 8k EEPROM programs
  3845. in a few seconds. There is no erasing time. The socket you write to it in need
  3846. only be configured for use with a byte wide RAM (like a 6164).
  3847.  
  3848.     I bought some Xicor EEPROMs which were about $20 each. I've seen adds for
  3849. some other 2864 EEPROMs at around $10 each. 2764 EPROMs run about $5 for 250
  3850. nS parts. The higher cost is essentially offset if you don't buy an EPROM
  3851. programmer. The "near zero" tuen around time is worth the $$ alone. If you
  3852. are going to reproduce a bunch a ROMs, though, use the EPROMs.
  3853.  
  3854.  
  3855. Dana H. Myers  WA6ZGB  (Halfway to QCWA and I'm not grey yet ;-)
  3856. Locus Computing Corp.
  3857. Inglewood, CA
  3858. lcc!dana@seas.ucla.edu
  3859.  
  3860. ------------------------------
  3861.  
  3862. Date: Thu, 18 Jan 90 10:26:18 GMT
  3863. From: pat.davis@mail.admin.wisc.edu
  3864. Subject: FIXMAIL 1.06 released!
  3865. Message-ID: <2064@pgd.adp.wisc.edu>
  3866.  
  3867. FYI-  FIXMAIL version 1.06 by Bryan DK Biggers, N9GBJ, is posted on:
  3868.  
  3869. pgd.adp.wisc.edu 128.104.198.22  as: FIXM106.zip  (pkz102.exe, req'd to UNZIP
  3870. it, is also there.. pkz102.exe is a self-extracting ZIPfile. PKZ102.exe is
  3871. SHAREWARE from Paul Katz).
  3872.  
  3873. FIXMAIL is a powerful utility for dealing with Bmailer mail.  V1.06 does what
  3874. the previous releases did but there are also NEW capabilities:
  3875.  
  3876. You can now automate the process of censoring forwarded mail..  So, if you
  3877. are gatewaying mail onto Amateur Radio bands, this IS for YOU!
  3878.  
  3879. If you run FIXMAIL in a Desqview window, you can invoke Desqview macros from
  3880. a 'command file' or '.TXT' file.  In addition, FIXMAIL 1.06 allows DOS
  3881. commands to be in the 'command' file.. This newer feature allows you to do
  3882. some extremely powerful (possibly dangerous) things with your station.
  3883.  
  3884.  
  3885. ------------------------------
  3886.  
  3887. Date: 18 Jan 90 03:15:39 GMT
  3888. From: root@sbcs.sunysb.edu  (Systems Staff)
  3889. Subject: PK-88 RFI problems
  3890. Message-ID: <4488@sbcs.sunysb.edu>
  3891.  
  3892. In article <19022@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes:
  3893. >In article <3333@cbnewsj.ATT.COM> kfr@cbnewsj.ATT.COM (k.redden,lz,) writes:
  3894. >Perhaps the FCC ought to revise its Class B requirements to match those
  3895. >of Tempest. I bet we'd see some innovative, low cost RF shielding
  3896. >techniques appear real fast! :-)
  3897. >Phil
  3898.  
  3899. One hopes you are just joking in even suggesting that class B be revised
  3900. for more stringent emission requirements.  It is enough of a pain in the
  3901. neck to get something simple like an Ethernet board that includes a cheapernet
  3902. xcvr to pass class B as things stand.  I dread the day that I have to try
  3903. to get a high res graphics controller to pass B :-) As hams we have to realize 
  3904. that sometimes all the items on our shopping list (eg low emissions from 
  3905. commercial equipment, free and clear use of spectrum, etc) don't always match 
  3906. up with the needs of the much larger general marketplace.
  3907.  
  3908. Agreed that TNC mfgs in particular should know enough to reduce RFI.  The
  3909. ones that should be particular sensitive to the issue are those who
  3910. offer RF products as well as their digital lines.
  3911.  
  3912.                     Rick Spanbauer/WB2CFV
  3913.                     State U of NY @ Stony Brook
  3914.  
  3915. ------------------------------
  3916.  
  3917. Date: 18 Jan 90 04:42:55 GMT
  3918. From: ka9q.bellcore.com!karn@bellcore.com  (Phil Karn)
  3919. Subject: PK-88 RFI problems
  3920. Message-ID: <19099@bellcore.bellcore.com>
  3921.  
  3922. WB2CFV:
  3923. >One hopes you are just joking in even suggesting that class B be revised
  3924. >for more stringent emission requirements.  It is enough of a pain in the
  3925. >neck to get something simple like an Ethernet board that includes a cheapernet
  3926. >xcvr to pass class B as things stand.
  3927.  
  3928. No, I'm perfectly serious. It's funny you should mention Ethernet boards
  3929. with Cheapernet transceivers, as that's another hot button of mine.  The
  3930. state of the RFI suppression art (such as it is) on these things is
  3931. downright criminal. The only board to do a halfway decent job in bypassing
  3932. the Cheapernet connector was the original long-card version of the 3Com
  3933. 3C501 - it's a shame the rest of its design is so bad.  It had a well-
  3934. designed pi-network filter on the BNC connector. A ferrite ring around the
  3935. connector formed the L, and there are three bypass caps with short leads to
  3936. chassis ground from each side of the ferrite.
  3937.  
  3938. Later versions of the 3C501 watered this down (with predictable results),
  3939. and some other manufacturers I could name do even worse. The Cheapernet
  3940. connector "filtering" in most PC ethernet cards nowadays consists of nothing
  3941. more than a single cap to ground, and it's not even located on the connector
  3942. to avoid ground loops. I finally had to give up and go to external DIX
  3943. transceivers here in the shack to get the HF RFI down to semi-acceptable
  3944. levels. It wasn't my own communications that were being interfered with (I
  3945. almost never operate HF), it was my next door neighbor (K2QWG)!
  3946.  
  3947. The reason that I get so upset about RFI in computer equipment is that it's
  3948. far easier to solve the problem in the initial design than it is to try to
  3949. fix it afterwards.  This is especially true when the job falls to the buyer
  3950. (e.g., me). I have no more sympathy for computer manufacturers who complain
  3951. about the cost of RFI control than I do for car manufacturers who complain
  3952. about the cost of emission control.
  3953.  
  3954. Phil
  3955.  
  3956. ------------------------------
  3957.  
  3958. Date: 17 Jan 90 21:34:02 GMT
  3959. From: hpda!hpcupt1!bmp@ucbvax.Berkeley.EDU  (Brian M. Perkin)
  3960. Subject: pk232 fax program.
  3961. Message-ID: <7400019@hpcupt1.HP.COM>
  3962.  
  3963. The AEA rep told me at the ham convention in San Jose
  3964. in October 89, that if I upgraded a standard PK-232
  3965. to the mailbox version, then I would need an upgraded
  3966. pkfax version. Give AEA a call.
  3967.  
  3968. Brian
  3969. N6RSW
  3970.  
  3971. ------------------------------
  3972.  
  3973. Date: 18 Jan 90 15:35:16 GMT
  3974. From: lectroid!k1te@CS.BU.EDU  (Bradshaw Lupton)
  3975. Subject: Sick TAPR Board, Advice Needed
  3976. Message-ID: <585@lectroid.sw.stratus.com>
  3977.  
  3978. If anyone knows the meaning of led D1 & D2 flashing in 1 sec interval on an
  3979. '83 TAPR Board I would appreciate knowing it.
  3980.  
  3981. Something about "unable to initialize VIA" then a barberpole display of
  3982. the BTEXT appeared shortly before the catatonic state.
  3983.  
  3984.                 tnx K1TE
  3985. -- 
  3986. *-----------------------*---------------------------*------------------------*
  3987. | Bradshaw B. Lupton Jr.| Stratus Computer, Marlboro| Ma 01752  508 490 6484 |
  3988. | Lupton@es.stratus.com | uunet!lectroid!es!Lupton  | es!Lupton@uunet.uu.net |
  3989. *-----------------------*---------------------------*------------------------*
  3990.  
  3991. ------------------------------
  3992.  
  3993. End of PACKET-RADIO Digest V90 Issue #14
  3994. ****************************************
  3995. 18-Jan-90 21:26:24-MST,12901;000000000000
  3996. Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
  3997. Date: Thu, 18 Jan 90 21:15:25 MST
  3998. From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
  3999. Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  4000. Subject: PACKET-RADIO Digest V90 #15
  4001. To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  4002.  
  4003. PACKET-RADIO Digest         Thu, 18 Jan 90       Volume 90 : Issue   15
  4004.  
  4005. Today's Topics:
  4006.               Heath Pocket TNC KISS ROMS
  4007.           New newsgroup rec.ham-radio.amsat?
  4008.          PEACESAT Data Communication Project
  4009.            Radar-detector detector (3 msgs)
  4010.         RFI & radios (was: PK-88 RFI problems)
  4011.           Unix/KA9Q pty support for outgoing telnet
  4012. ----------------------------------------------------------------------
  4013.  
  4014. Date: 18 Jan 90 05:16:04 GMT
  4015. From: cs.utexas.edu!helps!bongo!julian@tut.cis.ohio-state.edu  (julian macassey)
  4016. Subject: Heath Pocket TNC KISS ROMS
  4017. Message-ID: <294@bongo.UUCP>
  4018.  
  4019. >Date: Tue, 26 Dec 89 08:20:31 mst
  4020. >From: Bdale Garbee <bdale@hpcsos.col.hp.com>
  4021. >Message-Id: <8912261520.AA01666@hpcsos.col.hp.com>
  4022. >To: tcp-group@ucsd.edu
  4023. >Subject: Heath/Tasco u21 KISS
  4024. >Status: OR
  4025.  
  4026. >I have placed on col.hp.com, in ~ftp/ka9q/etc, the file u21_kiss.rom.  This
  4027. >is a binary image of a 27256 EPROM for the Heath/Tasco micro TNC that is a
  4028. >copy of the normal firmware with KISS support included.
  4029.  
  4030.     I have had trouble getting someone to get into col.hp.com to 
  4031. grab this file. Is it available for ftp from any other sites - 
  4032. seems from Greater Disneyland people have trouble getting files 
  4033. from col.hp.com - at least the people I try and cajole into 
  4034. midnight ftp sessions. Better yet, is it available on floppy from 
  4035. anyone? Or is it on a regular dialup bbs? I would really like to 
  4036. get my pocket TNC doing KISS. Portable tcp/ip is too good to pass 
  4037. up.
  4038.  
  4039.     Any disk/mailer expenses will be covered. If I get the code, 
  4040. anyone is then welcome to a copy on MS-DOS disk from me.
  4041.  
  4042.     Yours
  4043.  
  4044.  
  4045. -- 
  4046. Julian Macassey, n6are  julian@bongo.info.com  {ucla-an!denwa!bongo!julian
  4047. N6ARE@K6IYK (Packet Radio) n6are.ampr.org [44.16.0.81] voice (213) 653-4495
  4048.  
  4049. ------------------------------
  4050.  
  4051. Date: 16 Jan 90 19:12:01 GMT
  4052. From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hpl.hp.com  (Bdale Garbee)
  4053. Subject: New newsgroup rec.ham-radio.amsat?
  4054. Message-ID: <4390118@col.hp.com>
  4055.  
  4056. >With the upcomming launch of the microsats as well as the present
  4057. >group of oscar/amsat guys in the air is there enough intrest on the net
  4058. >to warrent a new group for oscar/amsat users?
  4059.  
  4060. Since the microsats are inherently digital, I'd suggest we focus microsat
  4061. discussion here in rec.ham-radio.packet, at least until it becomes an
  4062. unwelcome burden on the readership (if it does!).
  4063.  
  4064. 73 - Bdale, N3EUA
  4065.  
  4066. ------------------------------
  4067.  
  4068. Date: 19 Jan 90 02:52:20 GMT
  4069. From: uhccux!mikeg@ames.arc.nasa.gov  (Mike Gonsalves)
  4070. Subject: PEACESAT Data Communication Project
  4071. Message-ID: <6252@uhccux.uhcc.hawaii.edu>
  4072.  
  4073. I am a consultant to the PEACESAT Data Communication Project here
  4074. at the Social Sciences Research Institute, University of Hawaii. 
  4075. For those of you unfamiliar with PEACESAT, the Pan Pacific
  4076. Education And Communication Experiment Satellite is an association
  4077. of independent, autonomous terminal sites located throughout the
  4078. Pacific.  Its purposes are to use satellite communication
  4079. technology for education, experimentation, and health-related
  4080. emergencies.  All activities are non-commercial.
  4081.  
  4082. The objectives of the Data Communication Project are to provide a
  4083. BBS-type store-and-forward messaging system with the following
  4084. capabilities:
  4085.  
  4086.     -  E-mail
  4087.  
  4088.     -  Bulletin Board
  4089.  
  4090.     -  Airtime scheduling for ATS-1, ATS-3 and GOES
  4091.  
  4092.     -  Facsimile service
  4093.  
  4094.     -  Interactive Access to Remote Systems (such as
  4095.        OPAC, DIALOGUE, and BITNET/Internet) through
  4096.        a UH host computer
  4097.  
  4098.     -  Remote users in the Pacific Isles can use
  4099.        Honolulu hub system to automatically dial
  4100.        emergency numbers with automatic cut-off to
  4101.        voice patch
  4102.  
  4103. Ease-of-use is VERY important.
  4104.  
  4105. We have been experimenting with the W0RLI BBS software (version
  4106. 11.7) as a means of providing electronic messaging and access to
  4107. remote systems.  I'm having a problem with the gateway feature. 
  4108. When I call out on port B, which has an Evercom 2400e on it, I can
  4109. connect with the UH computer network, but I don't get all the
  4110. prompts on my remote display, even though they all show on the
  4111. W0RLI system display.  Specifically, any line that does not end in
  4112. CR does not come across to the remote system. This is really
  4113. awkward because most of these lines are prompts to log on, provide
  4114. a password, or issue a command.  I have tried setting PACTIME and
  4115. CPACTIME on the W0RLI TNC (a Kantronics KPC-2400), but to no avail. 
  4116. Any ideas as to why this is happening and how we might work around
  4117. this?  
  4118.  
  4119. I'm also looking for packet software that would accomplish the
  4120. above objectives and run on SCO UNIX.  Any recommendations,
  4121. suggestions or comments would be most welcome!  
  4122.  
  4123. I'm new to ham-radio, packet, UNIX, and the news groups, so if I
  4124. am missing something obvious, please excuse me.
  4125.  
  4126. Mike Gonsalves
  4127.  
  4128. ------------------------------
  4129.  
  4130. Date: 18 Jan 90 17:03:40 GMT
  4131. From: silver!amirza@iuvax.cs.indiana.edu  (anmar mirza)
  4132. Subject: Radar-detector detector
  4133. Message-ID: <33327@iuvax.cs.indiana.edu>
  4134.  
  4135. In article <1011@khijol.UUCP> erc@khijol.UUCP (Edwin R. Carp) writes:
  4136. >In article <22286@usc.edu> kjh@pollux.usc.edu (Kenneth J. Hendrickson N8DGN) writes:
  4137. >
  4138. >>I wonder if amateur radio operators are exempt from this foolishness?  I
  4139. >>am active on the 3 cm band, and I do in fact use modified radar
  4140.                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                     
  4141. >>detectors.  I use them both for test equipment and communications
  4142. >>transcievers.  Ontario may loose my tourist dollars with their little
  4143. >>ploy. 
  4144.  
  4145. I wonder if those are type accepted for what you use them for? :->
  4146.  
  4147. Anmar
  4148.  
  4149. I agree, I hardly go to New Jersey for much the same reasons, I think
  4150. their laws are largely unfair and restrictive.
  4151.  
  4152. ------------------------------
  4153.  
  4154. Date: 18 Jan 90 20:38:49 GMT
  4155. From: cica!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!usc!pollux.usc.edu!kjh@tut.cis.ohio-state.edu  (Kenneth J. Hendrickson N8DGN)
  4156. Subject: Radar-detector detector
  4157. Message-ID: <22388@usc.edu>
  4158.  
  4159. In article <33327@iuvax.cs.indiana.edu> amirza@silver.ucs.indiana.edu (anmar mirza) writes:
  4160. >In article <1011@khijol.UUCP> erc@khijol.UUCP (Edwin R. Carp) writes:
  4161. >>In article <22286@usc.edu> kjh@pollux.usc.edu (Kenneth J. Hendrickson N8DGN) writes:
  4162. >>>am active on the 3 cm band, and I do in fact use modified radar detectors
  4163. >                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  4164. >I wonder if those are type accepted for what you use them for? :->
  4165. >Anmar
  4166.  
  4167. Type acceptance is _NOT_ required for any equipment operated in the
  4168. amateur radio service.  Indeed - you can and are encouraged to design and
  4169. build your own equipment.
  4170.  
  4171. In the rare case that original ideas  Kenneth J. Hendrickson N8DGN
  4172. are found here, I am responsible.     1709 S. Bonnie Brae, LA, CA 90006
  4173. Internet: kjh@usc.edu                 UUCP: ...!uunet!usc!pollux!kjh
  4174.  
  4175. ------------------------------
  4176.  
  4177. Date: 19 Jan 90 02:20:19 GMT
  4178. From: amdahl!kelly@sun.com  (Kelly Goen)
  4179. Subject: Radar-detector detector
  4180. Message-ID: <59sJ02nA80C801@amdahl.uts.amdahl.com>
  4181.  
  4182. In article <33327@iuvax.cs.indiana.edu> amirza@silver.ucs.indiana.edu (anmar mirza) writes:
  4183. >In article <1011@khijol.UUCP> erc@khijol.UUCP (Edwin R. Carp) writes:
  4184. >>In article <22286@usc.edu> kjh@pollux.usc.edu (Kenneth J. Hendrickson N8DGN) writes:
  4185. >>
  4186. >>>I wonder if amateur radio operators are exempt from this foolishness?  I
  4187. >>>am active on the 3 cm band, and I do in fact use modified radar
  4188. >                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                     
  4189. >>>detectors.  I use them both for test equipment and communications
  4190. >>>transcievers.  Ontario may loose my tourist dollars with their little
  4191. >>>ploy. 
  4192. >I wonder if those are type accepted for what you use them for? :->
  4193. >
  4194. >Anmar
  4195. >
  4196. >I agree, I hardly go to New Jersey for much the same reasons, I think
  4197. >their laws are largely unfair and restrictive.
  4198. Amateur gear is specifically exempted from TYPE ACCEPTANCE requirements!!
  4199.     cheers
  4200.     kelly
  4201.  
  4202. ------------------------------
  4203.  
  4204. Date: 18 Jan 90 18:31:10 GMT
  4205. From: zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!stda.jhuapl.edu!mjj@tut.cis.ohio-state.edu  (Marshall Jose)
  4206. Subject: RFI & radios (was: PK-88 RFI problems)
  4207. Message-ID: <4517@aplcen.apl.jhu.edu>
  4208.  
  4209. In article <19022@bellcore.bellcore.com> karn@jupiter.bellcore.com
  4210.        (Phil R. Karn) writes:
  4211. >Perhaps the FCC ought to revise its Class B requirements to match those
  4212. >of Tempest. I bet we'd see some innovative, low cost RF shielding
  4213. >techniques appear real fast! :-)
  4214. >Phil
  4215.  
  4216. In article <4488@sbcs.sunysb.edu> root@sbcs.sunysb.edu
  4217.        (Rick Spanbauer/WB2CFV) writes:
  4218.  
  4219. >One hopes you are just joking in even suggesting that class B be revised
  4220. >for more stringent emission requirements.  It is enough of a pain in the
  4221. >neck to get something simple like an Ethernet board that includes a cheapernet
  4222. >xcvr to pass class B as things stand.  I dread the day that I have to try
  4223. >to get a high res graphics controller to pass B :-) As hams we have to realize 
  4224. >that sometimes all the items on our shopping list (eg low emissions from 
  4225. >commercial equipment, free and clear use of spectrum, etc) don't always match 
  4226. >up with the needs of the much larger general marketplace.
  4227.  
  4228. To which I respond:
  4229.  
  4230. I agree with Phil.  People think effective RFI shielding is expensive
  4231. because Tempest products are costly; but Tempest in turn is costly because
  4232. (a) usually it's a VAR technique (added to existing products) and (b) it's
  4233. what the market will bear.
  4234.  
  4235. Having spent a long time working with sensitive instrumentation (for
  4236. what that's worth), I have concluded that effective shielding is a
  4237. straightforward design matter as long as it's included in the design
  4238. phase.  Add-ons (short of brute-force steel boxes) rarely provide a
  4239. satisfactory solution.  When designing and laying-out the circuit, one
  4240. must think like an electron or like an EM wave:  "What paths are open
  4241. for me to travel along?"
  4242.  
  4243. Upon reflection, I must say I've noticed a tremendous difference in
  4244. computer RFI since the FCC laid down the law.  In the early days my
  4245. POLY-88 running my morse-code-copying program made itself useless by
  4246. trashing the station it was copying.  Nowadays, I'm surrounded by CPUs
  4247. in my station, none of which are objectionable RFI sources.
  4248.  
  4249. The variety of lossy ferrites and chip bypass capacitors I see at
  4250. the hamfests lately tells me designers could clean things up if
  4251. they wanted to.  Read that, "If it was economically advantageous
  4252. for them to do so".
  4253.  
  4254. Cheers,
  4255. Marshall Jose  WA3VPZ
  4256. mjj@aplvax.jhuapl.edu  ||  ...mimsy!aplcen!aplvax!mjj
  4257.  
  4258. ------------------------------
  4259.  
  4260. Date: 18 Jan 90 14:22:51 GMT
  4261. From: zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!texbell!splut!jay@tut.cis.ohio-state.edu  (Jay "you ignorant splut!" Maynard)
  4262. Subject: Unix/KA9Q pty support for outgoing telnet
  4263. Message-ID: <C#F:-FA@splut.conmicro.com>
  4264.  
  4265. In article <4390116@col.hp.com> bdale@col.hp.com (Bdale Garbee) writes:
  4266. >Anders Klemets at SICS has gotten NOS running under sysVr3 using shared memory
  4267. >and semaphores in such a way that the protocol modules and interface I/O are
  4268. >separate processes, and you have user commands to do things, ala BSD.
  4269.  
  4270. >I think his net address is klemets@sics.se, his bits are certainly available
  4271. >from the machine sics.se with anonymous FTP.  Not sure what revs of sysV it is
  4272. >likely to work under, though.
  4273.  
  4274. I've been (slowly...seems that my domain doesn't work from Sweden!)
  4275. talking to Anders about this. There are actually two separate
  4276. implementations involved: one uses a background daemon to do the
  4277. protocols and interface I/O, and another uses streams modules pushed on
  4278. top of the TTY driver. The streams stuff will only work under
  4279. SysVr3...since I'm stuck at SysVr2, I'd like to get the other
  4280. implementation (which he refers to as NETNIX in the 8th Conference
  4281. paper), make it work on my system, and polish it up. That seems to be
  4282. the right way to do it on Unix.
  4283.  
  4284. -- 
  4285. Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
  4286. jay@splut.conmicro.com       (eieio)| adequately be explained by stupidity.
  4287. {attctc,bellcore}!texbell!splut!jay +----------------------------------------
  4288.    "There is no doubt I should be tarred and feathered." - Richard Sexton
  4289.  
  4290. ------------------------------
  4291.  
  4292. End of PACKET-RADIO Digest V90 Issue #15
  4293. ****************************************
  4294. 19-Jan-90 11:24:33-MST,17601;000000000000
  4295. Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
  4296. Date: Fri, 19 Jan 90 11:15:22 MST
  4297. From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
  4298. Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  4299. Subject: PACKET-RADIO Digest V90 #16
  4300. To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  4301.  
  4302. PACKET-RADIO Digest         Fri, 19 Jan 90       Volume 90 : Issue   16
  4303.  
  4304. Today's Topics:
  4305.              PK-88 RFI problems (5 msgs)
  4306.         RFI & radios (was: PK-88 RFI problems)
  4307. ----------------------------------------------------------------------
  4308.  
  4309. Date: 18 Jan 90 13:31:05 GMT
  4310. From: cs.utexas.edu!helps!bongo!julian@tut.cis.ohio-state.edu  (julian macassey)
  4311. Subject: PK-88 RFI problems
  4312. Message-ID: <295@bongo.UUCP>
  4313.  
  4314. In article <19022@bellcore.bellcore.com>, karn@jupiter..bellcore.com (Phil R. Karn) writes:
  4315. > In article <3333@cbnewsj.ATT.COM> kfr@cbnewsj.ATT.COM (k.redden,lz,) writes:
  4316. > >AEA says the clock on the PK-88 does indeed put out a birdie on 145.01, but
  4317. > >they do have a mod you can make to fix the situation. The clock frequency is
  4318. > >controlled by C38, a 33 pF capacitor. If you change this to an 82 pF cap
  4319. > >(use a silver mica cap), it will lower the clock frequency enough to move
  4320. > >the birdie out of the packet band.
  4321. > That's called "sweeping the dirt under the rug". I agree that this may
  4322. > be the most expedient thing to do here, but computer RFI has long been a
  4323. > pet peeve of mine. Perhaps the Taiwanese who build PC clones can be
  4324. > partially excused, but digital hardware designers who build products
  4325. > intended specifically for use with radio transceivers ought to know
  4326. > better by now. Over and over again they'll design a new product without
  4327. > any advance consideration to RFI, and after they build the prototype
  4328. > they never fail to be surprised at how much crap it emits. Then they'll
  4329. > kludge up a test version that barely squeaks by the FCC Class B
  4330. > requirements. Even if the production models are as good, Class B is
  4331. > simply not good enough for an Oscar-class amateur station. And then it's
  4332. > up to us consumers to live with the problem or to try to fix it.  Over
  4333. > the past week I've almost worn out my electric drill removing paint from
  4334. > the interiors of various cabinets in my shack to improve electrical
  4335. > contact when they're closed.
  4336. > I don't mean to single out AEA here; ALL of the amateur TNC
  4337. > manufacturers are guilty of being more concerned about fancy cabinet
  4338. > paint jobs and picking connectors that shave a few pennies off their
  4339. > manufacturing costs than they are about building a RFI-clean product.
  4340. > The only exception I know of is Hadron, which packages PACCOMM TNC-200
  4341. > boards in Tempested boxes for the military. Unfortunately, I can't
  4342. > afford one.
  4343. > Perhaps the FCC ought to revise its Class B requirements to match those
  4344. > of Tempest. I bet we'd see some innovative, low cost RF shielding
  4345. > techniques appear real fast! :-)
  4346.     The FCC requirements are not so bad, it is the enforcement of 
  4347. those requirements that is lacking. I have been to many FCC sites 
  4348. - both U.S. and overseas - and seen "name brand" equipment made to 
  4349. pass FCC part 15 subpart J etc. What passes in no way represents 
  4350. what the consumer buys. When you see a computer with custom 
  4351. shielded cables, large ferrite chokes and caps everywhere pass 
  4352. Part 15, you are watching consumers being duped. Sure the lab 
  4353. will send all the mods to the manufacturer telling him to do them 
  4354. in production gear. But I haven't seen it happen yet.
  4355.  
  4356.     The major concern that most manufactures have during testing is 
  4357. how soon you can get the paperwork in so the unit can be on the 
  4358. market. I feel that most compliance departments are a division of 
  4359. sales. I have been shouted at for voicing concern about high crud 
  4360. levels rather than trying to get the paperwork shipped - Fed Ex 
  4361. of course - to the FCC. Yes, once someone tried to bribe me and 
  4362. others. A strange and impermanent way to reduce emissions.
  4363.  
  4364.     What we need is not tougher specs from the FCC, but tougher 
  4365. enforcement of those specs. The FCC should randomly buy equipment 
  4366. with their label on it an rigorsly test it. If it fails, close 
  4367. down the company's production line until it is fixed and fine 
  4368. them for each non-complying product shipped before. I would 
  4369. rather have the FCC do this with my dollars than chase people 
  4370. who use old english words that offend semi-literate religious 
  4371. fanatics. By the way, the FDA give manufacturers a hard time 
  4372. about non-complying products. Why don't the FCC?
  4373.  
  4374.     But I suppose we can do something too - besides modifying badly 
  4375. designed gear. We can ask ARRL, BYTE mag and others to include 
  4376. Part 15 compliance in their test reports. I bet that will make 
  4377. the fur fly. Also we can complain to manufacturers when their 
  4378. stuff is not up to par. And the last defence of capitalism, don't 
  4379. buy stuff that radiates.
  4380.  
  4381.     I feel much better now. 
  4382.     
  4383. -- 
  4384. Julian Macassey, n6are  julian@bongo.info.com  {ucla-an!denwa!bongo!julian
  4385. N6ARE@K6IYK (Packet Radio) n6are.ampr.org [44.16.0.81] voice (213) 653-4495
  4386.  
  4387. ------------------------------
  4388.  
  4389. Date: 19 Jan 90 15:11:15 GMT
  4390. From: root@sbcs.sunysb.edu  (Systems Staff)
  4391. Subject: PK-88 RFI problems
  4392. Message-ID: <4500@sbcs.sunysb.edu>
  4393.  
  4394. In article <19099@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes:
  4395. >WB2CFV:
  4396. >>One hopes you are just joking in even suggesting that class B be revised
  4397. >>for more stringent emission requirements.  It is enough of a pain in the
  4398. >>neck to get something simple like an Ethernet board that includes a cheapernet
  4399. >>xcvr to pass class B as things stand.
  4400. >
  4401. >No, I'm perfectly serious. It's funny you should mention Ethernet boards
  4402. >with Cheapernet transceivers, as that's another hot button of mine.  The
  4403. >state of the RFI suppression art (such as it is) on these things is
  4404. >downright criminal. The only board to do a halfway decent job in bypassing
  4405. >about the cost of RFI control than I do for car manufacturers who complain
  4406. >about the cost of emission control.
  4407.  
  4408.     KA9Q, again, RFI control isn't an item that everyone on the 
  4409.     planet dreams about at night.  Car emissions are something that directly
  4410.     affect everyone; RFI emissions (in these days of cable TV/FM) have
  4411.     far less direct impact on John Q Public.  I have a bunch of machines,
  4412.     all class B, sitting one room over from our consumer electronics.
  4413.     No interference.  Of course they do inject quite a bit of noise into
  4414.     the low band and even 2M rigs.  But then I am not about to ask my
  4415.     neighbors to underwrite my hobby through increased cost of electronics 
  4416.     (to control RFI) simply because it is hard to work the high end of 20 
  4417.     when their kids Tai PC clone is going.  I tune down a bit and be cool.
  4418.     I mean, what next?  Suggest that all color TV sets be required to
  4419.     meet Tempest simply because they produce some incidental emissions on 
  4420.     80? Or suggest that local governments adopt aggressive scrape and paint
  4421.     programs on municipal structures to ensure there are no sources of
  4422.     rectification?  Dealing with RFI is something that we should learn to 
  4423.     live with and you probably should buy a heavier duty drill :-)
  4424.  
  4425.     Seriously, this hobby has to realize we number only 300K -> 400K hams 
  4426.     and start to act like it.  I hear a lot of whining about antenna height
  4427.     restrictions, RFI, use of spectrum, inattention of FCC, etc - but the 
  4428.     average ham seems to be incredibly myopic when it comes time to realize
  4429.     there are other point of view/rights at work in the world.  Or more 
  4430.     succinctly, your right to have a free datalink ends at the right of 
  4431.     the public to have lower cellular phone rates (through fairer allocation        of spectrum).  Ah well.  I guess you pushed one of my hot buttons :-)
  4432.  
  4433. >Phil
  4434.  
  4435.                     Rick Spanbauer, WB2CFV
  4436.  
  4437. ------------------------------
  4438.  
  4439. Date: 19 Jan 90 16:36:00 GMT
  4440. From: agate!shelby!neon!kaufman@ucbvax.Berkeley.EDU  (Marc T. Kaufman)
  4441. Subject: PK-88 RFI problems
  4442. Message-ID: <1990Jan19.163600.2960@Neon.Stanford.EDU>
  4443.  
  4444. In article <4500@sbcs.sunysb.edu> root@sbcs.sunysb.edu (Systems Staff) writes:
  4445.  
  4446. -       ... I have a bunch of machines,
  4447. -       all class B, sitting one room over from our consumer electronics.
  4448. -       No interference.  Of course they do inject quite a bit of noise into
  4449. -       the low band and even 2M rigs.  But then I am not about to ask my
  4450. -       neighbors to underwrite my hobby through increased cost of electronics 
  4451. -       (to control RFI) simply because it is hard to work the high end of 20 
  4452. -       when their kids Tai PC clone is going.  I tune down a bit and be cool.
  4453. -       I mean, what next?  Suggest that all color TV sets be required to
  4454. -       meet Tempest simply because they produce some incidental emissions on 
  4455. -       80?
  4456.  
  4457. Short sighted, I think.  Incidental emissions increase the noise floor, so ALL
  4458. users have to run higher power, which increases interference even more.  We
  4459. may be the first (?) to notice the crud on the band, but it affects all the
  4460. users, even those who are not specifically aware of it.
  4461.  
  4462. After all, the hole in the ozone layer is at the South Pole, how can it
  4463. possibly affect me, safe here in the Northern Hemisphere?
  4464.  
  4465. Marc Kaufman (kaufman@Neon.stanford.edu)
  4466.  
  4467. ------------------------------
  4468.  
  4469. Date: 19 Jan 90 17:28:12 GMT
  4470. From: kchen@apple.com  (Kok Chen)
  4471. Subject: PK-88 RFI problems
  4472. Message-ID: <37952@apple.Apple.COM>
  4473.  
  4474. I used to think that I am the only one plagued by RFI/EMI from micros
  4475. and TNCs.  It seems that there are quite a few other folks are equally
  4476. irritated.
  4477.  
  4478. I still haven't completely solved my problems. My MFJ-1278 still puts 
  4479. out birdies on 20, 15 and 10 and, for gods sakes, even on 2m!  This, for 
  4480. a TNC "designed" for Ham use.  I can understand an East Asian clone maker 
  4481. not being sensitive to the needs of Hams, but a TNC manufacturer??  I
  4482. have toroids on every cable connected to the unit and have been able
  4483. to reduce some of the birdies by a dozen db. Even the power cable to
  4484. it radiates like nobody's business.  Why am I having to do this?  I would
  4485. gladly have paid an extra $100 for an RFI-clean unit.
  4486.  
  4487. My micro problems are abated somewhat (the hash across 20m is perhaps 2 
  4488. to 3 "S" points lower) when I went from an AT-clone to a Mac IIcx, but 
  4489. the problems haven't gone away, by any means.  I have considered repackaging 
  4490. AT boards (they are really inexpensive, afterall; and convenient for Hams 
  4491. who program down to the bare metal), but the amount of sheet metal work
  4492. is beyond my competance.
  4493.  
  4494. So!  Are a bunch of people willing to get together, pool our knowledge
  4495. and work to design some RFI-proof computational boxes, sort of in the spirit 
  4496. of the Amsat folks?
  4497.  
  4498.  
  4499. Kok Chen                        kchen@apple.COM, kk6dp
  4500. Apple Computer, Inc.
  4501.  
  4502. ------------------------------
  4503.  
  4504. Date: 19 Jan 90 16:34:32 GMT
  4505. From: root@sbcs.sunysb.edu  (Systems Staff)
  4506. Subject: PK-88 RFI problems
  4507. Message-ID: <4503@sbcs.sunysb.edu>
  4508.  
  4509. In article <295@bongo.UUCP> julian@bongo.UUCP (julian macassey) writes:
  4510. >In article <19022@bellcore.bellcore.com>, karn@jupiter..bellcore.com (Phil R. Karn) writes:
  4511. >> In article <3333@cbnewsj.ATT.COM> kfr@cbnewsj.ATT.COM (k.redden,lz,) writes:
  4512. >       The FCC requirements are not so bad, it is the enforcement of 
  4513. >those requirements that is lacking. I have been to many FCC sites 
  4514. >- both U.S. and overseas - and seen "name brand" equipment made to 
  4515. >pass FCC part 15 subpart J etc. What passes in no way represents 
  4516. >what the consumer buys. When you see a computer with custom 
  4517. >shielded cables, large ferrite chokes and caps everywhere pass 
  4518. >Part 15, you are watching consumers being duped. Sure the lab 
  4519. >will send all the mods to the manufacturer telling him to do them 
  4520. >in production gear. But I haven't seen it happen yet.
  4521.  
  4522.     This is generalization.  I've been through FCC testing with equipment
  4523.     and it was the case that the class B computer into which my board 
  4524.     plugged in DID pass B conductive & emissions while doing the required
  4525.     "HHHHHH...." patterns, hooked up to the printer, etc.  And, no
  4526.     I didn't tweak the machine at all.  Any responsible volume manufacturer
  4527.     in the US almost surely introduces the changes into production
  4528.     that were required to pass.  Look at it this way: on the off chance
  4529.     the mfg is caught, the penalties are already stiff enough to make
  4530.     it hurt.
  4531.  
  4532.     Remember, when listening/presenting stories you've heard second hand,
  4533.     that it is entirely possible that a machine can be abused after
  4534.     manufacture such that it no longer passes A/B/J, etc.  Is it the
  4535.     manufacturers responsibility to ensure his equipment is in compliance
  4536.     if you've damaged his seals, modified circuitry, replaced an LS TTL
  4537.     chip with a noiser AS chip because you didn't have the LS part on
  4538.     hand, etc?  Is your rig compliant with J when you operate it with
  4539.     the covers off?  What about when you make software changes to your
  4540.     TNC that alter the RFI profile of the unit?  Life ain't simple and
  4541.     there is more to these problems than casual banter on 
  4542.     rec.ham-radio.packet is willing to consider.
  4543.  
  4544. >       The major concern that most manufactures have during testing is 
  4545. >how soon you can get the paperwork in so the unit can be on the 
  4546. >market. I feel that most compliance departments are a division of 
  4547. >sales. I have been shouted at for voicing concern about high crud 
  4548. >levels rather than trying to get the paperwork shipped - Fed Ex 
  4549. >of course - to the FCC. Yes, once someone tried to bribe me and 
  4550. >others. A strange and impermanent way to reduce emissions.
  4551.  
  4552.     Oh, come on.  You've been watching too much Mike Wallace & 60 minutes.
  4553.     Anyone I've know who has been through the complaince testing
  4554.     has been the engineer who designed the widget in the first place.
  4555.  
  4556. >       What we need is not tougher specs from the FCC, but tougher 
  4557. >enforcement of those specs. The FCC should randomly buy equipment 
  4558. >with their label on it an rigorsly test it. If it fails, close 
  4559.  
  4560.     Who would pay to purchase Vax 9000's, Crays, etc.  All need to
  4561.     be at least class A.  I don't want my tax dollar going to such
  4562.     folly.  What *is* needed perhaps is to require followup testing
  4563.     of production units, preferably by a different testing lab than
  4564.     did the first units.
  4565.  
  4566. >fanatics. By the way, the FDA give manufacturers a hard time 
  4567. >about non-complying products. Why don't the FCC?
  4568.  
  4569.     Maybe it's because a few extra microvolts at 10 mHz will not
  4570.     make your hair fall out.  Let's make the justice fit the crime.
  4571.  
  4572. >       But I suppose we can do something too - besides modifying badly 
  4573. >designed gear. We can ask ARRL, BYTE mag and others to include 
  4574. >Part 15 compliance in their test reports. I bet that will make 
  4575. >the fur fly. Also we can complain to manufacturers when their 
  4576. >stuff is not up to par. And the last defence of capitalism, don't 
  4577. >buy stuff that radiates.
  4578.  
  4579.     .1% of the only ~300K hams who might buy a particular widget does
  4580.     not present a serious problem to the bad guy.  RFI performance matters
  4581.     only to hams and at most we might account for 300K units (if we
  4582.     all have PCs in the shack) of an installed base of some 11-15 million
  4583.     PCs.  Not enough to get attention.  Sure you can assert
  4584.     your own political agenda while you are at work, but I know my boss 
  4585.     probably would be more interested in how many mBytes each machine has 
  4586.     rather than how many uV/M the machine produces.  He would be really
  4587.     non-plussed if I decided on RFI performance over some attribute
  4588.     needed by the user population.  (IE, I guess I will buy 286 PC machines
  4589.     with 640x400 monochrome graphics rather than the whizz-bang i860
  4590.     machine w/1600x1200x24 bit color because the former is quieter on 20M).
  4591.  
  4592. >Julian Macassey, n6are  julian@bongo.info.com  {ucla-an!denwa!bongo!julian
  4593.  
  4594. ------------------------------
  4595.  
  4596. Date: 19 Jan 90 15:51:37 GMT
  4597. From: root@sbcs.sunysb.edu  (Systems Staff)
  4598. Subject: RFI & radios (was: PK-88 RFI problems)
  4599. Message-ID: <4501@sbcs.sunysb.edu>
  4600.  
  4601. In article <4517@aplcen.apl.jhu.edu> mjj@aplvax.UUCP (Marshall Jose) writes:
  4602. >In article <19022@bellcore.bellcore.com> karn@jupiter.bellcore.com
  4603. >because Tempest products are costly; but Tempest in turn is costly because
  4604. >(a) usually it's a VAR technique (added to existing products) and (b) it's
  4605. >what the market will bear.
  4606. >
  4607. >The variety of lossy ferrites and chip bypass capacitors I see at
  4608. >the hamfests lately tells me designers could clean things up if
  4609. >they wanted to.  Read that, "If it was economically advantageous
  4610. >for them to do so".
  4611. >Marshall Jose  WA3VPZ
  4612.  
  4613. 90%/10% - class B has taken us far enough along is the premise of my
  4614. position.  Getting the last 10% is going to cost more.  And the costs
  4615. are not just simply introducing the average digital engineer to ferrite
  4616. products and copper finger stock.  They go more like this:
  4617.  
  4618.     training of engineers + engineering support personnel (PCB designers,
  4619.         packaging people, power supply designers, marketing, etc) in 
  4620.         RFI control techniques.
  4621.     Cost to equip labs to instrument RFI during both development and
  4622.         production phases.  Ever price out a class A|B test setup?
  4623.         Get a current Tek catalog and get surprised :-)
  4624.     Time to market costs (already a problem in class B work) when your
  4625.         widget didn't pass.
  4626.     Extra costs on the enforcement half of the picture.
  4627.  
  4628. If you think all of this is going to pass through to the consumer as a
  4629. 5 cent ferrite bead and a couple of bypass caps, think again.  
  4630.  
  4631.                     Rick Spanbauer, WB2CFV
  4632.                     State U of NY/Stony Brook
  4633.  
  4634. ------------------------------
  4635.  
  4636. End of PACKET-RADIO Digest V90 Issue #16
  4637. ****************************************
  4638. 20-Jan-90 07:22:08-MST,10086;000000000000
  4639. Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
  4640. Date: Sat, 20 Jan 90 07:15:10 MST
  4641. From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
  4642. Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  4643. Subject: PACKET-RADIO Digest V90 #17
  4644. To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  4645.  
  4646. PACKET-RADIO Digest         Sat, 20 Jan 90       Volume 90 : Issue   17
  4647.  
  4648. Today's Topics:
  4649.               A location is not a route.
  4650.              Ham radio names and routing
  4651.              Heath u21 KISS code.
  4652.              Mailbox source code
  4653.           PBBS forwarding via dialup modem?
  4654.               PK-88 RFI problems
  4655.            Radar-detector detector (2 msgs)
  4656. ----------------------------------------------------------------------
  4657.  
  4658. Date: 19 Jan 90 17:20:58 GMT
  4659. From: amdahl!pacbell!tandem!kevinr@ames.arc.nasa.gov  (Kevin J. Rowett)
  4660. Subject: A location is not a route.
  4661. Message-ID: <1990Jan19.172058.27916@tandem.com>
  4662.  
  4663. In article <120@w2xo.UUCP> durham@w2xo.UUCP (Jim Durham) writes:
  4664. >> 
  4665. >  What we really need to weigh carefully is that in using the "location"
  4666. >scheme, we are really putting the onus on the user to make up for
  4667. >inadequacies in the network. Is this a case of pragmatism, or is it
  4668. >a case of a quick and dirty fix ? I want to think about this some more!
  4669. >-73
  4670. >Jim, W2XO
  4671.  
  4672.  
  4673. Jim, you are so right!  It works now, and solves a problem that needed 
  4674. problem.  When network connectivity gets better, we need to realize 
  4675. user applications will not all be faster BBS's, nor will the end user 
  4676. interface remain something so mundance as a PC :-).  We need all the
  4677. thoughts we can get, and we need people looking at AR saying, hey these
  4678. guys are thinking up some really interesting stuff and I'd like to
  4679. play too.
  4680.  
  4681. COme one ideas! Don't accept the status quo as the horizon!  
  4682.  
  4683. N6RCE
  4684.  
  4685. ------------------------------
  4686.  
  4687. Date: 19 Jan 90 17:14:24 GMT
  4688. From: amdahl!pacbell!tandem!kevinr@ames.arc.nasa.gov  (Kevin J. Rowett)
  4689. Subject: Ham radio names and routing
  4690. Message-ID: <1990Jan19.171424.27801@tandem.com>
  4691.  
  4692. In article <MT.:P.@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes:
  4693. >In article <1990Jan11.164732.18479@tandem.com> kevinr@tandem (Kevin J. Rowett) writes:
  4694. >I screwed up; I should have said K5ZC@WB5BBW.TX.USA.NA.
  4695. >That said, it's STILL a location, not a route. It says nothing at all
  4696. >except that WB5BBW is in Texas, and nothing at all about how that
  4697. >message is to get to Texas.
  4698. >
  4699. >Yes, WB5BBW is unique.
  4700. >Unfortunately, the only ways to know that WB5BBW is in Texas are 1) have
  4701. >the user, who knows it already, tell the computer about it; 2) store a
  4702.  
  4703. These two seem contridictory.  Since in one case it was pointed out
  4704. it's a location, then we asked the user to tell us the route. However,
  4705. Phil makes some good practical points, explaining why it came into
  4706. practice.
  4707.  
  4708. >If you have religious objections to what you see as source routing, then
  4709. >don't complain - come up with the software that will fix it.
  4710.  
  4711. I wish it were that easy.  With the current state of (lack of) connectivity,
  4712. 1200 Bd AFSK CSMA, sometimes ALOHA, real time nameservers just cant' easly
  4713. be done.
  4714.  
  4715. It really means we neeed to rebuild the stack from the bottom up. Actually,
  4716. we can build it from the bottom and top at the same time, and meet in the
  4717. middle.  Example, the top of the stack is BBS's, some of what goes under it
  4718. top to middle pieces are the KA9Q package. For the bottom, see the Dec 89
  4719. Ham Radio magazine, plus other fun stuff we hope to be putting on line
  4720. soon.  Lets not forget DSY's either, on the bottom of the stack.
  4721.  
  4722. However, as usually happens when several pieces are worked on together,
  4723. they don't always meet at their interfaces.  SOurce routing and domain
  4724. naming is one of these crucial areas.  That's why I'd like people to
  4725. realize what the names in BBS really are, and why it's only a practical
  4726. solution to a problem that should be abandoned when we achieve much
  4727. better connectivity.
  4728.  
  4729. Yes, I worship at the temple of SMOP daily.
  4730.  
  4731. N6RCE
  4732.  
  4733. ------------------------------
  4734.  
  4735. Date: Fri, 19 Jan 90 15:17:04 GMT
  4736. From: pat.davis@mail.admin.wisc.edu
  4737. Subject: Heath u21 KISS code.
  4738. Message-ID: <2173@pgd.adp.wisc.edu>
  4739.  
  4740. While I have NOT tried it, I have the TASCO/HEATH u21 KISS rom image-file
  4741. posted on pgd.adp.wisc.edu 128.104.198.22 .
  4742.  
  4743.  
  4744. I hope the code works...  Do tell me if it doesn't..  :-)  Pat
  4745.  
  4746.  
  4747. ------------------------------
  4748.  
  4749. Date: 21 Jan 90 08:50:20 GMT
  4750. From: masscomp!ocpt!tsdiag!ka2qhd!w2vy@think.com  (Thomas A Moulton)
  4751. Subject: Mailbox source code
  4752. Message-ID: <100@ka2qhd.UUCP>
  4753.  
  4754. Brian also gives out source for PRMBS
  4755. Contact him at KA2BQE@N1GMU.VT.USA
  4756. (If I knew where you were I could try to give you the ROUTE, but who cares
  4757. since the systems figure out who to give it to next based to the destination
  4758. locality...)
  4759.  
  4760. ------------------------------
  4761.  
  4762. Date: 21 Jan 90 08:44:06 GMT
  4763. From: masscomp!ocpt!tsdiag!ka2qhd!w2vy@think.com  (Thomas A Moulton)
  4764. Subject: PBBS forwarding via dialup modem?
  4765. Message-ID: <99@ka2qhd.UUCP>
  4766.  
  4767. Also the Packet Radio Mail Box System (PRMBS/ROSErver) by Brian KA2BQE
  4768. has complete support for land line modems. It can accept users and mail
  4769. forwarding over the phone, as well as x/y/zmodem upload/downloads.
  4770.  
  4771. If there is interest I can post a summary of all it's features.
  4772. 73, tom
  4773. w2vy@kd6th.nj.usa
  4774.  
  4775. ------------------------------
  4776.  
  4777. Date: 19 Jan 90 19:40:39 GMT
  4778. From: sbcs.sunysb.edu!root@sbcs.sunysb.edu  (Systems Staff)
  4779. Subject: PK-88 RFI problems
  4780. Message-ID: <4506@sbcs.sunysb.edu>
  4781.  
  4782. In article <1990Jan19.163600.2960@Neon.Stanford.EDU>,
  4783. kaufman@Neon.Stanford.EDU (Marc T. Kaufman) writes:
  4784. > In article <4500@sbcs.sunysb.edu> root@sbcs.sunysb.edu (Systems Staff)
  4785. writes:
  4786. > -     ... I have a bunch of machines,
  4787. > -     all class B, sitting one room over from our consumer electronics.
  4788. > -     No interference.  Of course they do inject quite a bit of noise into
  4789. > -     the low band and even 2M rigs.  But then I am not about to ask my
  4790. > -     neighbors to underwrite my hobby through increased cost of electronics 
  4791. > -     (to control RFI) simply because it is hard to work the high end of 20 
  4792. > -     when their kids Tai PC clone is going.  I tune down a bit and be cool.
  4793. > -     I mean, what next?  Suggest that all color TV sets be required to
  4794. > -     meet Tempest simply because they produce some incidental emissions on 
  4795. > -     80?
  4796. > Short sighted, I think.  Incidental emissions increase the noise
  4797. floor, so ALL
  4798. > users have to run higher power, which increases interference even more.  We
  4799. > may be the first (?) to notice the crud on the band, but it affects all the
  4800. > users, even those who are not specifically aware of it.
  4801.  
  4802.     A question of economic efficiency, I think.  Is it wiser to push
  4803.     all receiving gear to current technological limits or to add
  4804.     another kW at the transmitter or a slave transmitter closer the
  4805.     receiver?  There are probably quite a few people
  4806.     listening to this debate who I am sure could conjure up more
  4807.     efficient means to providing television, FM broadcast, etc at the
  4808.     expense of more complicated electronics in the receiver.  Who 
  4809.     would be willing to pay $5K for the resulting TV set though?  Of 
  4810.     course the point which you tradeoff is modulated BOTH by technology 
  4811.     and general public need (and to some extent environmental needs).  We 
  4812.     tend to fuss just over the technological part of the problems in  
  4813.     this group, much to the detrement of a more realistic understanding 
  4814.     of the issues considered.
  4815.  
  4816. > After all, the hole in the ozone layer is at the South Pole, how can it
  4817. > possibly affect me, safe here in the Northern Hemisphere?
  4818.  
  4819.     Assuming this is a comment to car emissions, it isn't so much that
  4820.     hole in the ozone layer that affects me as much as the guy sitting
  4821.     in front of me at the light who rather desperately needs a ring 
  4822.     job :-)
  4823.  
  4824. > Marc Kaufman (kaufman@Neon.stanford.edu)
  4825.  
  4826.                     Rick Spanbauer
  4827.  
  4828. ------------------------------
  4829.  
  4830. Date: 19 Jan 90 17:27:11 GMT
  4831. From: amdahl!pacbell!tandem!kevinr@ames.arc.nasa.gov  (Kevin J. Rowett)
  4832. Subject: Radar-detector detector
  4833. Message-ID: <1990Jan19.172711.28003@tandem.com>
  4834.  
  4835. >Would you post details?  Sounds interesting for point-to-point high-speed
  4836. >packet, control links, etc. for next to nothing!
  4837.  
  4838. See the Dec '89 Ham Radio magazine.
  4839.  
  4840. An interesting piece that didn't make it into the press, is the apparent wideband
  4841. nature of some radar detectors.  WHile testing units at the location of N6TTO,
  4842. several cars were observed to suddenly brake quickly and glance out their
  4843. windshields quizzckly. The local sheriff was not previously known to frequent that
  4844. corner.
  4845.  
  4846.  
  4847. N6RCE
  4848.  
  4849. ------------------------------
  4850.  
  4851. Date: 20 Jan 90 00:15:12 GMT
  4852. From: pacbell!tandem!kevinr@ames.arc.nasa.gov  (Kevin J. Rowett)
  4853. Subject: Radar-detector detector
  4854. Message-ID: <1990Jan20.001512.29924@tandem.com>
  4855.  
  4856. In article <59sJ02nA80C801@amdahl.uts.amdahl.com> kelly@amdahl.uts.amdahl.com (Kelly Goen) writes:
  4857. >Amateur gear is specifically exempted from TYPE ACCEPTANCE requirements!!
  4858. >    cheers
  4859. >    kelly
  4860. >
  4861. >
  4862.  
  4863. The FCC does in fact have a set of rules and regs for type acceptance of 
  4864. amateur radio service equipment.  ALL equipment used in the ARS MUST meet
  4865. it's requirements.   Part 97.  ARS is NOT exempt from type acceptance.
  4866. Look on the back of your store bought HT.  It says that ithas been type 
  4867. accepted for use in ARS and complies with Part 97 rules.
  4868.  
  4869. However, note a few things about those rules.  The requirements are less
  4870. restrictive than for other sections of the FCC R&R;  And a Ham can
  4871. build equipment for his own use; offer kits; and give away units of
  4872. not morethan five per year without gaining type acceptance for Part
  4873. 97 rules.
  4874.  
  4875. Also note, it's type acceptance, NOT type approval.
  4876.  
  4877. It's this very fact that restricts the use of ARS equipment outside
  4878. the ARS!
  4879.  
  4880. N6RCE
  4881.  
  4882. ------------------------------
  4883.  
  4884. End of PACKET-RADIO Digest V90 Issue #17
  4885. ****************************************
  4886. 22-Jan-90 10:21:55-MST,9064;000000000000
  4887. Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
  4888. Date: Mon, 22 Jan 90 10:15:33 MST
  4889. From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
  4890. Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  4891. Subject: PACKET-RADIO Digest V90 #18
  4892. To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  4893.  
  4894. PACKET-RADIO Digest         Mon, 22 Jan 90       Volume 90 : Issue   18
  4895.  
  4896. Today's Topics:
  4897.           ip/tcp packet radio on a BSD unix machine
  4898.             Lan-Link availability
  4899.                   Microsats
  4900.              PACKET-RADIO Digest V90 #15
  4901.               PK-88/TAPR DCD MOD
  4902.                type acceptance
  4903.                 Unix & packet
  4904. ----------------------------------------------------------------------
  4905.  
  4906. Date: 22 Jan 90 14:34:21 GMT
  4907. From: cs.utexas.edu!mailrus!b-tech!zeeff@tut.cis.ohio-state.edu  (Jon Zeeff)
  4908. Subject: ip/tcp packet radio on a BSD unix machine
  4909. Message-ID: <*-*#RR*@b-tech.uucp>
  4910.  
  4911. I'd like to run packet radio on my Sun 3/50.  I could just run the 
  4912. ka9q package, but I'd prefer to have all the existing {rlogin, telnet, 
  4913. ftp, etc} work as is.  Is there a AX.25 driver for a Sun or a box that 
  4914. will talk ethernet or scsi on one end and packet on the other?  Can a 
  4915. TNC use slip for input and do AX.25 and packet on the output?  Am I 
  4916. going to be better off using a PC as a gateway?  
  4917.  
  4918. What would be the cheapest way to connect a Sun 3/50 (no cards, just
  4919. ethernet, scsi, and RS-232 (9600 bps)) to the DSY 56kb modem?  I'm not sure
  4920. I care about getting better than 9600 bps performance.
  4921.  
  4922. -- 
  4923. Jon Zeeff       zeeff@b-tech.ann-arbor.mi.us  or b-tech!zeeff
  4924.  
  4925. ------------------------------
  4926.  
  4927. Date: 21 Jan 90 14:39:00 GMT
  4928. From: modcomp!dan@uunet.uu.net
  4929. Subject: Lan-Link availability
  4930. Message-ID: <97400002@modcomp>
  4931.  
  4932. I've recently seen reference to a new packet program:
  4933. Lan-Link by G3ZCZ. Is it available anywhere on usenet?
  4934.  
  4935. uunet!modcomp!dan
  4936.  
  4937. ------------------------------
  4938.  
  4939. Date: 20 Jan 90 17:14:09 GMT
  4940. From: vsi1!wyse!stevew@ames.arc.nasa.gov  (Steve Wilson xttemp dept303)
  4941. Subject: Microsats
  4942. Message-ID: <2584@wyse.wyse.com>
  4943.  
  4944. Just a quick note to everyone, the latest issue of "Aviation Week & Space 
  4945. Technology"  has a picture of the satellite assembly going up on the
  4946. Ariane with the microsats highlighted!!!!!!  They mention the sponsoring
  4947. organizations in the blurb but don't explain that these are Amateur Radio
  4948. payloads...So if anyone wants to get a picture of the birds before they
  4949. fly this would be a good source.
  4950.  
  4951. 73's de Steve KA6S
  4952.  
  4953. ------------------------------
  4954.  
  4955. Date: Sun, 21 Jan 90 23:33:52 EST
  4956. From: Roger Smith <ACPS5788%RYERSON.bitnet@ugw.utcs.utoronto.ca>
  4957. Subject: PACKET-RADIO Digest V90 #15
  4958. Message-ID: <90Jan21.233959est.57398@ugw.utcs.utoronto.ca>
  4959.  
  4960. Hi,
  4961.    Could someone please explain the Mechanism of the Radar-Dector Dector?
  4962. How is it possible to detect a device which is only receiving a signal?
  4963. Are we talking about your typical mount on the dashboard radar detector?
  4964.  
  4965.                              Roger Smith
  4966.  
  4967. ------------------------------
  4968.  
  4969. Date: Sun, 21 Jan 90 02:10:33 GMT
  4970. From: pat@kd9uu.ampr.org (Pat Davis, KD9UU)
  4971. Subject: PK-88/TAPR DCD MOD
  4972. Message-ID: <323@kd9uu.ampr.org>
  4973.  
  4974. DE: doug@w9wi.ampr.org (CQ DX 6!)
  4975.  
  4976.        INSTALLING THE TAPR DCD STATE MACHINE IN THE PK-88
  4977.  
  4978.      The AEA PK-88 is not among the TNCs for which detailed
  4979. installation instructions are given in the State Machine pamphlet.
  4980. It isn't that hard to figure out, but maybe these instructions can
  4981. help someone else get theirs working faster.
  4982.  
  4983.      First, electrical connections.  As the TAPR instructions
  4984. detail, the gray wire should connect to pin 26 of the 7910 modem
  4985. chip (IC10); the violet wire connects to pin 25; the brown wire to
  4986. pin 2; and the red wire to pin 22.
  4987.  
  4988.      The x16/x32 clock is a little harder to find.  I located it
  4989. on pin 13 of the 4020 clock divider chip, IC22.  This is an x32
  4990. clock, at 38.4KHz.  Connect the blue wire here.
  4991.  
  4992.      I returned the DCD signal from the TAPR board to the CD pins
  4993. of JP4.  This involves connecting the green wire to the jumper pin
  4994. closest to the rear of the PK-88 board, and closest to the power
  4995. switch.  Don't connect the green wire directly to this point; it'll
  4996. be too short to allow you to put the DCD board inside the case.
  4997. I lengthened the green wire by splicing the black wire (discarded
  4998. from the ribbon cable earlier in the installation) onto the green
  4999. wire.  You could also connect this signal to pin 14 of the RS-232
  5000. connector, J1.  By returning the TAPR DCD signal at this point, you
  5001. can revert to original PK-88 DCD operation by simply moving the CD
  5002. jumper back to its original position.  (especially important to me
  5003. since I wasn't too sure the rest of this installation was going to
  5004. work!)
  5005.  
  5006.      After making this connection, move the black jumper plug
  5007. nearest the power switch to the other position, so it's towards the
  5008. rear of the PK-88.
  5009.  
  5010.      Fitting the DCD board inside the PK-88 case isn't easy!
  5011. Before doing anything else, cut off the top 1/8" or so of the pins
  5012. on the JMP jumper on the TAPR board.  (make sure you replace the
  5013. jumper plug in the 1-2 position!)  I ended up wedging the DCD board
  5014. between the heat sink and the AM7910 chip.  To make this work, you
  5015. have to loosen the front screw holding the heat sink in place.  Be
  5016. careful (and don't retighten this screw all the way) since you could
  5017. probably crack the PC board.
  5018.  
  5019.      That should do it.  Open your squelch and enjoy!
  5020.  
  5021. 73 Doug
  5022.  
  5023.  
  5024.  
  5025.  
  5026. ------------------------------
  5027.  
  5028. Date: 20 Jan 90 20:40:13 GMT
  5029. From: zaphod.mps.ohio-state.edu!usc!pollux.usc.edu!kjh@tut.cis.ohio-state.edu  (Kenneth J. Hendrickson N8DGN)
  5030. Subject: type acceptance
  5031. Message-ID: <22426@usc.edu>
  5032.  
  5033. In article <1990Jan20.001512.29924@tandem.com> kevinr@tandem (Kevin J. Rowett) writes:
  5034. >The FCC does in fact have a set of rules and regs for type acceptance of 
  5035. >amateur radio service equipment.  ALL equipment used in the ARS MUST meet
  5036. >it's requirements.   Part 97.  ARS is NOT exempt from type acceptance.
  5037. >Look on the back of your store bought HT.  It says that ithas been type 
  5038. >accepted for use in ARS and complies with Part 97 rules.
  5039.  
  5040. My Kenwood TH-x5AT's have no such label on them.
  5041.  
  5042. >However, note a few things about those rules.  The requirements are less
  5043. >restrictive than for other sections of the FCC R&R;  And a Ham can
  5044. >build equipment for his own use; offer kits; and give away units of
  5045. >not morethan five per year without gaining type acceptance for Part
  5046. >97 rules.
  5047.  
  5048. I don't think that the manufacturers of equipment to be used only on the
  5049. amateur bands have to go through the rigorous testing procedure required
  5050. for type acceptance.  This is because the responsibility to ensure that
  5051. the equipment is operating according to part 97 falls upon the licensed
  5052. amateur radio operator operating the equipment.  We are supposed to be a
  5053. little smarter (or at least more educated in radio theory) than other
  5054. users of the spectrum.
  5055.  
  5056. >Also note, it's type acceptance, NOT type approval.
  5057. >
  5058. >It's this very fact that restricts the use of ARS equipment outside
  5059. >the ARS!
  5060.  
  5061. No, it's not.  What prevents us from using ARS equipment outside the
  5062. amateur bands is the LACK of type acceptance (which is required for most
  5063. other services).  Remember that we are supposed to have the required
  5064. skills and equipment to ensure that our equipment is operating according
  5065. to the standards set forth in part 97; other spectrum users are not
  5066. assumed to have these skills or this knowledge.
  5067.  
  5068. >N6RCE
  5069.  
  5070. In the rare case that original ideas  Kenneth J. Hendrickson N8DGN
  5071. are found here, I am responsible.     1709 S. Bonnie Brae, LA, CA 90006
  5072. Internet: kjh@usc.edu                 UUCP: ...!uunet!usc!pollux!kjh
  5073.  
  5074. ------------------------------
  5075.  
  5076. Date: 21 Jan 90 18:48:12 GMT
  5077. From: pacbell!uop!quack!mrapple@ames.arc.nasa.gov  (Nick Sayer)
  5078. Subject: Unix & packet
  5079. Message-ID: <5062@quack.UUCP>
  5080.  
  5081. Hi. I have a Sun-2 running SunOS 4.0. I also have a PK-232
  5082. and a 2 meter HT. I would like to set up a PBBS ala W0RLI
  5083. (or whatever). My understanding is that most of these
  5084. systems run on PCs. Is there one that works on BSD 4.[23]
  5085. machines? Since the sun is a multi-user system (of course),
  5086. will the software allow multiple users? Multiple ports (if
  5087. I get more TNCs, of course)?
  5088.  
  5089. Any information would be most helpful. Please reply by mail
  5090. and I will post a summary. My appologies if this is the
  5091. same question constantly being asked ad nauseum here.
  5092.  
  5093. ---------------------------------------------------------------------
  5094. Nick Sayer | quack!mrapple@uop.edu or cheers!quack!mrapple@apple.com
  5095. ... or { apple!cheers | pacbell!cogent!uop }!quack!mrapple
  5096. Packet radio: N6QQQ @ WB6V | (209) 952-5347 300/1200/2400 - login guest
  5097. Disclaimer: The BBC would like to appologise for that announcement
  5098.  
  5099. ------------------------------
  5100.  
  5101. End of PACKET-RADIO Digest V90 Issue #18
  5102. ****************************************
  5103. 23-Jan-90 16:19:43-MST,15357;000000000000
  5104. Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
  5105. Date: Tue, 23 Jan 90 16:15:17 MST
  5106. From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
  5107. Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  5108. Subject: PACKET-RADIO Digest V90 #19
  5109. To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
  5110.  
  5111. PACKET-RADIO Digest         Tue, 23 Jan 90       Volume 90 : Issue   19
  5112.  
  5113. Today's Topics:
  5114.             DOVE Satellite Downlink Sample
  5115.           ip/tcp packet radio on a BSD unix machine
  5116.              Need HELP with PSK Modem kit
  5117.             no more packet-radio mail ...
  5118.         Packet radio license without code requirement
  5119.             rec.ham-radio.amsat newsgroup.
  5120.                vm - view mailer
  5121. ----------------------------------------------------------------------
  5122.  
  5123. Date: 23 Jan 90 03:51:43 GMT
  5124. From: masscomp!ocpt!tsdiag!ka2qhd!kd2bd@think.com  (John Magliacane)
  5125. Subject: DOVE Satellite Downlink Sample
  5126. Message-ID: <106@ka2qhd.UUCP>
  5127.  
  5128. DOVE is a brand new OSCAR satellite that transmits telemetry on 145.825 MHz
  5129. using AX.25 protocol.
  5130.  
  5131. I just had a chance to copy some of DOVE's telemetry. During a 14 minute pass,
  5132. I copied 289 packet frames, or about 31 kilobytes of data. Here's just a SAMPLE
  5133. of what I copied, only about 26 hours after launch:
  5134.  
  5135.  
  5136. DOVE-1>TLM <UI>:
  5137. 00:58 01:59 02:88 03:32 04:58 05:58 06:6D 07:3F 08:6C 09:60 0A:A1
  5138. 0B:DD 0C:E8 0D:D7 0E:00 0F:24 10:CC 11:AE 12:01 13:01 14:B1 15:9D
  5139. 16:96 17:93 18:94 19:94 1A:92 1B:8B 1C:99 1D:97 1E:24 1F:5E 20:BE
  5140.  
  5141. DOVE-1>TLM <UI>:
  5142. 21:9B 22:7A 23:24 24:20 25:2D 26:00 27:00 28:00 29:00 2A:00 2B:00
  5143. 2C:00 2D:29 2E:00 2F:9C 30:C8 31:9C 32:B6 33:0F 34:C6 35:A2 36:A8
  5144. 37:9C 38:BC 39:98 3A:00
  5145.  
  5146. DOVE-1>STATUS <UI>:
  5147.  00 00 00 88 B0 18 BB 01 00 B0 00 00 B0 00 00 00 00 00 00 00
  5148.  
  5149. DOVE-1>WASH <UI>:
  5150. wash addr:3a00:0000, edac=0x7d
  5151. DOVE-1>TIME-1 <UI>:
  5152. PHT: uptime is 039/12:42:46.  Time is Tue Jan 23 03:11:40 1990
  5153.  
  5154. DOVE-1>TLM <UI>:
  5155. 00:58 01:58 02:88 03:32 04:58 05:58 06:6D 07:3F 08:6B 09:5F 0A:A0
  5156. 0B:DD 0C:E8 0D:D8 0E:01 0F:24 10:CC 11:AE 12:00 13:01 14:B2 15:9D
  5157. 16:99 17:91 18:95 19:94 1A:91 1B:87 1C:9A 1D:98 1E:24 1F:5D 20:BE
  5158.  
  5159. DOVE-1>TLM <UI>:
  5160. 21:9B 22:7B 23:22 24:1E 25:2E 26:00 27:00 28:00 29:00 2A:00 2B:01
  5161. 2C:00 2D:2A 2E:00 2F:9C 30:C8 31:9C 32:B6 33:0F 34:C5 35:A2 36:A8
  5162. 37:9C 38:BB 39:98 3A:00
  5163.  
  5164. DOVE-1>STATUS <UI>:
  5165.  00 00 00 88 B0 18 BB 01 00 B0 00 00 B0 00 00 00 00 00 00 00
  5166.  
  5167. DOVE-1>BCRXMT <UI>:
  5168. vbat= 10.877 vlo1= 10.540 vlo2= 10.040 vmax= 11.540 temp=  6.661
  5169.  
  5170.  
  5171. Note that all frames are <UI> frames (Unnumbered Information) addressed to
  5172. different "Unproto" designations (they are transmitted as beacons and do not
  5173. require "connection" to receive.
  5174.  
  5175. DOVE, a product of the efforts of AMSAT of Brazil (Bramsat), currently
  5176. transmits on 145.825 MHz FM, with packet beacons ON for 2.5 minutes and OFF
  5177. for 30 seconds.
  5178.  
  5179. Pretty neat, huh?
  5180.  
  5181. 73, de John, KD2BD
  5182.  
  5183. -- 
  5184. AMPR : KD2BD @ NN2Z (Neptune, NJ)
  5185. UUCP : ucbvax!rutgers!petsd!tsdiag!ka2qhd!kd2bd
  5186.        "For every problem, there is one solution which is simple,
  5187.        neat and wrong." -- H.L. Mencken
  5188.  
  5189. ------------------------------
  5190.  
  5191. Date: 23 Jan 90 06:10:33 GMT
  5192. From: ka9q.bellcore.com!karn@bellcore.com  (Phil Karn)
  5193. Subject: ip/tcp packet radio on a BSD unix machine
  5194. Message-ID: <19280@bellcore.bellcore.com>
  5195.  
  5196. For putting a UNIX system on packet, I recommend the setup I use:
  5197. Ethernet from the UNIX system to a dedicated PC/XT clone acting as
  5198. an IP router between the Ethernet and the packet radio modem (56kb/s
  5199. in my case, but it would also work with 1200 baud KISS TNCs).
  5200.  
  5201. This technique has a very important advantage, namely avoiding the need to
  5202. make any modifications to the UNIX system. You also get the benefit of
  5203. the PC's CPU in driving the radio interface, offloading that job from
  5204. the UNIX system.
  5205.  
  5206. You should make sure that your TCP is reasonably up to date so it will
  5207. perform reasonably well over the (slow) packet channel.
  5208.  
  5209. Phil
  5210.  
  5211. ------------------------------
  5212.  
  5213. Date: 23 Jan 90 21:01:50 GMT
  5214. From: usenet.ins.cwru.edu!cwjcc!ncoast!tbell@tut.cis.ohio-state.edu  (Terry Bell)
  5215. Subject: Need HELP with PSK Modem kit
  5216. Message-ID: <1990Jan23.210150.17829@NCoast.ORG>
  5217.  
  5218. I am having trouble with the "initial alignment" steps on a RadioKit
  5219. G3RUH PSK Modem kit.
  5220.  
  5221. Steps 1 thru 3 all okay.
  5222.  
  5223. #4 Adjust VR2 (with VR3 at mid-travel) so that the meter is exactly centered.
  5224.  
  5225. "DOWN" led lite. I adjust VR2 clockwise meter goes right to center point.
  5226. "DOWN" led stays lite. Any adjustment to VR3, "DOWN" led stays lite.
  5227.  
  5228. "DOWN" led lite. I adjust VR2 counter-clockwise meter goes left, "LOCK"
  5229. led comes on, then finally both led's go out and meter springs to center
  5230. point.
  5231.  
  5232. #5 Set VR3 fully clockwise, re-adjusting VR2 if meter moves from center.
  5233.    Reset VR3 to mid-position. Neither "UP", "DOWN", nor "LOCK" led's
  5234.    should be lit.
  5235.  
  5236. Well as I explained above this just isn't happening. Any help would be
  5237. GREATLY!!! appreciated.
  5238.  
  5239. Thanks in advance, and hope to see ya on the birds SHORTLY. ( I hope)
  5240. 73, Terry
  5241.  
  5242. -- 
  5243. ******************************************************************************
  5244. Terry Bell       FreeNet ab617@po.cwru.edu      UUCP: uunet!cwjcc!ncoast!tbell
  5245. N8HSP @WA8BXN.OH.USA.NA       AMSAT-NA       [44.70.4.10] tbell@n8hsp.ampr.org
  5246. ******************************************************************************
  5247.  
  5248. ------------------------------
  5249.  
  5250. Date: Tue, 23 Jan 90 09:32:29 CET
  5251. From: HLPHYSIK%DMRHRZ11.BITNET@CUNYVM.CUNY.EDU
  5252. Subject: no more packet-radio mail ...
  5253.  
  5254. Date: 23 January 1990, 09:31:32 CET
  5255. From: HLPHYSIK at DMRHRZ11
  5256. To:   packet-radio at wsmr-simtel20.army.mil
  5257.  
  5258. Please remove us from your mailing list.
  5259. (So long ...)
  5260.  
  5261. ------------------------------
  5262.  
  5263. Date: 23 Jan 90 18:02:44 GMT
  5264. From: mailrus!b-tech!zeeff@tut.cis.ohio-state.edu  (Jon Zeeff)
  5265. Subject: Packet radio license without code requirement
  5266. Message-ID: <K%_#1Q-@b-tech.uucp>
  5267.  
  5268. I've heard there may be a packet radio license available without the
  5269. code requirment.  Is this something that is likely to happen?  When?
  5270.  
  5271.  
  5272. -- 
  5273. Jon Zeeff       zeeff@b-tech.ann-arbor.mi.us  or b-tech!zeeff
  5274.  
  5275. ------------------------------
  5276.  
  5277. Date: 22 Jan 90 21:15:27 GMT
  5278. From: zephyr.ens.tek.com!tektronix!sequent!brians@beaver.cs.washington.edu  (Brian Sheets)
  5279. Subject: rec.ham-radio.amsat newsgroup.
  5280. Message-ID: <28120@sequent.UUCP>
  5281.  
  5282. I received a number of people who also would like a new newsgroup
  5283. for amsat/space related articles. Who would do this kinda thing?
  5284.  
  5285.  
  5286. -- 
  5287. Brian Sheets KA7KDX         _  /|                   "I'll be back"
  5288. 5544 N Burrage.             \`o_O'             
  5289. Portland Or. 97217            ( ) Aachk!        - Arnold Schwarzenegger,
  5290. 503-526-4091                   U   Phft!         Any movie he's been in.     
  5291.  
  5292. ------------------------------
  5293.  
  5294. Date: Mon, 22 Jan 90  16:16:24 EST
  5295. From: watmath!ria.ccs.uwo.ca!HAMSTER.business.uwo.ca!Mark@uunet.UU.NET
  5296. Subject: vm - view mailer
  5297. Message-ID: <1742@HAMSTER.Business.UWO.CA>
  5298.  
  5299. ==============================================================================
  5300.  
  5301. I have been working on the full screen mailer for NOS.  I invite people to
  5302. download it from HAMSTER.BUSINESS.UWO.CA   ftp 129.100.22.100
  5303. I am interested in any problems encountered.  I have been making changes
  5304. almost everyday, so check the date code (upper right hand corner of config
  5305. page) to vierify you have a recent version.  Below is some intro DOCS
  5306. on how to use View..
  5307. This message was created using VIEW..
  5308. ---------
  5309.  
  5310.  
  5311.          VIEW - A SMTP Mailer for TCP/IP
  5312.               January 1990
  5313.  
  5314.  
  5315. Introduction
  5316.  
  5317. View is a mailer designed to work with the networking software from Phil Karn
  5318. (KA9Q).  It is a full screen system that allows you to scroll through a message file
  5319. quickly and easily.  Mail can be read, or new messages created.  You have the choice of
  5320. selecting your own viewer and editor programs.  This program creates the files, but it is
  5321. up to the external software to view and/or edit them..
  5322. View was written in Turbo Pascal 5.0.  It can operate in color, or non-color modes.  The
  5323. configuration page must be filled-in in order for View to operate correctly..
  5324. View was written by Mark Bramwell, VE3PZR, London, Ontario.  I can be reached
  5325. during the day at (519) 661-3714, and at home (519) 473-3618.  View can be
  5326. downloaded from the internet from HAMSTER.business.uwo.ca [129.100.22.100]. 
  5327. Hamster supports anonymous FTP logins.  Feel free to send any comments regarding
  5328. view to mbramwel@uwo.ca
  5329.  
  5330.  
  5331. Quick Setup
  5332.  
  5333. Copy VIEW.EXE to your computer.  Make sure that you have a PATH command in
  5334. your AUTOEXEC.BAT so that DOS can find VIEW.EXE
  5335.  
  5336. If you have been using BM.EXE for mail, then the setup is simple..
  5337. If you have not been using BM.EXE, then some directories are needed..Type in the following commands:
  5338.  
  5339. C> MD \SPOOL
  5340. C> MD \SPOOL\MAIL
  5341. C> MD \SPOOL\MQUEUE
  5342.  
  5343. You are now ready to start View..
  5344. C> VIEW
  5345.  
  5346. Test Drive of View
  5347.  
  5348. When enter View for the first time, you will have to configure it for your system.  Select
  5349. the f5 function key to enter the configuration page.  Most items should be filled.  Here
  5350. is an example of some of my responses:
  5351.  
  5352.  
  5353.  
  5354.               Userid:  Mark
  5355.               Hostname: HAMSTER.business.uwo.ca
  5356.               Realname: Mark Bramwell
  5357.      
  5358.               Reply-To: mbramwel@uwo.ca
  5359.      
  5360.               editor: \util\qe.exe
  5361.               viewer: \util\list.com
  5362.  
  5363.               Comments:
  5364.               Signature: \spool\signatur.txt
  5365.  
  5366.               directory: \spool\mail
  5367.               Color: Y    Timezone: EST     Printer: LPT1
  5368.  
  5369.  
  5370.  
  5371. Remember to hit enter with each entry.  When you have filled in the configuration page,
  5372. hit ESC to save it.  View will resave the configuration each time you exit the config
  5373. screen.  
  5374.  
  5375. If you had mail, then some messages will appear on the screen.  If no mail is waiting,
  5376. then a short message will appear on the screen..
  5377. To read a message, use the arrows keys on the keyboard to move the high-lite bar. 
  5378. When the desired message is hi-lited, hit ENTER to read the message..
  5379. Special Keys
  5380.  
  5381. Certain keys have functions assigned to them.  For example, you can move the hi-lited
  5382. bar by using the following keys:  Arrow up, Arrow down, Home, End, PgUp, PgDn. 
  5383. You can mark messages for deletion with the DEL key.  
  5384.  
  5385. ALT-D allows you to jump to DOS without exiting view.  When you type EXIT
  5386. at the dos prompt, you will be returned to VIEW at the same point that you left.  This
  5387. is usefull when you are reading large files and it takes a long time for view to read-it-in. 
  5388.  
  5389. ALT-F is the full display key.  It opens a window at the bottom of the screen that will
  5390. display the full hostname and subject of the current message.  It can be toggled on and
  5391. off and the mode is save in the configuration..
  5392. ALT-P will print the hi-lited message on your printer.  Check config page to ensure that
  5393. you have the printer defined..
  5394. ALT-S will allow you to save the current message to a file.  View will ask for a filename. 
  5395. The message will be read and stored in that file.  This will erase the file if it already
  5396. exists.  View does not append to the file..
  5397. ALT-U is the update key, and forces view to immediately update the file by removing
  5398. marked messages.  View automatically updates the file whenever you have finished
  5399. reading the file and have selected another file..
  5400. ALT-X is the same as f3.  This simply exits view completely..
  5401. ALT-Z reads the current mail file and checks for EOF markers.  I have found that our
  5402. IBM 4381 sticks control-z characters in mail files.  This causes view mailer to think it is
  5403. at the end of file even though there are more messages waiting.  All messages after
  5404. control-z characters are lost.  I would make this routine run all the time except for the
  5405. fact that it slows down the initial mail file reading.  Packet radio mail, and mail directly
  5406. from the internet does not seem to have this problem.. Using VIEW
  5407.  
  5408. f1:  Help.  This displays a simple help screen for those who can't remember
  5409.      some of the special keys..
  5410. f2:  Send Msg.  This will allow you to create and send your own messages. 
  5411.      You must enter something when View asks for 'To:'.  If you just hit enter,
  5412.      then the creation of the message is aborted and you are returned back to
  5413.      the normal screen.  It is not neccessary for you to enter anything in
  5414.      response to 'subject:'.  
  5415.  
  5416.      You must have previously configured View in order for it to find your
  5417.      editor program..
  5418. f3:  Quit.  This exits Views, updates any messages that were deleted, and
  5419.      returns you to DOS..
  5420. f4:  Read Msg.  This will read the hi-lited message.  You can also press
  5421.      ENTER for the same effect..
  5422. f5:  Configure.  Allows you to specify various items about your machine.  This
  5423.      screen must be filled-in, else some of the functions won't work properly. 
  5424.      All info is stored in the \SPOOL\MAILER.CFG config file..
  5425. f6:  Split Digests / Read as mail.  This interesting function has the ability to
  5426.      read mail as normal messages, or try to split a long message into its'
  5427.      smaller parts.  I use this when I receive the info-hams digest.  This takes
  5428.      the 400 line message, and breaks it up into all the smaller messages.  It
  5429.      displays each host and subject separately.  This allows me to read only
  5430.      those messages that I am interested in, and ignore the rest.  This function
  5431.      can be toggled on/off and is stored in the MAILER.CFG file..
  5432. f7:  Select file.  This allows you to specify another .TXT file as your workfile. 
  5433.      For example:  I have all info-hams mail come into my machine under the
  5434.      userid HAMRADIO.  All packet mail comes in for the userid PACKET. 
  5435.      This creates 3 files on my machine  HAMRADIO.TXT, PACKET.TXT,
  5436.      and MARK.TXT.  Using select, I can choose which information I am
  5437.      interested in reading at this time.  Any marked messages are deleted
  5438.      before the new file is read..
  5439. f8:  Credits.  Who am I, and where can I be reached.  Also note the date code
  5440.      in the upper right hand corner of the screen.  This will allow you to know
  5441.      which version of the software you are running..
  5442. f9:  Forward a Message.  This will read the current message and allow you to
  5443.      forward it to someone else.  I use this to send a copy of interesting mail to
  5444.      my home machine. 
  5445.  
  5446. f10: Reply-to.  This will create a message using the hostname, subject, and text
  5447.      of the hi-lited message.  It allows you to reply to a message that you are
  5448.      reading.. 
  5449.  
  5450.  
  5451.  
  5452. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  5453. Mark Bramwell, VE3PZR                Located in sunny London, Ontario
  5454.  
  5455. Internet: mark@hamster.business.uwo.ca  IP Address: 129.100.22.100
  5456.   Packet:  VE3PZR @ VE3GYQ               UWO Phone: (519) 661-3714
  5457.  
  5458.  
  5459. ------------------------------
  5460.  
  5461. Date: Tue, 23 Jan 90 10:41:32 CET
  5462. From: HLPHYSIK%DMRHRZ11.BITNET@CUNYVM.CUNY.EDU
  5463.  
  5464. Date: 23 January 1990, 10:40:33 CET
  5465. From: HLPHYSIK at DMRHRZ11
  5466. To:   packet-radio at wsmr-simtel20.army.mil
  5467.  
  5468. UNSUBSCRIBE
  5469.  
  5470. ------------------------------
  5471.  
  5472. End of PACKET-RADIO Digest V90 Issue #19
  5473. ****************************************
  5474.