WD 3.0.3 is now available and is the preferred and stable release
|
Rob Robinett
This morning I changed the version number of WD 3.0.2.6 to WD 3.0.3 and checked it in as the 'master' version.
WD 3.0.2.6 had been running on 32 beta sites, and now the 21 sites to which I have remote access are running 3.0.3. I encourage the 11 sites still running 3.0.2.x to upgrade to 3.0.3. There are also 20 sites running WD 2.x and I also encourage them to upgrade to 3.0.3. If you have problems with an upgrade, 3.0 includes a configurable Remote Access feature which when enabled allows me to access your WD server without the need for you to make any modifications to your Wifi router or other Internet access equipment. In addition to many, many bug fixes, WD 3.0 supports decoding of the FST4W transmission modes introduced in WSJT-x 2.3.0. With 3.0 released, I will turn my software development efforts towards adding support for other SDRs like the RedPitaya, SDRPlay and AIRSpy. |
|
|
|
Edward (W3ENR / K3WRG)
This is great. Thank you Rob.
So what are opinions on what a reasonable selection of FST4W decoding to use at this point? I have started with: 2200 - W2:F2:F5:F15:F30 630 - W2:F2:F5:F15 160 - W2:F2:F5 80 - W2:F2:F5 Other bands are default. Opinions? Edward W3ENR (listening) / K3WRG (beacon) |
|
|
|
Rob Robinett
I am running an experiment with WB6YRW who has been sending FST4W-1800 on 160M. Decoding of FST4W is much more efficient than WSPR, so Unless you are running WD On a Pi, I think you can try decoding all modes and encourage beacon stations to try all modes to see what works. There have been so few FST4W rx stations that there has been very little use of that mode. Now with 30+ WD rx sites listening for all the FST4W modes, hopefully tx stations will be encouraged to use it and we will see some new propagation paths reported. On Tue, Jun 14, 2022 at 1:09 PM Edward Hammond <manager@...> wrote: This is great. Thank you Rob. --
|
|
|
|
Alrighty, I'll do it all on 80m and below. I hope to hear somebody soon! |
|
|
|
Rob Robinett
Edit the fstab file as you did last time Then stop WD Then sudo umount /tmp/wsprdaemon Then sudo mount /tmp/wsprdaemon Then start WD On Tue, Jun 14, 2022 at 2:01 PM Edward Hammond <manager@...> wrote:
--
|
|
|
|
Edward (W3ENR / K3WRG)
Great. Thank you. Got one: N3AGE on 630m, SNR recorded at -39 (!).
 |
|
|
|
On Mon, Jun 13, 2022 at 06:00 PM, Rob Robinett wrote:
With 3.0 released, I will turn my software development efforts towards adding support for other SDRs like the RedPitaya, SDRPlay and AIRSpy.Rob, that is excellent news, I was just curious if that means for an SDRPlay device with an 8 MHz bandwidth, would this enable multi-band decoding? And would it connect directly to the SDR via a USB port on the same system? 73, Bruce |
|
|
|
Jim Lill
My experience with the larger BW SDR connected via USB is that
they consume a lot of CPU. On 6/19/22 07:05, Bruce KX4AZ wrote:
On Mon, Jun 13, 2022 at 06:00 PM, Rob Robinett wrote: |
|
|
|
Rob Robinett
At KFS and Maui we have WebSDR systems with 8 SDRPlays attached to them and can use them to cover all of the HF bands. However it is my understanding that the SDPPlay's performance is seriously degraded if it is used to obtain a 4 MHz or greater bandwidth. I do have completely untested support for directly attached SDRPlays in the WD 3.0 SW. One of my first tasks when I start work on WD 3.1 in the next few weeks is to test that SDRPlay support. But the SDRPlay and many other similar dongles depend upon the host CPU to demodulate the raw IQ stream. A single SDRPaly consumed about 10% of a Pi4b while a Kiwi channel consumes only 2.5% So there will be tradeoffs, especially since a SDRPlay Costs $150 per band and a Kiwi with equivalent performance costs less than $40/band. For me the SDPlay's value is that it works on the VHF and UHF bands, Rob On Sun, Jun 19, 2022 at 4:52 AM Jim Lill <jim@...> wrote:
--
|
|
|