home *** CD-ROM | disk | FTP | other *** search
Text File | 1993-12-31 | 227.3 KB | 5,506 lines |
- 2-Jan-90 17:34:00-MST,10283;000000000000
- Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
- Date: Tue, 2 Jan 90 17:19:17 MST
- From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
- Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
- Subject: PACKET-RADIO Digest V89 #1
- To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
-
- PACKET-RADIO Digest Tue, 2 Jan 90 Volume 89 : Issue 1
-
- Today's Topics:
- Computers for packet
- Ham radio names and routing (3 msgs)
- Making things more difficult than necessary (was: Tasco TNC info) (2 msgs)
- Sorry for mangled articles
- tasco rom: thanks.
- TEST
- ----------------------------------------------------------------------
-
- Date: 2 Jan 90 09:43:20 GMT
- From: mcsun!ukc!stl!stc!praxis!newton!mikec@uunet.uu.net (Michael Chace)
- Subject: Computers for packet
- Message-ID: <MIKEC.90Jan2094320@hilbert.praxis.co.uk>
-
- Hello All,
-
- I'm considering changing computers, the main use of which is for packet
- and S/W development.
-
- I have a limited budget so a PC with a hard disk is out of the question.
-
- That leaves perhaps the Atari (520 & 1040) and Amiga.
-
- Any information on these machines for Packet would be appreciated as would
- experience with the KA9Q TCP/IP package.
-
- Thanks & 73
-
- Mike
- ****
-
- .............................................................................
- | ARPA : mikec@praxis.co.uk | Michael Chace |
- | JANET : mikec@uk.co.praxis | PraXis Electronic Design |
- | UUCP : ...!uunet!mcvax!ukc!praxis!mikec | The New Church |
- | | Henry Street |
- | Phone : (44) [0]225 444700 | Bath Avon |
- | AX25 : G6DHU @ G6DHU-2 or G6DHU @ GB7IMB | BA1 1PX UK |
- .............................................................................
-
- ------------------------------
-
- Date: 2 Jan 90 17:28:00 GMT
- From: zaphod.mps.ohio-state.edu!wuarchive!texbell!splut!jay@tut.cis.ohio-state.edu (Jay "you ignorant splut!" Maynard)
- Subject: Ham radio names and routing
- Message-ID: <6287#.@splut.conmicro.com>
-
- In the referenced message, John, KD7UW, writes a lot of common sense.
-
- All I can add is: Bravo!
-
- --
- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
- jay@splut.conmicro.com (eieio)| adequately be explained by stupidity.
- {attctc,bellcore}!texbell!splut!jay +----------------------------------------
- Only sick people need drugs.
-
- ------------------------------
-
- Date: 2 Jan 90 17:26:10 GMT
- From: pacbell!tandem!kevinr@ames.arc.nasa.gov (Kevin J. Rowett)
- Subject: Ham radio names and routing
- Message-ID: <1990Jan2.172610.8764@tandem.com>
-
- In article <2910002@hpubvwa.NSR.HP.COM> johnh@hpubvwa.NSR.HP.COM (John Hays) writes:
- >The problem I see with this whole discussion is the presumption that
- >one set of standards must be applied to all similar problems. The
-
- Not necessarly, just SANITY!
-
- >people in the BBS world have chosen to build a routing system that looks
- >like domain names. They are not domain names, they are routes ... this
-
- AND they've used SOURCE ROUTING, without considering the pitfalls!
-
- >group have decided on a STANDARD of their own design and implementation.
- >It is a STANDARD because it has been generally accepted by the writers
- >of PBBS software, it allows for interopability of Packet Bulletin Board
- >Systems. It may not be a standard by the measuring stick of the
- >INTERNET or OSI crowd, but it is as valid a standard as your telephone
- >number (which incidently is Geographic and a routing system) ...
-
- Just because it's a STD, doesn't mean it's good, or intelligent. Cited
- was the telephone numbering scheme. Implied is the goodness of that
- "plan". Goodness is in the eyes of the beholder. The telephone
- numbering plan is just great for phone companies, but for users it
- frankly is "user-UNfriendly". Why is it desirable from a user perspective
- to have SOURCE ROUTING! WHy can't I dial a friends god given SSN and
- have telco locate the instrument my friend currently happens to be bound
- to?
-
- >
- >The problem I see with the RELIGIOUS position of some of the posters is
- >that it denies that there might be other solutions.
-
- The implication here is that because the poster is fanatical ( spelled
- RELIGIOUS), the poster should be denied 1st amendment rights as well.
- Seems circular reasoning.
-
- >So lets get off of pointing fingers and get on with development in our
- >own areas of interest and let the better solutions "rise to the top."
-
- Excellent idea. Do we want source routing or not? Can we build an
- AMPRNET without resorting to source routing?
-
- >
- >BTW for the purposes of mail routing it should be easy enough to create
- >a subdomain "pbbs.ampr.org" if we can set our Religious points-of-view
- >aside.
-
- NAMEs are DESTINATIONS only!
-
- N6RCE
-
- ------------------------------
-
- Date: 1 Jan 90 00:49:02 GMT
- From: hp-pcd!hplsla!hpubvwa!johnh@hplabs.hp.com (John Hays)
- Subject: Ham radio names and routing
- Message-ID: <2910002@hpubvwa.NSR.HP.COM>
-
- The problem I see with this whole discussion is the presumption that
- one set of standards must be applied to all similar problems. The
- people in the BBS world have chosen to build a routing system that looks
- like domain names. They are not domain names, they are routes ... this
- group have decided on a STANDARD of their own design and implementation.
- It is a STANDARD because it has been generally accepted by the writers
- of PBBS software, it allows for interopability of Packet Bulletin Board
- Systems. It may not be a standard by the measuring stick of the
- INTERNET or OSI crowd, but it is as valid a standard as your telephone
- number (which incidently is Geographic and a routing system) ...
-
- The problem I see with the RELIGIOUS position of some of the posters is
- that it denies that there might be other solutions.
-
- It is much like the battles going on in the Computer industry now, there
- is one camp who promotes STANDARDS by limiting options (one O/S kernal,
- one RISC chip implementation, one User Interface definition), and one
- that says STANDARDS are for interopability but with choices (O/S
- interface specs such as POSIX, Networking definitions, Multiple CPU
- Architectures, etc.)
-
- So lets get off of pointing fingers and get on with development in our
- own areas of interest and let the better solutions "rise to the top."
-
- BTW for the purposes of mail routing it should be easy enough to create
- a subdomain "pbbs.ampr.org" if we can set our Religious points-of-view
- aside.
- [ Would maybe look like:
- kd7uw%nc7f.ut.usa.na@gateway.pbbs.ampr.org
- ]
- Well 73 --- John KD7UW
-
- ------------------------------
-
- Date: 1 Jan 90 03:40:51 GMT
- From: zaphod.mps.ohio-state.edu!swrinde!emory!stiatl!rsiatl!jgd@tut.cis.ohio-state.edu (John G. De Armond)
- Subject: Making things more difficult than necessary (was: Tasco TNC info)
- Message-ID: <1004@rsiatl.UUCP>
-
- In article <10676@ucsd.Edu> brian@ucsd.edu (Brian Kantor) writes:
- >Or if you want to have your cake and eat it too, just solder the kiss
- >prom humping on top of the manufacturer's prom with all the pins except
- >the chip select soldered together. Run the chip select from the board
- >out to the wiper of a SPDT switch, and two wires back to the proms, and
- >you have front panel control of which prom you're using.
-
- And, if you do the same thing to the RAM, use a DPDT switch and use the other
- side to switch the CS line on the RAM, you can even save your AX25 setup
- parameters.
-
- we've been running 'em like this for years around here.
-
- TIP: To solder the piggyback chip in place, coat the inside of each leg
- with surface mount flux-solder paste, mount and sweat in place with either
- hot air (prefered) or a quick swipe with a soldering iron. Be sure to
- bend the CS lead up, of course.
-
- John
-
-
- --
- John De Armond, WD4OQC | The Fano Factor -
- Radiation Systems, Inc. Atlanta, GA | Where Theory meets Reality.
- emory!rsiatl!jgd **I am the NRA** |
-
- ------------------------------
-
- Date: 31 Dec 89 17:33:23 GMT
- From: brian@ucsd.edu (Brian Kantor)
- Subject: Making things more difficult than necessary (was: Tasco TNC info)
- Message-ID: <10676@ucsd.Edu>
-
- Or if you want to have your cake and eat it too, just solder the kiss
- prom humping on top of the manufacturer's prom with all the pins except
- the chip select soldered together. Run the chip select from the board
- out to the wiper of a SPDT switch, and two wires back to the proms, and
- you have front panel control of which prom you're using.
-
- Yeah, yeah, it voids the warrantee. Duh.
- - Brian
-
- ------------------------------
-
- Date: 27 Dec 89 03:38:32 GMT
- From: usenet.ins.cwru.edu!mailrus!jarvis.csri.toronto.edu!torsqnt!tmsoft!mshiels@tut.cis.ohio-state.edu (Michael A. Shiels)
- Subject: Sorry for mangled articles
- Message-ID: <ipgea721f@tmsoft.uucp>
-
- Due to a slight configuration problem my site (masnet.uucp) which gateways
- for canremote.uucp has caused a couple of articles to reappear with mangled
- headers. The problem was corrected but not before a few articles got out
- of my hands. Sorry for any confusion caused. IT HAS BEEN FIXED!!
-
- Michael A. Shiels
-
- ------------------------------
-
- Date: 31 Dec 89 18:30:53 GMT
- From: cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!watserv1!watmath!ria!uwovax!31002_1650@tut.cis.ohio-state.edu
- Subject: tasco rom: thanks.
- Message-ID: <4587.259e0a0d@uwovax.uwo.ca>
-
- I have downloaded the rom i{age and it works great. KISS mode is now
- running. Thanks for the info.
-
- de VE3PZR.
-
- ------------------------------
-
- Date: 26 Dec 89 16:33:00 GMT
- From: usc!cs.utexas.edu!jarvis.csri.toronto.edu!torsqnt!tmsoft!masnet!canremote!stephen.woo@ucsd.edu (STEPHEN WOO)
- Subject: TEST
- Message-ID: <89122703183701@masnet.uucp>
-
- This is a test on Dec 26, 1989 to see if this e-mail will reach me at
- espinc.
- ---
- * Via ProDoor 3.1R
-
- ------------------------------
-
- End of PACKET-RADIO Digest V89 Issue #1
- ***************************************
- 3-Jan-90 05:17:45-MST,11275;000000000000
- Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
- Date: Wed, 3 Jan 90 05:15:07 MST
- From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
- Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
- Subject: PACKET-RADIO Digest V90 #2
- To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
-
- PACKET-RADIO Digest Wed, 3 Jan 90 Volume 90 : Issue 2
-
- Today's Topics:
- AX25 Protocol
- DOSGATE vs. CTTY
- Hierarchical addressing in packet radio, how to use (2 msgs)
- Making things more difficult than necessary (was: Tasco TNC info)
- SOFTWARE AND HARDWARE FOR RBBS
- ----------------------------------------------------------------------
-
- Date: 1 Jan 90 19:50:45 GMT
- From: attctc!mjbtn!raider!root@tut.cis.ohio-state.edu (Bob Reineri)
- Subject: AX25 Protocol
- Message-ID: <164@raider.MFEE.TN.US>
-
- Could some kind soul out there mail me the specs for the AX.25 protocol, or
- point me to where I could download them ??
-
- Thanks in advance, and best wishes for 1990.
-
- Bob, N4CDO
- --
- * RaiderNet Public Access *Middle Tenn's Unix Gateway* Murfreesboro, TN *
- * Data:(615)896-8716 896-7905 Voice:(615)684-4490 Mail:PO Box 2371 Zip 37133 *
- * Domain: root@raider.MFEE.TN.US UUCP: uunet!knuth!raider!root HAM: N4CDO *
-
- ------------------------------
-
- Date: 2 Jan 90 15:36:24 GMT
- From: mirror!necntc!necis!rbono@CS.BU.EDU (Rich Bono)
- Subject: DOSGATE vs. CTTY
- Message-ID: <1199@necis.UUCP>
-
- In article <8912280805.AA17199@ucbvax.Berkeley.EDU>, FTPAM1@ALASKA.BITNET writes:
- > As a matter of curiosity, what's the difference between DOSGATE
- > and the DOS command CTTY? They both seem to do the same thing
- > with the same limitations.
-
- There is a subtle difference, (actually a couple of differences).
-
- The DOS CTTY command poses several problems when used with packet:
-
- 1) DOS always echos the users keystrokes, this will cause problems
- as the user 'sees' his characters echoed back to him with the
- 'nominal' packet delays.
-
- 2) DOS is not aware of when a user is connected or disconnected. Or
- that there is any reason to know this at all.
-
- 3) The CTTY command completly (sp?) redirects the console to the remote
- port. The 'SYSOP' has no idea what the remote user is doing.
-
- 4) The CTTY command must be used to return control to the local console.
-
-
- DOSGATE solves these problems. It (by design) does not try to be another
- commercial package for remotely running the PC via a modem (like REMOTEPC,
- or similar packages that allow remote use of the PC including graphics, etc).
- It is designed with AX.25 packet in mind to allow *any* remote user (without
- special software or hardware of any kind at the remote end) to make use of
- the DOSGATE system.
-
- 1) DOSGATE 'absorbs' DOS's echoing of the users keystrokes.
-
- 2) DOSGATE is aware of when a user connects and disconnects, setting
- environment variables so that programs that need the information can
- 'know' who the current user is. This also allows certain housekeeping
- chores to be done, like returning the current directory to 'root' and
- ending any currently running program incase a user starts a program
- and then disconnects.
-
- 3) DOSGATE 'parallels' the console with the remote user. This allows the
- 'SYSOP' to see what the remote user is doing, and maintain control over
- the actions, or offer help to a user who is having trouble.
-
- 4) The local console under DOSGATE is *always* in control. The remote user
- can be disabled or enabled at will.
-
- Although DOSGATE can be used without a TNC (it can be used with just a dumb
- terminal in a remote location, or through a modem), it was designed with
- (AX.25) packet radio in mind. It (by design) does not attempt to make
- *all* programs usable remotely. By not requiring (SP?) any special terminal
- software, or hardware at the remote end, anyone who can access the packet net
- can run the DOSGATE system. The limitating factor in this is *ALL* software
- to be used on the DOSGATE system must do all its I/O through DOS INT 21h
- calls... and should be limited to TEXT only (7 bit ASCII) programs. This will
- allow anyone to use the software. Alas, most software for the PC these days
- doesn't use the DOS I/O, and uses BIOS or direct hardware accesses. So I
- have been converting many interesting programs to 'C' where I can control
- the application.
-
- Hope this answers your questions. If you have access to the (AX.25)
- packet net, connect to node 'SNH' and then connect to NM1D-2 (in Derry, NH)
- to see what I have done with my DOSGATE station as a simple example
- of what can be accomplished.
-
- I answered this to the net because I have had several queries of this type
- and thought the information would be useful to many of you.
-
- * Where is your nearest DOSGATE???? *
-
- Rich (NM1D)
-
-
-
- --
- /**************************************************************************\
- * Rich Bono (NM1D) If I could only 'C' forever!! rbono@necis.nec.com *
- * (508) 635-6300 NEC Technologies Inc. NM1D@WB1DSW *
- \**************************************************************************/
-
- ------------------------------
-
- Date: 3 Jan 90 03:31:36 GMT
- From: cs.utexas.edu!oakhill!val!ben@tut.cis.ohio-state.edu (Ben Thornton)
- Subject: Hierarchical addressing in packet radio, how to use
- Message-ID: <1990Jan3.033136.2666@val.com>
-
- bdale@col.hp.com (Bdale Garbee) writes:
-
- >This is an unrealistic request. I think Brian is being a bit harsh, but in
- >the long run, he's right. It would have been *so* much better for the creative
- >energy that has been expended inventing the HF routing scheme and putting it
- >to use to have been focussed on, say, building better automated routing
- >mechanisms for NET.
-
- >The ham radio community, and the packet radio neighborhood, are far too small
- >for us to be able to afford fragmentation and survive. We ought to be working
- >on how to work together, instead of pissing on each other...
-
- The same thing could be said about the use of NET/ROM. I think it would have
- been better to install IP routers instead. Now that the NET/ROM networks
- have been installed, it will be that much harder to change over.
- --
-
- Ben Thornton packet: WD5HLS @ KB5PM Internet: ben@val.com
- Video Associates Labs uucp: ...!cs.utexas.edu!val!ben
- Austin, TX fidonet: 1:382/40 - The Antenna Farm BBS
-
- ------------------------------
-
- Date: 3 Jan 90 03:43:57 GMT
- From: cs.utexas.edu!oakhill!val!ben@tut.cis.ohio-state.edu (Ben Thornton)
- Subject: Hierarchical addressing in packet radio, how to use
- Message-ID: <1990Jan3.034357.2755@val.com>
-
- jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes:
-
- >Brian has a religious fervor about his idea of how domain naming and
- >routing should be done. It's unrealistic for him to expect others who do
- >not share his fervor to do things his way, especially when his way won't
- >work without the full network, or large portions of it, are in place,
- >but the other way will (and does) work. This is no different from the
- >production code vs. neat hack argument: production code works, neat
- >hacks may not. Hams want something that works, and don't care how
- >technically pure it is.
-
- From the point of view of the end user the difference between a 'neat hack'
- and 'production code' is often not all that obvious. Therefore, I
- move that we get away from that terminology. If the word 'production'
- is supposed to connote 'bug free' or 'small number of minor bugs', then
- this is a misuse of the term; many commercial works of 'production'
- code have found their way to the end user.
-
- Or is the term 'production' supposed to connote 'paid for' :-) ?
-
- --
-
- Ben Thornton packet: WD5HLS @ KB5PM Internet: ben@val.com
- Video Associates Labs uucp: ...!cs.utexas.edu!val!ben
- Austin, TX fidonet: 1:382/40 - The Antenna Farm BBS
-
- ------------------------------
-
- Date: Saturday, 30 December 1989 15:58-MST
- From: winter@apple.com (Patty Winter)
- Subject: Making things more difficult than necessary (was: Tasco TNC info)
- Message-ID: <KPETERSEN.12555178856.BABYL@WSMR-SIMTEL20.ARMY.MIL>
-
- In article <7238@dtseng.UUCP> rps@dtseng.UUCP (Robert P. Scott) writes:
- >In article <4390094@col.hp.com>, bdale@col.hp.com (Bdale Garbee) writes:
- >> I just go through the
- >> auto-baud routine, then type 'kiss on' followed by 'restart', and it's
- >> in KISS mode until you cycle power on the TNC.
- >I'm curious why you go through this procedure rather than making KISS mode
- >the default. Not knowing this TNC I'm wondering if this is not possible.
-
- All this talk about having to set KISS defaults, MFJ TNCs popping out of
- KISS mode, and the like really has me wondering whether some hams aren't
- making packet radio more difficult than necessary.
-
- I've been running a modified (I substituted a KISS PROM for the original one)
- TAPR TNC-2 with the KA9Q TCP/IP program for nearly two years now. It just
- sits there and purrs along day after day. If I want to check out what's
- happening on a local PBBS or the DX Packet Cluster, I just dial up another
- frequency on my radio and make the necessary connection. When I'm done,
- I disconnect and dial back to the TCP/IP channel.
-
- Sure, I can't receive AMTOR or WEFAX or RTTY, but I'm happily using
- both TCP/IP and AX.25 packet, which is all I wanted in the first place.
- With my little ol' 1-megabyte Macintosh Plus, I'm running NET, BM, and
- TeachText (a simple text editor) all at once under MultiFinder. Within
- NET itself, I have one window to control the program, one for Trace,
- and one for Log if I want it. (Newer versions of NET for the Mac allow
- even more windows.)
-
- So take this as a vote for a back-to-the-basics TNC-2 with a KISS PROM!
- It's cheap, and as far as I'm concerned, it sure does the job.
-
-
- 73,
- Patty
-
- --
- *****************************************************************************
- Patty Winter N6BIS INTERNET: winter@apple.com
- AMPR.ORG: [44.4.0.44] UUCP: {decwrl,nsc,sun}!apple!winter
- *****************************************************************************
-
- ------------------------------
-
- Date: Tue, 2 Jan 90 22:03 EST
- From: "D.RODMAN" <OOPDAVID@ubvmsc.cc.buffalo.edu>
- Subject: SOFTWARE AND HARDWARE FOR RBBS
-
- As a new subscriber to I-PACRAD, I am impressed at the level of information
- passed on this list. Here is a simple question from a packet neophyte, but
- it is hoped that any answer will be serious and substantive.
-
- Would someone pass their suggestions for hardware (IBM) and software that
- will interface with a 2 meter data controller allowing me to run an RBBS
- that will allow me to send some of the I-PACRAD packett info to the local
- boys. Kindly be as specific as possible and all information is greatly
- appreciated.
-
- Thank you.
-
- Dave - KN2M
- BITNET: OOPDAVID@UBVMS
- OMNET: D.RODMAN/OMNET
-
- ------------------------------
-
- End of PACKET-RADIO Digest V90 Issue #2
- ***************************************
- 4-Jan-90 21:26:33-MST,17850;000000000000
- Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
- Date: Thu, 4 Jan 90 21:15:10 MST
- From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
- Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
- Subject: PACKET-RADIO Digest V90 #3
- To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
-
- PACKET-RADIO Digest Thu, 4 Jan 90 Volume 90 : Issue 3
-
- Today's Topics:
- A location is not a route.
- Apple ][ and packet switching
- BBS Network Routing.
- Ham radio names and routing (2 msgs)
- Making things more difficult than necessary (was: Tasco TNC info) (2 msgs)
- Names and Routes
- Strange DIGI operation needed...
- TAPR catalog?
- Tasco TNC info request (was: kiss for heath pocket packet?)
- ----------------------------------------------------------------------
-
- Date: 4 Jan 90 01:08:27 GMT
- From: zephyr.ens.tek.com!tektronix!sequent!mntgfx!hanko@beaver.cs.washington.edu (Hank Oredson @ APD x1325)
- Subject: A location is not a route.
- Message-ID: <1990Jan4.010827.9454@mentor.com>
-
- Note that the "BBS net" addresses are not routes, but locations.
- Routing takes place at the individual servers, and can be based
- on any of the location information, or on the addresses.
- OR.USA.NA is a location, and does not say anything about
- how one could GET there, but just where it is located.
-
- ... Hank - w0rli
-
- ------------------------------
-
- Date: 4 Jan 90 20:35:53 GMT
- From: rti!ntpdvp1!davel@mcnc.org (Dave Livingston)
- Subject: Apple ][ and packet switching
- Message-ID: <329@ntpdvp1.UUCP>
-
- Several of us have been considering the idea of putting my apple ][c up as
- a packet bbs. Anyone have any suggestions as to what software they have
- seen used?
-
- thanks in advance,
-
-
- Dave Livingston Standard Disclaimer Applies
- Northern Telecom - DMS-10
- Research Triangle Park, NC
- EMAIL ...!uunet!mcnc!rti!ntpdvp1!davel
- 919/992-3322
-
- ------------------------------
-
- Date: 4 Jan 90 21:47:59 GMT
- From: zephyr.ens.tek.com!tektronix!sequent!mntgfx!hanko@beaver.cs.washington.edu (Hank Oredson @ APD x1325)
- Subject: BBS Network Routing.
- Message-ID: <1990Jan4.214759.9633@mentor.com>
-
- I've seen a great deal of mis-information recently
- concerning how routing is handled in the "bbs net".
-
- Mostly the folks talking about how it is done do not
- appear to understand the process very well. Some of
- them claim to have a better technique. To those who
- know a better way to do it, please tell me about it.
- If there IS a better way, it will be implemented within
- a few weeks, and will replace the techniques now in use.
-
- i.e. don't tell me I did it wrong unless you are
- prepared to tell me how to do it right.
-
- There is no "source routing" done in the "bbs net".
-
- a LOCATION is not a ROUTE
- an ADDRESS is not a ROUTE
-
- The fact that I'm in OR.USA.NA tells you nothing about
- how to get here, it just tells you where you want to
- end up when you DO get here. There may be many routes
- that satisfy the destination location from any given
- source location. The routing is done at each host in
- whatever route is used. Each host will normally have
- many different routes to chose from when attempting to
- satisfy a given destination location. In one sense,
- you could say that ARP is distributed throughout the
- network, and uses local information to solve local route
- problems.
-
- Remember also that each human has a unique ADDRESS (their
- callsign) and that ADDRESS is attached to a LOCATION via
- the WP process and database. There is nothing here at all
- that speaks to the problem of ROUTING. Only the problem
- of LOCATING has been addressed, ROUTING cannot be solved
- until LOCATING has been solved first.
-
- In the "bbs net" world, each individual is identified as:
-
- USER_ADDRESS@HOST_ADDRESS.LOCATION
-
-
- ... Hank - w0rli
-
- ------------------------------
-
- Date: 3 Jan 90 17:11:48 GMT
- From: pacbell!tandem!kevinr@ames.arc.nasa.gov (Kevin J. Rowett)
- Subject: Ham radio names and routing
- Message-ID: <1990Jan3.171148.13647@tandem.com>
-
- In article <6287#.@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes:
- >
- >In the referenced message, John, KD7UW, writes a lot of common sense.
-
- Jay, What's the "common sense" that you speak of in SOURCE ROUTING?
-
- The quickest problem to point out is what happens to your traffic
- when one of the routers in the path goes away? And how do you discover
- the new path?
-
- N6RCE
-
- ------------------------------
-
- Date: 3 Jan 90 21:26:45 GMT
- From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hp.com (Bdale Garbee)
- Subject: Ham radio names and routing
- Message-ID: <4390105@col.hp.com>
-
- >The problem I see with this whole discussion is the presumption that
- >one set of standards must be applied to all similar problems.
-
- I may have implied this, but it certainly wasn't my intent. The concern I
- have, which I feel is worthy of an "overriding concern" label, is that we the
- amateur packet radio community are small enough in number, that our progress
- is likely to be substantially delayed if we insist on reinventing the wheel
- over and over again, instead of looking around to see what is good, and
- relatively available, before we jump in and "invent a new standard".
-
- It's pretty clear that there are times when nothing out there is good enough,
- and we need to do something different. The RSPF definition strikes me as a
- good example of this. But, in general, the PBBS community is plagued by the
- same problems that I saw while participating in the Fidonet community, etc. A
- bunch of folks with no experience and relatively little visibility to existing
- knowledge about how other folks have done things are far too quick to go off
- and invent something new... typically reiterating the same series of stumbles
- and falls that others have already suffered.
-
- To me, at least, the argument about nameservers is moot. If you come down to
- it, building a nameserver from the existing specs would probably have been an
- easier job than designing and implementing the BBS routing mechanism?
-
- >The problem I see with the RELIGIOUS position of some of the posters is
- >that it denies that there might be other solutions.
-
- It's unfortunate that we frequently fuzz the distinction between well-reasoned
- thought and religion. I'm quite guilty of it, I admit. In many cases, such
- as Brian's, I think it comes from answering the same question two-too-many
- times... The real failing, I think, is that somehow even though we call
- ourselves "communicators", we do a really poor job of communicating. Both on
- the part of those "in the know" who don't work hard enough to spread the word,
- and on the part of the general ham community, which is notorious for being
- more interested in "doing it my way" than in researching existing alternatives.
-
- Sigh.
-
- >BTW for the purposes of mail routing it should be easy enough to create
- >a subdomain "pbbs.ampr.org" if we can set our Religious points-of-view
- >aside.
-
- >kd7uw%nc7f.ut.usa.na@gateway.pbbs.ampr.org
-
- We've talked about this few times. But it really does work just as well to
- do
-
- kd7uw%nc7f.ut.usa.na@nn2z.ampr.org
-
- or equivalent for now, where nn2z is an advertised gateway for the local
- community. The only reason to create a '.pbbs.ampr.org' pseudo-subdomain
- would be to allow constructs of the form
-
- kd7uw@nc7f.ut.usa.na.pbbs.ampr.org
-
- There's a better way to do it. Since a gateway ought to be able to map from
- a callsign to a route, all the SMTP user should have to do is:
-
- kd7uw@nc7f.pbbs.ampr.org
-
- with the gateway understanding that the way to get to nc7f.pbbs.ampr.org is
- via the PBBS network with the full h-address.
-
- I'd almost be willing to accept that, but in reality there's no reason for
- the 'pbbs', as I don't want to have to care, and MX records ought to be able
- to point mail for 'nc7f.ampr.org' to the closest SMTP/PBBS gateway, and the
- gateway again should be keying in on the callsign. So, as far as I'm
- concerned,
-
- kd7uw@nc7f.ampr.org
-
- This is as good as it gets if we treat you as a user of the nc7f system.
-
- If you'll allow me to really dream, why can't I just send mail to you as
-
- john@kd7uw.ampr.org
-
- and let my blooming nameserver recognize that your mail should be routed to
- nc7f.ampr.org, etc? With proper software, nc7f would know that he's a service
- provider for you, and that when he sees mail for 'user@kd7uw.ampr.org', that
- he's expected to dump it into kd7uw's mailbox. Sendmail gets paid to do this
- kind of stuff on my systems all the time...
-
- This brings us back, I believe, to exactly what Brian was complaining about
- to start with. In the Internet community, is is recognized that an address is
- not a route, and therefore a separate "envelope" is maintained by SMTP for each
- "letter" being sent. The address on the envelope is subject to being
- manipulated as part of the mail routing process, in much the same way that the
- USPO frequently stamps a "forward to" address on an envelope, except that with
- electronic mail the stamps tend to be the rule and not the exception. The
- problem with the BBS community's approach, to me at least, is that by not
- recognizing this distinction, they're making it necessary for the sender to
- know more about the actual destination than he should have to, and making it
- more difficult to rationally design software to remove that burden.
-
- Sure, what they have works. But it's not general enough to withstand efforts
- at "internetworking". And, just as the Fidonet community moved from a flat
- address space to a net/host pair, to zone:net/host triples to whatever they
- are doing now, the PBBS community's requirements *will* change, and they aren't
- taking advantage of *existing* knowledge to help insure that they'll be able to
- make those changes gracefully.
-
- I'm all for originality and freedom of expression, but this strikes me as a
- painful waste of a limited resource... packet radio software manpower!
-
- Oops. I got religious again... /o\
-
- 73 - Bdale
-
- ------------------------------
-
- Date: 4 Jan 90 18:04:01 GMT
- From: rochester!rit!cci632!cb@louie.udel.edu (Just another hired gun (n2hkd))
- Subject: Making things more difficult than necessary (was: Tasco TNC info)
- Message-ID: <32944@cci632.UUCP>
-
- In article <10676@ucsd.Edu> brian@ucsd.edu (Brian Kantor) writes:
- >Or if you want to have your cake and eat it too, just solder the kiss
- >prom humping on top of the manufacturer's prom with all the pins except
- ^^^^^^^^^^^^^^^^^^^^^^
- >the chip select soldered together. Run the chip select from the board
- >out to the wiper of a SPDT switch, and two wires back to the proms, and
- >you have front panel control of which prom you're using.
-
- Please note that there are manufacturers out there have have made piggy
- back sockets for ram and rom parts. If you use those then all you have to
- do is connect those (of the socket, not the prom) two chip selects to
- a switch as Brian suggested. This allows for easy prom upgrade....
-
- I don't have my data books handy or I'd leave you with a part number, sorry.
-
- --
-
- email: cb@cci632 or !rochester!kodak!n2hkd!curtis
- Curtis Braun, N2HKD, Computronics, PO Box 1002 Fairport NY, 14450
-
- ------------------------------
-
- Date: 3 Jan 90 21:28:54 GMT
- From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hp.com (Bdale Garbee)
- Subject: Making things more difficult than necessary (was: Tasco TNC info)
- Message-ID: <4390106@col.hp.com>
-
- >So take this as a vote for a back-to-the-basics TNC-2 with a KISS PROM!
- >It's cheap, and as far as I'm concerned, it sure does the job.
-
- Patty, I agree. The problem is that Heath/Tasco don't provide a KISS-only
- EPROM for the "pocket packet", and it's too cute to ignore. :-) And to me,
- at least, since it's one of many TNC's in the shack, it just isn't worth
- writing a variant of the TNC-2 firmware to handle the CTC baud rate generation
- and differing addresses in the Toshiba Z80 monster-chip...
-
- Bdale
-
- ------------------------------
-
- Date: 3 Jan 90 10:47:43 GMT
- From: cs.utexas.edu!samsung!aplcen!wb3ffv!gvdgpc!gvdg@tut.cis.ohio-state.edu (Gerard J van der Grinten PA0GRI)
- Subject: Names and Routes
- Message-ID: <290@gvdgpc.UUCP>
-
- Happy New Year to all.
- Well , it seems (as Brian writes, also in the tcp-group) that
- Names and Routes are still intermixed.
- Please Note:
- Names are NO Routes.
- Also NOTE:
- Routes are no Names.
- The domain stuff uses NAMES. Still a flat name-space and indeed having its
- problems incorporated BUT HAMS live with inperfect solutions.
- (If it was perfect it would not be hammish).
- On the PBBS side CALL@PBBS.COUNTRY.STATE.WORLD.UNIVERSE is not a NAME but
- (SURPRISE.....) a route. Yes, a ROUTE. We as pbbs user have to tell the
- system where it has to go to.
- Please do not mix those XX@YY's with XX@YY's . They look the same but are not.
- Please note the similarity wit STAMPS.
- STAMPS look the same but old stamps have no value to a mailman and new stamps
- have no value(yet) for a collector. Yet both are stamps and look, feel and
- (yes) even are the same.
- For every one connected to (a part of) the Internet , NAMES are unique and
- a route to them can be found trough servers ( i.e. NAMESERVERS). Once you are
- on your own( i.e. outside and not connected to the Internet) , No one can tell
- you how to get "there".
- And those telling that an IP address has no routing info in it has to
- rethink.... Look at 44.137.x.x and YOU KNOW that you have to cross the atlantic
- to reach it. (it does not give a direct beam reading but close.)
- Lets al start this new decade with saying together:
- NAMES are NO ROUTES. (but dammed handy if used that way).
- Regards, gerard.
-
- ------------------------------
-
- Date: Thu, 4 Jan 90 08:50:03 PST
- From: elmquist@nips.ssesco.com
- Subject: Strange DIGI operation needed...
- Message-ID: <9001041450.AA00503@nips.ssesco.com>
-
- I have a need for a strange kind of DIGIpeater operation and I'm
- wondering if it can be done with "off-the-shelf" TNCs and firmware.
-
- I would like a TNC on 2m to have the callsign N0JCF (ie, no SSID).
- I would like a TNC on 70cm to have the callsign N0JCF-x (any SSID
- will do). Both of these TNCs are together at a site remote from
- my QTH. At my QTH I have a third TNC with callsign N0JCF-y (you
- supply another SSID). Now for the tricky part:
-
- I would like a user on 2m to be able to connect to N0JCF and then
- be automatically (without further keystrokes) be connected across
- the 70cm link to the TNC at my QTH. The TNC at my QTH should
- see this as a new connection..(ie, signal any PBBS software that
- a user has just connected). The 2m user can then interact with
- any PBBS software...and if he should disconnect, then the whole
- link will be broken down and ready for another connect.
-
- Am I making any sense? What's the point? well, I want to get
- the 2m packet stuff away from the QTH where I am trying to do
- weak signal 2m SSB and OSCAR stuff. Moving all of the packet
- to 70cm (or maybe 902) would eliminate the desense I am getting
- from the 2m packet transmitter. The majority of my packet buddies
- are all on 2m and I'd like the connection process to my station
- to be as simple as possible (ie, connecting to DIGI, issueing
- another connect request to me is a drag...and they won't talk
- to me anymore.)
-
- Anyone know of a way this could be accomplished? I'm not fully
- up to speed on how NET/ROM or TheNet works...but maybe it
- has an autoconnect mode like I am describing...
-
- 73, Chris N0JCF
-
-
- ------------------------------
-
- Date: 3 Jan 90 21:31:47 GMT
- From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hp.com (Bdale Garbee)
- Subject: TAPR catalog?
- Message-ID: <4390107@col.hp.com>
-
- >Just wondering if there is a TAPR catalog available that would list
- >the projects they currently have available. If so, does anyone have
- >a phone number or address they should be contacted at--?
-
- Join TAPR, which is cheap, and will get you a subscription to PSR, the
- newsletter. Each of the last several issues have had a catalog/orderform
- thingy in them, which would solve your problem nicely. All of the funds above
- and beyond those required to publish the newsletter go into TAPR research
- projects...
-
- TAPR
- PO Box 12925
- Tucson, AZ 85732
- (602) 323-1710
-
- 73 - Bdale, N3EUA -- TAPR VP
-
- ------------------------------
-
- Date: 3 Jan 90 20:47:02 GMT
- From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hp.com (Bdale Garbee)
- Subject: Tasco TNC info request (was: kiss for heath pocket packet?)
- Message-ID: <4390104@col.hp.com>
-
- >> I just go through the
- >> auto-baud routine, then type 'kiss on' followed by 'restart', and it's
- >> in KISS mode until you cycle power on the TNC.
- >I'm curious why you go through this procedure rather than making KISS mode
- >the default. Not knowing this TNC I'm wondering if this is not possible.
-
- If someone gives me step-by-step instructions, I might. I only use the tiny
- TNC when I'm portable, and that's not very often, so the effort to understand
- (again, it's been a long time) how non-KISS TNC's work well enough to make the
- bleeping thing do what I want has seemed excessive.
-
- What I really want, but won't spend the time to do since I have a ROM that
- pretty much does the right thing, is a KISS-only ROM for the tiny....
-
- I *always* run KISS mode when forced to use a TNC. Period.
-
- Bdale
-
- ------------------------------
-
- End of PACKET-RADIO Digest V90 Issue #3
- ***************************************
- 6-Jan-90 05:23:36-MST,13502;000000000000
- Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
- Date: Sat, 6 Jan 90 05:15:24 MST
- From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
- Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
- Subject: PACKET-RADIO Digest V90 #4
- To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
-
- PACKET-RADIO Digest Sat, 6 Jan 90 Volume 90 : Issue 4
-
- Today's Topics:
- BBS Network Routing.
- dsy modem article
- FTPable G8BPQ?
- Grapes on Duplex Repeat
- header compression in ka9q?
- Information on TNC boards requested.
- Making things more difficult than necessary (was: Tasco TNC info)
- RF Tight Boxes (2 msgs)
- Strange DIGI operation needed...
- What is HAMSTER?
- ----------------------------------------------------------------------
-
- Date: 5 Jan 90 19:12:19 GMT
- From: eru!luth!sunic!sics.se!sics.se!klemets@bloom-beacon.mit.edu (Anders Klemets)
- Subject: BBS Network Routing.
- Message-ID: <KLEMETS.90Jan5201219@shai.sics.se>
-
- Hank W0RLI writes:
- > To those who know a better way to do it, please tell me about it.
-
- Ok, here goes. The routing designators are currently parsed from left to
- right. This causes JA1KSO.42.JPN.AS to match wild-card ZIP codes, such
- as 42*. You solve the problem by stating that all fields below the state
- or province level should be prefixed by a #-sign. This makes the whole
- scheme look like a kludge!
-
- You can work around this problem by making the BBS aware of its own full
- hierarchical location. Then just parse the routing designators from the
- right to the left, instead of the other way around.
- Suppose you are W0BBS.NOCAL.CA.US.NA. If you get a message for
- K1BBS.SOCAL.CA.US.NA your parser should not bother about the right-most fields
- that are common to both addresses. The BBS would first search the forwarding
- file for entries matching K1BBS and K1BBS.SOCAL. If no matching entry is
- found, the left-most field is stripped off. In this example the fwd file would
- be searched for SOCAL.
-
- If the same BBS as in the previous example gets a message for JA1KSO.42.JPN.AS
- the forwarding file would first be searched for the full address, or if that
- fails the BBS would try to find 42.JPN.AS, JPN.AS, and finally only AS.
-
- Incomplete addresses can also be handled appropriately. In the example above,
- a message for W0XX.42 would be treated as W0XX.42.CA.US.NA since 42 does
- not match any known state, country or continent designator.
-
- As an aside, the users of BBS-systems should demand that mail to foreign
- stations should be sent to the right gateway even if no routing information
- at all is supplied. It is miserable that a BBS user should have to help
- the computer with the mapping of prefixes to country and continent designators.
- Computers should help us, and not the other way around. A good start would
- be by letting the BBS derive any country and continent designators it needs
- by looking at a prefix table. The prefix table would not take more than a
- few kilobytes of disk space if it is encoded properly, and would seldom need
- to be changed.
-
- 73, Anders
- --
- klemets@sics.se / SM0RGV
-
- ------------------------------
-
- Date: 5 Jan 90 10:39:57 GMT
- From: zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!phil@tut.cis.ohio-state.edu
- Subject: dsy modem article
- Message-ID: <30600028@ux1.cso.uiuc.edu>
-
- I looked for the HR article about the WA4DSY modem and could not find it.
- Can someone point me to where it is?
-
- --Phil Howard, KA9WGN--
- <phil@ux1.cso.uiuc.edu>
-
- ------------------------------
-
- Date: 3 Jan 90 14:14:57 GMT
- From: mitel!sce!cognos!dgbt!barry@uunet.uu.net (Barry McLarnon DGBT/DIP)
- Subject: FTPable G8BPQ?
- Message-ID: <1344@dgbt.uucp>
-
- From article <14564@orstcs.CS.ORST.EDU>, by batesm@mist.CS.ORST.EDU (Mike Bates):
- > Where can a person FTP the latest release of the
- > G8BPQ software?
-
- Try tomcat.gsfc.nasa.gov [128.183.10.100]. The latest 'n greatest (3.53)
- is available there now.
-
- > Also, any ideas when the software will be available on ROM?
-
- Nope, but I didn't get the impression from the latest release notes that
- this was high on his priority list just now.
-
- > Thanks Mike Bates, KF7DQ
- > batesm@mist.cs.orst.edu
- > KF7DQ@KA7VQD
-
- Barry VE3JF
-
- --
- Barry McLarnon Communications Research Center Ottawa, ON Canada
- UUCP: ...utzoo!bnr-vpa!bnr-rsc!dgbt!barry INTERNET: barry@dgbt.crc.dnd.ca
- Compu$erve: 71470,3651 Packet radio: VE3JF @ VE3JF
-
- ------------------------------
-
- Date: 5 Jan 90 00:20:15 GMT
- From: usc!cs.utexas.edu!helps!bongo!julian@apple.com (julian macassey)
- Subject: Grapes on Duplex Repeat
- Message-ID: <288@bongo.UUCP>
-
- Late last year someone on this newsgroup mentioned that they had
- a repeater running the GRAPES 56KB packet modem. Details were
- supposed to be forthcoming. Any news on the horizon?
-
- Yours
- --
- Julian Macassey, n6are julian@bongo.info.com {ucla-an!denwa!bongo!julian
- N6ARE@K6IYK (Packet Radio) n6are.ampr.org [44.16.0.81] voice (213) 653-4495
-
- ------------------------------
-
- Date: 5 Jan 90 19:11:07 GMT
- From: wuarchive!zaphod.mps.ohio-state.edu!samsung!shadooby!umich!itivax!b-tech!zeeff@decwrl.dec.com (Jon Zeeff)
- Subject: header compression in ka9q?
- Message-ID: <98JF4@b-tech.uucp>
-
- Has anyone put VanJacobson's header compression code into the ka9q net.exe
- software (either version)? It seems like a big win for slip links.
-
- --
- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us or b-tech!zeeff
-
- ------------------------------
-
- Date: 5 Jan 90 22:19:40 GMT
- From: shelby!cascade!faheem@decwrl.dec.com (Faheem Akram)
- Subject: Information on TNC boards requested.
- Message-ID: <1333@cascade.Stanford.EDU>
-
- An article entitled "Starter Packet" in the November issue of CQ explains how
- to get started in Packet Radio. It gives information on many things but there
- is nothing in the way of a recommendation of a suitable TNC board. The only
- thing I could gather from the article in this respect is that there is
- something called a TAPR-2 which also has many clones. I would appreciate
- if any who have experience with packet radio will provide me some
- answers to the following questions.
- 1. What is TAPR-2?
- 2. What is a suitable TNC board that can be plugged into an IBM PC-XT?
- Is there a survey article that reviews a bunch of TNC boards and if
- so can you please provide me the reference?
- 3. Is a modem also needed besides the TNC board or is the modem on the
- TNC board?
- 4. I have used the Procomm software with my modem. Besides Procomm, there
- are others viz. BOBCOM,MFJCOMM,MFJXER,PACFILE,PACPRO,PTP, and YAPP listed
- in the above mentioned article. Again is there a survey article covering
- and comparing these programs? If so please give me the reference. If not,
- which one is reasonbly priced and good. Or is Procomm sufficient?
-
- My thanks in advance.
- Sincerely,
-
- Faheem Akram
-
- ------------------------------
-
- Date: 4 Jan 90 14:37:06 GMT
- From: mitel!sce!cognos!dgbt!barry@uunet.uu.net (Barry McLarnon DGBT/DIP)
- Subject: Making things more difficult than necessary (was: Tasco TNC info)
- Message-ID: <1345@dgbt.uucp>
-
- From article <1004@rsiatl.UUCP>, by jgd@rsiatl.UUCP (John G. De Armond):
- > In article <10676@ucsd.Edu> brian@ucsd.edu (Brian Kantor) writes:
- >>Or if you want to have your cake and eat it too, just solder the kiss
- >>prom humping on top of the manufacturer's prom with all the pins except
- >>the chip select soldered together. Run the chip select from the board
- >>out to the wiper of a SPDT switch, and two wires back to the proms, and
- >>you have front panel control of which prom you're using.
- >
- > And, if you do the same thing to the RAM, use a DPDT switch and use the other
- > side to switch the CS line on the RAM, you can even save your AX25 setup
- > parameters.
- >
- > we've been running 'em like this for years around here.
- >
- > TIP: To solder the piggyback chip in place, coat the inside of each leg
- > with surface mount flux-solder paste, mount and sweat in place with either
- > hot air (prefered) or a quick swipe with a soldering iron. Be sure to
- > bend the CS lead up, of course.
-
- Or, yet another possibility: To avoid messy soldering (on the EPROM, at
- least), obtain a 27C512 and copy your original ROM into one half of the
- 64K address space, and KISS into the other half. Then use the switch as
- a ROM select by changing the state of the A14 line.
-
- But I still like Patty's solution the best! :-)
-
- > John
-
- Barry
-
- --
- Barry McLarnon Communications Research Center Ottawa, ON Canada
- UUCP: ...utzoo!bnr-vpa!bnr-rsc!dgbt!barry INTERNET: barry@dgbt.crc.dnd.ca
- Compu$erve: 71470,3651 Packet radio: VE3JF @ VE3JF
-
- ------------------------------
-
- Date: 5 Jan 90 00:33:22 GMT
- From: samsung!uakari.primate.wisc.edu!uwm.edu!cs.utexas.edu!helps!bongo!julian@think.com (julian macassey)
- Subject: RF Tight Boxes
- Message-ID: <289@bongo.UUCP>
-
- Back in the old days when FETs had not been invented and you had
- to use tubes if you wanted high impedance circuitry, finding an
- RF tight box was easy. Back then, pipe tobacco came in metal
- boxes and many items were distributed in tin plate containers.
- Brits may recall "OXO tins". Nowadays, boxes sold or used as
- containers are all plastic - handy to store stuff or build non
- crit circuits - useless for RF shielding.
-
- What I need is a source of "free" RF tight boxes. Hamtronics
- will sell me a 7 X 8 X 2 (ins) box for $30! This is about the
- size of an OXO tin and they came free if you purchased all the
- bouillon cubes inside them. The Hamtronics box is aluminium and
- hard to solder to, the OXO tin was tinplate.
-
- Any ideas out there?
- --
- Julian Macassey, n6are julian@bongo.info.com {ucla-an!denwa!bongo!julian
- N6ARE@K6IYK (Packet Radio) n6are.ampr.org [44.16.0.81] voice (213) 653-4495
-
- ------------------------------
-
- Date: 5 Jan 90 21:42:39 GMT
- From: amdcad!positron!brian@ucbvax.Berkeley.EDU (Brian McMinn)
- Subject: RF Tight Boxes
- Message-ID: <28643@amdcad.AMD.COM>
-
- In article <289@bongo.UUCP> julian@bongo.UUCP (julian macassey) writes:
- |
- | What I need is a source of "free" RF tight boxes.
-
- Around about Christmas time each year, you can get tins of butter
- cookies. Most of the tins are round :-(, but some cookies (especially
- Scottish Shortbread -- YUM!) come in relatively square tins. Sizes
- range, but 8" x 8" x 2" is about average. They are usually made of
- tin plated steel. I've never used one as an RF shield, but I have
- turned them over and "air boarded" simple circuits on them.
-
- Air boarding: Didja ever notice that them little components come with
- 2 to 3 centimeter leads on 'em? Well, them ain't leads, thems just
- real short wires! Air boarding is 3-d breadboarding without the
- breadboard. (You just solder the leads together.) (UGH!)
-
- Brian
- Brian McMinn brian@neptune.AMD.COM
- Advanced Micro Devices N5PSS
- Austin, Texas 1-(512)-462-5389
-
- ------------------------------
-
- Date: 6 Jan 90 03:00:56 GMT
- From: n8emr!gws@tut.cis.ohio-state.edu (Gary Sanders)
- Subject: Strange DIGI operation needed...
- Message-ID: <1399@n8emr.UUCP>
-
- In article <9001041450.AA00503@nips.ssesco.com> elmquist@NIPS.SSESCO.COM writes:
- >I have a need for a strange kind of DIGIpeater operation and I'm
- >wondering if it can be done with "off-the-shelf" TNCs and firmware.
- >
- >I would like a TNC on 2m to have the callsign N0JCF (ie, no SSID).
- >I would like a TNC on 70cm to have the callsign N0JCF-x (any SSID
- >will do). Both of these TNCs are together at a site remote from
- >my QTH. At my QTH I have a third TNC with callsign N0JCF-y (you
- >supply another SSID). Now for the tricky part:
-
- Well I think you can do the 2 freq gateway with only one
- standard tnc, A couple of guys around here have had gateways running
- from 220(novice band ) to 2 meter pbbs frequency. Although not the
- best way to manage spectrum space it will work.
-
-
- 2 meter speaker out -\ /- 2 meter mic in
- ==== TNC ===
- 70 cm speaker out -/ \- 70cm mic in
-
- anyone digipeating through either side will be digited
- on the both sides of the gateway.. One TNC, one callsign 2 freq,
- no additional operator intervention aside from a normal digipeat
- command.
-
- 73......
-
-
-
- --
- Gary W. Sanders (gws@n8emr or ...!osu-cis!n8emr!gws), 72277,1325
- N8EMR @ W8CQK (ip addr) 44.70.0.1 [Ohio AMPR address coordinator]
- HAM/SWL/SCANNER BBS (1200/2400/PEP) 614-457-4227
- Voice: 614-457-4595 (eves/weekends)
-
- ------------------------------
-
- Date: 5 Jan 90 16:24:15 GMT
- From: usc!cs.utexas.edu!natinst!rpp386!puzzle!khijol!erc@apple.com (Edwin R. Carp)
- Subject: What is HAMSTER?
- Message-ID: <887@khijol.UUCP>
-
- What is HAMSTER? I assume it's a BBS. What's the phone number/login sequence?
-
- Thanks for any information.
-
- Anybody know of any other BBS's, especially in Texas, that have radio mod info?
- --
- Ed Carp N7EKG/5 (28.3-28.5) uunet!cs.utexas.edu!khijol!erc
- Austin, Texas (512) 832-5884 "Good tea. Nice house." - Worf
- *** Did you know that Barbie Benton PLAYS THE PIANO?? Quite well, too! ***
-
- ------------------------------
-
- End of PACKET-RADIO Digest V90 Issue #4
- ***************************************
- 8-Jan-90 10:23:53-MST,10800;000000000000
- Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
- Date: Mon, 8 Jan 90 10:15:52 MST
- From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
- Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
- Subject: PACKET-RADIO Digest V90 #5
- To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
-
- PACKET-RADIO Digest Mon, 8 Jan 90 Volume 90 : Issue 5
-
- Today's Topics:
- A location is not a route.
- BBS Network Routing.
- Ham radio names and routing (2 msgs)
- KA9Q TCP/IP package
- Routing Question
- Strange DIGI operation needed...
- WA4DSY Duplex Repeater Info
- ----------------------------------------------------------------------
-
- Date: 5 Jan 90 05:41:56 GMT
- From: hp-pcd!hplsla!hpubvwa!johnh@hplabs.hp.com (John Hays)
- Subject: A location is not a route.
- Message-ID: <2910004@hpubvwa.NSR.HP.COM>
-
- How true, Hank...
-
- I didn't know you landed at mentor.
-
- John Hays KD7UW
-
- ------------------------------
-
- Date: 8 Jan 90 08:49:04 GMT
- From: eru!luth!sunic!mcsun!ukc!axion!news@bloom-beacon.mit.edu (Brian Lloyd)
- Subject: BBS Network Routing.
- Message-ID: <1990Jan8.084904.28352@axion.bt.co.uk>
-
- From article <KLEMETS.90Jan5201219@shai.sics.se>, by klemets@sics.se (Anders Klemets):
- > As an aside, the users of BBS-systems should demand that mail to foreign
- > stations should be sent to the right gateway even if no routing information
- > at all is supplied. It is miserable that a BBS user should have to help
- > the computer with the mapping of prefixes to country and continent designators.
- > Computers should help us, and not the other way around. A good start would
- > be by letting the BBS derive any country and continent designators it needs
- > by looking at a prefix table. The prefix table would not take more than a
- > few kilobytes of disk space if it is encoded properly, and would seldom need
- > to be changed.
- >
- > 73, Anders
- There is some software which is now widely used in the UK and is spreading
- to Europe which does this, and is written by yours truly. If no routing
- information other than the destination BBS is given when a user sends a
- message, the BBS looks up a file on disk and adds as much information as it
- can. As a bare minimum, it can work out that a G callsign needs .GBR.EU
- added, a W, K, A etc needs .USA.NA added, etc. Further details can be
- added to the lookup file as necessary.
- Brian
- ###########################################################################
- What? No silicon heaven? Ludicrous! Where would all the calculators go?
- Brian Lloyd, # Via e-mail : blloyd@axion.bt.co.uk
- RT3152, Rm G44, SSTF, # Via Packet : G1NNA @ GB7NNA.GBR.EU
- British Telecom Research Labs, # By Phone : +44 (0)473 646650
- Martlesham Heath, Ipswich, Suffolk. IP5 7RE
-
- ------------------------------
-
- Date: 5 Jan 90 05:51:58 GMT
- From: hp-pcd!hplsla!hpubvwa!johnh@hplabs.hp.com (John Hays)
- Subject: Ham radio names and routing
- Message-ID: <2910005@hpubvwa.NSR.HP.COM>
-
- Sorry about the weird sentence structure and possible spelling and
- punctuation errors in the last posting. VI is a little choppy when my
- 2400 baud modem is connected to a local host and then runs through PEP
- at 9600 baud to a remote host.
-
- John
-
- ------------------------------
-
- Date: 5 Jan 90 05:36:40 GMT
- From: hp-pcd!hplsla!hpubvwa!johnh@hplabs.hp.com (John Hays)
- Subject: Ham radio names and routing
- Message-ID: <2910003@hpubvwa.NSR.HP.COM>
-
- I have been reading all of this talk about "source routing" evils
- and so on.
-
- I am a user of both NOS and MSYS1.06 at my shack (as well as BSD4.3
- IP ala Domain/OS) ...
-
- In my NOS config I have several statements like
-
- route add 44.70.0.0/16 n4pcr 1
-
- (same on my Msys IP side of hings)
-
- For BBS "H" routing I have statements like
-
- "IL" in route table for nc7f (the next PBBS east of me) ...
-
- n4pcr probably has some route statement to some other host for
- "44.70.0.0" ... and so on.
-
- nc7f sends "IL" traffic to a station colorado or to an HF gateway ... I
- don't know and I don't really care.
-
- So if I want to SMTP or Telnet etc. to someone in ILlinois, it goes
- through a routed station in the Chicago area ... I know the first HOP
- in the path ... but not the rest, nor should I need to know or care.
-
- If I want to send a piece of traffic or bulletin to IL ... I can
- address it to "DEST@CALLSIGN" which gets converted to
- "DEST@CALLSIGN.IL.USA.NA" and once it leaves my station I don't know how
- or care how it is delivered (I just want it delivered).... I can also
- list the "IL" destination on several host routes and it will be sent by
- the first available (have I hard time in NOS in figuring out how to do
- this.. anyone worked it out N4PCR-1 NET/ROM only shows up occasionally
- [via a wormhole in california somewhere]) ....
-
- SO WHAT'S THE BIG DIFFERENCE?
-
- I like IP better because it is a standard I can use to connect to real
- computers (like my Apollo Unix box) but I am able to move a lot more
- information (today) to remote sites using the BBS "H" forwarding system.
-
- I think there is room for both.
-
- Also, my comments concerning the "RELGIOUSITY" of certain individuals is
- not meant to "deny them first amendment rights", it is that this
- attitude has created a dictatorship of the "AMPR.ORG" domain and Network
- "44" ... This dictatorial attitude prevents any democratic aproach to
- the question of subdomains, administrative subnetworks which can use
- geography for pragmatic reasons (eventhough you see geographic subnets
- in internets all the time), summary decisions to allocate less that full
- byte subnets without user input, etc. (I found the DIETY, MOTHER, and
- ADDRESS analogy very telling).
-
- I have a dream of someday "AMPRNET" becoming a network whose policies
- are not dictated but openly discussed by representatives of all the
- services which fall under the Amateur Packet Radio umbrella and that
- various needs can be met through an open process. I would say that a
- majority of users just want Email and Bulletin services, lets make the
- path easy between them and those who want the higher services of
- networks like IP.
-
- 73 es CUL,
- John KD7UW
- kd7uw@kd7uw.ut.usa.na (44.40.1.3)
- hays@apollo.hp.com
-
- ------------------------------
-
- Date: 6 Jan 90 16:32:00 GMT
- From: modcomp!dan@uunet.uu.net
- Subject: KA9Q TCP/IP package
- Message-ID: <97400001@modcomp>
-
- I'm looking for the KA9Q TCP/IP package for the Amiga or IBM/PC.
- I'd appreciate any tips, pointers, etc. on how to find it.
-
- -73- de Dan, N4IXP
-
- 305 977 1558
-
- ------------------------------
-
- Date: 8 Jan 90 05:06:26 GMT
- From: zephyr.ens.tek.com!tekig5!dwightj@uunet.uu.net (Dwight L. Johnson)
- Subject: Routing Question
- Message-ID: <5318@tekig5.PEN.TEK.COM>
-
- --------------------------
- Hi All,
-
- I recently bought a packet radio board for my computer and would like to
- know how to route messages from Santa Rosa, CA. to Hillsboro, OR. and visa-
- versa. I would appreciate any help as I am as green as green gets.
-
- Thanx in advance, Roy Harder N6HJT, Santa Rosa, CA.
- Phone: 1-707-538-5756
-
- ------------------------------
-
- Date: 7 Jan 90 04:52:38 GMT
- From: brian@ucsd.edu (Brian Kantor)
- Subject: Strange DIGI operation needed...
- Message-ID: <10860@ucsd.Edu>
-
- Paralleling the speakers of two receivers into one TNC just about
- guarantees that you'll run into hidden-station collisions. You can
- resolve this by having one receiver have priority over the other
- (i.e., it mutes the other receiver), but that still causes problems.
-
- I think your problem is better solved by having a remote-base - that is,
- you have a 444 MHz link from your station to the 2m radio, and a 449 MHz
- link back from the 2m radio to your station. You can do this with a
- total of three TNCs if you want the link to be all digital, or you can
- do it with just one if you want the link to be audio. Add some smarts
- at the remote site and you can even have the distant 2m radio be
- frequency-agile.
-
- Remote bases like this are real common in So California, although not
- for the reasons you want to do it. The first one is reputed to have
- gone on the air in 1956 or thereabouts, so it's not exactly a new idea.
- There are more than 500 of them in Los Angeles and points south.
- - Brian
-
- ------------------------------
-
- Date: Sat, 6 Jan 90 19:08:27 EST
- From: DYUILL@CARLETON.CA
- Subject: WA4DSY Duplex Repeater Info
- Message-ID: <900106.20051647.010645@CU.CP6>
-
- Julian Macassey Writes:
- >someone on this newsgroup mentioned that they had a repeater running the
- >GRAPES 56KB packet modem. Any details?
-
- The packet working group here in Ottawa has assembled and tested a repeater
- based on the DSY modem. It uses a regenerative design, ie: after down
- conversion from 220Mhz to 28Mhz on the repeater input the signal is fed
- into the DSY modem for demodulation, the synchronous output from the modem
- is fed into a shift register which is used to buffer the data as the modem
- uses seperate clocks for the modulator/demodulator. After buffering the
- data is sent back out to the modulator, the 28Mhz modem output is up
- converted to 70cm (10w) and voila| The advantage to our design is that we
- "siphon off" the bits after demodulation so we can feed them to our IP
- router/gateway/nameserver/network wonder object thereby allowing us to
- have a node at our repeater site without investing in another DSY modem.
- Also, operating split band eliminates the need for a duplexer and the
- carrier detect in the modem comes in handy for keying the repeaters xmiter.
- I understand that Phil Karn is working on a linear translator which of
- course does not require a DSY modem at the repeater site. It also may
- reduce the chance of packet collisions.
- While a regenerative design does increase the chance of packet collisions
- by introducing additional time for carrier detect through the repeater,
- early tests show that no increase in txd is required over a half duplex
- DSY modem. Also the full duplex design of the repeater will allow some
- clever programmer to write a driver for NET that checks for packet
- collisions in real time, which should make up for the slower carrier
- detect.
- Write to Barry, VE3JF for information on his design of the regeneration
- shift register. All the rest of it is pretty much off the shelf..
- Well you DO need to assemble the modem from a kit..
- Our site visit for installing all of the above is tomorrow. User testing
- to follow.
- --dy
- Doug Yuill, VE3OCU@VE3F, Ottawa or DYUILL@CARLETON.CA
-
- ------------------------------
-
- End of PACKET-RADIO Digest V90 Issue #5
- ***************************************
- 9-Jan-90 10:56:50-MST,7638;000000000000
- Mail-From: KPETERSEN created at 9-Jan-90 10:52:24
- Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
- Date: Tue, 9 Jan 90 10:52:24 MST
- From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
- Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
- Subject: PACKET-RADIO Digest V90 #6
- To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
-
- PACKET-RADIO Digest Tue, 9 Jan 90 Volume 90 : Issue 6
-
- Today's Topics:
- BBS Network Routing.
- dsy modem article
- Problem with Pk-232 MBX upgrade
- REMOTE STATION CONTROL
- Used PK-232 Price?
- What is HAMSTER? (2 msgs)
- ----------------------------------------------------------------------
-
- Date: 8 Jan 90 17:15:00 GMT
- From: pacbell!tandem!kevinr@ames.arc.nasa.gov (Kevin J. Rowett)
- Subject: BBS Network Routing.
- Message-ID: <1990Jan8.171500.5201@tandem.com>
-
- In article <1990Jan4.214759.9633@mentor.com> hanko@mentor.com (Hank Oredson @ APD x1325) writes:
- >
- > Remember also that each human has a unique ADDRESS (their
- > callsign) and that ADDRESS is attached to a LOCATION via
- > the WP process and database. There is nothing here at all
- > that speaks to the problem of ROUTING. Only the problem
- > of LOCATING has been addressed, ROUTING cannot be solved
- > until LOCATING has been solved first.
- >
- > In the "bbs net" world, each individual is identified as:
- >
- > USER_ADDRESS@HOST_ADDRESS.LOCATION
- >
- >
- > ... Hank - w0rli
-
-
- COULD someone please clarify the difference (in terms of
- how it affects BBSs) between a LOCATION and an ADDRESS?
-
- Understanding this seems fundamental to why
-
- K3MC.CA.NA is necessary over just 'K3MC'. Although so
- Mike can have more than one thing, I'd allow bbs.K3MC.ampr.org.
-
- N6RCE
-
- ------------------------------
-
- Date: 8 Jan 90 17:30:44 GMT
- From: pacbell!tandem!kevinr@ames.arc.nasa.gov (Kevin J. Rowett)
- Subject: dsy modem article
- Message-ID: <1990Jan8.173044.5328@tandem.com>
-
- In article <30600028@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu writes:
- >
- >I looked for the HR article about the WA4DSY modem and could not find it.
- >Can someone point me to where it is?
- >
- >--Phil Howard, KA9WGN--
- ><phil@ux1.cso.uiuc.edu>
-
-
- The Oct '89 issue of 73 had a EXCELLENT article on the DSY modems
- by Phil. If you get one, please pay particular attention to his
- note about the clock recovery fix.
-
- N6RCE
-
- ------------------------------
-
- Date: 8 Jan 90 22:27:33 GMT
- From: cs.utexas.edu!samsung!sol.ctr.columbia.edu!sdsu!ucselx!sunstroke.sdsu.edu!amagnet@tut.cis.ohio-state.edu (Andrew Magnet)
- Subject: Problem with Pk-232 MBX upgrade
- Message-ID: <4270@ucselx.sdsu.edu>
-
- I just installed my MBX upgrade and now have problems connecting
- to other stations. It will let me connect (sometimes) but it
- doesn't let me stay connected very long i.e., it disconnects me
- within 2 minutes. I changed the custom command from $A015 to $A014
- because someone said it worked for them. Well, neither work
- for me. Now the lights on the front start flashing and then I get
- a RS-232 link broken message. Sometimes it lets me run the software
- and other times it tells me that there is no link. This even
- happens when I don't even touch the keyboard...it will happen by
- itself within 5 minutes of bootup.
-
- I'm running my Pk-232(MBX) with a IBMPC-XT with the PC-PAKRATT
- software. It worked fine for about a year without problems
- before the upgrade was installed. Also, I did not install
- the battery that came with the upgrade.
-
- Can anyone help me that may have had a similar problem?
-
- Respond to amagnet@sunstroke.sdsu.edu
-
- TNX
- Andy Magnet (N6OSR)
-
- ------------------------------
-
- Date: Tue, 9 Jan 90 08:29 EST
- From: "D.RODMAN" <OOPDAVID@ubvmsc.cc.buffalo.edu>
- Subject: REMOTE STATION CONTROL
-
- Would anyone have experience with use of packet, telephone or microwave
- link to control an HF station by computer at a remote location?
-
- Thanks and 73,
- Dave
-
- ------------------------------
-
- Date: 9 Jan 90 00:43:02 GMT
- From: zephyr.ens.tek.com!tekcrl!tekgvs!jans@uunet.uu.net (Jan Steinman)
- Subject: Used PK-232 Price?
- Message-ID: <6631@tekgvs.LABS.TEK.COM>
-
- (Reply bounced.)
- ----- Transcript of session follows -----
- <<< RCPT To:<charlie%oakhill@cs.utexas.edu>
- <<< DATA
- 550 <charlie%oakhill@cs.utexas.edu>... Host unknown
-
- ----- Unsent message follows -----
- Posted-Date: Mon, 8 Jan 90 10:45:35 PST
- Received-Date: Mon, 8 Jan 90 17:05:10 CST
- Received: from RUTGERS.EDU by cs.utexas.edu (5.59/1.46)
- id AA04031; Mon, 8 Jan 90 17:05:10 CST
- Received: from ogicse.UUCP by rutgers.edu (5.59/SMI4.0/RU1.3/3.05) with UUCP
- id AA16227; Mon, 8 Jan 90 18:05:01 EST
- Received: by cse.ogi.edu
- (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
- 14:15:47 -0800 Received: by tektronix.TEK.COM (5.51/7.1)
- id AA01195; Mon, 8 Jan 90 11:00:55 PST
- Received: by tekirl.labs.tek.com (5.51/7.1)
- id AA08036; Mon, 8 Jan 90 06:45:22 PST
- Received: by stammer.LABS.TEK.COM (5.17/6.24)
- id AA02926; Mon, 8 Jan 90 10:45:36 PST
- From: jans@stammer.labs.tek.com (Jan Steinman)
- Message-Id: <9001081845.AA02926@stammer.LABS.TEK.COM>
- Date: Mon, 8 Jan 90 10:45:35 PST
- To: oakhill!charlie@cs.utexas.edu (Charlie Thompson)
- Subject: Re: Used PK-232 Price?
- In-Reply-To: Your Message of 6 Jan 90 04:07:31 GMT
-
-
- <Does anybody know what a used PK-232 goes for? Is $200 too much? What about
- PK-FAX? what's the price for this software (used version).>
-
- I just bought one for $200, which I thought fair. Ask about the ROM version.
- The oldest ones don't have FAX, older ones don't have NAVTEX, the brand new
- ones have MBOX.
-
- Be careful about PK-FAX. It won't run on my GRiD 100% compatible, and may not
- work on others.
-
- Jan Steinman - N7JDB
- Tektronix Electronic Systems Laboratory
- Box 500, MS 50-370, Beaverton, OR 97077
- (w)503/627-5881 (h)503/657-7703
-
- Jan Steinman - N7JDB
- Tektronix Electronic Systems Laboratory
- Box 500, MS 50-370, Beaverton, OR 97077
- (w)503/627-5881 (h)503/657-7703
-
- ------------------------------
-
- Date: 8 Jan 90 01:39:13 GMT
- 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
- Subject: What is HAMSTER?
- Message-ID: <30600029@ux1.cso.uiuc.edu>
-
- Originally from MBramwel@business.uwo.CA
-
- > The mods database is now available through the internet.
- >
- > IP address: 129.100.22.100 HAMSTER.business.uwo.ca
- >
- > If you want to post a file, please email it to me.
- >
- > A separate copy is stored on the IBM 4381 for mail users, therefore
- > I need to know if a new file comes in.
- >
- > Enjoy, let me know if you have any problems.
-
- --Phil Howard, KA9WGN--
- <phil@ux1.cso.uiuc.edu>
-
- ------------------------------
-
- Date: 8 Jan 90 14:41:10 GMT
- From: sun-barr!newstop!texsun!texbell!uudell!natinst!rpp386!puzzle!khijol!erc@lll-winken.llnl.gov (Edwin R. Carp)
- Subject: What is HAMSTER?
- Message-ID: <922@khijol.UUCP>
-
- In article <30600029@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu writes:
- >
- >> IP address: 129.100.22.100 HAMSTER.business.uwo.ca
-
- Yes, but is it available via uucp/dialup?
- --
- Ed Carp N7EKG/5 (28.3-28.5) uunet!cs.utexas.edu!khijol!erc
- Austin, Texas (512) 832-5884 "Good tea. Nice house." - Worf
- *** Did you know that Barbie Benton PLAYS THE PIANO?? Quite well, too! ***
-
- ------------------------------
-
- End of PACKET-RADIO Digest V90 Issue #6
- ***************************************
- 9-Jan-90 22:18:34-MST,12675;000000000000
- Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
- Date: Tue, 9 Jan 90 22:15:11 MST
- From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
- Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
- Subject: PACKET-RADIO Digest V90 #7
- To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
-
- PACKET-RADIO Digest Tue, 9 Jan 90 Volume 90 : Issue 7
-
- Today's Topics:
- AX25 Protocol
- Ham radio names and routing (2 msgs)
- Making things more difficult than necessary (was: Tasco TNC info)
- PBBS forwarding via dialup modem?
- Stolen radio
- Updates to NOS 900105 from Russ and me.
- ----------------------------------------------------------------------
-
- Date: 9 Jan 90 23:07:11 GMT
- From: shlump.nac.dec.com!koning.dec.com!koning@decwrl.dec.com (Paul Koning)
- Subject: AX25 Protocol
- Message-ID: <7335@shlump.nac.dec.com>
-
- In article <164@raider.MFEE.TN.US>, root@raider.MFEE.TN.US (Bob Reineri)
- writes:
-
- > Could some kind soul out there mail me the specs for the AX.25 protocol, or
- > point me to where I could download them ??
-
- You can buy it from ARRL for a few dollars. Have fun, and don't trip over the
- bugs in the spec...
-
- paul, ni1d
-
- ------------------------------
-
- Date: 9 Jan 90 22:02:05 GMT
- From: zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!splut!jay@tut.cis.ohio-state.edu (Jay "you ignorant splut!" Maynard)
- Subject: Ham radio names and routing
- Message-ID: <ZC-:A1@splut.conmicro.com>
-
- In article <1990Jan3.171148.13647@tandem.com> kevinr@tandem (Kevin J. Rowett) writes:
- >In article <6287#.@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes:
- >>In the referenced message, John, KD7UW, writes a lot of common sense.
- >Jay, What's the "common sense" that you speak of in SOURCE ROUTING?
- >The quickest problem to point out is what happens to your traffic
- >when one of the routers in the path goes away? And how do you discover
- >the new path?
-
- As has been pointed out here and on tcp-group, WB5BBW@HOU.TX.USA.NA is
- not a route, it's a location. All it says is that WB5BBW is in Houston,
- which is in Texas, which is in USA, which is in North America. It says
- nothing about how to get the message to any of those geographic
- locations.
-
- The common sense I was referring to was the part about how we should
- drop the religious objections and get on with making things work well.
-
- --
- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
- jay@splut.conmicro.com (eieio)| adequately be explained by stupidity.
- {attctc,bellcore}!texbell!splut!jay +----------------------------------------
- "There is no doubt I should be tarred and feathered." - Richard Sexton
-
- ------------------------------
-
- Date: 9 Jan 90 00:25:28 GMT
- From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hp.com (Bdale Garbee)
- Subject: Ham radio names and routing
- Message-ID: <4390108@col.hp.com>
-
- >SO WHAT'S THE BIG DIFFERENCE?
-
- The big difference is that in NET/NOS, we acknowledge that the static 'route'
- command is a poor substitute for an automatic routing protocol. It is clear
- from the syntax that naming and routing information are separate entities. And
- when RSPF/RIP/Whatever begin to enjoy wide use for route generation between
- IP switches, the only thing an end user station will need to do is to insert
- a 'route add default ax0 <local_switch_name>', and everything else will be
- automagic.
-
- The point has been made elsewhere that the BBS H addressing isn't actually
- source routing, but is a combination of a flat address (the callsign part of
- the "hostname"), and geographic routing hints (the .CO.USA.NA part). The
- confusion, and in large part the concern within the IP world, is that
- addressing and routing are separate issues, and the dot-notation syntax makes
- this appear to be a pseudo-domain-name, which it's not, and a concern that
- the folks building BBS software really understand the distinction between
- addressing/naming and providing routing hints.
-
- W9NK (I think) has made an interesting proposal on tcp-group that is being
- looked at, which would change the syntax of addresses on the PBBS side, and
- clarify the distinction between the flat address space callsign, and the
- routing hints. I think it's likely that some change from the dot-notation will
- likely be addopted by the PBBS authors, eventually.
-
- I don't think what they're doing is *wrong*, it's just misleading, and in many
- ways a less than optimal solution.
-
- >Also, my comments concerning the "RELGIOUSITY" of certain individuals is
- >not meant to "deny them first amendment rights", it is that this
- >attitude has created a dictatorship of the "AMPR.ORG" domain and Network
- >"44" ... This dictatorial attitude prevents any democratic aproach to
- >the question of subdomains, administrative subnetworks which can use
- >geography for pragmatic reasons (eventhough you see geographic subnets
- >in internets all the time), summary decisions to allocate less that full
- >byte subnets without user input, etc. (I found the DIETY, MOTHER, and
- >ADDRESS analogy very telling).
-
- Hmmm. It may be "very telling", but it avoids the basic issue, which is that
- religion is being confused with experience. Unfortunately, and at the root
- of the real problem, is that the "in crowd" in AMPR.ORG have had to answer the
- same questions about geographic routing 1e6 times in the last couple of years,
- as new users come online and get wild ideas in their heads, and become
- confused about the issues of addressing and routing, after reading well-meant
- articles and papers by folks in the amateur packet community who do not have
- much depth of experience building real internetworked systems.
-
- This is unfortunate, but strikes me as more of a communication problem than a
- "dictatorship"... The attitudes of individuals may get to seem "dictatorial"
- at times, but I think it's more out of boredom from explaining the same thing
- for the n'th time than any real reflection of attitude.
-
- >I would say that a
- >majority of users just want Email and Bulletin services, lets make the
- >path easy between them and those who want the higher services of
- >networks like IP.
-
- Agreed. And believe it or not, this exact wish is often at the root of
- complaints about the PBBS H address syntax and semantics. It generates a lot
- of confusion, and in some ways makes generating reasonable gateways and
- reasonable addressing rules harder for both sides...
-
- Bdale
-
- ------------------------------
-
- Date: 9 Jan 90 00:27:03 GMT
- From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hp.com (Bdale Garbee)
- Subject: Making things more difficult than necessary (was: Tasco TNC info)
- Message-ID: <4390109@col.hp.com>
-
- >Or, yet another possibility: To avoid messy soldering (on the EPROM, at
- >least), obtain a 27C512 and copy your original ROM into one half of the
- >64K address space, and KISS into the other half. Then use the switch as
- >a ROM select by changing the state of the A14 line.
-
- Le Huh?
-
- The KISS for the u21 that I made available is a copy of all the functionality
- provided in the standard firmware, plus KISS ala the TAPR 1.1.6 w/KISS EPROM.
-
- It is *not* KISS-only, and as such, there's no need for piggybacking, or
- anything!
-
- Bdale
-
- ------------------------------
-
- Date: Tue, 9 Jan 90 23:04:51 PST
- From: elmquist@nips.ssesco.com
- Subject: PBBS forwarding via dialup modem?
- Message-ID: <9001100505.AA01654@nips.ssesco.com>
-
- Just wondering if any of the PBBS packages (RLI, MBL, AA4RE, etc) have any
- provisions for forwarding traffic via dialup modem? I guess it would work
- something like UUCP. We have a problem here in Mpls/St. Paul..in that
- most of our outside world traffic comes and goes through a connection
- called the "Gofar Hole".
-
- This Gofar Hole is a piggy back connection
- on top of a private corporate network. A TNC in MSP is connected to
- the sio line of Sun...the Sun talks to another Sun in Maryland via the
- network...and the sio of that Sun is connected to another TNC which
- finally puts the stuff on the air. Both TNCs are NET/ROM'd.
-
- This all sounds great except that the link is down more often than
- it is up. It's not a high priority for the people who own the
- Suns and the network...to restart the processes that keep the AX.25
- traffic moving... consequently, we don't get any new packet traffic
- for days and days. The most frusterating part for me is not getting
- AMSAT bulletins. When we finally get them-- they are weeks, sometimes
- a month old!
-
- What I would like is a fall back connection via dialup modem. If
- the PBBS determines that forwarding via the Gofar Hole (or worm hole
- of your choice) is failing... then it will dial the other PBBS on
- the phone. If we were really smart, we'd compress the traffic using
- .ARC or .ZIP techniques and then use MNP on the link for reliability
- and speed.
-
- I work for a modem company-- hence v.32 9600 baud modems for
- each end are feasable.
-
- Any ideas? flames? Chris N0JCF
-
-
- ------------------------------
-
- Date: 9 Jan 90 19:47:31 GMT
- 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)
- Subject: Stolen radio
- Message-ID: <1990Jan9.194731.19118@ux1.cso.uiuc.edu>
-
- Kenwood HF transceiver model TS-440S (with general coverage receive)
- S/N 7060175
- Stolen during breakin of Synton ARC station between Jan 5 and Jan 8 1990.
-
- Features installed:
- AT-440 auto antenna tuner
- YK-88S 2.1 khz SSB filter
- YK-88C 500 hz CW filter
- 10 hz display mod
-
- If you find this radio, contact local police or:
- University of Illinois Police
- Officer Frost
- Case I90-0031
- Phone 217-333-1216
-
- Phil Howard, KA9WGN
- 217-384-4934
- 217-244-6246
- phil@ux1.cso.uiuc.edu
- uiucuxc!ux1!phil
- --
-
- --Phil Howard, KA9WGN--
- <phil@ux1.cso.uiuc.edu>
-
- ------------------------------
-
- Date: 9 Jan 90 15:08:35 GMT
- From: aplcen!wb3ffv!gvdgpc!gvdg@uunet.uu.net (Gerard J van der Grinten PA0GRI)
- Subject: Updates to NOS 900105 from Russ and me.
- Message-ID: <292@gvdgpc.UUCP>
-
- This version is a combination of Phil's work, from Russel Nelson and PA0GRI.
- Phils mods include tracing into a file (trace interface tracelevel [file])
- If file is not given output is redirected to the screen.
- From Russel Nellson are his mods as contained in diffs.arc.
- They include:
- a)
- Arcnet support where arcnet uses the packet driver interface.
- b)
- The fcntl control call and command.asm mods. This makes NOS run through when
- shell escaping to DOS as a tsr. (no smtp hangs anymore. Even trace goes on)
- c)
- Interprosess comunication via int 0x2f (for rlogin client)
- d)
- Logging of MKDir and RMDir commands.
- e)
- If you have a anonymous account in your ftpusers file any user name will be
- accepted and mapped into the anonymous account. (seems not "everybody" knows
- anonymous account, In europe guest is used in net/nos often)
- f)
- The JOINed disk (if used) is found and statused if a dir is done on the joined
- drive.
- g)
- Multiple directorys can be accessed on the same level. Normaly there is a
- root directory. In ftpusers it is like "anonymous * /dir1;/dir2 1"
- (directorys are separated by ; and no "white space" is alowed.
- h)
- A net.rc (aka .netrc) file is supported for ftp access to other machines.
- This auto logins you to the destined machine.
- Format is "system username password" . Note that it all is clear text.
- net.rc lives in the root directory.
- i)
- I did not find the rlogin client so that is not added but some hooks are
- in place.
- j)
- Tar backup feature! If you specify 'recv direct/tar/*.* than all files
- in direct are tarred into one destination file. This is great to backup
- a single directory into (onto) another system. I did not encounter speed
- degradation in backing up my NOS directory onto my UNIX system via ethernet.
- On a destination /tar/ read it should expand the tar file again.
- a)
- From PA0GRI the domain mods are included.
- b)
- autoexec.net is called autoexec.nos to make a difference on people using
- both NET and NOS and dont want to switch between configuration files.
-
- I uploaded nosadd.arc and nosgri30.exe to flash.bellcore.com in the files
- /pub/nosadd.arc and /pub/nosgri30.exe . nosadd.arc contains all changed files
- against nosv30tc.arc (phil's nos.arc 900105)
- Also on wb3ffv and gvdgpc bbs systems both files are uploaded.
- Note: nosv30 is phil's 900105 release.
- Regards. gerard.
-
- ------------------------------
-
- End of PACKET-RADIO Digest V90 Issue #7
- ***************************************
- 12-Jan-90 18:24:51-MST,12054;000000000000
- Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
- Date: Fri, 12 Jan 90 18:15:49 MST
- From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
- Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
- Subject: PACKET-RADIO Digest V90 #8
- To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
-
- PACKET-RADIO Digest Fri, 12 Jan 90 Volume 90 : Issue 8
-
- Today's Topics:
- A location is not a route.
- can't reach <dug@kd4nc.gatech.edu>
- Duplex Repeat
- Grapes on Duplex Repeat
- Ham radio names and routing
- PBBS forwarding via dialup modem?
- PK-88 RFI problems
- Unix/KA9Q pty support for outgoing telnet
- What is HAMSTER?
- ----------------------------------------------------------------------
-
- Date: 5 Jan 90 05:11:24 GMT
- From: dsl.pitt.edu!pitt!w2xo!durham@PT.CS.CMU.EDU (Jim Durham)
- Subject: A location is not a route.
- Message-ID: <119@w2xo.UUCP>
-
- W0RLI Writes:
-
- > Note that the "BBS net" addresses are not routes, but locations.
- > Routing takes place at the individual servers, and can be based
- > on any of the location information, or on the addresses.
- > OR.USA.NA is a location, and does not say anything about
- > how one could GET there, but just where it is located.
- >
- > ... Hank - w0rli
-
- I think Hank hit the nail on the head. I have been wondering how one
- could apply the term "source routing" to the W6XXX.CA.US.NA type
- scheme. A "source routing", scheme as I understand it, is to specify
- the entire path , as is done on Usenet (foobar!nerdley!fonzy!..etc).
-
- The ham packet network is not a network in the same sense as the
- Internet. It is a "bucket brigade". The decision that needs to be
- made at each BBS is, in the case of a destination address that is
- not directly reachable, "which 'next node' do I send this to?".
- Which way do I "pass the bucket". Knowing the geographical location
- of the destination drives this decision. Given the poor connectivity
- of the network, the only other solution would appear to be maintaining
- a "nameserver" at each BBS, which is the way things were originally
- done. This is a pain in the wazoo..
-
- -73
- Jim, w2xo
-
- ------------------------------
-
- Date: 12 Jan 90 10:39:39 GMT
- 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
- Subject: can't reach <dug@kd4nc.gatech.edu>
- Message-ID: <30600030@ux1.cso.uiuc.edu>
-
- Sorry for posting this, but I need a different E-mail address for someone
- who frequents this newsgroup. I am trying to send mail to Doug Drye KD4NC
- at the address he gives of "kd4nc.gatech.edu". Mail bounces apparently
- due to an error in a mailer near his end. Doug, here are the symptoms:
-
- > From MAILER-DAEMON@gatech.edu Thu Jan 11 20:17:18 1990
- > Received: from gatech.edu by ux1.cso.uiuc.edu with SMTP
- > (5.61+/IDA-1.2.8) id AA15273; Thu, 11 Jan 90 20:16:57 -0600
- > Received: by gatech.edu (5.58/GATECH-8.6)
- > id AA11203 for phil@ux1.cso.uiuc.edu; Thu, 11 Jan 90 21:14:58 EST
- > Date: Thu, 11 Jan 90 21:14:58 EST
- > From: MAILER-DAEMON@gatech.edu (Mail Delivery Subsystem)
- > Subject: Returned mail: Service unavailable
- > Message-Id: <9001120214.AA11203@gatech.edu>
- > To: <phil@ux1.cso.uiuc.edu>
- > Status: R
- >
- > ----- Transcript of session follows -----
- >>>> >>> HELO gatech.edu
- >>>> <<< 553 gatech.edu I refuse to talk to myself
- >>>> 554 <dug@kd4nc.gatech.edu>... Service unavailable: Bad file number
-
- Seems like an error in the gatech.edu mailer.
-
- >
- > ----- Unsent message follows -----
- > Received: from ux1.cso.uiuc.edu by gatech.edu (5.58/GATECH-8.6)
- > id AA11142 for ; Thu, 11 Jan 90 21:09:19 EST
- > Received: by ux1.cso.uiuc.edu
- > (5.61+/IDA-1.2.8) id AA14139; Thu, 11 Jan 90 20:10:19 -0600
- > Date: Thu, 11 Jan 90 20:10:19 -0600
- > From: Phil Howard KA9WGN <phil@ux1.cso.uiuc.edu>
- > Message-Id: <9001120210.AA14139@ux1.cso.uiuc.edu>
- > To: dug@kd4nc.gatech.edu
- > Subject: Re: WA4DSY
-
- ------------------------------
-
- Date: 10 Jan 90 06:37:08 GMT
- From: swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!stiatl!rsiatl!kd4nc!dug@ucsd.edu (Doug Drye KD4NC)
- Subject: Duplex Repeat
- Message-ID: <3400@kd4nc.UUCP>
-
- julian@bongo.UUCP (julian macassey) writes:
-
-
- >Late last year someone on this newsgroup mentioned that they had
- >a repeater running the GRAPES 56KB packet modem. Details were
- >supposed to be forthcoming. Any news on the horizon?
-
- You may not be referring to us, Julian.. Since I don't recall any promised
- publication of details...but anyway......
-
- GRAPES has three KA9Q switches "Mountaintop" interconnected with 56K modems
- here in N. Ga.. All of them have 1200 baud channels (most more that one).
- These switches make up the production AX.25 and TCP/IP network
- (Net/Rom will be integrated soon (Thanks, Dan)) for N. Ga. We are not
- building a parallel network for IP.
-
- One of the switches has a full duplex 1200 baud repeater for the LAN.
-
- I'm sorry to say that a full duplex 56K LAN is still on our "wish list",
- since our kit and switch building activities have taken up most of the
- energy needed to build the necessary hardware.
- The switches we have are running simplex 56K.
-
- I'd be happy to answer any questions on our setup, if it's of any interest
- to you.. I'd also like to hear about others who have production switches
- and/or 56K on the air full time especially Full Duplex.
-
- 73's
- Doug
-
-
- --
- Doug Drye KD4NC
-
- ------------------------------
-
- Date: 8 Jan 90 15:27:15 GMT
- From: mitel!sce!cognos!dgbt!barry@uunet.uu.net (Barry McLarnon DGBT/DIP)
- Subject: Grapes on Duplex Repeat
- Message-ID: <1347@dgbt.uucp>
-
- From article <288@bongo.UUCP>, by julian@bongo.UUCP (julian macassey):
- >
- > Late last year someone on this newsgroup mentioned that they had
- > a repeater running the GRAPES 56KB packet modem. Details were
- > supposed to be forthcoming. Any news on the horizon?
-
- I confess, 'twas I. Sorry for the delay, but the info is now in the mail
- to you and a few others who requested it.
-
- 73, Barry VE3JF
-
- --
- Barry McLarnon Communications Research Center Ottawa, ON Canada
- UUCP: ...utzoo!bnr-vpa!bnr-rsc!dgbt!barry INTERNET: barry@dgbt.crc.dnd.ca
- Compu$erve: 71470,3651 Packet radio: VE3JF @ VE3JF
-
- ------------------------------
-
- Date: 12 Jan 90 12:30:51 GMT
- From: usc!wuarchive!texbell!splut!jay@ucsd.edu (Jay "you ignorant splut!" Maynard)
- Subject: Ham radio names and routing
- Message-ID: <MT.:P.@splut.conmicro.com>
-
- In article <1990Jan11.164732.18479@tandem.com> kevinr@tandem (Kevin J. Rowett) writes:
- >>As has been pointed out here and on tcp-group, WB5BBW@HOU.TX.USA.NA is
- >I'd not seen this syntax. Is WB5BBW a user and HOU the host? Or is
- >WB5BBW a host? If so, who's the user?
-
- I screwed up; I should have said K5ZC@WB5BBW.TX.USA.NA.
- That said, it's STILL a location, not a route. It says nothing at all
- except that WB5BBW is in Texas, and nothing at all about how that
- message is to get to Texas.
-
- Yes, WB5BBW is unique.
- Unfortunately, the only ways to know that WB5BBW is in Texas are 1) have
- the user, who knows it already, tell the computer about it; 2) store a
- database potentially the size of the Callbook online to look it up; or
- 3) have the BBS contact a nameserver elsewhere that has the huge
- database on it. The nameserver doesn't exist. I haven't seen anyone
- volunteering to write it, nor have I seen anyone volunteering to
- manually maintain the huge list involved. Until the nameserver exists,
- and is the same production quality as the rest of the BBS software, it
- won't get used, reducing the available solutions to 1) and 2) above. 1)
- is much easier for everyone concerned, and works just fine.
-
- If you have religious objections to what you see as source routing, then
- don't complain - come up with the software that will fix it.
-
- --
- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
- jay@splut.conmicro.com (eieio)| adequately be explained by stupidity.
- {attctc,bellcore}!texbell!splut!jay +----------------------------------------
- "There is no doubt I should be tarred and feathered." - Richard Sexton
-
- ------------------------------
-
- Date: Wed, 10 Jan 90 07:37:30 PST
- From: "Roy Engehausen" <ENGE@IBM.COM>
- Subject: PBBS forwarding via dialup modem?
- Message-ID: <9001100505.AA01654@nips.ssesco.com>
-
- AA4RE PBBS version 2.8 has provision for a modem line and will forward
- via that port.
-
-
- ------------------------------
-
- Date: 10 Jan 90 18:14:36 GMT
- From: henry.jpl.nasa.gov!elroy.jpl.nasa.gov!jpl-devvax!jenkins@ames.arc.nasa.gov (Steve Jenkins)
- Subject: PK-88 RFI problems
- Message-ID: <6763@jpl-devvax.JPL.NASA.GOV>
-
- Hardware: AEA PK-88, battery powered, out of warranty
-
- Problem: With no cables except power connected, the PK-88
- generates enough RF on 145.01 to open the squelch on
- my Kenwood TH-215A (squelch set to max; duck) about
- 30 feet away. Using scan mode on the 215A, I found
- a strong peak at 145.01 and another at 147.465; both
- are definitely generated by the PK-88. It's done this
- since it was new; I didn't have time to mess with it
- until now.
-
- Tried: ensuring good chassis-to-case connections (case is metal)
- grounding chassis to outlet ground (no really good
- RF ground nearby)
- checking .1 mf bypass capacitor at DC input (seems OK)
-
- Not yet tried: ferrite beads on the power cable
- shielding power cable (It's AEA's cable....)
-
- Suggestions: by email please; I'll summarize.
-
- Thanks: in advance
-
- --
- Steve Jenkins N6UNI jenkins@jpl-devvax.jpl.nasa.gov
- Caltech/Jet Propulsion Laboratory (818) 354-0162
-
- ------------------------------
-
- Date: 12 Jan 90 14:32:07 GMT
- From: mailrus!b-tech!zeeff@tut.cis.ohio-state.edu (Jon Zeeff)
- Subject: Unix/KA9Q pty support for outgoing telnet
- Message-ID: <-H83MB@b-tech.uucp>
-
- I'm running the ka9q software on a unix system w/o tcp/ip support (Sys V).
- I'd like to get it to run a outgoing telnet session to a pty port(s)
- instead of the console. In other words, I'd like to get the ka9q
- software to read and write the telnet i/o to a pty port instead of the
- terminal that initiated the session (sort of the reverse of the pty
- support already in place). The result would be that I could run
- kermit or cu on the other end of the pty and get a login: prompt.
-
- Perhaps it could be generalized to the point where the ka9q session
- code wasn't used at all and the systems windowing code (X11 or virtual
- consoles) was used for each session.
-
- Any ideas before I start hacking the session code?
-
- --
- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us or b-tech!zeeff
- --
- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us or b-tech!zeeff
-
- ------------------------------
-
- Date: 10 Jan 90 12:00:21 GMT
- From: n8emr!gws@tut.cis.ohio-state.edu (Gary Sanders)
- Subject: What is HAMSTER?
- Message-ID: <1404@n8emr.UUCP>
-
- In article <922@khijol.UUCP> erc@khijol.UUCP (Edwin R. Carp) writes:
- >In article <30600029@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu writes:
- >>> IP address: 129.100.22.100 HAMSTER.business.uwo.ca
- >Yes, but is it available via uucp/dialup?
- >--
- >Ed Carp N7EKG/5 (28.3-28.5) uunet!cs.utexas.edu!khijol!erc
-
- If its not, you can get the same files from my dialup BBS.. I grabbed
- all of the mods files a few weeks ago... you can xmodem,ymodem,kermit
- them out.
-
- 73
-
-
-
-
-
-
- --
- Gary W. Sanders (gws@n8emr or ...!osu-cis!n8emr!gws), 72277,1325
- N8EMR @ W8CQK (ip addr) 44.70.0.1 [Ohio AMPR address coordinator]
- HAM/SWL/SCANNER BBS (1200/2400/PEP) 614-457-4227 614-895-2552 (after 1/12/90)
- Voice: 614-457-4595 (eves/weekends) 614-895-2553 (after 1/12/90)
-
- ------------------------------
-
- End of PACKET-RADIO Digest V90 Issue #8
- ***************************************
- 12-Jan-90 20:20:54-MST,13115;000000000000
- Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
- Date: Fri, 12 Jan 90 20:15:29 MST
- From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
- Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
- Subject: PACKET-RADIO Digest V90 #9
- To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
-
- PACKET-RADIO Digest Fri, 12 Jan 90 Volume 90 : Issue 9
-
- Today's Topics:
- A location is not a route.
- BBS Source code & KISS specification needed
- Digicom cartridge confusion
- packet radio (X.25) in aviation band
- PBBS forwarding via dialup modem?
- PK-88 RFI problems
- TAPR Annual Meeting
- ----------------------------------------------------------------------
-
- Date: 11 Jan 90 17:02:03 GMT
- From: amdahl!pacbell!tandem!kevinr@ames.arc.nasa.gov (Kevin J. Rowett)
- Subject: A location is not a route.
- Message-ID: <1990Jan11.170203.18601@tandem.com>
-
- In article <119@w2xo.UUCP> durham@w2xo.UUCP (Jim Durham) writes:
- >W0RLI Writes:
- >
- >> Note that the "BBS net" addresses are not routes, but locations.
- >> Routing takes place at the individual servers, and can be based
- >> on any of the location information, or on the addresses.
- >> OR.USA.NA is a location, and does not say anything about
- >> how one could GET there, but just where it is located.
- >>
- >> ... Hank - w0rli
- >
- >I think Hank hit the nail on the head. I have been wondering how one
- >could apply the term "source routing" to the W6XXX.CA.US.NA type
- >scheme. A "source routing", scheme as I understand it, is to specify
- >the entire path , as is done on Usenet (foobar!nerdley!fonzy!..etc).
-
- If isn't W6XXX.ca.us.na source routing, then W6XXX should be sufficent,
- right? Source routing is defined as the originator describing the
- path to reach a location.
-
- In the about case, we've tried to "qualify" the name with a path
- as well. Yes, I know some would argue that .ca.us.na is a "location",
- but how does a location differ from an "address"?
-
- >
- >The ham packet network is not a network in the same sense as the
- >Internet. It is a "bucket brigade". The decision that needs to be
- >made at each BBS is, in the case of a destination address that is
- >not directly reachable, "which 'next node' do I send this to?".
- >Which way do I "pass the bucket". Knowing the geographical location
- >of the destination drives this decision. Given the poor connectivity
-
- Which, in the example above, was obtained from the originator of the
- message.
-
- >of the network, the only other solution would appear to be maintaining
- >a "nameserver" at each BBS, which is the way things were originally
- >done. This is a pain in the wazoo..
-
- I agree at the present data rates and physical layer protocols,
- connectivity isn't the best, but a number of Hams are working to radically
- alter that situation. WHEN that comes about, the nameserver idea will
- be practical, and the benefits will be obvious.
-
- N6RCE
-
- ------------------------------
-
- Date: 11 Jan 90 20:19:00 GMT
- From: pixar!matt@ucbvax.Berkeley.EDU (Matthew Martin)
- Subject: BBS Source code & KISS specification needed
- Message-ID: <8526@pixar.UUCP>
-
- Greetings to the net! I would like to know if the source code
- for any of the popular BBS software packages (like RLI, MBL and AA4RE)
- is available. I also would like a quick pointer to information about
- KISS - in particular, a specification or detailed info about the commands,
- etc. If this is published anywhere (proceedings of ARRL Computer Networking
- Conference ???), a simple citation will do.
-
- We desire to set up a packet system in Marin County for RACES. It
- would be nice to make this system as automatic and user-friendly (gack!) as
- possible. Ultimately, a PC clone attached to a TNC & radio would be the
- basic hardware. The software would present to the user an editor for
- message origination, and once the message was edited, it would be send to
- its destination right away. Incoming messages would be printed immediately,
- without the need to list messages from a BBS, selecting your messages for
- printing. All the user need do is enter messages, and once entered the user
- would not have to mess with the mechanics of the packet transfer. Incoming
- traffic is as simple as checking for printout on the printer.
-
- I don't suppose such a system already exists?? Reply via e-mail,
- and I will summarize to the net. Many thanks!
-
- ----
- Matt Martin ....!ucbvax!pixar!matt
- N6LQB
-
- ------------------------------
-
- Date: 12 Jan 90 00:34:37 GMT
- From: masscomp!ocpt!tsdiag!ka2qhd!w2up@think.com (Barry Kutner W2UP)
- Subject: Digicom cartridge confusion
- Message-ID: <90@ka2qhd.UUCP>
-
- There has been some confusion about my Digicom cartridge (DIGICART).
- The DIGICART replaces the software ONLY. Its advantages include
- autobooting and ability to store parameters to the cartridge (both
- almost instantaneous). A Digicom modem is still needed for packet
- operation. Any questions can be referred to me here or via US mail.
- 73/Barry, W2UP
-
- ------------------------------
-
- Date: 11 Jan 90 20:01:34 GMT
- From: philmtl!philabs!briar.philips.com!rfc@uunet.uu.net (Robert Casey;6282;3.57;$0201)
- Subject: packet radio (X.25) in aviation band
- Message-ID: <73453@philabs.Philips.Com>
-
- copied from packet:
- From: ka2raf@nn2z.ampr.org (Chris Crosby)
- To: swls@allbbs
- Subject: Packet in Aviation Bands
-
- PACKET IN AVIATION BAND
- By Dave Sweigert
-
- What you hear on 131.55 is packet radio. Aeronautical Radio maintains
- 200 ground stations around the country that feed into a giant X.25
- computer network. Ever wonder where the flight attendant gets arriving
- gate info minutes before you land ? Via a terminal in the cockpit.
- Data such as engine tempature, winds aloaft, etc is downlinked via this
- network. All 200 stations operate on 131.55. For more info write:
-
- Industry Activities
- ARINC
- Radio Operations, Bldg 2
- 2551 Riva Road
- Annapolis, MD 21403
-
- They may send you some
- interesting brocherures.
-
- A few (airline company)freqs which I have tentatively identified:
-
- 129.2 American Airlines
- 129.5 Delta
- 130.65 Military Airlift Command
- 130.7 Eastern
- 129.625 TWA
- 131.925 Federal Express
-
-
- Enclosed are some airline company channels used in the Chicago area.
- Activity can also be heard on ARINC's MAC channel.
-
- Air France/aka Aeronautical Radio, company channel, transportation
- [Chicago] ___________ 129.0250____KFI9 (others)
- Air-Medic One, company channel, medical transportation
- [location?]_________ 131.1500____call? (others)
- American Airlines/aka Aeronautical Radio, company channel, aircraft
- maintenance, transportation
- [Chicago]___________ 130.2500____KSG7 (B. Parnass)
- British Airways/aka Aeronautical Radio, company channel
- [Chicago]___________ 131.1000____KFB8 (others)
- Delta Airlines/aka Aeronautical Radio, company channel
- [Chicago]___________ 129.6000____WCD4 (others)
- Eastern Airlines/aka Aeronautical Radio, company channel
- [Chicago]___________ 128.8500____KEB5 (others)
- Jetstream/aka Aeronautical Radio, company channel, airline transportation
- [Chicago]___________ 128.8500____KEB5
-
- -----------------------------------------------------------------------------
- New address is: PO Box 1286 Lakewood, NJ 08701 or KA2RAF@NN2Z
-
- [ Suns @10am on 7240 LSB, The ANARC Listeners' Net - DC to Light and MORE! ]
- 0435z, 1568 msgs, #13610 last @KD6TH-4 MailBox>
-
- ------------------------------
-
- Date: 12 Jan 90 03:20:48 GMT
- From: zaphod.mps.ohio-state.edu!wuarchive!texbell!ark!lrark!argate!richard@tut.cis.ohio-state.edu (Richard Duncan)
- Subject: PBBS forwarding via dialup modem?
- Message-ID: <14@argate.UUCP>
-
- In article <9001100505.AA01654@nips.ssesco.com>, elmquist@NIPS.SSESCO.COM writes:
- > Just wondering if any of the PBBS packages (RLI, MBL, AA4RE, etc) have any
- > provisions for forwarding traffic via dialup modem? I guess it would work
- > something like UUCP. We have a problem here in Mpls/St. Paul..in that
- > most of our outside world traffic comes and goes through a connection
- > called the "Gofar Hole".
- >
- -deleted-
- >
- > Any ideas? flames? Chris N0JCF
-
- We are using telco/uucp to forward between three systems here in the
- Little Rock area. I have written a RLI, et all, compatible PBBS on
- my Xenix 286 and also interfaced into ka9q's net software.
-
- Forwarding works fine, but the actual transfer is handled by the
- mail rather than the PBBS doing the actual calling. Why worry about
- functions that are already there.
-
- I also have several users that use uucp mail to send and receive packet
- mail through my system. Incoming packet messages are automaticly mailed
- via uucp to the destination. Mail coming in via uucp is checked and then
- flagged for the PBBS to pick it up and send out via packet. This has
- allowed several people to communicate via packet without having access.
-
- Am interested in experimenting more with mail forwarding via uucp to
- areas not normally covered easily by normal packet routes.
- :------------------------------------------------------------------:
- : Richard Duncan WD5B Packet: WD5B @ WD5B.AR.USA.NA :
- : Little Rock, AR uucp: 501/568-6809 (2400/1200) :
- : UUCP: ...!texbell!ark!lrark!argate!{richard|unetadm} :
- :------------------------------------------------------------------:
-
- ------------------------------
-
- Date: 11 Jan 90 22:30:35 GMT
- From: att!cbnewsj!kfr@ucbvax.Berkeley.EDU (k.redden)
- Subject: PK-88 RFI problems
- Message-ID: <3333@cbnewsj.ATT.COM>
-
- In article <6763@jpl-devvax.JPL.NASA.GOV> jenkins@jpl-devvax.JPL.NASA.GOV (Steve Jenkins) writes:
- > Hardware: AEA PK-88, battery powered, out of warranty
- >
- > Problem: With no cables except power connected, the PK-88
- > generates enough RF on 145.01 to open the squelch on
- > my Kenwood TH-215A (squelch set to max; duck) about
- > 30 feet away.
- > Steve Jenkins N6UNI jenkins@jpl-devvax.jpl.nasa.gov
- > Caltech/Jet Propulsion Laboratory (818) 354-0162
-
- I was talking to AEA customer service today about a different problem, and
- I told them about the subject posting. Since many others may have the
- problem, I'm posting my reply so all can see.
-
- AEA says the clock on the PK-88 does indeed put out a birdie on 145.01, but
- they do have a mod you can make to fix the situation. The clock frequency is
- controlled by C38, a 33 pF capacitor. If you change this to an 82 pF cap
- (use a silver mica cap), it will lower the clock frequency enough to move
- the birdie out of the packet band.
-
- If you have any trouble, call Ryan at AEA customer service at 206 775-7373.
-
- Good Luck,
-
- Kevin Redden, WB2ZLF
- AT&T Bell Labs, Lincroft NJ
-
- ------------------------------
-
- Date: 10 Jan 90 21:27:57 GMT
- From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hpl.hp.com (Bdale Garbee)
- Subject: TAPR Annual Meeting
- Message-ID: <4390110@col.hp.com>
-
- From: Andy Freeborn N0CCZ <ucsd.edu!winfree!andy>
- Subject: TAPR Annual Meeting
-
-
- ANNUAL TAPR MEETING - TUCSON AZ - SATURDAY AND SUNDAY - FEBRUARY 24th - 25th
-
- The TAPR annual meeting will be held at the Inn At The Airport, 7060 South
- Tucson Boulevard, Tucson AZ, 85706. The Inn is a very short distance from the
- airport terminal, walking distance if you're so inclined. Special rates for
- the meeting are $49.00 for either one or two in a room. Breakfast is included
- as well as a late afternoon cocktail hour. Our room block will be released on
- February 9, 1990 so get your reservations in prior to that date. Call 1-800-
- 772-3847 if outside Arizona, 602 746-0271 if in Arizona, or write the above
- address. Cite The TAPR Conference to assure rates.
-
- There will be a registration fee of $20.00. This fee will help to defray
- meeting costs plus lunch and private dinner at the hotel. Since breakfast and
- cocktail hour are provided to those staying at the hotel the overall cost is
- quite nominal. The Sunday session should be completed by noon or shortly
- thereafter for those planning return travel on Sunday afternoon.
-
- Networking, that's the packet radio buzzword for the early '90s. And that
- will be one of the main topics at the 1990 TAPR annual meeting. Equally
- exciting will be discussions by members of the Microsat team describing and
- graphically displaying the construction, pre/launch and launch activity of
- the Microsats and their UoSAT cousins.
-
- Expect to see many of the manufacturers of packet equipment present with
- displays and demos. Some have already contacted TAPR for arrangements. All
- the new TAPR kits will be shown and discussed.
-
- Those wishing to be on the speaking agenda should advise the TAPR office as
- soon as possible. The Sunday session should be concluded near or shortly
- after noontime for those planning afternoon departures.
-
-
-
- ------------------------------
-
- End of PACKET-RADIO Digest V90 Issue #9
- ***************************************
- 12-Jan-90 22:21:51-MST,14066;000000000000
- Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
- Date: Fri, 12 Jan 90 22:15:38 MST
- From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
- Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
- Subject: PACKET-RADIO Digest V90 #10
- To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
-
- PACKET-RADIO Digest Fri, 12 Jan 90 Volume 90 : Issue 10
-
- Today's Topics:
- Amateur packet radio on space shuttle
- Ham radio names and routing
- hapn card-TNC info wanted
- Making things more difficult than necessary (was: Tasco TNC info)
- packet in Poland
- PBBS forwarding via dialup modem?
- Update to NOS 900105 (2)
- ----------------------------------------------------------------------
-
- Date: 10 Jan 90 23:45:14 GMT
- From: vsi1!wyse!mips!prls!philabs!briar.philips.com!rfc@apple.com (Robert Casey;6282;3.57;$0201)
- Subject: Amateur packet radio on space shuttle
- Message-ID: <73297@philabs.Philips.Com>
-
- copied from packet:
-
- Msg# TSF Size #Rd Date/Time MsgID From To
- 14046 BF 2493 2 0103/0437 29730_W3IWI W3IWI ALL@NYNET
- Sb: SAREX2 - Packet on the Space Shuttle
-
- Note: Packet Radio is a computer communications mode of Amateur Radio.
-
- PACKET BID: 29730_W3IWI
-
- 1990 is going to be a vintage year for amateur packet radio in space.
- This month will see the launch of the four AMSAT Microsats plus two
- UoSATS (look for @AMSAT bulletins on you local BBS).
-
- Then in late April one of our MDC area astronauts, Ron Parise, WA4SIR
- will fly on the Shuttle Columbia in mission STS-35. Ron will be carrying
- 2M packet radio hardware with him -- a modified HK-21 TNC, a Motorola HT,
- a window-mounted antenna and a Grid lap-top computer.
-
- The TNC will be carrying special software -- an updated version of the
- SAREX "Robot" that would have flown in 1986 had not the Challenger
- disaster happened.
-
- The "Robot" software is an automatic QSO machine. You connect to the
- robot, you are given a serial number, and as soon as you ack the number,
- the Robot disconnects and enters the QSO into the log. As many as nine
- simultaneous QSOs can be going on. If the robot hears you, whether or not
- you make a full two-way QSO, that information is entered into a second
- log.
-
- You and the world know immediately if you had a QSO or were heard, because
- periodically the robot sends out beacons. A beacon addressed to QSL> lists
- the two-way QSO's and the serial number, and a beacon adddressed to QRZ>
- lists the stations heard.
-
- In addition, the robot has an additional beacon (called the Metabeacon)
- addressed to QST> which has up to 7 frames of up to 255 characters/frame
- (i.e. about 1.7 kbytes). This is intended to serve as a longer general
- information beacon into which Ron can put mission status information.
-
- N2WX and I have worked hard this past weekend to get a "beta" version of
- the flight TNC software working, and we are ready to test it. The SAREX
- goodies are now operating from here under the call W3IWI-5 (alias SAREX)
- on 145.05 using the same radio as the 145.05 W3IWI BBS port. The QST, QSL
- and QRZ beacons fire every 5 minutes.
-
- Please give the software a shot. Try to crash it! It is a lot better to
- it die now than in flight!
-
- 73, Tom
- 0450z, 1726 msgs, #14100 last @KD6TH-4 MailBox>
-
- ------------------------------
-
- Date: 11 Jan 90 16:47:32 GMT
- From: amdahl!pacbell!tandem!kevinr@ames.arc.nasa.gov (Kevin J. Rowett)
- Subject: Ham radio names and routing
- Message-ID: <1990Jan11.164732.18479@tandem.com>
-
- In article <ZC-:A1@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes:
- >In article <1990Jan3.171148.13647@tandem.com> kevinr@tandem (Kevin J. Rowett) writes:
- >>In article <6287#.@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes:
- >>>In the referenced message, John, KD7UW, writes a lot of common sense.
- >>Jay, What's the "common sense" that you speak of in SOURCE ROUTING?
- >>The quickest problem to point out is what happens to your traffic
- >>when one of the routers in the path goes away? And how do you discover
- >>the new path?
- >
- >As has been pointed out here and on tcp-group, WB5BBW@HOU.TX.USA.NA is
-
- I'd not seen this syntax. Is WB5BBW a user and HOU the host? Or is
- WB5BBW a host? If so, who's the user?
-
- If HOU.TX.USA.NA is really the name of a location that will accept
- mail for people living in the location named, then that's really nice to
- have. Neat.
-
- BUT, it's still source routing!
-
- We must recognize the difference between the name of an entity and
- the address of an entity. For example kevinr@tandem.com is really only
- a name, although it does have some element of source routing in it. Consider
- that it should (perhpas) be used only for traffic relating to the business
- of my employer. kevin@N6RCE is another name for the same entity, but again
- has the same element of source routing in it. I hope never to get anything
- but AR related traffic there.
-
- However, you'll note that in neither case, is it really necessary to
- specify my geographic location by the originator of the message.
- kevin@N6RCE is unique. Adding .norcal.usa.na.planetearth doesn't make it
- anymore unique.
-
- However, I agree it would be nice to find out a route to that location.
- And the originator may have a good idea. Dan Frnak (WN9K) had a very good
- idea along these lines. His suggested syntax is:
-
- user@host [state=CA,bbs=3Yota,nettype=IP]
-
- With the things in [] being optional, and the types of things similiar to
- what we have now...
-
- Think about some of the non-electronic mechanisms in use today that are and
- aren't source-routing and how well they work.
-
- The US Postal service (and UPS) is source routing. As is the phone company.
- Check cashing isn't. How would it do, if every time you gave a check to the
- grocery store, you had to tell them how to find your bank to present that
- check for payment. The store's bank presents it to the Fed, who looks at the
- ABA transit number and finds an adjacency to forward it in the right direction.
-
-
- N6RCE
-
- ------------------------------
-
- Date: 11 Jan 90 13:33:05 GMT
- From: mcsun!sunic!tut!kannel!junki@uunet.uu.net (Juha Nurmela)
- Subject: hapn card-TNC info wanted
- Message-ID: <1187@kannel.lut.fi>
-
- yana:
-
-
- I have a couple of questions about the HAPN card-TNC (TNC?).
-
-
- 1) Is the software for it in public domain, and if it is,
- from where could I obtain the bits? Particularly
- sources would be appreciated. What is the postal address
- of HAPN?
-
- (I know, I'm greedy.)
-
- 2) Does the 8273 do the FCS stuff? Does it send flags (not
- just one!) after keying PTT and before actually sending
- the frame? What the "standard" TNC is supposed to do in
- this time?
-
- 3) Does hapn use the p-persistence (persistance?) scheme?
-
- 4) And finally: Is there any reason why 89 ka9q doesn't
- have hapn-support compiled to net.exe? (Of course I
- can always compile it in, but I hate to torture my PC :-).
-
- That's it. I counted 10 question marks. Thanks in advance for any
- advice. Happy new decade, from
-
- juha nurmela, oh5nxo
- junki@kannel.lut.fi <- has nothing to do with drugs.
- (check your finnish-english dictionary)
-
- ------------------------------
-
- Date: 10 Jan 90 04:07:22 GMT
- From: dtseng!rps@decvax.dec.com (Robert P. Scott)
- Subject: Making things more difficult than necessary (was: Tasco TNC info)
- Message-ID: <7239@dtseng.UUCP>
-
- RE: Using KISS only ROM's.
-
- I find the idea of throwing away functionality offensive. It's sort of
- like throwing away compatibility to save 5 cents per component; nudge,
- nudge, wink, wink...
-
- RE: Kludging in both ROM's piggyback.
-
- I don't mind voiding the "90-day-but-that-doesn't-include-software" paper.
- And I have to admit that I didn't go look at the schematics, but.
- The described method may also cause design rule violations; fan-out for one.
- Yeah, yeah, it's picky but a 1->n ROM piggyback board would seem to be a better
- answer. (Actually, throwing the whole thing out and starting over sounds
- like more fun. All I have to do is find some company to foot the bill. heh,
- heh, heh...)
-
-
- --
- Robert P. Scott | DTS Engineering, Inc. | {decvax,zinn}!dtseng!rps
- Nothing could be finer than some green wallet liner....
-
- ------------------------------
-
- Date: 10 Jan 90 23:41:45 GMT
- From: vsi1!wyse!mips!prls!philabs!briar.philips.com!rfc@apple.com (Robert Casey;6282;3.57;$0201)
- Subject: packet in Poland
- Message-ID: <73296@philabs.Philips.Com>
-
- copied from packet:
-
- Msg# TSF Size #Rd Date/Time MsgID From To
- 13306 BF 1149 2 1222/1914 3343_SK6SA SP9VU POLAND@NYNET
- Sb: Poland packet start
- PACKET BID: 3343_SK6SA
-
- [ the following arrived a bit garbled at W3IWI and has been edited to make
- it more readible ]
-
- In SP efforts of the polish packet radio initiative group have brought
- long desired result.
-
- Special licences have been issued to 7 hams-
- SP5DED SP4LVG SP9VU SP5ALV SP5GTJ SP3CAI AND SP4KM.
- Operation will start 24.DEC.89. After an experimental period further
- permits
- are expected. Cu on packet. Lucjan SP9VU
- --- GXQ v3.52b
- 1504z, 1531 msgs, #13341 last @KD6TH-4 MailBox>
-
- ------------------------------
-
- Date: 11 Jan 90 08:13:52 GMT
- From: mcsun!ukc!axion!news@uunet.uu.net (Brian Lloyd)
- Subject: PBBS forwarding via dialup modem?
- Message-ID: <1990Jan11.081352.9247@axion.bt.co.uk>
-
- From article <9001100505.AA01654@nips.ssesco.com>, by elmquist@NIPS.SSESCO.COM:
- > Just wondering if any of the PBBS packages (RLI, MBL, AA4RE, etc) have any
- > provisions for forwarding traffic via dialup modem?
-
- Two BBSs in the UK which are a long way apart and have no good route
- between them export their mail to a separate directory, where a small
- telephone BBS program can get at it. The mail is then forwarded over the
- phone by the other program, and imported back by the PBBS at the other end.
- As far as I know this works well, and avoids the need for telephone modem
- support in the PBBS program which most people probably won't need.
-
- > Any ideas? flames? Chris N0JCF
-
- Brian G1NNA
-
- ###########################################################################
- Brian Lloyd, # Via e-mail : blloyd@axion.bt.co.uk
- RT3152, Rm G44, SSTF, # Via Packet : G1NNA @ GB7NNA.GBR.EU
- British Telecom Research Labs, # By Phone : +44 (0)473 646650
- Martlesham Heath, Ipswich, Suffolk. IP5 7RE
-
- ------------------------------
-
- Date: 10 Jan 90 14:53:19 GMT
- 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)
- Subject: Update to NOS 900105 (2)
- Message-ID: <293@gvdgpc.UUCP>
-
- This version is a combination of Phil's work, from Russell Nelson and PA0GRI.
- Phils mods include tracin into a file (trace interface tracelevel [file])
- If file is not given output is redirected to the screen.
- From Russell Nelson are his mods as contained in diffs.arc.
- They include:
- a)
- Arcnet support where arcnet uses the packet driver interface.
- b)
- The fcntl control call and command.asm mods. This makes NOS run through when
- shell escaping to DOS as a tsr. (no smtp hangs anymore. Even trace goes on)
- c)
- Interprosess comunication via int 0x2f (for rlogin client)
- d)
- Logging of MKDir and RMDir commands.
- e)
- If you have a anonymous account in your ftpusers file any user name will be
- accepted and mapped into the anonymous account. (seems not "everybody" knows
- anonymous account, In europe guest is used in net/nos often)
- f)
- The JOINed disk (if used) is found and statused if a dir is done on the joined
- drive.
- g)
- Multiple directorys can be accessed on the same level. Normaly there is a
- root directory. In ftpusers it is like "anonymous * /dir1;/dir2 1"
- (directorys are separated by ; and no "white space" is alowed.
- h)
- A net.rc (aka .netrc) file is supported for ftp access to other machines.
- This auto logins you to the destined machine.
- Format is "system username password" . Note that it all is clear text.
- net.rc lives in the root directory.
- i)
- I did not find the rlogin client so that is not added but some hooks are
- in place.
- j)
- Tar backup feature! If you specify 'recv direct/tar/*.* than all files
- in direct are tarred into one destination file. This is great to backup
- a single directory into (onto) another system. I did not encounter speed
- degradation in backing up my NOS directory onto my UNIX system via ethernet.
- On a destination /tar/ read it should expand the tar file again.
- a)
- From PA0GRI the domain mods are included. (domain 3.2)
- b)
- autoexec.net is called autoexec.nos to make a difference on people using
- both NET and NOS and dont want to switch between configuration files.
- c)
- A message is given when the default autoexec file is not found.
- d)
- domain search during autoexec startup is limited to the local machine.
- e)
- A domain server (series) is tried 4 times before giving up. If a server went
- down the probe to it was infinite and the system unusable due to lockup.
- (symptom: if typed "route add unknown ax0" the search went on infinite and
- only a reboot would give back a promt (whatever type).
-
- I uploaded nosadd.arc and nosgri30.exe to flash.bellcore.com in the files
- /pub/nosadd.arc and /pub/nosgri30.exe . nosadd.arc contains all changed files
- against nosv30tc.arc (phil's nos.arc 900105)
- Also on wb3ffv and gvdgpc bbs systems both files are uploaded.
- Note: nosv30 is phil's 900105 release.
- Regards. gerard.
- (on the nosadd.arc file trace.h and iface.h were missing, sorry.
- They are present now)
- (sorry for the mis-spelling of Russell Nelson's name.)
-
- ------------------------------
-
- End of PACKET-RADIO Digest V90 Issue #10
- ****************************************
- 13-Jan-90 14:24:43-MST,14903;000000000000
- Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
- Date: Sat, 13 Jan 90 14:15:38 MST
- From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
- Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
- Subject: PACKET-RADIO Digest V90 #11
- To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
-
- PACKET-RADIO Digest Sat, 13 Jan 90 Volume 90 : Issue 11
-
- Today's Topics:
- [rec.ham-radio.packet] G8BPQ software
- A location is not a route. (2 msgs)
- ka9q tcp/ip amiga ???
- Making things more difficult than necessary (was: Tasco TNC info)
- PBBS forwarding via dialup modem? (2 msgs)
- ----------------------------------------------------------------------
-
- Date: 11 Jan 90 03:44:07 GMT
- From: zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!zardoz!stanton!donegan@tut.cis.ohio-state.edu (Steven P. Donegan)
- Subject: [rec.ham-radio.packet] G8BPQ software
- Message-ID: <3868@stanton.UUCP>
-
- In article <10557@stag.math.lsa.umich.edu>, barry@dgbt.uucp (Barry McLarnon DGBT/DIP) writes:
- >
- > > Also, any ideas when the software will be available on ROM?
- >
- For this, and any other software that is ROMable, I would be happy to arrange
- for a burning for you. I can erase and program EPROMs of just about any size
- and will do so for the price of 1$ per ROM if you supply the EPROM and postage
- in both directions. This applies to software which has the author's permission
- to be ROMd only of course. Since this is such a low fee I hope it will not
- engender any flames about commercialism(I don't think I'll be able to make
- any profit on this in other words). If you object to this blatant profiteering
- keep your comments to yourself :-)
- --
- Steven P. Donegan (stanton!donegan) (714)-863-7998; Voice Mail
- Area Telecommunications Engineer (714)-894-2246; uucp(300-2400)
- Corporate Telecommunications Services (714)-897-3621; uucp(300-19200 PEP)
- Western Digital Corporation ogin: nuucp word: \r
- The opinions expressed here are mine, not Western Digital's.
-
- ------------------------------
-
- Date: 13 Jan 90 02:09:02 GMT
- From: dsl.pitt.edu!pitt!w2xo!durham@pt.cs.cmu.edu (Jim Durham)
- Subject: A location is not a route.
- Message-ID: <120@w2xo.UUCP>
-
- In article <1190Jan11.170203.18601@tandem.com> kevin@tandem.com (Kevin J.
- Rowett) writes:
- > In article <119@w2xo.UUCP> durham@w2xo.UUCP (Jim Durham) writes:
- > >W0RLI Writes:
- > >
- > >> Note that the "BBS net" addresses are not routes, but locations.
- > >> Routing takes place at the individual servers, and can be based
- > >> on any of the location information, or on the addresses.
- > >> OR.USA.NA is a location, and does not say anything about
- > >> how one could GET there, but just where it is located.
- > >>
- > >> ... Hank - w0rli
- > >
- > >I think Hank hit the nail on the head. I have been wondering how one
- > >could apply the term "source routing" to the W6XXX.CA.US.NA type
- > >scheme. A "source routing", scheme as I understand it, is to specify
- > >the entire path , as is done on Usenet (foobar!nerdley!fonzy!..etc).
- >
- > If isn't W6XXX.ca.us.na source routing, then W6XXX should be sufficent,
- > right? Source routing is defined as the originator describing the
- > path to reach a location.
- >
- > In the about case, we've tried to "qualify" the name with a path
- > as well. Yes, I know some would argue that .ca.us.na is a "location",
- > but how does a location differ from an "address"?
- >
- In thinking about this "location" business further, I remain convinced
- that is is not "source routing", as a *path* must be specified for true
- "source routing". However, on further relection, I *do* see a problem
- which could be best expressed as a violation of the principle of
- "letting the *network* do the *work*".
-
- I think what a lot of people are saying is that the *user* should only
- have to know the *name* of the entity receiving mail. If W6XXX.NOCAL.USA.NA
- suddenly moves to *Maine*, what becomes of mail addressed to the above
- address/location ? If the mail were addressed only to W6XXX, it would only
- be necessary for the nameservers of the network to be re-educated by
- some routing exchange protocol in order for the mail to be correctly
- delivered. The user would not need to know of the change.
-
- > >
- > >The ham packet network is not a network in the same sense as the
- > >Internet. It is a "bucket brigade". The decision that needs to be
-
- (stuff deleted)...
- >
- > I agree at the present data rates and physical layer protocols,
- > connectivity isn't the best, but a number of Hams are working to radically
- > alter that situation. WHEN that comes about, the nameserver idea will
- > be practical, and the benefits will be obvious.
- >
- What we really need to weigh carefully is that in using the "location"
- scheme, we are really putting the onus on the user to make up for
- inadequacies in the network. Is this a case of pragmatism, or is it
- a case of a quick and dirty fix ? I want to think about this some more!
-
- > N6RCE
-
- -73
- Jim, W2XO
-
- ------------------------------
-
- Date: 13 Jan 90 14:01:58 GMT
- From: brian@ucsd.edu (Brian Kantor)
- Subject: A location is not a route.
- Message-ID: <11033@ucsd.Edu>
-
- W6ABC@W6ZZZ.SAN.CA.USA is *** NOT *** a source route. It is a
- hostname/address ("W6ZZZ") with appended routing hints ("SAN.CA.USA")
- which the systems forwarding the message are free to disregard.
-
- The entire problem, in my opinion, is that the string on the right hand
- side of the "@" looks like an internet domain address and is therefore
- confusing. The idea, method, and semantics of the W0RLI addresses are
- not a problem. It is just their appearance.
-
- Someone (Dan Frank?) has suggested altering this to a more X.400-style
- of address, something like
- W6ABC@W6ZZZ{city=SAN,state=CA,country=USA}
- which preserves PRECISELY the same meaning as the current W0RLI address
- string. I have a problem with the verbosity of such an address but the
- idea is good. It has the great advantage that parts of a location
- (=routing hint) string can be omitted and the rest still parsed quite
- easily. (As in X.400, the "city", "state", etc can be abbreviated so
- that you don't have type the whole thing.
-
- It would also cause a considerable ripple in the network were we to
- convert to Dan's scheme, although the W0RLI BBS software could be
- modified to accept either but only emit the {} version, which would
- ease the pain of transition. I think it would be an ideal solution for
- a network such as the W0RLI BBSs which are hosted on machines too small
- to contain a complete routing table for the entire network - and for
- which no method exists for disseminating such a routing table even if
- one existed.
-
- In the short term, perhaps it would be better to replace either the
- first or all of the dots (".") in the W0RLI address string with some
- other character - for example, a virgule ("/"). A W0RLI-to-internet mail
- gateway could easily parse on that and separate the routing hints from
- the hostname quite easily. I can even envision such building a routing
- table from observed BBS traffic, much as Dave Mills suggested in his
- "wiretap" routing paper a few years ago. Such a routing table would be
- of great use in going the opposite way in an internet-to-W0RLI mail gateway.
- - Brian
-
- ------------------------------
-
- Date: 13 Jan 90 18:29:23 GMT
- From: zaphod.mps.ohio-state.edu!usc!samsung!aplcen!haven!sayshell.umd.edu!louie@tut.cis.ohio-state.edu (Louis A. Mamakos)
- Subject: ka9q tcp/ip amiga ???
- Message-ID: <1990Jan13.182923.16875@haven.umd.edu>
-
- A version of the KA9Q TCP/IP code is available for anonymous FTP from
- SAYSHELL.UMD.EDU. It is a port of the the NOS 890830 version; as I
- speak, er, type, I'm doing a port of the NOS 900105 version, which
- should also be available soon. Look for a file in /pub directory
- called amiganos.zoo.
-
- This is not a "production" release of the KA9Q code. The code base
- that I am porting from has not yet been released either, and no
- documentation has been prepared. I am more interested in having
- people *test* it, rather than use it as production quality software.
- Idealy, you should already have some expierence with the NOS code.
-
- The distribution is in ZOO format, and includes all the sources
- necessary to build it. You will need Lattice C 5.04 to compile it,
- and a system with a hard disk. On my system (A2000, 1M memory, A2090
- controller, medium speed 30MB hard disk), it takes a little over an
- hour to compile and link all of the modules.
-
- Before anyone asks, no, I can't mail copies of this to people. If you
- can't FTP it, you're out of luck. The "release" version will likely
- appear on a Fish Disk and probably also be available from TAPR, along
- with the PC version. Don't look for the release version for the Amiga
- until after the PC/MSDOS version since that's the porting base.
-
- louie WA3YMH
-
- ------------------------------
-
- Date: 11 Jan 90 18:28:04 GMT
- From: mitel!sce!cognos!dgbt!barry@uunet.uu.net (Barry McLarnon DGBT/DIP)
- Subject: Making things more difficult than necessary (was: Tasco TNC info)
- Message-ID: <1348@dgbt.uucp>
-
- From article <4390109@col.hp.com>, by bdale@col.hp.com (Bdale Garbee):
- >>Or, yet another possibility: To avoid messy soldering (on the EPROM, at
- >>least), obtain a 27C512 and copy your original ROM into one half of the
- >>64K address space, and KISS into the other half. Then use the switch as
- >>a ROM select by changing the state of the A14 line.
- >
- > Le Huh?
- >
- > The KISS for the u21 that I made available is a copy of all the functionality
- > provided in the standard firmware, plus KISS ala the TAPR 1.1.6 w/KISS EPROM.
- >
- > It is *not* KISS-only, and as such, there's no need for piggybacking, or
- > anything!
-
- Huh yourself. In spite of the Subject line, this thread diverged some time
- ago into a discussion of alternate firmwares for the generic TNC-2. The issue
- is that the KISS in the combined firmware like 1.1.6 and variants sometimes
- gives problems, viz: popping out of KISS mode, not responding to 'param ax0
- 255', etc. Hardware switching of modes adds a degree of robustness, when
- there is a KISS-only implementation. Another consideration is that there are
- some KISS-only variants, such as JKISS by G8BPQ, which appear to have some
- improvements over the standard K3MC release, and piggybacking gives you a
- way of trying them out.
-
- > Bdale
-
- Barry
- --
- Barry McLarnon Communications Research Center Ottawa, ON Canada
- UUCP: ...utzoo!dciem!nrcaer!dgbt!barry INTERNET: barry@dgbt.crc.dnd.ca
- CI$: 71470,3651 PBBS: VE3JF@VE3JF AMPRnet: barry@bbs.ve3jf [44.135.96.6]
-
- ------------------------------
-
- Date: 13 Jan 90 02:55:29 GMT
- From: dsl.pitt.edu!pitt!w2xo!durham@pt.cs.cmu.edu (Jim Durham)
- Subject: PBBS forwarding via dialup modem?
- Message-ID: <121@w2xo.UUCP>
-
- > In article <9001100505.AA01654@nips.ssesco.com>, elmquist@NIPS.SSESCO.COM writes:
- > > Just wondering if any of the PBBS packages (RLI, MBL, AA4RE, etc) have any
- > > provisions for forwarding traffic via dialup modem? I guess it would work
- > -deleted-
- > >
- > > Any ideas? flames? Chris N0JCF
- >
- > We are using telco/uucp to forward between three systems here in the
- > Little Rock area. I have written a RLI, et all, compatible PBBS on
- > my Xenix 286 and also interfaced into ka9q's net software.
- >
- > Forwarding works fine, but the actual transfer is handled by the
- > mail rather than the PBBS doing the actual calling. Why worry about
- >
- > I also have several users that use uucp mail to send and receive packet
- > mail through my system. Incoming packet messages are automaticly mailed
- (stuff deleted)
- > Am interested in experimenting more with mail forwarding via uucp to
- > : Richard Duncan WD5B Packet: WD5B @ WD5B.AR.USA.NA :
-
- I also am running my own PBBS code under Unix SYSV. I am running KA9Q
- as an AX25, Net/Rom and TCP/IP "front end" for my PBBS. The PBBS is
- simply an ordinary Unix Process which can be run from either KA9Q,
- a local terminal or from the telephone modem. In the "local mode", you
- simply run the bbs program as you would any program.. ie; "xobbs w2xo"
- would bring up the bbs and identify the user's call. Another system
- could call in, bring up the bbs with it's call, and send mail just
- as if it were logged in "over the air". By sending the usual "F>" at
- the end of the session, reverse forwarding would be initiated and
- all mail for the calling bbs would be sent. Of course, the usual Unix
- login: and password: gauntlet would have to be passed to get to the
- Unix command prompt initially. I have not written anything to initiate
- telephone forwarding, as I really hadn't thought of doing this until
- I saw N0JCF's article, but it should be pretty straight-forward to
- write an litte "daemon" process to do telephone forwarding inititation.
-
- IMHO, it would be a lot easier to do what you want, Chris, with
- Unix or Xenix than with DOS, if only so that your system could
- answer the phone any time a call came in from another system. This
- would be tough to do without multi-tasking, at least.
-
- Incidentally, I also have a UUCP to PBBS mail gateway in both directions
- operating as well as a Usenet News function in the PBBS.
-
- I am interested in hearing of anyone else who is doing work
- with Unix or Xenix based PBBS systems.
-
- -73
- Jim, W2XO (W2XO @ W2XO)
-
- ------------------------------
-
- Date: 11 Jan 90 18:56:55 GMT
- From: mcsun!ukc!axion!vision!davel@uunet.uu.net (Dave Lockwood)
- Subject: PBBS forwarding via dialup modem?
- Message-ID: <867@vision.UUCP>
-
- In article <9001100505.AA01654@nips.ssesco.com> elmquist@NIPS.SSESCO.COM writes:
- >Just wondering if any of the PBBS packages (RLI, MBL, AA4RE, etc) have any
- >provisions for forwarding traffic via dialup modem?
-
- W0RLI claims to have it (10.3 was the last I saw) and AA4RE again. Of the two,
- I'd prefer the latter from what I've seen (I ran a PBBS for a couple of
- years :-).
-
- Incidentally, whatever happened to WA7MBL?
-
- --
- --------------------------------------------------------------------------------
- * I I Dave Lockwood These opinions are shareware.
- * II Technical Consultant If you like them, send $10...
- * I * *
- * ** * davel@vision.UUCP VisionWare Ltd,
- * * * * ...!uunet!mcsun!ukc!vision!davel Leeds Business Park,
- ** ** +44-532-522020 X2439 Leeds, LS27 0JG,
- * * United Kingdom
- VISIONWARE DOS/UNIX Integration
- --------------------------------------------------------------------------------
-
- ------------------------------
-
- End of PACKET-RADIO Digest V90 Issue #11
- ****************************************
- 14-Jan-90 12:19:45-MST,10171;000000000000
- Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
- Date: Sun, 14 Jan 90 12:15:47 MST
- From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
- Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
- Subject: PACKET-RADIO Digest V90 #12
- To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
-
- PACKET-RADIO Digest Sun, 14 Jan 90 Volume 90 : Issue 12
-
- Today's Topics:
- hapn card-TNC info wanted
- Looking for Latest WA7MBL PBBS Software
- PBBS forwarding via dialup modem?
- Radar-detector detector
- Radar detectors on 3cm
- Removal of R: lines needed
- Routes, Names, Locations
- WA4DSY Duplex Repeater Info
- ----------------------------------------------------------------------
-
- Date: 13 Jan 90 01:46:13 GMT
- From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hpl.hp.com (Bdale Garbee)
- Subject: hapn card-TNC info wanted
- Message-ID: <4390113@col.hp.com>
-
- >4) And finally: Is there any reason why 89 ka9q doesn't
- > have hapn-support compiled to net.exe? (Of course I
- > can always compile it in, but I hate to torture my PC :-).
-
- Simple. When I compiled in all of the drivers that were available, the binary
- got to be *very* large. Since the HAPN (and other) cards are not so popular,
- it seemed like a good tradeoff to compile in the minimum set that most folks
- would want, and leave the rest available to anyone willing to recompile...
-
- Particularly given that one person in an area can do the recompile and share
- the binary with friends, this seemed like a good idea.
-
- Bdale, N3EUA
-
- ------------------------------
-
- Date: 13 Jan 90 20:07:11 GMT
- From: hp-pcd!hpspkla!dubner@hplabs.hpl.hp.com (Joseph L. Dubner)
- Subject: Looking for Latest WA7MBL PBBS Software
- Message-ID: <4640001@hpspkla.spk.hp.com>
-
- A local ham packet BBS SysOp (AH6AA) is running the WA7MBL verison 5.12
- PBBS software and asked me to try to find version 5.13 for him. Is this
- version available? Can anyone give me a pointer to it in an E-mailable or
- ftp-able form?
-
- Thanks and 73,
- Joe, K7JD
-
-
- --------------------------------------------------------------------
- Joe Dubner K7JD | H-P Spokane Division | dubner@hpspkla.HP.COM
- | Spokane, WA 99220 | (509) 921-3514
- --------------------------------------------------------------------
-
- ------------------------------
-
- Date: 13 Jan 90 01:44:13 GMT
- From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hpl.hp.com (Bdale Garbee)
- Subject: PBBS forwarding via dialup modem?
- Message-ID: <4390112@col.hp.com>
-
- This is done a lot in Japan... mostly with IP nodes, by periodically dialing
- up a slip link, and doing an 'smtp kick'. The timer functionality added to
- NET in Japan makes this pretty automatable.
-
- Bdale
-
- ------------------------------
-
- Date: 13 Jan 90 19:33:36 GMT
- From: usc!cs.utexas.edu!natinst!rpp386!puzzle!khijol!erc@ucsd.edu (Edwin R. Carp)
- Subject: Radar-detector detector
- Message-ID: <1011@khijol.UUCP>
-
- In article <22286@usc.edu> kjh@pollux.usc.edu (Kenneth J. Hendrickson N8DGN) writes:
-
- >I wonder if amateur radio operators are exempt from this foolishness? I
- >am active on the 3 cm band, and I do in fact use modified radar
- >detectors. I use them both for test equipment and communications
- >transcievers. Ontario may loose my tourist dollars with their little
- >ploy.
-
- Would you post details? Sounds interesting for point-to-point high-speed
- packet, control links, etc. for next to nothing!
- --
- Ed Carp N7EKG/5 (28.3-28.5) uunet!cs.utexas.edu!khijol!erc
- Austin, Texas (512) 832-5884 "Good tea. Nice house." - Worf
-
- ------------------------------
-
- Date: 14 Jan 90 05:31:34 GMT
- From: zaphod.mps.ohio-state.edu!usc!pollux.usc.edu!khendric@tut.cis.ohio-state.edu (Kenneth J. Hendrickson N8DGN)
- Subject: Radar detectors on 3cm
- Message-ID: <22304@usc.edu>
-
- In article <1011@khijol.UUCP> erc@khijol.UUCP (Edwin R. Carp) writes:
- >>I wonder if amateur radio operators are exempt from this foolishness? I
- >>am active on the 3 cm band, and I do in fact use modified radar
- >>detectors. I use them both for test equipment and communications
- >>transcievers.
- >Would you post details? Sounds interesting for point-to-point high-speed
- >packet, control links, etc. for next to nothing!
-
- Move the cavity down into the amateur band by changing the setting on
- the tuning screw that protrudes into the cavity. An exsiting rig with
- an IF strip tuned to a known frequency (or tunable) is useful here.
- Remove any wires going to the Gunn diode, and replace them with a
- regulated power supply capable of being modulated. Modulating the power
- supply voltage to the Gunn diode will both AM and FM the Gunn diode.
- Hook up an IF strip (perhaps with preamplifiers) to the mixer diode in
- the cavity. Add a good antenna, get a friend on 3cm, point it at him,
- and QSO. Wideband FM is exceptionally easy to get going, and provides
- very reasonable performance.
-
- ------------------------------
-
- Date: 14 Jan 90 16:30:36 GMT
- From: zaphod.mps.ohio-state.edu!wuarchive!swbatl!texbell!ark!lrark!argate!richard@tut.cis.ohio-state.edu (Richard Duncan)
- Subject: Removal of R: lines needed
- Message-ID: <15@argate.UUCP>
-
- This is addressed directly to PBBS writers particularly and users
- in general. Is the requirement still there for each PBBS to add
- a message received line (R:)?
-
- While I am not proposing the elimination of being able to trace
- a message, I am concerned about the amount of network time this
- information is taking. We have all seen mail with 20+ lines of
- R:'s and only 5 lines of text. There has been a lot of concern
- about routing, but little addressing of the problem once a route
- is established - getting it there.
-
- I just took a quick look (using wc and grep) of 383 messages here
- on my system. The 383 messages had 11167 lines of text. Of those
- 11167 lines, 3754 lines were R: tracings. That is 33%. This is
- not completely accurate as this assumes all lines are the same
- length, which they are not. I would venture to guess that the
- average actual text lines are SHORTER than the R: lines, thus
- making the percentage of required transmit time higher.
-
- Don't you think this is too much? I, again, can envision the need
- for tracing, but a simple callsign would suffice as in reading a
- message.
-
- Is the full R: line really required for anything other than ego?
-
- Is reducing to a single string of calls not sufficient to start
- a trace if required?
-
- Would it not be nice to have 33% (plus or minus) more time available
- for getting actual text across?
-
- :------------------------------------------------------------------:
- : Richard Duncan WD5B Packet: WD5B @ WD5B.AR.USA.NA :
- : Little Rock, AR BBS: 501/568-6809 (2400/1200) :
- : UUCP: ...!texbell!ark!lrark!argate!{richard|unetadm} :
- :------------------------------------------------------------------:
-
- ------------------------------
-
- Date: 13 Jan 90 01:17:53 GMT
- From: zephyr.ens.tek.com!tektronix!sequent!mntgfx!hanko@uunet.uu.net (Hank Oredson @ APD x1325)
- Subject: Routes, Names, Locations
- Message-ID: <1990Jan13.011753.927@mentor.com>
-
- Thought some of this had already been stomped out,
- but I see by the recent comments from n6rce that
- it has not. To take the specific example:
- W6XXX.ca.us.na .. which should actually be
- W6XXX.CA.USA.NA
- The ONLY thing the originator supplies is the
- W6XXX
- The software, using the cached information from
- the global name server, automatically appends
- .CA.USA.NA
- which indeed is a LOCATION, which is USED as if
- it were ROUTING HINTS.
-
- There ain't no source routing going on here folks.
-
- Of course, the system is flexible. One COULD supply
- the whole thing as the originator.\
-
- "But wait, there's more!"
-
- The originator probably did NOT supply even the W6XXX.
- He probably only supplied the destination USER callsign,
- N6ZZZ, and allowed the software to look up that users
- host (W6XXX), and that hosts location (CA.USA.NA).
-
- Since we have unique personal addresses, all of this
- is possible (now, working), with much more to come later.
-
- "But wait, there's more!"
-
- Once we have such a database (and we have it, NOW),
- we could choose to store other things in it. We do.
- We store QTH, zip code, handle, and information relating
- to the management of the data. Why not store other things?
- Simple: no one has asked. We COULD store the users IP
- address, for example, and thus be able to look up user
- given address or address given user, etc.
-
- The system works. The system is in phase 3 of a 5 phase
- development process. The system supports over 10,000
- hosts, and over 75,000 users. The system runs in over
- 100 countries. The system beats the US post office to
- all 50 states. Gee ... it ain't perfect. Got a better one?
-
- ... Hank - w0rli
-
- ------------------------------
-
- Date: 13 Jan 90 01:43:02 GMT
- From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hpl.hp.com (Bdale Garbee)
- Subject: WA4DSY Duplex Repeater Info
- Message-ID: <4390111@col.hp.com>
-
- >The advantage to our design is that we
- >"siphon off" the bits after demodulation so we can feed them to our IP
- >router/gateway/nameserver/network wonder object thereby allowing us to
- >have a node at our repeater site without investing in another DSY modem.
-
- This is a big win for a lot of sites, but it's worth pointing out that it's
- not uncommon for the best location for the switch to be in a different place
- than the best location for the local repeater...
-
- >All the rest of it is pretty much off the shelf..
-
- What are you guys using for the up and down converters? We're talking about
- building something nearly identical here in Colorado Springs, and I'm
- interested in your choice of RF pieces.
-
- Bdale
-
- ps: Barry, thanks for the schemo... it arrived fine.
-
- ------------------------------
-
- End of PACKET-RADIO Digest V90 Issue #12
- ****************************************
- 16-Jan-90 21:33:15-MST,10815;000000000000
- Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
- Date: Tue, 16 Jan 90 21:15:11 MST
- From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
- Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
- Subject: PACKET-RADIO Digest V90 #13
- To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
-
- PACKET-RADIO Digest Tue, 16 Jan 90 Volume 90 : Issue 13
-
- Today's Topics:
- A location is not a route
- BBS Source code & KISS specification needed
- G1NNA code via FTP?
- Mailbox source code
- Making things more difficult than necessary (was: Tasco TNC info)
- More DSY Modem Info
- New newsgroup rec.ham-radio.amsat?
- PK-88 RFI problems
- pk232 fax program.
- Re: Radar-detector detector
- Unix/KA9Q pty support for outgoing telnet
- ----------------------------------------------------------------------
-
- Date: Mon, 15 Jan 90 18:36:53 PST
- From: "Roy Engehausen" <ENGE@IBM.COM>
- Subject: A location is not a route
- Message-ID: <011590.183522.enge@ibm.com>
-
- I think we are arguing over semantics. Call the X6XXX.CA.USA.NA
- whatever you wish. In the absence of name servers, we had to do
- something. This implementation is working pretty good and getting
- better each day as more people start to use it.
-
- When the servers get running to where we can obtain reliable data in a
- few seconds, I will be happy consign the .CA.USA.NA to the waste bin.
-
- As far as alternate proposals, where were they when the paper was
- blank? The PBBS people have been working on this for over a year.
- There are over 20 authors of packet mailbox software on all continents
- making coordination of difficult but this is what we came up with.
- Now is not the time to start over from ground-zero. If there are
- proposals on how to integrate the PBBS addressing with AMPR.ORG, I am
- listening.
-
- Roy, AA4RE
-
-
- ------------------------------
-
- Date: 15 Jan 90 22:35:46 GMT
- From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hpl.hp.com (Bdale Garbee)
- Subject: BBS Source code & KISS specification needed
- Message-ID: <4390115@col.hp.com>
-
- >I also would like a quick pointer to information about
- >KISS - in particular, a specification or detailed info about the commands,
- >etc. If this is published anywhere (proceedings of ARRL Computer Networking
- >Conference ???), a simple citation will do.
-
- This was in the 6th or 7th ARRL conf proceedings, and is an appendix to
- userman.txt in the KA9Q documentation.
-
- > I don't suppose such a system already exists?? Reply via e-mail,
- > and I will summarize to the net. Many thanks!
-
- This functionality would be fairly easy for someone to add to the KA9Q
- package.
-
- Bdale
-
- ------------------------------
-
- Date: 16 Jan 90 00:19:52 GMT
- From: mcsun!sunic!tut!ousrvr!news@uunet.uu.net (Ari Husa OH8NUP)
- Subject: G1NNA code via FTP?
- Message-ID: <SO-LURU.90Jan16022326@stekt.oulu.fi>
-
- I would still like to give the G1NNA BBS a try. I am especially
- interested in the packing feature.
-
- So, what's the deal? Can I FTP it from somewhere or not?
-
- Luru
- --
-
- /// Ari Husa OH8NUP so-luru@stekt.oulu.fi
- o-o --... ...--
- o Ham Radio Operators Do It In Higher Frequency
-
- ------------------------------
-
- Date: Mon, 15 Jan 90 18:39:23 PST
- From: "Roy Engehausen" <ENGE@IBM.COM>
- Subject: Mailbox source code
- Message-ID: <011590.183657.enge@ibm.com>
-
- I think that source code is available for only two programs. CBBS and
- AA4RE BB. For the latter, KB7TV handles distribution for a nominal
- sum. The code is not for the faint hearted since its about 40,000
- lines of Turbo Pascal and takes up about 2MB on your disk when you
- compile it.
-
- Roy, AA4RE
-
- ------------------------------
-
- Date: 15 Jan 90 22:30:58 GMT
- From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hpl.hp.com (Bdale Garbee)
- Subject: Making things more difficult than necessary (was: Tasco TNC info)
- Message-ID: <4390114@col.hp.com>
-
- >Huh yourself. In spite of the Subject line, this thread diverged some time
- >ago into a discussion of alternate firmwares for the generic TNC-2.
-
- Ok, missed that.
-
- >piggybacking gives you a way of trying them out.
-
- Ok. That's valid. I'd do it differently (I swap ROM's in my TNC's routinely
- to try out new bits, so it doesn't bother me), but your point is made.
-
- Bdale
-
- ------------------------------
-
- Date: Tue, 16 Jan 90 11:58:22 EST
- From: DYUILL@CARLETON.CA
- Subject: More DSY Modem Info
- Message-ID: <900116.12460790.052874@CU.CP6>
-
- Bdale writes:
- >What are you guys using for up/down converters?
- After experimenting on 220Mhz using point to point links we wanted to
- maintain our investment in the Microwave Modules transverters we bought.
- 70cm receive converters from Microwave Modules cost about $75 so we went
- with those. A used 70cm transverter for the xmit side of the repeater
- left us with only a 220Mhz receiver converter to buy.
- We had to go with Advanced Receiver Research for the repeaters 220Mhz
- receive converter after Microwave Modules could not come through with
- anything for 220Mhz. A.R.R. is beter quality but requires a seperate
- pre-amp, guess what else A.R.R. makes?
- The repeater seems to be working well, although we are having a problem
- with dcd falsing at the user end. It seems we have enough intermod that
- some kind of bandpass filtering will be required by users living near
- pager sites.
- BTW, we are using a 2 cavity bandpass filter on the repeater input.
- I observe no falsing of the repeater dcd.
- We are using a Cushcraft 4 pole for 220 and a really nice 11.5db omni
- made by Diamond for 70cm which we bought from RF parts of San Marcos, CA.
- Having the extra gain at the ant. really helps make up for the 10w
- output of the transverter.
- Regarding switch vs repeater sites:
- I guess if you can run copper from your repeater to your switch you
- could use 4 wire line tranceivers. This may not be practical for you
- mountain dud's!
- --dy
- Doug Yuill VE3OCU@VE3JF.ONT.CAN.CA or DYUILL@CARLETON.CA
-
- ------------------------------
-
- Date: 14 Jan 90 21:23:01 GMT
- From: zephyr.ens.tek.com!tektronix!sequent!brians@uunet.uu.net (Brian Sheets)
- Subject: New newsgroup rec.ham-radio.amsat?
- Message-ID: <27737@sequent.UUCP>
-
- With the upcomming launch of the microsats as well as the present
- group of oscar/amsat guys in the air is there enough intrest on the net
- to warrent a new group for oscar/amsat users?
-
-
- --
- Brian Sheets KA7KDX _ /| "I'll be back"
- 5544 N Burrage. \`o_O'
- Portland Or. 97217 ( ) Aachk! - Arnold Schwarzenegger,
- 503-526-4091 U Phft! Any movie he's been in.
-
- ------------------------------
-
- Date: 16 Jan 90 23:55:52 GMT
- From: jupiter!karn@bellcore.com (Phil R. Karn)
- Subject: PK-88 RFI problems
- Message-ID: <19022@bellcore.bellcore.com>
-
- In article <3333@cbnewsj.ATT.COM> kfr@cbnewsj.ATT.COM (k.redden,lz,) writes:
- >AEA says the clock on the PK-88 does indeed put out a birdie on 145.01, but
- >they do have a mod you can make to fix the situation. The clock frequency is
- >controlled by C38, a 33 pF capacitor. If you change this to an 82 pF cap
- >(use a silver mica cap), it will lower the clock frequency enough to move
- >the birdie out of the packet band.
-
- That's called "sweeping the dirt under the rug". I agree that this may
- be the most expedient thing to do here, but computer RFI has long been a
- pet peeve of mine. Perhaps the Taiwanese who build PC clones can be
- partially excused, but digital hardware designers who build products
- intended specifically for use with radio transceivers ought to know
- better by now. Over and over again they'll design a new product without
- any advance consideration to RFI, and after they build the prototype
- they never fail to be surprised at how much crap it emits. Then they'll
- kludge up a test version that barely squeaks by the FCC Class B
- requirements. Even if the production models are as good, Class B is
- simply not good enough for an Oscar-class amateur station. And then it's
- up to us consumers to live with the problem or to try to fix it. Over
- the past week I've almost worn out my electric drill removing paint from
- the interiors of various cabinets in my shack to improve electrical
- contact when they're closed.
-
- I don't mean to single out AEA here; ALL of the amateur TNC
- manufacturers are guilty of being more concerned about fancy cabinet
- paint jobs and picking connectors that shave a few pennies off their
- manufacturing costs than they are about building a RFI-clean product.
- The only exception I know of is Hadron, which packages PACCOMM TNC-200
- boards in Tempested boxes for the military. Unfortunately, I can't
- afford one.
-
- Perhaps the FCC ought to revise its Class B requirements to match those
- of Tempest. I bet we'd see some innovative, low cost RF shielding
- techniques appear real fast! :-)
-
- Phil
-
- ------------------------------
-
- Date: Tue, 16 Jan 1990 10:11 EDT
- From: Mark Bramwell 519 661-3714 <watmath!ria.ccs.uwo.ca!business.uwo.ca!MBramwel@uunet.UU.NET>
- Subject: pk232 fax program.
- Message-ID: <9001161521.AA22301@ria.ccs.uwo.ca>
-
- I recently purchased a pk232 mbx and also got the pc pakratt and pk fax
- program. When I run the pkfax, it gives an error about the hardware
- not supporting fax. This is the lastest pk232, however, do I need a special
- pkfax version? If so, what is the date of the software?
-
-
- de VE3PZR.
-
- ------------------------------
-
- Date: 15 Jan 90 22:40:30 GMT
- From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hpl.hp.com (Bdale Garbee)
- Subject: Re: Radar-detector detector
- Message-ID: <4390117@col.hp.com>
-
- See the 12/89 issue of Ham Radio magazine, the article by N6GN and N6RCE...
-
- Bdale
-
- ------------------------------
-
- Date: 15 Jan 90 22:37:57 GMT
- From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hpl.hp.com (Bdale Garbee)
- Subject: Unix/KA9Q pty support for outgoing telnet
- Message-ID: <4390116@col.hp.com>
-
- >I'm running the ka9q software on a unix system w/o tcp/ip support (Sys V).
-
- Anders Klemets at SICS has gotten NOS running under sysVr3 using shared memory
- and semaphores in such a way that the protocol modules and interface I/O are
- separate processes, and you have user commands to do things, ala BSD.
-
- I think his net address is klemets@sics.se, his bits are certainly available
- from the machine sics.se with anonymous FTP. Not sure what revs of sysV it is
- likely to work under, though.
-
- Bdale
-
- ------------------------------
-
- End of PACKET-RADIO Digest V90 Issue #13
- ****************************************
- 18-Jan-90 10:31:33-MST,9666;000000000000
- Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
- Date: Thu, 18 Jan 90 10:15:15 MST
- From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
- Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
- Subject: PACKET-RADIO Digest V90 #14
- To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
-
- PACKET-RADIO Digest Thu, 18 Jan 90 Volume 90 : Issue 14
-
- Today's Topics:
- Dual-band HTs: recommendations/comments sought
- EPROM vs EEPROMs (or how to have your cake and eat it also)
- FIXMAIL 1.06 released!
- PK-88 RFI problems (2 msgs)
- pk232 fax program.
- Sick TAPR Board, Advice Needed
- ----------------------------------------------------------------------
-
- Date: 17 Jan 90 21:07:36 GMT
- From: young@ee.ecn.purdue.edu (Mike Young)
- Subject: Dual-band HTs: recommendations/comments sought
- Message-ID: <14182@pur-ee.UUCP>
-
- I am on the brink of blowing some Christmas money on (probably) a
- 2m/440 HT. Under consideration are the Yaesu FT470, Icom IC32AT or 24AT,
- Kenwood TH75A, and the Alinco DJ500T. (Have I missed any???) I hereby solicit,
- invite, and otherwise open the floor to any and all comments, recommendations,
- warnings, experiences, or (yes, even) horror stories related to any of these
- rigs, their respective manufacturers, or the dealerships at which they were
- purchased.
-
- A little background: I intend to use the rig for general yakking thru
- the local 2m repeaters (and soon the 440 repeater...); I suspect I will
- eventually stick an antenna up at home and get into packet too.
-
- A hearty thanks in advance to all respondents. Mail responses to me,
- or post if you think appropriate. I might be coaxed into posting a summary of
- responses after I make the purchase :-)
-
- Mike Young KA9HZE
- Purdue University EE Dept.
- W. Lafayette IN 47907
-
- young@ecn.purdue.edu
- ...!pur-ee!young
-
- ------------------------------
-
- Date: Wed, 17 Jan T 14:12:23 -0800
- From: Dana Myers <lcc!dana@seas.ucla.edu>
- Subject: EPROM vs EEPROMs (or how to have your cake and eat it also)
- Message-ID: <9001172224.AA06577@elrond.locus.com>
-
- I've been building various microcontroller based gadgets over the last year.
- For the sake of simplicity, they just use ROM based software rather than
- having RAM and a monitor and a serial port and a monitor and downloading.
-
- I couldn't bring myself to buy an EPROM programmer and a tubeful of
- 2764s. The programmer is > $200 (I don't have an XT clone with a bus - I
- have a bus-less portable and can't use the $150 bus programmers). An
- ultraviolet eraser is at least $25 or $30. The turnaround time on any given
- EPROM is 45 minutes or more. So, yeah, you keep a handful and cycle through
- them. What a hassle.
-
- You can get a 2864 EEPROM which will plug right into a 2764 socket. Program-
- ming them is close to trivial - in one of my micro- controllers (one that does
- have RAM and a monitor and a serial port) I use a spare socket and a short
- program which does the write/data poll sequence required. An 8k EEPROM programs
- in a few seconds. There is no erasing time. The socket you write to it in need
- only be configured for use with a byte wide RAM (like a 6164).
-
- I bought some Xicor EEPROMs which were about $20 each. I've seen adds for
- some other 2864 EEPROMs at around $10 each. 2764 EPROMs run about $5 for 250
- nS parts. The higher cost is essentially offset if you don't buy an EPROM
- programmer. The "near zero" tuen around time is worth the $$ alone. If you
- are going to reproduce a bunch a ROMs, though, use the EPROMs.
-
-
- Dana H. Myers WA6ZGB (Halfway to QCWA and I'm not grey yet ;-)
- Locus Computing Corp.
- Inglewood, CA
- lcc!dana@seas.ucla.edu
-
- ------------------------------
-
- Date: Thu, 18 Jan 90 10:26:18 GMT
- From: pat.davis@mail.admin.wisc.edu
- Subject: FIXMAIL 1.06 released!
- Message-ID: <2064@pgd.adp.wisc.edu>
-
- FYI- FIXMAIL version 1.06 by Bryan DK Biggers, N9GBJ, is posted on:
-
- pgd.adp.wisc.edu 128.104.198.22 as: FIXM106.zip (pkz102.exe, req'd to UNZIP
- it, is also there.. pkz102.exe is a self-extracting ZIPfile. PKZ102.exe is
- SHAREWARE from Paul Katz).
-
- FIXMAIL is a powerful utility for dealing with Bmailer mail. V1.06 does what
- the previous releases did but there are also NEW capabilities:
-
- You can now automate the process of censoring forwarded mail.. So, if you
- are gatewaying mail onto Amateur Radio bands, this IS for YOU!
-
- If you run FIXMAIL in a Desqview window, you can invoke Desqview macros from
- a 'command file' or '.TXT' file. In addition, FIXMAIL 1.06 allows DOS
- commands to be in the 'command' file.. This newer feature allows you to do
- some extremely powerful (possibly dangerous) things with your station.
-
-
- ------------------------------
-
- Date: 18 Jan 90 03:15:39 GMT
- From: root@sbcs.sunysb.edu (Systems Staff)
- Subject: PK-88 RFI problems
- Message-ID: <4488@sbcs.sunysb.edu>
-
- In article <19022@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes:
- >In article <3333@cbnewsj.ATT.COM> kfr@cbnewsj.ATT.COM (k.redden,lz,) writes:
- >Perhaps the FCC ought to revise its Class B requirements to match those
- >of Tempest. I bet we'd see some innovative, low cost RF shielding
- >techniques appear real fast! :-)
- >Phil
-
- One hopes you are just joking in even suggesting that class B be revised
- for more stringent emission requirements. It is enough of a pain in the
- neck to get something simple like an Ethernet board that includes a cheapernet
- xcvr to pass class B as things stand. I dread the day that I have to try
- to get a high res graphics controller to pass B :-) As hams we have to realize
- that sometimes all the items on our shopping list (eg low emissions from
- commercial equipment, free and clear use of spectrum, etc) don't always match
- up with the needs of the much larger general marketplace.
-
- Agreed that TNC mfgs in particular should know enough to reduce RFI. The
- ones that should be particular sensitive to the issue are those who
- offer RF products as well as their digital lines.
-
- Rick Spanbauer/WB2CFV
- State U of NY @ Stony Brook
-
- ------------------------------
-
- Date: 18 Jan 90 04:42:55 GMT
- From: ka9q.bellcore.com!karn@bellcore.com (Phil Karn)
- Subject: PK-88 RFI problems
- Message-ID: <19099@bellcore.bellcore.com>
-
- WB2CFV:
- >One hopes you are just joking in even suggesting that class B be revised
- >for more stringent emission requirements. It is enough of a pain in the
- >neck to get something simple like an Ethernet board that includes a cheapernet
- >xcvr to pass class B as things stand.
-
- No, I'm perfectly serious. It's funny you should mention Ethernet boards
- with Cheapernet transceivers, as that's another hot button of mine. The
- state of the RFI suppression art (such as it is) on these things is
- downright criminal. The only board to do a halfway decent job in bypassing
- the Cheapernet connector was the original long-card version of the 3Com
- 3C501 - it's a shame the rest of its design is so bad. It had a well-
- designed pi-network filter on the BNC connector. A ferrite ring around the
- connector formed the L, and there are three bypass caps with short leads to
- chassis ground from each side of the ferrite.
-
- Later versions of the 3C501 watered this down (with predictable results),
- and some other manufacturers I could name do even worse. The Cheapernet
- connector "filtering" in most PC ethernet cards nowadays consists of nothing
- more than a single cap to ground, and it's not even located on the connector
- to avoid ground loops. I finally had to give up and go to external DIX
- transceivers here in the shack to get the HF RFI down to semi-acceptable
- levels. It wasn't my own communications that were being interfered with (I
- almost never operate HF), it was my next door neighbor (K2QWG)!
-
- The reason that I get so upset about RFI in computer equipment is that it's
- far easier to solve the problem in the initial design than it is to try to
- fix it afterwards. This is especially true when the job falls to the buyer
- (e.g., me). I have no more sympathy for computer manufacturers who complain
- about the cost of RFI control than I do for car manufacturers who complain
- about the cost of emission control.
-
- Phil
-
- ------------------------------
-
- Date: 17 Jan 90 21:34:02 GMT
- From: hpda!hpcupt1!bmp@ucbvax.Berkeley.EDU (Brian M. Perkin)
- Subject: pk232 fax program.
- Message-ID: <7400019@hpcupt1.HP.COM>
-
- The AEA rep told me at the ham convention in San Jose
- in October 89, that if I upgraded a standard PK-232
- to the mailbox version, then I would need an upgraded
- pkfax version. Give AEA a call.
-
- Brian
- N6RSW
-
- ------------------------------
-
- Date: 18 Jan 90 15:35:16 GMT
- From: lectroid!k1te@CS.BU.EDU (Bradshaw Lupton)
- Subject: Sick TAPR Board, Advice Needed
- Message-ID: <585@lectroid.sw.stratus.com>
-
- If anyone knows the meaning of led D1 & D2 flashing in 1 sec interval on an
- '83 TAPR Board I would appreciate knowing it.
-
- Something about "unable to initialize VIA" then a barberpole display of
- the BTEXT appeared shortly before the catatonic state.
-
- tnx K1TE
- --
- *-----------------------*---------------------------*------------------------*
- | Bradshaw B. Lupton Jr.| Stratus Computer, Marlboro| Ma 01752 508 490 6484 |
- | Lupton@es.stratus.com | uunet!lectroid!es!Lupton | es!Lupton@uunet.uu.net |
- *-----------------------*---------------------------*------------------------*
-
- ------------------------------
-
- End of PACKET-RADIO Digest V90 Issue #14
- ****************************************
- 18-Jan-90 21:26:24-MST,12901;000000000000
- Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
- Date: Thu, 18 Jan 90 21:15:25 MST
- From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
- Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
- Subject: PACKET-RADIO Digest V90 #15
- To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
-
- PACKET-RADIO Digest Thu, 18 Jan 90 Volume 90 : Issue 15
-
- Today's Topics:
- Heath Pocket TNC KISS ROMS
- New newsgroup rec.ham-radio.amsat?
- PEACESAT Data Communication Project
- Radar-detector detector (3 msgs)
- RFI & radios (was: PK-88 RFI problems)
- Unix/KA9Q pty support for outgoing telnet
- ----------------------------------------------------------------------
-
- Date: 18 Jan 90 05:16:04 GMT
- From: cs.utexas.edu!helps!bongo!julian@tut.cis.ohio-state.edu (julian macassey)
- Subject: Heath Pocket TNC KISS ROMS
- Message-ID: <294@bongo.UUCP>
-
- >Date: Tue, 26 Dec 89 08:20:31 mst
- >From: Bdale Garbee <bdale@hpcsos.col.hp.com>
- >Message-Id: <8912261520.AA01666@hpcsos.col.hp.com>
- >To: tcp-group@ucsd.edu
- >Subject: Heath/Tasco u21 KISS
- >Status: OR
-
- >I have placed on col.hp.com, in ~ftp/ka9q/etc, the file u21_kiss.rom. This
- >is a binary image of a 27256 EPROM for the Heath/Tasco micro TNC that is a
- >copy of the normal firmware with KISS support included.
-
- I have had trouble getting someone to get into col.hp.com to
- grab this file. Is it available for ftp from any other sites -
- seems from Greater Disneyland people have trouble getting files
- from col.hp.com - at least the people I try and cajole into
- midnight ftp sessions. Better yet, is it available on floppy from
- anyone? Or is it on a regular dialup bbs? I would really like to
- get my pocket TNC doing KISS. Portable tcp/ip is too good to pass
- up.
-
- Any disk/mailer expenses will be covered. If I get the code,
- anyone is then welcome to a copy on MS-DOS disk from me.
-
- Yours
-
-
- --
- Julian Macassey, n6are julian@bongo.info.com {ucla-an!denwa!bongo!julian
- N6ARE@K6IYK (Packet Radio) n6are.ampr.org [44.16.0.81] voice (213) 653-4495
-
- ------------------------------
-
- Date: 16 Jan 90 19:12:01 GMT
- From: hpfcso!hpldola!hp-lsd!col!bdale@hplabs.hpl.hp.com (Bdale Garbee)
- Subject: New newsgroup rec.ham-radio.amsat?
- Message-ID: <4390118@col.hp.com>
-
- >With the upcomming launch of the microsats as well as the present
- >group of oscar/amsat guys in the air is there enough intrest on the net
- >to warrent a new group for oscar/amsat users?
-
- Since the microsats are inherently digital, I'd suggest we focus microsat
- discussion here in rec.ham-radio.packet, at least until it becomes an
- unwelcome burden on the readership (if it does!).
-
- 73 - Bdale, N3EUA
-
- ------------------------------
-
- Date: 19 Jan 90 02:52:20 GMT
- From: uhccux!mikeg@ames.arc.nasa.gov (Mike Gonsalves)
- Subject: PEACESAT Data Communication Project
- Message-ID: <6252@uhccux.uhcc.hawaii.edu>
-
- I am a consultant to the PEACESAT Data Communication Project here
- at the Social Sciences Research Institute, University of Hawaii.
- For those of you unfamiliar with PEACESAT, the Pan Pacific
- Education And Communication Experiment Satellite is an association
- of independent, autonomous terminal sites located throughout the
- Pacific. Its purposes are to use satellite communication
- technology for education, experimentation, and health-related
- emergencies. All activities are non-commercial.
-
- The objectives of the Data Communication Project are to provide a
- BBS-type store-and-forward messaging system with the following
- capabilities:
-
- - E-mail
-
- - Bulletin Board
-
- - Airtime scheduling for ATS-1, ATS-3 and GOES
-
- - Facsimile service
-
- - Interactive Access to Remote Systems (such as
- OPAC, DIALOGUE, and BITNET/Internet) through
- a UH host computer
-
- - Remote users in the Pacific Isles can use
- Honolulu hub system to automatically dial
- emergency numbers with automatic cut-off to
- voice patch
-
- Ease-of-use is VERY important.
-
- We have been experimenting with the W0RLI BBS software (version
- 11.7) as a means of providing electronic messaging and access to
- remote systems. I'm having a problem with the gateway feature.
- When I call out on port B, which has an Evercom 2400e on it, I can
- connect with the UH computer network, but I don't get all the
- prompts on my remote display, even though they all show on the
- W0RLI system display. Specifically, any line that does not end in
- CR does not come across to the remote system. This is really
- awkward because most of these lines are prompts to log on, provide
- a password, or issue a command. I have tried setting PACTIME and
- CPACTIME on the W0RLI TNC (a Kantronics KPC-2400), but to no avail.
- Any ideas as to why this is happening and how we might work around
- this?
-
- I'm also looking for packet software that would accomplish the
- above objectives and run on SCO UNIX. Any recommendations,
- suggestions or comments would be most welcome!
-
- I'm new to ham-radio, packet, UNIX, and the news groups, so if I
- am missing something obvious, please excuse me.
-
- Mike Gonsalves
-
- ------------------------------
-
- Date: 18 Jan 90 17:03:40 GMT
- From: silver!amirza@iuvax.cs.indiana.edu (anmar mirza)
- Subject: Radar-detector detector
- Message-ID: <33327@iuvax.cs.indiana.edu>
-
- In article <1011@khijol.UUCP> erc@khijol.UUCP (Edwin R. Carp) writes:
- >In article <22286@usc.edu> kjh@pollux.usc.edu (Kenneth J. Hendrickson N8DGN) writes:
- >
- >>I wonder if amateur radio operators are exempt from this foolishness? I
- >>am active on the 3 cm band, and I do in fact use modified radar
- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- >>detectors. I use them both for test equipment and communications
- >>transcievers. Ontario may loose my tourist dollars with their little
- >>ploy.
-
- I wonder if those are type accepted for what you use them for? :->
-
- Anmar
-
- I agree, I hardly go to New Jersey for much the same reasons, I think
- their laws are largely unfair and restrictive.
-
- ------------------------------
-
- Date: 18 Jan 90 20:38:49 GMT
- 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)
- Subject: Radar-detector detector
- Message-ID: <22388@usc.edu>
-
- In article <33327@iuvax.cs.indiana.edu> amirza@silver.ucs.indiana.edu (anmar mirza) writes:
- >In article <1011@khijol.UUCP> erc@khijol.UUCP (Edwin R. Carp) writes:
- >>In article <22286@usc.edu> kjh@pollux.usc.edu (Kenneth J. Hendrickson N8DGN) writes:
- >>>am active on the 3 cm band, and I do in fact use modified radar detectors
- > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- >
- >I wonder if those are type accepted for what you use them for? :->
- >Anmar
-
- Type acceptance is _NOT_ required for any equipment operated in the
- amateur radio service. Indeed - you can and are encouraged to design and
- build your own equipment.
-
- In the rare case that original ideas Kenneth J. Hendrickson N8DGN
- are found here, I am responsible. 1709 S. Bonnie Brae, LA, CA 90006
- Internet: kjh@usc.edu UUCP: ...!uunet!usc!pollux!kjh
-
- ------------------------------
-
- Date: 19 Jan 90 02:20:19 GMT
- From: amdahl!kelly@sun.com (Kelly Goen)
- Subject: Radar-detector detector
- Message-ID: <59sJ02nA80C801@amdahl.uts.amdahl.com>
-
- In article <33327@iuvax.cs.indiana.edu> amirza@silver.ucs.indiana.edu (anmar mirza) writes:
- >In article <1011@khijol.UUCP> erc@khijol.UUCP (Edwin R. Carp) writes:
- >>In article <22286@usc.edu> kjh@pollux.usc.edu (Kenneth J. Hendrickson N8DGN) writes:
- >>
- >>>I wonder if amateur radio operators are exempt from this foolishness? I
- >>>am active on the 3 cm band, and I do in fact use modified radar
- > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- >>>detectors. I use them both for test equipment and communications
- >>>transcievers. Ontario may loose my tourist dollars with their little
- >>>ploy.
- >
- >I wonder if those are type accepted for what you use them for? :->
- >
- >Anmar
- >
- >I agree, I hardly go to New Jersey for much the same reasons, I think
- >their laws are largely unfair and restrictive.
- Amateur gear is specifically exempted from TYPE ACCEPTANCE requirements!!
- cheers
- kelly
-
- ------------------------------
-
- Date: 18 Jan 90 18:31:10 GMT
- From: zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!stda.jhuapl.edu!mjj@tut.cis.ohio-state.edu (Marshall Jose)
- Subject: RFI & radios (was: PK-88 RFI problems)
- Message-ID: <4517@aplcen.apl.jhu.edu>
-
- In article <19022@bellcore.bellcore.com> karn@jupiter.bellcore.com
- (Phil R. Karn) writes:
- >Perhaps the FCC ought to revise its Class B requirements to match those
- >of Tempest. I bet we'd see some innovative, low cost RF shielding
- >techniques appear real fast! :-)
- >Phil
-
- In article <4488@sbcs.sunysb.edu> root@sbcs.sunysb.edu
- (Rick Spanbauer/WB2CFV) writes:
-
- >One hopes you are just joking in even suggesting that class B be revised
- >for more stringent emission requirements. It is enough of a pain in the
- >neck to get something simple like an Ethernet board that includes a cheapernet
- >xcvr to pass class B as things stand. I dread the day that I have to try
- >to get a high res graphics controller to pass B :-) As hams we have to realize
- >that sometimes all the items on our shopping list (eg low emissions from
- >commercial equipment, free and clear use of spectrum, etc) don't always match
- >up with the needs of the much larger general marketplace.
-
- To which I respond:
-
- I agree with Phil. People think effective RFI shielding is expensive
- because Tempest products are costly; but Tempest in turn is costly because
- (a) usually it's a VAR technique (added to existing products) and (b) it's
- what the market will bear.
-
- Having spent a long time working with sensitive instrumentation (for
- what that's worth), I have concluded that effective shielding is a
- straightforward design matter as long as it's included in the design
- phase. Add-ons (short of brute-force steel boxes) rarely provide a
- satisfactory solution. When designing and laying-out the circuit, one
- must think like an electron or like an EM wave: "What paths are open
- for me to travel along?"
-
- Upon reflection, I must say I've noticed a tremendous difference in
- computer RFI since the FCC laid down the law. In the early days my
- POLY-88 running my morse-code-copying program made itself useless by
- trashing the station it was copying. Nowadays, I'm surrounded by CPUs
- in my station, none of which are objectionable RFI sources.
-
- The variety of lossy ferrites and chip bypass capacitors I see at
- the hamfests lately tells me designers could clean things up if
- they wanted to. Read that, "If it was economically advantageous
- for them to do so".
-
- Cheers,
- Marshall Jose WA3VPZ
- mjj@aplvax.jhuapl.edu || ...mimsy!aplcen!aplvax!mjj
-
- ------------------------------
-
- Date: 18 Jan 90 14:22:51 GMT
- From: zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!texbell!splut!jay@tut.cis.ohio-state.edu (Jay "you ignorant splut!" Maynard)
- Subject: Unix/KA9Q pty support for outgoing telnet
- Message-ID: <C#F:-FA@splut.conmicro.com>
-
- In article <4390116@col.hp.com> bdale@col.hp.com (Bdale Garbee) writes:
- >Anders Klemets at SICS has gotten NOS running under sysVr3 using shared memory
- >and semaphores in such a way that the protocol modules and interface I/O are
- >separate processes, and you have user commands to do things, ala BSD.
-
- >I think his net address is klemets@sics.se, his bits are certainly available
- >from the machine sics.se with anonymous FTP. Not sure what revs of sysV it is
- >likely to work under, though.
-
- I've been (slowly...seems that my domain doesn't work from Sweden!)
- talking to Anders about this. There are actually two separate
- implementations involved: one uses a background daemon to do the
- protocols and interface I/O, and another uses streams modules pushed on
- top of the TTY driver. The streams stuff will only work under
- SysVr3...since I'm stuck at SysVr2, I'd like to get the other
- implementation (which he refers to as NETNIX in the 8th Conference
- paper), make it work on my system, and polish it up. That seems to be
- the right way to do it on Unix.
-
- --
- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
- jay@splut.conmicro.com (eieio)| adequately be explained by stupidity.
- {attctc,bellcore}!texbell!splut!jay +----------------------------------------
- "There is no doubt I should be tarred and feathered." - Richard Sexton
-
- ------------------------------
-
- End of PACKET-RADIO Digest V90 Issue #15
- ****************************************
- 19-Jan-90 11:24:33-MST,17601;000000000000
- Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
- Date: Fri, 19 Jan 90 11:15:22 MST
- From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
- Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
- Subject: PACKET-RADIO Digest V90 #16
- To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
-
- PACKET-RADIO Digest Fri, 19 Jan 90 Volume 90 : Issue 16
-
- Today's Topics:
- PK-88 RFI problems (5 msgs)
- RFI & radios (was: PK-88 RFI problems)
- ----------------------------------------------------------------------
-
- Date: 18 Jan 90 13:31:05 GMT
- From: cs.utexas.edu!helps!bongo!julian@tut.cis.ohio-state.edu (julian macassey)
- Subject: PK-88 RFI problems
- Message-ID: <295@bongo.UUCP>
-
- In article <19022@bellcore.bellcore.com>, karn@jupiter..bellcore.com (Phil R. Karn) writes:
- > In article <3333@cbnewsj.ATT.COM> kfr@cbnewsj.ATT.COM (k.redden,lz,) writes:
- > >AEA says the clock on the PK-88 does indeed put out a birdie on 145.01, but
- > >they do have a mod you can make to fix the situation. The clock frequency is
- > >controlled by C38, a 33 pF capacitor. If you change this to an 82 pF cap
- > >(use a silver mica cap), it will lower the clock frequency enough to move
- > >the birdie out of the packet band.
- >
- > That's called "sweeping the dirt under the rug". I agree that this may
- > be the most expedient thing to do here, but computer RFI has long been a
- > pet peeve of mine. Perhaps the Taiwanese who build PC clones can be
- > partially excused, but digital hardware designers who build products
- > intended specifically for use with radio transceivers ought to know
- > better by now. Over and over again they'll design a new product without
- > any advance consideration to RFI, and after they build the prototype
- > they never fail to be surprised at how much crap it emits. Then they'll
- > kludge up a test version that barely squeaks by the FCC Class B
- > requirements. Even if the production models are as good, Class B is
- > simply not good enough for an Oscar-class amateur station. And then it's
- > up to us consumers to live with the problem or to try to fix it. Over
- > the past week I've almost worn out my electric drill removing paint from
- > the interiors of various cabinets in my shack to improve electrical
- > contact when they're closed.
- >
- > I don't mean to single out AEA here; ALL of the amateur TNC
- > manufacturers are guilty of being more concerned about fancy cabinet
- > paint jobs and picking connectors that shave a few pennies off their
- > manufacturing costs than they are about building a RFI-clean product.
- > The only exception I know of is Hadron, which packages PACCOMM TNC-200
- > boards in Tempested boxes for the military. Unfortunately, I can't
- > afford one.
- >
- > Perhaps the FCC ought to revise its Class B requirements to match those
- > of Tempest. I bet we'd see some innovative, low cost RF shielding
- > techniques appear real fast! :-)
- >
- The FCC requirements are not so bad, it is the enforcement of
- those requirements that is lacking. I have been to many FCC sites
- - both U.S. and overseas - and seen "name brand" equipment made to
- pass FCC part 15 subpart J etc. What passes in no way represents
- what the consumer buys. When you see a computer with custom
- shielded cables, large ferrite chokes and caps everywhere pass
- Part 15, you are watching consumers being duped. Sure the lab
- will send all the mods to the manufacturer telling him to do them
- in production gear. But I haven't seen it happen yet.
-
- The major concern that most manufactures have during testing is
- how soon you can get the paperwork in so the unit can be on the
- market. I feel that most compliance departments are a division of
- sales. I have been shouted at for voicing concern about high crud
- levels rather than trying to get the paperwork shipped - Fed Ex
- of course - to the FCC. Yes, once someone tried to bribe me and
- others. A strange and impermanent way to reduce emissions.
-
- What we need is not tougher specs from the FCC, but tougher
- enforcement of those specs. The FCC should randomly buy equipment
- with their label on it an rigorsly test it. If it fails, close
- down the company's production line until it is fixed and fine
- them for each non-complying product shipped before. I would
- rather have the FCC do this with my dollars than chase people
- who use old english words that offend semi-literate religious
- fanatics. By the way, the FDA give manufacturers a hard time
- about non-complying products. Why don't the FCC?
-
- But I suppose we can do something too - besides modifying badly
- designed gear. We can ask ARRL, BYTE mag and others to include
- Part 15 compliance in their test reports. I bet that will make
- the fur fly. Also we can complain to manufacturers when their
- stuff is not up to par. And the last defence of capitalism, don't
- buy stuff that radiates.
-
- I feel much better now.
-
- --
- Julian Macassey, n6are julian@bongo.info.com {ucla-an!denwa!bongo!julian
- N6ARE@K6IYK (Packet Radio) n6are.ampr.org [44.16.0.81] voice (213) 653-4495
-
- ------------------------------
-
- Date: 19 Jan 90 15:11:15 GMT
- From: root@sbcs.sunysb.edu (Systems Staff)
- Subject: PK-88 RFI problems
- Message-ID: <4500@sbcs.sunysb.edu>
-
- In article <19099@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes:
- >WB2CFV:
- >>One hopes you are just joking in even suggesting that class B be revised
- >>for more stringent emission requirements. It is enough of a pain in the
- >>neck to get something simple like an Ethernet board that includes a cheapernet
- >>xcvr to pass class B as things stand.
- >
- >No, I'm perfectly serious. It's funny you should mention Ethernet boards
- >with Cheapernet transceivers, as that's another hot button of mine. The
- >state of the RFI suppression art (such as it is) on these things is
- >downright criminal. The only board to do a halfway decent job in bypassing
- >about the cost of RFI control than I do for car manufacturers who complain
- >about the cost of emission control.
-
- KA9Q, again, RFI control isn't an item that everyone on the
- planet dreams about at night. Car emissions are something that directly
- affect everyone; RFI emissions (in these days of cable TV/FM) have
- far less direct impact on John Q Public. I have a bunch of machines,
- all class B, sitting one room over from our consumer electronics.
- No interference. Of course they do inject quite a bit of noise into
- the low band and even 2M rigs. But then I am not about to ask my
- neighbors to underwrite my hobby through increased cost of electronics
- (to control RFI) simply because it is hard to work the high end of 20
- when their kids Tai PC clone is going. I tune down a bit and be cool.
- I mean, what next? Suggest that all color TV sets be required to
- meet Tempest simply because they produce some incidental emissions on
- 80? Or suggest that local governments adopt aggressive scrape and paint
- programs on municipal structures to ensure there are no sources of
- rectification? Dealing with RFI is something that we should learn to
- live with and you probably should buy a heavier duty drill :-)
-
- Seriously, this hobby has to realize we number only 300K -> 400K hams
- and start to act like it. I hear a lot of whining about antenna height
- restrictions, RFI, use of spectrum, inattention of FCC, etc - but the
- average ham seems to be incredibly myopic when it comes time to realize
- there are other point of view/rights at work in the world. Or more
- succinctly, your right to have a free datalink ends at the right of
- the public to have lower cellular phone rates (through fairer allocation of spectrum). Ah well. I guess you pushed one of my hot buttons :-)
-
- >Phil
-
- Rick Spanbauer, WB2CFV
-
- ------------------------------
-
- Date: 19 Jan 90 16:36:00 GMT
- From: agate!shelby!neon!kaufman@ucbvax.Berkeley.EDU (Marc T. Kaufman)
- Subject: PK-88 RFI problems
- Message-ID: <1990Jan19.163600.2960@Neon.Stanford.EDU>
-
- In article <4500@sbcs.sunysb.edu> root@sbcs.sunysb.edu (Systems Staff) writes:
-
- - ... I have a bunch of machines,
- - all class B, sitting one room over from our consumer electronics.
- - No interference. Of course they do inject quite a bit of noise into
- - the low band and even 2M rigs. But then I am not about to ask my
- - neighbors to underwrite my hobby through increased cost of electronics
- - (to control RFI) simply because it is hard to work the high end of 20
- - when their kids Tai PC clone is going. I tune down a bit and be cool.
- - I mean, what next? Suggest that all color TV sets be required to
- - meet Tempest simply because they produce some incidental emissions on
- - 80?
-
- Short sighted, I think. Incidental emissions increase the noise floor, so ALL
- users have to run higher power, which increases interference even more. We
- may be the first (?) to notice the crud on the band, but it affects all the
- users, even those who are not specifically aware of it.
-
- After all, the hole in the ozone layer is at the South Pole, how can it
- possibly affect me, safe here in the Northern Hemisphere?
-
- Marc Kaufman (kaufman@Neon.stanford.edu)
-
- ------------------------------
-
- Date: 19 Jan 90 17:28:12 GMT
- From: kchen@apple.com (Kok Chen)
- Subject: PK-88 RFI problems
- Message-ID: <37952@apple.Apple.COM>
-
- I used to think that I am the only one plagued by RFI/EMI from micros
- and TNCs. It seems that there are quite a few other folks are equally
- irritated.
-
- I still haven't completely solved my problems. My MFJ-1278 still puts
- out birdies on 20, 15 and 10 and, for gods sakes, even on 2m! This, for
- a TNC "designed" for Ham use. I can understand an East Asian clone maker
- not being sensitive to the needs of Hams, but a TNC manufacturer?? I
- have toroids on every cable connected to the unit and have been able
- to reduce some of the birdies by a dozen db. Even the power cable to
- it radiates like nobody's business. Why am I having to do this? I would
- gladly have paid an extra $100 for an RFI-clean unit.
-
- My micro problems are abated somewhat (the hash across 20m is perhaps 2
- to 3 "S" points lower) when I went from an AT-clone to a Mac IIcx, but
- the problems haven't gone away, by any means. I have considered repackaging
- AT boards (they are really inexpensive, afterall; and convenient for Hams
- who program down to the bare metal), but the amount of sheet metal work
- is beyond my competance.
-
- So! Are a bunch of people willing to get together, pool our knowledge
- and work to design some RFI-proof computational boxes, sort of in the spirit
- of the Amsat folks?
-
-
- Kok Chen kchen@apple.COM, kk6dp
- Apple Computer, Inc.
-
- ------------------------------
-
- Date: 19 Jan 90 16:34:32 GMT
- From: root@sbcs.sunysb.edu (Systems Staff)
- Subject: PK-88 RFI problems
- Message-ID: <4503@sbcs.sunysb.edu>
-
- In article <295@bongo.UUCP> julian@bongo.UUCP (julian macassey) writes:
- >In article <19022@bellcore.bellcore.com>, karn@jupiter..bellcore.com (Phil R. Karn) writes:
- >> In article <3333@cbnewsj.ATT.COM> kfr@cbnewsj.ATT.COM (k.redden,lz,) writes:
- > The FCC requirements are not so bad, it is the enforcement of
- >those requirements that is lacking. I have been to many FCC sites
- >- both U.S. and overseas - and seen "name brand" equipment made to
- >pass FCC part 15 subpart J etc. What passes in no way represents
- >what the consumer buys. When you see a computer with custom
- >shielded cables, large ferrite chokes and caps everywhere pass
- >Part 15, you are watching consumers being duped. Sure the lab
- >will send all the mods to the manufacturer telling him to do them
- >in production gear. But I haven't seen it happen yet.
-
- This is generalization. I've been through FCC testing with equipment
- and it was the case that the class B computer into which my board
- plugged in DID pass B conductive & emissions while doing the required
- "HHHHHH...." patterns, hooked up to the printer, etc. And, no
- I didn't tweak the machine at all. Any responsible volume manufacturer
- in the US almost surely introduces the changes into production
- that were required to pass. Look at it this way: on the off chance
- the mfg is caught, the penalties are already stiff enough to make
- it hurt.
-
- Remember, when listening/presenting stories you've heard second hand,
- that it is entirely possible that a machine can be abused after
- manufacture such that it no longer passes A/B/J, etc. Is it the
- manufacturers responsibility to ensure his equipment is in compliance
- if you've damaged his seals, modified circuitry, replaced an LS TTL
- chip with a noiser AS chip because you didn't have the LS part on
- hand, etc? Is your rig compliant with J when you operate it with
- the covers off? What about when you make software changes to your
- TNC that alter the RFI profile of the unit? Life ain't simple and
- there is more to these problems than casual banter on
- rec.ham-radio.packet is willing to consider.
-
- > The major concern that most manufactures have during testing is
- >how soon you can get the paperwork in so the unit can be on the
- >market. I feel that most compliance departments are a division of
- >sales. I have been shouted at for voicing concern about high crud
- >levels rather than trying to get the paperwork shipped - Fed Ex
- >of course - to the FCC. Yes, once someone tried to bribe me and
- >others. A strange and impermanent way to reduce emissions.
-
- Oh, come on. You've been watching too much Mike Wallace & 60 minutes.
- Anyone I've know who has been through the complaince testing
- has been the engineer who designed the widget in the first place.
-
- > What we need is not tougher specs from the FCC, but tougher
- >enforcement of those specs. The FCC should randomly buy equipment
- >with their label on it an rigorsly test it. If it fails, close
-
- Who would pay to purchase Vax 9000's, Crays, etc. All need to
- be at least class A. I don't want my tax dollar going to such
- folly. What *is* needed perhaps is to require followup testing
- of production units, preferably by a different testing lab than
- did the first units.
-
- >fanatics. By the way, the FDA give manufacturers a hard time
- >about non-complying products. Why don't the FCC?
-
- Maybe it's because a few extra microvolts at 10 mHz will not
- make your hair fall out. Let's make the justice fit the crime.
-
- > But I suppose we can do something too - besides modifying badly
- >designed gear. We can ask ARRL, BYTE mag and others to include
- >Part 15 compliance in their test reports. I bet that will make
- >the fur fly. Also we can complain to manufacturers when their
- >stuff is not up to par. And the last defence of capitalism, don't
- >buy stuff that radiates.
-
- .1% of the only ~300K hams who might buy a particular widget does
- not present a serious problem to the bad guy. RFI performance matters
- only to hams and at most we might account for 300K units (if we
- all have PCs in the shack) of an installed base of some 11-15 million
- PCs. Not enough to get attention. Sure you can assert
- your own political agenda while you are at work, but I know my boss
- probably would be more interested in how many mBytes each machine has
- rather than how many uV/M the machine produces. He would be really
- non-plussed if I decided on RFI performance over some attribute
- needed by the user population. (IE, I guess I will buy 286 PC machines
- with 640x400 monochrome graphics rather than the whizz-bang i860
- machine w/1600x1200x24 bit color because the former is quieter on 20M).
-
- >Julian Macassey, n6are julian@bongo.info.com {ucla-an!denwa!bongo!julian
-
- ------------------------------
-
- Date: 19 Jan 90 15:51:37 GMT
- From: root@sbcs.sunysb.edu (Systems Staff)
- Subject: RFI & radios (was: PK-88 RFI problems)
- Message-ID: <4501@sbcs.sunysb.edu>
-
- In article <4517@aplcen.apl.jhu.edu> mjj@aplvax.UUCP (Marshall Jose) writes:
- >In article <19022@bellcore.bellcore.com> karn@jupiter.bellcore.com
- >because Tempest products are costly; but Tempest in turn is costly because
- >(a) usually it's a VAR technique (added to existing products) and (b) it's
- >what the market will bear.
- >
- >The variety of lossy ferrites and chip bypass capacitors I see at
- >the hamfests lately tells me designers could clean things up if
- >they wanted to. Read that, "If it was economically advantageous
- >for them to do so".
- >Marshall Jose WA3VPZ
-
- 90%/10% - class B has taken us far enough along is the premise of my
- position. Getting the last 10% is going to cost more. And the costs
- are not just simply introducing the average digital engineer to ferrite
- products and copper finger stock. They go more like this:
-
- training of engineers + engineering support personnel (PCB designers,
- packaging people, power supply designers, marketing, etc) in
- RFI control techniques.
- Cost to equip labs to instrument RFI during both development and
- production phases. Ever price out a class A|B test setup?
- Get a current Tek catalog and get surprised :-)
- Time to market costs (already a problem in class B work) when your
- widget didn't pass.
- Extra costs on the enforcement half of the picture.
-
- If you think all of this is going to pass through to the consumer as a
- 5 cent ferrite bead and a couple of bypass caps, think again.
-
- Rick Spanbauer, WB2CFV
- State U of NY/Stony Brook
-
- ------------------------------
-
- End of PACKET-RADIO Digest V90 Issue #16
- ****************************************
- 20-Jan-90 07:22:08-MST,10086;000000000000
- Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
- Date: Sat, 20 Jan 90 07:15:10 MST
- From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
- Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
- Subject: PACKET-RADIO Digest V90 #17
- To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
-
- PACKET-RADIO Digest Sat, 20 Jan 90 Volume 90 : Issue 17
-
- Today's Topics:
- A location is not a route.
- Ham radio names and routing
- Heath u21 KISS code.
- Mailbox source code
- PBBS forwarding via dialup modem?
- PK-88 RFI problems
- Radar-detector detector (2 msgs)
- ----------------------------------------------------------------------
-
- Date: 19 Jan 90 17:20:58 GMT
- From: amdahl!pacbell!tandem!kevinr@ames.arc.nasa.gov (Kevin J. Rowett)
- Subject: A location is not a route.
- Message-ID: <1990Jan19.172058.27916@tandem.com>
-
- In article <120@w2xo.UUCP> durham@w2xo.UUCP (Jim Durham) writes:
- >>
- > What we really need to weigh carefully is that in using the "location"
- >scheme, we are really putting the onus on the user to make up for
- >inadequacies in the network. Is this a case of pragmatism, or is it
- >a case of a quick and dirty fix ? I want to think about this some more!
- >-73
- >Jim, W2XO
-
-
- Jim, you are so right! It works now, and solves a problem that needed
- problem. When network connectivity gets better, we need to realize
- user applications will not all be faster BBS's, nor will the end user
- interface remain something so mundance as a PC :-). We need all the
- thoughts we can get, and we need people looking at AR saying, hey these
- guys are thinking up some really interesting stuff and I'd like to
- play too.
-
- COme one ideas! Don't accept the status quo as the horizon!
-
- N6RCE
-
- ------------------------------
-
- Date: 19 Jan 90 17:14:24 GMT
- From: amdahl!pacbell!tandem!kevinr@ames.arc.nasa.gov (Kevin J. Rowett)
- Subject: Ham radio names and routing
- Message-ID: <1990Jan19.171424.27801@tandem.com>
-
- In article <MT.:P.@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes:
- >In article <1990Jan11.164732.18479@tandem.com> kevinr@tandem (Kevin J. Rowett) writes:
- >I screwed up; I should have said K5ZC@WB5BBW.TX.USA.NA.
- >That said, it's STILL a location, not a route. It says nothing at all
- >except that WB5BBW is in Texas, and nothing at all about how that
- >message is to get to Texas.
- >
- >Yes, WB5BBW is unique.
- >Unfortunately, the only ways to know that WB5BBW is in Texas are 1) have
- >the user, who knows it already, tell the computer about it; 2) store a
-
- These two seem contridictory. Since in one case it was pointed out
- it's a location, then we asked the user to tell us the route. However,
- Phil makes some good practical points, explaining why it came into
- practice.
-
- >If you have religious objections to what you see as source routing, then
- >don't complain - come up with the software that will fix it.
-
- I wish it were that easy. With the current state of (lack of) connectivity,
- 1200 Bd AFSK CSMA, sometimes ALOHA, real time nameservers just cant' easly
- be done.
-
- It really means we neeed to rebuild the stack from the bottom up. Actually,
- we can build it from the bottom and top at the same time, and meet in the
- middle. Example, the top of the stack is BBS's, some of what goes under it
- top to middle pieces are the KA9Q package. For the bottom, see the Dec 89
- Ham Radio magazine, plus other fun stuff we hope to be putting on line
- soon. Lets not forget DSY's either, on the bottom of the stack.
-
- However, as usually happens when several pieces are worked on together,
- they don't always meet at their interfaces. SOurce routing and domain
- naming is one of these crucial areas. That's why I'd like people to
- realize what the names in BBS really are, and why it's only a practical
- solution to a problem that should be abandoned when we achieve much
- better connectivity.
-
- Yes, I worship at the temple of SMOP daily.
-
- N6RCE
-
- ------------------------------
-
- Date: Fri, 19 Jan 90 15:17:04 GMT
- From: pat.davis@mail.admin.wisc.edu
- Subject: Heath u21 KISS code.
- Message-ID: <2173@pgd.adp.wisc.edu>
-
- While I have NOT tried it, I have the TASCO/HEATH u21 KISS rom image-file
- posted on pgd.adp.wisc.edu 128.104.198.22 .
-
-
- I hope the code works... Do tell me if it doesn't.. :-) Pat
-
-
- ------------------------------
-
- Date: 21 Jan 90 08:50:20 GMT
- From: masscomp!ocpt!tsdiag!ka2qhd!w2vy@think.com (Thomas A Moulton)
- Subject: Mailbox source code
- Message-ID: <100@ka2qhd.UUCP>
-
- Brian also gives out source for PRMBS
- Contact him at KA2BQE@N1GMU.VT.USA
- (If I knew where you were I could try to give you the ROUTE, but who cares
- since the systems figure out who to give it to next based to the destination
- locality...)
-
- ------------------------------
-
- Date: 21 Jan 90 08:44:06 GMT
- From: masscomp!ocpt!tsdiag!ka2qhd!w2vy@think.com (Thomas A Moulton)
- Subject: PBBS forwarding via dialup modem?
- Message-ID: <99@ka2qhd.UUCP>
-
- Also the Packet Radio Mail Box System (PRMBS/ROSErver) by Brian KA2BQE
- has complete support for land line modems. It can accept users and mail
- forwarding over the phone, as well as x/y/zmodem upload/downloads.
-
- If there is interest I can post a summary of all it's features.
- 73, tom
- w2vy@kd6th.nj.usa
-
- ------------------------------
-
- Date: 19 Jan 90 19:40:39 GMT
- From: sbcs.sunysb.edu!root@sbcs.sunysb.edu (Systems Staff)
- Subject: PK-88 RFI problems
- Message-ID: <4506@sbcs.sunysb.edu>
-
- In article <1990Jan19.163600.2960@Neon.Stanford.EDU>,
- kaufman@Neon.Stanford.EDU (Marc T. Kaufman) writes:
- > In article <4500@sbcs.sunysb.edu> root@sbcs.sunysb.edu (Systems Staff)
- writes:
- >
- > - ... I have a bunch of machines,
- > - all class B, sitting one room over from our consumer electronics.
- > - No interference. Of course they do inject quite a bit of noise into
- > - the low band and even 2M rigs. But then I am not about to ask my
- > - neighbors to underwrite my hobby through increased cost of electronics
- > - (to control RFI) simply because it is hard to work the high end of 20
- > - when their kids Tai PC clone is going. I tune down a bit and be cool.
- > - I mean, what next? Suggest that all color TV sets be required to
- > - meet Tempest simply because they produce some incidental emissions on
- > - 80?
- >
- > Short sighted, I think. Incidental emissions increase the noise
- floor, so ALL
- > users have to run higher power, which increases interference even more. We
- > may be the first (?) to notice the crud on the band, but it affects all the
- > users, even those who are not specifically aware of it.
-
- A question of economic efficiency, I think. Is it wiser to push
- all receiving gear to current technological limits or to add
- another kW at the transmitter or a slave transmitter closer the
- receiver? There are probably quite a few people
- listening to this debate who I am sure could conjure up more
- efficient means to providing television, FM broadcast, etc at the
- expense of more complicated electronics in the receiver. Who
- would be willing to pay $5K for the resulting TV set though? Of
- course the point which you tradeoff is modulated BOTH by technology
- and general public need (and to some extent environmental needs). We
- tend to fuss just over the technological part of the problems in
- this group, much to the detrement of a more realistic understanding
- of the issues considered.
-
- > After all, the hole in the ozone layer is at the South Pole, how can it
- > possibly affect me, safe here in the Northern Hemisphere?
-
- Assuming this is a comment to car emissions, it isn't so much that
- hole in the ozone layer that affects me as much as the guy sitting
- in front of me at the light who rather desperately needs a ring
- job :-)
-
- > Marc Kaufman (kaufman@Neon.stanford.edu)
-
- Rick Spanbauer
-
- ------------------------------
-
- Date: 19 Jan 90 17:27:11 GMT
- From: amdahl!pacbell!tandem!kevinr@ames.arc.nasa.gov (Kevin J. Rowett)
- Subject: Radar-detector detector
- Message-ID: <1990Jan19.172711.28003@tandem.com>
-
- >Would you post details? Sounds interesting for point-to-point high-speed
- >packet, control links, etc. for next to nothing!
-
- See the Dec '89 Ham Radio magazine.
-
- An interesting piece that didn't make it into the press, is the apparent wideband
- nature of some radar detectors. WHile testing units at the location of N6TTO,
- several cars were observed to suddenly brake quickly and glance out their
- windshields quizzckly. The local sheriff was not previously known to frequent that
- corner.
-
-
- N6RCE
-
- ------------------------------
-
- Date: 20 Jan 90 00:15:12 GMT
- From: pacbell!tandem!kevinr@ames.arc.nasa.gov (Kevin J. Rowett)
- Subject: Radar-detector detector
- Message-ID: <1990Jan20.001512.29924@tandem.com>
-
- In article <59sJ02nA80C801@amdahl.uts.amdahl.com> kelly@amdahl.uts.amdahl.com (Kelly Goen) writes:
- >Amateur gear is specifically exempted from TYPE ACCEPTANCE requirements!!
- > cheers
- > kelly
- >
- >
-
- The FCC does in fact have a set of rules and regs for type acceptance of
- amateur radio service equipment. ALL equipment used in the ARS MUST meet
- it's requirements. Part 97. ARS is NOT exempt from type acceptance.
- Look on the back of your store bought HT. It says that ithas been type
- accepted for use in ARS and complies with Part 97 rules.
-
- However, note a few things about those rules. The requirements are less
- restrictive than for other sections of the FCC R&R; And a Ham can
- build equipment for his own use; offer kits; and give away units of
- not morethan five per year without gaining type acceptance for Part
- 97 rules.
-
- Also note, it's type acceptance, NOT type approval.
-
- It's this very fact that restricts the use of ARS equipment outside
- the ARS!
-
- N6RCE
-
- ------------------------------
-
- End of PACKET-RADIO Digest V90 Issue #17
- ****************************************
- 22-Jan-90 10:21:55-MST,9064;000000000000
- Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
- Date: Mon, 22 Jan 90 10:15:33 MST
- From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
- Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
- Subject: PACKET-RADIO Digest V90 #18
- To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
-
- PACKET-RADIO Digest Mon, 22 Jan 90 Volume 90 : Issue 18
-
- Today's Topics:
- ip/tcp packet radio on a BSD unix machine
- Lan-Link availability
- Microsats
- PACKET-RADIO Digest V90 #15
- PK-88/TAPR DCD MOD
- type acceptance
- Unix & packet
- ----------------------------------------------------------------------
-
- Date: 22 Jan 90 14:34:21 GMT
- From: cs.utexas.edu!mailrus!b-tech!zeeff@tut.cis.ohio-state.edu (Jon Zeeff)
- Subject: ip/tcp packet radio on a BSD unix machine
- Message-ID: <*-*#RR*@b-tech.uucp>
-
- I'd like to run packet radio on my Sun 3/50. I could just run the
- ka9q package, but I'd prefer to have all the existing {rlogin, telnet,
- ftp, etc} work as is. Is there a AX.25 driver for a Sun or a box that
- will talk ethernet or scsi on one end and packet on the other? Can a
- TNC use slip for input and do AX.25 and packet on the output? Am I
- going to be better off using a PC as a gateway?
-
- What would be the cheapest way to connect a Sun 3/50 (no cards, just
- ethernet, scsi, and RS-232 (9600 bps)) to the DSY 56kb modem? I'm not sure
- I care about getting better than 9600 bps performance.
-
- --
- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us or b-tech!zeeff
-
- ------------------------------
-
- Date: 21 Jan 90 14:39:00 GMT
- From: modcomp!dan@uunet.uu.net
- Subject: Lan-Link availability
- Message-ID: <97400002@modcomp>
-
- I've recently seen reference to a new packet program:
- Lan-Link by G3ZCZ. Is it available anywhere on usenet?
-
- uunet!modcomp!dan
-
- ------------------------------
-
- Date: 20 Jan 90 17:14:09 GMT
- From: vsi1!wyse!stevew@ames.arc.nasa.gov (Steve Wilson xttemp dept303)
- Subject: Microsats
- Message-ID: <2584@wyse.wyse.com>
-
- Just a quick note to everyone, the latest issue of "Aviation Week & Space
- Technology" has a picture of the satellite assembly going up on the
- Ariane with the microsats highlighted!!!!!! They mention the sponsoring
- organizations in the blurb but don't explain that these are Amateur Radio
- payloads...So if anyone wants to get a picture of the birds before they
- fly this would be a good source.
-
- 73's de Steve KA6S
-
- ------------------------------
-
- Date: Sun, 21 Jan 90 23:33:52 EST
- From: Roger Smith <ACPS5788%RYERSON.bitnet@ugw.utcs.utoronto.ca>
- Subject: PACKET-RADIO Digest V90 #15
- Message-ID: <90Jan21.233959est.57398@ugw.utcs.utoronto.ca>
-
- Hi,
- Could someone please explain the Mechanism of the Radar-Dector Dector?
- How is it possible to detect a device which is only receiving a signal?
- Are we talking about your typical mount on the dashboard radar detector?
-
- Roger Smith
-
- ------------------------------
-
- Date: Sun, 21 Jan 90 02:10:33 GMT
- From: pat@kd9uu.ampr.org (Pat Davis, KD9UU)
- Subject: PK-88/TAPR DCD MOD
- Message-ID: <323@kd9uu.ampr.org>
-
- DE: doug@w9wi.ampr.org (CQ DX 6!)
-
- INSTALLING THE TAPR DCD STATE MACHINE IN THE PK-88
-
- The AEA PK-88 is not among the TNCs for which detailed
- installation instructions are given in the State Machine pamphlet.
- It isn't that hard to figure out, but maybe these instructions can
- help someone else get theirs working faster.
-
- First, electrical connections. As the TAPR instructions
- detail, the gray wire should connect to pin 26 of the 7910 modem
- chip (IC10); the violet wire connects to pin 25; the brown wire to
- pin 2; and the red wire to pin 22.
-
- The x16/x32 clock is a little harder to find. I located it
- on pin 13 of the 4020 clock divider chip, IC22. This is an x32
- clock, at 38.4KHz. Connect the blue wire here.
-
- I returned the DCD signal from the TAPR board to the CD pins
- of JP4. This involves connecting the green wire to the jumper pin
- closest to the rear of the PK-88 board, and closest to the power
- switch. Don't connect the green wire directly to this point; it'll
- be too short to allow you to put the DCD board inside the case.
- I lengthened the green wire by splicing the black wire (discarded
- from the ribbon cable earlier in the installation) onto the green
- wire. You could also connect this signal to pin 14 of the RS-232
- connector, J1. By returning the TAPR DCD signal at this point, you
- can revert to original PK-88 DCD operation by simply moving the CD
- jumper back to its original position. (especially important to me
- since I wasn't too sure the rest of this installation was going to
- work!)
-
- After making this connection, move the black jumper plug
- nearest the power switch to the other position, so it's towards the
- rear of the PK-88.
-
- Fitting the DCD board inside the PK-88 case isn't easy!
- Before doing anything else, cut off the top 1/8" or so of the pins
- on the JMP jumper on the TAPR board. (make sure you replace the
- jumper plug in the 1-2 position!) I ended up wedging the DCD board
- between the heat sink and the AM7910 chip. To make this work, you
- have to loosen the front screw holding the heat sink in place. Be
- careful (and don't retighten this screw all the way) since you could
- probably crack the PC board.
-
- That should do it. Open your squelch and enjoy!
-
- 73 Doug
-
-
-
-
- ------------------------------
-
- Date: 20 Jan 90 20:40:13 GMT
- From: zaphod.mps.ohio-state.edu!usc!pollux.usc.edu!kjh@tut.cis.ohio-state.edu (Kenneth J. Hendrickson N8DGN)
- Subject: type acceptance
- Message-ID: <22426@usc.edu>
-
- In article <1990Jan20.001512.29924@tandem.com> kevinr@tandem (Kevin J. Rowett) writes:
- >The FCC does in fact have a set of rules and regs for type acceptance of
- >amateur radio service equipment. ALL equipment used in the ARS MUST meet
- >it's requirements. Part 97. ARS is NOT exempt from type acceptance.
- >Look on the back of your store bought HT. It says that ithas been type
- >accepted for use in ARS and complies with Part 97 rules.
-
- My Kenwood TH-x5AT's have no such label on them.
-
- >However, note a few things about those rules. The requirements are less
- >restrictive than for other sections of the FCC R&R; And a Ham can
- >build equipment for his own use; offer kits; and give away units of
- >not morethan five per year without gaining type acceptance for Part
- >97 rules.
-
- I don't think that the manufacturers of equipment to be used only on the
- amateur bands have to go through the rigorous testing procedure required
- for type acceptance. This is because the responsibility to ensure that
- the equipment is operating according to part 97 falls upon the licensed
- amateur radio operator operating the equipment. We are supposed to be a
- little smarter (or at least more educated in radio theory) than other
- users of the spectrum.
-
- >Also note, it's type acceptance, NOT type approval.
- >
- >It's this very fact that restricts the use of ARS equipment outside
- >the ARS!
-
- No, it's not. What prevents us from using ARS equipment outside the
- amateur bands is the LACK of type acceptance (which is required for most
- other services). Remember that we are supposed to have the required
- skills and equipment to ensure that our equipment is operating according
- to the standards set forth in part 97; other spectrum users are not
- assumed to have these skills or this knowledge.
-
- >N6RCE
-
- In the rare case that original ideas Kenneth J. Hendrickson N8DGN
- are found here, I am responsible. 1709 S. Bonnie Brae, LA, CA 90006
- Internet: kjh@usc.edu UUCP: ...!uunet!usc!pollux!kjh
-
- ------------------------------
-
- Date: 21 Jan 90 18:48:12 GMT
- From: pacbell!uop!quack!mrapple@ames.arc.nasa.gov (Nick Sayer)
- Subject: Unix & packet
- Message-ID: <5062@quack.UUCP>
-
- Hi. I have a Sun-2 running SunOS 4.0. I also have a PK-232
- and a 2 meter HT. I would like to set up a PBBS ala W0RLI
- (or whatever). My understanding is that most of these
- systems run on PCs. Is there one that works on BSD 4.[23]
- machines? Since the sun is a multi-user system (of course),
- will the software allow multiple users? Multiple ports (if
- I get more TNCs, of course)?
-
- Any information would be most helpful. Please reply by mail
- and I will post a summary. My appologies if this is the
- same question constantly being asked ad nauseum here.
-
- ---------------------------------------------------------------------
- Nick Sayer | quack!mrapple@uop.edu or cheers!quack!mrapple@apple.com
- ... or { apple!cheers | pacbell!cogent!uop }!quack!mrapple
- Packet radio: N6QQQ @ WB6V | (209) 952-5347 300/1200/2400 - login guest
- Disclaimer: The BBC would like to appologise for that announcement
-
- ------------------------------
-
- End of PACKET-RADIO Digest V90 Issue #18
- ****************************************
- 23-Jan-90 16:19:43-MST,15357;000000000000
- Return-Path: <PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
- Date: Tue, 23 Jan 90 16:15:17 MST
- From: PACKET-RADIO-REQUEST@WSMR-SIMTEL20.ARMY.MIL
- Reply-To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
- Subject: PACKET-RADIO Digest V90 #19
- To: PACKET-RADIO@WSMR-SIMTEL20.ARMY.MIL
-
- PACKET-RADIO Digest Tue, 23 Jan 90 Volume 90 : Issue 19
-
- Today's Topics:
- DOVE Satellite Downlink Sample
- ip/tcp packet radio on a BSD unix machine
- Need HELP with PSK Modem kit
- no more packet-radio mail ...
- Packet radio license without code requirement
- rec.ham-radio.amsat newsgroup.
- vm - view mailer
- ----------------------------------------------------------------------
-
- Date: 23 Jan 90 03:51:43 GMT
- From: masscomp!ocpt!tsdiag!ka2qhd!kd2bd@think.com (John Magliacane)
- Subject: DOVE Satellite Downlink Sample
- Message-ID: <106@ka2qhd.UUCP>
-
- DOVE is a brand new OSCAR satellite that transmits telemetry on 145.825 MHz
- using AX.25 protocol.
-
- I just had a chance to copy some of DOVE's telemetry. During a 14 minute pass,
- I copied 289 packet frames, or about 31 kilobytes of data. Here's just a SAMPLE
- of what I copied, only about 26 hours after launch:
-
-
- DOVE-1>TLM <UI>:
- 00:58 01:59 02:88 03:32 04:58 05:58 06:6D 07:3F 08:6C 09:60 0A:A1
- 0B:DD 0C:E8 0D:D7 0E:00 0F:24 10:CC 11:AE 12:01 13:01 14:B1 15:9D
- 16:96 17:93 18:94 19:94 1A:92 1B:8B 1C:99 1D:97 1E:24 1F:5E 20:BE
-
- DOVE-1>TLM <UI>:
- 21:9B 22:7A 23:24 24:20 25:2D 26:00 27:00 28:00 29:00 2A:00 2B:00
- 2C:00 2D:29 2E:00 2F:9C 30:C8 31:9C 32:B6 33:0F 34:C6 35:A2 36:A8
- 37:9C 38:BC 39:98 3A:00
-
- DOVE-1>STATUS <UI>:
- 00 00 00 88 B0 18 BB 01 00 B0 00 00 B0 00 00 00 00 00 00 00
-
- DOVE-1>WASH <UI>:
- wash addr:3a00:0000, edac=0x7d
- DOVE-1>TIME-1 <UI>:
- PHT: uptime is 039/12:42:46. Time is Tue Jan 23 03:11:40 1990
-
- DOVE-1>TLM <UI>:
- 00:58 01:58 02:88 03:32 04:58 05:58 06:6D 07:3F 08:6B 09:5F 0A:A0
- 0B:DD 0C:E8 0D:D8 0E:01 0F:24 10:CC 11:AE 12:00 13:01 14:B2 15:9D
- 16:99 17:91 18:95 19:94 1A:91 1B:87 1C:9A 1D:98 1E:24 1F:5D 20:BE
-
- DOVE-1>TLM <UI>:
- 21:9B 22:7B 23:22 24:1E 25:2E 26:00 27:00 28:00 29:00 2A:00 2B:01
- 2C:00 2D:2A 2E:00 2F:9C 30:C8 31:9C 32:B6 33:0F 34:C5 35:A2 36:A8
- 37:9C 38:BB 39:98 3A:00
-
- DOVE-1>STATUS <UI>:
- 00 00 00 88 B0 18 BB 01 00 B0 00 00 B0 00 00 00 00 00 00 00
-
- DOVE-1>BCRXMT <UI>:
- vbat= 10.877 vlo1= 10.540 vlo2= 10.040 vmax= 11.540 temp= 6.661
-
-
- Note that all frames are <UI> frames (Unnumbered Information) addressed to
- different "Unproto" designations (they are transmitted as beacons and do not
- require "connection" to receive.
-
- DOVE, a product of the efforts of AMSAT of Brazil (Bramsat), currently
- transmits on 145.825 MHz FM, with packet beacons ON for 2.5 minutes and OFF
- for 30 seconds.
-
- Pretty neat, huh?
-
- 73, de John, KD2BD
-
- --
- AMPR : KD2BD @ NN2Z (Neptune, NJ)
- UUCP : ucbvax!rutgers!petsd!tsdiag!ka2qhd!kd2bd
- "For every problem, there is one solution which is simple,
- neat and wrong." -- H.L. Mencken
-
- ------------------------------
-
- Date: 23 Jan 90 06:10:33 GMT
- From: ka9q.bellcore.com!karn@bellcore.com (Phil Karn)
- Subject: ip/tcp packet radio on a BSD unix machine
- Message-ID: <19280@bellcore.bellcore.com>
-
- For putting a UNIX system on packet, I recommend the setup I use:
- Ethernet from the UNIX system to a dedicated PC/XT clone acting as
- an IP router between the Ethernet and the packet radio modem (56kb/s
- in my case, but it would also work with 1200 baud KISS TNCs).
-
- This technique has a very important advantage, namely avoiding the need to
- make any modifications to the UNIX system. You also get the benefit of
- the PC's CPU in driving the radio interface, offloading that job from
- the UNIX system.
-
- You should make sure that your TCP is reasonably up to date so it will
- perform reasonably well over the (slow) packet channel.
-
- Phil
-
- ------------------------------
-
- Date: 23 Jan 90 21:01:50 GMT
- From: usenet.ins.cwru.edu!cwjcc!ncoast!tbell@tut.cis.ohio-state.edu (Terry Bell)
- Subject: Need HELP with PSK Modem kit
- Message-ID: <1990Jan23.210150.17829@NCoast.ORG>
-
- I am having trouble with the "initial alignment" steps on a RadioKit
- G3RUH PSK Modem kit.
-
- Steps 1 thru 3 all okay.
-
- #4 Adjust VR2 (with VR3 at mid-travel) so that the meter is exactly centered.
-
- "DOWN" led lite. I adjust VR2 clockwise meter goes right to center point.
- "DOWN" led stays lite. Any adjustment to VR3, "DOWN" led stays lite.
-
- "DOWN" led lite. I adjust VR2 counter-clockwise meter goes left, "LOCK"
- led comes on, then finally both led's go out and meter springs to center
- point.
-
- #5 Set VR3 fully clockwise, re-adjusting VR2 if meter moves from center.
- Reset VR3 to mid-position. Neither "UP", "DOWN", nor "LOCK" led's
- should be lit.
-
- Well as I explained above this just isn't happening. Any help would be
- GREATLY!!! appreciated.
-
- Thanks in advance, and hope to see ya on the birds SHORTLY. ( I hope)
- 73, Terry
-
- --
- ******************************************************************************
- Terry Bell FreeNet ab617@po.cwru.edu UUCP: uunet!cwjcc!ncoast!tbell
- N8HSP @WA8BXN.OH.USA.NA AMSAT-NA [44.70.4.10] tbell@n8hsp.ampr.org
- ******************************************************************************
-
- ------------------------------
-
- Date: Tue, 23 Jan 90 09:32:29 CET
- From: HLPHYSIK%DMRHRZ11.BITNET@CUNYVM.CUNY.EDU
- Subject: no more packet-radio mail ...
-
- Date: 23 January 1990, 09:31:32 CET
- From: HLPHYSIK at DMRHRZ11
- To: packet-radio at wsmr-simtel20.army.mil
-
- Please remove us from your mailing list.
- (So long ...)
-
- ------------------------------
-
- Date: 23 Jan 90 18:02:44 GMT
- From: mailrus!b-tech!zeeff@tut.cis.ohio-state.edu (Jon Zeeff)
- Subject: Packet radio license without code requirement
- Message-ID: <K%_#1Q-@b-tech.uucp>
-
- I've heard there may be a packet radio license available without the
- code requirment. Is this something that is likely to happen? When?
-
-
- --
- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us or b-tech!zeeff
-
- ------------------------------
-
- Date: 22 Jan 90 21:15:27 GMT
- From: zephyr.ens.tek.com!tektronix!sequent!brians@beaver.cs.washington.edu (Brian Sheets)
- Subject: rec.ham-radio.amsat newsgroup.
- Message-ID: <28120@sequent.UUCP>
-
- I received a number of people who also would like a new newsgroup
- for amsat/space related articles. Who would do this kinda thing?
-
-
- --
- Brian Sheets KA7KDX _ /| "I'll be back"
- 5544 N Burrage. \`o_O'
- Portland Or. 97217 ( ) Aachk! - Arnold Schwarzenegger,
- 503-526-4091 U Phft! Any movie he's been in.
-
- ------------------------------
-
- Date: Mon, 22 Jan 90 16:16:24 EST
- From: watmath!ria.ccs.uwo.ca!HAMSTER.business.uwo.ca!Mark@uunet.UU.NET
- Subject: vm - view mailer
- Message-ID: <1742@HAMSTER.Business.UWO.CA>
-
- ==============================================================================
-
- I have been working on the full screen mailer for NOS. I invite people to
- download it from HAMSTER.BUSINESS.UWO.CA ftp 129.100.22.100
- I am interested in any problems encountered. I have been making changes
- almost everyday, so check the date code (upper right hand corner of config
- page) to vierify you have a recent version. Below is some intro DOCS
- on how to use View..
- This message was created using VIEW..
- ---------
-
-
- VIEW - A SMTP Mailer for TCP/IP
- January 1990
-
-
- Introduction
-
- View is a mailer designed to work with the networking software from Phil Karn
- (KA9Q). It is a full screen system that allows you to scroll through a message file
- quickly and easily. Mail can be read, or new messages created. You have the choice of
- selecting your own viewer and editor programs. This program creates the files, but it is
- up to the external software to view and/or edit them..
- View was written in Turbo Pascal 5.0. It can operate in color, or non-color modes. The
- configuration page must be filled-in in order for View to operate correctly..
- View was written by Mark Bramwell, VE3PZR, London, Ontario. I can be reached
- during the day at (519) 661-3714, and at home (519) 473-3618. View can be
- downloaded from the internet from HAMSTER.business.uwo.ca [129.100.22.100].
- Hamster supports anonymous FTP logins. Feel free to send any comments regarding
- view to mbramwel@uwo.ca
-
-
- Quick Setup
-
- Copy VIEW.EXE to your computer. Make sure that you have a PATH command in
- your AUTOEXEC.BAT so that DOS can find VIEW.EXE
-
- If you have been using BM.EXE for mail, then the setup is simple..
- If you have not been using BM.EXE, then some directories are needed..Type in the following commands:
-
- C> MD \SPOOL
- C> MD \SPOOL\MAIL
- C> MD \SPOOL\MQUEUE
-
- You are now ready to start View..
- C> VIEW
-
- Test Drive of View
-
- When enter View for the first time, you will have to configure it for your system. Select
- the f5 function key to enter the configuration page. Most items should be filled. Here
- is an example of some of my responses:
-
-
-
- Userid: Mark
- Hostname: HAMSTER.business.uwo.ca
- Realname: Mark Bramwell
-
- Reply-To: mbramwel@uwo.ca
-
- editor: \util\qe.exe
- viewer: \util\list.com
-
- Comments:
- Signature: \spool\signatur.txt
-
- directory: \spool\mail
- Color: Y Timezone: EST Printer: LPT1
-
-
-
- Remember to hit enter with each entry. When you have filled in the configuration page,
- hit ESC to save it. View will resave the configuration each time you exit the config
- screen.
-
- If you had mail, then some messages will appear on the screen. If no mail is waiting,
- then a short message will appear on the screen..
- To read a message, use the arrows keys on the keyboard to move the high-lite bar.
- When the desired message is hi-lited, hit ENTER to read the message..
- Special Keys
-
- Certain keys have functions assigned to them. For example, you can move the hi-lited
- bar by using the following keys: Arrow up, Arrow down, Home, End, PgUp, PgDn.
- You can mark messages for deletion with the DEL key.
-
- ALT-D allows you to jump to DOS without exiting view. When you type EXIT
- at the dos prompt, you will be returned to VIEW at the same point that you left. This
- is usefull when you are reading large files and it takes a long time for view to read-it-in.
-
- ALT-F is the full display key. It opens a window at the bottom of the screen that will
- display the full hostname and subject of the current message. It can be toggled on and
- off and the mode is save in the configuration..
- ALT-P will print the hi-lited message on your printer. Check config page to ensure that
- you have the printer defined..
- ALT-S will allow you to save the current message to a file. View will ask for a filename.
- The message will be read and stored in that file. This will erase the file if it already
- exists. View does not append to the file..
- ALT-U is the update key, and forces view to immediately update the file by removing
- marked messages. View automatically updates the file whenever you have finished
- reading the file and have selected another file..
- ALT-X is the same as f3. This simply exits view completely..
- ALT-Z reads the current mail file and checks for EOF markers. I have found that our
- IBM 4381 sticks control-z characters in mail files. This causes view mailer to think it is
- at the end of file even though there are more messages waiting. All messages after
- control-z characters are lost. I would make this routine run all the time except for the
- fact that it slows down the initial mail file reading. Packet radio mail, and mail directly
- from the internet does not seem to have this problem..Using VIEW
-
- f1: Help. This displays a simple help screen for those who can't remember
- some of the special keys..
- f2: Send Msg. This will allow you to create and send your own messages.
- You must enter something when View asks for 'To:'. If you just hit enter,
- then the creation of the message is aborted and you are returned back to
- the normal screen. It is not neccessary for you to enter anything in
- response to 'subject:'.
-
- You must have previously configured View in order for it to find your
- editor program..
- f3: Quit. This exits Views, updates any messages that were deleted, and
- returns you to DOS..
- f4: Read Msg. This will read the hi-lited message. You can also press
- ENTER for the same effect..
- f5: Configure. Allows you to specify various items about your machine. This
- screen must be filled-in, else some of the functions won't work properly.
- All info is stored in the \SPOOL\MAILER.CFG config file..
- f6: Split Digests / Read as mail. This interesting function has the ability to
- read mail as normal messages, or try to split a long message into its'
- smaller parts. I use this when I receive the info-hams digest. This takes
- the 400 line message, and breaks it up into all the smaller messages. It
- displays each host and subject separately. This allows me to read only
- those messages that I am interested in, and ignore the rest. This function
- can be toggled on/off and is stored in the MAILER.CFG file..
- f7: Select file. This allows you to specify another .TXT file as your workfile.
- For example: I have all info-hams mail come into my machine under the
- userid HAMRADIO. All packet mail comes in for the userid PACKET.
- This creates 3 files on my machine HAMRADIO.TXT, PACKET.TXT,
- and MARK.TXT. Using select, I can choose which information I am
- interested in reading at this time. Any marked messages are deleted
- before the new file is read..
- f8: Credits. Who am I, and where can I be reached. Also note the date code
- in the upper right hand corner of the screen. This will allow you to know
- which version of the software you are running..
- f9: Forward a Message. This will read the current message and allow you to
- forward it to someone else. I use this to send a copy of interesting mail to
- my home machine.
-
- f10: Reply-to. This will create a message using the hostname, subject, and text
- of the hi-lited message. It allows you to reply to a message that you are
- reading..
-
-
-
- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
- Mark Bramwell, VE3PZR Located in sunny London, Ontario
-
- Internet: mark@hamster.business.uwo.ca IP Address: 129.100.22.100
- Packet: VE3PZR @ VE3GYQ UWO Phone: (519) 661-3714
-
-
- ------------------------------
-
- Date: Tue, 23 Jan 90 10:41:32 CET
- From: HLPHYSIK%DMRHRZ11.BITNET@CUNYVM.CUNY.EDU
-
- Date: 23 January 1990, 10:40:33 CET
- From: HLPHYSIK at DMRHRZ11
- To: packet-radio at wsmr-simtel20.army.mil
-
- UNSUBSCRIBE
-
- ------------------------------
-
- End of PACKET-RADIO Digest V90 Issue #19
- ****************************************
-