Date: Thu, 9 Dec 93 04:30:31 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 #141 To: Ham-Digital Ham-Digital Digest Thu, 9 Dec 93 Volume 93 : Issue 141 Today's Topics: ATM on Amateur Radio? Digital with Sound Blaster??? F6FBB release 5.15b ? How much time does a G3RUH modem take to acquire signal? Looking for NOS Executable with NNTP Need advice on using tube-final rigs for RTTY/AFSK TEKK Radios Understanding AX.25 Packet monitored frames W9GR DSP article of Sept 1992 QST 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: Mon, 6 Dec 1993 20:35:10 GMT From: nntp.ucsb.edu!library.ucla.edu!europa.eng.gtefsd.com!howland.reston.ans.net!vixen.cso.uiuc.edu!newsrelay.iastate.edu!news.iastate.edu!metropolis.gis.iastate.edu!willmore@network.ucsd.edu Subject: ATM on Amateur Radio? To: ham-digital@ucsd.edu karn@unix.ka9q.ampr.org (Phil Karn) writes: >OSYSMAS@MVS.OAC.UCLA.EDU (Michael Stein) writes: >|> ATM breaks packets up into cells, the idea being that an time >|> critical (voice or video) packet can't affort to be held back >|> because a long (4k bytes?) packet is being sent. So all packets >|> are broken into cells, which can then be sent as needed (critical >|> ones first). >|> >|> Well, it appears that this solves the problem. Only on a 1Gbit >|> link a 4K byte packets is only 32 microseconds long so the >|> problem doesn't really exist for this speed link! >Absolutely! But you must understand the real driving factor behind the >design of ATM: voice. For all their lip service of "integrated" >voice/data/video services and supporting the Information Age, voice is >still the telcos' bread and butter, and it's the only thing they >consider important. For example, the specific frame size chosen for >ATM (48 bytes of data + 5 bytes of header) was picked to minimize the >packetizing delay for conventional 64kb/s digital voice, so as to >avoid having to use echo cancellers to take care of reflections off of >the hybrids in the analog local loops at the ends of a voice >call. (The degree to which people object to an echo of a given >amplitude is a strong function of its delay -- the longer the delay, >the more annoying it is). To be sure, this choice was more the fault >of the Europeans than the Americans, who wanted a somewhat larger cell >size. ------------------------------ Date: Tue, 7 Dec 1993 15:41:48 GMT From: usc!howland.reston.ans.net!pipex!bnr.co.uk!corpgate!nrtpa038!b4pph13e!cnc23a@network.ucsd.edu Subject: Digital with Sound Blaster??? To: ham-digital@ucsd.edu In your previous article, you wrote: > Can someone please tell me if there is any software that uses a Sound > Blaster to receive CW,RTTY,SSTV,PACKET,etc,etc. > > Thanks, 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 I'm sorry for not e-mailing, but my mail sys is funny. For CW : FFTMORSE by Francois Jalbert (jalbert@IRO.UMontreal.CA) For SSTV: SLOWSC by Gene Harlan WB9MMM For DTMF: _DMTF by Peter Jennings VE3SUN I found these on my SIMTEL CD, a local ham has developed a RTTY program, but has not generally released it. PACKET ???? Hope this is of some help. 73s es CUL N4ZBB -- ====================================================================== Ken M. Edwards, PE Bell Northern Research, Research Triangle Park, NC (919) 481-8476 email: cnc23a@bnr.ca Ham: N4ZBB All opinions are my own and do not necessarily reflect the views of my employer or co-workers, family, friends, congress, or president. (To the e-mail'r out there -> This is a short as it will gets) ------------------------------ Date: 9 Dec 93 11:03:29 GMT From: news-mail-gateway@ucsd.edu Subject: F6FBB release 5.15b ? To: ham-digital@ucsd.edu Can someone please tell me if is available the new release 5.15b of the F6FBB bbs software ? If so, where can be ftp'ed ? Tks, 73, Luiz Catalan internet: catalan@vortex.ufrgs.br packet: pp5aq@pp5aq.bra.sa ------------------------------ Date: 9 Dec 93 06:41:00 GMT From: news-mail-gateway@ucsd.edu Subject: How much time does a G3RUH modem take to acquire signal? To: ham-digital@ucsd.edu When a 9600 baud modem of the G3RUH/K9NG-type hears a signal, how long does it take (or more accurately, how many bit periods) does it take to begin to properly decode data? If it is just a matter of getting a few bit periods to sync the state machine, and then, say, 17 more to get the descrambler working, then 20 milliseconds should be more than enough time to get things working. In practical experience, how long *does* it take for the modem to start decoding data properly (at 9600 baud?) Thanks, ------------------------------ Date: Fri, 3 Dec 1993 15:10:22 GMT From: agate!howland.reston.ans.net!EU.net!sun4nl!hacktic!utopia.hacktic.nl!globv1.hacktic.nl!peter@ames.arpa Subject: Looking for NOS Executable with NNTP To: ham-digital@ucsd.edu ron@alpha.nsula.edu (Ron Wright) writes: >I am looking for a compiled version of NOS that has the NNTP server compiled >in. I do not currently have a compiler so I can't put together my own. Along >these lines... WNOS has nntp support built in. It's on ucsd.edu:/hamradio/packet/tcpip/wnos. >Does anyone know of the GNU c++ compiler will successfuly >compile NOS. You mean DJGPP, the GCC compiler for MS-DOS? If so, then the answer is no. Groetjes, Peter Busser -- Linux, the choice of a GNU generation. ------------------------------ Date: 7 Dec 1993 13:07:29 +0200 From: ucsnews!sol.ctr.columbia.edu!howland.reston.ans.net!EU.net!news.funet.fi!klaava!klaava!not-for-mail@network.ucsd.edu Subject: Need advice on using tube-final rigs for RTTY/AFSK To: ham-digital@ucsd.edu I'll be shopping for a used rig soon and will be on a very tight budget, so I'm trying to get a picture of what the minimal rig would be that will do what I want. Other than SSB/CW, I've been itching to get into RTTY, but have heard that many older rigs have problems both from the 100% duty cycle and sluggish operation. I'm intrested in hearing people's experiences working the various digital modes on HF using older tube rigs, or rigs with tube finals. More than likely, I'll be using a late-model multimode TNC and AFSK for HF RTTY/Baudot/AMTOR. What sort of things should I look for in a suitable rig. Obviously, the quality of the SSB signal is more important when using AFSK rather than FSK (right?). How can one estimate the max. drive the finals can take at 100% duty cycle? How can one determine if the tx is "fast" enough (or is sluggishness only a problem with FSK and not AFSK?). Of course, I'd particularly appreciate any recommendations for (or against) particular rigs, which would help me in my shopping. Thanks, ///////////////////////////////////////////////////////////////////////// Patrick M. Stickler OH2LUV, KC4YYY The comments contained herein WSOY - Information Systems Division do not necessarily reflect the Helsinki, FINLAND (psti@wsoy.fi) official views of my employer. ///////////////////////////////////////////////////////////////////////// ------------------------------ Date: Tue, 7 Dec 1993 02:45:12 GMT From: netcomsv!netcom.com!fmitch@decwrl.dec.com Subject: TEKK Radios To: ham-digital@ucsd.edu tekk has a special on the little data radios until the end of the year... call them for details... 800-521-8355... 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: 8 Dec 93 16:25:28 GMT From: news-mail-gateway@ucsd.edu Subject: Understanding AX.25 Packet monitored frames To: ham-digital@ucsd.edu UNDERSTANDING MONITORED PACKET FRAMES Don Rotolo N2IRZ Have you ever monitored the packet channel and wondered just what all those letters and numbers at the beginning of each packet "frame" mean ? Well, wonder no more ! This article will explain the basics of packet control. All packet HDLC (High-level Data Link Control) frames are similar, consisting of 6 unique "fields": | Flag | Address | Control | PID & Data | FCS | Flag | FLAG : The Flag fields are put at the beginning and end of each frame to indicate the boundaries of the frame. A unique bit sequence is used (01111110) so other parts of the frame won't be mistaken for a Flag. ADDRESS: This field normally specifies the destination of the frame. This is the actual call signs of the source, destination, and any digipeaters. CONTROL: This field identifies the frame type. See FRAME TYPES below. PID: The first byte of the Data field is the Protocol ID, specifying the type of protocol in use. DATA: This is the actual data to be transferred. Many frames do not have a data field. FCS: Frame Check Sequence, this is how errors are detected in a frame. Your TNC creates a number based on the rest of the fields, using a special mathematical formula. The other TNC does the same, and if the numbers match, the frame has no errors and is accepted. We will examine a typical frame: KD6TH-4>N2DSY-2*>N2IRZ [I;3,1]:0042z, 838 msgs, #40407 last @KD6TH-4 Mailbox> <----Address---------> <-----> <----------Data------------------------------> Control Note that you do not see the Flag, PID and FCS fields. FRAME TYPES: C Connect frame. Also known as a 'SABM' frame (Set Asynchronous Balanced Mode). D Disconnect frame. DM Disconnect Mode frame. I Information frame. UA Unnumbered Acknowledgement frame. UI Unnumbered Information frame. RR Receive Ready command and response. RJ ReJect frame. RNR Receive Not Ready command and response. FRMR FRaMe Reject response. DM Disconnected Mode response. When you type into your TNC a connect command, the TNC generates a frame like: N2IRZ*>KD6TH-4 [C,P] This means that N2IRZ is trying to connect to KD6TH-4. The * shows who is transmitting. The > shows the direction the frame is going (to KD6TH-4). The "C" indicates that it is a Connect frame, and the "P" means that the "Poll" bit is set. When the Poll bit is set, it means the originating station is Polling (or "searching") for the destination station (sort of asking "are you there ??"). If the destination station was to respond, it would send an "F", or Final, bit in response ("yep, I'm here"). If the radio path is "perfect", the Poll/Final bits will rarely be used again. KD6TH-4 is able to establish a connection to N2IRZ, so it sends: KD6TH-4*>N2IRZ [UA,F] This means that KD6TH-4 has acknowledged receiving N2IRZ's Connect request, and confirms the connection. Your TNC generates the familiar "*** Connected to ..." message for you. KD6TH-4 now sends a greeting (his "Connect Text"): KD6TH-4*>N2IRZ [I,P;0,0]:Hi Don, Welcome to KD6TH-4 BBS ! The "I" tells us that this is an information frame. The information (Hi Don...) can be any text. P is for Polling - KD6TH-4 is just making sure N2IRZ is still there. What is interesting here are the numbers in the "[I,P;0,0]:" part: The first number is the next frame number that KD6TH-4 expects from N2IRZ, and the second number is the number of the frame that is being sent. The order of the numbers switches when N2IRZ is sending. Upon receiving this frame without errors, N2IRZ sends: N2IRZ*>KD6TH-4 [RR,F;1] Telling KD6TH-4 that N2IRZ got frame 0 OK and is ready to receive frame 1. KD6TH-4 sends 2 more info frames to N2IRZ: KD6TH-4*>N2IRZ [I;0,1]:*** You have Unread Mail !!! KD6TH-4*>N2IRZ [I;0,2]:0045z, 745 msgs, #40498 last @KD6TH-4 Mailbox> N2IRZ didn't get the First packet without errors, but did get the Second, so it sends: N2IRZ*>KD6TH-4 [RJ;1] Which tells KD6TH-4 that it is rejecting the received packet: N2IRZ still wants packet number 1. If both packets were received OK, N2IRZ would simply send [RR;3] and the process would continue, but if N2IRZ hadn't received EITHER packet, no response would have been sent. Then KD6TH-4 would have started polling: KD6TH-4*>N2IRZ [RR,P;0] N2IRZ would reply N2IRZ*>KD6TH-4 [RR,F;1] Eventually, N2IRZ is finished reading the mail, so he signs off: N2IRZ*>KD6TH-4 [I;5,2]:Bye This is N2IRZ's frame 2, and he expects frame 5 back. KD6TH-4 responds KD6TH-4*>N2IRZ [RR;3] KD6TH-4*>N2IRZ [D,P] First the "Bye" packet is acknowledged, and then KD6TH-4 initiates a disconnect. N2IRZ responds N2IRZ*>KD6TH-4 [UA,F] and they are disconnected. KD6TH-4 now sends out its "MAIL_FOR:" beacon: KD6TH-4*>BBS [UI]: Mail_for: N2DSY WA2SQQ KA2USU W5GZT KB2BAV WA2SPO This last frame is an Unnumbered Information frame. The place it is addressed to (in this case, "BBS") is specified by the UNproto command, which usually has the default of "CQ". Now you have a good idea of what C, UA, I, RR, RJ, D and UI frames are like. A DM frame is sent when the other station is busy, or CONOk is Off, and your TNC generates a message that "KD6TH-4 is Busy", while KD6TH-4's TNC generates a "*** Connect Request: N2IRZ" message. The other frame types are somewhat rare: RNR is sent when one station polls another ("are you there ?") but the other station isn't ready to process another packet yet. FRMR is only sent when all hell breaks loose: the Frame Type (I, UA, RR, etc) is either undefined or improper protocol (Wrong type of reply). If you would like to learn more about the AX.25 Protocol, or Packet Radio in general, I suggest the following: Terry Fox, "AX.25 Amateur Packet Radio, Link-Layer Protocol Version 2.0", (Available from the ARRL), October 1984. Jim Grubbs, "Get ***CONNECTED to Packet Radio", QSKY Publishing, Springfield, Illinois. 1986. (Easy to read, great bibliography) Max Adams, "Basic Amateur Radio Packet", CQ Magazine, November 1985, pp.13-20. This article is part of an informal series of technical articles intended to promote experimentation, good operating habits, safety and technical knowledge. This article may be copied freely, with proper acknowledgement. Feedback is welcomed. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 73 de Don Rotolo * Knowledge is the only instrument * * N2IRZ@kd6th.nj.usa * of production that is not subject * * CIS : 73227,2644 * to diminishing returns -J.M. Clark * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ------------------------------ Date: Tue, 7 Dec 1993 18:45:51 GMT From: news.kpc.com!kpc!nat@decwrl.dec.com Subject: W9GR DSP article of Sept 1992 QST To: ham-digital@ucsd.edu Hi, I just stumbled across W9GR's article and am itching to build it. I have several questions: 1. is the PC board available. I can get hold of the parts locally. 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. Thanks in advance. Nat. -- ------------------------------------------------------------------------- Natarajan Gurumoorthy AB6SJ Kubota Pacific Computer, Inc. nat@kpc.com 2630 Walsh Avenue Phone 408 987 3341 Santa Clara, California 95051. ------------------------------ Date: (null) From: (null) >Nevertheless, complaints from computer networking people that tiny, >fixed-sized cells were not what they needed didn't seem to faze the >telcos. ATM just requires a protocol encapsulation/translation. Nothing much worse than fragments in TCP/IP. >|> Also my understanding is that currently all you can get today on >|> ATM is a permanent virtual circuit, no "dial up". It appears >|> that switched service is years away. And it's not clear how >|> (if?) ATM will handle multicast traffic. >A very common misconception about ATM, perhaps encouraged by the >telcos themselves to sound more trendy, is that ATM is packet >switching. It really isn't. First of all, ATM cells look nothing >like, say, the Ethernet frames with which computer networking people >are familiar: full source and destination addresses, followed by a >variable length data field with a reasonably large size limit. And >there's too little buffering in an ATM switch to make it a true packet >network, where lots of little bursty users all contend for each link >through a queue. The first time a packet follows a path through any modern routing system, the router will have to take extra time to compute the destination. Once it has cached that address resolution, latter packets take less time to route. Why should ATM be any different? Sure, it makes a packet switched network look more like a virtual circuit network, but that's just reality. Most packets go where one has already gone, anyway. >So to achieve a reasonably low lost-cell rate in ATM, you have to set >up a circuit in advance and preallocate some fraction of link >bandwidth. If it isn't used, it goes to waste. Think of ATM as just >another TDM (time division multiplex) switch, albeit with somewhat >finer-grained control over the bandwidth allocations that can be >made. Other than that, ATM doesn't do much that can't already be done >by a much simpler cross-connect switch at far lower cost. ATM would mostly be used to connect together LAN's into larger collections. With that in consideration, why wouldn't the traffic be fairly steady between nodes? It's not like ATM was supposed to run to peoples houses directly. >|> Remember, ATM is brought to you by the same people who designed >|> ISDN as the answer to local telephone service. Will it follow >|> the same installation / availability / cost path? >Most likely, or even worse. ISDN's and ATM's "features" are worse than >useless to anyone trying to build a real packet switched network like >the Internet. Oh sure, you *can* use them, and people do when the >tariffs are right. But all that added complexity buys you nothing over >a bunch of leased lines. Hence they're worse than useless. >In the case of ISDN, I don't know anyone who uses it as anything but a >leased line substitute between local packet routers. And this happens >only when the telcos price ISDN far enough below their traditionally >overpriced leased line services to make it worth dealing with ISDN's >many added hassles. Of course, if the telcos were to price all their >services according to their true costs, ISDN would immediately >disappear and they'd have to admit their mistake. ISDN didn't work out because it took so long to get some switches upgraded. This brought broadband ISDN closes and caused some of the market demand to decide to wait for B-ISDN. *sigh* Things like that happen. Remember Floptical Drives? They took too long to get to get to market that other technology like 128Meg MO drives and 140Meg MD drives beat them out. >Raw digital transmission, at least along major fiber routes, is the >one thing the telcos know how to do well. Unfortunately, getting just >that service out of them at a reasonable price is very difficult. Raw >transmission isn't "glamorous" enough for the telcos, so they keep >trying to "do it all" (e.g., move into information >services). Unfortunately, they don't even know how to properly >*switch* data, much less provide the complete stack including the >applications. With this, I can agree. All I want is a T1 line... *sigh* >|> What does this have to do with Amateur Radio? Well, I've been >|> thinking about all the claims that there isn't enough spectrum to >|> do Gigabit networking via RF. Really? What about local and line >|> of sight links in the 24Ghz to 100Ghz range? Sounds hard (a >|> challange) today, but doesn't sounds like it will remain so... >Well, IF we were to use ATM, then those claims about insufficient >spectrum would be true. If we don't, there shouldn't be a problem. :-) Good dig, but I'm not convinced that ATM is the best for radio use. Let me rephrase that. ATM is very poor for radio use. One of the prime assumptions of ATM was that the physical carrier had a very low bit error rate. Radio doesn't exactly meet that specification. Cheers, David (N0YMV) -- ___________________________________________________________________________ willmore@iastate.edu | "Death before dishonor" | "Better dead than greek" | David Willmore | "Ever noticed how much they look like orchids? Lovely!" | --------------------------------------------------------------------------- ------------------------------ End of Ham-Digital Digest V93 #141 ****************************** ******************************