Date   

locked Re: WSJT-X v2.2.2 WSPR error message

Erwin - PE3ES - F4VTQ
 

Yes here as well, on WIN10 with OpenHPSDR as feed.

By the way, same error message happens with JTDx RC151 or earlier but not in this combination but for longer runs of FT8 on ARM64 and other OS's.
--
PE3ES / F4VTQ
de Erwin


locked Re: Can Anyone Identify these two decodes of 1IO/IL0HBU

Joe Subich, W4TV
 

The ITU call sign blocks are recommendations and guidelines, not law
or not regulations.
The callsign blocks are international regulation (ie, treaty).

See: https://en.wikipedia.org/wiki/Non-ITU_prefix for examples.
The only *current* non-ITU prefix with any legal status are 1A0 and
S0 which should probably be replaced with "official" prefixes. 1A0
is the only "legitimate" use of the "unavailable" blocks.

All of the other "prefixes" shown in the "Table of Non-ITU radio
prefixes" have been abandoned, replaced or are areas in rebellion (e.g., 1B, 1C, 1X, D0/D1, O1) and legally considered "Pirate" operations by
the generally recognized government of the specific territory.

S0 is a de facto United Nations Protectorate (territory claimed by 5A).

Z6 is recognized by the European Union, the United States, the United
Kingdom, Canada and a majority of the world's nations. Z6 has been
assigned for aviation use by the ICAO but an "official" ITU assignment
has been vetoed by Russia at the behest of Serbia.

Still, since 1x, 0x and Qx are not assignable it makes little or no
sense to support the entire blocks (e.g., 1I) in the JT##, FT#, WSPR,
etc. protocol tables. If necessary, 1A (only) could be supported as
an exception preserving table space for other "exceptions" (like 3DA0,
etc.) as publicly documented.

73,

... Joe, W4TV


On 2020-07-31 1:22 PM, Kai-KE4PT wrote:
Joe,
The ITU call sign blocks are recommendations and guidelines, not law or not regulations. There are many non-ITU call signs in use, including several DXCC entities. They are not "illegal" and should remain in the WSJT-X protocol.
See: https://en.wikipedia.org/wiki/Non-ITU_prefix    for examples.
Cheers,
Kai, KE4PT
On 7/31/2020 13:02, Kai wrote:
This would appear to be a "false decode" although I wonder why
K1JT et. al. would waste the space in the protocol for an "illegal"
prefix block: <https://www.itu.int/en/ITU-R/terrestrial/fmd/Pages/call_sign_series.aspx>.


locked Re: 1/3 less power output with MSK144?

Lance Collister, W7GJ <w7gj@...>
 

Hi Bill,

MNI TNX for the clarification on this! VY 73, Lance

On 7/31/2020 19:25:55, Bill Somerville wrote:
On 31/07/2020 17:37, Lance Collister, W7GJ wrote:
Several of us have wondered why the wattmeter drops when the mode is switched from
FT8, JT65, or tune, etc. to MSK144. I checked the User Guide but couldn't find any
information about it. Is there some different way the tones are presented in
MSK144 that causes the power output to be read differently, or does this indicate
some problem with our sound cards not having the dynamic range to be able to
maintain the same output volume at different frequencies? Is there some
equalization we should be doing to fix this? Or is there some other software
reason for the power reduction? Thanks for any suggestions/insight!

VY 73, Lance
Hi Lance,

MSK144 modulation bandwidth is a little bit wider than a typical SSB Tx filter,
that means that the outermost sidebands are attenuated, and therefore the signal is
not quite constant envelope. The reduction of power by a dB or so is not really
significant but you should not attempt to recover it by increasing audio drive to
your rig. Set up for full power with a single tune tone and leave levels there for
calling and QSOs. Aiming for near minimum ALC action on your transmitter with a
single tone in the centre of the Tx passband is a good rule of thumb.

73
Bill
G4WJS.


--
Lance Collister, W7GJ(ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX, 3D2LR, 5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ, S79GJ, TX7MB)
P.O. Box 73
Frenchtown, MT 59834-0073
USA
TEL: (406) 626-5728
QTH: DN27ub
URL: http://www.bigskyspaces.com/w7gj
Skype: lanceW7GJ
2m DXCC #11 - 6m DXCC #815 - FFMA #7

Interested in 6m EME? Ask me about subscribing to the Magic Band EME
email group, or just fill in the request box at the bottom of my web
page (above)!


locked Re: 1/3 less power output with MSK144?

Bill Somerville
 

On 31/07/2020 17:37, Lance Collister, W7GJ wrote:
Several of us have wondered why the wattmeter drops when the mode is switched from FT8, JT65, or tune, etc. to MSK144. I checked the User Guide but couldn't find any information about it. Is there some different way the tones are presented in MSK144 that causes the power output to be read differently, or does this indicate some problem with our sound cards not having the dynamic range to be able to maintain the same output volume at different frequencies? Is there some equalization we should be doing to fix this? Or is there some other software reason for the power reduction? Thanks for any suggestions/insight!

VY 73, Lance
Hi Lance,

MSK144 modulation bandwidth is a little bit wider than a typical SSB Tx filter, that means that the outermost sidebands are attenuated, and therefore the signal is not quite constant envelope. The reduction of power by a dB or so is not really significant but you should not attempt to recover it by increasing audio drive to your rig. Set up for full power with a single tune tone and leave levels there for calling and QSOs. Aiming for near minimum ALC action on your transmitter with a single tone in the centre of the Tx passband is a good rule of thumb.

73
Bill
G4WJS.


locked HELP: Automatic log in to HRD Logbook not working

Charles Ristorcelli
 

My WSJT-X / JTAlert combination do noy log contacts automatically to HRD Logbook.

Set up as defined in the user manuals.


locked Re: Can Anyone Identify these two decodes of 1IO/IL0HBU

Kai-KE4PT
 

Joe,
The ITU call sign blocks are recommendations and guidelines, not law or not regulations. There are many non-ITU call signs in use, including several DXCC entities. They are not "illegal" and should remain in the WSJT-X protocol.
See: https://en.wikipedia.org/wiki/Non-ITU_prefix    for examples.

Cheers,
Kai, KE4PT

On 7/31/2020 13:02, Kai wrote:
This would appear to be a "false decode" although I wonder why
K1JT et. al. would waste the space in the protocol for an "illegal"
prefix block: <https://www.itu.int/en/ITU-R/terrestrial/fmd/Pages/call_sign_series.aspx>.


locked Re: Can Anyone Identify these two decodes of 1IO/IL0HBU

Kai-KE4PT
 

I have The Sovereign Military Order of Malt 1A0C (on JT65), and 1A0KM (CW and SSB), both confirmed on LoTW and by paper QSLs.

Cheers
Kai, KE4PT

On 7/31/2020 12:19, Joe Subich, W4TV wrote:

> I had two different time-slot decodes for *1IO/IL0HBU*

Any prefix that starts with the number 1 is not valid - the
1AA-1ZZ block is not used by the ITU (also 0AA-0ZZ and QAA-QZZ).

This would appear to be a "false decode" although I wonder why
K1JT et. al. would waste the space in the protocol for an "illegal"
prefix block: <https://www.itu.int/en/ITU-R/terrestrial/fmd/Pages/call_sign_series.aspx>.

73,

   ... Joe, W4TV


On 2020-07-31 11:01 AM, Dick Bingham wrote:
Greetings Everyone

I had two different time-slot decodes for *1IO/IL0HBU* on 80-meter WSPR I can not identify (see below)
When I enter that call in the WSPRNET map nothing shows up for that call.

Seems odd two random/bogus decodes would be exactly the same.

73  Dick/w7wkr

======================================

1310 -------------------- Transmitting WSPR ----------------------- 80m

1312 -20 1.3 3.569996 0 *1IO/IL0HBU* 7 *<====== HERE*

1312 4 3.2 3.570066 0 W7HMT CN97 23 59

1314 -22 0.5 3.570097 0 VA7BBG CO65 27 562

1316 -2 3.2 3.570067 0 W7HMT CN97 23 59

1316 -13 1.5 3.570072 0 KE6ZIQ DM09 23 616

1316 -29 0.7 3.570132 0 KD7JL DN13 23 379

1316 -22 0.4 3.570190 0 K7GXB DM34 30 1035

1320 -------------------- Transmitting WSPR ----------------------- 80m

1322 14 1.7 3.570014 0 KO6FE CN71 37 516

1328 -------------------- Transmitting WSPR ----------------------- 80m

1326 6 3.2 3.570067 0 W7HMT CN97 23 59

1326 -6 0.4 3.570146 0 KI7DX DN40 33 724

1330 -20 1.5 3.570195 0 KE6ZIQ DM09 23 616

1334 -------------------- Transmitting WSPR ----------------------- 80m

1332 -15 -2.2 3.569996 0 1IO/IL0HBU 7 <===== AND HERE

1332 -3 1.7 3.570014 0 KO6FE CN71 37 516





    


locked 1/3 less power output with MSK144?

Lance Collister, W7GJ <w7gj@...>
 

Several of us have wondered why the wattmeter drops when the mode is switched from FT8, JT65, or tune, etc. to MSK144. I checked the User Guide but couldn't find any information about it. Is there some different way the tones are presented in MSK144 that causes the power output to be read differently, or does this indicate some problem with our sound cards not having the dynamic range to be able to maintain the same output volume at different frequencies? Is there some equalization we should be doing to fix this? Or is there some other software reason for the power reduction? Thanks for any suggestions/insight!

VY 73, Lance

--
Lance Collister, W7GJ(ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX, 3D2LR, 5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ, S79GJ, TX7MB)
P.O. Box 73
Frenchtown, MT 59834-0073
USA
TEL: (406) 626-5728
QTH: DN27ub
URL: http://www.bigskyspaces.com/w7gj
Skype: lanceW7GJ
2m DXCC #11 - 6m DXCC #815 - FFMA #7

Interested in 6m EME? Ask me about subscribing to the Magic Band EME
email group, or just fill in the request box at the bottom of my web
page (above)!


locked Re: Can Anyone Identify these two decodes of 1IO/IL0HBU

Joe Subich, W4TV
 

I had two different time-slot decodes for *1IO/IL0HBU*
Any prefix that starts with the number 1 is not valid - the
1AA-1ZZ block is not used by the ITU (also 0AA-0ZZ and QAA-QZZ).

This would appear to be a "false decode" although I wonder why
K1JT et. al. would waste the space in the protocol for an "illegal"
prefix block: <https://www.itu.int/en/ITU-R/terrestrial/fmd/Pages/call_sign_series.aspx>.

73,

... Joe, W4TV


On 2020-07-31 11:01 AM, Dick Bingham wrote:
Greetings Everyone
I had two different time-slot decodes for *1IO/IL0HBU* on 80-meter WSPR I can not identify (see below)
When I enter that call in the WSPRNET map nothing shows up for that call.
Seems odd two random/bogus decodes would be exactly the same.
73  Dick/w7wkr
======================================
1310 -------------------- Transmitting WSPR ----------------------- 80m
1312 -20 1.3 3.569996 0 *1IO/IL0HBU* 7 *<====== HERE*
1312 4 3.2 3.570066 0 W7HMT CN97 23 59
1314 -22 0.5 3.570097 0 VA7BBG CO65 27 562
1316 -2 3.2 3.570067 0 W7HMT CN97 23 59
1316 -13 1.5 3.570072 0 KE6ZIQ DM09 23 616
1316 -29 0.7 3.570132 0 KD7JL DN13 23 379
1316 -22 0.4 3.570190 0 K7GXB DM34 30 1035
1320 -------------------- Transmitting WSPR ----------------------- 80m
1322 14 1.7 3.570014 0 KO6FE CN71 37 516
1328 -------------------- Transmitting WSPR ----------------------- 80m
1326 6 3.2 3.570067 0 W7HMT CN97 23 59
1326 -6 0.4 3.570146 0 KI7DX DN40 33 724
1330 -20 1.5 3.570195 0 KE6ZIQ DM09 23 616
1334 -------------------- Transmitting WSPR ----------------------- 80m
1332 -15 -2.2 3.569996 0 1IO/IL0HBU 7 <===== AND HERE
1332 -3 1.7 3.570014 0 KO6FE CN71 37 516


locked Re: V2.2.2 stops working

Lars Berg
 

Hi Bill. Ctrl-Alt- Esc worked (new for me). The keyboard is a Logitech K520 connected to a LogiLink USB reciver. WSJTx has now been running for over 5 hours without any problems. Have put it on the Process Monitor with filter wsjtx.exe. It might give a cloe of what the problem is.

73  de Lars.   (BTW G5AKF, Brentford, was my UK call back in the 60’ies. )

 

Skickades från E-post för Windows 10

 

Från: Bill Somerville
Skickat: den 31 juli 2020 12:15
Till: main@WSJTX.groups.io
Ämne: Re: [WSJTX] V2.2.2 stops working

 

Hi Lars,

 

something is seriously wrong with your PC if Ctrl+Alt+Del does not bring up the blue menu. Error messages from WSJT-X are the least of your issues. Are you sure you do not have a problem with your keyboard? If you keyboard is USB connected then there too is a clue. Your WSJT-X error messages show both audio and CAT control have been lost, if they and the keyboard all use USB then you have a problem with your PC's USB sub-system.

 

73
Bill
G4WJS.

 

On 31/07/2020 10:12, Lars Berg wrote:

Sorry…  After 4 hours this morning the ”Error in Sound Input” is back. WSJTx is looked. Does not respond on ”Control C” in the error pop up. Does not respond on Ctrl-Alt-delete or anything I have tried. Have to press and hold the computer start button to be able to restart.

73 de Lars

 

 

Skickades från E-post för Windows 10

 

Från: Lars Berg
Skickat: den 30 juli 2020 11:24
Till: main@WSJTX.groups.io
Ämne: Re: [WSJTX] V2.2.2 stops working

 

Anthony Thanks. You probably had it…

Change it this morning. 73 de Lars – SM3CCM

 

Skickades från E-post för Windows 10

 

Från: Anthony Luscre
Skickat: den 29 juli 2020 17:22
Till: main@WSJTX.groups.io
Ämne: Re: [WSJTX] V2.2.2 stops working

 

Check to make sure Com Port is not going to sleep and other com issues-

 

On Wed, Jul 29, 2020 at 7:56 AM Lars Berg <sm0ccm@...> wrote:




Working perfect for some hours, then  WSJTX stops with the this error. The only way I have found start WSJTx again is to make a  computer restart.
Using an IC-7100, W10 PRO 2004 , Fujitsi lunchbox, 2.9GHz, 16GB. SiliconLabs drivers
This happens one or twice times a day.
Any hint of what going wrong.
73 de Lars SM3CCM

 

 


locked FW: [WSJTX] Can Anyone Identify these two decodes of 1IO/IL0HBU

Reino Talarmo
 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Dick Bingham
Sent: 31. heinäkuuta 2020 18:02
To: main@WSJTX.groups.io
Subject: [WSJTX] Can Anyone Identify these two decodes of 1IO/IL0HBU

 

Greetings Everyone

I had two different time-slot decodes for 1IO/IL0HBU on 80-meter WSPR I can not identify (see below)
When I enter that call in the WSPRNET map nothing shows up for that call.

Seems odd two random/bogus decodes would be exactly the same.

73  Dick/w7wkr

======================================

1310 -------------------- Transmitting WSPR ----------------------- 80m

1312 -20 1.3 3.569996 0 1IO/IL0HBU<====== HERE

1312 4 3.2 3.570066 0 W7HMT CN97 23 59

1314 -22 0.5 3.570097 0 VA7BBG CO65 27 562

1316 -2 3.2 3.570067 0 W7HMT CN97 23 59

1316 -13 1.5 3.570072 0 KE6ZIQ DM09 23 616

1316 -29 0.7 3.570132 0 KD7JL DN13 23 379

1316 -22 0.4 3.570190 0 K7GXB DM34 30 1035

1320 -------------------- Transmitting WSPR ----------------------- 80m

1322 14 1.7 3.570014 0 KO6FE CN71 37 516

1328 -------------------- Transmitting WSPR ----------------------- 80m

1326 6 3.2 3.570067 0 W7HMT CN97 23 59

1326 -6 0.4 3.570146 0 KI7DX DN40 33 724

1330 -20 1.5 3.570195 0 KE6ZIQ DM09 23 616

1334 -------------------- Transmitting WSPR ----------------------- 80m

1332 -15 -2.2 3.569996 0 1IO/IL0HBU 7 <===== AND HERE

1332 -3 1.7 3.570014 0 KO6FE CN71 37 516

======================================


locked Re: Can Anyone Identify these two decodes of 1IO/IL0HBU

Alan G4ZFQ
 

Seems odd two random/bogus decodes would be exactly the same.
Dick,

Not in the least. There are some false calls that come up many times "spotted" from a number of stations.
And once you have made a bad decode then it is stored in the hashtable, so might increase the chance of being "spotted" again.

There are often other parts of the "decode" that do not look right.
Check the Database, if no-one else has seen it then it's almost certainly a false spot.
If no-one has seen the call on any band, in the last month that's just about 100% certain.

73 Alan G4ZFQ


locked Can Anyone Identify these two decodes of 1IO/IL0HBU

Dick Bingham
 

Greetings Everyone

I had two different time-slot decodes for 1IO/IL0HBU on 80-meter WSPR I can not identify (see below)
When I enter that call in the WSPRNET map nothing shows up for that call.

Seems odd two random/bogus decodes would be exactly the same.

73  Dick/w7wkr

======================================

1310 -------------------- Transmitting WSPR ----------------------- 80m

1312 -20 1.3 3.569996 0 1IO/IL0HBU<====== HERE

1312 4 3.2 3.570066 0 W7HMT CN97 23 59

1314 -22 0.5 3.570097 0 VA7BBG CO65 27 562

1316 -2 3.2 3.570067 0 W7HMT CN97 23 59

1316 -13 1.5 3.570072 0 KE6ZIQ DM09 23 616

1316 -29 0.7 3.570132 0 KD7JL DN13 23 379

1316 -22 0.4 3.570190 0 K7GXB DM34 30 1035

1320 -------------------- Transmitting WSPR ----------------------- 80m

1322 14 1.7 3.570014 0 KO6FE CN71 37 516

1328 -------------------- Transmitting WSPR ----------------------- 80m

1326 6 3.2 3.570067 0 W7HMT CN97 23 59

1326 -6 0.4 3.570146 0 KI7DX DN40 33 724

1330 -20 1.5 3.570195 0 KE6ZIQ DM09 23 616

1334 -------------------- Transmitting WSPR ----------------------- 80m

1332 -15 -2.2 3.569996 0 1IO/IL0HBU 7 <===== AND HERE

1332 -3 1.7 3.570014 0 KO6FE CN71 37 516

======================================


locked Hamlib error

Chuck Schloss <cschloss@...>
 

I need your help, please.
Things going fine this AM, couple far eastern contacts then stopped by Hamlib error: IO error while testing getting current VFO.

 

Can’t get rid of the error.  Turned off radio and computer, no help.  Still decodes sigs, but graph dead and no rig control.
has been running with no problem – couple thousand QSO’s on this setup.

 

Attached couple screen shots.  Could not attach – scanner software glitch.

 

Yaesu FTdx101MP to HP laptop running Windows 10 Home, version 1903.

 

Thank you, 73,

 

Chuck AG0W


locked Re: Hamlib error: Protocol error while testing getting current VFO

neil_zampella <neilz@...>
 
Edited

As it is, the version of Hamlib in WSJT-X is actually more up to date as it has been constantly been added to, and corrected, whereas the main Hamlib code was not.

In fact, the last Hamlib update that was incorporated included problems that caused issues for many Yeasu rigs.   That is why there was (is) a workaround to use the FT-857 (I believe) selection for other Yeasu 800 series rigs.

Neil, KN3ILZ

On 7/31/2020 1:12 AM, Bruce N7XGR wrote:

Randy,  As Neil has pointed out that some Hamlib files are incorporated within the dot exe
of WSJT-X then that is where the problem begins.  Instead of the files being within WSJT-X
it would be better to have the necessary Hamlib files in another location that can be easily
updated and separate from the dot exe.  Like this location,
C:\Users\YourName\AppData\Local\WSJT-X\Hamlib
The Hamlib folder is where all necessary files are there and can be easily updated.
One would copy the entire Hamlib folder to another location for safe keeping just in case
and then copy/paste the updated Hamlib files into the Hamlib folder then start WSJT-X
and in your case select the correct radio (FT817) in the dropdown.
WSJT-X can be setup to read from this Hamlib folder the required files for the operation.
I fully realize that some people will criticize this idea but it will most definitely solve the bugs
that Hamlib unleashes by simply being able to update manually with files that have been fixed.
As it stands now the only way for any updated Hamlib version to be contained in WSJT-X
is to put out a new WSJT-X version.  If a new radio comes out then the Hamlib team
incorporates this and comes out with a version that includes the new radio, copy this new
version into the Hamlib folder--no need to update the entire WSJT-X.
Of course a new WSJT-X version will be needed too, as I said earlier read from the
Hamlib folder the required files, from then on just update the Hamlib folder.
It is crazy for people to select a different radio in order to stop the rig error popup.
I am now donning my Kevlar suit just waiting for the licking of the flames!!!
 
Bruce  N7XGR 

On Thu, Jul 30, 2020 at 11:35 PM neil_zampella <neilz@...> wrote:

FWIW ... the latest version of Hamlib is compiled in with WSJT-X.

As far as earlier versions, they are always available on Sourceforge here:  https://sourceforge.net/projects/wsjt/files/

Neil, KN3ILZ

On 7/30/2020 9:00 PM, Randy Mönch wrote:
I share your pain.  I have Hamlib blues with my 817 since upgrade from 2.1  I see that FLdigi says it is using Hamlib 4.0.  When selecting rig with new version of FLdigi it has FT-818.  I have search for Hamlib 4.0 and can not find it on the web yet is has the FT818.  Could this mysterious version of Hamlib solve the problems with the latest version of WSJT-X? I would like to go back to WSTJ-X 2.1 but cannot find a downloadable file.

Randy - KE0RXF

Virus-free. www.avg.com

 


locked Re: #WSPR Subprocess Error when band hopping from the Schedule

Bill Somerville
 

On 30/07/2020 22:57, Eric Struble wrote:
Something I noticed today when trying to operate WSPR. I'm getting the following error when WSJT-X finishes a decode time period:

"Subprocess Error
Running: /Applications/wsjtx.app/Contents/MacOS/user_hardware 30
execvp: No such file or directory"

Note: the hardware number corresponds to the band, i.e: 30M
If I select OK, the app will crash. If I do nothing it will move to the next frequency in the band hopping schedule. It will transmit but I have no control after the error message dialog box pops up.

I completely removed WSJT-X the reinstalled it using the default configuration. Still doing it.
There isn't any file "user_hardware" in the main application contents file.

The only thing that seams to "trigger" the error might be the schedule for WSPR. After I loaded in a completely new/fresh version of WSJT-X, I started WSPR and at first I didn't get the error. I then remembered that I needed to load a schedule in. So, I went and added the frequencies I wanted to monitor and the first time it completed a receive cycle, I got the error when it tried to switch frequencies (which it did just fine).

Setup:
Kenwood: TS-590S
Running version 2.2.2
MacOS Catalina

Anyone seen something like this?

Thanks,
Eric, W7CSD
Hi Eric,

as has been reported here a few times, WSJT-X v2.2.2 has a known issue with WSPR band hopping. Please revert to WSJT-X v2.1.2 if you need to run WSPR Band Hopping.

73
Bill
G4WJS.


locked Re: V2.2.2 stops working

Bill Somerville
 

Hi Lars,

something is seriously wrong with your PC if Ctrl+Alt+Del does not bring up the blue menu. Error messages from WSJT-X are the least of your issues. Are you sure you do not have a problem with your keyboard? If you keyboard is USB connected then there too is a clue. Your WSJT-X error messages show both audio and CAT control have been lost, if they and the keyboard all use USB then you have a problem with your PC's USB sub-system.

73
Bill
G4WJS.

On 31/07/2020 10:12, Lars Berg wrote:

Sorry…  After 4 hours this morning the ”Error in Sound Input” is back. WSJTx is looked. Does not respond on ”Control C” in the error pop up. Does not respond on Ctrl-Alt-delete or anything I have tried. Have to press and hold the computer start button to be able to restart.

73 de Lars

 

 

Skickades från E-post för Windows 10

 

Från: Lars Berg
Skickat: den 30 juli 2020 11:24
Till: main@WSJTX.groups.io
Ämne: Re: [WSJTX] V2.2.2 stops working

 

Anthony Thanks. You probably had it…

Change it this morning. 73 de Lars – SM3CCM

 

Skickades från E-post för Windows 10

 

Från: Anthony Luscre
Skickat: den 29 juli 2020 17:22
Till: main@WSJTX.groups.io
Ämne: Re: [WSJTX] V2.2.2 stops working

 

Check to make sure Com Port is not going to sleep and other com issues-

 

On Wed, Jul 29, 2020 at 7:56 AM Lars Berg <sm0ccm@...> wrote:




Working perfect for some hours, then  WSJTX stops with the this error. The only way I have found start WSJTx again is to make a  computer restart.
Using an IC-7100, W10 PRO 2004 , Fujitsi lunchbox, 2.9GHz, 16GB. SiliconLabs drivers
This happens one or twice times a day.
Any hint of what going wrong.
73 de Lars SM3CCM



locked Re: Hamlib error: Protocol error while testing getting current VFO

Bill Somerville
 

On 31/07/2020 02:00, Randy Mönch wrote:
I share your pain.  I have Hamlib blues with my 817 since upgrade from 2.1  I see that FLdigi says it is using Hamlib 4.0.  When selecting rig with new version of FLdigi it has FT-818.  I have search for Hamlib 4.0 and can not find it on the web yet is has the FT818.  Could this mysterious version of Hamlib solve the problems with the latest version of WSJT-X? I would like to go back to WSTJ-X 2.1 but cannot find a downloadable file.

Randy - KE0RXF
Randy,

as has been posted here several times, there is a known issue with WSJT-X v2.2.2 which means that owners of Yaesu FT-817, FT-818, and FT-897 rigs must select the FT-857 option. That's it, it should work fine.

For owners of rigs that emulate the FT-817 to a greater or lesser extent, you may find that the FT-857 model does not work, or not work reliably for you. This is because the FT-817 driver in Hamlib has some extra code to support these incomplete FT-817 emulations. In this case we recommend reverting to WSJT-X v2.1.2 until a new release is published.

73
Bill
G4WJS.


locked Re: Hamlib error: Protocol error while testing getting current VFO

Bill Somerville
 

Bruce,

sure we could do that but the current release of Hamlib is many Years old, so to satisfy your rant we would have to remove many Years of new rig support and bug fixes. One reason we statically  link Hamlib with WSJT-X is that we can take pre-release versions of Hamlib by taking care to make sure they work correctly and give us  fixed point we can support.

73
Bill
G4WJS.

On 31/07/2020 06:12, Bruce N7XGR wrote:

Randy,  As Neil has pointed out that some Hamlib files are incorporated within the dot exe
of WSJT-X then that is where the problem begins.  Instead of the files being within WSJT-X
it would be better to have the necessary Hamlib files in another location that can be easily
updated and separate from the dot exe.  Like this location,
C:\Users\YourName\AppData\Local\WSJT-X\Hamlib
The Hamlib folder is where all necessary files are there and can be easily updated.
One would copy the entire Hamlib folder to another location for safe keeping just in case
and then copy/paste the updated Hamlib files into the Hamlib folder then start WSJT-X
and in your case select the correct radio (FT817) in the dropdown.
WSJT-X can be setup to read from this Hamlib folder the required files for the operation.
I fully realize that some people will criticize this idea but it will most definitely solve the bugs
that Hamlib unleashes by simply being able to update manually with files that have been fixed.
As it stands now the only way for any updated Hamlib version to be contained in WSJT-X
is to put out a new WSJT-X version.  If a new radio comes out then the Hamlib team
incorporates this and comes out with a version that includes the new radio, copy this new
version into the Hamlib folder--no need to update the entire WSJT-X.
Of course a new WSJT-X version will be needed too, as I said earlier read from the
Hamlib folder the required files, from then on just update the Hamlib folder.
It is crazy for people to select a different radio in order to stop the rig error popup.
I am now donning my Kevlar suit just waiting for the licking of the flames!!!

Bruce  N7XGR 

On Thu, Jul 30, 2020 at 11:35 PM neil_zampella <neilz@...> wrote:

FWIW ... the latest version of Hamlib is compiled in with WSJT-X.

As far as earlier versions, they are always available on Sourceforge here:  https://sourceforge.net/projects/wsjt/files/

Neil, KN3ILZ



locked Re: V2.2.2 stops working

Lars Berg
 

Sorry…  After 4 hours this morning the ”Error in Sound Input” is back. WSJTx is looked. Does not respond on ”Control C” in the error pop up. Does not respond on Ctrl-Alt-delete or anything I have tried. Have to press and hold the computer start button to be able to restart.

73 de Lars

 

 

Skickades från E-post för Windows 10

 

Från: Lars Berg
Skickat: den 30 juli 2020 11:24
Till: main@WSJTX.groups.io
Ämne: Re: [WSJTX] V2.2.2 stops working

 

Anthony Thanks. You probably had it…

Change it this morning. 73 de Lars – SM3CCM

 

Skickades från E-post för Windows 10

 

Från: Anthony Luscre
Skickat: den 29 juli 2020 17:22
Till: main@WSJTX.groups.io
Ämne: Re: [WSJTX] V2.2.2 stops working

 

Check to make sure Com Port is not going to sleep and other com issues-

 

On Wed, Jul 29, 2020 at 7:56 AM Lars Berg <sm0ccm@...> wrote:




Working perfect for some hours, then  WSJTX stops with the this error. The only way I have found start WSJTx again is to make a  computer restart.
Using an IC-7100, W10 PRO 2004 , Fujitsi lunchbox, 2.9GHz, 16GB. SiliconLabs drivers
This happens one or twice times a day.
Any hint of what going wrong.
73 de Lars SM3CCM


 


 

--

Anthony Luscre

 

K8ZT

Ohio Section Section Youth Coordinator & Education Outreach

ARRL - The National Association For Amateur Radio™

 

k8zt@... (best for Amateur Radio)

 

The Web Resource Hoarder- www.ZTLearn.com

 

K8ZT Radio Website- www.k8zt.com

 

Amateur Radio Resources for Students/Youth - www.k8zt.com/hry