> With the advent e.g of the MK2R(+), isn't it high time that
> WL provided a built in LPT port driver like N1MM and Wintest
> do?
N1MM does not have a built-in driver - it requires DlPortIO
(a third party driver similar to directio used by WriteLog).
Rather than continued use of hardware that is gong away ... a
SO2R standard based on serial port handshake lines (as recently
implemented by WinTest) and WinKey makes a lot of sense. This
avoids the problems with LPT but is simple enough that the end
user can still build his own hardware.
CW and PTT functions can be readily accommodated by the WinKey CW
processors by K1EL. These processors (WinKey and WinKey2 have the
additional benefit of eliminating the need for the logging application
to perform the critical timing tasks related to CW generation. The
application need only take minimal care not to overflow the limited
buffer capability of the original WinKey. In addition, WinKey handles
paddle inputs directly and can generate PTT by software command.
With only slight simplification, the remaining functions can be
accomplished with the handshake lines on a standard serial port
(8250 compatible) or USB UART like the FTDI FT-232R.
Since many of the more widely used contest and general purpose
logging programs already support WinKey for CW generation and
WinKey does not utilize the serial "handshake" signals for control
or communication, It would be a logical extension to the existing
WinKey usage to define the handshake signals on the same port
(physical or virtual) for radio switching and audio control.
There are two possible configurations:
1) Using WinKey or WinKey 2 in "single output" mode:
The WinKey CW processor is operated in the "single radio mode."
The A/B control provides CW/PTT steering. The hardware designer
may also use A/B for microphone steering if the target software
provides a single channel (Mono) DVK.
The signals are defined as:
DTR = A/B
RTS = Stereo (split)
DSR = Foot Switch | If supported by
RI = Foot switch #2 (optional) | target software
PTT may be generated in several ways:
CW - no PTT (QSK)
- WinKey generated PTT
- application controlled PTT using "key buffered:"
<18><01> (on) and <18><00> (off)
SSB - application controlled PTT using "key buffered:"
<18><01> (on) and <18><00> (off)
RTTY - (if needed) application controlled PTT using
"key buffered:" <18><01>(on) and <18><00> (off)
The single output mode may be extended to control of more than
two radios by moving the A/B signal to DTR on the radio control
(CAT/CI-V) port and using multiple steering (select) relays.
In this case the program would raise DTR on the port for the
desired radio and drop DTR for all other radios.
2) If WinKey 2 is used, the application may choose to make use of
the "dual radio mode" to allow independent selection of headphone
audio and transmitter. With dual radio mode, there is no need to
"steer" CW and PTT using hardware since WK2 provides independent
CW and PTT outputs for each radio. The appropriate outputs are
selected with the WinKey "Set PinConfig" commands: <09><xxxx10xx>
and <09><xxxx01xx>.
Even though there is no need to steer CW and PTT, the A/B signal
is still required for headphone (receiver) selection. However,
since transmitter selection is no longer effected by this signal,
the application is able to control receiver audio selection
independently. This flexibility can be used for functions like
"aggressive SO2R" where the headphones are switched to the non-
transmitting radio while during transmission.
The signals are defined as:
DTR = Receiver select
RTS = Stereo (split)
DSR = Foot Switch | If supported by
RI = Foot switch #2 (optional) | target software
As with the "single radio mode" PTT options are:
CW - no PTT (QSK)
- WinKey generated PTT
- application controlled PTT using "key buffered:"
<18><01> (on) and <18><00> (off)
SSB - application controlled PTT using "key buffered:"
<18><01> (on) and <18><00> (off)
RTTY - (if needed) application controlled PTT using
"key buffered:" <18><01>(on) and <18><00> (off)
These configurations should not be hard for software authors to
implement. Most current software already support "PTT by software
command" and those routines can be extended to support the use of
<18><01>/<18><00> for PTT. In addition, many programs already
support some subset of CT/NA/TR LPT control - even if it is only
pin 14 for transmit focus (or radio selection) - and it should be
relatively easy to map those functions to the serial port handshake
lines.
73,
... Joe, W4TV
> -----Original Message-----
> From: writelog-bounces@contesting.com
> [mailto:writelog-bounces@contesting.com] On Behalf Of Clive Whelan
> Sent: Saturday, November 11, 2006 1:53 PM
> To: writelog@contesting.com
> Subject: [WriteLog] LPT Ports and directio
>
>
> Even after a successful installation of directio, all the
> LPT port check boxes are still greyed out in the WL
> configuration dialogue. What might be wrong?
>
>
> With the advent e.g of the MK2R(+), isn't it high time that
> WL provided a built in LPT port driver like N1MM and Wintest
> do?
>
>
> 73
>
>
>
> Clive
> GW3NJW
>
> _______________________________________________
> WriteLog mailing list
> WriteLog@contesting.com
> http://lists.contesting.com/mailman/listinfo/writelog
> WriteLog on the web: http://www.writelog.com/
>
>
_______________________________________________
WriteLog mailing list
WriteLog@contesting.com
http://lists.contesting.com/mailman/listinfo/writelog
WriteLog on the web: http://www.writelog.com/
|