[wsjt-devel] Odd Decoding Problem on new Core i5-8250 Laptop - Only decodes perfect when running HDSDR in parallel

[Black Michael via wsjt-devel]

I had a test session with one user who can easily reproduce the audio dropouts. 
 Latency testing shows his system more than capable of handling realtime 
audio.I got some timings from the dataSink.The Good plot is a normal/good 
decode.  One high time period is corrected on the next iteration.The plots show 
the time intervals between calls to dataSink.
The Bad plot is when decoding has stopped.  the n_ihsym never gets to 50 to 
satisfy the n_ihsym requirement
  if(m_ihsym == m_hsymStop) {
Starting another program (most any one) will cause decoding to stop.  Having 
another audio program start will cause decoding to start succeeding again.  So 
the audio gets stalled periodically and sticks there until something tickles it.
de Mike W9MDB






 

On Saturday, January 12, 2019, 12:03:15 AM CST, Mike Lewis 
 wrote:  
 
 
Running the modern weather app set to radar observation map, it plays an 
animated loop and decodes work fine then, just the occasional cycle missed.  
This should have no audio connection, just cpu.  CPU is hanging around 15% with 
that running (and meinberg and n1mm).
 
  
 
The SSD is SK Hynix BC501 HFM256GDJTNG-8310A   - a 256GB stick drive.  PCIe Gen 
3x2.  Likely M.2 form factor.  
https://www.skhynix.com/eng/product/ssdClient.jsp   scroll down for BC501.  Not 
too shabby perf.
 
  
 
Don’t forget there are 2 separate sound devices this happens on, the USB and 
the internal Realtek.  Happens with either input.  Can have 2 instances of WSJT 
running on both inputs, and JTDX and all 3 instances stop and start at the same 
time.  They all share the same WSJTX library though.  We know the sound is 
getting through since the wave files and any audio app like Audacity keep 
recording audio fine. Has to be timing or maybe high noise I am thinking.   
Unfortunately to get low noise I have to go up to 28 and there are no signals 
there these days, save the occasional one off I made contact with today.
 
  
 
  
 
From: Black Michael  
Sent: Saturday, January 12, 2019 00:50
To: Mike Lewis 
Subject: Re: [wsjt-devel] Odd Decoding Problem on new Core i5-8250 Laptop - 
Only decodes perfect when running HDSDR in parallel
 
  
 
Uninstall and reinstall the sound device.
 
  
 
What kind of SSD do you have?  There were some problems before with SSDs but 
not about sound as far as I know.
 
  
 
  
 
  
 
  
 
  
 
On Friday, January 11, 2019, 11:38:27 PM CST, Mike Lewis  
wrote:
 
  
 
  
 
I have changed affinity, priority.  Audacity when recording has the same 
healing effect as HDSDR.  I turned off the firewall, no change.  I just turned 
on programs performance vs auto, no decodes when N1mm is running still.   I 
tried playing with N1MM recording test button but no real difference either.
 
 
 
Timing could certainly be a factor.  Testing the high background noise theory I 
tried all manner of settings in the K3 for Noise Blanker (DSP and/or IF) and 
Noise reduction, APF, and manual notch, in combination with different filter 
settings and RF gain and level.  No change, maybe a few chance decodes on a 
transition of major adjustments.
 
 
 
Do not have many programs on the machine that do something, but after changing 
program perf, I started Meinberg monitor and sat on the status page.   It is 
decoding a portion of the stations on some cycles, pretty spotty still, but 
better.  Turn N1MM off, all decode good.  Turn it back on, barely any decode 
cycles, so back to square one.
 
 
 
So for all my theories, I am no further.  My second antenna is a 6M dipole in 
the attic and is just as noisy.
 
 
 
 
 
From: Black Michael 
Sent: Saturday, January 12, 2019 00:21
To: Mike Lewis 
Subject: Re: [wsjt-devel] Odd Decoding Problem on new Core i5-8250 Laptop - 
Only decodes perfect when running HDSDR in parallel
 
 
 
Check your Performance settings and ensure it's set for "Programs".
 
 
 
And perhaps increase the priority for WSJT-X and see if any of those changes 
affect it.
 
 
 
Starting another app would take some CPU.
 
 
 
I'm doing some analysis on the timing now to see if that reveals anything.  
Nothing obvious yet other than it looks like the sound samples are getting 
starved.
 
 
 
 
 
 
 
 
 
On Friday, January 11, 2019, 9:58:21 PM CST, Mike Lewis  
wrote:
 
 
 
 
 
I started browsing the code on sourceforge tracking down m_ihsym.  I see 
symspec is called which I found in lib\symspec.f90.  Line 87 is where it gets 
incremented.  It is in index to the number of half symbols.  My interpretation 
is that the decode period is allowed to run until enough half symbol time slots 
have passed.  For FT8 the max, m_hymStop, is set to 50. 
 
 
 
It would seem something happens near the end of the period that cause the data 
block getting built to exit out before hitting completion at 50.  Could be a 
timer read issue, a file error, or, thinking about how noisy my Camano location 
is, perhaps the quality checks in symspec are looking at excessive noise and 
bailing out.  I see the computation is 

Re: [wsjt-devel] wrong time logged

[Black Michael via wsjt-devel]

We need to add one statement here probably
void MainWindow::on_dxCallEntry_textChanged (QString const& call){  m_hisCall = 
call;  statusChanged();  statusUpdate ();}
Tovoid MainWindow::on_dxCallEntry_textChanged (QString const& call){  m_hisCall 
= call;  statusChanged();  statusUpdate ();  set_dateTimeQSO(-1);}




 

On Friday, January 11, 2019, 12:47:53 PM CST, Don AA5AU 
 wrote:  
 
  This happens to me all the time. When you stop using WSJT-X, then go back a 
few hours later, many times it logs the next contact with a start time of when 
you last made a contact a few hours earlier. The end time is correct. The QSOs 
usually get flagged by eQSL as not being in the log. That's how I discovered it.
I'm using JTAlert and DXKeeper, but this has been an issue for quite some time. 
I know to either restart WSJT-X after a pause, or look at the first contact I 
log after a period of inactivity.
Seems to be an issue with WSJT-X. I thought it was a known issue.
Don AA5AU


On Friday, January 11, 2019, 10:43:53 AM CST, Al  wrote:  
 
   (WSJT-X V2.0.0, W 10 )
 This may have been reported before ??
 
 I was on earlier today and made several 80 contacts ending at 1319.
 I left the radio running  and came back at ~16:17 and changed bands to 17m.
 My first contact on 17m was at 16:19 but the logs recorded that contact time 
at 13:21.
 
 AL, K0VM
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wrong time logged

[Dan Malcolm]

FWIW I am running both WSJT-X v2 and JTAlert 2.12.10.  I rarely shut down 
either program and my computer and rig run 24/7.  I never have this problem.  
Of course saying it just now may cause it to start (Murphy’s Law).

__
Dan – K4SHQ

From: m...@handgunrepairshop.com [mailto:m...@handgunrepairshop.com]
Sent: Friday, January 11, 2019 1:04 PM
To: k...@arrl.net; WSJT software development 
Subject: Re: [wsjt-devel] wrong time logged

I have also experienced this logging start time issue many times, at least back 
as far as v1.8, usually after an aborted/incomplete or abandoned QSO. I have no 
idea why the previously aborted QSO start time does not clear when the Esc. or 
F4 key is used to clear the QSO from the DX Call & DX Grid boxes.
It does seem a bit ironic to me that a program that depends on 1 second time 
correctness for decodes, and always correctly logs the Tx frequency to 1 Hz 
accuracy, has a problem keeping up with the actual current QSO start time?
I am not a computer programmer, but apparently fixing this ongoing logging 
issue is more than the dev team wants to deal with.
Having said that, I do want to express my thanks to all the dev team for this 
software. My log has grown over 4,000 more QSOs since beginning to use WSJT-X!

73 de KV4ZY, Doug

 Original Message 
Subject: [wsjt-devel] wrong time logged
From: Al mailto:k...@arrl.net>>
Date: Fri, January 11, 2019 11:41 am
To: wsjt-devel@lists.sourceforge.net

(WSJT-X V2.0.0, W 10 )
This may have been reported before ??

I was on earlier today and made several 80 contacts ending at 1319.
I left the radio running  and came back at ~16:17 and changed bands to 17m.
My first contact on 17m was at 16:19 but the logs recorded that contact time at 
13:21.

AL, K0VM


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wrong time logged

[mail]

I have also experienced this logging start time issue many times, at least back as far as v1.8, usually after an aborted/incomplete or abandoned QSO. I have no idea why the previously aborted QSO start time does not clear when the Esc. or F4 key is used to clear the QSO from the DX Call & DX Grid boxes.It does seem a bit ironic to me that a program that depends on 1 second time correctness for decodes, and always correctly logs the Tx frequency to 1 Hz accuracy, has a problem keeping up with the actual current QSO start time?I am not a computer programmer, but apparently fixing this ongoing logging issue is more than the dev team wants to deal with.Having said that, I do want to express my thanks to all the dev team for this software. My log has grown over 4,000 more QSOs since beginning to use WSJT-X!73 de KV4ZY, Doug


 Original Message 
Subject: [wsjt-devel] wrong time logged
From: Al 
Date: Fri, January 11, 2019 11:41 am
To: wsjt-devel@lists.sourceforge.net

 (WSJT-X V2.0.0, W 10 ) This may have been reported before ??  I was on earlier today and made several 80 contacts ending at 1319. I left the radio running  and came back at ~16:17 and changed bands to 17m. My first contact on 17m was at 16:19 but the logs recorded that contact time at 13:21.  AL, K0VM___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Behavior during QSO between 2 long calls

[DX Jami via wsjt-devel]

Bill,
Thanks for your response.  The compound call issue is shared with me by many as 
we see.  As you mentioned ... after an FT8 exchange, I often send something 
like "Aloha fm Virginia" and sometimes I send the grid too.  There are some 
considerations about that though.  Number one - perhaps not all people pay 
attention to the extra transmission ... and are perhaps scrambling to find my 
grid on-line or more likely searching for other stations.  Number two - sending 
the extra info takes a lot of effort especially when on the air for a few hours 
and we start getting fatigued.  Number three -- compound calls should be 
handled without problems.  They are "legal" call signs allowed by many 
countries ... plus they are "authorized" under international treaty ... in most 
cases under CEPT, via the provisions of IRAP [International Amateur Radio 
Permit ] agreements, or under other reciprocal ham radio permit arrangements.  
As for us in the U.S. and territories, the FCC authorizes compound calls under 
the provisions of the US law regulating amateur radio, Part 97, Code of Federal 
Regulations.  Let me know, I will send you an extract if you desire.

I understand the technical limitations you described about this issue.  Your 
idea about a public domain database providing grid info sounds interesting.  I 
use Amateur Radio Ham Radio Maidenhead Grid Square Locator Map but 
unfortunately it does not do most compound calls.

With the lack of a usable database ... why doesn't WSJT-X generate one itself 
... a self-generating database.  For instance ... as someone enters a compound 
call in set-up ... the required information is transmitted to the big WSJT-X 
compound database in the sky [perhaps with user permission obtained from a 
pop-up], and integrated accordingly in the FT8 execution script.  [I recognize 
not all compound call users have internet access to do that ... but perhaps it 
could be done in preparation for DXpeditions and those taking DXvacations, 
etc.]  Of course we are up against the 77-bit limitation ... but you had an 
idea about databases - that is an option.
Another option in dealing with the 77-bit limitation is dividing the FT8 
transmission into two seamless execuables.  For instance ... two .bat files 
execute various lines of the FT8 transmission ... something like .bat1 executes 
FT8 lines Tx1, Tx2, and Tx3 ... .bat2 executes Tx4, Tx5, and perhaps Tx6 [maybe 
Tx6 does not demand some of the 77-bit allocation ... ???]  By executing the 
two .bat files, perhaps your programming can piggy-back two seamless executions 
as though they are one standard FT8 transmission.  Of course the compatibility 
issue may come into play ... hopefully your solution will be compatible with 
version 2, et al.  

Another option is to do whatever you did for KH1/KH7Z.  I am guessing you used 
city.dat to overcome that issue.  Not an option for someone like me who 
semi-routinely operates from two different DXCC entities - but might work for 
everyone else.

One more option ... perhaps do the compound calls as a special operating 
activity such a fox / hound ... or a contest, etc.  Now sure if you can 
overcome the 77-bit real estate issue and resolve the other technical issues 
here or not.  Just a thought ...

In closing, Bill - I want to say I appreciate the great effort by you, Joe, and 
the entire WSJT-X team.  It is an understatement to say your work has changed 
ham radio for the better.  With all due respect, I say the compound call issue 
must be overcome.  If you spend time on the bands playing FT8 ... daily, you 
will see various stations using compound calls and sometimes you will see calls 
from the two "overseas" US states [HI & AL], the US territories, and the 
Commonwealth of Puerto Rico seemingly out of place by transmitting from 
someplace else like Virginia or Massachusetts.  There a several stations on now 
operating under CEPT and other reciprocal permits.  I worked a few within the 
past few days and saw some this morning.  Of course there will be many other 
CERT calls on the bands when the spring and summer vacation season begins, and 
when this year's DXpeditions and DXvacations get up and roaring. 

Looking forward to you all overcoming the compound call issue.  

 73 and Aloha from Virginia, Danny W4/AH6FX 
 

  
|  
|   |  
Amateur Radio Ham Radio Maidenhead Grid Square Locator Map
 Amateur Radio Ham Radio Maidenhead Grid Locator in Google Maps  |  |

  |

 
 

On Wednesday, January 9, 2019 8:36 AM, Bill Somerville 
 wrote:
 

 On 09/01/2019 12:05, Bill Somerville wrote:
> If you are in this situation then you must either send you gridsquare 
> post QSO in a free text message if you want to give your QSO partner a 
> chance to recognize you are not in HI, or use a compound callsign that 
> indicates your location like /W4.

Hi again,

a correction to the above.

"If you are in this situation then you must either use a compound 
callsign 

[wsjt-devel] rigctlcom

[Black Michael via wsjt-devel]

I need some testers for a new hamlib program I'm calling "rigctlcom".  It is a 
TS-2000 emulator that will allow programs that don't know FLRig or rigctld to 
talk to those two programs.
App->COMX->COMY->rigctlcom->rig
This will allow you to run, for example, N1MM and WSJT-X both accessing your 
rig through FLRig or rigctld.  Should also work with MMTTY or any other such 
program.  Does not quite work yet with WSJT-X but WSJT-X can connect to rigctld 
or flrig so it's not really needed there.
Here's a link to a Windows executable.  You'll have to install WSJT-X if you 
don't already have it.And using FLRig will easily allow multiple programs to 
connect to your rig so install that too.  It will also allow multiple 
connections with rigctld as the primary rig if you want to go that route.
https://www.dropbox.com/s/1dye13rqyc4ve4i/rigctlcom.exe?dl=1

Place the executable in the wsjtx\bin directory where rigctl.exe resides.
You need a virtual serial port program like Eltima's or this free 
one.https://freevirtualserialports.com/

#1 Create a bridged serial port pair.  e.g. COM9/COM10#2 Run rigctlcom to 
connect to FLRig (or rigctld) and one of the virtual COM ports...e.g. COM9    
rigctlcom -m 4 -r 127.0.0.1:12345 -R COM9 -S 115200
#3 Run your other program, e.g. N1MM and connect it to the other COM 
port...e.g. COM10 as a TS-2000 8-N-1 115200baud#4 If you want to run multiple 
programs via COM ports you'll need another instance of rigctlcom for each app 
that needs a COM port.
de Mike W9MDB



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] wrong time logged

[Al]

(WSJT-X V2.0.0, W 10 )
This may have been reported before ??

I was on earlier today and made several 80 contacts ending at 1319.
I left the radio running  and came back at ~16:17 and changed bands to 17m.
My first contact on 17m was at 16:19 but the logs recorded that contact 
time at 13:21.


AL, K0VM
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel