[na-user] CW PTT/FT1000MP, ARRL DX, Software Lockout
Wed, 3 Feb 1999 13:46:17 -0500
Comments on recent discussions:
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.
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...)
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?
Administrative requests: na-user-REQUEST@contesting.com