Date: Fri, 25 Mar 94 04:30:19 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 V94 #81 To: Ham-Digital Ham-Digital Digest Fri, 25 Mar 94 Volume 94 : Issue 81 Today's Topics: (none) [REPOST] The # in PBBS addresses.... Baycom problem (2 msgs) Ever heard of Yaesu Ft 301??????? FROM INTERNET 4597267@MCIMAIL.COM G-TOR Heathkit HD-4040 TNC HF Digital Throughput HP100LX Palmtop & Baycom? KPC-3 and TCPIP 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: 24 Mar 94 14:15:52 GMT From: news-mail-gateway@ucsd.edu Subject: (none) To: ham-digital@ucsd.edu unsub llake1@services.dese.state.mo.us THANK YOU for your help and reply %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Lawrence (Larry) A. Lake * Lincoln County R-II School % % 208 Redwood Drive * Industrial Technology Department % % Elsberry, Missouri 63343 * Elsberry, Missouri 63343 % % Voice 314-898-5147 * Voice 314-898-2026 / 898-5553 % % E-mail llake1@services.dese.state.mo.us % % Packet kb0lco@k0pfx.#stl.mo.usa.na % % "Happiness is uniting your vocation with your avocation" % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ------------------------------ Date: 24 Mar 1994 04:54:23 GMT From: usc!howland.reston.ans.net!vixen.cso.uiuc.edu!newsrelay.iastate.edu!apollo1.cacd.cr.rockwell.com!zodiac.cca.cr.rockwell.com!newsfeed.ksu.ksu.edu!moe.ksu.ksu.edu!crcnis1.@@ihnp4.ucsd.edu Subject: [REPOST] The # in PBBS addresses.... To: ham-digital@ucsd.edu jangus@skyld.grendel.com (Jeffrey D. Angus) writes: >In article yarbrda@moose.gdss.grumman.com writes: > > What's the significance of the # in certain PBBS addresses? I've seen > > them used with some places and not in others. For example, my own is > > > > ke4dxa @n4lxi.#nova.va.us.noam. > ^-- North America (Continental Code) > ^----- United States (Country Code) > ^-------- State or Province > ^------------- State sub-divisor (Area) > ^-------------------- Destination BBS > ^---------------------------- User > the # symbol is an area designator. This way nova is not confused > with some other location. Slight correction to the above. The country code in packet radio is not us, it is usa. They are not the same and us is not acceptable at this time. There was talk at one time of using us, but it has not been adopted. On most systems that aren't wildcarded, us will become stuck. Gary ------------------------------ Date: 24 Mar 1994 07:49:45 -0600 From: ihnp4.ucsd.edu!swrinde!cs.utexas.edu!not-for-mail@network.ucsd.edu Subject: Baycom problem To: ham-digital@ucsd.edu I've just put together a Baycom modem. The transmit side works fine (tones are generated and the PTT triggers), but nothing seems to be received. I've traced the loudspeaker output through the modem chip and the 74HC14. The connection to the computer's CTS line is intact. My guess is that the computer's 8250 just isn't able to do anything with the 5V signal the 74HC14 produces. This in itself wouldn't surprise me, but the documentation with the program suggests that this isn't normally a problem. But I've connected the board to three different PCs now, and none of them receives anything. Could it be something else? Or is signal level mismatch a more common problem than the documentation would have you think? 73, Jim =========================================== Jim Donnett VE3LXS/G0MVY Dept. of Anatomy and Developmental Biology University College London Gower Street, London, WC1E 6BT e-mail: donnett@anatomy.ucl.ac.uk ------------------------------ Date: Thu, 24 Mar 1994 16:06:56 GMT From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!usenet.ins.cwru.edu!news.csuohio.edu!sww@network.ucsd.edu Subject: Baycom problem To: ham-digital@ucsd.edu I just went through the same thing. Watch the CTS out line for data when the radio is unsquelched and white noise is being fed to the audio input. If you are getting data out to the CTS, plug one of those boxes with the LEDs onto the line. Do you see the data? I did. But I still did not have a response on the screen. Run DEBUG and use the command "i 3fe". If you are on a port with a base address of 3f8, 3fe will be the input status register. A change in the returned value will indicate a change since the last read. I could verify that CTS was working by manually toggling the port using a breakout box. So CTS worked. I was putting data to the CTS line and the computer was capable of reading it but I was not seeing it. The solution was in a 25 to 9 pin adapter. It was a "full" adapter, they said. Well, it wasn't. It was not carrying the CTS through. Three more 25 to 9 adapters were the same way! My Logitech mouse plug adapter was the only 25 to 9 that carried the signal through. Good luck, 73, Steve ag807@cleveland.freenet.edu NO8M.#NEOH.OH.USA.NA ------------------------------ Date: 23 Mar 94 23:53:53 -0600 From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!newsrelay.iastate.edu!cobra.uni.edu!parickj4560@network.ucsd.edu Subject: Ever heard of Yaesu Ft 301??????? To: ham-digital@ucsd.edu Does anyone own a Yaesu Ft 301???? I have one and I was wondering if anyone else had one. I guess they are very hard to come by. Also does anyone have any ideas on how much the radio and matching power suply would cost? My radio is in mint condition. 73's N0ZYA temp AG Waterloo, Iowa ------------------------------ Date: 24 Mar 94 14:55:00 GMT From: news-mail-gateway@ucsd.edu Subject: FROM INTERNET 4597267@MCIMAIL.COM To: ham-digital@ucsd.edu HERE IS A LIST OF BOOKS ABOUT INTERNET AT WALDENBOOKS MOBILE, ALABAMA. 1. WHOLE EARTH ONLINE ALMANAC - DON RITTNER 2. ONLINE USERS ENCYCLO. - BERNARD ABBA 3. CONNECTING TO THE INTERNET - AN O'REILLY BUYER'S GUIDE 4. INTERNET: MAILING LISTS - EDWARD T. L. HARDIE /VIVIAN NEOU 5. THE INTERNET RESOURCE QUICK REF. 6. THE INTERNET NAVIGATOR - PAUL GILSTER 7. NAVIGATING THE INTERNET - GIBBS AND SMITH 8. THE INTERNET COMPANION - LAQUEY 9. RIDING THE INTERNET HIGHWAY - SHARON FISHER 10. THE INTERNET ROADMAP - BENNETT FALK 11. THE INTERNET YELLOW PAGES - HAHN AND STOUT 12. THE WHOLE INTERNET USERS GUIDE AND CATALOG- ED KROL 13. INTERNET: GETTING STARTED - APRIL MARINE/NEOU AND WARD I PURCHASED THE LAST BOOK. ALSO A GUIDEBOOK, ZEN AND THE ART OF THE INTERNET IS AVAILABLE ELECTRONICALLY, PLUS THERE IS A BOOK OUT BASED ON THE GUIDE, ZEN AND THE ART OF THE INTERNET: A BEGINNER'S GUIDE. BRENDAN KEHOE. THIRD EDITION JANUARY/1994. VIA N4SO KEN 4597267@MCIMAIL.COM NNNN ------------------------------ Date: 24 Mar 94 19:50:00 GMT From: news-mail-gateway@ucsd.edu Subject: G-TOR To: ham-digital@ucsd.edu Subject: Time:1:46 PM OFFICE MEMO G-TOR Date:3/24/94 Copyright 1994, Kantronics Co., Inc. All Rights Reserved. G-TOR is a trademark of Kantronics Co., Inc. Permission granted by Kantronics to post on Ham-Digital newsgroup. G-TOR(tm) The New, Faster HF Digital Mode for the KAM-Plus by Phil Anderson (1), W0XI, Michael Huslig, Glenn Prescott, WB0SKX, and Karl Medcalf, WK5M On New Year's Day, W0XI and WK5M transmitted a 9,718 byte file from Kansas to WA4EGT (2) in California on 20-meters in 5 minutes, 20 seconds. The mode was G-TOR. Immediately thereafter, the file was transmitted again, this time using Pactor. It took 20 minutes, 15 seconds. Throughout the month of January these tests were repeated with over one-million bytes transferred error-free. The average character/second rate for G-TOR was 23.7, for Pactor 8.64 (3). G-TOR, short for Golay-TOR, is an innovation of Kantronics, Inc. It's a new HF digital communications mode for the amateur service based somewhat on concepts outlined in the MIL-STD-188-100 series of documents (4). The error correction coding outlined in 188-141A (ALE) forms the basis for G-TOR. In order to keep costs low yet take advantage of concepts prescribed in the standards, G-TOR makes use of existing multi-mode TNC hardware but establishes a completely new hybrid ARQ system in firmware. The benefits of these innovations are: o dramatically increased throughput o apparent reduction in the effects of interference and multi-path o low cost The key features of G-TOR are: o extended Golay forward error correction coding o full-frame data interleaving o on-demand Huffman data compression with run-length encoding o link-quality based baud rate: 300, 200, or 100 o 2.4 second hybrid-ARQ cycle o fuzzy acknowledgements o reduced overhead within data frames o standard FSK tone pairs (mark and space) Background Research It occurred to us after porting Pactor into the KAM that this protocol did not go far enough. It did not incorporate any of the potential strengths prescribed by MIL-STD-188-141A. In addition, we knew that commercial and military systems use forward error correction (FEC) and data interleaving. So, we decided to evaluate the potential of using FEC coding with interleaving to increase data file transfer throughput with existing multi-mode TNCs such as the KAM and KAM-Plus. We collected signatures of HF error patterns by sending Pactor idle characters through a DSP-based HF simulator. The simulator was programmed for various types of channels and conditions. In particular, we gathered error signatures by using the good, moderate, poor, and flutter fading channels prescribed by the CCIR (5) as recommended simulator test channels. We then exclusive-ORed the error patterns with random data files on a PC and tested various coding schemes. Random data files were Golay encoded, interleaved, and then mutilated by the error signature. The process was then reversed; each file was de-interleaved, decoded and the data displayed. We were encouraged with the results so we moved on to the remaining major design tasks: designing a robust ARQ protocol and determining whether or not the TNC could handle the necessary computing task! Over several months we evolved a protocol that met the challenge. It was coded and ported into the KAM-Plus and real-time tests were conducted using the HF simulator. Minor adjustments were made - as in all projects - and we began on-the-air tests. Tests showed G-TOR to be even better than our simulator predicted. Through a combination of coding and interleaving, G-TOR 'hangs in there' when channel conditions get tough. G-TOR Frame Structure and ARQ Cycle G-TOR operates as a synchronous ARQ mode 1. Regardless of transmission rate, the cycle duration is always 2.4 seconds, data frames are 1.92 seconds long, and the acknowledgements take 0.16 seconds. At 300 baud, each data frame contains 69 bytes of data, one control byte, and a two byte CRC. At 200 baud the frame contains 45 data bytes, and at 100 baud 21 data bytes. Synchronization is established during the linking phase when the calling station (master) sends a G-TOR frame containing TO and FROM callsigns. The information receiving station (IRS), while in standby, synchronizes to the frame by searching for its callsign. Once in step, it acknowledges such to the master and sends to its terminal. Transmission of data may then begin. Sufficient time is left between the end of the data frame and the start of the acknowledgement for propagation between stations over an HF path. A change in information flow direction (changeover) is accomplished by extending the acknowledgement bytes into a changeover frame. Once acknowledged by the other station, changeover is complete. Link quality, dictated by the number of consecutive good or bad frames received, determines link speed. The effective performance of stations, while communicating over adverse HF channels, relies on the combined use of forward error correction, interleaving, and redundancy. These tools for improvement are incorporated in G-TOR within the firmware of the KAM-Plus (or KAM with enhancement board). We adopted an extended version of the (24,12) Golay code for G-TOR. Procedures for data formation, transmission, reception, and data recovery are outlined below. Prior to transmission, 300 baud frames are divided into 48 12-bit words and matched with 48 error correction words of 12 bits each. The entire 72 byte data frame is then interleaved bit by bit, resulting in 12 bins of 48 bits, and transmitted . Upon reception by the IRS, the reverse process is carried out. The frame is synchronized, de-interleaved, decoded, and checked for proper CRC. If the frame is found to be in error, the IRS will request that the matching parity frame be sent. Upon receipt, the parity frame is used in combination with the data frame in an attempt of recover the original data bits. If unsuccessful, the ARQ cycle begins again. The dispersement of noise-burst errors via interleaving and the power of the Golay code to correct 3 bits in every 24 usually results in the recovery of error-free frames. On-The-Air Testing During the month of January over a million bytes were transferred error-free from Lawrence, Kansas to Laguna Niguel, California. During these tests, TRACE was set ON at each station, enabling the display of acknowledgement bytes and data frames including control bytes. This allowed us to view and count data and acknowledgement frames received with and without the aid of forward error correction and interleaving. The results were somewhat surprising! While Pactor often dropped in transmission speed from 200 to 100 baud, G-TOR nearly always kept on crunching frames at 300 baud! Enough frames are corrected to keep the system running at 300 baud, regardless of man-made interference and mild multi-path conditions. This was apparent as G-TOR seldom dropped automatically from 300 to 200 baud. Transfer duration for the entire test file varied from 12 to 27 minutes for Pactor but only 5.5 to 7.5 minutes for all but one transfer in G-TOR. G-TOR simply maintained its highest pace better, resulting in a substantial increase in average throughput. Operation of G-TOR is much like AMTOR. You enter G-TOR standby by typing and in response to the cmd: prompt. From standby you can copy AMTOR FEC (also used as the calling mode for G-TOR CQs), or wait for a G-TOR link request from another station. To initiate a link with another station, you must type . The link is then established and the TNC reports . During a QSO, changeover is dictated by the usual keyboard (or host-mode) directives, and . Conclusion G-TOR features include Golay forward error correction coding, full-frame interleaving, on-the-fly Huffman data compression with run-length encoding, fuzzy acknowledgments, a long ARQ cycle of 2.4 seconds, and a link-quality based transmission rate. Combined, these techniques result in a new, very robust, interference-resistant, and existing equipment compatible mode for HF digital communication for the amateur radio service. Throughput exceeds other existing all-mode TNC modes by better than two-to-one. G-TOR is not available for KAMs without the enhancement board since EPROM space has been used up. G-TOR is now standard in the KAM-Plus and the Enhancement Board for the KAM (predecessor of the KAM-Plus). 1. Kantronics Inc., 1202 E 23rd Street, Lawrence, KS, 66046, 913-842-7745, fax 913-842-2021. 2. Towle, Jeff, InterFlex Systems, PO Box 6418, Laguna Niguel,CA, 92607. 3. Van Der Westhuizen, Mike, ZS6UP, "A Practical Comparison Between Clover and Pactor Data Transfer Rates," CQ, February, 1994. 4. Military Standard (MIL-STD) series -188-100, containing standards common to long-haul communications, Department of Defense. Specifically MIL-STD-188-141A, Interoperability and Performance Standards for Medium and High Frequency Radio Equipment. 5. Recommendations of the CCIR, 1990, Volume III. (Fixed Services at Frequencies Below About 30 Mhz), Recommendation 520-1, page 28. G-TOR is a trademark of Kantronics, Inc. ------------------------------ Date: 24 Mar 94 21:32:44 MDT From: ihnp4.ucsd.edu!dog.ee.lbl.gov!hellgate.utah.edu!cc.usu.edu!sltmw@network.ucsd.edu Subject: Heathkit HD-4040 TNC To: ham-digital@ucsd.edu In article <940321065400983@ctobbs.com>, kim.leong@ctobbs.com (Kim Leong) writes: > I don't think my original post made it into this group so I'm > re-posting. > > I have a Heathkit HD-4040 TNC that I built and had in service about 8 > years ago. I have been off packet for about 6 years. I dug the TNC out > of its burial box and am interested in getting back on packet with it. > The question I have is if there are some firmware or other updates > anyone knows of that should or can be done to the HD-4040. > > Thanks, > > Kim Leong - WA6QQF > BBS: Sysop @ (510) 799-2921 > Internet: kleong@ctobbs.com I use two HD-4040's...got 'em for about 25 bucks each, and one has a TAPR TNC-2 upgrade (DCD decoding too), and the other one has the WA7MBL firmware in it. They both work great! (I have the TNC-2 clone running KISS, and use JNOS) If you can get the upgrade, I would seriously consider it...Don't bother with the WA7MBL code (It is quality stuff, but no KISS mode) -- ------------------------------------------------------------------------------- Daniel D Holmes " " - Marcel Marceau Internet: SLTMW@CC.USU.EDU AmprNet: N7NKR @ N7NKR.HOME.AMPR.ORG 44.40.1.43 [located in Salt Lake City] N7NKR @ N7NKR.AMPR.ORG 44.40.12.10 [located in Logan] ------------------------------ Date: 24 Mar 94 20:04:07 GMT From: news-mail-gateway@ucsd.edu Subject: HF Digital Throughput To: ham-digital@ucsd.edu Subject: Time:1:52 PM OFFICE MEMO HF Digital Throughput Date:3/24/94 Based on published test data, here is my reading on the typical throughput (characters per second) to be expected from several HF digital modes: RTTY 6 AMTOR (ARQ) 5 Packet AX.25 4 PacTOR 10 G-TOR 25 CLOVER II 50 Note that Huffman data compression is available in the PacTOR and G-TOR protocols to increase throughput for certain data. Note also, that these throughputs are not normalized to occupied bandwidth. If one looks at characters per second per hertz there are even more dramatic differences. 73/Rick W0TN ------------------------------ Date: Thu, 24 Mar 1994 16:24:28 GMT From: ihnp4.ucsd.edu!galaxy.ucr.edu!library.ucla.edu!agate!usenet.ins.cwru.edu!news.csuohio.edu!sww@network.ucsd.edu Subject: HP100LX Palmtop & Baycom? To: ham-digital@ucsd.edu Steve Wolf (sww@csuohio.edu) wrote: : : Has anyone been able to get Baycom to work on the Hewlett Packard : 100LX palmtop? After externally powering the Baycom, I was able : to transmit readable packets. However, it does not appear that : the HP is reading the CTS line. I have verified that data is : going to the CTS out. : : There is a pretty good user support group on comp.palmtops and HP : seems interested in any application it can be put to. I wanted to : check here first. : : Also, the paltop runs the MSYS BBS without a complaint. Running with : 300 message slots and about 500 BIDs left me over 150k free (so I could : make lots more slots and BID space). : : Interesting that a 80188-based machine can run the serial port at : 57k yet we have to watch our BBS phone ports for dropped characters. : : 73, : Steve : ag807@clevland.freenet.edu < works better : NO8M@NO8M.#NEOH.OH.USA.NA : The solution to this problem was not easy. I verified that the HP was seeing CTS (through reading the status register) and that the Baycom was sending information through a meter. It turned out that a problem I had before came back. A 9 to 25 adapter did not carry the signal through. Three of them didn't. Only the Logitech adapter for my mouse worked. I now have those marked as problems. 73, Steve ag807@cleveland.freenet.edu NO8M@NO8M.#NEOH.OH.USA.NA ------------------------------ Date: 23 Mar 94 23:07:52 GMT From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!darkstar.UCSC.EDU!nic.scruz.net!cruzio!comix!jeffl@network.ucsd.edu Subject: KPC-3 and TCPIP To: ham-digital@ucsd.edu In article dparker@netcom.com (Dave Parker) writes: >One thing to consider is there is no upgrade for 9600 bps on this >TNC, look at the DRSI DPK-2 at least it has a modem disconnect >header so you can use an external high speed modem later if you wish. >Its priced roughly in the same ballpark as the KPC-3. >Dave, KD6RRS This is a plug. I just bought an AEA PK-96. This is a new TNC. It's a combination AFSK (1200 baud) and FSK (9600 baud G3RUH) tnc. In theory, you can have it all in one package. No ripping out the disconnect header every time you switch. I overpaid at $190 but am not complaining. It draws 400ma at 13.6v (3.5w) so it's not exactly suitable for battery operation. Too soon to tell if it's any good. Anyway, it is possible to buy a TNC that will do both 1200 and 9600. IMHO, tcp/ip should be run at 9600 and not 1200. It's just too slow. -- # Jeff Liebermann Box 272 1540 Jackson Ave Ben Lomond CA 95005 # 408.336.2558 voice wb6ssy@ki6eh.#nocal.ca.usa wb6ssy.ampr.org [44.4.18.10] # 408.699.0483 digital_pager 73557,2074 cis [don't] # jeffl@comix.santa-cruz.ca.us scruz.ucsc.edu!comix!jeffl ------------------------------ Date: 24 Mar 1994 15:49:04 GMT From: ihnp4.ucsd.edu!swrinde!elroy.jpl.nasa.gov!ncar!csn!col.hp.com!jms@network.ucsd.edu To: ham-digital@ucsd.edu References <2mksi3$mal@crl.crl.com>, <2mnbtp$sr7@hpbab.mentorg.com>, <1994Mar23.180631.11120@mnemosyne.cs.du.edu> Subject : Re: KPC-3 and TCPIP : >KPC-3 is excellent value for the money. : If you only want to go 1200 baud it's fine and if you want to keep the same : EPROM in it it's fine. But if you ever want to modify it for high speed : or DCD or KISS only you'll regret buying as I did. : Just my opinion and expierience, : 73, Nate The KPC-3 already has KISS capability. Mike, K0TER ------------------------------ End of Ham-Digital Digest V94 #81 ****************************** ******************************