Date   

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 <al7cr@...>
 

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


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

Gwyn Griffiths
 

I will be carrying out maintenance and a change to the wsprdaemon_spots table on logs1.wsprdaemon.org today.
The table may stop updating while the work is underway and you are advised to use logs2.wsprdaemon.org.

I will post a note after the work is complete, and as for the noise table, there will be a new table wsprdaemon_spots_s with an autosequence number.

thank you
Gwyn G3ZIL


Re: logs1 wsprdaemon_noise table - service interruption 10 August 2021 - new table name

Gwyn Griffiths
 

The work on the noise table on logs1 is now complete.

The work was to add an automatically generated incrementing sequence number to each noise line uploaded.
The noise table on logs1 that is now being updated is wsprdaemon_noise_s  the 's' added to indicate 'with sequence number'.
If you access the noise table on this server please be aware of this change. The noise table is still there with data up to 1104 UTC 10 August 2021.

Any issues, please let me know. I will be repeating this with wsprdaemon_spots on logs1 and will post a message at the time.

thank you
Gwyn G3ZIL


logs1 wsprdaemon_noise table - service interruption 10 August 2021

Gwyn Griffiths
 

Please be aware that I am testing out some changes to the wsprdaemon_noise table on logs1.wsprdaemon.org today.

The wsprdaemon_noise table will stop updating at times and there will be gaps in the data. 

If this affects you, please access wsprdaemon_noise on the server logs2.wsprdaemon.org that should be unaffected.

thank you
Gwyn G3ZIL


Re: WD 2.10k has been checked in. Please upgrade to it

Rolf Ekstrand
 

Thank you Rob

Completed here too, no issues

Rolf  K9DZT


KiwiSDR forum back (read-only)

Glenn Elmore
 

I just noticed that JKS has made the forum available again, though read only for now.

http://forum.kiwisdr.com/index.php?p=/categories/kiwisdr-discussion


Re: WD 2.10k has been checked in. Please upgrade to it

WA2TP - Tom
 

Thank you Rob
Completed on my end, no issues.

Tom

461 - 480 of 873