Re: LF: Monitoring 2190m WSPR

[DK7FC <selberdenken@posteo.de>]

Hello Domenico,

Very interesting and a good work, my compliments!
I often had the wish to have more options for the WSPR uploads. For example i'm running 2 instances on MF from the two loops on the tree (nw/se and ne/sw). Mostly there are two uploads from DK7FC/P for a single station from both loops. I would like to upload only the decode with the highest SNR. This should be possible with a script in Linux.

Also i saw that a noise blanker can improve the decode performance significantly on LF. Of course we expect this but many people seem to belive that it is already all inside the software. It isn't! And WSPR is probably not optimised for LF/MF.
However using a NB can cause multiple decodes from strong signals (!!!) Thus i usually don't use a NB since i'm in the center of EU activity here and have to deal with many strong signals.
For you it is probably not so dramatic since you are quite far away from most strong stations.
Did you try to optimise the vtblank parameters?
Maybe it is possible to measure the strength of the noise (in a 1 kHz BW, 1 min moving average for example) and dynamically change the vtblank parameters?
A great tool!
There are so many playing fields to operate on. You are working there. It is nice to see so many different places where things can be worked out here below 500 kHz...

Since i have a Linux PC and my MF vorbis stream from the tree, i could use your tools to realise the above functions. But i have no time unfortunately. To many open projects. But maybe in some time :-)

Tnx es 73, Stefan



Am 28.10.2017 02:21, schrieb Domenico IZ7SLZ:

Hi, LF

On 10/26/2017, Paul N1BUG wrote:

It seems WSPR-X is "conditionally stable". We had a fair bit of discussion about it on this side of the pond last winter. It works for some, but for others it doesn't. For me it stops doing anything after a few minutes and just idly sits there. I am not alone. There are others with the same issue and some for whom the program silently self terminates at seemingly random intervals. In my case it's on Windows 10 64 bit. I suppose there are too few of us interested in WSPR-15 to carry any weight with the developers. :-(

I want to share the results of an experimental whisper decoder running now at IZ7SLZ, maybe someone is interested: 

since some weeks i'm testing the linux version of WSJT-X. It does not manage the wspr-15 mode but its internal  decoding program 'wsprd' does. So i wrote a shell routine which,  by using some linux commands and programs from the vlfrx-tools package (thanks to Paul Nicholson) , is able to use  'wsprd'  without running WSJT-X program but only with the shell 'autowsprlf' (attached).

The result is a nice and stable decoder for wspr-15 and wspr-2 (at the same time) processing the audio coming from my LF receiver tuned on USB dial 136.000 kHz. In the attached screen-shot you can see of the program running. Furthermore, thanks to the excellent noise blanker P.N.'s program 'vtblank', it seems to be more sensitive compared with the wspr-x program running on the same audio. I have always reported 2-3 dB more in S/N ratio, and get more decodes.

In the shell file i'm using the program 'curl' to upload the received spot on the wsprnet.org site.

These are the spots so far received with this setup : http://qsl.net/iz7slz/OPDS/ALL_WSPR.TXT  (sorry if the list is upside-down ordered). Note that some LF spots are wspr-15 signals (i.e. 171027 2300   2 -35 -0.32   0.1376102  G8HUH IO81 20 ... thanks to G8HUH for transmitting this rare signal !)

I will be happy if some operator wants to test the program. It is a little bit messed, specially in the timeslot string generation, so any helps and comments for improving it are welcome.

All you need is a pc with linux (Ubuntu 14.04LTS works fine here) with 'autowsprlf' and following vlfrx-tools stuffs running in background:

- vtcard (to manage the audio card)

- vtresample (for 12000 samples/s audio required by wsprd)

- vtwrite (to record on the hard drive the raw audio)

other programs are running here, but i think they are not necessary for wspr mode:

- gpsd  for getting the precise time from my Jupiter GPS connected at  COM1 (1pps and binary protocol);

- ntpd (configured only for the gpsd daemon not for other ntp servers)

- vttime - for the audio calibration and time-stamping

Other routines are running on same Ubuntu PC for my auto-EbNaut decoder and for sending audio stream to another Windows's pc where is running SL and DF6NM's opds,..but this is another story.

I'm at disposal for any helps on the configuration of this setup.

73 all, Domenico / IZ7SLZ

 

On 26 October 2017 at 17:48, N1BUG <paul@n1bug.com> wrote:

Hello Chris,

It seems WSPR-X is "conditionally stable". We had a fair bit of discussion about it on this side of the pond last winter. It works for some, but for others it doesn't. For me it stops doing anything after a few minutes and just idly sits there. I am not alone. There are others with the same issue and some for whom the program silently self terminates at seemingly random intervals. In my case it's on Windows 10 64 bit. I suppose there are too few of us interested in WSPR-15 to carry any weight with the developers. :-(

I run into the shack every few minutes in my evenings to see if I've heard 2E0ILY yet! Eventually I go to sleep but the first thing I do in the morning is check to see if I've heard 2E0ILY overnight! (or anyone else across the pond)

The new tower is complete now. I feel the need to resurrect or replace the missing 80/40/30 meter antennas before I build the LF/MF transmitting antenna, but I am getting closer. I regret that my power will probably be too low to be heard on your side. The only good thing about it is I probably won't be setting many things alight. :-D

73,
Paul N1BUG WI2XTC


On 10/26/2017 06:42 AM, Chris Wilson wrote:

Hello Paul,

I am surprised you have had issues with WSPR-X and WSPR15 I often
forget I have it running in tandem with WSPR2 on WSJT-X and it is
still sound and solid after a few days. PC is Windows 7 pro 64 bit.
But it was also fine on Windows XP which I still run on another PC and
on a laptop. The developers were very none receptive to adding WSPR15
to WSJT-X :( I keep trying to get over to Maine most nights, but
conditions  or  Lady Luck have not obliged so far. There don't seem to
be  THAT  many  more  US stations on LF after the licence change, I was
expecting  far  more  to  be  honest.  Good  luck  Paul, don't let Mr.
Beveredge down :)


Thursday, October 26, 2017, 11:23:31 AM, you wrote:

I wish it were possible to have more WSPR-15 activity on LF. It
seems like a very promising mode and would be much more interesting
to me than Op32. Unfortunately for many of us the old WSPR-X
software needed to decode it is too unstable to run unattended.
Unless there are MANY requests to the developers that WSPR-15 be
included in the stable WSJT-X software, I am afraid we have seen the
death of this sub-mode. If I could have a stable WSPR-15 decoder I
would definitely monitor that mode alongside WSPR-2.

I'm struggling with my U3S assembly. All went well until I got to
the coils in the LF and MF low pass filters. Those are giving me
fits. The supplied wire came with many pre-installed sharp kinks,
plus I seem to have no skill whatsoever at this "scramble winding"
to get the required turns on the cores. I'm waiting now for a new
spool of wire to arrive before I try again. I've thought about
substituting a different core to allow a single layer winding. A
FT-37-61 would be lovely with 31 turns on LF. However I fear the Q
would be too low and losses high. Best to stick with what is proven,
if I can only learn to wind the devils!

I have the GPS with my U3S and also the OCXO (which I plan to
assemble later, after getting everything working with the standard
synthesizer).

73,
Paul N1BUG