Hello Ken,
Thanks for all your great work with CT 9.38b, I can see that you have been
very busy.
As an interim solution, I am pleased to advise that I have tested a
successful method of getting band data for two radios through LPT1 - the
only parallel port on my laptop PC. This data is essential for the switching
of band-pass filters and other peripherals associated with each radio.
As previously suggested, the preferred solution would be for CT to provide a
user option for radio 2 band data on LPT1 pins 3,4,5, and 6. Nevertheless,
having recently completed the prototype of a new contest station switching
system, I reached the stage where I needed to get band data for both radios
on LPT1.
I am pleased to share this solution with the contest community.
The solution has two parts: (1) a software bios utility which is run before
CT is started; and (2) hardware logic which reads the status of pin 14 to
distinguish which peripherals get the change of band data.
1. Software
The software bios utility lets CT think that the PC has both LPT1 and LPT2.
The utility makes the address for LPT2 point to the same address as LPT1.
Thus, when CT writes band data to either LPT1 or the notional LPT2, the
information appears at the actual LPT1.
2. Hardware
The hardware logic decides where the change of band data is to be applied.
For example: to the filter set on radio 1, or to the filter set on radio 2.
The status of pin 14 (high for radio 1, and low for radio 2) is used to make
the
distinction.
The hardware involves some additional complexity to overcome a small
quirk in the behaviour of information on pin 14.
Given that pin 14 is dedicated to the selection of radio 1 or radio 2, I was
not expecting the status of pin 14 to change while CT was implementing a
band change. However, the status of pin 14 does change for a short moment
every time a band change is implemented. This pin 14 'drop out' is a bit of
a nuisance because it complicates the hardware design.
The pin 14 'drop out' may be caused by DOS. This could be the case if the
DOS Print service routine is being used. The DOS routine always forces an
auto feed on pin 14, and I am not aware of any way of turning off the auto
feed. Writing directly to the port without using the DOS service routine
would be one way of avoiding the auto feed on pin 14. I have done this
successfully with my own software. However, it involves bit more work.
On the other hand, perhaps the CT software is activating the pin 14 'drop
out' for some purpose.
Anyhow, I have managed a way around the pin 14 'drop out'. But before I
commit myself, and others, to additional hardware complexity I would greatly
appreciate any comments or advice.
Should I proceed on the basis that the pin 14 'drop out' remains
unavoidable?
or should I wait for further advice on either of two approaches?
(1) the possibility of a simple fix of the pin 14 drop out; or
(2) a decision to provide a CT user option for radio 2 band data on LPT1
pins 3,4,5,and 6.
If approach 2 is on the horizon, then I don't mind that my patch software
and hardware solution will become redundant. Clearly, approach 2 would be
preferred by all CT users wanting to switch peripherals for 2 radios from a
lap top with only 1 printer port. Perhaps Band data for both radios could be
provided on LPT1 by default, if the user does not select a DVK for LPT1.
However, I recognise that this approach would mean more programming work in
CT.
Ken, your good advice and any comments from CT users would be greatly
appreciated.
Regards,
John Loftus
VK4EMM
--
Submissions: ct-user@contesting.com
Administrative requests: ct-user-REQUEST@contesting.com
WWW: http://www.contesting.com/ct/
Questions: owner-ct-user@contesting.com
|