toggle quoted messageShow quoted text
you are confusing the message protocols
and the order of messages exchanged in QSOs, they are very
different things. No changes were needed to the protocols to
enable the application to automatically select the Tx2 message
when replying to a CQ call, nor to select an RR73 grid square
message when replying to an R+report message or equivalent.
Why do you take the view that a reply
to a CQ call without a grid square should be ignored by the
software? A lot of work was put into the current 77-bit payload
protocols to support non-standard calls, why do you think that is
of no value to you? I should point out that often the most
desirable QSO partners may have non-standard calls.
Your proposal is not fair, in fact it
is grossly unfair to those users who have to use non-standard
If operators reply to your CQ calls
with no grid (enforced or otherwise), then please understand that
is their choice. You can choose to ignore them and work a
different station, but the software itself is not going to support
automation of such censorship.
On 01/10/2021 13:40, chas cartmel
I opened a can of
worms what I posted this issue a few days back.
It seems that the developers ignoring the protocol in the
official documentation succumbed to pressure from the users to
allow the disabling of the TX1 response. Also a slight to the
protocol designers who were basically told you got it wrong.
Can I therefore ask that a corresponding action be taken to
disable the auto sequencing response to replies to CQ calls
where the grid square if not included (TX1)?
Seems only fair.
Stay safe out there
No sorry never ignored your comments -
definitely not on purpose would I.
Yes I know there are issues with Special
event calls, did mention that - impossible to send grid in CQ
and needs to be freehand.
Contest mode - there was an issue a while
back where the reports were changing willie nilly - and
logging would take the previous details (think if you switched
QSO partners mid QSO) - yes I know both of those have now been
fixed. However, there were so many problems with report
issues (this was also the time where the were some Looong gaps
between versions). The RSGB activity contest (6m and up)
suggested users don’t use Contest Mode - normal mode worked a
lot better, some Eu contests then followed suit. This was to
avoid the string of complaints - it was the 1st few contests -
things have stabilised and quite a bit of UK and Eu activity
on these contests.
There is nothing now (as far as I can tell)
from reverting back to using Eu contest mode - is that nag
message still there ‘you should be in contest mode’?. Except
users have got in the habit of using Normal Mode. Add in, on
6m in particular all it takes is a nice Es opening to coincide
with a contest and all goes to pot - yes it has happening -
people prefer to work the DX than contest stations - contest
mode gets switched off to stop the nag message (it was there
at the time).
I would take a guess it will take a while
(at least a year?) to get the - is there such a thing as
average user - don't want to upset anyone - but getting
someone to read the docs (even read contest rules!!) can be -
shall we say be problematic. Change now a long term process.
The only way I can see this changing is to
make contest mode ’transparent’ to the user - if someone
calling CQ TEST then the remote system responds with
grid/serial number without any action being taken, someone
with a vanilla CQ is answered by contest station - full grid
and pseudo number sent without originator doing anything. This
all assumes a) there is interest, b) a spare bit exists to be
used and c) Someone willing to code it as I doubt in roadmap.
I do see where HF station want to save time
- they want to break the 10K FT8 QSO Count! - some DX may want
to give as many stations as possible that Prefix. On the
other side there is 6m (even 10m station to open up) and up
where quantity is not the driver.
So sorry again if you thought I was
ignoring your comments - I wasn’t - you and the others do a
On 1 Oct 2021, at 11:06, Bill
it seems to me that you thanked me
for my comments then completely ignored what I stated!
A couple of points to clarify what I stated:
1) non-standard calls cannot send
Tx6 or Tx2 messages containing a grid square - the
protocol has no room for that information.
2) the supported contest modes that
require exchange of grid squares or locators on air do
that for all participants (with the caveat that
non-standard calls other than standard calls signing
/P or /R cannot participate).
I will add that the facility to
reply to a CQ call with a Tx2 message along with the
facility to replace an RRR response with an RR73
response were both added with some reluctance due to
the huge number of stations doing exactly that on the
HF bands by modifying the messages sent manually.
On 01/10/2021 08:15, Tom Melvin
Thanks for comments Bill
I will stick with the comments of
6m and up should send grid.
The other issue not seen is
contests - the phrase ‘ all data must be transmitted
on air’ - looking up QRZ does not really count :-)
QRZ is often wrong - I adjudicate some VHF FT8
contests and the number of points lost due to
missing/wrong locators is rather high.
And; you should not substantially
alter the contest log prior to submission - editing
a pile of locators hmmm
Anyhow, there are circumstances
Special Event calls, JA’s and those that want to
save a period - so it’s up to individuals -
personally I don’t like it. However there is damm
all I can do about it, developers are not going to
alter software at this stage of the game.
It just need to make education
high on the list pointing out, for some people
receiving no grid can be a PITA.
Have fun on the bands and enjoy
My experience has been DX
stations on the receiving end of a pile up
On Thu, Sep 30, 2021,
2:50 AM chas cartmel <chas@...>
Not sure if this is a
new trend but lately I am having CQs
replied to with a report as the first
data sent rather than a locator.
Not a big deal here as I do not collect
squares, but still ‘off process’. It
does speed things up though J