World of Ham Radio 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ World of Ham Radio 1994 January / AMSOFT_1994.iso / packet / docs / pd199005.doc < prev next >

Wrap

Text File | 1993-12-31 | 653.0 KB | 11,003 lines

Wed, 2 May 90 04:00:04 PDTFrom: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #15To: packet-radioPacket-Radio Digest Wed, 2 May 90 Volume 90 : Issue 15Today's Topics: DOVE TELEMETRY DATA.... here is how. Failed Mail (8 msgs) faster modems Full Duplex packet on 2 meters? (3 msgs) Higher speeds New Packet Stuff @ Dayton?? Packet-Radio Digest V1 #14Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 1 May 90 15:38:48 GMTFrom: swrinde!zaphod.mps.ohio-state.edu!sunybcs!uhura.cc.rochester.edu! rochester!kodak!ektools!kinsman@ucsd.edu (Andrew A. Kinsman)Subject: DOVE TELEMETRY DATA.... here is how.To: packet-radio@ucsd.eduSpacecraft: DOVE-1: Rev: 1 Date: 1/7/90 Equations are in the form: Y = A*N^2 + B*N + C where: N = Telemetry Count (00 - FF) A, B, C = Equation Coefficients Y = Result (In Specified Units)HEX Descripion: C: B: A: Units: cccccccccc bbbbbbbbbb aaaaaaaaaa uuuuuu 0 Rx E/F Audio(W)+0.000 +0.0246 0.000 V(p-p) 1 Rx E/F Audio(N)+0.000 +0.0246 0.000 V(p-p) 2 Mixer Bias V: +0.000 +0.0102 0.000 Volts 3 Osc. Bisd V: +0.000 +0.0102 0.000 Volts 4 Rx A Audio (W):+0.000 +0.0246 0.000 V(p-p) 5 Rx A Audio (N):+0.000 +0.0246 0.000 V(p-p) 6 Rx A DISC: +10.427 -0.09274 0.000 kHz 7 Rx A S meter: +0.000 +1.000 0.000 Counts 8 Rx E/F DISC: +9.6234 -0.09911 0.000 kHz 9 Rx E/F S meter:+0.000 +1.000 0.000 Counts A +5 Volt Bus: +0.000 +0.0305 0.000 Volts B +5V Rx Current:+0.000 +0.000100 0.000 Amps C +2.5V VREF: +0.000 +0.0108 0.000 Volts D 8.5V BUS: +0.000 +0.0391 0.000 Volts E IR Detector: +0.000 +1.000 0.000 Counts F LO Monitor I: +0.000 +0.000037 0.000 Amps10 +10V Bus: +0.000 +0.05075 0.000 Volts11 GASFET Bias I: +0.000 +0.000026 0.000 Amps12 Ground REF: +0.000 +0.0100 0.000 Volts13 +Z Array V: +0.000 +0.1023 0.000 Volts14 Rx Temp: +101.05 -0.6051 0.000 Deg. C15 +X (RX) temp: +101.05 -0.6051 0.000 Deg. C16 Bat 1 V: +1.7932 -0.0034084 0.000 Volts17 Bat 2 V: +1.7978 -0.0035316 0.000 Volts18 Bat 3 V: +1.8046 -0.0035723 0.000 Volts19 Bat 4 V: +1.7782 -0.0034590 0.000 Volts1A Bat 5 V: +1.8410 -0.0038355 0.000 Volts1B Bat 6 V: +1.8381 -0.0038450 0.000 Volts1C Bat 7 V: +1.8568 -0.0037757 0.000 Volts1D Bat 8 V: +1.7868 -0.0034068 0.000 Volts1E Array V: +7.205 +0.07200 0.000 Volts1F +5V Bus: +1.932 +0.0312 0.000 Volts20 +8.5V Bus: +5.265 +0.0173 0.000 Volts21 +10V Bus: +7.469 +0.021765 0.000 Volts22 BCR Set Point: -8.762 +1.1590 0.000 Counts23 BCR Load Cur: -0.0871 +0.00698 0.000 Amps24 +8.5V Bus Cur: -0.00920 +0.001899 0.000 Amps25 +5V Bus Cur: +0.00502 +0.00431 0.000 Amps26 -X Array Cur: -0.01075 +0.00215 0.000 Amps27 +X Array Cur: -0.01349 +0.00270 0.000 Amps28 -Y Array Cur: -0.01196 +0.00239 0.000 Amps29 +Y Array Cur: -0.01141 +0.00228 0.000 Amps2A -Z Array Cur: -0.01653 +0.00245 0.000 Amps2B +Z Array Cur: -0.01137 +0.00228 0.000 Amps2C Ext Power Cur: -0.02000 +0.00250 0.000 Amps2D BCR Input Cur: +0.06122 +0.00317 0.000 Amps2E BCR Output Cur:-0.01724 +0.00345 0.000 Amps2F Bat 1 Temp: +101.05 -0.6051 0.000 Deg. C30 Bat 2 Temp: +101.05 -0.6051 0.000 Deg. C31 Baseplt Temp: +101.05 -0.6051 0.000 Deg. C32 FM TX#1 RF OUT:+0.0256 -0.000884 +0.0000836 Watts33 FM TX#2 RF OUT:-0.0027 +0.001257 +0.0000730 Watts34 PSK TX HPA Temp+101.05 -0.6051 0.000 Deg. C35 +Y Array Temp: +101.05 -0.6051 0.000 Deg. C36 RC PSK HPA Temp+101.05 -0.6051 0.000 Deg. C37 RC PSK BP Temp:+101.05 -0.6051 0.000 Deg. C38 +Z Array Temp: +101.05 -0.6051 0.000 Deg. C 39 S band TX Out: -0.0451 +0.00403 0.000 Watts3A S band HPA Temp+101.05 -0.6051 0.000 Deg. CADC Equations: V = 0.01028 N - 0.05138 N = 97.31 V +5.000------------------------------Date: Tue May 01 12:04:23 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Mon Apr 23 21:18:56 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 12:03:53 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa05949; 23 Apr 90 21:16 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id fb09731; 23 Apr 90 19:29 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id ae16278; 23 Apr 90 19:34 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa16248; 23 Apr 90 19:26 BST> Received: by ucsd.edu; id AA10927> sendmail 5.61/UCSD-2.0-sun> Sat, 21 Apr 90 04:00:07 -0700 for brian> Received: by ucsd.edu; id AA10914> sendmail 5.61/UCSD-2.0-sun> Sat, 21 Apr 90 04:00:05 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004211100.AA10914@ucsd.edu>> Date: Sat, 21 Apr 90 04:00:02 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #3> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Sat, 21 Apr 90 Volume 90 : Issue 3> > Today's Topics:> Fixmail 1.09 now posted :128.104.198.22> Innovators need thick skin (was: CP/M sofware...)> KISS Mode -- How Fast? (2 msgs)> Microwave oscillator sources (3 msgs)> USENET at Dayton Hamvention> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: Fri, 20 Apr 90 08:09:59 GMT> From: pat@pgd.adp.wisc.edu (Pat Davis)> Subject: Fixmail 1.09 now posted :128.104.198.22> To: packet-radio@ucsd.edu, tcp-group@ucsd.edu> > Fixmail 1.09 is posted on pgd.adp.wisc.edu for anonymous FTP.> 1.09 fixes a bug that would allow FIXMAIL to END/TERMINATE if/when there> was no more mail to censor.. That's right, censor.. Fixmail,> by Bryan HI-Q Biggers N9GBJ, manages SMTP mail from NET/NOS. It has some> very attractive features. FIXMAIL is Desqview "aware"..> > The file you want is FIXM109.ZIP, you might find more helpful files in> FIXM106.ZIP too...> > KD9UU> > ------------------------------> > Date: 20 Apr 90 16:18:00 GMT> From: att!cbnewsh!n2dsy@ucbvax.Berkeley.EDU (j.gordon.beattie)> Subject: Innovators need thick skin (was: CP/M sofware...)> To: packet-radio@ucsd.edu> > > First and foremost, plain old AX.25 text streams will be with us for> > a long, long time. Its the lowest common denominator for just about all of > > amateur packet radio. It is also the simplest packet "mode" to understand:> > just "CONNECT" and off you go. Given these two facts, I claim that plain> > old AX.25 text streams are and will continue to be the most popular "mode".> > I can agree with this point that the simple "CONNECT and go" user (POATS user)> is, and will be the major user type in the packet network for a long time > to come.> > I would just like to point out that the ROSE X.25 Switch software > supports "POATS" users simply by appearing to the user as a pair> of digipeaters. There's no extra user hardware or software to > buy/install/configure/hassle-with to use a ROSE X.25 network. > > In fact, the ROSE X.25 Switch will route you through the network without> the hassle that the NoNodes put you through of "connect, connect,> connect..connect, voila..the destination!" This is somewhat akin> to asking a sequence of "n" telephone operators to route your > telephone call...computers do a better job of this in less time!> > As far as interoperability goes, you can call between a NoNodes> network and a ROSE X.25 network by simply connecting using the> standard connection method for either network (C Destination v ...).> > TCP/IP is no problem to a ROSE X.25 network either: just make > a level 2 call through a ROSE X.25 network (like any POATS user)> and send your IP datagrammes through the network...simple!> > In any case, I'd like to see more integration of networks, but> let's first realize that simplicity of a tool (or a network)> can often be the most attractive feature to users.> > 73,> Gordon Beattie, n2dsy> n2dsy@hou2d.att.com> +1.201.615.4168> > ------------------------------> > Date: 20 Apr 90 01:16:22 GMT> From: bionet!hayes!usenet@apple.com> Subject: KISS Mode -- How Fast?> To: packet-radio@ucsd.edu> > I have one of the April 90 versions of NOS running on two different> PC compatibles. I can't seem to communicate reliably faster than 4800> baud. One machine is a 12 MHZ 286 with an 8250B. The other machine is a> laptop with a 4.77 MHz 80C88 and I presume the ASIC equivalent of an 8250.> Hardwired connection between the two machines with KISS mode at 4800 baud> seems reliable but 9600 baud is very spotty.> > Now the interesting thing is that the 286 machine is known to operate> to at least 38400 with an unsophisticated interrupt routine written in Turbo> Pascal. The laptop operates well at 9600 baud with various terminal emulators.> Why is NOS slower and what can I do about it? The 8250B in the 286 machine> is socketed but there is little I can do with the laptop, which is probably> the culprit. Mostly I want to know how fast can I run KISS mode on the 286> machine.> > The reason I bring this up is that I am working on a 2 chip packet> assembler/disassembler that is good to 1 Mbps (half-duplex) but I need a> decently fast way to interface it to the host computer. 4800 baud isn't> good enough.> > Philip Munts N7AHL> University of Alaska, Fairbanks> > ------------------------------> > Date: 21 Apr 90 05:47:43 GMT> From: ka9q.bellcore.com!karn@bellcore.com (Phil Karn)> Subject: KISS Mode -- How Fast?> To: packet-radio@ucsd.edu> > In article <1990Apr20.022915.8287@hayes.fai.alaska.edu> ftpam1@acad3.fai.alaska.edu writes:> > > I have one of the April 90 versions of NOS running on two different> >PC compatibles. I can't seem to communicate reliably faster than 4800> >baud.> > Fetch the latest stuff off flash.bellcore.com using anonymous ftp and> give it a try. If it isn't any better, let me know. I've been doing some> work on the 8250/16550 driver lately that should help improve performance> and I want to make sure that I haven't already fixed your problem before> looking at it again.> > Phil> > ------------------------------> > Date: 20 Apr 90 14:04:33 GMT> From: rochester!rit!cci632!dvh@rutgers.edu (David Hallidy)> Subject: Microwave oscillator sources> To: packet-radio@ucsd.edu> > In article <871@tsdiag.ccur.com>, davet@tsdiag.ccur.com (Dave Tiller N2KAU) writes:> > > > Has anyone had any experience with converting a microwave oven > > magnetron to Amateur use? Are there any problems with needing to> > 'bend' it down slightly from 2.450 GHz to make it into the Ham> > band? What are the power requirements? I noticed that MCM sells> > replacement magnetrons - could this be a source for cheep packet> > backbone oscillators? Inquiring minds gots'ta know...Any help> > would be greatly appreciated.> > > > PS - I don't intend to run one of these at ~600-1200 Watts aimed> > at the general public. A couple of Watts (<10) would be more> > resonable.> > Dave-> > Check out _RF DESIGN_ for March of 1989, there was an article about> using a microwave oven as a high powered RF source for 2450 MHz> ATV. It will work down into the ham band at the upper end of the> "13cm" segment- from 2390 to 2450 MHz. Problem is, I don't think> the stability of the mag will be very good- this may not be critical> in your application, certainly for wideband TV experimenting it's> probably not too important.> > The other problem is, you mentioned wanting to run low power- I> don't think you can with this type of setup. A magnetron, by its> nature, generates high levels of RF. It's a self excited device, and> if you try to just "lower the voltage" or reduce the intensity of> the magnetic field around the tube, it just won't oscillate. The way> the microwave ovens run at "reduced" power is to turn the tube on> and off for varying periods of time- this has the effect, on food,> of reducing the heating by reducing the amount of time the food is> exposed to the RF. The level of RF when the mag is running is always> at full power (>600 Watts, usually).> > I do think it might be worthwhile to experiment with injection-locking> of the magnetron to stabilize its output frequency. This would make> for a very cheap source of extremely high power on the band, useable> for modes other than wideband TV. Let me know if you try any of this> and any success (or failure) you may have.> > Hope this helps you some.> > 73 Dave H. KD5RO/2> > ------------------------------> > Date: 20 Apr 90 20:01:56 GMT> From: swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!t urnkey!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.c om!dana@ucsd.edu (Dana H. Myers)> Subject: Microwave oscillator sources> To: packet-radio@ucsd.edu> > In article <871@tsdiag.ccur.com> davet@tsdiag.ccur.com (Dave Tiller N2KAU) writes:> >> >Has anyone had any experience with converting a microwave oven > >magnetron to Amateur use? Are there any problems with needing to> >'bend' it down slightly from 2.450 GHz to make it into the Ham> >band? What are the power requirements? I noticed that MCM sells> >replacement magnetrons - could this be a source for cheep packet> >backbone oscillators? Inquiring minds gots'ta know...Any help> >would be greatly appreciated.> > Look in the 1989 index for 73 magazine - a cover article detailed> conversion of a surplus oven to ATV/FM use, a $200 700W exciter !> I'll try to get the date or possibly someone else can post it.> > > ***************************************************************** > * Dana H. Myers WA6ZGB | Views expressed here are *> * (213) 337-5136 | mine and do not necessarily *> * dana@locus.com | reflect those of my employer *> ***************************************************************** > > ------------------------------> > Date: 21 Apr 90 02:15:45 GMT> From: usc!pollux.usc.edu!kjh@ucsd.edu (Kenneth J. Hendrickson)> Subject: Microwave oscillator sources> To: packet-radio@ucsd.edu> > In article <871@tsdiag.ccur.com> davet@tsdiag.ccur.com (Dave Tiller N2KAU) writes:> >Has anyone had any experience with converting a microwave oven > >magnetron to Amateur use?> > It's already been done. Somebody in Illinois did it on ATV. There was> a skimpy write-up about it in one of the RF trade rags about Fall of> '88. I can't remember which magazine, but I think it might have been> "RF & Microwaves". Don't waste your time looking for the magazine,> however, there wasn't any more information in it than I have posted> here. It was kind of like the ARRL's current publication of microwave> information in QST.> > Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh> > ------------------------------> > Date: 20 Apr 90 02:34:52 GMT> From: usc!cs.utexas.edu!execu!sequoia!attdso!ssc!tad@ucsd.edu (Tad Cook)> Subject: USENET at Dayton Hamvention> To: packet-radio@ucsd.edu> > Just ONE more reminder. . . .If you are going to the Dayton Hamvention,> USENET folks will be getting together at Stouffers on Friday night in> suite 425, at the DIGITAL SUITE. Stouffers is downtown at Fifth and> Jefferson.> > See you there!> > > Tad Cook> Seattle, WA> Packet: KT7H @ N7HFZ.WA.USA.NA> Phone: 206/527-4089 > MCI Mail: 3288544 > Telex: 6503288544 MCI UW > USENET:...uw-beaver!sumax!amc-gw!ssc!tad> or, tad@ssc.UUCP> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 12:08:24 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Mon Apr 23 23:52:08 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 12:07:58 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa12342; 23 Apr 90 23:50 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id rp09731; 23 Apr 90 22:11 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id ab18786; 23 Apr 90 20:36 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa18731; 23 Apr 90 20:32 BST> Received: by ucsd.edu; id AA14795> sendmail 5.61/UCSD-2.0-sun> Mon, 23 Apr 90 04:00:07 -0700 for brian> Received: by ucsd.edu; id AA14783> sendmail 5.61/UCSD-2.0-sun> Mon, 23 Apr 90 04:00:04 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004231100.AA14783@ucsd.edu>> Date: Mon, 23 Apr 90 04:00:02 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #5> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Mon, 23 Apr 90 Volume 90 : Issue 5> > Today's Topics:> Has NOS been ported to the Atari ST?> TAPR TNC-2 for sale> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 23 Apr 90 01:34:39 GMT> From: swrinde!zaphod.mps.ohio-state.edu!samsung!umich!pmsmam!pmsmam.uuc p!wwm@ucsd.edu (Bill Meahan)> Subject: Has NOS been ported to the Atari ST?> To: packet-radio@ucsd.edu> > The subject line says it all.> > If not, why not? Micro-RTX could easily provide the requisite multi-tasking> kernel if the one that's included in the NOS source isn't suitable.> > We ST users wait with bated breath! (especially we who still have older> 520's :-) :-} )> -- > Bill Meahan | UUCP: uunet!mailrus!umich!pmsmam!wwm> | snail: 128 Factory St., Ypsilanti, MI 48197> #include <disclaimer.std> | voice: +1 313 484 9320> /* witty */ |packet: wa8tzg @ wa8ooh.mi.usa.na> > ------------------------------> > Date: 22 Apr 90 06:54:54 GMT> From: sumax!ole!ray@beaver.cs.washington.edu (Ray Berry)> Subject: TAPR TNC-2 for sale> To: packet-radio@ucsd.edu> > I have a TAPR TNC-2 built from a kit several yrs back I'd like to> sell. It was built and tested, aligned, etc., but never used. The firmware> is at whatever level existed at the time the TNC-2 first shipped. > I'd like $100 for this thing. I've never been active in packet,> so I don't know if this thing is already obsolete or what... if the price > sounds too high, please make an offer. Thanks.> -- > Ray Berry kb7ht uucp: ...ole!ray CIS: 73407,3152 /* "inquire within" */> Seattle Silicon Corp. 3075 112th Ave NE. Bellevue WA 98004 (206) 828-4422> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 12:15:30 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Tue Apr 24 06:54:29 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 12:15:03 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa00189; 24 Apr 90 6:50 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id fm22320; 24 Apr 90 4:59 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id ax28088; 24 Apr 90 3:19 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa27762; 24 Apr 90 2:13 BST> Received: by ucsd.edu; id AA26011> sendmail 5.61/UCSD-2.0-sun> Sun, 22 Apr 90 04:00:08 -0700 for brian> Received: by ucsd.edu; id AA25993> sendmail 5.61/UCSD-2.0-sun> Sun, 22 Apr 90 04:00:04 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004221100.AA25993@ucsd.edu>> Date: Sun, 22 Apr 90 04:00:02 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #4> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Sun, 22 Apr 90 Volume 90 : Issue 4> > Today's Topics:> Innovators need thick skin> Microwave oscillator sources> Packet-Radio Digest V1 #3> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 21 Apr 90 22:42:34 GMT> From: sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!k d4nc!ke4zv@ucsd.edu (Gary Coffman)> Subject: Innovators need thick skin> To: packet-radio@ucsd.edu> > In article <22370@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes:> >> >But be that as it may, you are getting somewhat closer to the truth. As> >I said before, TCP/IP has little to offer unless you have a computer.> > WORDS TO LIVE BY! I would also add that packet in general has little to> offer unless you have a computer. Contentless keyboard QSOs crawling> through the network have little value after the thrill of doing it once> wears off.> The real value of packet radio is connecting computers together in a> network to perform a useful function. Things like Email, Remote File> Sharing, and distributed computing are possible only with reliable> end to end data transfer. Our current slow network already carries> an important amount of Email. MUCH faster networks will make the other > things realistic. And there's the rub, little Terminal Node Controllers> aren't capable of supporting faster modems. In fact, TERMINAL Node> Controller is a concept whose time is past. It's time to return to> the PAD (Packet Assembler Disassembler) now that it is a single chip> (8530) in the computer and attach that to a truly high speed modem.> High speed modems are available and affordable NOW at 56kb and soon> at megabit rates. > > LET'S NOT FALL INTO THE TRAP OF HITCHING OURSELVES TO THE DEAD PAST> WITH A NETWORK DESIGN THAT CANNOT EASILY MIGRATE TOWARD OUR ULTIMATE> GOALS.> > Gary KE4ZV> > ------------------------------> > Date: 20 Apr 90 00:27:03 GMT> From: snorkelwacker!bu.edu!mirror!otto!jimi!unsvax!storkus@think.com (Mike Storke (N7MSD))> Subject: Microwave oscillator sources> To: packet-radio@ucsd.edu> > I'd also be very interested in knowing if you can convert a microwave oven> magnetron to amateur bands. Unlike the guy who originated this, I *WOULD* use> it at or near it's full rated power. This would be used for long-haul packet> links (~200+ miles, to be exact: Las Vegas-Bishop, California-Reno; a 2M link> currently exists along this route, but it's too loaded down). Any info would> be appreciated. Note that these links are all on top of mountains > 8500 ft.> high. Thanks and 73's, Mike, N7MSD> P.S. I got a hold of a surplus house that has traveling wave tubes for 2-4 gigs> and 8-9.6 gigs. Can the 8-9.6 be used at the 10 gig ham band? A friend of> mine said no because they are *very hard* to tune-he says they're something> like a helical antenna at their center frequency. Any info appreciated as> always, Mike> > ------------------------------> > Date: Sat, 21 Apr 90 22:31 EST> From: LARRY KNEHR <CSCON104@uoft02.utoledo.edu>> Subject: Packet-Radio Digest V1 #3> To: Packet-Radio@UCSD.EDU> > > > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 12:36:08 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Tue Apr 24 15:44:27 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 12:35:53 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa02220; 24 Apr 90 14:55 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id al06530; 24 Apr 90 11:49 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id ab11817; 24 Apr 90 13:04 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa11692; 24 Apr 90 13:00 BST> Received: by ucsd.edu; id AA20953> sendmail 5.61/UCSD-2.0-sun> Tue, 24 Apr 90 04:00:13 -0700 for brian> Received: by ucsd.edu; id AA20939> sendmail 5.61/UCSD-2.0-sun> Tue, 24 Apr 90 04:00:10 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004241100.AA20939@ucsd.edu>> Date: Tue, 24 Apr 90 04:00:06 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #6> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Tue, 24 Apr 90 Volume 90 : Issue 6> > Today's Topics:> Apple II Software for RTTY and Facsimile ?> faster modems> Getting Started!?> MFJ 1274 TNC for sale> pulse on X-band (2 msgs)> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 23 Apr 90 15:29:50 GMT> From: ncs.dnd.ca!asterix.drev.dnd.ca!louis@rutgers.edu (Louis Demers)> Subject: Apple II Software for RTTY and Facsimile ?> To: packet-radio@ucsd.edu> > (I am posting this for a collegue, hope this is the right place)> > A friend is looking for software for his Apple II+ to receive> Facsimile (he already has the interface to his radio) for example> of wheather maps. He would like also a piece of software that > implements the RTTY protocol.> > If software is unavailable, we would settle for the algorytms.> > Please respond through Email as this site doesn't receive any of the> rec. groups.> > PPS: Please don't laugh, this is all foreign to me.> -- > | Louis Demers | DREV, Defence Research Establishment,Valcartier |> | louis@asterix.drev.dnd.ca | POBox 8800, Courcelette,Quebec, CANADA, G0A 1R0 |> | (131.132.48.2) | Office: (418) 844-4424 fax (418) 844-4511 |> +---------------------------+------------------------------------ -------------+> > ------------------------------> > Date: Mon, 23 Apr 90 14:34:34 MST> From: sarrel%miranda.uucp@moc.Jpl.Nasa.Gov (Marc Sarrel)> Subject: faster modems> To: packet-radio@ucsd.edu> > Well, there has been some discussion recently here about how most hams> with TNCs are using horribly outdated and slow equipment. 1200 baud> seems to be the lowest common denominator. And, sometimes I get the> feeling that some hams don't have much desire or incentive to move to> higher baud rates. In fact, I spent a while talking to the "packet> expert" at a local amateur radio store recently. I asked him about> some TNC that had a 2400 baud modem vs one that had a 1200 baud modem.> I asked wether 2400 would catch on, given my experience with land line> modems where everyone was starved for speed. He said "no." His> reasons seemed pretty fuzzy to me, but he seemed to claim that 1) 2400> baud wouldn't catch on because everyone already has 1200 baud modems,> 2) 1200 baud seemed fast enough to him, and 3) that 2400 baud wasn't> _really_ twice as fast as 1200 because the extra speed was used> inefficiently. (But don't hold me to that, this was a while ago.)> > Anyway, my question is this: How can we "hams in the know" encourage> the use of faster and more effecient modems on the airwaves, given> that we agree that "faster is better." One of this guy's arguments> holds weight in that there is a lot of "hardware inertia" out there.> > Specifically what kind of faster and more efficient modems are> available and suitable for packet-radio? How fast is fast? 9600?> 19.2K? 56K? How much extra bandwidth do these faster modems require?> What about FCC regulations on speed?> > Is there such a thing as auto baud rate recognition that would allow a> digipeater to work a several different speeds with different stations> on the same frequency? This would allow a smoother transition to> faster modems by giving people incentive to buy them without> immediately obsoleting everyone's 1200 baud equipment?> > Would it be a good idea to set up digipeaters that work on several> different speeds (and frequencies) as a way of encouraging higher baud> rates?> > Just curious,> > --marc> -=-> Marc A. Sarrel> N7OLI> sarrel%miranda.uucp@moc.jpl.nasa.gov | "Oh, _lightweight_ Alpaca..."> ..!sun!sunburn!miranda!sarrel | -Blanche DuBois> > ------------------------------> > Date: 23 Apr 90 08:32:11 GMT> From: usc!sdsu!crash!jburnes@ucsd.edu (Jim Burnes)> Subject: Getting Started!?> To: packet-radio@ucsd.edu> > Hi!> > A friend of mine and I want to get into packet radio. We are not hams.> We are willing to jump through the necessary hoops. We both are software/> hardware engineers and understand various amounts of circuit theory.> We would like to know:> > 1. What is the highest speed modem usable on standard packet frequen-> cies? I have heard of 9600 bps modems being used. What about> Telebit Trailblazer spread-spectrum type modems?> > 2. What class of ham liscense is necessary to run packet? What tests> and theory must we have to get this liscense?> > 3. How much would a rig capable of 2400 bps operation cost (used)?> I already have a 386 machine. I would like to upgrade to national/> international coverage (if that is applicable) and also to higher> speeds.> > 4. I have heard that you cant upload messages/files to someones node> and then have that information automatically forwarded through> a network. Someone told me humans had to intervene. That sounded> silly. Kinda defeats the whole purpose of a network, no? Sorry..> since I'm mostly a pc hacker I not quite sure how to ask a lot of> questions without sounding naive.> > 5. What is a good book to get started with?> > 6. It seems like I have been trying to get into packet/ham for the last> 5 years or so and always fail to clear the morse/test hurdles. I'd> like to remedy this as soon as possible. Any ideas for making the > transition easier?> > Yours in communications,> Jim Burnes> > -------------------> I do not beleive in 'isms> I think, on the whole, 'isms are a bad thing> > Ferris Buehler (paraphrased)> --------------------> > ------------------------------> > Date: 24 Apr 90 00:53:37 GMT> From: psuvm!mls129@psuvax1.cs.psu.edu (Michael L. Sensor)> Subject: MFJ 1274 TNC for sale> To: packet-radio@ucsd.edu> > For sale once again:> > MFJ 1247 HF/VHF TNC. Almost never used (yes it works).> > LED tuning display. Compatible with MFJ WeFAX software (for PCs and> Macintoshes). Personal mailbox.> > Comes with 5-lead RS232 cable and homebrew connector to use on Icom IC2AT.> > Bought for $150.00 at Dayton. Asking $125.00. May trade or bargain.> > For more info:> > Mike Sensor KD3LR / AFA1UP> Box 134 Oak Hall> Penn State Altoona Campus> Altoona PA 16601-3760> (814) 949-5439> UNTIL MAY 4!> > 2406 E 32 St> Erie PA 16510-2702> (814) 899-8261> AFTER MAY 4!> > C'mon, MFJ isn't *that* bad!> > Mike Sensor MLS129 @ PSUVM> > ------------------------------> > Date: 24 Apr 90 01:28:17 GMT> From: usc!pollux.usc.edu!kjh@ucsd.edu (Kenneth J. Hendrickson)> Subject: pulse on X-band> To: packet-radio@ucsd.edu> > I received some email from W3OTC that I responded to, and thought a> posting would be appropriate. Here it is:> > % From: Robert Carpenter <rc%cmr.ncsl.nist.gov@usc.edu>> > % Am I missing something? It seemed to me that you wouldn't benefit from a> % low duty cycle when fighting a large path loss. I would think that some> % synchronous system, with correlation detection of some sort, would be the> % best bet. Of course you COULD build a receiver that just listened during> % the narrow pulses to ignore the in-between noise. I'd also worry a bit> % about pulse-spreading due to multipath. Maybe a pseudo-random scheme would> % be a good approach, but would likely have a mid-to-high duty cycle, and thus> % not be pulse.> > It is a possibility to build a receiver that only listens when a pulse> is supposed to occur, but that wasn't necessarily what I was thinking> about. The advantage of using the high peak power of a pulse is that it> would be EASILY DETECTABLE even with high path loss. This means that> (in theory) you could set up a data link much like CW is used with the> human ear: the presence of a pulse has one meaning, and the absence of a> pulse has another. There is probably even a better way to do it:> consider what you could do if you were to phase modulate the pulses. In> other words, control the time delay or latency between pulses. A short> time delay could mean a 0 bit, and a long delay could mean a 1 bit.> > % Or do you have a good source of low duty cycle 10 GHz power, and want to> % build a system around it?> > No, I don't have a 10 GHz pulse source, but they are available. Now if> we could only use them legally ...> > % Pardon the confused questions, but I don't normally think of low-duty-cycle> % pulse transmission and weak signal operation as going together.> > Most people don't. Certainly, I'm not suggesting that real time> communications like voice be sent this way. I'm merely proposing that> this might be a good use for part of our microwave spectrum. The packet> guys are in great need of high-speed inter-city links (among other> things).> > % Bob W3OTC> > % PS. Look at the picture of the 10 GHz SSB PHONE station in QST (I thought in> % W3XO's column, but can't find it.) I've seen and heard '3XO's video of it> % operating over a non-line-of-sight 25 mile path with excellent sigs.> % The power output was in the 20 - 100 mW range, I think.> > I've done better than 40 miles over non-line-of-sight paths with only> 10 mW and CRUDDY WIDEBAND FM! This was with 2 foot dish antennas on> both ends of the path at X-band. Still, I'm not pooh-poohing their> efforts; I'm just trying to show that even with simple cheap equipment> you can do a lot more than most people expect in the SHF and EHF> spectrum.> > Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh> > ------------------------------> > Date: 24 Apr 90 01:41:49 GMT> From: usc!pollux.usc.edu!kjh@ucsd.edu (Kenneth J. Hendrickson)> Subject: pulse on X-band> To: packet-radio@ucsd.edu> > In article <1250147@hpnmdla.HP.COM> glenne@hpnmdla.HP.COM (Glenn Elmore) writes:> % Ken,> % I don't think pulse privileges really are that much of an issue in> % preventing effective use of the band. As I see it, the main advantage would be> % in using surplus hardware.> > Yes, this would be the advantage. I'm not suggesting that we have an> undue hardship with the pulse restriction; I am suggesting that it is> arbitrary and capricious, and that if we didn't have the restriction,> there would be one more possible way that we could effectively> communicate on the band.> > % However, moderate power narrowband > % equipment is no longer a difficult proposition. Very long links and> % OTH links require optimum use of the resources; reasonably efficient> % use of the spectrum (bps/Hz numbers) and highly directional beams to> % avoid waste and QRM; as well as physically larger receive antenna apertures> % to recover the information. Even so I suspect that for reliable networks and > % comm. channels we are likely to end up with a larger number of shorter LOS > % links instead of long haul OTH ones.> > This may be true. However, I don't think anybody has ever experimented> with using high-power low-duty-cycle signals to build a packet switched> microwave network. My idea might not pan out to anything, but on the> other hand, how will we know unless somebody tries to do it?> > % Troposcatter is a fairly predictable > % propagation mechanism at 10 GHz (see my description of an> % experience with it on a 400+ mile path during the 1987 10 GHz terrestrial > % DX record outing in December 1987 QST) but long haul links are inherently> % lossier and less reliable than shorter LOS ones.> % I strongly agree that we need to use our microwave resources and in> % particular 10 GHz but I think we will end up finding that for efficient> % use of our amateur resources we will start looking more like the telephone> % companies and common carrier folks when we solve the backbone problem.> % > % Glenn Elmore -N6GN- N6GN @ K3MC glenn@n6gn.ampr.org glenne@hpnmd.hp.com > > Sure, we might wind up looking like the telephone companies. Maybe they> have already tried the pulse idea. On the other hand, I have never> heard of it. If nobody has yet tried it, to see what the results are,> what is wrong with us amateurs giving it a try. It just might be> useful.> > Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 15:00:22 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Thu Apr 26 17:52:50 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 15:00:00 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa01499; 26 Apr 90 17:46 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id aa09309; 26 Apr 90 16:06 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id ac10941; 26 Apr 90 17:16 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa10889; 26 Apr 90 17:13 BST> Received: by ucsd.edu; id AA19048> sendmail 5.61/UCSD-2.0-sun> Thu, 26 Apr 90 08:28:37 -0700 for brian> Received: by ucsd.edu; id AA19043> sendmail 5.61/UCSD-2.0-sun> Thu, 26 Apr 90 08:28:36 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004261528.AA19043@ucsd.edu>> Date: Thu, 26 Apr 90 08:27:52 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #9> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Thu, 26 Apr 90 Volume 90 : Issue 9> > Today's Topics:> DEC Rainbow> DOVE Satellite> faster modems> How decipher DOVE telemetry?> TAPR DCD on Heath 4040> US Navy and packet radio> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 25 Apr 90 19:53:26 GMT> From: swrinde!cs.utexas.edu!samsung!xylogics!bu.edu!m2c!wpi!tmurphy@ucs d.edu (Tom [Chris] Murphy)> Subject: DEC Rainbow> To: packet-radio@ucsd.edu> > With any luck, I'll be getting a Technician licence this weekend and> as soon as it comes in the mail, I plan on trying some work with packet> radio. I may be inheriting a DEC Rainbow, and was wondering what software> exists for it to do TCP based work, primarily mail although telnet and> ftp would be nice also. Thanks for the help in advance!> > Tom Murphy> tmurphy@wpi.wpi.edu> > ------------------------------> > Date: 25 Apr 90 15:06:01 GMT> From: idacrd!mac@princeton.edu (Robert McGwier)> Subject: DOVE Satellite> To: packet-radio@ucsd.edu> > In article <9004241908.AA14576@ucsd.edu>, by KEVIN@CALSTATE.BITNET:> > I have been monitoring for DOVE for a coupla days, and haven't heard a peep.> >> > Kevin:> > It is alive and well downlinking on 2401.100 Mhz +/- an unbelievable amount> of doppler. There is no way the straight calculation can be as impressive> as trying to track that stuff and copy data! I am reloading its software> and its gonna do speech when it comes back on.> > Bob> > -- > _________________________________________________________________ ___________> My opinions are my own no matter | Robert W. McGwier, N4HY> who I work for! ;-) | CCR, AMSAT, etc.> ----------------------------------------------------------------- -----------> > ------------------------------> > Date: 26 Apr 90 02:10:11 GMT> From: sun-barr!newstop!texsun!texbell!splut!jay@apple.com (Jay "you ignorant splut!" Maynard)> Subject: faster modems> To: packet-radio@ucsd.edu> > In article <22526@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes:> >I have done a *lot* of thinking about this problem. Given that amateur radio> >is a voluntary, personally funded activity, you can't force hams to buy new> >hardware. But there's another approach: establishing a frequency allocation> >policy that encourages the use of more efficient modulation and frequency> >reuse techniques. The more efficient your proposed use of the spectrum, the> >more likely you are to get an allocation.> > >Amateur frequency coordinators now follow a first-come first-served policy,> >and this *must* change. In many areas like Los Angeles and New York, the> >VHF/UHF bands are nearly full with FM repeaters and conventional 1200 baud> >packet, and there is little room to experiment with newer, more efficient> >techniques.> > (dig, dig...ok, I found it.) [putting on President, Texas VHF-FM Society hat]> > You've beat this drum before, and I've argued it before. While your idea> has merit in a perfect society, it *cannot* work in the real ham world.> > Frequency coordinators now serve in an advisory capacity. You'd like us> to tell people who have coordinations and are currently operating> repeaters on frequencies where they do not experience regular,> significant interference (the standard which coordinators try to> maintain) that, all of a sudden, the rules have changed, and that they> must either shut down entirely, or accept unheard-of, and previously> unacceptable, levels of interference.> > They wouldn't listen to us.> > Instead, they'd keep on operating on what they perceive as *their*> frequency. You know that they don't own it, I know it, but they don't -> and they're the only ones with the power to make such a change work.> > Frequency coordination and spectrum management isn't just a technical> problem, but a highly political one as well. Come up with a way to> accomplish your goal that *can* be accepted by the population of current> FM voice system operators and users, and your wish will come true, and> I'll sign up to promote it. This isn't the school debate society,> though, where changes can be implemented by fiat. You must account for> the mechanisms involved in implementing the change, and _that_ is where> your problem lies.> > -- > 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, RIP. It was nice knowing ya +----------------------------------------> "Flying is a lot more fun than being in the Senate." -- Senator Jake Garn> > ------------------------------> > Date: 25 Apr 90 22:20:31 GMT> From: deimos.cis.ksu.edu!harris.cis.ksu.edu!mac@uunet.uu.net (Myron A. Calhoun)> Subject: How decipher DOVE telemetry?> To: packet-radio@ucsd.edu> > My packet station can hear DOVE's telemetry;> now I'd like to know what it means.> > Is there a source for software to decipher the> hex stuff into meaningful-to-humans information?> > Please reply by email.> --Myron.> --> # Myron A. Calhoun, Ph.D. E.E.; Associate Professor (913) 539-4448 home> # INTERNET: mac@harris.cis.ksu.edu (129.130.10.2) 532-6350 work> # UUCP: ...{rutgers, texbell}!ksuvax1!harry!mac 532-7004 fax> # AT&T Mail: attmail!ksuvax1!mac> > ------------------------------> > Date: 25 Apr 90 20:27:41 GMT> From: sdd.hp.com!zaphod.mps.ohio-state.edu!sunybcs!uhura.cc.rochester.e du!rochester!kodak!eastman!hpcore!gerwitz@ucsd.edu (Paul Gerwitz)> Subject: TAPR DCD on Heath 4040> To: packet-radio@ucsd.edu> > I am posting this for someone who does not have net access. Please send> email replies to him directly at 'uunet!atexnet!kodak!eastman!dieter'.> > ----------------------------------------------------------------- ------> > Subject: HELP w/ TAPR DCD Upgrade> > I recently built a TAPR 2211 DCD upgrade kit. It is supposed to enhance DCD> operation.> > After installing the kit in my Heath HD-4040, the DCD light in fact does seem> to react much better (less falsing, more constant when it does lock on). The> only problem is now my TNC will TRANSMIT EVEN WHEN THE DCD LIGHT IS ON !!!! I> have checked the assembly and the value of most of the components. I cannot> imagine how the thing can transmit with the DCD light on. It's supposed to> inhibit transmit isn't it ? If anybody has any experience with this PLEASE> HELP !!! Leave a message, or call Mark at (716) 723-0227. Thanks> > ----------------------------------------------------------------- -------> --> +---------------------------------------------------------------- ------------+> | Paul F Gerwitz WA2WPI | SMTP: gerwitz@kodak.com |> | Eastman Kodak Co | UUCP: ..rutgers!rochester!kodak!eastman!gerwitz |> +---------------------------------------------------------------- ------------+> > ------------------------------> > Date: 25 Apr 90 16:08:00 EDT> From: "SWEIGERT, DAVID" <dsweigert@paxrv-nes.navy.mil>> Subject: US Navy and packet radio> To: "packet-radio" <packet-radio@wsmr-simtel20.army.mil>> > The U.S. Navy has commissioned a multi-media test of ship-shore> data communications. Particular media under test:> > o HF communications> o Fleet SATCOM (2400 bit/second US Navy satellites)> o INMARSAT Commercial satellite channels> > It is believed the HF communications portion shall include a packet radio> test.> > SPAWAR Code PMW-156 (Capt. Joesph Price, USN) is coordinating the test> at the direction of VADM Jerry O. Tuttle, USN, OPNAV Code 094. The testing> agent shall be the Naval Engineering Center at Vallejo, CA. The test platforms> shall be ships assigned out of San Diego, CA. The test is lated to begin> this summer.> > Mission support data shall be transferred from an aircraft carrier to shore> based NARDAC, Naval Regional Data Automation Center.> > > cheers...> > WB9VKO> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 15:15:49 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Fri Apr 27 13:29:54 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 15:15:27 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa05720; 27 Apr 90 13:20 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id af04978; 27 Apr 90 12:04 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id aa13232; 27 Apr 90 12:56 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa13189; 27 Apr 90 12:54 BST> Received: by ucsd.edu; id AA20478> sendmail 5.61/UCSD-2.0-sun> Fri, 27 Apr 90 04:00:10 -0700 for brian> Received: by ucsd.edu; id AA20467> sendmail 5.61/UCSD-2.0-sun> Fri, 27 Apr 90 04:00:06 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004271100.AA20467@ucsd.edu>> Date: Fri, 27 Apr 90 04:00:03 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #10> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Fri, 27 Apr 90 Volume 90 : Issue 10> > Today's Topics:> Ham Packet BBS on ATT UNIX PC?> Universal M-610 wanted> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 27 Apr 90 02:31:18 GMT> From: zaphod.mps.ohio-state.edu!math.lsa.umich.edu!sharkey!lopez!flash@ tut.cis.ohio-state.edu (Gary Bourgois)> Subject: Ham Packet BBS on ATT UNIX PC?> To: packet-radio@ucsd.edu> > Here's the deal. I am the system administrator of a Public Access Unix > BBS, and have been running a BBS at the same phone number since 1983. > Being a consultant by trade, and doing all of my work at home, I can run > the BBS, and also play ham radio day and night. I have a speaker from > the ham rig in my computer room, and I have a video feed from the BBS > monitor in my ham shack. The two hobbies sort of meld. I talk with > other UNIX people on the ham bands, and send email to ham friends on > USENET.> > I am obsessive compulsive, I admit it and I use it to an advantage.> > I do not have a packet system. Not today. I always managed to put it > off.> > The PBBS that serves this area of Upper Michigan is going to be going > down soon. They are looking for someone else to run one.> > A ham from Lower Michigan said he would donate a TNC. I agreed to supply > what equipment I can, and am mulling over what is the best way to go. I > have an old XTAL type 2m rig and a spare antenna to kick into the project.> > I also have an AT&T UNIX PC with a 20 meg hard drive. Not much, but > probably enough to run a PBBS.> > Why the UNIX PC? (also known as a 7300, or 3b1)> > Well I got to thinking how easy it would be, while reading rec.ham.radio > on the console of the landline BBS, I could forward articles to the > Packet BBS with ease, using UUCP.> > Has anyone ever done this?> > Would the 3b1 be up to the job? If so, I will also donate that to the > project. It would be a great service to the hams of Northern Michigan to > have selected articles from USENET ported over to our local PBBS. I will > not do it if I have to haul floppies up a flight of stairs (The USENET > site is on the ground floor, and my hamshack is one floor up).. BUT > using UUCP would be a breeze.> > Our own BBS software on lopez is locally written, so I can have any mods > I want tossed in simply, and many I can write myself (The software > STARBASE, is very configurable, and will eventually be made public)...> > The trick will be to link everything together. I am sure it could be > done with a XENIX type PC, but that route is beyond our meager budget.> > Any ideas, thoughts, ponderings, musings, experiences welcome.> > Thanks, es 73> > Gary> -- > == 14.313 == Amateur Radio Forum Saturday 11:00AM Eastern time == 14.313 ==> == Gary Bourgois flash@lopez (rutgers!sharkey!lopez!flash) GWN UPLink ==> == 3.950 Nationwide Amateur Radio Nightly after 0200z=Learning Channel ==> =============== WB8EOH = The Eccentric Old Hippie = WB8EOH ================> > ------------------------------> > Date: 26 Apr 90 13:50:56 GMT> From: portal!cup.portal.com!Lee_-_Reynolds@apple.com> Subject: Universal M-610 wanted> To: packet-radio@ucsd.edu> > Wanted - the Universal M-610 tuning scope and M-605 FDM box.> > > Please Email me at Portal or call me at (617)860-8629> > > Lee G8LCK> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 15:36:44 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Sat Apr 28 13:33:05 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 15:36:23 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa10554; 28 Apr 90 13:28 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id aa04573; 28 Apr 90 12:33 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id aa05678; 28 Apr 90 13:13 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa05603; 28 Apr 90 13:08 BST> Received: by ucsd.edu; id AA24794> sendmail 5.61/UCSD-2.0sun> S at, 28 Apr 90 04:00:07 -0700 for brian> Received: by ucsd.edu; id AA24788> sendmail 5.61/UCSD-2.0-sun> Sat, 28 Apr 90 04:00:06 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004281100.AA24788@ucsd.edu>> Date: Sat, 28 Apr 90 04:00:03 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #11> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Sat, 28 Apr 90 Volume 90 : Issue 11> > Today's Topics:> faster modems> Ham Packet BBS on ATT UNIX PC?> Hams in space?> MFJ TNC sold> Networking> SAREX STS-35 space shuttle> shareware in packet radio> Teletext> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 25 Apr 90 18:57:01 GMT> From: vsi1!zorch!tandem!kevinr@apple.com (Kevin J. Rowett)> Subject: faster modems> To: packet-radio@ucsd.edu> > In article <690@idacrd.UUCP> mac@idacrd.UUCP (Robert McGwier) writes:> >> >I believe that for hams in the US, it must be made into an appliance.> > I completely agree Bob!> > > We> >have also suffered another set back with the Totally Awesome IO board> ^^^^^^^^> > Bob, from the trenches, we don't really view it as a set back. Delay> *maybe*, but Awesome I/O *is* happenning! I'm staring at film right> now ready to go to a board maker....> > We do live in Silicon Valley, and getting cards made is easier than> shopping for a car here. The PacBell yellow pages has three entire> pages listing people who will make cards..> > We realize there's more to getting a product out than just having cards > made, but it K3MC Awesome will happen.> > >project. Its commercial license was never completed and those efforts> >have now fallen through. > > THis really sounds worse than it is. K3MC (Awesome ) has not died! Only the> arrangements with that particular commericalizer.> > > Totally Awesome> >IO from K3MC/N6RCE, 10 Ghz-megabit stuff from Glen Elmore, TCP-IP from> >KA9Q, we have ALL the technology we need to lead us into 21-st century.> >> >Bob> > > N6RCE> > ------------------------------> > Date: 27 Apr 90 21:24:51 GMT> From: umich!sharkey!cfctech!ttardis!rlw@CS.YALE.EDU (Ron Wilson)> Subject: Ham Packet BBS on ATT UNIX PC?> To: packet-radio@ucsd.edu> > In article <1990Apr27.023118.15972@lopez.UUCP>, flash@lopez.UUCP (Gary Bourgois) writes:> >A ham from Lower Michigan said he would donate a TNC. I agreed to supply > >what equipment I can, and am mulling over what is the best way to go. I > >have an old XTAL type 2m rig and a spare antenna to kick into the project.> >> >I also have an AT&T UNIX PC with a 20 meg hard drive. Not much, but > >probably enough to run a PBBS.> >....> >The trick will be to link everything together. I am sure it could be > >done with a XENIX type PC, but that route is beyond our meager budget.> >> >Gary> > Anything thing you can do with Xenix on a PC, you can do with the Unix-PC.> > A 20 meg disk might be too small - even a minimal news feed requires a lot> of disk space.> > There is program written by the people at KA9Q called simply KA9Q. It is> a program designed to implement protocols like Telnet (a terminal emulator),> FTP (file transfer protocol), and others over packet radio.> > KA9Q does work on the Unix-PC.> > Using the KA9Q program and a pty driver would enable any Unix system to> receive Telnet and FTP connections over packet radio (not to mention SLIP/SLFP> connections from other computers).> > Because of the pty driver (psuedo terminal), any Telnet connection would log> into the Unix system normally (via getty and login) just as through the> person had called in with a modem.> > I'm sure other people on the net can help you with technicalities in setting> this up (I know nothing about packet radio other than what it is).> > Good luck.> > - Ron> > ------------------------------> > Date: Fri, 27 Apr 90 07:52:53 PDT> From: KEVIN%CALSTATE.BITNET@CORNELLC.cit.cornell.edu> Subject: Hams in space?> To: packet-radio@ucsd.edu> > I recall reading some months ago that this summer, an astronaut on the Space> Shuttle will be doing 2 meter packet communications with earthlings.> > When will this occur? On what frequency? Will it be possible for me> to communicate with them using my BIG 5 watts of power? do i need a special> antenna or will my rinkydink ones made out of coathangers do the trick?> I expect QRM will be real bad, but the equiptment I got is what I'm stuck> with ... I yam what I yam.> > All help appreciated!> > -- Kevin> > +----------------------------------------+ DISCLAIMER: I assume no> : KEVIN M. SAVETZ - KC6GWQ : responsibility for any messages> : Bitnet: kevin@calstate.BITNET : that I post, expressed or> : Internet: humbolt!waffle@csun.edu : implied. Opinions expressed> : Fishnet: salmon@smoked.poached.fried : by me are not necessarily> +----------------------------------------+ my own.> > -30-> > ------------------------------> > Date: 27 Apr 90 19:39:24 GMT> From: psuvm!mls129@psuvax1.cs.psu.edu (Michael L. Sensor)> Subject: MFJ TNC sold> To: packet-radio@ucsd.edu> > The MFJ 1274 TNC I advertised here has been sold.> > Mike Sensor MLS129@PSUVM> > ------------------------------> > Date: 26 Apr 90 08:29:49 GMT> From: mcsun!ukc!stc!praxis!riemann!mikec@uunet.uu.net (Michael Chace)> Subject: Networking> To: packet-radio@ucsd.edu> > Hello All,> > I'd like the benefit of people's experiences concerning what to do when> your local 2m 1200bps single channel based network begins to overload.> > Our local packet network is at breaking point for about 50% of the time.> To put the network under a more 'formal' basis we had a meeting of> all local packeteers with the aim of creating a group to maintain and> enhance the network. Various suggestions were made on how to solve things,> some good, some bad. Here's a summary of the network as it stands:-> > NB - My local area is Bath/Bristol/Cardiff (S/W England & S Wales)> Total population ~1 million - Amateurs on packet ~300> > 90% of traffic sits on 144.650 all 1200bps - Local chats and node traffic.> Some links now exist on 70MHz - mainly for BBS forwarding.> There are 2 major nodes on 2m - They are on very high sites running 25W erp> consequently they hear a lot and lots can hear them.> > Perhaps a greater problem is that most routes out of our area are poor and> they also must talk to well-sited nodes. It not unusual to have stations> telephoning node sysops because they think the node is down - when its due> to the node hearing so much that its squelch is permanently open!> Most of the nodes in our area form backbone links in all directions and the> NTS Mailboxes rely on them heavily.> > The basic idea is to move the well-sited nodes into lower 'city' locations> keep them as the user access points and then tie up these nodes on separate> links (4m/70cms/23cms). Where to put the links is a moot point - 4m has a > source of cheap PMR equipment but no bandwidth - 70cms more expensive, more> channels but it's not a primary band - 23cms expensive but plenty of wide> open space.> > What I'd like are your thoughts/experiences/suggestions etc. Particularly> why you chose frequencies/data speed etc.> > As a final note - one of the things that I noticed at the meeting and while> talking to the local users were :-> > 1) People need to learn that the packet system needs to shunt data> fast. It's a serious network that moves data regardless of what> the data is and how it gets from one point to another.> > 2) People don't understand much about protocols and the NET/ROM> system eg. NOT realising that KA/NODES are not real nodes and> trying to explain why p-persist will squeeze a few more % out> of the network.> > > Thanks for your time & 73,> > Mike> ****> ................................................................. ............> | ARPA : mikec@praxis.co.uk | Michael Chace |> | JANET : mikec@uk.co.praxis | PraXis Systems |> | UUCP : ...!uunet!mcvax!ukc!praxis!mikec | Manvers Street |> | AMPRNET: g6dhu@g6dhu.ampr.org [44.131.20.3] | Bath, Avon |> | AX.25 : G6DHU @ G6DHU-2 or G6DHU @ GB7SDN | BA1 1PX UK |> | Phone : (44) [0]225 444700 | |> ................................................................. ............> > > > > ------------------------------> > Date: 27 Apr 90 16:38:43 GMT> From: microsoft!joehol@uunet.uu.net (Joseph HOLMAN)> Subject: SAREX STS-35 space shuttle> To: packet-radio@ucsd.edu> > i never got any direct replies, so i'll try again...> > > is any body out there going to have a way for use> people up in Seattle (latitude 47 deg.) to connect> to the SAREX mission ?> > i've heard rumors about people having KA-NODEs, but> i haven't heard from the horses mouth yet...> > anybody have any names or callsigns of people doing/planning > this ????> > joe holman, ka7ldn> uw-beaver!microsoft!joehol> joehol@microsoft.uucp> 206-882-8921 work> > ------------------------------> > Date: Fri, 27 Apr 90 13:25:12 MST> From: sarrel%miranda.uucp@moc.Jpl.Nasa.Gov (Marc Sarrel)> Subject: shareware in packet radio> To: packet-radio@ucsd.edu> > Is there an FCC policy or other generally accepted rules regarding> putting shareware on packet radio BBS's? Is transmitting shareware> considered a "business communication"? What about freeware? Just> curious...> > --marc> > -=-> Marc A. Sarrel> N7OLI> sarrel%miranda.uucp@moc.jpl.nasa.gov | "Oh, _lightweight_ Alpaca..."> ..!sun!sunburn!miranda!sarrel | -Blanche DuBois> > NSA fodder:> > Binary Chemical Weapon domestic disruption munitions FBI Clifford> Stoll Soviet detonator fissionable KGB colonel $400 million in gold> bullion genetic backsatter Pentagon nuclear> > ------------------------------> > Date: 27 Apr 90 15:01:26 GMT> From: motcid!froula@uunet.uu.net (Don Froula)> Subject: Teletext> To: packet-radio@ucsd.edu> > Does anyone have information about the fate of Teletext services in the US?> This is an information service that provides text and block color graphics> capability on a home TV receiver equipped with a special decoder. The data> is embedded in several unused TV lines in the vertical blanking interval.> The data repeats over and over in the form of a magazine. The decoder> simply grabs pages as they come by and stores them in a display buffer.> The system is very popular in the UK.> > Zenith used to offer an embedded decoder on some of their sets. Also, Dick> Smith electronics offered a kit a few years back.> > Observations on several local broadcast and cable channels show considerable> activity in the blanking interval. > > Information on current status of Teletext and sources for decoders would> be appreciated.> > Don WD9DMP> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 15:44:15 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Sun Apr 29 12:59:58 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 15:44:03 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa17143; 29 Apr 90 12:53 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id aa03394; 29 Apr 90 11:59 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id aa02926; 29 Apr 90 12:38 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa02870; 29 Apr 90 12:32 BST> Received: by ucsd.edu; id AA09531> sendmail 5.61/UCSD-2.0-sun> Sun, 29 Apr 90 04:00:08 -0700 for brian> Received: by ucsd.edu; id AA09518> sendmail 5.61/UCSD-2.0-sun> Sun, 29 Apr 90 04:00:05 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004291100.AA09518@ucsd.edu>> Date: Sun, 29 Apr 90 04:00:03 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #12> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Sun, 29 Apr 90 Volume 90 : Issue 12> > Today's Topics:> AR-2002 scanner remote info wanted> faster modems> Ham Packet BBS on ATT UNIX PC?> Need help in radio data communic.> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 28 Apr 90 10:38:55 GMT> From: eru!luth!sunic!mcsun!hp4nl!dutrun!dutentb!ese@BLOOM-BEACON.MIT.ED U (Kees Schot)> Subject: AR-2002 scanner remote info wanted> To: packet-radio@ucsd.edu> > !! HELP !!> > For about one year I'm looking for information on the> computer interface of the AR-2002 communications receiver.> > If someone has hard- or software information about> this interface (or also about other interesting aspects of> this equipment) please send it to me by email to> > schot@dutentb.tudelft.nl> > or on paper to:> > C.A. Schot,> Grote Kreek 45,> 3079 CC Rotterdam,> The Netherlands.> > Even the name and address of the (I thought Japanese)> manufacturer of this scanner can help me.> > Please, help me, because this is the last hope for me> to get this information.> > ------------------------------> > Date: 28 Apr 90 15:56:42 GMT> From: payne@tcgould.tn.cornell.edu (Andrew Payne)> Subject: faster modems> To: packet-radio@ucsd.edu> > In article <9004232134.AA04767@miranda.uucp> sarrel@miranda.UUCP (Marc Sarrel) writes:> >expert" at a local amateur radio store recently. I asked him about> >some TNC that had a 2400 baud modem vs one that had a 1200 baud modem.> >I asked wether 2400 would catch on, given my experience with land line> >modems where everyone was starved for speed. He said "no." His> >reasons seemed pretty fuzzy to me, but he seemed to claim that 1) 2400> >baud wouldn't catch on because everyone already has 1200 baud modems,> >2) 1200 baud seemed fast enough to him, and 3) that 2400 baud wasn't> >_really_ twice as fast as 1200 because the extra speed was used> >inefficiently. (But don't hold me to that, this was a while ago.)> >> I also feel that 2400 baud will not catch on, but my reasoning is > much different. 2400 baud is just not that much of a jump beyond 1200 to > make it worth the trouble. Go for 9600 baud or 56kb (though 4800 baud seems> to be a happy medium for many because it supposedly works with more radios than> the higher speeds).> > >Anyway, my question is this: How can we "hams in the know" encourage> >the use of faster and more effecient modems on the airwaves, given> >that we agree that "faster is better." One of this guy's arguments> >holds weight in that there is a lot of "hardware inertia" out there.> > The first step in taking advantage of higher speed modems is to use> them on the backbones. The backbones are where the heavy traffic is anyway,> and there is little "hardware inertia" involved. You could run some strange> I'm-not-compatible-with-anything protocol and modem on the backbones and it > wouldn't really matter.> > Many of the UHF backbone links of the network in Ohio are at 4800> baud. The NEDA guys have many 4800 baud trunks and are quickly moving for > 9600 baud. Also, on the NEDA network, many of the high-volume users (DX > clusters, BBSs, TCP/IP) are using higher speed uplinks to the backbone.> > There is never going to be an overnight switch away from 1200 baud.> Like MS-DOS, it will dog us for a long, long time. Put the high-speed modems> in the places will they will give maximum benefit and gradually people will> migrate beyond 1200 baud.> > > -- > = = = = = = = = = = = = = = = = = = = = = = = = = = => Andrew C. Payne, N8KEI UUCP: ...!cornell!batcomputer!payne> INTERNET: payne@tcgould.tn.cornell.edu> > ------------------------------> > Date: 28 Apr 90 21:56:00 GMT> From: usc!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs. uiuc.edu!kenny@ucsd.edu> Subject: Ham Packet BBS on ATT UNIX PC?> To: packet-radio@ucsd.edu> > >There is program written by the people at KA9Q called simply KA9Q.> > Gee, Phil, I never knew you were twins.... 8-)> > Kevin, KE9TV> kenny@cs.uiuc.edu> > ------------------------------> > Date: 28 Apr 90 00:08:00 GMT> From: swrinde!zaphod.mps.ohio-state.edu!uwm.edu!bionet!arisia!cdp!saff@ ucsd.edu> Subject: Need help in radio data communic.> To: packet-radio@ucsd.edu> > Friends,> > I work in a brazilian organization who also give> support for non-profits organizations. We work with a similar> organization, here in San Francisco Bay Area. We are about to get> authorization to use the PeaceSat, an old militar satellite now used> for pacific purposes, and we plan to use initially to get a cheap> and good link from our machines. I have no experience in this area,> so I am asking for help with some (maybe dumb) questions:> > - Possible baud rates> > - Hardware required> > - Places where look for hardware> > Thanks very much for any help,> > Saliel Figueira Filho> Chief Programmer> IBASE> > {pyramid, hplabs, ...}!cdp!saff> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: 2 May 90 05:43:47 GMTFrom: swrinde!emory!rsiatl!jgd@ucsd.edu (John G. De Armond)Subject: faster modemsTo: packet-radio@ucsd.edukarn@thumper..bellcore.com (Phil R. Karn) writes:>In article <1959@rsiatl.UUCP> jgd@rsiatl.UUCP (John G. De Armond) writes:>>In terms of rules, before the great ARRL/FCC rules rewrite, this type>>modem [wa4dsy]>>could be used at 220 mhz and above. Now that we've been "represented">>again by the ARRL, 220 is out. But anything 440 or above is fine.>This is news to me. I'm still running 56kbps on 220.55, and as far as I>know it's still entirely legal.I'm sorry that I can't quote chapter and verse, Phil, but I don't havemy personal copy of the new Part 97 yet. My comment stems from a GRAPESsession a few months ago when we were reviewing the rewrite. As I recall,the new language puts both a baudrate and a bps limit on everthing below440. I'm going to be in a ham store tomorrow, so I'll pick up myown copy of Part 97 and find the clause. Meanwhile, you might wantto reread the digital sections carefully. It was the consensus of every-body that read those paragraphs that day that 56k was out on 220.John-- John De Armond, WD4OQC | We can no more blame our loss of freedom on congressRadiation Systems, Inc. | than we can prostitution on pimps. Both simplyAtlanta, Ga | provide broker services for their customers.{emory,uunet}!rsiatl!jgd| - Dr. W Williams | **I am the NRA** ------------------------------Date: Tue, 1 May 90 9:00:38 PDTFrom: Peter Dahl <pdahl@milton.u.washington.edu>Subject: Full Duplex packet on 2 meters?To: packet-radio@ucsd.edu Is anyone operating dual frequency, full duplex packet nodes on2 meters on frequencies other than coordinatable/bandplan repeater pairs?How about 145.01/145.61? How do you interpret the fcc rules on this one?145.61 is in an area where repeaters are supposedly not permitted but is a fullduplex packet node a repeater as we have come to know repeaters? TheARRL Repeater Directory says that the frequencies between 145.5 and I believe145.8 are bandplanned for experimental modes. Everything in this developingmode of packet radio is experimental isn't it? Please let me know what you think.... We need some full duplexpacket systems and standard repeater pairs have all been used for voice repeaters whether they are really needed or not. Peter, WA7FUS------------------------------Date: 1 May 90 22:41:00 GMTFrom: zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1 .cso.uiuc.edu!phil@tut.cis.ohio-state.eduSubject: Full Duplex packet on 2 meters?To: packet-radio@ucsd.eduYou might try doing some unusual splits in the repeaters. The FCC rulesdo NOT allow repeaters in the 145.5-146 Mhz range (nor 144.0-144.5) soyou need to limit yourself to 144.5-145.5 and 146-148.It is a sad shame that spectrum planners and repeater coordinators are notmaking any attempt to plan for greater density of spectrum usage. Theysimply assume that when there is no repeater pair that comes up without aconflict on the computer, that that band is full at that location.Spectrum planners need to get on the ball and do some planning. If thatcalls for some repeater pairs to be dedicated to packet, so be it. It maynot be necessary to do that.However I must assert one thing for certain: just because someone has had arepeater on a given frequency already is no reason for having a "right" tostay there. If packet radio needs to share the spectrum of repeater pairsthen the spectrum should be allocated as needed.This probably means some repeaters will have to move. Hey folks, that ispart of progress. Of course some hams are totally against progress, andthe only solution I can suggest for them is to take them off the air.By the way, you CAN get several TIMES the number of repeaters on the airin the major cities as you have now. It also appears that the number ofrepeaters in several are NOT EVEN NEEDED. The situation as it exists nowis mostly turf claims. This has to end and spectrum planners and repeatercoordinators need to get off their hind ends and do something.Problems will always exist when those who coordinate are also there toprotect the turf of existing repeater owners.I a big city you can hit 20 to 40 repeaters easily. Tell me how many ofthem are actually IN USE most of the time? What is the average amount ofairtime per repeater per day? I think you will find things are NOT asdense as we might like to think.--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society<phil@ux1.cso.uiuc.edu> | no matter what the particular issue is all about.------------------------------Date: 2 May 90 01:50:19 GMTFrom: uokmax!nsslsun.gcn.uoknor.edu!skaggs@apple.com (Gary Skaggs)Subject: Full Duplex packet on 2 meters?To: packet-radio@ucsd.eduI agree 100% with Phil on the problem of repeaters and the need for endingthe *turf* battles that are occurring over frequency *rights*. But, I thinkthe REAL solution if you want *full duplex* is individual, not-necessarily-600 Khz-offset frequencies. put one in the 145 simplex area, the other in146. Yes, I know *FM simplex* is what it says. If the natives are restlessabout such *sins*, cross-band. This saves on duplexor costs. You can buya good quality radio for less than what it will cost you for a good set ofband pass/band reject duplexors. Then run real full duplex.On second thought, go up in frequency and run FAST, full duplex.__________________________________________________________ ____________________Gary Skaggs Internet: skaggs@nssl.gcn.uoknor.eduNational Severe Storms Laboratory (The Tornado People) "The Channel 9 Alpha system, technology at it's ____________?"------------------------------Date: 1 May 90 18:15:29 GMTFrom: ndcvb!cartan!ndmath!nstar!w8grt!jim.grubs@iuvax.cs.indiana.edu (Jim Grubs)Subject: Higher speedsTo: packet-radio@ucsd.edu(330) Sat 28 Apr 90 3:42pBy: Brian BattlesTo: Bob McgwierRe: Fast packetSt:-------------------------------------------------------- ----------------------@EID:1811 149c7d40Bob, In your reply to Marc Sorrel, you wrote: BM> ...Hams are basically cheap... Make that "poor," not necessarily cheap. Most hams I know areperpetually in danger of bankrupting their family financies to buynew gizmos. BM> ...and these days they are basically technically lazy... Although many are just busy or lacking education. Some of us havelittle time to get on the air, let alone design and build some fancynew digital high-tech device. Some hams have had little computer ordigital education and have to struggle to keep up. Besides, many hamsprefer to provide traffic handling/emergency communications/etc thanto build a lot of gear. BM> ...My efforts in this area along with partners KB2CST and KA2MOV BM> for commercial concerns and with WA7GXD, KV7B, W3IWI for TAPR and BM> AMSAT have essentially been done for free... And are greatly admired and appreciated by all amateurs with anyslight understanding of technology and creativity! BM> ...[with rigs] needed to work satellites, ROBOT 1200C's costing a BM> fortune when you can get them for SSTV, WEFAX APT equipment costing BM> a few hundred, etc, it has just gotten too expensive for a ham to BM> `do it all' with individual pieces of equipment... <sigh> All too true.73 de Brian Battles, WA1YUA * HAM RADIO & PACKET Echo ModeratorQTH New Britain, Conn.Packet: WA1YUA @ N1API... Someday my ham radio may save your life!--- Via Silver Xpress V2.24 (1:141/880) Brian Battles, WA1YUA - via FidoNet node 1:141/880UUCP: ...!ncar!asuvax!stjhmc!w8grt!880!141!1!brian.battlesINTERNET: brian.battles@f880.n141.z1.fidonet.org--------------------------- ---Date: Tue, 1 May 90 8:44:39 PDTFrom: Peter Dahl <pdahl@milton.u.washington.edu>Subject: New Packet Stuff @ Dayton??To: packet-radio@ucsd.eduI have not yet seen a list of the new packet related equipment that was introduced at Dayton last weekend. Can anyone who wasthere or has heard a report on this supply us with this info?CURIOUS MINDS WANT TO KNOW! 73 de Peter, WA7FUS------------------------------Date: Wed, 2 May 90 09:39 NFrom: Urs Baer <BWLLIBMOD%CSGHSG5A.BITNET@CUNYVM.CUNY.EDU>Subject: Packet-Radio Digest V1 #14To: Packet-Radio@UCSD.Eduplease remove my old adress 87674800s@csghsg5a.bitnet from this list!!!------------------------------End of Packet-Radio Digest******************************Date: Thu, 3 May 90 04:00:04 PDTFrom: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #16To: packet-radioPacket-Radio Digest Thu, 3 May 90 Volume 90 : Issue 16Today's Topics: faster modems frustration Full Duplex packet on 2 meters? Hams in space Packet in Cincinnati, OH? TNC2 1.1.7 Code Undeliverable messageSend Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 2 May 90 16:56:32 GMTFrom: thumper!karn@bellcore.com (Phil R. Karn)Subject: faster modemsTo: packet-radio@ucsd.eduIn article <2049@rsiatl.UUCP> jgd@rsiatl.UUCP (John G. De Armond) writes:>As I recall,>the new language puts both a baudrate and a bps limit on everthing below>440.I think you're referring to a typo in the rules rewrite that did indeedmove the limit for wideband packet up to 420 MHz. This was not the intentionof the FCC, and in fact it was fixed in an errata ruling.Phil------------------------------Date: Wed, 2 May 90 23:10:23 MSTFrom: sarrel%miranda.uucp@moc.Jpl.Nasa.Gov (Marc Sarrel)Subject: frustrationTo: packet-radio@ucsd.eduI've been trying to monitor some packet traffic, but without muchsuccess. A own MacRATT, a PK-232MBX and a TH-225A. What happens isthat I can see the DCD light go on and off and see the Mark and SpaceLED's go back and forth, but only rarely does the contents of thepackets get printed. The curious part is that the MHEARD list isconstantly being updated as though packets are being received. I'llspare the net the rest of the details. If you have any ideas, send meemail.advTHANKSance--marc-=-Marc A. SarrelN7OLIsarrel%miranda.uucp@moc.jpl.nasa.gov | "Oh, _lightweight_ Alpaca..."..!sun!sunburn!miranda!sarrel | -Blanche DuBoisNSA fodder:strategic, Treasury, Narco Terrorist, assassination, room temperaturesuperconductor.------------------------------Date: 2 May 90 20:10:47 GMTFrom: rsiatl!jgd@uunet.uu.net (John G. De Armond)Subject: Full Duplex packet on 2 meters?To: packet-radio@ucsd.edupdahl@MILTON.U.WASHINGTON.EDU (Peter Dahl) writes:> Is anyone operating dual frequency, full duplex packet nodes on>2 meters on frequencies other than coordinatable/bandplan repeater pairs?>How about 145.01/145.61? How do you interpret the fcc rules on this one?>145.61 is in an area where repeaters are supposedly not permitted but is a full>duplex packet node a repeater as we have come to know repeaters? TheThe new rules specifically prohibit full duplex, repeater-like serviceacross those splits. Sad but true.John-- John De Armond, WD4OQC | We can no more blame our loss of freedom on congressRadiation Systems, Inc. | than we can prostitution on pimps. Both simplyAtlanta, Ga | provide broker services for their customers.{emory,uunet}!rsiatl!jgd| - Dr. W Williams | **I am the NRA** ------------------------------Date: Wed, 02 May 90 23:39:09 PDTFrom: KEVIN%CALSTATE.BITNET@CORNELLC.cit.cornell.eduSubject: Hams in spaceTo: packet-radio@wsmr-simtel20.army.milI posted a query a few days ago about a space shuttle flight on which a ham opwoold be using 2-way packet communications. I received no answers (possiblybecause the internet address in my .sig was dead...) So I will ask again, andadd what little I do know, taken from May 1990 QST.Quote:The Shuttle Amateur Radio Experiment #2 (SAREX-2) packet radio station recentlyunderwent testing at the Marshall Space Flight Center in Huntsville, Alabama,with assistance from area hams. The packet radio station flying on space shuttle mission STS-35 willgive each amateur who connects to WA4SIR a QSO number confirming the contact.More than 550 teachers, parents, and Amateur Radio clubs assisting schools havecontacted the ARRL Educational Activities Department for details on making acontact with the shuttle crew. This is a great opportunity for showing the excitexcitment of Amateur Radio to our youth! QSL cards will be available. The FCC has granted Payload Specialist Ron Parise, WA4SIR, a waiver touse his call sign for a space station aboard STS-35 to be launched May 9, 1990.Teachers can obtain shuttle locators from the ARRL Educational Activities De-partment by sending a 9- x 12-inch envelope with 45 cents postage affixed.End Quote.Questions!: What frequency! What frequency! What frequency!? Can *I* contact this guy using my silly antenna made out of coathangers and5 watts of power on VHF? How do I know when the shuttle is audible? (I know -- listen for it. I meanhow do I predict?) What frequency?!I am not a parent, teacher, or club, and (besides) I doubt I'd get any meaning-ful info from the ARRL before the 9th anyway. All help appreciated. Kevin Savetz The .sig is right this time.... vvvvvvv+----------------------------------------+ DISCLAIMER: I assume no: KEVIN M. SAVETZ - KC6GWQ : responsibility for any messages: Bitnet: kevin@calstate.BITNET : that I post, expressed or: Internet: gpr001f@ccs.calstate.edu : implied. Opinions expressed: Fishnet: salmon@smoked.poached.fried : by me are not necessarily+----------------------------------------+ my own. -30-------------------------------Date: 2 May 90 22:13:32 GMTFrom: ius3.ius.cs.cmu.edu!ralphw@pt.cs.cmu.edu (Ralph Hyre)Subject: Packet in Cincinnati, OH?To: packet-radio@ucsd.eduMoved from urban area in Pittsburgh, PA (plenty of stations) to Milford, OH (near Cincinnati, OH) and I'm having more difficulty contacting stations. I can hear W8YS and KY8T (sp?) in PASSALL mode (I would expect errors, LebanonOH (home of W8YS) is 30 miles away, I don't know where the other station is.)Does anyone know how the Cincinnati WAN is organized? Where else should I lookbesides 145.0{1,3}.I'm ready to break out my 10M rig and go HF.Thanks. - Ralph N3FGW-- - Ralph W. Hyre, Jr.internet: ralphw@ius3.cs.cmu.edu AMPRnet: in transitionapplelink: am0005 (attn: Ralph Hyre) (user to be n3fgw@w2xo)------------------------------Date: 2 May 90 14:34:36 GMTFrom: hpcc01!col!bdale@hplabs.hp.com (Bdale Garbee)Subject: TNC2 1.1.7 CodeTo: packet-radio@ucsd.edu>Have TAPR made the new 1.1.7 TNC2 Code available for download yet ?No. You really want a copy of the new manual that is shipping with 1.1.7. Call TAPR and order a copy, it's cheap.TAPRPO Box 12925Tucson, AZ 85732(602) 323-1710Bdale------------------------------Date: 02 May 90 09:37:20 EDTFrom: Electronic Postmaster <POSTMASTER@CompuServe.COM>Subject: Undeliverable messageTo: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>Re: ? EMDITB - Mail Delivery Failure. Message too large. >EPX [70645,247]Packet-Radio Digest V1 #15Your message could not be delivered as addressed.--- Returned message ---Received: from ucsd.edu by saqqara.cis.ohio-state.edu (5.61-kk/5.900430) id AA01840; Wed, 2 May 90 08:56:29 -0400Received: by ucsd.edu; id AA09832 sendmail 5.61/UCSD-2.0-sun Wed, 2 May 90 04:00:17 -0700 for brianReceived: by ucsd.edu; id AA09827 sendmail 5.61/UCSD-2.0-sun Wed, 2 May 90 04:00:14 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-listMessage-Id: <9005021100.AA09827@ucsd.edu>Date: Wed, 2 May 90 04:00:04 PDTFrom: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #15To: packet-radio@cis.ohio-state.eduPacket-Radio Digest Wed, 2 May 90 Volume 90 : Issue 15Today's Topics: DOVE TELEMETRY DATA.... here is how. Failed Mail (8 msgs) faster modems Full Duplex packet on 2 meters? (3 msgs) Higher speeds New Packet Stuff @ Dayton?? Packet-Radio Digest V1 #14Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 1 May 90 15:38:48 GMTFrom: swrinde!zaphod.mps.ohio-state.edu!sunybcs!uhura.cc.rochester.edu! rochester!kodak!ektools!kinsman@ucsd.edu (Andrew A. Kinsman)Subject: DOVE TELEMETRY DATA.... here is how.To: packet-radio@ucsd.eduSpacecraft: DOVE-1: Rev: 1 Date: 1/7/90 Equations are in the form: Y = A*N^2 + B*N + C where: N = Telemetry Count (00 - FF) A, B, C = Equation Coefficients Y = Result (In Specified Units)HEX Descripion: C: B: A: Units: cccccccccc bbbbbbbbbb aaaaaaaaaa uuuuuu 0 Rx E/F Audio(W)+0.000 +0.0246 0.000 V(p-p) 1 Rx E/F Audio(N)+0.000 +0.0246 0.000 V(p-p) 2 Mixer Bias V: +0.000 +0.0102 0.000 Volts 3 Osc. Bisd V: +0.000 +0.0102 0.000 Volts 4 Rx A Audio (W):+0.000 +0.0246 0.000 V(p-p) 5 Rx A Audio (N):+0.000 +0.0246 0.000 V(p-p) 6 Rx A DISC: +10.427 -0.09274 0.000 kHz 7 Rx A S meter: +0.000 +1.000 0.000 Counts 8 Rx E/F DISC: +9.6234 -0.09911 0.000 kHz 9 Rx E/F S meter:+0.000 +1.000 0.000 Counts A +5 Volt Bus: +0.000 +0.0305 0.000 Volts B +5V Rx Current:+0.000 +0.000100 0.000 Amps C +2.5V VREF: +0.000 +0.0108 0.000 Volts D 8.5V BUS: +0.000 +0.0391 0.000 Volts E IR Detector: +0.000 +1.000 0.000 Counts F LO Monitor I: +0.000 +0.000037 0.000 Amps10 +10V Bus: +0.000 +0.05075 0.000 Volts11 GASFET Bias I: +0.000 +0.000026 0.000 Amps12 Ground REF: +0.000 +0.0100 0.000 Volts13 +Z Array V: +0.000 +0.1023 0.000 Volts14 Rx Temp: +101.05 -0.6051 0.000 Deg. C15 +X (RX) temp: +101.05 -0.6051 0.000 Deg. C16 Bat 1 V: +1.7932 -0.0034084 0.000 Volts17 Bat 2 V: +1.7978 -0.0035316 0.000 Volts18 Bat 3 V: +1.8046 -0.0035723 0.000 Volts19 Bat 4 V: +1.7782 -0.0034590 0.000 Volts1A Bat 5 V: +1.8410 -0.0038355 0.000 Volts1B Bat 6 V: +1.8381 -0.0038450 0.000 Volts1C Bat 7 V: +1.8568 -0.0037757 0.000 Volts1D Bat 8 V: +1.7868 -0.0034068 0.000 Volts1E Array V: +7.205 +0.07200 0.000 Volts1F +5V Bus: +1.932 +0.0312 0.000 Volts20 +8.5V Bus: +5.265 +0.0173 0.000 Volts21 +10V Bus: +7.469 +0.021765 0.000 Volts22 BCR Set Point: -8.762 +1.1590 0.000 Counts23 BCR Load Cur: -0.0871 +0.00698 0.000 Amps24 +8.5V Bus Cur: -0.00920 +0.001899 0.000 Amps25 +5V Bus Cur: +0.00502 +0.00431 0.000 Amps26 -X Array Cur: -0.01075 +0.00215 0.000 Amps27 +X Array Cur: -0.01349 +0.00270 0.000 Amps28 -Y Array Cur: -0.01196 +0.00239 0.000 Amps29 +Y Array Cur: -0.01141 +0.00228 0.000 Amps2A -Z Array Cur: -0.01653 +0.00245 0.000 Amps2B +Z Array Cur: -0.01137 +0.00228 0.000 Amps2C Ext Power Cur: -0.02000 +0.00250 0.000 Amps2D BCR Input Cur: +0.06122 +0.00317 0.000 Amps2E BCR Output Cur:-0.01724 +0.00345 0.000 Amps2F Bat 1 Temp: +101.05 -0.6051 0.000 Deg. C30 Bat 2 Temp: +101.05 -0.6051 0.000 Deg. C31 Baseplt Temp: +101.05 -0.6051 0.000 Deg. C32 FM TX#1 RF OUT:+0.0256 -0.000884 +0.0000836 Watts33 FM TX#2 RF OUT:-0.0027 +0.001257 +0.0000730 Watts34 PSK TX HPA Temp+101.05 -0.6051 0.000 Deg. C35 +Y Array Temp: +101.05 -0.6051 0.000 Deg. C36 RC PSK HPA Temp+101.05 -0.6051 0.000 Deg. C37 RC PSK BP Temp:+101.05 -0.6051 0.000 Deg. C38 +Z Array Temp: +101.05 -0.6051 0.000 Deg. C 39 S band TX Out: -0.0451 +0.00403 0.000 Watts3A S band HPA Temp+101.05 -0.6051 0.000 Deg. CADC Equations: V = 0.01028 N - 0.05138 N = 97.31 V +5.000------------------------------Date: Tue May 01 12:04:23 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Mon Apr 23 21:18:56 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 12:03:53 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa05949; 23 Apr 90 21:16 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id fb09731; 23 Apr 90 19:29 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id ae16278; 23 Apr 90 19:34 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa16248; 23 Apr 90 19:26 BST> Received: by ucsd.edu; id AA10927> sendmail 5.61/UCSD-2.0-sun> Sat, 21 Apr 90 04:00:07 -0700 for brian> Received: by ucsd.edu; id AA10914> sendmail 5.61/UCSD-2.0-sun> Sat, 21 Apr 90 04:00:05 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004211100.AA10914@ucsd.edu>> Date: Sat, 21 Apr 90 04:00:02 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #3> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Sat, 21 Apr 90 Volume 90 : Issue 3> > Today's Topics:> Fixmail 1.09 now posted :128.104.198.22> Innovators need thick skin (was: CP/M sofware...)> KISS Mode -- How Fast? (2 msgs)> Microwave oscillator sources (3 msgs)> USENET at Dayton Hamvention> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: Fri, 20 Apr 90 08:09:59 GMT> From: pat@pgd.adp.wisc.edu (Pat Davis)> Subject: Fixmail 1.09 now posted :128.104.198.22> To: packet-radio@ucsd.edu, tcp-group@ucsd.edu> > Fixmail 1.09 is posted on pgd.adp.wisc.edu for anonymous FTP.> 1.09 fixes a bug that would allow FIXMAIL to END/TERMINATE if/when there> was no more mail to censor.. That's right, censor.. Fixmail,> by Bryan HI-Q Biggers N9GBJ, manages SMTP mail from NET/NOS. It has some> very attractive features. FIXMAIL is Desqview "aware"..> > The file you want is FIXM109.ZIP, you might find more helpful files in> FIXM106.ZIP too...> > KD9UU> > ------------------------------> > Date: 20 Apr 90 16:18:00 GMT> From: att!cbnewsh!n2dsy@ucbvax.Berkeley.EDU (j.gordon.beattie)> Subject: Innovators need thick skin (was: CP/M sofware...)> To: packet-radio@ucsd.edu> > > First and foremost, plain old AX.25 text streams will be with us for> > a long, long time. Its the lowest common denominator for just about all of > > amateur packet radio. It is also the simplest packet "mode" to understand:> > just "CONNECT" and off you go. Given these two facts, I claim that plain> > old AX.25 text streams are and will continue to be the most popular "mode".> > I can agree with this point that the simple "CONNECT and go" user (POATS user)> is, and will be the major user type in the packet network for a long time > to come.> > I would just like to point out that the ROSE X.25 Switch software > supports "POATS" users simply by appearing to the user as a pair> of digipeaters. There's no extra user hardware or software to > buy/install/configure/hassle-with to use a ROSE X.25 network. > > In fact, the ROSE X.25 Switch will route you through the network without> the hassle that the NoNodes put you through of "connect, connect,> connect..connect, voila..the destination!" This is somewhat akin> to asking a sequence of "n" telephone operators to route your > telephone call...computers do a better job of this in less time!> > As far as interoperability goes, you can call between a NoNodes> network and a ROSE X.25 network by simply connecting using the> standard connection method for either network (C Destination v ...).> > TCP/IP is no problem to a ROSE X.25 network either: just make > a level 2 call through a ROSE X.25 network (like any POATS user)> and send your IP datagrammes through the network...simple!> > In any case, I'd like to see more integration of networks, but> let's first realize that simplicity of a tool (or a network)> can often be the most attractive feature to users.> > 73,> Gordon Beattie, n2dsy> n2dsy@hou2d.att.com> +1.201.615.4168> > ------------------------------> > Date: 20 Apr 90 01:16:22 GMT> From: bionet!hayes!usenet@apple.com> Subject: KISS Mode -- How Fast?> To: packet-radio@ucsd.edu> > I have one of the April 90 versions of NOS running on two different> PC compatibles. I can't seem to communicate reliably faster than 4800> baud. One machine is a 12 MHZ 286 with an 8250B. The other machine is a> laptop with a 4.77 MHz 80C88 and I presume the ASIC equivalent of an 8250.> Hardwired connection between the two machines with KISS mode at 4800 baud> seems reliable but 9600 baud is very spotty.> > Now the interesting thing is that the 286 machine is known to operate> to at least 38400 with an unsophisticated interrupt routine written in Turbo> Pascal. The laptop operates well at 9600 baud with various terminal emulators.> Why is NOS slower and what can I do about it? The 8250B in the 286 machine> is socketed but there is little I can do with the laptop, which is probably> the culprit. Mostly I want to know how fast can I run KISS mode on the 286> machine.> > The reason I bring this up is that I am working on a 2 chip packet> assembler/disassembler that is good to 1 Mbps (half-duplex) but I need a> decently fast way to interface it to the host computer. 4800 baud isn't> good enough.> > Philip Munts N7AHL> University of Alaska, Fairbanks> > ------------------------------> > Date: 21 Apr 90 05:47:43 GMT> From: ka9q.bellcore.com!karn@bellcore.com (Phil Karn)> Subject: KISS Mode -- How Fast?> To: packet-radio@ucsd.edu> > In article <1990Apr20.022915.8287@hayes.fai.alaska.edu> ftpam1@acad3.fai.alaska.edu writes:> > > I have one of the April 90 versions of NOS running on two different> >PC compatibles. I can't seem to communicate reliably faster than 4800> >baud.> > Fetch the latest stuff off flash.bellcore.com using anonymous ftp and> give it a try. If it isn't any better, let me know. I've been doing some> work on the 8250/16550 driver lately that should help improve performance> and I want to make sure that I haven't already fixed your problem before> looking at it again.> > Phil> > ------------------------------> > Date: 20 Apr 90 14:04:33 GMT> From: rochester!rit!cci632!dvh@rutgers.edu (David Hallidy)> Subject: Microwave oscillator sources> To: packet-radio@ucsd.edu> > In article <871@tsdiag.ccur.com>, davet@tsdiag.ccur.com (Dave Tiller N2KAU) writes:> > > > Has anyone had any experience with converting a microwave oven > > magnetron to Amateur use? Are there any problems with needing to> > 'bend' it down slightly from 2.450 GHz to make it into the Ham> > band? What are the power requirements? I noticed that MCM sells> > replacement magnetrons - could this be a source for cheep packet> > backbone oscillators? Inquiring minds gots'ta know...Any help> > would be greatly appreciated.> > > > PS - I don't intend to run one of these at ~600-1200 Watts aimed> > at the general public. A couple of Watts (<10) would be more> > resonable.> > Dave-> > Check out _RF DESIGN_ for March of 1989, there was an article about> using a microwave oven as a high powered RF source for 2450 MHz> ATV. It will work down into the ham band at the upper end of the> "13cm" segment- from 2390 to 2450 MHz. Problem is, I don't think> the stability of the mag will be very good- this may not be critical> in your application, certainly for wideband TV experimenting it's> probably not too important.> > The other problem is, you mentioned wanting to run low power- I> don't think you can with this type of setup. A magnetron, by its> nature, generates high levels of RF. It's a self excited device, and> if you try to just "lower the voltage" or reduce the intensity of> the magnetic field around the tube, it just won't oscillate. The way> the microwave ovens run at "reduced" power is to turn the tube on> and off for varying periods of time- this has the effect, on food,> of reducing the heating by reducing the amount of time the food is> exposed to the RF. The level of RF when the mag is running is always> at full power (>600 Watts, usually).> > I do think it might be worthwhile to experiment with injection-locking> of the magnetron to stabilize its output frequency. This would make> for a very cheap source of extremely high power on the band, useable> for modes other than wideband TV. Let me know if you try any of this> and any success (or failure) you may have.> > Hope this helps you some.> > 73 Dave H. KD5RO/2> > ------------------------------> > Date: 20 Apr 90 20:01:56 GMT> From: swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!t urnkey!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.c om!dana@ucsd.edu (Dana H. Myers)> Subject: Microwave oscillator sources> To: packet-radio@ucsd.edu> > In article <871@tsdiag.ccur.com> davet@tsdiag.ccur.com (Dave Tiller N2KAU) writes:> >> >Has anyone had any experience with converting a microwave oven > >magnetron to Amateur use? Are there any problems with needing to> >'bend' it down slightly from 2.450 GHz to make it into the Ham> >band? What are the power requirements? I noticed that MCM sells> >replacement magnetrons - could this be a source for cheep packet> >backbone oscillators? Inquiring minds gots'ta know...Any help> >would be greatly appreciated.> > Look in the 1989 index for 73 magazine - a cover article detailed> conversion of a surplus oven to ATV/FM use, a $200 700W exciter !> I'll try to get the date or possibly someone else can post it.> > > ***************************************************************** > * Dana H. Myers WA6ZGB | Views expressed here are *> * (213) 337-5136 | mine and do not necessarily *> * dana@locus.com | reflect those of my employer *> ***************************************************************** > > ------------------------------> > Date: 21 Apr 90 02:15:45 GMT> From: usc!pollux.usc.edu!kjh@ucsd.edu (Kenneth J. Hendrickson)> Subject: Microwave oscillator sources> To: packet-radio@ucsd.edu> > In article <871@tsdiag.ccur.com> davet@tsdiag.ccur.com (Dave Tiller N2KAU) writes:> >Has anyone had any experience with converting a microwave oven > >magnetron to Amateur use?> > It's already been done. Somebody in Illinois did it on ATV. There was> a skimpy write-up about it in one of the RF trade rags about Fall of> '88. I can't remember which magazine, but I think it might have been> "RF & Microwaves". Don't waste your time looking for the magazine,> however, there wasn't any more information in it than I have posted> here. It was kind of like the ARRL's current publication of microwave> information in QST.> > Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh> > ------------------------------> > Date: 20 Apr 90 02:34:52 GMT> From: usc!cs.utexas.edu!execu!sequoia!attdso!ssc!tad@ucsd.edu (Tad Cook)> Subject: USENET at Dayton Hamvention> To: packet-radio@ucsd.edu> > Just ONE more reminder. . . .If you are going to the Dayton Hamvention,> USENET folks will be getting together at Stouffers on Friday night in> suite 425, at the DIGITAL SUITE. Stouffers is downtown at Fifth and> Jefferson.> > See you there!> > > Tad Cook> Seattle, WA> Packet: KT7H @ N7HFZ.WA.USA.NA> Phone: 206/527-4089 > MCI Mail: 3288544 > Telex: 6503288544 MCI UW > USENET:...uw-beaver!sumax!amc-gw!ssc!tad> or, tad@ssc.UUCP> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 12:08:24 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Mon Apr 23 23:52:08 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 12:07:58 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa12342; 23 Apr 90 23:50 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id rp09731; 23 Apr 90 22:11 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id ab18786; 23 Apr 90 20:36 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa18731; 23 Apr 90 20:32 BST> Received: by ucsd.edu; id AA14795> sendmail 5.61/UCSD-2.0-sun> Mon, 23 Apr 90 04:00:07 -0700 for brian> Received: by ucsd.edu; id AA14783> sendmail 5.61/UCSD-2.0-sun> Mon, 23 Apr 90 04:00:04 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004231100.AA14783@ucsd.edu>> Date: Mon, 23 Apr 90 04:00:02 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #5> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Mon, 23 Apr 90 Volume 90 : Issue 5> > Today's Topics:> Has NOS been ported to the Atari ST?> TAPR TNC-2 for sale> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 23 Apr 90 01:34:39 GMT> From: swrinde!zaphod.mps.ohio-state.edu!samsung!umich!pmsmam!pmsmam.uuc p!wwm@ucsd.edu (Bill Meahan)> Subject: Has NOS been ported to the Atari ST?> To: packet-radio@ucsd.edu> > The subject line says it all.> > If not, why not? Micro-RTX could easily provide the requisite multi-tasking> kernel if the one that's included in the NOS source isn't suitable.> > We ST users wait with bated breath! (especially we who still have older> 520's :-) :-} )> -- > Bill Meahan | UUCP: uunet!mailrus!umich!pmsmam!wwm> | snail: 128 Factory St., Ypsilanti, MI 48197> #include <disclaimer.std> | voice: +1 313 484 9320> /* witty */ |packet: wa8tzg @ wa8ooh.mi.usa.na> > ------------------------------> > Date: 22 Apr 90 06:54:54 GMT> From: sumax!ole!ray@beaver.cs.washington.edu (Ray Berry)> Subject: TAPR TNC-2 for sale> To: packet-radio@ucsd.edu> > I have a TAPR TNC-2 built from a kit several yrs back I'd like to> sell. It was built and tested, aligned, etc., but never used. The firmware> is at whatever level existed at the time the TNC-2 first shipped. > I'd like $100 for this thing. I've never been active in packet,> so I don't know if this thing is already obsolete or what... if the price > sounds too high, please make an offer. Thanks.> -- > Ray Berry kb7ht uucp: ...ole!ray CIS: 73407,3152 /* "inquire within" */> Seattle Silicon Corp. 3075 112th Ave NE. Bellevue WA 98004 (206) 828-4422> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 12:15:30 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Tue Apr 24 06:54:29 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 12:15:03 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa00189; 24 Apr 90 6:50 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id fm22320; 24 Apr 90 4:59 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id ax28088; 24 Apr 90 3:19 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa27762; 24 Apr 90 2:13 BST> Received: by ucsd.edu; id AA26011> sendmail 5.61/UCSD-2.0-sun> Sun, 22 Apr 90 04:00:08 -0700 for brian> Received: by ucsd.edu; id AA25993> sendmail 5.61/UCSD-2.0-sun> Sun, 22 Apr 90 04:00:04 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004221100.AA25993@ucsd.edu>> Date: Sun, 22 Apr 90 04:00:02 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #4> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Sun, 22 Apr 90 Volume 90 : Issue 4> > Today's Topics:> Innovators need thick skin> Microwave oscillator sources> Packet-Radio Digest V1 #3> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 21 Apr 90 22:42:34 GMT> From: sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!k d4nc!ke4zv@ucsd.edu (Gary Coffman)> Subject: Innovators need thick skin> To: packet-radio@ucsd.edu> > In article <22370@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes:> >> >But be that as it may, you are getting somewhat closer to the truth. As> >I said before, TCP/IP has little to offer unless you have a computer.> > WORDS TO LIVE BY! I would also add that packet in general has little to> offer unless you have a computer. Contentless keyboard QSOs crawling> through the network have little value after the thrill of doing it once> wears off.> The real value of packet radio is connecting computers together in a> network to perform a useful function. Things like Email, Remote File> Sharing, and distributed computing are possible only with reliable> end to end data transfer. Our current slow network already carries> an important amount of Email. MUCH faster networks will make the other > things realistic. And there's the rub, little Terminal Node Controllers> aren't capable of supporting faster modems. In fact, TERMINAL Node> Controller is a concept whose time is past. It's time to return to> the PAD (Packet Assembler Disassembler) now that it is a single chip> (8530) in the computer and attach that to a truly high speed modem.> High speed modems are available and affordable NOW at 56kb and soon> at megabit rates. > > LET'S NOT FALL INTO THE TRAP OF HITCHING OURSELVES TO THE DEAD PAST> WITH A NETWORK DESIGN THAT CANNOT EASILY MIGRATE TOWARD OUR ULTIMATE> GOALS.> > Gary KE4ZV> > ------------------------------> > Date: 20 Apr 90 00:27:03 GMT> From: snorkelwacker!bu.edu!mirror!otto!jimi!unsvax!storkus@think.com (Mike Storke (N7MSD))> Subject: Microwave oscillator sources> To: packet-radio@ucsd.edu> > I'd also be very interested in knowing if you can convert a microwave oven> magnetron to amateur bands. Unlike the guy who originated this, I *WOULD* use> it at or near it's full rated power. This would be used for long-haul packet> links (~200+ miles, to be exact: Las Vegas-Bishop, California-Reno; a 2M link> currently exists along this route, but it's too loaded down). Any info would> be appreciated. Note that these links are all on top of mountains > 8500 ft.> high. Thanks and 73's, Mike, N7MSD> P.S. I got a hold of a surplus house that has traveling wave tubes for 2-4 gigs> and 8-9.6 gigs. Can the 8-9.6 be used at the 10 gig ham band? A friend of> mine said no because they are *very hard* to tune-he says they're something> like a helical antenna at their center frequency. Any info appreciated as> always, Mike> > ------------------------------> > Date: Sat, 21 Apr 90 22:31 EST> From: LARRY KNEHR <CSCON104@uoft02.utoledo.edu>> Subject: Packet-Radio Digest V1 #3> To: Packet-Radio@UCSD.EDU> > > > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 12:36:08 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Tue Apr 24 15:44:27 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 12:35:53 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa02220; 24 Apr 90 14:55 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id al06530; 24 Apr 90 11:49 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id ab11817; 24 Apr 90 13:04 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa11692; 24 Apr 90 13:00 BST> Received: by ucsd.edu; id AA20953> sendmail 5.61/UCSD-2.0-sun> Tue, 24 Apr 90 04:00:13 -0700 for brian> Received: by ucsd.edu; id AA20939> sendmail 5.61/UCSD-2.0-sun> Tue, 24 Apr 90 04:00:10 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004241100.AA20939@ucsd.edu>> Date: Tue, 24 Apr 90 04:00:06 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #6> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Tue, 24 Apr 90 Volume 90 : Issue 6> > Today's Topics:> Apple II Software for RTTY and Facsimile ?> faster modems> Getting Started!?> MFJ 1274 TNC for sale> pulse on X-band (2 msgs)> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 23 Apr 90 15:29:50 GMT> From: ncs.dnd.ca!asterix.drev.dnd.ca!louis@rutgers.edu (Louis Demers)> Subject: Apple II Software for RTTY and Facsimile ?> To: packet-radio@ucsd.edu> > (I am posting this for a collegue, hope this is the right place)> > A friend is looking for software for his Apple II+ to receive> Facsimile (he already has the interface to his radio) for example> of wheather maps. He would like also a piece of software that > implements the RTTY protocol.> > If software is unavailable, we would settle for the algorytms.> > Please respond through Email as this site doesn't receive any of the> rec. groups.> > PPS: Please don't laugh, this is all foreign to me.> -- > | Louis Demers | DREV, Defence Research Establishment,Valcartier |> | louis@asterix.drev.dnd.ca | POBox 8800, Courcelette,Quebec, CANADA, G0A 1R0 |> | (131.132.48.2) | Office: (418) 844-4424 fax (418) 844-4511 |> +---------------------------+------------------------------------ -------------+> > ------------------------------> > Date: Mon, 23 Apr 90 14:34:34 MST> From: sarrel%miranda.uucp@moc.Jpl.Nasa.Gov (Marc Sarrel)> Subject: faster modems> To: packet-radio@ucsd.edu> > Well, there has been some discussion recently here about how most hams> with TNCs are using horribly outdated and slow equipment. 1200 baud> seems to be the lowest common denominator. And, sometimes I get the> feeling that some hams don't have much desire or incentive to move to> higher baud rates. In fact, I spent a while talking to the "packet> expert" at a local amateur radio store recently. I asked him about> some TNC that had a 2400 baud modem vs one that had a 1200 baud modem.> I asked wether 2400 would catch on, given my experience with land line> modems where everyone was starved for speed. He said "no." His> reasons seemed pretty fuzzy to me, but he seemed to claim that 1) 2400> baud wouldn't catch on because everyone already has 1200 baud modems,> 2) 1200 baud seemed fast enough to him, and 3) that 2400 baud wasn't> _really_ twice as fast as 1200 because the extra speed was used> inefficiently. (But don't hold me to that, this was a while ago.)> > Anyway, my question is this: How can we "hams in the know" encourage> the use of faster and more effecient modems on the airwaves, given> that we agree that "faster is better." One of this guy's arguments> holds weight in that there is a lot of "hardware inertia" out there.> > Specifically what kind of faster and more efficient modems are> available and suitable for packet-radio? How fast is fast? 9600?> 19.2K? 56K? How much extra bandwidth do these faster modems require?> What about FCC regulations on speed?> > Is there such a thing as auto baud rate recognition that would allow a> digipeater to work a several different speeds with different stations> on the same frequency? This would allow a smoother transition to> faster modems by giving people incentive to buy them without> immediately obsoleting everyone's 1200 baud equipment?> > Would it be a good idea to set up digipeaters that work on several> different speeds (and frequencies) as a way of encouraging higher baud> rates?> > Just curious,> > --marc> -=-> Marc A. Sarrel> N7OLI> sarrel%miranda.uucp@moc.jpl.nasa.gov | "Oh, _lightweight_ Alpaca..."> ..!sun!sunburn!miranda!sarrel | -Blanche DuBois> > ------------------------------> > Date: 23 Apr 90 08:32:11 GMT> From: usc!sdsu!crash!jburnes@ucsd.edu (Jim Burnes)> Subject: Getting Started!?> To: packet-radio@ucsd.edu> > Hi!> > A friend of mine and I want to get into packet radio. We are not hams.> We are willing to jump through the necessary hoops. We both are software/> hardware engineers and understand various amounts of circuit theory.> We would like to know:> > 1. What is the highest speed modem usable on standard packet frequen-> cies? I have heard of 9600 bps modems being used. What about> Telebit Trailblazer spread-spectrum type modems?> > 2. What class of ham liscense is necessary to run packet? What tests> and theory must we have to get this liscense?> > 3. How much would a rig capable of 2400 bps operation cost (used)?> I already have a 386 machine. I would like to upgrade to national/> international coverage (if that is applicable) and also to higher> speeds.> > 4. I have heard that you cant upload messages/files to someones node> and then have that information automatically forwarded through> a network. Someone told me humans had to intervene. That sounded> silly. Kinda defeats the whole purpose of a network, no? Sorry..> since I'm mostly a pc hacker I not quite sure how to ask a lot of> questions without sounding naive.> > 5. What is a good book to get started with?> > 6. It seems like I have been trying to get into packet/ham for the last> 5 years or so and always fail to clear the morse/test hurdles. I'd> like to remedy this as soon as possible. Any ideas for making the > transition easier?> > Yours in communications,> Jim Burnes> > -------------------> I do not beleive in 'isms> I think, on the whole, 'isms are a bad thing> > Ferris Buehler (paraphrased)> --------------------> > ------------------------------> > Date: 24 Apr 90 00:53:37 GMT> From: psuvm!mls129@psuvax1.cs.psu.edu (Michael L. Sensor)> Subject: MFJ 1274 TNC for sale> To: packet-radio@ucsd.edu> > For sale once again:> > MFJ 1247 HF/VHF TNC. Almost never used (yes it works).> > LED tuning display. Compatible with MFJ WeFAX software (for PCs and> Macintoshes). Personal mailbox.> > Comes with 5-lead RS232 cable and homebrew connector to use on Icom IC2AT.> > Bought for $150.00 at Dayton. Asking $125.00. May trade or bargain.> > For more info:> > Mike Sensor KD3LR / AFA1UP> Box 134 Oak Hall> Penn State Altoona Campus> Altoona PA 16601-3760> (814) 949-5439> UNTIL MAY 4!> > 2406 E 32 St> Erie PA 16510-2702> (814) 899-8261> AFTER MAY 4!> > C'mon, MFJ isn't *that* bad!> > Mike Sensor MLS129 @ PSUVM> > ------------------------------> > Date: 24 Apr 90 01:28:17 GMT> From: usc!pollux.usc.edu!kjh@ucsd.edu (Kenneth J. Hendrickson)> Subject: pulse on X-band> To: packet-radio@ucsd.edu> > I received some email from W3OTC that I responded to, and thought a> posting would be appropriate. Here it is:> > % From: Robert Carpenter <rc%cmr.ncsl.nist.gov@usc.edu>> > % Am I missing something? It seemed to me that you wouldn't benefit from a> % low duty cycle when fighting a large path loss. I would think that some> % synchronous system, with correlation detection of some sort, would be the> % best bet. Of course you COULD build a receiver that just listened during> % the narrow pulses to ignore the in-between noise. I'd also worry a bit> % about pulse-spreading due to multipath. Maybe a pseudo-random scheme would> % be a good approach, but would likely have a mid-to-high duty cycle, and thus> % not be pulse.> > It is a possibility to build a receiver that only listens when a pulse> is supposed to occur, but that wasn't necessarily what I was thinking> about. The advantage of using the high peak power of a pulse is that it> would be EASILY DETECTABLE even with high path loss. This means that> (in theory) you could set up a data link much like CW is used with the> human ear: the presence of a pulse has one meaning, and the absence of a> pulse has another. There is probably even a better way to do it:> consider what you could do if you were to phase modulate the pulses. In> other words, control the time delay or latency between pulses. A short> time delay could mean a 0 bit, and a long delay could mean a 1 bit.> > % Or do you have a good source of low duty cycle 10 GHz power, and want to> % build a system around it?> > No, I don't have a 10 GHz pulse source, but they are available. Now if> we could only use them legally ...> > % Pardon the confused questions, but I don't normally think of low-duty-cycle> % pulse transmission and weak signal operation as going together.> > Most people don't. Certainly, I'm not suggesting that real time> communications like voice be sent this way. I'm merely proposing that> this might be a good use for part of our microwave spectrum. The packet> guys are in great need of high-speed inter-city links (among other> things).> > % Bob W3OTC> > % PS. Look at the picture of the 10 GHz SSB PHONE station in QST (I thought in> % W3XO's column, but can't find it.) I've seen and heard '3XO's video of it> % operating over a non-line-of-sight 25 mile path with excellent sigs.> % The power output was in the 20 - 100 mW range, I think.> > I've done better than 40 miles over non-line-of-sight paths with only> 10 mW and CRUDDY WIDEBAND FM! This was with 2 foot dish antennas on> both ends of the path at X-band. Still, I'm not pooh-poohing their> efforts; I'm just trying to show that even with simple cheap equipment> you can do a lot more than most people expect in the SHF and EHF> spectrum.> > Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh> > ------------------------------> > Date: 24 Apr 90 01:41:49 GMT> From: usc!pollux.usc.edu!kjh@ucsd.edu (Kenneth J. Hendrickson)> Subject: pulse on X-band> To: packet-radio@ucsd.edu> > In article <1250147@hpnmdla.HP.COM> glenne@hpnmdla.HP.COM (Glenn Elmore) writes:> % Ken,> % I don't think pulse privileges really are that much of an issue in> % preventing effective use of the band. As I see it, the main advantage would be> % in using surplus hardware.> > Yes, this would be the advantage. I'm not suggesting that we have an> undue hardship with the pulse restriction; I am suggesting that it is> arbitrary and capricious, and that if we didn't have the restriction,> there would be one more possible way that we could effectively> communicate on the band.> > % However, moderate power narrowband > % equipment is no longer a difficult proposition. Very long links and> % OTH links require optimum use of the resources; reasonably efficient> % use of the spectrum (bps/Hz numbers) and highly directional beams to> % avoid waste and QRM; as well as physically larger receive antenna apertures> % to recover the information. Even so I suspect that for reliable networks and > % comm. channels we are likely to end up with a larger number of shorter LOS > % links instead of long haul OTH ones.> > This may be true. However, I don't think anybody has ever experimented> with using high-power low-duty-cycle signals to build a packet switched> microwave network. My idea might not pan out to anything, but on the> other hand, how will we know unless somebody tries to do it?> > % Troposcatter is a fairly predictable > % propagation mechanism at 10 GHz (see my description of an> % experience with it on a 400+ mile path during the 1987 10 GHz terrestrial > % DX record outing in December 1987 QST) but long haul links are inherently> % lossier and less reliable than shorter LOS ones.> % I strongly agree that we need to use our microwave resources and in> % particular 10 GHz but I think we will end up finding that for efficient> % use of our amateur resources we will start looking more like the telephone> % companies and common carrier folks when we solve the backbone problem.> % > % Glenn Elmore -N6GN- N6GN @ K3MC glenn@n6gn.ampr.org glenne@hpnmd.hp.com > > Sure, we might wind up looking like the telephone companies. Maybe they> have already tried the pulse idea. On the other hand, I have never> heard of it. If nobody has yet tried it, to see what the results are,> what is wrong with us amateurs giving it a try. It just might be> useful.> > Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 15:00:22 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Thu Apr 26 17:52:50 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 15:00:00 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa01499; 26 Apr 90 17:46 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id aa09309; 26 Apr 90 16:06 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id ac10941; 26 Apr 90 17:16 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa10889; 26 Apr 90 17:13 BST> Received: by ucsd.edu; id AA19048> sendmail 5.61/UCSD-2.0-sun> Thu, 26 Apr 90 08:28:37 -0700 for brian> Received: by ucsd.edu; id AA19043> sendmail 5.61/UCSD-2.0-sun> Thu, 26 Apr 90 08:28:36 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004261528.AA19043@ucsd.edu>> Date: Thu, 26 Apr 90 08:27:52 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #9> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Thu, 26 Apr 90 Volume 90 : Issue 9> > Today's Topics:> DEC Rainbow> DOVE Satellite> faster modems> How decipher DOVE telemetry?> TAPR DCD on Heath 4040> US Navy and packet radio> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 25 Apr 90 19:53:26 GMT> From: swrinde!cs.utexas.edu!samsung!xylogics!bu.edu!m2c!wpi!tmurphy@ucs d.edu (Tom [Chris] Murphy)> Subject: DEC Rainbow> To: packet-radio@ucsd.edu> > With any luck, I'll be getting a Technician licence this weekend and> as soon as it comes in the mail, I plan on trying some work with packet> radio. I may be inheriting a DEC Rainbow, and was wondering what software> exists for it to do TCP based work, primarily mail although telnet and> ftp would be nice also. Thanks for the help in advance!> > Tom Murphy> tmurphy@wpi.wpi.edu> > ------------------------------> > Date: 25 Apr 90 15:06:01 GMT> From: idacrd!mac@princeton.edu (Robert McGwier)> Subject: DOVE Satellite> To: packet-radio@ucsd.edu> > In article <9004241908.AA14576@ucsd.edu>, by KEVIN@CALSTATE.BITNET:> > I have been monitoring for DOVE for a coupla days, and haven't heard a peep.> >> > Kevin:> > It is alive and well downlinking on 2401.100 Mhz +/- an unbelievable amount> of doppler. There is no way the straight calculation can be as impressive> as trying to track that stuff and copy data! I am reloading its software> and its gonna do speech when it comes back on.> > Bob> > -- > _________________________________________________________________ ___________> My opinions are my own no matter | Robert W. McGwier, N4HY> who I work for! ;-) | CCR, AMSAT, etc.> ----------------------------------------------------------------- -----------> > ------------------------------> > Date: 26 Apr 90 02:10:11 GMT> From: sun-barr!newstop!texsun!texbell!splut!jay@apple.com (Jay "you ignorant splut!" Maynard)> Subject: faster modems> To: packet-radio@ucsd.edu> > In article <22526@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes:> >I have done a *lot* of thinking about this problem. Given that amateur radio> >is a voluntary, personally funded activity, you can't force hams to buy new> >hardware. But there's another approach: establishing a frequency allocation> >policy that encourages the use of more efficient modulation and frequency> >reuse techniques. The more efficient your proposed use of the spectrum, the> >more likely you are to get an allocation.> > >Amateur frequency coordinators now follow a first-come first-served policy,> >and this *must* change. In many areas like Los Angeles and New York, the> >VHF/UHF bands are nearly full with FM repeaters and conventional 1200 baud> >packet, and there is little room to experiment with newer, more efficient> >techniques.> > (dig, dig...ok, I found it.) [putting on President, Texas VHF-FM Society hat]> > You've beat this drum before, and I've argued it before. While your idea> has merit in a perfect society, it *cannot* work in the real ham world.> > Frequency coordinators now serve in an advisory capacity. You'd like us> to tell people who have coordinations and are currently operating> repeaters on frequencies where they do not experience regular,> significant interference (the standard which coordinators try to> maintain) that, all of a sudden, the rules have changed, and that they> must either shut down entirely, or accept unheard-of, and previously> unacceptable, levels of interference.> > They wouldn't listen to us.> > Instead, they'd keep on operating on what they perceive as *their*> frequency. You know that they don't own it, I know it, but they don't -> and they're the only ones with the power to make such a change work.> > Frequency coordination and spectrum management isn't just a technical> problem, but a highly political one as well. Come up with a way to> accomplish your goal that *can* be accepted by the population of current> FM voice system operators and users, and your wish will come true, and> I'll sign up to promote it. This isn't the school debate society,> though, where changes can be implemented by fiat. You must account for> the mechanisms involved in implementing the change, and _that_ is where> your problem lies.> > -- > 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, RIP. It was nice knowing ya +----------------------------------------> "Flying is a lot more fun than being in the Senate." -- Senator Jake Garn> > ------------------------------> > Date: 25 Apr 90 22:20:31 GMT> From: deimos.cis.ksu.edu!harris.cis.ksu.edu!mac@uunet.uu.net (Myron A. Calhoun)> Subject: How decipher DOVE telemetry?> To: packet-radio@ucsd.edu> > My packet station can hear DOVE's telemetry;> now I'd like to know what it means.> > Is there a source for software to decipher the> hex stuff into meaningful-to-humans information?> > Please reply by email.> --Myron.> --> # Myron A. Calhoun, Ph.D. E.E.; Associate Professor (913) 539-4448 home> # INTERNET: mac@harris.cis.ksu.edu (129.130.10.2) 532-6350 work> # UUCP: ...{rutgers, texbell}!ksuvax1!harry!mac 532-7004 fax> # AT&T Mail: attmail!ksuvax1!mac> > ------------------------------> > Date: 25 Apr 90 20:27:41 GMT> From: sdd.hp.com!zaphod.mps.ohio-state.edu!sunybcs!uhura.cc.rochester.e du!rochester!kodak!eastman!hpcore!gerwitz@ucsd.edu (Paul Gerwitz)> Subject: TAPR DCD on Heath 4040> To: packet-radio@ucsd.edu> > I am posting this for someone who does not have net access. Please send> email replies to him directly at 'uunet!atexnet!kodak!eastman!dieter'.> > ----------------------------------------------------------------- ------> > Subject: HELP w/ TAPR DCD Upgrade> > I recently built a TAPR 2211 DCD upgrade kit. It is supposed to enhance DCD> operation.> > After installing the kit in my Heath HD-4040, the DCD light in fact does seem> to react much better (less falsing, more constant when it does lock on). The> only problem is now my TNC will TRANSMIT EVEN WHEN THE DCD LIGHT IS ON !!!! I> have checked the assembly and the value of most of the components. I cannot> imagine how the thing can transmit with the DCD light on. It's supposed to> inhibit transmit isn't it ? If anybody has any experience with this PLEASE> HELP !!! Leave a message, or call Mark at (716) 723-0227. Thanks> > ----------------------------------------------------------------- -------> --> +---------------------------------------------------------------- ------------+> | Paul F Gerwitz WA2WPI | SMTP: gerwitz@kodak.com |> | Eastman Kodak Co | UUCP: ..rutgers!rochester!kodak!eastman!gerwitz |> +---------------------------------------------------------------- ------------+> > ------------------------------> > Date: 25 Apr 90 16:08:00 EDT> From: "SWEIGERT, DAVID" <dsweigert@paxrv-nes.navy.mil>> Subject: US Navy and packet radio> To: "packet-radio" <packet-radio@wsmr-simtel20.army.mil>> > The U.S. Navy has commissioned a multi-media test of ship-shore> data communications. Particular media under test:> > o HF communications> o Fleet SATCOM (2400 bit/second US Navy satellites)> o INMARSAT Commercial satellite channels> > It is believed the HF communications portion shall include a packet radio> test.> > SPAWAR Code PMW-156 (Capt. Joesph Price, USN) is coordinating the test> at the direction of VADM Jerry O. Tuttle, USN, OPNAV Code 094. The testing> agent shall be the Naval Engineering Center at Vallejo, CA. The test platforms> shall be ships assigned out of San Diego, CA. The test is lated to begin> this summer.> > Mission support data shall be transferred from an aircraft carrier to shore> based NARDAC, Naval Regional Data Automation Center.> > > cheers...> > WB9VKO> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 15:15:49 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Fri Apr 27 13:29:54 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 15:15:27 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa05720; 27 Apr 90 13:20 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id af04978; 27 Apr 90 12:04 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id aa13232; 27 Apr 90 12:56 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa13189; 27 Apr 90 12:54 BST> Received: by ucsd.edu; id AA20478> sendmail 5.61/UCSD-2.0-sun> Fri, 27 Apr 90 04:00:10 -0700 for brian> Received: by ucsd.edu; id AA20467> sendmail 5.61/UCSD-2.0-sun> Fri, 27 Apr 90 04:00:06 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004271100.AA20467@ucsd.edu>> Date: Fri, 27 Apr 90 04:00:03 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #10> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Fri, 27 Apr 90 Volume 90 : Issue 10> > Today's Topics:> Ham Packet BBS on ATT UNIX PC?> Universal M-610 wanted> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 27 Apr 90 02:31:18 GMT> From: zaphod.mps.ohio-state.edu!math.lsa.umich.edu!sharkey!lopez!flash@ tut.cis.ohio-state.edu (Gary Bourgois)> Subject: Ham Packet BBS on ATT UNIX PC?> To: packet-radio@ucsd.edu> > Here's the deal. I am the system administrator of a Public Access Unix > BBS, and have been running a BBS at the same phone number since 1983. > Being a consultant by trade, and doing all of my work at home, I can run > the BBS, and also play ham radio day and night. I have a speaker from > the ham rig in my computer room, and I have a video feed from the BBS > monitor in my ham shack. The two hobbies sort of meld. I talk with > other UNIX people on the ham bands, and send email to ham friends on > USENET.> > I am obsessive compulsive, I admit it and I use it to an advantage.> > I do not have a packet system. Not today. I always managed to put it > off.> > The PBBS that serves this area of Upper Michigan is going to be going > down soon. They are looking for someone else to run one.> > A ham from Lower Michigan said he would donate a TNC. I agreed to supply > what equipment I can, and am mulling over what is the best way to go. I > have an old XTAL type 2m rig and a spare antenna to kick into the project.> > I also have an AT&T UNIX PC with a 20 meg hard drive. Not much, but > probably enough to run a PBBS.> > Why the UNIX PC? (also known as a 7300, or 3b1)> > Well I got to thinking how easy it would be, while reading rec.ham.radio > on the console of the landline BBS, I could forward articles to the > Packet BBS with ease, using UUCP.> > Has anyone ever done this?> > Would the 3b1 be up to the job? If so, I will also donate that to the > project. It would be a great service to the hams of Northern Michigan to > have selected articles from USENET ported over to our local PBBS. I will > not do it if I have to haul floppies up a flight of stairs (The USENET > site is on the ground floor, and my hamshack is one floor up).. BUT > using UUCP would be a breeze.> > Our own BBS software on lopez is locally written, so I can have any mods > I want tossed in simply, and many I can write myself (The software > STARBASE, is very configurable, and will eventually be made public)...> > The trick will be to link everything together. I am sure it could be > done with a XENIX type PC, but that route is beyond our meager budget.> > Any ideas, thoughts, ponderings, musings, experiences welcome.> > Thanks, es 73> > Gary> -- > == 14.313 == Amateur Radio Forum Saturday 11:00AM Eastern time == 14.313 ==> == Gary Bourgois flash@lopez (rutgers!sharkey!lopez!flash) GWN UPLink ==> == 3.950 Nationwide Amateur Radio Nightly after 0200z=Learning Channel ==> =============== WB8EOH = The Eccentric Old Hippie = WB8EOH ================> > ------------------------------> > Date: 26 Apr 90 13:50:56 GMT> From: portal!cup.portal.com!Lee_-_Reynolds@apple.com> Subject: Universal M-610 wanted> To: packet-radio@ucsd.edu> > Wanted - the Universal M-610 tuning scope and M-605 FDM box.> > > Please Email me at Portal or call me at (617)860-8629> > > Lee G8LCK> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 15:36:44 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Sat Apr 28 13:33:05 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 15:36:23 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa10554; 28 Apr 90 13:28 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id aa04573; 28 Apr 90 12:33 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id aa05678; 28 Apr 90 13:13 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa05603; 28 Apr 90 13:08 BST> Received: by ucsd.edu; id AA24794> sendmail 5.61/UCSD-2.0-sun> Sat, 28 Apr 90 04:00:07 -0700 for brian> Received: by ucsd.edu; id AA24788> sendmail 5.61/UCSD-2.0-sun> Sat, 28 Apr 90 04:00:06 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004281100.AA24788@ucsd.edu>> Date: Sat, 28 Apr 90 04:00:03 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #11> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Sat, 28 Apr 90 Volume 90 : Issue 11> > Today's Topics:> faster modems> Ham Packet BBS on ATT UNIX PC?> Hams in space?> MFJ TNC sold> Networking> SAREX STS-35 space shuttle> shareware in packet radio> Teletext> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 25 Apr 90 18:57:01 GMT> From: vsi1!zorch!tandem!kevinr@apple.com (Kevin J. Rowett)> Subject: faster modems> To: packet-radio@ucsd.edu> > In article <690@idacrd.UUCP> mac@idacrd.UUCP (Robert McGwier) writes:> >> >I believe that for hams in the US, it must be made into an appliance.> > I completely agree Bob!> > > We> >have also suffered another set back with the Totally Awesome IO board> ^^^^^^^^> > Bob, from the trenches, we don't really view it as a set back. Delay> *maybe*, but Awesome I/O *is* happenning! I'm staring at film right> now ready to go to a board maker....> > We do live in Silicon Valley, and getting cards made is easier than> shopping for a car here. The PacBell yellow pages has three entire> pages listing people who will make cards..> > We realize there's more to getting a product out than just having cards > made, but it K3MC Awesome will happen.> > >project. Its commercial license was never completed and those efforts> >have now fallen through. > > THis really sounds worse than it is. K3MC (Awesome ) has not died! Only the> arrangements with that particular commericalizer.> > > Totally Awesome> >IO from K3MC/N6RCE, 10 Ghz-megabit stuff from Glen Elmore, TCP-IP from> >KA9Q, we have ALL the technology we need to lead us into 21-st century.> >> >Bob> > > N6RCE> > ------------------------------> > Date: 27 Apr 90 21:24:51 GMT> From: umich!sharkey!cfctech!ttardis!rlw@CS.YALE.EDU (Ron Wilson)> Subject: Ham Packet BBS on ATT UNIX PC?> To: packet-radio@ucsd.edu> > In article <1990Apr27.023118.15972@lopez.UUCP>, flash@lopez.UUCP (Gary Bourgois) writes:> >A ham from Lower Michigan said he would donate a TNC. I agreed to supply > >what equipment I can, and am mulling over what is the best way to go. I > >have an old XTAL type 2m rig and a spare antenna to kick into the project.> >> >I also have an AT&T UNIX PC with a 20 meg hard drive. Not much, but > >probably enough to run a PBBS.> >....> >The trick will be to link everything together. I am sure it could be > >done with a XENIX type PC, but that route is beyond our meager budget.> >> >Gary> > Anything thing you can do with Xenix on a PC, you can do with the Unix-PC.> > A 20 meg disk might be too small - even a minimal news feed requires a lot> of disk space.> > There is program written by the people at KA9Q called simply KA9Q. It is> a program designed to implement protocols like Telnet (a terminal emulator),> FTP (file transfer protocol), and others over packet radio.> > KA9Q does work on the Unix-PC.> > Using the KA9Q program and a pty driver would enable any Unix system to> receive Telnet and FTP connections over packet radio (not to mention SLIP/SLFP> connections from other computers).> > Because of the pty driver (psuedo terminal), any Telnet connection would log> into the Unix system normally (via getty and login) just as through the> person had called in with a modem.> > I'm sure other people on the net can help you with technicalities in setting> this up (I know nothing about packet radio other than what it is).> > Good luck.> > - Ron> > ------------------------------> > Date: Fri, 27 Apr 90 07:52:53 PDT> From: KEVIN%CALSTATE.BITNET@CORNELLC.cit.cornell.edu> Subject: Hams in space?> To: packet-radio@ucsd.edu> > I recall reading some months ago that this summer, an astronaut on the Space> Shuttle will be doing 2 meter packet communications with earthlings.> > When will this occur? On what frequency? Will it be possible for me> to communicate with them using my BIG 5 watts of power? do i need a special> antenna or will my rinkydink ones made out of coathangers do the trick?> I expect QRM will be real bad, but the equiptment I got is what I'm stuck> with ... I yam what I yam.> > All help appreciated!> > -- Kevin> > +----------------------------------------+ DISCLAIMER: I assume no> : KEVIN M. SAVETZ - KC6GWQ : responsibility for any messages> : Bitnet: kevin@calstate.BITNET : that I post, expressed or> : Internet: humbolt!waffle@csun.edu : implied. Opinions expressed> : Fishnet: salmon@smoked.poached.fried : by me are not necessarily> +----------------------------------------+ my own.> > -30-> > ------------------------------> > Date: 27 Apr 90 19:39:24 GMT> From: psuvm!mls129@psuvax1.cs.psu.edu (Michael L. Sensor)> Subject: MFJ TNC sold> To: packet-radio@ucsd.edu> > The MFJ 1274 TNC I advertised here has been sold.> > Mike Sensor MLS129@PSUVM> > ------------------------------> > Date: 26 Apr 90 08:29:49 GMT> From: mcsun!ukc!stc!praxis!riemann!mikec@uunet.uu.net (Michael Chace)> Subject: Networking> To: packet-radio@ucsd.edu> > Hello All,> > I'd like the benefit of people's experiences concerning what to do when> your local 2m 1200bps single channel based network begins to overload.> > Our local packet network is at breaking point for about 50% of the time.> To put the network under a more 'formal' basis we had a meeting of> all local packeteers with the aim of creating a group to maintain and> enhance the network. Various suggestions were made on how to solve things,> some good, some bad. Here's a summary of the network as it stands:-> > NB - My local area is Bath/Bristol/Cardiff (S/W England & S Wales)> Total population ~1 million - Amateurs on packet ~300> > 90% of traffic sits on 144.650 all 1200bps - Local chats and node traffic.> Some links now exist on 70MHz - mainly for BBS forwarding.> There are 2 major nodes on 2m - They are on very high sites running 25W erp> consequently they hear a lot and lots can hear them.> > Perhaps a greater problem is that most routes out of our area are poor and> they also must talk to well-sited nodes. It not unusual to have stations> telephoning node sysops because they think the node is down - when its due> to the node hearing so much that its squelch is permanently open!> Most of the nodes in our area form backbone links in all directions and the> NTS Mailboxes rely on them heavily.> > The basic idea is to move the well-sited nodes into lower 'city' locations> keep them as the user access points and then tie up these nodes on separate> links (4m/70cms/23cms). Where to put the links is a moot point - 4m has a > source of cheap PMR equipment but no bandwidth - 70cms more expensive, more> channels but it's not a primary band - 23cms expensive but plenty of wide> open space.> > What I'd like are your thoughts/experiences/suggestions etc. Particularly> why you chose frequencies/data speed etc.> > As a final note - one of the things that I noticed at the meeting and while> talking to the local users were :-> > 1) People need to learn that the packet system needs to shunt data> fast. It's a serious network that moves data regardless of what> the data is and how it gets from one point to another.> > 2) People don't understand much about protocols and the NET/ROM> system eg. NOT realising that KA/NODES are not real nodes and> trying to explain why p-persist will squeeze a few more % out> of the network.> > > Thanks for your time & 73,> > Mike> ****> ................................................................. ............> | ARPA : mikec@praxis.co.uk | Michael Chace |> | JANET : mikec@uk.co.praxis | PraXis Systems |> | UUCP : ...!uunet!mcvax!ukc!praxis!mikec | Manvers Street |> | AMPRNET: g6dhu@g6dhu.ampr.org [44.131.20.3] | Bath, Avon |> | AX.25 : G6DHU @ G6DHU-2 or G6DHU @ GB7SDN | BA1 1PX UK |> | Phone : (44) [0]225 444700 | |> ................................................................. ............> > > > > ------------------------------> > Date: 27 Apr 90 16:38:43 GMT> From: microsoft!joehol@uunet.uu.net (Joseph HOLMAN)> Subject: SAREX STS-35 space shuttle> To: packet-radio@ucsd.edu> > i never got any direct replies, so i'll try again...> > > is any body out there going to have a way for use> people up in Seattle (latitude 47 deg.) to connect> to the SAREX mission ?> > i've heard rumors about people having KA-NODEs, but> i haven't heard from the horses mouth yet...> > anybody have any names or callsigns of people doing/planning > this ????> > joe holman, ka7ldn> uw-beaver!microsoft!joehol> joehol@microsoft.uucp> 206-882-8921 work> > ------------------------------> > Date: Fri, 27 Apr 90 13:25:12 MST> From: sarrel%miranda.uucp@moc.Jpl.Nasa.Gov (Marc Sarrel)> Subject: shareware in packet radio> To: packet-radio@ucsd.edu> > Is there an FCC policy or other generally accepted rules regarding> putting shareware on packet radio BBS's? Is transmitting shareware> considered a "business communication"? What about freeware? Just> curious...> > --marc> > -=-> Marc A. Sarrel> N7OLI> sarrel%miranda.uucp@moc.jpl.nasa.gov | "Oh, _lightweight_ Alpaca..."> ..!sun!sunburn!miranda!sarrel | -Blanche DuBois> > NSA fodder:> > Binary Chemical Weapon domestic disruption munitions FBI Clifford> Stoll Soviet detonator fissionable KGB colonel $400 million in gold> bullion genetic backsatter Pentagon nuclear> > ------------------------------> > Date: 27 Apr 90 15:01:26 GMT> From: motcid!froula@uunet.uu.net (Don Froula)> Subject: Teletext> To: packet-radio@ucsd.edu> > Does anyone have information about the fate of Teletext services in the US?> This is an information service that provides text and block color graphics> capability on a home TV receiver equipped with a special decoder. The data> is embedded in several unused TV lines in the vertical blanking interval.> The data repeats over and over in the form of a magazine. The decoder> simply grabs pages as they come by and stores them in a display buffer.> The system is very popular in the UK.> > Zenith used to offer an embedded decoder on some of their sets. Also, Dick> Smith electronics offered a kit a few years back.> > Observations on several local broadcast and cable channels show considerable> activity in the blanking interval. > > Information on current status of Teletext and sources for decoders would> be appreciated.> > Don WD9DMP> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 15:44:15 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Sun Apr 29 12:59:58 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 15:44:03 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa17143; 29 Apr 90 12:53 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id aa03394; 29 Apr 90 11:59 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id aa02926; 29 Apr 90 12:38 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa02870; 29 Apr 90 12:32 BST> Received: by ucsd.edu; id AA09531> sendmail 5.61/UCSD-2.0-sun> Sun, 29 Apr 90 04:00:08 -0700 for brian> Received: by ucsd.edu; id AA09518> sendmail 5.61/UCSD-2.0-sun> Sun, 29 Apr 90 04:00:05 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004291100.AA09518@ucsd.edu>> Date: Sun, 29 Apr 90 04:00:03 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #12> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Sun, 29 Apr 90 Volume 90 : Issue 12> > Today's Topics:> AR-2002 scanner remote info wanted> faster modems> Ham Packet BBS on ATT UNIX PC?> Need help in radio data communic.> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 28 Apr 90 10:38:55 GMT> From: eru!luth!sunic!mcsun!hp4nl!dutrun!dutentb!ese@BLOOM-BEACON.MIT.ED U (Kees Schot)> Subject: AR-2002 scanner remote info wanted> To: packet-radio@ucsd.edu> > !! HELP !!> > For about one year I'm looking for information on the> computer interface of the AR-2002 communications receiver.> > If someone has hard- or software information about> this interface (or also about other interesting aspects of> this equipment) please send it to me by email to> > schot@dutentb.tudelft.nl> > or on paper to:> > C.A. Schot,> Grote Kreek 45,> 3079 CC Rotterdam,> The Netherlands.> > Even the name and address of the (I thought Japanese)> manufacturer of this scanner can help me.> > Please, help me, because this is the last hope for me> to get this information.> > ------------------------------> > Date: 28 Apr 90 15:56:42 GMT> From: payne@tcgould.tn.cornell.edu (Andrew Payne)> Subject: faster modems> To: packet-radio@ucsd.edu> > In article <9004232134.AA04767@miranda.uucp> sarrel@miranda.UUCP (Marc Sarrel) writes:> >expert" at a local amateur radio store recently. I asked him about> >some TNC that had a 2400 baud modem vs one that had a 1200 baud modem.> >I asked wether 2400 would catch on, given my experience with land line> >modems where everyone was starved for speed. He said "no." His> >reasons seemed pretty fuzzy to me, but he seemed to claim that 1) 2400> >baud wouldn't catch on because everyone already has 1200 baud modems,> >2) 1200 baud seemed fast enough to him, and 3) that 2400 baud wasn't> >_really_ twice as fast as 1200 because the extra speed was used> >inefficiently. (But don't hold me to that, this was a while ago.)> >> I also feel that 2400 baud will not catch on, but my reasoning is > much different. 2400 baud is just not that much of a jump beyond 1200 to > make it worth the trouble. Go for 9600 baud or 56kb (though 4800 baud seems> to be a happy medium for many because it supposedly works with more radios than> the higher speeds).> > >Anyway, my question is this: How can we "hams in the know" encourage> >the use of faster and more effecient modems on the airwaves, given> >that we agree that "faster is better." One of this guy's arguments> >holds weight in that there is a lot of "hardware inertia" out there.> > The first step in taking advantage of higher speed modems is to use> them on the backbones. The backbones are where the heavy traffic is anyway,> and there is little "hardware inertia" involved. You could run some strange> I'm-not-compatible-with-anything protocol and modem on the backbones and it > wouldn't really matter.> > Many of the UHF backbone links of the network in Ohio are at 4800> baud. The NEDA guys have many 4800 baud trunks and are quickly moving for > 9600 baud. Also, on the NEDA network, many of the high-volume users (DX > clusters, BBSs, TCP/IP) are using higher speed uplinks to the backbone.> > There is never going to be an overnight switch away from 1200 baud.> Like MS-DOS, it will dog us for a long, long time. Put the high-speed modems> in the places will they will give maximum benefit and gradually people will> migrate beyond 1200 baud.> > > -- > = = = = = = = = = = = = = = = = = = = = = = = = = = => Andrew C. Payne, N8KEI UUCP: ...!cornell!batcomputer!payne> INTERNET: payne@tcgould.tn.cornell.edu> > ------------------------------> > Date: 28 Apr 90 21:56:00 GMT> From: usc!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs. uiuc.edu!kenny@ucsd.edu> Subject: Ham Packet BBS on ATT UNIX PC?> To: packet-radio@ucsd.edu> > >There is program written by the people at KA9Q called simply KA9Q.> > Gee, Phil, I never knew you were twins.... 8-)> > Kevin, KE9TV> kenny@cs.uiuc.edu> > ------------------------------> > Date: 28 Apr 90 00:08:00 GMT> From: swrinde!zaphod.mps.ohio-state.edu!uwm.edu!bionet!arisia!cdp!saff@ ucsd.edu> Subject: Need help in radio data communic.> To: packet-radio@ucsd.edu> > Friends,> > I work in a brazilian organization who also give> support for non-profits organizations. We work with a similar> organization, here in San Francisco Bay Area. We are about to get> authorization to use the PeaceSat, an old militar satellite now used> for pacific purposes, and we plan to use initially to get a cheap> and good link from our machines. I have no experience in this area,> so I am asking for help with some (maybe dumb) questions:> > - Possible baud rates> > - Hardware required> > - Places where look for hardware> > Thanks very much for any help,> > Saliel Figueira Filho> Chief Programmer> IBASE> > {pyramid, hplabs, ...}!cdp!saff> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: 2 May 90 05:43:47 GMTFrom: swrinde!emory!rsiatl!jgd@ucsd.edu (John G. De Armond)Subject: faster modemsTo: packet-radio@ucsd.edukarn@thumper..bellcore.com (Phil R. Karn) writes:>In article <1959@rsiatl.UUCP> jgd@rsiatl.UUCP (John G. De Armond) writes:>>In terms of rules, before the great ARRL/FCC rules rewrite, this type>>modem [wa4dsy]>>could be used at 220 mhz and above. Now that we've been "represented">>again by the ARRL, 220 is out. But anything 440 or above is fine.>This is news to me. I'm still running 56kbps on 220.55, and as far as I>know it's still entirely legal.I'm sorry that I can't quote chapter and verse, Phil, but I don't havemy personal copy of the new Part 97 yet. My comment stems from a GRAPESsession a few months ago when we were reviewing the rewrite. As I recall,the new language puts both a baudrate and a bps limit on everthing below440. I'm going to be in a ham store tomorrow, so I'll pick up myown copy of Part 97 and find the clause. Meanwhile, you might wantto reread the digital sections carefully. It was the consensus of every-body that read those paragraphs that day that 56k was out on 220.John-- John De Armond, WD4OQC | We can no more blame our loss of freedom on congressRadiation Systems, Inc. | than we can prostitution on pimps. Both simplyAtlanta, Ga | provide broker services for their customers.{emory,uunet}!rsiatl!jgd| - Dr. W Williams | **I am the NRA** ------------------------------Date: Tue, 1 May 90 9:00:38 PDTFrom: Peter Dahl <pdahl@milton.u.washington.edu>Subject: Full Duplex packet on 2 meters?To: packet-radio@ucsd.edu Is anyone operating dual frequency, full duplex packet nodes on2 meters on frequencies other than coordinatable/bandplan repeater pairs?How about 145.01/145.61? How do you interpret the fcc rules on this one?145.61 is in an area where repeaters are supposedly not permitted but is a fullduplex packet node a repeater as we have come to know repeaters? TheARRL Repeater Directory says that the frequencies between 145.5 and I believe145.8 are bandplanned for experimental modes. Everything in this developingmode of packet radio is experimental isn't it? Please let me know what you think.... We need some full duplexpacket systems and standard repeater pairs have all been used for voice repeaters whether they are really needed or not. Peter, WA7FUS------------------------------Date: 1 May 90 22:41:00 GMTFrom: zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1 .cso.uiuc.edu!phil@tut.cis.ohio-state.eduSubject: Full Duplex packet on 2 meters?To: packet-radio@ucsd.eduYou might try doing some unusual splits in the repeaters. The FCC rulesdo NOT allow repeaters in the 145.5-146 Mhz range (nor 144.0-144.5) soyou need to limit yourself to 144.5-145.5 and 146-148.It is a sad shame that spectrum planners and repeater coordinators are notmaking any attempt to plan for greater density of spectrum usage. Theysimply assume that when there is no repeater pair that comes up without aconflict on the computer, that that band is full at that location.Spectrum planners need to get on the ball and do some planning. If thatcalls for some repeater pairs to be dedicated to packet, so be it. It maynot be necessary to do that.However I must assert one thing for certain: just because someone has had arepeater on a given frequency already is no reason for having a "right" tostay there. If packet radio needs to share the spectrum of repeater pairsthen the spectrum should be allocated as needed.This probably means some repeaters will have to move. Hey folks, that ispart of progress. Of course some hams are totally against progress, andthe only solution I can suggest for them is to take them off the air.By the way, you CAN get several TIMES the number of repeaters on the airin the major cities as you have now. It also appears that the number ofrepeaters in several are NOT EVEN NEEDED. The situation as it exists nowis mostly turf claims. This has to end and spectrum planners and repeatercoordinators need to get off their hind ends and do something.Problems will always exist when those who coordinate are also there toprotect the turf of existing repeater owners.I a big city you can hit 20 to 40 repeaters easily. Tell me how many ofthem are actually IN USE most of the time? What is the average amount ofairtime per repeater per day? I think you will find things are NOT asdense as we might like to think.--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society<phil@ux1.cso.uiuc.edu> | no matter what the particular issue is all about.------------------------------Date: 2 May 90 01:50:19 GMTFrom: uokmax!nsslsun.gcn.uoknor.edu!skaggs@apple.com (Gary Skaggs)Subject: Full Duplex packet on 2 meters?To: packet-radio@ucsd.eduI agree 100% with Phil on the problem of repeaters and the need for endingthe *turf* battles that are occurring over frequency *rights*. But, I thinkthe REAL solution if you want *full duplex* is individual, not-necessarily-600 Khz-offset frequencies. put one in the 145 simplex area, the other in146. Yes, I know *FM simplex* is what it says. If the natives are restlessabout such *sins*, cross-band. This saves on duplexor costs. You can buya good quality radio for less than what it will cost you for a good set ofband pass/band reject duplexors. Then run real full duplex.On second thought, go up in freq uency and run FAST, full duplex.__________________________________________________________ ____________________Gary Skaggs Internet: skaggs@nssl.gcn.uoknor.eduNational Severe Storms Laboratory (The Tornado People) "The Channel 9 Alpha system, technology at it's ____________?"------------------------------Date: 1 May 90 18:15:29 GMTFrom: ndcvb!cartan!ndmath!nstar!w8grt!jim.grubs@iuvax.cs.indiana.edu (Jim Grubs)Subject: Higher speedsTo: packet-radio@ucsd.edu(330) Sat 28 Apr 90 3:42pBy: Brian BattlesTo: Bob McgwierRe: Fast packetSt:-------------------------------------------------------- ----------------------@EID:1811 149c7d40Bob, In your reply to Marc Sorrel, you wrote: BM> ...Hams are basically cheap... Make that "poor," not necessarily cheap. Most hams I know areperpetually in danger of bankrupting their family financies to buynew gizmos. BM> ...and these days they are basically technically lazy... Although many are just busy or lacking education. Some of us havelittle time to get on the air, let alone design and build some fancynew digital high-tech device. Some hams have had little computer ordigital education and have to struggle to keep up. Besides, many hamsprefer to provide traffic handling/emergency communications/etc thanto build a lot of gear. BM> ...My efforts in this area along with partners KB2CST and KA2MOV BM> for commercial concerns and with WA7GXD, KV7B, W3IWI for TAPR and BM> AMSAT have essentially been done for free... And are greatly admired and appreciated by all amateurs with anyslight understanding of technology and creativity! BM> ...[with rigs] needed to work satellites, ROBOT 1200C's costing a BM> fortune when you can get them for SSTV, WEFAX APT equipment costing BM> a few hundred, etc, it has just gotten too expensive for a ham to BM> `do it all' with individual pieces of equipment... <sigh> All too true.73 de Brian Battles, WA1YUA * HAM RADIO & PACKET Echo ModeratorQTH New Britain, Conn.Packet: WA1YUA @ N1API... Someday my ham radio may save your life!--- Via Silver Xpress V2.24 (1:141/880) Brian Battles, WA1YUA - via FidoNet node 1:141/880UUCP: ...!ncar!asuvax!stjhmc!w8grt!880!141!1!brian.battlesINTERNET: brian.battles@f880.n141.z1.fidonet.org--------------------------- ---Date: Tue, 1 May 90 8:44:39 PDTFrom: Peter Dahl <pdahl@milton.u.washington.edu>Subject: New Packet Stuff @ Dayton??To: packet-radio@ucsd.eduI have not yet seen a list of the new packet related equipment that was introduced at Dayton last weekend. Can anyone who wasthere or has heard a report on this supply us with this info?CURIOUS MINDS WANT TO KNOW! 73 de Peter, WA7FUS------------------------------Date: Wed, 2 May 90 09:39 NFrom: Urs Baer <BWLLIBMOD%CSGHSG5A.BITNET@CUNYVM.CUNY.EDU>Subject: Packet-Radio Digest V1 #14To: Packet-Radio@UCSD.Eduplease remove my old adress 87674800s@csghsg5a.bitnet from this list!!!------------------------------End of Packet-Radio Digest******************************----------------------------- -End of Packet-Radio Digest******************************Date: Fri, 4 May 90 04:00:04 PDTFrom: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #17To: packet-radioPacket-Radio Digest Fri, 4 May 90 Volume 90 : Issue 17Today's Topics: faster modems (3 msgs) Full Duplex packet on 2 meters? NOS hosts.net file? Undeliverable messageSend Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 3 May 90 16:57:06 GMTFrom: van-bc!ubc-cs!alberta!atha!tech@ucbvax.Berkeley.EDU (Richard Loken)Subject: faster modemsTo: packet-radio@ucsd.edupayne@batcomputer.tn.cornell.edu (Andrew Payne) writes:> The first step in taking advantage of higher speed modems is to use>them on the backbones. The backbones are where the heavy traffic is anyway,>and there is little "hardware inertia" involved. You could run some strange>I'm-not-compatible-with-anything protocol and modem on the backbones and it >wouldn't really matter.A friend recently presented a counter argument when I suggested the abovescenerio. The argument goes like this:The backbone traffic is orderly and reasonably predicatable and would probablyrun just fine at 9600 baud or less. The local level is chaos with stationscontending and colliding so they should run as fast as possible in order to allow each node to get his packet on the wire and out of the way quickly.Recently another message supported this perspective, the author was commentingon his local environment in England where 300 stations running 1200 baudwere running into congestion problems.The more I think about it the more I support the view that the nodes out in thecloud should send the data as quickly as possible - running 56K or better wouldobligate an upgrade in modems and radios but not the computers since you arenot expected to provide and decode 50k x 60 x 60 x 24 characters of packetsevery day. Hopefully each node is not quite that talkative. ********* 73 ********** Richard Loken VE6BSV . **** .. **** Athabasca University .... **** Athabasca, Alberta Canada..........**** tech@cs.AthabascaU.CA {alberta|decwrl}!atha!tech----------------- -------------Date: 4 May 90 01:42:10 GMTFrom: thumper!karn@bellcore.com (Phil R. Karn)Subject: faster modemsTo: packet-radio@ucsd.eduI agree that the high speed modems are needed most by the users. Everyother computer network I've seen (especially the Internet) has the highbandwidth links (10 mb/s Ethernets, etc) at the local level, somewhatslower links on the regional level, and the slowest links for the longhaul paths.I suspect that many people advocate putting high speed modems into the backbonelinks mainly because it's easier (i.e., it requires fewer modems) thangiving them to the end users. It's somewhat reminiscent of the old jokeabout the drunk who was observed searching for something under a streetlightat night. When asked what he was doing, he replied that he had lost a contactlens across the street. When then asked why he wasn't looking for it acrossthe street, he replied that the light was better on *this* side...Phil------------------------------Date: 4 May 90 02:06:03 GMTFrom: zaphod.mps.ohio-state.edu!sunybcs!bowen@tut.cis.ohio-state.edu (Devon E Bowen)Subject: faster modemsTo: packet-radio@ucsd.eduIn article <22921@bellcore.bellcore.com>, karn@thumper..bellcore.com(Phil R. Karn) writes:|> I suspect that many people advocate putting high speed modems into the|> backbone links mainly because it's easier (i.e., it requires fewer modems)|> than giving them to the end users.Also that the highest speeds attainable so far are in bands that supportpoint-to-point communication. That's why we're looking at a high speed back-bone in this area. 1 Mb/sec links are not as doable for local, generic use.Devon------------------------------Date: 3 May 90 15:52:08 GMTFrom: thumper!karn@bellcore.com (Phil R. Karn)Subject: Full Duplex packet on 2 meters?To: packet-radio@ucsd.eduIn article <2058@rsiatl.UUCP> jgd@rsiatl.UUCP (John G. De Armond) writes:>The new rules specifically prohibit full duplex, repeater-like service>across those splits. Sad but true.I wish people would stop talking about what the "new rules" do differentlyfrom the old rules. The intent of the rewrite was NOT to change what isor is not allowed, but to restructure the existing rules to incorporateinformal rulings to make them more easily accessible. It was againstthe rules to put repeaters outside the repeater subband before the newrules were adopted, and it's against the new rules to do it now.Be that as it may, I did advocate that definitions of "repeater" and"digipeater" be adopted that reflect the important distinction thatdigipeaters have to be specifically requested by a transmitting stationto retransmit their packets, while plain repeaters do not. This isimportant because the reason for limiting repeaters to subbands is toavoid unintentional repeating of stations that do not wish to berepeated. If a "repeater" will not retransmit a signal unless thesender specifically requests to be retransmitted, then it should beclassified as a "digipeater" and not restricted to the repeatersubbands. Unfortunately this was considered a too "radical" proposalby the ARRL and it was not incorporated into their rules rewritecomments.Phil------------------------------Date: 4 May 90 03:54:00 GMTFrom: uhccux!querubin@ames.arc.nasa.gov (Antonio Querubin)Subject: NOS hosts.net file?To: packet-radio@ucsd.eduI've been playing around with KA9Q (NOS version) and I noticed that it doesn't seem to read the same hosts.net file that the older version does. Can anyone tell me if the new version expects a different file name than hosts.net? Also, how do I configure NOS to use the ethernet port on a UNIX system and at the same time, not interfere with other processes running TCP/IP?I understand that NOS is undocumented but if anyone has collected a set of configuration notes/hints, I'd appreciate getting them.AH6BWInternet: antonio_querubin-manoa@uhplato.uhcc.hawaii.eduBITnet: antonio_querubin-manoa@uhplato.bitnet---------------------------- --Date: 03 May 90 08:48:36 EDTFrom: Electronic Postmaster <POSTMASTER@CompuServe.COM>Subject: Undeliverable messageTo: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>Re: ? EMDITB - Mail Delivery Failure. Message too large. >EPX [70645,247]Packet-Radio Digest V1 #16Your message could not be delivered as addressed.--- Returned message ---Received: from ucsd.edu by saqqara.cis.ohio-state.edu (5.61-kk/5.900430) id AA28146; Thu, 3 May 90 08:18:56 -0400Received: by ucsd.edu; id AA22702 sendmail 5.61/UCSD-2.0-sun Thu, 3 May 90 04:00:16 -0700 for brianReceived: by ucsd.edu; id AA22695 sendmail 5.61/UCSD-2.0-sun Thu, 3 May 90 04:00:13 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-listMessage-Id: <9005031100.AA22695@ucsd.edu>Date: Thu, 3 May 90 04:00:04 PDTFrom: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #16To: packet-radio@cis.ohio-state.eduPacket-Radio Digest Thu, 3 May 90 Volume 90 : Issue 16Today's Topics: faster modems frustration Full Duplex packet on 2 meters? Hams in space Packet in Cincinnati, OH? TNC2 1.1.7 Code Undeliverable messageSend Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 2 May 90 16:56:32 GMTFrom: thumper!karn@bellcore.com (Phil R. Karn)Subject: faster modemsTo: packet-radio@ucsd.eduIn article <2049@rsiatl.UUCP> jgd@rsiatl.UUCP (John G. De Armond) writes:>As I recall,>the new language puts both a baudrate and a bps limit on everthing below>440.I think you're referring to a typo in the rules rewrite that did indeedmove the limit for wideband packet up to 420 MHz. This was not the intentionof the FCC, and in fact it was fixed in an errata ruling.Phil------------------------------Date: Wed, 2 May 90 23:10:23 MSTFrom: sarrel%miranda.uucp@moc.Jpl.Nasa.Gov (Marc Sarrel)Subject: frustrationTo: packet-radio@ucsd.eduI've been trying to monitor some packet traffic, but without muchsuccess. A own MacRATT, a PK-232MBX and a TH-225A. What happens isthat I can see the DCD light go on and off and see the Mark and SpaceLED's go back and forth, but only rarely does the contents of thepackets get printed. The curious part is that the MHEARD list isconstantly being updated as though packets are being received. I'llspare the net the rest of the details. If you have any ideas, send meemail.advTHANKSance--marc-=-Marc A. SarrelN7OLIsarrel%miranda.uucp@moc.jpl.nasa.gov | "Oh, _lightweight_ Alpaca..."..!sun!sunburn!miranda!sarrel | -Blanche DuBoisNSA fodder:strategic, Treasury, Narco Terrorist, assassination, room temperaturesuperconductor.------------------------------Date: 2 May 90 20:10:47 GMTFrom: rsiatl!jgd@uunet.uu.net (John G. De Armond)Subject: Full Duplex packet on 2 meters?To: packet-radio@ucsd.edupdahl@MILTON.U.WASHINGTON.EDU (Peter Dahl) writes:> Is anyone operating dual frequency, full duplex packet nodes on>2 meters on frequencies other than coordinatable/bandplan repeater pairs?>How about 145.01/145.61? How do you interpret the fcc rules on this one?>145.61 is in an area where repeaters are supposedly not permitted but is a full>duplex packet node a repeater as we have come to know repeaters? TheThe new rules specifically prohibit full duplex, repeater-like serviceacross those splits. Sad but true.John-- John De Armond, WD4OQC | We can no more blame our loss of freedom on congressRadiation Systems, Inc. | than we can prostitution on pimps. Both simplyAtlanta, Ga | provide broker services for their customers.{emory,uunet}!rsiatl!jgd| - Dr. W Williams | **I am the NRA** ------------------------------Date: Wed, 02 May 90 23:39:09 PDTFrom: KEVIN%CALSTATE.BITNET@CORNELLC.cit.cornell.eduSubject: Hams in spaceTo: packet-radio@wsmr-simtel20.army.milI posted a query a few days ago about a space shuttle flight on which a ham opwoold be using 2-way packet communications. I received no answers (possiblybecause the internet address in my .sig was dead...) So I will ask again, andadd what little I do know, taken from May 1990 QST.Quote:The Shuttle Amateur Radio Experiment #2 (SAREX-2) packet radio station recentlyunderwent testing at the Marshall Space Flight Center in Huntsville, Alabama,with assistance from area hams. The packet radio station flying on space shuttle mission STS-35 willgive each amateur who connects to WA4SIR a QSO number confirming the contact.More than 550 teachers, parents, and Amateur Radio clubs assisting schools havecontacted the ARRL Educational Activities Department for details on making acontact with the shuttle crew. This is a great opportunity for showing the excitexcitment of Amateur Radio to our youth! QSL cards will be available. The FCC has granted Payload Specialist Ron Parise, WA4SIR, a waiver touse his call sign for a space station aboard STS-35 to be launched May 9, 1990.Teachers can obtain shuttle locators from the ARRL Educational Activities De-partment by sending a 9- x 12-inch envelope with 45 cents postage affixed.End Quote.Questions!: What frequency! What frequency! What frequency!? Can *I* contact this guy using my silly antenna made out of coathangers and5 watts of power on VHF? How do I know when the shuttle is audible? (I know -- listen for it. I meanhow do I predict?) What frequency?!I am not a parent, teacher, or club, and (besides) I doubt I'd get any meaning-ful info from the ARRL before the 9th anyway. All help appreciated. Kevin Savetz The .sig is right this time.... vvvvvvv+----------------------------------------+ DISCLAIMER: I assume no: KEVIN M. SAVETZ - KC6GWQ : responsibility for any messages: Bitnet: kevin@calstate.BITNET : that I post, expressed or: Internet: gpr001f@ccs.calstate.edu : implied. Opinions expressed: Fishnet: salmon@smoked.poached.fried : by me are not necessarily+----------------------------------------+ my own. -30-------------------------------Date: 2 May 90 22:13:32 GMTFrom: ius3.ius.cs.cmu.edu!ralphw@pt.cs.cmu.edu (Ralph Hyre)Subject: Packet in Cincinnati, OH?To: packet-radio@ucsd.eduMoved from urban area in Pittsburgh, PA (plenty of stations) to Milford, OH (near Cincinnati, OH) and I'm having more difficulty contacting stations. I can hear W8YS and KY8T (sp?) in PASSALL mode (I would expect errors, LebanonOH (home of W8YS) is 30 miles away, I don't know where the other station is.)Does anyone know how the Cincinnati WAN is organized? Where else should I lookbesides 145.0{1,3}.I'm ready to break out my 10M rig and go HF.Thanks. - Ralph N3FGW-- - Ralph W. Hyre, Jr.internet: ralphw@ius3.cs.cmu.edu AMPRnet: in transitionapplelink: am0005 (attn: Ralph Hyre) (user to be n3fgw@w2xo)------------------------------Date: 2 May 90 14:34:36 GMTFrom: hpcc01!col!bdale@hplabs.hp.com (Bdale Garbee)Subject: TNC2 1.1.7 CodeTo: packet-radio@ucsd.edu>Have TAPR made the new 1.1.7 TNC2 Code available for download yet ?No. You really want a copy of the new manual that is shipping with 1.1.7. Call TAPR and order a copy, it's cheap.TAPRPO Box 12925Tucson, AZ 85732(602) 323-1710Bdale------------------------------Date: 02 May 90 09:37:20 EDTFrom: Electronic Postmaster <POSTMASTER@CompuServe.COM>Subject: Undeliverable messageTo: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>Re: ? EMDITB - Mail Delivery Failure. Message too large. >EPX [70645,247]Packet-Radio Digest V1 #15Your message could not be delivered as addressed.--- Returned message ---Received: from ucsd.edu by saqqara.cis.ohio-state.edu (5.61-kk/5.900430) id AA01840; Wed, 2 May 90 08:56:29 -0400Received: by ucsd.edu; id AA09832 sendmail 5.61/UCSD-2.0-sun Wed, 2 May 90 04:00:17 -0700 for brianReceived: by ucsd.edu; id AA09827 sendmail 5.61/UCSD-2.0-sun Wed, 2 May 90 04:00:14 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-listMessage-Id: <9005021100.AA09827@ucsd.edu>Date: Wed, 2 May 90 04:00:04 PDTFrom: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #15To: packet-radio@cis.ohio-state.eduPacket-Radio Digest Wed, 2 May 90 Volume 90 : Issue 15Today's Topics: DOVE TELEMETRY DATA.... here is how. Failed Mail (8 msgs) faster modems Full Duplex packet on 2 meters? (3 msgs) Higher speeds New Packet Stuff @ Dayton?? Packet-Radio Digest V1 #14Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 1 May 90 15:38:48 GMTFrom: swrinde!zaphod.mps.ohio-state.edu!sunybcs!uhura.cc.rochester.edu! rochester!kodak!ektools!kinsman@ucsd.edu (Andrew A. Kinsman)Subject: DOVE TELEMETRY DATA.... here is how.To: packet-radio@ucsd.eduSpacecraft: DOVE-1: Rev: 1 Date: 1/7/90 Equations are in the form: Y = A*N^2 + B*N + C where: N = Telemetry Count (00 - FF) A, B, C = Equation Coefficients Y = Result (In Specified Units)HEX Descripion: C: B: A: Units: cccccccccc bbbbbbbbbb aaaaaaaaaa uuuuuu 0 Rx E/F Audio(W)+0.000 +0.0246 0.000 V(p-p) 1 Rx E/F Audio(N)+0.000 +0.0246 0.000 V(p-p) 2 Mixer Bias V: +0.000 +0.0102 0.000 Volts 3 Osc. Bisd V: +0.000 +0.0102 0.000 Volts 4 Rx A Audio (W):+0.000 +0.0246 0.000 V(p-p) 5 Rx A Audio (N):+0.000 +0.0246 0.000 V(p-p) 6 Rx A DISC: +10.427 -0.09274 0.000 kHz 7 Rx A S meter: +0.000 +1.000 0.000 Counts 8 Rx E/F DISC: +9.6234 -0.09911 0.000 kHz 9 Rx E/F S meter:+0.000 +1.000 0.000 Counts A +5 Volt Bus: +0.000 +0.0305 0.000 Volts B +5V Rx Current:+0.000 +0.000100 0.000 Amps C +2.5V VREF: +0.000 +0.0108 0.000 Volts D 8.5V BUS: +0.000 +0.0391 0.000 Volts E IR Detector: +0.000 +1.000 0.000 Counts F LO Monitor I: +0.000 +0.000037 0.000 Amps10 +10V Bus: +0.000 +0.05075 0.000 Volts11 GASFET Bias I: +0.000 +0.000026 0.000 Amps12 Ground REF: +0.000 +0.0100 0.000 Volts13 +Z Array V: +0.000 +0.1023 0.000 Volts14 Rx Temp: +101.05 -0.6051 0.000 Deg. C15 +X (RX) temp: +101.05 -0.6051 0.000 Deg. C16 Bat 1 V: +1.7932 -0.0034084 0.000 Volts17 Bat 2 V: +1.7978 -0.0035316 0.000 Volts18 Bat 3 V: +1.8046 -0.0035723 0.000 Volts19 Bat 4 V: +1.7782 -0.0034590 0.000 Volts1A Bat 5 V: +1.8410 -0.0038355 0.000 Volts1B Bat 6 V: +1.8381 -0.0038450 0.000 Volts1C Bat 7 V: +1.8568 -0.0037757 0.000 Volts1D Bat 8 V: +1.7868 -0.0034068 0.000 Volts1E Array V: +7.205 +0.07200 0.000 Volts1F +5V Bus: +1.932 +0.0312 0.000 Volts20 +8.5V Bus: +5.265 +0.0173 0.000 Volts21 +10V Bus: +7.469 +0.021765 0.000 Volts22 BCR Set Point: -8.762 +1.1590 0.000 Counts23 BCR Load Cur: -0.0871 +0.00698 0.000 Amps24 +8.5V Bus Cur: -0.00920 +0.001899 0.000 Amps25 +5V Bus Cur: +0.00502 +0.00431 0.000 Amps26 -X Array Cur: -0.01075 +0.00215 0.000 Amps27 +X Array Cur: -0.01349 +0.00270 0.000 Amps28 -Y Array Cur: -0.01196 +0.00239 0.000 Amps29 +Y Array Cur: -0.01141 +0.00228 0.000 Amps2A -Z Array Cur: -0.01653 +0.00245 0.000 Amps2B +Z Array Cur: -0.01137 +0.00228 0.000 Amps2C Ext Power Cur: -0.02000 +0.00250 0.000 Amps2D BCR Input Cur: +0.06122 +0.00317 0.000 Amps2E BCR Output Cur:-0.01724 +0.00345 0.000 Amps2F Bat 1 Temp: +101.05 -0.6051 0.000 Deg. C30 Bat 2 Temp: +101.05 -0.6051 0.000 Deg. C31 Baseplt Temp: +101.05 -0.6051 0.000 Deg. C32 FM TX#1 RF OUT:+0.0256 -0.000884 +0.0000836 Watts33 FM TX#2 RF OUT:-0.0027 +0.001257 +0.0000730 Watts34 PSK TX HPA Temp+101.05 -0.6051 0.000 Deg. C35 +Y Array Temp: +101.05 -0.6051 0.000 Deg. C36 RC PSK HPA Temp+101.05 -0.6051 0.000 Deg. C37 RC PSK BP Temp:+101.05 -0.6051 0.000 Deg. C38 +Z Array Temp: +101.05 -0.6051 0.000 Deg. C 39 S band TX Out: -0.0451 +0.00403 0.000 Watts3A S band HPA Temp+101.05 -0.6051 0.000 Deg. CADC Equations: V = 0.01028 N - 0.05138 N = 97.31 V +5.000------------------------------Date: Tue May 01 12:04:23 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Mon Apr 23 21:18:56 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 12:03:53 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa05949; 23 Apr 90 21:16 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id fb09731; 23 Apr 90 19:29 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id ae16278; 23 Apr 90 19:34 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa16248; 23 Apr 90 19:26 BST> Received: by ucsd.edu; id AA10927> sendmail 5.61/UCSD-2.0-sun> Sat, 21 Apr 90 04:00:07 -0700 for brian> Received: by ucsd.edu; id AA10914> sendmail 5.61/UCSD-2.0-sun> Sat, 21 Apr 90 04:00:05 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004211100.AA10914@ucsd.edu>> Date: Sat, 21 Apr 90 04:00:02 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #3> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Sat, 21 Apr 90 Volume 90 : Issue 3> > Today's Topics:> Fixmail 1.09 now posted :128.104.198.22> Innovators need thick skin (was: CP/M sofware...)> KISS Mode -- How Fast? (2 msgs)> Microwave oscillator sources (3 msgs)> USENET at Dayton Hamvention> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: Fri, 20 Apr 90 08:09:59 GMT> From: pat@pgd.adp.wisc.edu (Pat Davis)> Subject: Fixmail 1.09 now posted :128.104.198.22> To: packet-radio@ucsd.edu, tcp-group@ucsd.edu> > Fixmail 1.09 is posted on pgd.adp.wisc.edu for anonymous FTP.> 1.09 fixes a bug that would allow FIXMAIL to END/TERMINATE if/when there> was no more mail to censor.. That's right, censor.. Fixmail,> by Bryan HI-Q Biggers N9GBJ, manages SMTP mail from NET/NOS. It has some> very attractive features. FIXMAIL is Desqview "aware"..> > The file you want is FIXM109.ZIP, you might find more helpful files in> FIXM106.ZIP too...> > KD9UU> > ------------------------------> > Date: 20 Apr 90 16:18:00 GMT> From: att!cbnewsh!n2dsy@ucbvax.Berkeley.EDU (j.gordon.beattie)> Subject: Innovators need thick skin (was: CP/M sofware...)> To: packet-radio@ucsd.edu> > > First and foremost, plain old AX.25 text streams will be with us for> > a long, long time. Its the lowest common denominator for just about all of > > amateur packet radio. It is also the simplest packet "mode" to understand:> > just "CONNECT" and off you go. Given these two facts, I claim that plain> > old AX.25 text streams are and will continue to be the most popular "mode".> > I can agree with this point that the simple "CONNECT and go" user (POATS user)> is, and will be the major user type in the packet network for a long time > to come.> > I would just like to point out that the ROSE X.25 Switch software > supports "POATS" users simply by appearing to the user as a pair> of digipeaters. There's no extra user hardware or software to > buy/install/configure/hassle-with to use a ROSE X.25 network. > > In fact, the ROSE X.25 Switch will route you through the network without> the hassle that the NoNodes put you through of "connect, connect,> connect..connect, voila..the destination!" This is somewhat akin> to asking a sequence of "n" telephone operators to route your > telephone call...computers do a better job of this in less time!> > As far as interoperability goes, you can call between a NoNodes> network and a ROSE X.25 network by simply connecting using the> standard connection method for either network (C Destination v ...).> > TCP/IP is no problem to a ROSE X.25 network either: just make > a level 2 call through a ROSE X.25 network (like any POATS user)> and send your IP datagrammes through the network...simple!> > In any case, I'd like to see more integration of networks, but> let's first realize that simplicity of a tool (or a network)> can often be the most attractive feature to users.> > 73,> Gordon Beattie, n2dsy> n2dsy@hou2d.att.com> +1.201.615.4168> > ------------------------------> > Date: 20 Apr 90 01:16:22 GMT> From: bionet!hayes!usenet@apple.com> Subject: KISS Mode -- How Fast?> To: packet-radio@ucsd.edu> > I have one of the April 90 versions of NOS running on two different> PC compatibles. I can't seem to communicate reliably faster than 4800> baud. One machine is a 12 MHZ 286 with an 8250B. The other machine is a> laptop with a 4.77 MHz 80C88 and I presume the ASIC equivalent of an 8250.> Hardwired connection between the two machines with KISS mode at 4800 baud> seems reliable but 9600 baud is very spotty.> > Now the interesting thing is that the 286 machine is known to operate> to at least 38400 with an unsophisticated interrupt routine written in Turbo> Pascal. The laptop operates well at 9600 baud with various terminal emulators.> Why is NOS slower and what can I do about it? The 8250B in the 286 machine> is socketed but there is little I can do with the laptop, which is probably> the culprit. Mostly I want to know how fast can I run KISS mode on the 286> machine.> > The reason I bring this up is that I am working on a 2 chip packet> assembler/disassembler that is good to 1 Mbps (half-duplex) but I need a> decently fast way to interface it to the host computer. 4800 baud isn't> good enough.> > Philip Munts N7AHL> University of Alaska, Fairbanks> > ------------------------------> > Date: 21 Apr 90 05:47:43 GMT> From: ka9q.bellcore.com!karn@bellcore.com (Phil Karn)> Subject: KISS Mode -- How Fast?> To: packet-radio@ucsd.edu> > In article <1990Apr20.022915.8287@hayes.fai.alaska.edu> ftpam1@acad3.fai.alaska.edu writes:> > > I have one of the April 90 versions of NOS running on two different> >PC compatibles. I can't seem to communicate reliably faster than 4800> >baud.> > Fetch the latest stuff off flash.bellcore.com using anonymous ftp and> give it a try. If it isn't any better, let me know. I've been doing some> work on the 8250/16550 driver lately that should help improve performance> and I want to make sure that I haven't already fixed your problem before> looking at it again.> > Phil> > ------------------------------> > Date: 20 Apr 90 14:04:33 GMT> From: rochester!rit!cci632!dvh@rutgers.edu (David Hallidy)> Subject: Microwave oscillator sources> To: packet-radio@ucsd.edu> > In article <871@tsdiag.ccur.com>, davet@tsdiag.ccur.com (Dave Tiller N2KAU) writes:> > > > Has anyone had any experience with converting a microwave oven > > magnetron to Amateur use? Are there any problems with needing to> > 'bend' it down slightly from 2.450 GHz to make it into the Ham> > band? What are the power requirements? I noticed that MCM sells> > replacement magnetrons - could this be a source for cheep packet> > backbone oscillators? Inquiring minds gots'ta know...Any help> > would be greatly appreciated.> > > > PS - I don't intend to run one of these at ~600-1200 Watts aimed> > at the general public. A couple of Watts (<10) would be more> > resonable.> > Dave-> > Check out _RF DESIGN_ for March of 1989, there was an article about> using a microwave oven as a high powered RF source for 2450 MHz> ATV. It will work down into the ham band at the upper end of the> "13cm" segment- from 2390 to 2450 MHz. Problem is, I don't think> the stability of the mag will be very good- this may not be critical> in your application, certainly for wideband TV experimenting it's> probably not too important.> > The other problem is, you mentioned wanting to run low power- I> don't think you can with this type of setup. A magnetron, by its> nature, generates high levels of RF. It's a self excited device, and> if you try to just "lower the voltage" or reduce the intensity of> the magnetic field around the tube, it just won't oscillate. The way> the microwave ovens run at "reduced" power is to turn the tube on> and off for varying periods of time- this has the effect, on food,> of reducing the heating by reducing the amount of time the food is> exposed to the RF. The level of RF when the mag is running is always> at full power (>600 Watts, usually).> > I do think it might be worthwhile to experiment with injection-locking> of the magnetron to stabilize its output frequency. This would make> for a very cheap source of extremely high power on the band, useable> for modes other than wideband TV. Let me know if you try any of this> and any success (or failure) you may have.> > Hope this helps you some.> > 73 Dave H. KD5RO/2> > ------------------------------> > Date: 20 Apr 90 20:01:56 GMT> From: swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!t urnkey!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.c om!dana@ucsd.edu (Dana H. Myers)> Subject: Microwave oscillator sources> To: packet-radio@ucsd.edu> > In article <871@tsdiag.ccur.com> davet@tsdiag.ccur.com (Dave Tiller N2KAU) writes:> >> >Has anyone had any experience with converting a microwave oven > >magnetron to Amateur use? Are there any problems with needing to> >'bend' it down slightly from 2.450 GHz to make it into the Ham> >band? What are the power requirements? I noticed that MCM sells> >replacement magnetrons - could this be a source for cheep packet> >backbone oscillators? Inquiring minds gots'ta know...Any help> >would be greatly appreciated.> > Look in the 1989 index for 73 magazine - a cover article detailed> conversion of a surplus oven to ATV/FM use, a $200 700W exciter !> I'll try to get the date or possibly someone else can post it.> > > ***************************************************************** > * Dana H. Myers WA6ZGB | Views expressed here are *> * (213) 337-5136 | mine and do not necessarily *> * dana@locus.com | reflect those of my employer *> ***************************************************************** > > ------------------------------> > Date: 21 Apr 90 02:15:45 GMT> From: usc!pollux.usc.edu!kjh@ucsd.edu (Kenneth J. Hendrickson)> Subject: Microwave oscillator sources> To: packet-radio@ucsd.edu> > In article <871@tsdiag.ccur.com> davet@tsdiag.ccur.com (Dave Tiller N2KAU) writes:> >Has anyone had any experience with converting a microwave oven > >magnetron to Amateur use?> > It's already been done. Somebody in Illinois did it on ATV. There was> a skimpy write-up about it in one of the RF trade rags about Fall of> '88. I can't remember which magazine, but I think it might have been> "RF & Microwaves". Don't waste your time looking for the magazine,> however, there wasn't any more information in it than I have posted> here. It was kind of like the ARRL's current publication of microwave> information in QST.> > Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh> > ------------------------------> > Date: 20 Apr 90 02:34:52 GMT> From: usc!cs.utexas.edu!execu!sequoia!attdso!ssc!tad@ucsd.edu (Tad Cook)> Subject: USENET at Dayton Hamvention> To: packet-radio@ucsd.edu> > Just ONE more reminder. . . .If you are going to the Dayton Hamvention,> USENET folks will be getting together at Stouffers on Friday night in> suite 425, at the DIGITAL SUITE. Stouffers is downtown at Fifth and> Jefferson.> > See you there!> > > Tad Cook> Seattle, WA> Packet: KT7H @ N7HFZ.WA.USA.NA> Phone: 206/527-4089 > MCI Mail: 3288544 > Telex: 6503288544 MCI UW > USENET:...uw-beaver!sumax!amc-gw!ssc!tad> or, tad@ssc.UUCP> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 12:08:24 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Mon Apr 23 23:52:08 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 12:07:58 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa12342; 23 Apr 90 23:50 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id rp09731; 23 Apr 90 22:11 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id ab18786; 23 Apr 90 20:36 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa18731; 23 Apr 90 20:32 BST> Received: by ucsd.edu; id AA14795> sendmail 5.61/UCSD-2.0-sun> Mon, 23 Apr 90 04:00:07 -0700 for brian> Received: by ucsd.edu; id AA14783> sendmail 5.61/UCSD-2.0-sun> Mon, 23 Apr 90 04:00:04 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004231100.AA14783@ucsd.edu>> Date: Mon, 23 Apr 90 04:00:02 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #5> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Mon, 23 Apr 90 Volume 90 : Issue 5> > Today's Topics:> Has NOS been ported to the Atari ST?> TAPR TNC-2 for sale> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 23 Apr 90 01:34:39 GMT> From: swrinde!zaphod.mps.ohio-state.edu!samsung!umich!pmsmam!pmsmam.uuc p!wwm@ucsd.edu (Bill Meahan)> Subject: Has NOS been ported to the Atari ST?> To: packet-radio@ucsd.edu> > The subject line says it all.> > If not, why not? Micro-RTX could easily provide the requisite multi-tasking> kernel if the one that's included in the NOS source isn't suitable.> > We ST users wait with bated breath! (especially we who still have older> 520's :-) :-} )> -- > Bill Meahan | UUCP: uunet!mailrus!umich!pmsmam!wwm> | snail: 128 Factory St., Ypsilanti, MI 48197> #include <disclaimer.std> | voice: +1 313 484 9320> /* witty */ |packet: wa8tzg @ wa8ooh.mi.usa.na> > ------------------------------> > Date: 22 Apr 90 06:54:54 GMT> From: sumax!ole!ray@beaver.cs.washington.edu (Ray Berry)> Subject: TAPR TNC-2 for sale> To: packet-radio@ucsd.edu> > I have a TAPR TNC-2 built from a kit several yrs back I'd like to> sell. It was built and tested, aligned, etc., but never used. The firmware> is at whatever level existed at the time the TNC-2 first shipped. > I'd like $100 for this thing. I've never been active in packet,> so I don't know if this thing is already obsolete or what... if the price > sounds too high, please make an offer. Thanks.> -- > Ray Berry kb7ht uucp: ...ole!ray CIS: 73407,3152 /* "inquire within" */> Seattle Silicon Corp. 3075 112th Ave NE. Bellevue WA 98004 (206) 828-4422> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 12:15:30 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Tue Apr 24 06:54:29 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 12:15:03 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa00189; 24 Apr 90 6:50 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id fm22320; 24 Apr 90 4:59 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id ax28088; 24 Apr 90 3:19 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa27762; 24 Apr 90 2:13 BST> Received: by ucsd.edu; id AA26011> sendmail 5.61/UCSD-2.0-sun> Sun, 22 Apr 90 04:00:08 -0700 for brian> Received: by ucsd.edu; id AA25993> sendmail 5.61/UCSD-2.0-sun> Sun, 22 Apr 90 04:00:04 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004221100.AA25993@ucsd.edu>> Date: Sun, 22 Apr 90 04:00:02 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #4> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Sun, 22 Apr 90 Volume 90 : Issue 4> > Today's Topics:> Innovators need thick skin> Microwave oscillator sources> Packet-Radio Digest V1 #3> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 21 Apr 90 22:42:34 GMT> From: sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!k d4nc!ke4zv@ucsd.edu (Gary Coffman)> Subject: Innovators need thick skin> To: packet-radio@ucsd.edu> > In article <22370@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes:> >> >But be that as it may, you are getting somewhat closer to the truth. As> >I said before, TCP/IP has little to offer unless you have a computer.> > WORDS TO LIVE BY! I would also add that packet in general has little to> offer unless you have a computer. Contentless keyboard QSOs crawling> through the network have little value after the thrill of doing it once> wears off.> The real value of packet radio is connecting computers together in a> network to perform a useful function. Things like Email, Remote File> Sharing, and distributed computing are possible only with reliable> end to end data transfer. Our current slow network already carries> an important amount of Email. MUCH faster networks will make the other > things realistic. And there's the rub, little Terminal Node Controllers> aren't capable of supporting faster modems. In fact, TERMINAL Node> Controller is a concept whose time is past. It's time to return to> the PAD (Packet Assembler Disassembler) now that it is a single chip> (8530) in the computer and attach that to a truly high speed modem.> High speed modems are available and affordable NOW at 56kb and soon> at megabit rates. > > LET'S NOT FALL INTO THE TRAP OF HITCHING OURSELVES TO THE DEAD PAST> WITH A NETWORK DESIGN THAT CANNOT EASILY MIGRATE TOWARD OUR ULTIMATE> GOALS.> > Gary KE4ZV> > ------------------------------> > Date: 20 Apr 90 00:27:03 GMT> From: snorkelwacker!bu.edu!mirror!otto!jimi!unsvax!storkus@think.com (Mike Storke (N7MSD))> Subject: Microwave oscillator sources> To: packet-radio@ucsd.edu> > I'd also be very interested in knowing if you can convert a microwave oven> magnetron to amateur bands. Unlike the guy who originated this, I *WOULD* use> it at or near it's full rated power. This would be used for long-haul packet> links (~200+ miles, to be exact: Las Vegas-Bishop, California-Reno; a 2M link> currently exists along this route, but it's too loaded down). Any info would> be appreciated. Note that these links are all on top of mountains > 8500 ft.> high. Thanks and 73's, Mike, N7MSD> P.S. I got a hold of a surplus house that has traveling wave tubes for 2-4 gigs> and 8-9.6 gigs. Can the 8-9.6 be used at the 10 gig ham band? A friend of> mine said no because they are *very hard* to tune-he says they're something> like a helical antenna at their center frequency. Any info appreciated as> always, Mike> > ------------------------------> > Date: Sat, 21 Apr 90 22:31 EST> From: LARRY KNEHR <CSCON104@uoft02.utoledo.edu>> Subject: Packet-Radio Digest V1 #3> To: Packet-Radio@UCSD.EDU> > > > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 12:36:08 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Tue Apr 24 15:44:27 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 12:35:53 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa02220; 24 Apr 90 14:55 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id al06530; 24 Apr 90 11:49 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id ab11817; 24 Apr 90 13:04 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa11692; 24 Apr 90 13:00 BST> Received: by ucsd.edu; id AA20953> sendmail 5.61/UCSD-2.0-sun> Tue, 24 Apr 90 04:00:13 -0700 for brian> Received: by ucsd.edu; id AA20939> sendmail 5.61/UCSD-2.0-sun> Tue, 24 Apr 90 04:00:10 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004241100.AA20939@ucsd.edu>> Date: Tue, 24 Apr 90 04:00:06 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #6> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Tue, 24 Apr 90 Volume 90 : Issue 6> > Today's Topics:> Apple II Software for RTTY and Facsimile ?> faster modems> Getting Started!?> MFJ 1274 TNC for sale> pulse on X-band (2 msgs)> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 23 Apr 90 15:29:50 GMT> From: ncs.dnd.ca!asterix.drev.dnd.ca!louis@rutgers.edu (Louis Demers)> Subject: Apple II Software for RTTY and Facsimile ?> To: packet-radio@ucsd.edu> > (I am posting this for a collegue, hope this is the right place)> > A friend is looking for software for his Apple II+ to receive> Facsimile (he already has the interface to his radio) for example> of wheather maps. He would like also a piece of software that > implements the RTTY protocol.> > If software is unavailable, we would settle for the algorytms.> > Please respond through Email as this site doesn't receive any of the> rec. groups.> > PPS: Please don't laugh, this is all foreign to me.> -- > | Louis Demers | DREV, Defence Research Establishment,Valcartier |> | louis@asterix.drev.dnd.ca | POBox 8800, Courcelette,Quebec, CANADA, G0A 1R0 |> | (131.132.48.2) | Office: (418) 844-4424 fax (418) 844-4511 |> +---------------------------+------------------------------------ -------------+> > ------------------------------> > Date: Mon, 23 Apr 90 14:34:34 MST> From: sarrel%miranda.uucp@moc.Jpl.Nasa.Gov (Marc Sarrel)> Subject: faster modems> To: packet-radio@ucsd.edu> > Well, there has been some discussion recently here about how most hams> with TNCs are using horribly outdated and slow equipment. 1200 baud> seems to be the lowest common denominator. And, sometimes I get the> feeling that some hams don't have much desire or incentive to move to> higher baud rates. In fact, I spent a while talking to the "packet> expert" at a local amateur radio store recently. I asked him about> some TNC that had a 2400 baud modem vs one that had a 1200 baud modem.> I asked wether 2400 would catch on, given my experience with land line> modems where everyone was starved for speed. He said "no." His> reasons seemed pretty fuzzy to me, but he seemed to claim that 1) 2400> baud wouldn't catch on because everyone already has 1200 baud modems,> 2) 1200 baud seemed fast enough to him, and 3) that 2400 baud wasn't> _really_ twice as fast as 1200 because the extra speed was used> inefficiently. (But don't hold me to that, this was a while ago.)> > Anyway, my question is this: How can we "hams in the know" encourage> the use of faster and more effecient modems on the airwaves, given> that we agree that "faster is better." One of this guy's arguments> holds weight in that there is a lot of "hardware inertia" out there.> > Specifically what kind of faster and more efficient modems are> available and suitable for packet-radio? How fast is fast? 9600?> 19.2K? 56K? How much extra bandwidth do these faster modems require?> What about FCC regulations on speed?> > Is there such a thing as auto baud rate recognition that would allow a> digipeater to work a several different speeds with different stations> on the same frequency? This would allow a smoother transition to> faster modems by giving people incentive to buy them without> immediately obsoleting everyone's 1200 baud equipment?> > Would it be a good idea to set up digipeaters that work on several> different speeds (and frequencies) as a way of encouraging higher baud> rates?> > Just curious,> > --marc> -=-> Marc A. Sarrel> N7OLI> sarrel%miranda.uucp@moc.jpl.nasa.gov | "Oh, _lightweight_ Alpaca..."> ..!sun!sunburn!miranda!sarrel | -Blanche DuBois> > ------------------------------> > Date: 23 Apr 90 08:32:11 GMT> From: usc!sdsu!crash!jburnes@ucsd.edu (Jim Burnes)> Subject: Getting Started!?> To: packet-radio@ucsd.edu> > Hi!> > A friend of mine and I want to get into packet radio. We are not hams.> We are willing to jump through the necessary hoops. We both are software/> hardware engineers and understand various amounts of circuit theory.> We would like to know:> > 1. What is the highest speed modem usable on standard packet frequen-> cies? I have heard of 9600 bps modems being used. What about> Telebit Trailblazer spread-spectrum type modems?> > 2. What class of ham liscense is necessary to run packet? What tests> and theory must we have to get this liscense?> > 3. How much would a rig capable of 2400 bps operation cost (used)?> I already have a 386 machine. I would like to upgrade to national/> international coverage (if that is applicable) and also to higher> speeds.> > 4. I have heard that you cant upload messages/files to someones node> and then have that information automatically forwarded through> a network. Someone told me humans had to intervene. That sounded> silly. Kinda defeats the whole purpose of a network, no? Sorry..> since I'm mostly a pc hacker I not quite sure how to ask a lot of> questions without sounding naive.> > 5. What is a good book to get started with?> > 6. It seems like I have been trying to get into packet/ham for the last> 5 years or so and always fail to clear the morse/test hurdles. I'd> like to remedy this as soon as possible. Any ideas for making the > transition easier?> > Yours in communications,> Jim Burnes> > -------------------> I do not beleive in 'isms> I think, on the whole, 'isms are a bad thing> > Ferris Buehler (paraphrased)> --------------------> > ------------------------------> > Date: 24 Apr 90 00:53:37 GMT> From: psuvm!mls129@psuvax1.cs.psu.edu (Michael L. Sensor)> Subject: MFJ 1274 TNC for sale> To: packet-radio@ucsd.edu> > For sale once again:> > MFJ 1247 HF/VHF TNC. Almost never used (yes it works).> > LED tuning display. Compatible with MFJ WeFAX software (for PCs and> Macintoshes). Personal mailbox.> > Comes with 5-lead RS232 cable and homebrew connector to use on Icom IC2AT.> > Bought for $150.00 at Dayton. Asking $125.00. May trade or bargain.> > For more info:> > Mike Sensor KD3LR / AFA1UP> Box 134 Oak Hall> Penn State Altoona Campus> Altoona PA 16601-3760> (814) 949-5439> UNTIL MAY 4!> > 2406 E 32 St> Erie PA 16510-2702> (814) 899-8261> AFTER MAY 4!> > C'mon, MFJ isn't *that* bad!> > Mike Sensor MLS129 @ PSUVM> > ------------------------------> > Date: 24 Apr 90 01:28:17 GMT> From: usc!pollux.usc.edu!kjh@ucsd.edu (Kenneth J. Hendrickson)> Subject: pulse on X-band> To: packet-radio@ucsd.edu> > I received some email from W3OTC that I responded to, and thought a> posting would be appropriate. Here it is:> > % From: Robert Carpenter <rc%cmr.ncsl.nist.gov@usc.edu>> > % Am I missing something? It seemed to me that you wouldn't benefit from a> % low duty cycle when fighting a large path loss. I would think that some> % synchronous system, with correlation detection of some sort, would be the> % best bet. Of course you COULD build a receiver that just listened during> % the narrow pulses to ignore the in-between noise. I'd also worry a bit> % about pulse-spreading due to multipath. Maybe a pseudo-random scheme would> % be a good approach, but would likely have a mid-to-high duty cycle, and thus> % not be pulse.> > It is a possibility to build a receiver that only listens when a pulse> is supposed to occur, but that wasn't necessarily what I was thinking> about. The advantage of using the high peak power of a pulse is that it> would be EASILY DETECTABLE even with high path loss. This means that> (in theory) you could set up a data link much like CW is used with the> human ear: the presence of a pulse has one meaning, and the absence of a> pulse has another. There is probably even a better way to do it:> consider what you could do if you were to phase modulate the pulses. In> other words, control the time delay or latency between pulses. A short> time delay could mean a 0 bit, and a long delay could mean a 1 bit.> > % Or do you have a good source of low duty cycle 10 GHz power, and want to> % build a system around it?> > No, I don't have a 10 GHz pulse source, but they are available. Now if> we could only use them legally ...> > % Pardon the confused questions, but I don't normally think of low-duty-cycle> % pulse transmission and weak signal operation as going together.> > Most people don't. Certainly, I'm not suggesting that real time> communications like voice be sent this way. I'm merely proposing that> this might be a good use for part of our microwave spectrum. The packet> guys are in great need of high-speed inter-city links (among other> things).> > % Bob W3OTC> > % PS. Look at the picture of the 10 GHz SSB PHONE station in QST (I thought in> % W3XO's column, but can't find it.) I've seen and heard '3XO's video of it> % operating over a non-line-of-sight 25 mile path with excellent sigs.> % The power output was in the 20 - 100 mW range, I think.> > I've done better than 40 miles over non-line-of-sight paths with only> 10 mW and CRUDDY WIDEBAND FM! This was with 2 foot dish antennas on> both ends of the path at X-band. Still, I'm not pooh-poohing their> efforts; I'm just trying to show that even with simple cheap equipment> you can do a lot more than most people expect in the SHF and EHF> spectrum.> > Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh> > ------------------------------> > Date: 24 Apr 90 01:41:49 GMT> From: usc!pollux.usc.edu!kjh@ucsd.edu (Kenneth J. Hendrickson)> Subject: pulse on X-band> To: packet-radio@ucsd.edu> > In article <1250147@hpnmdla.HP.COM> glenne@hpnmdla.HP.COM (Glenn Elmore) writes:> % Ken,> % I don't think pulse privileges really are that much of an issue in> % preventing effective use of the band. As I see it, the main advantage would be> % in using surplus hardware.> > Yes, this would be the advantage. I'm not suggesting that we have an> undue hardship with the pulse restriction; I am suggesting that it is> arbitrary and capricious, and that if we didn't have the restriction,> there would be one more possible way that we could effectively> communicate on the band.> > % However, moderate power narrowband > % equipment is no longer a difficult proposition. Very long links and> % OTH links require optimum use of the resources; reasonably effic ient> % use of the spectrum (bps/Hz numbers) and highly directional beams to> % avoid waste and QRM; as well as physically larger receive antenna apertures> % to recover the information. Even so I suspect that for reliable networks and > % comm. channels we are likely to end up with a larger number of shorter LOS > % links instead of long haul OTH ones.> > This may be true. However, I don't think anybody has ever experimented> with using high-power low-duty-cycle signals to build a packet switched> microwave network. My idea might not pan out to anything, but on the> other hand, how will we know unless somebody tries to do it?> > % Troposcatter is a fairly predictable > % propagation mechanism at 10 GHz (see my description of an> % experience with it on a 400+ mile path during the 1987 10 GHz terrestrial > % DX record outing in December 1987 QST) but long haul links are inherently> % lossier and less reliable than shorter LOS ones.> % I strongly agree that we need to use our microwave resources and in> % particular 10 GHz but I think we will end up finding that for efficient> % use of our amateur resources we will start looking more like the telephone> % companies and common carrier folks when we solve the backbone problem.> % > % Glenn Elmore -N6GN- N6GN @ K3MC glenn@n6gn.ampr.org glenne@hpnmd.hp.com > > Sure, we might wind up looking like the telephone companies. Maybe they> have already tried the pulse idea. On the other hand, I have never> heard of it. If nobody has yet tried it, to see what the results are,> what is wrong with us amateurs giving it a try. It just might be> useful.> > Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 15:00:22 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Thu Apr 26 17:52:50 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 15:00:00 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa01499; 26 Apr 90 17:46 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id aa09309; 26 Apr 90 16:06 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id ac10941; 26 Apr 90 17:16 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa10889; 26 Apr 90 17:13 BST> Received: by ucsd.edu; id AA19048> sendmail 5.61/UCSD-2.0-sun> Thu, 26 Apr 90 08:28:37 -0700 for brian> Received: by ucsd.edu; id AA19043> sendmail 5.61/UCSD-2.0-sun> Thu, 26 Apr 90 08:28:36 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004261528.AA19043@ucsd.edu>> Date: Thu, 26 Apr 90 08:27:52 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #9> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Thu, 26 Apr 90 Volume 90 : Issue 9> > Today's Topics:> DEC Rainbow> DOVE Satellite> faster modems> How decipher DOVE telemetry?> TAPR DCD on Heath 4040> US Navy and packet radio> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 25 Apr 90 19:53:26 GMT> From: swrinde!cs.utexas.edu!samsung!xylogics!bu.edu!m2c!wpi!tmurphy@ucs d.edu (Tom [Chris] Murphy)> Subject: DEC Rainbow> To: packet-radio@ucsd.edu> > With any luck, I'll be getting a Technician licence this weekend and> as soon as it comes in the mail, I plan on trying some work with packet> radio. I may be inheriting a DEC Rainbow, and was wondering what software> exists for it to do TCP based work, primarily mail although telnet and> ftp would be nice also. Thanks for the help in advance!> > Tom Murphy> tmurphy@wpi.wpi.edu> > ------------------------------> > Date: 25 Apr 90 15:06:01 GMT> From: idacrd!mac@princeton.edu (Robert McGwier)> Subject: DOVE Satellite> To: packet-radio@ucsd.edu> > In article <9004241908.AA14576@ucsd.edu>, by KEVIN@CALSTATE.BITNET:> > I have been monitoring for DOVE for a coupla days, and haven't heard a peep.> >> > Kevin:> > It is alive and well downlinking on 2401.100 Mhz +/- an unbelievable amount> of doppler. There is no way the straight calculation can be as impressive> as trying to track that stuff and copy data! I am reloading its software> and its gonna do speech when it comes back on.> > Bob> > -- > _________________________________________________________________ ___________> My opinions are my own no matter | Robert W. McGwier, N4HY> who I work for! ;-) | CCR, AMSAT, etc.> ----------------------------------------------------------------- -----------> > ------------------------------> > Date: 26 Apr 90 02:10:11 GMT> From: sun-barr!newstop!texsun!texbell!splut!jay@apple.com (Jay "you ignorant splut!" Maynard)> Subject: faster modems> To: packet-radio@ucsd.edu> > In article <22526@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes:> >I have done a *lot* of thinking about this problem. Given that amateur radio> >is a voluntary, personally funded activity, you can't force hams to buy new> >hardware. But there's another approach: establishing a frequency allocation> >policy that encourages the use of more efficient modulation and frequency> >reuse techniques. The more efficient your proposed use of the spectrum, the> >more likely you are to get an allocation.> > >Amateur frequency coordinators now follow a first-come first-served policy,> >and this *must* change. In many areas like Los Angeles and New York, the> >VHF/UHF bands are nearly full with FM repeaters and conventional 1200 baud> >packet, and there is little room to experiment with newer, more efficient> >techniques.> > (dig, dig...ok, I found it.) [putting on President, Texas VHF-FM Society hat]> > You've beat this drum before, and I've argued it before. While your idea> has merit in a perfect society, it *cannot* work in the real ham world.> > Frequency coordinators now serve in an advisory capacity. You'd like us> to tell people who have coordinations and are currently operating> repeaters on frequencies where they do not experience regular,> significant interference (the standard which coordinators try to> maintain) that, all of a sudden, the rules have changed, and that they> must either shut down entirely, or accept unheard-of, and previously> unacceptable, levels of interference.> > They wouldn't listen to us.> > Instead, they'd keep on operating on what they perceive as *their*> frequency. You know that they don't own it, I know it, but they don't -> and they're the only ones with the power to make such a change work.> > Frequency coordination and spectrum management isn't just a technical> problem, but a highly political one as well. Come up with a way to> accomplish your goal that *can* be accepted by the population of current> FM voice system operators and users, and your wish will come true, and> I'll sign up to promote it. This isn't the school debate society,> though, where changes can be implemented by fiat. You must account for> the mechanisms involved in implementing the change, and _that_ is where> your problem lies.> > -- > 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, RIP. It was nice knowing ya +----------------------------------------> "Flying is a lot more fun than being in the Senate." -- Senator Jake Garn> > ------------------------------> > Date: 25 Apr 90 22:20:31 GMT> From: deimos.cis.ksu.edu!harris.cis.ksu.edu!mac@uunet.uu.net (Myron A. Calhoun)> Subject: How decipher DOVE telemetry?> To: packet-radio@ucsd.edu> > My packet station can hear DOVE's telemetry;> now I'd like to know what it means.> > Is there a source for software to decipher the> hex stuff into meaningful-to-humans information?> > Please reply by email.> --Myron.> --> # Myron A. Calhoun, Ph.D. E.E.; Associate Professor (913) 539-4448 home> # INTERNET: mac@harris.cis.ksu.edu (129.130.10.2) 532-6350 work> # UUCP: ...{rutgers, texbell}!ksuvax1!harry!mac 532-7004 fax> # AT&T Mail: attmail!ksuvax1!mac> > ------------------------------> > Date: 25 Apr 90 20:27:41 GMT> From: sdd.hp.com!zaphod.mps.ohio-state.edu!sunybcs!uhura.cc.rochester.e du!rochester!kodak!eastman!hpcore!gerwitz@ucsd.edu (Paul Gerwitz)> Subject: TAPR DCD on Heath 4040> To: packet-radio@ucsd.edu> > I am posting this for someone who does not have net access. Please send> email replies to him directly at 'uunet!atexnet!kodak!eastman!dieter'.> > ----------------------------------------------------------------- ------> > Subject: HELP w/ TAPR DCD Upgrade> > I recently built a TAPR 2211 DCD upgrade kit. It is supposed to enhance DCD> operation.> > After installing the kit in my Heath HD-4040, the DCD light in fact does seem> to react much better (less falsing, more constant when it does lock on). The> only problem is now my TNC will TRANSMIT EVEN WHEN THE DCD LIGHT IS ON !!!! I> have checked the assembly and the value of most of the components. I cannot> imagine how the thing can transmit with the DCD light on. It's supposed to> inhibit transmit isn't it ? If anybody has any experience with this PLEASE> HELP !!! Leave a message, or call Mark at (716) 723-0227. Thanks> > ----------------------------------------------------------------- -------> --> +---------------------------------------------------------------- ------------+> | Paul F Gerwitz WA2WPI | SMTP: gerwitz@kodak.com |> | Eastman Kodak Co | UUCP: ..rutgers!rochester!kodak!eastman!gerwitz |> +---------------------------------------------------------------- ------------+> > ------------------------------> > Date: 25 Apr 90 16:08:00 EDT> From: "SWEIGERT, DAVID" <dsweigert@paxrv-nes.navy.mil>> Subject: US Navy and packet radio> To: "packet-radio" <packet-radio@wsmr-simtel20.army.mil>> > The U.S. Navy has commissioned a multi-media test of ship-shore> data communications. Particular media under test:> > o HF communications> o Fleet SATCOM (2400 bit/second US Navy satellites)> o INMARSAT Commercial satellite channels> > It is believed the HF communications portion shall include a packet radio> test.> > SPAWAR Code PMW-156 (Capt. Joesph Price, USN) is coordinating the test> at the direction of VADM Jerry O. Tuttle, USN, OPNAV Code 094. The testing> agent shall be the Naval Engineering Center at Vallejo, CA. The test platforms> shall be ships assigned out of San Diego, CA. The test is lated to begin> this summer.> > Mission support data shall be transferred from an aircraft carrier to shore> based NARDAC, Naval Regional Data Automation Center.> > > cheers...> > WB9VKO> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 15:15:49 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Fri Apr 27 13:29:54 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 15:15:27 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa05720; 27 Apr 90 13:20 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id af04978; 27 Apr 90 12:04 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id aa13232; 27 Apr 90 12:56 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa13189; 27 Apr 90 12:54 BST> Received: by ucsd.edu; id AA20478> sendmail 5.61/UCSD-2.0-sun> Fri, 27 Apr 90 04:00:10 -0700 for brian> Received: by ucsd.edu; id AA20467> sendmail 5.61/UCSD-2.0-sun> Fri, 27 Apr 90 04:00:06 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004271100.AA20467@ucsd.edu>> Date: Fri, 27 Apr 90 04:00:03 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #10> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Fri, 27 Apr 90 Volume 90 : Issue 10> > Today's Topics:> Ham Packet BBS on ATT UNIX PC?> Universal M-610 wanted> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 27 Apr 90 02:31:18 GMT> From: zaphod.mps.ohio-state.edu!math.lsa.umich.edu!sharkey!lopez!flash@ tut.cis.ohio-state.edu (Gary Bourgois)> Subject: Ham Packet BBS on ATT UNIX PC?> To: packet-radio@ucsd.edu> > Here's the deal. I am the system administrator of a Public Access Unix > BBS, and have been running a BBS at the same phone number since 1983. > Being a consultant by trade, and doing all of my work at home, I can run > the BBS, and also play ham radio day and night. I have a speaker from > the ham rig in my computer room, and I have a video feed from the BBS > monitor in my ham shack. The two hobbies sort of meld. I talk with > other UNIX people on the ham bands, and send email to ham friends on > USENET.> > I am obsessive compulsive, I admit it and I use it to an advantage.> > I do not have a packet system. Not today. I always managed to put it > off.> > The PBBS that serves this area of Upper Michigan is going to be going > down soon. They are looking for someone else to run one.> > A ham from Lower Michigan said he would donate a TNC. I agreed to supply > what equipment I can, and am mulling over what is the best way to go. I > have an old XTAL type 2m rig and a spare antenna to kick into the project.> > I also have an AT&T UNIX PC with a 20 meg hard drive. Not much, but > probably enough to run a PBBS.> > Why the UNIX PC? (also known as a 7300, or 3b1)> > Well I got to thinking how easy it would be, while reading rec.ham.radio > on the console of the landline BBS, I could forward articles to the > Packet BBS with ease, using UUCP.> > Has anyone ever done this?> > Would the 3b1 be up to the job? If so, I will also donate that to the > project. It would be a great service to the hams of Northern Michigan to > have selected articles from USENET ported over to our local PBBS. I will > not do it if I have to haul floppies up a flight of stairs (The USENET > site is on the ground floor, and my hamshack is one floor up).. BUT > using UUCP would be a breeze.> > Our own BBS software on lopez is locally written, so I can have any mods > I want tossed in simply, and many I can write myself (The software > STARBASE, is very configurable, and will eventually be made public)...> > The trick will be to link everything together. I am sure it could be > done with a XENIX type PC, but that route is beyond our meager budget.> > Any ideas, thoughts, ponderings, musings, experiences welcome.> > Thanks, es 73> > Gary> -- > == 14.313 == Amateur Radio Forum Saturday 11:00AM Eastern time == 14.313 ==> == Gary Bourgois flash@lopez (rutgers!sharkey!lopez!flash) GWN UPLink ==> == 3.950 Nationwide Amateur Radio Nightly after 0200z=Learning Channel ==> =============== WB8EOH = The Eccentric Old Hippie = WB8EOH ================> > ------------------------------> > Date: 26 Apr 90 13:50:56 GMT> From: portal!cup.portal.com!Lee_-_Reynolds@apple.com> Subject: Universal M-610 wanted> To: packet-radio@ucsd.edu> > Wanted - the Universal M-610 tuning scope and M-605 FDM box.> > > Please Email me at Portal or call me at (617)860-8629> > > Lee G8LCK> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 15:36:44 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Sat Apr 28 13:33:05 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 15:36:23 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa10554; 28 Apr 90 13:28 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id aa04573; 28 Apr 90 12:33 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id aa05678; 28 Apr 90 13:13 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa05603; 28 Apr 90 13:08 BST> Received: by ucsd.edu; id AA24794> sendmail 5.61/UCSD-2.0-sun> Sat, 28 Apr 90 04:00:07 -0700 for brian> Received: by ucsd.edu; id AA24788> sendmail 5.61/UCSD-2.0-sun> Sat, 28 Apr 90 04:00:06 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004281100.AA24788@ucsd.edu>> Date: Sat, 28 Apr 90 04:00:03 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #11> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Sat, 28 Apr 90 Volume 90 : Issue 11> > Today's Topics:> faster modems> Ham Packet BBS on ATT UNIX PC?> Hams in space?> MFJ TNC sold> Networking> SAREX STS-35 space shuttle> shareware in packet radio> Teletext> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 25 Apr 90 18:57:01 GMT> From: vsi1!zorch!tandem!kevinr@apple.com (Kevin J. Rowett)> Subject: faster modems> To: packet-radio@ucsd.edu> > In article <690@idacrd.UUCP> mac@idacrd.UUCP (Robert McGwier) writes:> >> >I believe that for hams in the US, it must be made into an appliance.> > I completely agree Bob!> > > We> >have also suffered another set back with the Totally Awesome IO board> ^^^^^^^^> > Bob, from the trenches, we don't really view it as a set back. Delay> *maybe*, but Awesome I/O *is* happenning! I'm staring at film right> now ready to go to a board maker....> > We do live in Silicon Valley, and getting cards made is easier than> shopping for a car here. The PacBell yellow pages has three entire> pages listing people who will make cards..> > We realize there's more to getting a product out than just having cards > made, but it K3MC Awesome will happen.> > >project. Its commercial license was never completed and those efforts> >have now fallen through. > > THis really sounds worse than it is. K3MC (Awesome ) has not died! Only the> arrangements with that particular commericalizer.> > > Totally Awesome> >IO from K3MC/N6RCE, 10 Ghz-megabit stuff from Glen Elmore, TCP-IP from> >KA9Q, we have ALL the technology we need to lead us into 21-st century.> >> >Bob> > > N6RCE> > ------------------------------> > Date: 27 Apr 90 21:24:51 GMT> From: umich!sharkey!cfctech!ttardis!rlw@CS.YALE.EDU (Ron Wilson)> Subject: Ham Packet BBS on ATT UNIX PC?> To: packet-radio@ucsd.edu> > In article <1990Apr27.023118.15972@lopez.UUCP>, flash@lopez.UUCP (Gary Bourgois) writes:> >A ham from Lower Michigan said he would donate a TNC. I agreed to supply > >what equipment I can, and am mulling over what is the best way to go. I > >have an old XTAL type 2m rig and a spare antenna to kick into the project.> >> >I also have an AT&T UNIX PC with a 20 meg hard drive. Not much, but > >probably enough to run a PBBS.> >....> >The trick will be to link everything together. I am sure it could be > >done with a XENIX type PC, but that route is beyond our meager budget.> >> >Gary> > Anything thing you can do with Xenix on a PC, you can do with the Unix-PC.> > A 20 meg disk might be too small - even a minimal news feed requires a lot> of disk space.> > There is program written by the people at KA9Q called simply KA9Q. It is> a program designed to implement protocols like Telnet (a terminal emulator),> FTP (file transfer protocol), and others over packet radio.> > KA9Q does work on the Unix-PC.> > Using the KA9Q program and a pty driver would enable any Unix system to> receive Telnet and FTP connections over packet radio (not to mention SLIP/SLFP> connections from other computers).> > Because of the pty driver (psuedo terminal), any Telnet connection would log> into the Unix system normally (via getty and login) just as through the> person had called in with a modem.> > I'm sure other people on the net can help you with technicalities in setting> this up (I know nothing about packet radio other than what it is).> > Good luck.> > - Ron> > ------------------------------> > Date: Fri, 27 Apr 90 07:52:53 PDT> From: KEVIN%CALSTATE.BITNET@CORNELLC.cit.cornell.edu> Subject: Hams in space?> To: packet-radio@ucsd.edu> > I recall reading some months ago that this summer, an astronaut on the Space> Shuttle will be doing 2 meter packet communications with earthlings.> > When will this occur? On what frequency? Will it be possible for me> to communicate with them using my BIG 5 watts of power? do i need a special> antenna or will my rinkydink ones made out of coathangers do the trick?> I expect QRM will be real bad, but the equiptment I got is what I'm stuck> with ... I yam what I yam.> > All help appreciated!> > -- Kevin> > +----------------------------------------+ DISCLAIMER: I assume no> : KEVIN M. SAVETZ - KC6GWQ : responsibility for any messages> : Bitnet: kevin@calstate.BITNET : that I post, expressed or> : Internet: humbolt!waffle@csun.edu : implied. Opinions expressed> : Fishnet: salmon@smoked.poached.fried : by me are not necessarily> +----------------------------------------+ my own.> > -30-> > ------------------------------> > Date: 27 Apr 90 19:39:24 GMT> From: psuvm!mls129@psuvax1.cs.psu.edu (Michael L. Sensor)> Subject: MFJ TNC sold> To: packet-radio@ucsd.edu> > The MFJ 1274 TNC I advertised here has been sold.> > Mike Sensor MLS129@PSUVM> > ------------------------------> > Date: 26 Apr 90 08:29:49 GMT> From: mcsun!ukc!stc!praxis!riemann!mikec@uunet.uu.net (Michael Chace)> Subject: Networking> To: packet-radio@ucsd.edu> > Hello All,> > I'd like the benefit of people's experiences concerning what to do when> your local 2m 1200bps single channel based network begins to overload.> > Our local packet network is at breaking point for about 50% of the time.> To put the network under a more 'formal' basis we had a meeting of> all local packeteers with the aim of creating a group to maintain and> enhance the network. Various suggestions were made on how to solve things,> some good, some bad. Here's a summary of the network as it stands:-> > NB - My local area is Bath/Bristol/Cardiff (S/W England & S Wales)> Total population ~1 million - Amateurs on packet ~300> > 90% of traffic sits on 144.650 all 1200bps - Local chats and node traffic.> Some links now exist on 70MHz - mainly for BBS forwarding.> There are 2 major nodes on 2m - They are on very high sites running 25W erp> consequently they hear a lot and lots can hear them.> > Perhaps a greater problem is that most routes out of our area are poor and> they also must talk to well-sited nodes. It not unusual to have stations> telephoning node sysops because they think the node is down - when its due> to the node hearing so much that its squelch is permanently open!> Most of the nodes in our area form backbone links in all directions and the> NTS Mailboxes rely on them heavily.> > The basic idea is to move the well-sited nodes into lower 'city' locations> keep them as the user access points and then tie up these nodes on separate> links (4m/70cms/23cms). Where to put the links is a moot point - 4m has a > source of cheap PMR equipment but no bandwidth - 70cms more expensive, more> channels but it's not a primary band - 23cms expensive but plenty of wide> open space.> > What I'd like are your thoughts/experiences/suggestions etc. Particularly> why you chose frequencies/data speed etc.> > As a final note - one of the things that I noticed at the meeting and while> talking to the local users were :-> > 1) People need to learn that the packet system needs to shunt data> fast. It's a serious network that moves data regardless of what> the data is and how it gets from one point to another.> > 2) People don't understand much about protocols and the NET/ROM> system eg. NOT realising that KA/NODES are not real nodes and> trying to explain why p-persist will squeeze a few more % out> of the network.> > > Thanks for your time & 73,> > Mike> ****> ................................................................. ............> | ARPA : mikec@praxis.co.uk | Michael Chace |> | JANET : mikec@uk.co.praxis | PraXis Systems |> | UUCP : ...!uunet!mcvax!ukc!praxis!mikec | Manvers Street |> | AMPRNET: g6dhu@g6dhu.ampr.org [44.131.20.3] | Bath, Avon |> | AX.25 : G6DHU @ G6DHU-2 or G6DHU @ GB7SDN | BA1 1PX UK |> | Phone : (44) [0]225 444700 | |> ................................................................. ............> > > > > ------------------------------> > Date: 27 Apr 90 16:38:43 GMT> From: microsoft!joehol@uunet.uu.net (Joseph HOLMAN)> Subject: SAREX STS-35 space shuttle> To: packet-radio@ucsd.edu> > i never got any direct replies, so i'll try again...> > > is any body out there going to have a way for use> people up in Seattle (latitude 47 deg.) to connect> to the SAREX mission ?> > i've heard rumors about people having KA-NODEs, but> i haven't heard from the horses mouth yet...> > anybody have any names or callsigns of people doing/planning > this ????> > joe holman, ka7ldn> uw-beaver!microsoft!joehol> joehol@microsoft.uucp> 206-882-8921 work> > ------------------------------> > Date: Fri, 27 Apr 90 13:25:12 MST> From: sarrel%miranda.uucp@moc.Jpl.Nasa.Gov (Marc Sarrel)> Subject: shareware in packet radio> To: packet-radio@ucsd.edu> > Is there an FCC policy or other generally accepted rules regarding> putting shareware on packet radio BBS's? Is transmitting shareware> considered a "business communication"? What about freeware? Just> curious...> > --marc> > -=-> Marc A. Sarrel> N7OLI> sarrel%miranda.uucp@moc.jpl.nasa.gov | "Oh, _lightweight_ Alpaca..."> ..!sun!sunburn!miranda!sarrel | -Blanche DuBois> > NSA fodder:> > Binary Chemical Weapon domestic disruption munitions FBI Clifford> Stoll Soviet detonator fissionable KGB colonel $400 million in gold> bullion genetic backsatter Pentagon nuclear> > ------------------------------> > Date: 27 Apr 90 15:01:26 GMT> From: motcid!froula@uunet.uu.net (Don Froula)> Subject: Teletext> To: packet-radio@ucsd.edu> > Does anyone have information about the fate of Teletext services in the US?> This is an information service that provides text and block color graphics> capability on a home TV receiver equipped with a special decoder. The data> is embedded in several unused TV lines in the vertical blanking interval.> The data repeats over and over in the form of a magazine. The decoder> simply grabs pages as they come by and stores them in a display buffer.> The system is very popular in the UK.> > Zenith used to offer an embedded decoder on some of their sets. Also, Dick> Smith electronics offered a kit a few years back.> > Observations on several local broadcast and cable channels show considerable> activity in the blanking interval. > > Information on current status of Teletext and sources for decoders would> be appreciated.> > Don WD9DMP> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 15:44:15 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Sun Apr 29 12:59:58 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 15:44:03 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa17143; 29 Apr 90 12:53 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id aa03394; 29 Apr 90 11:59 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id aa02926; 29 Apr 90 12:38 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa02870; 29 Apr 90 12:32 BST> Received: by ucsd.edu; id AA09531> sendmail 5.61/UCSD-2.0-sun> Sun, 29 Apr 90 04:00:08 -0700 for brian> Received: by ucsd.edu; id AA09518> sendmail 5.61/UCSD-2.0-sun> Sun, 29 Apr 90 04:00:05 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004291100.AA09518@ucsd.edu>> Date: Sun, 29 Apr 90 04:00:03 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #12> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Sun, 29 Apr 90 Volume 90 : Issue 12> > Today's Topics:> AR-2002 scanner remote info wanted> faster modems> Ham Packet BBS on ATT UNIX PC?> Need help in radio data communic.> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 28 Apr 90 10:38:55 GMT> From: eru!luth!sunic!mcsun!hp4nl!dutrun!dutentb!ese@BLOOM-BEACON.MIT.ED U (Kees Schot)> Subject: AR-2002 scanner remote info wanted> To: packet-radio@ucsd.edu> > !! HELP !!> > For about one year I'm looking for information on the> computer interface of the AR-2002 communications receiver.> > If someone has hard- or software information about> this interface (or also about other interesting aspects of> this equipment) please send it to me by email to> > schot@dutentb.tudelft.nl> > or on paper to:> > C.A. Schot,> Grote Kreek 45,> 3079 CC Rotterdam,> The Netherlands.> > Even the name and address of the (I thought Japanese)> manufacturer of this scanner can help me.> > Please, help me, because this is the last hope for me> to get this information.> > ------------------------------> > Date: 28 Apr 90 15:56:42 GMT> From: payne@tcgould.tn.cornell.edu (Andrew Payne)> Subject: faster modems> To: packet-radio@ucsd.edu> > In article <9004232134.AA04767@miranda.uucp> sarrel@miranda.UUCP (Marc Sarrel) writes:> >expert" at a local amateur radio store recently. I asked him about> >some TNC that had a 2400 baud modem vs one that had a 1200 baud modem.> >I asked wether 2400 would catch on, given my experience with land line> >modems where everyone was starved for speed. He said "no." His> >reasons seemed pretty fuzzy to me, but he seemed to claim that 1) 2400> >baud wouldn't catch on because everyone already has 1200 baud modems,> >2) 1200 baud seemed fast enough to him, and 3) that 2400 baud wasn't> >_really_ twice as fast as 1200 because the extra speed was used> >inefficiently. (But don't hold me to that, this was a while ago.)> >> I also feel that 2400 baud will not catch on, but my reasoning is > much different. 2400 baud is just not that much of a jump beyond 1200 to > make it worth the trouble. Go for 9600 baud or 56kb (though 4800 baud seems> to be a happy medium for many because it supposedly works with more radios than> the higher speeds).> > >Anyway, my question is this: How can we "hams in the know" encourage> >the use of faster and more effecient modems on the airwaves, given> >that we agree that "faster is better." One of this guy's arguments> >holds weight in that there is a lot of "hardware inertia" out there.> > The first step in taking advantage of higher speed modems is to use> them on the backbones. The backbones are where the heavy traffic is anyway,> and there is little "hardware inertia" involved. You could run some strange> I'm-not-compatible-with-anything protocol and modem on the backbones and it > wouldn't really matter.> > Many of the UHF backbone links of the network in Ohio are at 4800> baud. The NEDA guys have many 4800 baud trunks and are quickly moving for > 9600 baud. Also, on the NEDA network, many of the high-volume users (DX > clusters, BBSs, TCP/IP) are using higher speed uplinks to the backbone.> > There is never going to be an overnight switch away from 1200 baud.> Like MS-DOS, it will dog us for a long, long time. Put the high-speed modems> in the places will they will give maximum benefit and gradually people will> migrate beyond 1200 baud.> > > -- > = = = = = = = = = = = = = = = = = = = = = = = = = = => Andrew C. Payne, N8KEI UUCP: ...!cornell!batcomputer!payne> INTERNET: payne@tcgould.tn.cornell.edu> > ------------------------------> > Date: 28 Apr 90 21:56:00 GMT> From: usc!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs. uiuc.edu!kenny@ucsd.edu> Subject: Ham Packet BBS on ATT UNIX PC?> To: packet-radio@ucsd.edu> > >There is program written by the people at KA9Q called simply KA9Q.> > Gee, Phil, I never knew you were twins.... 8-)> > Kevin, KE9TV> kenny@cs.uiuc.edu> > ------------------------------> > Date: 28 Apr 90 00:08:00 GMT> From: swrinde!zaphod.mps.ohio-state.edu!uwm.edu!bionet!arisia!cdp!saff@ ucsd.edu> Subject: Need help in radio data communic.> To: packet-radio@ucsd.edu> > Friends,> > I work in a brazilian organization who also give> support for non-profits organizations. We work with a similar> organization, here in San Francisco Bay Area. We are about to get> authorization to use the PeaceSat, an old militar satellite now used> for pacific purposes, and we plan to use initially to get a cheap> and good link from our machines. I have no experience in this area,> so I am asking for help with some (maybe dumb) questions:> > - Possible baud rates> > - Hardware required> > - Places where look for hardware> > Thanks very much for any help,> > Saliel Figueira Filho> Chief Programmer> IBASE> > {pyramid, hplabs, ...}!cdp!saff> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: 2 May 90 05:43:47 GMTFrom: swrinde!emory!rsiatl!jgd@ucsd.edu (John G. De Armond)Subject: faster modemsTo: packet-radio@ucsd.edukarn@thumper..bellcore.com (Phil R. Karn) writes:>In article <1959@rsiatl.UUCP> jgd@rsiatl.UUCP (John G. De Armond) writes:>>In terms of rules, before the great ARRL/FCC rules rewrite, this type>>modem [wa4dsy]>>could be used at 220 mhz and above. Now that we've been "represented">>again by the ARRL, 220 is out. But anything 440 or above is fine.>This is news to me. I'm still running 56kbps on 220.55, and as far as I>know it's still entirely legal.I'm sorry that I can't quote chapter and verse, Phil, but I don't havemy personal copy of the new Part 97 yet. My comment stems from a GRAPESsession a few months ago when we were reviewing the rewrite. As I recall,the new language puts both a baudrate and a bps limit on everthing below440. I'm going to be in a ham store tomorrow, so I'll pick up myown copy of Part 97 and find the clause. Meanwhile, you might wantto reread the digital sections carefully. It was the consensus of every-body that read those paragraphs that day that 56k was out on 220.John-- John De Armond, WD4OQC | We can no more blame our loss of freedom on congressRadiation Systems, Inc. | than we can prostitution on pimps. Both simplyAtlanta, Ga | provide broker services for their customers.{emory,uunet}!rsiatl!jgd| - Dr. W Williams | **I am the NRA** ------------------------------Date: Tue, 1 May 90 9:00:38 PDTFrom: Peter Dahl <pdahl@milton.u.washington.edu>Subject: Full Duplex packet on 2 meters?To: packet-radio@ucsd.edu Is anyone operating dual frequency, full duplex packet nodes on2 meters on frequencies other than coordinatable/bandplan repeater pairs?How about 145.01/145.61? How do you interpret the fcc rules on this one?145.61 is in an area where repeaters are supposedly not permitted but is a fullduplex packet node a repeater as we have come to know repeaters? TheARRL Repeater Directory says that the frequencies between 145.5 and I believe145.8 are bandplanned for experimental modes. Everything in this developingmode of packet radio is experimental isn't it? Please let me know what you think.... We need some full duplexpacket systems and standard repeater pairs have all been used for voice repeaters whether they are really needed or not. Peter, WA7FUS------------------------------Date: 1 May 90 22:41:00 GMTFrom: zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1 .cso.uiuc.edu!phil@tut.cis.ohio-state.eduSubject: Full Duplex packet on 2 meters?To: packet-radio@ucsd.eduYou might try doing some unusual splits in the repeaters. The FCC rulesdo NOT allow repeaters in the 145.5-146 Mhz range (nor 144.0-144.5) soyou need to limit yourself to 144.5-145.5 and 146-148.It is a sad shame that spectrum planners and repeater coordinators are notmaking any attempt to plan for greater density of spectrum usage. Theysimply assume that when there is no repeater pair that comes up without aconflict on the computer, that that band is full at that location.Spectrum planners need to get on the ball and do some planning. If thatcalls for some repeater pairs to be dedicated to packet, so be it. It maynot be necessary to do that.However I must assert one thing for certain: just because someone has had arepeater on a given frequency already is no reason for having a "right" tostay there. If packet radio needs to share the spectrum of repeater pairsthen the spectrum should be allocated as needed.This probably means some repeaters will have to move. Hey folks, that ispart of progress. Of course some hams are totally against progress, andthe only solution I can suggest for them is to take them off the air.By the way, you CAN get several TIMES the number of repeaters on the airin the major cities as you have now. It also appears that the number ofrepeaters in several are NOT EVEN NEEDED. The situation as it exists nowis mostly turf claims. This has to end and spectrum planners and repeatercoordinators need to get off their hind ends and do something.Problems will always exist when those who coordinate are also there toprotect the turf of existing repeater owners.I a big city you can hit 20 to 40 repeaters easily. Tell me how many ofthem are actually IN USE most of the time? What is the average amount ofairtime per repeater per day? I think you will find things are NOT asdense as we might like to think.--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society<phil@ux1.cso.uiuc.edu> | no matter what the particular issue is all about.------------------------------Date: 2 May 90 01:50:19 GMTFrom: uokmax!nsslsun.gcn.uoknor.edu!skaggs@apple.com (Gary Skaggs)Subject: Full Duplex packet on 2 meters?To: packet-radio@ucsd.eduI agree 100% with Phil on the problem of repeaters and the need for endingthe *turf* battles that are occurring over frequency *rights*. But, I thinkthe REAL solution if you want *full duplex* is individual, not-necessarily-600 Khz-offset frequencies. put one in the 145 simplex area, the other in146. Yes, I know *FM simplex* is what it says. If the natives are restlessabout such *sins*, cross-band. This saves on duplexor costs. You can buya good quality radio for less than what it will cost you for a good set ofband pass/band reject duplexors. Then run real full duplex.On second thought, go up in frequency and run FAST, full duplex.__________________________________________________________ ____________________Gary Skaggs Internet: skaggs@nssl.gcn.uoknor.eduNational Severe Storms Laboratory (The Tornado People) "The Channel 9 Alpha system, technology at it's ____________?"------------------------------Date: 1 May 90 18:15:29 GMTFrom: ndcvb!cartan!ndmath!nstar!w8grt!jim.grubs@iuvax.cs.indiana.edu (Jim Grubs)Subject: Higher speedsTo: packet-radio@ucsd.edu(330) Sat 28 Apr 90 3:42pBy: Brian BattlesTo: Bob McgwierRe: Fast packetSt:-------------------------------------------------------- ----------------------@EID:1811 149c7d40Bob, In your reply to Marc Sorrel, you wrote: BM> ...Hams are basically cheap... Make that "poor," not necessarily cheap. Most hams I know areperpetually in danger of bankrupting their family financies to buynew gizmos. BM> ...and these days they are basically technically lazy... Although many are just busy or lacking education. Some of us havelittle time to get on the air, let alone design and build some fancynew digital high-tech device. Some hams have had little computer ordigital education and have to struggle to keep up. Besides, many hamsprefer to provide traffic handling/emergency communications/etc thanto build a lot of gear. BM> ...My efforts in this area along with partners KB2CST and KA2MOV BM> for commercial concerns and with WA7GXD, KV7B, W3IWI for TAPR and BM> AMSAT have essentially been done for free... And are greatly admired and appreciated by all amateurs with anyslight understanding of technology and creativity! BM> ...[with rigs] needed to work satellites, ROBOT 1200C's costing a BM> fortune when you can get them for SSTV, WEFAX APT equipment costing BM> a few hundred, etc, it has just gotten too expensive for a ham to BM> `do it all' with individual pieces of equipment... <sigh> All too true.73 de Brian Battles, WA1YUA * HAM RADIO & PACKET Echo ModeratorQTH New Britain, Conn.Packet: WA1YUA @ N1API... Someday my ham radio may save your life!--- Via Silver Xpress V2.24 (1:141/880) Brian Battles, WA1YUA - via FidoNet node 1:141/880UUCP: ...!ncar!asuvax!stjhmc!w8grt!880!141!1!brian.battlesINTERNET: brian.battles@f880.n141.z1.fidonet.org--------------------------- ---Date: Tue, 1 May 90 8:44:39 PDTFrom: Peter Dahl <pdahl@milton.u.washington.edu>Subject: New Packet Stuff @ Dayton??To: packet-radio@ucsd.eduI have not yet seen a list of the new packet related equipment that was introduced at Dayton last weekend. Can anyone who wasthere or has heard a report on this supply us with this info?CURIOUS MINDS WANT TO KNOW! 73 de Peter, WA7FUS------------------------------Date: Wed, 2 May 90 09:39 NFrom: Urs Baer <BWLLIBMOD%CSGHSG5A.BITNET@CUNYVM.CUNY.EDU>Subject: Packet-Radio Digest V1 #14To: Packet-Radio@UCSD.Eduplease remove my old adress 87674800s@csghsg5a.bitnet from this list!!!------------------------------End of Packet-Radio Digest******************************----------------------------- -End of Packet-Radio Digest******************************----------------------------- -End of Packet-Radio Digest******************************Date: Sat, 5 May 90 04:00:03 PDTFrom: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #18To: packet-radioPacket-Radio Digest Sat, 5 May 90 Volume 90 : Issue 18Today's Topics: Early DRSI PC Packet Adapter faster modems (2 msgs) Full Duplex packet on 2 meters? Hams in space NOS domain.txt format NOS hosts.net file? (2 msgs) Supersport 286 memory Undeliverable messageSend Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: Fri, 4 May 90 07:10:04 -0400From: david@lambton.on.caSubject: Early DRSI PC Packet AdapterTo: packet-radio@ucsd.eduHas anyone got a set of schematics for the first rev of the DRSI PC*PAboards that they could share with me? Mine is about two years old andis (I think) the same as the type 1 board now, except for the layout.The first boards had some of the jumper straps accessable from the topof the card while it was in the machine and were located just to therear of the LEDs.I'd like to add the TAPR DCD state mod that I picked up in Dayton to it.I'd also be willing to listen to any advice from those who have addedthe DCD mod or a K9NG or G3RUH modem to any of the DRSI cards.thanks de Dave - - - - - - - - - - - - - - - Email: david@lambton.on.ca Ma Bell: (519) 542-7751 x293 Paper: David Grant Fax: (519) 542-6667 Lambton College of AA&T Radio: VE3DGR (Digital class) 1457 London Rd., Box 969 Sarnia, Ontario, CANADA N7T 7K4------------------------------Date: 4 May 90 19:59:38 GMTFrom: optilink!elliott@uunet.uu.net (Paul Elliott x225)Subject: faster modemsTo: packet-radio@ucsd.eduIn article <22921@bellcore.bellcore.com>, karn@thumper..bellcore.com (Phil R. Karn) writes:> > I agree that the high speed modems are needed most by the users. Every> other computer network I've seen (especially the Internet) has the high> bandwidth links (10 mb/s Ethernets, etc) at the local level, somewhat> slower links on the regional level, and the slowest links for the long> haul paths.... while for the switched phone network, the speed capabilities from thelocal loop to the long-haul lines is just the opposite. We have slow connections between the user and the central office, and the fastest oneson the inter-office lines.The optimum economical selection of interconnect bandwidth seems to (obviously)be related to the traffic patterns and topology. In computer networks, thelocal area net carries by far the bulk of the traffic (workstation to fileserver, for example). Much less data needs to travel between sites.The phone network has a more even distribution of near/far connections, andthe high-speed interoffice trunks are an efficient arrangement for thetopology.What is the most appropriate model for ham radio packet? How does thevirtual connection vs. datagram mode affect this? (Please excuse my probablemis-use of the terminology; I am but a humble, clueless neophyte ;-)-- Paul M. Elliott Optilink Corporation (707) 795-9444 {uunet, pyramid, pixar, tekbspa}!optilink!elliott "Less than perfect, that's what I've been aiming for all along."------------------------------Date: 4 May 90 19:43:13 GMTFrom: hpl-opus!hpnmdla!glenne@hplabs.hp.com (Glenn Elmore)Subject: faster modemsTo: packet-radio@ucsd.eduDevon writes:> Also that the highest speeds attainable so far are in bands that support> point-to-point communication. That's why we're looking at a high speed back-> bone in this area. 1 Mb/sec links are not as doable for local, generic use. It's true that high speeds require point to point hardware if we areto make efficient use of our spectrum and hardware resources whileproviding access to more than a very small number of users. However thespecifics of "how point-point" and how fast is fast are intertangled withuser population density, geography, spectrum availability and a varietyof social/political/economic issues. Clearly pure Aloha operation in a major metropolitan area can onlysupport *very* low user throughputs (witness 145.01 near any major populationbase) but the transition to rip-roaring speeds is a shades-of-gray deal. In addition, the question of highspeed backbone/moderatespeed user orlow speed bacbone/highspeed user depends on how we plan on using this thing.I think that there is little question that it is always going to be easierto make and support systems with highspeeds "close to home" but what isdesired depends on one's interperetation of a high speed network. Is theemphasis on *highspeed* or is it on *network*? We are going to have todesign for some compromise of the two since we aren't likely to be ableto provide two way info at 100 MBps simultaneously among all hams worldwidewithin our lifetime. The highspeed emphasis opens the door to fundamentally new applicationsamong local users, truly exciting stuff which can do a great deal tomake amateur radio enticing and exciting again. I believe we amateurs have theunique resources and skills to provide a "playground" which could entice a*lot* of new blood into the hobby. If even a portion of today's information-agetechies; the CS types who didn't go into amateur radio but pursued computerhobbies instead, were attracted to the hobby I think our future would bebrighter. Yes, the face of the hobby will have to change some, but it couldcontinue as a vehicle for technically oriented individual to have a handin the "state of the art". It could certainly also continue in its strengthsas a social environment for that group. Highspeed applications might dowonders to augment those things that are already fun and interesting aboutthe hobby too. The networking emphasis leans in the direction of offering global communications. The demonstrated value and potential of crossing national andcultural boundaries is also truly exciting. Even if we can support little more than low latency worldwide e-mail and not high speed applications( X windows between continents etc) a worldwide amateur network could be extremely powerful in helping continue the hobby. The potential forsome very interesting news group titles exists! But 1 million users all runningeven 300 baud throughput would demand some pretty fancy backbones. Our present effort here in northern California is to provide a comprimise.Current plans are for the 900/1200 MHz "user" radios to be used on half-directional/half omni (gain omni antennas) links. These radiosare designed to work at or below 500 kbaud. Although I haven't done rigorous modeling yet, it appears that this all has a reasonably goodchance of working given current resources and constraints. Longer term, asthe number of users, density of users and information rates increase wewill have to go to dedicated pt-pt link hardware. Our first backbone forconnecting the user cells is expected to use the same sort of hardware asthe users themselves. This suggests an emphasis on high speed to the userover networking, per se. Because of the need for geographically diverse groups to cooperate inbuilding the network and for the need to use amateur expertise and"connections" in getting backbone radios at existing high level sites,some of the early applications which are written for the network needto be ones which sell it to some "non-digital" people. I would loveto see a simple client/server written for NOS which would allow remotebase and repeater sysops to monitor and control a few bits and an analog lineor two at their high level site. Such an application (providing accessto the remote from anywhere the network goes) could generate a lot of goodwill and support from a very important group of amateurs. Such an applicationin trade for getting UHF or microwave(non-interfering with existing radios because of their higher frequency nature) backbones at a high level sitecould be a mutually beneficial arrangement. As has already been mentioned under this basenote, the "political" and cooperational issues are probably more unknown and more difficult thanany of the technical issues.Higher speed hardware, protocols and applications are coming. I guess thequestion is "Can we cooperate enough to put them all to use in time?"Glenn Elmore -N6GN-N6GN @ K3MC glenn@n6gn.ampr.orgglenne@hpnmd.hp.com ------------------------------Date: 4 May 90 06:45:33 GMTFrom: swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!emory!rsiatl!jgd @ucsd.edu (John G. De Armond)Subject: Full Duplex packet on 2 meters?To: packet-radio@ucsd.edukarn@thumper..bellcore.com (Phil R. Karn) writes:#I wish people would stop talking about what the "new rules" do differently#from the old rules. The intent of the rewrite was NOT to change what is#or is not allowed, but to restructure the existing rules to incorporate#informal rulings to make them more easily accessible. It was against#the rules to put repeaters outside the repeater subband before the new#rules were adopted, and it's against the new rules to do it now.But the fact remains that regardless of the intent, we have to live withwhat is written on the pages of part 97. And from my perspective,many changes were made. This is simply one.John-- John De Armond, WD4OQC | We can no more blame our loss of freedom on congressRadiation Systems, Inc. | than we can prostitution on pimps. Both simplyAtlanta, Ga | provide broker services for their customers.{emory,uunet}!rsiatl!jgd| - Dr. W Williams | **I am the NRA** ------------------------------Date: 4 May 90 23:20:25 GMTFrom: haven!aplcen!jhunix!ins_atge@ames.arc.nasa.gov (Thomas G Edwards)Subject: Hams in spaceTo: packet-radio@ucsd.eduIn article <9005030639.AA05453@ucsd.edu> KEVIN@CALSTATE.BITNET writes:> What frequency! What frequency! What frequency!?> Can *I* contact this guy using my silly antenna made out of coathangers and>5 watts of power on VHF?Read the STS-35 press info stuff on Sci.space.shuttle. Why hasn'tanyone knowledgeable talked about SAREX on here yet!?!?!?!Anyway, primary frequencies will be one-fourty-four.95 uplink and one-fourty-five.55 downlink(ever discover a key doesn't work during a post?)------------------------------Date: 5 May 90 09:25:33 GMTFrom: uhccux!querubin@ames.arc.nasa.gov (Antonio Querubin)Subject: NOS domain.txt formatTo: packet-radio@ucsd.eduAfter finding out that NOS wanted to see either a domain.txt file or hosts.nos file, I tried copying my old hosts.net into domain.txt and hosts.nos.Unfortunately this didn't work. But I also just found an old article that states domain.txt has to be in a domain nameserver format which I presume isdifferent from the hosts.net format.Can anyone tell me what this format is supposed to look like?Internet: antonio_querubin-manoa@uhplato.uhcc.hawaii.eduBITnet: antonio_querubin-manoa@uhplatoAH6BW------------------------------ Date: 4 May 90 12:35:45 GMTFrom: unmvax!ariel!hydra.unm.edu!deichert@ucbvax.Berkeley.EDU (Diana Eichert)Subject: NOS hosts.net file?To: packet-radio@ucsd.eduI would be interested in some type of compilation for NOS also. That isif someone has done something like that.diana eichertYrisarri Systemsdeichert@hydra.unm.edu------------------------------Date: 4 May 90 22:03:57 GMTFrom: uc!shamash!shamash.cdc.com@tut.cis.ohio-state.edu ( Jeff Comstock - VTC/SEATTLE SILICON )Subject: NOS hosts.net file?To: packet-radio@ucsd.eduCheck out these files on tomcat.gsfc.nasa.gov [128.183.10.100]The files are in tcp/nos:nos-info.txt Mainly info on updates.nosdoc.txt An archive of notes from the tcp-group dealing with NOS.sample.net W3IWI's doc on how to setup NOS. Also, Phil is working on a doc for NOS. It sounds like it will be out in atest mode pretty soon. 73,Jeff - NR0D------------------------------Date: 5 May 90 02:04:58 GMTFrom: uhccux!querubin@ames.arc.nasa.gov (Antonio Querubin)Subject: Supersport 286 memoryTo: packet-radio@ucsd.eduThe extra 384K of memory in a Supersport 286 is useable only as expandedmemory. Press Ctrl-Alt-Ins and enter 'setup'. Then seleect the memory configuration as expanded memory even though you don't have memory beyond the1 Mbyte limit. This will let emm.sys see 256k of this extra memory asexpanded memory and all your software that knows how to use expanded memorycan now access it. 128K of memory is used to hold a copy of the BIOS as 'shadow RAM'. The BIOS code runs faster when executed from RAM than from ROM.I complained to Zenith about this 'deceptive advertising'. If they were gonnasteal 128K for 'shadow RAM' then they should have said the Supersport 286 comeswith only 916K of useable RAM. Or provided 1132K of RAN in the first place.------------------------------Date: 04 May 90 11:19:10 EDTFrom: Electronic Postmaster <POSTMASTER@CompuServe.COM>Subject: Undeliverable messageTo: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>Re: ? EMDITB - Mail Delivery Failure. Message too large. >EPX [70645,247]Packet-Radio Digest V1 #17Your message could not be delivered as addressed.--- Returned message ---Received: from ucsd.edu by saqqara.cis.ohio-state.edu (5.61-kk/5.900430) id AA26342; Fri, 4 May 90 08:37:15 -0400Received: by ucsd.edu; id AA04650 sendmail 5.61/UCSD-2.0-sun Fri, 4 May 90 04:00:23 -0700 for brianReceived: by ucsd.edu; id AA04640 sendmail 5.61/UCSD-2.0-sun Fri, 4 May 90 04:00:18 -0700 for /usr/lib/sendmail -o c -o db -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-listMessage-Id: <9005041100.AA04640@ucsd.edu>Date: Fri, 4 May 90 04:00:04 PDTFrom: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #17To: packet-radio@cis.ohio-state.eduPacket-Radio Digest Fri, 4 May 90 Volume 90 : Issue 17Today's Topics: faster modems (3 msgs) Full Duplex packet on 2 meters? NOS hosts.net file? Undeliverable messageSend Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 3 May 90 16:57:06 GMTFrom: van-bc!ubc-cs!alberta!atha!tech@ucbvax.Berkeley.EDU (Richard Loken)Subject: faster modemsTo: packet-radio@ucsd.edupayne@batcomputer.tn.cornell.edu (Andrew Payne) writes:> The first step in taking advantage of higher speed modems is to use>them on the backbones. The backbones are where the heavy traffic is anyway,>and there is little "hardware inertia" involved. You could run some strange>I'm-not-compatible-with-anything protocol and modem on the backbones and it >wouldn't really matter.A friend recently presented a counter argument when I suggested the abovescenerio. The argument goes like this:The backbone traffic is orderly and reasonably predicatable and would probablyrun just fine at 9600 baud or less. The local level is chaos with stationscontending and colliding so they should run as fast as possible in order to allow each node to get his packet on the wire and out of the way quickly.Recently another message supported this perspective, the author was commentingon his local environment in England where 300 stations running 1200 baudwere running into congestion problems.The more I think about it the more I support the view that the nodes out in thecloud should send the data as quickly as possible - running 56K or better wouldobligate an upgrade in modems and radios but not the computers since you arenot expected to provide and decode 50k x 60 x 60 x 24 characters of packetsevery day. Hopefully each node is not quite that talkative. ********* 73 ********** Richard Loken VE6BSV . **** .. **** Athabasca University .... **** Athabasca, Alberta Canada..........**** tech@cs.AthabascaU.CA {alberta|decwrl}!atha!tech----------------- -------------Date: 4 May 90 01:42:10 GMTFrom: thumper!karn@bellcore.com (Phil R. Karn)Subject: faster modemsTo: packet-radio@ucsd.eduI agree that the high speed modems are needed most by the users. Everyother computer network I've seen (especially the Internet) has the highbandwidth links (10 mb/s Ethernets, etc) at the local level, somewhatslower links on the regional level, and the slowest links for the longhaul paths.I suspect that many people advocate putting high speed modems into the backbonelinks mainly because it's easier (i.e., it requires fewer modems) thangiving them to the end users. It's somewhat reminiscent of the old jokeabout the drunk who was observed searching for something under a streetlightat night. When asked what he was doing, he replied that he had lost a contactlens across the street. When then asked why he wasn't looking for it acrossthe street, he replied that the light was better on *this* side...Phil------------------------------Date: 4 May 90 02:06:03 GMTFrom: zaphod.mps.ohio-state.edu!sunybcs!bowen@tut.cis.ohio-state.edu (Devon E Bowen)Subject: faster modemsTo: packet-radio@ucsd.eduIn article <22921@bellcore.bellcore.com>, karn@thumper..bellcore.com(Phil R. Karn) writes:|> I suspect that many people advocate putting high speed modems into the|> backbone links mainly because it's easier (i.e., it requires fewer modems)|> than giving them to the end users.Also that the highest speeds attainable so far are in bands that supportpoint-to-point communication. That's why we're looking at a high speed back-bone in this area. 1 Mb/sec links are not as doable for local, generic use.Devon------------------------------Date: 3 May 90 15:52:08 GMTFrom: thumper!karn@bellcore.com (Phil R. Karn)Subject: Full Duplex packet on 2 meters?To: packet-radio@ucsd.eduIn article <2058@rsiatl.UUCP> jgd@rsiatl.UUCP (John G. De Armond) writes:>The new rules specifically prohibit full duplex, repeater-like service>across those splits. Sad but true.I wish people would stop talking about what the "new rules" do differentlyfrom the old rules. The intent of the rewrite was NOT to change what isor is not allowed, but to restructure the existing rules to incorporateinformal rulings to make them more easily accessible. It was againstthe rules to put repeaters outside the repeater subband before the newrules were adopted, and it's against the new rules to do it now.Be that as it may, I did advocate that definitions of "repeater" and"digipeater" be adopted that reflect the important distinction thatdigipeaters have to be specifically requested by a transmitting stationto retransmit their packets, while plain repeaters do not. This isimportant because the reason for limiting repeaters to subbands is toavoid unintentional repeating of stations that do not wish to berepeated. If a "repeater" will not retransmit a signal unless thesender specifically requests to be retransmitted, then it should beclassified as a "digipeater" and not restricted to the repeatersubbands. Unfortunately this was considered a too "radical" proposalby the ARRL and it was not incorporated into their rules rewritecomments.Phil------------------------------Date: 4 May 90 03:54:00 GMTFrom: uhccux!querubin@ames.arc.nasa.gov (Antonio Querubin)Subject: NOS hosts.net file?To: packet-radio@ucsd.eduI've been playing around with KA9Q (NOS version) and I noticed that it doesn't seem to read the same hosts.net file that the older version does. Can anyone tell me if the new version expects a different file name than hosts.net? Also, how do I configure NOS to use the ethernet port on a UNIX system and at the same time, not interfere with other processes running TCP/IP?I understand that NOS is undocumented but if anyone has collected a set of configuration notes/hints, I'd appreciate getting them.AH6BWInternet: antonio_querubin-manoa@uhplato.uhcc.hawaii.eduBITnet: antonio_querubin-manoa@uhplato.bitnet---------------------------- --Date: 03 May 90 08:48:36 EDTFrom: Electronic Postmaster <POSTMASTER@CompuServe.COM>Subject: Undeliverable messageTo: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>Re: ? EMDITB - Mail Delivery Failure. Message too large. >EPX [70645,247]Packet-Radio Digest V1 #16Your message could not be delivered as addressed.--- Returned message ---Received: from ucsd.edu by saqqara.cis.ohio-state.edu (5.61-kk/5.900430) id AA28146; Thu, 3 May 90 08:18:56 -0400Received: by ucsd.edu; id AA22702 sendmail 5.61/UCSD-2.0-sun Thu, 3 May 90 04:00:16 -0700 for brianReceived: by ucsd.edu; id AA22695 sendmail 5.61/UCSD-2.0-sun Thu, 3 May 90 04:00:13 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-listMessage-Id: <9005031100.AA22695@ucsd.edu>Date: Thu, 3 May 90 04:00:04 PDTFrom: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #16To: packet-radio@cis.ohio-state.eduPacket-Radio Digest Thu, 3 May 90 Volume 90 : Issue 16Today's Topics: faster modems frustration Full Duplex packet on 2 meters? Hams in space Packet in Cincinnati, OH? TNC2 1.1.7 Code Undeliverable messageSend Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 2 May 90 16:56:32 GMTFrom: thumper!karn@bellcore.com (Phil R. Karn)Subject: faster modemsTo: packet-radio@ucsd.eduIn article <2049@rsiatl.UUCP> jgd@rsiatl.UUCP (John G. De Armond) writes:>As I recall,>the new language puts both a baudrate and a bps limit on everthing below>440.I think you're referring to a typo in the rules rewrite that did indeedmove the limit for wideband packet up to 420 MHz. This was not the intentionof the FCC, and in fact it was fixed in an errata ruling.Phil------------------------------Date: Wed, 2 May 90 23:10:23 MSTFrom: sarrel%miranda.uucp@moc.Jpl.Nasa.Gov (Marc Sarrel)Subject: frustrationTo: packet-radio@ucsd.eduI've been trying to monitor some packet traffic, but without muchsuccess. A own MacRATT, a PK-232MBX and a TH-225A. What happens isthat I can see the DCD light go on and off and see the Mark and SpaceLED's go back and forth, but only rarely does the contents of thepackets get printed. The curious part is that the MHEARD list isconstantly being updated as though packets are being received. I'llspare the net the rest of the details. If you have any ideas, send meemail.advTHANKSance--marc-=-Marc A. SarrelN7OLIsarrel%miranda.uucp@moc.jpl.nasa.gov | "Oh, _lightweight_ Alpaca..."..!sun!sunburn!miranda!sarrel | -Blanche DuBoisNSA fodder:strategic, Treasury, Narco Terrorist, assassination, room temperaturesuperconductor.------------------------------Date: 2 May 90 20:10:47 GMTFrom: rsiatl!jgd@uunet.uu.net (John G. De Armond)Subject: Full Duplex packet on 2 meters?To: packet-radio@ucsd.edupdahl@MILTON.U.WASHINGTON.EDU (Peter Dahl) writes:> Is anyone operating dual frequency, full duplex packet nodes on>2 meters on frequencies other than coordinatable/bandplan repeater pairs?>How about 145.01/145.61? How do you interpret the fcc rules on this one?>145.61 is in an area where repeaters are supposedly not permitted but is a full>duplex packet node a repeater as we have come to know repeaters? TheThe new rules specifically prohibit full duplex, repeater-like serviceacross those splits. Sad but true.John-- John De Armond, WD4OQC | We can no more blame our loss of freedom on congressRadiation Systems, Inc. | than we can prostitution on pimps. Both simplyAtlanta, Ga | provide broker services for their customers.{emory,uunet}!rsiatl!jgd| - Dr. W Williams | **I am the NRA** ------------------------------Date: Wed, 02 May 90 23:39:09 PDTFrom: KEVIN%CALSTATE.BITNET@CORNELLC.cit.cornell.eduSubject: Hams in spaceTo: packet-radio@wsmr-simtel20.army.milI posted a query a few days ago about a space shuttle flight on which a ham opwoold be using 2-way packet communications. I received no answers (possiblybecause the internet address in my .sig was dead...) So I will ask again, andadd what little I do know, taken from May 1990 QST.Quote:The Shuttle Amateur Radio Experiment #2 (SAREX-2) packet radio station recentlyunderwent testing at the Marshall Space Flight Center in Huntsville, Alabama,with assistance from area hams. The packet radio station flying on space shuttle mission STS-35 willgive each amateur who connects to WA4SIR a QSO number confirming the contact.More than 550 teachers, parents, and Amateur Radio clubs assisting schools havecontacted the ARRL Educational Activities Department for details on making acontact with the shuttle crew. This is a great opportunity for showing the excitexcitment of Amateur Radio to our youth! QSL cards will be available. The FCC has granted Payload Specialist Ron Parise, WA4SIR, a waiver touse his call sign for a space station aboard STS-35 to be launched May 9, 1990.Teachers can obtain shuttle locators from the ARRL Educational Activities De-partment by sending a 9- x 12-inch envelope with 45 cents postage affixed.End Quote.Questions!: What frequency! What frequency! What frequency!? Can *I* contact this guy using my silly antenna made out of coathangers and5 watts of power on VHF? How do I know when the shuttle is audible? (I know -- listen for it. I meanhow do I predict?) What frequency?!I am not a parent, teacher, or club, and (besides) I doubt I'd get any meaning-ful info from the ARRL before the 9th anyway. All help appreciated. Kevin Savetz The .sig is right this time.... vvvvvvv+----------------------------------------+ DISCLAIMER: I assume no: KEVIN M. SAVETZ - KC6GWQ : responsibility for any messages: Bitnet: kevin@calstate.BITNET : that I post, expressed or: Internet: gpr001f@ccs.calstate.edu : implied. Opinions expressed: Fishnet: salmon@smoked.poached.fried : by me are not necessarily+----------------------------------------+ my own. -30-------------------------------Date: 2 May 90 22:13:32 GMTFrom: ius3.ius.cs.cmu.edu!ralphw@pt.cs.cmu.edu (Ralph Hyre)Subject: Packet in Cincinnati, OH?To: packet-radio@ucsd.eduMoved from urban area in Pittsburgh, PA (plenty of stations) to Milford, OH (near Cincinnati, OH) and I'm having more difficulty contacting stations. I can hear W8YS and KY8T (sp?) in PASSALL mode (I would expect errors, LebanonOH (home of W8YS) is 30 miles away, I don't know where the other station is.)Does anyone know how the Cincinnati WAN is organized? Where else should I lookbesides 145.0{1,3}.I'm ready to break out my 10M rig and go HF.Thanks. - Ralph N3FGW-- - Ralph W. Hyre, Jr.internet: ralphw@ius3.cs.cmu.edu AMPRnet: in transitionapplelink: am0005 (attn: Ralph Hyre) (user to be n3fgw@w2xo)------------------------------Date: 2 May 90 14:34:36 GMTFrom: hpcc01!col!bdale@hplabs.hp.com (Bdale Garbee)Subject: TNC2 1.1.7 CodeTo: packet-radio@ucsd.edu>Have TAPR made the new 1.1.7 TNC2 Code available for download yet ?No. You really want a copy of the new manual that is shipping with 1.1.7. Call TAPR and order a copy, it's cheap.TAPRPO Box 12925Tucson, AZ 85732(602) 323-1710Bdale------------------------------Date: 02 May 90 09:37:20 EDTFrom: Electronic Postmaster <POSTMASTER@CompuServe.COM>Subject: Undeliverable messageTo: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>Re: ? EMDITB - Mail Delivery Failure. Message too large. >EPX [70645,247]Packet-Radio Digest V1 #15Your message could not be delivered as addressed.--- Returned message ---Received: from ucsd.edu by saqqara.cis.ohio-state.edu (5.61-kk/5.900430) id AA01840; Wed, 2 May 90 08:56:29 -0400Received: by ucsd.edu; id AA09832 sendmail 5.61/UCSD-2.0-sun Wed, 2 May 90 04:00:17 -0700 for brianReceived: by ucsd.edu; id AA09827 sendmail 5.61/UCSD-2.0-sun Wed, 2 May 90 04:00:14 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-listMessage-Id: <9005021100.AA09827@ucsd.edu>Date: Wed, 2 May 90 04:00:04 PDTFrom: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #15To: packet-radio@cis.ohio-state.eduPacket-Radio Digest Wed, 2 May 90 Volume 90 : Issue 15Today's Topics: DOVE TELEMETRY DATA.... here is how. Failed Mail (8 msgs) faster modems Full Duplex packet on 2 meters? (3 msgs) Higher speeds New Packet Stuff @ Dayton?? Packet-Radio Digest V1 #14Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 1 May 90 15:38:48 GMTFrom: swrinde!zaphod.mps.ohio-state.edu!sunybcs!uhura.cc.rochester.edu! rochester!kodak!ektools!kinsman@ucsd.edu (Andrew A. Kinsman)Subject: DOVE TELEMETRY DATA.... here is how.To: packet-radio@ucsd.eduSpacecraft: DOVE-1: Rev: 1 Date: 1/7/90 Equations are in the form: Y = A*N^2 + B*N + C where: N = Telemetry Count (00 - FF) A, B, C = Equation Coefficients Y = Result (In Specified Units)HEX Descripion: C: B: A: Units: cccccccccc bbbbbbbbbb aaaaaaaaaa uuuuuu 0 Rx E/F Audio(W)+0.000 +0.0246 0.000 V(p-p) 1 Rx E/F Audio(N)+0.000 +0.0246 0.000 V(p-p) 2 Mixer Bias V: +0.000 +0.0102 0.000 Volts 3 Osc. Bisd V: +0.000 +0.0102 0.000 Volts 4 Rx A Audio (W):+0.000 +0.0246 0.000 V(p-p) 5 Rx A Audio (N):+0.000 +0.0246 0.000 V(p-p) 6 Rx A DISC: +10.427 -0.09274 0.000 kHz 7 Rx A S meter: +0.000 +1.000 0.000 Counts 8 Rx E/F DISC: +9.6234 -0.09911 0.000 kHz 9 Rx E/F S meter:+0.000 +1.000 0.000 Counts A +5 Volt Bus: +0.000 +0.0305 0.000 Volts B +5V Rx Current:+0.000 +0.000100 0.000 Amps C +2.5V VREF: +0.000 +0.0108 0.000 Volts D 8.5V BUS: +0.000 +0.0391 0.000 Volts E IR Detector: +0.000 +1.000 0.000 Counts F LO Monitor I: +0.000 +0.000037 0.000 Amps10 +10V Bus: +0.000 +0.05075 0.000 Volts11 GASFET Bias I: +0.000 +0.000026 0.000 Amps12 Ground REF: +0.000 +0.0100 0.000 Volts13 +Z Array V: +0.000 +0.1023 0.000 Volts14 Rx Temp: +101.05 -0.6051 0.000 Deg. C15 +X (RX) temp: +101.05 -0.6051 0.000 Deg. C16 Bat 1 V: +1.7932 -0.0034084 0.000 Volts17 Bat 2 V: +1.7978 -0.0035316 0.000 Volts18 Bat 3 V: +1.8046 -0.0035723 0.000 Volts19 Bat 4 V: +1.7782 -0.0034590 0.000 Volts1A Bat 5 V: +1.8410 -0.0038355 0.000 Volts1B Bat 6 V: +1.8381 -0.0038450 0.000 Volts1C Bat 7 V: +1.8568 -0.0037757 0.000 Volts1D Bat 8 V: +1.7868 -0.0034068 0.000 Volts1E Array V: +7.205 +0.07200 0.000 Volts1F +5V Bus: +1.932 +0.0312 0.000 Volts20 +8.5V Bus: +5.265 +0.0173 0.000 Volts21 +10V Bus: +7.469 +0.021765 0.000 Volts22 BCR Set Point: -8.762 +1.1590 0.000 Counts23 BCR Load Cur: -0.0871 +0.00698 0.000 Amps24 +8.5V Bus Cur: -0.00920 +0.001899 0.000 Amps25 +5V Bus Cur: +0.00502 +0.00431 0.000 Amps26 -X Array Cur: -0.01075 +0.00215 0.000 Amps27 +X Array Cur: -0.01349 +0.00270 0.000 Amps28 -Y Array Cur: -0.01196 +0.00239 0.000 Amps29 +Y Array Cur: -0.01141 +0.00228 0.000 Amps2A -Z Array Cur: -0.01653 +0.00245 0.000 Amps2B +Z Array Cur: -0.01137 +0.00228 0.000 Amps2C Ext Power Cur: -0.02000 +0.00250 0.000 Amps2D BCR Input Cur: +0.06122 +0.00317 0.000 Amps2E BCR Output Cur:-0.01724 +0.00345 0.000 Amps2F Bat 1 Temp: +101.05 -0.6051 0.000 Deg. C30 Bat 2 Temp: +101.05 -0.6051 0.000 Deg. C31 Baseplt Temp: +101.05 -0.6051 0.000 Deg. C32 FM TX#1 RF OUT:+0.0256 -0.000884 +0.0000836 Watts33 FM TX#2 RF OUT:-0.0027 +0.001257 +0.0000730 Watts34 PSK TX HPA Temp+101.05 -0.6051 0.000 Deg. C35 +Y Array Temp: +101.05 -0.6051 0.000 Deg. C36 RC PSK HPA Temp+101.05 -0.6051 0.000 Deg. C37 RC PSK BP Temp:+101.05 -0.6051 0.000 Deg. C38 +Z Array Temp: +101.05 -0.6051 0.000 Deg. C 39 S band TX Out: -0.0451 +0.00403 0.000 Watts3A S band HPA Temp+101.05 -0.6051 0.000 Deg. CADC Equations: V = 0.01028 N - 0.05138 N = 97.31 V +5.000------------------------------Date: Tue May 01 12:04:23 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Mon Apr 23 21:18:56 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 12:03:53 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa05949; 23 Apr 90 21:16 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id fb09731; 23 Apr 90 19:29 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id ae16278; 23 Apr 90 19:34 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa16248; 23 Apr 90 19:26 BST> Received: by ucsd.edu; id AA10927> sendmail 5.61/UCSD-2.0-sun> Sat, 21 Apr 90 04:00:07 -0700 for brian> Received: by ucsd.edu; id AA10914> sendmail 5.61/UCSD-2.0-sun> Sat, 21 Apr 90 04:00:05 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004211100.AA10914@ucsd.edu>> Date: Sat, 21 Apr 90 04:00:02 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #3> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Sat, 21 Apr 90 Volume 90 : Issue 3> > Today's Topics:> Fixmail 1.09 now posted :128.104.198.22> Innovators need thick skin (was: CP/M sofware...)> KISS Mode -- How Fast? (2 msgs)> Microwave oscillator sources (3 msgs)> USENET at Dayton Hamvention> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: Fri, 20 Apr 90 08:09:59 GMT> From: pat@pgd.adp.wisc.edu (Pat Davis)> Subject: Fixmail 1.09 now posted :128.104.198.22> To: packet-radio@ucsd.edu, tcp-group@ucsd.edu> > Fixmail 1.09 is posted on pgd.adp.wisc.edu for anonymous FTP.> 1.09 fixes a bug that would allow FIXMAIL to END/TERMINATE if/when there> was no more mail to censor.. That's right, censor.. Fixmail,> by Bryan HI-Q Biggers N9GBJ, manages SMTP mail from NET/NOS. It has some> very attractive features. FIXMAIL is Desqview "aware"..> > The file you want is FIXM109.ZIP, you might find more helpful files in> FIXM106.ZIP too...> > KD9UU> > ------------------------------> > Date: 20 Apr 90 16:18:00 GMT> From: att!cbnewsh!n2dsy@ucbvax.Berkeley.EDU (j.gordon.beattie)> Subject: Innovators need thick skin (was: CP/M sofware...)> To: packet-radio@ucsd.edu> > > First and foremost, plain old AX.25 text streams will be with us for> > a long, long time. Its the lowest common denominator for just about all of > > amateur packet radio. It is also the simplest packet "mode" to understand:> > just "CONNECT" and off you go. Given these two facts, I claim that plain> > old AX.25 text streams are and will continue to be the most popular "mode".> > I can agree with this point that the simple "CONNECT and go" user (POATS user)> is, and will be the major user type in the packet network for a long time > to come.> > I would just like to point out that the ROSE X.25 Switch software > supports "POATS" users simply by appearing to the user as a pair> of digipeaters. There's no extra user hardware or software to > buy/install/configure/hassle-with to use a ROSE X.25 network. > > In fact, the ROSE X.25 Switch will route you through the network without> the hassle that the NoNodes put you through of "connect, connect,> connect..connect, voila..the destination!" This is somewhat akin> to asking a sequence of "n" telephone operators to route your > telephone call...computers do a better job of this in less time!> > As far as interoperability goes, you can call between a NoNodes> network and a ROSE X.25 network by simply connecting using the> standard connection method for either network (C Destination v ...).> > TCP/IP is no problem to a ROSE X.25 network either: just make > a level 2 call through a ROSE X.25 network (like any POATS user)> and send your IP datagrammes through the network...simple!> > In any case, I'd like to see more integration of networks, but> let's first realize that simplicity of a tool (or a network)> can often be the most attractive feature to users.> > 73,> Gordon Beattie, n2dsy> n2dsy@hou2d.att.com> +1.201.615.4168> > ------------------------------> > Date: 20 Apr 90 01:16:22 GMT> From: bionet!hayes!usenet@apple.com> Subject: KISS Mode -- How Fast?> To: packet-radio@ucsd.edu> > I have one of the April 90 versions of NOS running on two different> PC compatibles. I can't seem to communicate reliably faster than 4800> baud. One machine is a 12 MHZ 286 with an 8250B. The other machine is a> laptop with a 4.77 MHz 80C88 and I presume the ASIC equivalent of an 8250.> Hardwired connection between the two machines with KISS mode at 4800 baud> seems reliable but 9600 baud is very spotty.> > Now the interesting thing is that the 286 machine is known to operate> to at least 38400 with an unsophisticated interrupt routine written in Turbo> Pascal. The laptop operates well at 9600 baud with various terminal emulators.> Why is NOS slower and what can I do about it? The 8250B in the 286 machine> is socketed but there is little I can do with the laptop, which is probably> the culprit. Mostly I want to know how fast can I run KISS mode on the 286> machine.> > The reason I bring this up is that I am working on a 2 chip packet> assembler/disassembler that is good to 1 Mbps (half-duplex) but I need a> decently fast way to interface it to the host computer. 4800 baud isn't> good enough.> > Philip Munts N7AHL> University of Alaska, Fairbanks> > ------------------------------> > Date: 21 Apr 90 05:47:43 GMT> From: ka9q.bellcore.com!karn@bellcore.com (Phil Karn)> Subject: KISS Mode -- How Fast?> To: packet-radio@ucsd.edu> > In article <1990Apr20.022915.8287@hayes.fai.alaska.edu> ftpam1@acad3.fai.alaska.edu writes:> > > I have one of the April 90 versions of NOS running on two different> >PC compatibles. I can't seem to communicate reliably faster than 4800> >baud.> > Fetch the latest stuff off flash.bellcore.com using anonymous ftp and> give it a try. If it isn't any better, let me know. I've been doing some> work on the 8250/16550 driver lately that should help improve performance> and I want to make sure that I haven't already fixed your problem before> looking at it again.> > Phil> > ------------------------------> > Date: 20 Apr 90 14:04:33 GMT> From: rochester!rit!cci632!dvh@rutgers.edu (David Hallidy)> Subject: Microwave oscillator sources> To: packet-radio@ucsd.edu> > In article <871@tsdiag.ccur.com>, davet@tsdiag.ccur.com (Dave Tiller N2KAU) writes:> > > > Has anyone had any experience with converting a microwave oven > > magnetron to Amateur use? Are there any problems with needing to> > 'bend' it down slightly from 2.450 GHz to make it into the Ham> > band? What are the power requirements? I noticed that MCM sells> > replacement magnetrons - could this be a source for cheep packet> > backbone oscillators? Inquiring minds gots'ta know...Any help> > would be greatly appreciated.> > > > PS - I don't intend to run one of these at ~600-1200 Watts aimed> > at the general public. A couple of Watts (<10) would be more> > resonable.> > Dave-> > Check out _RF DESIGN_ for March of 1989, there was an article about> using a microwave oven as a high powered RF source for 2450 MHz> ATV. It will work down into the ham band at the upper end of the> "13cm" segment- from 2390 to 2450 MHz. Problem is, I don't think> the stability of the mag will be very good- this may not be critical> in your application, certainly for wideband TV experimenting it's> probably not too important.> > The other problem is, you mentioned wanting to run low power- I> don't think you can with this type of setup. A magnetron, by its> nature, generates high levels of RF. It's a self excited device, and> if you try to just "lower the voltage" or reduce the intensity of> the magnetic field around the tube, it just won't oscillate. The way> the microwave ovens run at "reduced" power is to turn the tube on> and off for varying periods of time- this has the effect, on food,> of reducing the heating by reducing the amount of time the food is> exposed to the RF. The level of RF when the mag is running is always> at full power (>600 Watts, usually).> > I do think it might be worthwhile to experiment with injection-locking> of the magnetron to stabilize its output frequency. This would make> for a very cheap source of extremely high power on the band, useable> for modes other than wideband TV. Let me know if you try any of this> and any success (or failure) you may have.> > Hope this helps you some.> > 73 Dave H. KD5RO/2> > ------------------------------> > Date: 20 Apr 90 20:01:56 GMT> From: swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!t urnkey!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.c om!dana@ucsd.edu (Dana H. Myers)> Subject: Microwave oscillator sources> To: packet-radio@ucsd.edu> > In article <871@tsdiag.ccur.com> davet@tsdiag.ccur.com (Dave Tiller N2KAU) writes:> >> >Has anyone had any experience with converting a microwave oven > >magnetron to Amateur use? Are there any problems with needing to> >'bend' it down slightly from 2.450 GHz to make it into the Ham> >band? What are the power requirements? I noticed that MCM sells> >replacement magnetrons - could this be a source for cheep packet> >backbone oscillators? Inquiring minds gots'ta know...Any help> >would be greatly appreciated.> > Look in the 1989 index for 73 magazine - a cover article detailed> conversion of a surplus oven to ATV/FM use, a $200 700W exciter !> I'll try to get the date or possibly someone else can post it.> > > ***************************************************************** > * Dana H. Myers WA6ZGB | Views expressed here are *> * (213) 337-5136 | mine and do not necessarily *> * dana@locus.com | reflect those of my employer *> ***************************************************************** > > ------------------------------> > Date: 21 Apr 90 02:15:45 GMT> From: usc!pollux.usc.edu!kjh@ucsd.edu (Kenneth J. Hendrickson)> Subject: Microwave oscillator sources> To: packet-radio@ucsd.edu> > In article <871@tsdiag.ccur.com> davet@tsdiag.ccur.com (Dave Tiller N2KAU) writes:> >Has anyone had any experience with converting a microwave oven > >magnetron to Amateur use?> > It's already been done. Somebody in Illinois did it on ATV. There was> a skimpy write-up about it in one of the RF trade rags about Fall of> '88. I can't remember which magazine, but I think it might have been> "RF & Microwaves". Don't waste your time looking for the magazine,> however, there wasn't any more information in it than I have posted> here. It was kind of like the ARRL's current publication of microwave> information in QST.> > Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh> > ------------------------------> > Date: 20 Apr 90 02:34:52 GMT> From: usc!cs.utexas.edu!execu!sequoia!attdso!ssc!tad@ucsd.edu (Tad Cook)> Subject: USENET at Dayton Hamvention> To: packet-radio@ucsd.edu> > Just ONE more reminder. . . .If you are going to the Dayton Hamvention,> USENET folks will be getting together at Stouffers on Friday night in> suite 425, at the DIGITAL SUITE. Stouffers is downtown at Fifth and> Jefferson.> > See you there!> > > Tad Cook> Seattle, WA> Packet: KT7H @ N7HFZ.WA.USA.NA> Phone: 206/527-4089 > MCI Mail: 3288544 > Telex: 6503288544 MCI UW > USENET:...uw-beaver!sumax!amc-gw!ssc!tad> or, tad@ssc.UUCP> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 12:08:24 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Mon Apr 23 23:52:08 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 12:07:58 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa12342; 23 Apr 90 23:50 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id rp09731; 23 Apr 90 22:11 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id ab18786; 23 Apr 90 20:36 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa18731; 23 Apr 90 20:32 BST> Received: by ucsd.edu; id AA14795> sendmail 5.61/UCSD-2.0-sun> Mon, 23 Apr 90 04:00:07 -0700 for brian> Received: by ucsd.edu; id AA14783> sendmail 5.61/UCSD-2.0-sun> Mon, 23 Apr 90 04:00:04 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004231100.AA14783@ucsd.edu>> Date: Mon, 23 Apr 90 04:00:02 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #5> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Mon, 23 Apr 90 Volume 90 : Issue 5> > Today's Topics:> Has NOS been ported to the Atari ST?> TAPR TNC-2 for sale> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 23 Apr 90 01:34:39 GMT> From: swrinde!zaphod.mps.ohio-state.edu!samsung!umich!pmsmam!pmsmam.uuc p!wwm@ucsd.edu (Bill Meahan)> Subject: Has NOS been ported to the Atari ST?> To: packet-radio@ucsd.edu> > The subject line says it all.> > If not, why not? Micro-RTX could easily provide the requisite multi-tasking> kernel if the one that's included in the NOS source isn't suitable.> > We ST users wait with bated breath! (especially we who still have older> 520's :-) :-} )> -- > Bill Meahan | UUCP: uunet!mailrus!umich!pmsmam!wwm> | snail: 128 Factory St., Ypsilanti, MI 48197> #include <disclaimer.std> | voice: +1 313 484 9320> /* witty */ |packet: wa8tzg @ wa8ooh.mi.usa.na> > ------------------------------> > Date: 22 Apr 90 06:54:54 GMT> From: sumax!ole!ray@beaver.cs.washington.edu (Ray Berry)> Subject: TAPR TNC-2 for sale> To: packet-radio@ucsd.edu> > I have a TAPR TNC-2 built from a kit several yrs back I'd like to> sell. It was built and tested, aligned, etc., but never used. The firmware> is at whatever level existed at the time the TNC-2 first shipped. > I'd like $100 for this thing. I've never been active in packet,> so I don't know if this thing is already obsolete or what... if the price > sounds too high, please make an offer. Thanks.> -- > Ray Berry kb7ht uucp: ...ole!ray CIS: 73407,3152 /* "inquire within" */> Seattle Silicon Corp. 3075 112th Ave NE. Bellevue WA 98004 (206) 828-4422> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 12:15:30 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Tue Apr 24 06:54:29 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 12:15:03 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa00189; 24 Apr 90 6:50 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id fm22320; 24 Apr 90 4:59 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id ax28088; 24 Apr 90 3:19 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa27762; 24 Apr 90 2:13 BST> Received: by ucsd.edu; id AA26011> sendmail 5.61/UCSD-2.0-sun> Sun, 22 Apr 90 04:00:08 -0700 for brian> Received: by ucsd.edu; id AA25993> sendmail 5.61/UCSD-2.0-sun> Sun, 22 Apr 90 04:00:04 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004221100.AA25993@ucsd.edu>> Date: Sun, 22 Apr 90 04:00:02 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #4> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Sun, 22 Apr 90 Volume 90 : Issue 4> > Today's Topics:> Innovators need thick skin> Microwave oscillator sources> Packet-Radio Digest V1 #3> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 21 Apr 90 22:42:34 GMT> From: sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!k d4nc!ke4zv@ucsd.edu (Gary Coffman)> Subject: Innovators need thick skin> To: packet-radio@ucsd.edu> > In article <22370@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes:> >> >But be that as it may, you are getting somewhat closer to the truth. As> >I said before, TCP/IP has little to offer unless you have a computer.> > WORDS TO LIVE BY! I would also add that packet in general has little to> offer unless you have a computer. Contentless keyboard QSOs crawling> through the network have little value after the thrill of doing it once> wears off.> The real value of packet radio is connecting computers together in a> network to perform a useful function. Things like Email, Remote File> Sharing, and distributed computing are possible only with reliable> end to end data transfer. Our current slow network already carries> an important amount of Email. MUCH faster networks will make the other > things realistic. And there's the rub, little Terminal Node Controllers> aren't capable of supporting faster modems. In fact, TERMINAL Node> Controller is a concept whose time is past. It's time to return to> the PAD (Packet Assembler Disassembler) now that it is a single chip> (8530) in the computer and attach that to a truly high speed modem.> High speed modems are available and affordable NOW at 56kb and soon> at megabit rates. > > LET'S NOT FALL INTO THE TRAP OF HITCHING OURSELVES TO THE DEAD PAST> WITH A NETWORK DESIGN THAT CANNOT EASILY MIGRATE TOWARD OUR ULTIMATE> GOALS.> > Gary KE4ZV> > ------------------------------> > Date: 20 Apr 90 00:27:03 GMT> From: snorkelwacker!bu.edu!mirror!otto!jimi!unsvax!storkus@think.com (Mike Storke (N7MSD))> Subject: Microwave oscillator sources> To: packet-radio@ucsd.edu> > I'd also be very interested in knowing if you can convert a microwave oven> magnetron to amateur bands. Unlike the guy who originated this, I *WOULD* use> it at or near it's full rated power. This would be used for long-haul packet> links (~200+ miles, to be exact: Las Vegas-Bishop, California-Reno; a 2M link> currently exists along this route, but it's too loaded down). Any info would> be appreciated. Note that these links are all on top of mountains > 8500 ft.> high. Thanks and 73's, Mike, N7MSD> P.S. I got a hold of a surplus house that has traveling wave tubes for 2-4 gigs> and 8-9.6 gigs. Can the 8-9.6 be used at the 10 gig ham band? A friend of> mine said no because they are *very hard* to tune-he says they're something> like a helical antenna at their center frequency. Any info appreciated as> always, Mike> > ------------------------------> > Date: Sat, 21 Apr 90 22:31 EST> From: LARRY KNEHR <CSCON104@uoft02.utoledo.edu>> Subject: Packet-Radio Digest V1 #3> To: Packet-Radio@UCSD.EDU> > > > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 12:36:08 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Tue Apr 24 15:44:27 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 12:35:53 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa02220; 24 Apr 90 14:55 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id al06530; 24 Apr 90 11:49 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id ab11817; 24 Apr 90 13:04 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa11692; 24 Apr 90 13:00 BST> Received: by ucsd.edu; id AA20953> sendmail 5.61/UCSD-2.0-sun> Tue, 24 Apr 90 04:00:13 -0700 for brian> Received: by ucsd.edu; id AA20939> sendmail 5.61/UCSD-2.0-sun> Tue, 24 Apr 90 04:00:10 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004241100.AA20939@ucsd.edu>> Date: Tue, 24 Apr 90 04:00:06 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #6> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Tue, 24 Apr 90 Volume 90 : Issue 6> > Today's Topics:> Apple II Software for RTTY and Facsimile ?> faster modems> Getting Started!?> MFJ 1274 TNC for sale> pulse on X-band (2 msgs)> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 23 Apr 90 15:29:50 GMT> From: ncs.dnd.ca!asterix.drev.dnd.ca!louis@rutgers.edu (Louis Demers)> Subject: Apple II Software for RTTY and Facsimile ?> To: packet-radio@ucsd.edu> > (I am posting this for a collegue, hope this is the right place)> > A friend is looking for software for his Apple II+ to receive> Facsimile (he already has the interface to his radio) for example> of wheather maps. He would like also a piece of software that > implements the RTTY protocol.> > If software is unavailable, we would settle for the algorytms.> > Please respond through Email as this site doesn't receive any of the> rec. groups.> > PPS: Please don't laugh, this is all foreign to me.> -- > | Louis Demers | DREV, Defence Research Establishment,Valcartier |> | louis@asterix.drev.dnd.ca | POBox 8800, Courcelette,Quebec, CANADA, G0A 1R0 |> | (131.132.48.2) | Office: (418) 844-4424 fax (418) 844-4511 |> +---------------------------+------------------------------------ -------------+> > ------------------------------> > Date: Mon, 23 Apr 90 14:34:34 MST> From: sarrel%miranda.uucp@moc.Jpl.Nasa.Gov (Marc Sarrel)> Subject: faster modems> To: packet-radio@ucsd.edu> > Well, there has been some discussion recently here about how most hams> with TNCs are using horribly outdated and slow equipment. 1200 baud> seems to be the lowest common denominator. And, sometimes I get the> feeling that some hams don't have much desire or incentive to move to> higher baud rates. In fact, I spent a while talking to the "packet> expert" at a local amateur radio store recently. I asked him about> some TNC that had a 2400 baud modem vs one that had a 1200 baud modem.> I asked wether 2400 would catch on, given my experience with land line> modems where everyone was starved for speed. He said "no." His> reasons seemed pretty fuzzy to me, but he seemed to claim that 1) 2400> baud wouldn't catch on because everyone already has 1200 baud modems,> 2) 1200 baud seemed fast enough to him, and 3) that 2400 baud wasn't> _really_ twice as fast as 1200 because the extra speed was used> inefficiently. (But don't hold me to that, this was a while ago.)> > Anyway, my question is this: How can we "hams in the know" encourage> the use of faster and more effecient modems on the airwaves, given> that we agree that "faster is better." One of this guy's arguments> holds weight in that there is a lot of "hardware inertia" out there.> > Specifically what kind of faster and more efficient modems are> available and suitable for packet-radio? How fast is fast? 9600?> 19.2K? 56K? How much extra bandwidth do these faster modems require?> What about FCC regulations on speed?> > Is there such a thing as auto baud rate recognition that would allow a> digipeater to work a several different speeds with different stations> on the same frequency? This would allow a smoother transition to> faster modems by giving people incentive to buy them without> immediately obsoleting everyone's 1200 baud equipment?> > Would it be a good idea to set up digipeaters that work on several> different speeds (and frequencies) as a way of encouraging higher baud> rates?> > Just curious,> > --marc> -=-> Marc A. Sarrel> N7OLI> sarrel%miranda.uucp@moc.jpl.nasa.gov | "Oh, _lightweight_ Alpaca..."> ..!sun!sunburn!miranda!sarrel | -Blanche DuBois> > ------------------------------> > Date: 23 Apr 90 08:32:11 GMT> From: usc!sdsu!crash!jburnes@ucsd.edu (Jim Burnes)> Subject: Getting Started!?> To: packet-radio@ucsd.edu> > Hi!> > A friend of mine and I want to get into packet radio. We are not hams.> We are willing to jump through the necessary hoops. We both are software/> hardware engineers and understand various amounts of circuit theory.> We would like to know:> > 1. What is the highest speed modem usable on standard packet frequen-> cies? I have heard of 9600 bps modems being used. What about> Telebit Trailblazer spread-spectrum type modems?> > 2. What class of ham liscense is necessary to run packet? What tests> and theory must we have to get this liscense?> > 3. How much would a rig capable of 2400 bps operation cost (used)?> I already have a 386 machine. I would like to upgrade to national/> international coverage (if that is applicable) and also to higher> speeds.> > 4. I have heard that you cant upload messages/files to someones node> and then have that information automatically forwarded through> a network. Someone told me humans had to intervene. That sounded> silly. Kinda defeats the whole purpose of a network, no? Sorry..> since I'm mostly a pc hacker I not quite sure how to ask a lot of> questions without sounding naive.> > 5. What is a good book to get started with?> > 6. It seems like I have been trying to get into packet/ham for the last> 5 years or so and always fail to clear the morse/test hurdles. I'd> like to remedy this as soon as possible. Any ideas for making the > transition easier?> > Yours in communications,> Jim Burnes> > -------------------> I do not beleive in 'isms> I think, on the whole, 'isms are a bad thing> > Ferris Buehler (paraphrased)> --------------------> > ------------------------------> > Date: 24 Apr 90 00:53:37 GMT> From: psuvm!mls129@psuvax1.cs.psu.edu (Michael L. Sensor)> Subject: MFJ 1274 TNC for sale> To: packet-radio@ucsd.edu> > For sale once again:> > MFJ 1247 HF/VHF TNC. Almost never used (yes it works).> > LED tuning display. Compatible with MFJ WeFAX software (for PCs and> Macintoshes). Personal mailbox.> > Comes with 5-lead RS232 cable and homebrew connector to use on Icom IC2AT.> > Bought for $150.00 at Dayton. Asking $125.00. May trade or bargain.> > For more info:> > Mike Sensor KD3LR / AFA1UP> Box 134 Oak Hall> Penn State Altoona Campus> Altoona PA 16601-3760> (814) 949-5439> UNTIL MAY 4!> > 2406 E 32 St> Erie PA 16510-2702> (814) 899-8261> AFTER MAY 4!> > C'mon, MFJ isn't *that* bad!> > Mike Sensor MLS129 @ PSUVM> > ------------------------------> > Date: 24 Apr 90 01:28:17 GMT> From: usc!pollux.usc.edu!kjh@ucsd.edu (Kenneth J. Hendrickson)> Subject: pulse on X-band> To: packet-radio@ucsd.edu> > I received some email from W3OTC that I responded to, and thought a> posting would be appropriate. Here it is:> > % From: Robert Carpenter <rc%cmr.ncsl.nist.gov@usc.edu>> > % Am I missing something? It seemed to me that you wouldn't benefit from a> % low duty cycle when fighting a large path loss. I would think that some> % synchronous system, with correlation detection of some sort, would be the> % best bet. Of course you COULD build a receiver that just listened during> % the narrow pulses to ignore the in-between noise. I'd also worry a bit> % about pulse-spreading due to multipath. Maybe a pseudo-random scheme would> % be a good approach, but would likely have a mid-to-high duty cycle, and thus> % not be pulse.> > It is a possibility to build a receiver that only listens when a pulse> is supposed to occur, but that wasn't necessarily what I was thinking> about. The advantage of using the high peak power of a pulse is that it> would be EASILY DETECTABLE even with high path loss. This means that> (in theory) you could set up a data link much like CW is used with the> human ear: the presence of a pulse has one meaning, and the absence of a> pulse has another. There is probably even a better way to do it:> consider what you could do if you were to phase modulate the pulses. In> other words, control the time delay or latency between pulses. A short> time delay could mean a 0 bit, and a long delay could mean a 1 bit.> > % Or do you have a good source of low duty cycle 10 GHz power, and want to> % build a system around it?> > No, I don't have a 10 GHz pulse source, but they are available. Now if> we could only use them legally ...> > % Pardon the confused questions, but I don't normally think of low-duty-cycle> % pulse transmission and weak signal operation as going together.> > Most people don't. Certainly, I'm not suggesting that real time> communications like voice be sent this way. I'm merely proposing that> this might be a good use for part of our microwave spectrum. The packet> guys are in great need of high-speed inter-city links (among other> things).> > % Bob W3OTC> > % PS. Look at the picture of the 10 GHz SSB PHONE station in QST (I thought in> % W3XO's column, but can't find it.) I've seen and heard '3XO's video of it> % operating over a non-line-of-sight 25 mile path with excellent sigs.> % The power output was in the 20 - 100 mW range, I think.> > I've done better than 40 miles over non-line-of-sight paths with only> 10 mW and CRUDDY WIDEBAND FM! This was with 2 foot dish antennas on> both ends of the path at X-band. Still, I'm not pooh-poohing their> efforts; I'm just trying to show that even with simple cheap equipment> you can do a lot more than most people expect in the SHF and EHF> spectrum.> > Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh> > ------------------------------> > Date: 24 Apr 90 01:41:49 GMT> From: usc!pollux.usc.edu!kjh@ucsd.edu (Kenneth J. Hendrickson)> Subject: pulse on X-band> To: packet-radio@ucsd.edu> > In article <1250147@hpnmdla.HP.COM> glenne@hpnmdla.HP.COM (Glenn Elmore) writes:> % Ken,> % I don't think pulse privileges really are that much of an issue in> % preventing effective use of the band. As I see it, the main advantage would be> % in using surplus hardware.> > Yes, this would be the advantage. I'm not suggesting that we have an> undue hardship with the pulse restriction; I am suggesting that it is> arbitrary and capricious, and that if we didn't have the restriction,> there would be one more possible way that we could effectively> communicate on the band.> > % However, moderate power narrowband > % equipment is no longer a difficult proposition. Very long links and> % OTH links require optimum use of the resources; reasonably efficient> % use of the spectrum (bps/Hz numbers) and highly directional beams to> % avoid waste and QRM; as well as physically larger receive antenna apertures> % to recover the information. Even so I suspect that for reliable networks and > % comm. channels we are likely to end up with a larger number of shorter LOS > % links instead of long haul OTH ones.> > This may be true. However, I don't think anybody has ever experimented> with using high-power low-duty-cycle signals to build a packet switched> microwave network. My idea might not pan out to anything, but on the> other hand, how will we know unless somebody tries to do it?> > % Troposcatter is a fairly predictable > % propagation mechanism at 10 GHz (see my description of an> % experience with it on a 400+ mile path during the 1987 10 GHz terrestrial > % DX record outing in December 1987 QST) but long haul links are inherently> % lossier and less reliable than shorter LOS ones.> % I strongly agree that we need to use our microwave resources and in> % particular 10 GHz but I think we will end up finding that for efficient> % use of our amateur resources we will start looking more like the telephone> % companies and common carrier folks when we solve the backbone problem.> % > % Glenn Elmore -N6GN- N6GN @ K3MC glenn@n6gn.ampr.org glenne@hpnmd.hp.com > > Sure, we might wind up looking like the telephone companies. Maybe they> have already tried the pulse idea. On the other hand, I have never> heard of it. If nobody has yet tried it, to see what the results are,> what is wrong with us amateurs giving it a try. It just might be> useful.> > Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 15:00:22 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Thu Apr 26 17:52:50 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 15:00:00 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa01499; 26 Apr 90 17:46 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id aa09309; 26 Apr 90 16:06 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id ac10941; 26 Apr 90 17:16 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa10889; 26 Apr 90 17:13 BST> Received: by ucsd.edu; id AA19048> sendmail 5.61/UCSD-2.0-sun> Thu, 26 Apr 90 08:28:37 -0700 for brian> Received: by ucsd.edu; id AA19043> sendmail 5.61/UCSD-2.0-sun> Thu, 26 Apr 90 08:28:36 -0700 for /us r/l ib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004261528.AA19043@ucsd.edu>> Date: Thu, 26 Apr 90 08:27:52 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #9> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Thu, 26 Apr 90 Volume 90 : Issue 9> > Today's Topics:> DEC Rainbow> DOVE Satellite> faster modems> How decipher DOVE telemetry?> TAPR DCD on Heath 4040> US Navy and packet radio> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 25 Apr 90 19:53:26 GMT> From: swrinde!cs.utexas.edu!samsung!xylogics!bu.edu!m2c!wpi!tmurphy@ucs d.edu (Tom [Chris] Murphy)> Subject: DEC Rainbow> To: packet-radio@ucsd.edu> > With any luck, I'll be getting a Technician licence this weekend and> as soon as it comes in the mail, I plan on trying some work with packet> radio. I may be inheriting a DEC Rainbow, and was wondering what software> exists for it to do TCP based work, primarily mail although telnet and> ftp would be nice also. Thanks for the help in advance!> > Tom Murphy> tmurphy@wpi.wpi.edu> > ------------------------------> > Date: 25 Apr 90 15:06:01 GMT> From: idacrd!mac@princeton.edu (Robert McGwier)> Subject: DOVE Satellite> To: packet-radio@ucsd.edu> > In article <9004241908.AA14576@ucsd.edu>, by KEVIN@CALSTATE.BITNET:> > I have been monitoring for DOVE for a coupla days, and haven't heard a peep.> >> > Kevin:> > It is alive and well downlinking on 2401.100 Mhz +/- an unbelievable amount> of doppler. There is no way the straight calculation can be as impressive> as trying to track that stuff and copy data! I am reloading its software> and its gonna do speech when it comes back on.> > Bob> > -- > _________________________________________________________________ ___________> My opinions are my own no matter | Robert W. McGwier, N4HY> who I work for! ;-) | CCR, AMSAT, etc.> ----------------------------------------------------------------- -----------> > ------------------------------> > Date: 26 Apr 90 02:10:11 GMT> From: sun-barr!newstop!texsun!texbell!splut!jay@apple.com (Jay "you ignorant splut!" Maynard)> Subject: faster modems> To: packet-radio@ucsd.edu> > In article <22526@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes:> >I have done a *lot* of thinking about this problem. Given that amateur radio> >is a voluntary, personally funded activity, you can't force hams to buy new> >hardware. But there's another approach: establishing a frequency allocation> >policy that encourages the use of more efficient modulation and frequency> >reuse techniques. The more efficient your proposed use of the spectrum, the> >more likely you are to get an allocation.> > >Amateur frequency coordinators now follow a first-come first-served policy,> >and this *must* change. In many areas like Los Angeles and New York, the> >VHF/UHF bands are nearly full with FM repeaters and conventional 1200 baud> >packet, and there is little room to experiment with newer, more efficient> >techniques.> > (dig, dig...ok, I found it.) [putting on President, Texas VHF-FM Society hat]> > You've beat this drum before, and I've argued it before. While your idea> has merit in a perfect society, it *cannot* work in the real ham world.> > Frequency coordinators now serve in an advisory capacity. You'd like us> to tell people who have coordinations and are currently operating> repeaters on frequencies where they do not experience regular,> significant interference (the standard which coordinators try to> maintain) that, all of a sudden, the rules have changed, and that they> must either shut down entirely, or accept unheard-of, and previously> unacceptable, levels of interference.> > They wouldn't listen to us.> > Instead, they'd keep on operating on what they perceive as *their*> frequency. You know that they don't own it, I know it, but they don't -> and they're the only ones with the power to make such a change work.> > Frequency coordination and spectrum management isn't just a technical> problem, but a highly political one as well. Come up with a way to> accomplish your goal that *can* be accepted by the population of current> FM voice system operators and users, and your wish will come true, and> I'll sign up to promote it. This isn't the school debate society,> though, where changes can be implemented by fiat. You must account for> the mechanisms involved in implementing the change, and _that_ is where> your problem lies.> > -- > 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, RIP. It was nice knowing ya +----------------------------------------> "Flying is a lot more fun than being in the Senate." -- Senator Jake Garn> > ------------------------------> > Date: 25 Apr 90 22:20:31 GMT> From: deimos.cis.ksu.edu!harris.cis.ksu.edu!mac@uunet.uu.net (Myron A. Calhoun)> Subject: How decipher DOVE telemetry?> To: packet-radio@ucsd.edu> > My packet station can hear DOVE's telemetry;> now I'd like to know what it means.> > Is there a source for software to decipher the> hex stuff into meaningful-to-humans information?> > Please reply by email.> --Myron.> --> # Myron A. Calhoun, Ph.D. E.E.; Associate Professor (913) 539-4448 home> # INTERNET: mac@harris.cis.ksu.edu (129.130.10.2) 532-6350 work> # UUCP: ...{rutgers, texbell}!ksuvax1!harry!mac 532-7004 fax> # AT&T Mail: attmail!ksuvax1!mac> > ------------------------------> > Date: 25 Apr 90 20:27:41 GMT> From: sdd.hp.com!zaphod.mps.ohio-state.edu!sunybcs!uhura.cc.rochester.e du!rochester!kodak!eastman!hpcore!gerwitz@ucsd.edu (Paul Gerwitz)> Subject: TAPR DCD on Heath 4040> To: packet-radio@ucsd.edu> > I am posting this for someone who does not have net access. Please send> email replies to him directly at 'uunet!atexnet!kodak!eastman!dieter'.> > ----------------------------------------------------------------- ------> > Subject: HELP w/ TAPR DCD Upgrade> > I recently built a TAPR 2211 DCD upgrade kit. It is supposed to enhance DCD> operation.> > After installing the kit in my Heath HD-4040, the DCD light in fact does seem> to react much better (less falsing, more constant when it does lock on). The> only problem is now my TNC will TRANSMIT EVEN WHEN THE DCD LIGHT IS ON !!!! I> have checked the assembly and the value of most of the components. I cannot> imagine how the thing can transmit with the DCD light on. It's supposed to> inhibit transmit isn't it ? If anybody has any experience with this PLEASE> HELP !!! Leave a message, or call Mark at (716) 723-0227. Thanks> > ----------------------------------------------------------------- -------> --> +---------------------------------------------------------------- ------------+> | Paul F Gerwitz WA2WPI | SMTP: gerwitz@kodak.com |> | Eastman Kodak Co | UUCP: ..rutgers!rochester!kodak!eastman!gerwitz |> +---------------------------------------------------------------- ------------+> > ------------------------------> > Date: 25 Apr 90 16:08:00 EDT> From: "SWEIGERT, DAVID" <dsweigert@paxrv-nes.navy.mil>> Subject: US Navy and packet radio> To: "packet-radio" <packet-radio@wsmr-simtel20.army.mil>> > The U.S. Navy has commissioned a multi-media test of ship-shore> data communications. Particular media under test:> > o HF communications> o Fleet SATCOM (2400 bit/second US Navy satellites)> o INMARSAT Commercial satellite channels> > It is believed the HF communications portion shall include a packet radio> test.> > SPAWAR Code PMW-156 (Capt. Joesph Price, USN) is coordinating the test> at the direction of VADM Jerry O. Tuttle, USN, OPNAV Code 094. The testing> agent shall be the Naval Engineering Center at Vallejo, CA. The test platforms> shall be ships assigned out of San Diego, CA. The test is lated to begin> this summer.> > Mission support data shall be transferred from an aircraft carrier to shore> based NARDAC, Naval Regional Data Automation Center.> > > cheers...> > WB9VKO> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 15:15:49 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Fri Apr 27 13:29:54 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 15:15:27 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa05720; 27 Apr 90 13:20 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id af04978; 27 Apr 90 12:04 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id aa13232; 27 Apr 90 12:56 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa13189; 27 Apr 90 12:54 BST> Received: by ucsd.edu; id AA20478> sendmail 5.61/UCSD-2.0-sun> Fri, 27 Apr 90 04:00:10 -0700 for brian> Received: by ucsd.edu; id AA20467> sendmail 5.61/UCSD-2.0-sun> Fri, 27 Apr 90 04:00:06 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004271100.AA20467@ucsd.edu>> Date: Fri, 27 Apr 90 04:00:03 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #10> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Fri, 27 Apr 90 Volume 90 : Issue 10> > Today's Topics:> Ham Packet BBS on ATT UNIX PC?> Universal M-610 wanted> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 27 Apr 90 02:31:18 GMT> From: zaphod.mps.ohio-state.edu!math.lsa.umich.edu!sharkey!lopez!flash@ tut.cis.ohio-state.edu (Gary Bourgois)> Subject: Ham Packet BBS on ATT UNIX PC?> To: packet-radio@ucsd.edu> > Here's the deal. I am the system administrator of a Public Access Unix > BBS, and have been running a BBS at the same phone number since 1983. > Being a consultant by trade, and doing all of my work at home, I can run > the BBS, and also play ham radio day and night. I have a speaker from > the ham rig in my computer room, and I have a video feed from the BBS > monitor in my ham shack. The two hobbies sort of meld. I talk with > other UNIX people on the ham bands, and send email to ham friends on > USENET.> > I am obsessive compulsive, I admit it and I use it to an advantage.> > I do not have a packet system. Not today. I always managed to put it > off.> > The PBBS that serves this area of Upper Michigan is going to be going > down soon. They are looking for someone else to run one.> > A ham from Lower Michigan said he would donate a TNC. I agreed to supply > what equipment I can, and am mulling over what is the best way to go. I > have an old XTAL type 2m rig and a spare antenna to kick into the project.> > I also have an AT&T UNIX PC with a 20 meg hard drive. Not much, but > probably enough to run a PBBS.> > Why the UNIX PC? (also known as a 7300, or 3b1)> > Well I got to thinking how easy it would be, while reading rec.ham.radio > on the console of the landline BBS, I could forward articles to the > Packet BBS with ease, using UUCP.> > Has anyone ever done this?> > Would the 3b1 be up to the job? If so, I will also donate that to the > project. It would be a great service to the hams of Northern Michigan to > have selected articles from USENET ported over to our local PBBS. I will > not do it if I have to haul floppies up a flight of stairs (The USENET > site is on the ground floor, and my hamshack is one floor up).. BUT > using UUCP would be a breeze.> > Our own BBS software on lopez is locally written, so I can have any mods > I want tossed in simply, and many I can write myself (The software > STARBASE, is very configurable, and will eventually be made public)...> > The trick will be to link everything together. I am sure it could be > done with a XENIX type PC, but that route is beyond our meager budget.> > Any ideas, thoughts, ponderings, musings, experiences welcome.> > Thanks, es 73> > Gary> -- > == 14.313 == Amateur Radio Forum Saturday 11:00AM Eastern time == 14.313 ==> == Gary Bourgois flash@lopez (rutgers!sharkey!lopez!flash) GWN UPLink ==> == 3.950 Nationwide Amateur Radio Nightly after 0200z=Learning Channel ==> =============== WB8EOH = The Eccentric Old Hippie = WB8EOH ================> > ------------------------------> > Date: 26 Apr 90 13:50:56 GMT> From: portal!cup.portal.com!Lee_-_Reynolds@apple.com> Subject: Universal M-610 wanted> To: packet-radio@ucsd.edu> > Wanted - the Universal M-610 tuning scope and M-605 FDM box.> > > Please Email me at Portal or call me at (617)860-8629> > > Lee G8LCK> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 15:36:44 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Sat Apr 28 13:33:05 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 15:36:23 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa10554; 28 Apr 90 13:28 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id aa04573; 28 Apr 90 12:33 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id aa05678; 28 Apr 90 13:13 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa05603; 28 Apr 90 13:08 BST> Received: by ucsd.edu; id AA24794> sendmail 5.61/UCSD-2.0-sun> Sat, 28 Apr 90 04:00:07 -0700 for brian> Received: by ucsd.edu; id AA24788> sendmail 5.61/UCSD-2.0-sun> Sat, 28 Apr 90 04:00:06 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004281100.AA24788@ucsd.edu>> Date: Sat, 28 Apr 90 04:00:03 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #11> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Sat, 28 Apr 90 Volume 90 : Issue 11> > Today's Topics:> faster modems> Ham Packet BBS on ATT UNIX PC?> Hams in space?> MFJ TNC sold> Networking> SAREX STS-35 space shuttle> shareware in packet radio> Teletext> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 25 Apr 90 18:57:01 GMT> From: vsi1!zorch!tandem!kevinr@apple.com (Kevin J. Rowett)> Subject: faster modems> To: packet-radio@ucsd.edu> > In article <690@idacrd.UUCP> mac@idacrd.UUCP (Robert McGwier) writes:> >> >I believe that for hams in the US, it must be made into an appliance.> > I completely agree Bob!> > > We> >have also suffered another set back with the Totally Awesome IO board> ^^^^^^^^> > Bob, from the trenches, we don't really view it as a set back. Delay> *maybe*, but Awesome I/O *is* happenning! I'm staring at film right> now ready to go to a board maker....> > We do live in Silicon Valley, and getting cards made is easier than> shopping for a car here. The PacBell yellow pages has three entire> pages listing people who will make cards..> > We realize there's more to getting a product out than just having cards > made, but it K3MC Awesome will happen.> > >project. Its commercial license was never completed and those efforts> >have now fallen through. > > THis really sounds worse than it is. K3MC (Awesome ) has not died! Only the> arrangements with that particular commericalizer.> > > Totally Awesome> >IO from K3MC/N6RCE, 10 Ghz-megabit stuff from Glen Elmore, TCP-IP from> >KA9Q, we have ALL the technology we need to lead us into 21-st century.> >> >Bob> > > N6RCE> > ------------------------------> > Date: 27 Apr 90 21:24:51 GMT> From: umich!sharkey!cfctech!ttardis!rlw@CS.YALE.EDU (Ron Wilson)> Subject: Ham Packet BBS on ATT UNIX PC?> To: packet-radio@ucsd.edu> > In article <1990Apr27.023118.15972@lopez.UUCP>, flash@lopez.UUCP (Gary Bourgois) writes:> >A ham from Lower Michigan said he would donate a TNC. I agreed to supply > >what equipment I can, and am mulling over what is the best way to go. I > >have an old XTAL type 2m rig and a spare antenna to kick into the project.> >> >I also have an AT&T UNIX PC with a 20 meg hard drive. Not much, but > >probably enough to run a PBBS.> >....> >The trick will be to link everything together. I am sure it could be > >done with a XENIX type PC, but that route is beyond our meager budget.> >> >Gary> > Anything thing you can do with Xenix on a PC, you can do with the Unix-PC.> > A 20 meg disk might be too small - even a minimal news feed requires a lot> of disk space.> > There is program written by the people at KA9Q called simply KA9Q. It is> a program designed to implement protocols like Telnet (a terminal emulator),> FTP (file transfer protocol), and others over packet radio.> > KA9Q does work on the Unix-PC.> > Using the KA9Q program and a pty driver would enable any Unix system to> receive Telnet and FTP connections over packet radio (not to mention SLIP/SLFP> connections from other computers).> > Because of the pty driver (psuedo terminal), any Telnet connection would log> into the Unix system normally (via getty and login) just as through the> person had called in with a modem.> > I'm sure other people on the net can help you with technicalities in setting> this up (I know nothing about packet radio other than what it is).> > Good luck.> > - Ron> > ------------------------------> > Date: Fri, 27 Apr 90 07:52:53 PDT> From: KEVIN%CALSTATE.BITNET@CORNELLC.cit.cornell.edu> Subject: Hams in space?> To: packet-radio@ucsd.edu> > I recall reading some months ago that this summer, an astronaut on the Space> Shuttle will be doing 2 meter packet communications with earthlings.> > When will this occur? On what frequency? Will it be possible for me> to communicate with them using my BIG 5 watts of power? do i need a special> antenna or will my rinkydink ones made out of coathangers do the trick?> I expect QRM will be real bad, but the equiptment I got is what I'm stuck> with ... I yam what I yam.> > All help appreciated!> > -- Kevin> > +----------------------------------------+ DISCLAIMER: I assume no> : KEVIN M. SAVETZ - KC6GWQ : responsibility for any messages> : Bitnet: kevin@calstate.BITNET : that I post, expressed or> : Internet: humbolt!waffle@csun.edu : implied. Opinions expressed> : Fishnet: salmon@smoked.poached.fried : by me are not necessarily> +----------------------------------------+ my own.> > -30-> > ------------------------------> > Date: 27 Apr 90 19:39:24 GMT> From: psuvm!mls129@psuvax1.cs.psu.edu (Michael L. Sensor)> Subject: MFJ TNC sold> To: packet-radio@ucsd.edu> > The MFJ 1274 TNC I advertised here has been sold.> > Mike Sensor MLS129@PSUVM> > ------------------------------> > Date: 26 Apr 90 08:29:49 GMT> From: mcsun!ukc!stc!praxis!riemann!mikec@uunet.uu.net (Michael Chace)> Subject: Networking> To: packet-radio@ucsd.edu> > Hello All,> > I'd like the benefit of people's experiences concerning what to do when> your local 2m 1200bps single channel based network begins to overload.> > Our local packet network is at breaking point for about 50% of the time.> To put the network under a more 'formal' basis we had a meeting of> all local packeteers with the aim of creating a group to maintain and> enhance the network. Various suggestions were made on how to solve things,> some good, some bad. Here's a summary of the network as it stands:-> > NB - My local area is Bath/Bristol/Cardiff (S/W England & S Wales)> Total population ~1 million - Amateurs on packet ~300> > 90% of traffic sits on 144.650 all 1200bps - Local chats and node traffic.> Some links now exist on 70MHz - mainly for BBS forwarding.> There are 2 major nodes on 2m - They are on very high sites running 25W erp> consequently they hear a lot and lots can hear them.> > Perhaps a greater problem is that most routes out of our area are poor and> they also must talk to well-sited nodes. It not unusual to have stations> telephoning node sysops because they think the node is down - when its due> to the node hearing so much that its squelch is permanently open!> Most of the nodes in our area form backbone links in all directions and the> NTS Mailboxes rely on them heavily.> > The basic idea is to move the well-sited nodes into lower 'city' locations> keep them as the user access points and then tie up these nodes on separate> links (4m/70cms/23cms). Where to put the links is a moot point - 4m has a > source of cheap PMR equipment but no bandwidth - 70cms more expensive, more> channels but it's not a primary band - 23cms expensive but plenty of wide> open space.> > What I'd like are your thoughts/experiences/suggestions etc. Particularly> why you chose frequencies/data speed etc.> > As a final note - one of the things that I noticed at the meeting and while> talking to the local users were :-> > 1) People need to learn that the packet system needs to shunt data> fast. It's a serious network that moves data regardless of what> the data is and how it gets from one point to another.> > 2) People don't understand much about protocols and the NET/ROM> system eg. NOT realising that KA/NODES are not real nodes and> trying to explain why p-persist will squeeze a few more % out> of the network.> > > Thanks for your time & 73,> > Mike> ****> ................................................................. ............> | ARPA : mikec@praxis.co.uk | Michael Chace |> | JANET : mikec@uk.co.praxis | PraXis Systems |> | UUCP : ...!uunet!mcvax!ukc!praxis!mikec | Manvers Street |> | AMPRNET: g6dhu@g6dhu.ampr.org [44.131.20.3] | Bath, Avon |> | AX.25 : G6DHU @ G6DHU-2 or G6DHU @ GB7SDN | BA1 1PX UK |> | Phone : (44) [0]225 444700 | |> ................................................................. ............> > > > > ------------------------------> > Date: 27 Apr 90 16:38:43 GMT> From: microsoft!joehol@uunet.uu.net (Joseph HOLMAN)> Subject: SAREX STS-35 space shuttle> To: packet-radio@ucsd.edu> > i never got any direct replies, so i'll try again...> > > is any body out there going to have a way for use> people up in Seattle (latitude 47 deg.) to connect> to the SAREX mission ?> > i've heard rumors about people having KA-NODEs, but> i haven't heard from the horses mouth yet...> > anybody have any names or callsigns of people doing/planning > this ????> > joe holman, ka7ldn> uw-beaver!microsoft!joehol> joehol@microsoft.uucp> 206-882-8921 work> > ------------------------------> > Date: Fri, 27 Apr 90 13:25:12 MST> From: sarrel%miranda.uucp@moc.Jpl.Nasa.Gov (Marc Sarrel)> Subject: shareware in packet radio> To: packet-radio@ucsd.edu> > Is there an FCC policy or other generally accepted rules regarding> putting shareware on packet radio BBS's? Is transmitting shareware> considered a "business communication"? What about freeware? Just> curious...> > --marc> > -=-> Marc A. Sarrel> N7OLI> sarrel%miranda.uucp@moc.jpl.nasa.gov | "Oh, _lightweight_ Alpaca..."> ..!sun!sunburn!miranda!sarrel | -Blanche DuBois> > NSA fodder:> > Binary Chemical Weapon domestic disruption munitions FBI Clifford> Stoll Soviet detonator fissionable KGB colonel $400 million in gold> bullion genetic backsatter Pentagon nuclear> > ------------------------------> > Date: 27 Apr 90 15:01:26 GMT> From: motcid!froula@uunet.uu.net (Don Froula)> Subject: Teletext> To: packet-radio@ucsd.edu> > Does anyone have information about the fate of Teletext services in the US?> This is an information service that provides text and block color graphics> capability on a home TV receiver equipped with a special decoder. The data> is embedded in several unused TV lines in the vertical blanking interval.> The data repeats over and over in the form of a magazine. The decoder> simply grabs pages as they come by and stores them in a display buffer.> The system is very popular in the UK.> > Zenith used to offer an embedded decoder on some of their sets. Also, Dick> Smith electronics offered a kit a few years back.> > Observations on several local broadcast and cable channels show considerable> activity in the blanking interval. > > Information on current status of Teletext and sources for decoders would> be appreciated.> > Don WD9DMP> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: Tue May 01 15:44:15 BST 1990From: Mail Router <xopen!mail-router@relay.EU.net>Subject: Failed MailTo: packet-radio@ucsd.eduYour mail to `andy' failed at xopen.Reason: mail: can't send to andy.Returned message follows...> From nsfnet-relay.ac.uk!packet-radio-request Sun Apr 29 12:59:58 1990 remote from ukc> Received: from ukc by xopen with v7.16; Tue May 01 15:44:03 BST 1990> Received: from nsfnet-relay.ac.uk by kestrel.Ukc.AC.UK > via Janet (UKC CAMEL FTP) id aa17143; 29 Apr 90 12:53 BST> Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK > Via Ethernet with SMTP id aa03394; 29 Apr 90 11:59 GMT> Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel> id aa02926; 29 Apr 90 12:38 BST> Received: from ucsd.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP> id aa02870; 29 Apr 90 12:32 BST> Received: by ucsd.edu; id AA09531> sendmail 5.61/UCSD-2.0-sun> Sun, 29 Apr 90 04:00:08 -0700 for brian> Received: by ucsd.edu; id AA09518> sendmail 5.61/UCSD-2.0-sun> Sun, 29 Apr 90 04:00:05 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list> Message-Id: <9004291100.AA09518@ucsd.edu>> Date: Sun, 29 Apr 90 04:00:03 PDT> From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>> Reply-To: Packet-Radio@ucsd.edu> Subject: Packet-Radio Digest V1 #12> To: packet-radio@ucsd.edu> Sender: packet-radio-request@nsfnet-relay.ac.uk> > > Packet-Radio Digest Sun, 29 Apr 90 Volume 90 : Issue 12> > Today's Topics:> AR-2002 scanner remote info wanted> faster modems> Ham Packet BBS on ATT UNIX PC?> Need help in radio data communic.> > Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>> > Send requests of an administrative nature (addition to, deletion from the> distribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>> > Archives of past issues of the Packet-Radio Digest are available > (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".> Digest files are named Vv.n where v=volume and n=number in volume.> > Digests will be issued daily unless there is no traffic.> > SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. The> Internet-to-BITNET mail gateway systems would prefer that you instead> add yourself to a BITNET redistribution of this list; you may add> yourself to the list by sending the following command:> > SUBSCRIBE I-PACRAD your full name> > to LISTSERV@UIUCVMD. You can send that in an interactive if your system> supports them (e.g. the CMS TELL command), or in the body of a mail message> (*not* the subject line).> > Please note: Although you'll be receiving Packet-Radio mailing from the> network address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Edu> is the source. Any contributions from you should be sent to UCSD.> > The mailing list is in the form of a digest. It is not edited, just> a convenient envelope for multiple messages to reduce netmail load.> If your mail reader does not have an "undigestify" option, contact> Keith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll send> you C-language source for one.> > 73,> - Brian (brian@ucsd.edu)> ----------------------------------------------------------------- -----> > Date: 28 Apr 90 10:38:55 GMT> From: eru!luth!sunic!mcsun!hp4nl!dutrun!dutentb!ese@BLOOM-BEACON.MIT.ED U (Kees Schot)> Subject: AR-2002 scanner remote info wanted> To: packet-radio@ucsd.edu> > !! HELP !!> > For about one year I'm looking for information on the> computer interface of the AR-2002 communications receiver.> > If someone has hard- or software information about> this interface (or also about other interesting aspects of> this equipment) please send it to me by email to> > schot@dutentb.tudelft.nl> > or on paper to:> > C.A. Schot,> Grote Kreek 45,> 3079 CC Rotterdam,> The Netherlands.> > Even the name and address of the (I thought Japanese)> manufacturer of this scanner can help me.> > Please, help me, because this is the last hope for me> to get this information.> > ------------------------------> > Date: 28 Apr 90 15:56:42 GMT> From: payne@tcgould.tn.cornell.edu (Andrew Payne)> Subject: faster modems> To: packet-radio@ucsd.edu> > In article <9004232134.AA04767@miranda.uucp> sarrel@miranda.UUCP (Marc Sarrel) writes:> >expert" at a local amateur radio store recently. I asked him about> >some TNC that had a 2400 baud modem vs one that had a 1200 baud modem.> >I asked wether 2400 would catch on, given my experience with land line> >modems where everyone was starved for speed. He said "no." His> >reasons seemed pretty fuzzy to me, but he seemed to claim that 1) 2400> >baud wouldn't catch on because everyone already has 1200 baud modems,> >2) 1200 baud seemed fast enough to him, and 3) that 2400 baud wasn't> >_really_ twice as fast as 1200 because the extra speed was used> >inefficiently. (But don't hold me to that, this was a while ago.)> >> I also feel that 2400 baud will not catch on, but my reasoning is > much different. 2400 baud is just not that much of a jump beyond 1200 to > make it worth the trouble. Go for 9600 baud or 56kb (though 4800 baud seems> to be a happy medium for many because it supposedly works with more radios than> the higher speeds).> > >Anyway, my question is this: How can we "hams in the know" encourage> >the use of faster and more effecient modems on the airwaves, given> >that we agree that "faster is better." One of this guy's arguments> >holds weight in that there is a lot of "hardware inertia" out there.> > The first step in taking advantage of higher speed modems is to use> them on the backbones. The backbones are where the heavy traffic is anyway,> and there is little "hardware inertia" involved. You could run some strange> I'm-not-compatible-with-anything protocol and modem on the backbones and it > wouldn't really matter.> > Many of the UHF backbone links of the network in Ohio are at 4800> baud. The NEDA guys have many 4800 baud trunks and are quickly moving for > 9600 baud. Also, on the NEDA network, many of the high-volume users (DX > clusters, BBSs, TCP/IP) are using higher speed uplinks to the backbone.> > There is never going to be an overnight switch away from 1200 baud.> Like MS-DOS, it will dog us for a long, long time. Put the high-speed modems> in the places will they will give maximum benefit and gradually people will> migrate beyond 1200 baud.> > > -- > = = = = = = = = = = = = = = = = = = = = = = = = = = => Andrew C. Payne, N8KEI UUCP: ...!cornell!batcomputer!payne> INTERNET: payne@tcgould.tn.cornell.edu> > ------------------------------> > Date: 28 Apr 90 21:56:00 GMT> From: usc!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs. uiuc.edu!kenny@ucsd.edu> Subject: Ham Packet BBS on ATT UNIX PC?> To: packet-radio@ucsd.edu> > >There is program written by the people at KA9Q called simply KA9Q.> > Gee, Phil, I never knew you were twins.... 8-)> > Kevin, KE9TV> kenny@cs.uiuc.edu> > ------------------------------> > Date: 28 Apr 90 00:08:00 GMT> From: swrinde!zaphod.mps.ohio-state.edu!uwm.edu!bionet!arisia!cdp!saff@ ucsd.edu> Subject: Need help in radio data communic.> To: packet-radio@ucsd.edu> > Friends,> > I work in a brazilian organization who also give> support for non-profits organizations. We work with a similar> organization, here in San Francisco Bay Area. We are about to get> authorization to use the PeaceSat, an old militar satellite now used> for pacific purposes, and we plan to use initially to get a cheap> and good link from our machines. I have no experience in this area,> so I am asking for help with some (maybe dumb) questions:> > - Possible baud rates> > - Hardware required> > - Places where look for hardware> > Thanks very much for any help,> > Saliel Figueira Filho> Chief Programmer> IBASE> > {pyramid, hplabs, ...}!cdp!saff> > ------------------------------> > End of Packet-Radio Digest> ******************************------------------------------Date: 2 May 90 05:43:47 GMTFrom: swrinde!emory!rsiatl!jgd@ucsd.edu (John G. De Armond)Subject: faster modemsTo: packet-radio@ucsd.edukarn@thumper..bellcore.com (Phil R. Karn) writes:>In article <1959@rsiatl.UUCP> jgd@rsiatl.UUCP (John G. De Armond) writes:>>In terms of rules, before the great ARRL/FCC rules rewrite, this type>>modem [wa4dsy]>>could be used at 220 mhz and above. Now that we've been "represented">>again by the ARRL, 220 is out. But anything 440 or above is fine.>This is news to me. I'm still running 56kbps on 220.55, and as far as I>know it's still entirely legal.I'm sorry that I can't quote chapter and verse, Phil, but I don't havemy personal copy of the new Part 97 yet. My comment stems from a GRAPESsession a few months ago when we were reviewing the rewrite. As I recall,the new language puts both a baudrate and a bps limit on everthing below440. I'm going to be in a ham store tomorrow, so I'll pick up myown copy of Part 97 and find the clause. Meanwhile, you might wantto reread the digital sections carefully. It was the consensus of every-body that read those paragraphs that day that 56k was out on 220.John-- John De Armond, WD4OQC | We can no more blame our loss of freedom on congressRadiation Systems, Inc. | than we can prostitution on pimps. Both simplyAtlanta, Ga | provide broker services for their customers.{emory,uunet}!rsiatl!jgd| - Dr. W Williams | **I am the NRA** ------------------------------Date: Tue, 1 May 90 9:00:38 PDTFrom: Peter Dahl <pdahl@milton.u.washington.edu>Subject: Full Duplex packet on 2 meters?To: packet-radio@ucsd.edu Is anyone operating dual frequency, full duplex packet nodes on2 meters on frequencies other than coordinatable/bandplan repeater pairs?How about 145.01/145.61? How do you interpret the fcc rules on this one?145.61 is in an area where repeaters are supposedly not permitted but is a fullduplex packet node a repeater as we have come to know repeaters? TheARRL Repeater Directory says that the frequencies between 145.5 and I believe145.8 are bandplanned for experimental modes. Everything in this developingmode of packet radio is experimental isn't it? Please let me know what you think.... We need some full duplexpacket systems and standard repeater pairs have all been used for voice repeaters whether they are really needed or not. Peter, WA7FUS------------------------------Date: 1 May 90 22:41:00 GMTFrom: zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1 .cso.uiuc.edu!phil@tut.cis.ohio-state.eduSubject: Full Duplex packet on 2 meters?To: packet-radio@ucsd.eduYou might try doing some unusual splits in the repeaters. The FCC rulesdo NOT allow repeaters in the 145.5-146 Mhz range (nor 144.0-144.5) soyou need to limit yourself to 144.5-145.5 and 146-148.It is a sad shame that spectrum planners and repeater coordinators are notmaking any attempt to plan for greater density of spectrum usage. Theysimply assume that when there is no repeater pair that comes up without aconflict on the computer, that that band is full at that location.Spectrum planners need to get on the ball and do some planning. If thatcalls for some repeater pairs to be dedicated to packet, so be it. It maynot be necessary to do that.However I must assert one thing for certain: just because someone has had arepeater on a given frequency already is no reason for having a "right" tostay there. If packet radio needs to share the spectrum of repeater pairsthen the spectrum should be allocated as needed.This probably means some repeaters will have to move. Hey folks, that ispart of progress. Of course some hams are totally against progress, andthe only solution I can suggest for them is to take them off the air.By the way, you CAN get several TIMES the number of repeaters on the airin the major cities as you have now. It also appears that the number ofrepeaters in several are NOT EVEN NEEDED. The situation as it exists nowis mostly turf claims. This has to end and spectrum planners and repeatercoordinators need to get off their hind ends and do something.Problems will always exist when those who coordinate are also there toprotect the turf of existing repeater owners.I a big city you can hit 20 to 40 repeaters easily. Tell me how many ofthem are actually IN USE most of the time? What is the average amount ofairtime per repeater per day? I think you will find things are NOT asdense as we might like to think.--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society<phil@ux1.cso.uiuc.edu> | no matter what the particular issue is all about.------------------------------Date: 2 May 90 01:50:19 GMTFrom: uokmax!nsslsun.gcn.uoknor.edu!skaggs@apple.com (Gary Skaggs)Subject: Full Duplex packet on 2 meters?To: packet-radio@ucsd.eduI agree 100% with Phil on the problem of repeaters and the need for endingthe *turf* battles that are occurring over frequency *rights*. But, I thinkthe REAL solution if you want *full duplex* is individual, not-necessarily-600 Khz-offset frequencies. put one in the 145 simplex area, the other in146. Yes, I know *FM simplex* is what it says. If the natives are restlessabout such *sins*, cross-band. This saves on duplexor costs. You can buya good quality radio for less than what it will cost you for a good set ofband pass/band reject duplexors. Then run real full duplex.On second thought, go up in frequency and run FAST, full duplex.__________________________________________________________ ____________________Gary Skaggs Internet: skaggs@nssl.gcn.uoknor.eduNational Severe Storms Laboratory (The Tornado People) "The Channel 9 Alpha system, technology at it's ____________?"------------------------------Date: 1 May 90 18:15:29 GMTFrom: ndcvb!cartan!ndmath!nstar!w8grt!jim.grubs@iuvax.cs.indiana.edu (Jim Grubs)Subject: Higher speedsTo: packet-radio@ucsd.edu(330) Sat 28 Apr 90 3:42pBy: Brian BattlesTo: Bob McgwierRe: Fast packetSt:-------------------------------------------------------- ----------------------@EID:1811 149c7d40Bob, In your reply to Marc Sorrel, you wrote: BM> ...Hams are basically cheap... Make that "poor," not necessarily cheap. Most hams I know areperpetually in danger of bankrupting their family financies to buynew gizmos. BM> ...and these days they are basically technically lazy... Although many are just busy or lacking education. Some of us havelittle time to get on the air, let alone design and build some fancynew digital high-tech device. Some hams have had little computer ordigital education and have to struggle to keep up. Besides, many hamsprefer to provide traffic handling/emergency communications/etc thanto build a lot of gear. BM> ...My efforts in this area along with partners KB2CST and KA2MOV BM> for commercial concerns and with WA7GXD, KV7B, W3IWI for TAPR and BM> AMSAT have essentially been done for free... And are greatly admired and appreciated by all amateurs with anyslight understanding of technology and creativity! BM> ...[with rigs] needed to work satellites, ROBOT 1200C's costing a BM> fortune when you can get them for SSTV, WEFAX APT equipment costing BM> a few hundred, etc, it has just gotten too expensive for a ham to BM> `do it all' with individual pieces of equipment... <sigh> All too true.73 de Brian Battles, WA1YUA * HAM RADIO & PACKET Echo ModeratorQTH New Britain, Conn.Packet: WA1YUA @ N1API... Someday my ham radio may save your life!--- Via Silver Xpress V2.24 (1:141/880) Brian Battles, WA1YUA - via FidoNet node 1:141/880UUCP: ...!ncar!asuvax!stjhmc!w8grt!880!141!1!brian.battlesINTERNET: brian.battles@f880.n141.z1.fidonet.org--------------------------- ---Date: Tue, 1 May 90 8:44:39 PDTFrom: Peter Dahl <pdahl@milton.u.washington.edu>Subject: New Packet Stuff @ Dayton??To: packet-radio@ucsd.eduI have not yet seen a list of the new packet related equipment that was introduced at Dayton last weekend. Can anyone who wasthere or has heard a report on this supply us with this info?CURIOUS MINDS WANT TO KNOW! 73 de Peter, WA7FUS------------------------------Date: Wed, 2 May 90 09:39 NFrom: Urs Baer <BWLLIBMOD%CSGHSG5A.BITNET@CUNYVM.CUNY.EDU>Subject: Packet-Radio Digest V1 #14To: Packet-Radio@UCSD.Eduplease remove my old adress 87674800s@csghsg5a.bitnet from this list!!!------------------------------End of Packet-Radio Digest******************************----------------------------- -End of Packet-Radio Digest******************************----------------------------- -End of Packet-Radio Digest******************************----------------------------- -Date: (null)From: (null)As far as whether or not you can hit SAREX, I'm not sure.Making a beam may be a good idea. DOVE was very easy to pick upon 2m with an HT and a magmount..hitting SAREX might be more difficult.-Tom------------------------------End of Packet-Radio Digest******************************Date: Sun, 6 May 90 04:00:02 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #19To: packet-radioPacket-Radio Digest Sun, 6 May 90 Volume 90 : Issue 19Today's Topics: Administrivia Am7910 modem chips Hams in space Hams in space? Need information on VADCG Board NOS domain.txt format PC-Pakratt patch TNC2 1.1.7 Code (vs. MFJ-1274)Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: Sat, 5 May 90 14:52:26 -0700From: brian (Brian Kantor)Subject: AdministriviaTo: packet-radio-digestOne or more broken mailers out there are returning undeliverable mail to theheader From: line rather than to the transport error return address in themail envelope. I've changed the from line to keep them from polluting thedigest; be careful if you use your mailer's REPLY command to make sure thatyour mail goes where you intend it to go. Sorry for the hassle. - Brian------------------------------Date: 4 May 90 22:27:18 GMTFrom: usc!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!turnk ey!orchard.la.locus.com!prodnet.la.locus.com!lando.la.locus.com!d ana@ucsd.edu (Dana H. Myers)Subject: Am7910 modem chipsTo: packet-radio@ucsd.edu I want a couple. Maybe I should post this to 'rec.ham-radio.swap' exceptthis is an item only packeteers would care about. I've tried a localdistributor but he's outta stock. Call me if you have one you want tosell reasonably. Thanks --dana*********************************************************** ******* Dana H. Myers KK6JQ | Views expressed here are ** (213) 337-5136 (ex WA6ZGB) | mine and do not necessarily ** dana@locus.com | reflect those of my employer ******************************************************** **********------------------------------Date: 3 May 90 16:06:03 GMTFrom: usc!zaphod.mps.ohio-state.edu!rpi!uupsi!uhasun!jbloom@ucsd.edu (Jon Bloom)Subject: Hams in spaceTo: packet-radio@ucsd.eduSAREX update from ARRL----------------------Launch is tentatively scheduled for 0445Z on May 15(12:45 AM, May 16 EDT), but it is subject to change, naturally.Unless you have a scheduled QSO (if you don't, it's too late now), youcan pretty much forget voice contact with the Shuttle on this mission.You can try for a packet contact, however. Use your normal TNC and2-meter FM radio.Here is the expected operating schedule for unattended packet (subjectto change as mission requirements dictate). MET GMT EDT Start End Start End Start End ----------------------------------------------------------------- --- 0/22:00 - 1/10:20 05/16 02:45 - 05/16 15:05 05/15 22:50 - 05/16 11:051/21:15 - 2/08:35 05/17 02:00 - 05/17 13:20 05/16 22:05 - 05/17 09:202/20:00 - 3/07:55 05/18 00:45 - 05/18 12:40 05/17 20:50 - 05/18 08:403/19:00 - 4/06:40 05/18 23:45 - 05/19 11:25 05/18 19:50 - 05/19 07:254/18:30 - 5/05:45 05/19 23:15 - 05/20 10 30 05/19 19:20 - 05/20 06:305/17:20 - 6/05:50 05/20 22:05 - 05/21 10:35 05/20 18:10 - 05/21 06:356/17:40 - 7/05:35 05/21 22:25 - 05/22 10:20 05/21 18:40 - 05/22 06:207/17:45 - 8/04:45 05/22 22:30 - 05/23 09:30 05/22 18:35 - 05/23 05:30In this table, the MET is the "mission elapsed time," or elapsed timesince launch. For example, 1/21:15 means one day, 22 hours and 15minutes after launch. The GMT and EDT tables are based on a launchtime of May 15 at 0445Z. If the launch time is different, adjust thetime/date accordingly.The following is extracted from an AMSAT handout...Frequencies Listed below are the frequencies presently intended to be used bySAREX for both packet and voice. Note, that in no case is"simplex" operation indicated. DO NOT CALL WA4SIR ON THE SAMEFREQUENCY WHICH YOU HEAR HIM. This procedure may be a littlestrange for packet folks, but everything works the same way as itdoes when 2 or more stations are operating on a single channel. Shuttle Accompanying Offset Transmit Freq. Shuttle Receive Freqs. Designation Group 1 145.55 MHz 144.95 MHz Primary " 144.91 Secondary No. 1 " 144.97 Secondary No. 2 Group 2 145.51 144.91 Primary " 144.93 Secondary No. 1 " 144.99 Secondary No. 2 Group 3 145.59 144.99 Primary " 144.95 Secondary No. 1 Group 4 145.55 144.95 Primary " 144.70 Secondary No. 1 " 144.75 Secondary No. 2 " 144.80 Secondary No. 3 " 144.85 Secondary No. 4 The primary pair for use for both voice and packet is145.55/144.95. To facilitate communication with ground stationswhose split frequency capability is limited to repeater operation,600 kHz spacing is used on this and all Primary Offsets. However,if WA4SIR experiences too much QRM on a Primary Offset, he mayswitch to one of the Secondaries in the group corresponding to histransmit frequency. Group 4 is intended for use over Europe andAfrica. Information Dissemination Dissemination of Shuttle information to those participating, aswell as all interested amateurs will be via a system of keystations, particularly WA3NAN, at Goddard in Greenbelt, MD,W5RRR, at JSC in Houston, and W6VIO at JPL, in Pasadena, CA. These stations, and others, will operate on HF and VHF 24 hours aday, carrying official NASA supplied voice communication betweenMission Control in Houston and the Shuttle crew. This isbasically the same service that they has performed on all non-DoDShuttle fights for the past several years. To further provideinformation specific SAREX communication opportunities andrelated information, bulletins originated by amateur volunteersstationed at the Johnson Space Center will be fed via a computernetwork to these stations and others including W1AW. TheMetabeacon may also be used for announcements. It is plannedthat the frequencies listed below will be used for this service. The selection of which HF frequencies are activated at aparticular time will depend on propagation conditions. Station Approx. Nominal Frequencies in MHz QTH (+/- QRM) WA3NAN Wash. DC 3.860, 7.185, 14.295, 21.395, 28.650. 147.45 (FM) W5RRR Houston 3.850, 7.227, 14.280, 21.350, 28.495, 146.64 (FM)W6VIO L.A. 3.840, 21.280, 224.04 (FM)W6FXN L.A. 145.46 (FM) All are SSB using the sideband normally used on the band, except whereotherwise indicated. 73 de KE3Z------------------------------Date: 5 May 90 16:27:52 GMTFrom: payne@tcgould.tn.cornell.edu (Andrew Payne)Subject: Hams in space?To: packet-radio@ucsd.eduIn article <9004271452.AA27108@ucsd.edu> KEVIN@CALSTATE.BITNET writes:>I recall reading some months ago that this summer, an astronaut on the Space>Shuttle will be doing 2 meter packet communications with earthlings.>>When will this occur? On what frequency? Will it be possible for me>to communicate with them using my BIG 5 watts of power? do i need a special>antenna or will my rinkydink ones made out of coathangers do the trick?>I expect QRM will be real bad, but the equiptment I got is what I'm stuck>with ... I yam what I yam. Well, I don't know how suitable your equipment is for earth-shuttlecommuncations, but all of the details are written up in this month's (May)issue of _73 Amateur Radio_. It says the primary frequencies will be 145.55 down and 144.95 up.The article also says (important): "DO NOT CALL THE SHUTTLE ON THE SAMEFREQUENCY ON WHICH YOU HEAR IT." STS-35 is scheduled for liftoff on May 9 at 0477 UTC, and should be up for 7 or 8 days. I'd suggest:(1) Buy the May _73_.(2) Try to grab the AMSAT announcements from packet or 'rec.ham-radio'.(3) Get an orbit calculation program (if you don't already have one).(4) Watch packet or 'rec.ham-radio' or 'sci.space' for the STS-35 orbital elements.(5) Go for it!-- = = = = = = = = = = = = = = = = = = = = = = = = = = =Andrew C. Payne, N8KEI UUCP: ...!cornell!batcomputer!payne INTERNET: payne@tcgould.tn.cornell.edu------------------------------Date: 6 May 90 00:06:36 GMTFrom: van-bc!ubc-cs!nebulus!dennis@ucbvax.Berkeley.EDU (Dennis S. Breckenridge)Subject: Need information on VADCG BoardTo: packet-radio@ucsd.eduHi, I just found an old VADCG TNC board (unbuilt) and I was wondering if it would be worth the hassel of stuffing it and trying to use it.Can I use a 201 style modem? with it. Is there any software updates for KISS or normal (modern TNC) modes? Any information would be would help the cause!-- ----------------------------------------------------------------- ------------Dennis S. Breckenridge (604) 277-7413 dennis@nebulus.uucp VE7TCP Still brain dead after all these years :-) ----------------------------------------------------------------- ------------------------------------------Date: 5 May 90 18:32:54 GMTFrom: uc!shamash!vtcqa@tut.cis.ohio-state.edu ( VTC)Subject: NOS domain.txt formatTo: packet-radio@ucsd.eduIn article <7575@uhccux.uhcc.hawaii.edu> querubin@uhccux.UUCP (Antonio Querubin) writes:>After finding out that NOS wanted to see either a domain.txt file or hosts.nos >>Can anyone tell me what this format is supposed to look like?>>AH6BWHere is what my domain.txt looks like:nr0d.ampr.org. IN A 44.94.3.12bbs IN CNAME nr0d.ampr.org. nr0d IN CNAME nr0d.ampr.org.#at386.nr0d.ampr.org. IN A 44.94.3. 23at IN CNAME at386.nr0d.ampr.org.#n0buu.ampr.org. IN A 44.94. 2.6n0buu IN CNAME n0buu.ampr.org.buu IN CNAME n0buu.ampr.org. #unix.g1xrl.ampr.org. IN A 44.94.3.15unix IN CNAME unix.g1xrl.a mpr.org.grettir IN CNAME unix.g1xrl.ampr.org.## This is a comment line. You can take these out if you want.#The IN A records define the IP address for the given station. The CNAMErecords are like an alias. For instance, to ftp to N0BUU, I can entereither of the following:ftp n0buu.ampr.orgftp n0buuftp buuNote that the only reason 'ftp n0buu' will work is because of the CNAMErecord that ties n0buu to n0buu.ampr.org .The lines that start with a # sign are comment lines.Also be sure to use periods after the domain name, like they are above.Have fun,Jeff------------------------------Date: 4 May 90 20:35:31 GMTFrom: swlabs!jack@uunet.uu.net (Jack Bonn)Subject: PC-Pakratt patchTo: packet-radio@ucsd.eduI have a PK-232 and had been running the PC-Pakratt software for over a year on a genuine AT without incident. I have recently put a 386SX in the shack and find that there is a timingdependency in the PC-Pakratt software that prevents it from operating.The software indicates that it is "Unable to establish communicationswith Pakratt" and terminates.When I called the tech support at AEA, they told me that indeed therewas a timing dependency in the PC-Pakratt software and that the original authors of the code were nowhere to be found. I asked about a fix and they indicated that they had a new program that was going to be released during the summer. At that point, owners of PC-Pakratt wouldbe offered a "deal", I was told.So it looks like the near term solution is to patch the timing loop toeliminate the problem. To save the time, has anyone on the net hacked/patched PC-Pakratt to eliminate this problem? -Jack-- Jack Bonn, KC1UH, <> Software Labs, Ltd, Box 451, Easton CT 06612uunet!swlabs!jack (UUCP) jack%swlabs.uucp@uunet.uu.net (INTERNET)jack@kc1uh (TCP/IP) kc1uh@wb1cqo (AX.25)------------------------------Date: 5 May 90 19:54:08 GMTFrom: ius3.ius.cs.cmu.edu!ralphw@pt.cs.cmu.edu (Ralph Hyre)Subject: TNC2 1.1.7 Code (vs. MFJ-1274)To: packet-radio@ucsd.eduDon't know about downloading, but I ordered one from TAPR at Dayton.It arrived today, but my TNC2 clone (an MFJ-1274) doesn't seem to like it.When I power up, the STA and CON Leds stay lit, and nothing comes over the serial port. Things work as expected when I revert to my MFJ firmware. (TAPR 1.1.3-based, but with a 1986 Systek copyright). There was a note about bbRAM being loaded with defaults after trying the new firmware. [does this mean that the newfirmware touched something in bbRAM, but left the LEDs on?]Any hints appreciated. Mechanical contact between the EPROM and socket seemsOK, but I don't have away to verify the EPROM contents.THanks.------------------------------End of Packet-Radio Digest******************************Date: Mon, 7 May 90 04:00:02 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #20To: packet-radioPacket-Radio Digest Mon, 7 May 90 Volume 90 : Issue 20Today's Topics: Full Duplex packet on 2 meters? NOS hosts.net file?Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 4 May 90 18:09:55 GMTFrom: usc!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa .gov!peregrine!ccicpg!cci632!cb@ucsd.edu (Just another hired gun (n2hkd))Subject: Full Duplex packet on 2 meters?To: packet-radio@ucsd.eduThere are many repeater pairs allocated in this area, but I knowof a few that have to repeater(s) on them. The person "owning"the pair has just never gotten around to put one up (going ona decade or more). Maybe it's inventory time, just like we doat work to see which nodes are used and which are not, thenwe won't have to pay tfor the unused ones :-(. Packet clusters seem to create a lot of traffic, they wouldbenefit the most from the offset repeater idea :-).-- email: cb@cci632 or !rochester!kodak!n2hkd!curtis Curtis Braun, N2HKD, Computronics, PO Box 1002 Fairport NY, 14450 ------------------------------Date: 4 May 90 18:35:18 GMTFrom: usc!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!pereg rine!ccicpg!cci632!cb@ucsd.edu (Just another hired gun (n2hkd))Subject: NOS hosts.net file?To: packet-radio@ucsd.eduIn response to the routing question...Set the router to handle your trafiic!.route add [44]/8 dr0 a # sends all packet traffic to drsi (tnc)route add [129.126]/16 lan # sends all 129.126.*.* to ethernetroute add [129.126,81.51] sl0 # sends this one to slipIf you set the default to ethernet then any thing ont listedgoes there. If you add the route command for a group orindividual addresses the that's where they will go.Don't forget tot attach harware for each interface:attach **** drsi dr0aattach **** com1 sl0attach **** 3com lanetc.Hope this helps, I have an XT which routes packet traffic aswell as slips to my other computers, which in turn routesuff to the lan.-- email: cb@cci632 or !rochester!kodak!n2hkd!curtis Curtis Braun, N2HKD, Computronics, PO Box 1002 Fairport NY, 14450 -- email: cb@cci632 or !rochester!kodak!n2hkd!curtis Curtis Braun, N2HKD, Computronics, PO Box 1002 Fairport NY, 14450 ------------------------------End of Packet-Radio Digest******************************Date: Tue, 8 May 90 04:00:02 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #21To: packet-radioPacket-Radio Digest Tue, 8 May 90 Volume 90 : Issue 21Today's Topics: faster modems FT-207R with Packet??? HELP, want to run packet on 386 AT with 386/ix SYSV 3.2 UNIX How packet BBS's exchange mail More NOS questions (3 msgs) Net/rom performance questions New Packet Stuff @ Dayton?? NOS hosts.net file? PS-186 ??? TM-231A rx audio for packet? US Navy WET NETs Wanted: FT736<->G3RUH 9600 baud interfacing infoSend Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 7 May 90 20:01:19 GMTFrom: hpcc01!col!bdale@hplabs.hp.com (Bdale Garbee)Subject: faster modemsTo: packet-radio@ucsd.edu>I suspect that many people advocate putting high speed modems into the backbone>links mainly because it's easier (i.e., it requires fewer modems) than>giving them to the end users. Actually, Kevin Rowett N6RCE postulated a different reason that I thought madea lot of sense, and which has caused me to moderate my opinion on this subject.He suggested that bandwidth tends to follow lines of "social locality". In thenormal engineering environment, your social neighbors, or co-workers, aretypically near you physically, leading to lots of local bandwidth. Yourinteractions with folks who are physically far away are much less, such thatthe need for bandwidth falls off with physical distance.He pointed out that as Hams, may of us belong to "social groups" that are notphysically adjacent. The fact that the 10Ghz work N6GN started is beingcarried on by folks in CO and Ottawa is an example of a social, or work, groupthat wants desperately to share a "fast lan", but which is widely separatedphysically.The concept of bandwidth "local to the users who communicate with each other"is still valid, it just doesn't map with geography.Bdale------------------------------Date: 8 May 90 04:08:27 GMTFrom: portal!cup.portal.com!Justin_Randall_Padawer@apple.comSubject: FT-207R with Packet???To: packet-radio@ucsd.eduI goofed and posted a message titled "Packet and FT-207r" on therec.ham-radio board instead of rec.ham-radio.packet. Could anyoneread it anyway and possibly help? I'm trying to get started withpacket.------------------------------Date: 7 May 90 18:22:17 GMTFrom: pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!uupsi!su nic!dkuug!rcbal!fk@tut.cis.ohio-state.edu (Fleming Kraglund)Subject: HELP, want to run packet on 386 AT with 386/ix SYSV 3.2 UNIXTo: packet-radio@ucsd.eduSince I now have gotten a 386 unix box i'll like to use it for packet but which card should i use (what would you recomend)and is there a UNIX driver for itand is there any UNIX commandsand does anybody know if the AX25 protocol is availeble electronicaly some where or do i have to order a paper copy.I could proberly write the driver and commands my self (beeing a sw guy)but that will take time and i would proberly reinvent the wheel.73 de OZ1LBP-- Flemming Kraglund fk@rci.dk This is my OWN opinion---------------------------------------------------------- ----------------------1/2 * PS = PS/2 (half a computer) | 1/2 * OS = OS/2 (half an operating system)------------------------------Date: 7 May 90 18:04:00 GMTFrom: swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc .edu!ux1.cso.uiuc.edu!phil@ucsd.eduSubject: How packet BBS's exchange mailTo: packet-radio@ucsd.eduI would like to know a little more about how the present BBS's using AX.25do mail and posting forwarding. I am interested in basically enough of theprotocol to actually design a BBS program that does it just the same, thoughI doubt if I ever will (SMTP/TCP/IP is the way I would anyway). Pointersto magazine articles, books, etc, would be useful. I mostly just want tounderstand the concepts so I can comprehend things like failure modes, butthis does require bottom level protocol knowledge equal to BBS writing.--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society<phil@ux1.cso.uiuc.edu> | no matter what the particular issue is all about.------------------------------Date: 7 May 90 10:50:54 GMTFrom: uhccux!querubin@ames.arc.nasa.gov (Antonio Querubin)Subject: More NOS questionsTo: packet-radio@ucsd.eduWell, now that I've finally been clued into the major differences between the old and new version of KA9Q, I have some more questions (thought you got rid ofme huh? :-) ).Can NOS be setup to auto-answer a regular modem (on a standard serial port, nota SLIP line) and connect the caller directly to the mailbox and if so how do I'attach' the port?Could someone (somegroup) summarize the pro and cons of setting up a TCP/IP network versus a ROSE network? I understand that setting up a ROSE node entails some changes to a TNC (much like adding a KISS EPROM to an older TNC Isuppose). What exactly are these mods? Does a ROSE node require a dedicatedcomputer the way NOS does? Which network has the largest set of users and why?(If you think I'm an ignorant neophyte at this game, you're absolutely right.)AH6BWInternet: antonio_querubin-manao@uhplato.uhcc.hawaii.eduBITnet: antonio_querubin-manoa@uhplato------------------------------Date: 7 May 90 15:48:55 GMTFrom: uc!shamash!vtcqa@tut.cis.ohio-state.edu ( VTC)Subject: More NOS questionsTo: packet-radio@ucsd.eduIn article <7591@uhccux.uhcc.hawaii.edu> querubin@uhccux.UUCP (Antonio Querubin) writes:>>Can NOS be setup to auto-answer a regular modem (on a standard serial port, not>a SLIP line) and connect the caller directly to the mailbox and if so how do I>'attach' the port?>>>AH6BWI hacked NOS to accept commands for the modem on a slip link. Making themailbox forget IP might be difficult ( maybe a nightmare ), but it couldprobably be done. BUT, the reason I am posting this is - dont forget aboutTCP/IP, and have other people call your station when they are running NOSas a term program. I experimented with this, and the nice thing is thatyou can have multiple sessions. At 2400 baud, I had someone transfer twofiles to me, I was transferring two files to them, and we had a chat sessiongoing all at the same time ! Someone could start an ftp session with youto grab a file, and while it was transferring they could telnet to yourmailbox to read mail, etc. It beats the hell out of xmodem or some otherprotocol.Jeff------------------------------Date: 7 May 90 17:21:26 GMTFrom: winter@apple.com (Patty Winter)Subject: More NOS questionsTo: packet-radio@ucsd.eduIn article <7591@uhccux.uhcc.hawaii.edu> querubin@uhccux.UUCP (Antonio Querubin) writes:>Could someone (somegroup) summarize the pro and cons of setting up a TCP/IP >network versus a ROSE network? I understand that setting up a ROSE node >entails some changes to a TNC (much like adding a KISS EPROM to an older TNC I>suppose). What exactly are these mods? ROSE *is* on a PROM.>Does a ROSE node require a dedicated >computer the way NOS does? One person's "require" is another person's "take advantage of". :-)I was flabbergasted when ROSE first came out to discover that it*doesn't* let you use the full power of your personal computer; it'sjust another ROM replacement. I guess that's good news for people whodon't want to run their PCs on packet, but bad news for those of uswho are enjoying the new-generation software (like the KA9Q package)that lets our desktop computers do what they're built to do insteadof sitting around like dumb terminals (or even smart terminals).BTW, net experts, does ROSE also support AX.25 and NET/ROM the way the KA9Q package does? Maybe it does; I just don't recall.Patty-- ***************************************************************** ************ Patty Winter N6BIS INTERNET: winter@apple.comAMPR.ORG: [44.4.0.44] UUCP: {decwrl,nsc,sun}!apple!winter************************************ ***************************************** ------------------------------Date: Mon, 7 May 90 13:59:51 PDTFrom: brian@cyberpunk.ucsd.edu (Brian Kantor)Subject: Net/rom performance questionsTo: packet-radio@ucsd.edu, tcp-group@ucsd.eduI was discussing some upgrades to the local repeater group's net/romnode configurartion with them and ran into some interesting rumours.It seems that there are reports of performance problems with net/rom inthe configurations they're planning on using here. I couldn't confirmor deny these rumours. Anyone who know more? (These are for realRaikes net/roms plugged into TNC2s with the fast processor clockselected.)Rumour 1. Net/rom can't achieve a long-term throughput sufficient tojustify using 9600 bps radios; supposedly the software spends so muchtime with interrupts disable or doing malloc/frees or something that itjust can't get more than an effective 4800 bps through it.Rumour 2. Net/rom doesn't have very good throughput in a three-stationnode because there is some problem with the RTS/CTS arbitration of theserial lines coupling the TNCs together; apparently collisions or longholdoffs or something occurs on the serial interconnections that limitseffective throughput.I don't have the facilities to experiment with this to confirm ordispute these rumoured problems. Anyone know for sure? A solid answerwould really help me advise the local group. - Brian------------------------------Date: 7 May 90 20:16:08 GMTFrom: hpcc01!col!bdale@hplabs.hp.com (Bdale Garbee)Subject: New Packet Stuff @ Dayton??To: packet-radio@ucsd.edu>I have not yet seen a list of the new packet related equipment >that was introduced at Dayton last weekend. Can anyone who was>there or has heard a report on this supply us with this info?The only outfit actually selling anything new this year at Daytonwas Grace Communications, consisting of N4PCR and friends and their 68302-based packet switches. AEA was showing the N4HY-designed DSP-based "pk232-replacement",a standalone TNC with modems implemented using a Mot 56001 DSPchip... neat stuff. Dunno when it'll ship. They were onceagain distributing a PS-186 flyer, but no board in evidence,they seem to be waiting for me to "finish *the* software" (emphasis mine), dunno if/when it'll ship.TAPR had a set of loaded boards for the packetRADIO to show, andschematics of the approaching-alpha-test TAPR DSP PC plug-incard. Dunno when it'll ship.Kantronics was showing a neat new box that implements a weathermonitor that can be hooked to a TNC or computer, and connectedto remotely. Didn't have much time to play with it. They werealso showing their Data Engine product, which is a dual-portV40-based TNC. It just passed FCC testing, dunno when it'll ship.I didn't see much new at the DRSI booth, we're still hearing about the 56001-based DSP card they're working on with DSSI, but dunno when it'll ship. (starting to sound like a brokenrecord, right?)I didn't ever get very close to the Paccomm booth because of thecrowd surrounding them and AEA (across the aisle from each other!), but I heard they have a TNC with modified firmware toimplement a 1200 baud full duplex regenerating repeater insoftware... sounds neat.The GRAPES guys were in the flea as usual, with WA4DSY modems for sale... dunno how well they fared.73 - Bdale, N3EUA------------------------------Date: 7 May 90 22:35:15 GMTFrom: decvax.dec.com!zinn!ubbs-nh!wa1omm!paul@mcnc.org (Paul MacDonald)Subject: NOS hosts.net file?To: packet-radio@ucsd.eduIt requires a file called DOMAIN.TXT which also happens to be adifferent format than HOSTS.NET. Here is a sample entry from DOMAIN.TXT:## Bob Springfieldnq1c.ampr.org. IN A 44.44.0.35nq1c. IN CNAME nq1c.ampr.org.-- /\ /\ //\\//\\ +--------------------------------------------+ | From the shack of WA1OMM -- Paul MacDonald | | Using the power of the multitasking Amiga! | | | | Compuserve: 70411,626 PLink: UPPERCRUST | | Amateur Packet Radio: WA1OMM@KB4N.NH.USA | +--------------------------------------------+ \\//\\// \/ \/ ------------------------------Date: Mon, 7 May 90 16:29:37 PDTFrom: Peter Dahl <pdahl@milton.u.washington.edu>Subject: PS-186 ???To: packet-radio@ucsd.eduDoes anyone know when AEA will begin shipping the PS-186?Do I remember correctly that it has more ports and more othercapabilities than the Kantronics Data Engine? What needs to be done to convince AEA to nake this product availableto us? Peter, WA7FUS------------------------------Date: 7 May 90 17:29:43 GMTFrom: amdahl!pacbell!billp@apple.com (Bill W. Putney)Subject: TM-231A rx audio for packet?To: packet-radio@ucsd.eduI just bought a Kenwood TM-231A and an MFJ 1270 TNC2 cloan. I noticedthat the TM-231A has unsquelched audio out at the mic plug. Thisis marked 100 mv into 10K ohms in the manual. I guess that it wasmeasured at something like 4.5 Khz dev with a 1Khz tone although itdoesn't say anywhere. What the manual doesn't say (actually thereare a lot of things it doesn't say...) is if this is de-emphasizedaudio. The MFJ manual has a few holes too. For instance, it doesn'tsay what the input level should be or what the input impedance is. Italked to MFJ this morning on the phone and they don't know ether.They seem to think it's input impedance is 8 ohms. Just from glancingat the schematic I find that hard to believe.I'd like to build a nifty little interface box, but I don't want tobuild it more than once.If anyone out there has more info I'd like to hear from you. I wouldlike to know; a) Does the TNC care if the audio is properly de-emphasized? b) Just what is the input impedance and level for an MFJ 1270 TNC? Maybe it's close to what a TAPR TNC2 is.Thanks - Bill Putney - WB6RFW billp@net.com or ames!unet!billp or (415)780-5309------------------------------Date: 7 May 90 11:04:00 EDTFrom: "SWEIGERT, DAVID" <dsweigert@paxrv-nes.navy.mil>Subject: US Navy WET NETsTo: "packet-radio" <packet-radio@wsmr-simtel20.army.mil>From:David SweigertTo:Interested partiesRef:DAEDALEAN's packet test for US NavyDate:May 7, 1990 GOOD NEWS ! The US Navy has decided to go ahead with a demonstrationtest to measure the effectiveness of data transmissions from shipto shore. The following mediums shall be utilized: o L-Band 1545 Mhz INMARSAT satellite o HF 20 - 30 Mhz links with data modems o Navy owned Fleet SATCOM satellites (2400 bits/second) This represents a significant step forward for the US Navy,to measure the cost/benefit of moving data from ship to shoredirectly from PC user to PC user. Data will not be routedthrough traditional channels, i.e. radio room, communicationsofficer. Test shall be conducted by the Navy Electronic SystemsActivity at Vallejo, Ca. Test area shall be an aircraft carriersailing out of San Diego, CA. If you would like more details let me know.Dave Sweigert, WB9VKOWB9VKO a W3ZH301-637-5602------------------------------Date: 7 May 90 18:20:09 GMTFrom: swrinde!zaphod.mps.ohio-state.edu!samsung!rex!rouge!pc.usl.edu!jp d@ucsd.edu (DugalJP)Subject: Wanted: FT736<->G3RUH 9600 baud interfacing infoTo: packet-radio@ucsd.eduAt the Dayton Hamvention I saw (very briefly) a description by G3RUH of hismodifications to a Yaesu FT736R for his 9600 baud modem. I'd like to obtaina copy, preferably ascii, of this information. Would anyone having a copyplease post it to this group, or email it to my address listed below?Both Lafayette-area FT736 and G3RUH modem owners thank you in advance!73 de-- James Dugal, N5KNX Internet: jpd@pc.usl.eduAssociate Director Ham packet: n5knx@w5ddlComputing Center US Mail: PO Box 42770 Lafayette, LA 70504University of Southwestern LA. Tel. 318-231-6417 U.S.A.---- James Dugal, N5KNX Internet: jpd@usl.eduAssociate Director Ham packet: n5knx@w5ddlComputing Center US Mail: PO Box 42770 Lafayette, LA 70504University of Southwestern LA. Tel. 318-231-6417 U.S.A.------------------------------End of Packet-Radio Digest******************************Date: Wed, 9 May 90 04:00:03 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #22To: packet-radioPacket-Radio Digest Wed, 9 May 90 Volume 90 : Issue 22Today's Topics: faster modems faster modems and spectrum allocation New Packet Stuff @ Dayton?? PC-Pakratt patch PS-186 ??? Xerox 820 computersSend Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 8 May 90 19:42:08 GMTFrom: oliveb!amdahl!pacbell!tandem!kevinr@apple.com (Kevin J. Rowett)Subject: faster modemsTo: packet-radio@ucsd.eduIn article <3576@optilink.UUCP> elliott@optilink.UUCP (Paul Elliott x225) writes:>>What is the most appropriate model for ham radio packet? [The original article wondered about relative speeds between switches]In general, Internet practices deliver service such that the more interactionhad with someone ( or his data ), the faster the link provided. Locality ofdata access forms the link arch.We all have very fast ( 10 Mbps - 100 Mbps ) to our file servers and to peoplein our work group. To other employees within the same company, it ranges fromT1 to 10 MBps. TO Mr. Karn, it drops to a nailed up 9.6Kbps V.32 SLIP link.So, physical adjacent maps to speed adjacency. For the AR community, speedadjacency and physical adjacency don't map too well.For Internet practices, the pipe gets smaller the farther data travels. TELCOs, on the other hand, always delivery the same size pipe, no matter how far you travel. Bear in mind, the pipe the TELCO delivers is universallytoo SMALL.Just ideas for thought.N6RCE------------------------------Date: 9 May 90 06:17:17 GMTFrom: pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!sol. ctr.columbia.edu!emory!rsiatl!jgd@tut.cis.ohio-state.edu (John G. De Armond)Subject: faster modems and spectrum allocationTo: packet-radio@ucsd.eduA conversation on the local repeater this afternoon brought up an issuethat was news to me. A ham who works in the land-mobile business commentedthat the FCC is going to reallocate most of our 900 mhz band in severallarge metro areas - Atlanta included - to land-mobile service. Hefurther commented that there was a NPRM published a couple of monthsago.I never saw anything in this group, from the ARRL, or anywhere elseabout this turn of events. Anyone else know anything about this stateof affairs?John-- John De Armond, WD4OQC | We can no more blame our loss of freedom on congressRadiation Systems, Inc. | than we can prostitution on pimps. Both simplyAtlanta, Ga | provide broker services for their customers.{emory,uunet}!rsiatl!jgd| - Dr. W Williams | **I am the NRA** ------------------------------Date: 8 May 90 14:58:02 GMTFrom: usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!cunews!bcars 8!bnrgate!bcarh342!mleech@ucsd.edu (Marcus Leech)Subject: New Packet Stuff @ Dayton??To: packet-radio@ucsd.eduIn article <18330021@col.hp.com>, bdale@col.hp.com (Bdale Garbee) writes:> The GRAPES guys were in the flea as usual, with WA4DSY modems > for sale... dunno how well they fared.Well, they made (as usual) a pile off us, Bdale. We bought another couple ofcomplete modems, and another two boards sets. I have just about all the piecesI need now for my laptop 56Kbps packet station!-----------------Marcus Leech, 4Y11 Bell-Northern Research |opinions expressedmleech@bnr.ca P.O. Box 3511, Stn. C |are my own, and notVE3MDL@VE3JF.ON.CAN.NA Ottawa, ON, CANADA |necessarily BNRs------------------------------Date: 8 May 90 13:20:12 GMTFrom: usc!cs.utexas.edu!ut-emx!frank@ucsd.edu (Frank Abernathy)Subject: PC-Pakratt patchTo: packet-radio@ucsd.eduIn article <1990May4.203531.15322@swlabs.uucp>, jack@swlabs.uucp (Jack Bonn) writes:> The software indicates that it is "Unable to establish communications> with Pakratt" and terminates.> > So it looks like the near term solution is to patch the timing loop to> eliminate the problem. To save the time, has anyone on the net > hacked/patched PC-Pakratt to eliminate this problem? > -- > Jack Bonn, KC1UH, <> Software Labs, Ltd, Box 451, Easton CT 06612> uunet!swlabs!jack (UUCP) jack%swlabs.uucp@uunet.uu.net (INTERNET)> jack@kc1uh (TCP/IP) kc1uh@wb1cqo (AX.25)I also had a problem as you described above.What I did to resolve it was to turn down the volume, disconnect the audio-inor set the DCD Threshold to a point where the CD light doesn't come on.Then reinitialize the I/O.Works every time for me. PK-232/MBX with PC-Pakratt.I suspect that having active data transitions while it's trying to initializejust blows their firmware's mind..hope this helpslaterfrank-- Frank Abernathy, University of Texas at Austin, frank@ut-emx.utexas.eduWork: (512)-471-3216 Home: (512)-244-0625 (ans. mach always on...)------------------------------Date: 8 May 90 16:06:23 GMTFrom: hpcc01!col!bdale@hplabs.hp.com (Bdale Garbee)Subject: PS-186 ???To: packet-radio@ucsd.edu>Does anyone know when AEA will begin shipping the PS-186?No. At Dayton, AEA once again had a spec-sheet available, but was notoffering any price or delivery information that I heard.I understand that they passed FCC, and claim they are "waiting for software"before beginning production and shipments.>Do I remember correctly that it has more ports and more other>capabilities than the Kantronics Data Engine? It has 4 ports plus console instead of 2 plus console, or 5 instead of 3 ifyou're thinking in switch terms. It has provision for an optional SCSIinterface. It uses an 80C186 instead of a V40, which is a bit of a downer,but simply indicates vintage, and doesn't affect performance notably.>What needs to be done to convince AEA to nake this product available>to us?Dunno. Every time I've heard from them, it's been a different reason. AtDayton, they made it pretty clear they expect me to deliver up a NOS implemenation before they'll ship. It's absolutely amazing to me that AEA has invested in the PS-186, and wouldhalt that close to production out of an unwillingness to invest in any internalsoftware development. The Kantronics approach of shipping software that makestheir unit look like a multi-port fast TNC by default is really neat, becauseit means they can ship hardware that can be semi-useful to people even withoutany additional software effort. And it's a fundamental law of nature thatfolks like me write software for whatever hardware *is available* that solvesa given problem.If you want a PS-186, call AEA and tell them so, and try to pin them down onprice and delivery information. Make it clear to them that you want hardwaresooner rather than later, and if you feel strongly enough about it, tell themyou want it regardless of software availability.If you want a DE with more ports, call Kantronics and ask them if/when theymight do a 4-port follow-on product.If you want a 5-10 port switch product you can buy today, that's very fastwith a price to match, contact Grace Communications and ask about their PacketTen, which was shown and was available for sale at Dayton, based on a 68302 processor. They'll answer email at uunet!ldhmi!donl, I'm pretty sure. They had NOS running on the board at Dayton... pretty neat.Either way, I've got NOS "almost working" on both the PS-186 and the DE, andsometime this summer you'll be able to get ROMs from me somehow (maybe via TAPR?) that give you switch functionality on either the PS-186 or DE.73 - Bdale, N3EUA------------------------------Date: 29 Apr 90 19:59:30 GMTFrom: zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!peregrine !ccicpg!cci632!rit!ultb!jla4983@tut.cis.ohio-state.edu (J.L. Austin)Subject: Xerox 820 computersTo: packet-radio@ucsd.edu I bought a Xerox 820 motherboard and most of the parts toassemble it (memory , processor , misc. chips) at a hamfest this weekendfor $10.00. It didn't come with any documentation. Does anyone knowwhere I can get some info on this. I can think of lots of projects fora Z-80 machine with 2 serial ports and 2 parallel ports and I'd like toput it togethor sometime this summer.73,Jim ------------------------------End of Packet-Radio Digest******************************Date: Thu, 10 May 90 04:00:03 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #23To: packet-radioPacket-Radio Digest Thu, 10 May 90 Volume 90 : Issue 23Today's Topics: faster modems and spectrum allocation New Packet Stuff @ Dayton?? PC-Pakratt patchSend Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 9 May 90 14:37:52 GMTFrom: usc!elroy.jpl.nasa.gov!hydra!jta@ucsd.edu (Jon T. Adams)Subject: faster modems and spectrum allocationTo: packet-radio@ucsd.eduIn article <2154@rsiatl.UUCP> jgd@rsiatl.UUCP (John G. De Armond) writes:>...>that the FCC is going to reallocate most of our 900 mhz band in several>large metro areas - Atlanta included - to land-mobile service. He>further commented that there was a NPRM published a couple of months>ago.>...>JohnWe have lost the 904 - 912MHz portion of the band to an arm of PacificTelephone. In fact, later this month the Southern California frequency coordination board for 900 will be meeting in a special session to rearrange the bandplan; there is also the possibility that a second chunk,from 916 - 924MHz, may be on the block.However, the ARRL is busily pursuing the matter; right after they getdone with their monument to dead hams.What am I going to do? Seems like it's time to put packet on 900 andmake terrible amounts of noise... (See? Packet IS good for something!):):):)73 - Jon --Jon Trent Adams, NW6H | "Per Aspera Ad Astra" A Dead RomanJTA@hydra.jpl.nasa.gov | Way-Rad : Opinionated : Single : Prevaricator :"jpl don't know me from squat"| Raconteur : Engineer : President, Local ChapterGhenghis Khan Fan Club : Honorable Mention, "Calvin" Lookalike Contest------------------------------Date: 9 May 90 19:46:38 GMTFrom: hpcc01!col!bdale@hplabs.hp.com (Bdale Garbee)Subject: New Packet Stuff @ Dayton??To: packet-radio@ucsd.edu>In article <18330021@col.hp.com>, bdale@col.hp.com (Bdale Garbee) writes:>> The GRAPES guys were in the flea as usual, with WA4DSY modems >> for sale... dunno how well they fared.>>Well, they made (as usual) a pile off us, Bdale. We bought another couple of>complete modems, and another two boards sets. I have just about all the pieces>I need now for my laptop 56Kbps packet station!Yeah, and you cost me a bundle, too! I wandered by Spectrum International onSunday morning and bought their last 220 transverter, and one each 220 and 430downconverters... now I have all the pieces to build our repeater, if andwhen I can find time...:-)Bdale------------------------------Date: 9 May 90 23:50:25 GMTFrom: att!cbnewsh!k4bnc@ucbvax.Berkeley.EDU (john.a.siegel)Subject: PC-Pakratt patchTo: packet-radio@ucsd.eduIn article <29621@ut-emx.UUCP>, frank@ut-emx.UUCP (Frank Abernathy) writes:> > with Pakratt" and terminates.> > > > So it looks like the near term solution is to patch the timing loop to> > eliminate the problem. To save the time, has anyone on the net > > hacked/patched PC-Pakratt to eliminate this problem? > > -- > > Jack Bonn, KC1UH, <> Software Labs, Ltd, Box 451, Easton CT 06612> > I also had a problem as you described above.> > What I did to resolve it was to turn down the volume, disconnect the audio-in> or set the DCD Threshold to a point where the CD light doesn't come on.> > Then reinitialize the I/O.> > Works every time for me. PK-232/MBX with PC-Pakratt.> > I suspect that having active data transitions while it's trying to initialize> just blows their firmware's mind..> > > hope this helps> later> frank> > > -- ------------------------------End of Packet-Radio Digest******************************Date: Fri, 11 May 90 04:00:05 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #24To: packet-radioPacket-Radio Digest Fri, 11 May 90 Volume 90 : Issue 24Today's Topics: Old Bulletins - a (LONG) proposal to wipe them out (2 msgs) Packet-Radio Digest V1 #23 SAREX Information And Operating HintsSend Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 10 May 90 20:51:36 GMTFrom: van-bc!ubc-cs!alberta!dvinci!news@ucbvax.Berkeley.EDU (Peter Hardie)Subject: Old Bulletins - a (LONG) proposal to wipe them outTo: packet-radio@ucsd.edu One of the amusing/annoying things about bulletins is watching astation transmit a bulletin that is obviously way out of date. As anexample, consider the bandwidth that has been wasted due to thecontinued transmission of a bulletin announcing the launch of theMICROSATS. This bulletin was still being transmitted long after theevent and was then closely followed by bulletins that gave morerecent element sets, each of which was soon superseded by another.Other examples are the ARRL DX bulletins and the AMSAT satelliteelement sets whose useful life is typically only two weeks. The problem here is not the individuals who generate thebulletins, nor is it really the SYSOPs fault. What is required is amechanism, built into the bulletin transmission, which automaticallyprevents an out of date bulletin from being forwarded (even if it hasnot been forwarded to all stations on a BBS forwarding list) andwhich also deletes bulletins once their usefulness has expired. In Europe there's a BBS called THEBOX which has an extra fieldwhen sending a bulletin called the 'lifetime' field. At the end ofthe line there's a field that looks like this '#12'. The # indicatesa lifetime field and the 12 says the bulletin's lifetime is 12 days.So any BBS that has this bulletin for more than 12 days will stopforwarding it and, presumably, also delete it. However, there are twoproblems with this. It is not compatible with most BBS systems herein North America and may make some of them croak. But it also doesnot prevent the continuous transmission of the bulletin after itsoriginal lifetime is up. This is because its lifetime is relative towhen it was received at a BBS. So if I create a bulletin with alifetime of two days and just before the two days are up I send it tosomeone else, then it can live for two more days there. If they thensend it on, it lives another two days and it can therefore live muchlonger than it should. I have a proposal for any and all BBS writers out there. Ibelieve this proposal is compatible with all existing systems andwill help alleviate the above problem if implemented. I propose that an expiry date be encoded in the BID field of anybulletin. The advantage to this is that every BBS accepts and passesBIDs. If they don't understand the expiry field, it won't matterbecause they'll just pass it on and treat it as they would any otherBID. But compatible systems would do 'the right thing'. The BBS I'mmost familiar with is CBBS (which I ported to the AMIGA) and it's BIDfield is limited to 12 chars. So to minimize the amount of spacetaken up in the BID I propose to encode an expiry date in thefollowing way. If the first character of the BID (after the '$' BIDindicator) is a number sign '#' (arbitrary, but we must all agree onit) then it is followed by two more characters which encode month andday of expiry. This encoding will assume that bulletins are neverpermitted to have an expiry date more than six months into thefuture. As an example, if I created a bulletin with an expiry dateof May 5th and it is now May 10th then I consider May 5th to be over11 months into the future (i.e. it refers to NEXT May 5th). Thus abulletin has expired if its expiry date specifies a month/day that ismore than six months in the future. If necessary, this 'standard'could add another character to include the year as a number relativeto 1990 but this would then permit ridiculously long expiry dates.The month (1-12) and day (1-31) are encoded as a single character byindexing the number into the string 0123456789ABCDEFGHIJKLMNOPQRSTUV Thus an expiry date of Jun 14th would be encoded as #6E and theremainder of the BID then follows e.g. sb all @ sask <ve5va $#6E2214ve5va Putting the expiry date first ensures that it won't gettruncated by a system which stores a shorter than normal BID. Anycurrent system that doesn't know what the #6E means will simply passit along as a part of the BID. BUT, compatible systems are required to do the following. 1. If a system sends you a bulletin whose BID expiry date is more than six months in the future then you must reject it (i.e. the BBS replies 'N - expired'). This will occur if a non-compatible system tries to forward an expired bulletin. 2. No bulletin that has expired will be forwarded any further even if it has not yet been distributed to all those you normally send it to. 3. In the BBS cleanup process, the SYSOP should have the option to specify that expired bulletins are automatically deleted (or archived), otherwise they are marked as 'O'ld and the SYSOP will still manually clean them up. 4. A modification is required to the commands (SB, MB etc.) that create bulletins. First there should be a universally agreed (or SYSOP specified) default expiry time, such as 14 days from the date of creation which is used on any bulletin created without an explicit expiry date. There should also be a universally agreed maximum that users can specify, say, 3 months? certainly no more than 6! Then, borrowing from THEBOX, the syntax for the SB, and similar, commands should be extended so that the user can specify the lifetime of the bulletin in days (e.g. to 21 days) by adding #21 on the end of the command. This does NOT mean that the #21 is sent when the bulletin is forwarded. It is converted into the encoded expiry date in the BID and the #21 is stripped from the command. This would have the slightly beneficial side-effect that systems with this feature would automatically adapt to receiving such a command from THEBOX and would convert the lifetime into a useful expiry date for further transmission. There are lots of RLI/MBL/MSYS systems in Europe, some of which must talk to THEBOX, and this will make them more compatible. If you implement such a BBS you could make it even more compatible by detecting if you are forwarding to a THEBOX (look for either [THEBOX or [DL5UY ), and converting the expiry date back into a # field at the end of the sb command (but, of course, leave the expiry field in the bid). My CBBS currently stores and forwards the lifetime field to THEBOX. (I use the THEBOX syntax only because it already exists and I don't know of any other system that has anything similar). NOTE that the worst that happens with this system is that thingsstay as they are - they don't get worse. But if implemented it helpsto improve things considerably. I will probably implement this in the next CBBS distribution for theAMIGA. Any comment? 73 de Pete Hardie VE5VAhardie@skyfox.usask.ca ------------------------------Date: 11 May 90 01:55:26 GMTFrom: haven!sayshell.umd.edu!louie@purdue.edu (Louis A. Mamakos)Subject: Old Bulletins - a (LONG) proposal to wipe them outTo: packet-radio@ucsd.eduIt seems that we hams are doing our typical thing again: re-inventing wheels.Why not use the experience gained by the USENET community in building a verylarge distributed bulletin board system, not to mention all of the code that'sfreely available? Instead, its being re-invented bit-by-bit, piece by piece.NIH: gack!louie WA3YMH------------------------------Date: Thu, 10 May 90 14:12 NFrom: Urs Baer <BWLLIBMOD%CSGHSG5A.BITNET@CORNELLC.cit.cornell.edu>Subject: Packet-Radio Digest V1 #23To: Packet-Radio@UCSD.EduPLEASE REMOVE MY OLD ADRESS 87674800S@CSGHSG5A.BITNET FROM YOUR LIST. THELISTSERV AT UCSD DOESN'T WORK.THANKS, URS HB9DIL------------------------------Date: 8 May 90 01:14:27 GMTFrom: usc!zaphod.mps.ohio-state.edu!rpi!crdgw1!ge-dab!tarpit!peora!tsdi ag!ka2qhd!kd2bd@ucsd.edu (John Magliacane)Subject: SAREX Information And Operating HintsTo: packet-radio@ucsd.eduSAREX-II is a secondary payload on STS-35, currently scheduled for launch onMay 17, 1990. It will be located in the Aft Flight Deck of the Space ShuttleColumbia. Ron Parise, WA4SIR, the Payload Specialist and astronomer on Colum-bia will be the Astronaut ham operator.SAREX-II-02 is a secondary payload on STS-37, currently scheduled for launchon November 1, 1990. It will be located in the Aft Flight Deck of the SpaceShuttle Atlantis. Ken Cameron, KB5AWP, the pilot of Atlantis will be theAstronaut ham operator.The American Radio Relay League (ARRL) is the customer on the SAREX-IIpayloads. NASA gave its authorization for SAREX operations for the followingreasons: To encourage our youth to become excited about science and technology, and To familiarize large numbers of the general public with manned space flightNASA's intent in making astronauts available for SAREX operations is toinvolve the largest possible number of people, particularly youngsters, inAmateur Radio and the US space program. With amateur radio clubs and hams,our astronauts will speak over amateur frequencies directly with large groupsof students, showing teachers, parents and communities how Amateur Radioenergizes youngsters about science, technology, and learning.You can easily become a part of this activity in your local school, as theastronauts will operate the SAREX equipment in the amateur two meter band.You will be able to send and receive messages via packet for periods of about12 hours daily. The astronauts' work schedules will determine your chancesfor a voice or television message, but Ron and Ken may have an hour or moreeach day for these modes.The Johnson Space Center's Amateur Radio Club station, W5RRR, in Houston,Texas, will re-transmit astronaut's signals to WA3NAN, at Goddard SpaceFlight Center, in Greenbelt, MD (near Washington, DC), and to W6VIO, at theJet Propulsion Laboratory in Pasadena, CA. These stations, plus W1AW andseveral VHF and UHF repeater groups, will re-transmit the signals on mostamateur bands so that you and the students can copy the communications. Youwill hear NASA Mission Commentary, frequent bulletins to advise listeners ofastronaut planned transmissions, and all amateur two-way voice and amateurtelevision transmissions with the shuttles. Using a simple hand-heldtransceiver, you can open the world of science to hundreds of youngsters.Students themselves can take part in the shuttle flight via a packetconnection, and some will even be able to talk directly to the astronautsin orbit.ARRL and AMSAT are co-sponsoring these exciting missions, with AMSAT headingup technical operations. Hundreds of Amateur Radio operators have alreadybeen working behind the scenes for months. The ARRL takes the lead withinformation and educational support. ARRL Educational Activities Branch(EAB) and NASA HQ will create lesson plans for teachers. All you need toprovide is a 2-meter rig or a packet radio setup. If you are a teacher orinstructor, contact ARRL EAB to get everything you will need and regular newsupdates. If you are a parent or a grandparent, contact ARRL EAB and a localschool. EAB will send you materials, including ways to convince teachers andschool administrators that Amateur Radio is an important discipline the schoolshould take advantage of on a full-time basis.This a tremendous opportunity for you to showcase SAREX 1990 and amateur radioto kids of all ages in a big way. Plan on being a part of it; contact ARRLEAB now and give your best to our exciting hobby and to our hope for tomorrow:America's youth.Listen to the ARRL Bulletins on W1AW (see QST for CW and voice bulletins) on adaily basis; and to the AMSAT Nets on Tuesdays (U. S.), 3.840 MHz, 01:30Z to03:00Z, and on Sundays (international), 14.282 MHz, 18:00Z to 21:00Z, +/- QRM.[ANS would like to thank ARRL and NASA for this contribution. Stay tuned nextweek to the ANS bulletins for more details about the STS-35 mission and itsamateur radio operations.]The WA4SIR flight aboard the STS-35 flight of the Shuttle Columbia isstill officially scheduled for early May 16th (GMT), although there aresome hints that it might slip by one day. The SAREX mission will carrythe packet ROBOT automatic QSO machine which will allow many amateursaround the world to have two-way packet QSO's with the Shuttle duringthe times when our ham astronaut, Ron Parise is busy.To work the ROBOT, you transmit on 144.950 MHz and listen to the Shuttleon 145.550 MHz. Subsequent SAREX information bulletins will give youoperating hints and describe the schedule in more detail.If you are successful in making a two-way QSO, you call and your uniqueQSO serial number will be automatically logged and you will receive aQSL card after the mission. You will know you met all requirements of atwo-way QSO by seeing your call in the QSL beacon which will be sentevery 2 minutes and looks something like: WA4SIR>QSL <UI>: NI3F/186 WB2TNL/185 W3IUI/179 WB3AFL/177 NF3N/176 WA3EPT/175 N4QQ/174 W3IWI/172 JY1/153 U6MIR/127If you are heard by the ROBOT, your call will appear in the QRZ beaconwhich will look something like: WA4SIR>QRZ <UI>: #3405-NE3H NI3F K1LNJ WB2TNL WB3ILO N3ACL N3FWX WA3TSD WA3USG etceterawhere the #3405 is a serial number incremented every 2 minutes when theQRZ beacon is sent.Unlike the QSL "worked" list, the QRZ "heard" list is not retained inthe ROBOT and the laptop computer on the shuttle. In order to send SWLcards to those who were heard, it will be necessary to have amateursaround the world help to collect the list. When you are monitoring theWA4SIR SAREX transmissions, try to capture the beacons and send them into us in machine readable format. We are only interested in the QRZ andQSL beacon information; please strip out everything else (like QSOsmonitored, any other beacons, etc.). You may send it through the amateurpacket network addressed like this: SP SAREX @ W3IWI.MD.USAor via the Internet addressed like: sarex@tomcat.gsfc.nasa.govand make the Subject: field contain the date/time of the beacons like: May 19 @ 03:42zHere are several hints that may help you make a successful packet QSOwith the SAREX ROBOT that will fly with Ron Parise, WA4SIR in mid-May.1. Frequencies: Your transmitter uplink frequency should be 144.950 MHzand you should listen for the shuttle downlink 600 kHz higher on 145.550MHz. Under no conditions should you transmit on the 145.550 downlink!Since there may be other packet or voice activity in your area on thesefrequencies, local coordination to insure a clear frequency during theten day STS-35 mission may be needed.2. Modulation: The uplinks and downlinks are ordinary AFSK/FM 1200 BPSsignals, just like most terrestrial VHF packets. No special modems areneeded. You are advised to check your transmitter's FM deviation and setit to 3 kHz or less. Most radios are typically set to 5-6 kHz and thiswill be too wide because of doppler shifts. If you don't have adeviation meter, listen on another radio and crank the tone level downuntil you hear the volume drop noticeably. Most people run too muchdeviation on their packet signals anyway, and you will probably findthis improves the reliability on terrestrial paths too!3. When to hear/work the shuttle: During the mission Keplerian elementsand predictions will be sent frequently by WA3NAN, W5RRR, W6VIO, andmany local FM repeaters, as well as by packet bulletins addressed to@AMSAT. Check with your local AMSAT area coordinators for information inyour area. In general in the USA, the windows are in the late eveningand early morning hours. Don't expect the SAREX hardware to be activateduntil the second day of the ten-day mission. Because the inclination ofthe shuttle orbit is only 28.5 degrees, the signals can only be heardbetween about +43 and -43 degrees latitude.4. LISTEN!!!: Most packeteers don't listen to the BRAAAAP! from theirradios, but you should listen during the shuttle activity. If Ron ispersonally available, he may turn off the SAREX packet hardware and beQRV on voice.5. Connecting to the shuttle: All you do is to issue a connect. If youare heard, you will see something like this: cmd: CONNECT WA4SIR *** Connected to WA4SIR #191--- Tnx QSO with the SAREX Shuttle "ROBOT" automatic QSO machine *** DISCONNECTEDWhen the ROBOT hears your "ack" of its transmission, it will disconnectand you will be in the log. Because the ROBOT queues information for 3seconds and sends several replies in one transmission, you should setyour DWAIT to about 4 seconds.6. Multiple QSO's: Once you have worked the ROBOT and make it into thelog, no further QSO's from you will be logged (even if you use adifferent SSID). Give others a chance and don't connect multiple times!7. Monitor!!!: Every 2 minutes a beacon addressed to QRZ will liststations heard recently, and the QSL beacon will list those worked.Every 3 minutes the Metabeacon (up to 1.7 kbytes in 7 packet frames)addressed to QST will send text describing shuttle activities. Monitorthese beacons to keep informed. In Bulletin #1 we ask for you to submitcopies of the QRZ and QSL beacons you copy.8: Your chances for success: Signals from many hundreds of stations canbe heard from the shuttle. With FM transmissions, only the strongestsignal "wins", just like in a DX pileup. To help, the ROBOT can have upto 9 QSO's in progress at any one time. Perserverance and a wellequipped station will help -- but if activity levels are high and theuplink channels are busy, it will be a matter of luck.[ From: w3iwi%w3iwi.md.usa@bbs.nn2z.ampr.org ]-- 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------------------------------End of Packet-Radio Digest******************************Date: Sat, 12 May 90 04:00:05 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #25To: packet-radioPacket-Radio Digest Sat, 12 May 90 Volume 90 : Issue 25Today's Topics: NOS and ax.25/NetRom timing this is a test... disregard if you receive thisSend Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 11 May 90 18:29:25 GMTFrom: silver!barkeyp@iuvax.cs.indiana.edu (patrick barkey)Subject: NOS and ax.25/NetRom timingTo: packet-radio@ucsd.eduI have a problem with NOS when I am using either ax.25 or net/rom.The problem is that whenever the sending station sends me morethan one frame, my acknowledgement of the first frame collides withthe second frame sent by the sending station.This never happens with IP packets, but always happens with ax.25and net/rom packets. Can anyone give me any hints what parameters totinker with to eliminate this problem? Thanks in advance. -- Pat Barkey WA8YVR Bloomington, IN------------------------------Date: Fri, 11 May 90 18:41 CDTFrom: Buckaroo Bonzai and the Team of Baker Street IrregularsSubject: this is a test... disregard if you receive thisTo: NEXT-L@BROWNVM.BITNET, INFO-UNIX@BRL.MIL, TCP-IP@NIC.DDN.MIL,this is a test.. please disregard if you get this... my mail router hereat the university of houston has died a death or two.william sanders, a subscriber to this list------------------------------End of Packet-Radio Digest******************************Date: Sun, 13 May 90 04:00:03 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #26To: packet-radioPacket-Radio Digest Sun, 13 May 90 Volume 90 : Issue 26Today's Topics: KA9Q & PC-NFS Mac/Commodore-Amiga KA9Q (2 msgs) NOS and ax.25/NetRom timingSend Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 12 May 90 09:51:22 GMTFrom: uhccux!querubin@ames.arc.nasa.gov (Antonio Querubin)Subject: KA9Q & PC-NFSTo: packet-radio@ucsd.eduI have a PC with a 386 processor running DOS 3.3 and SUN's PC-NFS on a 3COM3C503 card. I would also like to be able to set the machine up as a bridge toan AX.25 TCP/IP network by running KA9Q's NOS. Can the packet driver for the3C503 coexist with PC-NFS so that both PC-NFS and KA9Q can be running at thesame time under something like Desqview or Windows/386? Is there perhapsanother way of accomplishing the same thing without having to buy a separateEthernet card for KA9Q? For example, could PC-NFS be setup to use a packetdriver? Would appreciate hearing from anyone who has tried the above.Internet: antonio_querubin-manoa@uhplato.uhcc.hawaii.eduBITnet: antonio_querubin-manoa@uhplato ------------------------------Date: 10 May 90 10:52:45 GMTFrom: uhccux!querubin@ames.arc.nasa.gov (Antonio Querubin)Subject: Mac/Commodore-Amiga KA9QTo: packet-radio@ucsd.eduAnyone know where the latest releases of both the Macintosh & Commodore-Amigaversion of KA9Q can be FTP'd from? The Macintosh KA9Q I have is very buggy.And a friend of mind with a Commodore-Amiga wants to run KA9Q.AH6BWInternet: antonio_querubin-manoa@uhplato.uhcc.hawaii.eduBITnet: antonio_querubin-manoa@uhplato------------------------------Date: 13 May 90 01:07:20 GMTFrom: winter@apple.com (Patty Winter)Subject: Mac/Commodore-Amiga KA9QTo: packet-radio@ucsd.eduIn article <7627@uhccux.uhcc.hawaii.edu> querubin@uhccux.UUCP (Antonio Querubin) writes:>Anyone know where the latest releases of both the Macintosh & Commodore-Amiga>version of KA9Q can be FTP'd from? The latest released version of the Mac code can be found in /pub/ham-radioon apple.com. Anyone who really wants to stay informed about new releasesshould send their name and address to Doug Thom, N6OYU, at 1405 Graywood Drive, San Jose, CA 95129. He can provide you with interim (i.e., notofficial releases) versions.>The Macintosh KA9Q I have is very buggy.What version is this? There's been a very stable version available sinceat least April, 1989.73,Patty-- ***************************************************************** ************ Patty Winter N6BIS INTERNET: winter@apple.comAMPR.ORG: [44.4.0.44] UUCP: {decwrl,nsc,sun}!apple!winter************************************ ***************************************** ------------------------------Date: 13 May 90 04:08:54 GMTFrom: ka9q.bellcore.com!karn@bellcore.com (Phil Karn)Subject: NOS and ax.25/NetRom timingTo: packet-radio@ucsd.eduIn article <44693@iuvax.cs.indiana.edu> barkeyp@silver.ucs.indiana.edu (patrick barkey) writes:>I have a problem with NOS when I am using either ax.25 or net/rom.>The problem is that whenever the sending station sends me more>than one frame, my acknowledgement of the first frame collides with>the second frame sent by the sending station.All you have to do is to get the other stations to set their MAXFRAMEparameters to 1. Half duplex AX.25 packet radio stations should alwaysoperate this way, with packet sizes varied to suit channel conditions. Phil ------------------------------End of Packet-Radio Digest******************************Date: Mon, 14 May 90 04:00:03 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #27To: packet-radioPacket-Radio Digest Mon, 14 May 90 Volume 90 : Issue 27Today's Topics: Mac/Commodore-Amiga KA9Q NOS and ax.25/NetRom timing TCP/IP activity in NYC areaSend Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 14 May 90 04:28:00 GMTFrom: uhccux!querubin@ames.arc.nasa.gov (Antonio Querubin)Subject: Mac/Commodore-Amiga KA9QTo: packet-radio@ucsd.eduThe copy of MacNET that I have is from simtel20.arpa which seems to be exactlythe same as the one on flash.bellcore.com. The copy on apple.com has a laterdate on it so I'll check into it.The version I now have running (or not running) rejects the attachcommands in the autoexec.net file, but when the same attach command is typed inmanually in the console window the program takes it (am I missing somethingobvious?). There are also a number of inconsistencies between the on-line helpand the separate help doc about the syntax of the attach command.------------------------------Date: 14 May 90 00:58:29 GMTFrom: usc!wuarchive!texbell!splut!jay@ucsd.edu (Jay "you ignorant splut!" Maynard)Subject: NOS and ax.25/NetRom timingTo: packet-radio@ucsd.eduIn article <23173@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes:>In article <44693@iuvax.cs.indiana.edu> barkeyp@silver.ucs.indiana.edu (patrick barkey) writes:>>I have a problem with NOS when I am using either ax.25 or net/rom.>>The problem is that whenever the sending station sends me more>>than one frame, my acknowledgement of the first frame collid e s with>>the second frame sent by the sending station.>All you have to do is to get the other stations to set their MAXFRAME>parameters to 1. Half duplex AX.25 packet radio stations should always>operate this way, with packet sizes varied to suit channel conditions. While they probably should, remember that not everybody has beenordained in the Holy Church of Karn's Packet Operating Technique, andinvestigate the problem a little further. Is this collision happeningbecause the other station drops carrier between the two packets? If so,won't the retransmission happen with the carrier on continuously, andthe acknowledgement be sent for the last frame - or does the AX25handler do that? If not, is his TNC trying to transmit while there'sstill a signal on the channel, or is the link weak enough that his TNCis losing lock?The recommendation in the past has been that BBSes and other data hostsrun with a MAXFRAME of 1, but said nothing about user stations.(On another subject, my system has been down for two weeks. Have youcome up with a politically acceptable spectrum management plan yet?)-- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which canjay@splut.conmicro.com (eieio)| adequately be explained by stupidity.attctc, RIP. It was nice knowing ya +---------------------------------------- "Flying is a lot more fun than being in the Senate." -- Senator Jake Garn------------------------------Date: 13 May 90 05:13:53 GMTFrom: l70si@cunyvm.cuny.edu (Don)Subject: TCP/IP activity in NYC areaTo: packet-radio@ucsd.eduHi, I was wondering if anyone on this conference could give me info on whoin the New York city area is running TCP/IP. A friend (KA2PBT) and I are just starting out with the KA2Q softwareand was wondering :1) Who in the NYC (Staten Island) area is running KA9Q (calls/QTH/net addresses etc)2) What freq/data rates (5.01/4.95 etc) are most common here? Thanks in advance Don-------******************************************************* ***************** Donald Barr Internet: L70SI@CUNYVM.CUNY.EDU ** At&t (718)-987-8751 Bitnet: L70SI@CUNYVM ** or 0652 HAM: KA2YDX ***************************************************************** *******------------------------------End of Packet-Radio Digest******************************Date: Tue, 15 May 90 04:00:03 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #28To: packet-radioPacket-Radio Digest Tue, 15 May 90 Volume 90 : Issue 28Today's Topics: 2 Mbps modems for packet use Atari Portfolio on packet = interference Educational Application for Packet/tcp-ip Enquiry about HDLC chip NOS and ax.25/NetRom timing (2 msgs)Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 13 May 90 23:31:02 GMTFrom: mintaka!snorkelwacker!bu.edu!mirror!otto!rex@think.com (Rex Jolliff)Subject: 2 Mbps modems for packet useTo: packet-radio@ucsd.eduSome of my friends and I are interested in building a TCP basednetwork using the 2 MBPS modems that are being talked about in thisnewgroup. I would like to get the details on where I can buy thesemodems, and other things like if it's possible to use a transverterand a 144 Mhz radio with these modems, etc.Most of us have (or will have) 386PCs running Xenix. Is there aproblem running KA9Q under Xenix? Thanks in advance, Rex.-- Rex Jolliff (rex@otto.lvsun.com, {convex, texsun, mirror}!otto!rex)The Sun Newspaper - |Disclaimer: The opinions and comments inNevada's Largest Daily Morning | this article are my own and in no wayNewspaper | reflect the opinions of my employers.- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Why are we letting the government drug propaganda get the best of us?------------------------------Date: 15 May 90 02:56:33 GMTFrom: usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!xanth!mka@u csd.edu (Mark K Arquette)Subject: Atari Portfolio on packet = interferenceTo: packet-radio@ucsd.eduI need some help from the interference gurus out there. I am trying to set upa portable packet station using a kenwood th-21at, a heathkit hk-21 tnc and aportfolio. The problem is that the portfolio creates a whining sound rightaround 145.01 and 223.5 Mhz. I doubt that anyone has specific info on the ataribut how about some general idea on supressing computer interference that areapplicable to the portfolio. I know that the computer is the culpret throughthe process of elimination, and the realy nice part it that it only interferswhen running a program, especially the term program for it. I am going to trysome other programs but it's serial port is not quite standard at the low levelso I doubt that they will work, also they (the other programs) are very big.The term program for the portfolio is just over 2k and includes xmodem filetransfers and programmable function key strings. Oh well, any help will beappreciated.------------------------------Date: 15 May 90 05:04:38 GMTFrom: cs.utexas.edu!asuvax!stjhmc!ddodell@tut.cis.ohio-state.edu (David Dodell)Subject: Educational Application for Packet/tcp-ipTo: packet-radio@ucsd.eduI have a educational application for packet radio, where we would like to run some high-speed links using KA9Q tcp/ip package.While I have done this in my amateur installation (wb7tpy.ampr.org) at 1200 baud, what speed modems are available at the moment in either design or kit form ... 9600? 56kps?Any information would be appreciated.David -- ----------------------------------------------------------------- -------- St. Joseph's Hospital and Medical Center, Phoenix, Arizona uucp: {gatech, ames, rutgers}!ncar!asuvax!stjhmc!ddodell Bitnet: ATW1H @ ASUACAD FidoNet=> 1:114/15 Internet: ddodell@stjhmc.fidonet.org FAX: +1 (602) 451-1165------------------------------Date: Tue, 15 MAY 90 10:55:00 GMTFrom: ZDEE699%elm.cc.kcl.ac.uk@NSFnet-Relay.AC.UKSubject: Enquiry about HDLC chipTo: packet-radio <@NSFnet-Relay.AC.UK:packet-radio@ucsd.edu>Could anyone contact me to send me a data sheet of the HDLC chipmost commonly used, which I believe is MITEL (somenumber). Or couldanyone help me in contacting this company to get hold of a data sheetabout this chip ? Thanks,Olivier Crepin-Leblond, Computer Systems & Electronics Eng.,Electrical & Electronic Eng., King's College London, UK.ARPA/INTERNET: <zdee699%elm.cc.kcl.ac.uk@nsfnet-relay.ac.uk>BITNET: <zdee699@elm.cc.kcl.ac.uk>------------------------------Date: 14 May 90 16:06:04 GMTFrom: brian@ucsd.edu (Brian Kantor)Subject: NOS and ax.25/NetRom timingTo: packet-radio@ucsd.eduSome factors to consider:1) It's unusual for KISS TNCs to sense RF carrier at 1200 bps. Theyusually listen for data carrier, and if you're running a squelched FMradio, they may take far to long to do that. You should have a decentcarrier detect circuit. Of the 1200 bps standalone TNCs on the market,ONLY the MFJ1278 does, as far as I know. You can add it to all therest - mod kits are available from TAPR for $11 to $20 or so. Makes aBIG improvement in performance.*2) Even if your TNC does sense carrier well, it can't report it to thesoftware, so all the collision avoidance is done in the KISS codeinside the TNC and not in NOS.3) If the TNC is in full duplex, it will transmit even if it's hearingdata carrier.4) If there are more than two stations (including yourself) active ona channel, EVERYONE should be running with MAXFRAMES=1. Otherwise acollision wastes a gross amount of time.*In some recent tests here, I found that I typically had to have TXDset around 15 to 30 to reliably send my packets whilst receiving withan unmodified TNC on a squelched radio. Modifying the rx TNC todetect data instead of energy as carrier allowed me to leave thesquelch blowing; I could then use TXD on the order of 6 to 8. Withshort packets, that can more than double throughput. Not bad for $11and an hour's work. - Brian------------------------------Date: 14 May 90 20:29:49 GMTFrom: swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali!rp i!uupsi!sunic!tut!ousrvr!news@ucsd.edu (Ari Husa OH8NUP)Subject: NOS and ax.25/NetRom timingTo: packet-radio@ucsd.eduIn article <13653@ucsd.Edu> brian@ucsd.Edu (Brian Kantor) writes:> radio, they may take far to long to do that. You should have a decent> carrier detect circuit. Of the 1200 bps standalone TNCs on the market,> ONLY the MFJ1278 does, as far as I know. You can add it to all theIs the MFJ1278 'TAPR firmware compatible'? What is the price? Luru------------------------------End of Packet-Radio Digest******************************Date: Wed, 16 May 90 04:00:02 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #29To: packet-radioPacket-Radio Digest Wed, 16 May 90 Volume 90 : Issue 29Today's Topics: Beginner's Guide to TCP/IP Gel/Cell battery NOS and ax.25/NetRom timing (2 msgs)Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 15 May 90 23:00:27 GMTFrom: iris!ford@ucdavis.ucdavis.edu (Gary Ford)Subject: Beginner's Guide to TCP/IPTo: packet-radio@ucsd.eduI have written a document entitled "Beginner's Guide to TCP/IP on theAmateur Packet Radio Network Using the KA9Q Internet Software." This44 page guide documents the use of NET v890421.1 and BM v3.3.1 on anIBM PC or clone with a serial interface to a TNC running the KISSfirmware.The guide is available by anonymous ftp from clover.ucdavis.edu[128.120.57.1] as the 113K ASCII file "begin.doc" in the directory/pub/ka9q. Comments and suggestions for change to the document arewelcome.I'm sure someone will ask why the guide documents NET now that NOS isavailable. The main reason is that NET is most commonly in use in myarea. When I helped to set up a TCP/IP switch, the users needed abetter manual, so I took a shot at writing one. My next project is toattempt to port NOS to my Sys5 (actually HP-UX) machine, using AndersKlemets porting kit. If I have success, I'll edit the guide to coverNOS. Gary Ford, N6GF------------------------------Date: 16 May 90 00:52:31 GMTFrom: hercules!fernwood!portal!cup.portal.com!John_A_Pham@apple.comSubj ect: Gel/Cell batteryTo: packet-radio@ucsd.eduI have a few Gel/Cell rechargeable batteries that I want to use. My questionis what is the standard recharge voltage specs for these units? The battery hasonly the following marking: Globe Battery Division Gel/Cell rechargeable battery GC680 6 volt 7.5 Amp Hr A list of book references on battery would be welcome.John------------------------------Date: 15 May 90 23:14:24 GMTFrom: swrinde!zaphod.mps.ohio-state.edu!wuarchive!texbell!nuchat!splut! jay@ucsd.edu (Jay "you ignorant splut!" Maynard)Subject: NOS and ax.25/NetRom timingTo: packet-radio@ucsd.eduIn article <13653@ucsd.Edu> brian@ucsd.Edu (Brian Kantor) writes:>You should have a decent>carrier detect circuit. Of the 1200 bps standalone TNCs on the market,>ONLY the MFJ1278 does, as far as I know. You can add it to all the>rest - mod kits are available from TAPR for $11 to $20 or so. Makes a>BIG improvement in performance.*What constitutes a decent carrier detect circuit? What should I look foron the schematic of my shiny new PK-88? Should I even bother looking? Ifit doesn't have one, can TAPR help?Actually, now that I think of it, the instructions in the book are toopen the squelch and set the volume where the DCD light just comes onsolid...which sounds like a not-decent carrier detect. :-(-- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which canjay@splut.conmicro.com (eieio)| adequately be explained by stupidity.attctc, RIP. It was nice knowing ya +---------------------------------------- "Flying is a lot more fun than being in the Senate." -- Senator Jake Garn------------------------------Date: 15 May 90 23:50:08 GMTFrom: hpcc01!col!bdale@hplabs.hp.com (Bdale Garbee)Subject: NOS and ax.25/NetRom timingTo: packet-radio@ucsd.edu>> radio, they may take far to long to do that. You should have a decent>> carrier detect circuit. Of the 1200 bps standalone TNCs on the market,>> ONLY the MFJ1278 does, as far as I know. You can add it to all the>>Is the MFJ1278 'TAPR firmware compatible'? What is the price?No. It is a bit different from your run of the mill TNC-2 clone...Bdale------------------------------End of Packet-Radio Digest******************************Date: Thu, 17 May 90 04:00:03 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #30To: packet-radioPacket-Radio Digest Thu, 17 May 90 Volume 90 : Issue 30Today's Topics: Atari Portfolio on Packet Commercially-available data radios DSP Book References FLEA at MIT This Sunday May 20 Cambridge MA Gel/Cell battery (3 msgs) NOS and ax.25/NetRom timingSend Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 16 May 90 16:48:31 GMTFrom: pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!xant h!mka@tut.cis.ohio-state.edu (Mark K Arquette)Subject: Atari Portfolio on PacketTo: packet-radio@ucsd.eduWell I have gotten a few responses from people on possible cures for myinterference problems. For those who haven't seen this, I am trying to useand Atari portfolio on packet radio with a Kenwood HT. The portfolio causesa whine right at 145.01 Mhz (also at 223.40 Mhz on another Kenwood HT). I have confirmed that it is a radiated interference, it is not being transmittedthrough any of the cables. It is quite strong and does not diminish very wellwith distance (I put the antenna across the room and the signal seemed louder!).I think I need some sort of sheilding on the Portfolio but I am not sure that iseven feasible. I think I heard of some sort of conductive spray that might workbut I don't have any particulars, any ideas?For the people who inquired about my setup, I am using the Portfolio as aterminal running Xterm2 by Jim Straus. This is a terminal program for the Portfolio that supports xmodem and ascii transfers and programable functionkey strings. It is quite nice and still less than 3k in size. I have been looking for something geared more towards packet (like yapp or pakcom (?)) butmost of what I have found is too big (30-60k will work but is too big justfor a few little features) It looks like I may have to do it myself.Well thanks for any info/help you may have.Pete Borders WB4TKA (just using a friend's account)P.S. Our mailer can't get through to pr@NFSnet-Relay.AC.UK so if Peter Robinsonwants to supply an alternate route let me know.------------------------------Date: 16 May 90 18:01 -0700From: Doug Collinge VE7GNU <djc@samisen@uvicctr.uvic.ca>Subject: Commercially-available data radiosTo: packet-radio@ucsd.edu, tcp-group@ucsd.edu>X-Mailer: Mush 6.5.6 (PC R6.3 22-Sep-89)I have been on the phone calling every company I could think of askingabout 9600 baud packet radio. Here are the results:PacComm: no longer in the picture. They have withdrawn their earlierNB9600 series and its successor is nowhere near production. "Six months,maybe?" was the answer. That probably means never. Their G3RUH modemis still available, however, and plugs right into their own TNCs andTNC2 clones.Kantronics: paydirt! The DVR2-2 (144MHz, 2W) works with the G3RUH modemat 9600 baud. Lists for $239US. Compatible with a 30W power amp fromRF Concepts, list $129US. The whole thing is tested and works with aTXD of 4 (40 ms). All shipping now. The 440MHz version of theKantronics DVR2-2 is not yet available. They expect to ship inmid-July. I don't have any idea how reliable this estimate might be. The Data Engine is shipping now, so there's something.TAPR: the PacketRadio is still in neverland. Betatest has not started.Someone has the flu or maybe something more awful. They plan to offerit as a kit and also license it to commercial outfits. They figure thekit will be out in September but I really doubt that - their estimateshave been very optimistic on this project so far. But I don't think itis fair to call it the "VapourRadio" (as funny as it is) consideringthat they showed the boards at Dayton.AEA: nothing. The only data RF product they had has been cancelled andthere is nothing up their sleeve. The PS186 data switch platform isin neverland. "You mean it's waiting for someone to make up his mind?""Something like that." You know what they say: "Confused minds say No."DRSI: The guy at DRSI told me that they are thinking about making a 4Wdata radio for the Amateur market which would be similar to thecommercial ones they have made. Committed to the idea but noparticular date in mind right now. A high-speed modem is currently ahigher priority for some reason.MFJ: - I didn't call cause I don't think they have anything and I wasgetting discouraged at this point.BOTTOM LINE: There is no commercial 440MHz data radio available now.There are also none in the works, except for the Kantronics, Real SoonNow. The cost of the Kantronics is not known but will certainly behigher than the DVR2-2 at $239US. It probably also comes uncrystalled.Now if any of you can suggest anyone else who sells data radios, or kits,or ANYTHING, please shoot me a note and I will update this list andrepost. 73 doug.-- /\/\/\/\/\/Doug Collinge, first try: collinge@uvicctr.uvic.ca then try: samisen!djc@uvicctr.uvic.caVE7GNU VE7GNU@VE7GNU.#VIC.BC.CA.NA V ictoria, BC, Canada------------------------------Date: 15 May 90 20:53:02 GMTFrom: ndsuvm1.bitnet!mn007334@cunyvm.cuny.eduSubject: DSP Book ReferencesTo: packet-radio@ucsd.edu A while back, someone posted a list of good DSP books. If anyone stillhas this list, could they please send me a copy? Many Thanks in advance!!!Todd Enders arpa: mn007334@vm1.nodak.eduMinot State Univ. bitnet mn007334@ndsuvm1Minot, ND 58701------------------------------Date: 17 May 90 00:31:02 GMTFrom: w1gsl@bloom-beacon.mit.edu (Steven L. Finberg)Subject: FLEA at MIT This Sunday May 20 Cambridge MATo: packet-radio@ucsd.eduJust a reminder it's this weekend...The Flea at MIT will now be held monthly through the summeron the third Sunday of each month April through September.***** 50 cent buyers discount with hardcopy of this notice ********COMPUTERS - ELECTRONICS - HAM RADIO - COMPUTERS - ELECTRONICS SPRING FLEA AT MIT Sunday, May 20, 1989 9AM-2PMCome to the city for a great flea - plenty of free parking. MIT's electronics and ham radio flea will take place on the third Sunday of each month this summer. There is tailgate space for over 200 sellers and free, off-street parking for >1000 cars! Buyers admission is $1.50 (you get 50c off if you're lucky enough to have a copy of our add) and sellers spaces are $8.00-each at the gate or $5.00 if mailed by the preceding 5th. The flea will be held at the corner of Albany and Main streets in Cambridge; right in the Kendall Square area from 9AM to 2PM, with sellers set-up time starting at 7AM. !! RAIN or SHINE !! Have no fear of rain, a covered tailgate area is available for all sellers (6'8" clearance). Talk-in: 146.52 and W1XM/R-449.725/444.725 (PL 114.8/2A). Sponsors: MIT Electronics Research Society MIT UHF Repeater Association (W1XM) MIT Radio Society (W1MX) For more info / advanced reservations 617 253 3776******** 50 cent buyers discount with hard copy of this notice ************------------------------------Date: 16 May 90 13:52:46 GMTFrom: swrinde!cs.utexas.edu!news-server.csri.toronto.edu!smoke.cs.toron to.edu!neat.cs.toronto.edu!enenkel@ucsd.edu (Robert Frederick Enenkel)Subject: Gel/Cell batteryTo: packet-radio@ucsd.eduIn article <29930@cup.portal.com> John_A_Pham@cup.portal.com writes:>[wants charge specs for]>> Globe Battery Division> Gel/Cell rechargeable battery> GC680 6 volt 7.5 Amp Hr> My Electrosonic catalogue lists the 20 hour charge rate as 375 mA andthe 1 hour rate as 4.1 A. This is (I believe) for constant currentcharging, which is how I charge mine. For constant applied voltage,the initial rate is approximately 3 times the rates given above, andwill taper off as the charging progresses. Robert.------------------------------Date: 16 May 90 19:16:04 GMTFrom: amdcad.amd.com!pepsi!phil@sun.com (Phil Ngai)Subject: Gel/Cell batteryTo: packet-radio@ucsd.eduIn article <29930@cup.portal.com> John_A_Pham@cup.portal.com writes:| Globe Battery Division| Gel/Cell rechargeable battery| GC680 6 volt 7.5 Amp HrHere are some numbers I have. Both have been happy to send metechnical information. (f means fax) (I haven't includedthat stupid 1 in front of the numbers, I assume anyonecapable of operating a telephone understands how that works.)Panasonic Batteries, Ted Williams, 408 946 7481, 408 946 3753Panasonic Battery Sales, 714 373 7538, 892 8552fYuasa, 800 423 4667 (not in CA) 213 949 4266, 800 962 1287--Phil Ngai, phil@amd.com {uunet,decwrl,ucbvax}!amdcad!philAnother NRA extremist.------------------------------Date: 16 May 90 21:00:56 GMTFrom: hpcc01!hpccc!wille@hplabs.hp.com (Ross Wille)Subject: Gel/Cell batteryTo: packet-radio@ucsd.edu/ hpccc:rec.ham-radio.packet / enenkel@cs.toronto.edu (Robert Frederick Enenkel) / 6:52 am May 16, 1990 /> In article <29930@cup.portal.com> John_A_Pham@cup.portal.com writes:> >[wants charge specs for]> >> > Globe Battery Division> > Gel/Cell rechargeable battery> > GC680 6 volt 7.5 Amp Hr> > > My Electrosonic catalogue lists the 20 hour charge rate as 375 mA and> the 1 hour rate as 4.1 A. This is (I believe) for constant current ^^^^^^^^^^^^^^^^^^^^> charging, which is how I charge mine. For constant applied voltage,> the initial rate is approximately 3 times the rates given above, and> will taper off as the charging progresses. Robert.> ----------> You can't expect to charge a 7.5 AH battery with 4.1 A for 1 hr... (4.1A * 1.0hr = 4.1AH < 7.5AH)For constant current charging, try charging with a current of 0.1 theAH rating of the battery (in this case 3/4 Amp). Ideally it would take10 hours to fully charge your battery. Batteries are not 100% efficientin storing the charge energy (some is wasted in heating the battery) soyou should charge it a little longer, like 11 hours rather than 10. Don'tleave it on the charger.For constant voltage charging (which is what I do) use a voltage of 2.3Vper cell. Your 6 volt battery has 3 cells in it, so 2.3 * 3 = 6.9V.Use an accurate digital voltmeter to measure this and don't exceed thisvoltage. It is better to be a little lower than a little over. Overvoltage will destroy the battery over time. Under voltage will only causeyour battery to be less than 100% charged. You can maintain a constant-voltage charge indefinitely (called a "float charge").There was a good series of articles (three of them) in consecutive issuesof QST magazine (Jan, Feb, Mar 1990 I believe) regarding the use of lead-acidbatteries. Much of the information was directly applicable to gel cells(which are a type of lead-acid battery).There are circuits that will charge your battery quickly at first thenswitch over to a maintaince float charge to keep it fully charged, but Iwon't get into that... just so you know.73,Ross Wille - N6SJDwille@hpda.hp.com------------------------------Date: 16 May 90 16:53:00 GMTFrom: swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cs o.uiuc.edu!m.cs.uiuc.edu!kenny@ucsd.eduSubject: NOS and ax.25/NetRom timingTo: packet-radio@ucsd.eduJay Maynard writes:>What constitutes a decent carrier detect circuit? What should I look for>on the schematic of my shiny new PK-88? Should I even bother looking? If>it doesn't have one, can TAPR help?If I'm designing my own TNC, what should I do for carrier detection?Is a phaselock detector on the PLL that discriminates the tones anadequate data-carrier-detect function, or do I need something else,like maybe a combination of phaselock and a particular AGC level?Kevin, KE9TVkenny@cs.uiuc.edu------------------------------End of Packet-Radio Digest******************************Date: Fri, 18 May 90 04:00:03 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #31To: packet-radioPacket-Radio Digest Fri, 18 May 90 Volume 90 : Issue 31Today's Topics: Atari Portfolio on Packet Commercially-available data radios KA9Q for Atari Kantronics Packet Communicator II Packet-Radio Digest V1 #30Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 17 May 90 15:24:34 GMTFrom: swrinde!zaphod.mps.ohio-state.edu!mips!prls!philabs!briar!rfc@ucs d.edu (Robert Casey)Subject: Atari Portfolio on PacketTo: packet-radio@ucsd.eduI'm not familiar with the Atari Portfolio computer, but maybe you could findits crystal oscillator clock and move it a few KHz. Assuming that you can getat the actual xtal (that it's not a sealed rectangular can that includes theoscillator ckt), try putting a small (about 5pF) cap across the xtal. Thismight pull the harmonic off the freq of interest, and ruin reception on someother freq! If it is a sealed module, maybe replace it with one with a freq afraction of a % higher or lower. Watch out that you don't adversely impact some critical timing, like a modem circuit. **This is not a high quality fix, as all you're doing is pushing your RFI toanother frequency. But if you just want to operate the one frequency, and youdon't have any neighbors into radio, you could get away with this.>>best is to eliminate the RFI, if you can.Hope this helps WA2ISE========================================================== ===================A notice found on a piece of test equipment made in Japan:"IT PUT ON THE VINYL SHEET ON THE SURFACE OF UPPER & LOWER PANEL FOR THEPROTECTION PLEASE USE AFTER TEAR OFF VINYL SHEET WHEN USING.------------------------------Date: 17 May 90 11:12:50 GMTFrom: mintaka!ogicse!emory!kd4nc!ke4zv@think.com (Gary Coffman)Subject: Commercially-available data radiosTo: packet-radio@ucsd.eduIn article <26518126.samisen@samisen@uvicctr.uvic.ca> collinge@uvicctr.uvic.ca writes:>>Now if any of you can suggest anyone else who sells data radios, or kits,>or ANYTHING, please shoot me a note and I will update this list and>repost. >Under the catagory of ANYTHING -), don't forget the Grapes 56k RF modem.It is both the modem and the radio and you CAN throttle it back to 9600baud if you insist.-)On the topic of G3RUH 9600 baud modems, I have two and they work finewith MODIFIED, CRYSTAL controlled commercial radios (GE). They are notplug-and-play and they WON'T work with SYNTHESIZED radios. It seems thePLL in the radio nulls out some of the spectral energy of the modem thatfalls within the passband of the loop filter.-(73 Gary KE4ZV------------------------------Date: 18 May 90 04:35:35 GMTFrom: uhccux!querubin@ames.arc.nasa.gov (Antonio Querubin)Subject: KA9Q for AtariTo: packet-radio@ucsd.eduAnyone know where I can find an Atari version of KA9Q?AH6BWInternet: antonio_querubin-manoa@uhplato.uhcc.hawaii.eduBITnet: antonio_querubin-manoa@uhplato------------------------------Date: 17 May 90 13:15:15 GMTFrom: ogicse!emory!ducvax.auburn.edu@ucsd.edu (THOMAS_JONI)Subject: Kantronics Packet Communicator IITo: packet-radio@ucsd.eduI am interested in purchasing the KPC-2. Can some of you who use thismodem provide some feedback? Also, any of you who have other preferenceswith similar features, I would appreciate hearing your opinions. Please send e-mail to me, and I will summarize and post the results. Thanks!Mark Hall Internet==> MHall@Ducvax.Auburn.Edu------------------------------Date: Thu, 17 May 90 16:09 NFrom: Urs Baer <BWLLIBMOD%CSGHSG5A.BITNET@CORNELLC.cit.cornell.edu>Subject: Packet-Radio Digest V1 #30To: Packet-Radio@UCSD.Eduplease remove my old adress 87674800s at csghsg5a (bitnet) from the list.------------------------------End of Packet-Radio Digest******************************Date: Sat, 19 May 90 04:00:03 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #32To: packet-radioPacket-Radio Digest Sat, 19 May 90 Volume 90 : Issue 32Today's Topics: 9600 baud modems Atari Portfolio on Packet (2 msgs) Kantronics KPC-2 NOS/NET Unix (2 msgs) NOS and ax.25/NetRom timing Quote without commentSend Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 18 May 90 04:29:41 GMTFrom: pilchuck!algedi!kenk@uunet.uu.net (Ken Koster (N7IPB))Subject: 9600 baud modemsTo: packet-radio@ucsd.eduAs part of a planned upgrade to the local network we are in the process ofevaluating the performance of the various 9600 baud modems. We would appreciatehearing from anyone using any of the available modems. While measured performancewould be the most valuable, even subjective comments would be welcomed.Information on their performance in regenerative repeater applications would beparticularly welcome.As usual please EMAIL your responses to me and I will summarize for the net.Thanks--Ken Koster (N7IPB) algedi!kenk@pilchuck.Data-IO.COM or12653 NE 95th ...uunet!pilchuck!algedi!kenkKirkland,Wa 98033 Packet: n7ipb@kd7nm------------------------------Date: 18 May 90 15:00:47 GMTFrom: hpl-opus!hpnmdla!glenne@hplabs.hp.com (Glenn Elmore)Subject: Atari Portfolio on PacketTo: packet-radio@ucsd.edu> even feasible.I think I heard of some sort of conductive spray that might work> but I don't have any particulars, any ideas?You might consider Miller-Stephenson "MilShield" Conductive coating,part number MS485 is an aerosol can. Applied as instructed they claimit gives surface resistivity of half an ohm/square. I think a cancosts around $6 or so but I make no claim for the product other than thatI have used it in the past (coated a homebrew fiberglass parabola with itand it worked fine through 10 GHz).Miller-Stephenson Chemical Company IncCorp. Hdqrtrs Danbury, COnnecticut 0681012261 Foothill BoulevardSylmar California 6348 Oakton StreetMorton Grove, Illinois514 Carlingview DriveRexdale, OntarioCanadaI suppose the aerosol is full of CFCs.....Glenn Elmore -N6GN-N6GN @ K3MC glenn@n6gn.ampr.orgglenne@hpnmd.hp.com ------------------------------Date: 18 May 90 03:25:23 GMTFrom: sun-barr!newstop!texsun!texbell!uudell!helps!bongo!xyzoom!rob@app le.com (Rob Lingelbach)Subject: Atari Portfolio on PacketTo: packet-radio@ucsd.eduIn article <12535@xanth.cs.odu.edu> you write:>>even feasible. I think I heard of some sort of conductive spray that might work>but I don't have any particulars, any ideas?>>Pete Borders WB4TKA (just using a friend's account)------------------------------Date: 18 May 90 20:56:12 GMTFrom: swrinde!emory!ducvax.auburn.edu@ucsd.edu (Mark Hall)Subject: Kantronics KPC-2To: packet-radio@ucsd.eduI am interested in purchasing the Kantronics Packet Communicator II (KPC-2).Does anyone have any advice, horror stories, or love stories they would like to share concerning this piece of hardware? Does anyone have another favoritethey would like to tell me about? I am open to suggestions and any assistanceI can get! (My first packet set-up) Thanks in advance for any assistance.Mark Hall Internet ==> MHall@Ducvax.Auburn.Edu Ma Bell ==> 205/844-9185------------------------------Date: 18 May 90 17:12:19 GMTFrom: van-bc!ubc-cs!nebulus!dennis@ucbvax.Berkeley.EDU (Dennis S. Breckenridge)Subject: NOS/NET UnixTo: packet-radio@ucsd.eduI have been looking for a newer version of NOS or NETfor Unix. The version I have for NET us 890421.1a (unix)Several things are broke, TELNETD, the mail box goo. I have fixed some of the bugs with it but it still hangs on a msgsnd() every no and then. Can someone outthere let me know the IP address of the host that isthe keeper of the currrent NOS/NET Unix bits. I am also looking for a local site to feed me the tcp-groupmailing list either via news or standard mail. If you canhelp me out please call me at 277-7413 after business hoursThank you!-- ----------------------------------------------------------------- ------------Dennis S. Breckenridge (604) 277-7413 dennis@nebulus.uucp VE7TCP Still brain dead after all these years :-) ----------------------------------------------------------------- ------------------------------------------Date: 19 May 90 08:05:28 GMTFrom: brutus.cs.uiuc.edu!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!e mv@apple.com (Edward Vielmetti)Subject: NOS/NET UnixTo: packet-radio@ucsd.eduthe home of unix for nos is sics.se [192.16.123.90] but it is aslow ftp from here. from a recent posting to tcp-group:From: klemets@sics.se> What are the various Unix versions of NOS? Where are they?You will find them at sics.se in the directory archive/packet/ka9q/nos.The archive nosunix.tar.Z contains files for BSD UNIX that have beentested on Sun-3's with SunOS 4.0 and NeXT's. It also contains fileswhich I have been using for UNIX System V release 3. These may beslightly out of date however.The archive lwpnos.tar.Z contains files for the Sun-4 (e.g. SparcStation.)The files will also work on any other machine that uses SunOS 4.0,such as Sun-3's.If you run NOS like this on a BSD system you can make it talk to thenative IP code using Julian Onions "Tunnel driver". This driver isinstalled in the kernel and allows you to route IP datagrams betweenthe kernel and a process in user space (e.g. NOS.) If you are onpacket radio, this is an excellent way of making your BSD systemavailable on the radio channel. It is definitely much cheaper thanbuying a PC to use as a dedicated router, as some may suggest.The version of the Tunnel driver that I was using had a bug in it,that had to be fixed. This bug may have been fixed in later versions,but to be on the safe side you should consider using my correctedversion of the Tunnel driver, which is in tundrvr.tar.Z.The AX.25 STREAMS module for SunOS 4.0 and UNIX System V is instreams.tar. I am still seeking for volunteers who would like to turnthis into something useful. The idea is, as presented in the ARRL CNCpaper, to build a stack of protocol modules on top of this module.I began writing ARP and IP modules. One would put a TCP STREAMSdriver on top of them. In user space there would be a couple ofroutines that mimic the BSD socket interface using the STREAMS driver.The archive netnix.tar.Z contains my special version of NOS that takesadvantage of the multitasking in UNIX. It implements a client-servermodel with the protocol stack in user space, using semaphores andshared memory. It will work on machines with SunOS 4.0 and on UNIXSystem V.The NETNIX files have just recently been updated thanks to ScottBertilson. He corrected a couple of bugs, such as a problem with thesemaphores that would cause erratic behaviour under some circumstances.I had been puzzled for quite some time by this bug. He also modified theserial port driver so that it would be more efficient.Users of NETNIX are therefore encouraged to upgrade to the latestversion.The NETNIX distribution is self-contained. That is, you are notsupposed to merge the files with a recent version of src.arc as withthe other UNIX versions of NOS.Good luck, Anders (SM0RGV)--EdEdward Vielmetti, U of Michigan math dept.emv@math.lsa.umich.edu------------------------------Date: 14 May 90 20:18:37 GMTFrom: agate!shelby!portia.stanford.edu!jessica.stanford.edu!paulf@ucbva x.Berkeley.EDU (Paul Flaherty)Subject: NOS and ax.25/NetRom timingTo: packet-radio@ucsd.edu> While they probably should, remember that not everybody has been> ordained in the Holy Church of Karn's Packet Operating Technique, and> investigate the problem a little further.E Yea Yea Et Dominae,E Yea Yea Et Requiem....>BONK< -- Mothy Python and The Holy GrailThat recommendation can be found in nearly any good networkingreference. Perhaps we should replacethe CW requirement with readings from the Tome of Internet Hacking?-=Paul Flaherty, N9FZX/VK2WYX | "Unix could use a more user-friendly front->paulf@shasta.Stanford.EDU | end. Does anyone have a card punch handy?"------------------------------Date: 19 May 90 05:39:20 GMTFrom: ka9q.bellcore.com!karn@bellcore.com (Phil Karn)Subject: Quote without commentTo: packet-radio@ucsd.eduAdvertisement in the October 7, 1989 issue of the British magazine"New Scientist", page 15:"The International Organization for Standardization (ISO) is seeking, for itsnew project based on OSI LAN with distributed environment including serversand VM and VMS hosts (PC or PS/2 user terminals), an experienced NETWORK SYSTEMS SPECIALIST familiar with the hardware/software aspects of LAN, network management andoperating systems, terminal emulation and host coupling, OSI protocolsINCLUDING TCP/IP [my emphasis - Phil], X.400 and X.25, to be responsiblefor overall implementation of the network system. Please apply with cv toISO Personnel Services, Case postale 56, CH-1211 Geneva 20, Switzerland." --Phil ------------------------------Date: (null)From: (null)Advantages:MS-485 is a black coating which may be applied in a 2 mil layer to absorb RFI/EMI over a broad frequency range. It dries in approximately15 minutes and is functional within minutes of application.Safety:Low order of toxicityDoes not attack plastic, rubber or metalsThe above two paragraphs are verbatim from the can...I do not havepersonal experience with the product.Miller-Stephenson's corporate offices are in Danbury, CT.-- Rob Lingelbach internet: rob@xyzoom.info.com Compuserve: 71101,176packet radio: KB6CUN@K6IYK.#SOCAL.CA.USA.NA amprnet: [44.16.0.106]voice: 213 464-6266 xyzoom: 213 464-4281 2641 Rinconia Dr Los Angeles, CA 90068------------------------------End of Packet-Radio Digest******************************Date: Sun, 20 May 90 04:00:02 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #33To: packet-radioPacket-Radio Digest Sun, 20 May 90 Volume 90 : Issue 33Today's Topics: Looking for multiport tnc? (2 msgs)Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 19 May 90 22:00:23 GMTFrom: icom!icom.icom.com!kevin@uunet.uu.net (Kevin Gilmore)Subject: Looking for multiport tnc?To: packet-radio@ucsd.edu I have a unix box at home with many ports. I have a 50 wattkenwood 2 meter unit with an antenna 70 feet high. I want to run a multi user Bbs. Any one know of a TNC that allows multiconnect withonly one radio?Please reply via email as I do not usually read this news group. Kevin Gilmore, N9EDA kevin@icom.icom.com uunet!icom!kevin------------------- -----------Date: 20 May 90 03:50:43 GMTFrom: brian@ucsd.edu (Brian Kantor)Subject: Looking for multiport tnc?To: packet-radio@ucsd.eduActually, MOST of the commercial TNCs offer multi-connect capability,but not as you perhaps envision, with lots of serial ports.What you can do is to put them in multiconnect transparent mode, anddemultiplex the incoming streams yourself. For example, in the MFJ1270,you can tell the software USERS=10, CONM TRANS, and STREAMDOUBLE. Theneach separate connections will be preceded by a two-character flagsuch as |A or |J or whatever. Your software can then split these upinto separate streams, and prefix the responses with the appropriatestream switch characters to direct output back to same user.I've been thinking of cobbling up something like this with a BSD Unixpseudo-tty interface (like the 'uw' package) so that up to 10 userscould have pseudo-ports on a single serial port on my workstation usingonly one tnc and radio. Haven't done it yet, but it seems feasible. - Brian------------------------------End of Packet-Radio Digest******************************Date: Mon, 21 May 90 04:00:03 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #34To: packet-radioPacket-Radio Digest Mon, 21 May 90 Volume 90 : Issue 34Today's Topics: Death of WET NET Gel/Cell battery Kantronics Data Engine Mod file: Uniden 2510 AGC speed mod for packet NOS 0418 won't xmit NOS Files (2 msgs)Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 20 May 90 15:40:00 EDTFrom: "SWEIGERT, DAVID" <dsweigert@paxrv-nes.navy.mil>Subject: Death of WET NETTo: "packet-radio" <packet-radio@WSMR-SIMTEL20.ARMY.MIL>Well, looks like the US Navy is going to drag it's feet on packet radio.Test slated for this summer will most likely be cancelled. Sooo, my company has advised me of impending lay-off. If anyone here (hears)of a potiential job site, let me know. Thanks.=========DAVID G. SWEIGERT R E S U M EB4 Perry Circle Phone: (301) 637-5098 (day) SECRET ClearanceAnnapolis, MD 21403OBJECTIVE A position where extensive experience, education, and capabilities in the areas of Systems Analysis, Network Design, Documentation, Interface Modules, and Software Engineering would have valuable applications. SUMMARY OF QUALIFICATIONS EXPERIENCE Ten years of direct experience encompassing the following areas: SENIOR NETWORK ANALYST: Responsible for the design, development and implementation of computer networking systems . . Developed designs and documented requirements with use of long-haul and local area networks and management tools . . . UNIX appliactions, NFS, TCP/IP, X.25, Ethernet, Token Ring, Protocol Conversion . . . Software QA and Configuration Management . . . and experienced in system level testing on mainframe, minicomputers and microcomputers platforms. HARDWARE: ATT 3B2. . .3Com. . .Sun Workstations . . .MicroVAX . . . IEEE 802.X. . .Novell. . .PCs' 286 and 386 . . . Tandem NonStop II. . .DEC Vax 8350. . Concurrent Computer Corp 3256/60. . .Sperry 1100/60. SOFTWARE: X.25. . .UNIX (Sun/OS, Berkeley, C-Shell, Bourne Shell) . . .ASYNC. . . MSDOS/PCDOS. . . SCO Xenix. . .TCP/IP. . .VMS LANGUAGES: C . . . SQL (ORACLE) . . ASSEMBLEREDUCATION Florida Institue of Technology, Masters Business Administration candidate, night school at Andrews AFB, MD. Program Management, Budgets, Contract Law. Texas A & M University system, Bachelor of Business Administration, Information SystemsDAVID SWEIGERT -2- R E S U M EEMPLOYMENT BACKGROUND1989 to Present DAEDALEAN, Inc. (DAI), Columbia, Maryland PROJECT ENGINEER/PROGRAM MANAGER: Responsible the design and implementation of Santa Crux Operation Xenix application for the 386 environment to move data files from shipboard Honeywell DPS-6 via commercial dial- up satellite channel (INMARSAT) to shore based counterpart. Technical Project Leader responsible for providing direction of 2 software engineers for the design and coding of small scale software project. Activities include software design and development software requirements, design and documenta{ion, updating, documenting, maintaining and conversion of existing software. Determined system specifications. System and Unit level testing of the existing systems. Worked from specification to improve efficiency of the system. Researched data for conversion to new the system. 1988 to 1989 TRW Information Netwoetc..etc..------------------------------Date: 18 May 90 05:08:54 GMTFrom: voder!pyramid!leadsv!practic!vlsisj!davidc@ucbvax.Berkeley.EDU (David Chapman)Subject: Gel/Cell batteryTo: packet-radio@ucsd.eduIn article <90May16.095209edt.1649@smoke.cs.toronto.edu> enenkel@cs.toronto.edu (Robert Frederick Enenkel) writes:|In article <29930@cup.portal.com> John_A_Pham@cup.portal.com writes:|>[wants charge specs for]|> Globe Battery Division|> Gel/Cell rechargeable battery|> GC680 6 volt 7.5 Amp Hr|My Electrosonic catalogue lists the 20 hour charge rate as 375 mA and|the 1 hour rate as 4.1 A. This is (I believe) for constant current|charging, which is how I charge mine.For best lifetime, charge at about a 10% rate (e.g. 750 mA here) or less.Otherwise the cells will overheat and dry out.-- David Chapman{known world}!decwrl!vlsisj!fndry!davidcvlsisj!fndry!davidc@decwrl.dec.c om------------------------------Date: 21 May 90 05:54:00 GMTFrom: zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1 .cso.uiuc.edu!phil@tut.cis.ohio-state.eduSubject: Kantronics Data EngineTo: packet-radio@ucsd.eduI just saw an ad for the Kantronics "Data Engine" TNC(?) in the June issueof QST (surprise, I am a member of ARRL). I certainly do intend to call upKantronics and ask them all about it, but I'd like to find out what peoplehere know about this thing. Can someone who might happen to know more pleasepost what they can? One thing I did notice is that they claim this has an"open architecture" and a "developers technical reference" of some sort.I tend to disbelieve, so I will have to see it to believe it that this thingis going to be an easy platform to develop new ROM code for. We'll see.--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society<phil@ux1.cso.uiuc.edu> | no matter what the particular issue is all about.------------------------------Date: 19 May 90 04:02:23 GMTFrom: philmtl!philabs!briar!rfc@uunet.uu.net (Robert Casey)Subject: Mod file: Uniden 2510 AGC speed mod for packetTo: packet-radio@ucsd.educopied from packet: Msg# TSF Size #Rd Date/Time MsgID From To26389 BF 1878 1 0508/1111 6894_TI3DJT TI3DJT MODS@NYNET () Sb: speeding up Uniden 2510 AGC For those of you who are using a Uniden 2510 for packet, you can speed up AGC speed considerably, just by removing the AGC SSB switch transistor Q-111 This transistor switches the AGC off for CW operation, and on for SSB operation. All I did was remove it and my radio now works with very good speed on 10m. You may put a switch between the pads that were for collector and ground. When you want slow AGC turn the switch ON pulling line to ground. For fast agc turn switch off leaving line floating. That is all there is to it. The description of the mod for the 2510 may work for the 2600. Those who have the Uniden 2600 may find that the AGC is the same for this radio. Look for NJM2902 IC (this is the AGC amp), you may find a transistor connected thru a RC network, to pin 12 of said ic. Remove also. (this mod not tested!) Ciao de Chuck ti3djt @ ti0paq.cri.na----------------------------------------Note: I haven't tried or verified this, proceed at your own risk! WA2ISE=========================================================== ===============A notice found on a piece of test equipment made in Japan:"IT PUT ON THE VINYL SHEET ON THE SURFACE OF UPPER & LOWER PANEL FOR THEPROTECTION PLEASE USE AFTER TEAR OFF VINYL SHEET WHEN USING.------------------------------Date: 21 May 90 01:04:59 GMTFrom: cs.utexas.edu!asuvax!mcdphx!phx.mcd.mot.com!dlf@tut.cis.ohio-stat e.edu (3726)Subject: NOS 0418 won't xmitTo: packet-radio@ucsd.eduI have been using the 0329 version of NOS for quite awhile here, withoutmuch trouble. After getting the preliminary NOS documentation, Idecided it was time to drop the 0418 version in place and start usingthe current stuff. When I did, I found that the only time my systemwould actually key the transmitter, was on startup of NOS (I would imaginethat the "netrom bcnodes" is what went out). After that, if I do a"finger", "connect", or any other type of connection to another station,the transmitter never gets keyed. The 0329 version, with the sameenvironment works like a charm. The interesting thing is, the AX.25timers are running, and retrys are occurring, even though nothing isactually being transmitted. Eventually, the "connect" attemp times out.My configuration is: - 8088 XT @ 8 Mhz - com2: (8250) - MFJ-1270 TNCAny help? I have the sources and can apply patches. I haven't seen theversion of NOS on "flash" change since 04-18-90.Dave Fritsche (wb8zxu)dlf@phx.mcd.mot.com...!noao!asuvax!mcdphx!dlf------------ ------------------Date: 20 May 90 07:11:13 GMTFrom: mcsun!ukc!slxsys!dircon!uab1017@uunet.uu.netSubject: NOS FilesTo: packet-radio@ucsd.eduHello Folks, I have obtained a copy of NOS_0329 but I have no examples ofthe autoexe and domain files that go with it, could some kind solemail me an example of the format of these. I assume that the auto fileis similar to the previous NET s/w but the Domain file is differentto the hosts file. I previously have only used the ATARI versionsbut now reluctantly have bought a PC clone.Regards Charles G4GUO [44.131.16.14]------------------------------Date: 20 May 90 19:19:31 GMTFrom: ka9q.bellcore.com!karn@bellcore.com (Phil Karn)Subject: NOS FilesTo: packet-radio@ucsd.eduI released a user reference manual for NOS several weeks ago. It can befound on flash.bellcore.com (128.96.32.20) by anonymous FTP. The file nameis /pub/ka9q/userref.nr. This is a nroff/troff source file; it should beprinted with the command "nroff -ms userref.nr" or "troff -ms userref.nr".For those of you without access to nroff, I have placed an nroff'ed versionof this file in "userref.out" in the same directory.Phil------------------------------End of Packet-Radio Digest******************************Date: Tue, 22 May 90 04:00:03 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #35To: packet-radioPacket-Radio Digest Tue, 22 May 90 Volume 90 : Issue 35Today's Topics: 9600 baud modems Full Duplex via Counter-Polarized Antennas Gel/Cell battery (2 msgs) I'm looking for information on high speed packet modems Kantronics Data Engine (2 msgs) Kantronics KPC-2 (2 msgs) NOS 0418 won't xmit tapr tnc-1 (beginner looking for info)Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: Mon, 21 May 90 17:39:29 EDTFrom: mgb@tecnet1.jcte.jcs.milSubject: 9600 baud modemsTo: #packet-radio@tecnet1.jcte.jcs.milHas anyone gotten a G3RUH 9600 baud modem working on any radio on 220 MHz?If so, could you please specify what radio, and any other personal experiencethat you may have had with these modems. I am especially interested in anyreports of problems using them with PLL radios.I am aware that they are a "plug and play" with the new Kantronics DVR units,but Kantronics doesn't make one for 220. In addition, the TAPR packet-RADIOseems to be pretty well bogged down, and their beta test models are nowgoing to be strictly on 2 meters vice both 144 and 220 MHz.Any "hints or kinks" would be MOST appreciated!Thanks for your time.Mark Bitterlichwa3jpy@wb4uoumgb@tecnet1.jcte.jcs.mil------------------ ------------Date: 21 May 90 22:09 -0700From: Doug Collinge VE7GNU <djc@samisen@uvicctr.uvic.ca>Subject: Full Duplex via Counter-Polarized AntennasTo: packet-radio@ucsd.edu, tcp-group@ucsd.edu>X-Mailer: Mush 6.5.6 (PC R6.3 22-Sep-89)I want to make full duplex point-to-point links on 430/439 MHz. I alsowant to avoid using a duplexer. Here is an idea I had:Feed TX to a horizontally-polarized yagi and use a vertically-polarizedyagi mounted on the other end of a boom. How much isolation do I buy?I probably need a balanced matching system for this work at all well solet's assume that I use a toroidal transformer for the balun and aT-match or something like that. Furthermore, I also agree to mount thething symmetrically on the tower.PreS: Numerous replies in answer to my post "Commercial Data Radios"and I will repost soon. Hint: the news is not very good.73 doug-- /\/\/\/\/\/Doug Collinge, first try: collinge@uvicctr.uvic.ca then try: samisen!djc@uvicctr.uvic.caVE7GNU VE7GNU@VE7GNU.#VIC.BC.CAN.NA Victoria, BC, Canada----------------------- -------Date: 21 May 90 15:11:20 GMTFrom: swrinde!cs.utexas.edu!usc!venera.isi.edu!gremlin!nrtc!wdarden@ucs d.edu (Bill Darden <swrinde!cs.utexas.edu!usc!venera.isi.edu!gremlin!nrtc!wdarden@uc sd.edu>)Subject: Gel/Cell batteryTo: packet-radio@ucsd.eduIn article <15574@vlsisj.VLSI.COM> davidc@vlsisj.UUCP (David Chapman) writes:>In article <90May16.095209edt.1649@smoke.cs.toronto.edu> enenkel@cs.toronto.edu (Robert Frederick Enenkel) writes:>|In article <29930@cup.portal.com> John_A_Pham@cup.portal.com writes:>|>[wants charge specs for]>|> Globe Battery Division>|> Gel/Cell rechargeable battery>|> GC680 6 volt 7.5 Amp Hr>|My Electrosonic catalogue lists the 20 hour charge rate as 375 mA and>|the 1 hour rate as 4.1 A. This is (I believe) for constant current>|charging, which is how I charge mine.>>For best lifetime, charge at about a 10% rate (e.g. 750 mA here) or less.>Otherwise the cells will overheat and dry out.>-- If you have access to a voltage regulated power supply, adjust it*unloaded* for 2.43 volts per cell for lead acid battaries (or 1.43for nicad's). When the current drops off to a few milliamps, thecells are charged. Adding inexpensive three terminal adjustable regulators to existingcheap "non-regulated current" battary charges will more than pay forthemselves in saving battaries. When the manfacturer wants you notto leave the battary in the charger for more than x hours, you knowthat there is *no* protection and that the charger *will* overchargeyour battary if left in for long periods of time. Good luck,BiLL.....------------------------------Date: 22 May 90 03:53:00 GMTFrom: zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1 .cso.uiuc.edu!phil@tut.cis.ohio-state.eduSubject: Gel/Cell batteryTo: packet-radio@ucsd.edu> If you have access to a voltage regulated power supply, adjust it> *unloaded* for 2.43 volts per cell for lead acid battaries (or 1.43> for nicad's). When the current drops off to a few milliamps, the> cells are charged. Nicads have a phenomena where a constant voltage source can causea thermal runaway condition. Just after full charge, heat beginsto build up in the battery resulting in a decrease in resistance,an increase in current, an in increase in heat, less resistance,more current, etc. You can see smoke, sparks, spraying hydroxides,explosions, etc.Limit your charging current to C/10 where C is the 1 hour capacityfor standard charging and charge for 15-16 hours. Quick chargershave thermal detection circuits or something more sophisticatedto know when to stop charging and drop to trickle charge (C/50).I always slow charge my nicads and frequently leave them chargingfor 24, 48, and even 72 hours with barely perceptable heating.The charger is current limited by 18 volts through 75 ohms for1200 mah packs. I also run the packs down SLOWLY to virtually0 volts (low current and equal cells is not likely to reversea cell) and have never seen a hint of life shortening in theyear and nearly 100 cycles I have used them.--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society<phil@ux1.cso.uiuc.edu> | no matter what the particular issue is all about.------------------------------Date: 20 May 90 21:02:00 GMTFrom: usc!snorkelwacker!bu.edu!mirror!otto!rex@ucsd.edu (Rex Jolliff)Subject: I'm looking for information on high speed packet modemsTo: packet-radio@ucsd.eduAbout a week ago I posted asking for information on high speed packetmodems. All I got back was a few mail messages from people who werealso interested in information on high speed packet modems.If anyone has information on where to get 56Kbps or 2Mbps modems inany form (plans only, kit form, or built & tested), please mail me orpost the information and I will summarize. I'm interested in themodem hardware, the interface to the computer (PC/386 running Xenix)and software drivers available.Some of my friends and I are planning to setup a TCP/IP network usinghigh speed modems, and we would much appreciate this infomation. Thanx in advance, Rex.-- Rex Jolliff (rex@otto.lvsun.com, {convex, texsun, mirror}!otto!rex)The Sun Newspaper - |Disclaimer: The opinions and comments inNevada's Largest Daily Morning | this article are my own and in no wayNewspaper | reflect the opinions of my employers.- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Why are we letting the government drug propaganda get the best of us?------------------------------Date: 21 May 90 13:15:50 GMTFrom: zaphod.mps.ohio-state.edu!samsung!emory!kd4nc!ke4zv@tut.cis.ohio- state.edu (Gary Coffman)Subject: Kantronics Data EngineTo: packet-radio@ucsd.eduIn article <30600041@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu writes:>>I just saw an ad for the Kantronics "Data Engine" TNC(?) in the June issue>of QST (surprise, I am a member of ARRL). I certainly do intend to call up>Kantronics and ask them all about it, but I'd like to find out what people>here know about this thing. Can someone who might happen to know more please>post what they can? One thing I did notice is that they claim this has an>"open architecture" and a "developers technical reference" of some sort.>I tend to disbelieve, so I will have to see it to believe it that this thing>is going to be an easy platform to develop new ROM code for. We'll see.>I spent quite a while at Dayton with the Kantronics folks asking questionsabout this box. It's based on a V40 processor. It will accept 512k of ROMand 512k of RAM though it ships with 64k and 64k (thats bytes not bits).It is designed to be an open data engine that can drive two 56k baud portsand a 19.2kb async link simultaneously. Their developers guide will includefull schematics and address maps. The modems can be daughter cards internalto the box or external via connectors on the back. They include one 1200baud daughter card modem with each unit shipped. They have available prototyping daughter cards for your own modem designs. The externalconnections have been tested with the G3RUH 9600 baud modem and theGrapes 56k modem. Since the architecture is similar to a pc, you shouldbe able to port code developed on a pc to the data engine rather easily.The software that ships with the box is very similar to the KAM. Thehardware physically looks very good (nice clean layout). Whether we needa "super tnc" is of course another question altogether. As a two porthigh speed switch with a lower speed tap (19.2k to an ordinary kiss tnc),it has possibilities. It also might serve as a telebit substitute ona Unix (tm) box. I like it!73 Gary KE4ZV------------------------------Date: 22 May 90 03:56:00 GMTFrom: usc!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!brutus.cs. uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!phil@ucsd.eduSubject: Kantronics Data EngineTo: packet-radio@ucsd.eduThe DataEngine ad also mentioned the 85C30. Is this also fully accessableby developer code?--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society<phil@ux1.cso.uiuc.edu> | no matter what the particular issue is all about.------------------------------Date: 21 May 90 16:33:58 GMTFrom: swrinde!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!aplcen!s tda.jhuapl.edu!mjj@ucsd.edu (Marshall Jose)Subject: Kantronics KPC-2To: packet-radio@ucsd.eduIn article <5502@emory.mathcs.emory.edu> mhall@ducvax.auburn.edu writes:>I am interested in purchasing the Kantronics Packet Communicator II (KPC-2).>Does anyone have any advice, horror stories, or love stories they would like toMark,I have been using two KPC-2's in KISS mode for about a year, and havefound them to be the most reliable part of my station. The only thingabout them which I'm not real sure about is the DCD-modem combination.Kantronics uses the 7910 modem chip, and doesn't have a true "state-machine" DCD circuit. Rather, it regards any channel activity asa detected carrier. This doesn't affect things too much on VHF, buton HF it might be a hassle.Nevertheless, I remember reading in one of the Packet Conference proceedingsthat the 7910 did a better job on noisy signals than the TAPR 2121/2122circuit. I can't remember which conference and I'm only 80% sureof this information.Regarding the DCD circuit, 73 Magazine recently ran an article aboutretrofitting a TAPR state-machine DCD to a Kantronics TNC, so eventhat little problem (if it is one) can be taken care of.Cheers,Marshall Jose WA3VPZmjj%stda@aplcen.apl.jhu.edu || ...mimsy!aplcen!aplvax!mjj------------------------------Date: 21 May 90 18:34:28 GMTFrom: swrinde!zaphod.mps.ohio-state.edu!samsung!umich!pmsmam!wwm@ucsd.e du (Bill Meahan)Subject: Kantronics KPC-2To: packet-radio@ucsd.eduIn article <5504@aplcen.apl.jhu.edu> mjj@aplvax.UUCP (Marshall Jose) writes:>In article <5502@emory.mathcs.emory.edu> mhall@ducvax.auburn.edu writes:>>I am interested in purchasing the Kantronics Packet Communicator II (KPC-2).>>Does anyone have any advice, horror stories, or love stories they would like to>>Mark,>>I have been using two KPC-2's in KISS mode for about a year, and have>found them to be the most reliable part of my station. The only thing>about them which I'm not real sure about is the DCD-modem combination.>Kantronics uses the 7910 modem chip, and doesn't have a true "state->machine" DCD circuit. Rather, it regards any channel activity as>a detected carrier. This doesn't affect things too much on VHF, but>on HF it might be a hassle.>>Nevertheless, I remember reading in one of the Packet Conference proceedings>that the 7910 did a better job on noisy signals than the TAPR 2121/2122>circuit. I can't remember which conference and I'm only 80% sure>of this information.>>Regarding the DCD circuit, 73 Magazine recently ran an article about>retrofitting a TAPR state-machine DCD to a Kantronics TNC, so even>that little problem (if it is one) can be taken care of.>Will this mod also work with the KAM??For the benefit of us who don't subscribe to '73' could you either postthe appropriate info or point to a source of more info?>Cheers,>>Marshall Jose WA3VPZ>mjj%stda@aplcen.apl.jhu.edu || ...mimsy!aplcen!aplvax!mjj73-- Bill Meahan WA8TZG uunet!mailrus!umich!pmsmam!wwmI speak only for myself - even my daughter's cat won't let me speak for her!------------------------------Date: 22 May 90 05:59:30 GMTFrom: ka9q.bellcore.com!karn@bellcore.com (Phil Karn)Subject: NOS 0418 won't xmitTo: packet-radio@ucsd.eduUntil NOS 900418, the transmit routine "kick started" the interrupt handlerwhenever a frame is sent. One of my contributors suggested removing it,claiming it may have been causing corruption of transmitted data. In anyevent, it did seem unnecessary, at least with the NS16550A chips I use on mysystem, so I took it out.Apparently this breaks some systems with standard 8250 serial port chips. Ihave since found that the corrupted transmit data problem was caused byanother bug that has also been fixed, so I'll reinstall the "kick start"routine in my next update of NOS.Phil------------------------------Date: 21 May 90 13:48:45 GMTFrom: ingr!b11!bill@uunet.uu.net (Bill Welch)Subject: tapr tnc-1 (beginner looking for info)To: packet-radio@ucsd.eduI picked up a 2m rig and a tnc-1 at the b'ham fest. Until now,I have been so busy with other aspects of amateur radio, and haveignored packet. Now I am interested :-)Any pointers to what I can do with this would be appreciated.It came with eproms for WA8DED and KISS, as well as the originalfirmware.I managed to connect to a local bbs using wa8ded firmware, butI am sure that some of you out there have a lot of good informationconcerning operation, etc. Thanks in advance!bill welch uunet!ingr!bill kc4mxj------------------------------End of Packet-Radio Digest******************************Date: Wed, 23 May 90 04:00:05 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #36To: packet-radioPacket-Radio Digest Wed, 23 May 90 Volume 90 : Issue 36Today's Topics: 9600 baud G3RUH modems Beginers Guide to tcp/ip Beginners Guide to tcpip - GOT IT! Full Duplex via Counter-Polarized Antennas hosts.net (2 msgs) Net/rom configuration? New Macintosh TCP/IP release PE1CHL NET Quote without commentSend Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: Tue, 22 May 90 22:28:59 PDTFrom: sox!ka6sox@ucsb.eduSubject: 9600 baud G3RUH modemsTo: Packet-Radio@ucsd.eduAbout 2 years ago I got a pair of them going using the midland 13-509 radios.They work fairly well used as a pair (talking to like radios). The secret tothe G3RUH is that the transmitter modulation waveform is pre-distorted to takeinto account the other receivers IF filter distortion. This means that themodem is designed for a homogenous network (one in which all the recievers arethe same or have similar IF characteristics). Reality says that in 220mhz thisis probably going to be the case as I have not heard of anyone using anythingother than 13-309's for medium speed work (4800-9600 baud). WB9MJN wrote a very good article in 220 NOTES a few months back on what mods need to be done to make the radios work very well. The only mods I did to the radios were making them true FM (adding a VARACTOR to the TX XTAL) and bringing out the discriminator, PTT, and modulator lines.After many months of waiting to see what was going to happen to the lower 2megsof 220 a few brave souls are going to put them on the air for real :-). We aregoing to use them for a 60mile hop between Ventura CA and Santa Barbara CA.Both ends are G8BPQ switches using DRSI boards. 73's Tom ------------------------------Date: 22 May 90 19:07:22 GMTFrom: cs.utexas.edu!ut-emx!lad-shrike!kriss@tut.cis.ohio-state.edu (R M Kriss)Subject: Beginers Guide to tcp/ipTo: packet-radio@ucsd.eduHelp! I noticed a posting the other day aboutan ftp source for a beginner's guide to tcp/ip.I trashed the posting and sure would like tohave the source. I have been trying to get startedusing the new NET/Mac v1.1 program. Nothing seemsto work right, so I need the Beginner's Guide.Dick, KD5VU------------------------------Date: 22 May 90 22:47:12 GMTFrom: cs.utexas.edu!ut-emx!lad-shrike!kriss@tut.cis.ohio-state.edu (R M Kriss)Subject: Beginners Guide to tcpip - GOT IT!To: packet-radio@ucsd.eduThanks to all that responded to my request for helpDick,KD5VU------------------------------Date: 22 May 90 17:36:15 GMTFrom: hpl-opus!hpnmdla!glenne@hplabs.hp.com (Glenn Elmore)Subject: Full Duplex via Counter-Polarized AntennasTo: packet-radio@ucsd.edu> > I want to make full duplex point-to-point links on 430/439 MHz. I also> want to avoid using a duplexer. Here is an idea I had:> > Feed TX to a horizontally-polarized yagi and use a vertically-polarized> yagi mounted on the other end of a boom. How much isolation do I buy?> I probably need a balanced matching system for this work at all well so> let's assume that I use a toroidal transformer for the balun and a> T-match or something like that. Furthermore, I also agree to mount the> thing symmetrically on the tower.> > PreS: Numerous replies in answer to my post "Commercial Data Radios"> and I will repost soon. Hint: the news is not very good.> > Doug Collinge, first try: collinge@uvicctr.uvic.ca> then try: samisen!djc@uvicctr.uvic.ca> VE7GNU VE7GNU@VE7GNU.#VIC.BC.CAN.NA> Victoria, BC, Canada> Doug, I suspect that spacial separation between antennas will be the bestinvestment towards isolation. Avoiding feedline radiation through goodbalance and chokes is probably pretty important too since the twofeedlines no doubt get pretty close together at some point. Usingdifferent polarizations may be helpful but probably not as big a helpparticularly if there are scattering and reflecting sources (groundclutter) fairly nearby. If you were to use opposite sensed circularantennas remember that reflection from a nearby specular reflector (asopposed to a scatterer) will reverse the sense and can actually makematters worse than if you were using two linearly polarized antennas.Similarly, a linearly polarized wavefront hitting a local scatterer willgenerate any variety of polarizations. Summary is: put the antennas as far apart as possible and the mainbeams as far away (in both ax and el) from anything close that canintercept RF. Do a good job of feedint the antennas. Use differentpolarizations too but don't count on that as buying as much as the otherremedies.Glenn Elmore -N6GN-N6GN @ K3MC glenn@n6gn.ampr.orgglenne@hpnmd.hp.com ------------------------------Date: 22 May 90 17:25:27 GMTFrom: cunixf.cc.columbia.edu!lamont!rgb@rutgers.edu (bob bookbinder)Subject: hosts.netTo: packet-radio@ucsd.edu Where can I ftp a copy of the latest hosts.net file. I'd settlefor a local (NY area) piece of it. Bob Bookbinder------------------------------------------------------- ---------------------------Lamont-Doherty Geological Observatory of Columbia UniversityPalisades, New York 10964Analog: 914-359-2900 X 498Digital: rgb@lamont.ldgo.columbia.eduFax: 914-359-5215RF: WA 2LWE@WB2COY------------------------------------------------------ -----------------------------------------------------------Date: 22 May 90 20:14:42 GMTFrom: brian@ucsd.edu (Brian Kantor)Subject: hosts.netTo: packet-radio@ucsd.eduNo global hosts.net file exists, and if one did, it would be of verylittle value, since the AMPRNet is not a connected network anyway.To obtain the latest list for your area, contact the address coordinatorwho assigns IP addresses in that area. Here is a complete list of thosepeople.----------------------------------------------------- -------------------44.002 Bob Meyer K6RTV Calif: Sacramento44.004 Douglas Thom N6OYU Calif: Silicon Valley - San Francisco44.006 Don Jacob WB5EKU Calif: Santa Barbara/Ventura44.008 Brian Kantor WB6CYT Calif: San Diego44.010 Brian Roode KA6CCF Calif: Orange County44.012 Joe Dubner K7JD Eastern Washington,Idaho44.014 John Shalamskas KJ9U Hawaii & Pacific Islands44.016 Don Jacob WB5EKU Calif: Los Angeles - S F Valley44.018 Geoffrey Joy KE6QH Calif: San Bernardino & Riverside44.020 Bill Flynn AI0C Colorado: Northeast44.022 John Stannard KL7JL Alaska44.024 Clifford Neuman N1DMM Washington state: Western (Puget Sound)44.026 Ron Henderson WA7TAS Oregon44.028 Don Adkins KD5QN Texas: Dallas44.030 J Gary Bender WS5N New Mexico44.032 Bdale Garbee N3EUA Colorado (Colorado Springs)44.034 Jeff Pierce WD4NMQ Tennesee44.036 Doug Drye KD4NC Georgia44.038 Mike Abbott N4QXV South Carolina44.040 Jeff Jacobsen WA7MBL Utah44.042 Phil Akers WA4DDE Mississippi44.044 Rolfe Tessem W3VH Massachusetts: western44.046 William Simmons WB0ROT Missouri44.048 Jacques Kubley KA9FJS Indiana44.050 Ron Breitwisch KC0OX Iowa44.052 Gary Grebus K8LT New Hampshire44.054 Ralph Stetson KD1R Vermont44.056 Jim Posiadlo AE1C Boston44.058 Rich Clemens KB8AOB West Virginia44.060 Howard Leadmon WB3FFV Maryland44.062 Jim Dearras WA4ONG Virginia (not DC)44.064 Phil Karn KA9Q New Jersey: northern 44.065 John Pearce WB2MNF New Jersey: southern 44.066 unassigned44.068 Norm Sternberg W2JUP New York: Long Island44.069 Paul Gerwitz WA2WPI New York: upstate44.070 Gary Sanders N8EMR Ohio44.072 Dick Gulbrandsen WD9DBJ Chicago - North Ill.44.074 James Curran KA4OJN North Carolina44.076 Kurt Freiberger WB5BBW Texas: central?44.077 Rod Huckabay KA5EJX Texas: west44.078 Joe Buswell K5JB Oklahoma44.080 John Gayman WA3WBU Pennsylvania: eastern44.082 Steven Elwood N7GXP Montana44.084 Bob Ludtke K9MWM Colorado: western44.086 Reid Fletcher WB7CJO Wyoming44.088 Jon Bloom KE3Z Connecticut44.090 Mike Nickolaus NF0N Nebraska44.092 Pat Davis KD9UU Wisconsin, upper peninsula Michigan44.094 Gary Sharp WD0HEB Minnesota44.096 Bill Babson WA1IVD District of Columbia44.098 Garry Paxinos (waiting) Florida44.100 Jere Sandidge K4FUM Alabama44.102 Steven Corso KV8G Michigan (lower peninsula)44.104 Ed Rasso WA2FTC Rhode Island44.106 Bob Austin N4CLH Kentucky44.108 James Dugal N5KNX Louisiana44.110 Richard Duncan WD5B Arkansas44.112 Bob Hoffman N3CVL Pennsylvania: western44.114 Steven Elwood N7GXP N&S Dakota44.116 Tom Kloos WS7S Oregon: NW&Portland,Vancouver WA44.118 Jon Andrews WA2YVL Maine44.120 unassigned44.122 Troy Majors WI0R Kansas44.124 David Dodell WB7TPY Arizona44.125 Earl Petersen KF7TI Nevada44.126 Karl Wagner KP4QG Puerto Rico## 44.128 is reserved for testing. Do not use for operational networks.# You may safely assume that any packets with 44.128 addresses are bogons# unless you are using them for some sort of testing#44.128 TEST## International subnet coordinators by country#44.129 Japan JG1SLY Tak Kushida, JH3XCU Joly Kanbayashi44.130 Germany DL4TA44.131 United Kingdom G6KVK Gareth Howell44.132 Indonesia YB1BG Robby Soebiakto44.133 Spain EA4DQX Jose Antonio Garcia. Madrid. (EA4DQX @ EA4DQX)44.134 Italy I2KFX44.135 Canada VE3GYQ David Toth44.136 Australia VK2ZXQ John Tanner44.137 Holland PA0GRI Gerard Van Der Grinten44.138 Israel 4X6OJ Ofer Lapid44.139 Finland OH2BJU44.140 Sweden SM0RGV Anders Klemets44.141 Norway LA4JL Per Eotang44.142 Switzerland HB9CAT Marco Zollinger44.143 Austria OE1YSS Irmela Gagern44.144 Belgium ON7LE44.145 Denmark OZ1EUI44.146 Phillipin es DU1UJ Eddie Manolo44.147 New Zealand44.148 Ecuador HC5K Ted44.149 Hong Kong VS6EL44.150 Yugoslavia YU3FK Iztok Saje44.151 France FC1BQP Pierre-Francois Monet44.152 Venezuela OA4KO/YV5 Luis Suarez44.153 Argentina LU7ABF Pedro Converso44.154 Greece SV1IW Manos44.155 Ireland EI9GL Paul Healy44.156 Hungary HA5DI Markus Bela44.157 Chile CE6EZB Raul Burgos44.158 Portugal CT1DIA Artur Gomes44.159 Thailand HS1JC Kunchit Charmaraman44.193 Outer Space-AMSAT W3IWI Tom Clark------------------------------Date: 22 May 90 15:09:19 GMTFrom: brian@ucsd.edu (Brian Kantor)Subject: Net/rom configuration?To: packet-radio@ucsd.eduIf you are managing a net/rom node or nodes, and have set any of theparameters to non-default values, I'd like to know what values you choseand why (except, of course, the rather obvious point of settingmaxframes to 1 on the access channel).I manage a number of nodes here in town and have been tuning them the wayI think it ought to be done, but I'd like to compare notes on what otherpeople do. - Brian------------------------------Date: 22 May 90 23:23:19 GMTFrom: apple.com!winter@apple.com (Patty Winter)Subject: New Macintosh TCP/IP releaseTo: packet-radio@ucsd.edu The latest (and last) Macintosh version of the KA9Q Internet ProtocolsPackage is now available for anonymous FTP from apple.com (/pub/ham-radiodirectory). Both NET and BM are there, executables as well as source code. If you don't have FTP capability, you can send a formatted 800K diskwith a stamped return disk mailer to Doug Thom, N6OYU, 1405 Graywood Drive,San Jose, CA 95129. Or send $5.00 in lieu of disk and mailer. As previously announced, this will be the last Macintosh version releasedunless someone else takes over development. Our thanks are due toDoug and to Dewayne Hendricks, WA8DZP, for all their work on the Macversion over the past few years. Patty------------------------------Date: 23 May 90 07:59:23 GMTFrom: zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!tut!santra!kolvi.hut.fi !kwi@tut.cis.ohio-state.edu (Kaj Wiik)Subject: PE1CHL NETTo: packet-radio@ucsd.eduIs the newest version of PE1CHL NET Atari ST version available via FTPsomewhere. I have found the MS-DOS version from numerous places, andeven the revision history for ST(!) but not the ST executables...Please...Kaj,OH6EH/2------------------------------D ate: 21 May 90 12:55:41 GMTFrom: shlump.nac.dec.com!ryn.esg.dec.com!pstjtt.enet.dec.com!taber@decu ac.dec.comSubject: Quote without commentTo: packet-radio@ucsd.eduIn article <23433@bellcore.bellcore.com>, karn@ka9q.bellcore.com (Phil Karn) writes...> NETWORK SYSTEMS SPECIALIST> >familiar with the hardware/software aspects of LAN, network management and>operating systems, terminal emulation and host coupling, OSI protocols>INCLUDING TCP/IP [my emphasis - Phil], ...Yeah, so? OSI's TP4 is almost exactly TCP/IP -- that's no secret. >>>==>PStJTT Patrick St. Joseph Teahan TaberMail address: Nahhhhh, you don't want to send me mail....------------------------------End of Packet-Radio Digest******************************Date: Thu, 24 May 90 04:00:06 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #37To: packet-radioPacket-Radio Digest Thu, 24 May 90 Volume 90 : Issue 37Today's Topics: Kantronics Data Engine (3 msgs) List of BBS's that are used by HAM'S (2 msgs)Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 23 May 90 13:32:17 GMTFrom: usc!samsung!xylogics!bu.edu!mirror!necntc!necis!rbono@ucsd.edu ( NM1D)Subject: Kantronics Data EngineTo: packet-radio@ucsd.eduIn article <30600041@ux1.cso.uiuc.edu>, phil@ux1.cso.uiuc.edu writes:> > I just saw an ad for the Kantronics "Data Engine" TNC(?) in the June issue> of QST (surprise, I am a member of ARRL). I certainly do intend to call up> Kantronics and ask them all about it, but I'd like to find out what people> here know about this thing. Can someone who might happen to know more please> post what they can? One thing I did notice is that they claim this has an> "open architecture" and a "developers technical reference" of some sort.> I tend to disbelieve, so I will have to see it to believe it that this thing> is going to be an easy platform to develop new ROM code for. We'll see.> I am on the Kantronix Beta list... they sent me a "beta" copy ofthe USERS manual for this beast.... It looks interesting, can can supportseveral types of external modems. Kantronix even asks developers to letthem know if there is need for MORE support for other types of Modems. The ad (I just saw it too) actually explains Kantronix intentionsBETER than their user manual.... Keep in mind, that the manual was for theAX.25 code (and KISS) that they ship standard with the TNC..... I have notseen the developers manual..... I thought a couple of outstanding features (of their software) were: 1) The ability (through a *random* password algorithm) to control the TNC remotely 2) A "HOST" mode (finally :-)) I don't remember the rest.... It seems that this unit should allow developers to "roll their own" without worying about the hardware design... I hope the cost is reasonable!!!! Rich-- /**************************************************************** **********\ * Rich Bono (NM1D) If I could only 'C' forever!! rbono@necis.nec.com * * (508) 635-6300 NEC Technologies Inc. NM1D@WB1DSW * \**************************************************************** **********/------------------------------Date: 23 May 90 20:35:00 GMTFrom: sdd.hp.com!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.u iuc.edu!ux1.cso.uiuc.edu!phil@ucsd.eduSubject: Kantronics Data EngineTo: packet-radio@ucsd.edu> I am on the Kantronix Beta list... they sent me a "beta" copy of> the USERS manual for this beast.... It looks interesting, can can support> several types of external modems. Kantronix even asks developers to let> them know if there is need for MORE support for other types of Modems.I was specifically told by the person who was head of technical developmentat Kantronics a couple years ago that there was no such program for peopleto do reviews or development. I assumed that people who were developingother ROM code for the TNC's were doing so after doing their own reverseengineering.Has there in fact been an effort to allow certain people to develop codefor these machines that they could have been lying to me about?I remember when the Macintosh computer from Apple first came out and Applewas instituting a "developers program". Since NeXT did this as well, Iassume it was a Steve Jobs idea. However, when I pursued finding out aboutthe program, I was told that the only people who were qualified were thosewho had already done development. I had not done development before becauseI didn't anything worth doing the development on. This started a bad viewI had of Apple which has only gotten worse with other matters.Now the question is, has Kantronics in the past acted this way? Is thefuture going to consist of them not holding back any technical information?One of the experiments I have in mind for a TNC involves doing some work onan arriving packet in real time during packet assembly making KISS mode notusable.> The ad (I just saw it too) actually explains Kantronix intentions> BETER than their user manual.... Keep in mind, that the manual was for the> AX.25 code (and KISS) that they ship standard with the TNC..... I have not> seen the developers manual.....I was told today my Matt Foster at Kantronics that the Technical Developer'sManual for teh DataEngine will be available "sometime this summer".> I thought a couple of outstanding features (of their software) were:> > 1) The ability (through a *random* password algorithm) to control> the TNC remotely> > 2) A "HOST" mode (finally :-))What is "HOST" mode? The term is sufficiently vague for me to be able tocome up with lots of grandiose things that could be called by this.> I don't remember the rest.... It seems that this unit should allow> developers to "roll their own" without worying about the hardware> design... I hope the cost is reasonable!!!!Sorry, but I cannot imaging doing software development without worrying, orat least knowing, the hardware design. This is probably because I do workwith software at the very lowest level and perhaps most programmers never do.If Kantronics has the perception of this, and supplies "technical" data onhow to make use of their low level code without giving me a chance to writebetter low level code, then this machine is not the developer's machine Ineed. Running a PC and a TNC in KISS mode would serve this need well if Iwere restricted this way.So far, all the information I have about the DataEngine cannot rule outthat Kantronics is not making this machine 100% open. However, I have alsonot been able, yet, to exhaust all sources, so significant hope still exists.--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society<phil@ux1.cso.uiuc.edu> | no matter what the particular issue is all about.------------------------------Date: 23 May 90 22:34:41 GMTFrom: usc!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!emory!kd4nc!ke4zv@uc sd.edu (Gary Coffman)Subject: Kantronics Data EngineTo: packet-radio@ucsd.eduIn article <30600043@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu writes:>>The DataEngine ad also mentioned the 85C30. Is this also fully accessable>by developer code?Yes.Gary KE4ZV------------------------------Date: 23 May 90 04:10:47 GMTFrom: dasys1!probe@nyu.edu (michael)Subject: List of BBS's that are used by HAM'STo: packet-radio@ucsd.eduI'm looking for a list of computer BBS's where I can get in touch with HAMradio operators. I'm interested in geting involved with HAMing and would liketo find a users group that would help me get started. Thanks in advance!------------------------------Date: 24 May 90 01:44:08 GMTFrom: winter@apple.com (Patty Winter)Subject: List of BBS's that are used by HAM'STo: packet-radio@ucsd.eduIn article <1990May23.041047.22322@dasys1.uucp> probe@dasys1.UUCP (michael) writes:>I'm looking for a list of computer BBS's where I can get in touch with HAM>radio operators. I'm interested in geting involved with HAMing and would like>to find a users group that would help me get started. Thanks in advance!Michael doesn't say where he is, but here are three BBSs that heor other people might be interested in. (I hope he's in the U.S. orCanada, because I've limited this followup to North America.)MacScience BBSVarious ham-related applications, including antenna design, propagation, WEFAX, packet, and Morse code. (408) 866-4933. Digikron Systems BBSVarious ham-related applications, including logging, propagation, Morse code, and packet. (408) 253-1309.WB3FFV BBSVarious ham-related software, including packet, contesting, and Morsecode applications. (301) 625-0817, 625-9482, and 625-9663. 73,Patty-- ***************************************************************** ************ Patty Winter N6BIS INTERNET: winter@apple.comAMPR.ORG: [44.4.0.44] UUCP: {decwrl,nsc,sun}!apple!winter************************************ ***************************************** ------------------------------End of Packet-Radio Digest******************************Date: Fri, 25 May 90 04:00:03 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #38To: packet-radioPacket-Radio Digest Fri, 25 May 90 Volume 90 : Issue 38Today's Topics: Antenna Tuner Delivery Failure Report List of BBS's that are used by HAM'S Tuning Indicator for MFJ 1270BSend Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send requests of an administrative nature (addition to, deletion from thedistribution list, et al) to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. You can send that in an interactive if your systemsupports them (e.g. the CMS TELL command), or in the body of a mail message(*not* the subject line).Please note: Although you'll be receiving Packet-Radio mailing from thenetwork address I-PACRAD@UIUCVMD, Packet-Radio@UCSD.Eduis the source. Any contributions from you should be sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one.73, - Brian (brian@ucsd.edu)------------------------------------------ ----------------------------Date: 24 May 90 06:57:55 GMTFrom: zaphod.mps.ohio-state.edu!samsung!umich!vela!swood@tut.cis.ohio-s tate.edu (Scott Wood)Subject: Antenna TunerTo: packet-radio@ucsd.eduAmp Supply -- AT 12001200 Watt antenna Tuner 4-sale :: $ 100.00 oboincluding shippingmint conditionSWood.-- "'`No Problem is too big, that you can't run away from it` - Snoopy (C.Shultz).I get truth where I can find it.' - Don Shimoda" - R.Bach (Illusions) I ain't as dumm as u tink I are SWood The Notorious Tre'------------------------------Date: 24 May 90 05:12:00 PSTFrom: "MRGATE::"SSXMB::POSTMSTR"" <postmstr"%mrgate."ssxmb.decnet@consrt.rok.com>Subject: Delivery Failure ReportTo: "packet-radio" <packet-radio@ucsd.edu>From: POSTMSTR @SSXMBTo: MRREMNET @MRGATE WINS%"PACKET-RADIO @UCSD.EDU" @CONSRT @MRGATE Author: Sender: WINS%"PACKET-RADIO @UCSD.EDU"@CONSRT@MRGATE@CONSRT Subject: Packet-Radio Digest V1 #37 Message Class: Recipients: BCCROWE@DALMACUnable to deliver mail from Sender name WINS%"PACKET-RADIO@UCSD.EDU"@CONSRT@MRGATE@CONSRT.Please contact your Soft-Switch Administrator to register this user in the Name Translate Directory.------------------------------Date: 24 May 90 13:49:22 GMTFrom: van-bc!ubc-cs!nebulus!dennis@ucbvax.Berkeley.EDU (Dennis S. Breckenridge)Subject: List of BBS's that are used by HAM'STo: packet-radio@ucsd.eduVE7TCP Vancouver Communications BBS [44.135.160.60] (nebulus)Ham related software, current versions of MSYS, NOS, NET. USENET accessUnix based. FTP and uucp supported. Part of ARES. (604) 277-7412 (TB2500)-- ----------------------------------------------------------------- ------------Dennis S. Breckenridge (604) 277-7413 dennis@nebulus.uucp VE7TCP Still brain dead after all these years :-) ----------------------------------------------------------------- ------------------------------------------Date: 25 May 90 00:52:04 GMTFrom: ogicse!intelhf!guest@ucsd.edu (Guest User)Subject: Tuning Indicator for MFJ 1270BTo: packet-radio@ucsd.eduLast week I bought a MFJ 1270B at a local hamfest. It is very difficult to tune to HF Packet stations using the 1270B.Is it worth $50 to buy a tuning indicator from MFJ?Is there any other way to tune to HF Packet?Does TAPR sell anything ? Thanks in Advance73'sKB&IHO (radha)----------------------------------------------rvenka@pcocd 2.intel.comrvenka@pcocd2.intel.com:w----------------------------- -End of Packet-Radio Digest******************************Date: Sat, 26 May 90 04:00:02 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #39To: packet-radioPacket-Radio Digest Sat, 26 May 90 Volume 90 : Issue 39Today's Topics: 9600 baud G3RUH modems Commercial Data Radios: followup. Delivery Failure Report hosts.net (3 msgs) PC-100 or 8530 for NOS ??Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. Please note that although you'll be receivingPacket-Radio mailing from the network address I-PACRAD@UIUCVMD,Packet-Radio@UCSD.Edu is the source. Any contributions shouldbe sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one. 73, Brian (brian@ucsd.edu)------------------------------------------------- ---------------------Date: 25 May 90 17:19:09 GMTFrom: swrinde!zaphod.mps.ohio-state.edu!rpi!bu.edu!mirror!ssi3b1!shyoon !tegra!vail@ucsd.edu (Johnathan Vail)Subject: 9600 baud G3RUH modemsTo: packet-radio@ucsd.eduIn article <9005230528.AA10166@hub.ucsb.edu> ka6sox@sox.UUCP writes: About 2 years ago I got a pair of them going using the midland 13-509 radios. They work fairly well used as a pair (talking to like radios). The secret to the G3RUH is that the transmitter modulation waveform is pre-distorted to take ^^^^^^^^^^^^^you might say "pre-compensated" instead. sounds less like a kluge :-) into account the other receivers IF filter distortion. This means that the modem is designed for a homogenous network (one in which all the recievers are the same or have similar IF characteristics). Reality says that in 220mhz thisOr in the case of a repeater, the repeater can be tweaked to be as flatas possible and then each user station tweaks for good match to therepeater. If the repeater is regenerating from the digital signalthis should work well without having any real problems in trying toconnect to any random station whose tx/rx characteristics may bedifferent."The death of God left the angels in a strange position." _____| | Johnathan Vail | tegra!N1DXG@ulowell.edu |Tegra| (508) 663-7435 | N1DXG@448.625-(WorldNet) ----- jv@n1dxg.ampr.org {...sun!sunne ..uunet}!tegra!vail------------------------------Date: 25 May 90 14:29 -0700From: Doug Collinge VE7GNU <djc@samisen@uvicctr.uvic.ca>Subject: Commercial Data Radios: followup.To: packet-radio@ucsd.edu, tcp-group@ucsd.edu>X-Mailer: Mush 6.5.6 (PC R6.3 22-Sep-89)Here is the updated results of my research into data radio possibilities.The information is now suffixed with a date.PacComm: no longer in the picture. They have withdrawn their earlierNB9600 series and its successor is nowhere near production. "Six months,maybe?" was the answer. That probably means never. Their G3RUH modemis still available, however, and plugs right into their own TNCs andTNC2 clones. I got several reports saying the the G3RUH works well withseveral different kinds of modified radios, and it works with no modswith the Kantronics DVR2-2. (1990-05-15)Kantronics: paydirt! The DVR2-2 (144MHz, 2W) works with the G3RUH modemat 9600 baud. Lists for $239US. Compatible with a 30W power amp fromRF Concepts, list $129US. The whole thing is tested and works with aTXD of 4 (40 ms). All shipping now. The 440MHz version of theKantronics DVR2-2 is not yet available. They expect to ship inmid-July. I don't have any idea how reliable this estimate might be. The Data Engine is shipping now, so there's something. (1990-05-15) Igot a note saying that an engineer at Kanx reported that the DVR4-2(440MHz) will likely be frequency synthesized. I don't see how theycan have it in production and shipping by "mid-July" if they haven'teven finalized the design - but then, what do I know? The price of theDVR2-2 has been reduced to $219US. (1990-05-20) TAPR: the PacketRadio is still in neverland. Betatest has not started.Someone has the flu or maybe something more awful. They plan to offerit as a kit and also license it to commercial outfits. They figure thekit will be out in September but I really doubt that - their estimateshave been very optimistic on this project so far. But I don't think itis fair to call it the "VapourRadio" (as funny as it is) consideringthat they showed the boards at Dayton. (1990-05-14) Since then I readin QEX that they haven't even designed the whole thing yet but I don'tknow when that article went to press. TAPR also sells the K9NG 9600 baudmodem, which is what the G3RUH is supposed to be compatible with. TheK9NG is half-duplex; the G3RUH is full duplex and has a digital TXfilter that can compensate somewhat for poor receiver response. Thisis good if you are using a repeater or if everyone has the same type ofRX. (1990-05-18)Hamtronics: They have a modem, RX, and TX that are supposed to do 9600baud. Their catalog hasn't arrived so I can't give more details. Doesanyone have first-hand experience with this stuff? Second-hand? But Ireally don't think publishing rumours is worth anything. (1990-05-24)AEA: nothing. The only data RF product they had has been cancelled andthere is nothing up their sleeve. The PS186 data switch platform is inneverland. "You mean it's waiting for someone to make up his mind?""Something like that." You know what they say: "Confused minds sayNo." (1990-05-15)DRSI: The guy at DRSI told me that they are thinking about making a 4Wdata radio for the Amateur market which would be similar to thecommercial ones they have made. Committed to the idea but noparticular date in mind right now. A high-speed modem is currently ahigher priority for some reason. (1990-05-15)GLB: I called up GLB and they have an integrated data radio called the"Netlink 450" available now for $1495US. It is a half-duplex unit with9600 baud stock, higher data rates on special order. The controller isbuilt-in, data appears on an RS232 port. All details of transmissionare handled inside the box - I don't know how it is done or what isdone about callsigns, if anything. It sounds like a good thing fortrunking. The price sounds high but you have to consider that itincludes just about everything needed to make it work, even in high RFenvironments: TNC, fast switching RX/TX (1 ms), TX 2W (12W available),5 helical RF filter. The specs sound very good, too: ovens on thecrystals, digital AFC, sensitivity .6uV for 10E-3 BER, -60dB RXbandwidth is 30kHz, TX bandwidth 15kHz for 9600 baud. (1990-05-20)They also sold a 19.2kbaud unit a while back but this has apparentlybeen discontinued since they certainly didn't mention it to me and did not include it in their literature. (1990-05-24)GRAPES: The Heatherington (,WA7DSY,DSY) 56kbaud modem is availablefrom GRAPES and works. It is an RF modem operating in the 30MHzrange and therefore needs a transverter for VHF or UHF operation.Phil tells me that the modem+xverter can be assembled for $500US;however, he didn't tell me where to buy the transverter. A 432/28transverter I located was priced at $599US. You still need a controllerof some sort, of course, and I read that a street-legal TNC can'tcope with 56k on its radio port. GRAPES uses a bored and superchargedTNC2 - I don't know exactly what they do to it - and then there isthe new Kanx Data Engine, which has two 56k ports on it. Seems veryodd that they didn't put a 56k host port on as well - why not? (Withany luck it just needs a bitrate clock generated somewhere and themod will be easy)======================I still welcome comments and more information - post a note.73 doug.-- /\/\/\/\/\/Doug Collinge, first try: collinge@uvicctr.uvic.ca then try: samisen!djc@uvicctr.uvic.caVE7GNU VE7GNU@VE7GNU.#VIC.BC.CAN.NA Victoria, BC, Canada------------------------------Date: 25 May 90 05:14:00 PSTFrom: "MRGATE::"SSXMB::POSTMSTR"" <postmstr"%mrgate."ssxmb.decnet@consrt.rok.com>Subject: Delivery Failure ReportTo: "packet-radio" <packet-radio@ucsd.edu>From: POSTMSTR @SSXMBTo: MRREMNET @MRGATE WINS%"PACKET-RADIO @UCSD.EDU" @CONSRT @MRGATE Author: Sender: WINS%"PACKET-RADIO @UCSD.EDU"@CONSRT@MRGATE@CONSRT Subject: Packet-Radio Digest V1 #38 Message Class: Recipients: BCCROWE@DALMACUnable to deliver mail from Sender name WINS%"PACKET-RADIO@UCSD.EDU"@CONSRT@MRGATE@CONSRT.Please contact your Soft-Switch Administrator to register this user in the Name Translate Directory.------------------------------Date: 25 May 90 19:46:15 GMTFrom: eagle!news@ucbvax.Berkeley.EDU (Jim McKim)Subject: hosts.netTo: packet-radio@ucsd.eduIn article <13873@ucsd.Edu> brian@ucsd.Edu (Brian Kantor) writes:>No global hosts.net file exists, and if one did, it would be of very>little value, since the AMPRNet is not a connected network anyway. ...Interesting - I just tried an nslookup of an ampr.org site and mymachine found a couple of nameservers - thumper.bellcore.com and ucsd.edu!------------------Jim McKim / Internet: mckim@mildred.lerc.nasa.gov This is yourPhone: +1 216 891 2977 / Packet: kb8dcr@kb8dcr.ampr.org brain on NetNews---------------- Any Questions?------------------------------Date: 26 May 90 04:51:26 GMTFrom: brian@ucsd.edu (Brian Kantor)Subject: hosts.netTo: packet-radio@ucsd.eduYes, of course they did, since you asked on the internet. Now turn onyour radio and switch over the the tcp/ip channel in your area, andask your nameserver about some host you know to be in, say, New Mexico.Oh, no nameserver responded?As I said, it's not a connected network.Any questions? - Brian------------------------------Date: 26 May 90 05:38:47 GMTFrom: uhccux!querubin@ames.arc.nasa.gov (Antonio Querubin)Subject: hosts.netTo: packet-radio@ucsd.eduIn article <1990May25.194615.15138@eagle.lerc.nasa.gov> mckim@mildred.lerc.nasa.gov (Jim McKim) writes:>In article <13873@ucsd.Edu> brian@ucsd.Edu (Brian Kantor) writes:>>No global hosts.net file exists, and if one did, it would be of very>>little value, since the AMPRNet is not a connected network anyway.> ...>>Interesting - I just tried an nslookup of an ampr.org site and my>machine found a couple of nameservers - thumper.bellcore.com and ucsd.edu!I did the same and found both servers mentioned above plus 2 more I think andabout 2500 or so hosts. I doubt if many are reachable. The only question I have though is just how did all those hosts get caught up in ucsd'sdomain tables? Did someone temporarily hook up a gateway which had accumulateda lot of hostnames to the Internet?On another topic, does anyone have a list of HF TCP/IP hosts that serve asbridges to more local/regional TCP/IP networks? Or to put it another way,if I wanted to link a Hawaii AMPRnet to the mainland who should I be talkingto? And an even more fundamental question, just how well connected are theregional AMPRnets across the mainland (and beyond)?AH6BWInternet: antonio_querubin-manoa@uhplato.uhcc.hawaii.eduBITnet: antonio_querubin-manoa@uhplato------------------------------Date: 25 May 90 16:04:53 GMTFrom: asuvax!mcdphx!phx.mcd.mot.com!dlf@handies.ucar.edu (3726)Subject: PC-100 or 8530 for NOS ??To: packet-radio@ucsd.eduDoes anyone have any information on a "PC-100" from PacComm?I understand that this is a 2-port (8530) board that plugs into an XT, and is supported (to some extent) by the KA9Q NOSsoftware.I have read here that you can get these "bare boards" fromPacComm for around $30 or so. What I'm wondering is, are thereany EPROMS or PALS on the board? Also, I understand there aremodems on board, are there also some sort of disconnect headersto allow plugging in to 9600 bps modems (like the K9NG from TAPR)?I'm really just looking for the simplest & cheapest way to add an8530 to my XT, so that I can run higher-speed TCP/IP with NOS. (Ido have a couple of 8530's and AMD7910's in the junk drawer)Any information on either PC-100, or alternative ways to add an8530 & necessary support to an XT would be greatly appreciated.Dave Fritsche (wb8zxu)dlf@phx.mcd.mot.com...!ncar!noao!asuvax!mcdphx!dlf------- -----------------------End of Packet-Radio Digest******************************Date: Sun, 27 May 90 04:00:03 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #40To: packet-radioPacket-Radio Digest Sun, 27 May 90 Volume 90 : Issue 40Today's Topics: Firmware Wars High School needs help with Packrat 262 Supercharged GRAPE (was Re: Commercial Data Radios: followup.)Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. Please note that although you'll be receivingPacket-Radio mailing from the network address I-PACRAD@UIUCVMD,Packet-Radio@UCSD.Edu is the source. Any contributions shouldbe sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one. 73, Brian (brian@ucsd.edu)------------------------------------------------- ---------------------Date: 27 May 90 07:44:14 GMTFrom: brian@ucsd.edu (Brian Kantor)Subject: Firmware WarsTo: packet-radio@ucsd.eduThere are messages currently circulating on packet BBSs out here on theleft coast that would seem to indicate that the firmware wars areheating up again.Unfortunately, I can't seem to pin down anyone who knows first-handwhat's going on. Story, as I heard it from several sources, seems tobe that supporters of one particular type of networking software havebeen urging the government agencies and managers of sites containingnodes running the probably-less-legitimate other version of thatsoftware to do something about it.Since most radio site owners barely tolerate hams in their mountaintopsanyway, all it seems to take is a little concerted harrassment by onefaction or the other, and the edict comes down "ok, that's enough, allthe ham stuff goes". And it would seem that's what's happening.So out here in beautiful LA LA Land, it would seem that it's not justpacket radio that's become a political football, but the private remotebases and open voice repeaters are getting tossed over the goalposts too.At the swapmeet the other day, people were wondering how long it wouldbe before someone did something irrational. After all, this is theland of freeway shootings, and the hot weather is just getting started.See, and all along you thought networking was just a matter of solvingsome technical problems. Hah.Seems a Pyrrhic victory to me. And nobody is the winner. - Brian------------------------------Date: 26 May 90 17:30:52 GMTFrom: ucselx.sdsu.edu!bionet!agate!darkstar!ucscb.UCSC.EDU!abbiel@ucsd. eduSubject: High School needs help with Packrat 262To: packet-radio@ucsd.eduI am posting this query for a friend, Myra May, who is charge of the Amateur Radio program at Soquel High School in Soquel, CA.They are interested in becoming active in Packet Radio, and believethat they have all of the hardware necessary to accomplish this task, however, they have *no* local expertise in setting up a system.Computers: Apple IIE /SuperSerial Card IBM PCPacket: Packrat 262 + software for IBMHF and VHF radios and antennas available.Can *you* help with this project either over the Internet, via email tomy account, or to Myra directly via radio or telephone? She'd like tohave it operating before the end of the school year.Myra MaySoquel High SchoolRoom 306(408) 429-3453 10:00AM & 2:00PM best times to call(408) 476-7412 (home)Please contact Myra directly via phone, or use email to contact me and Ican set up further schedules.Thank you in advance for all of your help! LarryLarry McElhiney(408) 475-8027 (H)(408) 426-5858 (W)------------------------------Date: 26 May 90 21:44:39 GMTFrom: swrinde!emory!rsiatl!jgd@ucsd.edu (John G. De Armond)Subject: Supercharged GRAPE (was Re: Commercial Data Radios: followup.)To: packet-radio@ucsd.edudjc@samisen@uvicctr.uvic.ca (Doug Collinge VE7GNU) writes:>transverter I located was priced at $599US. You still need a controller>of some sort, of course, and I read that a street-legal TNC can't>cope with 56k on its radio port. GRAPES uses a bored and supercharged>TNC2 - I don't know exactly what they do to it - Ok, here's our KISS racing secret. We use a nitro-injected jumper toset the clock to a high illegal 8 mhz and then we install Dale's ported and polished KISS-56 rom. A few RAD cuts and solders later,and shazam - a street-legal 56kb driver. :-)Note that the link to the PC is still 19.2 kb so the thruput is limitedto this. We recommend going with one of the aforementioned driverboards but a souped up TNC-2 will work in a pinch. We supply modificationsand the ROM with the kit.John-- John De Armond, WD4OQC | We can no more blame our loss of freedom on congressRadiation Systems, Inc. | than we can prostitution on pimps. Both simplyAtlanta, Ga | provide broker services for their customers.{emory,uunet}!rsiatl!jgd| - Dr. W Williams | **I am the NRA** ------------------------------End of Packet-Radio Digest******************************Date: Tue, 29 May 90 04:00:03 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #41To: packet-radioPacket-Radio Digest Tue, 29 May 90 Volume 90 : Issue 41Today's Topics: Packet Radio in the USSR Tasco TNCSend Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. Please note that although you'll be receivingPacket-Radio mailing from the network address I-PACRAD@UIUCVMD,Packet-Radio@UCSD.Edu is the source. Any contributions shouldbe sent to UCSD.The mailing list is in the form of a digest. It is not edited, justa convenient envelope for multiple messages to reduce netmail load.If your mail reader does not have an "undigestify" option, contactKeith Petersen W8SDZ <W8SDZ@WSMR-SIMTEL20.Army.Mil> and he'll sendyou C-language source for one. 73, Brian (brian@ucsd.edu)------------------------------------------------- ---------------------Date: 28 May 90 20:58:35 GMTFrom: portal!cup.portal.com!ckp@apple.com (Christine K Paustian)Subject: Packet Radio in the USSRTo: packet-radio@ucsd.eduThere may be a broader interest in this topic - would responders post to theNet rather than by E-Mail? Many thanks. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%% % Christine K. Paustian % ckp@cup.portal.com % % Los Numeros On-Line %%% sun!portal!cup.portal.com!ckp % % PO Box 149 %%% 1:272/39 (FidoNet) % % Briarcliff Manor, NY 10510 % C.PAUSTIAN (GEnie) % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%% ------------------------------Date: 29 May 90 01:45:19 GMTFrom: quanta.eng.ohio-state.edu!phonon.eng.ohio-state.edu!rlong@tut.cis .ohio-state.edu (Prof. Ronald Long)Subject: Tasco TNCTo: packet-radio@ucsd.eduAn article in QEX May 1990 page 13 tells about some hamsusing 1200 baud psk on 10 meter band.It says they are using TASCO TNC-24 MK II tnc's. It does not mention using an external psk modem such as TAPR.Does anyone know about these TNC's? Is this a completetnc with built in psk modem?? Who sells them etc.?-=-Ronald K. Long, Ph.D.Ohio State Univ EE Dept., 2015 Neil Ave., Columbus, OH 43210rlong@phonon.eng.ohio-state.edu----------------------------- -End of Packet-Radio Digest******************************Date: Wed, 30 May 90 04:00:04 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #42To: packet-radioPacket-Radio Digest Wed, 30 May 90 Volume 90 : Issue 42Today's Topics: Commercial Data Radios: followup. How do I get on the TCP/IP mailing list?? PC-100 or 8530 for NOS ??Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".Digest files are named Vv.n where v=volume and n=number in volume.Digests will be issued daily unless there is no traffic.SPECIAL NOTE FOR BITNET PEOPLE: UCSD.EDU is an internet site. TheInternet-to-BITNET mail gateway systems would prefer that you insteadadd yourself to a BITNET redistribution of this list; you may addyourself to the list by sending the following command: SUBSCRIBE I-PACRAD your full nameto LISTSERV@UIUCVMD. Please note that although you'll be receivingPacket-Radio mailing from the network address I-PACRAD@UIUCVMD,Packet-Radio@UCSD.Edu is the source. Any contributions shouldbe sent to UCSD. - Brian (brian@ucsd.edu)------------------------------------------------- ---------------------Date: 29 May 90 19:06:28 GMTFrom: sunybcs!bowen@rutgers.edu (Devon E Bowen)Subject: Commercial Data Radios: followup.To: packet-radio@ucsd.eduIn article <265d2c9f.samisen@samisen@uvicctr.uvic.ca>,djc@samisen@uvicctr.uv ic.ca (Doug Collinge VE7GNU) writes:|> They also sold a 19.2kbaud unit a while back but this has apparently|> been discontinued since they certainly didn't mention it to me and |> did not include it in their literature. (1990-05-24)Last I was down there GLB still had some on the shelves. They run in the220 band and I think they stopped pushing them when we lost a major chunkof that. I'm pretty sure you can still get them, though. If anyone isinterested, I'll see them Wednesday nights and can get more info.Devon------------------------------Date: 29 May 90 18:19:50 GMTFrom: usc!samsung!umich!pmsmam!wwm@ucsd.edu (Bill Meahan)Subject: How do I get on the TCP/IP mailing list??To: packet-radio@ucsd.eduThe subject line really says it all.Thanks!____-- Bill Meahan WA8TZG uunet!mailrus!umich!pmsmam!wwmI speak only for myself - even my daughter's cat won't let me speak for her!------------------------------Date: 29 May 90 14:20:33 GMTFrom: sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!bu.edu!mirror!ssi3b1!shy oon!tegra!vail@ucsd.edu (Johnathan Vail)Subject: PC-100 or 8530 for NOS ??To: packet-radio@ucsd.eduIn article <12953@mcdphx.phx.mcd.mot.com> dlf@phx.mcd.mot.com (3726) writes: I'm really just looking for the simplest & cheapest way to add an 8530 to my XT, so that I can run higher-speed TCP/IP with NOS. (I do have a couple of 8530's and AMD7910's in the junk drawer) Any information on either PC-100, or altern ative ways to add an 8530 & necessary support to an XT would be greatly appreciated.I am reluctant to post until I have everything working-working but Ihave designed an 8530 card which can be built and populated for about$50. It uses a JDR prototyping card, the kind with the decoding palsand buffers already etched on the board. I came up with replacementpals and a schematic to make it emulate the Eagle board, at least asfar as the driver in NET (and NOS?) works. There is no DMA (the NETdriver doesn't use it, I am not sure if the Eagle originally had it)but the same interrupt masking and addressing is supported. I havebuilt a board and tested it from debug but have not run it with thedriver yet. This proved the design of the PALS and such could talk tothe chip as I expected to. I don't know yet if this is what thedriver really expects. I was waiting to get the right oscillators andhaven't gotten back to it yet.I can email schematics (Postscript and Orcad) and PAL files (PALASMand JEDEC). I can be reached below. The files are also available forFTPing from n1dxg.ampr.org in the New England Area. For $12 I cansend a set of PALs, a disk and the crystal oscillator needed.When this is playing with NOS I will more formally announce it anddistribute it better."They, that can give up essential liberty, to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin 1759 _____| | Johnathan Vail | tegra!N1DXG@ulowell.edu |Tegra| (508) 663-7435 | N1DXG@448.625-(WorldNet) ----- jv@n1dxg.ampr.org {...sun!sunne ..uunet}!tegra!vail------------------------------End of Packet-Radio Digest******************************Date: Thu, 31 May 90 04:30:02 PDTFrom: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>Reply-To: Packet-Radio@UCSD.EduSubject: Packet-Radio Digest V1 #43To: packet-radioPacket-Radio Digest Thu, 31 May 90 Volume 90 : Issue 43Today's Topics: How do I get on the TCP/IP mailing list?? W0RLI help? (2 msgs)Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>Send subscription requests to: <listserv@UCSD.Edu>Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".------------------------------------- ---------------------------------Date: 30 May 90 18:07:37 GMTFrom: zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!peregrine !ccicpg!cci632!cb@tut.cis.ohio-state.edu (Just another hired gun (n2hkd))Subject: How do I get on the TCP/IP mailing list??To: packet-radio@ucsd.eduHi, I too would like to get on the list, thanks.-- email: cb@cci632 or !rochester!kodak!n2hkd!curtis Curtis Braun, N2HKD, Computronics, PO Box 1002 Fairport NY, 14450 ------------------------------Date: 30 May 90 18:26:21 GMTFrom: sundc!newstop!east!hienergy!jimv@seismo.css.gov (Jim Vienneau - CSS Project Manager)Subject: W0RLI help?To: packet-radio@ucsd.eduIt's totally amazing that a SW package as widely used and accepted asthe W0RLI BBS could be so poorly documented! Having gotten that off my chest: I'm having trouble getting W0RLI 11.11 to run on my AT and PK-88.Actually, it seems to run, but hangs trying to MBINIT the TNC. If Itake the TNC out of "ports.mb" it comes up and runs just fine. If Itry to configure the TNC, it just hangs.... The CPU seems to still bealive (caps lock still toggles the light), but the only way out isCTRL-ALT-DEL. Are there any W0RLI experts out there that would be willingto spend a few minutes on the phone or via email to help out a frustratedfellow HAM? Jim Vienneau, Sun Microsystems Inc - Billerica, MAEmail: jvienneau@east.sun.com Amateur Radio: WB1BGood old Ma Bell (well old anyway): (508)671-0372------------------------------Date: 31 May 90 04:53:24 GMTFrom: sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!uhasun!jbloom@ucsd .edu (Jon Bloom)Subject: W0RLI help?To: packet-radio@ucsd.eduIn article <1963@east.East.Sun.COM>, jimv@hienergy.East.Sun.COM (Jim Vienneau - CSS Project Manager) writes:> > It's totally amazing that a SW package as widely used and accepted as> the W0RLI BBS could be so poorly documented! Having gotten that off my You get what you pay for, y'know.--Jon Bloom, KE3Z | American Radio Relay LeagueInternet: jbloom@uhasun.hartford.edu |Snail: 225 Main St., Newington, CT 06111 | "I have no opinions."------------------------------End of Packet-Radio Digest******************************