Re: [digitalradio] -tor modes and PCs
Because of the timing issues with Amtor/Pactor/Gtor, etc., it seems clear that we should be developing modes that do work with the kind of computers that most all hams have available to them. Because of the mediocre performance, I would consider Pactor I and certainly Amtor to be obsolete for all practical purposes. Clearly, the pipelined approach is the very best way to incorporate ARQ into most existing sound card digital modes without a big penalty for speed. Once someone came up with the basic routines, wouldn't it be fairly easy to insert various modes into the ARQ framework? 73, Rick, KV9U Chris Jewell wrote: jhaynesatalumni writes: I'm willing to believe that the timing tolerances in -tor modes are so tight that ordinary PC operating systems cannot cope with them the way a dedicated processor can. What I don't understand is why the tolerances need to be so tight. The transmitter sends a packet and then listens for an ACK or NAK. Why can't it wait arbitrarily long? The ACK time could be made as long as you like, but the throughput would suffer accordingly. For example, with Pactor I, (according to p. 9-24 of the 2005 ARRL Handbook), the sender sends the packet in 0.96 seconds, then propagation delays and receipt of the ACK takes 0.29 seconds, for a total of 1.25 seconds per packet. If we increase the ACK delay to be the same as the transmit time, the total time per packet would be 1.92 seconds for the same amount of data as Pactor I sends in 1.25 second, and the throughput would be 1.25/1.96 or approximately 0.65 times what the present protocol delivers. Is it doable? Yes. Would most hams want it? I have my doubts. To get the same throughput with a longer ACK time, you have to make the transmit time longer too, so it bears the same relationship to the total time as it does now. That means either a much longer data packet, or a pipelined group of packets covered by a single ACK. The longer the packet, the greater chance that a static crash or other event will corrupt the packet, so we're back to talking about pipelined packets. Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org Other areas of interest: The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/ DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy discussion) Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [digitalradio] -tor modes and PCs
At 08:14 AM 8/29/2006,Rick,KV9U wrote in part: I would consider Pactor I and certainly Amtor to be obsolete for all practical purposes. Far from it Rick. I have been on Amtor from just about day one and still us the mode a lot even today. Same holds true for Pactor-1. I will agree that it's not like it once was but it's still alive and well. I try to keep my Amtor station on 7,075 24/7 for the most part. I do have more QSO's with these 2 mode then I do with Pactor-2 or 3. Or so it seems. John Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org Other areas of interest: The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/ DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy discussion) Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
RE: [digitalradio] -tor modes and PCs
When amateur radio operators who are used to keyboard-to-keyboard QSOs and then go to a data transfer or messaging system, they do tend to become impatient with ACK times. I do believe that if we understand that we can send several/many seconds of data that have a moderate level FEC, we can wait for an ACK or NARK...especially if this is a broadcast type transmission. For a 5-15 second data transmission, I don't think that 5-7 seconds of wait time will kill us. If propagation is good, we might consider 20-30 seconds of data transmission and 5-10 seconds of delay. If propagation is poor, then 5-10 second transmissions might still warrant a 5-10 second delay. The consideration should be the average throughput over a long period...say 5-10 minutes which should equal a rather large volume of data. It is good to keep all these considerations in mind; however, I don't think they should be a reason to not consider any certain modulation scheme or data mode. There will inevitably be a necessity to obtain a balance between RAW data/modulation rate, delay, level of use of FEC and ARQ. The solution is to build a mode or even modes that, over the long term, can have a substantially greater throughput than current systems using the same or equal hardware. One other consideration is that there are differences between what can be done with a computer and external hardware. The desire for open software to run on a computer seems to be the push for sound card modems while the use of external hardware, such as the Pactor Modems, does not have the appeal to those who are running modes using a computer alone. I would recommend that external hardware be given consideration; however, not proprietary hardware or systems but rather COTS hardware that will run open source applications such as the EVM boards that were popular a few years ago. They were (perhaps still are) quite reasonably priced and might well produce modes superior to any current hardware generated mode. Also, one would want to consider external COTS soundcards for mode generation...perhaps even a combination of something like an EVM card and external soundcards. Perhaps even entire computers such as are available for under $200. 73, Walt/K5YFW -Original Message- From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] Sent: Monday, August 28, 2006 3:08 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] -tor modes and PCs jhaynesatalumni writes: I'm willing to believe that the timing tolerances in -tor modes are so tight that ordinary PC operating systems cannot cope with them the way a dedicated processor can. What I don't understand is why the tolerances need to be so tight. The transmitter sends a packet and then listens for an ACK or NAK. Why can't it wait arbitrarily long? The ACK time could be made as long as you like, but the throughput would suffer accordingly. For example, with Pactor I, (according to p. 9-24 of the 2005 ARRL Handbook), the sender sends the packet in 0.96 seconds, then propagation delays and receipt of the ACK takes 0.29 seconds, for a total of 1.25 seconds per packet. If we increase the ACK delay to be the same as the transmit time, the total time per packet would be 1.92 seconds for the same amount of data as Pactor I sends in 1.25 second, and the throughput would be 1.25/1.96 or approximately 0.65 times what the present protocol delivers. Is it doable? Yes. Would most hams want it? I have my doubts. To get the same throughput with a longer ACK time, you have to make the transmit time longer too, so it bears the same relationship to the total time as it does now. That means either a much longer data packet, or a pipelined group of packets covered by a single ACK. The longer the packet, the greater chance that a static crash or other event will corrupt the packet, so we're back to talking about pipelined packets. -- 73 DE AE6VW Chris JewellGualala CA USA Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org Other areas of interest: The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/ DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy discussion) Yahoo! Groups Links Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org Other areas of interest: The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/ DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy discussion) Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [digitalradio] -tor modes and PCs
At 11:41 AM 8/28/2006, you wrote: I'm willing to believe that the timing tolerances in -tor modes are so tight that ordinary PC operating systems cannot cope with them the way a dedicated processor can. What I don't understand is why the tolerances need to be so tight. The transmitter sends a packet and then listens for an ACK or NAK. Why can't it wait arbitrarily long? There are protocols for wire transmission e.g. IBMs Bi-Sync which worked in the days of modems that could only transmit in one direction at a time. These used old slow computers to run the protocol. That is pretty much the way it is with the ALE DTM ARQ, DBM ARQ protocols and most of the ARQ protocols on the high speed MIL-STD-188-110x PSK serial tone modem. The FSK one's will run on just about any CPU and PC Sound Device when an 8Khz sample clock is used. The '188-110 modem is a CPU/Memory hog and requires a 9.6Khz sample clock, to have both the FSK/PSK modems active at the same time on the same PC Sound Device you need a common ground so 48Khz is used as its dividable by both 8k and 9.6k. We have a version of MARS-ALE called Legacy Edition that only has the FSK modem at 8Khz and then both modem at 48Khz, thus the MARS-ALE LE version runs on a 386 and Windows 98SE and that DBM ARQ is a real performer at a raw 125 baud and deep interleaving. /s/ Steve, N2CKH Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org Other areas of interest: The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/ DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy discussion) Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [digitalradio] -tor modes and PCs
Hi Chris, Take a look at DBM ARQ in http://www.n2ckh.com/MARS_ALE_FORUM/MIL-STD-188-141B.pdf starting on page 178, it really lends itself to the PCSDM and its works fantastic, I love GTOR, more so than PACTOR I since the day I bought my first KAM Plus (I like my KAM XL a bit better though) and DBM ARQ ( GTOR is a kissing cousin) is every bit as good and in some ways better. Here's a comparison of the TOR's and DMB ARQ timing: ProtocolCycle LengthData Length Ack Length NOTE: All in seconds: AMTOR 0.450.210.07 PACTOR 1.250.960.12 GTOR2.401.920.16 DBM ARQ variablevariable1.57 If for no other reason, anyone interested in a robust FSK ARQ protocol (there DBM BRD which is just FEC that is great as well) should give it a try in any version of PC-ALE, no Scanning, no Sounding required, just you and a buddy establish a link and then send your message with DBM, pretty much like establishing a link with GTOR or PACTOR but no constant channel diddling while linked, its so much less annoying to others tuning by or having a QSO in the distance, the only transmitting is the Linking and then the sending of the data and the handshaking and the throughput is just as fast. As my Mother used to say and was often right, Try it, you'll like it! /s/ Steve, N2CKH At 07:23 PM 8/28/2006, you wrote: The ACK time could be made as long as you like, but the throughput would suffer accordingly. For example, with Pactor I, (according to p. 9-24 of the 2005 ARRL Handbook), the sender sends the packet in 0.96 seconds, then propagation delays and receipt of the ACK takes 0.29 seconds, for a total of 1.25 seconds per packet. If we increase the ACK delay to be the same as the transmit time, the total time per packet would be 1.92 seconds for the same amount of data as Pactor I sends in 1.25 second, and the throughput would be 1.25/1.96 or approximately 0.65 times what the present protocol delivers. Is it doable? Yes. Would most hams want it? I have my doubts. To get the same throughput with a longer ACK time, you have to make the transmit time longer too, so it bears the same relationship to the total time as it does now. That means either a much longer data packet, or a pipelined group of packets covered by a single ACK. The longer the packet, the greater chance that a static crash or other event will corrupt the packet, so we're back to talking about pipelined packets. -- 73 DE AE6VW Chris JewellGualala CA USA Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org Other areas of interest: The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/ DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy discussion) Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
