Date   

locked #mainscreen #FST4 #Q65 - User Guides for v2.3.0 and v2.4.0-rc3 #mainscreen #FST4 #Q65

Frode Igland
 

Thanks for version 2.4.0-rc3.

In the v2.4.0-rc3 User Guide, the illustration of section 10.1.5  Mode Menu shows the v2.3.0 Mode Menu, including QRA64 and ISCAT, both to be deprecated in v2.4.0. I guess this should be replaced by a new mode list including Q65, but not QRA64 and ISCAT.

In the User Guide for v2.4.0-rc3, the title of the previous section 10.2 Button Row (on the main screen) has been removed and replaced by this text:
    === Button Row
// Status=edited
All the previous text under "Button Row" has been retained. Should the Button Row still have its own section title and number, or is the change intended?

I have translated the User Guide for v2.3.0 GA (submitted in early February, not yet published) and v2.4.0-rc3, hence the tags FST4 and Q65.
Where do you want to receive the translations to make them available on the WSJT-X page?

The User Guide is an important part of WSJT-X. Does it deserve its own hash tag?

73, Frode LA6VQ


locked Re: Logged Stations Still Show Up In Band Activity As Not Worked - Green Highlighted #logging

Robert Lorenzini
 

I can duplicate this in 2.2.2 by starting everything from DXLabs launcher even when JTAlert is started last.
Killing JTAlert and restarting will fix it. Until I realized what was going on I made a number of embarrassing
workedB4 contacts. It may be JTAlert is the problem, I will revert and try that when I get back from my bike ride.

dod
JTAlert 2.16.17

On 3/16/2021 7:49 AM, Bob wrote:
No Bill, there is a bug.

dod

On 3/16/2021 6:37 AM, Bill Somerville wrote:
On 16/03/2021 12:02, Don Bolstad K9DEB wrote:
Recently had to re-install programs on PC after a Windows crash requiring a restore.  Fortunately the restore job saved my data and logs. However software programs needed to be re-installed.
Downloaded and installed  WSJt-x V2.3.0 and JTAlert 2.16.17.

Noticed that after I work and log a station, that station still shows up in the Band Activity window with green highlight, indicating not worked.  I checked the 'wsjtx_log.adi" and "wsjx.log" files and the qso has been properly recorded.  This has caused me to chase the station again, even though I may have worked him the same day.   All CQ lines in the band activity window are green.  This was not the way it was before the restore.

Anybody with an idea this is happening?

Don K9DEB

Don,

with the default colour scheme for highlighting decodes in WSJT-X a green background means they are calling CQ, no more, no less.

73
Bill






locked WSJT-X not Answering Calls #FT8

Dale Martin, KG5U
 

I noticed the other day that WSJT-X(v2.3.0) is not recognizing calling stations in response to my CQs. In fact, it just continues calling CQ in spite of there being 1,2,or 3 callers showing up in the Rx Frequency pane answering the just finished CQ. I've checked my settings and cannot find anything that might turn on/off such a feature. 

Thanks for any info anyone can provide. 

73, dale, kg5u


locked Re: Logged Stations Still Show Up In Band Activity As Not Worked - Green Highlighted #logging

neil_zampella
 

Since he stated that he reinstalled after a crash, its very possible that the WSJT settings file didn't make it.    That may be why the colors are wrong, not because of the version.   

Neil, KN3ILZ

On 3/16/2021 9:47 AM, Robert Lorenzini wrote:
Same here, try restarting JTAlert, worked for me but there are other problems with 2.3. I reverted
to 2.2.2 and all my problems went away.

Bob - wd6dod

On 3/16/2021 5:02 AM, Don Bolstad K9DEB wrote:
Recently had to re-install programs on PC after a Windows crash requiring a restore.  Fortunately the restore job saved my data and logs. However software programs needed to be re-installed.
Downloaded and installed  WSJt-x V2.3.0 and JTAlert 2.16.17.   

Noticed that after I work and log a station, that station still shows up in the Band Activity window with green highlight, indicating not worked.  I checked the 'wsjtx_log.adi" and "wsjx.log" files and the qso has been properly recorded.  This has caused me to chase the station again, even though I may have worked him the same day.   All CQ lines in the band activity window are green.  This was not the way it was before the restore.

Anybody with an idea this is happening?

Don K9DEB





locked Re: Not receiving anything... #GeneralGroupInfo

ve4cy
 

One thing to check is your computer time.  It has to be pretty accurate or you'll get no decodes..  

You can check your system time accuracy by going to  https://time.is/



From: "Ron Schunk" <ron051798@...>
To: main@WSJTX.groups.io
Sent: Tuesday, March 16, 2021 8:56:24 AM
Subject: [WSJTX] Not receiving anything... #GeneralGroupInfo

Been having a problem off and on...I can see a lot of activity in the Waterfall, but nothing is showing up on the Band Activity Window...I can TEST CAT and that works, I can Enable TX and I see my call go out on the RX Frequency window, I"m showing green on the Receiving button, the receiving bar stays solid green at about 37db, I can hit the TUNE button and see my output go up...but nothing on the Band Activity window....running ver. 2.2.2 to a FT857..
Any ideas????





locked Re: FST$4W in a PIC #FST4W

Kenneth Williams
 

OK, I do see that but I see nothing that says F1 has to be the initial frequency, talking only about ramped-FSK mode because, per the datasheet:

The purpose of ramped FSK is to provide better bandwidth
containment than can be achieved using traditional FSK.

Going back to my second comment in the thread, and without actually working out the details, I have to believe that the process of sending out a stream of symbols with both upshift and downshift of frequencies must be possible with the mechanisms in this device (ramped FSK of course) otherwise the stuff in this chip would not have much value.

Yes?

Ken
KC6PUQ


On Tue, Mar 16, 2021 at 2:04 PM Bill Somerville <g4wjs@...> wrote:
Hi Ken,

that device requires the F1 register be the lower frequency when using *ramped-FSK* mode, in non-ramped FSK mode the two registers may be either higher or lower than each other. The ramp from F1 to F2 or F2 to F1 depends on the last change of the FSK input pin.

73
Bill
G4WJS.

On 16/03/2021 20:53, Kenneth Williams wrote:
Hi folks.  I am jumping in because this looks interesting and may be something I want to look at more closely.. I want to comment that I am not clear on the understanding of F1/F2 as expressed in this thread.  I do not see anything in the datasheet that says F1 is the starting frequency and F2 is the end.  From what I see, either F1 or F2 can be that starting frequency. (example in figs 34, 35).

Thanks in advance for educating me.

Ken
KC6PUQ

On Tue, Mar 16, 2021 at 4:28 AM Bill Somerville <g4wjs@...> wrote:
On 16/03/2021 11:16, Bill Somerville wrote:
On 16/03/2021 11:04, Bill Somerville wrote:
On 16/03/2021 10:58, Andy TALBOT wrote:
OK, I now understand the process and can see a way forward in a PIC, sampling at a rate perhaps 32 or 64 times that of the symbol period
From the look of the curves for BT=1 and BT=2, at any one time only the contribution from two pulses need be taken into account.  The contribution from pulses further away are too small to contribute when using a table-based approach to generating the GFSK waveform.

The next stage, when time permits,  is to write some code for a PIC that will sample at 32 or 64 times symbol rate, which is less than 1kHz even for the fastest FST15 mode, then send the results to a 48 bit DDS.
 It needs to be a 48 bit device - I use the AD9852 - as a normal 32 bit one is too coarse to give the correct increments at the slowest modes.

If I'm using contributions from two adjacent symbols, the curve stored in the table need only cover half the entire shape as the second half is a mirror image.  That will possibly,simplify the table lookup process.    I'll be using an 8 bit table, so frequency during the shift  will be quantised and I don't have the mathematical nous to calculate the effect that may have on spurii.

Andy   G4JNT

Hi Andy,

the AD9852 appears to directly support smoothed FSK transitions using what it calls ramped-FSK, I would have though that is a better approach that will avoid possibly noisy small frequency steps between symbols. The data sheet says that even though the ramp function is linear, it may be adjusted on the fly for more complex transitions.

73
Bill
G4WJS.

Hi Andy,

having suggested that, I am not sure how feasible it would be to generate ramped-MFSK using the FSK capabilities of that DDS since you cannot ensure that F1 is always lower than F2 without sometimes having to change either F1 or F2 while it is being used by the DDS. I say this because ramped-FSK has a requirement that F1 always be lower than F2. Perhaps it is a non-starter :(

73
Bill
G4WJS.

Hi Andy,

OTOH you may be able to set F1 equal to F2 (or vice versa depending on the last frequency transition direction) mid-symbol then flip the FSK input when; you need to exchange F1 and F2 to shift down or up (depending on the last frequency transition direction) to a new frequency for the next transition. That way you can do arbitrary frequency transitions while always keeping F1 lower than F2.

73
Bill
G4WJS.






locked Re: FST$4W in a PIC #FST4W

Bill Somerville
 

Hi Ken,

that device requires the F1 register be the lower frequency when using *ramped-FSK* mode, in non-ramped FSK mode the two registers may be either higher or lower than each other. The ramp from F1 to F2 or F2 to F1 depends on the last change of the FSK input pin.

73
Bill
G4WJS.

On 16/03/2021 20:53, Kenneth Williams wrote:
Hi folks.  I am jumping in because this looks interesting and may be something I want to look at more closely.. I want to comment that I am not clear on the understanding of F1/F2 as expressed in this thread.  I do not see anything in the datasheet that says F1 is the starting frequency and F2 is the end.  From what I see, either F1 or F2 can be that starting frequency. (example in figs 34, 35).

Thanks in advance for educating me.

Ken
KC6PUQ

On Tue, Mar 16, 2021 at 4:28 AM Bill Somerville <g4wjs@...> wrote:
On 16/03/2021 11:16, Bill Somerville wrote:
On 16/03/2021 11:04, Bill Somerville wrote:
On 16/03/2021 10:58, Andy TALBOT wrote:
OK, I now understand the process and can see a way forward in a PIC, sampling at a rate perhaps 32 or 64 times that of the symbol period
From the look of the curves for BT=1 and BT=2, at any one time only the contribution from two pulses need be taken into account.  The contribution from pulses further away are too small to contribute when using a table-based approach to generating the GFSK waveform.

The next stage, when time permits,  is to write some code for a PIC that will sample at 32 or 64 times symbol rate, which is less than 1kHz even for the fastest FST15 mode, then send the results to a 48 bit DDS.
 It needs to be a 48 bit device - I use the AD9852 - as a normal 32 bit one is too coarse to give the correct increments at the slowest modes.

If I'm using contributions from two adjacent symbols, the curve stored in the table need only cover half the entire shape as the second half is a mirror image.  That will possibly,simplify the table lookup process.    I'll be using an 8 bit table, so frequency during the shift  will be quantised and I don't have the mathematical nous to calculate the effect that may have on spurii.

Andy   G4JNT

Hi Andy,

the AD9852 appears to directly support smoothed FSK transitions using what it calls ramped-FSK, I would have though that is a better approach that will avoid possibly noisy small frequency steps between symbols. The data sheet says that even though the ramp function is linear, it may be adjusted on the fly for more complex transitions.

73
Bill
G4WJS.

Hi Andy,

having suggested that, I am not sure how feasible it would be to generate ramped-MFSK using the FSK capabilities of that DDS since you cannot ensure that F1 is always lower than F2 without sometimes having to change either F1 or F2 while it is being used by the DDS. I say this because ramped-FSK has a requirement that F1 always be lower than F2. Perhaps it is a non-starter :(

73
Bill
G4WJS.

Hi Andy,

OTOH you may be able to set F1 equal to F2 (or vice versa depending on the last frequency transition direction) mid-symbol then flip the FSK input when; you need to exchange F1 and F2 to shift down or up (depending on the last frequency transition direction) to a new frequency for the next transition. That way you can do arbitrary frequency transitions while always keeping F1 lower than F2.

73
Bill
G4WJS.



locked Re: FST$4W in a PIC #FST4W

Kenneth Williams
 

In other words, do what Bill said.  I have to believe that the makers of this device intended such a need as this otherwise, this would be a pretty useless feaure.

Ken
KC6PUQ


locked Re: FST$4W in a PIC #FST4W

Kenneth Williams
 

Hi folks.  I am jumping in because this looks interesting and may be something I want to look at more closely.. I want to comment that I am not clear on the understanding of F1/F2 as expressed in this thread.  I do not see anything in the datasheet that says F1 is the starting frequency and F2 is the end.  From what I see, either F1 or F2 can be that starting frequency. (example in figs 34, 35).

Thanks in advance for educating me.

Ken
KC6PUQ

On Tue, Mar 16, 2021 at 4:28 AM Bill Somerville <g4wjs@...> wrote:
On 16/03/2021 11:16, Bill Somerville wrote:
On 16/03/2021 11:04, Bill Somerville wrote:
On 16/03/2021 10:58, Andy TALBOT wrote:
OK, I now understand the process and can see a way forward in a PIC, sampling at a rate perhaps 32 or 64 times that of the symbol period
From the look of the curves for BT=1 and BT=2, at any one time only the contribution from two pulses need be taken into account.  The contribution from pulses further away are too small to contribute when using a table-based approach to generating the GFSK waveform.

The next stage, when time permits,  is to write some code for a PIC that will sample at 32 or 64 times symbol rate, which is less than 1kHz even for the fastest FST15 mode, then send the results to a 48 bit DDS.
 It needs to be a 48 bit device - I use the AD9852 - as a normal 32 bit one is too coarse to give the correct increments at the slowest modes.

If I'm using contributions from two adjacent symbols, the curve stored in the table need only cover half the entire shape as the second half is a mirror image.  That will possibly,simplify the table lookup process.    I'll be using an 8 bit table, so frequency during the shift  will be quantised and I don't have the mathematical nous to calculate the effect that may have on spurii.

Andy   G4JNT

Hi Andy,

the AD9852 appears to directly support smoothed FSK transitions using what it calls ramped-FSK, I would have though that is a better approach that will avoid possibly noisy small frequency steps between symbols. The data sheet says that even though the ramp function is linear, it may be adjusted on the fly for more complex transitions.

73
Bill
G4WJS.

Hi Andy,

having suggested that, I am not sure how feasible it would be to generate ramped-MFSK using the FSK capabilities of that DDS since you cannot ensure that F1 is always lower than F2 without sometimes having to change either F1 or F2 while it is being used by the DDS. I say this because ramped-FSK has a requirement that F1 always be lower than F2. Perhaps it is a non-starter :(

73
Bill
G4WJS.

Hi Andy,

OTOH you may be able to set F1 equal to F2 (or vice versa depending on the last frequency transition direction) mid-symbol then flip the FSK input when; you need to exchange F1 and F2 to shift down or up (depending on the last frequency transition direction) to a new frequency for the next transition. That way you can do arbitrary frequency transitions while always keeping F1 lower than F2.

73
Bill
G4WJS.





locked Re: Waterfall display halts stalls with regular period #IssueReport

M0PWX
 

 

Yep RC3 it stops dead after a long run, not seen this before on any previous version

 

Peter

 

M0PWX

 

From: Kenneth Williams

By going through the sequence of disabling 'Monitor' then re-enabling 'Monitor' some time later, the waterfall display will halt for some time during every other TX/RX sequence.
The complete mechanism necessary to reproduce this is unknown but it seems that disabling Monitor and re-enabling it only a short time later does not cause this problem to manifest itself.  In the picture shown below, I disabled Monitor in the evening and re-enabled it in the morning and observed the problem.  My CAT connected radio, a TS-570S, was on during this time.
I have observed this behavior in earlier versions as well.  The actual decoding of signals is also affected during these truncated cycles.  Restarting WSJT-X allows the system to recover and behave normally.

Ken
KC6PUQ


 


locked Re: 2.4 and FTDX101MP #Cat_RigControl

Bill Somerville
 

On 16/03/2021 15:33, Buddy Morgan via groups.io wrote:
Since I downloaded 2.4, I have had problems getting my FTDX101MP to work with the software. I have got it to work a few times - I have no idea how I did it. 2.4 works fine with my IC 9700 and my IC 7100. When I try the '101, I get the following error message:

Hamlib error: Feature not implemented
newcat_set_freq: special_60m=0, 60m freq=0, is_ftdx3000=0
newcat.c(782):newcat_set_freq return(-4)
rig.c(1592):rig_set_freq return(-4) while setting frequency

Timestamp: 2021-03-16T12:50:51.749Z

Any help would be appreciated.

Buddy Morgan WB4OMG

Buddy,

which WSJT-X version are you running? 2.4 is not sufficiently specific, there have been three separate release candidates so far.

73
Bill
G4WJS.


locked 2.4 and FTDX101MP #Cat_RigControl

Buddy Morgan
 

Since I downloaded 2.4, I have had problems getting my FTDX101MP to work with the software. I have got it to work a few times - I have no idea how I did it. 2.4 works fine with my IC 9700 and my IC 7100. When I try the '101, I get the following error message:

Hamlib error: Feature not implemented
newcat_set_freq: special_60m=0, 60m freq=0, is_ftdx3000=0
newcat.c(782):newcat_set_freq return(-4)
rig.c(1592):rig_set_freq return(-4) while setting frequency

Timestamp: 2021-03-16T12:50:51.749Z

Any help would be appreciated.

Buddy Morgan WB4OMG


locked Re: Version 2.3.0 64 bit will not install #install

Gary Liebisch
 

I would like to report that I solved this problem. On the install file for Windows 10,  go to properties--Security tab. There will be a notice at the bottom "This file came from another computer and may be blocked".   Check box to unblock.  This worked for me.
--
Gary Liebisch
W8GEL
Powell, OH


locked Re: Time Sync Program. #Timesync

Geoff,G4FKA
 

Meinberg also running here on Windows 10 computer. Within 2msec at the moment.

Geoff G4FKA


locked Waterfall display halts stalls with regular period #IssueReport

Kenneth Williams
 

My machine: Windows 7, 64-bit
WSJT-X Version 2.4.0-rc3
Current mode: FT8


By going through the sequence of disabling 'Monitor' then re-enabling 'Monitor' some time later, the waterfall display will halt for some time during every other TX/RX sequence.
The complete mechanism necessary to reproduce this is unknown but it seems that disabling Monitor and re-enabling it only a short time later does not cause this problem to manifest itself.  In the picture shown below, I disabled Monitor in the evening and re-enabled it in the morning and observed the problem.  My CAT connected radio, a TS-570S, was on during this time.
I have observed this behavior in earlier versions as well.  The actual decoding of signals is also affected during these truncated cycles.  Restarting WSJT-X allows the system to recover and behave normally.

Ken
KC6PUQ



locked Re: Time Sync Program. #Timesync

Alan G4ZFQ
 

Yes, I'm running Windows 10 on my shack PC and it works well for me.
Dave,

Thanks, I just wondered, last update 2008, only up to W8, no obvious recommendation from Meinberg.

73 Alan G4ZFQ


locked Re: Logged Stations Still Show Up In Band Activity As Not Worked - Green Highlighted #logging

Robert Lorenzini
 

Same here, try restarting JTAlert, worked for me but there are other problems with 2.3. I reverted
to 2.2.2 and all my problems went away.

Bob - wd6dod

On 3/16/2021 5:02 AM, Don Bolstad K9DEB wrote:
Recently had to re-install programs on PC after a Windows crash requiring a restore.  Fortunately the restore job saved my data and logs. However software programs needed to be re-installed.
Downloaded and installed  WSJt-x V2.3.0 and JTAlert 2.16.17.   

Noticed that after I work and log a station, that station still shows up in the Band Activity window with green highlight, indicating not worked.  I checked the 'wsjtx_log.adi" and "wsjx.log" files and the qso has been properly recorded.  This has caused me to chase the station again, even though I may have worked him the same day.   All CQ lines in the band activity window are green.  This was not the way it was before the restore.

Anybody with an idea this is happening?

Don K9DEB




locked Re: Logged Stations Still Show Up In Band Activity As Not Worked - Green Highlighted #logging

Robert Lorenzini
 

No Bill, there is a bug.

dod

On 3/16/2021 6:37 AM, Bill Somerville wrote:
On 16/03/2021 12:02, Don Bolstad K9DEB wrote:
Recently had to re-install programs on PC after a Windows crash requiring a restore.  Fortunately the restore job saved my data and logs. However software programs needed to be re-installed.
Downloaded and installed  WSJt-x V2.3.0 and JTAlert 2.16.17.

Noticed that after I work and log a station, that station still shows up in the Band Activity window with green highlight, indicating not worked.  I checked the 'wsjtx_log.adi" and "wsjx.log" files and the qso has been properly recorded.  This has caused me to chase the station again, even though I may have worked him the same day.   All CQ lines in the band activity window are green.  This was not the way it was before the restore.

Anybody with an idea this is happening?

Don K9DEB

Don,

with the default colour scheme for highlighting decodes in WSJT-X a green background means they are calling CQ, no more, no less.

73
Bill






locked Re: Logged Stations Still Show Up In Band Activity As Not Worked - Green Highlighted #logging

JP Tucson, AZ
 

Hello all,

Bill - technically speaking what you wrote is true, but not really...

The Cyan (lt. Blue) is "NEW CALL", & once worked, the call falls through the list & will show up as Green; therefore a de-facto "already worked" is implied.




73 - John - N7GHZ




On Tue, Mar 16, 2021, 6:43 AM Bill Somerville <g4wjs@...> wrote:
On 16/03/2021 12:02, Don Bolstad K9DEB wrote:
> Recently had to re-install programs on PC after a Windows crash
> requiring a restore.  Fortunately the restore job saved my data and
> logs. However software programs needed to be re-installed.
> Downloaded and installed  WSJt-x V2.3.0 and JTAlert 2.16.17.
>
> Noticed that after I work and log a station, that station still shows
> up in the Band Activity window with green highlight, indicating not
> worked.  I checked the 'wsjtx_log.adi" and "wsjx.log" files and the
> qso has been properly recorded.  This has caused me to chase the
> station again, even though I may have worked him the same day.   All
> CQ lines in the band activity window are green.  This was not the way
> it was before the restore.
>
> Anybody with an idea this is happening?
>
> Don K9DEB

Don,

with the default colour scheme for highlighting decodes in WSJT-X a
green background means they are calling CQ, no more, no less.

73
Bill





locked Not receiving anything... #GeneralGroupInfo

Ron Schunk
 

Been having a problem off and on...I can see a lot of activity in the Waterfall, but nothing is showing up on the Band Activity Window...I can TEST CAT and that works, I can Enable TX and I see my call go out on the RX Frequency window, I"m showing green on the Receiving button, the receiving bar stays solid green at about 37db, I can hit the TUNE button and see my output go up...but nothing on the Band Activity window....running ver. 2.2.2 to a FT857..
Any ideas????

14901 - 14920 of 38068