Hi Brian, At 08:24 AM 8/6/2007, you wrote: >Of course, if you don't have a spare RS232 port then CAT contol is >obviously better. At least for PSK, I found the CAT control on the MP >to work just fine.
I can't speak for all software applications, but for PC-ALE the standard use of RTS or DTR for PTT is made via the same serial port as is CAT control, you simply use an RS232-Y cable or connector/connector shelled Tri-Port adapter etc. PC-ALE does for some time now also support a dedicated RS-232 port for PTT has many Amateurs requested this, but a dedicated port in my opinion is waste, I reluctantly added the same alternate PTT support for a dedicated RS232 PTT port to MARS-ALE due to users requests as that is how they are configured for other applications, which makes no sense to me when doing it all on the CAT RS-232 port is the logical way to support hardware PTT. >I question the "timing" conclusion. Anybody who has tried using RS232 >ports or LPT's for sending CW knows the highly buffered environment in >XP and VISTA screws up the timing. We're talking way more than 10 ms >delays and timing inaccuracies. People have gotten around this in XP >by a program called DLPORT which allows direct port writes like one >could do in older OS's. > >Another solution has been to use WINKEY instead of generating CW >within the computer. One sends out an ASCII character via a port and >the WINKEY PIC generates the perfect CW character. In effect it is a >CW TNC. That's real progress! Instead of just turning on and off an >external line at prescribed times one has to resort to such nonsense. > >Anyhow the software/hardware out there should be working on USB >interfaces rather than COM port interfaces. USB/com port intefaces >have been problematic with RTTY due to the slow baud rate. I assume >the same would be true for these modes. Obviously rig control for >most present generation rigs has to be over COM's. Most USB/COM port >converters work OK for rig control. However, the same timing problems >most likely exist. I simply don't know if USB timing suffers from the >above timing problems or not. Perhaps so. But for computers with no >COM ports, USB is the way to go. > >The problem is that a real time operating system is needed when timing >is critical. All GUI based OS's are a challenge for timing, long ago I added support to my old CATCC software for CW keying, however it was in support of controlling my AEA MM-3 keyer ( the best keyer ever designed to data in my opinion!!) when my wrists and fingers needed a break from the paddle and even pressing the keypad to send from memory. For repetitive fast time domain events just running an open application under MS-Windows is not going to provide proper results all the time, its a given due to the nature if the OS. I had to take it to another level of timing even just for radio control support of a beast of a radio that requires RS232 breaks as attention timing prior to the follow on command data recently for reliable CAT control of this one make/model radio, timing to less than 10ms can be achieved under MS-Windows, but you basically need to reduce the OS to an almost single application use level, which depending on the application is just fine and can be done using the embedded application API calls or other multi-media calls, buts its a lot more work to manage things. /s/ Steve, N2CKH >73 de Brian/K3KO > >--- In [email protected], "Simon Brown" <[EMAIL PROTECTED]> >wrote: > > > > Chiming in here: no delays, less to go wrong. Also a *lot* easier >for the > > poor old programmer. > > > > Simon Brown, HB9DRV > > > > ----- Original Message ----- > > From: "Jon Maguire" <[EMAIL PROTECTED]> > > > > > > Can you give a rundown as why dedicated PTT is better than CAT PTT? > > > Thank you. > > > > > > >Announce your digital presence via our Interactive Sked Page at >http://www.obriensweb.com/drsked/drsked.php > >Yahoo! Groups Links > > >
