|
Re: Noise Plots
Dean Shutt <al7cr@...>
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: --
|
|
|
|
Re: Noise Plots
Dean Shutt <al7cr@...>
That site looks great but all my plots give this error:
|
|
|
|
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
|
|
|
|
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:
--
|
|
|
|
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
Response from VK7JJ
toggle quoted messageShow quoted text
Hi Carol,
|
|
|
|
No New Spots on Wspr.rocks since 2230 UTC
|
|
|
|
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,
|
|
|
|
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
|
|
|
