[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 ) > 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/
[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/
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: 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/
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/
[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 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/
[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/
