Date   

locked Re: odd behavior after update to WSJT-X 2.5.4 #Icom

John Wiener
 

I will add that the Mac audio input shows appropriate varying input level bars.


locked Re: odd behavior after update to WSJT-X 2.5.4 #Icom

John Wiener
 

Yes. Appears normal.


locked Re: Why frequencies steps are not locked on 50Hz? #frequency

Pedro Silva <cs7bac@...>
 

Yes, i got it and i had no clue that the decoder can handle much smaller
chunks like this.
in this case, no doubt we are in the perfect path.
Thanks guys!
73

On Wed, May 4, 2022 at 8:29 AM Ellis Birt (G7SAI) via groups.io <ellis.birt=
googlemail.com@groups.io> wrote:

To elaborate, if you consider the ft8 band to be 2kHz wide, that is 40
50Hz bands. The decoder can discriminate between signals much closer, I.e.
overlapping. A 10Hz step can accommodate 200 signals.

Now factor in people transmitting 'over' others signals because they
cannot hear them. If there are only 40 slots, this is more likely. It is
highly unlikely two signals will exactly overlay each other, allowing the
decoder to decode both.

The elephant in the room is the strong local station of the one
over-modulating which can overwhelm your receive path.






locked Re: Why frequencies steps are not locked on 50Hz? #frequency

Ellis Birt (G7SAI)
 

To elaborate, if you consider the ft8 band to be 2kHz wide, that is 40 50Hz bands. The decoder can discriminate between signals much closer, I.e. overlapping. A 10Hz step can accommodate 200 signals.

Now factor in people transmitting 'over' others signals because they cannot hear them. If there are only 40 slots, this is more likely. It is highly unlikely two signals will exactly overlay each other, allowing the decoder to decode both.

The elephant in the room is the strong local station of the one over-modulating which can overwhelm your receive path.


locked Re: connecting to WSJT and radio issue #WSPR

Reino Talarmo
 

Hi,I write all my settings down for setting up WSJT.It usually has worked but now it won't connect my radio.Hamlib error.I have a Rigblaster Plug and play.Also I spit the port as I use it with 2 programs at once.Using a Kenwood TS2000.I tried closing the com spitter and using the master port and it still won't work.So not sure what to do.I was told to rase the >ini file and that resets the software but I don't see a .IMI file in WSJT folder.
Hi Rich,
First of all a com port splitter can not work, if there is any two directional traffic on the second connection.
You can include the Hamlib error details into your mail by first opening the details and then copy it using Ctrl-C and Ctrl-V in the mail message. Without that information it is difficult to help any further.
The wsjt-x.ini file is in the directory where you can go by File | Open log directory. A resetting as such may not help unless you have messed wsjt-x settings. A reset will erase all settings and you need to do those again.
73, Reino OH3mA


locked Re: Why frequencies steps are not locked on 50Hz? #frequency

Alan G4ZFQ
 

I think it would be much more organized and band efficient if the frequency choice for Tx and Rx was only possible in 50Hz steps, as this is the chunk for one FT8 tone.
Pedro,

This would be very inefficient:-)
The decoders work very well on signals which are very close together.

73 Alan G4ZFQ


locked Why frequencies steps are not locked on 50Hz? #frequency

Pedro Silva <cs7bac@...>
 

Hi!
I believe someone already had this idea before, but anyway...
I think it would be much more organized and band efficient if the frequency choice for Tx and Rx was only possible in 50Hz steps, as this is the chunk for one FT8 tone.
As per my observation the spectrum is always messy due to a lot of people transmitting in completely off-position frequencies, and when many people do the same we reduce the effective quantity of available slots, as many people overlap one another.
Thanks!
73
CS7BAC
Pedro Silva


locked Re: odd behavior after update to WSJT-X 2.5.4 #Icom

Gary Rogers
 

John are there any signals displayed on the waterfall?

On May 3, 2022, at 7:35 PM, John Wiener <jawodms@...> wrote:

IC-7300 ver 1.30. to Mac Mini OSX 12.3.1
Earlier today, I had some squirrelly behavior...I can't recall exactly but it had to do with not transmitting. I looked at the version i had...2.5.0? So, I updated to the current 2.5.4 version of WSJT-X per instructions for Mac and accessed the Terminal Bar, etc.and it worked fine...worked good DX on 15 and 17M in the afternoon.
This evening, it worked well until I switched to 20M
Then the (audio) Power bar on the right side started to work in reverse: mouse mvt opposite that of the level button...and the output increased towards the bottom of the scale...
-45 dB at the top and 0 dB at the bottom.
AND it does not decode...I checked the audio settings and they seem OK.
I am not aware that I made any changes.
This is a weird one... Thanks
John AB8O





locked odd behavior after update to WSJT-X 2.5.4 #Icom

John Wiener
 

IC-7300 ver 1.30. to Mac Mini OSX 12.3.1
Earlier today, I had some squirrelly behavior...I can't recall exactly but it had to do with not transmitting. I looked at the version i had...2.5.0? So, I updated to the current 2.5.4 version of WSJT-X per instructions for Mac and accessed the Terminal Bar, etc.and it worked fine...worked good DX on 15 and 17M in the afternoon.
This evening, it worked well until I switched to 20M
Then the (audio) Power bar on the right side started to work in reverse: mouse mvt opposite that of the level button...and the output increased towards the bottom of the scale...
-45 dB at the top and 0 dB at the bottom.
AND it does not decode...I checked the audio settings and they seem OK.
I am not aware that I made any changes.
This is a weird one... Thanks
John AB8O


locked connecting to WSJT and radio issue #WSPR

Rich
 

Hi,I write all my settings down for setting up WSJT.It usually has worked but now it won't connect my radio.Hamlib error.I have a Rigblaster Plug and play.Also I spit the port as I use it with 2 programs at once.Using a Kenwood TS2000.I tried closing the com spitter and using the master port and it still won't work.So not sure what to do.I was told to rase the >ini file and that resets the software but I don't see a .IMI file in WSJT folder.
73
RIch


locked 1x1 call sign "bug" in WSPR spotting #WSPR #IssueReport

Bruce KX4AZ
 

I posted about this issue recently in the context of a special event beacon I was working with, but wanted to make sure the WSJT-x developers are aware of it. The WSPR protocol allows for the transmission of a special 3 character 1x1 call sign such as N1D, but on the decoding end (i.e. wsprd) the spots are not uploaded. Only some of the (perhaps older) obscure decoders such as that used in the KiwiSDR (aka Kiwi 1.3) will upload a 1x1 call sign spot in WSPR. My workaround was to use the compound call sign N1D/4, but I would have preferred the "plain" 'N1D' call sign.

It's a an obscure issue, of course, but hopefully not a difficult thing to address in a future iteration. As far as I know the decode process works, just not the upload process.


locked Re: WSJT-X 2.5.4 PTT Serial Issue #IssueReport #Cat_RigControl #WSJTX_config #Yaesu #linux

Michael Black
 

I believe if you tried the newest hamlib you'd see a better error message.The more useful error would've scrolled off the screen.
You probably have Hamlib 4.4 installed.
I'm going to look at keeping a bit more history as frequently the most important error message scrolls off the screen.
Mike W9MDB

On Tuesday, May 3, 2022, 01:56:40 AM CDT, Kristian Glass <groupsio@...> wrote:

You're a star Mike, thanks - all fixed now! Issue not caused by WSJT-X at all - the error message and failure mode led me down the wrong path.

For reference:

Mike's config enabled useful debugging logging for WSJT-X. From the logfile I saw:

```
[RIGCTRL][2022-05-02 21:45:16.912823][00:00:17.759554][error] rig_open: cannot open PTT device "/dev/serial/by-id/usb-1a86_USB2.0-Ser_-if00-port0"
```

And I realised the PTT serial device was completely missing. I'd not thought to check this, because the failure mode was a total lack of *CAT* connection, so I'd been inspecting the CAT side of things.

Looking in dmesg I saw:

```
[39435.282608] usbcore: registered new interface driver ch341                                                                         
[39435.282633] usbserial: USB Serial support registered for ch341-uart                                                                 
[39435.282655] ch341 2-3.2:1.0: ch341-uart converter detected                                                                         
[39435.285588] usb 2-3.2: ch341-uart converter now attached to ttyUSB1                                                                 
[39435.642764] usb 2-3.2: usbfs: interface 0 claimed by ch341 while 'brltty' sets config #1                                           
[39435.643649] ch341-uart ttyUSB1: ch341-uart converter now disconnected from ttyUSB1                                                 
[39435.643668] ch341 2-3.2:1.0: device disconnected                                   
```

so the device was noticed, but then for some reason the tty device was disconnected.

Looking in my udev rules for `brltty` (and confirmed by https://stackoverflow.com/q/70123431/928098) it looks like in the Ubuntu upgrade I'd gained udev rules for a Braille e-reader that used the same serial converter. As I don't use Braille e-readers, I could just `sudo apt remove brltty`, and then `modprobe -r ch341 && modprobe ch341` to re-probe the serial device, and bam, return of the tty.

And now everything works - thanks again Mike!

WSJT-X wasn't at fault here, *but*:

* It would have been great to have more detailed information in the error popup, like the actual device name
* This logging config feels really useful - the kind of thing it would be great to have more discoverable (e.g. configurable from within WSJT-X so I could have stumbled across it myself)
* Since there was nothing wrong with the *CAT* config, it would have been great if that part had succeeded in the event of an issue with *PTT* config - that would have probably had me looking harder in the right place

But, fundamentally, I'm good to go now - cheers!


locked Re: WSJT-X 2.5.4 PTT Serial Issue #IssueReport #Cat_RigControl #WSJTX_config #Yaesu #linux

William Smith
 

Very nice, thank you!

73, Willie N1JBJ


On May 3, 2022, at 7:26 AM, Thomas, SM0KBD <sm0kbd@...> wrote:

Hi,

this is how I do it to get around the problem with the changing device-names:

https://www.thuben.com/amateur/software/fixed-devices

As pointed out on the page, it is important to find something which is significant for your rig. For Yaesu it should be possible to find a serial number or so. I already see that the A / B in the Icom case probably is port0 / port1 in the Yaesu case.

BR

---
Thomas, SM0KBD
sm0kbd@...
https://www.thuben.com/amateur

2022-05-03 00:17 skrev Kristian Glass:
You're a star Mike, thanks - all fixed now! Issue not caused by WSJT-X
at all - the error message and failure mode led me down the wrong
path.
For reference:
Mike's config enabled useful debugging logging for WSJT-X. From the
logfile I saw:
```
[RIGCTRL][2022-05-02 21:45:16.912823][00:00:17.759554][error]
rig_open: cannot open PTT device
"/dev/serial/by-id/usb-1a86_USB2.0-Ser_-if00-port0"
```
And I realised the PTT serial device was completely missing. I'd not
thought to check this, because the failure mode was a total lack of
*CAT* connection, so I'd been inspecting the CAT side of things.
Looking in dmesg I saw:
```
[39435.282608] usbcore: registered new interface driver ch341
[39435.282633] usbserial: USB Serial support registered for ch341-uart
[39435.282655] ch341 2-3.2:1.0: ch341-uart converter detected
[39435.285588] usb 2-3.2: ch341-uart converter now attached to ttyUSB1
[39435.642764] usb 2-3.2: usbfs: interface 0 claimed by ch341 while
'brltty' sets config #1
[39435.643649] ch341-uart ttyUSB1: ch341-uart converter now
disconnected from ttyUSB1
[39435.643668] ch341 2-3.2:1.0: device disconnected
```
so the device was noticed, but then for some reason the tty device was
disconnected.
Looking in my udev rules for `brltty` (and confirmed by
https://stackoverflow.com/q/70123431/928098) it looks like in the
Ubuntu upgrade I'd gained udev rules for a Braille e-reader that used
the same serial converter. As I don't use Braille e-readers, I could
just `sudo apt remove brltty`, and then `modprobe -r ch341 && modprobe
ch341` to re-probe the serial device, and bam, return of the tty.
And now everything works - thanks again Mike!
WSJT-X wasn't at fault here, *but*:
* It would have been great to have more detailed information in the
error popup, like the actual device name
* This logging config feels really useful - the kind of thing it would
be great to have more discoverable (e.g. configurable from within
WSJT-X so I could have stumbled across it myself)
* Since there was nothing wrong with the *CAT* config, it would have
been great if that part had succeeded in the event of an issue with
*PTT* config - that would have probably had me looking harder in the
right place
But, fundamentally, I'm good to go now - cheers!




locked Re: WSJT-X 2.5.4 PTT Serial Issue #IssueReport #Cat_RigControl #WSJTX_config #Yaesu #linux

Thomas, SM0KBD
 

Hi,

this is how I do it to get around the problem with the changing device-names:

https://www.thuben.com/amateur/software/fixed-devices

As pointed out on the page, it is important to find something which is significant for your rig. For Yaesu it should be possible to find a serial number or so. I already see that the A / B in the Icom case probably is port0 / port1 in the Yaesu case.

BR

---
Thomas, SM0KBD
sm0kbd@...
https://www.thuben.com/amateur

2022-05-03 00:17 skrev Kristian Glass:

You're a star Mike, thanks - all fixed now! Issue not caused by WSJT-X
at all - the error message and failure mode led me down the wrong
path.
For reference:
Mike's config enabled useful debugging logging for WSJT-X. From the
logfile I saw:
```
[RIGCTRL][2022-05-02 21:45:16.912823][00:00:17.759554][error]
rig_open: cannot open PTT device
"/dev/serial/by-id/usb-1a86_USB2.0-Ser_-if00-port0"
```
And I realised the PTT serial device was completely missing. I'd not
thought to check this, because the failure mode was a total lack of
*CAT* connection, so I'd been inspecting the CAT side of things.
Looking in dmesg I saw:
```
[39435.282608] usbcore: registered new interface driver ch341
[39435.282633] usbserial: USB Serial support registered for ch341-uart
[39435.282655] ch341 2-3.2:1.0: ch341-uart converter detected
[39435.285588] usb 2-3.2: ch341-uart converter now attached to ttyUSB1
[39435.642764] usb 2-3.2: usbfs: interface 0 claimed by ch341 while
'brltty' sets config #1
[39435.643649] ch341-uart ttyUSB1: ch341-uart converter now
disconnected from ttyUSB1
[39435.643668] ch341 2-3.2:1.0: device disconnected
```
so the device was noticed, but then for some reason the tty device was
disconnected.
Looking in my udev rules for `brltty` (and confirmed by
https://stackoverflow.com/q/70123431/928098) it looks like in the
Ubuntu upgrade I'd gained udev rules for a Braille e-reader that used
the same serial converter. As I don't use Braille e-readers, I could
just `sudo apt remove brltty`, and then `modprobe -r ch341 && modprobe
ch341` to re-probe the serial device, and bam, return of the tty.
And now everything works - thanks again Mike!
WSJT-X wasn't at fault here, *but*:
* It would have been great to have more detailed information in the
error popup, like the actual device name
* This logging config feels really useful - the kind of thing it would
be great to have more discoverable (e.g. configurable from within
WSJT-X so I could have stumbled across it myself)
* Since there was nothing wrong with the *CAT* config, it would have
been great if that part had succeeded in the event of an issue with
*PTT* config - that would have probably had me looking harder in the
right place
But, fundamentally, I'm good to go now - cheers!


locked Re: WSJT-X 2.5.4 PTT Serial Issue #IssueReport #Cat_RigControl #WSJTX_config #Yaesu #linux

Kristian Glass
 

You're a star Mike, thanks - all fixed now! Issue not caused by WSJT-X at all - the error message and failure mode led me down the wrong path.

For reference:

Mike's config enabled useful debugging logging for WSJT-X. From the logfile I saw:

```
[RIGCTRL][2022-05-02 21:45:16.912823][00:00:17.759554][error] rig_open: cannot open PTT device "/dev/serial/by-id/usb-1a86_USB2.0-Ser_-if00-port0"
```

And I realised the PTT serial device was completely missing. I'd not thought to check this, because the failure mode was a total lack of *CAT* connection, so I'd been inspecting the CAT side of things.

Looking in dmesg I saw:

```
[39435.282608] usbcore: registered new interface driver ch341
[39435.282633] usbserial: USB Serial support registered for ch341-uart
[39435.282655] ch341 2-3.2:1.0: ch341-uart converter detected
[39435.285588] usb 2-3.2: ch341-uart converter now attached to ttyUSB1
[39435.642764] usb 2-3.2: usbfs: interface 0 claimed by ch341 while 'brltty' sets config #1
[39435.643649] ch341-uart ttyUSB1: ch341-uart converter now disconnected from ttyUSB1
[39435.643668] ch341 2-3.2:1.0: device disconnected
```

so the device was noticed, but then for some reason the tty device was disconnected.

Looking in my udev rules for `brltty` (and confirmed by https://stackoverflow.com/q/70123431/928098) it looks like in the Ubuntu upgrade I'd gained udev rules for a Braille e-reader that used the same serial converter. As I don't use Braille e-readers, I could just `sudo apt remove brltty`, and then `modprobe -r ch341 && modprobe ch341` to re-probe the serial device, and bam, return of the tty.

And now everything works - thanks again Mike!

WSJT-X wasn't at fault here, *but*:

* It would have been great to have more detailed information in the error popup, like the actual device name
* This logging config feels really useful - the kind of thing it would be great to have more discoverable (e.g. configurable from within WSJT-X so I could have stumbled across it myself)
* Since there was nothing wrong with the *CAT* config, it would have been great if that part had succeeded in the event of an issue with *PTT* config - that would have probably had me looking harder in the right place

But, fundamentally, I'm good to go now - cheers!


locked Re: WSJT-X Schema negotiation #networking

Stephen Houser, N1SH
 

Perhaps I have found the solution on my own via experimentation.

The "responses" going back to WSJT-X need to be unicast packets to the source port WSJT-X is sending from, not to the multicast group.

I'm sure there is some reasoning here, perhaps to prevent "looping" data, but it is not clear in any documentation I could find that this is the proper communication path.

If this thinking is incorrect, please do let me know.

Stephen, N1SH


locked WSJT-X Schema negotiation #networking

Stephen Houser, N1SH
 

I am working to understand and get schema negotiation working correctly so I can properly parse WSJT-X datagrams in NodeRed. I am working across two different instances of WSJT-X, one on macOS (v2.5.4) and one on Ubuntu (v2.5.4). In both cases WSJT-X sends it's initial heartbeat message encoded with schema v2 and shows as accepting up to v3. I am working with a multicast group (224.0.0.1) port 2237.

How do I properly respond that I would like to get messages encoded with schema v3 if WSJT-X fresh-starts with schema v2?

Reading https://wsjtx.groups.io/g/main/topic/78427820#18644
---
... Each new application joining the "mesh" shall wait for a Heartbeat message and examine the current schema being used, it shall then reply with another Heartbeat message that contains the highest schema number it can work with. The WSJT-X client receiving that Heartbeat message will adjust it's outgoing schema by lowering it to match if necessary. That in turn will be received by all server applications in the "mesh" and they in turn will adjust if necessary. The result, eventually, will be all applications will settle on the adjusted schema number. You application shall always monitor the schema number of incoming traffic and be prepared to move to a lower schema number. It is forbidden to send a message with a higher schema number than any previously received schema number in a given operating session.
---

My reading of this is to send a heartbeat encoded with schema v2, specifying max schema v3 to the same multicast group and port. However even after I do this, I continue to receive packets encoded with schema v2. There are no other clients or servers on the network, just WSJT-X and NodeRed (with a single UDP listener)

Thank you for any assistance and guidance. I feel like I'm missing something blatantly obvious.

Stephen, N1SH

UDP Server: 224.0.0.1
UDP Server port number: 2237
(checked) Accept UDP requests
(checked) Notify on accepted UDP request
(checked) Accepted UDP request restores window


locked Re: #EnhancementReqest Choice of either 4 or 6 digit grid square #EnhancementReqest

PATRICK COKER
 

Yes no need for 73 , remove 73 and make 6 digit grid
My thoughts
N6rmj

On May 2, 2022, at 3:03 PM, Frank Kelly <wb6cwn@...> wrote:




Hello WSJT Team,
Q65 works very well on the microwave bands. The work on Q65 to provide for
doppler and other sources of frequency shift shows benefit and promise.
Thank you!

WANTED: A simple check-box like allowance for either 4 OR 6 digit grid
squares in the exchange report.

WHY: Six digit grid exchanges are needed for microwave contests and
distance claim records. The current WSJT workaround using the six digit EU
contest exchange check-box adds a QSO number to the exchange which is
unnecessary and out of place in the US. Sending the grid manually is not
practical in a contest. The current QSO exchange mechanism and format is
fine microwave contacts, the grid squares exchanged just need two more
digits for some contacts.

Thank you.

Frank
WB6CWN





locked #EnhancementReqest Choice of either 4 or 6 digit grid square #EnhancementReqest

Frank Kelly
 


Hello WSJT Team,
Q65 works very well on the microwave bands. The work on Q65 to provide for
doppler and other sources of frequency shift shows benefit and promise.
Thank you!

WANTED: A simple check-box like allowance for either 4 OR 6 digit grid
squares in the exchange report.

WHY: Six digit grid exchanges are needed for microwave contests and
distance claim records. The current WSJT workaround using the six digit EU
contest exchange check-box adds a QSO number to the exchange which is
unnecessary and out of place in the US. Sending the grid manually is not
practical in a contest. The current QSO exchange mechanism and format is
fine microwave contacts, the grid squares exchanged just need two more
digits for some contacts.

Thank you.

Frank
WB6CWN


locked Re: #NewUser #NewUser

Jim Bacher - WB8VSU
 

Ralph, wsjt-x needs to be able to control the radio and have access to the audio. If they loaded correctly they will automatically engage when the radio is turned on.

In wsjt-x settings you should be able to select the correct audio devices and control ports.

You can go into Windows "Device Manager" and confirm that Windows is seeing the audio and com ports. That can help confirm you have the settings in wsjt-x correct.

⁣Jim Bacher, WB8VSU
wb8vsu@...
https:\\trc.guru​

On May 2, 2022, 3:38 PM, at 3:38 PM, Ralph Crumrine <ralph.crumrine@...> wrote:
Yes, loaded but not opened. Are they required for the most basic mode
of operation of WSJTX? Can I not manually set up the transceiver for
the frequency and mode of modulation, USB?
On Monday, May 2, 2022, 08:54:30 AM CDT, Jim Bacher - WB8VSU
<wb8vsu@...> wrote:

Ralph, have you loaded the Kenwood drivers off of the Kenwood site?

⁣Jim Bacher, WB8VSU
wb8vsu@...
https:\\trc.guru​

On May 2, 2022, 9:36 AM, at 9:36 AM, Ralph Crumrine
<ralph.crumrine@...> wrote:
I have the WSJTX software loaded and running on a Win10, latest
version
software desktop. This is connected to the TS-590s via an USB A-B
cable. When running through the settings, I get an error message,
"invalid audio input device." Also, nothing happens when I try "tune."
I suspect that sound in and out is not set right.  None of the
instructions I have tried have sound card descriptions that match what
I see when I use the sound control panel. I'm new to this so I'm
looking for some help.

Thanks









4281 - 4300 of 37978