How to see WD 2.10's log of overload events


Rob Robinett
 

I have recently become aware of how little many Kiwi users appreciate the importance of filtering the RF feed to a Kiwi so as to minimize RF overload events.

Each Kiwi receive job run by WD logs those events to a size-limited per-receive-channel file 'ov.log'.
You can see the list of those ov.log files sorted by time by executing this Linux command line:               ls -ltr $(find /tmp/wsprdaemon/ -name ov.log)
Each line of an ov.log  file consists of 2 or three fields:   

1) the time in epoch of the log entry   (epoch is seconds since Jan 1 1970)
2) the total number of ov events reported by the Kiwi since the WD listening session was started
and optionally:
3) the work PRINTED if the line was printed to the recording.log file in the same directory

Unless you have started WD at an elevated debug verbosity, those PRINTED ov.log lines won't be found in the  more human readable 'recording.log' file,.  And you don't want to run WD at an elevated verbosity level or the resulting log files will soon overflow your /tmp/wsprdaemon/... file system.  (That limitation is fixed in WD 3.0)

Running "ls -ltr $(find /tmp/wsprdaemon/ -name ov.log)"  will give a list of ov.log files like this:

oe9ghv@radiohill-wspr:~$ ls -ltr $(find /tmp/wsprdaemon/ -name ov.log)
......
-rw-r--r-- 1 oe9ghv oe9ghv 1939 Oct 19 14:26 /tmp/wsprdaemon/recording.d/KIWI_2/60/ov.log
-rw-r--r-- 1 oe9ghv oe9ghv   12 Oct 19 16:45 /tmp/wsprdaemon/recording.d/KIWI_1/2200/ov.log
-rw-r--r-- 1 oe9ghv oe9ghv   12 Oct 19 16:45 /tmp/wsprdaemon/recording.d/KIWI_1/630/ov.log
-rw-r--r-- 1 oe9ghv oe9ghv   12 Oct 19 16:45 /tmp/wsprdaemon/recording.d/KIWI_5/630/ov.log
-rw-r--r-- 1 oe9ghv oe9ghv   12 Oct 19 16:45 /tmp/wsprdaemon/recording.d/KIWI_3/12/ov.log
-rw-r--r-- 1 oe9ghv oe9ghv   25 Oct 19 16:45 /tmp/wsprdaemon/recording.d/KIWI_5/2200/ov.log
-rw-r--r-- 1 oe9ghv oe9ghv   25 Oct 19 16:45 /tmp/wsprdaemon/recording.d/KIWI_3/10/ov.log
-rw-r--r-- 1 oe9ghv oe9ghv 1883 Oct 19 19:47 /tmp/wsprdaemon/recording.d/KIWI_2/80/ov.log
-rw-r--r-- 1 oe9ghv oe9ghv 2042 Oct 19 19:47 /tmp/wsprdaemon/recording.d/KIWI_2/160/ov.log
-rw-r--r-- 1 oe9ghv oe9ghv 1970 Oct 19 19:47 /tmp/wsprdaemon/recording.d/KIWI_2/40/ov.log
oe9ghv@radiohill-wspr:

Looking at the lines at the ov.log file at the bottom of the list (the most recently written to) shows the raw file format described above:

oe9ghv@radiohill-wspr:/tmp/wsprdaemon/recording.d/KIWI_2/40$ tail -n 20 /tmp/wsprdaemon/recording.d/KIWI_2/40/ov.log ; echo
1634328773 846
1634328779 872
1634328784 892
1634328789 900 PRINTED
1634361165 909 PRINTED
1634361170 926
1634361180 930
1634361200 946
1634361205 955
1634361220 959
1634361225 960 PRINTED
1634371594 961 PRINTED
1634402669 962 PRINTED
1634402791 964 PRINTED
1634420806 966 PRINTED
1634488364 967 PRINTED
1634589724 972 PRINTED
1634605846 973 PRINTED
1634653571 974 PRINTED
1634672856 975 PRINTED
oe9ghv@radiohill-wspr:/tmp/wsprdaemon/recording.d/KIWI_2/40$

Since those epoch times are meaningless to most humans, you can run this awk command to get a more friendly output:  "awk '{ printf "%s: %4d %s\n",  strftime("%c",$1), $2, $3}'  OV_FILENAME.LOG | tail
Where you substitute for "OV_FILENAME.LOG" the name of the ov.log file you want to see.  e.g.:

oe9ghv@radiohill-wspr:~$ awk '{ printf "%s: %4d %s\n",  strftime("%c",$1), $2, $3}'  /tmp/wsprdaemon/recording.d/KIWI_2/40/ov.log | tail -n 20
Fri 15 Oct 2021 08:12:53 PM UTC:  846
Fri 15 Oct 2021 08:12:59 PM UTC:  872
Fri 15 Oct 2021 08:13:04 PM UTC:  892
Fri 15 Oct 2021 08:13:09 PM UTC:  900 PRINTED
Sat 16 Oct 2021 05:12:45 AM UTC:  909 PRINTED
Sat 16 Oct 2021 05:12:50 AM UTC:  926
Sat 16 Oct 2021 05:13:00 AM UTC:  930
Sat 16 Oct 2021 05:13:20 AM UTC:  946
Sat 16 Oct 2021 05:13:25 AM UTC:  955
Sat 16 Oct 2021 05:13:40 AM UTC:  959
Sat 16 Oct 2021 05:13:45 AM UTC:  960 PRINTED
Sat 16 Oct 2021 08:06:34 AM UTC:  961 PRINTED
Sat 16 Oct 2021 04:44:29 PM UTC:  962 PRINTED
Sat 16 Oct 2021 04:46:31 PM UTC:  964 PRINTED
Sat 16 Oct 2021 09:46:46 PM UTC:  966 PRINTED
Sun 17 Oct 2021 04:32:44 PM UTC:  967 PRINTED
Mon 18 Oct 2021 08:42:04 PM UTC:  972 PRINTED
Tue 19 Oct 2021 01:10:46 AM UTC:  973 PRINTED
Tue 19 Oct 2021 02:26:11 PM UTC:  974 PRINTED
Tue 19 Oct 2021 07:47:36 PM UTC:  975 PRINTED
oe9ghv@radiohill-wspr:~$

As you can see, the Kiwi at Holger OE9GHV does suffer from a few overloads , mostly in the early morning and evening grayline times.  
I wouldn't try to eliminate all overload events, just add enough filtering to ensure there are only a few per hour.

Of course the next challenge is to identify what bands and stations are the source of the overload events and add appropriate filters in the RF chain. 
To do that you will probably need to log on to your Kiwi during periods of many overloads and look at the 0-30 MHz spectrum.

Join wsprdaemon@groups.io to automatically receive all group messages.