Re: [wsjt-devel] Hamlib3 compile error

[Bill Somerville]

On 04/03/2017 02:51, Dan Malcolm wrote:
> The very first error encountered is "Win32 error 998" which is translated as
> "Invalid access to memory location".  Reading the Win10 Application log I
> find the faulting application is perl.exe and faulting module is
> msys-perl5_8.dll subsequent errors fault the same file or state 'unknown'.
> So far I have lots of indicator messages, but I don't yet have a handle on
> the problem.

Hi Dan,

open a JTSDK command prompt and type:

which perl

and report back what is printed please?

73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib3 compile error

[Dan Malcolm]

All,
The very first error encountered is "Win32 error 998" which is translated as
"Invalid access to memory location".  Reading the Win10 Application log I
find the faulting application is perl.exe and faulting module is
msys-perl5_8.dll subsequent errors fault the same file or state 'unknown'.
So far I have lots of indicator messages, but I don't yet have a handle on
the problem.

Prior to yesterday I have been able to compile the devel package just fine,
and did so every week or so.  Obviously something changed on my computer.

_
Dan Malcolm CFI/II
K4SHQ

-Original Message-
From: Greg Beam [mailto:ki7m...@gmail.com] 
Sent: Friday, March 03, 2017 5:44 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] Hamlib3 compile error

Hi Dan, All,

I'm not sure what's going on here either. My version of Perl, via MSYS, is
5.8.8. I was able to build Hamlib3 from MSYS directly, and JTSDK-QT via QT
5.2 and 5.5 without error.

As Bill suggested, log the build and post it. To eliminate JTSDK-QT ENV, use
the JTSDK-MSYS terminal, then:

 From JTSDK-MSYS Terminal, type the command:

build-hamlib3 |tee -a hamlib3-build.log

or

build-hamlib3 >> hamlib3-build.log

The first command allows you to watch the build progress. Then post that
file to the dev list.

As best I can tell, there are no versions of Perl associated with QT, so
that should not be a conflict of any sort. The update process within JTSDK
does not alter the MSYS installation. So, if the build worked at some point
in the past, something has changed in one of the environments on your
system. What, and where would be a question only you could answer.

73's
Greg, KI7MT

On 3/3/2017 10:58 AM, Dan Malcolm wrote:
> Bill,
>
> Reboot didn't help and the Windows Event Log messages just reported 
> what was already known.  I uninstalled JTSDK and then deleted the 
> folder.  I downloaded fresh files from SourceForge, and did a complete
reinstall.
> The problem is not fixed.  See the attached capture image.  WSJT-X 
> compilation also failed under JTSDK-QT.  There were so many error 
> lines that I could not scroll back far enough to see the first one.
> Experience has taught me to fix the first reported failure first.  Are 
> these problems related?
>
>
>
> _
>
> Dan Malcolm CFI/II
>
> K4SHQ
>
>
>
> *From:*Bill Somerville [mailto:g4...@classdesign.com]
> *Sent:* Thursday, March 02, 2017 10:21 AM
> *To:* wsjt-devel@lists.sourceforge.net
> *Subject:* Re: [wsjt-devel] Hamlib3 compile error
>
>
>
> On 02/03/2017 16:06, Dan Malcolm wrote:
>
> Seems the offending module is: Faulting module path:
> C:\JTSDK\msys\bin\msys-perl5_8.dll.
>
> The problem seems to be inability to find a file
>
> It appears I am using Perl5_8.  If memory serves, there was a
> discussion about which Perl version should be used.  Could 5.8 be
> the problem?
>
> HI Dan,
>
> the message is telling us that the version of perl being used is the 
> one in the JTSDK. That should be fine. The errors were memory access 
> and copy errors. It could possibly be a corrupted file in the JTSDK. 
> If rebooting does not sort this out and there is nothing in the 
> Windows Event Log then it may be worth trying to re-install the JTSDK.
>
> 73
> Bill
> G4WJS.


--
Check out the vibrant tech community on one of the world's most engaging
tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] IC-7300 control lost

[Pino Zollo]

End of show .

El 02/03/17 a las 19:11, wsjt-devel-requ...@lists.sourceforge.net escribió:
> #4 You still haven't sent us enough of the log to see what was going on
> what it stopped...



rig_register (372)
icom_init: civ_version=1
rig_set_conf: civaddr='0x94'
rig:rig_open called
serial_open: Unable to open /dev/ttyUSB0 - No such file or directory
rig_open: error = IO error


while doing some WSPR

the computer does not recognize any more the /dev/ttyUSB0


The computer USB seems good as it sees my pendrivers.


Shell I complain with ICOM ?


73

Pino ZP4KFX

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Cumulative patch

[Bill Somerville]

On 03/03/2017 19:17, Edson W. R. Pereira wrote:
> The way the signal level meter works is also very good as it measures 
> the signal at the wxjt-x input in relation to the ADC floor. This, in 
> my view, is the best indicator to correctly set the audio levels (at ~ 
> 30 dB).

Hi Edson,

that is not currently the case, the patch Mike and Joe are discussing 
will make that a step closer.

73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Cumulative patch

[Bill Somerville]

On 03/03/2017 19:07, Joe Taylor wrote:
> As general statement, setting the audio level is simply not very critical.

Hi Joe,

it certainly doesn't justify the >30dB noise level on the forums -- hi 
hi. Still I think every time it comes up, a few more users both 
understand a bit better and realize that they don't have as much control 
as they thought.

73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Cumulative patch

[Bill Somerville]

On 03/03/2017 19:17, Edson W. R. Pereira wrote:
> Also, some soundcards have no hardware fader control (the best ones).

Hi Edson,

I would be a little surprise if any soundcard had a hardware level 
control other that mic boost. Do you know otherwise?

73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Cumulative patch

[Edson W. R. Pereira]

Hi Bill,

The concern I have is if the control of the OS fader would be OS agnostic.
Also, some multi input/output soundcards have a collection of controls --
some independent some not. Also, some soundcards have no hardware fader
control (the best ones).

The way WXJT-X works today seems quite adequate. It empowers the user to
have full control on the sound levels. The way the signal level meter works
is also very good as it measures the signal at the wxjt-x input in relation
to the ADC floor. This, in my view, is the best indicator to correctly set
the audio levels (at ~ 30 dB).

73, Edson PY2SDR


On Fri, Mar 3, 2017 at 2:49 PM, Bill Somerville 
wrote:

> On 03/03/2017 15:38, Joe Taylor wrote:
> > 2. The slider should not affect the meter reading.
> >
> HI Joe & all,
>
> we have another enhancement possibility available to us. WSJT-X could
> set the operating system/driver fader to 0 dB as well. This may cause
> some consternation amongst users who have tweaked the levels because we
> have said the best place for the WSJT-X slider is in the middle. Those
> who have done this are probably doing more harm than if they had tweaked
> the WSJT-X slider to get to 30 dB on background noise.
>
> Another option is that we could also switch the WSJT-X level control to
> actually change the o/s / driver fader but note the value is in the
> range 0.0 to 1.0 and I assume that 1.0 is 0 dB FS so maybe only
> attenuation is available.
>
> Related to this, I have never been sure if the operating system level is
> more than just digital manipulation of the 16-bit PCM stream. For
> example it could have access to a 24-bit sample stream at a high sample
> rate on the input side (for example my laptop is capable of 192 kHz
> 24-bit audio input) and therefore has more resolution available than a
> gain control on a 16-bit sample stream would have.
>
> 73
> Bill
> G4WJS.
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Cumulative patch

[Joe Taylor]

Hi Bill,

Reasonable suggestion... though I suspect many users would have the 
consternation you mention, when we alter a control setting they thought 
they had control over.

As for your last question: I don't have a reference link handy, but Leif 
(SM5BSZ) has shown that most "24-bit" soundcards only provide about 18 
bits of real data.  The remaining 6 bits or so are random noise.

Of course we want to provide the best available advice to users; but I 
think people are spending far too much time worrying about what is in 
most cases a non-issue.  As general statement, setting the audio level 
is simply not very critical.

-- Joe

On 3/3/2017 12:49 PM, Bill Somerville wrote:
> On 03/03/2017 15:38, Joe Taylor wrote:
>> 2. The slider should not affect the meter reading.
>>
> HI Joe & all,
>
> we have another enhancement possibility available to us. WSJT-X could
> set the operating system/driver fader to 0 dB as well. This may cause
> some consternation amongst users who have tweaked the levels because we
> have said the best place for the WSJT-X slider is in the middle. Those
> who have done this are probably doing more harm than if they had tweaked
> the WSJT-X slider to get to 30 dB on background noise.
>
> Another option is that we could also switch the WSJT-X level control to
> actually change the o/s / driver fader but note the value is in the
> range 0.0 to 1.0 and I assume that 1.0 is 0 dB FS so maybe only
> attenuation is available.
>
> Related to this, I have never been sure if the operating system level is
> more than just digital manipulation of the 16-bit PCM stream. For
> example it could have access to a 24-bit sample stream at a high sample
> rate on the input side (for example my laptop is capable of 192 kHz
> 24-bit audio input) and therefore has more resolution available than a
> gain control on a 16-bit sample stream would have.
>
> 73
> Bill
> G4WJS.
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib3 compile error

[Bill Somerville]

On 03/03/2017 18:47, Dan Malcolm wrote:
I still have the question: Are these two failures (Hamlib3 and WSJTX) 
related?


Hi Dan,

I don't know. Your instinct to examine the first error message is 
correct, I explained how you can do that.


73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Cumulative patch

[Bill Somerville]

On 03/03/2017 18:30, char...@sucklingfamily.free-online.co.uk wrote:

Another option is that we could also switch the WSJT-X level control to
actually change the o/s / driver fader but note the value is in the
range 0.0 to 1.0 and I assume that 1.0 is 0 dB FS so maybe only
attenuation is available.


I think this a good idea, as it makes it easier for users to access the
"critical' control, and would avoid having the operating system control
too high and mistakenly trying to compensate  with the existing slider.


Hi Charlie,

the problem with that is that the o/s or driver fader is not the 
critical control and moving it away from 0 dB may well be non-optimal. 
The critical control is the one in the analogue domain that sets the 
level before the ADC, whether that be some level control on the rig, the 
RF gain control or an extra attenuator just before the sound card input.


73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] PreAmp SDR settings

[Bill Somerville]

On 03/03/2017 18:17, Clemens Heese wrote:
> Somehow I have a similar issue. Using an SDR (RedPitaya) with a variable
> gain amplifier as preamp (and a 30 MHz low pass). I am wondering how to
> best set the preamp. Currently I have just experimentally set the gain
> to get most decodes in 24h (weighted by my reference station)

Hi Clemens,

empirical testing is hard to beat.

Other than that I can't see any serious problem with the following approach:

use a two way aerial coax switch with your aerial and a dummy load. 
Adjust the preamp gain to the minimum level where switching to the dummy 
load reduces the background noise. Turn the gain up a notch to allow for 
noise QSB.

My thinking is that an amplifier is a source of noise which may be 
directly related to gain setting so using the minimum level that doesn't 
loose the band noise floor is probably best.

I'm sure the EME operators will have more scientific methods for setting 
pre-amp gain. No doubt some will ask which end of the feeder the pre-amp 
is located.

YMMV, 73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib3 compile error

[Dan Malcolm]

I know its my specific to my system.  Just not sure what it is.  There were
no install errors.  I still have the question: Are these two failures
(Hamlib3 and WSJTX) related?  I think not, but you know the architecture
better than I do. 



Dan Malcolm CFI/II

K4SHQ

 

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Friday, March 03, 2017 12:07 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Hamlib3 compile error

 

On 03/03/2017 17:58, Dan Malcolm wrote:

There were so many error lines that I could not scroll back far enough to
see the first one.  Experience has taught me to fix the first reported
failure first.  Are these problems related?

Hi Dan,

this is something specific to your system, no one else is reporting similar
issues.

To see the first error you need to redirect the build output to a file. Try:

build-command >build.log 2>&1

73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Cumulative patch

[charlie]

Hi Bill and all


> Another option is that we could also switch the WSJT-X level control to
> actually change the o/s / driver fader but note the value is in the
> range 0.0 to 1.0 and I assume that 1.0 is 0 dB FS so maybe only
> attenuation is available.
>

I think this a good idea, as it makes it easier for users to access the
"critical' control, and would avoid having the operating system control
too high and mistakenly trying to compensate  with the existing slider.


Charlie




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib3 compile error

[Bill Somerville]

On 03/03/2017 17:58, Dan Malcolm wrote:
There were so many error lines that I could not scroll back far enough 
to see the first one.  Experience has taught me to fix the first 
reported failure first.  Are these problems related?


Hi Dan,

this is something specific to your system, no one else is reporting 
similar issues.


To see the first error you need to redirect the build output to a file. Try:

build-command >build.log 2>&1

73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Cumulative patch

[Bill Somerville]

On 03/03/2017 15:38, Joe Taylor wrote:
> 2. The slider should not affect the meter reading.
>
HI Joe & all,

we have another enhancement possibility available to us. WSJT-X could 
set the operating system/driver fader to 0 dB as well. This may cause 
some consternation amongst users who have tweaked the levels because we 
have said the best place for the WSJT-X slider is in the middle. Those 
who have done this are probably doing more harm than if they had tweaked 
the WSJT-X slider to get to 30 dB on background noise.

Another option is that we could also switch the WSJT-X level control to 
actually change the o/s / driver fader but note the value is in the 
range 0.0 to 1.0 and I assume that 1.0 is 0 dB FS so maybe only 
attenuation is available.

Related to this, I have never been sure if the operating system level is 
more than just digital manipulation of the 16-bit PCM stream. For 
example it could have access to a 24-bit sample stream at a high sample 
rate on the input side (for example my laptop is capable of 192 kHz 
24-bit audio input) and therefore has more resolution available than a 
gain control on a 16-bit sample stream would have.

73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Cumulative patch

[Joe Taylor]

Hi Edson,



On 3/3/2017 11:09 AM, Edson W. R. Pereira wrote:
> Hello Joe and Mike,
>
> Since I was the one who implemented the level meter, I have a
> suggestion: Please don't make the level meter change colors depending of
> the dB level. It makes it rather difficult to read for those of us with
> not so good eyes. It is perhaps better to change the color of the text
> or background of the dB label, if the feature is really needed. I
> personally find that the way the level meter works now is very clear,
> elegant and not visually intrusive.
>
> 73, Edson PY2SDR

Thanks for weighing in on this topic.  I agree that we don't want to 
introduce any flashing color changes that become a distraction.

In normal operation the warnings I had in mind should appear very 
seldom, if at all.  They would simply draw attention to problems such as 
no audio input, or audio input that is far too high.

I don't have a strong opinion about how such warnings might best be 
displayed.  Maybe background color of the dB label is a good idea.

-- Joe

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Cumulative patch

[Black Michael]

Thanks for the explanation...helps a lot.
What about after the 2nd pass on JT65?  How does that affect the noise floor?
de Mike W9MDB
  From: Joe Taylor 
 To: WSJT software development  
 Sent: Friday, March 3, 2017 10:37 AM
 Subject: Re: [wsjt-devel] Cumulative patch
   
Hi all,

For the record, I want to clarify once again why it's a good idea to set 
the audio level so low that 16-bit digitized samples of pure background 
noise have an rms range around 30.

Seemingly very reasonably, Mike asked why would we not want to set the 
level higher, thereby using more bits and having a closer digital 
approximation of the underlying analog signal.

On 3/2/2017 3:40 PM, Black Michael wrote:
> We've got 90dB of space to work with.  Why would we NOT want the dynamic
> range?  ...more dynamic
> range means more accurate FFTs and such, doesn't it?

Suppose the background noise level has been set to give rms=30 for the 
digitized data.  The average "power" is then the square of this value, 
i.e. 900.

A small portion of this 900 units of power comes from quantizing noise 
in the A/D process.  How small a portion?  Ideally the largest 
quantizing errors fall in the range -0.5 to +0.5, i.e., half of a 
least-significant bit.  So the "power" in the quantizing noise is less 
than 0.5^2 = 0.25.

Maybe the A/D is kinda lousy, so the amplitude errors are twice as big 
and the "power" in quantizing noise thus four time as big, i.e. 1.0. 
This means that our 900 units of measured power are 899 units of 
background noise and 1 unit of quantizing noise.

OK: so how much S/N is lost as a result of the quantization errors?  The 
signal level S is unchanged. In this worst possible case, the noise is 
increased from 899 to 900 units.  The loss of S/N (in dB) is therefore 
10*log10(900/899) = 0.0048 dB.

If you can set the level for background noise significantly higher than 
30 dB and still not run out of headroom when strong signals or strong 
impulsive noise are present, there is no harm in doing that.  But you 
won't gain more than about 0.005 dB in your quest to decode weak signals.

    -- 73, Joe, K1JT

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


   --
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Cumulative patch

[Joe Taylor]

On 3/3/2017 10:51 AM, Black Michael wrote:
> OK...I'll do it that way.   So the idea is that the colors represent
> peak values then but the meter is noise.  That works.
>
> 15dB peak value though is something like 5dB RMS on my system.
>  Shouldn't that be a fair bit higher for a warning?  Peak will alway be
> well above noise.

Please read my item 6 again:

6. Warning colors may be displayed on the level meter if pxdb<15
(yellow?) or pxdbmax>85 (red?).

Red depends on peak.  Yellow on average.

-- Joe, K1JT

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Cumulative patch

[Bill Somerville]

On 02/03/2017 19:36, Joe Taylor wrote:

Update TIME_ON method to use transmit messages and adds widget on status
bar to allow TIME_ON setting

Input widget on status bar does NOT seem like a good idea.  Shouldn't
logging information be entered on on the Log QSO window?

Were you not in favor of minimizing the number and size of status bar
widgets?


Hi Joe & Mike,

as I suggested improvements to Mike's logged time on and off patch I 
would like to work with him on this part of the proposed changes.


73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel