[digitalradio] Re: New to Digital HF -- PACTOR setup and hardware maybe needed???
The issue is control over the operating system's scheduling decisions. There are real-time versions of Linux that are comparable in this dimension to the firmware running in a TNC; given sufficient CPU horsepower, a Pactor-2 or Pactor-3 implementation on realtime Linux is feasible. The Windows scheduler cannot be adequately controlled for use timing- critical applications; as a result, the response time requirements of protocols like Pactor-2 and Pactor-3 cannot be guaranteed, no matter how fast the CPU. Generating CW with consistent timing is a challenge on this platform. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, John Becker [EMAIL PROTECTED] wrote: It was on a linux system But that does not matter. The problem is EVERY time the computer thinks what do I need to do now - the timing is lost and so is the link. At 09:53 AM 8/27/2006, you wrote: Have you tried it with an up-scale sound card on a computer equipped with both a fast processor and a lot of RAM? What was the interface between PC and rig? USB 1.0, 1.1, 2.0, Serial, Parallel, other? I am wondering if the rapidly improving PC hardware may have solved the speed problem? Also, which OS did you test, please? Apple, the MS version of windows (XP?), Linux? I am not questioning your observations just am curious as to the testing context. -- Thanks! 73, doc, KD4E ... somewhere in FL URL: bibleseven (dot) com 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/
[digitalradio] Re: ALE QRM is minimal
The documentation in http://hflink.com/ recommends that a station transmit a 20-30 second sounding hourly on each frequency. Below, Bonnie says In amateur radio ALE, there is only one pilot channel per ham band where repetitive sounding (station ID) happens on a regular basis. How many stations can be sounding a band's pilot channel before it saturates? Lets assume the best case, which is that each stations sounds for 20 seconds each hour. If the channel is perfectly utilized, it can handle (60*60)/20 = 180 independent stations 180 non-synchronized stations attempting to sound one frequency for 20 seconds each hour would produce nearly continuous collisions. I have yet to find any reference to collision detection and/or collision avoidance on an ALE pilot channel. Does ALE provide some means of reducing contention? Without contention reduction, the practical number of simultaneous ALE stations sounding the same frequency at the recommended rates would be in the 30 to 60 range. How could 1000 amateur ALE operators to be simultaneously QRV with one pilot channel per amateur band? 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, expeditionradio [EMAIL PROTECTED] wrote: John VE5MU wrote: If we have 1000 Ale stations sounding 24/7, how much QRM will this create? Hi John, It would be far less QRM than the average RTTY contest, such as we had this weekend that took over a large chunk of the ham bands with soundings. In fact, it is unlikely that you would notice 1000 ALE operators on the air, unless you tune your VFO to the specific frequency the ALE operators are using. In amateur radio ALE, there is only one pilot channel per ham band where repetitive sounding (station ID) happens on a regular basis. The nature of the way ALE works enables many stations to dynamically use the same channel on a time/space shared basis for various purposes, such as messaging, calling, sounding, and geo-position reporting. The global or regional capacity of a single channel for ALE is rather large. One channel is probabably enough to handle a 1000% increase in amateur radio ALE use over the next 5 years, if and when it becomes that popular. It would be wonderful if we had 1000 ALE stations on the air 24/7. Perhaps the ALE On-The-AIR Week event in October will give us some idea of what is possible with a few hundred stations on at the same time. We don't really know yet, since this will be the first such event. Bonnie KQ6XA 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/
[digitalradio] Re: New to Digital HF -- PACTOR setup and hardware maybe needed???
There are variants of Linux with pre-emptive scheduling; this enables guaranteed real-time response. Linux-based cellphones use this approach, for example. See http://en.wikipedia.org/wiki/Hard_real-time Dave, AA6YQ --- In digitalradio@yahoogroups.com, Chris Jewell ae6vw- [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: On Sun, 27 Aug 2006 22:02:33 -0500, John Becker [EMAIL PROTECTED] wrote: It was on a linux system But that does not matter. The problem is EVERY time the computer thinks what do I need to do now - the timing is lost and so is the link. ??? now, I am not a geek for computers, but my Perl mobo has a pair of 3.1ghz cpus running with huge cache, and 2gb of ram. the soundcard is running along with a pretty wide gateway and its own gb or so of ram. i just don't think that the wait states, if there are any, are going to be sufficient to bog down a real, damned slow modem since most of those are probably running at 1200 to 2400bps. which is real slow. I have a dsl which supposedly is running at 3.2kbips but it is uploading slower than my pc is pushing it up the line. I am definitely confused which is NOT unusual in the least. Suppose you're using your sound card as a modem to receive Pactor I data. Your sound card takes care of turning tones from the receiver into 1s and 0s. There's no problem there. However, when a packet is finished arriving (and getting turned from frequency shifts into bytes of data), the application program running on the PC must verify the check, turn the radio around to transmit, and send either a positive or negative acknowledgement, then turn it back to receive mode so it can hear the next packet. The problem is that the OS may have dispatched some other process at the time, and the process that does the checking and sending of the ACK or NAK may not get a time slice from the OS soon enough to meet the timing requirements of the Pactor acknowledgement. If you were using a TNC, the processor in the TNC would be old and slow by current standards, but it would have nothing else to do EXCEPT check the checksum and send the ack or nak, while the much faster CPU in your Linux (or even worse, Windows) PC may be busy doing something else at the crucial time, since it is running a multitasking, and even potentially multi-user, OS. In principle, it seems that it should be possible to manage that problem in the Linux environment by: 1. adjusting the dispatching code in the OS so that it gives very short timeslices to processes, so the Pactor process can get CPU time sooner; and 2. running the Pactor process with a high dispatching priority (which the superuser can accomplish with a negative priority value on the renice command.) Shortening the time slice means that more of your CPU power is used up on trips through the dispatcher portion of the OS, rather than in running whatever user-mode application programs are ready to run, but with a fast computer that doesn't have a lot to do, that should be okay. In FreeBSD, you would issue a command like this as root: # sysctl kern.sched.quantum=1 The quantum is measured in microseconds. The default value is 100,000, or 100 milliseconds. By changing it to 10,000, or 10 milliseconds, you make it possible for the highest-priority task to get use of the CPU within 10 milliseconds, rather than 100. I'm not really a Linux guy, so I don't know whether there is a comparable sysctl variable in Linux, or whether you can build a custom kernel that uses a shorter scheduling quantum, or what. -- 73 DE AE6VW, Chris Jewell [EMAIL PROTECTED] Gualala 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/
Re: [digitalradio] Re: New to Digital HF -- PACTOR setup and hardware maybe needed???
GM Dave, Yes, a technical item up for discussion. I must assume that you have never done any Near Real Time Systems development such as ATE or Industrial Control applications under MS-Windows? I on the other hand have and the WIN32 API beginning all the way back with Windows NT implemented a number of functions for embedded applications with critical timing requirements. For example you have the GetTickCount() API call which has a resolution of 10ms and the QueryPerformanceCounter() which returns the resolution of a high-resolution performance counter to 0.8 microseconds and then there are Spinlocks to synchronize timing events during an interrupt response or other similar activity, together with Process Priority and Asynchronous I/O and some other functions you can achieve nanosecond accuracy and make your application own the operating system to prevent other system processes from interfering with your critical timing needs. It is my opinion that ARQ protocols such as AMTOR and others with their short ACK/NAK can implemented under MS-Windows 2000 Professional and above taking the above approach. /s/ Steve, N2CKH/AAR2EY At 10:23 PM 8/27/2006, you wrote: The issue is control over the operating system's scheduling decisions. There are real-time versions of Linux that are comparable in this dimension to the firmware running in a TNC; given sufficient CPU horsepower, a Pactor-2 or Pactor-3 implementation on realtime Linux is feasible. The Windows scheduler cannot be adequately controlled for use timing- critical applications; as a result, the response time requirements of protocols like Pactor-2 and Pactor-3 cannot be guaranteed, no matter how fast the CPU. Generating CW with consistent timing is a challenge on this platform. 73, Dave, AA6YQ 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] Re: ALE QRM is minimal
Hi Dave, At 10:53 PM 8/27/2006, you wrote: Does ALE provide some means of reducing contention? I recommend that to answer all of your technical questions on subject ALE that you refer the actual Federal, Military and STANAG Standards which you can find on the Internet quite easily. You can start with a number of them at the following URL: http://www.n2ckh.com/MARS_ALE_FORUM/tecref.html Listed below are the ALE Operational Rules taken directly from MIL-STD-188-141B APPENDIX A, take the time to read this and do additional research WRT the details of the referenced items herein and you should be satisfied that ALE is the most courteous digital mode with automatic operation you could ever want to see, compared to any other system that has ever been used on the Amateur Radio bands. /s/ Steve, N2CKH/AAR2EY A.4.4 ALE operational rules. The ALE system shall incorporate the basic operational rules listed in table A-V. Some of these rules may not be applicable in certain applications. For example, always listening is not possible while transmitting with a transceiver or when using a common antenna with a separate transmitter and receiver. TABLE A-V. ALE operational rules. 1) Independent ALE receive capability (in parallel with other modems and simular audio receivers) (critical). 2) Always listening (for ALE signals) (critical). 3) Always will respond (unless deliberately inhibited). 4) Always scanning (if not otherwise in use). 5) Will not interfere with active channel carrying detectable traffic in accordance with table A-I (unless this listen call function is overriden by the operator or other controller). 6) Always will exchange LQA with other stations when requested (unless inhibited), and always measures the signal quality of others. 7) Will respond in the appropriate time slot to calls requiring slotted responses. 8) Always seek (unless inhibited) and maintain track of their connectivities with others. 9) Linking ALE stations employ highest mutual level of capability. 10) Minimize transmit and receive time on channel. 11) Automatically minimize power used (if capable). NOTE : Listed in order of precedence. TABLE A-I. Occupancy detection probability (2G and 3G). WaveformSNR (dB in 3 kHz) Dwell Time (s) Detection Prob ALE 0 2.0 0.80 6 2.0 0.99 SSB Voice 6 2.0 0.80 9 2.0 0.99 MIL-STD-188-110 0 2.0 0.80 (Serial Tone PSK) 6 2.0 0.99 STANAG 45290 2.0 0.80 6 2.0 0.99 STANAG 4285 0 2.0 0.80 6 2.0 0.99 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] Re: ALE QRM is minimal
Several key points on Bonnie's comments: 1) RTTY contests are human operating events. There is no automatic RTTY that I am aware of. Big difference! It is one thing to find an apparent hole to TX into, but are able to back off if it is busy. ALE would be nearly inoperative during a contest if it is truly monitoring the frequencies. Frequently, you will have wall to wall TX that take up the band. If you ever think that you can make an argument to preempt human operation with machine, you will lose with the great majority of hams. 2) Having many ALE soundings on one frequency is beginning to sound like packet collision issues where nothing gets through. This can work for military, commercial, MARS, use perhaps where you have a fairly small number of stations that would send at any one time. But if you had even two stations sending on top of each other, wouldn't they trash the ALE packet? Then imagine having a lot more than 2! And if you only sound once an hour, you won't even know that it did not work. Is this really practical for amateur radio use in a band that has long distance capabilities (sometimes world wide)? 73, Rick, KV9U expeditionradio wrote: It would be far less QRM than the average RTTY contest, such as we had this weekend that took over a large chunk of the ham bands with soundings. In fact, it is unlikely that you would notice 1000 ALE operators on the air, unless you tune your VFO to the specific frequency the ALE operators are using. In amateur radio ALE, there is only one pilot channel per ham band where repetitive sounding (station ID) happens on a regular basis. The nature of the way ALE works enables many stations to dynamically use the same channel on a time/space shared basis for various purposes, such as messaging, calling, sounding, and geo-position reporting. The global or regional capacity of a single channel for ALE is rather large. One channel is probabably enough to handle a 1000% increase in amateur radio ALE use over the next 5 years, if and when it becomes that popular. It would be wonderful if we had 1000 ALE stations on the air 24/7. Perhaps the ALE On-The-AIR Week event in October will give us some idea of what is possible with a few hundred stations on at the same time. We don't really know yet, since this will be the first such event. Bonnie KQ6XA 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/
[digitalradio] Timing requirements of digital ARQ
Since I am not a programmer, other than taking some rudimentary courses, reading some of Don Lancaster's books, and knowing that it is not something I could ever do very well, something still doesn't seem right to me when it comes to the claim that computers just can not meet the timing requirements of ARQ digital modes. When I use the computer to key my ICOM 756 Pro 2 with Dave's DX Lab Commander software in order to run other programs that interface with Commander (such as Multipsk which is my main digital sound card program), it does not seem to have much latency at all. And if one could key relatively slow CW as is done with the software for the SDR1000, why would that not be almost a magnitude faster than you would need for adequate ARQ switching speed? How many ms do you need? Rick, KN6KB, the inventor of SCAMP, has said that the power in the typical Windows OS computer we use is something like a magnitude less than that available in the dedicated SCS modems and that is why they perform so well compared to a computer (for the dedicated part). I wonder where the dividing line will come so that computers will at least match the SCS type units? 73, Rick, KV9U Dave Bernstein wrote: The issue is control over the operating system's scheduling decisions. There are real-time versions of Linux that are comparable in this dimension to the firmware running in a TNC; given sufficient CPU horsepower, a Pactor-2 or Pactor-3 implementation on realtime Linux is feasible. The Windows scheduler cannot be adequately controlled for use timing- critical applications; as a result, the response time requirements of protocols like Pactor-2 and Pactor-3 cannot be guaranteed, no matter how fast the CPU. Generating CW with consistent timing is a challenge on this platform. 73, Dave, AA6YQ 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] New to Digital HF -- PACTOR setup and hardware maybe needed???
Chris, What is your view on using pipelined programming such as what was used in the SCAMP mode to get around this issue with moving the ACK to the next packet. The main penalty is latency for the user, but it seems manageable. 73, Rick, KV9U Chris Jewell wrote: Suppose you're using your sound card as a modem to receive Pactor I data. Your sound card takes care of turning tones from the receiver into 1s and 0s. There's no problem there. However, when a packet is finished arriving (and getting turned from frequency shifts into bytes of data), the application program running on the PC must verify the check, turn the radio around to transmit, and send either a positive or negative acknowledgement, then turn it back to receive mode so it can hear the next packet. The problem is that the OS may have dispatched some other process at the time, and the process that does the checking and sending of the ACK or NAK may not get a time slice from the OS soon enough to meet the timing requirements of the Pactor acknowledgement. If you were using a TNC, the processor in the TNC would be old and slow by current standards, but it would have nothing else to do EXCEPT check the checksum and send the ack or nak, while the much faster CPU in your Linux (or even worse, Windows) PC may be busy doing something else at the crucial time, since it is running a multitasking, and even potentially multi-user, OS. In principle, it seems that it should be possible to manage that problem in the Linux environment by: 1. adjusting the dispatching code in the OS so that it gives very short timeslices to processes, so the Pactor process can get CPU time sooner; and 2. running the Pactor process with a high dispatching priority (which the superuser can accomplish with a negative priority value on the renice command.) Shortening the time slice means that more of your CPU power is used up on trips through the dispatcher portion of the OS, rather than in running whatever user-mode application programs are ready to run, but with a fast computer that doesn't have a lot to do, that should be okay. In FreeBSD, you would issue a command like this as root: # sysctl kern.sched.quantum=1 The quantum is measured in microseconds. The default value is 100,000, or 100 milliseconds. By changing it to 10,000, or 10 milliseconds, you make it possible for the highest-priority task to get use of the CPU within 10 milliseconds, rather than 100. I'm not really a Linux guy, so I don't know whether there is a comparable sysctl variable in Linux, or whether you can build a custom kernel that uses a shorter scheduling quantum, or what. -- 73 DE AE6VW, Chris Jewell [EMAIL PROTECTED] Gualala 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/
[digitalradio] Re: Timing requirements of digital ARQ
--- In digitalradio@yahoogroups.com, KV9U [EMAIL PROTECTED] wrote: Since I am not a programmer, other than taking some rudimentary courses, reading some of Don Lancaster's books, and knowing that it is not something I could ever do very well, something still doesn't seem right to me when it comes to the claim that computers just can not meet the timing requirements of ARQ digital modes. When I use the computer to key my ICOM 756 Pro 2 with Dave's DX Lab Commander software in order to run other programs that interface with Commander (such as Multipsk which is my main digital sound card program), it does not seem to have much latency at all. And if one could key relatively slow CW as is done with the software for the SDR1000, why would that not be almost a magnitude faster than you would need for adequate ARQ switching speed? How many ms do you need? Rick, KN6KB, the inventor of SCAMP, has said that the power in the typical Windows OS computer we use is something like a magnitude less than that available in the dedicated SCS modems and that is why they perform so well compared to a computer (for the dedicated part). I wonder where the dividing line will come so that computers will at least match the SCS type units? The problem is not that the PC's are not fast enough, it's that the timing of events is not predictable enough. In even the smallest microcontrollers, you can control the timing of events and processing down to a microsecond, if you so choose. For example, you can set the state of a pin, wait 8.76 milliseconds, change the state - and you KNOW that the state will be changed at that 8.76ms point, no if's, and's, or but's. In a typical PC OS, however, you lose that predictability. You can tell the OS, I want to wait 8.76ms, so you can then go and change the state of the pin, but, in reality, you may not actually be able to do it for 8, 10, or 30ms later, because the OS is busy doing other things, in the meantime. Asking for an 8.76ms pause doesn't mean you'll GET an 8.76ms pause. I can't speak as to the accuracy of the posting that indicated that Windows has some facilities to accomodate real-time programming. If that's the case, I have to wonder why nobody has done it under Pactor I, at least, for Windows. Years ago, there were P-I *decoders* that worked under DOS. And now there's a P-I application for Linux called 'hfterm'. But, I've compared on-the-air performance between hfterm and my SCC PTC-II modem in P-I mode, and there's just no comparison - the SCS blows hfterm away. At least, so far. ;-) - Rich 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/
[digitalradio] Re: New to Digital HF -- PACTOR setup and hardware maybe needed???
Precise timing isn't the issue, Steve. WinWarbler originally used GetTickCount() and QueryPerformanceCounter() in its CW generation code, but a high-resolution timer using the multimedia library is sufficiently accurate and more convenient. The problem is thread scheduling. WinWarbler uses SetPriorityClass to establish REALTIME_PRIORITY_CLASS and SetThreadPriority to establish THREAD_PRIORITY_TIME_CRITICAL . Nonetheless, there are many CPU- consumptive events that Windows insists on handling at higher priority -- such as displaying and moving the Task Manager window. Spin locks are not an acceptable solution IMHO; the user would find it disconcerting if the mouse pointer stopped following mouse movements during CW generation or Pactor-3 operation, for example. Yes, one could dedicate a headless Windows PC to executing one application like Pactor-3, but what would be the point? Even the most expensive Pactor-3 TNC would be cheaper and more compact to boot. I didn't comment on the feasibility of implementing AMTOR on Windows; Pactor-2 and Pactor-3 were the protocols I mentioned. From my days as a CPU architect and designer, I have lots of experience with real-time operating systems and applications -- but WinWarbler was my first encounter with extracting real-time performance from Windows. Any suggestions or pointers you have in this area would be appreciated. 73, Dvae, AA6YQ --- In digitalradio@yahoogroups.com, Steve Hajducek [EMAIL PROTECTED] wrote: GM Dave, Yes, a technical item up for discussion. I must assume that you have never done any Near Real Time Systems development such as ATE or Industrial Control applications under MS- Windows? I on the other hand have and the WIN32 API beginning all the way back with Windows NT implemented a number of functions for embedded applications with critical timing requirements. For example you have the GetTickCount() API call which has a resolution of 10ms and the QueryPerformanceCounter() which returns the resolution of a high-resolution performance counter to 0.8 microseconds and then there are Spinlocks to synchronize timing events during an interrupt response or other similar activity, together with Process Priority and Asynchronous I/O and some other functions you can achieve nanosecond accuracy and make your application own the operating system to prevent other system processes from interfering with your critical timing needs. It is my opinion that ARQ protocols such as AMTOR and others with their short ACK/NAK can implemented under MS-Windows 2000 Professional and above taking the above approach. /s/ Steve, N2CKH/AAR2EY At 10:23 PM 8/27/2006, you wrote: The issue is control over the operating system's scheduling decisions. There are real-time versions of Linux that are comparable in this dimension to the firmware running in a TNC; given sufficient CPU horsepower, a Pactor-2 or Pactor-3 implementation on realtime Linux is feasible. The Windows scheduler cannot be adequately controlled for use timing- critical applications; as a result, the response time requirements of protocols like Pactor-2 and Pactor-3 cannot be guaranteed, no matter how fast the CPU. Generating CW with consistent timing is a challenge on this platform. 73, Dave, AA6YQ 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/
[digitalradio] Re: ALE QRM is minimal
Steve, I asked a few simple questions about the amateur implementation of ALE; these questions were not focused on politeness, but rather on understanding how many ALE users can be simultaneously QRV if there's one pilot channel per amateur band. Bonnie claimed 1000, but two multiplications and a division yields a much lower number. If the model underlying this math is incorrect, please set me straight. I have reviewed enough of the military documentation to understand that they employ dedicated ALE transceivers capable of much faster scanning rates. As a result, sounding duration is signficantly reduced, and channel capacity increases in proportion. But one ham with an amateur transceiver limited to a 2 channel-per-second scan rate would force all ALE participants to sound for 20 seconds, even if their equipment could scan more rapidly. Do I have this right? Since the 20 second sounding time is calculated to allow each station to scan 40 frequencies without missing a sounding, one obvious step to increase capacity would be to reduce the number of frequencies being scanned. If there's only one pilot channel per amateur band, scanning could be reduced to 10 frequencies, which would allow sounding time to be reduced to 5 seconds. This would increase capacity by a factor of 4 -- to ~120 simultaneous users, if I understand correctly. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, Steve Hajducek [EMAIL PROTECTED] wrote: Hi Dave, At 10:53 PM 8/27/2006, you wrote: Does ALE provide some means of reducing contention? I recommend that to answer all of your technical questions on subject ALE that you refer the actual Federal, Military and STANAG Standards which you can find on the Internet quite easily. You can start with a number of them at the following URL: http://www.n2ckh.com/MARS_ALE_FORUM/tecref.html Listed below are the ALE Operational Rules taken directly from MIL-STD-188-141B APPENDIX A, take the time to read this and do additional research WRT the details of the referenced items herein and you should be satisfied that ALE is the most courteous digital mode with automatic operation you could ever want to see, compared to any other system that has ever been used on the Amateur Radio bands. /s/ Steve, N2CKH/AAR2EY A.4.4 ALE operational rules. The ALE system shall incorporate the basic operational rules listed in table A-V. Some of these rules may not be applicable in certain applications. For example, always listening is not possible while transmitting with a transceiver or when using a common antenna with a separate transmitter and receiver. TABLE A-V. ALE operational rules. 1) Independent ALE receive capability (in parallel with other modems and simular audio receivers) (critical). 2) Always listening (for ALE signals) (critical). 3) Always will respond (unless deliberately inhibited). 4) Always scanning (if not otherwise in use). 5) Will not interfere with active channel carrying detectable traffic in accordance with table A-I (unless this listen call function is overriden by the operator or other controller). 6) Always will exchange LQA with other stations when requested (unless inhibited), and always measures the signal quality of others. 7) Will respond in the appropriate time slot to calls requiring slotted responses. 8) Always seek (unless inhibited) and maintain track of their connectivities with others. 9) Linking ALE stations employ highest mutual level of capability. 10) Minimize transmit and receive time on channel. 11) Automatically minimize power used (if capable). NOTE : Listed in order of precedence. TABLE A-I. Occupancy detection probability (2G and 3G). WaveformSNR (dB in 3 kHz) Dwell Time (s) Detection Prob ALE 0 2.0 0.80 6 2.0 0.99 SSB Voice 6 2.0 0.80 9 2.0 0.99 MIL-STD-188-110 0 2.0 0.80 (Serial Tone PSK) 6 2.0 0.99 STANAG 45290 2.0 0.80 6 2.0 0.99 STANAG 4285 0 2.0 0.80 6 2.0 0.99 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] ALE QRM
Yes! Just select a calling frequency. Then move off. From: kd4e [EMAIL PROTECTED] Reply-To: digitalradio@yahoogroups.com To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] ALE QRM Date: Sun, 27 Aug 2006 23:32:12 +0800 Someone somewhere will *have* to sound* else no one anywhere will make a contact! :-) That said, in small numbers the ALE sounding-QRM is unlikely to be unbearable. Were the usage numbers to increase then the sounding-QRM could definitely become more than an occasional nuisance. Since ALE is mostly of value in military-like emergency communications support there is no good argument for it to be spread all over all of the Ham HF spectrum. Tiny slivers of each band answer the propagation availability question. Spinning the VFO and listening solves the available frequency question. Best of both worlds, least probability of QRM. WDYT? doc Where did you get the idea that we on ALE are sounding 24/7 ? ? If you check the HFLINK web site you will notice to the set up is asking that the system is *NOT* be sounding... please seehttp://www.hflink.com/beta/pcale1061options.jpg John, W0JAB At 09:30 PM 8/27/2006, you wrote: It is truly amazing to me that the same hams who have torn up this group time after time, objecting long and vigorously against automatic Pactor stations , are promoting the concept of ALE sounding on HF 24/7 Talk about being hypocritical !!! If we have 1000 Ale stations sounding 24/7, how much QRM will this create? John VE5MU -- Thanks! 73, doc, KD4E ... somewhere in FL URL: bibleseven (dot) com 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] Re: Can You Call Another Ham On The Air? Right Now?
Ahhh...we're a tiny minority. Most Hams know only SSB and CW. Besides, most of the new digital modes seems to come out of Europe! From: Dave Bernstein [EMAIL PROTECTED] Reply-To: digitalradio@yahoogroups.com To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: Can You Call Another Ham On The Air? Right Now? Date: Mon, 28 Aug 2006 05:59:07 - If as you say, ham radio operators have not been thinking outside the box, and are largely content with the status quo, having never known anything better, then how do you explain - the blizzard of new digital modes developed over the past 5 years - the rapid adoption of panoramic reception and broadband decoding - the use of software-defined transceivers ? 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, expeditionradio [EMAIL PROTECTED] wrote: Dave G0DJA David It's a bit of a silly arguement to say we should be able to call up someone who we probably have never spoken to before and have not got any idea whether they use the same bands and modes as we do... Hi Dave, I believe it is not silly at all to call specific hams we have never spoken with before, without knowing bands or modes they use... simply by knowing their callsign. I suggest that the reason some might think it is odd, is that ham radio operators have not been thinking outside the box, and are largely content with the status quo, having never known anything better. Calling each other on the air is technically feasible in many ways, especially with our available digital radio technologies, microprocessor-driven transceivers, and computers. In posing the question, I had hoped to spur some thought and intelligent discussion about different ways to dependably initiate communications with each other on the air. I'm interested in all kinds of methods, especially the ones that do not require schedules, manual net monitoring, or telephone calls. Bonnie KQ6XA . 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] Re: ALE QRM is minimal
One of the main interests that I have in digital modes is getting a message through the most difficult conditions, completely intact as sent, and as fast as possible. I was looking at the STANAG 5066 specifications and test results, (Steve has some below), and quite frankly I am concerned that this standard has what I would normally consider to be unacceptable performance (non performance) with weak signals. I am not sure what kind of cps or wpm throughput the bit rates mean but it I wonder how it compares to SCAMP running at 10 db S/N? Because SCAMP only operated down to about +10 db S/N (maybe slightly better), it was rejected as unacceptable for practical messaging. From the info on Steve's site: http://www.n2ckh.com/MARS_ALE_FORUM/MIL-STD-188-110B.pdf Here are some claimed performance levels: Bit rate Multipath SNR BER 4800 2 ms 27 db 1 x e-3 with .5 Hz fading BW 2400 2 ms 30 db 1 x e-3 with 5 Hz fading BW 1200 2 ms 11 db 1 x e-5 with 1 Hz fading BW 300 5 ms 7 db 1 x e-5 with 5 Hz fading BW 75 5 ms 2 db 1 x e-5 with 5 Hz fading BW Even with the slowest 75 bps, and a multipath of 5 ms, it can only work down to 2 db ABOVE the noise! This is not good. From personal experience, it is not easy to get even 10 db S/N signals with typical amateur signals with modest antennas on the lower bands. They even show some constellations at 64 QAM. From what the SSTV folks have said, 64 QAM is not really a useful mode on HF. Perhaps that is because they are not using ARQ? Note also that the multipaths are moderate to low compared to worst case HF propagation. I question whether this stuff can work under many conditions we routinely operate with sound card modes (but are not 100% copy without ARQ). The BER that this system can handle seems to indicate that the channel has to be rather good. These BER's seem to be more appropriate for what we would expect on equipment designed for VHF and up ... aren't they? For those of you who have used STANAG 5066 waveforms, what kind of throughput have you experienced with real world connections? The deeper I examine this NATO standardized agreeement, the more it is beginning to look like another one of those the emperor has no clothes findings. Thanks and 73, Rick, KV9U Steve Hajducek wrote: I recommend that to answer all of your technical questions on subject ALE that you refer the actual Federal, Military and STANAG Standards which you can find on the Internet quite easily. You can start with a number of them at the following URL: http://www.n2ckh.com/MARS_ALE_FORUM/tecref.html Listed below are the ALE Operational Rules taken directly from MIL-STD-188-141B APPENDIX A, take the time to read this and do additional research WRT the details of the referenced items herein and you should be satisfied that ALE is the most courteous digital mode with automatic operation you could ever want to see, compared to any other system that has ever been used on the Amateur Radio bands. /s/ Steve, N2CKH/AAR2EY A.4.4 ALE operational rules. The ALE system shall incorporate the basic operational rules listed in table A-V. Some of these rules may not be applicable in certain applications. For example, always listening is not possible while transmitting with a transceiver or when using a common antenna with a separate transmitter and receiver. TABLE A-V. ALE operational rules. 1) Independent ALE receive capability (in parallel with other modems and simular audio receivers) (critical). 2) Always listening (for ALE signals) (critical). 3) Always will respond (unless deliberately inhibited). 4) Always scanning (if not otherwise in use). 5) Will not interfere with active channel carrying detectable traffic in accordance with table A-I (unless this listen call function is overriden by the operator or other controller). 6) Always will exchange LQA with other stations when requested (unless inhibited), and always measures the signal quality of others. 7) Will respond in the appropriate time slot to calls requiring slotted responses. 8) Always seek (unless inhibited) and maintain track of their connectivities with others. 9) Linking ALE stations employ highest mutual level of capability. 10) Minimize transmit and receive time on channel. 11) Automatically minimize power used (if capable). NOTE : Listed in order of precedence. TABLE A-I. Occupancy detection probability (2G and 3G). WaveformSNR (dB in 3 kHz) Dwell Time (s) Detection Prob ALE 0 2.0 0.80 6 2.0 0.99 SSB Voice 6 2.0 0.80 9 2.0 0.99 MIL-STD-188-110 0 2.0 0.80
RE: [digitalradio] Re: The digital throughput challenge on H
New/updated Routing Information...station availibility, frequency changes, etc? Currently in NTS called net bulletins. 73...K5YFW -Original Message- ...under what circumstances would a message transport layer require one-to-many transmission? 73, Dave, AA6YQ 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] Re: ALE QRM is minimal
Hi Dave, At 10:46 AM 8/28/2006, you wrote: I have reviewed enough of the military documentation to understand that they employ dedicated ALE transceivers capable of much faster scanning rates. Really? Please enlighten me, I was under the impression that the ALE scan rates of 1, 2 and 5 ch/sec was it at present and that the future goal as stated in MIL-STD-188-141B was 10 ch/sec. The PC-ALE software supports 1, 2 and 5 ch/sec with an HF transceiver that is cable of all selections. As a result, sounding duration is signficantly reduced, Sorry, but you will have to explain to me how Sounding duration decreases with an increase in the Scan Rate. and channel capacity increases in proportion. Well not exactly. A 2 ch/sec scan rate allows you to cover the same number of channels faster than a 1 ch/sec scan rate and thus increase the odds of hearing a Sounding or a Linking call sooner. Running 2 or 5 ch/sec will also permit the station to be part of more than one ALE network at the same time, not an issue per see with Amateur Radio, but if two networks had scan groups of 10 channels each, you could scan both with excellent results. The number of channels you scan does have an effect on your Soundings, you sound longer when you have more channels in the mix. There are variable here as we are now at a stage were you have 3 generations of ALE. The latest ALE technology supports GPS time synchronization of the Scanning/Sounding which in the future will radically reduce BER/SNR data transfer for LQA ranking when all user's can support it. But one ham with an amateur transceiver limited to a 2 channel-per-second scan rate would force all ALE participants to sound for 20 seconds, even if their equipment could scan more rapidly. Do I have this right? The details are to be found in MIL-STD-188-141B Appendix A. Regardless of the scan rate, if the controller Sounds based on number of channels in the scan group its less than 1 second per channel. The minimum redundant sound length (Trs) is equal to the standard one-word address leading call; that is, Trs = Tlc min = 2 Ta min = 2 Trw = 784 ms. Thus for 12 channels it would be about 9.4 seconds depending on your address length being sent. The address length is based on an ALE Word which is 3 ASCII characters, for Amateur Radio applications we would being using 2 ALE Words as there are no 3 character callsigns, whereas in the Military and Government world there are 3 character ALE Self Addresses being used. So W1AW, N2CKH and WB2XYZ are all 2 ALE Words were automatic padding is used to fill the second word. The least number of ALE Words the more efficient and reliable is the system. One would now want to use WB2XYZ/W6 to indicate they are in California. For AQC-ALE where many things were changed to make things even more efficient, a 2 ALE Word is the maximum allowed, whereas the original ALE allowed a 5 ALE Word (15 character) Address to support the Military Automatic Digital Network (AUTODIN) system to directly link a Phone Patch call. Feel free to double check me with the standards, I am no expert on all this stuff and I am not perfect either, I make calculation errors often. /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] Re: ALE QRM is minimal
Hello Bonnie - what is ALE please? - 73 Bruce. 72/73 - Bruce ve5rc/ve5qrp - QRP-C#1, QRP-L#886, A1 Operator Enter QRP-Canada's RUN with RAC contest - details - http://www.qrp-canada.com 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] Re: New to Digital HF -- PACTOR setup and hardware maybe needed???
Hi Dave, I mentioned AMTOR as its timing is more robust that PACTOR I. As I have stated to the MARS-ALE users, the future version of that tool when PACTOR I support is added ont he PCSDM will pretty much own the OS, not a problem for our purposes as that one program running is our only focus. GTOR is less demanding, but may be require the same approach as PACTOR I. This is not required of DBM ARQ which is much less demanding that GTOR. /s/ Steve, N2CKH At 06:43 AM 8/28/2006, you wrote: Precise timing isn't the issue, Steve. WinWarbler originally used GetTickCount() and QueryPerformanceCounter() in its CW generation code, but a high-resolution timer using the multimedia library is sufficiently accurate and more convenient. The problem is thread scheduling. WinWarbler uses SetPriorityClass to establish REALTIME_PRIORITY_CLASS and SetThreadPriority to establish THREAD_PRIORITY_TIME_CRITICAL . Nonetheless, there are many CPU- consumptive events that Windows insists on handling at higher priority -- such as displaying and moving the Task Manager window. Spin locks are not an acceptable solution IMHO; the user would find it disconcerting if the mouse pointer stopped following mouse movements during CW generation or Pactor-3 operation, for example. Yes, one could dedicate a headless Windows PC to executing one application like Pactor-3, but what would be the point? Even the most expensive Pactor-3 TNC would be cheaper and more compact to boot. I didn't comment on the feasibility of implementing AMTOR on Windows; Pactor-2 and Pactor-3 were the protocols I mentioned. From my days as a CPU architect and designer, I have lots of experience with real-time operating systems and applications -- but WinWarbler was my first encounter with extracting real-time performance from Windows. Any suggestions or pointers you have in this area would be appreciated. 73, Dvae, AA6YQ 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/
[digitalradio] Re: Timing requirements of digital ARQ
To use your example, Rick, if Windows introduces a 10 ms delay from the time when you strike a button to initiate transmission in MultiPSK until the point where Commander sends a CI-V Transmit! command to your 756 Pro2, you'd never notice. However, such a delay in confirming reception of a Pactor-3 packet would break the protocol. The SCS PTC-II Pro, which supports both Pactor-2 and Pactor-3, utilizes a Motorola (now Freescale) 68360 clocked at 25 MHz and a 56303 24-bit DSP clocked at 100 MHz; see http://www.globalmarinenet.net/ptc.htm The 68360 is a descendant of the venerable 68000; its probably being used for administrative tasks like running the serial port and command line interface. The 56303 DSP does the heavy lifting. While its DSP instruction set is advantageous, its performance is modest by current standards; see http://www.bdti.com/articles/benchmark_icspat99.pdf#search=%22dsp% 20benchmarks%22 I am unable to locate a benchmark comparing the performance of dedicated DSP chips like the 56303 DSP with general purpose microprocessors, but I suspect that a 1 GHz Pentium could handle the processing load. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, KV9U [EMAIL PROTECTED] wrote: Since I am not a programmer, other than taking some rudimentary courses, reading some of Don Lancaster's books, and knowing that it is not something I could ever do very well, something still doesn't seem right to me when it comes to the claim that computers just can not meet the timing requirements of ARQ digital modes. When I use the computer to key my ICOM 756 Pro 2 with Dave's DX Lab Commander software in order to run other programs that interface with Commander (such as Multipsk which is my main digital sound card program), it does not seem to have much latency at all. And if one could key relatively slow CW as is done with the software for the SDR1000, why would that not be almost a magnitude faster than you would need for adequate ARQ switching speed? How many ms do you need? Rick, KN6KB, the inventor of SCAMP, has said that the power in the typical Windows OS computer we use is something like a magnitude less than that available in the dedicated SCS modems and that is why they perform so well compared to a computer (for the dedicated part). I wonder where the dividing line will come so that computers will at least match the SCS type units? 73, Rick, KV9U Dave Bernstein wrote: The issue is control over the operating system's scheduling decisions. There are real-time versions of Linux that are comparable in this dimension to the firmware running in a TNC; given sufficient CPU horsepower, a Pactor-2 or Pactor-3 implementation on realtime Linux is feasible. The Windows scheduler cannot be adequately controlled for use timing- critical applications; as a result, the response time requirements of protocols like Pactor-2 and Pactor-3 cannot be guaranteed, no matter how fast the CPU. Generating CW with consistent timing is a challenge on this platform. 73, Dave, AA6YQ 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/
[digitalradio] Re: The digital throughput challenge on H
Those are all low-occurrence events that could be implemented with one-to-one messages with no significant performance degradation. One-to-one messaging with ARQ would seem optimal. KISS, remember? 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, DuBose Walt Civ AETC CONS/LGCA [EMAIL PROTECTED] wrote: New/updated Routing Information...station availibility, frequency changes, etc? Currently in NTS called net bulletins. 73...K5YFW -Original Message- ...under what circumstances would a message transport layer require one-to-many transmission? 73, Dave, AA6YQ 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] Re: ALE QRM is minimal
Hi Rick, Just time for a quick comment. Don't confuse STANAG 5066 Data Link Protocol (DLP) as covered in MIL-STD-188-141B which is a Data Link Protocol at the Physical Layer with STANAG 5066 which is a network protocol at the Link Layer. Basically and DLP with the need ARQ support and speed can be used at the Physical Layer. If an MT-63 Adaptive ARQ protocol with a transport layer and enough speed were to develop it could be used. STANAG 5066 DLP (S5066) replaced FED-STD-1052 DLP (FS-1052) going from MIL-STD-188-141A to MIL-STD-188-141B. Both are DLP's that make use of the MIL-STD-188-110x modems, both provide and ARQ protocol, where 5066 DLP is much improved. We use FS-1052 daily in MARS, we get full 2400bps throughput on a good channel with stations that are properly configured. We have not yet implemented S5066, its on the To Do list. /s/ Steve, N2CKH/AAR2EY At 11:16 AM 8/28/2006, you wrote: One of the main interests that I have in digital modes is getting a message through the most difficult conditions, completely intact as sent, and as fast as possible. I was looking at the STANAG 5066 specifications and test results, (Steve has some below), and quite frankly I am concerned that this standard has what I would normally consider to be unacceptable performance (non performance) with weak signals. I am not sure what kind of cps or wpm throughput the bit rates mean but it I wonder how it compares to SCAMP running at 10 db S/N? Because SCAMP only operated down to about +10 db S/N (maybe slightly better), it was rejected as unacceptable for practical messaging. From the info on Steve's site: http://www.n2ckh.com/MARS_ALE_FORUM/MIL-STD-188-110B.pdf Here are some claimed performance levels: Bit rate Multipath SNR BER 4800 2 ms 27 db 1 x e-3 with .5 Hz fading BW 2400 2 ms 30 db 1 x e-3 with 5 Hz fading BW 1200 2 ms 11 db 1 x e-5 with 1 Hz fading BW 300 5 ms 7 db 1 x e-5 with 5 Hz fading BW 75 5 ms 2 db 1 x e-5 with 5 Hz fading BW Even with the slowest 75 bps, and a multipath of 5 ms, it can only work down to 2 db ABOVE the noise! This is not good. From personal experience, it is not easy to get even 10 db S/N signals with typical amateur signals with modest antennas on the lower bands. They even show some constellations at 64 QAM. From what the SSTV folks have said, 64 QAM is not really a useful mode on HF. Perhaps that is because they are not using ARQ? Note also that the multipaths are moderate to low compared to worst case HF propagation. I question whether this stuff can work under many conditions we routinely operate with sound card modes (but are not 100% copy without ARQ). The BER that this system can handle seems to indicate that the channel has to be rather good. These BER's seem to be more appropriate for what we would expect on equipment designed for VHF and up ... aren't they? For those of you who have used STANAG 5066 waveforms, what kind of throughput have you experienced with real world connections? The deeper I examine this NATO standardized agreeement, the more it is beginning to look like another one of those the emperor has no clothes findings. Thanks and 73, Rick, KV9U Steve Hajducek wrote: I recommend that to answer all of your technical questions on subject ALE that you refer the actual Federal, Military and STANAG Standards which you can find on the Internet quite easily. You can start with a number of them at the following URL: http://www.n2ckh.com/MARS_ALE_FORUM/tecref.html Listed below are the ALE Operational Rules taken directly from MIL-STD-188-141B APPENDIX A, take the time to read this and do additional research WRT the details of the referenced items herein and you should be satisfied that ALE is the most courteous digital mode with automatic operation you could ever want to see, compared to any other system that has ever been used on the Amateur Radio bands. /s/ Steve, N2CKH/AAR2EY A.4.4 ALE operational rules. The ALE system shall incorporate the basic operational rules listed in table A-V. Some of these rules may not be applicable in certain applications. For example, always listening is not possible while transmitting with a transceiver or when using a common antenna with a separate transmitter and receiver. TABLE A-V. ALE operational rules. 1) Independent ALE receive capability (in parallel with other modems and simular audio receivers) (critical). 2) Always listening (for ALE signals) (critical). 3) Always will respond (unless deliberately inhibited). 4) Always scanning (if not otherwise in use). 5) Will not interfere with active channel carrying detectable traffic in accordance with table A-I (unless this listen call function is overriden by the operator or other controller). 6)
[digitalradio] Re: ALE QRM is minimal
AA6YQ comments below --- In digitalradio@yahoogroups.com, Steve Hajducek [EMAIL PROTECTED] wrote: snip I have reviewed enough of the military documentation to understand that they employ dedicated ALE transceivers capable of much faster scanning rates. Really? Please enlighten me, I was under the impression that the ALE scan rates of 1, 2 and 5 ch/sec was it at present and that the future goal as stated in MIL-STD-188-141B was 10 ch/sec. The PC-ALE software supports 1, 2 and 5 ch/sec with an HF transceiver that is cable of all selections. In a previous post, you stated that the scan rate for amateur ALE was 2 channels per second. Current military equipment supports 5 channels per second. That's 2.5 time faster, is it not? As a result, sounding duration is signficantly reduced, Sorry, but you will have to explain to me how Sounding duration decreases with an increase in the Scan Rate. My understand from www.hflink.org is that a station must sound for an interval long enough to allow all receivers to scan all channels; a shorter sounding interval would result in some receivers failing to hear the sounding. If all receivers scan the same number of channels at a faster rate, then sounding duration can be decreased. is this not correct? and channel capacity increases in proportion. Well not exactly. A 2 ch/sec scan rate allows you to cover the same number of channels faster than a 1 ch/sec scan rate and thus increase the odds of hearing a Sounding or a Linking call sooner. A 2 ch/sec scan rate allows you to use half the sounding interval required by a 1 ch/sec scan rate. This doubles the number of supportable simultaneous users, does it not? Running 2 or 5 ch/sec will also permit the station to be part of more than one ALE network at the same time, not an issue per see with Amateur Radio, but if two networks had scan groups of 10 channels each, you could scan both with excellent results. We're discussing amateur ALE here. The number of channels you scan does have an effect on your Soundings, you sound longer when you have more channels in the mix. There are variable here as we are now at a stage were you have 3 generations of ALE. The latest ALE technology supports GPS time synchronization of the Scanning/Sounding which in the future will radically reduce BER/SNR data transfer for LQA ranking when all user's can support it. Yes, that's the sort of approach I was asking about when I asked if there were techniques for reducing contention among competing sounders. PC-ALE would have to be extended to support this, and as you say its only effective if everyone uses it. But one ham with an amateur transceiver limited to a 2 channel-per-second scan rate would force all ALE participants to sound for 20 seconds, even if their equipment could scan more rapidly. Do I have this right? The details are to be found in MIL-STD-188-141B Appendix A. Regardless of the scan rate, if the controller Sounds based on number of channels in the scan group its less than 1 second per channel. The minimum redundant sound length (Trs) is equal to the standard one-word address leading call; that is, Trs = Tlc min = 2 Ta min = 2 Trw = 784 ms. Thus for 12 channels it would be about 9.4 seconds depending on your address length being sent. The address length is based on an ALE Word which is 3 ASCII characters, for Amateur Radio applications we would being using 2 ALE Words as there are no 3 character callsigns, whereas in the Military and Government world there are 3 character ALE Self Addresses being used. So W1AW, N2CKH and WB2XYZ are all 2 ALE Words were automatic padding is used to fill the second word. The least number of ALE Words the more efficient and reliable is the system. One would now want to use WB2XYZ/W6 to indicate they are in California. For AQC-ALE where many things were changed to make things even more efficient, a 2 ALE Word is the maximum allowed, whereas the original ALE allowed a 5 ALE Word (15 character) Address to support the Military Automatic Digital Network (AUTODIN) system to directly link a Phone Patch call. Feel free to double check me with the standards, I am no expert on all this stuff and I am not perfect either, I make calculation errors often. I don't see how the sounding duration can be independent of scanning rate (as discussed above), but using your 9.4 second sounding duration for 12 channels with each station sounding once per hour, (60*60)/9.4 yields a capacity of 383 users with 100% pilot channel utilization. Without synchronization or some other form of collision avoidance, the realistic number of simultaneous users would be in the range of 64 to 128. This is considerably less than Bonnie's claim of 1000 simultaneous users - so either I'm misunderstanding something, or the claim is false. 73, Dave, AA6YQ Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org Other
[digitalradio] Re: New to Digital HF -- PACTOR setup and hardware maybe needed???
Agreed, there's no problem if you can own the OS; but on an end- user's Windows PC, you can't do that. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, Steve Hajducek [EMAIL PROTECTED] wrote: Hi Dave, I mentioned AMTOR as its timing is more robust that PACTOR I. As I have stated to the MARS-ALE users, the future version of that tool when PACTOR I support is added ont he PCSDM will pretty much own the OS, not a problem for our purposes as that one program running is our only focus. GTOR is less demanding, but may be require the same approach as PACTOR I. This is not required of DBM ARQ which is much less demanding that GTOR. /s/ Steve, N2CKH At 06:43 AM 8/28/2006, you wrote: Precise timing isn't the issue, Steve. WinWarbler originally used GetTickCount() and QueryPerformanceCounter() in its CW generation code, but a high-resolution timer using the multimedia library is sufficiently accurate and more convenient. The problem is thread scheduling. WinWarbler uses SetPriorityClass to establish REALTIME_PRIORITY_CLASS and SetThreadPriority to establish THREAD_PRIORITY_TIME_CRITICAL . Nonetheless, there are many CPU- consumptive events that Windows insists on handling at higher priority -- such as displaying and moving the Task Manager window. Spin locks are not an acceptable solution IMHO; the user would find it disconcerting if the mouse pointer stopped following mouse movements during CW generation or Pactor-3 operation, for example. Yes, one could dedicate a headless Windows PC to executing one application like Pactor-3, but what would be the point? Even the most expensive Pactor-3 TNC would be cheaper and more compact to boot. I didn't comment on the feasibility of implementing AMTOR on Windows; Pactor-2 and Pactor-3 were the protocols I mentioned. From my days as a CPU architect and designer, I have lots of experience with real-time operating systems and applications -- but WinWarbler was my first encounter with extracting real-time performance from Windows. Any suggestions or pointers you have in this area would be appreciated. 73, Dvae, AA6YQ 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/
[digitalradio] Re: New to Digital HF -- PACTOR setup and hardware maybe needed???
Chas, the term modem is a contraction of modulator and demodulator; it purpose is the bidirectional conversion of digital signals to analog signals. There are many different kinds of modems, employing different modulation techniques to achieve different speeds and error rates over different transmission media. A modem used for internet dialup access, for example, is optimized for use with telephone lines and uses industry-standard signalling conventions so it can interoperate with any other telephone modem. The RTTY modem in in a TNC (Terminal Node Controller) uses the baudot code and RTTY mark and space tones and should be optimized for transmission and reception over HF. Circuits that modulate and demodulate PSK, FSK, Pactor, Amtor, or Olivia are all referred to as modems, but their implementations are radically different. Multi-mode TNCs typically employ a microprocessor and perhaps a programmable DSP circuit; software running on this one set of hardware components can thus implement multiple protocols -- but only one protocol is typically running at any one time. The modem in your PC is most likely a telephone modem; it may also have facsimile capabilities. The Icom 756 definitely does not include a modem; I doubt that the 736 or 746 do either. More recent Icom transceivers like the 7800 and 756 Pro 3 include a dedicated RTTY modem; to my knowledge, this modem cannot be used to encode or decode any other protocol. You mentioned the Icom CI-V bus in an earlier post. This is the means by which an application running on a PC can control an Icom transceiver -- read or write its frequency or mode, etc. It is not a modem -- its a simple serial protocol using open-collector TTL levels (a binary 0 is represented by 0 volts, and a binary 1 is represented by 5 volts). To use this with a PC serial port, a level converter to RS-232 levels is required. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, [EMAIL PROTECTED] wrote: On Mon, 28 Aug 2006 00:17:06 -0700, Chris Jewell [EMAIL PROTECTED] wrote: Suppose you're using your sound card as a modem to receive Pactor I data. Your sound card takes care of turning tones from the receiver into 1s and 0s. There's no problem there. actually, there is a modem in the 736. why can't that handle the packet checking tasks? it IS an FSK system but should be available, using HRD to run it, to handle any modem duties in the txcvr. Also, I THINK, that there is a high speed modem built into my mobo as well as 10/100 etherlink. I am just trying to figure out why I have to add another piece of hardware to the system. we KNOW that the latest, deep pocket ICOMs like the 756P3 are fully set up with an internal TNC, or so I have been assured by some of those elmers/gurus (the ones who do not agree with each other G) The reason I am here is to try to find out what is true and what is bushwa and to simplify the shack to as great an extent as possible. My experience is that the more hardware you add, the greater the load on output of final product. that applies to anything with a pretty limited source of power, be it computing, motive or whatever. I truly do appreciate all the information I am getting here. Again, do I HAVE TO HAVE a TNC with an IC736, 746 or 756? thanks 73/chas -- K5DAM Houston EL29fuAAR6TU http://tinyurl.com/df55x (BPL Presentation) 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] New to Digital HF -- PACTOR setup and hardware maybe needed???
KV9U writes: Chris, What is your view on using pipelined programming such as what was used in the SCAMP mode to get around this issue with moving the ACK to the next packet. The main penalty is latency for the user, but it seems manageable. I haven't read any detailed specs of the SCAMP protocol, only vague descriptions, and I understand that the source code is not available for public inspection at this time, but in principle a pipelined approach seems like a good way to handle the problem of OS latency in ACK/NAK at the application level, without requiring expert hackery in low-level OS details. My previous reply was just an attempt to describe the problem of non-realtime operating systems and lockstep ARQ modes such as Pactor for someone who had asked. I note that another reply said that there is a alternative real-time-capable kernel for Linux systems, so for those willing and able to use Linux, the ARQ problem may be already solved. However, a solution available to the Windows and Mac users seems like a good thing even so. In TCP, the receiving host periodically sends an ACK that responds NOT to a specific incoming packet, but instead says I have received correctly everything up to byte number N. If the sending host doesn't get an ACK up through the bytes in a given packet within a certain interval, it resends the data and all following data. This allows communication to succeed eventually if some ACKs or NAKs don't get back to the sending station. Of course, TCP/IP was conceived for full-duplex media: the sender can keep the outgoing pipe full, provided the ACKs arrive soon enough. The window size (how many bytes ahead of the ACK the sender may send) needs to be larger for faster circuit, and also larger for a circuit with a long round-trip time, such as via geosynch satellites or with many overloaded routers in the path; the window can be smaller for terrestrial circuits with few routers between the communicating hosts. Partly because incorrect packets are going to be more frequent on HF radio than on land lines, we probably should not duplicate the TCP solution in ham radio, but it gives us a starting point to think about. A system for half-duplex HF radio circuits has to provide for periodic turnaround. Short packets with frequent ACK/NAK cycles a la Pactor or GTOR allow the receiver to promptly notify the sender of changing propagation on the channel. A deep pipeline postpones that feedback, so more data may need to be resent when the circuit is unstable, BUT also makes it straightforward to implement on a typical multitasking OS. It's all a matter of trade-offs. Given that we deal with noiser circuits than were envisioned by the designers of TCP/IP, we probably want a fixed (or periodically adjusted) packet size, and a fixed number of packets sent before turnaround. The ACK would then say which of the packets arrived clean and which need to be resent. The sender could then resend those packets which need it, and add some more new ones to make up the agreed number to be placed in the pipeline. (For the sake of argument, how about 8 Pactor-sized packets followed by an ACK window 8 times as long as Pactor uses?) This is off the top of my head: if anyone has already been thinking more deeply about this and has better suggestions, by all means offer them. I'm an old computer geek but a new ham: I'm happy to learn about either computers or radio from anyone who can improve my understanding. -- 73 DE AE6VW Chris Jewell[EMAIL PROTECTED]Gualala CA USA 95445 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/
[digitalradio] -tor modes and PCs
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. 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/
[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 * 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] Re: Timing requirements of digital ARQ
Hello Rick, An additive remark to Dave. In Multispk, I have added Pactor 1 (RX/TX) but only in FEC. I would have liked to propose an ARQ Pactor1 but it is impossible. A bit in Pactor1 lasts 10 ms or 5 ms (200 bauds). This obliges to have a precision of at least 2 ms, which would be easy under DOS but impossible under Windows as you don't have a sample after sample input as under DOS, but buffers of datas. You can reduce the buffers length, perhaps down to an equivalent of 50 ms, on powerful PC but not less...so FEC (i.e asynchronous exchange of datas as in Pactor 1 FEC or in Pax) is the only solution. 73 Patrick - Original Message - From: Dave Bernstein To: digitalradio@yahoogroups.com Sent: Monday, August 28, 2006 6:35 PM Subject: [digitalradio] Re: Timing requirements of digital ARQ To use your example, Rick, if Windows introduces a 10 ms delay from the time when you strike a button to initiate transmission in MultiPSK until the point where Commander sends a CI-V Transmit! command to your 756 Pro2, you'd never notice. However, such a delay in confirming reception of a Pactor-3 packet would break the protocol. The SCS PTC-II Pro, which supports both Pactor-2 and Pactor-3, utilizes a Motorola (now Freescale) 68360 clocked at 25 MHz and a 56303 24-bit DSP clocked at 100 MHz; see http://www.globalmarinenet.net/ptc.htm The 68360 is a descendant of the venerable 68000; its probably being used for administrative tasks like running the serial port and command line interface. The 56303 DSP does the heavy lifting. While its DSP instruction set is advantageous, its performance is modest by current standards; see http://www.bdti.com/articles/benchmark_icspat99.pdf#search=%22dsp% 20benchmarks%22 I am unable to locate a benchmark comparing the performance of dedicated DSP chips like the 56303 DSP with general purpose microprocessors, but I suspect that a 1 GHz Pentium could handle the processing load. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, KV9U [EMAIL PROTECTED] wrote: Since I am not a programmer, other than taking some rudimentary courses, reading some of Don Lancaster's books, and knowing that it is not something I could ever do very well, something still doesn't seem right to me when it comes to the claim that computers just can not meet the timing requirements of ARQ digital modes. When I use the computer to key my ICOM 756 Pro 2 with Dave's DX Lab Commander software in order to run other programs that interface with Commander (such as Multipsk which is my main digital sound card program), it does not seem to have much latency at all. And if one could key relatively slow CW as is done with the software for the SDR1000, why would that not be almost a magnitude faster than you would need for adequate ARQ switching speed? How many ms do you need? Rick, KN6KB, the inventor of SCAMP, has said that the power in the typical Windows OS computer we use is something like a magnitude less than that available in the dedicated SCS modems and that is why they perform so well compared to a computer (for the dedicated part). I wonder where the dividing line will come so that computers will at least match the SCS type units? 73, Rick, KV9U Dave Bernstein wrote: The issue is control over the operating system's scheduling decisions. There are real-time versions of Linux that are comparable in this dimension to the firmware running in a TNC; given sufficient CPU horsepower, a Pactor-2 or Pactor-3 implementation on realtime Linux is feasible. The Windows scheduler cannot be adequately controlled for use timing- critical applications; as a result, the response time requirements of protocols like Pactor-2 and Pactor-3 cannot be guaranteed, no matter how fast the CPU. Generating CW with consistent timing is a challenge on this platform. 73, Dave, AA6YQ [Non-text portions of this message have been removed] 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/
[digitalradio] Re: -tor modes and PCs
In the case of Pactor-2 and Pactor-3, the developers knew they were running on dedicated processors with complete control over scheduling, so there was no reason to reduce performance by unnecessarily extending turnaround time or pipelining control messages (which extends recovery when an error occurs). If you're in the business of selling standalone TNCs, as these developers are, then you exploit every strength afforded by this approach. The last thing you'd do is design a protocol that could be implemented without your hardware! IBM Bisync? I know it all too well. The first commercial product I designed was a hardware interface for this protocol. Dating myself, it was implemented with TTL MSI -- before the availability of large scale integration or customizable logic. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, jhaynesatalumni [EMAIL PROTECTED] 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. 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] New to Digital HF -- PACTOR setup and hardware maybe needed???
Back in the late 80's when Mil-STD-188-110 was still in development, a Harris RF Comm Gp engineer/programmer recommended that you send a frame with X number of numbered packets with a CRC. The receiving station would only NAK the packets it didn't receive. The transmitting stations would start transmitting another frame with the missed packets first and then the new packets. The total of the packets, missed and new, would be less than the original number of packets. When no NAKs were received, the transmitting station would start sending more packets in a frame. Walt/K5YFW -Original Message- From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] Sent: Monday, August 28, 2006 2:28 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] New to Digital HF -- PACTOR setup and hardware maybe needed??? KV9U writes: Chris, What is your view on using pipelined programming such as what was used in the SCAMP mode to get around this issue with moving the ACK to the next packet. The main penalty is latency for the user, but it seems manageable. I haven't read any detailed specs of the SCAMP protocol, only vague descriptions, and I understand that the source code is not available for public inspection at this time, but in principle a pipelined approach seems like a good way to handle the problem of OS latency in ACK/NAK at the application level, without requiring expert hackery in low-level OS details. My previous reply was just an attempt to describe the problem of non-realtime operating systems and lockstep ARQ modes such as Pactor for someone who had asked. I note that another reply said that there is a alternative real-time-capable kernel for Linux systems, so for those willing and able to use Linux, the ARQ problem may be already solved. However, a solution available to the Windows and Mac users seems like a good thing even so. In TCP, the receiving host periodically sends an ACK that responds NOT to a specific incoming packet, but instead says I have received correctly everything up to byte number N. If the sending host doesn't get an ACK up through the bytes in a given packet within a certain interval, it resends the data and all following data. This allows communication to succeed eventually if some ACKs or NAKs don't get back to the sending station. Of course, TCP/IP was conceived for full-duplex media: the sender can keep the outgoing pipe full, provided the ACKs arrive soon enough. The window size (how many bytes ahead of the ACK the sender may send) needs to be larger for faster circuit, and also larger for a circuit with a long round-trip time, such as via geosynch satellites or with many overloaded routers in the path; the window can be smaller for terrestrial circuits with few routers between the communicating hosts. Partly because incorrect packets are going to be more frequent on HF radio than on land lines, we probably should not duplicate the TCP solution in ham radio, but it gives us a starting point to think about. A system for half-duplex HF radio circuits has to provide for periodic turnaround. Short packets with frequent ACK/NAK cycles a la Pactor or GTOR allow the receiver to promptly notify the sender of changing propagation on the channel. A deep pipeline postpones that feedback, so more data may need to be resent when the circuit is unstable, BUT also makes it straightforward to implement on a typical multitasking OS. It's all a matter of trade-offs. Given that we deal with noiser circuits than were envisioned by the designers of TCP/IP, we probably want a fixed (or periodically adjusted) packet size, and a fixed number of packets sent before turnaround. The ACK would then say which of the packets arrived clean and which need to be resent. The sender could then resend those packets which need it, and add some more new ones to make up the agreed number to be placed in the pipeline. (For the sake of argument, how about 8 Pactor-sized packets followed by an ACK window 8 times as long as Pactor uses?) This is off the top of my head: if anyone has already been thinking more deeply about this and has better suggestions, by all means offer them. I'm an old computer geek but a new ham: I'm happy to learn about either computers or radio from anyone who can improve my understanding. -- 73 DE AE6VW Chris Jewell[EMAIL PROTECTED]Gualala CA USA 95445 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:
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/
RE: [digitalradio] The digital throughput challenge on HF
Why? Because your digital voice QSO sounds like noise to SSBers? From: John Becker [EMAIL PROTECTED] Reply-To: digitalradio@yahoogroups.com To: digitalradio@yahoogroups.com Subject: RE: [digitalradio] The digital throughput challenge on HF Date: Sun, 27 Aug 2006 20:29:05 -0500 You should try DIGITAL VOICE once. There is 1000% chance that your QSO will be QRM'ed At 04:43 AM 8/25/2006, you wrote: The problem is QRM. Consisting of PACTOR, MFSK, OLIVIA, PSK31, and on 30 meters also SSB signals coming on frequency during your qso. 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/
[digitalradio] What is ALE?
An Article on the HFLINK.COM website explains ALE for amateur radio operators. The PCALE software to run ALE on your ham transceiver is also available for download on HFLINK.COM website. ALE on HF in the Amateur Radio Service Selective Calling and Automatic Linking for Voice, Text, Image, CW, and Data What is ALE? ALE is Automatic Link Establishment. With the capability to call up a specific station, a group of stations, a net... or just CQ, ALE is a versatile system for connecting operators on the air for voice, data, text, instant messaging, CW, or image QSOs. A radio operator initiating an ALE call on HF or VHF, can... read more click here: http://hflink.com/articles ALE in Ham Radio For the past 5 years, a group of ham operators has joined together for experiments and communications in Amateur Radio ALE and Selective Calling. The number of hams has grown from just a handful active in 2001, to the hundreds of... read more click here: http://hflink.com/articles How ALE Works Each ham radio ALE station uses the operator's callsign as an address in the ALE controller.When not actively in a QSO with another station, each HF SSB transceiver constantly scans through a list of frequencies, listening for its callsign. To reach a specific station, the caller simply enters the callsign just like... (read more) What is the Bandwidth of the ALE Signal? The emission type and bandwidth of the ALE 8FSK is ... read more click here: http://hflink.com/articles 73---Bonnie KQ6XA . 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] What is ALE?
Thank you Bonnie - 73 Bruce. 72/73 - Bruce ve5rc/ve5qrp - QRP-C#1, QRP-L#886, A1 Operator Enter QRP-Canada's RUN with RAC contest - details - http://www.qrp-canada.com 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/
