Date: Mon, 6 Dec 93 04:30:27 PST From: Ham-Digital Mailing List and Newsgroup Errors-To: Ham-Digital-Errors@UCSD.Edu Reply-To: Ham-Digital@UCSD.Edu Precedence: Bulk Subject: Ham-Digital Digest V93 #137 To: Ham-Digital Ham-Digital Digest Mon, 6 Dec 93 Volume 93 : Issue 137 Today's Topics: HAM-server index file KPC-3: Remote Station Gets 'Busy' Replies?? MICOR on 9.6kbaud packet? PK-88 vs KPC-3 vs DPK-2 Recent APRS posts from the .ampr net TEKK Radios (3 msgs) unsubscribe Who should use gateways for what (was Re: wb7tpy gateway) 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 Ham-Digital Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 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: 5 Dec 93 01:35:57 GMT From: ogicse!cs.uoregon.edu!sgiblab!pacbell.com!amdahl!grafex!ka6etb@network.ucsd.edu Subject: HAM-server index file To: ham-digital@ucsd.edu In <9312022028591.gilbaronw0mn.DLITE@delphi.com> gilbaronw0mn@delphi.com (Gilbert Baron) writes: >>>Phooey on you Gil! I for one am glad to see the list of files. This >>>ham-server is a gold mine of info - I've gotten so many goodies off >That is what the index is for. Go and read the index yourself and then get >what you need. Don't subject the rest of the network to this. It is not >needed and waste time and space and LOTS of money. Probably no more costly than the AMSAT or KEPLER info published on a much more regular basis. Boy, are you gonna be peeved when I get HAM-server set up for PBBS. 73 de KA6ETB ------------------------------ Date: Fri, 03 Dec 93 12:26:43 EST From: ucsnews!sol.ctr.columbia.edu!howland.reston.ans.net!newsserver.jvnc.net!yale.edu!news.yale.edu!YaleVM.YCC.Yale.Edu!MIKEN@network.ucsd.edu Subject: KPC-3: Remote Station Gets 'Busy' Replies?? To: ham-digital@ucsd.edu What software are you using with the TNC? Miken@yalevm.cis.yale.edu N1JJX@N1JJX.AMPR.ORG In article <97124@cup.portal.com> AllanWS@cup.portal.com (Allan BA Schlaugat) writes: >This problem is making me lose more hair than I have on my head! > >I have a KPC-3 TNC which I use to connect to the local PacketCluster. >The cluster sysop set up a script where if the path between the cluster >and my location drops and I retry out, the cluster will attempt to reconnect >to my TNC. This is how I discovered the 'problem'... >With the computer off (a 386 clone), leaving the TNC/radio on, a station >cannot connect to my TNC. They receive a ***busy on their end and I get >a *** connect request! Note that the remote station is not trying to >access the KA-Node or the mailbox; he is just trying to connect to my >normal user ID. When I turn the computer on and boot up my packet software, >I get a buffer full of *** connect requests as well as other channel >traffic. Stations can now connect to me. It seems that I must keep the >computer on with terminal software loaded up but this does not seem right. >I have been involved with packet for 3 years and have used the MFJ-1278 >with no problems. In fact, I cannot reproduce this problem with the >MFJ. Some locals suggested CTS/RTS hardware flow control might >be at fault here. I have my USERS set at 10 /MAXUSERS at 10 btw. >Is there anything I am overlooking here? The KPC-3 is 3 weeks old >and I never got this thing to work like the MFJ (KPC firmware is >5.1). Any clues?? > >Thanks > >Al Schlaugat / allanws@cup.portal.com \ Amateur Radio: N9ISN ------------------------------ Date: 6 Dec 1993 02:52:08 GMT From: nothing.ucsd.edu!brian@network.ucsd.edu Subject: MICOR on 9.6kbaud packet? To: ham-digital@ucsd.edu UHF MICORs work fine at 9600 bps. Just shove the transmitted data stream into the modulator, which direct-FMs the offset oscillator. Pick the received data off pin 6 of the demodulator chip. As with most commercial radios, the IFs are just a tiny bit too narrow for 9600, but will work well if the signals are at least a few microvolts. A word of caution: UHF mobile Micor output transistors are no longer available. These are highly-inefficient early RF devices, and tend to be somewhat fragile in repeater service. Pick up a few extra radios for spare parts. Also, they're real power wasters. Be sure to have a fan on the heatsink if you're going to be using it in repeater or BBS service. - Brian ------------------------------ Date: Thu, 02 Dec 93 18:43:01 MST From: mvb.saic.com!unogate!news.service.uci.edu!usc!cs.utexas.edu!asuvax!ennews!stat!aznet!dan@network.ucsd.edu Subject: PK-88 vs KPC-3 vs DPK-2 To: ham-digital@ucsd.edu rdewan@casbah.acns.nwu.edu (Rajiv Dewan) writes: > On a comparison of Pk88, DPK-2 and KPC-3, Bob Nielsen > wrote: > > > >All three of them run KISS. The DPK-2 is the only one which has > >firmware which is completely compatible with TAPR firmware. Any > >of these can be upgraded to 'open squelch' operation using a > >$15.00 kit from TAPR. The PK-88 and DPK-2 both can be adapted to > >use external modems, but the KPC-3 cannot. > >... > > The KPC-3 comes ready to run "open squelch" right out of the box. All > it needs are two commands: > > interface terminal > cd software THE ONLY PROBLEM IS THAT IT IS SOFTWARE OPEN SQUELCH AND FALSES A GREAT DEAL! > > Rajiv > aa9ch > r-dewan@nwu.edu Dan ---------------------- dan@aznet.stat.com Daniel J. Meredith Fax - (602) 956-2566 Voice - (602) 809-0555 ------------------------------ Date: Sun, 5 Dec 1993 18:33:15 GMT From: csus.edu!netcom.com!rander@decwrl.dec.com Subject: Recent APRS posts from the .ampr net To: ham-digital@ucsd.edu This post is a relay of some recent traffic on the packet network about the APRS. For those who aren't familiar, APRS is the "Automatic Packet Reporting System" by WB4APR that allows position data from a GPS or LORAN receiver to automatically be sent out by a TNC and then displayed on a map display be other stations running APRS. --------------------included messages follow-------------------------- Date: 04 Dec 93 15:26 Message-ID: <28974@KA6EYH> From: W7KKE@KA6EYH To: APRS@ALLCAN Subject: New/Modified APRS maps Path: KI6EH!N6IYA!N6QMY!WA8DRZ!WD6CMU!KA6EYH!KA6EYH From: W7KKE@KA6EYH.#NOCAL.CA.USA.NA To : APRS@ALLCAN I have uploaded some new and updated APRS maps to the KA6EYH LLBBS. This BBS can be reached at 415-359-6985. Login with your callsign and use the password "COAST". The maps are in the APRS directory. This BBS uses standard packet BBS commands, plus semi-DOS commands. It supports Xmodem and Ymodem in the land-line mode. To download a file using Xmodem use the following commands after log-in: D - Sets you in FBBDOS mode cd APRS - Changes current directory to APRS dir - Lists contents of the directory XGET filename - Sets up file transfer via Xmodem. After you are finished transfering files, Exit - Returns to packet BBS mode The new/updated maps in the APRS directory are: CALIF.MAP - Filled the map shell WB4APR sends with his distribution disk with more northern & central California roads. CAOBISBO.MAP - Covers south central coast between CA-LA.MAP and CAGILROY.MAP CA_DALY.MAP - Covers Daly City, San Bruno, Colma, and Burlingame, and South San Francisco. (Includes corrections from WB6LPG's GPS trips) CAFSTRCTY.MAP - Covers Foster City and Redwood Shores area. This is expanded from the map on the WB4APRS distribution disk in that it includes Redwood Shores. (Includes corrections from WB6LPG's GPS trips) CA_MATEO.MAP - Covers San Mateo, part of Burlingame, San Carlos, Belmont, and a bit of Redwood City. (Includes corrections from WB6LPG's GPS trips) HALFMOON.MAP - Covers from Halfmoon Bay airport south to Pigeon Pt. and east to Skyline Blvd. (Includes partial corrections from WB6LPG's GPS trips) 73, Ken W7KKE @ KA6EYH.#NOCAL.CA.USA Date: 04 Dec 93 17:43 Message-ID: <28010@WB3V> From: WB4APR@WB3V To: APRS@ALLUS Subject: APRS Football Tracking Success! Path: KI6EH!N6IYA!WD6CMU!KA6EYH!KA6EYH!WX3K!KI7AE!KQ4OK ... This year we had three packet/GPS trackers attached to the chase vehicles for the Army/Navy game footbal run from Annapolis MD to the Meadowlands outside of NY City on 3 Dec. We were able to track the 1 watt 2m devices over the full 250 miles! Volunteer packet stations all along the route left their TNC's on so that we could use them as digipeaters, and W2HOB put up a temporary digi in southern NJ at 600 feet! Using only three hops, the once every 2 minute position reports made it all along the route ust fine! Lessons learned: ALthough the position reports were very reliable, APRS messages to the mobiles often took 10's of minutes to be ACKed (if at all) towards the end of the route. This is the same reason that DIGI's are poor performers in normal packet. Ii is simple. If there is a 20% chance that a packet gets through the 3 digipeater path, then there is only a 4% chance that the ACK will get back to the sender! This is one of the main reasons that APRS avoids CONNECTED packet and ACKS. (I am working on an improved message send capability for APRS that tries to mimimize the need for ACKS) Direction finding: With all the vehicles 100 miles out of Annapolis, a stuck transmitter in Baltimore jammed the frequency for 2 hours solid. Fortunately position reports were still being digipeated forward through the network into NJ, and N2CZF was digipeating them out onto the 40m HF APRS net, so that we still got the reports! All activity in Annapolis turned toward DFing. In minutes we had crossed bearing lines, but as more and more non APRS stations got involved the bearings deteriated! Later we found out that some reports were given by apartment dwellers moving around in their apartments with HT's and telling us which corner of their rooms gave the strongest signal! Although APRS plotted all these lines well, there was no real convergence. But since there was only one other APRS station on the map anywhere within 10 miles of the mess of lines, he was not home! When he finally was reached several hours later, long after the signal had disappeared, he could find no evidence that it was his transmitter. Anyway, as soon as the signal quit, the position reports came rolling in and all was well! OTHERS: In addition to the GPS equipped chase vehicles, we also saw two other APRS GPS vehicles join the fun. N3JLQ was automatic-GPS mobile and N2MSM was manually entering his GPS position into his Porta-pkt TNC BText! Both stations hill-topped around the area of the entourage so that they could be used for digipeating to the big DIGI's... We also saw our first Xcountry APRS posit from WB6LPG in California! A total of 55 APRS stations were observed during the event and we all had fun! ------------------------------ Date: Fri, 3 Dec 1993 15:43:34 GMT From: newsgate.watson.ibm.com!watnews.watson.ibm.com!sernews!news@uunet.uu.net Subject: TEKK Radios To: ham-digital@ucsd.edu Can anyone tell me about the TEKK 440 based Radios? I know they are only 2watts, but are they good performers? Any information will be greatly appreciated. 73, Mike KB4LFH ==================================== KB4LFH @ VNET.IBM.COM ==================================== ------------------------------ Date: Sat, 4 Dec 1993 13:40:38 GMT From: butch!netcomsv!netcom.com!fmitch@uunet.uu.net Subject: TEKK Radios To: ham-digital@ucsd.edu Felton Mitchell (fmitch@netcom.com) wrote: : kb4lfh@vnet.ibm.com wrote: : : Can anyone tell me about the TEKK 440 based Radios? I know they : : are only 2watts, but are they good performers? Any information : : will be greatly appreciated. : : 73, Mike KB4LFH : : ==================================== : : KB4LFH @ VNET.IBM.COM : : ==================================== : hi mike... the tekk's work great! we are using one with a 20 watt brick : for our main 9600 baud backbone node on 446.100... for the price, : you can't go wrong... we have ordered 5 more to complete our : backbone... we probably will use tthe power amps out of some : old commercial gear for a little higher power... : the tekk expert is geoff, kd4goe, he is on the 'net and his : 'net address is geoffp@netcom.com : cul... : mitch, wa4osr oops... forgot to tell you one thing... the tekk's don't like 12 volts... you have to power them from 10-11 volts max, else they aren't frequency stable... they pull such little current this is not a problem, just a nusiance... mitch, wa4osr -- ------------------------------------------------------------------------------- fmitch@netcom.com Felton "Mitch" Mitchell, WA4OSR in Mobile, Alabama USA 205-342-7259 home, 205-476-4100 work, 205-476-0465 FAX co-sysop for W4IAX bbs running fbb ... sysop for WA4OSR DXCluster in Mobile.. ------------------------------------------------------------------------------ ------------------------------ Date: 6 Dec 1993 02:46:29 GMT From: nothing.ucsd.edu!brian@network.ucsd.edu Subject: TEKK Radios To: ham-digital@ucsd.edu The TEKK radio is ok for simple 9600 bps links. The transmitter is ok, and shows good modulation response when used with the typical 9600 bps modem - I've tried the TAPR and K9NG, and others report G3RUH modems work ok. The RF is more-or-less clean. I'd recommend using a cavity or other filter on it in most circumstances, and if it's going to be in a place where there are other radios on nearby frequencies (such as at a repeater site), a circulator or isolator wouldn't be a bad idea. The receiver is only fair. The front-end is easily smashed by strong signals, so you need additional selectivity if your site has any other transmitters nearby. The IF bandpass filters are not ideal for 9600 bps, but if you have nice strong signals and reduce the transmitted deviation, your digital signal will make it through ok. Performance is really poor at 9600 with weak signals, though. I don't think I'm going to buy any more of them for our links. Maxar and Mitrek radios are available surplus for less and seem to be better. - Brian ------------------------------ Date: 5 Dec 93 18:01:05 GMT From: news-mail-gateway@ucsd.edu Subject: unsubscribe To: ham-digital@ucsd.edu ------------------------------ Date: Thu, 02 Dec 93 21:45:13 ARG From: ucsnews!sol.ctr.columbia.edu!math.ohio-state.edu!news.cyberstore.ca!nwnexus!a2i!satlink!burzaco!colla@network.ucsd.edu Subject: Who should use gateways for what (was Re: wb7tpy gateway) To: ham-digital@ucsd.edu winter@apple.com (Patty Winter) writes: >In article <1993Nov23.085806.17098@mnemosyne.cs.du.edu>, >Jonathan Magee wrote: >>The only use of the internet in ham radio should be to connect ham >>stations via worm holes ie only hams can use it. > Over long haul paths Internet could be considered one heck of a backbone provided you can check both the origin and the destination are hams; some countries might consider one side not being an amateur illegal, some others not. Beside that, as far as I know there is no regulations preventing amateurs to send mail (unidirectionally) to the Internet world with a contents within regulations. I can also think in several things from the internet that could also be carried legally over packet nets such as software, special bulletins, emergency mail, etc; most of them usually served by automatic machines and again with contents that could be considered otherwise legal if exchanged between two licenced hams over the air. To got an Internet hook, even an UUCP downstream feed not always is neither cheap nor feasible. ------------------------------------------------------------------------------ Ing.Pedro E. Colla - Mail:colla@burzaco.satlink.net - Buenos Aires - Argentina ------------------------------ Date: Sat, 4 Dec 1993 19:40:53 +0000 From: news.sprintlink.net!demon!djwhome.demon.co.uk!david@uunet.uu.net To: ham-digital@ucsd.edu References <1993Nov23.163518.13551@hemlock.cray.com>, <2d08eo$mi4@wvhpadm1.mentorg.com>, <2d24se$dam@unicorn.ccc.nottingham.ac.uk> Subject : Misroutes to Namibia usa.na domain (was: wb7tpy gateway) Well it looks from the DNS lookup that what is catching people out is a very shallow domain name structure in Namibia. My guess is that there is little or no real Internet connectivity in Namibia so there is one mail relay which forwards all mail by something like UUCP. Thus a *.na MX record is not unreasonable, as nearly all na mail needs to go to the same relay and there is no point in recording individual sub-domains; a lot of commercial domains do this. I'm not sure about the na MX records, but there is nothing technically wrong with them. Although the mentorg.com example of dropping the domain name for local traffic is largely true, it misses one significant point, which is that you should not use top level domain names as subdomain names when doing this. Actually, in this particular case, there would seem to be a simple solution within the domain name system which could avoid this problem. All that needs to happen is for Namibia to add an MX record for *.usa.na, pointing to a North American Internet to Packet gateway, or a bit bucket (but the IP address must be good so that mailers don't try to fall back to the *.na address). With the former, as I understand it, inbound mail needs human vetting, so a warning can be sent to the originator and the mail optionally forwarded into the Packet network. Alternatively, the gateway could just bounce it with an appropriate message. By doing this, at most, only a DNS query has to go to Namibia, and if a long time to live is given for the entry any one source of such misrouted mail should only rarely need to do this. By the way, the logic behind the UK restriction on third party traffic partly relates to the historic state monopoly on telecommunications and partly to the idea that the radio spectrum is commercially valuable, so amateurs, who get access well below the market rate for the resource should not be able to compete with commercial communication providers. (I think that the US will only allow third party traffic when both the countries involved allow it.) I am copying this to the DNS administrator and postmaster for na, but to fully implement it will need some cooperation from a US gateway. So I suggest that you agree as to which gateways should be targets of a *.usa.na MX record and then the administrators of those gateways should follow up to the na DNS administrator. -- David Woolley, London, England david@djwhome.demon.co.uk ------------------------------ End of Ham-Digital Digest V93 #137 ****************************** ******************************