From wang!elf.wang.com!ucsd.edu!packet-radio-relay Sat Mar 23 21:42:10 1991 remote from tosspot Received: by tosspot (1.63/waf) via UUCP; Sat, 23 Mar 91 20:35:56 EST for lee Received: from somewhere by elf.wang.com id aa24637; Sat, 23 Mar 91 21:42:08 GMT Received: from ucsd.edu by news.UU.NET with SMTP (5.61/UUNET-shadow-mx) id AA06109; Sat, 23 Mar 91 15:12:49 -0500 Received: by ucsd.edu; id AA10456 sendmail 5.64/UCSD-2.1-sun Sat, 23 Mar 91 04:30:27 -0800 for brian Received: by ucsd.edu; id AA10451 sendmail 5.64/UCSD-2.1-sun Sat, 23 Mar 91 04:30:14 -0800 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list Message-Id: <9103231230.AA10451@ucsd.edu> Date: Sat, 23 Mar 91 04:30:06 PST From: Packet-Radio Mailing List and Newsgroup Reply-To: Packet-Radio@ucsd.edu Subject: Packet-Radio Digest V91 #69 To: packet-radio@ucsd.edu Packet-Radio Digest Sat, 23 Mar 91 Volume 91 : Issue 69 Today's Topics: Administrivia ? how to route with tcpip (2 msgs) Anonymous ftp site for BayComm ??? (2 msgs) anybody RUNNING 9600 ?? (2 msgs) APLINK Baycom Circuit Wanted Class C IP address for packet radio? Dayton - Digital Suite? Digital repeater network G3RUH 9600 baud users on UO-14 Hierarchical Forwarding pounds (#) (13 msgs) How to get email from packet??? Inadvertant "clear screen" (4 msgs) KA9Q & mbox BBS forwarding KA9Q v910308 problems KAM dual-mode enhancement Monthly On-Line Elmers Resource Directory (2 msgs) New packet user No Subject Packet BBS SID and personal mbox reverse forward PK-88 Pinouts (2 msgs) portable packet (4 msgs) SMTP Mail on PBBS? STS-37 SAREX Information Summary TAPR meeting notes TCP/IP Thanks The Amateur Radio BBS - How to access The N2GTE Packet Mail Switch TNC Emulators on PC's (3 msgs) WANTED: Docs for NETPC (DL3DBT v891105) Where can I download Baycom? Send Replies or notes for publication to: Send subscription requests to: Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the Packet-Radio Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Fri, 22 Mar 91 14:04:58 -0800 From: brian (Brian Kantor) Subject: Administrivia To: info-ham-digest, packet-radio-digest Sorry about the deluge of digests; I just fixed the gateway and we had 10 days worth of traffic to catch up on. Things should tame out now. As many of you know, these mailing lists are gatewayed bidirectionally with newsgroups on Usenet. Recently those newsgroups underwent a reorganization, with the ham-radio group being split into several groups, primarily splitting off a "policy" group for the discussion of things like no-code, license classes, rules and regulations, etc. That newsgroup is now available as a separate digest from ucsd, the ham-policy digest. You may subscribe, as always, by sending mail to listserv@ucsd.edu. Now that everything is working, I'm going on vacation for a week. Flames will be extinguished when I get back. - Brian ------------------------------ Date: 23 Mar 91 02:46:37 GMT From: usc!samsung!munnari.oz.au!manuel!csc.canberra.edu.au!echo!skcm@ucsd.edu Subject: ? how to route with tcpip To: packet-radio@ucsd.edu In <1991Mar22.193108.10649@xanadu.com> jeff@xanadu.com (Jeff Crilly N6ZFX) writes: >It seems that this should be doable without have to change the routing >table (using arp and route add) on kg6kf. If not, then everyone has to be >able to hear everyone else; and only direct connections would be possible. I haven't found a way yet. :-( I have a similar problem here in Canberra. Hidden Transmitters are the norm. The only solution we have come up with is to have every station you want to talk to that isn't direct pointed to by a route and/or arp entry and they also have to have you defined. We have another problem here in Australia. IP routing isn't legal over the air. (Yet, we're trying) To talk to stations out of line of site we HAVE to use digipeaters. :-( Usually we end up having all the people we normally talk to defined to ARP with a digipeater chain. :-( Carl. ------------------------------ Date: 23 Mar 91 01:51:06 GMT From: swrinde!zaphod.mps.ohio-state.edu!usc!apple!fernwood!portal!cup.portal.com!Jeepster@ucsd.edu Subject: ? how to route with tcpip To: packet-radio@ucsd.edu >... So the question is, how can I get arp to send to kg6kf via wn6i-7 >instead of replying directly? You might try adding the following "route" entry: ax25 route add kg6kf wn6i-7 That's what I had to do to get to a local tcp/ip station thru a digi. John, KF0OU jeepster@cup.portal.com kf0ou@kf0ou.ampr.org [44.20.0.38] Good luck, hope it helps! ------------------------------ Date: 13 Mar 91 16:44:03 GMT From: bonnie.concordia.ca!s3!mlefebvr@uunet.uu.net Subject: Anonymous ftp site for BayComm ??? To: packet-radio@ucsd.edu I am looking for a anonymous ftp site from which I could get BayComm. Is there such a site somewhere ? Thank you. Marc, VE2HQI -- Marc Lefebvre, IREQ: Institut de Recherche d'Hydro-Quebec Analyste Ressources Informatiques 1802 Montee Ste-Julie, Varennes, Prov. Quebec, CANADA J3X 1S1. mlefebvr@ireq.hydro.qc.ca Tel: 514 652-8554 fax: 514 652-8555 ------------------------------ Date: 15 Mar 91 15:04:39 GMT From: orion.oac.uci.edu!ucivax!jarthur!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!news.funet.fi!kannel!huopio@ucsd.edu Subject: Anonymous ftp site for BayComm ??? To: packet-radio@ucsd.edu > I am looking for a anonymous ftp site from which I could get BayComm. > Is there such a site somewhere ? Thank you. > Marc, VE2HQI ------------------------------ Date: 13 Mar 91 15:43:37 GMT From: norand!lusere@uunet.uu.net Subject: anybody RUNNING 9600 ?? To: packet-radio@ucsd.edu I am interested in anyone's experiences in modifying and OPERATING commercial and ham equipment to operate 4800-9600 baud packet. This question is concerned with modifying FM radios for terrestrial links, not satellite work through SSB equipment. In particular, I'd like to hear any experiences with setting up the radios and what performance figures are being seen (like dBm for 10-6 BER, bandwidths for various baudrates, deviation values that worked, radios that worked better than others, etc.) I would like to try to use the older rock-bound commercial gear like Micors, Maxars, MASTR EXEC's, etc. Email is fine, I will summarize and re-post what I hear by that means. Thanks, Ron Luse, KD9KX Norand Data Systems Cedar Rapids, Iowa uunet!norand!ron | norand!ron@uunet.uu.net | kd9kx @ wa0rjt.ia ------------------------------ Date: 13 Mar 91 18:52:48 GMT From: brian@ucsd.edu Subject: anybody RUNNING 9600 ?? To: packet-radio@ucsd.edu In article <47@norand.UUCP> lusere@norand.UUCP (Ron Luse) writes: >I am interested in anyone's experiences in modifying and OPERATING >commercial and ham equipment to operate 4800-9600 baud packet. >I would like to try to use the older rock-bound commercial gear like Micors, >Maxars, MASTR EXEC's, etc. I have been modifying several of these kinds of radios for 9600 bps operation recently. The MASTR Exec-II won't do it easily; it's got a phase modulator and won't do flat dev. The receiver works fine, so we'd thought about shoving the modulation into the temperature compensation voltage line to see if we could move the tempcomp varicap around to get true FM. That might work, but we never got around to trying it. The old lowband Mocom-70 will work at 9600 bps, but our experience is that you really need to use them at 4800, because they have enough frequency drift that the IF might wind up shaving off the edges of received signals if one end is drifting opposite the other. The MICOR will work just fine on 450 MHz, since there is a direct-FM modulator on the TX offset oscillator. The highband and some lowband models have phase modulators, which won't work, and the serrasoid modulator on lowband is hopeless. I did have success in using a 450 channel element in a highband Micor TX, and shoving the modulation into the AFC input of the element, but it wasn't real clean. All bands have plenty of receive IF bandwidth. The Maxar is ideal because its transmitter has a direct-fm varicap modulator. You just pop one end of the 10uF DC blocking cap off and feed the modem into there. The receiver has sufficient IF bandwidth but the detector is loaded down by the deemphasis network that hangs off pin 6 of the detector chip; just chop off the 2.7k resistor and take the output directly from pin 6 to the modem. The Mitrek is pretty much the same as the MAXAR except that you have to feed the transmit modulation directly into the modulation input line for the channel element, since the previous stage is part of the splatter lowpass filter. We'll be using Mitreks on the hill since they have a much better front end than the Maxar does. Hope that helps. - Brian ------------------------------ Date: 20 Mar 91 02:20:42 GMT From: swrinde!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!think.com!linus!linus!mwunix.mitre.org!m21198@ucsd.edu Subject: APLINK To: packet-radio@ucsd.edu If that is not the required syntax for a posting a certain "Elmer" is going to suffer the Wouff Hong. I, and I presume others, would like some information on APLINK bulletin board systems. They seem to be fairly common on hf Amtor and to be linked with the national BBS system. I would like to know: * What is APLINK * What can it do * How is it linked to the rest of the world * Where can the software to run it be obtained (APLINK 5.03) * How is the frequency/band/beam heading scanning accomplished * Any other lurid details: Enquiring minds want, you know Thanks: John WA9FCH McHarry@MITRE.org ------------------------------ Date: 14 Mar 91 18:16:00 GMT From: rosevax!bert.Rosemount.COM!mikef@uunet.uu.net Subject: Baycom Circuit Wanted To: packet-radio@ucsd.edu I am looking for the schematic for the circuit as described in the "BAYCOM" documentation. I realize that there are boards available for the DIGICOM version, but this requires an external power supply. The circuit for the BAYCOM gets power from the RS232 port to power the board. The documentation suggests sending 89 Deutch Marks to an adress in Germany, but I don't have a readily available source for the Deutch Marks and I don't think that I want to send cash (even German) thru the mail. I don't know how else to send for it or how long it would take if I did find a way to order thru Germany. Does anyone have a copy of the schematic for this circuit or suggestions on how to order it? Mikef@bert.rosemount.com ------------------------------ Date: 19 Mar 91 03:52:39 GMT From: usc!zaphod.mps.ohio-state.edu!uwm.edu!bionet!hayes.ims.alaska.edu!acad3.alaska.edu!ftpam1@ucsd.edu Subject: Class C IP address for packet radio? To: packet-radio@ucsd.edu I have some questions for the amateur radio IP community. I have an Arcnet LAN and have been thinking about getting a Class C IP network address for it. This would greatly simplify some projects that I am working on. However, there appear to be some pitfalls. Questions follow: 1. How many of you have Net 44 dependant routing? For an example with KA9Q, Net 44 packets are routed to a KISS serial port and everything else is routed to a campus Ethernet ultimately connected to Internet. 2. How many of you have amateur radio IP nodes with addresses outside Net 44? Have you had problems with routing as described above? Philip Munts N7AHL NRA Extremist, etc. University of Alaska, Fairbanks ------------------------------ Date: 18 Mar 91 18:24:16 GMT From: pilchuck!ssc!tad@uunet.uu.net Subject: Dayton - Digital Suite? To: packet-radio@ucsd.edu In article <3866@mjbtn.JOBSOFT.COM>, root@mjbtn.JOBSOFT.COM (Mark J. Bailey) writes: > Hi, > > Who all is planning to go to Dayton this year? War's over, travel is probably > getting safer again, economy may rebound.... > > Also, will there be another gathering of the "Digital Suite" at the Stouffer > and if so, same place, same day (Friday) and time? I organized the Digital Suite at Stouffers last year. I'm not going to Dayton this year. The Digital Suite was a one time thing on my part. A friend had reserved the Orville Wright Suite the year before, then didn't use it. He gave it to me for free, and I thought it would be fun to gather usenet/fidonet/packet/RTTY hams for a party. It was great fun, but NO WAY could I ever afford to do this again, at least with my money. Tad Cook Seattle, WA Packet: KT7H @ N7ENT.#WWA.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 ------------------------------ Date: 13 Mar 91 21:29:21 GMT From: sdd.hp.com!caen!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!cunixb.cc.columbia.edu!mig@ucsd.edu Subject: Digital repeater network To: packet-radio@ucsd.edu Has anyone looked into the feasibility of creating a digital repeater network? It seems to me that this would allow most any ham to talk to most any other, anywhere, using a simple handheld radio. This seems like a logical extension of the current plans to create an analog system using dynamic links to a long distance backbone. The problem with this scheme is: what happens if a link in the backbone fails; and if more than one user wants to use the system at the same time? It would be a very resource intensive system, anyway. In short: why couldn't the Amateur community set up the equivalent of a digital cellular network with modest user requirements, linked exclusively by radio and therefore immune to damage to the hard-wired systems such as the telephone network. Phil: can you hear me? * * * * * * * ======================= Meir Green * * * * * * * * ======================= mig@cunixb.cc.columbia.edu * * * * * * * ======================= N2JPG ------------------------------ Date: 14 Mar 91 19:01:54 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!rex!rouge!pc.usl.edu!jpd@ucsd.edu Subject: G3RUH 9600 baud users on UO-14 To: packet-radio@ucsd.edu Here's a list of users and their equipment summary, of satellite UO-14. This pacsat operates at 9600 baud full duplex. *UO-14 Users List rev.10 Compiled by JA6FTL 03-10-1990 ======================== Uploader:18 Countries 84 stations are counted (~ Mar.10) CT1DIA DB2OS DD1EG DF5DP DL1YDD DL8NCI DF3LZ DL6KG DL1SBY EA2ARU EA2CLS EA4BPN G3YJO G4WFQ G8NOB G0K8KA G0MJW G3RUH G4AXC G8TZJ G3PJA HB9BOM I2KBD I3RUF IV3IBX I6CGE JA6FTL JR1EDE JR1ING JA1OGZ JA1QHQ JH1TWZ KF4WQ K8YAH K7PYK K8IRC WC8J WA2LQQ W3QNS WB6YMH WD0E W7KRC W9FMW WB0KSL WA9FMQ WD3Q W3GYJ N4HY NK6K N6HBB N5AHD N5BF N3FKV LU8DYF OH2SN OH2YU ON6UG ON5PV ON4KVI PE1CHL PA3DVG PE1HML PE1DNA SM5BVF SM0TER SV1IT SV3KH UA3CR RK3KP VK2BKQ VK3DTO VK5AGR VK7ZBX VK6BMD VK6VV VK5HI VK2XLG VK7ZBX VK3DFI VK2AIT YN1UNI ZL1AOX ZL1TRE ZL1TJK *********************************************** *UO-14 USERS INFO (59 entries Mar.10) ===================================== CALL ! name ! MODEM ! ANT dwnlnk ! RX dwnlnk ! ANT trak ! uplnkPWR ! ! HM-BBS! TNC ! ANT uplnk ! TX uplnk ! Freq trak! CPU remarks* ------------------------------------------------------------------------------- DB2OS ! Peter ! G3RUH ! 2x20 XY Maspro! TS-811E ! OSCAR-ST ! <50W ! ! DK0MAV! TNC2S ! 2x12 XY Maspro! TS-700G ! - ! AT286 16MHz! DD1EG ! Det ! G3RUH ! 2x20 XY Maspro! IC-471H ! AMSAT-DL ! <25W ! ! DB0IZ 1 TNC-2 ! 2x12 XY ! FT-225RD ! - ! V-20 8MHz ! DF3LZ ! Roland! G3RUH ! 2x19 XY ! C500 ! KCT ! 10W ! ! DB0OQ ! TNC2C ! 2x12 XY ! TS-700 ! - ! AT386/387sx! DF5DP ! Bert ! G3RUH ! 2x20 XY Maspro! FT726R ! KCT ! - ! ! DB0IZ ! TNC2A ! 2x12 XY ! IC-475H ! - ! AT386 33M ! DL1YDD ! Hart ! G3RUH ! 2x7 3M BOOM ! FT-780R+AMP ! HB TSR ! 100W ! ! DB0IZ ! TNC2C ! 2x16 3M BOOM ! FT-480R ! - !386/387 33MHz! DL1SBY ! Axel ! G3RUH ! 2x12 XY RHCP ! IC-275 ! MANUAL ! 100W ! ! - ! TNC2C ! 2x20 XY RHCP ! IC-475 ! - ! AT 12MHz. ! DL6KG ! Hans ! G3RUH ! 4x12 ele.horiz! FT-726R ! MirageMTI! <25W ! ! DB0IE ! TNC-2 ! 2x9 wle XY ! TS-711E ! MANUAL ! AT286 16MHz! DL8NCI ! Matt ! G3RUH ! 17 ele vert. ! FT-726R ! MANUAL ! 10/100W !* ! DB0GE ! TNC-2 ! 7 ele vert. ! FT-726R ! MANUAL ! 80286 ! EA2ARU ! JABI ! G3RUH ! 2x19 XY TONNA ! TS-790S ! KCT ! 45W ! ! EA2RCG! TNC-2 ! 2x14 XY TONNA ! TS-790S ! - ! AT286 12MHz! EA2CLS/! Tom ! G3RUH ! KLM 435-40CX ! TS-790A ! KCT/ ! 45W ! kb7hta! EA2CDN! PK-88 ! KLM 2M-22C ! TS-790A ! - ! AT386 33MHz! EA4BPN ! Rafael! NB-96 ! 5/8+5/8 vert. ! TR-851E ! - ! 25W ! ! EA4URE! TNC-2 ! 19ele Hor. ! TS-711E ! - ! AT286 16MHz! G4AXC ! Peter ! G3RUH ! 10 ele XY ! FT-736 ! MANUAL ! 25W ! ! PLYBBS! TINY2 ! 10t Helix ! FT-736 ! MANUAL ! 286 ! G4WFQ ! Dave ! G3RUH ! MBM88EL ! FT736R ! MANUAL ! 25W ! ! GB7DDX! TNC220! KLM14C ! FT736R ! MANUAL ! PC286 8MHz.! G8TZJ ! Andrew! G3RUH ! 17 el XY RHCP ! IC-471E ! HB VIC-20! 60W ! ! GB7FCI! TINY2 ! 6 el XY RHCP ! IC-211E ! HB AFC ! 8086 8MHz ! I3RUF ! GINO ! G3RUH ! 1x21 orriz ! TS-790E ! KCT ! 50W ! ! I3YPJ ! TNC200! 1x16 orriz ! TS-790E ! - ! 386/387 33M! I6CGE ! Alfio ! G3RUH ! 2x17+17 ele ! FT-736 ! KCT ! <80W ! ! I6CGE !MFJ1270! 10+10 ele ! TS-790 ! AUTO ! 286 21MHz ! IV3IBX ! FULVIO! G3RUH ! 2x19 XY ! TS-790E ! KCT ! 50W ! ! IV3PFF! TNC2 ! 2x9 XY ! TS-790S ! - ! 386/287 25M! JA1OGZ ! Akira ! G3RUH ! 2x19 XY ! FT-780 ! KCT ! 30W ! ! JL1ZIJ! TNC-2 ! 12 XY ! TR-9000+amp ! MANUAL ! 5530z-SX ! JA1QHQ ! Ehara ! G3RUH ! F9FT 19 XY*2 ! IC-371 ! MANUAL ! 40W ! ! JL1ZIJ! TNC200! F9FT 9 XY ! IC-251+amp ! MANUAL ! Dynabook ! JH1TWZ ! nojyu ! G3RUH ! 2x25 vert ! FT-736 ! MANUAL ! 50W ! ! JL1ZIJ!TNC-20H! 2x12 vert ! FT-736 ! MANUAL !DynaBook(XT)! JR1EDE ! Kohjin! NB96 ! - ! TS-790S ! KCT/IT1.0! 50W ! ! JL1ZIJ! TINY2 ! - ! TS-790S ! hb AFC ! 386 ! JA6FTL ! sueo ! NB96 ! 19 ele XY ! TS-790S ! KCT/IT1.0! 50W !* ! JA6FTL!mPOWER2! 12 ele XY ! TS-790S+amp ! hb AFC ! 5530z-SX16M! K7PYK ! Wes !PacComm! 2xKLM435-40CX ! FT-736R ! KCT/QT ! 125W ! ! K7PYK ! TNC-2 ! 2xKLM2M-22C ! FT-736R ! KCTune/QT! 386&286 ! K8IRC ! BART ! NB-96 ! 40ele KLM ! FT-736 ! KCT ! 25W ! ! KA0REW! TINY2 ! 20ele Cir. ! FT-736 ! KCT-tuner! XT 10MHz ! K8YAH ! RON ! NB96 ! 6 ele HORZ ! IC-475A ! MANUAL ! 25/200 ! ! W8CQK ! TNC200! 4 ele VERT ! IC275A+amp ! MANUAL ! TURBO XT ! OH2SN ! Pate ! G3RUH ! 19 ele XY ! IC-490E ! Auto ! 150W ! ! OH2RBI! TNC2C ! 2x9 ele. HOR. ! IC-251/Mutek! Auto dplr! 386 !* OH2YU ! Sirpo ! G3RUH ! 2x17 XY RHCP ! FT-736R ! Auto PC ! 20W ! ! OH2RBA! TNC-2 ! 2x10 XY RHCP ! FT-736R ! Manual ! 386sx 16MHz! ON4KVI !RENAULD! G3RUH ! 17ele XY ! TS811 ! MANUAL ! 100W ! ! ON7RC ! TNC2S ! 9ele XY ! TS711 ! MANUAL ! PCXT 8MHz. ! ON5PV ! PHIL ! G3RUH ! 17ele V-H ! FT-726R ! MANUAL ! 40W ! ! ON7RC ! TNC2S ! 6ele V-H ! TM221E ! MANUAL ! 286 16MHz ! ON6UG ! Freddy! G3RUH ! 2M Dish ! FT-736R ! HB Auto ! 80W ! ! ON7RC ! TNC2C ! 9 ele XY ! FT-736R ! - ! 386SX 16MHz! PA3DVG ! AREND ! G3RUH ! 2x17 CD HOR. ! FT-736R ! KCT ! 100W ! ! PI8JYL! PK87 ! 2x15 CD HOR. ! FT-736R ! KCT ! 386 25MHz ! PE1CHL ! Rob ! G3RUH ! 2x15 XY RHCP ! FT-712RH ! fixed elv! 45W !* ! PI8UTR! HB ! 2x6 XY RHCP ! FT-212RH ! - ! Atari520ST ! PE1HML ! Hendrik!G3RUH ! TURNSTYLE ! FT-780 ! NONE ! 12W !* ! PI8ZAA!SCC8530! VERTICAL ! FT-480 ! NONE ! 8MHz PC ! PE1DNA ! Joop ! G3RUH ! 19ele Yagi ! IC-475 !MANUAL(IT)! - ! ! - ! none ! 15ele Yagi ! IC-275 ! - ! AT clone !* RK3KP !ClubSTn! NB96 ! 2x20 XY Maspro! FT-736R ! KCT ! - !* ! RK3KP ! TINY2 ! 2x12 XY ! FT-736 ! MANUAL ! 286 ! SM0TER ! BRUCE ! G3RUH ! 4x14 SKEWED CP! TX790A ! HB 8052 ! 45W ! ! SM0ETV! TINY2 ! 2x9 SKEWED CP! TX790A ! HB AFC ! COMPAQ286 ! SM5BVF ! HENLY ! G3RUH ! 2x13 skewed ! IC-475 ! KCT ! 50W ! ! SM0ETV! TNC200! 2x6 skewed ! IC-275 ! HB ! 386 16MHz ! SV1IT ! Kostas! G3RUH ! 9ele vertical ! TR851 ! MANUAL ! 25W ! ! UOSAT3! TNC-2 ! 19ele vertical! TR751 ! MANUAL !COMPAQLTE386! SV3KH ! Nick ! NB96 ! 2x22ele K1FO ! IC-475 ! MANUAL ! 25W ! ! SV8RV !MFJ1270! 2x9ele TONA ! IC-275 ! - ! 386sx 16MHz! UA3CR ! Leo ! G3RUH ! 9ele F9FT ! FT-736 ! Fixed ! - ! ! RK3KP ! TNC2 ! Helix 10T ! FT-736 ! MANUAL ! XT ! VK2AIT ! Geoff ! G3RUH ! 15 ele HOR ! FT-780R ! MANUAL ! <50W ! ! VK2XY ! TINY2 ! 12 ele HOR ! FT-480R ! MANUAL ! 386 33MHz ! VK3CFI/! Maggie! G3RUH ! Maspro ! IC-251A ! - ! - !* VK3DFI! VK3JAV!mPOWER2! Maspro ! IC-471H ! - ! T3100E ! VK3DTO ! Andy ! G3RUH ! 2x12 XY 18ver ! TS-711A ! - ! - ! ! - !mPOWER2! 2x11 XY ! TS811,IC490A! - ! - ! VK5AGR ! Graham! G3RUH ! 2x20 XY Maspro! IC-271A ! KCT/IT1.0! 25W ! ! VK5WI ! PK87 ! 2x12 XY ! IC-471A ! MANUAL ! AT286 12MHz! VK5HI ! Colin ! G3RUH ! 2x9 ele KLM ! TS-700A ! MANUAL ! 10/100W ! ! - ! TINY2 ! 2x7 ele KLM ! TS-811A ! MANUAL ! 386sx 20MHz! VK6BMD ! Bruce ! G3RUH ! 2x19 el vert ! IC-471H ! MANUAL ! 25W ! ! VK6BBS! FRASH ! 1x17 el vert ! IC-290H ! MANUAL ! XT 8MHz. ! VK6VV ! Arnold! G3RUH ! 16T Helical ! TS-790A ! MANUAL ! 45W ! ! VK6BBS!PAD-205! 14 ele Vert ! TS-790A !JA6FTL AFC! AT286 16MHz! VK7ZBX !Richard! G3RUH ! 16T Helix RHC ! FT-736R ! MANUAL ! 25W ! ! VK7GL ! PK-88 ! 10 XY RHC ! FT-736R ! MANUAL ! 286 20MHz. ! W3GYJ ! ROD ! NB96 ! KLM44CX ! FT-736R ! KCT/QT4.0! 25W ! ! - ! TINY2 ! CR144-20 ! FT-736R ! KCT-Tuner! 386 25MHz. ! W7KRC ! Wally ! NB96 ! KLM44CX ! FT-726R ! XCT/xt ! 25W ! ! K7ZTM ! TINY2 ! KLM22C ! FT-726R ! MANUAL ! Laptop12MHz! W9FMW ! Jack ! NB96 ! 2xKLM 40CX ! IC-475A ! Graftrak ! 100W ! ! KA9LQM! TNC200! 2xKLM 22C ! IC-274A+amp ! 2xKCT ! 286 16MHz ! WA2LQQ ! Rip ! NB96 ! KLM435-40CX ! TS-790A ! KCT/GT ! 45W ! ! WA2SNA! TNC-2 ! KLM2M-22C ! TS-790A ! KCTune/GT! 286 12Mhz. ! WA9FMQ ! Gary ! NB96 ! KLM-14c ! TS-790 ! KCT/QT4.0! - !* ! - !mPOWER2! KLM-22c ! TS-790 ! KCT Tuner! Zeos386sx ! WB6MPQ ! Al ! NB-96 ! KLM-40C ! FT-736 ! MANUAL ! 50W ! !NN2Z.NJ! PK232 ! KLM-22C ! FT-736 ! MANUAL ! 386 20MHz ! WC8J ! Rich ! G3RUH ! 20ele RH-XY ! ICOM 471H ! HB + IT ! - ! ! - ! 1270B ! 40ele XY ! ICOM 275H ! - ! 286 16MHz ! WD3Q ! Eric ! NB96 ! KLM-14c ! TS-790 ! KCT ! - !* ! - !mPOWER2! KLM-22C ! TS-790 ! KCT-tuner! Zeos386sx ! ZL1AOX ! Ian ! G3RUH ! 15T HELIX RHC ! IC-475H ! MANUAL ! <75W ! ! ZL1AB !MFJ1270! KLM22C,5/8COLI! IC-275H ! MANUAL ! XT 10MHz ! ZL1TRE ! Mark ! G3RUH ! KLM40CX ! TS-811A ! MANUAL ! 25W ! ! ZL1AB !MFJ1270! KLM22C ! TS-711A ! MANUAL ! 386 26MHz ! ------------------------------------------------------------------------------- Remarks DL8NCI : developing own ftl0/bdcast s/w. JA6FTL : AFC for 790/736 document is uploaded to this board. PE1CHL : developing PACSAT s/w for Atari ST&PC,TCP/IP PE1CHL version with FTL0 PE1HML : Using NET TCP/IP with ftl0 by PE1CHL PE1DNA : No TNC's 2*OPtoPcScc card by PA0HZP (4 8530s) RK3KP : Amsat-U-Sputnik.Club Stn of Center of Science & Technology for Youth VK3CFI : CFI:Maggie, DFI:Lou WD3Q/WA9FMQ : VITA station in Rosslyn,VA,Washington.DC OH2SN : rx freq controled by 1khz steps with freq.calclat. tracking program ------------------------------------------------------------------------------- PLEASE give me your comment about this format and send your station information with above form via UO-14/AO-16/FO-20.IF you have general remarks, Pse inform me within one line. 73s SUEO ASATO JA6FTL @ja6ftl.jnet6.jpn.asia = = = = = = = = = = = = = = = = = = = = Reposted (without permission ;-) by: -- -- James Dugal, N5KNX Internet: jpd@usl.edu Associate Director Ham packet: n5knx@k5arh Computing Center US Mail: PO Box 42770 Lafayette, LA 70504 University of Southwestern LA. Tel. 318-231-6417 U.S.A. ------------------------------ Date: 15 Mar 91 02:50:40 GMT From: swrinde!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!matt.ksu.ksu.edu!steve@ucsd.edu Subject: Hierarchical Forwarding pounds (#) To: packet-radio@ucsd.edu While using hierarchical addressing on the packet network, what is the use of the pound (#) in the address. An example would be: KB0AGD @ K0VAY.#NEKS.KS.USA.NA I realize that #NEKS means North East Kansas, but what is the # for? A flyback from the days of early sub-netting? -Steve Schallehn, KB0AGD Kansas State University ------------------------------ Date: 18 Mar 91 15:23:41 GMT From: mcsun!ukc!axion!kitkat!blloyd@uunet.uu.net Subject: Hierarchical Forwarding pounds (#) To: packet-radio@ucsd.edu > > The main reason for having the # before the second field is to eliminate any > problem which may arise from having a local hierarchical address which is > the same as a country or continent designator. If, for example, you had a > local address of NA (for Northern Australia, say), then the BBS would try to ^^^^^ > send the message to North America, as that is what NA is supposed to be. > That should have been `might', rather than `would', depending on how the forwarding file was set up. The important thing is that the BBS would have to know the difference between NA meaning Northern Australia and NA meaning North America. Brian ------------------------------ Date: 15 Mar 91 05:16:57 GMT From: brian@ucsd.edu Subject: Hierarchical Forwarding pounds (#) To: packet-radio@ucsd.edu In article <1991Mar15.025040.16086@maverick.ksu.ksu.edu> steve@matt.ksu.ksu.edu (Steve Schallehn) writes: >While using hierarchical addressing on the packet network, what is >the use of the pound (#) in the address. An example would be: >KB0AGD @ K0VAY.#NEKS.KS.USA.NA The # (sharp, octothorp, hash, pound, etc ad nauseum) means that the "regional" name following is a non-standardized one, as if the others were more standardized. In particular, it means that it's a more localized routing indicator than ones that don't have the # in front of them, and can be skipped without error if the station attempting to route doesn't know what it means. (I.e., if you don't know what #NEKS means, you may unhesitatingly skip over it and attempt to route at the KS.USA.NA) (Note that the TELLUS.SOL.MW is implied in this address and need not be supplied.) Do not confuse these with the Internet hierarchical domains. They don't have any thing to do with the DNS, despite their identical format. Grr. - Brian ------------------------------ Date: 19 Mar 91 10:44:24 GMT From: ucselx!bionet!apple!mips!spool.mu.edu!munnari.oz.au!manuel!csc.canberra.edu.au!echo!skcm@ucsd.edu Subject: Hierarchical Forwarding pounds (#) To: packet-radio@ucsd.edu In <1991Mar18.150624.23335@axion.bt.co.uk> blloyd@axion.bt.co.uk (Brian Lloyd) writes: >The idea of scanning from left to right is to find the most direct route to >the destination. If I was to forward a message to you, the BBS would perform >the following steps : >If, on the other hand, I had a direct link to VK6BBS I would forward the >message there, rather than to Australia, as VK6BBS is much closer to you >Australia in general. Hang on. It would be stupid to route only on the first match. I can't believe Internet domain routers operate by only matching the first match from right to left! What you are saying is that EVERY segment of an address must be unique world wide. This, obviously, won't work! The higher levels in the address MUST be taken into consideration when making a match. Carl. ------------------------------ Date: 19 Mar 91 02:50:20 GMT From: munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!snap.adelaide.edu.au@THEORY.TN.CORNELL.EDU Subject: Hierarchical Forwarding pounds (#) To: packet-radio@ucsd.edu Organization: Adelaide University NNTP-Posting-Host: snap.adelaide.edu.au Just a note about the H-addressing. The new AA4RE v2.11 BBS software DOES now search like the internet style. Eg if you have an address of, VK5ZWI@VK5TTY.#SA.AUS.OC the AA4RE BBS can be set to search for, VK5TTY.#SA.AUS.OC #SA.AUS.OC AUS.OC OC The first one that matches is the one that the mail will go to. This means the # is no longer required. BUT I wouldnt go suggesting it be dropped because there are still many BBS systems that dont search that way. Cheers de Grant VK5ZWI Grant Willis (VK5ZWI) - Adelaide University, South Australia - ** 2nd/3rd Year Electrical Engineering Student ** Packet Radio: VK5ZWI@VK5TTY.#SA.AUS.OC AmPR TCP/IP: [44.136.171.11] AARNet/Internet1: e2grwill@snap.adelaide.edu.au ACSnet/Internet2: e2grwill@snap.ua.oz.au Disclaimer: What I write is mine. The Uni has nothing to do with it! ------------------------------ Date: 18 Mar 91 15:06:24 GMT From: mcsun!ukc!axion!kitkat!blloyd@uunet.uu.net Subject: Hierarchical Forwarding pounds (#) To: packet-radio@ucsd.edu ------------------------------ Date: 18 Mar 91 21:52:39 GMT From: swrinde!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu!hpa@ucsd.edu Subject: Hierarchical Forwarding pounds (#) To: packet-radio@ucsd.edu In article <1991Mar18.150624.23335@axion.bt.co.uk> blloyd@zaphod.axion.bt.co.uk writes: >The idea of scanning from left to right is to find the most direct route to >the destination. If I was to forward a message to you, the BBS would perform >the following steps : > >Do I know where VK6ZJM is? >No - do I know where VK6BBS is? >No - do I know where #WA is? >No - do I know where AUS is? >Yes - forward the message in that direction. In proper domain-style addressing, a la the Internet, this would rather be: Do I know where VK6ZJM.WA.AUS is? No Do I know where WA.AUS is? No Do I know where AUS is? Yes Forward in direction AUS Note that the complete tail is a part of the address. Thus, VK6ZJM.WA.AUS could not be confused with, for example W0BBS.WA.US.NA; if my (non-existent) system N9ITP.IL.US.NA connected it would try: W0BBS.WA.US.NA Not found VK6ZJM.WA.AUS Not found WA.US.NA Found -> forward WA.AUS Not found AUS Found -> forward See how easy it becomes? 73 de N9ITP U R 599+9600 BPS KN + @ -- hpa = H. Peter Anvin (in case you wondered) * Heja Sverige! INTERNET: hpa@casbah.acns.nwu.edu FIDONET: 1:115/989.4 HAM RADIO: N9ITP, SM4TKN RBBSNET: 8:970/101.4 ------------------------------ Date: 21 Mar 91 17:07:46 GMT From: swrinde!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!munnari.oz.au!uniwa!cc.curtin.edu.au!nmurrayr@ucsd.edu Subject: Hierarchical Forwarding pounds (#) To: packet-radio@ucsd.edu In article <1991Mar20.110655.23351@axion.bt.co.uk>, blloyd@axion.bt.co.uk (Brian Lloyd) writes: > The problem comes when we > comes across a sub-field which is not unique (eg #WA could be Western > Australia or the Watsui province of Japan). The BBS somehow needs to know > that there is a #WA in Australia and another one in Japan, and at present I > don't think that's possible. What needs to be added, therefore, is some way > of allowing the BBS to forward to #WA.AUS or #WA.JAP This is the point I was trying to make in my original post. There IS such a way, without adding anything. If you scan from right to left, with all fields significant, then there's no ambiguity. To use your example, #WA.AUS is obviously not the same as #WA.JAP, and any software that thinks it is clearly brain-damaged. It's like telling someone that he can't call himself "John Smith" because there's already a "John Jones" somewhere else in the world, regardless of the fact that they're bound to have different higher-order addresses (ie one lives in Sydney and the other lives in Oslo). .....Ron -- =============================================================================== Internet: Murray_RJ@cc.curtin.edu.au | "You can lead a horse to ACSnet: Murray_RJ@cc.cut.oz.au | water, but if you can Bitnet: Murray_RJ%cc.curtin.edu.au@cunyvm.bitnet | get him to float on his UUCP : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ | back you've really got Amateur Packet Radio: VK6ZJM@VK6BBS.#WA.AUS.OC | something" TCP/IP: 44.136.204.14, 44.136.204.19 | -- Murphy's Law I =============================================================================== ------------------------------ Date: 16 Mar 91 20:25:48 GMT From: usc!apple!bionet!hayes.ims.alaska.edu!acad3.alaska.edu!ifjrs@ucsd.edu Subject: Hierarchical Forwarding pounds (#) To: packet-radio@ucsd.edu In article <1991Mar15.025040.16086@maverick.ksu.ksu.edu>, steve@matt.ksu.ksu.edu (Steve Schallehn) writes... >While using hierarchical addressing on the packet network, what is >the use of the pound (#) in the address. An example would be: > >KB0AGD @ K0VAY.#NEKS.KS.USA.NA > >I realize that #NEKS means North East Kansas, but what is the # >for? A flyback from the days of early sub-netting? > This is an excerpt from documentation provided with AA4RE's BB bulletin board program: "W0RLI, VE3GYQ, and N6VV have devised a scheme called hierarchical addressing. Here's their description of their idea: (stuff deleted) "As an example, say that we send something to W0RLI @ W0RLI.CA.USA.NA, and that the only entries that we have in the forward file are for CA. That match would be sufficient to allow the message to be forwarded. If W0RLI were found, that entry would take precedence (because it is more left in the field than CA) and would of course also ensure delivery. The best way to look at it is 'W0RLI AT W0RLI which is in CA which is in USA which is in NA'. So far so good. But the Japanese network wants to use area routing numbers. For example, JA1ABC.42.JPN.AS ... and everyone says, 'So what, let them!' Of course, that is very mature of all of us, but the trouble is that the 42 in that string may also match wild-card ZIP codes that some folks keep in their forward file, such as 42*. The solution we propose is to use an agreed upon key character for designators below the state and province level, and we recommend the octothorpe, '#'. So now the above address would be JA1ABC @ JA1KSO.#42.JPN.AS ..." (etc.) Hope that explains a little more fully the reasoning ... John >-Steve Schallehn, KB0AGD > Kansas State University -- John Stannard ifjrs@acad3.fai.alaska.edu BITNET: IFJRS@ALASKA KL7JL@KL7JL.AK.USA.NA kl7jl.ampr.org [44.22.0.1] "God is the Answer!" "Oh?? ... er, ... What was the Question?" -- ------------------------------ Date: 21 Mar 91 01:49:06 GMT From: sdd.hp.com!spool.mu.edu!munnari.oz.au!manuel!csc.canberra.edu.au!echo!skcm@ucsd.edu Subject: Hierarchical Forwarding pounds (#) To: packet-radio@ucsd.edu In <1991Mar20.110655.23351@axion.bt.co.uk> blloyd@axion.bt.co.uk (Brian Lloyd) writes: >comes across a sub-field which is not unique (eg #WA could be Western >Australia or the Watsui province of Japan). The BBS somehow needs to know >that there is a #WA in Australia and another one in Japan, and at present I Precisly. The WHOLE address needs to be taken into consideration when routing. You cannot route to just "#WA". You must route to "#WA.AUS.OC". >> VK6ZJM) should ONLY be considered for routing purposes if it is shown as part >I think that when someone moves the first person they tell (in the packet >world) is the SYSOP of their local BBS, otherwise that BBS is going to keep >trying to forward mail to them when they're not there. Being able to forward >on the TO field is often very useful - remote SYSOPs often like to have mail >addressed to SYSOP forwarded on to them, for example. Forwarding on the TO field shouldn't be enabled. The ONLY thing the TO field should be used for is allowing the destination station (named in the TO) to read his private mail. It certainly shouldn't be used for forwarding. Most (if not all) programs allow remapping of addresses. If your remote SYSOP (mentioned above) wanted to get his bulletins then they should be remapped to SYSOP@. Maybe things are different in the UK but here in Canberra I don't try to forward mail to individual users. They log on to my BBS to read it. I have 2 users who run PMSs who get mail forwarded and I have asked them to detail their heirarchical addresses as; (for example) vk1mc@vk1mc.vk1kcm.act.aus.oc and no other BBS except me has to have routing information for them. (I also remap vk1mc@vk1kcm to vk1mc@vk1mc.vk1kcm.act.aus.oc as few amateurs understand heirarchical addressing. :-( ) The TO field on Bulletins is another story. :-( It shouldn't be there at all. Carl. vk1kcm@vk1kcm.act.aus.oc skcm@ise.canberra.edu.au 3:620/241.7 [44.136.0.5][14][16] PC/BBS/Xenix ------------------------------ Date: 19 Mar 91 18:21:01 GMT From: swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!vision!mgc!dave@ucsd.edu Subject: Hierarchical Forwarding pounds (#) To: packet-radio@ucsd.edu In article <1991Mar18.150624.23335@axion.bt.co.uk> blloyd@zaphod.axion.bt.co.uk writes: >From article <7492.27e484b1@cc.curtin.edu.au>, by Murray_RJ@cc.curtin.edu.au (Ron Murray): >> >> 1. The whole hierarchical forwarding process as implemented is a kludge (like >> half of the rest of packet's "protocols"): why in hell should it scan left >> to right when it makes more sense to scan right to left? > >The idea of scanning from left to right is to find the most direct route to >the destination. If I was to forward a message to you, the BBS would perform >the following steps : > >Do I know where VK6ZJM is? >No - do I know where VK6BBS is? >No - do I know where #WA is? >No - do I know where AUS is? >Yes - forward the message in that direction. > It's equally true to say: Do I know where AUS is? Yes - continue; No - warn Sysop Do I know where #WA is? Yes - continue; No - forward using AUS Do I know where VK6BBS is ? Yes - continue; No - forward using #WA Do I know where VK6ZJM is ? Yes - forward, No - forward using VK6BBS So right to left is OK, too...and is much more in line with most other mail system algorithms (although that might not count for much!). However, with your method, you might get the answer: VK6ZJM - no VK6BBS - no #WA - yes......it's the Watsui province of Japan, so send it there. Right to left precedence is required. And while I'm pontificating (:-) the left most callsign (in the above examples VK6ZJM) should ONLY be considered for routing purposes if it is shown as part of the domain segment (eg VK6ZJM.VK6BBS.#WA.AUS). Once the '@' is reached in the right to left scan, routing should stop. The reason is this: the originator of the message may know that VK6ZJM has moved QTH - routing software wouldn't always know this. -- Dave Lockwood dave@mgc.uucp G4CLI@GB7DCC._199.GBR.EU Head of Technology ...!uunet!mcsun!ukc!vision!mgc!dave MG Computer Systems Ltd, PO Box 50, Doncaster, DN4 5AW +44-302-738770 ------------------------------ Date: 18 Mar 91 01:13:21 GMT From: sdd.hp.com!samsung!munnari.oz.au!uniwa!vax7!nmurrayr@ucsd.edu Subject: Hierarchical Forwarding pounds (#) To: packet-radio@ucsd.edu In article <1991Mar16.202548.18162@ims.alaska.edu>, ifjrs@acad3.alaska.edu (STANNARD JOHN R) writes: (quoting from the AA4RE documentation) > > "As an example, say that we send something to W0RLI @ W0RLI.CA.USA.NA, > and that the only entries that we have in the forward file are for > CA. That match would be sufficient to allow the message to be forwarded. > If W0RLI were found, that entry would take precedence (because > it is more left in the field than CA) and would of course also > ensure delivery. The best way to look at it is 'W0RLI AT W0RLI > which is in CA which is in USA which is in NA'. So far so good. > > But the Japanese network wants to use area routing numbers. For > example, JA1ABC.42.JPN.AS ... and everyone says, 'So what, let > them!' Of course, that is very mature of all of us, but the trouble > is that the 42 in that string may also match wild-card ZIP codes > that some folks keep in their forward file, such as 42*. The > solution we propose is to use an agreed upon key character for > designators below the state and province level, and we recommend > the octothorpe, '#'. > So far, it all seems to make sense (even if about as easy to read as Attila the Hun's laundry list). Here in Australia they went a little further... If you look at my .sig below, you'll see the #WA between the BBS call and the abbreviation for Australia. We were told that this was necessary (rather than the much more obvious "WA" for Western Australia) because the hierarchical forwarding software would assume that it was the abbreviation for Washington state in the US because it scans the address from left to right. This leads me to conclude that either: 1. The whole hierarchical forwarding process as implemented is a kludge (like half of the rest of packet's "protocols"): why in hell should it scan left to right when it makes more sense to scan right to left? Internet domain names are scanned in this fashion. It's a bit like telling someone that he can't call himself "John Smith" because there's already a John Smith somewhere else. Or worse, that he has to call himself #Fred Bloggs because there's a Fred Bloggs in Outer Mongolia. or 2. Someone in Australia mis-read the documentation and decided that this name change was necessary. This is probably the more likely. Suggestions and corrections welcome. ....Ron -- =============================================================================== Internet: Murray_RJ@cc.curtin.edu.au | "You can lead a horse to ACSnet: Murray_RJ@cc.cut.oz.au | water, but if you can Bitnet: Murray_RJ%cc.curtin.edu.au@cunyvm.bitnet | get him to float on his UUCP : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ | back you've really got Amateur Packet Radio: VK6ZJM@VK6BBS.#WA.AUS.OC | something" TCP/IP: 44.136.204.14, 44.136.204.19 | -- Murphy's Law I =============================================================================== ------------------------------ Date: 20 Mar 91 11:06:55 GMT From: gatech!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!axion!kitkat!blloyd@ucsd.edu Subject: Hierarchical Forwarding pounds (#) To: packet-radio@ucsd.edu ------------------------------ Date: 20 Mar 91 21:27:34 GMT From: swrinde!elroy.jpl.nasa.gov!usc!apple!erc@ucsd.edu Subject: How to get email from packet??? To: packet-radio@ucsd.edu I'm a relative newcomer to the world of packet radio, and am interested in getting email via packet. How might this be accomplished? If someone could point me to references, books, etc. that might help (something current) I'd really appreciate it! Ed Carp, N7EKG/6 Alameda, CA -- Ed Carp N7EKG/6 erc@khijol.UUCP ...uunet!khijol!erc Alameda, CA Computers HAVE caused a revolution in how much information we can safely ignore! --robs@ux1.cso.uiuc.edu (Rob Schaeffer) ------------------------------ Date: 15 Mar 91 20:06:53 GMT From: hpl-opus!hpnmdla!alanb@hplabs.hpl.hp.com Subject: Inadvertant "clear screen" To: packet-radio@ucsd.edu In rec.radio.amateur.packet, andrem@pyrman2.pyramid.com (Andre Molyneux) writes: >I've been experiencing an odd problem with my packet station. Basically, >my screen gets cleared by the transmissions of other stations. The problem ...>developed as follows: >I understand that I can set the TNC to filter out specific characters that >are incompatible with the terminal in use. Obviously ctrl-z is one of them, >but I need to find what the other "clear screen" character is. Any idea on >how I should go about this? The ASCII "formfeed" character (12 decimal) is used as a "clear screen" command by many terminals. AL N1AL ------------------------------ Date: 18 Mar 91 19:37:51 GMT From: swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac, Subject: Inadvertant "clear screen" To: packet-radio@ucsd.edu In article <2285@ke4zv.UUCP> gary@ke4zv.UUCP (Gary Coffman) writes: >formfeed will be one character you'll want to filter. Most nodes, and >all TCP/IP stations transmit some packets in fully binary mode so you >will often have characters on your screen in monitor mode that will The 1.1.7 tapr firmware (MFJ adds WEFAX and calls it 1.2.7) includes a MNONAX25 ON/OFF command, to eliminate tcp/ip, netrom routing, and other packets having a PID different from that of AX.25. 73, -- -- James Dugal, N5KNX Internet: jpd@usl.edu Associate Director Ham packet: n5knx@k5arh Computing Center US Mail: PO Box 42770 Lafayette, LA 70504 University of Southwestern LA. Tel. 318-231-6417 U.S.A. ------------------------------ Date: 17 Mar 91 18:45:47 GMT From: usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac, Subject: Inadvertant "clear screen" To: packet-radio@ucsd.edu In article <148305@pyramid.pyramid.com> andrem@pyrman2.pyramid.com (Andre Molyneux) writes: >I've been experiencing an odd problem with my packet station. Basically, >my screen gets cleared by the transmissions of other stations. The problem >developed as follows: [deleted] >I understand that I can set the TNC to filter out specific characters that >are incompatible with the terminal in use. Obviously ctrl-z is one of them, >but I need to find what the other "clear screen" character is. Any idea on >how I should go about this? (I've asked another packet operator to see if >he get's any "unusual" characters from the node in question. He reports >that he doesn't see anything out of the ordinary when he connects to this >node.) Some TNCs have a filter command that removes all non-printing characters from the incoming stream. I don't believe the MFJ 1274 is one of them. I think you are limited to 10 characters in your filter list. Certainly formfeed will be one character you'll want to filter. Most nodes, and all TCP/IP stations transmit some packets in fully binary mode so you will often have characters on your screen in monitor mode that will cause your terminal to do strange things. You'll need to sit down with your terminal book and TNC manual and figure out what to kill. Gary KE4ZV ------------------------------ Date: 14 Mar 91 23:39:46 GMT From: pyramid!andrem@hplabs.hpl.hp.com Subject: Inadvertant "clear screen" To: packet-radio@ucsd.edu I've been experiencing an odd problem with my packet station. Basically, my screen gets cleared by the transmissions of other stations. The problem developed as follows: I bought a MFJ 1274 TNC and hooked it up to a XT clone using Procomm. Everything ran fine. Decided to free up the PC by getting a dedicated terminal for packet. Borrowed a Lee Data (don't remember the model #) terminal from a friend, which ran in VT200 emulation mode. Found that the screen would get cleared everytime my TNC tried to display a packet from a local node (SFO on 145.01 in the SF bay area). I connected to this node and found that any option I chose would result in a cleared screen. I didn't worry about it too much considering that the terminal was a loaner. Well, this past weekend I went to the Foothill College swapmeet and picked up an old Televideo terminal (TVI 321???). Fired it up and found that it too would get its screen cleared by the same node. In addition, I found that the character used to indicate the end of a message on mailboxes (ctrl-z), also clears the screen of the Televideo (ctrl-z didn't bother the Lee Data). I understand that I can set the TNC to filter out specific characters that are incompatible with the terminal in use. Obviously ctrl-z is one of them, but I need to find what the other "clear screen" character is. Any idea on how I should go about this? (I've asked another packet operator to see if he get's any "unusual" characters from the node in question. He reports that he doesn't see anything out of the ordinary when he connects to this node.) +---------------------------------------------------+--------------------------+ | Andre Molyneux KA7WVV andrem@pyrman2.pyramid.com |*** GENERIC DISCLAIMER ***| +---------------------------------------------------+--------------------------+ | -=-------- PYRAMID TECHNOLOGY CORPORATION |All the usual disclaimers | | ---===------ 1295 Charleston Road |apply although, as far as | | -----=====---- Mountain View, California 94043 |I can tell, my employer | |-------=======-- (415) 965-7200 |doesn't care what I think!| +---------------------------------------------------+--------------------------+ ------------------------------ Date: 20 Mar 91 04:20:39 GMT From: uhccux!uhcmtg.phys.hawaii.edu!tony@ames.arpa Subject: KA9Q & mbox BBS forwarding To: packet-radio@ucsd.edu I need some assistance from any kind soul in mbox message forwarding. I'm trying to setup a PC running KA9Q to forward messages to non-TCP/IP stations. Suppose I want messages for AH6BW to be forwarded to AH6BW@AH6BW-2 where AH6BW-2 is a different machine that doesn't handle TCP/IP. In my /alias file I have: ah6bw ah6bw@ah6bw-10 In my /spool/forward.bbs file I have: ---- ah6bw-10 ax25 ax1 ah6bw-10 ah6bw ---- When the SMTP timer kicks in I get a message about ah6bw-10 being an unknown host (as if it wants to deliver the message via TCP/IP and it fails on a hostname lookup). Shouldn't the entry in the forward.bbs file be enough to tell NOS that ah6bw-2 is NOT a TCP/IP station? What am I missing here? I'm running the latest version of NOS from thumper. Tony AH6BW tony@uhcmtg.phys.hawaii.edu ------------------------------ Date: 21 Mar 91 17:13:53 GMT From: swrinde!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!munnari.oz.au!uniwa!cc.curtin.edu.au!nmurrayr@ucsd.edu Subject: KA9Q v910308 problems To: packet-radio@ucsd.edu When I run KA9Q version 910308 on my XT clone, it works fine on a SLIP link to my AT at 9600 baud. If I try an AX25 connect to a non-TCP/IP system, it crashes after a few K of data has been received. I don't think it happens on a Telnet session over AX25, but I can't test it due to a complete lack of other stations here in Perth running TCP/IP (Philistines!). It certainly didn't crash the one time I tried a Telnet to it from someone else's computer, but I might have been lucky. Has anyone else experienced this? .....Ron -- =============================================================================== Internet: Murray_RJ@cc.curtin.edu.au | "You can lead a horse to ACSnet: Murray_RJ@cc.cut.oz.au | water, but if you can Bitnet: Murray_RJ%cc.curtin.edu.au@cunyvm.bitnet | get him to float on his UUCP : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ | back you've really got Amateur Packet Radio: VK6ZJM@VK6BBS.#WA.AUS.OC | something" TCP/IP: 44.136.204.14, 44.136.204.19 | -- Murphy's Law I =============================================================================== ------------------------------ Date: 17 Mar 91 00:44:36 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!matt.ksu.ksu.edu!steve@ucsd.edu Subject: KAM dual-mode enhancement To: packet-radio@ucsd.edu [hopefully there is enough interest to merit this reply] A question came over the net a few weeks ago asking if a Kantronics KAM could do both VHF packet and HF RTTY operation simultaneously. After talking to Karl Medcalf of Kantronics, I have just found out that Kantronics is testing new firmware to allow any HF operation and VHF packet operation to occur at the same time on a Kantronics KAM. With the firmware upgrade and a specialized program running on a PC, one could, for example, log into a DX cluster and work RTTY at the same time. Availability for the upgrade scheduled mid-spring. Pricing for upgrades is somewhere around $100. --- -Steve Schallehn, KB0AGD Kansas State University PS: I am not affiliated with Kantronics. ------------------------------ Date: 15 Mar 91 18:16:15 GMT From: swrinde!zaphod.mps.ohio-state.edu!caen!kuhub.cc.ukans.edu!zeus.unomaha.edu!acmnews@ucsd.edu Subject: Monthly On-Line Elmers Resource Directory To: packet-radio@ucsd.edu As part of the multi-pronged strategy of Project SAVE THE BANDWIDTH, I will now put out a call for On-Line Elmers. These are people, who by virtue of skill and knowledge in an area of expertise in ham radio, are willing to field E-mail by readers of the rec.radio.* groups. Volunteers need only send me their name, E-mail address, and area of expertise. "Generalists" or "Miscellaneous" Elmers are also quite welcome. Naturally, the more that volunteer, the more the work is distributed. If upon volunteering, you are unable to meet your obligations, simply write to me and I will remove your name from the list. I could also add that because of "personal committments" or "career broadening" you no longer are available to Elmer on a regular basis. I will be the point-of-contact for this project. I will maintain the list, post it to the groups at least monthly, and have the latest copy placed in the supplemental archives at ftp.cs.buffalo.edu in subdirectory pub/ham-radio. Here is the latest version of the list. If you sent me mail and are not on it, please resend as it may have been lost on the way or once it reached my host. 73, Paul, KD3FU ACMNEWS@zeus.unomaha.edu uunet!unocss!zeus!acmnews 137.48.1.1 ps67@umail.umd.edu uunet!mimsy!umail!ps67 128.8.10.28 ON-LINE Elmers Resource Directory (as of 03/15/91) ------------------------------------------------------ Dan Halbert, KB1RT QTH is West Newton, MA, near Boston. halbert@crl.dec.com Building homebrew QRP gear, Advice on simple antennas ------------------------------------------------------ Paul W. Schleck, KD3FU acmnews@zeus.unomaha.edu ps67@umail.umd.edu Miscellaneous, Internet, College Clubs ------------------------------------------------------ Mike Waters AA4MW/7 waters@nddsun1.sps.mot.com Miscellaneous ------------------------------------------------------ ------------------------------ Date: 22 Mar 91 00:42:34 GMT From: dog.ee.lbl.gov!ncis.tis.llnl.gov!lll-winken!uwm.edu!caen!kuhub.cc.ukans.edu!zeus.unomaha.edu!acmnews@ucsd.edu Subject: Monthly On-Line Elmers Resource Directory To: packet-radio@ucsd.edu (Note: Although less than a month has gone by, my list of volunteers has nearly quadrupled. Also, someone suggested that I add a list of suggested areas of expertise. So, here is the latest list...) As part of the multi-pronged strategy of Project SAVE THE BANDWIDTH, I will be compiling a directory of On-Line Elmers. These are people who, by virtue of skill and knowledge in an area of expertise in ham radio, are willing to field E-mail by readers of the rec.radio.* groups. Volunteers need only send me their name, E-mail address, and area of expertise. As requested, here is a suggested list of areas of expertise that are needed: 1. Volunteer Examiners 2. Novice Instructors 3. DX'ers and Contesters 4. QRP 5. Homebrewers 6. Packet Ops (both AX.25 and TCP/IP) 7. VHF and Repeaters 8. OSCAR and other satellites 9. MARS (Military Affiliate Radio System) 10. CAP (Civil Air Patrol) 11. ARES (Amateur Radio Emergency Service) 12. RACES (Radio Amateur Civil Emergency Service) 13. Skywarn (Amateur Weather Spotters) 14. ARRL Field Organization (American Radio Relay League) "Generalist" or "Miscellaneous" Elmers are also quite welcome. Naturally, the more that volunteer, the more the work is distributed. If upon volunteering, you are unable to meet your obligations, simply write to me and I will remove your name from the list. I could also add that because of "personal committments" or "career broadening" you no longer are available to Elmer on a regular basis. I will be the point-of-contact for this project. I will maintain the list, post it to the groups at least monthly, and have the latest copy placed in the supplemental archives at ftp.cs.buffalo.edu in subdirectory pub/ham-radio. Here is the latest version of the list. If you sent me mail and are not on it, please resend as it may have been lost on the way or once it reached my host. 73, Paul, KD3FU ACMNEWS@zeus.unomaha.edu uunet!unocss!zeus!acmnews 137.48.1.1 ps67@umail.umd.edu uunet!mimsy!umail!ps67 128.8.10.28 ON-LINE Elmers Resource Directory (as of 03/21/91) ----------------------------------------------------- John Brewer WB5OAU brewer@anarky.enet.dec.com Miscellaneous, Wire antennas, ------------------------------------------------------ Dan Halbert, KB1RT QTH is West Newton, MA, near Boston. halbert@crl.dec.com Building homebrew QRP gear, Advice on simple antennas ----------------------------------------------------- R.D. Keys Dept. of Crop Science NCSU Raleigh, NC 27695-7620 rdkeys@ccvr1.cc.ncsu.edu de NA4G, "Boat Anchor Bob", an ol' cw fart ..... If I can be of assistance in older equipment, junk-boxing your way to hamdom, the cheapskate's approach, let me know. 22 yrs a ham, extra class, mostly cw, mostly boat anchors and radio in the traditional sense. {Telegraphy has been in my family for almost 100 years!} ------------------------------------------------------ Dave Potter, K1MBO potter@think.com electronics theory, regulations, antennas and transmission lines, operating practices. ------------------------------------------------------ Tony Reeves KK6XC QTH Beach Area of So. Los Angeles Torrance, Redondo Beach, Hermosa Beach, Manhattan beach tony@hacgate.scg.hac.com Novice training, local VE for Novice-Tech tests, General questions ------------------------------------------------------ Paul W. Schleck, KD3FU acmnews@zeus.unomaha.edu ps67@umail.umd.edu Miscellaneous, Internet, College Clubs ------------------------------------------------------ Tom Sefranek WA1RHP tcs@ll.mit.edu Elmering for the last 20 years. Almost all fields, Specializing in power supplies, micro-controllers, antennas ------------------------------------------------------ Diana L. Syriac Leominster, MA dls@genrad.com KC1SP QSL Bureaus (how to use them) Volunteer Examiner Service (how to become one) Macintosh Hamstacks Civil Air Patrol ------------------------------------------------------ Mike Waters AA4MW/7 waters@nddsun1.sps.mot.com Miscellaneous ------------------------------------------------------ Bob Witte HP Colorado Springs Division bobw@col.hp.com P.O. Box 2197 Phone:(719) 590-3230 Colorado Springs, CO 80901 Radio: KB0CY "All Disclaimers Apply." Miscellaneous ------------------------------------------------------- End of Directory ------------------------------ Date: 14 Mar 91 15:24:00 GMT From: swrinde!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!boulder!bohemia!f510.n5000.z200.METRONET.ORG!Gary.Box@ucsd.edu Subject: New packet user To: packet-radio@ucsd.edu Hi Clay and welcome to Ham Radio and Packet. I run packet with little more than a terminal program on an old CPM machine and it works fine. One thing you will need is some local help for finding your local BBS on packet; equipment set up; etc. Thats a little tough to do here. Once on the air, you can connect to the local BBS and send messages all over the world. Most BBS's have a help file that will describe the commands. While connected to any other packet station, or even to your own mailbox, your computer works as a terminal, so I would n't worry about operating system. Just have a terminal emulator program available. You can work up to a dedicated package like LanLink (which is for DOS) later. By the way, when you get running send me a note. My call is N0JCG and my home BBS is WA0CQG. You would address a message to me at N0JCG @ WA0CQG. I think you'l like packet. I QSO with England, Greece and Israel regularly with it. --- * Origin: The Computer Lab (200:5000/510) -- ============================================================================= Gary Box - via MetroNet node 200:5000/301 The Bohemia BBS System, Boulder Colorado (303)449-8946 UUCP: Gary.Box@f510.n5000.z200.METRONET.ORG or : ...!boulder!bohemia.METRONET.ORG!510!Gary.Box ============================================================================= ------------------------------ Date: 21 Mar 91 21:24:28 GMT From: news-mail-gateway@ucsd.edu Subject: No Subject To: packet-radio@ucsd.edu ------------------------------ Date: 13 Mar 91 22:08:24 GMT From: swrinde!zaphod.mps.ohio-state.edu!usc!apple!bionet!hayes.ims.alaska.edu!acad3.alaska.edu!ifjrs@ucsd.edu Subject: Packet BBS SID and personal mbox reverse forward To: packet-radio@ucsd.edu In article <3091@oucsace.cs.OHIOU.EDU>, farrar@oucsace.cs.ohiou.edu (J. Craig Farrar) writes... >Problem: Home BBS (MBL) will forward to personal mailbox in my TNC, but the TNC >will not respond to the reverse forward poll when it sees it. > (Stuff deleted) > >The MBL board is a busy one and successfully forwards and reverse forwards >with several neighboring boards. The problem with the TNC mailboxes seems >to be that they don't have a '$' in their SID. That is reasonable since they >are intended for private mail forwarding and not the flood forwarding that >needs BID checking. However, it causes the reverse forwarding to fail because >the full-service BBS stations seem to require it. > >Checking with the sysop of the MBL board we learn that this is a built-in >feature and can't be changed. Is this really true? It would really be nice >to have reverse forwarding work as it has been advertised, but we seem to have >an impasse. Do any of you in the net know a solution? > A user here in Alaska has a KAM with the same problem--he adds the SID _with_ the '$' in his "connect" text msg--it seems to work quite well. Hope this works for you in _your_ situation. 73, John >--------- >J. Craig Farrar farrar@oucsace.cs.ohiou.edu W8UKE@KA8DRR.OH.USA.NA >Ohio University, Athens, Ohio -- John Stannard ifjrs@acad3.fai.alaska.edu BITNET: IFJRS@ALASKA KL7JL@KL7JL.AK.USA.NA kl7jl.ampr.org [44.22.0.1] "God is the Answer!" "Oh?? ... er, ... What was the Question?" -- ------------------------------ Date: 20 Mar 91 20:27:21 GMT From: newstop!eastapps!Sun.COM!kerskine@sun.com Subject: PK-88 Pinouts To: packet-radio@ucsd.edu I bought a PK-88 a few months ago and am now ready to use it, but I seem to have misplaced the manual. Can anyone tell me the pinouts on the 8 pin tx/rc connector? Thanks....Keith Erskine - KA1RHO ps: I'm connecting this to an old Yaesu FT-22R 2M all-band. Any special considerations I should know about? - thx ke ------------------------------ Date: 21 Mar 91 17:34:42 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!tandem!netcom!edg@ucsd.edu Subject: PK-88 Pinouts To: packet-radio@ucsd.edu In article <4984@eastapps.East.Sun.COM> kerskine@Sun.COM (Keith Erskine - Sun Technical Marketing - Boston) writes: >I bought a PK-88 a few months ago and am now ready to use it, >but I seem to have misplaced the manual. Can anyone tell me >the pinouts on the 8 pin tx/rc connector? 1 Ground Brown 2 Mic Audio White 3 Push-To-Talk Red 8 Receive Audio Green 7 Squelch Input Black (optional) Using the provided cable, follow the colors above to match up with the manual, when you find it. By the way, I am reasonably computer literate, network literate and radio literate and I wouldn't attempt to do much with this TNC without the book. It's worth getting another copy from AEA, since the TNC is loaded with commands and features. -edg -- Ed Greenberg, WB2GOH/6 San Jose, CA edg@netcom.COM ------------------------------ Date: 17 Mar 91 02:39:05 GMT From: ogicse!unicorn!n9041169@ucsd.edu Subject: portable packet To: packet-radio@ucsd.edu I do not own a packet although I am thinking about buying one soon, one thing you might try though is purchasing one of the new breed of "notebook" size pc laptops. Most I have seen come with serial and parallel ports, vga lcd, screen and a fair amount of memory, and a 1.44mb 3.5in disk - all for between 1800-3600$. Zeos, Austin and a few others all make IBM compatible machines with 80286 12-16hz processors for about 2000 dolloars. Take a look in the March Computer Shopper for a run- down on most the latest of these notebook sized machines weighing generally less than 6lb. hope you find what you're looking for, Chris ------------------------------ Date: 14 Mar 91 19:37:07 GMT From: swrinde!cs.utexas.edu!ut-emx!ccwf.cc.utexas.edu!wdlee@ucsd.edu Subject: portable packet To: packet-radio@ucsd.edu I am planning a cross country expedition (by *RAIL*) and would like to take along my packet radio system. I have a couple of issues I'd like to discuss: DUMB TERMINALS (or, 'Why is this lap-top so heavy?') My girlfriend agreed to loan me her laptop computer (bless her heart) but it just HURLS RF at 145.01 MHz. In addition, I'd just use it to run PROCOMM anyway. (It weighs more than my entire packet setup!) So I was at the mall this morning and saw something that I found intriguing (as Cmdr. Data would say). Have you seen the Casio B.O.S.S. model SF-9500? or model SF-800? These are little clock, calendar, memo, telephone number, rolodex, scratch your back, do everything hand-held LCD display things with little alpha-numeric keypads... and guess what... There's a serial port on the little guy and the literature states that "you can hook it up to your PC..."! Has anyone heard of any sort of modern little hand held LCD thing being used as a dumb (RS232) terminal? I'd only need a couple of lines (with scrollback perhaps) and I'd let my TNC do all the work. In closing, the other issue I was concerned about is... Should I even bother attempting to try 2 meter work from within a huge steel rail car moving at 80 mph? I love trains and have traveled coast to coast more than 10 times (I don't fly), and I have met other hams aboard the train with their HT's by their side. What do you think? All aboard! David their HT's on their belts ------------------------------ Date: 14 Mar 91 22:40:55 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!know!tegra!vail@ucsd.edu Subject: portable packet To: packet-radio@ucsd.edu In article <45605@ut-emx.uucp> wdlee@ccwf.cc.utexas.edu (david lee) writes: DUMB TERMINALS (or, 'Why is this lap-top so heavy?') My girlfriend agreed to loan me her laptop computer (bless her heart) but it just HURLS RF at 145.01 MHz. In addition, I'd just use it to run PROCOMM anyway. (It weighs more than my entire packet setup!) So I was at the mall this morning and saw something that I found intriguing (as Cmdr. Data would say). Have you seen the Casio B.O.S.S. model SF-9500? or model SF-800? These are little clock, calendar, memo, telephone number, rolodex, scratch your back, do everything hand-held LCD display things with little alpha-numeric keypads... and guess what... There's a serial port on the little guy and the literature states that "you can hook it up to your PC..."! Has anyone heard of any sort of modern little hand held LCD thing being used as a dumb (RS232) terminal? I'd only need a couple of lines (with scrollback perhaps) and I'd let my TNC do all the work. I had the idea of connecting tha cable from my BOSS into the speaker jack of my IC-24, put a NOS prompt on the screen and send it in to QST as portable packet. The answere to your question is: no. The BOSS will transfer data to another computer running the appropriate software with a simple Intel Hex based protocol. There is no "terminal mode" although I bet Casio could sell a few more BOSSs if they added one. The BOSS is a really neat and useful device although the only amateur radio uses I have found for it are alternate time (GMT) and saving repeater control codes and frequency information for reference. "theobromine: a compound which, contrary to it's name, contains neither bromine nor God" -- David Throop _____ | | Johnathan Vail | n1dxg@tegra.com |Tegra| (508) 663-7435 | N1DXG@448.625-(WorldNet) ----- jv@n1dxg.ampr.org {...sun!sunne ..uunet}!tegra!vail ------------------------------ Date: 16 Mar 91 15:45:34 GMT From: swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac, Subject: portable packet To: packet-radio@ucsd.edu In article <45605@ut-emx.uucp> wdlee@ccwf.cc.utexas.edu (david lee) writes: >I am planning a cross country expedition (by *RAIL*) and would like >to take along my packet radio system. I have a couple of issues I'd like >to discuss: > >DUMB TERMINALS (or, 'Why is this lap-top so heavy?') A friend of mine uses his Sharp Wizard with a pocket packet TNC. The major problems are the screen and keyboard being smaller than standard. Most packeteers format their messages for 80 column and this makes it hard to read on a 40 col display. Secondly, the keyboards on these little jewels aren't really suited to touch typing. Keyboard QSOs are slow anyway, but having to hunt and peck on the little keyboard makes it intolerable to me anyway. The new Wizard (the one with the QWERTY keyboard) has a serial port that works up to 9600 baud. I don't know the baud rates available on the BOSS series. I have another friend who has one of these and I'll ask him. The consensus around here is that the Wizard is a better value than the BOSS, but if you're only going to use it as a terminal, then that probably doesn't matter. One lightweight system I've used for portable packet is the Radio Shack Mod 100. It suffers from the 40 col screen, but the keyboard is decent and it has a built in terminal program. Used Mod 100s should be lots cheaper than the BOSS or the Wizard. RCA used to make a simple dumb terminal with a 2 line 80 col display and a full size keyboard. These are a little smaller than a Mod 100 and I've seen them at hamfests for $25. Your HT should work fine on the train. I'd make a twinlead J-pole and tape it to a window for best results. Between your terminal and your TNC, there should be enough digital hash that I'd want to locate the antenna a few feet from the noise. Also the extra gain of the J-pole will help on voice too. Do be aware that train power may not be 110 VAC 60 Hertz. So battery elimination or charging may become a problem if you don't have the proper adapters. Check this out ahead of time with your travel agent or call the train company's maintence yard and talk to their electrician. Have fun! Gary KE4ZV ------------------------------ Date: 19 Mar 91 03:45:33 GMT From: ARDSLEY.BUSINESS.UWO.CA!Mark@ucbvax.berkeley.edu Subject: SMTP Mail on PBBS? To: packet-radio@ucsd.edu I have been using KA9Q nos for quite a while now. I am interested in trying something else for awhile. Unforunately, I don't find NOS stable enough, or quick enough for AX25 use. I would like to have a bbs program that supports SMTP mail plus the messages come in as one file per user. Does anyone know of such a program? There is MSYS here, but it stores each message separately. Any ideas? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mark Bramwell, VE3PZR Located in sunny London, Ontario Internet: Mark@ARDSLEY.business.uwo.ca IP Address: 129.100.29.33 Packet: VE3PZR @ VE3GYQ UWO Phone: (519) 661-3714 ------------------------------ Date: 21 Mar 91 17:13:28 GMT From: agate!eos!aio!gamorris@ucbvax.berkeley.edu Subject: STS-37 SAREX Information Summary To: packet-radio@ucsd.edu STS-37 SAREX Shuttle Amateur Radio EXperiment Information Summary Table of Contents ----------------- o Introduction o Keplerian Element Set o SAREX Uplink/Downlink Frequencies o SAREX Packet Operating Hints o Mission Audio Retransmissions o W5RRR Special Event Station o W1AW Voice Bulletins o AMSAT Net Operations o JSC INFO BBS o NASA Select Video Broadcast o STS-37 SAREX Timeline Revised: 910321 N5QWC ============================================================ SAREX Introduction STS-37 Crew: N5RAW, Steve Nagel, Mission Commander KB5AWP, Ken Cameron, Pilot N5QWL, Jay Apt, Mission Specialist N5RAX, Linda Godwin, Mission Specialist N5SCW, Jerry Ross, Mission Specialist SAREX equipment on this flight includes a 2m (144-146 Mhz) Motorola radio (output 2.3 watts), Robot 1200C slow scan convertor, Heath HK-21 packet TNC, a 70cm FSTV receiver, a video camera, and a Monitor/VCR. Planned operations include voice contacts, packet robot, downlinking orbiter video via SSTV, uplinking FSTV video to the orbiter. During sleep periods and when no other SAREX activities are scheduled the equipment will be left on in packet robot mode. If time permits the crew will setup SAREX to transmit SSTV using orbiter video cameras during the GRO satellite release and during the EVA. The GRO satellite release is scheduled for MET 2/03:00 (2 days 3 hours after launch) for 1 hour. The EVA is scheduled for MET 2/22:00 thru MET 3/05:00. With 5 hams on the flight there may be many unscheduled opportunities for operation, I suggest you monitor both downlink frequencies on all passes starting with orbit 1 until landing, even during sleep periods you could hear something other than packet. Contacts between the shuttle and school children will be retransmitted by W5RRR, see timeline for times, and W5RRR frequency information below. ============================================================ Keplerian Element Set STS-37 1 00037U 91 94.64868056 .00023000 17236-3 0 49 2 00037 28.4683 237.6443 0006982 279.6613 80.3332 15.37985111 23 Satellite: STS-37 Epoch time: 91094.64868056 Element set: JSC-004 Inclination: 28.4683 deg Space Shuttle Flight STS-37 RA of node: 237.6443 deg Keplerian Elements Eccentricity: .0006982 from pre-launch post OMS-2 vector Arg of perigee: 279.6613 deg Launch: 04 APR 91 14:20 UTC Mean anomaly: 80.3332 deg Mean motion: 15.37985111 rev/day W5RRR Decay rate: 2.30E-04 rev/day^2 NASA Johnson Space Center Epoch rev: 2 ============================================================ SAREX Uplink/Downlink Frequencies Downlink/Uplink Frequencies for Voice/Packet/SSTV to be used on Upcoming Mission Get out your HTUs and HT programming manuals. You will want to program your 2 meter FM transceivers with the following information. Note that only stations with prior arrangements can uplink FSTV signals (special authorization is required from the FCC). It is expected that uplinking FSTV will require about 15kw ERP. FSTV ops and 2m can occur simultaneously. Mode Downlink Freq Uplink Freq -------------- ------------- ----------- Voice/SSTV 145.55 144.95 (primary), 144.91, 144.97 Packet 145.51 144.91 (primary), 144.93, 144.99 FSTV none 70cm band Please note that the frequencies they will be listening for stations ARE DIFFERENT than the one they will transmit on. This is a very important fact to understand. They will transmit to earth (downlink) on a single frequency 145.55 MHz for voice and SSTV. They will listen for stations transmitting to the shuttle (uplink) on the other frequencies listed. This "split" operation is used quite successfully by DXers when operating in an environment where large pile ups are expected. There will be no simplex operation with SAREX on either voice or packet. Although packeteers are not accustomed to operation with a TX/RX offset, in this case, it is the only way to connect to SAREX. If you transmit on 145.55 or 145.51 MHz the only people who will hear you are those other Hams in your area trying to hear the shuttle. ============================================================ SAREX Packet Operating Hints FULLDUP OFF DWAIT 0.1 - 0.5 seconds FRACK > 3.0 seconds C KB5AWP The packet call sign on board the shuttle is KB5AWP (SSID=0). Your TNC should be in half-duplex mode (FULLDUP OFF) with CD active just like you do for normal VHF packet operations. If you can compensate for doppler shift it is worth the extra effort. The bandwidth of the SAREX radio is +/-4Khz, maximum doppler is around 3.3Khz. If you canUt compensate for doppler your best chance for contact is when the shuttle is at peak elevation at your site. You should be careful with the setting of two of your TNC's timers: DWAIT and FRACK. DWAIT is the time interval after your Carrier Detect light goes out and before your transmitter turns on. You want to make sure your connects requests and ACKs are contained in the 3 second FUDtimer window. If everybody runs the same DWAIT (like the typical 0.1 - 0.5 second values used for terrestrial packet), then everybody will be transmitting at the same time. Part of the key to your success when uplink QRM is heavy is to pick a DWAIT that nobody else is using! (sort of like picking a lottery number!) FRACK sets the time interval between your transmissions. After you send a frame, your TNC waits for the FRACK time, and then waits for the Carrier Detect signal to drop, then waits DWAIT, and then tries again. You should make sure your FRACK is at least 3 seconds so that you are not transmitting when the robot's FUDtimer decides it is time for it to transmit -- if you are transmitting at the same time, you will miss any packets the shuttle is addressing to you and you won't have a successful QSO. Note that your DWAIT (how soon do I transmit?) and FRACK (then how long do I wait?) parameters and the need to stop transmitting so you can hear a reply are just like you encounter when working a DXpedition pileup on HF. If the DX station has a pattern of listening for a few seconds (=FUDtimer) before transmitting, you may have better luck being the LAST station they hear, after the din dies down. The differences are that (1) the robot is a computer and is very predictable and (2) the robot can be working several stations at one time. ============================================================ Mission Audio Retransmissions The following stations will retransmit the mission audio from the shuttle and ground controllers. WA3NAN - Goddard Space Flight Center (GSFC), Greenbelt, Maryland. W5RRR - Johnson Space Center (JSC), Houston, Texas W6VIO - Jet Propulsion Laboratory (JPL), Pasadena, California. W6FXN - Los Angeles K6MF - San Francisco W4MWG - Mebane, NC Station VHF 10m 15m 20m 40m 80m ------ ------ ------ ------ ------ ----- ----- WA3NAN 147.45 28.650 21.395 14.295 7.185 3.860 W5RRR 146.64 W6VIO 224.04 21.340 14.270 W6FXN 145.46 K6MF 145.58 7.165 3.840 NASA/JSC 171.15 W4MWG 14.230 (SSTV) ============================================================ W5RRR Special Event Station W5RRR - Johnson Space Center (JSC) ARC, Houston, TX. Special event station with bulletins, updated element sets, and current flight information will be making contacts and answering questions using SSB on the HF bands. The frequencies are listed below. The special event station will start after launch and run up thru landing. W5RRR will also retransmit the audio from the contacts between STS-37 and schools. Three of the 5 bands will be in use at any given time, band selection will be determined by propagation (usually 10/15/20m daytime, 20/40/80m night). Station 10m 15m 20m 40m 80m ----- ------ ------ ------ ----- ----- W5RRR 28.400 21.350 14.280 7.227 3.850 (+/- QRM) ============================================================ W1AW Voice Bulletins W1AW will be broadcasting daily bulletins with updated information on SAREX during the flight. Voice bulletins are transmitted daily at 0230 UTC and 0530 UTC on the following frequencies: Station 10m 15m 17m 20m 40m 80m ----- ------ ------ ------ ------ ----- ----- W1AW 28.590 21.390 18.160 14.290 7.290 3.990 ============================================================ AMSAT Net Operations Information will also be available from the AMSAT net, tune in for bulletins. The net operates every week on: Sunday 1800-2100 UCT (international) 14.282 Mhz USB Tuesday 0130-0300 UCT (USA) 3.840 Mhz LSB ============================================================ JSC INFO BBS The Public Affairs Office at the Johnson Space Center operates a BBS to provide information to the public. Check this board for updates to the keplerian element sets during the flight. To access the BBS, call +1-713-483-2500 using 1200 baud, 8-N-1, at the ENTER NUMBER: prompt, enter "62511" and you will be connected to the BBS. Check file area 30 or 99 for latest element sets. NASA JSC's Electronic Space Information BBS is intended to provide 24-hour access to biographies of NASA officials and astronauts, news releases, space flight mission presskits and television schedules, space shuttle systems information, flight manifests and schedules, and other information about the space program. ============================================================ NASA Select Video Broadcast The continental United States will receive NASA Select television, 24 hours a day throughout the mission, via: SATCOM F2R Transponder 13 72 degrees West Longitude 3960 MHz (Video) 6.8 MHZ (Audio) ============================================================ STS-37 SAREX Timeline (unofficial summary) MET (ST/DST)** UTC D H M Rev Event PT CT ET ----------- ------- --- ----------------------------------- ---- -------- ---- 4/4/91 1420 0 00 00 1 LAUNCH 0620 4/4 0820 0920 4/4/91 2115 0 06 55 5 Start SAREX Setup 1315 4/4 1515 1615 4/4/91 2120 0 07 00 5 Begin Pre-Sleep Activity 1320 4/4 1520 1620 4/4/91 2140 0 07 20 5 Finish SAREX Setup 1340 4/4 1540 1640 4/5/91 0020 0 10 00 7 Begin Sleep Period 1620 4/4 1820 1920 4/5/91 0820 0 18 00 12 Begin Post-Sleep Activity 0020 4/5 0220 0320 4/5/91 1120 0 21 00 14 End Post-Sleep Activity 0320 4/5 0520 0620 4/5/91 1210 0 21 50 15 Cabin depress to 10.2 PSI 0410 4/5 0610 0710 4/5/91 1332 0 23 12 16 AOS FSTV w/N9AB, US Bridge 0532 4/5 0732 0832 4/5/91 1350 0 23 30 16 LOS FSTV w/N9AB, US Bridge 0550 4/5 0750 0850 4/5/91 1511 1 00 51 17 AOS School #1 via US Bridge 0711 4/5 0911 1011 4/5/91 1529 1 01 09 17 LOS School #1 via US Bridge 0729 4/5 0929 1029 4/5/91 1649 1 02 29 18 AOS School #2 via US Bridge 0849 4/5 1049 1149 4/5/91 1707 1 02 47 18 LOS School #2 via US Bridge 0907 4/5 1107 1207 4/5/91 1829 1 04 09 19 AOS School #3 via US Bridge 1029 4/5 1229 1329 4/5/91 1845 1 04 25 19 LOS School #3 via US Bridge 1045 4/5 1245 1345 4/5/91 2020 1 06 00 20 Begin Pre-Sleep Activity 1220 4/5 1420 1520 4/5/91 2020 1 06 00 20 AOS School #4 via SA Bridge 1220 4/5 1420 1520 4/5/91 2041 1 06 21 20 LOS School #4 via SA Bridge 1241 4/5 1441 1541 4/5/91 2320 1 09 00 22 Begin Sleep Period 1520 4/5 1720 1820 4/6/91 0720 1 17 00 27 Begin Post-Sleep Activity 2320 4/6 0120 0220 4/6/91 1020 1 20 00 29 End Post-Sleep Activity 0220 4/6 0420 0520 4/6/91 1120 1 21 00 30 GRO Grapple 0320 4/6 0520 0620 4/6/91 1130 1 21 10 30 GRO Unberth 0330 4/6 0530 0630 4/6/91 1230 1 22 10 30 GRO Solar Array Deploy 0430 4/6 0630 0730 4/6/91 1350 1 23 30 31 GRO High Gain Antenna Deploy 0550 4/6 0750 0850 4/6/91 1431 2 00 11 32 AOS FSTV w/W5RRR, KE4PT w/US Bridge 0631 4/6 0831 0931 4/6/91 1451 2 00 31 32 LOS FSTV w/W5RRR, KE4PT w/US Bridge 0651 4/6 0851 0951 4/6/91 1730 2 03 10 34 GRO Release 0930 4/6 1130 1230 4/6/91 2020 2 06 00 35 Begin Pre-Sleep Activity 1220 4/6 1420 1520 4/6/91 2320 2 09 00 37 Begin Sleep Period 1520 4/6 1720 1820 4/7/91 0720 2 17 00 42 Begin Post-Sleep Activity 2320 4/7 0020 0120 4/7/91 1020 2 20 00 44 End Post-Sleep Activity 0120 4/7 0320 0420 4/7/91 1020 2 20 00 44 Begin EVA Prep 0120 4/7 0320 0420 4/7/91 1210 2 21 50 46 Unscheduled SSTV/Packet 0310 4/7 0510 0610 4/7/91 1235 2 22 15 46 Airlock Depress/Egress 0335 4/7 0535 0635 4/7/91 1340 2 23 20 47 Unscheduled SSTV/Packet 0440 4/7 0640 0740 4/7/91 1510 3 00 50 48 Unscheduled SSTV/Packet 0610 4/7 0810 0910 4/7/91 1640 3 02 20 49 Unscheduled SSTV/Packet 0740 4/7 0940 1040 4/7/91 1850 3 04 30 50 Airlock Ingress/Repress 0950 4/7 1150 1250 4/7/91 1935 3 05 15 50 Begin Pre-Sleep Activity 1035 4/7 1235 1335 4/7/91 2235 3 08 15 52 Begin Sleep Period 1335 4/7 1535 1635 4/8/91 0535 3 15 15 57 Begin Post-Sleep Activity 2035 4/7 2235 2335 4/8/91 0835 3 18 15 59 End Post-Sleep Activity 2335 4/8 0135 0235 4/8/91 0835 3 18 15 59 Cabin repress to 14.7 PSI 2335 4/8 0135 0235 4/8/91 1314 3 22 54 62 AOS School #5 US Bridge 0414 4/8 0614 0714 4/8/91 1333 3 23 13 62 LOS School #5 US Bridge 0433 4/8 0633 0733 4/8/91 1452 4 00 32 63 AOS Backup FSTV or w/W5RRR US Bridg 0552 4/8 0752 0852 4/8/91 1512 4 00 52 63 LOS Backup FSTV or w/W5RRR US Bridg 0612 4/8 0812 0912 4/8/91 1925 4 05 05 66 Begin Pre-Sleep Activity 1025 4/8 1225 1325 4/8/91 1930 4 05 10 66 Start SAREX Stow 1030 4/8 1230 1330 4/8/91 2000 4 05 40 66 Finish SAREX Stow 1100 4/8 1300 1400 4/8/91 2225 4 08 05 68 Begin Sleep Period 1325 4/8 1525 1625 4/9/91 0625 4 16 05 73 Begin Post-Sleep Activity 2125 4/8 2325 0025 4/9/91 0925 4 19 05 75 End Post-Sleep Activity 0025 4/9 0225 0325 4/9/91 1325 4 23 05 77 Deorbit Burn 0425 4/9 0625 0725 4/9/91 1430 5 00 10 78 EDW Landing 0530 4/9 0730 0830 ** PT (Pacific Time), CT (Central Time) and ET (Eastern Time) starts as stan- dard time then changes to daylight savings time on April 7, 0200 local time. ============================================================ ### -- Gary Morris Internet: garym@telesoft.com Lockheed, Houston, Texas UUCP: lobster!avocado!gamorris N5QWC/W5RRR Phone: +1 713 283 5195 ------------------------------ Date: 23 Mar 91 01:21:04 GMT From: epic!karn@bellcore.bellcore.com Subject: TAPR meeting notes To: packet-radio@ucsd.edu In article <17671@sdcc6.ucsd.edu>, williams@beowulf.ucsd.edu (Paul Williamson) writes: |> |> A detailed blow-by-blow account of the 1991 TAPR Annual Meeting in Tucson |> is available for FTP on tomcat.gsfc.nasa.gov in /public/tapr/blowby.txt |> and on thumper.bellcore.com in /pub/ka9q/incoming/blowby.txt (until Phil |> moves it to a permanent location). I've moved it to /pub/ka9q/misc/blowby.txt. Phil ------------------------------ Date: 18 Mar 91 00:48:18 GMT From: usc!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!phage!helix.cshl.org!markiewi@ucsd.edu Subject: TCP/IP To: packet-radio@ucsd.edu Can someone offer me a hand? I am new to both the Internet, and to packet so please bear with me. I have a PK232 and am ineterested in using the KA9Q TCP/IP package with it. Does anyone have a basic document that they could mail me on the proper techniques of its use? How does one obtain their address? etc. Any help would be greatly appreciated.. Thanks, Peter N2IFC ------------------------------ Date: 18 Mar 91 23:05:35 GMT From: sdd.hp.com!usc!rpi!uupsi!phage!helix.cshl.org!markiewi@ucsd.edu Subject: Thanks To: packet-radio@ucsd.edu Thanks to all the people who responded to my posting yesterday. I think I have all the info I need, or atleast were I can find it. Thanks again, Peter N2IFC ------------------------------ Date: 19 Mar 91 02:57:23 GMT From: uvaarpa!haven!boingo.med.jhu.edu!aplcen!wb3ffv!howardl@mcnc.org Subject: The Amateur Radio BBS - How to access To: packet-radio@ucsd.edu +------------------------------------------------------------------------------+ HOW TO ACCESS THE WB3FFV AMATEUR RADIO TELEPHONE BBS !!! I have placed a BBS system on-line that is mainly oriented towards the Amateur Community (but there is other stuff on-line). As of now I have not attempted to promote this system any place except in the amateur channels (PACKET, USENET, & word of mouth), and will continue under this policy, as I hope to keep it oriented toward amateur radio. The various software for UP/DOWNload is available via telephone dialup and Packet TCP/IP, and through user support I hope to keep the latest and greatest ham software on-line. Below is the information that is needed in order to access the BBS via Telephone -or- TCP/IP, please pass it around to as many ham's as possible. System Name: WB3FFV User Login: bbs Number: (301)-625-0817 -- 1200 & 2400 (Non-MNP) Number: (301)-625-9482 -- 1200,2400,4800,9600,19200,38400 V.32 (V.42bis/MNP5) Number: (301)-625-9663 -- 1200 & 2400 (MNP5), 9600 & 19200 (PEP) Data Settings: 8 Bits, NO Parity, 1 Stop Bit Times: 24hrs/365days (except for routine maintenance) Software: XBBS (UNIX/Xenix Multiuser BBS) IP Address: 44.60.128.1 {wb3ffv.ampr.org} [for FTP access on 145.650 mhz ONLY] Misc. Info: Machine is an 80486 computer running UNIX V.3.2 and features 800 Meg of on-line storage. Most transfer protocols are available!! I attempt to keep the latest and greatest HAM software on-line, and encourage all to upload anything new that they come up with, as it is of benefit to all. Here is a sample of a couple pieces of software that is available for DOWNLOAD: KA9Q TCP/IP Software for the PC (Latest OFFICIAL release + TEST Versions) KA9Q TCP/IP for the Atari-ST, MAC, & Amiga KA9Q TCP/IP for UNIX based systems KA9Q TCP/IP (The NOS release) [UNIX, MS/DOS, Amiga] KA9Q TCP/IP (Version by G1EMM, PE1CHL, PA0GRI, Etc.) N2GTE Packet Mail Switch [GTEPMS] (Version 1.2) WA7MBL BBS for the PC (Versions 3.31, 4.31 & 5.1[2,3,4]) W0RLI BBS for the PC (Versions 6.xx, 7.xx, 8.xx, 9.xx, 10.xx, 11.xx) MSYS BBS for the PC running KISS TNC's (Version 1.07-1.10) AA4RE BBS for the PC (Version 2.10) Various BBS utilities and enhancements Several MORSE CODE Tutors TheNet software by NORD> GIDEN@WSUVM1.CSC.WSU.EDU (Robert Giden N7KCG) writes: >Some time ago, a European software package was announced that could >emulate a TNC on an IBM PC or PC Clone. Besides that package, are >there any other IBM clones TNC emulators around? Yes, there is. I've written a program called PMP (Poor Man's Packet) that is in use here in the Ithaca, NY area. The gory details of the serial protocol are not as cleanly implemented as Baycom (my program hangs the machine during RX and TX) and I don't have as many features as Baycom. But overall, I think my program is much more cleanly implemented (overall structure, user interface, configuration). Originally, I was going to make the program shareware. Now, with the usual lack of time, I'm giving it away as "guiltware"--send me what you think it is worth. I offer no guarantees; I may never get around to fixing bugs. But I will give you some help: full source code (Turbo C). If there is any interest, I will make it available via anonymous FTP. -- = = = = = = = = = = = = = = = = = = = = = = = = = = = Andrew C. Payne, N8KEI UUCP: ...!cornell!batcomputer!payne INTERNET: payne@tcgould.tn.cornell.edu ------------------------------ Date: 21 Mar 91 21:55:06 GMT From: usc!wuarchive!waikato.ac.nz!comp.vuw.ac.nz!cc-server4.massey.ac.nz!G.Moretti@ucsd.edu Subject: TNC Emulators on PC's To: packet-radio@ucsd.edu >>> Re PMP - A user's comments An excellent program. I've been using it for about a year and it works well. Several other users down in this part of the world have been using it quite successfully too ... One disadvantage (which apparently is shared by BAYCOM) is that you cannot upload/download binary files (no YAPP/XMODEM ...) support. I've been using the second parallel port, but as the port address, the active bit and which level is active are defined in the config file (PMP.CFG) you should be able to use either serial or parallel port to talk to the modem. The modem side is simply a 7910 based modem for 1200 baud. These comments apply to PMP version 0.93. Andy may have released a later version. Cheers Giovanni ZL2BOI -- ------------------------------------------------------------------------------ Giovanni Moretti, Consultant | G.Moretti@massey.ac.nz, Pkt-ZL2BOI@ZL2BFJ Computer Centre, Massey University| Ph 64 63 69099 x8398, FAX 64 63 505607 Palmerston North, New Zealand | QUITTERS NEVER WIN, WINNERS NEVER QUIT ------------------------------------------------------------------------------ ------------------------------ Date: 20 Mar 91 15:26:23 GMT From: usc!apple!well!kdavis%well.sf.ca.us@ucsd.edu Subject: WANTED: Docs for NETPC (DL3DBT v891105) To: packet-radio@ucsd.edu I am running the net.exe called netpc developed in Germany by DL3DBT and group. I have it running fine on two ports with tcp/ip and net/rom. I need the documentation for this (in English, I hope). Many features like NOS are handled with this program and it has color and windowing support. If anyone knows where I can ftp the docs please contact me. Thanks! -- Ken ------------------------------ Date: 21 Mar 91 17:57:32 GMT From: agate!apple!veritas!amdcad!sono!collins@ucbvax.berkeley.edu Subject: Where can I download Baycom? To: packet-radio@ucsd.edu I am looking for a copy of Baycom and noticed in a previous posting that someone (don't remember who, unfortunately) mentioned downloading it. Does anyone know of a site which has Baycom and which could e-mail a uuencode'd copy (I do not have ftp access)? Thanks in advance, Michael Stratford Collins collins@sono.uucp sun!sono!collins ------------------------------ Date: (null) From: (null) > And while I'm pontificating (:-) the left most callsign (in the above > examples > VK6ZJM) should ONLY be considered for routing purposes if it is shown as part > of the domain segment (eg VK6ZJM.VK6BBS.#WA.AUS). Once the '@' is reached in > the right to left scan, routing should stop. The reason is this: the > originator > of the message may know that VK6ZJM has moved QTH - routing software wouldn't > always know this. > I think that when someone moves the first person they tell (in the packet world) is the SYSOP of their local BBS, otherwise that BBS is going to keep trying to forward mail to them when they're not there. Being able to forward on the TO field is often very useful - remote SYSOPs often like to have mail addressed to SYSOP forwarded on to them, for example. ---- Brian Lloyd Software Management & Control, # By e-mail : blloyd@axion.bt.co.uk Software Technology Division, # By Phone : +44 (0)473 646650 SSTF Building, BTRL, Martlesham Heath, # By Fax : +44 (0)473 643019 Ipswich, Suffolk. UK. IP5 7RE # By Packet : G1NNA@GB7NNA.GBR.EU ------------------------------ Date: 19 Mar 91 05:01:47 GMT From: gatech!udel!haven!ni.umd.edu!sayshell.umd.edu!louie@ucsd.edu To: packet-radio@ucsd.edu References <7492.27e484b1@cc.curtin.edu.au>, <1991Mar18.150624.23335@axion.bt.co.uk>, <1991Mar18.215239.19274@casbah.acns.nwu.edu> Subject : Re: Hierarchical Forwarding pounds (#) In article <1991Mar18.215239.19274@casbah.acns.nwu.edu> hpa@casbah.acns.nwu.edu (Peter Anvin) writes: >In proper domain-style addressing, a la the Internet, this would rather be: > >Do I know where VK6ZJM.WA.AUS is? No >Do I know where WA.AUS is? No >Do I know where AUS is? Yes >Forward in direction AUS > Bzzzzzt - wrong. In domain-style "addresses", names are just names, and DO NOT imply routes. There are names, addresses, and routes; it is important to keep the distinction between each of them. Internet style names are broken into an administrative heirarchy which has (by design and absolute intent) nothing to do with routing or addresses. If you are going to cite Internet style domain names, please don't change the meaning while you're at it. Yes, some of us are really sensitive about this distinction. louie WA3YMH ------------------------------ Date: 19 Mar 91 10:35:36 GMT From: ucselx!bionet!apple!mips!spool.mu.edu!munnari.oz.au!manuel!csc.canberra.edu.au!echo!skcm@ucsd.edu To: packet-radio@ucsd.edu References <1991Mar15.025040.16086@maverick.ksu.ksu.edu>, <1991Mar16.202548.18162@ims.alaska.edu>, <7492.27e484b1@cc.curtin.edu.au> Subject : Re: Hierarchical Forwarding pounds (#) In <7492.27e484b1@cc.curtin.edu.au> Murray_RJ@cc.curtin.edu.au (Ron Murray) writes: >> the octothorpe, '#'. >2. Someone in Australia mis-read the documentation and decided that this name > change was necessary. This is probably the more likely. FAR FAR more likely. :-) Browsing thru the mail on my BBS (VK1KCM) I notice South Australia and Western Australia both use the "#" at the state level while everybody else only uses it below the state. (#SA, #WA and ACT, NSW etc) It's rare, however, for there to be any identifiers below the state level. My address here in Canberra is; vk1kcm@vk1kcm.act.aus.oc Also the "Asianet" sysops, mainly Brian Beamish Vk4BBS decided that we wouldn't use .au as our domain. Instead we have to use .oc (for Oceania). Needless to say none of these people are on the internet. :-( Carl. ------------------------------ Date: 15 Mar 91 03:12:15 GMT From: swrinde!elroy.jpl.nasa.gov!sdd.hp.com!uakari.primate.wisc.edu!umriscc!maverick.ksu.ksu.edu!matt.ksu.ksu.edu!steve@ucsd.edu To: packet-radio@ucsd.edu References <47@norand.UUCP>, <29868@ucsd.Edu>, <1991Mar13.212921.31032@cunixf.cc.columbia.edu>ck.ks Subject : Re: Digital repeater network >Has anyone looked into the feasibility of creating a digital repeater network? >It seems to me that this would allow most any ham to talk to most any other, >anywhere, using a simple handheld radio. This seems like a logical extension >of the current plans to create an analog system using dynamic links to a >long distance backbone. The problem with this scheme is: what happens >if a link in the backbone fails; and if more than one user wants to use the >system at the same time? It would be a very resource intensive system, >anyway. I have thought of this idea. With current A/D and DSP technology, it would be easy to build a fully Digital Audio Repeater (DAR). Just convert the received audio with an A-to-D, add filtering/CW tones/ect with a DSP and spit out the result using a D-to-A. If output to a network is wanted, just send the digital streams to a RF modem as well as the transmitter. Also, voice mail could easily be implemented with the addition of secondary storage. (it could even be transferred as normal mail over conventional packet channels.) >In short: why couldn't the Amateur community set up the equivalent of a >digital cellular network with modest user requirements, linked exclusively >by radio and therefore immune to damage to the hard-wired systems such as >the telephone network. A similar 'what if' was presented at the _9th Computer Networking Conference_ by Jon Bloom, KE3Z. The technology is getting there, but it will take even more time before the idea catches on. We have a large base of old technology voice repeaters that will not go away. :-) -Steve Schallehn, KB0AGD Kansas State University ------------------------------ Date: (null) From: (null) --Kauto, OH5LFM -- ****************** Kauto Huopio (huopio@kannel.lut.fi) ********************** * Mail: Kauto Huopio, Punkkerikatu 1 A 10, SF-53850 Lappeenranta,Finland * ***************************************************************************** ------------------------------ Date: 20 Mar 91 02:49:36 GMT From: swrinde!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu!hpa@ucsd.edu To: packet-radio@ucsd.edu References <1991Mar18.150624.23335@axion.bt.co.uk>, <1991Mar18.215239.19274@casbah.acns.nwu.edu>, <1991Mar19.050147.911@ni.umd.edu> Subject : Re: Hierarchical Forwarding pounds (#) In article <1991Mar19.050147.911@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes: >Bzzzzzt - wrong. In domain-style "addresses", names are just names, >and DO NOT imply routes. There are names, addresses, and routes; it >is important to keep the distinction between each of them. > >Internet style names are broken into an administrative heirarchy which has >(by design and absolute intent) nothing to do with routing or addresses. > >If you are going to cite Internet style domain names, please don't change >the meaning while you're at it. I stand corrected -- to a degree. What I should have said, I guess, would be something like ``this is the intent of hierarchial **addressing**''. As you correctly point out, Internet host names are hierarchial but do not necessarily imply addressing. They do if and only if they point to a non-IP subdomain for mail traffic, such as fidonet.org, where routing is provided through UUCP to different gateways depending on a specified subdomain. In the store-and-forward landline network Fidonet, addresses are hierarchial but numerical on the form NNN:NNN/NNN.NNN (the punctuation allows for abbreviation only) The Fidonet address is left-major, opposite the direction of the Internet and Amateur Packet hierarchial names, but partially similar to the IP numbering system (NNN.NNN.NNN.NNN). If a system is to send mail to, say, 2:206/203.1 it uses an algorithm like this: [THIS IS VERY SIMPLIFIED AS ANYONE FAMILIAR WITH FIDONET WOULD SEE IMMEDIATELY] Do I have a route to 2:206/203.1? No Do I have a route to 2:206/203.0? No Do I have a route to 2:206/0.0? No Do I have a route to zone 2? YES - 1:115/500.0 -> forward The amateur AX.25 network is different from Fidonet, Internet and UUCP in topology, nature of the nodes, the information each node has, and addressing format. Thus what applies to one does not necessarily aplpy to the other. That doesn't prevent us from learning from each other and find a good combination of techniques needed for each individual network. /Peter -- hpa = H. Peter Anvin (in case you wondered) * Heja Sverige! INTERNET: hpa@casbah.acns.nwu.edu FIDONET: 1:115/989.4 HAM RADIO: N9ITP, SM4TKN RBBSNET: 8:970/101.4 ------------------------------ Date: (null) From: (null) The idea of scanning from left to right is to find the most direct route to the destination. If I was to forward a message to you, the BBS would perform the following steps : Do I know where VK6ZJM is? No - do I know where VK6BBS is? No - do I know where #WA is? No - do I know where AUS is? Yes - forward the message in that direction. If, on the other hand, I had a direct link to VK6BBS I would forward the message there, rather than to Australia, as VK6BBS is much closer to you Australia in general. The main reason for having the # before the second field is to eliminate any problem which may arise from having a local hierarchical address which is the same as a country or continent designator. If, for example, you had a local address of NA (for Northern Australia, say), then the BBS would try to send the message to North America, as that is what NA is supposed to be. I hope this helps a bit. Brian (G1NNA@GB7NNA.GBR.EU) ------------------------------ End of Packet-Radio Digest ******************************