Date: Sat, 11 Dec 93 04:30:26 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 #143 To: Ham-Digital Ham-Digital Digest Sat, 11 Dec 93 Volume 93 : Issue 143 Today's Topics: 1933 vs. 1935 HDLC 9k6 baud packet - is there any point? COMPLETE Documented NOS Wanted Digital Cellular HP48 Communications (2 msgs) Need advice on using tube-final rigs for RTTY/AFSK NETMGR a tool for R.O.S.E. Scrambler lockup W9GR DSP article of Sept 1992 QST X1J at 38.4 kbps 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: Thu, 9 Dec 1993 05:35:17 GMT From: news.Hawaii.Edu!tony@ames.arpa Subject: 1933 vs. 1935 HDLC To: ham-digital@ucsd.edu What is the difference between a WD 1933 and a WD 1935? I notice that the manual/schematic for some TNC-1 clones show a 1933 but when you pop the thing open there's a 1935 in there. -- Antonio Querubin tony@mpg.phys.hawaii.edu / ah6bw@uhm.ampr.org / querubin@uhunix.bitnet ------------------------------ Date: 10 Dec 1993 11:10:25 -0600 From: mvb.saic.com!unogate!news.service.uci.edu!usc!howland.reston.ans.net!gatech!concert!corpgate!crchh327.bnr.ca!debaker@network.ucsd.edu Subject: 9k6 baud packet - is there any point? To: ham-digital@ucsd.edu In article <755446538snx@llondel.demon.co.uk>, dave@llondel.demon.co.uk (David Hough) writes: |> In article froud@sunlab41.sx.ac.uk (How much wood could a woodchuck chuck if a woodchuck could chuck wood?) writes: |> >Just a minor point I wouldn't mind cleared up if anyone has a few seconds... |> > |> >I read that rigs had to be modified to allow upwards of 2k4 baud transmission, |> >but is this pointless if the person you are trying to commmunicate with |> >hasn't a repicrocal modification at the either end to allow reception of |> >higher baud transmissions? |> > |> Unlike land-line modems, there is no speed negotiation on packet (unless you |> are using strange kit) so you have to set up your rig/TNC to work at a |> particular speed. Once you have tried 9600baud you will think that 1200 is |> *very* slow. It isn't hard to modify rigs either.... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ OK, now I am ready to get some info on modifying rigs for 9600! I have a kenwood TM-742A that I would like to use...does anyone know where I can find information explaining how to do this? Also, how do I go about finding a 'full sevice PBBS' (if that is what I am looking for) in order to send long distance packet mail, i.e. to an address of a person in another city or state (or country)?? |> |> Dave |> -- |> |> ***************************************************************************** |> * G4WRW @ GB7WRW.#41.GBR.EU AX25 * Start at the beginning. Go on * |> * dave@llondel.demon.co.uk Internet * until the end. Then stop. * |> * g4wrw@g4wrw.ampr.org Amprnet * (the king to the white rabbit) * |> ***************************************************************************** Thanks, 73, ____________________________________________________________ | David E. Baker Opinions expressed are | | Callsign: AB5PI mine, and they do not | | Internet: debaker@bnr.ca necessarily reflect | | IP Addr: 47.122.65.7 the opinions of BNR or | | Unix ID: crchh7b0 or Northern Telecom. | |----------------------------------------------------------| ------------------------------ Date: Wed, 8 Dec 1993 18:32:12 GMT From: nih-csl!helix.nih.gov!mack@uunet.uu.net Subject: COMPLETE Documented NOS Wanted To: ham-digital@ucsd.edu In article <9312012304.tn22729@aol.com> writes: >I would like to know how I could attain a copy of the latest version of KA9Q >unmodified NOS. I would appreciate it if I could find a package with complete >documentation that includes the file BM.EXE. Please send responses to >MattHarvey@aol.com OR KD4AZH@KB4GBS.#TPA.FL.US.NOAM. > >Thank you. Do you know about the book from tthe ARRL (forget what it's called - comething like NOSGUIDE). Unfortunately it's pitched at a very low level. Joe NA3T mack@ncifcrf.gov ------------------------------ Date: Wed, 08 Dec 93 12:49:04 MST From: pacbell.com!sgiblab!swrinde!cs.utexas.edu!asuvax!ennews!stat!aznet!dan@network.ucsd.edu Subject: Digital Cellular To: ham-digital@ucsd.edu We are currently running Digital in our system, but it is still undergoing testing and is not accessible by the public just yet. We are testing the format of CDMA. Dan ---------------------- dan@aznet.stat.com Daniel J. Meredith Fax - (602) 956-2566 Voice - (602) 809-0555 ------------------------------ Date: 10 Dec 1993 08:39:06 -0600 From: mvb.saic.com!unogate!news.service.uci.edu!usc!cs.utexas.edu!swrinde!gatech!news-feed-1.peachnet.edu!concert!corpgate!crchh327.bnr.ca!kharker@network.ucsd.edu Subject: HP48 Communications To: ham-digital@ucsd.edu In article , jann0004@maroon.tc.umn.edu (Scott Jann) writes: |> I am looking for a cheap way to communicate between two HP-48 calculators |> (longer than the build in IR can do), maybe 50-100 feet. I have heard of |> people modifying walkie-talkies to use with the hp48. I don't want to use |> TNC equipment....too expensive for me. |> How would I go about modifying a walkie-talkie to do digital |> communications? I don't care about error checking or anything, just a way |> to send simple ascii messages. |> Can anyone help me with doing this? |> |> Thanks As another idea, I have seen infrared "repeaters" little red pyramid-shaped things that relay the signals of tv remotes and whatnot. Perhaps a strategically placed one (if you're going to be using the calculators basically in the same area all the time) would do the trick. Don't know where you'd go to find one of these things. Probably saw it in a Damark catalog or someplace like that. -- ====================================================================== Kenneth E. Harker BNR "Any opinions expressed kharker@bnr.ca Richardson, Texas, USA are solely mine and do N1PVB (214) 684-5115 not represent BNR" ====================================================================== ------------------------------ Date: Fri, 10 Dec 1993 05:12:47 GMT From: pacbell.com!sgiblab!swrinde!cs.utexas.edu!howland.reston.ans.net!gatech!news-feed-1.peachnet.edu!umn.edu!dialup-1-75.gw.umn.edu!user@network.ucsd.edu Subject: HP48 Communications To: ham-digital@ucsd.edu I am looking for a cheap way to communicate between two HP-48 calculators (longer than the build in IR can do), maybe 50-100 feet. I have heard of people modifying walkie-talkies to use with the hp48. I don't want to use TNC equipment....too expensive for me. How would I go about modifying a walkie-talkie to do digital communications? I don't care about error checking or anything, just a way to send simple ascii messages. Can anyone help me with doing this? Thanks ------------------------------ Date: Thu, 9 Dec 1993 16:50:30 GMT From: pravda.sdsc.edu!usc!howland.reston.ans.net!europa.eng.gtefsd.com!emory!rsiatl!ke4zv!gary@network.ucsd.edu Subject: Need advice on using tube-final rigs for RTTY/AFSK To: ham-digital@ucsd.edu In article alanb@sr.hp.com (Alan Bloom) writes: >Patric M Stickler (stickler@klaava.Helsinki.FI) wrote: >: How can one >: estimate the max. drive the finals can take at 100% duty cycle? > >If the rig has an AM mode, use the AM carrier power rating. Good. >Even better, mount a 3 or 5-inch muffin fan on the side of the cabinet >blowing directly on the final amplifier tubes. With that, you should >be able to run full CW power on digital modes. The main limitation then >will be the power transformer -- As long as you keep the transmit time >below 50% (at least 50% listening time), you should be OK. Not so good. The limitation isn't usually raw envelope temperature, it's the temperature of the plate structure and the seals at the connections. With sweep tubes, you can't cool them effectively enough with a muffin fan to get even 50% power, much less 100% power when key down time exceeds a few seconds. The plate structures aren't up to it, and you need to get airflow across the base seals, and they're masked by the tube socket. Real transmitting tubes are better because their plate structures are heavier, but you still have seal problems unless you have air sockets. Best, of course, are external anode tubes mounted in proper air sockets with proper chimneys. Low duty cycles are good, but you still have to watch absolute key down times. If the key down time exceeds the thermal inertia of the tube, you've got to treat it like it's 100% duty cycle use. Gary -- Gary Coffman KE4ZV | I kill you, | gatech!wa4mei!ke4zv!gary Destructive Testing Systems | You kill me, | uunet!rsiatl!ke4zv!gary 534 Shannon Way | We're the Manson Family | emory!kd4nc!ke4zv!gary Lawrenceville, GA 30244 | -sorry Barney | ------------------------------ Date: 7 Dec 1993 22:45:42 -0500 From: kb2ear.ampr.org!not-for-mail@princeton.edu Subject: NETMGR a tool for R.O.S.E. To: ham-digital@ucsd.edu Bill Slack NX2P asked me to post this. NETMGR is a Windows based ROSE network managment took. It allows the ROSE network manager or switchOP to graphically draw the network (or part of the network) and automatically generate the configuration files. In most cases no manual editing of the configuration files will be neccessary. If you would like a copy and don't have FTP please send me email and I send a copy via email. Or I'll post somewhere on USENET. What FTP sites should I post this on? If you would like more info about ROSE send email to askrat@kb2ear.ampr.org and/or get on the ROSE mailing list. To get on the mailing list send email to listserv@kb2ear.ampr.org with this line as the body: ADD rose or ADD rose To post to the list send email to rose@kb2ear.ampr.org. 73, -- Scott R. Weis KB2EAR Internet: kb2ear@kb2ear.ampr.org Snail Mail: 10 Palmer Rd., Kendall Park, NJ, 08824-1228 Phone: +1 908 297 0469 ------------------------------ Date: 11 Dec 93 05:55:25 GMT From: news-mail-gateway@ucsd.edu Subject: Scrambler lockup To: ham-digital@ucsd.edu Here in Utah, we have designed and run some test on a T1 radio modem. The modem appears to work very well but there is an area of slight concern: This modem uses a 17 bit maximal-length scrambler (taps on bits 5 and 17). This scrambler uses the same circuit topography as the scrambler in the GRAPES modem and uses 2 XOR gates (74HC86) 2 shift registers (2 74HC164's) and a flip-flop (1/2 of a 74HC74). The problem seems to be that there some unsusal circumstances (cause unknown) in which the scrambler seems to get "stuck". Since this sequence generator is obstensively an open loop system (as opposed to a PN generator used for Spread Spectrum) I don't see how this should be able to occur, but occur it can. Has anyone else had experience with this sort of scrambler and had to deal with this problem? Several things come to mind: On could detect the lack of appropriate transitions and reset the system to get it working once again. One could also have the system software detect a stoppage of the data and cause a reset to be issued. Interestingly enough, the descrambler, which is nearly identical to the scrambler, does NOT seem to exhibit this sort of behavior. We will soon be using these modems in a full-duplex T1 microwave link and will report on their performance. ka7oei@uugate.wa7slg.ampr.org clint@uugate.aim.utah.edu ------------------------------ Date: Wed, 8 Dec 1993 19:53:03 GMT From: mel.dit.csiro.au!its.csiro.au!dmssyd.syd.dms.CSIRO.AU!metro!basser.cs.su.oz.au!harbinger.cc.monash.edu.au!yeshua.marcam.com!zip.eecs.umich.edu!umn.edu!news-feed-2.@@munnari.oz.au Subject: W9GR DSP article of Sept 1992 QST To: ham-digital@ucsd.edu In article <1993Dec7.184551.24853@kpc.com>, nat@kpc.com (Natarajan Gurumoorthy) writes: |> Hi, |> I just stumbled across W9GR's article and am itching to build it. |> I have several questions: |> 2. The article mentions that the TI assembly files for the prom code |> are available on compuserve. Are they also available at some internet ftp site. |> Any pointers would be helpful. |> 3. The article also mentions that the prom programming files are |> also available. Again pointers would be helpful. |> I found these files via anonymous ftp at nic.funet.fi. Get into the machine and cd to directory /pub/ham/dsp/w9gr. The name of the file is w9gr.zip. The file contains the prom programming files as well as the assembly sources for the lms and 3 CW filters. I located the files through the archie server at UNL Nebraska. Enjoy Nat. -- ------------------------------------------------------------------------- Natarajan Gurumoorthy AB6SJ Kubota Pacific Computer, Inc. nat@kpc.com 2630 Walsh Avenue Phone 408 987 3341 Santa Clara, California 95051. ------------------------------ Date: 10 Dec 93 20:55:42 GMT From: ogicse!cs.uoregon.edu!sgiblab!sdd.hp.com!col.hp.com!srgenprp!glenne@network.ucsd.edu Subject: X1J at 38.4 kbps To: ham-digital@ucsd.edu Since posting the basenote, I've had some very helpful and useful exchanges with Dave Roberts, the author of X1J. In addition, the remote site I mentioned has been visited and the TNC running X1J was replaced with another which has a DCD state machine. Also, several days after vanishing from the band, the remote X1J started functioning, poorly but still working, again. In considering the differences between the remote X1J and one in the hamshack (allright, it's really the garage) I came to the idea that maybe what was happening wasn't due to the fundamental inability of X1J to run fast enough. Dave's comments substantiated this. Due to the difference of DCD signals, the remote node had been running full duplex. This required limiting MAXFRAME to one but that was tolerable. I had set the node to FDX in order to ignore the RF derived DCD coming from the radio which in this case can tend to have a lot of edges due to Part 15 and other devices sharing 902-928 MHz. However, the radios are also designed such that RxD is qualified by DCD, even if the TNC ignores DCD, RxD doesn't. With a loosely set squelch and/or lots of fast FH spread spectrum signals there can be a *lot* of edges. With a loose squelch the RxD line is a gated version of what the discriminator sees (which is very noisy with a lot of fast edges in the 500 KHz bandwidth). I now suspect that the radio squelch was set loose and the radio could probably hear itself weakly (noisey) during transmit. The problem I saw was likely the result of a tremendous number of interrupts from the receive side of the TNC SIO (probably mostly receive aborts or errors of some kind). I expect that the receive interrupts have higher priority than transmit interrupts and consequently the transmit side was able to run out of data to send and reported underruns. Since replacing the TNC and disabling FDX the excessive number of underruns disappeared and performance has returned to the same level as that of the local X1J boxes. The X1J code does require considerable overhead so performance isn't stellar, but it *does* seem to run now at 38.4 kbps. Ping RTT is about 300 milliseconds. This is way longer than the raw channel rate alone requires but it *does* still allow higher speed data to go through the node and offers remote diagnostics. Following Dave's advice, I've disabled mheard and nodes broadcasts and will use minqual to effectively disable NET/ROM operation. So, for anyone else wanting faster operation and KISS in a standalone box for lowcost, X1J still seems viable to 38.4 kbps. I still hope to get a version of K3MC KISS code modified to include digipeating since I think this might be able to run my radios much faster, perhaps in the 100-200 kbps territory. If this happens before the fullspeed controllers are working properly I'll probably try to get that code installed in the TNCs. All this is certainly trying to squeeze an underpowered platform, the TNC2, but it is still a lot less expensive than the few alternatives, Gracilis, the German TNC3 and perhaps the Data Engine and presently it is more available than MIO. I think that it points to a general issue though; as we seek higher speeds we will continue to need to handle as much of the "pre-filtering" in hardware as possible. Building radio hardware which has data which is as "qualified" as possible, along with doing FEC in hardware rather than software may be requirements as we push for performance. Picking radio methods (like SS or equalization) combined with fast hardware FEC to provide "host ready" data may be a necessary. The TNC was originally designed as an interface between a "dumb radio" and a dumb terminal. As we've increasingly run higher levels of complexity, TCP/IP and other networking protocols, we've drifted toward "doing the hard part in the increasingly powerful local host. KISS protocol is an example of this. However, as we turn the speed up, I think many functions like "data cleaning" and FEC if not some of the higher ones like switching/routing may have to be done closer to the physical medium again. Glenn Elmore n6gn ax.25 n6gn@wx3k.#nocal.ca.usa.na amateur IP: glenn@SantaRosa.ampr.org Internet: glenne@sr.hp.com ------------------------------ End of Ham-Digital Digest V93 #143 ****************************** ******************************