Date   

locked Re: QSO sequence #QSO_practices

Bill Somerville
 

Charlie,

you are either putting word into my mouth I did not say, or you are misunderstanding. A Tx1 message does not always contain a gridsquare. A user can choose not to enter their grid square into "Settings->General", or they may be using a callsign that does not allow the Tx1 (or Tx6) to include a gridsquare.

73
Bill
G4WJS.

On 01/10/2021 16:34, chas cartmel wrote:
Bill
No I'm not, you are talking semantics here. I am referring to the sequence messaging and as it's a prescribed order it is in itself a protocol, albeit not a data one.

It is I and others it seems who want to ignore calls responding to a CQ without a grid square so would like to have the choice to ignore them.

You seem to be defending the disabling of TX1 and misreading or even disregarding the viewpoint of others. This is a simple request so that operators can have the choice to disregard those responders who don't use TX1 as in the recommended sequence in the manual section 7.1.

If this stops me from working those with non-standard calls then that is down to my choice and I must live with the consequences. It doesn't stop operators from doing exactly what they are doing now, it is simply to stop my auto sequence from being triggered what I consider invalid.


73 Charlie
G4EST
www.g4est.me.uk
Stay safe out there



-----Original Message-----
From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of groups@...
Sent: 01 October 2021 14:25
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] QSO sequence #QSO_practices

On 01/10/2021 13:52, Bill Somerville wrote:
Charlie,

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 callsigns!

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.

73
Bill
G4WJS.

I agree it is unfair to ignore non-standard calls.

On the other hand I consider it quite acceptable for standard calls.

73
Roger
GW4HZA


locked Re: QSO sequence #QSO_practices

chas cartmel
 

Bill
No I'm not, you are talking semantics here. I am referring to the sequence messaging and as it's a prescribed order it is in itself a protocol, albeit not a data one.

It is I and others it seems who want to ignore calls responding to a CQ without a grid square so would like to have the choice to ignore them.

You seem to be defending the disabling of TX1 and misreading or even disregarding the viewpoint of others. This is a simple request so that operators can have the choice to disregard those responders who don't use TX1 as in the recommended sequence in the manual section 7.1.

If this stops me from working those with non-standard calls then that is down to my choice and I must live with the consequences. It doesn't stop operators from doing exactly what they are doing now, it is simply to stop my auto sequence from being triggered what I consider invalid.


73 Charlie
G4EST
www.g4est.me.uk
Stay safe out there

-----Original Message-----
From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of groups@...
Sent: 01 October 2021 14:25
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] QSO sequence #QSO_practices

On 01/10/2021 13:52, Bill Somerville wrote:
Charlie,

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 callsigns!

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.

73
Bill
G4WJS.
I agree it is unfair to ignore non-standard calls.

On the other hand I consider it quite acceptable for standard calls.

73
Roger
GW4HZA
This email has been scanned by BullGuard antivirus protection.
For more info visit www.bullguard.com


locked Re: Now getting shared memory error on iMac with wsjtx 2.4 #macOS

Bill Somerville
 

On 01/10/2021 16:00, David Head wrote:
Thanks Bill
Guess I should read the incuded documents...

73
Dave
W4WLC
Hi Dave,

we don't really expect users to read them, but at least we can point them out when they do happen cover the issue being asked about, hi.

73
Bill
G4WJS.


locked Re: Now getting shared memory error on iMac with wsjtx 2.4 #macOS

David Head <iamfilmiam@...>
 

Thanks Bill
Guess I should read the incuded documents...

73 
Dave
W4WLC


locked Re: Now getting shared memory error on iMac with wsjtx 2.4 #macOS

Bill Somerville
 

On 01/10/2021 15:44, David Head wrote:
Bill

Trying to install WSJTX 2.5 on the Mac laptop.  It has never had the WSJTX program on it.
The topic should have said 2.5 not 2.4.

Dave
W4WLC
Hi Dave,

instructions to configure shared memory parameters for your system are included in the ReadMe.txt file on the installer DMG.

73
Bill
G4WJS.


locked Re: Now getting shared memory error on iMac with wsjtx 2.4 #macOS

David Head <iamfilmiam@...>
 

Bill

Trying to install WSJTX 2.5 on the Mac laptop.  It has never had the WSJTX program on it.
The topic should have said 2.5 not 2.4.

Dave
W4WLC


locked Re: QSO sequence #QSO_practices

Bill Somerville
 

On 01/10/2021 14:42, Ralf Schlatterbeck wrote:
Cool.
I'd set the 590000 to 0 or 1 if possible to at least reduce the
confusion a bit .-)

But a mechanism to update the first call <G4WJS> in your example with
the qso partner of the last call automagically would be very nice!
I'll try how fast I can do this during a QSO, maybe even with my regular
call...
Or I'll update my UDP-Protocol coloring program to do it for me...

And if this works, maybe it could be institutionalized (= documented)
for stations where location info really matters (e.g. /mm)?
<snipped part answered separately>
73 de Ralf OE3RSU
Hi Ralf,

you can't send 0 or 1 for the report & serial word, it's not that flexible. The report part must be one of 52, 53, 54, 55, 56, 57, 58, 59.

A token in "macro" messages to substitute the current DX Call field value would be useful, I'll have a look at implementing that.

73
Bill
G4WJS.


locked Re: QSO sequence #QSO_practices

Ralf Schlatterbeck
 

On Fri, Oct 01, 2021 at 03:42:01PM +0200, Ralf Schlatterbeck wrote:
On Fri, Oct 01, 2021 at 01:58:57PM +0100, Bill Somerville wrote:
there is nothing stopping you from entering a message like the following
into the Tx5 field:

<G4WJS> <DL/OE3RSU> 590000 JN75mm
Cool.
I'd set the 590000 to 0 or 1 if possible to at least reduce the
confusion a bit .-)
Or to 73.

Ralf
--
Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
Open Source Consulting www: www.runtux.com
Reichergasse 131, A-3411 Weidling email: office@...


locked Re: QSO sequence #QSO_practices

Bill Somerville
 

On 01/10/2021 14:42, Ralf Schlatterbeck wrote:
And next on my wishlist would be an extension to the UDP-Protocol to
not just temporarily override the callsign (this can currently be done)
but also a telegram to override the location: This could be used by
mobile stations to update location from a GPS receiver or similar.
Would you accept a patch for that?

73 de Ralf OE3RSU
Hi Ralph,

that is already implemented - see the Location(11) message in the WSJT-X UDP Message Protocol:

https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/Network/NetworkMessage.hpp#l406

You must check the "Settings->General->Station Details->Auto Grid" option to enable this feature.

73
Bill
G4WJS.


locked Re: QSO sequence #QSO_practices

Ralf Schlatterbeck
 

On Fri, Oct 01, 2021 at 01:58:57PM +0100, Bill Somerville wrote:
On 01/10/2021 12:02, Ralf Schlatterbeck wrote:
On Fri, Oct 01, 2021 at 11:06:35AM +0100, Bill Somerville wrote:
1) non-standard calls cannot send Tx6 or Tx2 messages containing a grid
square - the protocol has no room for that information.
Sorry for chiming into the middle of this, but wouldn't it be possible
for the non-standard call to send an EU-VHF message (i3=5) with two
hashes for the callsigns and a locator with length 6 (and probably
sequence number s11=0)? That would be especially interesting for /MM
stations etc.
To my knowledge the current sequencing would not allow to send this, but
would it constitute a protocol violation? E.g. when sent at the end of
the call?
[..]

Hi Ralph,

there is nothing stopping you from entering a message like the following
into the Tx5 field:

<G4WJS> <DL/OE3RSU> 590000 JN75mm

It will be transmitted, and if the receiving station has previously copied
both callsigns un-hashed, then it will be received exactly as entered.

As to what the receiver will think the 590000 part means is probably
debatable, but at least it achieves your intent of relaying your location
information with grid locator accuracy.

Cool.
I'd set the 590000 to 0 or 1 if possible to at least reduce the
confusion a bit .-)

But a mechanism to update the first call <G4WJS> in your example with
the qso partner of the last call automagically would be very nice!
I'll try how fast I can do this during a QSO, maybe even with my regular
call...
Or I'll update my UDP-Protocol coloring program to do it for me...

And if this works, maybe it could be institutionalized (= documented)
for stations where location info really matters (e.g. /mm)?

And next on my wishlist would be an extension to the UDP-Protocol to
not just temporarily override the callsign (this can currently be done)
but also a telegram to override the location: This could be used by
mobile stations to update location from a GPS receiver or similar.
Would you accept a patch for that?

73 de Ralf OE3RSU
--
Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
Open Source Consulting www: www.runtux.com
Reichergasse 131, A-3411 Weidling email: office@...


locked Re: QSO sequence #QSO_practices

Roger
 

On 01/10/2021 13:52, Bill Somerville wrote:
Charlie,
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 callsigns!
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.
73
Bill
G4WJS.
I agree it is unfair to ignore non-standard calls.

On the other hand I consider it quite acceptable for standard calls.

73
Roger
GW4HZA


locked Re: QSO sequence #QSO_practices

Bill Somerville
 

On 01/10/2021 12:02, Ralf Schlatterbeck wrote:
On Fri, Oct 01, 2021 at 11:06:35AM +0100, Bill Somerville wrote:
Tom,

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.
Sorry for chiming into the middle of this, but wouldn't it be possible
for the non-standard call to send an EU-VHF message (i3=5) with two
hashes for the callsigns and a locator with length 6 (and probably
sequence number s11=0)? That would be especially interesting for /MM
stations etc.
To my knowledge the current sequencing would not allow to send this, but
would it constitute a protocol violation? E.g. when sent at the end of
the call?

Especially in Europe, where operating under your own callsign with the
country prefix (I've worked e.g. as DL/OE3RSU and 9A/OE3RSU) is very
common it would also be nice to occasionally (not in every QSO) send
your own locator to let people know where in the country you're
operating.

Ralf OE3RSU

Hi Ralph,

there is nothing stopping you from entering a message like the following into the Tx5 field:

<G4WJS> <DL/OE3RSU> 590000 JN75mm

It will be transmitted, and if the receiving station has previously copied both callsigns un-hashed, then it will be received exactly as entered.

As to what the receiver will think the 590000 part means is probably debatable, but at least it achieves your intent of relaying your location information with grid locator accuracy.

73
Bill
G4WJS.


locked Re: QSO sequence #QSO_practices

Bill Somerville
 

Charlie,

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 callsigns!

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.

73
Bill
G4WJS.

On 01/10/2021 13:40, chas cartmel wrote:

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.


73 Charlie

G4EST

www.g4est.me.uk

Stay safe out there

 




 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Tom Melvin
Sent: 01 October 2021 13:04
To: main@wsjtx.groups.io
Subject: Re: [WSJTX] QSO sequence #QSO_practices

 

Hi Bill

 

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 good job.

 

Regards

 

Tom

GM8MJV

 

 



On 1 Oct 2021, at 11:06, Bill Somerville <g4wjs@...> wrote:

 

Tom,

 

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.

 

73
Bill
G4WJS.

 

On 01/10/2021 08:15, Tom Melvin wrote:

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

 

Tom

GM8MJV

 



On 30 Sep 2021, at 20:12, Bob Abernethy <winston.rothschild@...> wrote:

 

My experience has been DX stations on the receiving end of a pile up prefer it.

 

BA

 

On Thu, Sep 30, 2021, 2:50 AM chas cartmel <chas@...> wrote:

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

Thoughts?

 

73 Charlie

G4EST



locked Re: QSO sequence #QSO_practices

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.


73 Charlie

G4EST

www.g4est.me.uk

Stay safe out there

 




 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Tom Melvin
Sent: 01 October 2021 13:04
To: main@wsjtx.groups.io
Subject: Re: [WSJTX] QSO sequence #QSO_practices

 

Hi Bill

 

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 good job.

 

Regards

 

Tom

GM8MJV

 

 



On 1 Oct 2021, at 11:06, Bill Somerville <g4wjs@...> wrote:

 

Tom,

 

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.

 

73
Bill
G4WJS.

 

On 01/10/2021 08:15, Tom Melvin wrote:

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

 

Tom

GM8MJV

 



On 30 Sep 2021, at 20:12, Bob Abernethy <winston.rothschild@...> wrote:

 

My experience has been DX stations on the receiving end of a pile up prefer it.

 

BA

 

On Thu, Sep 30, 2021, 2:50 AM chas cartmel <chas@...> wrote:

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

Thoughts?

 

73 Charlie

G4EST

 



 


This email has been scanned by BullGuard antivirus protection.
For more info visit www.bullguard.com


locked Re: QSO sequence #QSO_practices

Tom Melvin
 

Hi Bill

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 good job.

Regards

Tom
GM8MJV



On 1 Oct 2021, at 11:06, Bill Somerville <g4wjs@...> wrote:

Tom,

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.

73
Bill
G4WJS.

On 01/10/2021 08:15, Tom Melvin wrote:
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

Tom
GM8MJV


On 30 Sep 2021, at 20:12, Bob Abernethy <winston.rothschild@...> wrote:

My experience has been DX stations on the receiving end of a pile up prefer it.

BA

On Thu, Sep 30, 2021, 2:50 AM chas cartmel <chas@...> wrote:
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

Thoughts?
 
73 Charlie
G4EST







locked Re: QSO sequence #QSO_practices

Ralf Schlatterbeck
 

On Fri, Oct 01, 2021 at 11:06:35AM +0100, Bill Somerville wrote:
Tom,

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.
Sorry for chiming into the middle of this, but wouldn't it be possible
for the non-standard call to send an EU-VHF message (i3=5) with two
hashes for the callsigns and a locator with length 6 (and probably
sequence number s11=0)? That would be especially interesting for /MM
stations etc.
To my knowledge the current sequencing would not allow to send this, but
would it constitute a protocol violation? E.g. when sent at the end of
the call?

Especially in Europe, where operating under your own callsign with the
country prefix (I've worked e.g. as DL/OE3RSU and 9A/OE3RSU) is very
common it would also be nice to occasionally (not in every QSO) send
your own locator to let people know where in the country you're
operating.

Ralf OE3RSU
--
Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
Open Source Consulting www: www.runtux.com
Reichergasse 131, A-3411 Weidling email: office@...


locked Re: Now getting shared memory error on iMac with wsjtx 2.4 #macOS

Bill Somerville
 

On 01/10/2021 02:51, David Head wrote:
Mac Air Laptop running 10.15.7.

Any help would be appreciated.

Thanks,
Dave W4WLC
Dave,

what did you change?

73
Bill
G4WJS.


locked Re: QSO sequence #QSO_practices

Bill Somerville
 

Tom,

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.

73
Bill
G4WJS.

On 01/10/2021 08:15, Tom Melvin wrote:
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

Tom
GM8MJV


On 30 Sep 2021, at 20:12, Bob Abernethy <winston.rothschild@...> wrote:

My experience has been DX stations on the receiving end of a pile up prefer it.

BA

On Thu, Sep 30, 2021, 2:50 AM chas cartmel <chas@...> wrote:
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

Thoughts?

 

73 Charlie
G4EST



locked Re: QSO sequence #QSO_practices

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

Tom
GM8MJV


On 30 Sep 2021, at 20:12, Bob Abernethy <winston.rothschild@...> wrote:

My experience has been DX stations on the receiving end of a pile up prefer it.

BA

On Thu, Sep 30, 2021, 2:50 AM chas cartmel <chas@...> wrote:
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

Thoughts?

 

73 Charlie
G4EST
Stay safe out there

 


This email has been scanned by BullGuard antivirus protection.
For more info visit www.bullguard.com








locked Now getting shared memory error on iMac with wsjtx 2.4 #macOS

David Head <iamfilmiam@...>
 

Mac Air Laptop running 10.15.7.

Any help would be appreciated.

Thanks,
Dave W4WLC

6521 - 6540 of 35397