On Mar 16, 2021, at 2:26 PM, Robert Lorenzini <bob@...> wrote:

 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

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

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.

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

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