Date   

Re: WD 3.0 users of scheduling should 'git pull'

Rob Robinett
 

This morning I made further refinements to WD 3.0.2.6 to address some 'zombie kiwirecorder' issues.
That newest 3.0.2.6 has been running cleanly on about 20 servers for 2-6 hours
So I would strongly encourage the dozen or so WD users who are running 3.0.2.6 to 'git pull' it and restart their WD service.
After startup run 'wd -l e' to watch for error lines.  You may see some or many lines soon after starting it, but after that you should see no error lines reported


Re: Kiwi connections not going away

Chris Mackerell
 

Yep. At least I have:

wsprdaemon      ALL=(ALL:ALL)   NOPASSWD:ALL

in /etc/sudoers. I assume that's what you mean?

I can login as wsprdaemon and do stuff like "sudo reboot"
without getting prompted for a password anyway.


If I shutdown things with "-z" all the strays get killed off
ok, so I thing that is ok. It's just during "normal operations"
that the kiwirecorders aren't getting killed.

Cheers, Chris


On 2022-06-03 16:31, Rob Robinett wrote:
Is your account set up for your user to 'auto-sudo'?

On Thu, Jun 2, 2022 at 9:29 PM Chris Mackerell <chris@...> wrote:
Hi Rob

I'm already on 3.0.2.6

It looks like only the WSPR decoding process is getting killed:

wsprdaemon@wsprdaemon:/tmp/wsprdaemon/recording.d/KIWI_1/10$ more decoding_daemon_kill_handler.log
Fri 03 Jun 2022 03:09:07 PM NZST: decoding_daemon_kill_handler() running in /tmp/wsprdaemon/recording.d/KIWI_1/10 with pid 941 i
s processing SIGTERM to stop decoding on KIWI_1,10
Fri 03 Jun 2022 03:09:07 PM NZST: Successful: 'kill_wav_recording_daemon running as pid 941 for KIWI_1 10 => 0

but there is still a kiwirecorder.py running and writing
.wav files to /tmp/wsprdaemon/recording.d/KIWI_1/10

   5464 ?        S      0:00 sudo nice --adjustment=-40 python3 -u /home/wsprdaemon/wsprdaemon/kiwiclient/kiwirecorder.py --freq=28124.6 --server-host=kiwisdr3.owdjim.gen.nz --server-port=8077 --OV --user=wsprdaemon_v3.0.2.6 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60

Cheers, Chris

On 2022-06-03 16:11, Rob Robinett wrote:
Hi Chris,

Run 'git pull' to get the latest version of 3.0 after which  'wd -V' should print 3.0.2.6.

In beta testing I found that on busy servers the kiwirecord.py process which records the wav files was being interrupted by other programs and as a result there were corrupted wav files.  To address that problem I raised the program priority  of the kiwirecorder jobs, but they have to run as user 'root', so the schedule change must 'sudo kill ...' to them.  With that change those zombie kiwirecorder jobs should be killed.

There is still a lot of log file 'noise' associated with these changes and I am working to clean that up.

73,

Rob



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


Re: Kiwi connections not going away

Rob Robinett
 

Is your account set up for your user to 'auto-sudo'?

On Thu, Jun 2, 2022 at 9:29 PM Chris Mackerell <chris@...> wrote:
Hi Rob

I'm already on 3.0.2.6

It looks like only the WSPR decoding process is getting killed:

wsprdaemon@wsprdaemon:/tmp/wsprdaemon/recording.d/KIWI_1/10$ more decoding_daemon_kill_handler.log
Fri 03 Jun 2022 03:09:07 PM NZST: decoding_daemon_kill_handler() running in /tmp/wsprdaemon/recording.d/KIWI_1/10 with pid 941 i
s processing SIGTERM to stop decoding on KIWI_1,10
Fri 03 Jun 2022 03:09:07 PM NZST: Successful: 'kill_wav_recording_daemon running as pid 941 for KIWI_1 10 => 0

but there is still a kiwirecorder.py running and writing
.wav files to /tmp/wsprdaemon/recording.d/KIWI_1/10

   5464 ?        S      0:00 sudo nice --adjustment=-40 python3 -u /home/wsprdaemon/wsprdaemon/kiwiclient/kiwirecorder.py --freq=28124.6 --server-host=kiwisdr3.owdjim.gen.nz --server-port=8077 --OV --user=wsprdaemon_v3.0.2.6 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60

Cheers, Chris

On 2022-06-03 16:11, Rob Robinett wrote:
Hi Chris,

Run 'git pull' to get the latest version of 3.0 after which  'wd -V' should print 3.0.2.6.

In beta testing I found that on busy servers the kiwirecord.py process which records the wav files was being interrupted by other programs and as a result there were corrupted wav files.  To address that problem I raised the program priority  of the kiwirecorder jobs, but they have to run as user 'root', so the schedule change must 'sudo kill ...' to them.  With that change those zombie kiwirecorder jobs should be killed.

There is still a lot of log file 'noise' associated with these changes and I am working to clean that up.

73,

Rob



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


Re: Kiwi connections not going away

Chris Mackerell
 

Hi Rob

I'm already on 3.0.2.6

It looks like only the WSPR decoding process is getting killed:

wsprdaemon@wsprdaemon:/tmp/wsprdaemon/recording.d/KIWI_1/10$ more decoding_daemon_kill_handler.log
Fri 03 Jun 2022 03:09:07 PM NZST: decoding_daemon_kill_handler() running in /tmp/wsprdaemon/recording.d/KIWI_1/10 with pid 941 i
s processing SIGTERM to stop decoding on KIWI_1,10
Fri 03 Jun 2022 03:09:07 PM NZST: Successful: 'kill_wav_recording_daemon running as pid 941 for KIWI_1 10 => 0

but there is still a kiwirecorder.py running and writing
.wav files to /tmp/wsprdaemon/recording.d/KIWI_1/10

   5464 ?        S      0:00 sudo nice --adjustment=-40 python3 -u /home/wsprdaemon/wsprdaemon/kiwiclient/kiwirecorder.py --freq=28124.6 --server-host=kiwisdr3.owdjim.gen.nz --server-port=8077 --OV --user=wsprdaemon_v3.0.2.6 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60

Cheers, Chris

On 2022-06-03 16:11, Rob Robinett wrote:
Hi Chris,

Run 'git pull' to get the latest version of 3.0 after which  'wd -V' should print 3.0.2.6.

In beta testing I found that on busy servers the kiwirecord.py process which records the wav files was being interrupted by other programs and as a result there were corrupted wav files.  To address that problem I raised the program priority  of the kiwirecorder jobs, but they have to run as user 'root', so the schedule change must 'sudo kill ...' to them.  With that change those zombie kiwirecorder jobs should be killed.

There is still a lot of log file 'noise' associated with these changes and I am working to clean that up.

73,

Rob


WD 3.0 users of scheduling should 'git pull'

Rob Robinett
 

There were scheduling problems in 3.0.2.5 which are corrected in 3.0.2.6


Re: Kiwi connections not going away

Rob Robinett
 

Hi Chris,

Run 'git pull' to get the latest version of 3.0 after which  'wd -V' should print 3.0.2.6.

In beta testing I found that on busy servers the kiwirecord.py process which records the wav files was being interrupted by other programs and as a result there were corrupted wav files.  To address that problem I raised the program priority  of the kiwirecorder jobs, but they have to run as user 'root', so the schedule change must 'sudo kill ...' to them.  With that change those zombie kiwirecorder jobs should be killed.

There is still a lot of log file 'noise' associated with these changes and I am working to clean that up.

73,

Rob


Kiwi connections not going away

Chris Mackerell
 

Hi

I run a sliding schedule of bands that connect to my KiwiSDRs.

The connections to the Kiwis are not going away at the end
of a scheduled timeframe any more. New connections start all right,
but at the end they don't close completely.

"wd -s" doesn't show the jobs, but the Kiwi admin window still
shows connections. If I "kick" them from there they come
straight back up.

If I shut down wd I get lots of meaningless (to me anyway!)
messages about zombies running around the place.

This used to all work fine, but my Kiwis are now filling
up with unwanted connections at the wrong time of day.
I'm not 100% when this started going wrong, but suspect
it was around when v3 was merged into the master branch.

I've been running "wd -l e" but nothing appears there.

Running on Intel-based Ubuntu.

Any ideas?

Cheers, Chris

--
Chris Mackerell, 217 Sandy Bay-Marahau Road, Marahau
RD 2, Motueka 7197, New Zealand chris@...


Re: Sunrise errors

Rob Robinett
 

Hi Bryan,

It appears that your site has a lot of switching power supply RFI.  I find it more helpful to look at the spectrum display, both zoomed in and 0-30 Mhz,  than just the waterfall.  Here is a closeup of a Kiwi at KFS where you can see both picket fence and zigzag RFI.  At KFS I have tracked that down to SWPSUs in a cell phone equipment shed, but at most sites we have see that RFI is introduced by common mode ingress through ground loops between the RF input ground and the Kiwi's DC input ground.  Such RFI can also be introduced through imbalances in the antenna system. 

 If the antenna is balanced (e.g. dipole or loop), then a good starting test is to short the antenna connection terminals.  If the RFI doesn't go down by 10-20 dB, then the noise is not being sourced by then antenna but rather by the feedline and/or other components of the RF distribution system. Of course such a test isn't meaningful for unbalanced antennas.

Systems with LNAs at the antenna which are fed DC by a bias-t are especially vulnerable to ground loop induced RFI, since the ground of the bias-t power supply is connected to the RF input ground and thus forms a loop from there to the ground of the Kiwi's DC power supply.  In such a case feeding the bias-t with a battery will show if that biat-s DC power supply is a RFI source.

We have been supporting a Kiwi installation at VY0ERC up at Ellesmere Island at 82 north where RFI from the current antenna system renders it almost deaf.  Fixing such problems remotely is a real challenge.

Rob

Screen Shot 2022-06-02 at 10.22.58 AM.png
 

On Thu, Jun 2, 2022 at 9:58 AM Bryan Klofas <bklofas@...> wrote:
Hey Rob and Gwyn--

Yes, I'm trying to put a site in Inuvik, Canada. Everything is
installed, but the noise floor at this WISP site is absolutely
horrendous, see attached pic, so I'm not sure if this is going to work
or not. Spinning the loop around doesn't help.

I'll see if I can just rip out the sunrise/sunset stuff, I don't need
any complex scheduling at all, just turn it on a let it run 24/7.

Thanks, have a great afternoon!
--
Bryan Klofas

On 6/2/22 07:23, Rob Robinett wrote:
> I think that the only rx site which may encounter this is VY0ERC which
> is currently offline.  Since this astral problem is encountered only by
> WD users with sunrise/sunset schedules and there is only one site which
> could encounter the problem, I think this is a low priority issue.
>
> As a reminder:   In WD 3.0 sunrise/sunset times are in the timezone of
> the WD server
> Look at the file "hhmm.sched" to see how WD has translated
> the WSPR_SCHEDULE in the conf file to a HH:MM schedule.
> The file "suntimes" contains the sunrise/sunset times calculated by the
> astral library
>
>
>
> On Wed, Jun 1, 2022 at 11:43 PM Gwyn Griffiths via groups.io
> <http://groups.io> <gxgriffiths=virginmedia.com@groups.io
> <mailto:virginmedia.com@groups.io>> wrote:
>
>     Bryan
>
>     This is a known problem with the python astral library for locations
>     with near to and higher latitudes than the Arctic and Antarctic
>     Circles depending on time of year when the sun does not set or does
>     not rise.
>     The set location in your example is in the north of Canada's
>     Northwest territories - was that your intention?
>     If truly so, then Rob, we should discuss options, e.g. wrapping the
>     astral program within one that has to check for applicable time of
>     year and latitude before passing to astral.
>
>     regards
>     Gwyn G3ZIL
>
>
>
> --
> Rob Robinett
> AI6VN
> rob@... <mailto:rob@...>
> mobile: +1 650 218 8896
>







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


Re: Sunrise errors

Bryan Klofas
 

Hey Rob and Gwyn--

Yes, I'm trying to put a site in Inuvik, Canada. Everything is installed, but the noise floor at this WISP site is absolutely horrendous, see attached pic, so I'm not sure if this is going to work or not. Spinning the loop around doesn't help.

I'll see if I can just rip out the sunrise/sunset stuff, I don't need any complex scheduling at all, just turn it on a let it run 24/7.

Thanks, have a great afternoon!
--
Bryan Klofas

On 6/2/22 07:23, Rob Robinett wrote:
I think that the only rx site which may encounter this is VY0ERC which is currently offline.  Since this astral problem is encountered only by WD users with sunrise/sunset schedules and there is only one site which could encounter the problem, I think this is a low priority issue.
As a reminder:   In WD 3.0 sunrise/sunset times are in the timezone of the WD server
Look at the file "hhmm.sched" to see how WD has translated the WSPR_SCHEDULE in the conf file to a HH:MM schedule.
The file "suntimes" contains the sunrise/sunset times calculated by the astral library
On Wed, Jun 1, 2022 at 11:43 PM Gwyn Griffiths via groups.io <http://groups.io> <gxgriffiths@... <mailto:virginmedia.com@groups.io>> wrote:
Bryan
This is a known problem with the python astral library for locations
with near to and higher latitudes than the Arctic and Antarctic
Circles depending on time of year when the sun does not set or does
not rise.
The set location in your example is in the north of Canada's
Northwest territories - was that your intention?
If truly so, then Rob, we should discuss options, e.g. wrapping the
astral program within one that has to check for applicable time of
year and latitude before passing to astral.
regards
Gwyn G3ZIL
--
Rob Robinett
AI6VN
rob@... <mailto:rob@...>
mobile: +1 650 218 8896


Re: Sunrise errors

Rob Robinett
 

I think that the only rx site which may encounter this is VY0ERC which is currently offline.  Since this astral problem is encountered only by WD users with sunrise/sunset schedules and there is only one site which could encounter the problem, I think this is a low priority issue.

As a reminder:   In WD 3.0 sunrise/sunset times are in the timezone of the WD server
Look at the file "hhmm.sched" to see how WD has translated the WSPR_SCHEDULE in the conf file to a HH:MM schedule.
The file "suntimes" contains the sunrise/sunset times calculated by the astral library



On Wed, Jun 1, 2022 at 11:43 PM Gwyn Griffiths via groups.io <gxgriffiths=virginmedia.com@groups.io> wrote:
Bryan

This is a known problem with the python astral library for locations with near to and higher latitudes than the Arctic and Antarctic Circles depending on time of year when the sun does not set or does not rise.
The set location in your example is in the north of Canada's Northwest territories - was that your intention?
If truly so, then Rob, we should discuss options, e.g. wrapping the astral program within one that has to check for applicable time of year and latitude before passing to astral.

regards
Gwyn G3ZIL



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


Re: Sunrise errors

Gwyn Griffiths
 

Bryan

This is a known problem with the python astral library for locations with near to and higher latitudes than the Arctic and Antarctic Circles depending on time of year when the sun does not set or does not rise.
The set location in your example is in the north of Canada's Northwest territories - was that your intention?
If truly so, then Rob, we should discuss options, e.g. wrapping the astral program within one that has to check for applicable time of year and latitude before passing to astral.

regards
Gwyn G3ZIL


Sunrise errors

Bryan Klofas
 

Hey Rob--

Corner case: The sun is always up or down. From watchdog_daemon.log:

Thu 02 Jun 2022 05:05:01 UTC: watchdog_daemon() Starting in /home/wsprdaemon/wsprdaemon as pid 21929
Thu 02 Jun 2022 05:05:01 UTC: watchdog_daemon() Starting odd minute, do all watching functions
Spawned new upload_to_wsprnet_daemon job with PID '22163' and recorded that pid to '/home/wsprdaemon/wsprdaemon/uploads.d/wsprnet.d/spots.d/upload_to_wsprnet_daemon.pid' == 22163
Spawned new upload_to_wsprdaemon_daemon job with PID '22171' and recorded that pid to '/home/wsprdaemon/wsprdaemon/uploads.d/wsprdaemon.d/upload_to_wsprdaemon_daemon.pid' == 22171
Thu 02 Jun 2022 05:05:01 UTC: get_sunrise_sunset() Get sunrise/sunset for Maidenhead CP38di at long/lat -134 68
Thu 02 Jun 2022 05:05:03 UTC: get_astral_sun_times() ERROR: 'python3 /home/wsprdaemon/wsprdaemon/suntimes_astral2-2.py 68 -134 Etc/UTC' => 1

This is with the latest 3.0.2.5. Thoughts? Thanks!
--
Bryan Klofas


Re: External USB Stick/Disk

Rob Robinett
 

WD stores all of its temporary files in the ram disk /tmp/wsprdaemon.  Only important files which you wouldn't want to be lost in an unexpected power off event (like the cache of spots waiting to uploaded) are stored on the microSD
Storing on an external USB drive would be slow, so much so that configurations with many channels might not run and would in any case soon wear out a flash drive.


External USB Stick/Disk

whartmuth@...
 

A Raspberry Pi runs from SD-Card. so It might be a good idea when /tmp/wsprdaemon is not on the same SD-Card.
Is there an easy way to convince wsprdaemon to use an external USB-Stick or disk to store the files?

I am using a Raspberry Pi 4 with 4Gb memory and bullseye.

Thank you, vy73
Wolfgang, DG2MDJ


Re: performance wsprdaemon on a RPI3

Bryan Klofas
 

Hey Rob--

Thanks for the tips on decreasing the "-o" flag if I run out of cycles. My current KF6ZEO spotting station is actually running on a Ubuntu 20.04 VM with 2 threads of a i3-5010U, so it's got enough horsepower. I'm building up a Pi for a remote site.

It might be helpful to add a bit more error logging if kiwirecorder can't access the SDR.

For instance, I just stopped wsprdaemon, git pull, started, and viewed the error logs. Nothing showed up using "-l e", but no spots were being uploaded.

It turns out that as soon as I stopped wsprdaemon, the KiwiSDR started to update itself, with no incoming connections allowed. Judging by htop, it appears that kiwirecorder is crashlooping. Running kiwirecorder by hand results in:

kiwi.client.KiwiDownError: 192.168.1.82: server is down atm

However, the recovery worked well. As soon as the server came back up, kiwirecorder stopped crashing and wsprdaemon started uploading spots. So maybe I'm getting a bit too into the weeds here.

Thanks for continuing to work on wsprdaemon, have a great weekend!
--
Bryan Klofas KF6ZEO

On 5/26/22 18:32, Rob Robinett wrote:
Hi Bryan,
I see from http://wspr.rocks/livequeries/ <http://wspr.rocks/livequeries/> that you are still running 3.0.2.3. You would benefit from updating your WD by running:
git pull
wd -z
wd -a
I have just installed Wd 3.0.2 at many of the top sites and have found how to use some of its features to ensure there is no CPU overloading on the WD server.  Logging is much improved in WD 3.0, so wsprd timeouts and other errors which were silently handled (tom some extent) by WD 2.10 are now much more visible.  To see log lines with ERROR execute:
wd -l e    (show Log errors)
You can ignore the "ERROR: only x o y spots accepted by wsprnet.org" lines, but any other error lines should be investigated.
If you see "ERROR: timeout..." lines, then you are running out of CPU cycles and you should try adding this line to your conf file:
WSPRD_CMD_FLAGS="-C 500 -o 3 -d"
At one especially challenged site I had to go down from the default '-o 4' to:
WSPRD_CMD_FLAGS="-C 500 -o 2 -d"
Even '-o 2' didn't seem to affect the number of decoded spots, so users with Pi 3bs may be able to scan 14+ bands.


Re: Memory leak (Bullseye)

Rob Robinett
 

The memory leak is in the Bash version 5.1.4 included in bullseye.  Gwyn has compiled Bash 5.1.16 on his bullseye Pi 3b and that fixes the problem.  I have no insight into if/when they will update the Bash is bullseye.

I switched my Pi4 to the 64 bit Ubuntu for the Pi which includes Bash 5.1.16 and it runs with no leak.  That version of Ubuntu is offered as an option in the 'Raspberry Pi Imager' which I run on my Mac to load microSD cards.  Burning the card and then setting it up in the Pi took me about 15 minutes, but I do have a lot of experience with that process.

Rob

On Fri, May 27, 2022 at 7:01 AM John <johnk5mo@...> wrote:
Rob mentions:

in your case the much bigger problem is a memory leak in the Bash 5.1.4 included in bullseye.  Gwyn G3ZIL identified that problem which leads the Pi to run out of memory in 1-5 days.

I now see this too, in my Pi4 install of 3.0.2 .  It's running great otherwise.  ("other than that, how did you like the play Mrs Lincoln?").   Do I understand this is an issue with Bash?

While I can restart my system every 5 days or so, does anyone know if this is likely to be fixed in a new release of Bash, or is it associated only with the combination of Bash and WD?

Thanks. It's probably a dumb question, but I'd rather wait and update Bash than build a new system.

John K5MO



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


Memory leak (Bullseye)

John K5MO
 

Rob mentions:

in your case the much bigger problem is a memory leak in the Bash 5.1.4 included in bullseye.  Gwyn G3ZIL identified that problem which leads the Pi to run out of memory in 1-5 days.

I now see this too, in my Pi4 install of 3.0.2 .  It's running great otherwise.  ("other than that, how did you like the play Mrs Lincoln?").   Do I understand this is an issue with Bash?

While I can restart my system every 5 days or so, does anyone know if this is likely to be fixed in a new release of Bash, or is it associated only with the combination of Bash and WD?

Thanks. It's probably a dumb question, but I'd rather wait and update Bash than build a new system.

John K5MO


Re: wsprdaemon with SDRplay devices on Raspberry Pi 4

Bruce KX4AZ
 

On Thu, May 26, 2022 at 11:20 PM, Rob Robinett wrote:
... I have ordered one of those clones from ebay if only to compare it against my RP2.
...The big issue with using any of those SDRs for VHF/UHF WSPR is calibrating its frequency settings
Thanks Rob, looking forward to hearing how well it works.  I ordered one as well from Aliexpress - the one with five SMA filter inputs.  The main difference versus the single input with the DIP switches is bandwidth claimed (2 GHz versus 1 GHz for the 5 inputs).  Presumably all of those 5 SMA inputs add enough extra capacitance to roll things off at a lower frequency.  They claim there is a 0.5 ppm TXCO on board so perhaps after calibrating against a GPSDO the accuracy will be good enough for VHF/UHF WSPR.  Unless you can swamp out the TXCO by feeding it a stronger external clock, perhaps.  In any event, even given the outdated RSP1 design, it would be a significant upgrade from the RTL-SDR direct mode for HF, with those extra bits as well as the lack of aliasing for the >14.4 MHz region, not to mention the much wider bandwidth, and similar cost. 


Re: wsprdaemon with SDRplay devices on Raspberry Pi 4

Erwin - PE3ES - F4VTQ
 

First of all these are clones of the way outdated version RSP1, not the later RSP1a. And also the "designer" tells it is a simplified design.
So I would not be to hopeful on performance.
If it will work with the needed latest official SDRplay API versions needs to be seen as well.

Well, one can always hope.

Cheers


Re: wsprdaemon with SDRplay devices on Raspberry Pi 4

Rob Robinett
 

Perhaps  I could tune the RP1/2 to a carrier generated by a GPSDO on the bench next to the RP and then use the measured tuning error to adjust the WSPR tuning frequency.  That isn't nearly as good as driving the clock of the RP1/2, but no soldering required ;=)

On Thu, May 26, 2022 at 8:46 PM Glenn Elmore <n6gn@...> wrote:
Unfortunately upon surveying  > 30 OTA HDTV broadcasts here on Colorado
's Front Range with my GPSDO referenced 0-2 GHz Frequency Extender,
hearing HDTV ATSC pilot carriers from well South of Denver up to the
Wyoming border, I find almost *NONE* of them on the 'correct' ATSC spot.
They are generally within 1 kHz (FCC spec?) but they deliberately offset
in order to avoid QRMing each other. Unless you can get the
engineer-in-charge to tell you what their exact offset is (if they know
it) I don't think these signals are nearly as useful as first hoped.

So much for using ATSC for the truly accurate frequency information it
might otherwise provide. It's slated to disappear anyway...

On 5/26/22 21:20, Rob Robinett wrote:
> That RP clone doesn't appear to have an external clock input option,
> so I can use the "calibrate against a local ATSC pilot carrier' if
> those can be trusted.







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

761 - 780 of 1662