Date: Wed, 6 Apr 94 04:30:22 PDT 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 #99 To: Ham-Digital Ham-Digital Digest Wed, 6 Apr 94 Volume 94 : Issue 99 Today's Topics: Baycom TCP/IP Software FTP-able copy of AX.25 standard? GTOR INFO Looking for Wampes docs... MFJ 1270C & Netrom MFJ 1270C TNC and Host Mode Unknown RTTY mode (2 msgs) 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 Apr 94 11:59:33 GMT From: ncrgw2.ncr.com!ncrhub2!ciss!wtcp!blangos@uunet.uu.net Subject: Baycom TCP/IP Software To: ham-digital@ucsd.edu Is there a driver available for TCP/IP on the Baycom software and modem? Thanks -- Bruce Langos Workstation Products Division F&A Bruce.Langos@wtcp.DaytonOH.NCR.COM ...!uunet!ncrcom!ciss!wtcp!blangos ------------------------------ Date: 5 Apr 1994 11:38:09 GMT From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!xlink.net!news.urz.uni-heidelberg.de!rz.uni-karlsruhe.de!rzstud1.rz.uni-karlsruhe.de!ukkt@network.ucsd.edu Subject: FTP-able copy of AX.25 standard? To: ham-digital@ucsd.edu Johnny B. (mrmoose@netcom.com) wrote: : "American Radio Relay League, Inc., AX. 25 Amateur : Packet-Radio Link-Layer Protocol, Version 2.0, : October 1984 (or compatible)," : At any rate, is it around? You can get it by email from info@arrl.org. Send a msg with HELP in the body of the msg to get information how to use the info-server. jochen -- ########## Jochen Topf email: ukkt @ rz.uni-karlsruhe.de ## Schlehenweg 20 ax25 : DH0GAG @ DB0GE.#SAR.DEU.EU #### 76149 Karlsruhe ## ## 0721-756508 #### W3-Link ------------------------------ Date: 5 Apr 94 23:28:47 GMT From: news-mail-gateway@ucsd.edu Subject: GTOR INFO To: ham-digital@ucsd.edu THE FOLLOWING TEXT WAS PICKED UP FROM THE DL2FAK PACTOR MBX IN GERMANY BY VE2FK IN MONTREAL. IT WAS WRITTEN BY DL2FAK, ONE OF THE DEVELOPERS OF PACTOR. G-TOR - An Improvement? G-TOR is a new digital mode, which has been developed by Kantronics. Most of its features (like on-line Huffman data compression, link-quality based baud rate adjustment, CRC, fundamentals of the packet structure, etc.) are adopted from PACTOR. The baud rate used in G-TOR can be 100, 200 or 300 baud. The main differences are the use of Golay forward error correction coding with the ob- ligatory data interleaving and a hybrid ARQ system. The Golay encoding however, as used in the G-TOR mode, is only able to correct 3 bits in a block of 24 bits and only half of this block (12 bits) carries in- formation. The remaining 12 bits have to contain the required redundancy, and no new data. It is therefore only possible to correct a few errors despite the large overhead. For this reason the Golay encoding would only be useful for errors caused by short spikes on the higher short wave frequencies (10 to 20m). You cannot however expect it to provide any improvements in typical 80m con- ditions. Here it is necessary not only to use hybrid-2 ARQ systems, but also suitable, powerful (invertible) codes, which allow the reconstruction of the original information, even when only the redundancy block is received, rather than Golay or similar simple block coding, which always requires both blocks to be received to get the data transferred. The most robust HF (short wave), narrow band, data transmission systems known, apply very powerful convolutional codes with Viterbi decoding and soft deci- sion (requiring an ADC/DSP just like analog Memory-ARQ). The processing speed of those systems exceeds the capability of a KAM by factor 100. Despite this very expensive approach, they only achieve around 10 dB better weak signal performance than PACTOR-1. The closer a system approaches the Shannon boundary (theoretical throughput limit) the more difficult it gets to gain another one or two decibels. W0XI et al claim that they were able to transfer a certain file on the 20m band in about 5 minutes using G-TOR, whereas PACTOR, which was used afterwards, took about 20 minutes. The conclusion was that G-TOR would be about 4 times faster than PACTOR in general, which is actually impossible!! According to the system description, G-TOR can on average only be about 1.5 times faster than PACTOR. The 20m band, which was used for the tests, normally provides a good SNR and only very few fluctuations. It is therefore obviously no problem to reach higher throughputs, especially when using 300 baud (even short wave Packet Radio could have been faster than PACTOR in this case). Also, the comparison between PACTOR and G-TOR was based on the PACTOR implementation in the KAM, which does not, apparently, provide the full performance anyway, due to the different converter and the missing ADC. Since the KAM already uses a modem designed for 300 baud operation, it is obvious that G-TOR is favoured. The original PACTOR system will still do better than G-TOR on weak signals, as an ADC is used in the PACTOR-Controller (PTC) to allow real analog Memory-ARQ. To achieve impartial results, you have to transfer the same files containing random characters on the typical 80m conditions in G-TOR using two KAMs and in PACTOR using two PTCs. The 8.64 characters per second, considered to be the typical average throughput of PACTOR, and which led to the conclusion that G-TOR would be 4 times faster than PACTOR, are much slower than the average rate we obtained with our units. Under even worse conditions we obtained around 17 characters per second, depending on the transferred information due to the Huffman coding. Regardless of the Huffman data compression, which improves the throughput of both systems in the same way, the comparison of throughput between PACTOR and G-TOR can be easily calculated. According to the protocol description pub- lished by W0XI, G-TOR is able to transfer a maximum of 19 characters per se- cond when running on 200 baud (They claim 69 data bytes in a cycle duration of 2.4 seconds at 300 baud, which means maximum 2/3*69/2.4 characters per second at 200 baud). The maximum rate of PACTOR at the same speed is 16 chrs/s, which is a relationship of 1.18 to 1. The Golay encoding is not able to improve the throughput so dramatically that you finally result in a factor 4. It must be remembered that the analog Memory-ARQ, as used in the original PACTOR imple- mentation, is able to improve the effective signal-noise ratio with each ag- gregated packet and hence enables a higher throughput (especially in weak con- ditions) than the Golay coding gain. It is therefore obvious that the higher maximum throughput of G-TOR is mainly based on its higher maximum baudrate. This however means, it has to exceed the usual 500 Hz band width limit. With this in mind it must also be remembered that a wider receiver bandwidth receives more noise. A 300 baud G-TOR signal will therefore have a poorer S/N ratio than a 200 baud PACTOR signal (if they are both of the same fieldstrength and the receiver bandwidth is correctly adjusted for both modes). As signals decrease, G-TOR would have to switch to 200 baud before the PACTOR signal would be affected, thus further reducing some of the proposed speed gain. There are still some more disadvantages of G-TOR in comparison to PACTOR, e.g. the cycle duration is quite long at 2.4 seconds, and will increase to almost 5 seconds when using the Golay encoding, hence leading to quite long break-in times. The speed adaptation times are necessarily also longer, thus leading to poorer results in rapidly changing conditions (multipath). Furthermore, the interleaving and the 3 different baud rates used in G-TOR will probably lead to a lot of problems with the listen mode, an important point for all digital modes used in Amateur Radio. Actually G-TOR is just a modified PACTOR system, which probably does not pro- vide enough improvement that introducing this mode as another new standard would be worth-while. With regard to the basic requirements of each digital data transfer mode (like throughput, bandwidth, error rate, etc.) PACTOR al- ready represents nearly the optimum attributes that are obtainable with an FSK system. A real improvement over the current PACTOR system can only be reached when using different modulation schemes like PSK, which require a DSP hardware. This step will be done this year with the introduction of PACTOR Level-II. Tom Rink, DL2FAK via VE2FK via W0MFK via WT0N ENJOY, I JUST GOT MY GTOR UPGRADE TODAY, IF YOU WANT TO TEST GTOR LET ME KNOW AND I WILL SET THE AMSAT PBBS ON 30 METERS UP FOR GTOR USE. YOU CAN CONTACT ME AT IN BJARTS@STTTHOMAS.EDU PAC. WT0N@WB0GDB.#STP.MN.USA.NOAM ------------------------------ Date: 5 Apr 94 18:29:34 GMT From: sdd.hp.com!vixen.cso.uiuc.edu!eagle.sangamon.edu!freeman@hplabs.hp.com Subject: Looking for Wampes docs... To: ham-digital@ucsd.edu Hello, I'm looking for any docs on setting up Wampes under Linux. The docs with the package consist of one skimpy readme file. Thanks, Jay -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Jay Freeman, WT9S Packet: wt9s@w9yci.il.usa.noam + + internet: freeman@eagle.sangamon.edu + + finger for PGP public key. + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ------------------------------ Date: 5 Apr 94 22:13:33 GMT From: news-mail-gateway@ucsd.edu Subject: MFJ 1270C & Netrom To: ham-digital@ucsd.edu > In a previous article, chuckv@comtch.iea.com (Chuck Vyverberg) says: > > >I saw some messages the last couple fo week giving detailed instructions > >on how to get the MFJ1270C TNC to run as a netrom node. > > > > To use the MFJ1270C with netrom or TheNET, all you need to do is program > a 27256 EPROM with the modified firmware module (V2.08B is the one I have > in three digi's in central IL) and plug it in. No circuit mods are > required. > > Installing an X1J node is another matter... > > 73, Drew > > -- > *-----------------------------*-------------------------------------* > | Andrew B. White K9CW | internet: k9cw@prairienet.org | > | ABW Associates, Ltd. | phone/fax: 217-643-7327 | > *-----------------------------*-------------------------------------* Yes there is a mod required to use the C version of the tnc with TheNet or X1J. Here's a copy of the message that went around about it. Bill N8KHN healy@moriah.ee.unr.edu X1/TheNET mods for MFJ-1270C From: WB0YRQ@NF0N.#NENE.NE.USA.NA To : INFO@ALLUS WB0YRQ @ NF0N.#nene.ne.usa.na /TPK 1.81 Msg #:751 Date:02-01-80 Time:9:56Z To modify the MFJ-1270C for use with X1J/Thenet EPROMS follow these instructions: You must complete all of these steps in order for Netrom firmware to function. NOTE: if you are not using X1J firmware skip the first step and make sure that JP15 is set for 256k. Step 1: Bend pin 1 of 27c512 out so it will not touch socket, then jumper pin 1 of 27c512 to pin 8 of MODEM header J4. (see X1J docs) Step 2: Remove U40. Add jumper from pin 16 to pin 1 (ground pin 16) ^ [I think this should be 10 (gnd)] Step 3: Remove JMP9 altogether (no jumper on any pins) Step 4: Cut JMPX "PAD" to prevent node from hearing itself Step 5: Add 100ohm resistors to R14 and R15 if not already in place. This information came directly from MFJ and I have used it successfully. Hope this helps you. ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD? 3 IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM; 3 3 : [[221100 73's de Al WB0YRQ @ NF0N.#NENE.NE.USA.NA 001122[[ : 3 3 : [[221100 Akron, Iowa. 712-568-2810 GRID 001122[[ : 3 3 : [[221100 TCP/IP 44.50.2.6 001122[[ : 3 3 : [[221100 Internet: SCHEMMERAL@BVC.EDU 001122[[ : 3 3 HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM< 3 @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY ------------------------------ Date: 5 Apr 94 22:29:53 GMT From: sdd.hp.com!saimiri.primate.wisc.edu!news.doit.wisc.edu!news@hplabs.hp.com Subject: MFJ 1270C TNC and Host Mode To: ham-digital@ucsd.edu I've been looking through my TNC documentation, and the only reference I find to host mode mentions that documentation is available on diskette, but no command is given for putting the TNC into host mode. Can anyone help? 73, Tom N9UDL ------------------------------ Date: Tue, 5 Apr 1994 20:05:39 GMT From: ihnp4.ucsd.edu!swrinde!gatech!newsxfer.itd.umich.edu!nntp.cs.ubc.ca!alberta!quartz.ucs.ualberta.ca!kakwa.ucs.ualberta.ca!gov.nt.ca!ve8ev@network.ucsd.edu Subject: Unknown RTTY mode To: ham-digital@ucsd.edu Keywords: teletype RTTY digital signal identification In regards to the questions on RTTY signals on the SW bands: There are hundreds of different FSK modes in use by government and commercial HF stations worldwide. 95% of these are encrypted so that they cannot be decoded without the proper key (usually some form of bit inversion). In addition to the coded signals, there are also stations using odd speeds and shifts and stations transmitting non-roman text, ie, chinese, korean, etc. If you are interested in decoding some of these transmissions, Universal Radio makes several high end digital decoders which can probably decode a large percentage of what is out there. 73 John Boudreau ve8ev@inukshuk.gov.nt.ca ------------------------------ Date: Tue, 5 Apr 1994 16:22:10 +0000 From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!pipex!demon!isis.demon.co.uk!ian@network.ucsd.edu Subject: Unknown RTTY mode To: ham-digital@ucsd.edu In article jdc@cci.com "James D. Cronin" writes: >I have also run into these signals. I always thought the inability >to decode them was due to shortcomings in hardware interface and >software. (I use Hamcom 2.2 with the 741 op-amp interface.) But >this may not be the case. > >After receiving the last half of a weather-fax map, the station switched >to RTTY. It was strong signal, and the weather-fax came in OK. After >it switched to RTTY I fired up Hamcom 2.2. It was easy to figure out >frequency shift and baud rate with the "Spectrum" and "Bit length" >screens. But the text was undeciperable gobbledygook. > >Seems like it must be some type of maritime-related station. Anybody >have more specific info? Are you sure that Hamcom isn't just letter shifting ? A lot of weather related RTTY is almost purely numeric. Most decoders will tend to assume that they've missed a letter shift and just switch modes after a few numbers. From then on it is gobbledygook. You can switch off the automatic shift. Regards Ian. -- | Ian Smith | "The Moving Finger writes; | ian@isis.demon.co.uk | and, having writ, Moves on." ------------------------------ Date: 5 Apr 1994 17:41:22 GMT From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!pipex!sunic!psinntp!psinntp!news.mentorg.com!hpbab33.mentorg.com!wv.mentorg.com!hanko@network.ucsd.edu To: ham-digital@ucsd.edu References <2na50c$bsl@network.ucsd.edu>, <2nfdlm$llk@hpbab.mentorg.com>, <1994Apr1.102339.15324@hemlock.cray.com> Reply-To : Hank_Oredson@mentorg.com Subject : Re: [REPOST] The # in PBBS addresses.... In article <1994Apr1.102339.15324@hemlock.cray.com>, andyw@aspen32.cray.com (Andy Warner) writes: |> |> In article <2nfdlm$llk@hpbab.mentorg.com>, hanko@wv.mentorg.com (Hank Oredson) writes: |> > [...] |> > Or is there some magic required of the subdomains of .ampr.org |> > that is not required of other .org subdomains? |> |> Maybe some semblance of responsibility - it sounds like you want |> to hide an ad hoc network behind a "correctly implemented" |> (in internet terms) one, without having to to actually change |> anything. This is a two way street, if you want the "advantages" |> offered by high connectivity, you may need to change a few things |> (and - gasp - admit some things were badly thought out, or badly |> implemented..). Fidonet seem to have grasped that point years ago.... |> |> Of course, folks can always retreat into the "why would we ever |> want to connect to anyone else" mindset, the last bastion of |> people who see their empire crumbling... This is the third try. Thus far, the responses have only been "The way it is done now is wrong." This is from at least three avowed "networking experts." However, "It is wrong" is useless information. We all perfectly willing to agree that it is wrong. I have been attempting to get answers to a different question, let me try it again. "What should we do so it is done right?" So far, nobody has posted any useful response to this question. Can you explain what you meant by "... ad hoc network..." and give examples of "non-ad hoc networks"? This might be helpful information. Long ago and far away (when this packet stuff all started) several of us asked the same question, and go much the same answers we are getting now: "No No No, you are DOING IT ALL WRONG". We got tired of this and simply went ahead and defined our own subdomains of ampr.org. Again, we have the same response from the "networking gurus", but a total lack of useful information. If indeed "we got it all wrong", what should we do to fix that? Waiting with 'bated breath for an educational reply ... ... Hank -- Hank Oredson @ Mentor Graphics Internet : hank_oredson@mentorg.com Amateur Radio: W0RLI@W0RLI.OR.USA.NOAM ------------------------------ End of Ham-Digital Digest V94 #99 ****************************** ******************************