Date   

Re: Noise Plots

Dean Shutt
 

If you are still around my new install throws this error:

./wsprdaemon.sh: line 235: /tmp/./kiwiclient.log: Permission denied

Any ideas?

Thanks


Re: Noise Plots

Dean Shutt
 

Thanks, I am reinstalling now.


Re: Noise Plots

Rob Robinett
 

Your conf file looks OK to me and any user with autosudo permissions should run with it.
But it would be good to create a user 'wsprdaemon' and give it sudo permissions.
I'll try your conf on my Pi in the morning and report back

On Tue, Sep 7, 2021 at 9:03 PM Dean Shutt <al7cr@...> wrote:
I believe so.  Here is my conf file:

##############################################################
### The RECEIVER_LIST() array defines the physical (KIWI_xxx,AUDIO_xxx,SDR_xxx) and logical (MERGED_RX...) receive devices available on this server
### Each element of RECEIVER_LIST is a string with 5 space-seperated fields:
###   " ID(no spaces)             IP:PORT or RTL:n    MyCall       MyGrid  KiwPassword (NULL => none required)"
### In this simple example we will only connect to a single KiwiSDR. No changes are needed on your KiwiSDR to use wsprdaemon.
### Replace the ID G3ZIL_1 below with an identification for your receiver. Replace 10.0.1.89 with the IP address of your KiwiSDR on your network.  
### If you have changed your KiwiSDR from the default 8073 then you will need to make the change in your RECEIVER_LIST below.
### Replace G3ZIL with your callsign and IO90hw with your six character grid locator.
### If your KiwiSDR is on the same subnet as the computer running wsprdaemon you may not need a password, as here, so use NULL.
### If you are on different subnets then replace NULL with your KiwiSDR's password.
ls
 sudo g
declare RECEIVER_LIST=(
        "AL7CR_1                  192.168.0.119:8073     AL7CR      CN82ie    NULL"
)

### wsprdaemon.conf can run complex band scheduling, but in this simple example we use the simplest line with no schedule
### 00:00 is the start time for the schedule, leave as is
### There follows a list of your RECEIVER_ID then a comma then the band designator in metres. Note that options 60eu and 80eu are also available.
### Note that there is no comma between the band and the next RECEIVER_ID, just a space. The order does not matter.
### You can have up to 8 bands on a KiwiSDR with BeagleBone Green and up to 14 on a BeagleBone AI.

declare WSPR_SCHEDULE=(
    "00:00 AL7CR_1,80 AL7CR_1,40 AL7CR_1,30 AL7CR_1,20 AL7CR_1,17 AL7CR_1,15 AL7CR_1,12 AL7CR_1,10"
)

### These are options that you can change
CURL_MEPT_MODE=yes                 ### This is the recommended setting
SIGNAL_LEVEL_STATS=yes              ### Change to yes if you want noise level measurements stored in a signals.log file in each rx directory
                                   ###  and to enable a web page of noise graphs for the last 24 hours
SIGNAL_LEVEL_UPLOAD_GRAPHS="yes"    ### If changed to yes, wsprdaemon will upload your noise graphs to http://wsprdaemon.org/graphs/CallSign
###                                    Change Callsign in the next line to yours
SIGNAL_LEVEL_UPLOAD_ID="AL7CR"
SIGNAL_LEVEL_UPLOAD="yes"           ### change to yes to upload signal level data as part of extended wsprdaemon data, database fields rms_level and c2_level
SIGNAL_LEVEL_LOCAL_GRAPHS="yes"    ### change to no if you do not want LOCAl noise plots, on the computer running wsprdaemon at localhost/noise_graph.png
###
### Now run wsprdaemon in its directory using:
### ./wsprdaemon.sh -a
### and after a few moments check its status with
### ./wsprdaemon.sh -s
### and when you need to stop it
### ./wsprdaemon.sh -z
###

When I stop wsprdaemon and then restart using the -z and -a options a noise plot is made.  However no further data is added until I repeat the process.  I did not install as a seperate user, perhaps I have a permission problem.



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


Re: Noise Plots

Dean Shutt
 

I believe so.  Here is my conf file:

##############################################################
### The RECEIVER_LIST() array defines the physical (KIWI_xxx,AUDIO_xxx,SDR_xxx) and logical (MERGED_RX...) receive devices available on this server
### Each element of RECEIVER_LIST is a string with 5 space-seperated fields:
###   " ID(no spaces)             IP:PORT or RTL:n    MyCall       MyGrid  KiwPassword (NULL => none required)"
### In this simple example we will only connect to a single KiwiSDR. No changes are needed on your KiwiSDR to use wsprdaemon.
### Replace the ID G3ZIL_1 below with an identification for your receiver. Replace 10.0.1.89 with the IP address of your KiwiSDR on your network.  
### If you have changed your KiwiSDR from the default 8073 then you will need to make the change in your RECEIVER_LIST below.
### Replace G3ZIL with your callsign and IO90hw with your six character grid locator.
### If your KiwiSDR is on the same subnet as the computer running wsprdaemon you may not need a password, as here, so use NULL.
### If you are on different subnets then replace NULL with your KiwiSDR's password.
ls
 sudo g
declare RECEIVER_LIST=(
        "AL7CR_1                  192.168.0.119:8073     AL7CR      CN82ie    NULL"
)

### wsprdaemon.conf can run complex band scheduling, but in this simple example we use the simplest line with no schedule
### 00:00 is the start time for the schedule, leave as is
### There follows a list of your RECEIVER_ID then a comma then the band designator in metres. Note that options 60eu and 80eu are also available.
### Note that there is no comma between the band and the next RECEIVER_ID, just a space. The order does not matter.
### You can have up to 8 bands on a KiwiSDR with BeagleBone Green and up to 14 on a BeagleBone AI.

declare WSPR_SCHEDULE=(
    "00:00 AL7CR_1,80 AL7CR_1,40 AL7CR_1,30 AL7CR_1,20 AL7CR_1,17 AL7CR_1,15 AL7CR_1,12 AL7CR_1,10"
)

### These are options that you can change
CURL_MEPT_MODE=yes                 ### This is the recommended setting
SIGNAL_LEVEL_STATS=yes              ### Change to yes if you want noise level measurements stored in a signals.log file in each rx directory
                                   ###  and to enable a web page of noise graphs for the last 24 hours
SIGNAL_LEVEL_UPLOAD_GRAPHS="yes"    ### If changed to yes, wsprdaemon will upload your noise graphs to http://wsprdaemon.org/graphs/CallSign
###                                    Change Callsign in the next line to yours
SIGNAL_LEVEL_UPLOAD_ID="AL7CR"
SIGNAL_LEVEL_UPLOAD="yes"           ### change to yes to upload signal level data as part of extended wsprdaemon data, database fields rms_level and c2_level
SIGNAL_LEVEL_LOCAL_GRAPHS="yes"    ### change to no if you do not want LOCAl noise plots, on the computer running wsprdaemon at localhost/noise_graph.png
###
### Now run wsprdaemon in its directory using:
### ./wsprdaemon.sh -a
### and after a few moments check its status with
### ./wsprdaemon.sh -s
### and when you need to stop it
### ./wsprdaemon.sh -z
###

When I stop wsprdaemon and then restart using the -z and -a options a noise plot is made.  However no further data is added until I repeat the process.  I did not install as a seperate user, perhaps I have a permission problem.


Re: Noise Plots

Rob Robinett
 

Are you configured to upload spots and noise to wsprdaemon.org?

On Tue, Sep 7, 2021 at 8:48 PM Dean Shutt <al7cr@...> wrote:
That site looks great but all my plots give this error:

Code: 386, e.displayText() = DB::Exception: There is no supertype for types String, UInt8 because some of them are String/FixedString and some of them are not: while executing 'FUNCTION equals(band : 17, 10 : 19) -> equals(band, 10) LowCardinality(UInt8) : 20' (version 21.8.4.51 (official build))

Object
status:500
 
statusText:""
 
data:Object
message:"Code: 386, e.displayText() = DB::Exception: There is no supertype for types String, UInt8 because some of them are String/FixedString and some of them are not: while executing 'FUNCTION equals(band : 17, 10 : 19) -> equals(band, 10) LowCardinality(UInt8) : 20' (version 21.8.4.51 (official build)) "
 
error:""
 
response:"Code: 386, e.displayText() = DB::Exception: There is no supertype for types String, UInt8 because some of them are String/FixedString and some of them are not: while executing 'FUNCTION equals(band : 17, 10 : 19) -> equals(band, 10) LowCardinality(UInt8) : 20' (version 21.8.4.51 (official build)) "
 
message:"Code: 386, e.displayText() = DB::Exception: There is no supertype for types String, UInt8 because some of them are String/FixedString and some of them are not: while executing 'FUNCTION equals(band : 17, 10 : 19) -> equals(band, 10) LowCardinality(UInt8) : 20' (version 21.8.4.51 (official build)) "
 
 



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


Re: Noise Plots

Dean Shutt
 

That site looks great but all my plots give this error:

Code: 386, e.displayText() = DB::Exception: There is no supertype for types String, UInt8 because some of them are String/FixedString and some of them are not: while executing 'FUNCTION equals(band : 17, 10 : 19) -> equals(band, 10) LowCardinality(UInt8) : 20' (version 21.8.4.51 (official build))

Object
 


Re: Noise Plots

Rob Robinett
 

Hi Dean,

Use https://wspr.live/gui/d/ereVvgn7z/station-noise-stats?orgId=1&refresh=1m to get far more flexible displays of your noise levels and much more.

Rob 


Noise Plots

Dean Shutt
 

I have an eight channel installation running with great success.  My local noise plot shows only a very few points however even though I have run the installation for several hours.  Is there a way to trigger production of a plot?  On what schedule are they produced?  Thanks for the help.


Re: Nightly report of comparison kfs - kph on 80m to copy JA's in contest

ON5KQ
 

Hi Glenn,

Exactly.

When you have a very quit location and a really well working omni-directional antenna the only way to get better wspr-reception reports is:

- directional antennas......   AND (very important!)

- many of them in different directions 

with only one directional antenna you will have less spots than with the simple omni-directional antenna....

Only in that case it makes sense to me, to use more that one receiver on one frequency. Although it is clear that more receivers increase the number of spots due to statistical reasons...

As I do not have this directional antenna set-up at the moment I use only one receiver per band at the moment (with exceptions during antenna tests)


May be, I will NOT join coming Wednesday - we are planning a full day cycling tour and I might not be back in time for the meeting....

So please inform the group...

Ulli


Ulli,
An interesting comparison, thanks for sharing it.  Because of it, I took a look at Grafana to compare KPH/TCI-530 with KFS/best_of_all_merged_antennas  on 80m during that same time, it looks like this:


What I find interesting is that KPH and KFS are almost exactly the same on WSPR during this time of day - and actually overall. They are closer than the perhaps 6 dB of SNR improvement your JA CW captures show.  This seems to me to add support your hypothesis that the extra directivity, the F/B of KFS antenna is helping, but of course only in that direction. On average, considering all WSPR signal directions they have similar performance.
I think this rather confirms what we knew - directive antennas can be useful when used appropriately but they aren't a solution in every situation.  No doubt if there were noise sources over the pacific (maybe a really noisy SMPS at Rob's AI6VN/KH6 site (:>)  )  things might be different.



Re: x86 PC

Rob Robinett
 

Hi Yuri,

I am adding this to the WD forum so others see the issue.
I will be testing WD 3.0 installation on Ubuntu 20.04 and will address all such problems
thanks for the report.

Rob

On Wed, Sep 1, 2021 at 7:33 AM Юрий Максимов <rz3dvp@...> wrote:
Hi Rob, 
I don't know why but on x86 with clean Ubuntu 20.04.03 LTS system your script doesn't install libfftw3-3 package and I added it manually with "sudo apt install libfftw3-3", because I had errors in log:
"wsprd: error while loading shared libraries: libfftw3f.so.3: cannot open shared object file: No such file or directory"
Maybe add his install to the script?

Best regards,
Yuri


On Fri, Aug 13, 2021 at 7:32 AM Юрий Максимов <rz3dvp@...> wrote:
Hello Rob,
I added these strings to my wsprdaemon.sh after upgrading it to 2.10k on RPi4 with 64-bit Ubuntu, when I received information about unsupported architecture after starting it.
Some time ago, support for arm64 OS was added to https://physics.princeton.edu/pulsar/K1JT/wsjtx.html and they started uploading a file for this architecture.
After these modifications, a new version of wsjtx was downloaded, installed and 2.10k works fine.

Best regards,
Yuri



On Fri, Aug 13, 2021 at 2:13 AM Rob Robinett <rob@...> wrote:
Is that a change you made and tested on WD 2.10?
If so, I’ll add it to 3.0

On Thu, Aug 12, 2021 at 2:47 PM Юрий Максимов <rz3dvp@...> wrote:
Hello Rob,
Please add support arm64 to your wsprdaemon.sh:

 case ${cpu_arch} in
            x86_64)
                wsjtx_pkg=wsjtx_${WSJTX_REQUIRED_VERSION}_amd64.deb
                ;;
            armv7l)
                # https://physics.princeton.edu/pulsar/K1JT/wsjtx_2.2.1_armhf.deb
                wsjtx_pkg=wsjtx_${WSJTX_REQUIRED_VERSION}_armhf.deb
                ;;
            aarch64)
                wsjtx_pkg=wsjtx_${WSJTX_REQUIRED_VERSION}_arm64.deb
                ;;
            *)

                echo "ERROR: CPU architecture '${cpu_arch}' is not supported by this program"
                exit 1
                ;;
        esac


73! Yuri


On Wed, Aug 4, 2021 at 4:45 PM Rob Robinett <rob@...> wrote:
Hi Yuri,

The accuracy of WSPR decoding is limited by the transmitted modulation technique and by the decoding algorithm.  So if the rx CPU can finish decoding in 2 minutes then it an ARM will report the same spots as an x86.
However in WSJT-x V2.3 a new transmit modulation technique FST4W was introduced which offers about 2 dB better SNRs.  In wsprdaemon version 3.0 I will add support for FST4W  and running both decodes will require at least double the CPU time.
So your investment in the x86 server will soon be put to use

73,

Rob

On Wed, Aug 4, 2021 at 1:30 AM Юрий Максимов <rz3dvp@...> wrote:
Hello Rob, 
I am trying to use x86 PC with Ubuntu 20.04 for your daemon and it works great, good job!
But I want to ask you some questions, x86 PCs are much more powerful than Raspberry Pi, do you have any configuration commands for more complex or accurate wspr decoding?

Best regards, 73!
Yuri


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


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


Re: Nightly report of comparison kfs - kph on 80m to copy JA's in contest

Glenn Elmore
 

Ulli,
An interesting comparison, thanks for sharing it.  Because of it, I took a look at Grafana to compare KPH/TCI-530 with KFS/best_of_all_merged_antennas  on 80m during that same time, it looks like this:


What I find interesting is that KPH and KFS are almost exactly the same on WSPR during this time of day - and actually overall. They are closer than the perhaps 6 dB of SNR improvement your JA CW captures show.  This seems to me to add support your hypothesis that the extra directivity, the F/B of KFS antenna is helping, but of course only in that direction. On average, considering all WSPR signal directions they have similar performance.
I think this rather confirms what we knew - directive antennas can be useful when used appropriately but they aren't a solution in every situation.  No doubt if there were noise sources over the pacific (maybe a really noisy SMPS at Rob's AI6VN/KH6 site (:>)  )  things might be different.


Re: No New Spots on Wspr.rocks since 2230 UTC

Carol KP4MD
 

Response from VK7JJ

Hi Carol,
 
Thanks for the heads up and yes, I do know. I'll put a sign up on it.
 
The WSPRnet.org owner Bruce W1BW changed the domain name of the part of the site that delivers the data and Arne, the owner of the ClickHouse db that wspr.rocks uses is on a different time zone and hasn't yet discovered that he needs to make changes to fix it.
 
wsprd.vk7jj.com is working but with a loss of 3 hours data which should be made up sometime over the next day, it gets data from Rob's database at wsprdaemon.org and he's already made the changes.
 
wspr.vk7jj.com  is not affected, I modded it to suit the new changes and it gets it's data live from wsprnet.org.
 
I'll go and add an alert to wspr.rocks now.
 
73  Phil.


No New Spots on Wspr.rocks since 2230 UTC

Carol KP4MD
 

I do not see new WSPR spots on wspr.rocks since 2230 UTC this afternoon (8/27/2021).
Carol KP4MD


Nightly report of comparison kfs - kph on 80m to copy JA's in contest

ON5KQ
 

Great, that kph is receiving again with the kiwi's...
I thought I use the Japanese CW contest to make a screenshot of kfs (NWest antenna) and compare it with the TCI 530 at kph
I know that this is not a fair comparison - for your information - both TCI-530s at kfs and kph were very similar with almost no difference in reception.

However if you already have a real good receiver, how much you need to invest more, to improve the reception further ? This gives some impression...

As usual, the 80m band is very noisy at 3h20 local California time....
So to hear the JA-stations in 80m CW you need some attenuation of the QRN (from the land side) and good gain over the pacific...
The directional LPDAs at kfs offer both....

Here is the difference - I attach two high resolution screenshots, so you can really compare the details.
All stations calling above 3510kHz are JA's in the contest calling. You can see, that just a tiny bit better reception makes the difference in this band propagation...
Most stations were difficult to copy at kph, due to the noise...
The noise situation was not much better at kfs, however the net gain into the northern Pacific make the difference - the visible stations were very easy to copy... some stations could be copied which were not at all readable at kph...

Conclusion: It is very worthwhile to have large directional antennas to the pacific from west-coast US-stations. Especially as the distances are very long, low elevation take-off antennas should be used...

Ulli, ON5KQ
P.S.: screenshots are taken exactly at the same time...


Re: WD 3.0 development status and plans

Rolf Ekstrand
 

Rob,  

Thanks for the info and the work you are doing.  

Rolf


WD 3.0 development status and plans

Rob Robinett
 

Hi Rolf,

I resumed daily work on WD 3.0 about 2 weeks ago and have just about finished the very extensive software restructuring work.  Wspr.rocks queries show my WD_3.0a alpha code running reliably at AI6VN (a Pi in my office listening on a KFS Kiwi), KFS, and AI6VN/KH6.

So far the only new user-level functionality is support for reverse-proxy access to the user's WD server.  In contrast to the Kiwi, this remote access feature is OFF by default, but it can be enabled by adding a variable declaration on your conf file.  When enabled, this reverse proxy feature will give me ssh access to your WD server without requiring port forwarding, while utilizing several levels of security that minimizes the possibility of hacker access to your server.

My next development priority is to add support for decodes of FST4W packets which I hope will take me no more than a couple of weeks to finish development and debug.  When FST4W is working I will start beta testing at all of the sites which have offered me remote access.  When it is reasonably well tested, that will become the first general release of 3.0 and I plan to make that the default github download.

Next in the feature list is SoapyAPI support for other SDRs, but beta testing for that will probably follow the first 3.0 release by a month or more.  Like FST4W, much of the SoapyAPI code exists in the current WD sources but hasn't been integrated and debugged.

I am pleased to see that 38 WD users have upgraded to v2.10k which gives me some visibility into the WD user base.  And seeing so many responsive WD users encourages me to continue to invest my time in the project.

Stay tuned to this forum where I will keep WD users informed of development events.

Rob

On Sat, Aug 21, 2021 at 11:06 AM Rolf Ekstrand <rekstrand@...> wrote:
Hi Rob,

I know Murphy was an optimist and that even the best plans do not last through the battle. How well do I know from years in the trenches. 
Just curious here how you are doing as I am working on my "upgrade" plans.  

Rolf  K9DZT


Any News about WD 3.0?

Rolf Ekstrand
 

Hi Rob,

I know Murphy was an optimist and that even the best plans do not last through the battle. How well do I know from years in the trenches. 
Just curious here how you are doing as I am working on my "upgrade" plans.  

Rolf  K9DZT


Re: KiwiSDR forum back (read-only)

Jim Lill
 

I just posted...  it works

On 8/14/21 11:14 PM, Glenn Elmore wrote:
It appears that the forum may be fully returned, though I haven't tried to post yet...


Re: KiwiSDR forum back (read-only)

Glenn Elmore
 

It appears that the forum may be fully returned, though I haven't tried to post yet...


Re: logs1 wsprdaemon_spots table - service interruption 11-12 August 2021 - new table name

Gwyn Griffiths
 

All work on logs1 is now complete, with new table names wsprdaemon_spots_s and wsprdaemon_noise_s with an autosequence index.

This has allowed Arne to import these data into Clickhouse. Grafana plots are available, e.g.
https://wspr.live/gui/d/ereVvgn7z/station-noise-stats?orgId=1&refresh=1m

Note that there is now  300-day retention on the TimescaleDB tables on this server, for older data use logs2 or Arne's Clickhouse database.

I am now working on replicating the autosequencing addition on logs2 wsprdaemon_spots and _noise tables. There will be some disruption on 13 August.

thank you
Gwyn

261 - 280 of 679