WSJT-X JT65 settings help requested pls

DrTeeth

I am using WSJT-X 1.4.0 RC4 with the TS2000 fix.
I can decode JT9 signals that I cannot see nor hear, but it is not the same with JT65. Often I see and hear a few signals (not just weak ones either) and do not get a decode - they are not one on top of the other either.
I set things up so the receive meter in WSJT-X is peaking at the max, but not flat-topping. JT65 seems to be more sensitive than JT65 + JT9, that could be my imagination.
What setting an I missing as some moderately strong signals are not decoding? I am asking here as the user error could be in either the WSJT-X config or the rig setup.
TIA,
Guy

Larry Loen WO7R

Set the RF gain lower. If it is between 40 and 50 dB on the "left hand side" of the "decoding" display, you are just fine.

Carl N8VZ

Ben, could you email me at n8vz --at-- qth -dot- com a screen shot of your setup screen? I'm having trouble getting CAT control though I did have it working once. tnxs &73 de Carl, N8VZ

Carl N8VZ

Sorry my question was addressed to Guy, not Ben.

Dave -- W5DJB

I have never been able to get 1.4 cat controls to work with my 6700. 1.3 works fine.

Takeshi Yamada

So do I.
Would anyone help me setting up WSJT-X 1.4 RC4 on Flex6X00?
I have problems on "Radio" tab setting.
  Rig: Flex6XXX ...
  CAT Control:  COMXX
 
  And I cannot set comm speed etc - they are all dimmed.

de JI1BNU
 

Jay Nation

Guy
"I set things up so the receive meter in WSJT-X is peaking at the max,"
That does sound like user error. What's the theory with setting the level so high, or am I misunderstanding how your determining "peaking at the max, but not flat-topping"?
If I am understanding what your doing, you are overdriving "swamping" the decoder with signals+ noise floor.

73, Jay - NO5J

DrTeeth

Hi Jay,

Flat-topping would be the received signal indicator being hard against the top of the scale, peaking at the max it is just hitting the max fleetingly on occasion. If I set it lower, I seem to get less decodes. Will set lower and see what happens.

Thanks.

DrTeeth

To those with CAT probs.

Flex6XXX is control is broken and there are issues with the TS 2000 setup (the latter will be fixed on release). Use TS 480 and you will get everything working FB.

DrTeeth

Screenshot sent as requested Carl. Good luck.

Jay Nation

Guy 
I've read plenty of opinions that suggest that optimum decoding will be had with the slider set as close to centered as possible and received signals set @midscale. I get 
good results with in the HF bands with ...

mode: DIGU
AGCT: 50 - FAST
DAX RX: 20

RX Filter set to 0-4k or 5k but adding the extra 1000Hz will raise the WSJTX quiet Interval levels so you should lower the AGCT level to compensate. 

WSJTX Slider set to the 6th Index mark. which is InGain=0, Stored in the C:UsersYOUAppDataLocalWSJT-XWSJT-X.ini file. the index marks are 10db apart, so to center on the 5th mark the WSJT-X.ini file would read InGain=-10. I just set it to 0 and leave it there. and set it by editing the ini file, the slider isn't very accurate in the way it moves and what looks like centered 0n 60 might be +- 5 in the ini.

WSJTX was designed to operate ideally with the slider set for InGain=0, and then be fed enough signal so that your level with signals present would be center scale on the level meter, ignoring the peak level indicator. The scale of the meter is 0dB to 60dB, so the middle of the scale should be 30dB. Typically I see it between 30dB and 40dB
when decoding well. so I aim for 35dB, with signals present. During the quiet intervals the band noise usually reads 24-25 dB. To maintain the 35dB sweet spot signal, I only adjust the AGCT level.  

When I see the WSJT-X level hitting 40dB I back off the AGCT 1 click. If it drops below 30dB I raise it 1 click.

My goal is to not overdrive the decoders with the BandPass noise.

You might get more decodes with louder settings but you might also overload the decoders and loose a few decodes running things to hot.

As always ignore the WSJT-X waterfall appearance, and the SmartSDR waterfall,
They dont affect anything with the decoders. Just there for you to have something to look at, Sort of an Art project for the folks that crave pretty colors. 

This setup also works with the 1.5 alpha versions, which are doing a better job of simultaneous JT65 and JT9 decodes.

Of course you local conditions and radio might require adjustments to the exact settings but aiming for 35dB with signals present is working here.

BTW my WSJT-X RX level when switched over to the dummy load typically is 18dB
with this setup. I sometime just set it all to 18dB with the dummy load to pre-normalize a session.

YMMV

73, Jay - NO5J

 

DrTeeth

Thanks Jay for your comprehensive answer. Time to get experimenting.
First think I have noticed is that the InGain setting does not change with the slider position. I make sure I do not have the ini file open to view. Change slider, close and reload WSJT-X, check ini file, value is the same. I have set it to 0 in the ini file directly.

Jay Nation

It gets saved when you close WSJT-X. It's how WSJT-X remembers settings from session to session. Edit it before you open WSJT-X. 

73, Jay - NO5J

DrTeeth

It did not here. Steps taken, check ini file then close it. Open wsjt-x change slider, close it and then check ini file again - no change. Repeated a few times moving slider each time. The value only changes very occasionally, maybe one time in 20, definitely not every time. The timestamp does not change either. Also, changing the InGain value does not change the position of the slider - that should work too AIUI.

Jay Nation

Guy
WSJT-X must MUST remain closed or it will change the setting to the sliders current position. Is it possible you got more than one ini file and your editing the wrong one? Try a windows search for the filename on the entire hardrive partition. Trust me on this if thats actually the only ini file you have for WSJT-X then its pilot error. Since it's not using the changes then there has to be another file or it would create another copy which is what it does if you delete the file. I won't ask you to humour me, you just did.

73, Jay - NO5J

N4AB

Most of my "No Decode" problems seem to be related to the timing differences between my Clock and the received Clock. If the delta time exceeds about 1.5 seconds I get a lot of "No Decodes".
But I have also noted that too much signal strength will also cause the loss of decoding.
I first look at the "dt" column on the display.
The timing problem is one reason I would like to be able to use the GPSDO to sync my computers clock.
73,   Al,   N4AB  

Larry Loen WO7R

There are programs out there that synch your clock.  However, in Arizona, with its whacky no-DST, I have found them a bit of a problem. 

So, what I have done instead with some success is increase the frequency that my system synchronizes with internet time.  This isn't perfect, but it works pretty good.  You have to be willing to do a "regedit" on a variable and then (some sources don't know this) you must force a resynch of internet time for the new offset to take place (a lot of sources don't understand this, either, so they offer needlessly elaborate answers).  This seems to be the safest, simplest, and most accurate reference:  http://www.wikihow.com/Change-the-Time-Synchronization-Interval-in-Windows-7  

The clock on my shack computer seems particularly lousy, so I've had to shorten the interval to about six hours.  You shouldn't have to do that, but once or twice a day should keep you close.  Obviously, Microsoft doesn't want millions of computers updating so often as that, even (the default interval is something like a week) but if you set the interval by hand and then force a reset so the new value is used ever after, you can get it to update enough to "cover for" the inaccuracies of your local clock.

KY6LA_Howard

Until my GPSDO actually talks to my computer I use Dimension 4 to correct the time

http://www.thinkman.com/dimension4/

DH2ID

I have been using Time-Sync for a long time:
http://www.speed-soft.de/software/time_sync/details/download.php?language=en
But will try setting Windows 7 polling time to 20 minutes. Tnx for the info!

UPDATE: Great,http://www.wikihow.com/Change-the-Time-Synchronization-Interval-in-Windows-7 works, uninstalled Time-Synch, 1 program less to start 8-) 

73, Alex DH2ID

Larry Loen WO7R

Even for a very lousy clock, 20 minutes is probably excessive.   (Though in truth, if only one or two of us does it, it is a drop in the bucket). 

If you can't get satisfactory results for somewhere between 4 and 6 hours, then the problem is there is too much lag between your PC and your time source and making it run more often won't do the job (should be rare, but who knows).  Maybe a different time source would be in order (one physically closer) in that case.

Remember that the REGEDIT variable is in seconds, so be careful not to set it "as if" it is in minutes.  If you run the function even once a minute, it probably interferes with other stuff you're doing.  Like maybe even SmartSDR.

Tim - W4TME

Or Meinberg https://www.meinbergglobal.com/english/sw/ntp.htm

Jay Nation

Meinberg/ntpd in use here for a very long time.
Lan synced with ntp and windows machine synced to Lan with Meinberg
Stratum 2 is good enough for WSJT/WSPR.
 

DrTeeth

Hi Jay,

Confirm no other wsjt-x ini file (I did search my whole drive). I have mentioned this issue on the dev mail list. I have opened and closed wsjtr-x and edited the ini file in all possible permutations and there does seem to be an issue.

73

DrTeeth

Just had a long TeamViewer session with one of the devs and my problem is 110% solved.
The solution was to increase Bins/Pixel value on the waterfall from the default 2 to 8 and gain from default 0 to 2.
Before those adjustments, I could only decode 1 JT65 signal out of a wav file that contained 3 and 1 JT9 signal. Got a 1.5.0 dev version into the bargain. Sweet.

Jay Nation

Guy 
I saw from today's posts to the developers list that , you've reported the the ini file issue resolved.  was it just permissions causing the problem?
73, Jay - NO5J

KY6LA_Howard

Curious why the waterfall bin size and gain would have anything to do with decodes?

BTW.. running 1.3 and 1.5 WSJT- both attached to the same slice and same DAX

Not seeing much difference in what each will decode...

Jay Nation

Guy 
Could you post a screen shot of the WSJT-X window also including the waterfall, as you have it adjusted, also what do you have AGC-T and DAX RX set to? I'm curious.
73, Jay - NO5J

Tim - W4TME

Methinks large bins will allow more signal (and noise) for the DSP to operate on for decoding.  But this is just a guess.

Bob N7ZO

In WSJT-X, the waterfall bandwidth controls the decoding bandwidth, and bin size affects the waterfall bandwidth.  I don't think the waterfall gain affects the decode, it is just for the display.

There is a discussion (prompted by Guy's question) about this in the WSJTX Yahoo group.

https://groups.yahoo.com/neo/groups/WSJTX/conversations/topics/849

The following was proposed as a manual addition by Mike W9MDB:
"the visible bandwidth on the Wide Graph controls the decoding bandwidth...any signals outside the visible area of the waterfall will not be decoded"

DrTeeth

Likely it was.

Whenever I install windows, I take ownership of all files and folders and give explicit admin control so can install in program files and never have to install a program as admin.
I reinstalled WSJT-X as admin and did some permissions tweaking.

No other program has permission issues so it is strange that one only would, but then again, all seemed to work well after the above tweaking.

DrTeeth

Jay, all my other settings are as per your useful answer from a day or so ago.

Since the changes have been made last night, my number of decodes has increase by a factor of 4 and I can decode both JT65 and JT9 at the sma e time at long last. The settings that were changed were left at their default values and it is a puzzle why others do not have the same issues I had (dev was puzzled too). I have had to show two lines of callsigns since the fix last night in JTAlert.
Tests were run with a WAV file that contained 3 x JT65 and 1 x JT9 signal - initially only 1 JT65 signal would decode initially.