Date   

Re: wsprdaemon on Nvidia Jetson Nano

Jim Lill
 

what OS are you running?


Re: KIWI reports error in log

John Seamons
 

This error shouldn't appear in more recent Kiwi versions. When the non-NBFM squelch was implemented the API was changed slightly. But there was a period of time where the old API was not accepted as it should have been. The old API is used by directTDoA, kiwirecorder and, it looks like, wsprdaemon.


Re: Muting in new firmware of KiwiSDR.

John Seamons
 

(Sorry, only seeing this now as I don't check here very often.)

The new (non-NBFM) squelch function only effects the browser. Like the mute button.

But kiwirecorder connections are coming in on a different channel than a browser connection. So there wouldn't be any interaction anyway. There has been a suggestion that a muted channel should stop sending audio to the browser to save network bandwidth. But even if that were implemented it still wouldn't effect kiwirecorder connections.

Kiwirecorder has its own squelch setting that pauses recording to the file to save space.


wsprdaemon on Nvidia Jetson Nano

John
 

I have been working to get the daemon running on the 4GB nano. Most is looking well. The KIWIs are loading ok just no spot uploads.
At decode time { 8 sec mark} I see a bump in CPU to 80% but it only lasts for 3 seconds. How can I check on the wsprd processes? Can I learn anything with three -d ? Is there a place in the wsprdaemon.sh  where I might trap an error message?

John
TI4JWC


Re: 2 KIWI classic stuck in UPDATE

John
 

All fixed. Was ethernet switch problems./


Re: 2 KIWI classic stuck in UPDATE

WA2TP
 

I have found the update takes about 17 minutes. Try and do a full power cycle after 17 minutes


On Mar 28, 2021, at 8:35 PM, Rob Robinett <rob@...> wrote:


I think there is a topic on this problem in the forums.kiwisdr.com site.

On Sun, Mar 28, 2021 at 2:11 PM John via groups.io <n0ure=yahoo.com@groups.io> wrote:
I have two Classic KIWI stuck in Update. One from 1.445 to 1.446 and the other is just sitting at 1442 with 1446 Available but with no action. Both are not accepting settings from wsprdaemon.
Any ideas?
John
TI4JWC 



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


Re: 2 KIWI classic stuck in UPDATE

Rob Robinett
 

I think there is a topic on this problem in the forums.kiwisdr.com site.

On Sun, Mar 28, 2021 at 2:11 PM John via groups.io <n0ure=yahoo.com@groups.io> wrote:
I have two Classic KIWI stuck in Update. One from 1.445 to 1.446 and the other is just sitting at 1442 with 1446 Available but with no action. Both are not accepting settings from wsprdaemon.
Any ideas?
John
TI4JWC 



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


2 KIWI classic stuck in UPDATE

John
 

I have two Classic KIWI stuck in Update. One from 1.445 to 1.446 and the other is just sitting at 1442 with 1446 Available but with no action. Both are not accepting settings from wsprdaemon.
Any ideas?
John
TI4JWC 


Ok, I'm Officially Impressed With ClickHouse

Greg Beam
 

Hello All,

I was going through their examples (on my local workstation), testing things out, and getting a feel the CLI / API. I decided to load one of their bigger datasets and play around some. I chose the Airline OnTime-Dataset first and went through all the example queries. This thing is seriously fast, and that's putting it mildly.

I don't know what it would do, or how it would handle, hundreds of concurrent users, but, if it scales with clustering the way it's performing on a single node, it's hard to imagine using anything else (at the price point it offers) with the anticipated volumes WSPR is expecting over the next cycle.

I realize there is still a fair bit of ETL needed before shoving things a into the warehouse, but, I can see use cases of all sorts with this thing.

73's
Greg, KI7MT


Re: ClickHouse / PostreSQL FDW Integrations

Greg Beam
 

Hello All,

I should have looked a bit further before diving into a complex solution.

Third Party UI Clients are Plentiful

I already have a subscription to JetBrains DataGrip (and others), and it has native support for ClickHouse. All I had to do was look for the connector .. Doooh !!!

In any Case, the more I learn about ClickHouse, the more impressed I become. This thing is powerful, and seriously fast !!

73's
Greg, KI7MT


Re: This is not good - All the more reason for distributed services I suppose

Greg Beam
 

Disaster recovery / backups are never important until ya need them (been there, done that, lost the data).

I've got a full copy of the WSPRnet dataset also, in multiple locations. Not that I really need to, but, its nice not having to re-download those big files.

I've got data center infrastructure on Azure and AWS in multiple zones also. It's costly to have and maintain, but, it's there when the lights go out in a zone.


Re: This is not good - All the more reason for distributed services I suppose

Rob Robinett
 

We maintain 3 copies of the wsprdaemon.org site:  

1) wsprdameon.org is a cloud server maintained by digitalocean.com on a Silicon Valley server
2) wd1.wsprdaemon.org is a Dell server located in a telco engineering lab in Sacramento California , 200 Km from WD2
3) wd2.wsprdaemon.org is a Dell server located in the Hurricane Electric Tier 1 peering point in Fremont California in Silicon Valley

DNS is handled by Google.

So unless all of California burns up or slides in the Pacific Ocean, I think we have a pretty reliable system


Re: This is not good - All the more reason for distributed services I suppose

admin@...
 

Yeah that was bad luck. I never considered wspr.live to be important enough to include it in my backups and now it is gone into the cloud forever. The dashboards and the information page are lost.

But I just rewrote the page and will put Grafana back on air soon.

The Database itself is easy to restore in case of loss as long as wsprnet.org is available we can just reimport the data.


ClickHouse / PostreSQL FDW Integrations

Greg Beam
 

Hello All,

I'm probably late to the party, as usual, but, I was playing around with Phill's wspr.rocks site, and it definitely Rocks on the speed front !!

I'm looking to explore ClickHouse Database solutions a good bit more and was wondering two things:
I have a server set up with ClickHouse and walked through a couple of their DataSet examples. There's no question, the thing is seriously fast.

Thanks

73's
Greg, KI7MT


This is not good - All the more reason for distributed services I suppose

Greg Beam
 

Just saw this today.

Thankfully, the DB looks to be functional still.


Muting in new firmware of KiwiSDR.

KD2OM
 

Does the threshold control have any effect on kiwirecorder, or is it just for the audio that is heard in the browser?

73
Steve KD2OM


Re: http://jimlill.com/today_int.html Down?

Jim Lill
 

It had a hardware failure. Time permitting, it will arise from the ashes soon...  The scraper portion is running. The analysis section will be awhile and I am doing a rewrite since it is already down.
1310.00


Re: migrate wsprdaemon to Atomicpi

John
 

I spent 3 days trying to get port forwarding to work with SSH server and access with Putty from my windows machine. No problems when I use the local NAT addresses.
But no joy when out on the Internet. I have found that I am behind the ISP fiber router in the house that also provides voice service. I have no access to this router so cannot enable port forwarding I have settled on TeamViewer for remote access.


Re: Conf file example - two receivers, different bands, one Pi

Edward Hammond
 

Great, thank you.  I was just figuring out the wickedness of my ways and fixing my immediate problem when this arrived.

You've gone above and beyond and actually answered what would have been my next question below!  :-)

Thank you!

Edward

On 3/14/21 2:34 PM, Glenn Elmore wrote:
The wd.conf below works to allow to different Kiwi's (GN2 remote and GN0 local) to both post as "N6GN/K", run on both same and different bands and be scheduled throughout the day, though lately I've been running the same 24/7. This is  WSPR_SCHEDULE_merged

Declare the RECEIVER_LIST first, individual Kiwi's come before the merged ones.  Then just call out what you want in the schedule.

THere is a subtle 'gotcha' that you shouldn't run different receiver/gridsquare on the same band as they may post twice rather than once as is desired.

Glenn n6gn


# To enable these options, remove the leading '#' and modify SIGNAL_LEVEL_UPLOAD_ID from "AI6VN" to your call sign:
SIGNAL_LEVEL_UPLOAD="noise"        ### If this variable is defined and not "no", AND SIGNAL_LEVEL_UPLOAD_ID is defined, then upload signal levels to the wsprdaemon cloud database
                                   ### SIGNAL_LEVEL_UPLOAD_MODE="no"    => (Default) Upload spots directly to wsprnet.org
                                   ### SIGNAL_LEVEL_UPLOAD_MODE="noise" => Upload extended spots and noise data.  Upload spots directly to wsprnet.org
                                   ### SIGNAL_LEVEL_UPLOAD_MODE="proxy" => In addition to "noise", don't upload to wsprnet.org from this server.  Regenerate and upload spots to wsprnet.org on the wsprdaemon.org server
SIGNAL_LEVEL_UPLOAD="yes"          ### If this variable is defined as "yes" AND SIGNAL_LEVEL_UPLOAD_ID is defined, then upload extended spots and noise levels to the logs.wsprdaemon.org database and graphics file server.
SIGNAL_LEVEL_UPLOAD_ID="N6GN"     ### The name put in upload log records, the the title bar of the graph, and the name used to view spots and noise at that server.
SIGNAL_LEVEL_UPLOAD_GRAPHS="yes"   ### If this variable is defined as "yes" AND SIGNAL_LEVEL_UPLOAD_ID is defined, then FTP graphs of the last 24 hours to http://wsprdaemon.org/graphs/SIGNAL_LEVEL_UPLOAD_ID
SIGNAL_LEVEL_LOCAL_GRAPHS="yes"    ### If this variable is defined as "yes" AND SIGNAL_LEVEL_UPLOAD_ID is defined, then make graphs visible at http://localhost/

##############################################################
### The RECEIVER_LIST() array defines the physical (KIWI_xxx,AUDIO_xxx,SDR_xxx) and logical (MERG...) 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    Optional SIGNAL_LEVEL_ADJUSTMENTS
### [[DEFAULT:ADJUST,]BAND_0:ADJUST[,BAND_N:ADJUST_N]...]
### A comma-separated list of BAND:ADJUST pairsyy
### BAND is one of 2200..10, while AJUST is in dBp TO BE ADDED to the raw data, e.g. '-10' will LOWER the reported level
### DEFAULT defaults to zero and is applied to all bands not specified with a BAND:ADJUST

declare RECEIVER_LIST=(
"GN0            10.0.0.161:8073         N6GN/K       DN70ll kiwis_password DEFAULT:-2.0,2200:11.6,630:10.5,160:4.5,80:1.3,60:0.0,40:-0.7,30:-1.0,20:-0.8,17:-1.0,15:-0.4,12:0.2,10:0.0"
"GN2            10.0.0.102:8075         N6GN/K       DN70jo kiwis_password DEFAULT:-2.0,2200:11.6,630:10.5,160:4.5,80:1.3,60:0.0,40:-0.7,30:-1.0,20:-0.8,17:-1.0,15:-0.4,12:0.2,10:0.0"
"GN3            10.0.0.77:8074          N6GN/K       DN70ll kiwis_password DEFAULT:-2.0,2200:11.6,630:10.5,160:4.5,80:1.3,60:0.0,40:-0.7,30:-1.0,20:-0.8,17:-1.0,15:-0.4,12:0.2,10:0.0"
"GN4            10.0.0.67:8076          N6GN/P       DN70ll kiwis_password DEFAULT:-2.0,2200:11.6,630:10.5,160:4.5,80:1.3,60:0.0,40:-0.7,30:-1.0,20:-0.8,17:-1.0,15:-0.4,12:0.2,10:0.0"
"K6RFT          k6rft.proxy.kiwisdr.com:8073     K6RFT   EM47bg kiwis_password     DEFAULT:0.0"

"MERGED_RX_02   GN0,GN2                 N6GN/K       DN70ll kiwis_password"
"MERGED_RX_23   GN2,GN3                 N6GN/K       DN70ll kiwis_password"
"MERGED_RX_03   GN0,GN3                 N6GN/K       DN70ll kiwis_password"
"MERGED_RX_023  GN0,GN2,GN3             N6GN/K       DN70ll kiwis_password"
"MERGED_RX_034  GN0,GN3,GN4             N6GN/K       DN70ll kiwis_password"
"MERGED_RX_34   GN3,GN4                 N6GN/K       DN70ll kiwis_password"
)

### This table defines a schedule of configurations which will be applied by '-j a,all' and thus by the watchdog daemon when it runs '-j a,all' ev ery odd two minutes
### The first field of each entry in the start time for the configuration defined in the following fields
### Start time is in the format HH:MM (e.g 13:15) and by default is in the time zone of the host server unless ',UDT' is appended, e.g '01:30,UDT'
### Following the time are one or more fields of the format 'RECEIVER,BAND'
### If the time of the first entry is not 00:00, then the latest (not necessarily the last) entry will be applied at time 00:00
### So the form of each line is  "START_HH:MM[,UDT] RECEIVER,BAND... ".  Here are some examples:

declare WSPR_SCHEDULE_simple1=(
    "00:00                       GN0,2200 GN0,630 GN0,160 GN0,80 GN0,80eu GN0,60 GN0,40 GN0,30 GN0,20 GN0,17 GN0,15 GN0,12 GN0,10"
)

declare WSPR_SCHEDULE_simple2=(
    "00:00                       GN0,2200 MERGED_RX_03,630 MERGED_RX_03,160 GN0,80eu MERGED_RX_03,80 GN0,60 MERGED_RX_03,40 MERGED_RX_03,30 MERGED_RX_03,20 GN0,17 MERGED_RX_03,15  GN0,12 GN0,10"
)

declare WSPR_SCHEDULE_simple4=(
    "00:00                       GN0,2200 GN0,630 GN0,160 GN0,80 GN0,80eu GN0,60 GN0,40 GN0,30 GN0,20 GN0,17 GN0,15 GN0,12 GN0,10    GN3,80 GN3,40 GN3,30 GN3,20 GN3,17 GN3,15 GN3,10"
)


declare WSPR_SCHEDULE_merged=(
    "00:00                       GN0,2200 GN0,630 GN0,160 MERGED_RX_02,80 GN0,80eu GN0,60eu MERGED_RX_02,40 MERGED_RX_02,30  MERGED_RX_02,20  MERGED_RX_02,17 MERGED_RX_02,15 GN0,12 GN0,10 "
)

declare WSPR_SCHEDULE_complex=(
    "sunrise-01:00               KIWI_0,630 KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12          "
    "sunrise+01:00                          KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12 KIWI_1,10"
    "09:00                       KIWI_0,630 KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12          "
    "10:00                                  KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12 KIWI_1,10"
    "11:00                                             KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12 KIWI_1,10"
    "18:00           KIWI_0,2200 KIWI_0,630 KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15                    "
    "sunset-01:00                           KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12 KIWI_1,10"
    "sunset+01:00                KIWI_0,630 KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12 KIWI_1,10"
)

### This array WSPR_SCHEDULE defines the running configuration. Here we make the simple configuration defined above the active one:
#declare WSPR_SCHEDULE=( "${WSPR_SCHEDULE_simple2[@]}" )
declare WSPR_SCHEDULE=( "${WSPR_SCHEDULE_merged[@]}" )

On 3/14/21 11:39 AM, Edward Hammond wrote:
Hi Folks -

I would greatly appreciate it if somebody could please forward an example of a wsprdaemon.conf file that manages two Kiwis *while allocating a different set of bands to each receiver*.

I was getting right proud of myself for merging my receivers ... on the first try even .... and then I realized (duh!) that each Kiwi is now monitoring the same set of bands!

In my setup the receivers are tuned to different bands, but I would love to manage them with a single Pi running a single wsprdaemon instance.  Presently I have two Pis each running its own wsprdaemon.

Unplugging one Pi would be great as I am planning to move the whole WSPR receiving setup off-grid and it would save quite a bit of electricity (relative to a modest solar setup!).

Edward

W3ENR








Re: Conf file example - two receivers, different bands, one Pi

Glenn Elmore
 

The wd.conf below works to allow to different Kiwi's (GN2 remote and GN0 local) to both post as "N6GN/K", run on both same and different bands and be scheduled throughout the day, though lately I've been running the same 24/7. This is  WSPR_SCHEDULE_merged

Declare the RECEIVER_LIST first, individual Kiwi's come before the merged ones.  Then just call out what you want in the schedule.

THere is a subtle 'gotcha' that you shouldn't run different receiver/gridsquare on the same band as they may post twice rather than once as is desired.

Glenn n6gn


# To enable these options, remove the leading '#' and modify SIGNAL_LEVEL_UPLOAD_ID from "AI6VN" to your call sign:
SIGNAL_LEVEL_UPLOAD="noise"        ### If this variable is defined and not "no", AND SIGNAL_LEVEL_UPLOAD_ID is defined, then upload signal levels to the wsprdaemon cloud database
                                   ### SIGNAL_LEVEL_UPLOAD_MODE="no"    => (Default) Upload spots directly to wsprnet.org
                                   ### SIGNAL_LEVEL_UPLOAD_MODE="noise" => Upload extended spots and noise data.  Upload spots directly to wsprnet.org
                                   ### SIGNAL_LEVEL_UPLOAD_MODE="proxy" => In addition to "noise", don't upload to wsprnet.org from this server.  Regenerate and upload spots to wsprnet.org on the wsprdaemon.org server
SIGNAL_LEVEL_UPLOAD="yes"          ### If this variable is defined as "yes" AND SIGNAL_LEVEL_UPLOAD_ID is defined, then upload extended spots and noise levels to the logs.wsprdaemon.org database and graphics file server.
SIGNAL_LEVEL_UPLOAD_ID="N6GN"     ### The name put in upload log records, the the title bar of the graph, and the name used to view spots and noise at that server.
SIGNAL_LEVEL_UPLOAD_GRAPHS="yes"   ### If this variable is defined as "yes" AND SIGNAL_LEVEL_UPLOAD_ID is defined, then FTP graphs of the last 24 hours to http://wsprdaemon.org/graphs/SIGNAL_LEVEL_UPLOAD_ID
SIGNAL_LEVEL_LOCAL_GRAPHS="yes"    ### If this variable is defined as "yes" AND SIGNAL_LEVEL_UPLOAD_ID is defined, then make graphs visible at http://localhost/

##############################################################
### The RECEIVER_LIST() array defines the physical (KIWI_xxx,AUDIO_xxx,SDR_xxx) and logical (MERG...) 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    Optional SIGNAL_LEVEL_ADJUSTMENTS
### [[DEFAULT:ADJUST,]BAND_0:ADJUST[,BAND_N:ADJUST_N]...]
### A comma-separated list of BAND:ADJUST pairsyy
### BAND is one of 2200..10, while AJUST is in dBp TO BE ADDED to the raw data, e.g. '-10' will LOWER the reported level
### DEFAULT defaults to zero and is applied to all bands not specified with a BAND:ADJUST

declare RECEIVER_LIST=(
"GN0            10.0.0.161:8073         N6GN/K       DN70ll kiwis_password DEFAULT:-2.0,2200:11.6,630:10.5,160:4.5,80:1.3,60:0.0,40:-0.7,30:-1.0,20:-0.8,17:-1.0,15:-0.4,12:0.2,10:0.0"
"GN2            10.0.0.102:8075         N6GN/K       DN70jo kiwis_password DEFAULT:-2.0,2200:11.6,630:10.5,160:4.5,80:1.3,60:0.0,40:-0.7,30:-1.0,20:-0.8,17:-1.0,15:-0.4,12:0.2,10:0.0"
"GN3            10.0.0.77:8074          N6GN/K       DN70ll kiwis_password DEFAULT:-2.0,2200:11.6,630:10.5,160:4.5,80:1.3,60:0.0,40:-0.7,30:-1.0,20:-0.8,17:-1.0,15:-0.4,12:0.2,10:0.0"
"GN4            10.0.0.67:8076          N6GN/P       DN70ll kiwis_password DEFAULT:-2.0,2200:11.6,630:10.5,160:4.5,80:1.3,60:0.0,40:-0.7,30:-1.0,20:-0.8,17:-1.0,15:-0.4,12:0.2,10:0.0"
"K6RFT          k6rft.proxy.kiwisdr.com:8073     K6RFT   EM47bg kiwis_password     DEFAULT:0.0"

"MERGED_RX_02   GN0,GN2                 N6GN/K       DN70ll kiwis_password"
"MERGED_RX_23   GN2,GN3                 N6GN/K       DN70ll kiwis_password"
"MERGED_RX_03   GN0,GN3                 N6GN/K       DN70ll kiwis_password"
"MERGED_RX_023  GN0,GN2,GN3             N6GN/K       DN70ll kiwis_password"
"MERGED_RX_034  GN0,GN3,GN4             N6GN/K       DN70ll kiwis_password"
"MERGED_RX_34   GN3,GN4                 N6GN/K       DN70ll kiwis_password"
)

### This table defines a schedule of configurations which will be applied by '-j a,all' and thus by the watchdog daemon when it runs '-j a,all' ev ery odd two minutes
### The first field of each entry in the start time for the configuration defined in the following fields
### Start time is in the format HH:MM (e.g 13:15) and by default is in the time zone of the host server unless ',UDT' is appended, e.g '01:30,UDT'
### Following the time are one or more fields of the format 'RECEIVER,BAND'
### If the time of the first entry is not 00:00, then the latest (not necessarily the last) entry will be applied at time 00:00
### So the form of each line is  "START_HH:MM[,UDT] RECEIVER,BAND... ".  Here are some examples:

declare WSPR_SCHEDULE_simple1=(
    "00:00                       GN0,2200 GN0,630 GN0,160 GN0,80 GN0,80eu GN0,60 GN0,40 GN0,30 GN0,20 GN0,17 GN0,15 GN0,12 GN0,10"
)

declare WSPR_SCHEDULE_simple2=(
    "00:00                       GN0,2200 MERGED_RX_03,630 MERGED_RX_03,160 GN0,80eu MERGED_RX_03,80 GN0,60 MERGED_RX_03,40 MERGED_RX_03,30 MERGED_RX_03,20 GN0,17 MERGED_RX_03,15  GN0,12 GN0,10"
)

declare WSPR_SCHEDULE_simple4=(
    "00:00                       GN0,2200 GN0,630 GN0,160 GN0,80 GN0,80eu GN0,60 GN0,40 GN0,30 GN0,20 GN0,17 GN0,15 GN0,12 GN0,10    GN3,80 GN3,40 GN3,30 GN3,20 GN3,17 GN3,15 GN3,10"
)


declare WSPR_SCHEDULE_merged=(
    "00:00                       GN0,2200 GN0,630 GN0,160 MERGED_RX_02,80 GN0,80eu GN0,60eu MERGED_RX_02,40 MERGED_RX_02,30  MERGED_RX_02,20  MERGED_RX_02,17 MERGED_RX_02,15 GN0,12 GN0,10 "
)

declare WSPR_SCHEDULE_complex=(
    "sunrise-01:00               KIWI_0,630 KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12          "
    "sunrise+01:00                          KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12 KIWI_1,10"
    "09:00                       KIWI_0,630 KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12          "
    "10:00                                  KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12 KIWI_1,10"
    "11:00                                             KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12 KIWI_1,10"
    "18:00           KIWI_0,2200 KIWI_0,630 KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15                    "
    "sunset-01:00                           KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12 KIWI_1,10"
    "sunset+01:00                KIWI_0,630 KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12 KIWI_1,10"
)

### This array WSPR_SCHEDULE defines the running configuration. Here we make the simple configuration defined above the active one:
#declare WSPR_SCHEDULE=( "${WSPR_SCHEDULE_simple2[@]}" )
declare WSPR_SCHEDULE=( "${WSPR_SCHEDULE_merged[@]}" )

On 3/14/21 11:39 AM, Edward Hammond wrote:
Hi Folks -

I would greatly appreciate it if somebody could please forward an example of a wsprdaemon.conf file that manages two Kiwis *while allocating a different set of bands to each receiver*.

I was getting right proud of myself for merging my receivers ... on the first try even .... and then I realized (duh!) that each Kiwi is now monitoring the same set of bands!

In my setup the receivers are tuned to different bands, but I would love to manage them with a single Pi running a single wsprdaemon instance.  Presently I have two Pis each running its own wsprdaemon.

Unplugging one Pi would be great as I am planning to move the whole WSPR receiving setup off-grid and it would save quite a bit of electricity (relative to a modest solar setup!).

Edward

W3ENR




81 - 100 of 287