Date   

Re: Transient missing spots events may require WD server CPU upgrade

Rob Robinett
 

In WD V3.0 I will be adding support for FST4W 120/300/900/1800 and using those modes, especially the 900/1800, will surely require more CPU than any Pi can offer.

On Tue, May 25, 2021 at 1:06 PM Edward Hammond <manager@...> wrote:
Sorry, a correction.  It was FT8 that was pushing my Pi to its limits
then, not WSPR.  But I would think overclocking would similarly help in
this situation.

EH


On 5/25/21 3:29 PM, Edward Hammond wrote:
>
> I noticed last year that my decode cycles were pushing the Pi's
> limits.  Your mileage may vary, and it certainly will void any
> warranty, but overclocking the Pi4 is also a possibility.
>
> I experimented with that option and, on my example at least, I could
> dial in a ~12-14% clock speed boost stably (IIRC).  This did shorten
> the decoding cycle.
>
> Any higher clock rate, again on my particular Pi, and it started
> behaving erratically.
>
> Edward
>
>
>
> On 5/25/21 12:37 PM, Rob Robinett wrote:
>> This kind of problem has been reported by others in the Wednesday WD
>> Zoom call and fixed by upgrading to a more powerful CPU than the ARM
>> on the Pi4.  It appears that with the summer months and increasing
>> sunspot cycle, the Pi CPUs can't keep up decoding the number of spots
>> in the wav file captures.  However it is hard to observe those 'out
>> of CPU' events.
>> Most of the top spotting sites have migrated from Pi4s to i86
>> servers.  An inexpensive, low power and high performance option is
>> the Lenovo M93P Tiny PC (don't get the larger model) with i5 CPU
>> which can be purchased used or refurbished for $100 or less on ebay:
>> https://tinyurl.com/emrjnw  The M93P consumes 12W peaking at 36W
>> while decoding spots.
>> WD requires very little RAM space, so a 2 or 4GB machine would be
>> fine.  I bought mine without HD and added a SSD and installed Ubuntu
>> 20.04 LTS. But since WD does very little disk  IO to the root file
>> system, using a rotating HD might be a better choice for longer life.
>>
>
>








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


Re: Transient missing spots events may require WD server CPU upgrade

Edward Hammond
 

Sorry, a correction.  It was FT8 that was pushing my Pi to its limits then, not WSPR.  But I would think overclocking would similarly help in this situation.

EH

On 5/25/21 3:29 PM, Edward Hammond wrote:

I noticed last year that my decode cycles were pushing the Pi's limits.  Your mileage may vary, and it certainly will void any warranty, but overclocking the Pi4 is also a possibility.

I experimented with that option and, on my example at least, I could dial in a ~12-14% clock speed boost stably (IIRC).  This did shorten the decoding cycle.

Any higher clock rate, again on my particular Pi, and it started behaving erratically.

Edward



On 5/25/21 12:37 PM, Rob Robinett wrote:
This kind of problem has been reported by others in the Wednesday WD Zoom call and fixed by upgrading to a more powerful CPU than the ARM on the Pi4.  It appears that with the summer months and increasing sunspot cycle, the Pi CPUs can't keep up decoding the number of spots in the wav file captures.  However it is hard to observe those 'out of CPU' events.
Most of the top spotting sites have migrated from Pi4s to i86 servers.  An inexpensive, low power and high performance option is the Lenovo M93P Tiny PC (don't get the larger model) with i5 CPU which can be purchased used or refurbished for $100 or less on ebay: https://tinyurl.com/emrjnw  The M93P consumes 12W peaking at 36W while decoding spots.
WD requires very little RAM space, so a 2 or 4GB machine would be fine.  I bought mine without HD and added a SSD and installed Ubuntu 20.04 LTS. But since WD does very little disk  IO to the root file system, using a rotating HD might be a better choice for longer life.


Re: Transient missing spots events may require WD server CPU upgrade

Edward Hammond
 

I noticed last year that my decode cycles were pushing the Pi's limits.  Your mileage may vary, and it certainly will void any warranty, but overclocking the Pi4 is also a possibility.

I experimented with that option and, on my example at least, I could dial in a ~12-14% clock speed boost stably (IIRC).  This did shorten the decoding cycle.

Any higher clock rate, again on my particular Pi, and it started behaving erratically.

Edward

On 5/25/21 12:37 PM, Rob Robinett wrote:
This kind of problem has been reported by others in the Wednesday WD Zoom call and fixed by upgrading to a more powerful CPU than the ARM on the Pi4.  It appears that with the summer months and increasing sunspot cycle, the Pi CPUs can't keep up decoding the number of spots in the wav file captures.  However it is hard to observe those 'out of CPU' events.
Most of the top spotting sites have migrated from Pi4s to i86 servers.  An inexpensive, low power and high performance option is the Lenovo M93P Tiny PC (don't get the larger model) with i5 CPU which can be purchased used or refurbished for $100 or less on ebay: https://tinyurl.com/emrjnw  The M93P consumes 12W peaking at 36W while decoding spots.
WD requires very little RAM space, so a 2 or 4GB machine would be fine.  I bought mine without HD and added a SSD and installed Ubuntu 20.04 LTS. But since WD does very little disk  IO to the root file system, using a rotating HD might be a better choice for longer life.


Transient missing spots events may require WD server CPU upgrade

Rob Robinett
 

This kind of problem has been reported by others in the Wednesday WD Zoom call and fixed by upgrading to a more powerful CPU than the ARM on the Pi4.  It appears that with the summer months and increasing sunspot cycle, the Pi CPUs can't keep up decoding the number of spots in the wav file captures.  However it is hard to observe those 'out of CPU' events.
 
Most of the top spotting sites have migrated from Pi4s to i86 servers.  An inexpensive, low power and high performance option is the Lenovo M93P Tiny PC (don't get the larger model) with i5 CPU which can be purchased used or refurbished for $100 or less on ebay:  https://tinyurl.com/emrjnw  The M93P consumes 12W peaking at 36W while decoding spots.
 
WD requires very little RAM space, so a 2 or 4GB machine would be fine.  I bought mine without HD and added a SSD and installed Ubuntu 20.04 LTS. But since WD does very little disk  IO to the root file system, using a rotating HD might be a better choice for longer life.
 


Re: recent c2_level very low on some bands

Rob Robinett
 

I hope the new CPU fixes your problem.
It is great to have help with OS support.


On Sat, May 22, 2021 at 3:21 PM hf_linkz <ounaid@...> wrote:
I would like to thanks Rob and company for the analysis of my setup the other day (via the Zoom meeting)
It appeared that my Raspberry Pi 3B+ was too weak for a 12 chan monitoring, it used to work fine in the past so maybe the newer OS release was a bit too heavy that time .. who knows

But today I have modified the script to run on a more powerful computer, running an Archlinux distro
Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz (bogomips ~5700, it was 40 on the pi3 HI HI) - 4GB RAM - SSD drive

It's now 2310z on 22 may 2021 and wsprdaemon.sh is running on this computer
I will have a look on the logs to see if something is wrong and if it's OK then I'll fork the git code and commit the modified version for that specific OS, mods are mostly s/apt-get/pacman/ btw

Regards







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


Re: recent c2_level very low on some bands

hf_linkz
 

I would like to thanks Rob and company for the analysis of my setup the other day (via the Zoom meeting)
It appeared that my Raspberry Pi 3B+ was too weak for a 12 chan monitoring, it used to work fine in the past so maybe the newer OS release was a bit too heavy that time .. who knows

But today I have modified the script to run on a more powerful computer, running an Archlinux distro
Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz (bogomips ~5700, it was 40 on the pi3 HI HI) - 4GB RAM - SSD drive

It's now 2310z on 22 may 2021 and wsprdaemon.sh is running on this computer
I will have a look on the logs to see if something is wrong and if it's OK then I'll fork the git code and commit the modified version for that specific OS, mods are mostly s/apt-get/pacman/ btw

Regards


Re: Audio input decoding

Rob Robinett
 

Have you executed './wsprdaemon.sh -i' ? 
t will help you find the audio port IDs and set the gain of your ports.


Audio input decoding

Paulo CT
 

Hello all,

I´ve been trying to run a single band wspr monitor with the audio input feature, but with no success. My present setup consists on a Funcube dongle, playong on the PC´s own soundcard. Since there´s no speakers plugged in, the default input the monitor for dummy audi output, that can be seen both by WSJTX and a QRSS grabbers.

I´m using a modified default config file, with only AUDIO_0 enabled, which suposedly should be listening on localhost:0,0. So far, I havn´t been able to see any spots from this setup. i also tried with my main shack PC, with an external soundcard, with no results as well.
OS is Ubuntu 20.04.

Here´s my current .conf file:

# To enable these options, remove the leading '#' and modify SIGNAL_LEVEL_UPLOAD_ID from "AI6VN" to your call sign:
#SIGNAL_LEVEL_UPLOAD="proxy"        ### 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="AI6VN"     ### 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 pairs
###                                                                                       BAND is one of 2200..10, while ADJUST is in dBs TO BE ADDED to the raw data
###                                                                                       So If you have a +10 dB LNA, ADJUST '-10' will LOWER the reported level so that your reports reflect the level at the input of the LNA
###                                                                                       DEFAULT defaults to zero and is applied to all bands not specified with a BAND:ADJUST

declare RECEIVER_LIST=(
#        "KIWI_0                  10.11.12.100:8073     AI6VN         CM88mc    NULL"
#        "KIWI_1                  10.11.12.101:8073     AI6VN         CM88mc  foobar       DEFAULT:-10,80:-12,30:-8,20:2,15:6"
#        "KIWI_2                  10.11.12.102:8073     AI6VN         CM88mc  foobar"
         "AUDIO_0                     localhost:0,0     CT2IWW        IN51wf  foobar"               ### The id AUDIO_xxx is special and defines a local audio input device as the source of WSPR baseband 1400-1600 Hz signals
#        "AUDIO_1                     localhost:1,0     AI6VN         CM88mc  foobar"  
#        "SDR_0                           RTL-SDR:0     AI6VN         CM88mc  foobar"               ### The id SDR_xxx   is special and defines a local RTL-SDR or other Soapy-suported device
#        "SDR_1                           RTL-SDR:1     AI6VN         CM88mc  foobar"
#        "MERG_0    KIWI_1,KIWI2,AUDIO_1,SDR_1     AI6VN         CM88mc  foobar"
)

### 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_simple=(
    "00:00                       AUDIO_0,10 "
)

#declare WSPR_SCHEDULE_merged=(
#    "00:00                       MERG_0,630 MERG_0,160"
#)

#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_simple[@]}" )

Any thoughts?

thanks

Paulo, CT2IWW


Re: Prefix/suffix call signs TX messages (Type 2) don't make it to WSPRnet.org, any solution for this?

Harry Zachrisson - SM7PNV
 

I think I am on its way to track down the weirdness with Type 2 messages.
It seems they only show up if I am also running a receiver with the same call sign and suffix.

I if  run a TX sending SM7PNV/7 and a RX with call sign SM7PNV the TX messages don't show up until I change my RX call sign to SM7PNV/7
The Type 2 message don't contain a locator so it is taken from the RX instead of leaving blank.
This a slight problem as well.

So if I send type    1 message as SM7PNV with locator AA00
followed by a type 2 message as SM7PNV/7

the first message will have locator AA00 but the second message will not.
It will have the locator of my receiving station inserted

OK at least know I know how it works, not super useful in my applications.
I was thinking to use it for trackers that could have used the Type 2 message to differentiate between several trackers running at the same time
E.g several balloons or sea buoys operating with the same Call sign but with different suffixes

73
//Harry 

 


Re: recent c2_level very low on some bands

hf_linkz
 

Ok thanks

I'll provide you a link to

Regards


Re: recent c2_level very low on some bands

Rob Robinett
 

I can think of no band specific error mechanism.
If you can provide me a way to ssh to your Pi, I'll log on and take a look.

On Wed, May 19, 2021 at 6:44 AM hf_linkz <ounaid@...> wrote:
Hello Rob

yes, yes and yes







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


Re: recent c2_level very low on some bands

hf_linkz
 

Hello Rob

yes, yes and yes


Re: recent c2_level very low on some bands

Rob Robinett
 

Hi,

Are both Kiwis configured in 8 channel mode?  When WD is not running are all 8 channels free?  Then, when you start WD do you see the 6 WD users on each of the Kiwis?

Rob 

On Wed, May 19, 2021 at 6:35 AM hf_linkz <ounaid@...> wrote:
Hi

I'm using a Raspberry Pi 3B+ with 2 local LAN KiwiSDRs (one on v1.444, the other on v1.456)
I recently had problems on the old SD card that was unwritable so i had to rebuild a 32GB SD with Raspberry Pi OS Lite (no desktop env) - Python 3.7.3 - numpy 1.16.2
I git to retrieve the 2.10j project
./wsprdaemon.sh -V ran successfully w/o errors
I'm also using the backup wsprdaemon.conf from the previous setup (shown below)
declare WSPR_SCHEDULE_simple=(
    "00:00                       KIWI_0,2200 KIWI_0,630 KIWI_0,160 KIWI_0,80 KIWI_0,60eu KIWI_0,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12 KIWI_1,10"
declare WSPR_SCHEDULE=( "${WSPR_SCHEDULE_simple[@]}" )

----
My problem is that 40, 30 & 20 bands spots are not reported on wsprnet.org (it's working if I use the KiwiSDR wspr extension on them)
----

I tried to debug using different antennas configurations, swapping the KIWI_0 with KIWI_1 and vice-versa, but still noticing the c2_levels are most of the time at -1000 value for the 3 bands so the noise graphs are only showing rms levels... (The noise graphs on the 9 other bands look ok)

I'm going mad, I used to plot much more trafic on 40,30 & 20
What's the problem of those -1000 c2_level values on the 3 bands ?

Any suggestions ?

Regards







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


recent c2_level very low on some bands

hf_linkz
 

Hi

I'm using a Raspberry Pi 3B+ with 2 local LAN KiwiSDRs (one on v1.444, the other on v1.456)
I recently had problems on the old SD card that was unwritable so i had to rebuild a 32GB SD with Raspberry Pi OS Lite (no desktop env) - Python 3.7.3 - numpy 1.16.2
I git to retrieve the 2.10j project
./wsprdaemon.sh -V ran successfully w/o errors
I'm also using the backup wsprdaemon.conf from the previous setup (shown below)
declare WSPR_SCHEDULE_simple=(
"00:00 KIWI_0,2200 KIWI_0,630 KIWI_0,160 KIWI_0,80 KIWI_0,60eu KIWI_0,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12 KIWI_1,10"
declare WSPR_SCHEDULE=( "${WSPR_SCHEDULE_simple[@]}" )

----
My problem is that 40, 30 & 20 bands spots are not reported on wsprnet.org (it's working if I use the KiwiSDR wspr extension on them)
----

I tried to debug using different antennas configurations, swapping the KIWI_0 with KIWI_1 and vice-versa, but still noticing the c2_levels are most of the time at -1000 value for the 3 bands so the noise graphs are only showing rms levels... (The noise graphs on the 9 other bands look ok)

I'm going mad, I used to plot much more trafic on 40,30 & 20
What's the problem of those -1000 c2_level values on the 3 bands ?

Any suggestions ?

Regards


Re: URL for Spots history

Rob Robinett
 

Hi Jim,  I miss your %dups column.  Phil's 'Duplicates' page doesn't quite show that information.

On Sat, May 15, 2021 at 9:37 AM Jim Lill <jim@...> wrote:

I have thought above retiring my site but as I still want all the spot data for my own propagation research, I decided to continue

On 5/15/21 11:16 AM, Rob Robinett wrote:
Jim, you inspired Phil's site.

On Sat, May 15, 2021 at 7:58 AM Jim Lill <jim@...> wrote:

as a backup, there's always my site jimlill.com:8088

On 5/15/21 10:47 AM, Edward Hammond wrote:

As far as I know, there's really nothing even close to as good as http://wspr.rocks  ... except I suppose wsprd.vk7jj.com.  :-)

It's fantastic, and having a really handsome and functional site like that adds loads of interest, for me at least, in the WSPR hobby. 

My thanks and congratulations to those responsible.

Edward

W3ENR


On 5/15/21 10:30 AM, Rob Robinett wrote:
The bands are fine
My preferred search:  http://wspr.rocks/

On Sat, May 15, 2021 at 6:57 AM John via groups.io <n0ure=yahoo.com@groups.io> wrote:
What are the URLs for WSPR history? Are the bands dead? I have no spots.

John


--
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: URL for Spots history

Jim Lill
 

I have thought above retiring my site but as I still want all the spot data for my own propagation research, I decided to continue

On 5/15/21 11:16 AM, Rob Robinett wrote:
Jim, you inspired Phil's site.

On Sat, May 15, 2021 at 7:58 AM Jim Lill <jim@...> wrote:

as a backup, there's always my site jimlill.com:8088

On 5/15/21 10:47 AM, Edward Hammond wrote:

As far as I know, there's really nothing even close to as good as http://wspr.rocks  ... except I suppose wsprd.vk7jj.com.  :-)

It's fantastic, and having a really handsome and functional site like that adds loads of interest, for me at least, in the WSPR hobby. 

My thanks and congratulations to those responsible.

Edward

W3ENR


On 5/15/21 10:30 AM, Rob Robinett wrote:
The bands are fine
My preferred search:  http://wspr.rocks/

On Sat, May 15, 2021 at 6:57 AM John via groups.io <n0ure=yahoo.com@groups.io> wrote:
What are the URLs for WSPR history? Are the bands dead? I have no spots.

John


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


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


Re: URL for Spots history

WA2TP
 

HI John,

 The last spots uploaded I see for you were on 5/10. 

Tom
WA2TP


From: wsprdaemon@groups.io <wsprdaemon@groups.io> on behalf of John via groups.io <n0ure@...>
Sent: Saturday, May 15, 2021 9:57 AM
To: wsprdaemon@groups.io <wsprdaemon@groups.io>
Subject: [wsprdaemon] URL for Spots history
 
What are the URLs for WSPR history? Are the bands dead? I have no spots.

John


Re: URL for Spots history

Edward Hammond
 

And, actually, that is precisely the other site that I use.  :-)   Thank you too!

Edward


On 5/15/21 10:57 AM, Jim Lill wrote:

as a backup, there's always my site jimlill.com:8088

On 5/15/21 10:47 AM, Edward Hammond wrote:

As far as I know, there's really nothing even close to as good as http://wspr.rocks  ... except I suppose wsprd.vk7jj.com.  :-)

It's fantastic, and having a really handsome and functional site like that adds loads of interest, for me at least, in the WSPR hobby. 

My thanks and congratulations to those responsible.

Edward

W3ENR


On 5/15/21 10:30 AM, Rob Robinett wrote:
The bands are fine
My preferred search:  http://wspr.rocks/

On Sat, May 15, 2021 at 6:57 AM John via groups.io <n0ure=yahoo.com@groups.io> wrote:
What are the URLs for WSPR history? Are the bands dead? I have no spots.

John


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


Re: URL for Spots history

Rob Robinett
 

Jim, you inspired Phil's site.

On Sat, May 15, 2021 at 7:58 AM Jim Lill <jim@...> wrote:

as a backup, there's always my site jimlill.com:8088

On 5/15/21 10:47 AM, Edward Hammond wrote:

As far as I know, there's really nothing even close to as good as http://wspr.rocks  ... except I suppose wsprd.vk7jj.com.  :-)

It's fantastic, and having a really handsome and functional site like that adds loads of interest, for me at least, in the WSPR hobby. 

My thanks and congratulations to those responsible.

Edward

W3ENR


On 5/15/21 10:30 AM, Rob Robinett wrote:
The bands are fine
My preferred search:  http://wspr.rocks/

On Sat, May 15, 2021 at 6:57 AM John via groups.io <n0ure=yahoo.com@groups.io> wrote:
What are the URLs for WSPR history? Are the bands dead? I have no spots.

John


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



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


Re: URL for Spots history

Jim Lill
 

as a backup, there's always my site jimlill.com:8088

On 5/15/21 10:47 AM, Edward Hammond wrote:

As far as I know, there's really nothing even close to as good as http://wspr.rocks  ... except I suppose wsprd.vk7jj.com.  :-)

It's fantastic, and having a really handsome and functional site like that adds loads of interest, for me at least, in the WSPR hobby. 

My thanks and congratulations to those responsible.

Edward

W3ENR


On 5/15/21 10:30 AM, Rob Robinett wrote:
The bands are fine
My preferred search:  http://wspr.rocks/

On Sat, May 15, 2021 at 6:57 AM John via groups.io <n0ure=yahoo.com@groups.io> wrote:
What are the URLs for WSPR history? Are the bands dead? I have no spots.

John


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

321 - 340 of 571