Re: [wsjt-devel] WSJT Audio Input Loss

[Black Michael via wsjt-devel]

You can run a 2nd copy of WSJT-X (perhaps the other version that had problems?) 
and see if it locks up.
Just add the -r option and pick a name
wsjtx -r test
de Mike W9MDB

 

On Saturday, July 6, 2019, 04:57:44 PM CDT, Hasan al-Basri 
 wrote:  
 
 31 hours and counting since I installed the debug version you sent me the link 
to. No errors. Will report more tomorrow morning.I can't imagine that this 
install somehow fixed the issue?73, N0ANHasan

On Sat, Jul 6, 2019 at 2:38 PM Black Michael via wsjt-devel 
 wrote:

What web browser do you use?  There aren't a lot of these report so it doesn't 
seem like this is a common problem otherwise we'd hear more about it5.
There has to be something in common.
So what does your audio path look like?  Rig, sound card, USB Hub?, PC model. 
de Mike W9MDB

 

On Saturday, July 6, 2019, 02:32:27 PM CDT, Rick Drexel  
wrote:  
 
 Your observations match those I have seen for about a year.  I've tried to 
find a common set of circumstances that always cause the failure but have had 
no luck.  I use WSJT-X in FT8 receive mode and PSKREPORTER to check band 
performance over a long time period.  After a random amount of time, WSJT-X 
come to a halt.  Specifically the Wide Graph Display and the Band Activity 
Display stop updating.  The UTC in the Wide Graph Display no longer matches the 
UTC in the bottom left portion of the Main window.  There is no correlation 
between the activity on the band and the time it takes to hang.  Rarely does it 
not hang.
As a software developer this has all the hallmarks of a race condition failure. 
 Two (or more) threads update a shared resource without using a LOCK, UPDATE, 
UNLOCK sequence.  During a thread context swap one of the threads reads the 
value, loses control to another thread that updates the value, then the first 
thread gets scheduled and writes back its stale value.  The result is undefined 
behavior.
Most of the time there is no conflict.  Even under a heavy load.  Then it fails 
unexpectedly.  This makes it extremely difficult to debug.
To recover I have to exit out of WSJT-X and restart it.  
This might not be the root cause but I would put it high on my list of the 
usual suspects.
73, Rick
WK1P


From: Peter Putnam 
Sent: Wednesday, July 3, 2019 3:06 PM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] WSJT Audio Input Loss Greetings,

I have been using WSJT-X quite successfully for several years during 
June VHF Contests. I experienced a failure of the WSJT program to accept 
received audio input after several hours of proper operation during the 
recent Field Day exercise.

I'll provide a brief outline and reply with more detail, should it be 
needed.

My computer is a Dell Optiplex 780 running Win 7 Pro SP1, 64-bit. The 
WSJT-X software version is 2.0.1 7ddcb7.

My receiver is a Flex 6500. It passes data to a Flex-supplied "DAX" 
program that interfaces various applications that wish to receive the 
audio stream. WSJT accepts the stream and displays results on the Wide 
Graph and a small audio signal-strength window. Activity proceeded 
normally for the first three hours of Field Day, until both the Wide 
Graph and the audio signal-strength stopped showing any incoming audio.

I can't offer any help on what might have caused the problem. It was 
abrupt and seemingly unrelated to any other system actions. I am unable 
to reproduce the problem.

Several operators spent several hours speculating about what a solution 
might be. Program restarts and computer re-boots (time-tested favorite 
of generations) changed nothing. The only useful clue was that the DAX 
audio output stream was present and could be re-directed to Fldigi, but 
not to WSJT-X.

I was able to restore operation for a brief period by stopping WSJT, 
renaming WSJT.ini and restarting WSJT. That fix lasted for a half hour. 
Repeating the procedure provided operation for the rest of Field Day.

The two .ini files that were renamed are available for your inspection, 
along with the one that continued to function.

Any suggestions you can offer to prevent a recurrence would be greatly 
appreciated.

Regards,
Peter
NI6E






___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7Cc8a88765c47b45e54e0208d6ffea13fc%7C84df9e7fe9f640afb435%7C1%7C0%7C63698175354267sdata=QIhhN8eBXU7WkgMKIK4WOGh%2BO2Zt6d3mRyQ5qFFV%2FGM%3Dreserved=0
___
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

Re: [wsjt-devel] Cannot get trace mode to turn on correctly [RPi debug build v2.0.1]: suggestions?

[Phil Erickson]

Hi Bill,

Ok. Will report back to you. I do not have the radio here right now and I
would like to obtain it again to make sure the error occurs again before
spending any more of your time on it.

73
Phil W1PJE

On Sat, Jul 6, 2019 at 19:59 Bill Somerville  wrote:

> On 06/07/2019 23:59, Phil Erickson wrote:
> > Hi Bill,
> >
> >   I'm trying to trace problems documented in this previous message to
> > the list:
> >
> > https://sourceforge.net/p/wsjt/mailman/message/36701791/
> >
> >   I'm happy not to try and compile a debug version if you happen to
> > have any insight there!
> >
> > 73
> > Phil W1PJE
> >
> Hi Phil,
>
> you didn't say if you located the trace log file?
>
> Does rig control work if you set WSJT-X to talk directly to the rig over
> the CI-V interface serial port?
>
> Do you have any offset set in "Settings->Frequencies->Station Details"?
>
> Please answer these questions before including any more information
> about your setup or this issue.
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
-- 

Phil Erickson
phil.erick...@gmail.com
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Cannot get trace mode to turn on correctly [RPi debug build v2.0.1]: suggestions?

[Bill Somerville]

On 06/07/2019 23:59, Phil Erickson wrote:

Hi Bill,

  I'm trying to trace problems documented in this previous message to 
the list:


https://sourceforge.net/p/wsjt/mailman/message/36701791/

  I'm happy not to try and compile a debug version if you happen to 
have any insight there!


73
Phil W1PJE


Hi Phil,

you didn't say if you located the trace log file?

Does rig control work if you set WSJT-X to talk directly to the rig over 
the CI-V interface serial port?


Do you have any offset set in "Settings->Frequencies->Station Details"?

Please answer these questions before including any more information 
about your setup or this issue.


73
Bill
G4WJS.



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

[wsjt-devel] Request for FT8 and FT4 Logs

[Ed Muns]

We are testing the log submittal and log checking process for the upcoming WW 
Digi DX Contest at the end of August.  We need logs to test with.

 

At the end of May 2019, I worked over 600 QSOs on FT8 and FT4 as P49X.  I would 
appreciate it if anyone who worked P49X on the FT modes would please send me 
their ADIF log file.  It can be any date range as long as it includes the end 
of May QSOs with P49X.  Our software can ignore QSOs outside that period.

 

Just forward your ADIF log file to w...@ww-digi.com   
to help us get ready for log processing.

 

Thanks,

Ed

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

Re: [wsjt-devel] Cannot get trace mode to turn on correctly [RPi debug build v2.0.1]: suggestions?

[Phil Erickson]

Hi Bill,

  I'm trying to trace problems documented in this previous message to the
list:

https://sourceforge.net/p/wsjt/mailman/message/36701791/

  I'm happy not to try and compile a debug version if you happen to have
any insight there!

73
Phil W1PJE


On Sat, Jul 6, 2019 at 6:54 PM Bill Somerville 
wrote:

> On 06/07/2019 23:30, Phil Erickson wrote:
> > It made a new executable in /usr/local/bin as expected, but when I ran
> > it, there is no sign of the "..trace.log" file in /tmp.
>
> HI Phil,
>
> the name of the trace log file is:
>
> /tmp/WSJT-X_trace.log
>
> or if you pass a --rig-name=xxx command line argument it will be:
>
> "/tmp/WSJT-X - xxx_trace.log"
>
> What CAT problems are you trying to fix? Have you tried using rigctld
> (wsjtx-rigctld built with WSJT-X), with that you can get Hamlib CAT
> trace information by starting the wsjtx_rigctld daemon with a -v
> option. Connect to wsjtx_rigctld by selecting "Hamlib Net rigctl" as the
> rig in WSJT-X "Settings->Radio->Rig".
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>


-- 

Phil Erickson
phil.erick...@gmail.com
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Cannot get trace mode to turn on correctly [RPi debug build v2.0.1]: suggestions?

[Bill Somerville]

On 06/07/2019 23:30, Phil Erickson wrote:
It made a new executable in /usr/local/bin as expected, but when I ran 
it, there is no sign of the "..trace.log" file in /tmp.


HI Phil,

the name of the trace log file is:

/tmp/WSJT-X_trace.log

or if you pass a --rig-name=xxx command line argument it will be:

"/tmp/WSJT-X - xxx_trace.log"

What CAT problems are you trying to fix? Have you tried using rigctld 
(wsjtx-rigctld built with WSJT-X), with that you can get Hamlib CAT 
trace information by starting the wsjtx_rigctld daemon with a -v 
option. Connect to wsjtx_rigctld by selecting "Hamlib Net rigctl" as the 
rig in WSJT-X "Settings->Radio->Rig".


73
Bill
G4WJS.



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

[wsjt-devel] Cannot get trace mode to turn on correctly [RPi debug build v2.0.1]: suggestions?

[Phil Erickson]

Hi all,

  Please forgive the somewhat newbie question (although I've been doing
compiles since SysV days in the early 80s), but I cannot for the life of me
get the debug trace log mode to compile in correctly using the latest
Debian Stretch installation on a Raspberry Pi.  Hopefully someone can point
out what I'm doing wrong.  I'm having some CAT problems and wanted to get
debug traces.

  I first installed the prerequisites with "apt-get install" following this
page:

https://www.kk5jy.net/wsjtx-build/

  I downloaded v2.0.1 and executed:

tar -zxvf wsjtx-2.0.1.tgz
mkdir build
cd build

  I then executed "cmake-gui" and set the following switches on:

WSJT_TRACE_CAT=ON
WSJT_HAMLIB_TRACE=ON
WSJT_HAMLIB_VERBOSE_TRACE=ON
WSJT_QDEBUG_TO_FILE=ON
WSJT_QDEBUG_IN_RELEASE=ON

  That generated the "CMakeCache.txt" file attached below, except that I
further edited it after "cmake-gui" to set the build to

CMAKE_BUILD_TYPE:STRING=RelWithDebInfo

  After that, I made the application as usual:

make
sudo make install

  It made a new executable in /usr/local/bin as expected, but when I ran
it, there is no sign of the "..trace.log" file in /tmp.  Furthermore,
examining the binary shows I think that the needed debugging flags were
never set on compile based on the following:

cd /usr/local/bin
strings wsjtx | grep trace.log   (returns no output)

  I expected the above command to return a match since if
WSJT_QDEBUG_TO_FILE were really on at compile time, the following code from
"main.cpp" ought to have been included:

#if WSJT_QDEBUG_TO_FILE
  // Open a trace file
  TraceFile trace_file {temp_dir.absoluteFilePath (a.applicationName ()
+ "_trace.log")};
  qSetMessagePattern ("[%{time MMdd HH:mm:ss.zzz t}
%{if-debug}D%{endif}%{if-info}I%{endif}%{if-warning}W%{endif}%{if-critical}C%{endif}%{if-fatal}F%{endif}]
%{file}:%{line} - %{message}");
  qDebug () << program_title (revision ()) + " - Program startup";
#endif

  The first statement after the "#if" means I should have been able to find
"trace.log" in a string within the compiled program somewhere.  But I
didn't.

  Any suggestions?  Where did I mess up?  I've spent a long time on this
one and I'm pretty stumped.  By the way, I also tried a "Debug" build type
and that didn't work either.

73
Phil W1PJE
# This is the CMakeCache file.
# For build in directory: /home/pi/src/wsjtx/build_debug
# It was generated by CMake: /usr/bin/cmake
# You can edit this file to change values found and used by cmake.
# If you do not want to change any of the values, simply exit the editor.
# If you do want to change a value, simply edit, save, and exit the editor.
# The syntax for the file is as follows:
# KEY:TYPE=VALUE
# KEY is the name of a variable in the cache.
# TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!.
# VALUE is the current value for the KEY.


# EXTERNAL cache entries


//Path to a program.
CMAKE_AR:FILEPATH=/usr/bin/ar

//Choose the type of build, options are: None(CMAKE_CXX_FLAGS or
// CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel.
CMAKE_BUILD_TYPE:STRING=RelWithDebInfo

//Enable/Disable color output during build.
CMAKE_COLOR_MAKEFILE:BOOL=ON

//CXX compiler
CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++

//Flags used by the compiler during all build types.
CMAKE_CXX_FLAGS:STRING=-O2 -march=native -mtune=native

//Flags used by the compiler during debug builds.
CMAKE_CXX_FLAGS_DEBUG:STRING=-g

//Flags used by the compiler during release builds for minimum
// size.
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG

//Flags used by the compiler during release builds.
CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG

//Flags used by the compiler during release builds with debug info.
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG

//C compiler
CMAKE_C_COMPILER:FILEPATH=/usr/bin/cc

//Flags used by the compiler during all build types.
CMAKE_C_FLAGS:STRING=-O2 -march=native -mtune=native

//Flags used by the compiler during debug builds.
CMAKE_C_FLAGS_DEBUG:STRING=-g

//Flags used by the compiler during release builds for minimum
// size.
CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG

//Flags used by the compiler during release builds.
CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG

//Flags used by the compiler during release builds with debug info.
CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG

//Flags used by the linker.
CMAKE_EXE_LINKER_FLAGS:STRING=

//Flags used by the linker during debug builds.
CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING=

//Flags used by the linker during release minsize builds.
CMAKE_EXE_LINKER_FLAGS_MINSIZEREL:STRING=

//Flags used by the linker during release builds.
CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING=

//Flags used by the linker during Release with Debug Info builds.
CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING=

//Enable/Disable output of compile commands during generation.
CMAKE_EXPORT_COMPILE_COMMANDS:BOOL=OFF

//Install path prefix, prepended onto install 

Re: [wsjt-devel] WSJT Audio Input Loss

[Rick Drexel]

The rig is an Icom IC-7100 connected by a USB cable directly to a Windows 10 
64-bit desktop machine with 32 GB RAM. No sound card needed but I do have to 
check Settings to make sure WSJT-X Audio Tab hasn’t changed after a forced 
restart.

I use Firefox or IE to open PskReporter to see what’s been reported by WSJT-X 
during the monitoring period.

Rick WK1P




From: Black Michael via wsjt-devel 
Sent: Saturday, July 6, 2019 3:35:43 PM
To: pe...@ni6e.com; WSJT software development
Cc: Black Michael
Subject: Re: [wsjt-devel] WSJT Audio Input Loss

What web browser do you use?  There aren't a lot of these report so it doesn't 
seem like this is a common problem otherwise we'd hear more about it5.

There has to be something in common.

So what does your audio path look like?  Rig, sound card, USB Hub?, PC model.

de Mike W9MDB




On Saturday, July 6, 2019, 02:32:27 PM CDT, Rick Drexel  wrote:


Your observations match those I have seen for about a year.  I've tried to find 
a common set of circumstances that always cause the failure but have had no 
luck.  I use WSJT-X in FT8 receive mode and PSKREPORTER to check band 
performance over a long time period.  After a random amount of time, WSJT-X 
come to a halt.  Specifically the Wide Graph Display and the Band Activity 
Display stop updating.  The UTC in the Wide Graph Display no longer matches the 
UTC in the bottom left portion of the Main window.  There is no correlation 
between the activity on the band and the time it takes to hang.  Rarely does it 
not hang.

As a software developer this has all the hallmarks of a race condition failure. 
 Two (or more) threads update a shared resource without using a LOCK, UPDATE, 
UNLOCK sequence.  During a thread context swap one of the threads reads the 
value, loses control to another thread that updates the value, then the first 
thread gets scheduled and writes back its stale value.  The result is undefined 
behavior.

Most of the time there is no conflict.  Even under a heavy load.  Then it fails 
unexpectedly.  This makes it extremely difficult to debug.

To recover I have to exit out of WSJT-X and restart it.

This might not be the root cause but I would put it high on my list of the 
usual suspects.

73, Rick
WK1P



From: Peter Putnam 
Sent: Wednesday, July 3, 2019 3:06 PM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] WSJT Audio Input Loss

Greetings,

I have been using WSJT-X quite successfully for several years during
June VHF Contests. I experienced a failure of the WSJT program to accept
received audio input after several hours of proper operation during the
recent Field Day exercise.

I'll provide a brief outline and reply with more detail, should it be
needed.

My computer is a Dell Optiplex 780 running Win 7 Pro SP1, 64-bit. The
WSJT-X software version is 2.0.1 7ddcb7.

My receiver is a Flex 6500. It passes data to a Flex-supplied "DAX"
program that interfaces various applications that wish to receive the
audio stream. WSJT accepts the stream and displays results on the Wide
Graph and a small audio signal-strength window. Activity proceeded
normally for the first three hours of Field Day, until both the Wide
Graph and the audio signal-strength stopped showing any incoming audio.

I can't offer any help on what might have caused the problem. It was
abrupt and seemingly unrelated to any other system actions. I am unable
to reproduce the problem.

Several operators spent several hours speculating about what a solution
might be. Program restarts and computer re-boots (time-tested favorite
of generations) changed nothing. The only useful clue was that the DAX
audio output stream was present and could be re-directed to Fldigi, but
not to WSJT-X.

I was able to restore operation for a brief period by stopping WSJT,
renaming WSJT.ini and restarting WSJT. That fix lasted for a half hour.
Repeating the procedure provided operation for the rest of Field Day.

The two .ini files that were renamed are available for your inspection,
along with the one that continued to function.

Any suggestions you can offer to prevent a recurrence would be greatly
appreciated.

Regards,
Peter
NI6E






___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7Cc8a88765c47b45e54e0208d6ffea13fc%7C84df9e7fe9f640afb435%7C1%7C0%7C63698175354267sdata=QIhhN8eBXU7WkgMKIK4WOGh%2BO2Zt6d3mRyQ5qFFV%2FGM%3Dreserved=0

___
wsjt-devel mailing list

Re: [wsjt-devel] WSJT Audio Input Loss

[Hasan al-Basri]

31 hours and counting since I installed the debug version you sent me the
link to. No errors. Will report more tomorrow morning.
I can't imagine that this install somehow fixed the issue?
73, N0AN
Hasan


On Sat, Jul 6, 2019 at 2:38 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> What web browser do you use?  There aren't a lot of these report so it
> doesn't seem like this is a common problem otherwise we'd hear more about
> it5.
>
> There has to be something in common.
>
> So what does your audio path look like?  Rig, sound card, USB Hub?, PC
> model.
>
> de Mike W9MDB
>
>
>
>
> On Saturday, July 6, 2019, 02:32:27 PM CDT, Rick Drexel 
> wrote:
>
>
> Your observations match those I have seen for about a year.  I've tried to
> find a common set of circumstances that always cause the failure but have
> had no luck.  I use WSJT-X in FT8 receive mode and PSKREPORTER to check
> band performance over a long time period.  After a random amount of time,
> WSJT-X come to a halt.  Specifically the Wide Graph Display and the Band
> Activity Display stop updating.  The UTC in the Wide Graph Display no
> longer matches the UTC in the bottom left portion of the Main window.
> There is no correlation between the activity on the band and the time it
> takes to hang.  Rarely does it not hang.
>
> As a software developer this has all the hallmarks of a race condition
> failure.  Two (or more) threads update a shared resource without using a
> LOCK, UPDATE, UNLOCK sequence.  During a thread context swap one of the
> threads reads the value, loses control to another thread that updates the
> value, then the first thread gets scheduled and writes back its stale
> value.  The result is undefined behavior.
>
> Most of the time there is no conflict.  Even under a heavy load.  Then it
> fails unexpectedly.  This makes it extremely difficult to debug.
>
> To recover I have to exit out of WSJT-X and restart it.
>
> This might not be the root cause but I would put it high on my list of the
> usual suspects.
>
> 73, Rick
> WK1P
>
>
> --
> *From:* Peter Putnam 
> *Sent:* Wednesday, July 3, 2019 3:06 PM
> *To:* wsjt-devel@lists.sourceforge.net
> *Subject:* [wsjt-devel] WSJT Audio Input Loss
>
> Greetings,
>
> I have been using WSJT-X quite successfully for several years during
> June VHF Contests. I experienced a failure of the WSJT program to accept
> received audio input after several hours of proper operation during the
> recent Field Day exercise.
>
> I'll provide a brief outline and reply with more detail, should it be
> needed.
>
> My computer is a Dell Optiplex 780 running Win 7 Pro SP1, 64-bit. The
> WSJT-X software version is 2.0.1 7ddcb7.
>
> My receiver is a Flex 6500. It passes data to a Flex-supplied "DAX"
> program that interfaces various applications that wish to receive the
> audio stream. WSJT accepts the stream and displays results on the Wide
> Graph and a small audio signal-strength window. Activity proceeded
> normally for the first three hours of Field Day, until both the Wide
> Graph and the audio signal-strength stopped showing any incoming audio.
>
> I can't offer any help on what might have caused the problem. It was
> abrupt and seemingly unrelated to any other system actions. I am unable
> to reproduce the problem.
>
> Several operators spent several hours speculating about what a solution
> might be. Program restarts and computer re-boots (time-tested favorite
> of generations) changed nothing. The only useful clue was that the DAX
> audio output stream was present and could be re-directed to Fldigi, but
> not to WSJT-X.
>
> I was able to restore operation for a brief period by stopping WSJT,
> renaming WSJT.ini and restarting WSJT. That fix lasted for a half hour.
> Repeating the procedure provided operation for the rest of Field Day.
>
> The two .ini files that were renamed are available for your inspection,
> along with the one that continued to function.
>
> Any suggestions you can offer to prevent a recurrence would be greatly
> appreciated.
>
> Regards,
> Peter
> NI6E
>
>
>
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
>
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7Cc8a88765c47b45e54e0208d6ffea13fc%7C84df9e7fe9f640afb435%7C1%7C0%7C63698175354267sdata=QIhhN8eBXU7WkgMKIK4WOGh%2BO2Zt6d3mRyQ5qFFV%2FGM%3Dreserved=0
> 
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 

Re: [wsjt-devel] WSJT Audio Input Loss

[Black Michael via wsjt-devel]

We've heard a few people say IE has caused audio problems.
But...for the main testwhat happens if you run no browser at all?  And how 
often does it fail?
de Mike W9MDB


 

On Saturday, July 6, 2019, 04:48:26 PM CDT, Rick Drexel  
wrote:  
 
 The rig is an Icom IC-7100 connected by a USB cable directly to a Windows 10 
64-bit desktop machine with 32 GB RAM. No sound card needed but I do have to 
check Settings to make sure WSJT-X Audio Tab hasn’t changed after a forced 
restart.  
I use Firefox or IE to open PskReporter to see what’s been reported by WSJT-X 
during the monitoring period.  
Rick WK1P 


From: Black Michael via wsjt-devel 
Sent: Saturday, July 6, 2019 3:35:43 PM
To: pe...@ni6e.com; WSJT software development
Cc: Black Michael
Subject: Re: [wsjt-devel] WSJT Audio Input Loss What web browser do you use?  
There aren't a lot of these report so it doesn't seem like this is a common 
problem otherwise we'd hear more about it5.
There has to be something in common.
So what does your audio path look like?  Rig, sound card, USB Hub?, PC model. 
de Mike W9MDB



On Saturday, July 6, 2019, 02:32:27 PM CDT, Rick Drexel  wrote:

Your observations match those I have seen for about a year.  I've tried to find 
a common set of circumstances that always cause the failure but have had no 
luck.  I use WSJT-X in FT8 receive mode and PSKREPORTER to check band 
performance over a long time period.  After a random amount of time, WSJT-X 
come to a halt.  Specifically the Wide Graph Display and the Band Activity 
Display stop updating.  The UTC in the Wide Graph Display no longer matches the 
UTC in the bottom left portion of the Main window.  There is no correlation 
between the activity on the band and the time it takes to hang.  Rarely does it 
not hang.
As a software developer this has all the hallmarks of a race condition failure. 
 Two (or more) threads update a shared resource without using a LOCK, UPDATE, 
UNLOCK sequence.  During a thread context swap one of the threads reads the 
value, loses control to another thread that updates the value, then the first 
thread gets scheduled and writes back its stale value.  The result is undefined 
behavior.
Most of the time there is no conflict.  Even under a heavy load.  Then it fails 
unexpectedly.  This makes it extremely difficult to debug.
To recover I have to exit out of WSJT-X and restart it.  
This might not be the root cause but I would put it high on my list of the 
usual suspects.
73, Rick
WK1P


From: Peter Putnam 
Sent: Wednesday, July 3, 2019 3:06 PM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] WSJT Audio Input Loss Greetings,

I have been using WSJT-X quite successfully for several years during 
June VHF Contests. I experienced a failure of the WSJT program to accept 
received audio input after several hours of proper operation during the 
recent Field Day exercise.

I'll provide a brief outline and reply with more detail, should it be 
needed.

My computer is a Dell Optiplex 780 running Win 7 Pro SP1, 64-bit. The 
WSJT-X software version is 2.0.1 7ddcb7.

My receiver is a Flex 6500. It passes data to a Flex-supplied "DAX" 
program that interfaces various applications that wish to receive the 
audio stream. WSJT accepts the stream and displays results on the Wide 
Graph and a small audio signal-strength window. Activity proceeded 
normally for the first three hours of Field Day, until both the Wide 
Graph and the audio signal-strength stopped showing any incoming audio.

I can't offer any help on what might have caused the problem. It was 
abrupt and seemingly unrelated to any other system actions. I am unable 
to reproduce the problem.

Several operators spent several hours speculating about what a solution 
might be. Program restarts and computer re-boots (time-tested favorite 
of generations) changed nothing. The only useful clue was that the DAX 
audio output stream was present and could be re-directed to Fldigi, but 
not to WSJT-X.

I was able to restore operation for a brief period by stopping WSJT, 
renaming WSJT.ini and restarting WSJT. That fix lasted for a half hour. 
Repeating the procedure provided operation for the rest of Field Day.

The two .ini files that were renamed are available for your inspection, 
along with the one that continued to function.

Any suggestions you can offer to prevent a recurrence would be greatly 
appreciated.

Regards,
Peter
NI6E






___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7Cc8a88765c47b45e54e0208d6ffea13fc%7C84df9e7fe9f640afb435%7C1%7C0%7C63698175354267sdata=QIhhN8eBXU7WkgMKIK4WOGh%2BO2Zt6d3mRyQ5qFFV%2FGM%3Dreserved=0
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net

Re: [wsjt-devel] FT8 ghost signals

[George Molnar]

Hi Rich,

I’ve observed the same, exactly as you described. Had put it down to urban 
reflections, perhaps more obvious when W3/W4 is beaming N/NE. Agree with you 
they are not aircraft scatter.



George J Molnar
Arlington, Virginia, USA
(702) 767-5420
KF2T   -   FM18lv





> On Jul 6, 2019, at 4:06 PM, Rich Zwirko - K1HTV  wrote:
> 
> 
> Here in the Mid-Atlantic, a number of 6 Meter FT8 DXers have observed 
> backscatter signals that appear as a 2nd or even a 3rd signal on the WSJT-X 
> Wide Graph window. The Doppler shifted frequency is usually lower than the 
> direct signal. In addition to the directly received FT8 signal appearing on 
> the waterfall display, at times both direct signal as well as one or more of 
> the reflected backscatter Doppler shifted signals can be decoded. The DF 
> between the main and ghost signals is usually between 40 and 130 Hz. The 
> average appears to be around negative 70 Hz. 
> 
> When these ghost signals are observed, they are usually noted on multi-KW FT8 
> signals produced by stations in the Mid-Atlantic region that are beaming 
> towards highly ionization Es regions. These extra waterfall signals can last 
> a few minutes then quickly disappear. I have not observed them when there is 
> no Es opening. They don't appear to be the result of signals being reflected 
> off aircraft.
> 
> 73,
> Rich - K1HTV
> 
> = = =
> 
> From: Jim Brown [mailto:k...@audiosystemsgroup.com 
> ] 
> Sent: 6. heinäkuuta 2019 9:28
> To: wsjt-devel@lists.sourceforge.net 
> Subject: Re: [wsjt-devel] 60 Hz + harmonics sidebands on FT8 signals?
> 
> There are two common causes of sidebands with a station that is properly 
> adjusted and uses good equipment.
> 
> 1) The best gear (Elecraft K3, K3S, or a Flex 6000-series), and a first class 
> power amp) have sidebands roughly 40 dB down on both sides of their signal 
> due to IM distortion in the RF stages. These sidebands are generally 
> symmetrical, and the total -40 dB bandwidth is about 680 Hz.
> 
> 2) Doppler shift produced by reflections from aircraft. These sidebands are 
> generally asymmetrical (that is, on one side or the other of the main 
> signal). Here in the SF Bay Area, which includes Silicon Valley and extends 
> down along the Monterey Bay, we have glide paths for major airports in San 
> Jose and San Francisco.
> 
> There are roughly a dozen or so locals running 500W with gear like this, and 
> we all regularly experience what you're seeing.
> 
> 73, Jim K9YC  
> ___
> 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] FT8 ghost signals

[Rich Zwirko - K1HTV]

Here in the Mid-Atlantic, a number of 6 Meter FT8 DXers have observed
backscatter signals that appear as a 2nd or even a 3rd signal on the WSJT-X
Wide Graph window. The Doppler shifted frequency is usually lower than the
direct signal. In addition to the directly received FT8 signal appearing on
the waterfall display, at times both direct signal as well as one or more
of the reflected backscatter Doppler shifted signals can be decoded. The DF
between the main and ghost signals is usually between 40 and 130 Hz. The
average appears to be around negative 70 Hz.

When these ghost signals are observed, they are usually noted on multi-KW
FT8 signals produced by stations in the Mid-Atlantic region that are
beaming towards highly ionization Es regions. These extra waterfall signals
can last a few minutes then quickly disappear. I have not observed them
when there is no Es opening. They don't appear to be the result of signals
being reflected off aircraft.

73,
Rich - K1HTV

= = =

From: Jim Brown [mailto:k...@audiosystemsgroup.com]
Sent: 6. heinäkuuta 2019 9:28
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] 60 Hz + harmonics sidebands on FT8 signals?

There are two common causes of sidebands with a station that is properly
adjusted and uses good equipment.

1) The best gear (Elecraft K3, K3S, or a Flex 6000-series), and a first
class power amp) have sidebands roughly 40 dB down on both sides of their
signal due to IM distortion in the RF stages. These sidebands are generally
symmetrical, and the total -40 dB bandwidth is about 680 Hz.

2) Doppler shift produced by reflections from aircraft. These sidebands are
generally asymmetrical (that is, on one side or the other of the main
signal). Here in the SF Bay Area, which includes Silicon Valley and extends
down along the Monterey Bay, we have glide paths for major airports in San
Jose and San Francisco.

There are roughly a dozen or so locals running 500W with gear like this,
and we all regularly experience what you're seeing.

73, Jim K9YC
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT Audio Input Loss

[VE3FBZ]

Yeah, in the old days of data bases we used to call that ac”deadly embrace”


 Regards and 73s
VE3FBZ
London Amateur Radio Club
www.larc.ca 




> On Jul 6, 2019, at 14:54, Rick Drexel  wrote:
> 
> Your observations match those I have seen for about a year.  I've tried to 
> find a common set of circumstances that always cause the failure but have had 
> no luck.  I use WSJT-X in FT8 receive mode and PSKREPORTER to check band 
> performance over a long time  period.  After a random amount of time, WSJT-X 
> come to a halt.  Specifically the Wide Graph Display and the Band Activity 
> Display stop updating.  The UTC in the Wide Graph Display no longer matches 
> the UTC in the bottom left portion of the Main window.  There is no 
> correlation between the activity on the band and the time it takes to hang.  
> Rarely does it not hang.
> 
> As a software developer this has all the hallmarks of a race condition 
> failure.  Two (or more) threads update a shared resource without using a 
> LOCK, UPDATE, UNLOCK sequence.  During a thread context swap one of the 
> threads reads the value, loses control to another thread that updates the 
> value, then the first thread gets scheduled and writes back its stale value.  
> The result is undefined behavior.
> 
> Most of the time there is no conflict.  Even under a heavy load.  Then it 
> fails unexpectedly.  This makes it extremely difficult to debug.
> 
> To recover I have to exit out of WSJT-X and restart it. 
> 
> This might not be the root cause but I would put it high on my list of the 
> usual suspects.
> 
> 73, Rick
> WK1P
> 
> 
> From: Peter Putnam 
> Sent: Wednesday, July 3, 2019 3:06 PM
> To: wsjt-devel@lists.sourceforge.net
> Subject: [wsjt-devel] WSJT Audio Input Loss
>  
> Greetings,
> 
> I have been using WSJT-X quite successfully for several years during 
> June VHF Contests. I experienced a failure of the WSJT program to accept 
> received audio input after several hours of proper operation during the 
> recent Field Day exercise.
> 
> I'll provide a brief outline and reply with more detail, should it be 
> needed.
> 
> My computer is a Dell Optiplex 780 running Win 7 Pro SP1, 64-bit. The 
> WSJT-X software version is 2.0.1 7ddcb7.
> 
> My receiver is a Flex 6500. It passes data to a Flex-supplied "DAX" 
> program that interfaces various applications that wish to receive the 
> audio stream. WSJT accepts the stream and displays results on the Wide 
> Graph and a small audio signal-strength window. Activity proceeded 
> normally for the first three hours of Field Day, until both the Wide 
> Graph and the audio signal-strength stopped showing any incoming audio.
> 
> I can't offer any help on what might have caused the problem. It was 
> abrupt and seemingly unrelated to any other system actions. I am unable 
> to reproduce the problem.
> 
> Several operators spent several hours speculating about what a solution 
> might be. Program restarts and computer re-boots (time-tested favorite 
> of generations) changed nothing. The only useful clue was that the DAX 
> audio output stream was present and could be re-directed to Fldigi, but 
> not to WSJT-X.
> 
> I was able to restore operation for a brief period by stopping WSJT, 
> renaming WSJT.ini and restarting WSJT. That fix lasted for a half hour. 
> Repeating the procedure provided operation for the rest of Field Day.
> 
> The two .ini files that were renamed are available for your inspection, 
> along with the one that continued to function.
> 
> Any suggestions you can offer to prevent a recurrence would be greatly 
> appreciated.
> 
> Regards,
> Peter
> NI6E
> 
> 
> 
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7Cc8a88765c47b45e54e0208d6ffea13fc%7C84df9e7fe9f640afb435%7C1%7C0%7C63698175354267sdata=QIhhN8eBXU7WkgMKIK4WOGh%2BO2Zt6d3mRyQ5qFFV%2FGM%3Dreserved=0
> ___
> 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] WSJT Audio Input Loss

[Black Michael via wsjt-devel]

What web browser do you use?  There aren't a lot of these report so it doesn't 
seem like this is a common problem otherwise we'd hear more about it5.
There has to be something in common.
So what does your audio path look like?  Rig, sound card, USB Hub?, PC model. 
de Mike W9MDB

 

On Saturday, July 6, 2019, 02:32:27 PM CDT, Rick Drexel  
wrote:  
 
 Your observations match those I have seen for about a year.  I've tried to 
find a common set of circumstances that always cause the failure but have had 
no luck.  I use WSJT-X in FT8 receive mode and PSKREPORTER to check band 
performance over a long time period.  After a random amount of time, WSJT-X 
come to a halt.  Specifically the Wide Graph Display and the Band Activity 
Display stop updating.  The UTC in the Wide Graph Display no longer matches the 
UTC in the bottom left portion of the Main window.  There is no correlation 
between the activity on the band and the time it takes to hang.  Rarely does it 
not hang.
As a software developer this has all the hallmarks of a race condition failure. 
 Two (or more) threads update a shared resource without using a LOCK, UPDATE, 
UNLOCK sequence.  During a thread context swap one of the threads reads the 
value, loses control to another thread that updates the value, then the first 
thread gets scheduled and writes back its stale value.  The result is undefined 
behavior.
Most of the time there is no conflict.  Even under a heavy load.  Then it fails 
unexpectedly.  This makes it extremely difficult to debug.
To recover I have to exit out of WSJT-X and restart it.  
This might not be the root cause but I would put it high on my list of the 
usual suspects.
73, Rick
WK1P


From: Peter Putnam 
Sent: Wednesday, July 3, 2019 3:06 PM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] WSJT Audio Input Loss Greetings,

I have been using WSJT-X quite successfully for several years during 
June VHF Contests. I experienced a failure of the WSJT program to accept 
received audio input after several hours of proper operation during the 
recent Field Day exercise.

I'll provide a brief outline and reply with more detail, should it be 
needed.

My computer is a Dell Optiplex 780 running Win 7 Pro SP1, 64-bit. The 
WSJT-X software version is 2.0.1 7ddcb7.

My receiver is a Flex 6500. It passes data to a Flex-supplied "DAX" 
program that interfaces various applications that wish to receive the 
audio stream. WSJT accepts the stream and displays results on the Wide 
Graph and a small audio signal-strength window. Activity proceeded 
normally for the first three hours of Field Day, until both the Wide 
Graph and the audio signal-strength stopped showing any incoming audio.

I can't offer any help on what might have caused the problem. It was 
abrupt and seemingly unrelated to any other system actions. I am unable 
to reproduce the problem.

Several operators spent several hours speculating about what a solution 
might be. Program restarts and computer re-boots (time-tested favorite 
of generations) changed nothing. The only useful clue was that the DAX 
audio output stream was present and could be re-directed to Fldigi, but 
not to WSJT-X.

I was able to restore operation for a brief period by stopping WSJT, 
renaming WSJT.ini and restarting WSJT. That fix lasted for a half hour. 
Repeating the procedure provided operation for the rest of Field Day.

The two .ini files that were renamed are available for your inspection, 
along with the one that continued to function.

Any suggestions you can offer to prevent a recurrence would be greatly 
appreciated.

Regards,
Peter
NI6E






___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7Cc8a88765c47b45e54e0208d6ffea13fc%7C84df9e7fe9f640afb435%7C1%7C0%7C63698175354267sdata=QIhhN8eBXU7WkgMKIK4WOGh%2BO2Zt6d3mRyQ5qFFV%2FGM%3Dreserved=0
___
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] WSJT Audio Input Loss

[Rick Drexel]

Your observations match those I have seen for about a year.  I've tried to find 
a common set of circumstances that always cause the failure but have had no 
luck.  I use WSJT-X in FT8 receive mode and PSKREPORTER to check band 
performance over a long time period.  After a random amount of time, WSJT-X 
come to a halt.  Specifically the Wide Graph Display and the Band Activity 
Display stop updating.  The UTC in the Wide Graph Display no longer matches the 
UTC in the bottom left portion of the Main window.  There is no correlation 
between the activity on the band and the time it takes to hang.  Rarely does it 
not hang.

As a software developer this has all the hallmarks of a race condition failure. 
 Two (or more) threads update a shared resource without using a LOCK, UPDATE, 
UNLOCK sequence.  During a thread context swap one of the threads reads the 
value, loses control to another thread that updates the value, then the first 
thread gets scheduled and writes back its stale value.  The result is undefined 
behavior.

Most of the time there is no conflict.  Even under a heavy load.  Then it fails 
unexpectedly.  This makes it extremely difficult to debug.

To recover I have to exit out of WSJT-X and restart it.

This might not be the root cause but I would put it high on my list of the 
usual suspects.

73, Rick
WK1P



From: Peter Putnam 
Sent: Wednesday, July 3, 2019 3:06 PM
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] WSJT Audio Input Loss

Greetings,

I have been using WSJT-X quite successfully for several years during
June VHF Contests. I experienced a failure of the WSJT program to accept
received audio input after several hours of proper operation during the
recent Field Day exercise.

I'll provide a brief outline and reply with more detail, should it be
needed.

My computer is a Dell Optiplex 780 running Win 7 Pro SP1, 64-bit. The
WSJT-X software version is 2.0.1 7ddcb7.

My receiver is a Flex 6500. It passes data to a Flex-supplied "DAX"
program that interfaces various applications that wish to receive the
audio stream. WSJT accepts the stream and displays results on the Wide
Graph and a small audio signal-strength window. Activity proceeded
normally for the first three hours of Field Day, until both the Wide
Graph and the audio signal-strength stopped showing any incoming audio.

I can't offer any help on what might have caused the problem. It was
abrupt and seemingly unrelated to any other system actions. I am unable
to reproduce the problem.

Several operators spent several hours speculating about what a solution
might be. Program restarts and computer re-boots (time-tested favorite
of generations) changed nothing. The only useful clue was that the DAX
audio output stream was present and could be re-directed to Fldigi, but
not to WSJT-X.

I was able to restore operation for a brief period by stopping WSJT,
renaming WSJT.ini and restarting WSJT. That fix lasted for a half hour.
Repeating the procedure provided operation for the rest of Field Day.

The two .ini files that were renamed are available for your inspection,
along with the one that continued to function.

Any suggestions you can offer to prevent a recurrence would be greatly
appreciated.

Regards,
Peter
NI6E






___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7Cc8a88765c47b45e54e0208d6ffea13fc%7C84df9e7fe9f640afb435%7C1%7C0%7C63698175354267sdata=QIhhN8eBXU7WkgMKIK4WOGh%2BO2Zt6d3mRyQ5qFFV%2FGM%3Dreserved=0
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] 60 Hz + harmonics sidebands on FT8 signals?

[Reino Talarmo]

When those sidebands are 60 Hz steps from the main signal, then there is a 60 
Hz mains and the audio going into an nonlinear part in the transmitter and 
those signals are mixed together. More often the sidebands are in 120 Hz steps 
due to full wave rectification in power supply. If in an power amplifier its 
gain is dependent of voltage, then it acts as an amplitude modulator and the 
modulation waveform is a kind of triangle 120 Hz that contains multiples of 120 
Hz. That happens easier, when most output power is pressed from the amplifier. 
Keeping amplifier in linear range normally helps.
40 dB down is quite good, but could be better; there are many signal with 
sidebands a bit more than 30 dB down.
73, Reino oh3ma

-Original Message-
From: Jim Brown [mailto:k...@audiosystemsgroup.com] 
Sent: 6. heinäkuuta 2019 9:28
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] 60 Hz + harmonics sidebands on FT8 signals?

There are two common causes of sidebands with a station that is properly 
adjusted and uses good equipment.

1) The best gear (Elecraft K3, K3S, or a Flex 6000-series), and a first class 
power amp) have sidebands roughly 40 dB down on both sides of their signal due 
to IM distortion in the RF stages. These sidebands are generally symmetrical, 
and the total -40 dB bandwidth is about 680 Hz.

2) Doppler shift produced by reflections from aircraft. These sidebands are 
generally asymmetrical (that is, on one side or the other of the main signal). 
Here in the SF Bay Area, which includes Silicon Valley and extends down along 
the Monterey Bay, we have glide paths for major airports in San Jose and San 
Francisco.

There are roughly a dozen or so locals running 500W with gear like this, and we 
all regularly experience what you're seeing.

73, Jim K9YC

On 7/5/2019 11:02 PM, Paul Kube wrote:
> ’ve seen various kinds of problematic  FT8 signals that I think I 
> understand -- “barcode” harmonics etc. – but what is going on here:



___
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] Field Day time problem

[Claude Frantz]

On 6/24/19 12:11 AM, Topher Petty wrote:

Hi Topher and all,

GPSD (Linux and OSX should be able to run this) can sync time to the 
computer from a GPS receiver... I've used that in the past on where 
internet access is problematic and time sync was critical.


I can confirm that using gpsd and ntpd is a good solution. Running ntpd 
with a GPS mouse connected via USB and 3 NTP server via a good Internet 
connection, gave me the opportunity to compare these sources, looking at 
the ntpd statistics with ntpq.


Some recommendations based on my own observations:

The system needs some time to stabilize, when we expect good results. 
Looking to the ntpd statistics with ntpq was the way I have used.


The GPS mouse need a good view to the sky, in order to see numerous 
satellites. Use the GPS utilities to look at the mouse stats.


Don't use long USB hub chains and don't intermix USB2 and USB3.

In the fudge line of the ntp.conf, insert an appropriate value as time1. 
In my environment, time1 0.265 was as good value for a mouse using the 
Venus 8 chip. time1 0.180 was a good value for a mouse with an ublox-5 
chip.


Not all mice are made equal. With the Venus 8 chip, I got good, stable 
and more precise values as with the ublox-5 chip.


A cheap USB 
GPS unit could then be purchased (I've seen them as low as $5 on US 
sites, and around $2 on alibaba/aliexpress) for that purpose. Plug in 
the GPS, run GPSD, sync, go.


I cannot confirm that such a quick plug and go strategy give good results.

Best wishes,
Claude (DJ0OT)


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

Re: [wsjt-devel] WSJT Audio Input Loss

[Claude Frantz]

On 7/6/19 5:59 AM, Black Michael via wsjt-devel wrote:

If you're not seeing dropout messages with the dropout debug version 
than your audio stream has completely stopped.

The dropouts are only checked when the audio packets are flowing.
You should be seeing a few messages at startup about dataSink1 like this 
to ensure you're running the dropout version.

Inline image


What is the reason why your PNG image has a ".jpg" suffix ?

Best wishes,
Claude (DJ0OT)


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

Re: [wsjt-devel] 60 Hz + harmonics sidebands on FT8 signals?

[Jim Brown]

BTW -- IMD that's 40 dB down is quite good and better than FCC 
type-acceptance specs -- it takes a very good rig and a first rate tube 
or solid state power amp to achieve that.


73, Jim K9YC

On 7/5/2019 11:27 PM, Jim Brown wrote:
There are two common causes of sidebands with a station that is properly 
adjusted and uses good equipment.


1) The best gear (Elecraft K3, K3S, or a Flex 6000-series), and a first 
class power amp) have sidebands roughly 40 dB down on both sides of 
their signal due to IM distortion in the RF stages. These sidebands are 
generally symmetrical, and the total -40 dB bandwidth is about 680 Hz.


2) Doppler shift produced by reflections from aircraft. These sidebands 
are generally asymmetrical (that is, on one side or the other of the 
main signal). Here in the SF Bay Area, which includes Silicon Valley and 
extends down along the Monterey Bay, we have glide paths for major 
airports in San Jose and San Francisco.


There are roughly a dozen or so locals running 500W with gear like this, 
and we all regularly experience what you're seeing.


73, Jim K9YC

On 7/5/2019 11:02 PM, Paul Kube wrote:
’ve seen various kinds of problematic  FT8 signals that I think I 
understand -- “barcode” harmonics etc. – but what is going on here:




___
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] 60 Hz + harmonics sidebands on FT8 signals?

[Jim Brown]

There are two common causes of sidebands with a station that is properly 
adjusted and uses good equipment.


1) The best gear (Elecraft K3, K3S, or a Flex 6000-series), and a first 
class power amp) have sidebands roughly 40 dB down on both sides of 
their signal due to IM distortion in the RF stages. These sidebands are 
generally symmetrical, and the total -40 dB bandwidth is about 680 Hz.


2) Doppler shift produced by reflections from aircraft. These sidebands 
are generally asymmetrical (that is, on one side or the other of the 
main signal). Here in the SF Bay Area, which includes Silicon Valley and 
extends down along the Monterey Bay, we have glide paths for major 
airports in San Jose and San Francisco.


There are roughly a dozen or so locals running 500W with gear like this, 
and we all regularly experience what you're seeing.


73, Jim K9YC

On 7/5/2019 11:02 PM, Paul Kube wrote:
’ve seen various kinds of problematic  FT8 signals that I think I 
understand -- “barcode” harmonics etc. – but what is going on here:




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

[wsjt-devel] 60 Hz + harmonics sidebands on FT8 signals?

[Paul Kube]

I’ve seen various kinds of problematic  FT8 signals that I think I
understand -- “barcode” harmonics etc. – but what is going on here:


[image: multiple decode.PNG]

The “blackbox” station there (call elided, no need to name names) has
multiple sidebands on his main signal, some of them strong enough to be
separately decoded, all at multiples of 60 Hz. What is causing this?
Inadequate power supply filtering?



Pretty sure it’s not in my receive chain; I see many signals stronger than
this +12 dB one that are perfectly clean.



73, Paul K6PO
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel