[DXLog.net - Support] Some notes after CQ WW RTTY

[9A5K]

Hi everyone.

I am still recovering from CQ WW RTTY 9A0Z at 9A5K M/S operation here.
We used 2 stations (RUN+MULT) with 2 PC's, running DXL version 2.1.8 from
devtest.
Both stations were running dual decoders (MMTTY + 2Tone)..
The idea was to involve more younger hams here, and to test DXL in bigger
contest.

Just couple of quick answers...

Spots disappearing problem..  Spot from DXAnn window as well as bandmap
windows are deleted mostly in three cases:
1. When spot time is older then minutes number defined in bandmap
properties window (by default it's 30 minutes)
2. When callsign is spotted at different frequency on same band
3. When another callsign is spotted at same frequency.

In third case, same frequency is calculated based on mode bandwidth also in
bandmap properties window. For RTTY, this is
1000 Hz by default (which is probably too wide).. I've changed it during
the contest at 200 Hz...
So, if station is spotted at some frequency, all spots +/- half of defined
mode bandwidth are deleted. So, in this case if station
is spotted at for example 21080.0 , all previous spots between 21079.5 and
21080.5 (+/- 500 Hz) are deleted...
This is very often the case when you're using skimmer spots and I suppose
this was the reason why spots disappeared.

Regarding INS key and grabbing the callsign..
By default, INS key grab last highlighted callsign from primary decoder
window if callsign field is empty.
In the case when highlighted callsign is wrong and you correct it  or enter
it manually in callsign field, it's by design that callsign
isn't grabbed from decoder window. In case you have to repeat the report,
this is a problem, because it will grab last one from
decoder window. This can be avoid by pressing F2 key instead of INS key,
which will send report only, without $LOGGEDCALL macro.
Own callsign is sent in such cases because it is highlighted too, and this
should be changed in the code, so we wouldn't highlight our
own callsign anymore.

F1 autorepeat.. I agree, this will be disabled when mode is S&P..

By the way, it's possible to use autoswitching between run/s&p, so it's
easier than changing it manually with CTRL+TAB..

Problem with filling state field.. yep, this happens because clicking in
decoder window(s) triggers the method to fill received data in
qso line. If clicked data is highlighted, it will move data in callsign
field. If not, it is looking for first field where data can be filled in.
In this case, first field is numeric only, and if there are any non numeric
characters found, it will try to move it to another field.
This is the place where we have to check if this data will be ok against
other controls defined for such field, in this case if it is a
state/province..
If not, it shouldn't be moved in the field. This caused a problem with $CR
macro, which execute ENTER key command, and trying to
save the qso.
Obviously, it's not allowed when some data is wrong, for example if invalid
state/province is entered in state field. etc...

Terminator map has inverse colors. I confirm this one.. Probably it's
broken in some of last versions, will be fixed ASAP.

ALT+K and keyboard sending will be checked. Probably, button at decoder
window isn't sending right command to the window.
Also, for some reason, I've noticed that ALT+K mode sends data to MMTTY too
slowly.. This needs to be checked once again.

Once again, thanks for all comments.
I will try to check once again if I've missed some of them. In meantime,
already working to fix this problems mentioned above.

73,
Chris - 9A5K



On Tue, Sep 30, 2014 at 12:26 AM, Dave Zeph <zephd at indy.rr.com> wrote:

>
> I used 2.1.8 DEV, Unassisted, only in RUN Mode, and with both MMTTY and
> 2TONE.  So I can't comment on problems with Spots.  But let me be the 4th
> to
> have experienced problem 2) described by Sergei.
>
> This ersatz data would sometimes be a single letter, but sometimes a call
> from the Receive Window(s).  This would happen before a CALL was typed, and
> was not overridden by the STATE lookup from the Call History Database.
>
> Sometimes I would not notice it had occurred until there was a problem
> entering the next call.  This was because DXLog would not execute the
> embedded $CR to enter the QSO with an invalid STATE Field.
>
> Or I found I had inadvertently overtyped the CALL of the previous QSO.  I
> didn't want to use F11 to WIPE the previous QSO, so I'd move the cursor and
> use the SPACE bar to clear the "crud" and cycle the SPACE Bar to get STATE
> lookup from the Call History Database.
>
> Another problem that occurred too often was when I'd do S&P in RUN Mode.
> The messages are much the same and it was easier to not have to use
> CTRL-TAB
> to switch back and forth.  I'd press ENTER to log the QSO but occasionally
> the station would ask for a repeat of his report.  So my cursor would be in
> the CALL Field of the new QSO Line and I'd press the INSert Key to resend
> the Report.  Sometime my call would suddenly appear in the CALL field of
> the
> new line and my Report would be sent to my call rather than the call of the
> station I'd just worked.  I wish I could describe what happens and in what
> sequence but it would just "happen" at inconvenient times!
>
> A couple of cases DXLog would not "forget" when QSO Data was entered, but
> not logged with an <ENTER> or $CR.  It only happened a couple of times, so
> I
> can't describe how to repeat the glitch.  The only way to get rid of the
> line of QSO Data was to overtype the call with my call and log the "QSO" or
> to exit and then restart DXLog.
>
> I SHOULD NOT HAVE to also enter my STATE - or ANY OTHER FIELD - when I have
> to nullify a QSO by typing my call,.  Entering one's own call is All that
> should be necessary.  Now DXLog requires these field to be filled before
> the
> nullified QSO is logged.
>
> Also I second Fabio's entire comments about ALT-K.  I sensed that stuff I
> tried to send manually (often a repeat of my State) was not being
> transmitted.  Now that I think of it, typing ALT-K would not always result
> in sending of Diddles.  And it would be helpful to automate the Manual Send
> and then close the Window.   The operator would know when the "send" was
> complete.
>
> Finally I second John's observation that MMTTY's ALT-K Button does not
> function - and least not when run under DXLog.
>
>
>
> ---- Dave
>
>
>
>
>
> -----Original Message-----
> From: support-bounces at dxlog.net [mailto:support-bounces at dxlog.net] On
> Behalf
> Of Sergey Dvadnenko
> Sent: Monday, 29 September, 2014 7:32
> To: DXLog.net Reflector
> Subject: [DXLog.net - Support] Some notes after CQ WW RTTY
>
>
> Hi group!
> I used ver 2.1.7
>
> Problems that have been seen in the last CQ WW:
>
> 1) Spots disappeared from the dx-announcements window Their life was just a
> few seconds.
> 2) When clicking mouse to text in the receiving windows which is not
> contain
> the callsing it always paste the    text to the STATE field. Why if
> callsign
> field is still clear?
> 3) Toward the end of the contest after the transmiting of macro ( for ex
> F1)
> trcvr did not go to the reception mode.
> Sergey UA6AA
> _______________________________________________
> Support mailing list
> Support at dxlog.net
> http://www.dxlog.net/mailman/listinfo/support
>
> _______________________________________________
> Support mailing list
> Support at dxlog.net
> http://www.dxlog.net/mailman/listinfo/support
>