+19dB

This morning, it was possible to deploy, for a brief period around peak long-path time (07:40UT), a 1/4 wave vertical at a local (and deserted) beach site.

I have not had time to perfect a receiver for beach use as yet.  It's easy to do, but it requires a computer that is separate from normal shack operations, in order to avoid software problems than inevitably occur when settings and hardware are changed.

Early morning Long Path operations from the beach, but there were computing problems...

So, I risked using my shack laptop, running on internal power and coupled to a SDRPlay RSP1a.

This worked OK, but there were two main problems:

(1) Not all timeslots were decoded.  This isn't a clock issue, but something to do with power management by the laptop, it seems.  It doesn't happen on a desktop PC, and it's not obviously easy to resolve (maybe you have ideas?)

(2) The laptop wasn't uploading spots to the database. At the time, I thought I had lost all the decodes.  Then I remembered the file ALL.TXT stores everything!

At 07:40UT came a staggering +19dB from VK3MO.  My delta at home recorded only +0dB - a power factor of 80 times weaker!

To put this into context, ZL2BCI was only receiving at +11dB - and he is only 2600km away from Ian's huge Yagi arrays pointing in his general direction!  In Europe, nobody was hearing better than my delta's +0db in that 07:40UT timeslot.

As well as very dramatically showing the benefits of seawater operation, this result, single though it is, does hint that, unless we can see ultra-low radiation angles, we will miss a lot of the detail of what is going on with any particular signal.

I now have three options:

(1) Grab the car's dedicated Raspberry Pi, and also remove the TS480 transceiver from the car, to replace the use of a SDR.  Why?  Because, unlike my much more expensive laptop, the Pi never misses a decode cycle - ever.  It also means I won't have to run resource-hungry SDR software for receiving whilst on battery, as the transceiver does all the signal handling in analogue mode.  The only downside is the need for a smallish 12V battery to power the transceiver.

(2) Build a new Raspberry Pi system (I already have a Pi 4 delivered), and hope that when I run SDRPlay's Pi image on it, there will be no resource issues and decode misses.  This is the best solution if I can make it work, as the power requirements are easier to handle, and the (cheaper) computer easier to protect in the field.

(3) Try the laptop and RSP1a combination again and just record everything on the disk for later decoding or simply uploading the time slots that aren't missed.  I guess this is the option that will get me straight back on the beach for some 'daily exercise' by next week (WSPR tends to suffer QRM during weekends).

If you have any other options, or solutions to some of the problems, please drop me a comment!