rrobinet

I have configured several Kiwis for wifi access by attaching an inexpensive router configured as a Wifi client to the ethernet port of the Kiwi. This $25 TP Link has worked well for me: https://smile.amazon.com/TP-Link-Wireless-Portable-Travel-Router/dp/B00TQEX8BO/ref=sr_1_14?keywords=tplink+wifi+router&qid=1548188019&sr=8-14 In principle one could enable the internal BB Wifi or attach a USB wifi adapter, but I am reluctant to fiddle with the Kiwi's OS.

About

Username
rrobinet
Joined
Visits
1,246
Last Active
Roles
Member
Points
7

Reactions

42Helpful42Awesome

  • FST4W

    rrobinetrrobinet

    It will support both modes and all the packet lengths

    njc

  • FST4W

    rrobinetrrobinet

    Hi Steve,

    I am adding support for all the FST4W-nnn modes to wsprdaemon V3.0.

    The auto-wspr feature built in to the Kiwi is a port from an earlier version of WDSJT-x and required a significant amount of code rewriting. Also, that current autowspr feature is severely constrained by the limited CPU power of the BeagleBone.

    It was at John's suggestion that I started the wsprdaemon project which moves all of the WSPR signal processing to a remote server which can run the latest releases of WSJT-x and have as much CPU power as is required to execute the new WSPR modes.

    Rob

    rz3dvpjkssesykes71

  • Alternatives to reverse proxy

    rrobinetrrobinet

    Thanks Yuri,


    I was not aware of frp.

    I'll make it a configurable option in a future version of wsprdaemon.


    Rob

    rz3dvp

  • wsprdaemon - A Raspberry Pi WSPR decoding service

    rrobinetrrobinet
    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

  • wsprdaemon - A Raspberry Pi WSPR decoding service

    rrobinetrrobinet
    I owe to Jim the suggestion to implement this important MERG feature in WD.

    Here is a fuller explanation and example of the use of MERGed receivers:
    1) MERG_K0_K1 merges the spots decoded from KIWI_0 with those decoded from KIWI_1
    2) MERG_K0_A0 merges the decodes from KIWI_0 with decodes from the analog audio output of a 10M receiver
    3) MERG_K0_A1 merges the decodes from KIWI_0 with decodes from the analog audio output of a 20M receiver

    This is *NOT* diversity reception where the RF or audio signals are mixed. The decodes are performed separately on the signals from each of the MERGed receivers, from which WD picks the best set of decodes to be posted to wsprnet.org.

    As a configuration example, here is a section of the conf for my Pi4 with two local Kiwis and two USB audio dongles attached: 
    declare RECEIVER_LIST=(
        "KIWI_0                  192.168.1.20:8073     AI6VN         CM88mc    NULL"           ### Kiwi fed by 160M - 10M antenna
        "KIWI_1                  192.168.1.21:8073     AI6VN         CM88mc    NULL"           ### Kiwi fed by 2200M - 160M antenna
        "AUDIO_0                     localhost:1,0     AI6VN         CM88mc  foobar"               ### Audio from a receiver tuned to 10M.  The id AUDIO_xxx is special and defines a local audio input device as the source o 
        "AUDIO_1                     localhost:2,0     AI6VN         CM88mc  foobar"               ### Audio from a receiver tuned to 20M
        "MERG_K0_K1                  KIWI_0,KIWI_1     AI6VN         CM88mc  foobar"          ### The antennas useful ranges overlap on 160M
        "MERG_K0_A0                 KIWI_0,AUDIO_0     AI6VN         CM88mc  foobar"        ### A 'virtual' receiver useful only for 10M WSPR band
        "MERG_K0_A1                 KIWI_0,AUDIO_1     AI6VN         CM88mc  foobar"        ### A 'virtual' receiver useful only for 20M WSPR band
)

declare WSPR_SCHEDULE=(
   "00:00  MERG_K0_A0,10   KIWI_0,15   KIWI_0,17   MERG_K0_A1, 20   KIWI_0,30   KIWI_0,40   KIWI_0,80   MERG_K0_K1,160   KIWI_1,630   KIWI_1,2200"
    When so configured, on 20M WD merges the signals received by AUDIO_1 with those from KIWI_0 and posts only one copy (the strongest) of each received signal.
    Similarly on 10M WD merges the signals received by AUDIO_0 with those from KIWI_0 , and on 160M WD merges signals from KIWI_0 with those from KIWI_1.

    Not only will MERGed rxs avoid double posting spots to wsprnet.org, but as importantly when WD is run at verbosity level 1 (start as ./wsprdaemon.sh -va'), WD generates decode reports each two minutes which show all the spots in a MERG rx and which spot was chosen to be posted to wsprnet.org. Here is an example from another WD site of what you can learn in those posting.log files: 
    
odroid@wspr:/tmp/wspr-captures$ ls -lrt /tmp/wspr-captures/*/*/posting.log
-rw-r--r-- 1 odroid odroid      0 Jan  9 21:10 /tmp/wspr-captures/MERGED_RX_0/2200/posting.log
-rw-r--r-- 1 odroid odroid  32232 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/17/posting.log
-rw-r--r-- 1 odroid odroid  87501 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/20/posting.log
-rw-r--r-- 1 odroid odroid  22376 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/12/posting.log
-rw-r--r-- 1 odroid odroid  23300 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/60/posting.log
-rw-r--r-- 1 odroid odroid  26226 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/10/posting.log
-rw-r--r-- 1 odroid odroid  28614 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/15/posting.log
-rw-r--r-- 1 odroid odroid  27073 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/80eu/posting.log
-rw-r--r-- 1 odroid odroid  47324 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/160/posting.log
-rw-r--r-- 1 odroid odroid  88536 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/30/posting.log
-rw-r--r-- 1 odroid odroid  24427 Jan 10 04:41 /tmp/wspr-captures/K74/2200/posting.log
-rw-r--r-- 1 odroid odroid  53565 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/630/posting.log
-rw-r--r-- 1 odroid odroid  65804 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/80/posting.log
-rw-r--r-- 1 odroid odroid  24378 Jan 10 04:41 /tmp/wspr-captures/MERGED_RX_0/60eu/posting.log
-rw-r--r-- 1 odroid odroid 172637 Jan 10 04:42 /tmp/wspr-captures/MERGED_RX_0/40/posting.log
odroid@wspr:/tmp/wspr-captures$ tail -n 20 /tmp/wspr-captures/MERGED_RX_0/40/posting.log
Fri Jan 10 04:39:59 UTC 2020:   7.039999    W4ENN        -16    -27     -16p
Fri Jan 10 04:39:59 UTC 2020:   7.040049    N6KOG        -28            -28p
Fri Jan 10 04:39:59 UTC 2020:   7.040050    ZS3RF        -13    -13p    -14
Fri Jan 10 04:39:59 UTC 2020:   7.040069   WA8KNE          1     -0       1p
Fri Jan 10 04:39:59 UTC 2020:   7.040073   KJ4IHN        -23            -23p
Fri Jan 10 04:39:59 UTC 2020:   7.040106    K4APC         -5    -14      -5p
Fri Jan 10 04:39:59 UTC 2020:   7.040156    N9QDS        -20    -21     -20p
Fri Jan 10 04:39:59 UTC 2020:   7.040160         -12    -17     -12p
Fri Jan 10 04:42:10 UTC 2020:  FREQUENCY     CALL POSTED_SNR     K74     K76       TOTAL=19, POSTED=11
Fri Jan 10 04:42:10 UTC 2020:   7.039999   KD9JYV        -19    -22     -19p
Fri Jan 10 04:42:10 UTC 2020:   7.040000          -28            -28p
Fri Jan 10 04:42:10 UTC 2020:   7.040014    AF4MP        -26            -26p
Fri Jan 10 04:42:10 UTC 2020:   7.040028    W4DJW         -9     -9p    -10
Fri Jan 10 04:42:10 UTC 2020:   7.040039     KK1D        -22    -22p    -22p
Fri Jan 10 04:42:10 UTC 2020:   7.040058    W5MWI        -23    -24     -23p
Fri Jan 10 04:42:10 UTC 2020:   7.040068   VE3OWV        -23    -26     -23p
Fri Jan 10 04:42:10 UTC 2020:   7.040126   VE6DAI        -22    -24     -22p
Fri Jan 10 04:42:10 UTC 2020:   7.040141   KK4YEL        -24    -26     -24p
Fri Jan 10 04:42:10 UTC 2020:   7.040158    W1CEW        -21            -21p
Fri Jan 10 04:42:10 UTC 2020:   7.040162    W9RAN         -1     -3      -1p
odroid@wspr:/tmp/wspr-captures$
    You can see from that table that on 40M at 04:42 UTC rx "K76" is generally 1-3 dB more sensitive than "K74"
    G0LUJ