The KiwiSDR 2 online store is open for orders! Please visit kiwisdr.nz

wsprdaemon - A Raspberry Pi WSPR decoding service

1235

Comments

  • Rob,
    I again get the mentioned errors in the log file as informed February 8th (see above)
    What should I do ? It keeps popping up in wsprdaemon.log...

    Ulli
  • I have just learned that the merged log files grow unbounded.
    That is fixed in v2.8 which should be available in a few days.
    Until then, reboot your Pi any time 'df /tmp/wsprdaemon' shows that file system is getting full
  • Many thanks for your great work, Rob. My problem is, that I often do not understand the meaning of any errors, which might occur, as I am a real beginner in Linux... however the Internet helps... but it takes looooooong time..hi

    Side-effect: I keep playing with kiwi-rx rather than using my transmitter... wsprdaemon/kiwi is so much fun...

    Thanks for that, Rob & John
  • Hi Rob.
    This morning when I restarted WD, the new version 2.8a installed from github...

    At the end of the progress report of the installation I get 2 lines of "warning" :

    The directory '/home/on5kq/.cache/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
    The directory '/home/on5kq/.cache/pip' or its parent directory is not owned by the current user and caching wheels has been disabled. check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.


    What do I exactly need to do ?
    I am sorry although searching on the Internet for this, I don't know...

    Many thanks for info!

    Ulli
  • wsprdaemon v2.8a upgraded via 'git pull' and running on two separate Pi4s, apparently without issue at the moment. Looks good.
  • if you're running WD.. let me know so I can include you on my ranking analysis. See ranking page and my e-mail contact at http://www.wa2zkd.net:8088
  • Hi Ulli,

    You seem to be spotting well, so it seems those warnings can be ignored.

    Rob
  • @WA2ZKD My kiwis are aready being listed on your pages.
    SWLIO52RP in Limerick, Ireland, MFA-30 cheapie amplified antenna as a 4m horizontal dipole literally on the lawn in the garden, gets ~15% of world's wspr transmissions, top 50 is positions.
    SWLJN47FJ in Zurich, Switzerland. AAA-1c amplified antenna, two pairs of 1m pipe loops, in the attic of an apartment building (loads of noise), get ~11% of wspr transmissions, top 100 positions.

    The Zurich one may have to go offline in a month, depending on the job market results.
    WA2ZKD
  • Seems fairly reliable this Kiwi and Wsprdaemon stuff.
    Probably should update but I was waiting for the 1000Hrs

  • very reliable!
  • The noise graphs generated by v2.7 are no longer displayed by wsprdaemon.org
    Also, in v2.7 there are some log files which for MERGed configurations can grow to overflow the file system.
    Go to http://wsprdaemon.org for more information and links to additional resources for viewing your data
    Powernumpty
  • Cheers Rob, I noticed my graphs stopped ages ago but wasn't bothered, will make a bit more effort with this version.
    The Kiwi AI updated nice and quickly this time too.
    I am only running one source so luckily didn't see any logs growing (I did see that in previous comments)

    Thanks for the software, off to play with Grafana now.
  • noise graphs can be very useful for spotting local RFI intrusions
  • On the Grafana set up I fail at the datasource "Metric request error" any obvious errors? I've tried a couple of times.
    Maximum version on the non commercial install (on Ubuntu) seems to 10 but I didn't think that would be a killer unless the queries were only in 11?

  • Hello Powernumpty

    My error I'm afraid - if you've downloaded the Guide from the wsprdaemon website.
    Drop the http:// from the Host url and try again.

    73
    Gwyn G3ZIL
  • Hi Gwyn, Doh I should have tried that! Many thanks.
    My shaky history with wsprdaemon setup meant I was determined to follow the guide exactly..

    Cheers
    Stu
  • Hi Stu, You are an early 'beta tester' with the Guide, please do let me know of any other quirks.
    Section 3 on the use of pull-down menu options gave me most difficulty, and I'm keen to know if what I've captured works for all - SQL is not my forte.

    73
    Gwyn G3ZIL
  • edited April 2020
    Don't want to admit, I struggled with it quite a bit.
    I have zero experience of Grafana and virtually the same for SQL

    I think it would be a perfect task for a small video or even a screen capture image of what you are setting before the explanation. Maybe even italics where you expect it to be a choice from a drop down

    E.G.

    FROM > Enter spots
    Time column > no change
    Metric column > tx_call

    But even now I see it is harder to describe than to do.

    73
    Stu
  • Later..

    For my eyes (and using F-Lux) the light theme made spotting fields for entry much more obvious.
    I've made more progress your instructions than I ever have previously and actually quite like Grafana now.

    One Question - Heatmaps where does one join the "rx_id" club?
    I can select a few calls but I'm not sure how it is generated - that term is not in the config so I'm guessing from here.

    Thanks
    Stu
  • Hi Stu
    Mm. Grafana seems slow, and that may explain why you have to ask the question ...
    There's no 'club' of rx_id, currently it has over 4000 of them from reporters to wsprnet.org over the last three weeks. It should present you with a list when you click on the box after the equals sign, but checking now it is very slow, so just an empty box. You can directly type the rx_id you are interested in into the box, but it has to be within single quotes so 'G3ZIL' and in upper case.
    73
    Gwyn G3ZIL
    PS Glad you find the Guide useful - I have thought of doing videos as you suggested but a couple of projects to complete!
  • Thanks for that Gwyn, it was partly in jest, so now one last attempt, manually typing over the values with the same (visual) value ...Bingo

    My error was that something about "time" was obviously wrong but showing no other errors, I eventually tried entering it manually as "time" and it told me the syntax was wrong but then took it and started showing the heatmap. Not sure if the browser had auto-filled some hidden space or something, might try from a private browser session next time to avoid that.

    Grafana -great software frustrating as hell to the unwary.
    The drop down on 'rx_id' stops at the 'B...' so not much point having a drop down there (no disrespect to A and B calls).
    The Mix of 'text' "text" and text fields is also an acquired skill obviously.
    Anyway as with most things Wsprdaemon, I make hard work of it but enjoy the results.

    Cheers
    Stu


  • Stu
    "The Mix of 'text' "text" and text fields is also an acquired skill obviously" ...
    I think the problem is that Grafana's Query Builder does not isolate you from the syntax needs of the database being queried - in this case postgreSQL. So from what I've gathered of postgreSQL syntax:
    1. Column names do not need any form of quote, except if the name of the column has even one capital letter in it. It's bad form to have capitals in postgreSQL column names, but we have SNR and tx_dBm, and so postgreSQL demands that we use double quotes around those column names, else it turns them into lower case and then can't find them.
    2. Column data entries that are text fields e.g. rx_id, tx_call etc need single quotes to denote as text. In the noise table, while one may think band is numeric, I had to make it text so as to have 60eu and 80eu as options.
    3. As for time - I'm still trying to figure that one out. In part because I think that if one makes a manual entry, then even if it is wrong, the pull-down remembers it.
    Yes, a nice tool, but I spent many hours to get this far ...
    73
    Gwyn G3ZIL
    Powernumpty
  • I saw on github there was an update, so I did a 'git pull' on my two rpi4s that pull wspr streams from my two kiwis, but it would appear that grafana graphs are not taking new measurements.

    I have confirmed that my spots are still being received at wsprnet.

    My update process, that I had successfully followed before, from the wsprdaemon directory:
    git pull ./wsprdaemon.sh -z ./wsprdaemon.sh -V ./wsprdaemon.sh -a ./wsprdaemon.sh -s
    and I could see the new version number reported on the Kiwi status page, as well as the expected set of PIDs of the wsprdaemon processes.

    However there's now a gap in the grafana graphs since doing that update.

    Has anyone seen similar?
  • I have not updated but did notice some change about 19:00 UTC yesterday.
    I was running a spot count, probably with some incorrect parameters but either way my noise graphs are still working but I had to revise that spot count (maybe something was renamed).

    This is a question - Should we not run
    ./wsprdaemon.sh -z
    before
    git pull
    otherwise we are trying to overwrite new files that are in use?
  • There have been some changes to Grafana related data but Rob will have to explain...
  • The new code is backwards compatible with earlier WD.conf and running installations.

    WD extended spots are stored in a new TS table 'wsprdaemon_spots' on wsprdaemon.org and include high resolution frequency and DT spot values and include all the fields reported by 'wsprd' in ALL_WSPR.TXT.

    The noise values now stored in 'wsprdaemon_noise' and now include a count of overload events reported by the Kiwi during the 2 minute long WSPR cycle.

    I will be posting to http://wsprdaemon.org/forum.html about features and fixed to V2.9
    cathalferris
  • V2.9 had a bug which blocked generating noise level graphs. That has been fixed in 2.9a and you can learn more at: http://wsprdaemon.org/forum.html
    cathalferris
  • Stu
    You are one of three wsprdaemon users that are still posting noise values to the wsprdaemon.org TimescaleDB table 'noise'. Release 2.9 posts to the new table 'wsprdaemon_noise' to which Rob now logs the ov overload count. We need to recover some disk space and avoid multiple instances, so I will stop new data input to table 'noise' on or after 1200UTC on 17 May, and on or after 1200UTC on 20 May I will delete the table. Upgrading to v2.9 will mean you writing to table 'wsprdaemon_noise'.
    I am sorry for these changes, but as you know, wsprdaemon has been under continual development.
    best wishes
    Gwyn G3ZIL
  • Gwyn, I've just updated, hope that is correct now.

    I've been testing other radio bits and sort of negelected/ignored the WSPR side (as anything I moved in the garden dropped the spot count).
    Hopefully I'm not the last to update.

    Thanks for the features

    Stu
  • Thanks, Stu, I can see you've stopped posting to 'noise' - no not the last - two to go!
    best wishes
    Gwyn
Sign In or Register to comment.