Date   

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:
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.
I've experimented a little with this:
- If I do this with my recent QSO partner in the first hash, wsjtx will
pop up a warning (at the QSO-partner) that EU VHF mode should be turned on.
I don't want to irritate QSO partners with this :-)
[Worse: These warnings pile up if the message repeats having to
confirm each one in series, maybe this should be changed to pop up the
warning only once? But this is a minor issue since directly-addressed
contest messages should be rare. Looks like a denial-of-service attack
on some of the bot operators could be mounted that way :-) A
config-option to turn off these popups would be nice.]
- If I put my own callsign in both hashes the QSO partner is not
affected.

But: In both cases if I'm replacing my 73 message with this special
message I'm never prompted for logging the QSO. (Even if I put 590073 as
the combined report/sequence number :-)

So I guess this *can* be used by a mobile operator for sending their
locator (and their callsign in *both* hashes) from time to time but
cannot be used to modify the usual QSO sequence.

Or can we come up with a modification (a special value in one of the
fields) of the EU VHF message that does not pop up a warning at the
receiver? (And maybe even not display the report)

BTW: I was testing this with two computers w/ microphone and speakers.
Is there a better way to test the auto-sequencing code without resorting
to a real communication setup (and wait times for transmissions)?

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: Possible bug with tune button on 2.5.0 GA #IssueReport #Yaesu #Cat_RigControl #transmit

Reino Talarmo
 

>I've noticed a similar problem. Running the "Pwr" slider down and up seems to remedy it for the session. 

 

Hi Jason,

Have you tested possible RFI? Turning down power or using dummy load?

73, Reino OH3mA

 


locked WSJT-X and 630 meters, a match made in heaven #FST4 #FST4W

Mark ~ AE2EA <mark.erdle@...>
 

When I decided to operate on the newly opened 630 meter band, the lack of commercial amateur radio equipment for the bands below 160 meters forced me to get creative So here's the approach that I took to get on 630 meters by utilizing a repurposed non directional beacon, a modified HP downconverter, and a reconfigured 80 meter dipole antenna.
I originally used JT9 and WSPR but have migrated to FST4 and FST4W. On 630 meters every db of S/N improvement helps and I really appreciate the inclusion of the MF and LF modes. It's astounding what the roughly 350 milliwatts EIRP that my antenna radiates can do. Claude Shannon would be proud of what the WSJT-X developers have done.

Watch it here: https://youtu.be/zGWTdNh75CE

Mark ~ AE2EA


locked Re: Possible bug with tune button on 2.5.0 GA #IssueReport #Yaesu #Cat_RigControl #transmit

Jeff Townsend
 

It must be a dirty virtual slider pot. Get out the virtual contact cleaner George and give it a spray. 
<Grin>


On Oct 1, 2021, at 7:23 PM, George J Molnar, KF2T <george@...> wrote:

I've noticed a similar problem. Running the "Pwr" slider down and up seems to remedy it for the session. 



Jeff Townsend
WB8LYJ





locked Re: Possible bug with tune button on 2.5.0 GA #IssueReport #Yaesu #Cat_RigControl #transmit

George J Molnar, KF2T
 

I've noticed a similar problem. Running the "Pwr" slider down and up seems to remedy it for the session. 


locked Re: WSJT-X 2.4.0 and ICOM 7800. #Cat_RigControl

Joe Subich, W4TV
 

Eddy,

No reply from any other user with the ICOM 7800.
Check the firmware version installed in the Icom 7800 and compare it
with the version expected by hamlib. Icom made major changes beginning
with v 3.10 for the 7800. Some software now expects v 3.10 or later
and has been known to fail to work with earlier versions of the
firmware. I do not know if hamlib is one of those applications but
it sounds suspicious since WSJTX 2.2.2 and 2.3.0 work (they have a
built-in version of an older hamlib) where 2.4.0 and 2.5.0 do not work
(they use the current *dll* version of hamlib.

73,

... Joe, W4TV


On 2021-10-01 3:12 PM, Eddy Van de Velde wrote:
Hi Bill,
My apologies for this late reply. No reply from any other user with the ICOM 7800.
We had to find some time to get together and sort things out.
We also thought better wait until next release.
V 2.2.2 Windows 64, no problem at all. V 2.3.0 Windows 64 also no problem at all.
Both V 2.4.0 and V 2.5.0 do not work and this Error screen pops up.
We tried al versions with exactly the same settings Going back to V 2.3.0 and all goes fine, no problems at all.
By the way, I have a FLex-6300 with DDUtl_V3 and never had any problems with new versions.
We hope this helps.
73,
Eddy ON5UQ.
*Van: *Bill Somerville <mailto:g4wjs@...>
*Verzonden: *woensdag 7 juli 2021 11:27
*Aan: *main@WSJTX.groups.io <mailto:main@WSJTX.groups.io>
*Onderwerp: *Re: [WSJTX] WSJT-X 2.4.0 and ICOM 7800. #hamlib
On 07/07/2021 07:21, Eddy Van de Velde wrote:

> Hi all,

>

> I'm posting here for a good ham friend of mine having problems after

> upgrading to WSJT-X 2.4.0.

>

> PC Windows 8.1 64 bits.

> Transceiver ICOM 7800.

>

> WSJT-X 2.2.2 had been running on this combination since it's release

> and never had any problem at all. After upgrading to WSJT-X 2.4.0

> communication with the transceiver fails because of a Hamlib error.

> The radio does not recognise the command. However all settings are

> exactly the same as for WSJT-X 2.2.2. Uninstalling WSJT-X 2.4.0 and

> again install WSJT-X 2.2.2 fixes the problem.

>

> Anyone on this list using this combination or having a fix ?

>

> Thank you and 73,

>

> Eddy ON5UQ.
Eddy,
reporting an error message from WSJT-X without telling us the exact
text, including details, of that message is not helpful.
73
Bill
G4WJS.


locked Re: WSJTX optical scatter or light communication #Q65

Rex Moncur
 

Hi James

 

I refer you to DUBUS Volume 4/20 page 97.  "Optical communication with FST4 and FST4W".   The Q65 tests were an extension of these tests from FST4 to Q65.  In 300 second periods there is probably not much difference between FST4 and Q65 for Optical Scatter. FST4 can run at 1800 second periods and pick up more sensitivity but as there is often QSB on clear air scatter and cloud scatter there may not be much advantage in the longer periods.

 

73 Rex VK7MO

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of James Whitfield
Sent: Saturday, 2 October 2021 4:34 AM
To: main@WSJTX.groups.io
Subject: [WSJTX] WSJTX optical scatter or light communication #Q65

 

Reading the Q65_Quick_Start guide, I saw reference for Optical Scatter using the 300 second period with A tone spacing.  Having worked with light communications, I was curious.  So far I have not found any further information about this or other WSJT-X efforts using light, so I would appreciate any further information that is available.

 

Thank you.

 

James Whitfield

 n5gui

 

 

 

 


locked Re: WSJT-X 2.4.0 and ICOM 7800. #Cat_RigControl

Michael Black
 

Please try WSJTX-2.5.0 -- there was a fix for the 7800 after 2.4.0

Mike W9MDB




On Friday, October 1, 2021, 02:15:55 PM CDT, Eddy Van de Velde <van.de.velde.eddy@...> wrote:


 

Hi Bill,

 

My apologies for this late reply. No reply from any other user with the ICOM 7800.

 

We had to find some time to get together and sort things out.

We also thought better wait until next release.

V 2.2.2 Windows 64, no problem at all. V 2.3.0 Windows 64 also no problem at all.

Both V 2.4.0 and V 2.5.0 do not work and this Error screen pops up.

 

We tried al versions with exactly the same settings Going back to V 2.3.0 and all goes fine, no problems at all.

 

By the way, I have a FLex-6300 with DDUtl_V3 and never had any problems with new versions.

 

We hope this helps.

 

73,

 

Eddy ON5UQ.

 

 

 

Van: Bill Somerville
Verzonden: woensdag 7 juli 2021 11:27
Aan: main@WSJTX.groups.io
Onderwerp: Re: [WSJTX] WSJT-X 2.4.0 and ICOM 7800. #hamlib

 

On 07/07/2021 07:21, Eddy Van de Velde wrote:

> Hi all,

> I'm posting here for a good ham friend of mine having problems after

> upgrading to WSJT-X 2.4.0.

> PC Windows 8.1 64 bits.

> Transceiver ICOM 7800.

> WSJT-X 2.2.2 had been running on this combination since it's release

> and never had any problem at all. After upgrading to WSJT-X 2.4.0

> communication with the transceiver fails because of a Hamlib error.

> The radio does not recognise the command. However all settings are

> exactly the same as for WSJT-X 2.2.2. Uninstalling WSJT-X 2.4.0 and

> again install WSJT-X 2.2.2 fixes the problem.

> Anyone on this list using this combination or having a fix ?

> Thank you and 73,

> Eddy ON5UQ.

 

Eddy,

 

reporting an error message from WSJT-X without telling us the exact

text, including details, of that message is not helpful.

 

73

Bill

G4WJS.

 

 





locked Re: WSJT-X 2.4.0 and ICOM 7800. #Cat_RigControl

Eddy Van de Velde
 

 

Hi Bill,

 

My apologies for this late reply. No reply from any other user with the ICOM 7800.

 

We had to find some time to get together and sort things out.

We also thought better wait until next release.

V 2.2.2 Windows 64, no problem at all. V 2.3.0 Windows 64 also no problem at all.

Both V 2.4.0 and V 2.5.0 do not work and this Error screen pops up.

 

We tried al versions with exactly the same settings Going back to V 2.3.0 and all goes fine, no problems at all.

 

By the way, I have a FLex-6300 with DDUtl_V3 and never had any problems with new versions.

 

We hope this helps.

 

73,

 

Eddy ON5UQ.

 

 

 

Van: Bill Somerville
Verzonden: woensdag 7 juli 2021 11:27
Aan: main@WSJTX.groups.io
Onderwerp: Re: [WSJTX] WSJT-X 2.4.0 and ICOM 7800. #hamlib

 

On 07/07/2021 07:21, Eddy Van de Velde wrote:

> Hi all,

> I'm posting here for a good ham friend of mine having problems after

> upgrading to WSJT-X 2.4.0.

> PC Windows 8.1 64 bits.

> Transceiver ICOM 7800.

> WSJT-X 2.2.2 had been running on this combination since it's release

> and never had any problem at all. After upgrading to WSJT-X 2.4.0

> communication with the transceiver fails because of a Hamlib error.

> The radio does not recognise the command. However all settings are

> exactly the same as for WSJT-X 2.2.2. Uninstalling WSJT-X 2.4.0 and

> again install WSJT-X 2.2.2 fixes the problem.

> Anyone on this list using this combination or having a fix ?

> Thank you and 73,

> Eddy ON5UQ.

 

Eddy,

 

reporting an error message from WSJT-X without telling us the exact

text, including details, of that message is not helpful.

 

73

Bill

G4WJS.

 

 


locked Re: QSO sequence #QSO_practices

Jim Brown
 

On 10/1/2021 8:54 AM, chas cartmel wrote:
It’s called choice, they choose not to send a grid square so I choose to ignore them.
That's your choice, and your loss. I've been at this for 65 years, and grids are a VERY new thing in ham radio. I chase grids on 6M.

73, Jim K9YC


locked Re: WSJTX optical scatter or light communication #Q65

Charles Suckling
 

Dave, James

VK7MO has done a lot of work on this.  Google will find references.

73

Charlie DL3WDG

On Fri, 1 Oct 2021 at 20:39, Dave (NK7Z) <dave@...> wrote:
Please share on list if possible, this also interests me.

73, and thanks,
Dave (NK7Z)
https://www.nk7z.net
ARRL Volunteer Examiner
ARRL Technical Specialist, RFI
ARRL Asst. Director, NW Division, Technical Resources

On 10/1/21 11:33 AM, James Whitfield wrote:
> Reading the Q65_Quick_Start guide, I saw reference for Optical Scatter
> using the 300 second period with A tone spacing.  Having worked with
> light communications, I was curious.  So far I have not found any
> further information about this or other WSJT-X efforts using light, so I
> would appreciate any further information that is available.
>
> Thank you.
>
> James Whitfield
>   n5gui
>
>
>
>
>
>
>
>




locked Re: WSJTX optical scatter or light communication #Q65

Dave (NK7Z)
 

Please share on list if possible, this also interests me.

73, and thanks,
Dave (NK7Z)
https://www.nk7z.net
ARRL Volunteer Examiner
ARRL Technical Specialist, RFI
ARRL Asst. Director, NW Division, Technical Resources

On 10/1/21 11:33 AM, James Whitfield wrote:
Reading the Q65_Quick_Start guide, I saw reference for Optical Scatter using the 300 second period with A tone spacing.  Having worked with light communications, I was curious.  So far I have not found any further information about this or other WSJT-X efforts using light, so I would appreciate any further information that is available.
Thank you.
James Whitfield
 n5gui


locked WSJTX optical scatter or light communication #Q65

James Whitfield <n5gui@...>
 

Reading the Q65_Quick_Start guide, I saw reference for Optical Scatter using the 300 second period with A tone spacing.  Having worked with light communications, I was curious.  So far I have not found any further information about this or other WSJT-X efforts using light, so I would appreciate any further information that is available.

Thank you.

James Whitfield
 n5gui





locked Re: QSO sequence #QSO_practices

Sam Birnbaum
 

Hi Charlie,

You can just uncheck the Call 1st checkbox. You now have a choice as to which station to answer to.

73,

Sam W2JDB



-----Original Message-----
From: Philip Rose via groups.io <gm3zza@...>
To: main@WSJTX.groups.io <main@WSJTX.groups.io>
Sent: Fri, Oct 1, 2021 11:52 am
Subject: Re: [WSJTX] QSO sequence #QSO_practices

Charlie,
 
You can choose to ignore them, by disabling TX before you have a chance to reply, or double-clicking on the call you do want to answer. The choice is all yours.
 
73 Phil GM3ZZA
 
Sent from Mail for Windows
 
From: chas cartmel
Sent: 01 October 2021 16:34
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] QSO sequence #QSO_practices
 
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
 
 
 
 

--
73 Phil GM3ZZA




locked Re: QSO sequence #QSO_practices

Bill Somerville
 

Charlie,

you are going to have to give us an example of that. If "Call 1st" is not enabled then a response to a CQ never initiates any auto sequencing, you as the operator have to select a reply to start a QSO with.

73
Bill
G4WJS.

On 01/10/2021 18:33, chas cartmel wrote:

I do, but when the calling station responds it sets auto sequence back on. Time to select a station to work is limited, hence I want the function to filter out those I am not interested in before the time segment restarts and give me a chance to work viable contacts.

I am NOT wanting a change to the calling stations procedures, they do what they want how they want, standard or not, but if a function such as auto sequence is in place it should not trigger when the standard exchange is not followed.


73 Charlie

G4EST

www.g4est.me.uk

Stay safe out there

 

 

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of neil_zampella
Sent: 01 October 2021 18:23
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] QSO sequence #QSO_practices

 

Its your preference, and as such, just uncheck the 'AutoSeq' and/or 'Call1st' box(es) and manually do what you prefer.

Neil, KN3ILZ

On 10/1/2021 10:54 AM, chas cartmel wrote:

Sorry, but I don’t care, my request stands in that I want a way to ignore responses which are not of the standard format and do not include a grid square.

It’s called choice, they choose not to send a grid square so I choose to ignore them.

As a further point why bother with a grid square in the CQ. If so many now think it’s not a requirement then why not do away with it in the standard exchange for the CQ message. I’m sure the space taken up by encoding this could be used elsewhere?

Personally I like it, it’s useful, which is why I want to keep it. If a TX1 does not contain a gridsquare then fine (to a point) it will NOT however contain the report which triggers the sequence from the wrong point which is what I am wanting to avoid.



73 Charlie

G4EST

www.g4est.me.uk

Stay safe out there

 

 

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Bill Somerville
Sent: 01 October 2021 16:41
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] QSO sequence #QSO_practices

 

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
 

I do, but when the calling station responds it sets auto sequence back on. Time to select a station to work is limited, hence I want the function to filter out those I am not interested in before the time segment restarts and give me a chance to work viable contacts.

I am NOT wanting a change to the calling stations procedures, they do what they want how they want, standard or not, but if a function such as auto sequence is in place it should not trigger when the standard exchange is not followed.


73 Charlie

G4EST

www.g4est.me.uk

Stay safe out there

 

 

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of neil_zampella
Sent: 01 October 2021 18:23
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] QSO sequence #QSO_practices

 

Its your preference, and as such, just uncheck the 'AutoSeq' and/or 'Call1st' box(es) and manually do what you prefer.

Neil, KN3ILZ

On 10/1/2021 10:54 AM, chas cartmel wrote:

Sorry, but I don’t care, my request stands in that I want a way to ignore responses which are not of the standard format and do not include a grid square.

It’s called choice, they choose not to send a grid square so I choose to ignore them.

As a further point why bother with a grid square in the CQ. If so many now think it’s not a requirement then why not do away with it in the standard exchange for the CQ message. I’m sure the space taken up by encoding this could be used elsewhere?

Personally I like it, it’s useful, which is why I want to keep it. If a TX1 does not contain a gridsquare then fine (to a point) it will NOT however contain the report which triggers the sequence from the wrong point which is what I am wanting to avoid.



73 Charlie

G4EST

www.g4est.me.uk

Stay safe out there

 

 

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Bill Somerville
Sent: 01 October 2021 16:41
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] QSO sequence #QSO_practices

 

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

 

This email has been scanned by BullGuard antivirus protection.

For more info visit www.bullguard.com



 
 
 

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


locked Re: QSO sequence #QSO_practices

chas cartmel
 

I know… a grid square is though.


73 Charlie

G4EST

www.g4est.me.uk

Stay safe out there

 

 

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Robert Lorenzini
Sent: 01 October 2021 18:11
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] QSO sequence #QSO_practices

 

Charlie here is the US a call sign is no longer a indicator of location.

Bob - wd6dod

On 10/1/2021 8:54 AM, chas cartmel wrote:

Sorry, but I don’t care, my request stands in that I want a way to ignore responses which are not of the standard format and do not include a grid square.

It’s called choice, they choose not to send a grid square so I choose to ignore them.

As a further point why bother with a grid square in the CQ. If so many now think it’s not a requirement then why not do away with it in the standard exchange for the CQ message. I’m sure the space taken up by encoding this could be used elsewhere?

Personally I like it, it’s useful, which is why I want to keep it. If a TX1 does not contain a gridsquare then fine (to a point) it will NOT however contain the report which triggers the sequence from the wrong point which is what I am wanting to avoid.

73 Charlie

G4EST

www.g4est.me.uk

Stay safe out there

 

 

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Bill Somerville
Sent: 01 October 2021 16:41
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] QSO sequence #QSO_practices

 

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

 

This email has been scanned by BullGuard antivirus protection.

For more info visit www.bullguard.com



 
 
 

 


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


locked Re: QSO sequence #QSO_practices

neil_zampella
 

Its your preference, and as such, just uncheck the 'AutoSeq' and/or 'Call1st' box(es) and manually do what you prefer.

Neil, KN3ILZ

On 10/1/2021 10:54 AM, chas cartmel wrote:

Sorry, but I don’t care, my request stands in that I want a way to ignore responses which are not of the standard format and do not include a grid square.

It’s called choice, they choose not to send a grid square so I choose to ignore them.

As a further point why bother with a grid square in the CQ. If so many now think it’s not a requirement then why not do away with it in the standard exchange for the CQ message. I’m sure the space taken up by encoding this could be used elsewhere?

Personally I like it, it’s useful, which is why I want to keep it. If a TX1 does not contain a gridsquare then fine (to a point) it will NOT however contain the report which triggers the sequence from the wrong point which is what I am wanting to avoid.


73 Charlie

G4EST

www.g4est.me.uk

Stay safe out there

 

 

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Bill Somerville
Sent: 01 October 2021 16:41
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] QSO sequence #QSO_practices

 

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

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




locked Re: QSO sequence #QSO_practices

Robert Lorenzini
 

Charlie here is the US a call sign is no longer a indicator of location.

Bob - wd6dod

On 10/1/2021 8:54 AM, chas cartmel wrote:

Sorry, but I don’t care, my request stands in that I want a way to ignore responses which are not of the standard format and do not include a grid square.

It’s called choice, they choose not to send a grid square so I choose to ignore them.

As a further point why bother with a grid square in the CQ. If so many now think it’s not a requirement then why not do away with it in the standard exchange for the CQ message. I’m sure the space taken up by encoding this could be used elsewhere?

Personally I like it, it’s useful, which is why I want to keep it. If a TX1 does not contain a gridsquare then fine (to a point) it will NOT however contain the report which triggers the sequence from the wrong point which is what I am wanting to avoid.


73 Charlie

G4EST

www.g4est.me.uk

Stay safe out there

 

 

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Bill Somerville
Sent: 01 October 2021 16:41
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] QSO sequence #QSO_practices

 

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

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





locked Re: QSO sequence #QSO_practices

chas cartmel
 

Not exactly easy in the 2 second gap.
I actually do this but the calling station often repeats the reply (not exactly saving time) and the whole rigmarole starts again.
You can also close the program, shut down the rig. The options are obvious but if you have the facility such as auto sequence which gets reinstated when the next call comes in it is simply annoying.


73 Charlie

G4EST

www.g4est.me.uk

Stay safe out there

 

 

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Philip Rose via groups.io
Sent: 01 October 2021 16:52
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] QSO sequence #QSO_practices

 

Charlie,

 

You can choose to ignore them, by disabling TX before you have a chance to reply, or double-clicking on the call you do want to answer. The choice is all yours.

 

73 Phil GM3ZZA

 

Sent from Mail for Windows

 

From: chas cartmel
Sent: 01 October 2021 16:34
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] QSO sequence #QSO_practices

 

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

 

 

 

 


--
73 Phil GM3ZZA


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

6521 - 6540 of 35419