rrobinet

V2.9 had a bug which blocked generating noise level graphs. That has been fixed in 2.9a and you can learn more at: http://wsprdaemon.org/forum.html

The new code is backwards compatible with earlier WD.conf and running installations.

WD extended spots are stored in a new TS table 'wsprdaemon_spots' on wsprdaemon.org and include high resolution frequency and DT spot values and include all the fields reported by 'wsprd' in ALL_WSPR.TXT.

The noise values now stored in 'wsprdaemon_noise' and now include a count of overload events reported by the Kiwi during the 2 minute long WSPR cycle.

I will be posting to http://wsprdaemon.org/forum.html about features and fixed to V2.9

For over a year, at KPH I have fed 7 Kiwis from one GPS antenna on the roof: GPS Puck ====> 30M RG-6u =====> $15 passive splitter =====> 7 Kiwis
The 8-way I used is no longer offered, but I have installed this 6 way at other sites: https://smile.amazon.com/gp/product/B01KCY5MBU/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
No mods are required on the Kiwis
I started with the Kiwi's GPS puck on the roof into this system and that worked fine, but replaced the puck with a 45 dB gain 'bullit' GPS antenna which I bought as a precaution against the losses
The 100' RG8 measured 8 dB loss at 1500 MHz and the splitter introduces 11 dB, but the rooftop location more than compensates for those losses

The noise graphs generated by v2.7 are no longer displayed by wsprdaemon.org
Also, in v2.7 there are some log files which for MERGed configurations can grow to overflow the file system.
Go to http://wsprdaemon.org for more information and links to additional resources for viewing your data

There is a bug in v2.7a in which WD fails to install the Linux 'sox' utility problem. Legacy sites will have sox already installed, so they are not affected by this bug.
'git pull' will download v2.7b which fixes this problem

wsprdaemon -z
kill $(ps aux | awk '/wsprdaemon/{print $2}')
rm -rf /tmp/wspr-captures/*
wsprdaemon -a

Thanks for the feedback. I will clarify the use of 'wd' and alias and add further cleanup to the installation instructions.

As for the plotting problems, here is more information than may interest you on the cause.

v2.7 adds c2_fft data to each line of the signal-levels.log file which is used to create the noise graphs.

In 2.6 the 13th column was the source of fft data which was created by running the sox fft command

In 2.7 there are 14 column in each line and by default sox fft is not run, so that column is set to -999.9. The the newly implemented c2_fft value is always calculated and put in to the newly populated column 14 (the last one of each line).

In v2.7 the python plotting program /tmp/wsprdaemon/noise_plot.py has been modified to use the values in column 14. I think I regenerate that program when the plotting is done each odd 2 minutes, but if a 2.6 noise_plot.py is run it will plot column 13 which is now -999.9 and thus off the bottom of the graph.

In addition, legacy lines in /home/pi/wsprdaemon/signal_levels/*/*/signal-levels.log files might not contain 14 columns and crash the new noise_plot.py

So the safest way to upgrade probably involves:
1) flushing your old signal-level.logs files with: 'rm -rf /home/pi/wsprdaemon/signal_levels/*'
then
2) rebooting your server which will recreate /tmp/wsprdaemon/....

Of course it will then be several WSPR cycles before there are enough measurements for the noise graphs to show visible points.

WD -V (capital V) will print the version number of yoru WDS
"sudo systemctl status wsprdaemon" will show info about status
"sudo systemctl enable wsprdaemon" will ensure that WD is started at server boot time.
I will add a command flag to v2.7x check/enable/disable startup

I owe to Jim the suggestion to implement this important MERG feature in WD.

Here is a fuller explanation and example of the use of MERGed receivers:
1) MERG_K0_K1 merges the spots decoded from KIWI_0 with those decoded from KIWI_1
2) MERG_K0_A0 merges the decodes from KIWI_0 with decodes from the analog audio output of a 10M receiver
3) MERG_K0_A1 merges the decodes from KIWI_0 with decodes from the analog audio output of a 20M receiver

This is *NOT* diversity reception where the RF or audio signals are mixed. The decodes are performed separately on the signals from each of the MERGed receivers, from which WD picks the best set of decodes to be posted to wsprnet.org.

As a configuration example, here is a section of the conf for my Pi4 with two local Kiwis and two USB audio dongles attached:

declare RECEIVER_LIST=(
        "KIWI_0                  192.168.1.20:8073     AI6VN         CM88mc    NULL"           ### Kiwi fed by 160M - 10M antenna
        "KIWI_1                  192.168.1.21:8073     AI6VN         CM88mc    NULL"           ### Kiwi fed by 2200M - 160M antenna
        "AUDIO_0                     localhost:1,0     AI6VN         CM88mc  foobar"               ### Audio from a receiver tuned to 10M.  The id AUDIO_xxx is special and defines a local audio input device as the source o 
        "AUDIO_1                     localhost:2,0     AI6VN         CM88mc  foobar"               ### Audio from a receiver tuned to 20M
        "MERG_K0_K1                  KIWI_0,KIWI_1     AI6VN         CM88mc  foobar"          ### The antennas useful ranges overlap on 160M
        "MERG_K0_A0                 KIWI_0,AUDIO_0     AI6VN         CM88mc  foobar"        ### A 'virtual' receiver useful only for 10M WSPR band
        "MERG_K0_A1                 KIWI_0,AUDIO_1     AI6VN         CM88mc  foobar"        ### A 'virtual' receiver useful only for 20M WSPR band
)

declare WSPR_SCHEDULE=(
   "00:00  MERG_K0_A0,10   KIWI_0,15   KIWI_0,17   MERG_K0_A1, 20   KIWI_0,30   KIWI_0,40   KIWI_0,80   MERG_K0_K1,160   KIWI_1,630   KIWI_1,2200"
 

When so configured, on 20M WD merges the signals received by AUDIO_1 with those from KIWI_0 and posts only one copy (the strongest) of each received signal.
Similarly on 10M WD merges the signals received by AUDIO_0 with those from KIWI_0 , and on 160M WD merges signals from KIWI_0 with those from KIWI_1.

Not only will MERGed rxs avoid double posting spots to wsprnet.org, but as importantly when WD is run at verbosity level 1 (start as ./wsprdaemon.sh -va'), WD generates decode reports each two minutes which show all the spots in a MERG rx and which spot was chosen to be posted to wsprnet.org. Here is an example from another WD site of what you can learn in those posting.log files:

odroid@wspr:/tmp/wspr-captures$ ls -lrt /tmp/wspr-captures/*/*/posting.log
-rw-r--r-- 1 odroid odroid      0 Jan  9 21:10 /tmp/wspr-captures/MERGED_RX_0/2200/posting.log
-rw-r--r-- 1 odroid odroid  32232 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/17/posting.log
-rw-r--r-- 1 odroid odroid  87501 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/20/posting.log
-rw-r--r-- 1 odroid odroid  22376 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/12/posting.log
-rw-r--r-- 1 odroid odroid  23300 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/60/posting.log
-rw-r--r-- 1 odroid odroid  26226 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/10/posting.log
-rw-r--r-- 1 odroid odroid  28614 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/15/posting.log
-rw-r--r-- 1 odroid odroid  27073 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/80eu/posting.log
-rw-r--r-- 1 odroid odroid  47324 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/160/posting.log
-rw-r--r-- 1 odroid odroid  88536 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/30/posting.log
-rw-r--r-- 1 odroid odroid  24427 Jan 10 04:41 /tmp/wspr-captures/K74/2200/posting.log
-rw-r--r-- 1 odroid odroid  53565 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/630/posting.log
-rw-r--r-- 1 odroid odroid  65804 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/80/posting.log
-rw-r--r-- 1 odroid odroid  24378 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/60eu/posting.log
-rw-r--r-- 1 odroid odroid 172637 Jan 10 04:42 /tmp/wspr-captures/MERGED_RX_0/40/posting.log
odroid@wspr:/tmp/wspr-captures$ tail -n 20 /tmp/wspr-captures/MERGED_RX_0/40/posting.log
Fri Jan 10 04:39:59 UTC 2020:   7.039999    W4ENN        -16    -27     -16p
Fri Jan 10 04:39:59 UTC 2020:   7.040049    N6KOG        -28            -28p
Fri Jan 10 04:39:59 UTC 2020:   7.040050    ZS3RF        -13    -13p    -14
Fri Jan 10 04:39:59 UTC 2020:   7.040069   WA8KNE          1     -0       1p
Fri Jan 10 04:39:59 UTC 2020:   7.040073   KJ4IHN        -23            -23p
Fri Jan 10 04:39:59 UTC 2020:   7.040106    K4APC         -5    -14      -5p
Fri Jan 10 04:39:59 UTC 2020:   7.040156    N9QDS        -20    -21     -20p
Fri Jan 10 04:39:59 UTC 2020:   7.040160         -12    -17     -12p
Fri Jan 10 04:42:10 UTC 2020:  FREQUENCY     CALL POSTED_SNR     K74     K76       TOTAL=19, POSTED=11
Fri Jan 10 04:42:10 UTC 2020:   7.039999   KD9JYV        -19    -22     -19p
Fri Jan 10 04:42:10 UTC 2020:   7.040000          -28            -28p
Fri Jan 10 04:42:10 UTC 2020:   7.040014    AF4MP        -26            -26p
Fri Jan 10 04:42:10 UTC 2020:   7.040028    W4DJW         -9     -9p    -10
Fri Jan 10 04:42:10 UTC 2020:   7.040039     KK1D        -22    -22p    -22p
Fri Jan 10 04:42:10 UTC 2020:   7.040058    W5MWI        -23    -24     -23p
Fri Jan 10 04:42:10 UTC 2020:   7.040068   VE3OWV        -23    -26     -23p
Fri Jan 10 04:42:10 UTC 2020:   7.040126   VE6DAI        -22    -24     -22p
Fri Jan 10 04:42:10 UTC 2020:   7.040141   KK4YEL        -24    -26     -24p
Fri Jan 10 04:42:10 UTC 2020:   7.040158    W1CEW        -21            -21p
Fri Jan 10 04:42:10 UTC 2020:   7.040162    W9RAN         -1     -3      -1p
odroid@wspr:/tmp/wspr-captures$

You can see from that table that on 40M at 04:42 UTC rx "K76" is generally 1-3 dB more sensitive than "K74"

This is really a feature request, not a problem
CW and SSB users of KPH reported very few audio problems were introduced even when set to the minimum 0.25 seconds, and at those settings the Kiwis are far more friendly when used in two way conversations.
So I think it would be great if users could select the audio buffer size and if there were an admin page setting for the default size.