Date   

locked #install #macOS #install #macOS

Gerry Bay
 

I am running Mac OS 12.5 and SLAB V6. I recently upgraded to WSJT-X V 2.5.4. However, I’m now getting a rig control error message. It reads:

"Hamlib error: IO error
iofunc.c(181):port_open return(-6) IO error
serial.c(250):serial_open return(-6) IO error
serial_open(235): open failed#4
serial_open: Unable to open /dev/cu.SLAB_USBtoUART - No such file or directory
serial_open: Unable to open /dev/cu.SLAB_USBtoUART - No such file or directoryport_open: serial_open(/dev/cu.SLAB_USBtoUART) status=-6, err=No such file or directory
port_open: serial_open(/dev/cu.SLAB_USBtoUART) status=-6, err=No such file or directoryrig_open: rs->comm_state==0?=0
rig.c(833):rig_open return(-6) IO error
iofunc.c(181):port_open return(-6) IO error
serial.c(250):serial_open return(-6) IO error
serial_open(235): open failed#4
serial_open: Unable to open /dev/cu.SLAB_USBtoUART - No such file or directory
serial_open: Unable to open /dev/cu.SLAB_USBtoUART - No such file or directoryport_open: serial_open(/dev/cu.SLAB_USBtoUART) status=-6, err=No such file or directory
port_open: serial_open(/dev/cu.SLAB_USBtoUART) status=-6, err=No such file or directoryrig_open: rs->comm_state==0?=0
rig_open: rs->comm_state==0?=0 while opening connection to rig

Timestamp: 2022-08-10T14:48:23.113Z

Any thoughts on how to fix this would be appreciated….

Gerry
W1XY


locked #IssueReport 2.6.0-rc2 bug in "new period decodes on top" #IssueReport

Fred Goldstein
 

The RC2 is great. But I tried "new period decodes on top" and all it did was display a blank window -- no decodes were displayed at all. They were scrolled out.

program version -- 2.6.0-rc2
Operating system -- Windows 7 Pro

I was using it normally with scrolling decodes. I turned on the "new period decodes on top" and instead of scrolling down, new period decodes stayed out of view, above the window, so I only saw a blank window, though I could scroll up to see them.

For good measure I tried turning on and off the blank line between periods option, but that didn't make a difference. I'm using FT8 and FLrig.
- fred k1io


locked Re: Incorrect logged QSO times in WSJT-X Version 2.5.4 when running MSK144 #IssueReport #logging #MSK144

 

Gentlemen! Lots of good discussion about what the start time should be, BUT, that has nothing to do with my original complaint which is that WSJT-X sometimes logs the end time of a QSO as also being the start time. Regardless of what the start time is, it can NEVER be the same time as the end time.

--
John P.
WA2FZW


locked Re: Frequency offset between TX and RX #frequency #FreqCal

Hervé. (F1SKF)
 

Thank you to everyone who replied to me on this group and / or in private.
73
Herve
F1SKF


locked Re: U.S.A. CQers #band

Karl Beckman WA8NVW - NNV5BH
 

I am not aware that wildcards are supported, but then again I haven't yet taken time to read the user manual. Others on here certainly can provide the right answer.

--
Karl  WA8NVW  OH
WA8NVW@...
in WSJTX@groups.io


locked Re: U.S.A. CQers #band

Joe Subich, W4TV
 

Yes, you said JT Alert, I responded with a feature of JT Alert
that is much more flexible than turning off an entire continent.

73,

... Joe, W4TV

On 2022-08-10 8:38 AM, Michael Black via groups.io wrote:
Oh...you mean JTAlert.  I thought you were referring to something in lieu of JTAlert (i.e. WSJTX)
Mike W9MDB
On Wednesday, August 10, 2022 at 07:34:04 AM CDT, Joe Subich, W4TV <lists@...> wrote:
On 2022-08-09 11:21 PM, Michael Black via groups.io wrote:
> I must be blind...where is "DX Decodes" ?
In the "View type" selection box.  Right click on the panel
number - "Decodes: DX"
For the sake of completeness ... JT Alert also provides the ability
to ignore any arbitrary callsign (Settings -> Miscellaneous Alerts ->
Ignored Callsigns).
73,
    ... Joe, W4TV
On 2022-08-09 11:21 PM, Michael Black via groups.io wrote:
I must be blind...where is "DX Decodes" ?
Mike W9MDB


      On Tuesday, August 9, 2022 at 06:36:12 PM CDT, Joe Subich, W4TV <lists@...> wrote:
On 2022-08-09 4:49 PM, Michael Black via groups.io wrote:
  > If you're on Windows use JTAlert.  You can turn off North America.

You can also select "DX Decodes" which will display all decodes
from countries *other* that your own no matter what your country.

73,

      ... Joe, W4TV


locked Re: U.S.A. CQers #band

Michael Black
 

Oh...you mean JTAlert.  I thought you were referring to something in lieu of JTAlert (i.e. WSJTX)

Mike W9MDB

On Wednesday, August 10, 2022 at 07:34:04 AM CDT, Joe Subich, W4TV <lists@...> wrote:



On 2022-08-09 11:21 PM, Michael Black via groups.io wrote:
> I must be blind...where is "DX Decodes" ?

In the "View type" selection box.  Right click on the panel
number - "Decodes: DX"

For the sake of completeness ... JT Alert also provides the ability
to ignore any arbitrary callsign (Settings -> Miscellaneous Alerts ->
Ignored Callsigns).

73,

    ... Joe, W4TV


On 2022-08-09 11:21 PM, Michael Black via groups.io wrote:
I must be blind...where is "DX Decodes" ?
Mike W9MDB

 

      On Tuesday, August 9, 2022 at 06:36:12 PM CDT, Joe Subich, W4TV <lists@...> wrote:
 
 
On 2022-08-09 4:49 PM, Michael Black via groups.io wrote:
  > If you're on Windows use JTAlert.  You can turn off North America.

You can also select "DX Decodes" which will display all decodes
from countries *other* that your own no matter what your country.

73,

      ... Joe, W4TV


locked Re: U.S.A. CQers #band

Joe Subich, W4TV
 

On 2022-08-09 11:21 PM, Michael Black via groups.io wrote:
I must be blind...where is "DX Decodes" ?
In the "View type" selection box. Right click on the panel
number - "Decodes: DX"

For the sake of completeness ... JT Alert also provides the ability
to ignore any arbitrary callsign (Settings -> Miscellaneous Alerts ->
Ignored Callsigns).

73,

... Joe, W4TV


On 2022-08-09 11:21 PM, Michael Black via groups.io wrote:
I must be blind...where is "DX Decodes" ?
Mike W9MDB
On Tuesday, August 9, 2022 at 06:36:12 PM CDT, Joe Subich, W4TV <lists@...> wrote:
On 2022-08-09 4:49 PM, Michael Black via groups.io wrote:
> If you're on Windows use JTAlert.  You can turn off North America.
You can also select "DX Decodes" which will display all decodes
from countries *other* that your own no matter what your country.
73,
    ... Joe, W4TV


locked Re: Frequency offset between TX and RX #frequency #FreqCal

 

Hi Herve,

This is intentional behaviour. Your actual frequency is the dial frequency plus the audio frequency of your signal. On TX WST-X adjusts the dial frequency to keep the audio frequency between 1.5 kHz and 2 kHz. The two combinations (on RX and TX) should remain the same. This is for two reasons: 1) to prevent harmonics of the audio frequency from modulating your signal, 2) to keep the signal in the seet spot of your transmit filter.

73 Phil GM3ZZA

Sent from Mail for Windows

From: Hervé. (F1SKF)
Sent: 10 August 2022 09:44
To: main@WSJTX.groups.io
Subject: [WSJTX] Frequency offset between TX and RX #FreqCal #frequency

Hello,
I don't know what happened, but this morning using WSJT I notice that I have a 1 Khz mismatch between the receive and transmit frequency.
My transceiver is correct, no delay in voice when I press the microphone.
Transceiver also cprrect, when I command it with Flrig's PTT key.
Frequency offset is when WSJT goes TX with Enable TX or Tune!!
I don't see how to fix this problem.
Thank you for your help.
Herve
F1SKF








--
73 Phil GM3ZZA


locked ARE: [WSJTX] Frequency offset between TX and RX #frequency #FreqCal

Reino Talarmo
 

Hello Herve

You seems to use Split operation and your audio frequency is either below 500 Hz or above 3000 Hz. See User Manual 4.2. Radio last bullet point for details. All is working as designed!

73, Reino OH3mA


locked Re: Offset frequency #frequency

Pietro Molina
 

Herve, it's normal. TX and RX frequencies are not correlated. Usually you
choose your tx frequency where you prefer, and the rx is the frequency of
your correspondent.
Tone of WSJT is always 1500 Hz, and the rig moves the TX freq to achieve
the desired tone in the audio spectre.
If you move your tx frequency, the TX frequency of the rig moves to follow.

Pietro I2OIM

Il giorno mer 10 ago 2022 alle ore 10:44 Hervé. (F1SKF) <
herve.courtois@...> ha scritto:

Hello,
I have a problem since this morning with WSJT that I can't solve.
When WSJT goes on transmission, my transmitter transmits with a frequency
shift of 1 Khz between transmission and reception.
The transceiver is ok (no lag) when I press the mic or press the PPT
button on FLRIG.
The frequency offset is only with WSJT on the air!!
Any help would be appreciated.
73 QRO
Herve
F1SKF






locked Offset frequency #frequency

Hervé. (F1SKF)
 

Hello,
I have a problem since this morning with WSJT that I can't solve.
When WSJT goes on transmission, my transmitter transmits with a frequency shift of 1 Khz between transmission and reception.
The transceiver is ok (no lag) when I press the mic or press the PPT button on FLRIG.
The frequency offset is only with WSJT on the air!!
Any help would be appreciated.
73 QRO
Herve
F1SKF


locked Frequency offset between TX and RX #frequency #FreqCal

Hervé. (F1SKF)
 

Hello,
I don't know what happened, but this morning using WSJT I notice that I have a 1 Khz mismatch between the receive and transmit frequency.
My transceiver is correct, no delay in voice when I press the microphone.
Transceiver also cprrect, when I command it with Flrig's PTT key.
Frequency offset is when WSJT goes TX with Enable TX or Tune!!
I don't see how to fix this problem.
Thank you for your help.
Herve
F1SKF


locked Re: Hamlib 4.5 testing #hamlib

Reino Talarmo
 

Hi All,
When you have RFI problems, then Jim's K9YC net pages provides a lot of useful information. Most probably the discussed case is so called Pin 1 problem.
The shield cutting and ferrites may help as just a few dB less RF current in the victim wire could (marginally) solve the problem. Both help, if there is a low impedance to a common ground at both sides of the USB cable.
If an end fed antenna is used, then the "missing half" of the antenna i.e. a low impedance connection to ground needs to be arranges somehow. An end fed antenna is actually more or less a vertical antenna unless all station equipment are hanging in the air, including power supply, PC and operator such as in The Zeppelin case. RF always finds a way to ground (or to other wires or structures that form a suitable RF impedance). If that impedance is high, then voltage will be high as some current in flowing.
Typically that "missing" part of the antenna is outer shield of the feedline, rig enclosure, any wires connected to rig including USB cable, PC and any wires connected to PC including operator. A good symptom is mouse or touchpad that goes wild during transmission.
How we can divert RF current from entering into rig's or PC's sensitive circuits? (The sensitive circuit need not to be the actual USB chip, but some other related circuitry). The first should be a proper grounding or counterpoise at antenna feed point, next is a low impedance grounding of the enclosure of the rig. Now the remaining RF current flows on the USB cable as common mode. Best would be to by bypassing USB data and power lines by a low impedance. That means a good shielded cable, where the cable shield is only connected to the outer shells of connector and the shells are connected to enclosures outside or rig and PC. The latter requirement may be impossible due to various reason how connectors are wired to enclosure and circuit board ground. Another or additional method is to connect enclosures together by a short heavy wire. This may be impossible especially at the PC end. I have had some success by using VGA connector shell for that purpose.
The next method is to add common mode RF impedance of the UBSB cable by adding ferrites. That helps, if the PC happens to be a low impedance to ground. If the impedance of the PC to ground is high say hundreds of ohms, then a typical one turn ferrite clam with tens of ohms impedance has very little effect.
The shield cutting may help as the Pin 1 problem is minimized. We should remember that there are still data and power lines inside the USB cable and those will then curry the common mode current. The common mode RF current distribution inside the equipment may be less disturbing due to different impedances and well balanced data line construction. The shield cutting may as well make situation worse.

Better to stop now. In short it would be better to divert the common mode current to ground before it reaches the USB or some other RF sensitive connection cable.

73, Reino OH3mA


locked Re: Hamlib 4.5 testing #hamlib

Jim Brown
 

On 8/9/2022 9:45 PM, Tim Dawson wrote:
It's in a solid metal case -*THAT* is far better shielded than plastic or nothing
Not necessarily. Properly laid-out circuit boards using microstrip (traces above a CONTINUOUS "ground" layer) form transmission lines with that layer confines signal return current to the ground layer immediately under the trace, making the circuitry self-shielding. Stripline, (sandwiching the signal layer between a pair of "ground" layers) provides significantly greater shielding. These types of construction are necessary to prevent crosstalk between circuits.

Proper layout is the key -- the ground layer must not be interrupted under a trace, because it's no longer a transmission line.

. . . (there is far more to shielding than just the cable!)

YES. And for cable shielding to work, it must be bonded to the shielding enclosure AT BOTH ENDS, AT THE POINT OF ENTRY. If there's no shielding enclosure, it must be bonded to the ground layer of that microstrip or stripline board.

73, Jim K9YC


locked Re: U.S.A. CQers #band

David Ross
 

F4

David VA3MJR

On 2022-08-09 11:21 p.m., Michael Black via groups.io wrote:
I must be blind...where is "DX Decodes" ?
Mike W9MDB


On Tuesday, August 9, 2022 at 06:36:12 PM CDT, Joe Subich, W4TV<lists@...> wrote:
On 2022-08-09 4:49 PM, Michael Black via groups.io wrote:
> If you're on Windows use JTAlert.  You can turn off North America.

You can also select "DX Decodes" which will display all decodes
from countries *other* that your own no matter what your country.

73,

    ... Joe, W4TV

On 2022-08-09 4:49 PM, Michael Black via groups.io wrote:
If you're on Windows use JTAlert.  You can turn off North America.
Mike W9DMB


      On Tuesday, August 9, 2022 at 03:44:36 PM CDT, w5ec<bhw5ec@...> wrote:
  In most world wide DX contests, most of the CQ decodes are from USA stations which I don't want to contact.
This makes it hard for me to watch the fast moving decodes for elusive DX stations that I do want to contact.
Is there any way to easily and temporarily stop decoding USA stations during the contest and return to normal after the contest?











--


locked Re: Incorrect logged QSO times in WSJT-X Version 2.5.4 when running MSK144 #IssueReport #logging #MSK144

Gary - AG0N
 

On Aug 9, 2022, at 10:45, Michael Black via groups.io <mdblack98@...> wrote:

The times have been based on the transmit messages where it seems it would be better on the received messages.
Obviously, different people were tutored by different people. For those who don’t know, some of us started when logging was REQUIRED. The log contained the both the start and end time of the QSO. What’s a QSO? I have always assumed it is a two way communication. If you are calling CQ, that is not the beginning of the QSO, (but back then it would still require an entry in the log). Today, we don’t require that much detail. I consider the beginning of the QSO to be the beginning of a two way exchange. OK, you send CQ. We’re on 2M MSK144. I hear your CQ 5 minutes later, because there were no meteors that cooperated with the needed path….or I walked in and heard your CQ 5 minutes later and start answering. Pings are few and far behind, and you don’t hear my me for several minutes after I start calling you. The start of the QSO (2-way communication), for me, was the initial 5 minute delay, PLUS the amount of time I called before you heard me. I know people who have tried for days to get 2-way communications established. Your start time would be when you finally heard me calling you and you started sending the response to my call. My start time would be when I first heard your response to my call.

This sort of long delay QSO is very common and has been for decades. QSOs can take HOURS to complete, and yes, even days. It used to be fairly common. Most people don’’t have the patience to do this sort of operation, but in the early days of MS, it was pretty common.

There’s a lot more to consider than what you do on HF, where things are pretty reliable. Think about it.

73, Gary - AG0N


locked Re: Incorrect logged QSO times in WSJT-X Version 2.5.4 when running MSK144 #IssueReport #logging #MSK144

Reino Talarmo
 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Jim Brown
Sent: 9. elokuutata 2022 10:51

Hi Jim and Mike,

It seems that I receive some mails quite delayed and the responses may not match what have been sent between, hi! In any case same responses inline.

On 8/8/2022 10:16 PM, Reino Talarmo wrote:
With all respect of your problems you are actually introducing a third working related time "Caller's Start Time".
No, I did not. What I said is that the logging software sets the caller's "Start Time" under the conditions I described can often be 30-90 minutes before the QSO actually takes place, it takes place over
1-2 minutes, and the DX logs it when HE responds to the caller. In the conditions I described, these Starting Times are 30-90 minutes apart.

That caller's "Start Time" is a totally wrong start time! The proper one is, when the caller gets a response from the DX (minus 15 s or perhaps minus 30 s, but that's irrelevant compared to 30 min tolerance). Before that caller has only tried to start a QSO; almost same as a CQ'er would set start time, when he starts calling CQ, well not really. Only a received response is a start of a real QSO. It is close to the time DX logs as well, isn't it!

[I think that this is not only a wsjt-x problem. Some logging programs could mark a start time once you just type the call sign of the DX.]

Yes, but it doesn't matter. What matters is that they log the Start Time of the QSO within 30 minutes of each other. This is a STANDARD, which in the context of this discussion, is poorly conceived, but it is the STANDARD, and we have to live with it.
So start time is passed, when you have received first response from the DX (Tx2 or Tx3 depending what you sent). That time will also be the one DX is considering as the start time as you pointed. (With the same principle DX station should set start time for each caller in a pile-up to those he happens to decode each station first time.)

I think that Mike is now implementing Start time using this principle.

Of course there are additional delays, when messages are lost. But seldom more than 30 minutes! The lost message problem exists also at the definition of the end time. On the other hand FT8 AP helps at that time quite a lot and messages get though easier.

GN and 73, Reino OH3mA


locked Re: Incorrect logged QSO times in WSJT-X Version 2.5.4 when running MSK144 #IssueReport #logging #MSK144

Joe Subich, W4TV
 

All of this assumes no repeated messages ...e.g., the "missing 73"
and the need to repeat the RRR or RR73 messages which is currently
the subject of much debate on the FFMA list.

Frankly, the software should automatically log the end time when
R-02, RR73 or RRR are *first sent* (depending on the sequence) as
sending an acknowledgement of the receipt of the unique information
(signal report or grid square) defines a completed QSO, *whether or*
*not* the other station acknowledges receipt of the acknowledgement.

There can be a one sequence difference in the end time for stations
on even/odd sequences but that will not be an issue for LotW since
the LotW "matching window" is triggered on start time.

73,

... Joe, W4TV

On 2022-08-09 2:10 PM, Michael Black via groups.io wrote:
Without the HTML formatting...
The times have been based on the transmit messages where it seems it would be better on the received messages.
I'm working on it right now so the reception of TX1, TX2 or TX3 will set time to the start of the period (i.e. will subtract the time periods involved)
We have to allow for tail-ending, plus those who skip TX1.
So...this tail-end sequence with an RR73 ending the QSO (no extra 73)
130000 W9MDB K9YC RR73
130015 K9YC OH3MA -03
130030 OH3MA K9YC R-02
130045 K9YC OH3MA RR73
Start time should be 130015 on both sides of the QSO
Stop stop should be 130045 on both sides of the QSO since the logging window pops up on RR73
A subsequent
140000 OH3MA K9YC 73
will not change the QSO stop time.
Then we have the non-tail QSO
130000 CQ K9YC CM87
130015 K9YC OH3MA -03
130030 OH3MA K9YC R-02
130045 K9YC OH3MA RR73
Same logic applies -- start time should be 130015 on both sides based on the 1st message received.
Mike W9MDB


locked Re: Incorrect logged QSO times in WSJT-X Version 2.5.4 when running MSK144 #IssueReport #logging #MSK144

Jim Brown
 

On 8/9/2022 9:45 AM, Sam Birnbaum via groups.io wrote:
Would it be possible for you in the next contest using msk144 to uncheck the Auto log option and use the prompt me to log option for a few QSO's and see if that changes the time off value.
This issue has NOTHING to do with Contesting.

73, Jim K9YC

3061 - 3080 of 39846