|
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,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
|
|
|
|
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>
Jeff Townsend WB8LYJ
|
|
|
|
locked
Re: Possible bug with tune button on 2.5.0 GA
#IssueReport
#Yaesu
#Cat_RigControl
#transmit
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,
|
|
|
|
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
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
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
|
|
|
|
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.
|
|
|
|
Dave (NK7Z)
Please share on list if possible, this also interests me.
toggle quoted messageShow quoted text
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.
|
|
|
|
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
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:
|
|
|
|
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. 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. On 10/1/2021 10:54 AM, chas cartmel wrote:
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. On 10/1/2021 8:54 AM, chas cartmel wrote:
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.
On 10/1/2021 10:54 AM, chas cartmel
wrote:
|
|
|
|
locked
Re: QSO sequence
#QSO_practices
Robert Lorenzini
Charlie here is the US a call sign is no longer a indicator of
location.
toggle quoted messageShow quoted text
Bob - wd6dod
On 10/1/2021 8:54 AM, chas cartmel
wrote:
|
|
|
|
locked
Re: QSO sequence
#QSO_practices
chas cartmel
Not exactly easy in the 2 second gap. 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
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
|
|
|
