Date   

Re: Dupes suddenly not zero anymore

Rob Robinett
 

Hi John,

Yours is a common question, so I'm including the WD group in my response.

There are some stations  in the UK which transmit in two 60M channels at the same time.  WD treats the 60Mand 60eu bands as separate and doesn't (I think appropriately) reject one of them as a duplicate, so both are uploaded to wsprnet.org.

However Phil has only one column for the 60M band, so he can only treat those two spots as duplicates.   I have forgotten how I was previously able to find and display those duplicates on wspr.rocks.  Perhaps Phil can remind us.

Since only UK and perhaps some EU stations are authorized to transmit WSPR on 60M, only rx stations in Europe and the US East Coast like you, KD2OM and WA2TP report those phantom dups.

73,

Rob



 

On Thu, Oct 28, 2021 at 6:48 AM John Huggins <john.huggins.ee@...> wrote:
Hi Rob,

While watching wspr.rocks, I, KX4O, seem to now be reporting some dupes...

Screen Shot 2021-10-28 at 9.38.56 AM.png

This has always been zero and I always figured my one instance of wsprdaemon was doing a good job of preventing dupes.

Then again, what do I know right?

This all began when I added the preamplifier so maybe I'm simply seeing better results.

Hmmm, now that I think of it, perhaps it's my recent changing of the config to include both 60 and 60eu.

I mention this because I sure don't want to upset the apple cart with induction into the "Rank of Shame" mentioned below.

Screen Shot 2021-10-28 at 9.45.28 AM.png

My guess is this is all fine, but who better to ask than you right?

73
John, kx4o



--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Re: Filtering data by AZIMUTH *and* DISTANCE - seeking your feedback

Gwyn Griffiths
 

Hi Curt
Your idea is not a million miles from a Grafana Dashboard I have available via the wsprdaemon.org site.

I've attached a screenshot with example 'graphs' below. One can choose how many days to show - time is along the x axis, here 4 days.
Range is along the Y axis and the color represents number of spots in 'bins' that are 20 minutes in time and 200 km in range. One can select two bands and a reception location by 4-character grid, in this case 40 m top and 20 m bottom and IO90 (UK)  and one sets the direction (heading) at the receiver, and the 'beamwidth', here 275˚ with a 30˚ beamwidth, which from IO90 covers North America. The resolution in this plot does not do justice to the data.

Information on the wsprdaemon.org Grafana Dashboards is at http://wsprdaemon.org/grafana.html
However ... because of quantity of data etc. these plots using the Timescale database can take minutes to render. I am in the process of converting to use Clickhouse, but not done this one yet. I can prioritise if of interest to you.

regards
Gwyn G3ZIL


Re: Filtering data by AZIMUTH *and* DISTANCE - seeking your feedback

Curt K7ZOO
 

Following some coaching from VK7JJ I'm attaching an answer to my question.  de K7ZOO


Interview request (from WSPR Facebook group

kk6pr
 

Hi all. I'm K1GF, but writing in my capacity as science reporter for Newsy. I'd like to do a story about WSPR, the absolute opposite of broadband.
I'm curious if any of you running QRP WSPR would agree to a short interview? Though we're US based you don't need to be here if you'd like to be included.
IF you'd rather contact me via email: geoff.fox@...
 
Like
 
 
 
Comment
 
 
Share
 
 


Filtering data by AZIMUTH *and* DISTANCE - seeking your feedback

Curt K7ZOO
 

.....seeking feedback on this idea from a broad audience!

In a month or so I'd like to give a talk to a group here in Arizona, a group of DX'rs who haven't used WSPR to study propagation.  They have keen interest in contacting specific countries, of course...  so I think it might be very interesting if they could filter data as such:

a) FROM    a specific grid (in my case DM42 in southwestern United States / Arizona)
 b) TO         between a range of azimuthal angles
 c) TO          between a range of distances

In this manner, one could easily see when a specific band was open to a (roughly) rectangular section across the globe.  Honestly, I think it could be really cool to specify a rectangle of interest.  As an example, around Japan: and know when 15 meters was open to that country.  See the plots below as an example.

Is there a SQL command anyone could recommend?  (I really like VK7JJ's tool; in it one can use SQL; I reached out to him as well.  I confess to knowing nothing about SQL, though).

If you are developing analysis tools for WSPR data, or if you are consuming the data, I'm really curious to hear what you think about this filter idea!

Have a good day,

Curt / K7ZOO
University of Arizona Radio Station Manager, K7UAZ

image.png

image.png



Re: How to see WD 2.10's log of overload events

Jim Lill
 

a further variation...

awk '{ printf "%s: %4d %s\t %s\n",  strftime("%c",$1), $2, FILENAME, $3}' ./*/ov.log | sort -k3,3 | less

On 10/24/21 12:37 PM, Jim Lill wrote:
I took your script and added filename, thus knowing band

awk '{ printf "%s: %4d %s\t %s\n",  strftime("%c",$1), $2, FILENAME, $3}' ./*/ov.log

I run that from the receiver path. So for K76, one of my receivers, from

/tmp/wsprdaemon/recording.d/K76

that gives me this output, for example

Sat Oct  9 10:44:54 2021:    0 ./80/ov.log
Fri Oct 15 23:39:17 2021:    1 ./80/ov.log     PRINTED
Fri Oct 15 23:45:30 2021:    2 ./80/ov.log     PRINTED
Sat Oct 16 01:01:29 2021:    4 ./80/ov.log     PRINTED
Sat Oct 16 01:04:24 2021:    5 ./80/ov.log
Sat Oct 16 01:09:42 2021:    6 ./80/ov.log     PRINTED
Sat Oct 16 01:13:54 2021:    7 ./80/ov.log     PRINTED
Sat Oct 16 10:30:02 2021:    8 ./80/ov.log     PRINTED
Sat Oct 16 10:30:19 2021:    9 ./80/ov.log
Sat Oct 16 10:31:36 2021:   11 ./80/ov.log     PRINTED
Fri Oct 22 01:59:23 2021:   12 ./80/ov.log     PRINTED
Sat Oct  9 10:44:55 2021:    0 ./80eu/ov.log
Fri Oct 15 23:41:02 2021:    1 ./80eu/ov.log     PRINTED
Fri Oct 15 23:43:49 2021:    2 ./80eu/ov.log
Fri Oct 15 23:46:49 2021:    3 ./80eu/ov.log     PRINTED
Sat Oct 16 00:19:58 2021:    4 ./80eu/ov.log     PRINTED
Sat Oct 16 00:34:48 2021:    5 ./80eu/ov.log     PRINTED
Fri Oct 22 01:19:51 2021:    6 ./80eu/ov.log     PRINTED
Fri Oct 22 01:59:22 2021:    8 ./80eu/ov.log     PRINTED
Fri Oct 22 02:00:57 2021:    9 ./80eu/ov.log     PRINTED


On 10/24/21 10:35 AM, Rob Robinett wrote:
awk '{ printf "%s: %4d %s\n", strftime("%c",$1), $2, $3}'



Re: How to see WD 2.10's log of overload events

Jim Lill
 

I took your script and added filename, thus knowing band

awk '{ printf "%s: %4d %s\t %s\n",  strftime("%c",$1), $2, FILENAME, $3}' ./*/ov.log

I run that from the receiver path. So for K76, one of my receivers, from

/tmp/wsprdaemon/recording.d/K76

that gives me this output, for example

Sat Oct  9 10:44:54 2021:    0 ./80/ov.log
Fri Oct 15 23:39:17 2021:    1 ./80/ov.log     PRINTED
Fri Oct 15 23:45:30 2021:    2 ./80/ov.log     PRINTED
Sat Oct 16 01:01:29 2021:    4 ./80/ov.log     PRINTED
Sat Oct 16 01:04:24 2021:    5 ./80/ov.log
Sat Oct 16 01:09:42 2021:    6 ./80/ov.log     PRINTED
Sat Oct 16 01:13:54 2021:    7 ./80/ov.log     PRINTED
Sat Oct 16 10:30:02 2021:    8 ./80/ov.log     PRINTED
Sat Oct 16 10:30:19 2021:    9 ./80/ov.log
Sat Oct 16 10:31:36 2021:   11 ./80/ov.log     PRINTED
Fri Oct 22 01:59:23 2021:   12 ./80/ov.log     PRINTED
Sat Oct  9 10:44:55 2021:    0 ./80eu/ov.log
Fri Oct 15 23:41:02 2021:    1 ./80eu/ov.log     PRINTED
Fri Oct 15 23:43:49 2021:    2 ./80eu/ov.log
Fri Oct 15 23:46:49 2021:    3 ./80eu/ov.log     PRINTED
Sat Oct 16 00:19:58 2021:    4 ./80eu/ov.log     PRINTED
Sat Oct 16 00:34:48 2021:    5 ./80eu/ov.log     PRINTED
Fri Oct 22 01:19:51 2021:    6 ./80eu/ov.log     PRINTED
Fri Oct 22 01:59:22 2021:    8 ./80eu/ov.log     PRINTED
Fri Oct 22 02:00:57 2021:    9 ./80eu/ov.log     PRINTED

On 10/24/21 10:35 AM, Rob Robinett wrote:
awk '{ printf "%s: %4d %s\n",  strftime("%c",$1), $2, $3}'


Re: How to see WD 2.10's log of overload events

Rob Robinett
 

On Tue, Oct 19, 2021 at 02:33 PM, Rob Robinett wrote:
awk '{ printf "%s: %4d %s\n",  strftime("%c",$1), $2, $3}' 
On my Pi 4b running bash, I needed to run that script using 'gawk'.  Download and install it :  "sudo apt-get install gawk'


Re: Chasing ov

Jim Lill
 

your MW OV is likely less severe than mine but perhaps not. In any event, I built discrete notches for the offending  mW stations and that solved things.  You might also consider as a diagnostic tool, putting in a 2 MHz LPF so you can work on MW OV without HF OV clouding the picture. Once you have the MW under control you can then see if you have HF OV too.

-Jim

On 10/22/21 3:28 PM, Rolf Ekstrand wrote:
Rob

Here the 1660  station is about 10 km @ 10 Kw daytime 1 Kw night time  and the  1560 is about 5 km @ 5 Kw daytime and 1 Kw nighttime.   I have another one with 4 phased towers about 2 1/2 km at 990.  Not sure about the power yet, but the Flamingo knocks them down well below the two others.  I am still running the Kiwi without any pre amp as I think it is better to solve the overloads first. 

Yup them EU stations have a much tougher situation on 40 m. I still remember the racket   when I lived in SM land prior to 1978 (I got my licence there in 1964).  If I recall it right it was Radio Peking all over the place.  Those were also the years of the Russian Woodpecker that was even worse QRM. 

Rolf


Re: Chasing ov

Rolf Ekstrand
 

Rob

Here the 1660  station is about 10 km @ 10 Kw daytime 1 Kw night time  and the  1560 is about 5 km @ 5 Kw daytime and 1 Kw nighttime.   I have another one with 4 phased towers about 2 1/2 km at 990.  Not sure about the power yet, but the Flamingo knocks them down well below the two others.  I am still running the Kiwi without any pre amp as I think it is better to solve the overloads first. 

Yup them EU stations have a much tougher situation on 40 m. I still remember the racket   when I lived in SM land prior to 1978 (I got my licence there in 1964).  If I recall it right it was Radio Peking all over the place.  Those were also the years of the Russian Woodpecker that was even worse QRM. 

Rolf


Re: Chasing ov

Rob Robinett
 

In Maui the Flamingo was not enough to suppress overloads from the 10 Km distant 5 KW 550 AM station.   A friend designed a custom replacement which suppresses 550AM by more than 60 dB while passing the 630M / 474 KHz band at about -6 dB..
But solving AM overload is easy compared to the problems of European sites who have many SW broadcast signals in the just above our 40M WSPR band.

On Fri, Oct 22, 2021 at 9:46 AM Rolf Ekstrand <rekstrand@...> wrote:
Greetings, y'all

I am now chasing ov events here.  Have installed the Flamingo - am bandpass filter, but seemingly still have some ov events around daybreak. The culprit are likely to be traced to two stations at 1560 and 1660.  In particular I suspect the last one as it switch from nighttime to daytime  transmitting power.  The station at 1660 is definitely the strongest  here both nighttime ( even behind the filter) and daytime and in looking at the Flamingo filter the attenuation is not that hot at that high end of the band. I guess I need to "cobble" together a  notch filter for 1660 and try that.   I also have a QRO DX hound 500 ft down the road that is many times taking advantage of the grey line propagation which is when these ov events so far can be traced to.  

I guess I have to keep trying to find out what cause these events. 

73  K9DZT   Rolf



--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Chasing ov

Rolf Ekstrand
 

Greetings, y'all

I am now chasing ov events here.  Have installed the Flamingo - am bandpass filter, but seemingly still have some ov events around daybreak. The culprit are likely to be traced to two stations at 1560 and 1660.  In particular I suspect the last one as it switch from nighttime to daytime  transmitting power.  The station at 1660 is definitely the strongest  here both nighttime ( even behind the filter) and daytime and in looking at the Flamingo filter the attenuation is not that hot at that high end of the band. I guess I need to "cobble" together a  notch filter for 1660 and try that.   I also have a QRO DX hound 500 ft down the road that is many times taking advantage of the grey line propagation which is when these ov events so far can be traced to.  

I guess I have to keep trying to find out what cause these events. 

73  K9DZT   Rolf


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.


Re: wsprdaemon.log, error message meaning

Bruce KX4AZ
 

On Mon, Oct 18, 2021 at 05:02 PM, Rob Robinett wrote:
No, those are not benign and your log file will grow unbounded.
Can you email your conf file and I'll log into it.

 
 
Emailed it to the address shown at qrz
 


Re: wsprdaemon.log, error message meaning

Rob Robinett
 

No, those are not benign and your log file will grow unbounded.
Can you email your conf file and I'll log into it.

On Mon, Oct 18, 2021 at 1:57 PM Bruce KX4AZ <bruce@...> wrote:
As far as I can determine wsprdaemon is running fine since I got it started a day or two ago.  I have noticed that the log file is full of repeated error messages of this type:

Mon Oct 18 12:30:01 UTC 2021: watchdog_daemon() starting as pid 1112
sed: -e expression #1, char 16: unknown option to `s'
sed: -e expression #1, char 14: unknown option to `s'
sed: -e expression #1, char 16: unknown option to `s'
sed: -e expression #1, char 14: unknown option to `s'
sed: -e expression #1, char 16: unknown option to `s'...

The file size is about 159 kB right now after about 9 hours uptime, just wanted to make sure these are "benign" errors that won't eventually cause a problem.
 



--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


wsprdaemon.log, error message meaning

Bruce KX4AZ
 

As far as I can determine wsprdaemon is running fine since I got it started a day or two ago.  I have noticed that the log file is full of repeated error messages of this type:

Mon Oct 18 12:30:01 UTC 2021: watchdog_daemon() starting as pid 1112
sed: -e expression #1, char 16: unknown option to `s'
sed: -e expression #1, char 14: unknown option to `s'
sed: -e expression #1, char 16: unknown option to `s'
sed: -e expression #1, char 14: unknown option to `s'
sed: -e expression #1, char 16: unknown option to `s'...

The file size is about 159 kB right now after about 9 hours uptime, just wanted to make sure these are "benign" errors that won't eventually cause a problem.
 


Re: New install on Pi4 question

Rob Robinett
 

In WD 3.0 I will add checks of the receiver names to the config file validation function.
Thanks for the reports

On Fri, Oct 15, 2021 at 6:49 AM Bruce KX4AZ <bruce@...> wrote:
On Fri, Oct 15, 2021 at 08:46 AM, KD2OM wrote:
I think the problem may be the names. There is no need to use a call as the receiver name.
You are correct!  Right after my last post I went back to the original example conf file example (from the web site) and changed the receiver name to remove the '/T' suffix from the call sign, while leaving it present for the uploaded spots - important for me to distinguish different locations I use.  After a restart the spots  began uploading correctly.  I also did some more editing of the example conf file to change all of the "no" values to "yes" for the noise related reporting.  Hopefully that is working correctly too - I have a lot ore learning to do to figure out how to verify that.



--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Re: Radio "limbo"

Jim Lill
 

I have 2 public systems, jimlill.com:8075 has a Nooelec filter,   jimlill.com:8073 has HB notch filters on the nearby very strong MWBC stations.  You can compare...

On 10/18/21 8:54 AM, Bruce KX4AZ wrote:
On Sun, Oct 17, 2021 at 04:03 PM, Rob Robinett wrote:
...The $16 Nooelec Flamingo AMBF (https://www.nooelec.com/store/flamingo-am.html) is enough for several of my receive sites, but you could very well need even more filtering than the 20-35 dB it provides. 
Every 10 minutes WD logs overload events to files /tmp/wsprdaemon/..../ov.log where you can learn about OVs which happen when you aren't looking at the Kiwi's S-meter.

 
Rob,
Thanks for reminding me about the Nooelec filter.  I do have the RTL-SDR filter for MW, but is a high pass filter which rolls off at 2.6 MHz, so it chops off 160m and everything below.  As expected, the (roughly) 25dB amplification (with no filtering for MW!) that I left in place yesterday created an ugly overflow mess after sunset.  I wish I hadn't rebooted the Pi before I saw your note about the overflow file in the tmp WD directory.  My dilemma with MW filtering is that this antenna has re-kindled an old interest of mine in DXing there during the daytime.  The RTL-SDR MW filter is much stronger in that band than the Nooelec. Which makes me think that the Nooelec might have just enough attenuation to prevent overloading, whilst preserving some of the MW DXing.  Until I have that filter in hand I am going to dial down the amplification by reducing the supply voltage and/or attenuation before/after the LNA.  I have the Airspy HF+ Discovery running (unamplified in parallel) off the same antenna, so comparing the WSPR spot counts between the two seems like the best way to dial in the minimum LNA strength on the KiwiSDR needed to achieve WSPR equivalency...and then see what happens at night.  I normally only visit the site during the daytime, but a night visit to make LNA adjustments would certainly be more useful.  Worst case, I can always leave the Airpsy HF in place & running unfiltered, to preserve my MW fun going forward.
Bruce


Re: Radio "limbo"

Bruce KX4AZ
 

On Sun, Oct 17, 2021 at 04:03 PM, Rob Robinett wrote:
...The $16 Nooelec Flamingo AMBF (https://www.nooelec.com/store/flamingo-am.html) is enough for several of my receive sites, but you could very well need even more filtering than the 20-35 dB it provides. 
Every 10 minutes WD logs overload events to files /tmp/wsprdaemon/..../ov.log where you can learn about OVs which happen when you aren't looking at the Kiwi's S-meter.

 
Rob,
Thanks for reminding me about the Nooelec filter.  I do have the RTL-SDR filter for MW, but is a high pass filter which rolls off at 2.6 MHz, so it chops off 160m and everything below.  As expected, the (roughly) 25dB amplification (with no filtering for MW!) that I left in place yesterday created an ugly overflow mess after sunset.  I wish I hadn't rebooted the Pi before I saw your note about the overflow file in the tmp WD directory.  My dilemma with MW filtering is that this antenna has re-kindled an old interest of mine in DXing there during the daytime.  The RTL-SDR MW filter is much stronger in that band than the Nooelec. Which makes me think that the Nooelec might have just enough attenuation to prevent overloading, whilst preserving some of the MW DXing.  Until I have that filter in hand I am going to dial down the amplification by reducing the supply voltage and/or attenuation before/after the LNA.  I have the Airspy HF+ Discovery running (unamplified in parallel) off the same antenna, so comparing the WSPR spot counts between the two seems like the best way to dial in the minimum LNA strength on the KiwiSDR needed to achieve WSPR equivalency...and then see what happens at night.  I normally only visit the site during the daytime, but a night visit to make LNA adjustments would certainly be more useful.  Worst case, I can always leave the Airpsy HF in place & running unfiltered, to preserve my MW fun going forward.
Bruce


Re: Radio "limbo"

Rob Robinett
 

With any kind of decent antenna and a reasonably quiet site, the Kiwi needs 10+ dB gain to get signals above 10 MHz to be stronger than the internal noise of the Kiwi RF amplifier.
Of course that 10 dB gain makes Kiwi ADC overloads from local AM broadcast stations even more common, so you need an AM blocking filter ahead of the LNA.
The $16 Nooelec Flamingo AMBF (https://www.nooelec.com/store/flamingo-am.html) is enough for several of my receive sites, but you could very well need even more filtering than the 20-35 dB it provides. 
Every 10 minutes WD logs overload events to files /tmp/wsprdaemon/..../ov.log where you can learn about OVs which happen when you aren't looking at the Kiwi's S-meter.

On Sun, Oct 17, 2021 at 12:02 PM Bruce KX4AZ <bruce@...> wrote:
On Sun, Oct 17, 2021 at 11:16 AM, Rolf Ekstrand wrote:
 
...see you got your Kiwi WD up and running and doing well.  What antenna(s) are you using on the RX site?     

73  Rolf
Rolf,
Currently I have one antenna for the KX4AZ/T WD site - a random wire dipole that is resonant at about 3.4 MHz, roughly 15 feet above ground level.  I am still tweaking the matching/feedline setup, using Cat 7 ethernet cable as a balanced feedline.  Earlier today I added an LNA to the KiwiSDR input which boosted the WSPR performance significantly, but I am positive that will lead to overloading later today - will need to adjust the gain.  But I am certainly having a lot of fun learning & experimenting with this new setup.
Bruce



--
Rob Robinett
AI6VN
mobile: +1 650 218 8896

781 - 800 of 1300