Hi Jon, Simon: Well MS-Windows being an event driven, multi-tasking environment is the not the best environment when it comes to dealing with signaling and data comm ports, however it can be managed for PTT needs reasonable well depending on how strict such PTT timing requirements are. For example as we all should know by now repetitive PTT timing down to 10ms is a big challenge.
Anyhow, the point with regard to ALE operations and PTT is that when fully exercised ALE is a near-real time scanning operation at 1, 2 and 5 channels per second (ch/sec) presently and 10 ch/sec coming as mentioned in the current MIL-STD-188-141B standard. At that 5 ch/sec scan rate there is but a 100ms window to change radio characteristics from channel to channel regarding Frequency, Mode ( and other parameters that may be supported such as Antenna Port, ATU etc.) when Scanning/Sounding. Par of the Sounding process is of course PTT as is when receiving and replying to a call while Scanning or during a user initiated LQA Linking Call during Scanning. What must be taken into account here also is the baud rate at which the radio is operating, at 9600 baud and 100ms a maximum of 80 characters can be exchanged whereas at 1200 baud it is only 10, 2400 baud is 20, 4800 baud is 40. Also, even though a radio may be operating at 9600 baud, its CPU may not be able to process the data sent to it fast enough and may use whatever means provided ( if any) to ask the PC application to wait before sending more data at certain juncture and if not the follow on data that comes to fast will be ignored. In ALE operations the last thing to be sent for a TX event is the TX method, thus for CAT PTT the TX command is the last item sent to the radio and if may be ignored. I have however found in my testing that it does work rather well with the make model radios that I have here for testing with, but I still prefer and I do only use RS-232 RTS or DTR for my PTT needs as I know for sure that the RS-232 will go high and go low, I state that as aside from what I have just pointed out, RS232 noise, data collision ( depending on the topology such as CI-V CSMA) and dropped data bits, missing polling event ( depending on radio model), a constant keep in PTT or keep alive command needing to be sent over and over for some models ( e.g. Harris RF-350 family and Kachina 505DSP) etc. as well as the possibility of radio lock up due to RFI or over heating or just plain failure come into play with CAT PTT and not with RTS/DTR signaling. For casual use of Amateur Radio CAT PTT is fine as far as I am concerned, its also seems to work ok for most radios, most of the time for ALE applications from the years of experience now under my belt in discussing this issue with MARS-ALE users who have been using it and as stated, its not supported for each radio type selection in the next version of PC-ALE being tested for those that want to use it, I just can't recommend it for everyone to use taking into account the known issues and variables involved, whereas hardware PTT through the 10 ch/sec ( supported in MARS-ALE) scan rate works great all the time. With it now being in place in the next PC-ALE, everyone can experiment with their installation ( if their radio supports it) to determine if its reliable for their ALE pursuits. /s/ Steve, N2CKH At 07:45 AM 8/6/2007, you 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.
