[wsjt-devel] WSJT-X 2.7.0-rc2imp: TIME_ON = TIME_OFF when I am the called station #adif #IssueReport

[Frode Igland via wsjt-devel]

Using WSJT-X 2.7.0-rc2imp I experience this as a new "feature":

When a counterpart responds to my CQ, or he/she tailends a QSO I am
finishing, both start time and end time are logged with TIME_OFF only, i.e
a duration of 0 seconds.

However, when I respond to stations calling CQ, or I tail-end a QSO,
TIME_ON and TIME_OFF are logged correctly. TIME_ON is logged when I start
the Tx 1 message that my counterpart responds to, and TIME_OFF is logged at
the start of my RR73 (Tx 4) message. Such a QSO is logged with a duration
of 1 minute.

 This corresponds to "normal" time logging when I am calling other
stations, but changes to "contest" time logging when I am being called
(TIME_OFF only). I want my QSOs to be logged with the correct QSO start
time (TIME_ON) and QSO end time. I see no reason for having different
logging practices depending on who is the caller in the QSO, so I tend to
see this as a bug that should be looked into.

73, Frode LA6VQ


Virusfri.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJTX Cabrillo log time

[Frode Igland via wsjt-devel]

Regarding logged time in cabrillo. Let's reason backwards:
1. Cabrillo is a file format used for submitting contest logs only.
2. Cabrillo is a file format normally created from an ADIF file that is
created by specialized logging software, say N1MM Logger+, WinTest or some
other contest software.
3. Logging softwares have no idea of when a QSO starts, because the only
input they receive is when the logging of a QSO takes place, i.e. not until
the contester finds the QSO to be complete, which is another way to say
that logging takes place at TIME-OFF.
4. Matching of contest QSOs takes place if the time difference between the
two involved logs are less than a specified time difference, which at least
in the major contests is five minutes.
5. So, if you want to submit a cabrillo contest log, you should certainly
make sure that the cabrillo file is created using TIME_OFF, no matter which
software (contest software or not) you have used to log the QSOs during the
contest. That also applies to using WSJTX_LOG.ADI as the ADIF contest log.
6. The time difference of 30 minutes allowed for QSO matching in LoTW
obviously is not relevant for the time logged in the cabrillo log. They
have two very different purposes, and LoTW has no bearing whatsoever of
what a contest sponsor will accept.
7. Based on the above, starting from the origin and purpose of a cabrillo
file, there is no reason to consider any other time than TIME_OFF for the
cabrillo log.

73, Frode LA6VQ (LC6C in contest)


Virusfri.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

lør. 13. mai 2023 kl. 07:06 skrev Reino Talarmo via wsjt-devel <
wsjt-devel@lists.sourceforge.net>:

> Hi Saku
>
> Some comments in-line. A bit long email, sri. It's time for the new
> candidate release discussion.
>
> 73, Reino OH3mA
>
> > From: Saku via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net]
> > Sent: perjantai 12. toukokuuta 2023 21.22
>
> > if you calling CQ (TX1) and someone(s) answer to it qso starts from
> point you start first TX2 transmission (to any of answering stations).
> >It is very clear. There is no exchange happened yet, and your TX2 will
> start the exchange chain (= qso).
> > Same if you try to answer someones CQ. Once he sends first TX2 qso
> begins.
>
> Reino: LoTW states that "both QSO descriptions specify start times within
> 30 minutes of each other". So in that sense start time gets one plus point.
>
> > In case of missed TX2 receive you will get different start time than the
> opponent, that is true. However the base of qso starting definition is
> clear.
>
> Reino: That issue is a real challenge especially on pile-up situations.
> You may need to send your Tx2 even hours e.g. as a Hound, before the Fox
> picks your call into the QSO list (= potential earliest start time on the
> Fox point of view). Even the so started QSO may fail and Fox never sends
> RR73 to you. Now would it be a new QSO start, if you send even once again
> Tx2?
>
> > End time of qso is more or less unclear. It is clear (by rules) when
> both sides have exchanged reports and got confirmation to them.
> > You get confirmation with report as "R-xx" and you confirm it by sending
> "RRR" or "RR73".
>
> Reino: That is recommended in the User Guide with a potential need for a
> resending RR73 or RRR due to a repeated "R-xx". To me that is a clear point
> of time as the operator feels the QSO is completed, he has sent RR73 (RRR)
> or received RR73 or 73 and no more a reception of "R-xx". User may need to
> correct the proposed end time in that case.
>
> > What I mean "unclear" is that someone requires 73 after RRR or RR73 to
> see the qso complete, someone else do not.
> > There has been lot of conversation about this in past and I do not want
> to make another "split argue" with this.
>
> Reino: Fully agree that there are at least two strong opinions on that and
> absolutely no need to restart any discussion on that issue. As an example
> is DXpedition mode, where Fox simply logs QSO at the sending the RR73.
> There is simply no action defined in that protocol for a reception of 73.
> For that reason there are dupes, but who cares. The same applies to some
> contests, where the sending of the 73 is not defined or stated optional. If
> there is a disagreement between operators, then simply there is no QSO (a
> NIL). That's a different issue, isn't it.
>
> Reino: My comment is also "what about interleaved QSOs or QSO attempts?".
> Well, normally QSO order in a log does not matter. BUT for a program that
> generates some challenges. E.g. how may QSO attempts (sending the first
> Tx2) it needs to remember?
>
> > My 5 cents is that qso start time is easier to define so that all can
> agree with definition and should be used with Cabrillo, like it is used
> with CW and phone, too.
> 

Re: [wsjt-devel] 3Y0J F/H operation - highlight Fox messages

[Frode Igland via wsjt-devel]

Forgive me for asking, but why would you need to highlight Fox messages in
addition to the easily observable characteristics of Fox/Hound mode?
As this is the WSJT-X dev forum, I assume that you are talking about the
WSJT-X software and "real" Fox/Hound, not any multi-stream operation. When
you are looking for a Fox, you hopefully know the call sign of the Fox
(otherwise you have no idea who to call or who to look for, in which case
the Fox will be of no interest). A Fox never operates on the standard FT8
frequencies, and will normally be alone calling on Even periods.i.e 00/30
seconds (with the exception of the most regrettable practices of those
using the clones, allowing TX in any period), and in the 300-600 Hz audio
frequency range. So by these few characteristics you already know who the
Fox is and you cannot miss any Fox transmission that you decode. In the
rare case where two Foxes may be operating on the same (non-standard)
frequency, they will again be easily identified by being the only ones
transmitting on 00/30 seconds.

The 3Y0J expedition's unfortunate time offset of 14 seconds without
synchronization was most unfortunate, but this is very rare. With 14
seconds off, they were inside the margin for the following odd period, and
sending Fox transmission to be decoded in the wrong  period, causing
substantial confusion. If it had been 5 or 10 seconds, the lack of sync
would have been discovered much earlier, as the waterfall would have
revealed the non-synced signal and no-one with synced computers would have
been able to make contact. Most DX-peditions knowing that they are going
off internet coverage will carry a dongle or some other receiver of GPS
time to secure good synchronization for FT8 and the other WSJT-X modes. I
don't know if 3Y0J brought a GPS dongle or used other measures to sync, but
they eventually got it right and were reasonably easy to work, save for all
the DQRM-ers in need of heavy psychiatry.

A comment to cluster information: Almost since the first clone started to
offer multi-stream capability, the clusters have been full of incorrect
messages, based on the flawed assumption by the spotters who never read, or
failed to understand, the Fox/Hound manual that any multi-stream signal is
a Fox/Hound operation. Cluster information about F/H operation in standard
FT8 frequencies or at Fox audio frequencies above 1000 Hz or  transmitting
in odd (15/45 seconds) periods can and should be ignored. By all means work
the multi-streaming stations, but then use standard mode, as Fox/Hound mode
will not bring a contact. For DX-peditions it is way more important to read
their plan for operations, modes and frequencies, than to trust cluster
information from spotters who don't understand the characteristics of the
Fox/Hound mode.

73, Frode LA6VQ

fre. 17. feb. 2023 kl. 15:23 skrev Erik Icket via wsjt-devel <
wsjt-devel@lists.sourceforge.net>:

> Hi dear developers,
>
> I believe the 3Y0J expedition learned us a lot about correct F/H practices
> and at the same time, pushed the protocol to its limits.
>
> There is however one situation which occurred in the early hours of the
> expedition where unsolvable confusion reigned : "Was the expedition using
> the true WSJTX F/H protocol or was is multi-stream from a WSJTX clone" ?
> This was compounded with contradicting messages on the DX cluster, which
> did
> not contribute either. Unfortunately, it is not the first expedition where
> this occurred ..
>
> Can I therefore resuscitate (or discuss) an earlier request for an option
> to
> highlight Fox messages (i.e. Type 0.1 protocol messages) ?
> I think the color highlighting of Fox messages will not compete with other
> highlighting criteria, because it is the most important thing we are after.
>
> My apologies if I missed something out or there are better ways to find out
> !
>
> 73's Erik
> ON4PB
>
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] UDP Status message defect. WD status not set when in Hound mode.

[Frode Igland via wsjt-devel]

I have nothing against getting WD reporting in the UDP Status message, but
I guess the most important part of the WD in Hound mode is that the "Enable
Tx" button is deactivated, and that the operator must be able to maintain
an attention span of two minutes to reactivate the "Enable Tx" button. That
should be doable without UDP messaging.

Frode

ons. 18. jan. 2023 kl. 17:18 skrev Laurie, VK3AMA via wsjt-devel <
wsjt-devel@lists.sourceforge.net>:

>
>
> On 19/01/2023 1:45 am, Frode Igland wrote:
> > this tells that the WD timer in Hound mode is deliberately hardcoded
> > and non-editable
>
> I am not asking that the Hound mode WD timer be editable. I am fine with
> it being fixed. I fully support that design.
>
> The problem (defect) is that the status of the WD is not being reported
> in the UDP Status message. That is, when the Hound WD is triggered it is
> not setting the WD flag in the status message.
>
> de Laurie VK3AMA
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] UDP Status message defect. WD status not set when in Hound mode.

[Frode Igland via wsjt-devel]

The User Manual for FT8 DX-pedition mode, "Detailed Instruction for Hounds"
# 11 at the top of page 5, says:

> You will need to re-activate Enable Tx (or hit
> Enter on the keyboard) at least once every two minutes. (This restriction
> is to
> ensure that an operator is present and paying attention.)
>

I believe this tells that the WD timer in Hound mode is deliberately
hardcoded and non-editable, and gives an excellent reason why, just like
you have to actually be on the mike or the key to be able to make a call in
an SSB or CW pile-up.

73, Frode LA6VQ

ons. 18. jan. 2023 kl. 01:16 skrev Laurie, VK3AMA via wsjt-devel <
wsjt-devel@lists.sourceforge.net>:

> On 18/01/2023 8:41 am, Ton PA0TBR wrote:
>
> The desired operation would be that the TX watchdog setting is also used
> for Hound mode.
>
> 73,
> Ton PA0TBR
>
>
> That's correct. I neglected to say that in my original fault report.
> The Tx Watchdog being triggered in Hound mode should be setting the
> relevant flag in the UDP Status message (#1)
>
> de Laurie VK3AMA
> (JTAlert author)
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Missing input sanitation for TX_PWR field in ADIF log

[Frode Igland via wsjt-devel]

Roman,
I see your point. Since the power data is manually input in the logging
window, I guess that the check for "numbers only" in the "Tx Power" field
must be made in the  logging window, before the "OK" is accepted. However,
I don't know if this check can be easily implemented. In the meanwhile, be
disciplined and use numbers only.  

73, Frode LA6VQ

ons. 19. okt. 2022 kl. 22:08 skrev cirnod via wsjt-devel <
wsjt-devel@lists.sourceforge.net>:

> Hi Frode
>
> I agree with you that in practice many applications are tolerant and read
> non-compliant ADIF files without errors. However, my report was actually
> triggered by a practical problem. Concretely, I tried to read the ADIF file
> created by WSJT-X using the Python library "hamutils". This did not work
> and resulted in errors. Upon further investigation, I realized that (in
> certain cases) WSJT-X strictly speaking generates ADIF files that do not
> conform to the specifications. After manually correcting the values of the
> tx_pwr fields in the ADIF file, the processing using the "hamutils" library
> works without issues. To permanently fix this issue and prevent further
> similar problems in combination with other software I would therefore
> welcome it if the WSJT-X software could be adapted such that the generated
> ADIF file always complies with the specifications.
>
> Regards
> Roman HB9HDN
>
>
> On 19.10.22 15:05, Frode Igland via wsjt-devel wrote:
>
> Hi, Roman.
> My experience is that the ADIF format accepts more than the ADIF
> specifications may indicate. I have used the "Tx power" field in the WSJT-X
> logging window for most of my tens of thousands of WSJT-X QSOs. Whether I
> enter "40 W", "40W" or "40", it hits my HRD Logbook as "40", i.e. a clean
> number. Apparently, the ADIF protocol is smart enough to find and
> understand the numbers, leaving out the letters. However, that also means
> that "1kW" or "1 kW" is transferred as "1". In the practical world, this
> may be a smaller problem for WSJT-X, as I cannot see any good reason to use
> 1kW for the common WSJT-X modes, except for EME QSOs. EME operators will
> soon enough understand that they didn't make a QSO with 1 W, and should be
> able to edit the Tx Power in their logging software. Human interaction and
> thoughtful discretion is still a good value in ham radio. 
>
> I guess the issue may be solved practically by changing the field title in
> the logging window from "Tx power" to "Tx power (W)" or "Tx power (watt)",
> or possibly, like you suggest, make a tooltip reminding the operator that a
> watt *number* is expected, however, I don't know if the logging window is
> open for tooltips, as there are none yet.
>
> 73, Frode LA6VQ
>
> ons. 19. okt. 2022 kl. 00:53 skrev cirnod via wsjt-devel <
> wsjt-devel@lists.sourceforge.net>:
>
>> Hi
>>
>> I would like to report an issue with the ADIF log
>> created by WSJT-X. I'm currently using v2.5.4 on
>> macOS 12.6.
>>
>> WSJT-X offers to log QSOs by filling in a form
>> prompt. One of the fields of the form allows to
>> log the "Tx power". Apparently, the form accepts
>> any text string entered into this field.
>> Furthermore, the unmodified text string is used to
>> create the ADIF log of WSJT-X. This behavior
>> potentially leads to invalid ADIF files as they do
>> not conform with the ADIF specifications [1]. For
>> example a user could enter "10W" or "1kW".
>> According to the specifications, the "TX_PWR"
>> field should contain "the logging station's power
>> in Watts with a value greater than 0". In
>> addition, the data type of this ADIF field is
>> "Number", i.e. "a sequence of one or more Digits
>> representing a decimal number, optionally preceded
>> by a minus sign (ASCII code 45) and optionally
>> including a single decimal point  (ASCII  code 46) ".
>>
>> I see the following points that could help fixing
>> the mentioned issue:
>> * Adding tooltip/instructions for the user to
>> clarify what data type and value (in what units)
>> should be entered in the "Tx power" field.
>> * User input sanitation either for the "Tx power"
>> field of the QSO log form prompt or before writing
>> the value entered by the user to the ADIF log
>> file. One option would be to rejecting the
>> submission of the form and informing the user in
>> case a wrong data type has been entered.
>>
>

Re: [wsjt-devel] Missing input sanitation for TX_PWR field in ADIF log

[Frode Igland via wsjt-devel]

Laurie,
Yes, I use JTAlert, but not for logging. The logging data are sent directly
from WSJT-X to HRD Logbook, which apparently does the same alpha character
stripping as JTAlert. On the next session start, I let JTAlert scan the
database, to have the alerts working properly.

(Outside Roman's subject:
Generally, I let the various applications (JTAlert, GridTracker, etc.)
receive their input data from the one and only original source, i.e.
WSJT-X. I am aware of the automation opportunities in JTAlert and
GridTracker and that many users let data go from one application to the
next (including their logbooks), and then to upload to eQSL, QRZ.com
Logbook and other web databases. My hard earned experience is that letting
data pass  through several "processing plants" on the way to my logbook,
introduces multiple sources of process errors. So, having spent countless
hours tracing and understanding errors, I like to keep things as simple,
understandable and controllable as possible. Uploads to QSO/QSL databases
on the Internet (LoTW, eQSL, etc) I always do manually, as I work from
various IOTA and non-IOTA locators with two call signs (standard and
contest). I upload standard QSOs during or after the operating session,
whilst contest QSOs have to wait past the log submission deadline, except
for LoTW, which is a double blind matching database. With HRD Logbook
uploads are simple and fast (seconds), and I have full control of the data
I upload.)

73,  Frode LA6VQ

tor. 20. okt. 2022 kl. 00:25 skrev Laurie, VK3AMA via wsjt-devel <
wsjt-devel@lists.sourceforge.net>:

>
>
> On 20/10/2022 12:05 am, Frode Igland via wsjt-devel wrote:
> > I have used the "Tx power" field in the WSJT-X logging window for most
> > of my tens of thousands of WSJT-X QSOs. Whether I enter "40 W", "40W"
> > or "40", it hits my HRD Logbook as "40
>
> Frode,
>
> I recall that you are using JTAlert, is that correct? JTAlert is
> stripping the non-numeric characters from the power field before sending
> it to HRDLogbook. No attempt is made to decipher the meaning of the
> alpha character, they are simply stripped.
>
> de Laurie VK3AMA
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Missing input sanitation for TX_PWR field in ADIF log

[Frode Igland via wsjt-devel]

Hi, Roman.
My experience is that the ADIF format accepts more than the ADIF
specifications may indicate. I have used the "Tx power" field in the WSJT-X
logging window for most of my tens of thousands of WSJT-X QSOs. Whether I
enter "40 W", "40W" or "40", it hits my HRD Logbook as "40", i.e. a clean
number. Apparently, the ADIF protocol is smart enough to find and
understand the numbers, leaving out the letters. However, that also means
that "1kW" or "1 kW" is transferred as "1". In the practical world, this
may be a smaller problem for WSJT-X, as I cannot see any good reason to use
1kW for the common WSJT-X modes, except for EME QSOs. EME operators will
soon enough understand that they didn't make a QSO with 1 W, and should be
able to edit the Tx Power in their logging software. Human interaction and
thoughtful discretion is still a good value in ham radio. 

I guess the issue may be solved practically by changing the field title in
the logging window from "Tx power" to "Tx power (W)" or "Tx power (watt)",
or possibly, like you suggest, make a tooltip reminding the operator that a
watt *number* is expected, however, I don't know if the logging window is
open for tooltips, as there are none yet.

73, Frode LA6VQ

ons. 19. okt. 2022 kl. 00:53 skrev cirnod via wsjt-devel <
wsjt-devel@lists.sourceforge.net>:

> Hi
>
> I would like to report an issue with the ADIF log
> created by WSJT-X. I'm currently using v2.5.4 on
> macOS 12.6.
>
> WSJT-X offers to log QSOs by filling in a form
> prompt. One of the fields of the form allows to
> log the "Tx power". Apparently, the form accepts
> any text string entered into this field.
> Furthermore, the unmodified text string is used to
> create the ADIF log of WSJT-X. This behavior
> potentially leads to invalid ADIF files as they do
> not conform with the ADIF specifications [1]. For
> example a user could enter "10W" or "1kW".
> According to the specifications, the "TX_PWR"
> field should contain "the logging station's power
> in Watts with a value greater than 0". In
> addition, the data type of this ADIF field is
> "Number", i.e. "a sequence of one or more Digits
> representing a decimal number, optionally preceded
> by a minus sign (ASCII code 45) and optionally
> including a single decimal point  (ASCII  code 46) ".
>
> I see the following points that could help fixing
> the mentioned issue:
> * Adding tooltip/instructions for the user to
> clarify what data type and value (in what units)
> should be entered in the "Tx power" field.
> * User input sanitation either for the "Tx power"
> field of the QSO log form prompt or before writing
> the value entered by the user to the ADIF log
> file. One option would be to rejecting the
> submission of the form and informing the user in
> case a wrong data type has been entered.
>
> Regards
> Roman HB9HDN
>
> [1]
> https://www.adif.org/313/ADIF_313.htm#QSO_Field_TX_PWR
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.6.0-rc4: Sudden shut-down, "CQ: Max Dist" doesn't work, "CQ: None" stops working

[Frode Igland via wsjt-devel]

Hi, Jarmo.
Does that mean that "CQ: Max Dist" is setup to work *only* with the ARRL
International Digital Contest?
Neither the Release Notes nor the -rc4 User Guide say anything about "CQ:
Max Dist", so it is  difficult to say. "CQ: Max Dist" looks like the FT8
version of the "Best S+P" functionality in FT4, which works also outside
contests, although FT4 was developed primarily for contesting. Then I find
it strange that similar functionality in the general usage FT8 mode should
work only in contest, and even only in one contest of the year.

The ARRL International Digital Contest  ran on 4-5 June 2022, whilst the
WSJT-X 2.6.0-rc1 introducing "CQ: Max Dist"  was published only on 20 June,
i.e. shortly after this year's contest. If your information is correct,  I
guess it will not be possible to test this functionality until next June.
Then it is strange that it was introduced almost a year before it was
needed or useful.

The hover-over help text reads "Max* Pts*", not "Max Dist", probably a
small typo.

73, Frode LA6VQ

tor. 13. okt. 2022 kl. 16:33 skrev jarmo via wsjt-devel <
wsjt-devel@lists.sourceforge.net>:

> Thu, 13 Oct 2022 08:34:37 -0400
> Dennis W1UE via wsjt-devel  kirjoitti:
>
> Problem2 in not a problem, hover mouse over text, you can see, that
> shoud wor with ARRL contest.
>
> jarmo, oh1mrr
> > I can also confirm problem #1.  It is the same problem that existed in
> > version 2.6.0 RC1,2,3 and 4.
> >
> > Since I use WSJT in combination with N1MM+ for logging, I get a "TCP
> > Error" when the program closes.
> > If I'm not using the combo, WSJT just closes.  I have not noticed
> > that the closing occurs when using
> > only FT8; it may also occur when using FT4, but there isn't enough
> > activity on FT4 to see if it happens.
> >
> > A couple of additional observations:
> > 1. At the suggestion of K1JT, I replaced the Hamlib dll of 2.6.0rc4
> > with the same dll from 2.5.4.  The closing
> > seemed to stop.  This only works if your rig is supported by the
> > earlier dll.
> > 2. A fresh install of 2.6.0rc4 will enable 20+ hours of operation
> > before it closes.  Once it starts closing, it will
> > continually do it.
> >
> > I have not seen the issues with "CQ MAX DIST".  Are you sure it's not
> > picking the correct call?
> > 1. Calls without a grid are never selected unless they are the only
> > reply to your CQ.
> > 2. Band/Mode dupes are given a score of zero and only selected if the
> > only caller.
> > 3. Call selection is based on the point score generated by the program
> > calculations; I know SP is further than
> > DL, but if they have the same point total and the DL is before the SP
> > in the decode window, the WSJT will
> > select the DL station to call.
> >
> > Dennis W1UE
> >
> >
> > On Thu, Oct 13, 2022 at 8:21 AM jan0--- via wsjt-devel <
> > wsjt-devel@lists.sourceforge.net> wrote:
> >
> > > I can confirm problem 1, as it happened to me less than an hour ago,
> > > including the orphaned JT9 decoding application.  Running Win 10 on
> > > a Lenovo X1 Carbon laptop.  I had been on FT8 for about an hour
> > > when it happened.
> > >
> > >
> > >
> > > Ed N4II.
> > >
> > >
> > >
> > > *From:* Frode Igland via wsjt-devel
> > >  *Sent:* Thursday, October 13,
> > > 2022 5:06 AM *To:* WSJT software development
> > >  *Cc:* Frode Igland
> > >  *Subject:* [wsjt-devel] WSJT-X 2.6.0-rc4:
> > > Sudden shut-down, "CQ: Max Dist" doesn't work, "CQ: None" stops
> > > working
> > >
> > >
> > >
> > > I have used -rc4 since it was released and have found it quite
> > > stable with three notable exceptions:
> > >
> > >
> > >
> > > *1. Sudden closing in FT8 after extended periods of operation*
> > >
> > > After an extended period of use in FT8 mode (normally more than two
> > > hours), WSJT-X may close down abruptly. The closing happens at the
> > > start of an FT8 sequence. I have never experienced closing on FT4,
> > > but then I have very rarely worked FT4 for extended periods. To
> > > start again, an orphaned JT9 decoding application first has to be
> > > terminated in the Task Manager. This issue started with WSJT-X
> > > 2.6.0-rc1 and still happens.
> > >
> > >
> > >
> > > *2. "CQ: Max Dist" doesn't work*
> > >
> > > After selecting 

Re: [wsjt-devel] WSJT-X 2.6.0-rc4: Sudden shut-down, "CQ: Max Dist" doesn't work, "CQ: None" stops working

[Frode Igland via wsjt-devel]

Hi, Dennis.

I will try the Hamlib dll from v2.5.4, a version where I had no problems
with sudden closing.

I cannot say whether the sudden closings apply to FT4, but I cannot
remember noticing the sudden closing in FT4, whilst it happens now and then
with FT8, as described.

Re the "CQ: Max Dist" issue: Working from Norway, I have observed a locator
from Germany being selected over a locator from the USA, with both stations
being new to me. I am aware that the callers with no locator is placed last
in the queue.

73, Frode LA6VQ

tor. 13. okt. 2022 kl. 14:39 skrev Dennis W1UE via wsjt-devel <
wsjt-devel@lists.sourceforge.net>:

> I can also confirm problem #1.  It is the same problem that existed in
> version 2.6.0 RC1,2,3 and 4.
>
> Since I use WSJT in combination with N1MM+ for logging, I get a "TCP
> Error" when the program closes.
> If I'm not using the combo, WSJT just closes.  I have not noticed that the
> closing occurs when using
> only FT8; it may also occur when using FT4, but there isn't enough
> activity on FT4 to see if it happens.
>
> A couple of additional observations:
> 1. At the suggestion of K1JT, I replaced the Hamlib dll of 2.6.0rc4 with
> the same dll from 2.5.4.  The closing
> seemed to stop.  This only works if your rig is supported by the earlier
> dll.
> 2. A fresh install of 2.6.0rc4 will enable 20+ hours of operation before
> it closes.  Once it starts closing, it will
> continually do it.
>
> I have not seen the issues with "CQ MAX DIST".  Are you sure it's not
> picking the correct call?
> 1. Calls without a grid are never selected unless they are the only reply
> to your CQ.
> 2. Band/Mode dupes are given a score of zero and only selected if the only
> caller.
> 3. Call selection is based on the point score generated by the program
> calculations; I know SP is further than
> DL, but if they have the same point total and the DL is before the SP in
> the decode window, the WSJT will
> select the DL station to call.
>
> Dennis W1UE
>
>
> On Thu, Oct 13, 2022 at 8:21 AM jan0--- via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>> I can confirm problem 1, as it happened to me less than an hour ago,
>> including the orphaned JT9 decoding application.  Running Win 10 on a
>> Lenovo X1 Carbon laptop.  I had been on FT8 for about an hour when it
>> happened.
>>
>>
>>
>> Ed N4II.
>>
>>
>>
>> *From:* Frode Igland via wsjt-devel 
>> *Sent:* Thursday, October 13, 2022 5:06 AM
>> *To:* WSJT software development 
>> *Cc:* Frode Igland 
>> *Subject:* [wsjt-devel] WSJT-X 2.6.0-rc4: Sudden shut-down, "CQ: Max
>> Dist" doesn't work, "CQ: None" stops working
>>
>>
>>
>> I have used -rc4 since it was released and have found it quite stable
>> with three notable exceptions:
>>
>>
>>
>> *1. Sudden closing in FT8 after extended periods of operation*
>>
>> After an extended period of use in FT8 mode (normally more than two
>> hours), WSJT-X may close down abruptly. The closing happens at the start of
>> an FT8 sequence. I have never experienced closing on FT4, but then I have
>> very rarely worked FT4 for extended periods. To start again, an orphaned
>> JT9 decoding application first has to be terminated in the Task Manager.
>> This issue started with WSJT-X 2.6.0-rc1 and still happens.
>>
>>
>>
>> *2. "CQ: Max Dist" doesn't work*
>>
>> After selecting "CQ: Max Dist", WSJT-X still selects the station first
>> decoded, notwithstanding the distance. It makes no difference whether "CQ:
>> Max Dist" is selected after "CQ: None" or "CQ: First" or if "CQ: Max Dist"
>> was selected on start-up before first CQ.
>>
>>
>>
>> *3. "CQ: None" stops working after a while*
>>
>> I often call CQ DX with the "CQ: None" setting, to be able to select
>> which DX station to work. This normally works well, but suddenly WSJT-X may
>> start answering the first station decoded automatically, without being
>> selected manually by me. Sometimes, reselecting "CQ: None" helps, and
>> sometimes I have to close and reopen WSJT-X and select "CQ: None" before
>> calling CQ.
>>
>>
>>
>> These are my experiences with WSJT-X 2.6.0-rc4.
>>
>>
>>
>> 73, Frode LA6VQ
>>
>>
>>
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJT-X 2.6.0-rc4: Sudden shut-down, "CQ: Max Dist" doesn't work, "CQ: None" stops working

[Frode Igland via wsjt-devel]

I have used -rc4 since it was released and have found it quite stable with
three notable exceptions:

*1. Sudden closing in FT8 after extended periods of operation*
After an extended period of use in FT8 mode (normally more than two hours),
WSJT-X may close down abruptly. The closing happens at the start of an FT8
sequence. I have never experienced closing on FT4, but then I have very
rarely worked FT4 for extended periods. To start again, an orphaned JT9
decoding application first has to be terminated in the Task Manager. This
issue started with WSJT-X 2.6.0-rc1 and still happens.

*2. "CQ: Max Dist" doesn't work*
After selecting "CQ: Max Dist", WSJT-X still selects the station first
decoded, notwithstanding the distance. It makes no difference whether "CQ:
Max Dist" is selected after "CQ: None" or "CQ: First" or if "CQ: Max Dist"
was selected on start-up before first CQ.

*3. "CQ: None" stops working after a while*
I often call CQ DX with the "CQ: None" setting, to be able to select which
DX station to work. This normally works well, but suddenly WSJT-X may start
answering the first station decoded automatically, without being selected
manually by me. Sometimes, reselecting "CQ: None" helps, and sometimes I
have to close and reopen WSJT-X and select "CQ: None" before calling CQ.

These are my experiences with WSJT-X 2.6.0-rc4.

73, Frode LA6VQ
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] WSJT-X 2.4.0 User Guide: Where to send translations? Proposals for corrections/updates.

[Frode Igland]

Thanks to the WSJT-X Development Team for WSJT-X 2.4.0.

*Where to send translations?*

I have downloaded and tried WSJT-X 2.4.0 as well as the User Guide. I have
also reviewed the WSJT-X 2.4.0 User Guide for translation and have
completed the Norwegian translation. Having submitted a number of
translations for v2.3 (GAs and release candidates), in accordance with the
User Guide section 1.4, without seeing them published, I wonder where to
send them for publication?

I don’t know if translations for other languages have not been forthcoming,
or if they just haven’t been published, but apparently, translations for
several languages have been lagging behind the version numbers.

*Proposals for corrections in WSJT-X 2.4.0. User Guide*

During my review, I have come across a few issues that requires the
attention of the editor of the User Guide. Some of these issues have been
reported previously, but apparently they have survived into the 2.4.0 GA
version.

*Section 3.1*

The links for *Win32 OpenSSL Light Package *and *Win64 OpenSSL Light
Package* are incorrect. They link to version 1_1_1j:
https://slproweb.com/download/Win32OpenSSL_Light-1_1_1j.msi  and
https://slproweb.com/download/Win64OpenSSL_Light-1_1_1j.msi

Version 1_1_1j is no longer available on the linked page.

The latest versions are 1_1_1k, and the correct links are
https://slproweb.com/download/Win32OpenSSL_Light-1_1_1k.msi  and
https://slproweb.com/download/Win64OpenSSL_Light-1_1_1k.msi



*Section 10.1.4 Mode menu*

The mode menu shown in the v2.4.0 User Manual is the mode menu from v2.3,
containing the now deprecated modes QRA64 and ISCAT.

In v2.4.0 theses two modes have been replaced by *Q65*. The mode menu
illustration needs updating.



*Section 10.1.9 Help menu*

The previous section *10.2 Button Row* has lost its numbering and the
previous section title has now been replaced by:

=== Button Row

// Status=edited



The *Button Row* obviously has no place under *Section 10.1.9 Help menu*,
and should have its number 10.2 reissued, requiring a renumbering of the
current sections 10.2 – 10.9 to 10.3 – 10.10.



*Section 14. Cooperating programs*

JTAlert has been updated to version *2.50.1*, with a considerable layout
makeover from v2.14.

It may be worthwhile to update the illustration.



*Section 16. Frequently Asked Questions*

Question #7.

*I am using WSJT-X with Ham Radio Deluxe. All seems well until I start HRD
Logbook or DM780 running in parallel; then CAT control becomes unreliable.*

You may see delays up to 20 seconds or so in frequency changes or other
radio commands, due to a bug in HRD. HRD folks are aware of the problem,
and are working to resolve it.

I am a Ham Radio Deluxe user myself, having never experienced any massive
delays, nor have I noticed any attention on this issue in the various user
forums. Consequently, I have contacted HRD Support regarding this
information. According to HRD Support the delays have nothing to do with
the HRD software, nor WSJT-X, and HRD developers are not working to solve
this issue. If this had been a problem, HRD Support would have had a large
number of support requests on this matter, and they don’t. The problem is
caused by operators trying to run a number of softwares on computers with
insufficient processing power.

According to HRD Support, the information in the preceding paragraph has
been conveyed to the WSJT-X Development team on a number of occasions,
aiming to correct the information in the User Guide, but it has been
impossible to have this corrected, so they have just given up. I promised
them to make another attempt.

Having spent considerable time translating the User Guide over the last
several years, as well as having made proposals for corrections (which have
been corrected), it is my firm belief and opinion that the WSJT-X User
Guide shall be accurate, reliable and up to date, like it is on the
workings of WSJT-X, and not convey incorrect information about other
softwares or other software suppliers.

Isn’t it time to correct this error, and delete this FAQ?



*Section 17.2.10 Summary*

*Table 7*

*Mode*

*FEC Type*

*(n,k)*

*Q*

*Modulation type*

*Keying rate (Baud)*

*Bandwidth (Hz)*

*Sync Energy*

*Tx Duration (s)*

*S/N Threshold (dB)*

*FST4-15*

LDPC

(240,101)

4

4-GFSK

16.67

67.7

0.25

9.6

-20.7



Assuming that Bandwidth equals (Keying Rate) × (number of tones/frequencies
in the Modulation Type), like it is for the other FST modes, I guess the
Bandwidth should amount to 16.67 × 4 = 66.7 Hz, not 67.7 Hz, or is there
something special about the bandwidth for the FST4-15 mode?

73, Frode LA6VQ
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-x Icom CI-V Issue?

[Frode Igland]

John,
As the change of mode happens on tune or transmit, have you checked for
RFI? I am not familiar with the IC-7300 settings, but  in a couple of
IC-7600 I have seen RFI change the of mode (e.g. from USB-D1 or USB to LSB)
when transmitting. Change of TX filter width has also happened
simultaneously with the mode changes, from the widest filter (3000 Hz) to
the narrowest (500 Hz). Reducing the TX power and adding ferrites took care
of it. Just a thought for your consideration.

The CI-V address difference between the Tarheel andthe IC-7300 is beyond
me, but in the IC-7600 "CI-V Transceive" control should be set to OFF, to
avoid CI-V and WSJT-X CAT control to fight for controlling the rig. I
assume it is the same for IC-7300.

73, Frode LA6VQ

man. 26. apr. 2021 kl. 00:20 skrev John Deegan :

> Good evening/morning Bill and thank you for your reply.
>
>
>
> I installed the json file in my log files directory, configured my IC-7300
> with CI-V address 70h, set IC-7300 as the rig in Settings>Radio and
> restarted WSJT-x V2.3.1. I was unable to get a “Green” on the CAT test in
> Settings>Radio.
>
>
>
> Changing the rig definition in WSJT-x 2.3.1 to IC-7000 with or without the
> json file allows me to get a “Green” on CAT and a “Red” on PTT, BUT ...
> when either the Test PTT button is (soft) pushed or “Tune” on the main
> screen is pushed, the radio’s USB-D setting immediately reverts to USB, the
> radio goes into transmit mode and no tones are transmitted.
>
>
>
> As it relates to separate CI-V addresses for the 7300, I’ve not yet found
> a way to set CI-V Output (for ANT) to 70h and leave the main USB address at
> 94h. I’ve reached out into the IC-7300 community for help with this.
>
>
>
> Please let me know if there is a better forum for discussing (and
> hopefully resolving) this issue.
>
>
>
> Best regards de K9XT
>
>
>
> John Deegan, Fillmore, IN
>
>
>
> *From:* Bill Somerville [mailto:g4...@classdesign.com]
> *Sent:* Sunday, April 25, 2021 6:39 AM
> *To:* wsjt-devel@lists.sourceforge.net
> *Subject:* Re: [wsjt-devel] WSJT-x Icom CI-V Issue?
>
>
>
> On 23/04/2021 01:56, John Deegan wrote:
>
> Good afternoon. I am experiencing a problem with what I believe might be
> an issue with WSJT CI-V addressing.
>
>
>
> My environment is WSJT-x version 2.3.1, primarily running FT-8 and FT-4.
> The PC is an I-7 desktop or an I-7 laptop using Windows 10 Pro version
> 20H2. The radio is an IC-7300 with version 1.40 firmware.
>
>
>
> The problem with CI-V addressing occurs while operating in my RV. In this
> environment, I am using a Tarheel antenna and a “TennaTronix” Tenna Tuner-2
> antenna tuner. Because the Tenna Tuner-2 has a hard-coded CI-V address of
> 70h, I have to change the CI-V address of the 7300 to 70h from 94h and set
> the configuration of WSJT-x to emulate an IC-7000 Icom radio.
>
>
>
> When I set WSJT to IC-7000 and change the IC-7300 CI-V address to 70h, I
> get a good CAT and PTT indications in the Settings screens, but audio tones
> are not sent to the 7300 when I push the “Tune” soft button on the FT8
> screen. Also, the IC-7300’s USB-D setting immediately resets to USB. I
> experience this same problem on the FT4 mode screen.
>
>
>
> I have successfully defined the environment as an IC-7200 (76h) and an
> IC-7100 (88h) and everything appears to work properly.  Defining the
> environment as an IC-7300 (94h) also works properly.
>
>
>
> I appreciate any help you might be able to give me with this problem.
>
>
>
> Best regards de K9XT.
>
>
>
> *John Deegan*
>
> Hi John,
>
> thanks for joining the list. You can override the default CI-V address
> used by WSJT-X/Hamlib by creating a file in the WSJT-X log files directory
> called hamlib_settings.json with the following contents:
>
> {
>
> "config": {
>
> "civaddr": "0x70"
>
> }
>
> }
>
> That will allow you to use the regular IC-7300 rig setting in WSJT-X with
> your IC-730 switched to CI-V address 70h.
>
> Having said that, I thought the IC-7300 was capable of using a different
> CI-V address on the REMOTE port from the one used on the USB virtual serial
> port for CAT control. You will need to unlink the REMOTE port from the USB
> port in the IC-7300 menu, then set the Ci-V Output (for ANT) menu setting
> to 70h while leaving the main USB virtual port using the default of 94h.
>
> 73
> Bill
> G4WJS.
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJTX-X 2.4.0 rcX split

[Frode Igland]

Joe,
Whilst reviewing the User Guide, would you take a look at two issues:
1. The former section 10.2 Button Row has now been reduced to:

=== Button Row
// Status=edited

Is this a deliberate change?

2. Section 17.2.10, Table 7
The Bandwidth for FST4-15 is given as 67.7 Hz. Should that be 66.7 Hz
(Baudrate 16.67 x 4)?

... and one question:
3. Where do I send updated translations for v2.3.1 GA and 2.4.0-rc4?

73, Frode LA6VQ

fre. 2. apr. 2021 kl. 17:05 skrev Joe Taylor :

> Hi Sandro,
>
> Thanks, as always, for your careful reporting of several anomalies in
> the behavior or documentation of WSJT-X 2.4.0-rc4.
>
> I am working now on removing references to "JT9+JT65+ mode in the User
> Guide.  As you know, this mode is no longer useful and therefore not
> supported in v2.4.0.
>
> As for the maximum height restriction on the Wide Graph: to be honest, I
> do not uderstand why there is a current limit.  I will look into it
> further.
>
> -- 73, Joe, K1JT
>
> On 3/30/2021 5:17 AM, Alessandro Gorobey via wsjt-devel wrote:
> > Hi All
> >
> > Lower left spin box in wide graph (as toltip tells me) was used for JT9
> > start frequency decode in "JT9+JT65" mode.
> >
> > But "JT9+JT65" mode is now removed from menu.
> > The split control is active in FST4* modes.
> > The manual has the old description, but as it is a rc it will be
> > corrected in future.
> >
> >
> > Now what do split control in FST4* mode ?
> >
> >
> > Thanks in advance
> >
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

[Frode Igland]

Steve,
My apologies that I hadn't noticed that Reino had already explained the
invalid call sign. I should have read all the messages this morning before
I responded to your e-mail.

I guess that we may wish that the WSJT-X algorithm for identifying the DXCC
entity should have had a checkpoint that the call sign is at all valid
(involving at least the prefix and number), prior to identifying the DXCC
entity (I guess the current method is to look at the first 2-3 characters
after "CQ " from Tx6 or "CQ DX " from Tx5). As this was a case from Tx5, we
know the message after "CQ DX " must conform to the special standards
required to allow more than 13 characters, or it will be considered free
text and truncated beyond 13 characters.

As Tx5 obviously did not accept 5CT as a call sign, there must already be
some sort of "valid call sign check", at least in that message, otherwise
it would have been sent as an ordinary CQ DX message from Tx5 with an
untruncated locator. I have no idea whether a general "valid call sign
check" to avoid DXCC entity identification of invalid call signs is a
simple matter to include, or if it may slow down decoding or have other
undesirable effects in WSJT-X.

Nor do I know whether a "valid call sign check" is needed, as identifying
call signs not conforming to call sign format standards may be something
that should be left to the operator's attention and consideration, not the
computer's logic. We don't have to automate everything just because it may
be possible to do it. I guess Bill, Joe et al. will look into the matter
and decide whether this issue makes it to the priority list.

73 Frode LA6VQ


ons. 19. aug. 2020 kl. 10:25 skrev Stephen VK3SIR :

> Frode and The Community-at-large,
>
>
>
> Yes its invalid – the discussion has clearly identified that and I
> suspected that at the first post. The community has done a great job in
> clarifying this not only just for me but also lots of others.
>
> No more discussion needed on that subject of the callsign validity forever
> as it is repetitive and it has been most clearly identified ….
>
>
>
> WSJT-X has correctly prevented Tx response to the station…. Good Job J
>
>
>
> But… There is a point that many of you are missing here and that I am
> trying to get across … So I’ll place this in a container for clarity:
>
>
>
>
> --
>
>
>
> Why has the stream been decoded (good) and the logic allowed it to be
> identified – displayed - as coming from Morocco (bad)? The station should
> not display that it has come from Morocco in the first place as the call
> violates the rules of callsign structures for that DXCC entity. That is the
> real point I am making here !
>
>
>
>
> --
>
>
>
> There are many ways that this could be adjusted when the codebase for
> r2.2.2 is examined with some methods having greater impact than others to
> the codebase – If this behaviour has not been addressed already with other
> tweaks that may have entered the codebase > r2.2.2 (which we know is
> awaiting the Hamlib go).
>
> There is no point posting changes to the codebase as it is closed … what I
> could post may upset something else unknown to me. So therefore we have to
> post “anomalies identified” and rely on the intelligence of our core
> development team to consider, rate and implement changes if necessary.
>
>
>
> Many many many posts of mine have been about refactoring logic to prevent
> and eliminate false decodes and user confusion. This is a false lead issue
> reported here created a user confusion issue in a number of stations at the
> time that contacted me (Remember many of us hunt DX in packs !). I could
> validate the confusion issue when it presented itself. Therefore I have a
> responsibility to report the matter to the community !!!
>
>
>
> Almost all my posts are around improving utility especially for the
> “learner” and decreasing end-user confusion J
>
>
>
> 73
>
>
>
> Steve I
>
> VK3VM / VK3SIR
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

[Frode Igland]

Steve,
The issue with 5CT is that it is not a valid amateur call sign. That
requires a Prefix, a Number and a Suffix. The Prefix must have 1-2
characters of which one character must be a letter. The Suffix can be
longer, but must also have at least one letter.

If 5C is the Prefix (which belongs to Morocco), the Number is missing. If 5
is the Number, the Prefix is missing.

The invalid call sign caused WSJT-X to interpret the message as free text,
truncating anything beyond 13 characters, including the last digit of the
locator. Free text messages has no predefined format and therefore no
automatic recognition of call sign and locator, so clicking or
double-clicking does not fill the "DX Call" and "DX Grid" fields, which are
the data sources for generating standard messages and for logging.

A call sign like N7W qualifies as an amateur radio call sign and creates no
problem.

73 Frode LA6VQ

tir. 18. aug. 2020, 13:55 skrev Stephen VK3SIR :

> Frode,
>
>
>
> Thanks … By not “picking up” I was meaning you could not click,
> double-click or even use a third-party product via the UDP interface to
> force WSJT-X to place WSJT-X into a Tx2 mode that should have responded to
> the call. It’s a damn shame that I could not catch the call quickly enough
> (again) to get a recording of the stream.
>
> Recorders are on now … Hopefully someone else out there has seen this, has
> it and can supply?
>
>
>
>- I had no problem sending any of the Tx1 - Tx5 messages with 5CT in
>the DX Call field and JN0 in the DX Grid field.
>
>
>
> The problem is not sending; it’s the program being able to RESPOND through
> WSJT-X to 5CT sent as an attempted Tx1 ! It was not just me seeing this -
> which is why I responded with a report here.
>
>
>
>- First of all 5CT is not a valid call sign.
>
>
>
> It may or it may not be … It COULD have been allocated. But I have been
> responding to a number of calls that now fit this template i.e. N7C (
> https://www.qrz.com/db/n7c ) is a VERY valid and sought after call. I was
> able to make contact with that station but not this one !
>
>
>
> 73
>
>
>
> Steve I
>
> VK3VM / Vk3SIR
>
>
>
>
>
> *From:* Frode Igland 
> *Sent:* Tuesday, 18 August 2020 9:08 PM
> *To:* WSJT software development 
> *Subject:* Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that
> use DX
>
>
>
> Steve, I guess that your statement "WSJT-X will not pick up this call"
> means that WSJT-X will not *automatically *enter this call into the "DX
> Call" field, nor the locator into the "DX Grid" field. That is true, but
> WSJT-X will certainly pick up the call and grid as decoded if you enter it
> manually into the two fields. WSJT-X does not care how the call and grid
> arrives in the two fields, but once they are there they are used as entered.
>
> I had no problem sending any of the Tx1 - Tx5 messages with 5CT in the DX
> Call field and JN0 in the DX Grid field.
>
>
>
> Secondly, and all important here, it 5CT is not in accordance with the
> WSJT-X defintions and algorithms for what constitutes a call sign as
> defined in
> https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.2.2.html#PROTOCOL_OVERVIEW
> . Consequently, all my messages were sent as free text messages truncated
> at 13 characters, which is just right.
>
>
>
> 73 Frode LA6VQ
>
>
>
> tir. 18. aug. 2020 kl. 08:11 skrev Stephen VK3SIR :
>
> Hi Folks,
>
> I am unsure whether this has been reported:
>
> 30m:
>
> 055130 -11  0.2 1626 ~  CQ CO8LY FL20  Cuba
> 055130 -17  0.3 1342 ~  R3BV F1LYV RR73
> 055130 -19  0.3  618 ~  CQ DX 5CT JN0  Morocco  <-- Will not allow
> this to be picked this up
> 055200 -12  0.2 1627 ~  CQ CO8LY FL20  Cuba
>
> No matter what you do or how you try to pick up this calling station and
> pick up its call (i.e. click on it, double click, even use JTAlert) WSJT-X
> will not pick up this call !
>
> I can see that this is being primarily interpreted as a text message (i.e.
> > 13 chars) ... with the call framed in a " bad" format (missing the final
> char of the maidenhead).
>
> [ It is fully understandable and understood why the logic will not allow
> this call to be picked up as the truncated maidenhead is confusing things ]
>
> Unfortunately I do not have a recording of this to post back ...
>
> The screen is going nuts here with PM's so it needs be reported.
>
> 73
>
> Steve I
> VK3VM / Vk3SIR
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX

[Frode Igland]

Steve, I guess that your statement "WSJT-X will not pick up this call"
means that WSJT-X will not *automatically *enter this call into the "DX
Call" field, nor the locator into the "DX Grid" field. That is true, but
WSJT-X will certainly pick up the call and grid as decoded if you enter it
manually into the two fields. WSJT-X does not care how the call and grid
arrives in the two fields, but once they are there they are used as entered.
I had no problem sending any of the Tx1 - Tx5 messages with 5CT in the DX
Call field and JN0 in the DX Grid field.

First of all 5CT is not a valid call sign. Secondly, and all important
here, it 5CT is not in accordance with the WSJT-X defintions and algorithms
for what constitutes a call sign as defined in
https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.2.2.html#PROTOCOL_OVERVIEW
. Consequently, all my messages were sent as free text messages truncated
at 13 characters, which is just right.

73 Frode LA6VQ

tir. 18. aug. 2020 kl. 08:11 skrev Stephen VK3SIR :

> Hi Folks,
>
> I am unsure whether this has been reported:
>
> 30m:
>
> 055130 -11  0.2 1626 ~  CQ CO8LY FL20  Cuba
> 055130 -17  0.3 1342 ~  R3BV F1LYV RR73
> 055130 -19  0.3  618 ~  CQ DX 5CT JN0  Morocco  <-- Will not allow
> this to be picked this up
> 055200 -12  0.2 1627 ~  CQ CO8LY FL20  Cuba
>
> No matter what you do or how you try to pick up this calling station and
> pick up its call (i.e. click on it, double click, even use JTAlert) WSJT-X
> will not pick up this call !
>
> I can see that this is being primarily interpreted as a text message (i.e.
> > 13 chars) ... with the call framed in a " bad" format (missing the final
> char of the maidenhead).
>
> [ It is fully understandable and understood why the logic will not allow
> this call to be picked up as the truncated maidenhead is confusing things ]
>
> Unfortunately I do not have a recording of this to post back ...
>
> The screen is going nuts here with PM's so it needs be reported.
>
> 73
>
> Steve I
> VK3VM / Vk3SIR
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] strange response

[Frode Igland]

In the Log QSO window the call sign is changed from W5KDJ to 1W. Did that
happen automatically as that was the "call sign" in the RR73 message that
initiated the logging procedure, or is that entered manually by K0VM?

73  Frode LA6VQ

man. 13. jul. 2020 kl. 17:56 skrev Bill Somerville :

> On 13/07/2020 16:44, Bill Somerville wrote:
>
> On 13/07/2020 16:21, Al wrote:
>
> (wsjt-x 2.2.2 Win10 2004 )
> FYI..
> This sequence ended strangely..
>
>
> AL, K0VM
>
> Hi Al,
>
> nothing strange there. You QSO partner acknowledged your report to him, on
> the third resend with a non-standard message, something he can do as his
> callsign is sufficiently short and he chose not to address it to your
> callsign. He has sent the equivalent of an RR73 message and can be seen
> going immediately on to working another station, so I think you are
> perfectly OK to log the QSO as complete two-way. There must always be some
> doubt that the message "R 1W W5KDJ 73" was actually addressed to you, but
> given the context it is probably fine.
>
> 73
> Bill
> G4WJS.
>
> Hi Al,
>
> note that, critically, if there had been an extra pair of periods between
> the CQ by W5KDJ at 151200, and his response at 151230, with no decoded
> message from W5KDJ. Then you could make no such assumption since he could
> be signing off with a completely different station, i.e. not with you.
>
> 73
> Bill
> G4WJS.
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Bug Report: Four Letter Suffix in WSPR

[Frode Igland]

Onno,
There is nothing wrong with your call sign of four characters in the
suffix. It is just too long to fit within the restrictions of WSJT-X if you
want to use WSJT-X in the standard way.  Mind you, you can still use
WSJT-X, just not in the standard way.

WSJT-X was never created to work smoothly with all legal call signs, only
those consisting of up to two characters in the prefix + a digit + up to
three characters in the suffix (2 x 3 type call sign). In the WSJT-X  2.2.1
User Guide
https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.2.1.html#PROTOCOLS
you will find more about how the protocols have been worked out, whilst
https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.2.1.html#COMP-CALL
will tell you more about non-standard call signs. The add-on letter/numbers
are like "VP9/" or /P (rover station) or numbered portable designators like
"/3" or "/6". The Help menu shows the approved Type 1 prefixes and suffixes.

The WSJT-X development team's focus is to offer a protocol that can be used
for weak signals. That involves a number of compromises, or priorities if
you like, and covering all call signs (even if they are perfectly legal and
in accordance with international call sign rules) did not make it to the
priority list for standard operation, and most likely will not. I guess
your desire to use WSJT-X in the standard way is faster and safer achieved
by a shorter call sign (license upgrade?), than waiting for WSJT-X to
accommodate four character suffixes for standard operation. Sorry, but such
has the world become. :-(

73 Frode LA6VQ

fre. 19. jun. 2020 kl. 11:06 skrev Onno Benschop :

> Today I attempted to TX using WSPR and learned that my callsign (VK6FLAB)
> which I've held for nearly a decade isn't considered a "standard" callsign
> - this format was introduced in 2005.
>
> According to the ITU[1], my callsign is a perfectly legal callsign (and
> has been since 2003) (*emphasis* mine):
>
> *19.67 Amateur and experimental stations*
> *19.68 § 30 1)*
> - one character (provided that it is the letter B, F, G, I, K, M, N, R or
> W) and a single digit (other than 0 or 1), followed by a group of not more
> than *four characters*, the last of which shall be a letter, or
> - two characters and a single digit (other than 0 or 1), followed by a
> group of not more than *four characters*, the last of which shall be a
> letter. (WRC-03)
> *19.68A 1A)* On special occasions, for temporary use, administrations may
> authorize use of call signs with more than the four characters referred to
> in No. 19.68. (WRC-03)
> *19.69 2)* However, the prohibition of the use of the digits 0 and 1 does
> not apply to amateur stations.
>
>
> [1]
> https://www.itu.int/en/ITU-R/terrestrial/fmd/Documents/fxm-art19-sec3.pdf
>
>
> I also investigated using an extended (type 2) message which allows
> (according to the WSJT-X manual):
>
> Add-on prefixes can be up to three alphanumeric characters; add-on
> suffixes can be a single letter or one or two digits.
>
>
> I could theoretically use VK6FLA/B as my WSPR callsign, but I'm sure that
> the owner of VK6FLA would not be happy about this. Another "creative"
> implementation could be "VK6/F0LAB", but I'm sure that the French station
> owner of F0LAB would be surprised that they're transmitting from VK6.
>
> I'm raising this now because it wasn't legal for me to use my callsign on
> any digital mode until September last year and I've only just managed to
> get HF running at my QTH..
>
> I realise that this report is likely to require a fundamental change in
> the WSPR protocol and I suspect that other JT modes will be affected to
> more or lesser degree. I should probably also flag that any reporting,
> API, database, etc. might also be affected by this issue.
>
> I'm currently using WSJT-X v2.0.0 under Debian 10. I've not yet managed to
> compile or run a later version.
>
> Look forward to your feedback and comments.
>
> de Onno VK6FLAB
> --
> Onno Benschop
>
> ()/)/)()..ASCII for Onno..
> |>>?..EBCDIC for Onno..
> --- -. -. ---   ..Morse for Onno..
>
> If you need to know: "What computer should I buy?" http://goo.gl/spsb66
>
> ITmaze   -   ABN: 56 178 057 063   -  ph: 04 1219    -
> o...@itmaze.com.au
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 F/H mode - am I out of step ?

[Frode Igland]

It seems just right. According to the "RX Frequency" window you did not
transmit 091645 and 091715 (no yellow line). That is the times when you see
in the "Band Activity" window what was going on from all the other chasers
you were able to decode. They did the same on all other 15 and 45, but you
didn't see that because you were transmitting and therefore not decoding
them.

It looks like there was a good pile-up going, so congratulations on making
the contact, Erik.

73 Frode LA6VQ

ons. 26. feb. 2020 kl. 10:51 skrev :

> Hi,
>
> This morning I was trying to contact the PY0FF expedition and observed a
> strange behaviour when attempting the QSO and sending my locator.
> My "PY0FF ON4PB JO20" message is sent every 30 secs whereas all other
> stations are sending their locator in group at a specific time (see
> screenshot at 091715).
>
> I did not receive other stations sending their locator "out of step", so I
> thought something went amiss here ?
> From the screenshot, one can see that I am in hound mode and calling above
> 1000 Hz :
>
> https://1drv.ms/u/s!AtBGol2-BnqRhflgvVRljaWMXxDnjg?e=T9rava
>
> And for the record, I was eventually able to complete the QSO.
> Is this a correct behaviour or am I missing something here ?
>
> 73's Erik
> ON4PB
>
>
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement

[Frode Igland]

As I read Rich's message in digest format, a response may already be given,
so my apologies if I repeat a previous reply.

It seems like the check box under Settings - General - "Disable Tx after
sending 73" repeatedly creates some confusion. The mouse-over help text
describes exactly what checking this box does: "Turns off automatic
transmission after sending 73 or any other free text message". Nothing more
is implied, and specifically this does *not* mean that *un*checking (the
default state) it *en*ables automatic transmissions after sending 73. The
opposite, or the antithethical interpretation if you like, just does not
apply, nor does the mouse-over help text indicate that it applies.
Specifically, unchecking this box is no workaround to automatically create
a red "Enable TX" button again after sending 73. That would possibly create
an FT8 QSO robot enabling operations with no operator in
attendance/control, which is illegal in many (most/almost all?) countries.

WSJT-X includes considerably more demanding modes than FT8, e.g. meteor
modes, where repeating the message after sending 73 may be required to
complete a QSO and is normal until a return 73 has been received. However,
sometimes the conditions are good even for these modes, and then it may be
desirable to not transmit again after sending 73. That is a case when you
check the box "Disable Tx after sending 73". For FT8 the general disabling
of "Enable TX" after sending your 73 is desired actions and cannot
overridden in standard WSJT-X, which has not prevented operators from
creating robots.

Having not worked as a Fox, I am not in a position to jugde whether
clicking the "Enable TX" button is a sufficient PITA to enable DXpedition
QSO robots. However, even for expeditions to very rare DXCC entities (for
which FT8 DXpedition mode is created), the requirement for a control
operator applies. Unattended FT8 QSO robots are no more legal in exotic
places than other places. I understand the clicking inconvenience, but as
far as I understand, all other modes used by DXpeditions require the
operator to key the transmitter for *each* exchange in a QSO, either by
stepping on a foot switch or a mike PTT button or by pressing a function
key on a keyboard, so I don't know if clicking the "Enable TX" button once
per QSO is widely different or too much to ask for FT8 Fox operations.

man. 18. nov. 2019 kl. 01:03 skrev Rich Zwirko - K1HTV :

> Grant,
> By any chance could the problem described have been caused because under
> Settings, General tab you had the "Disable Tx after sending 73' check box
> checked? I don't know if this might be bypassed in the Fox mode. If not, it
> should be disabled automatically when the Fox mode is used.
>
> 73,
> Rich - K1HTV
>
> = = =
>
> VK5GR wrote:
>
> 2.   Secondly, and this was a MOST frustrating aspect of using the
> software. No matter what we did we couldn’t seem to find any settings that
> would stop the “Enable TX” button from being cancelled *every time* the
> FOX sent RR73 on any channel. Now it appears as though this is by design
> although I hope it is in fact a bug. Our view is that if the FOX operator
> had made the deliberate effort to load a station into the calling queue
> then *the enable TX button should remain active until the last station
> leaves the calling queue.*
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 F/H. NO CQ. CANNOT CALL

[Frode Igland]

The spotter may not have decoded 3DA0AO in a CQ, but in a QSO. Being quite
rare, I guess 3DA0AO was quite busy, with callers front, back, left and
right, not requiring CQs to conduct QSOs. Nevertheless, it is of course
best practice to make a CQ call every now and then.

Another issue may be that 3DA0AO is a non-standard call sign, which may not
respond to double-clicking the QSO line in the Band Activity window. I know
there was a discussion a while ago, where it was proposed to make an
exception for 3DA# and define it as a standard prefix (as it is for
eSwatini, ex Swaziland), but I don't remember if that has been executed.

However, as you say, if double-clicking doesn't move the call into the DX
field, entering the callsign by six clicks does. However, the spotter may
not know this method of preparing a call, so your point of failing to read
instructions may be very valid. But then again, that is no news.

Frode LA6VQ

tir. 17. sep. 2019 kl. 19:44 skrev Andy Durbin :

> "FT8 F/H. NO CQ. CANNOT CALL" was seen in a spot of 3DA0AO.   Don't FT8
> ops know it's possible to type the DX call in the DX Call box if they have
> no decodes of the DX to click on.  But why would they want to call if they
> have no decodes of the DX  to click on?  Isn't rule 1 - don't call if you
> can't hear (decode) the DX?
>
> Is failure to read the instructions the reason for this spot message or
> could there be some other explanation?
>
> 73,
> Andy k3wyc
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Special callsign

[Frode Igland]

Hi Svend Aage,
Adding the IOTA Reference to the CQ will be understood by WSJT-X as a free
text message, and will be limited to 13 character. I tried to figure out
the same some weeks ago, for my holiday in EU-055, but found no working
solution that would allow me to add the IOTA Reference to any of the
standard messages. However, you can add the IOTA Reference as free text in
the Tx5 message, e.g. like "IOTA EU44, 73". Then if you also update your
QRZ.com profile page and profile (correct IOTA Reference, locator and name
of the island), you can hope that someone spots you and then you'll have
enough to do. EU-044 West Finnmark is rarely active and should fetch good
interest.
on the air.

Enjoy the trip, and thanks for activating EU-044.

73 Frode LA6VQ

man. 12. aug. 2019 kl. 11:58 skrev Bill Somerville :

> On 12/08/2019 08:09, Svend Aage Jessen wrote:
> > I am going far up north for a few days next week
> > to IOTA designation EU-044, and tried to put the
> > extra letters into the Callsign field in the software.
> > Did not get it to work. Am I missing something here?
> > Red the online instruction, but...
> > Thanks...
> > --
> > 73 de LA6YJA
>
> Hi Sven Aage,
>
> which software are you referring to? Which modes do you intent to use
> and what is the callsign you have?
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.0.1: Bug-fix Release

[Frode Igland]

... and as soon as I sent the e-mail, the v2.0.1 User Guide was up and
ruinning. Thanks.

Frode

Den man. 25. feb. 2019 kl. 18:20 skrev Frode Igland :

> Thanks to Joe and the team for v2.0.1.
>
> The link to the v2.0.1 User Guide is not working yet. Updated translations
> will be forthcoming swiftly on receipt of the updated User guide.
>
> 73 Frode LA6VQ
>
> Den man. 25. feb. 2019 kl. 16:17 skrev Joe Taylor :
>
>> The WSJT Development Group is pleased to announce the general
>> availability (GA) release of WSJT-X Version 2.0.1, a bug-fix release.
>> It includes repairs of defects reported up to February 22, 2019.
>>
>> For a list of corrected bugs see the Release Notes:
>> http://physics.princeton.edu/pulsar/k1jt/Release_Notes.txt
>>
>> Additional details on code changes can be found here:
>> http://physics.princeton.edu/pulsar/k1jt/wsjtx-2.0.1.log
>>
>> Links to installation packages for Windows, Linux, and Macintosh are
>> available on the WSJT web site:
>> http://physics.princeton.edu/pulsar/k1jt/wsjtx.html
>>
>> You can also download the packages from our SourceForge site:
>> https://sourceforge.net/projects/wsjt/files/
>>
>> It may take a short time for the SourceForge site to be updated.
>>
>> We hope you will enjoy using WSJT-X Version 2.0.1.
>>
>>   -- 73, Joe, K1JT, for the WSJT Development Group
>>
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel