Dave, in my estimation, the delay times you are talking about adding are
miniscule compared to the problem. I'm guessing that the PTT delay is
close to 50 ms: it buries a whole dot at about 30 wpm. Someone needs to
take a scope and look at the actual timing between the CW and PTT lines to
make sure that it is a problem with the radio and not the computer software
or the interface. If there is a big delay on the MP then maybe we need to
approach Yaesu for a fix.
On the VHF delay, the only way to do that properly is through the use of a
keyed sequencer. Ie., PTT from NA, DVP, etc. keys the sequencer, which
keys everything else before finally keying the IF radio. You could build
in a big delay time for the CW generation vs PTT if you like. That would
have to be widely adjustable to suit the hardware and using the paddle
would be out without using a footswitch, as up to a 1/2 second delay is
common.
As one of those that hates to give up SO2R with 2 computers, I would
suggest a couple of solutions. First there is the tried and true relay
interlock scheme which just routes the PTT throught a relay driven by the
other radio. This doesnt allow any "smart" operation of NA, but it does
keep the two from being on the air at the same time. The more elegant
solution would solve the problem by providing an "Inhibit" input on the LPT
port. Use the PTT output on the LPT of each computer to signal the
"Inhibit" input on the others LPT port. Perhaps you could also add a line
to signal the other computer to send a CQ, like the single computer system
can accomplish now. Doing it all via the LPT is the way to go.
I'd still like to see you set up number sequencing across the network for
things like WPX. WF1B has accomplished this with his RTTY software by
sending it across the network when the F2 (exchange) message is sent. It
works FB and minimizes the number of sequence busts as well as virtually
eliminating duplicate and skipped numbers in the log.
73, Ty K3MM
dap14@daimlerchrysler.com on 02/03/99 01:46:17 PM
Please respond to dap14@daimlerchrysler.com
To: na-user@contesting.com
cc: (bcc: Tyler G Stewart/BENN/CEC)
Subject: [na-user] CW PTT/FT1000MP, ARRL DX, Software Lockout
Comments on recent discussions:
CW PTT/FT1000MP
Tim, K9TM may be onto something with his "propogation delay suggestion" as
a
short term fix to the CW PTT condition affecting FT1000MPs. Perhaps a
small
capacitor from the base of the CW keying transistor to ground might
introduce
enough delay to satisfy the radio. On the leading edge of the CW signal,
this
capacitor will slow down the rise time of the voltage waveform which turns
on
the transistor on. On the trailing edge, the capacitor will hold the
transistor
"on" for a small additional time. While these delays might not be exactly
equal, the differences might not be noticable if the capacitor is small.
As a starting point, consider that the "on" time for a dot at 44 WPM is
approximately 27 mS. As a (very) rough guess it would not seem to be too
hard
to introduce 2 mS of delay which might make the radio happy and not affect
the
CW timing enough to be noticable. With a 1K base resistor, a 2.2uF
capacitor
would be a good starting point. I would suggest starting a capacitor that
is
MUCH too large (say 100uf) and the CW keying set slow (maybe 20 WPM) and
verify
that the delay fixes the problem. Then I would back off the value of the
capacitor while increasing the CW speed until satisfactory performance
results.
I realize this is a pain in the butt as a short term fix. However, I DO
plan to
implement an adjustable CW turn-on delay interval. In addition to 1000MP
users,
the VHF boys with their transverters, mast-mounted preamps, and keying
sequencers need the capability to introduce a delay. TRLog allows the user
to
adjust this delay time with an actual resolution of approximately 1.6 mS.
We'll
do something similar, and tie it to actual time, not the CW bit rate.
ARRL DX
We are aware of this bug and plan to have it fixed this week prior to my
business trip to Germany. An unfinished 10.36 has been on my computer for
a
month, but there in addition to the ARRL DX fix there is some other stuff
that
needs to be finished as well before it can go into the user's hands. If we
get
it out this week we'll have two weeks to beat on it prior to ARRL DX CW.
10.36 will have the W9XT Contest Card mixed-mode fix (phone memories are
not
accidentally erased on CW), ARRL DX CW fixed, and a couple other things.
One
feature that I'd like to get done before ARRL DX CW is N5TJ's suggestion of
separate CW sidetones for paddle and message-sent CW (a useful separation
for
SO2R). Some of the logistics to do this (separate on/off bits for each
type of
sidetone) has been done. Sounds like a project for the long plane
flight(s) to
and from Germany. (Now where is my laptop...)
SOFTWARE LOCKOUT
I'd like to understand exactly what people want from this software lockout
feature. What it SOUNDS like is that people want to do SO2R like NA & TR
do it,
but across two computers. Why? I think I know the answer - people want a
dedicated screen for each radio. While this can be done, it WILL have
issues.
K9TM and I brainstormed this a little today and we can see a number of
difficulties. First, if you want to "really" ensure that only one computer
transmits, then any given computer must go out onto the network and "ask
permission" before it starts. What W4AN proposed was a simpler "inhibit",
which
to me assumes some sort of "master-slave" relationship. Second, in the
example
W4AN gave the F4 key is pressed on the #2 computer which waits until #1 is
done.
If you're CQing on #1 it may be several seconds before your call is dumped
on #2
and the station my be doing something else already. I think this is rude.
Doing this type of control across a serial data connection introduces an
entire
series of problems that go away when its all in one computer. It has
always
been my objective to be able to support many different ways of configuring
and
using NA, but there is a limit to the amount of time I can devote to coding
these days. Is this valuable enough to justify the work? What other new
features are you willing to give up?
73,
Dave/K8CC
--
Submissions: na-user@contesting.com
Administrative requests: na-user-REQUEST@contesting.com
WWW: http://www.contesting.com/datom/
Questions: owner-na-user@contesting.com
--
Submissions: na-user@contesting.com
Administrative requests: na-user-REQUEST@contesting.com
WWW: http://www.contesting.com/datom/
Questions: owner-na-user@contesting.com
|