more wave radar stuff.... CODAR like? On 4/21/22 10:51, ON5KQ wrote:

I could not see the problem at kph today, but instead there was a similar signal about 20db weaker that yesterday observed at kfs at local morning time: Obviously a 'real' signal, perhaps related to

Question: is it "normal", that currently there is no noise data shown at wspr.live for spotters running wsprdaemon v3.0 ? I cannot see any errors here at the client side running the new V 3.0a and

ignore my last.... too early here and didn't read all the received messages thoroughly! On 4/20/22 20:47, Bruce KX4AZ wrote:

Can you receive yourself on a 2nd radio with wsjt-x and see if it decodes your ZackTech correctly? On 4/20/22 20:47, Bruce KX4AZ wrote:

Hi Rob, good morning from Belgium! I just upgraded from Vers 2.10l to version 3.0a A new wsprd version was uploaded and installed on the Rpi This new wsprd version is now running the wsprd process

I know of no reason why your wsprd would be terminated at 60 seconds. To debug it I would need to log on to your Pi. I am so deep into testing WD 3.0 that it would be much easier to debug your problem

There is the known issue, that when the wsprd decoding program starts to decode the recorded Wav-file from wsprdaemon program it should finish it decoding after max 110sec. That is because the total

This afternoon I switched to using 'N1D/4' for the call sign, which is working OK., the '4' symbolizing the US call region 4. Wasn't my first choice since it requires 2 cycles for a complete "spot",

Wsprdaemon takes the spots added to ALL_WSPR.TXT by running the WSPR binary taken from the WDJT-x distribution. WD then removes only spots with the tx call sign “<…>” from that list and uploads

Hi Bruce, One work around may be to use N1D/1 Recently, I added a filter to only upload reports with more than 42 characters. I did so while chasing a bug in my own software. The filter solved my

this data from wspr rocks shows that decoders other than just kiwi are doing the job. N1D is also in the data I download from the database at wsprdaemon.org for http://www.jimlill.com:8088

your spots from today are not in the daily wsprnet database that shows decoder type yet. On 4/19/22 11:39, Jim Lill wrote:

the kiwi extension uses the wsprd decoder albeit an earlier version IIRC. wsprdaemon uses wsprd also. Let me look at some raw data. On 4/19/22 11:04, Bruce KX4AZ wrote:

On Tue, Apr 19, 2022 at 10:53 AM, Jim Lill wrote: A quick look at all the active TX stations shows no other 3-char TX stations. I wonder if you'd be legal using N_1_D and if that would fix the

A quick look at all the active TX stations shows no other 3-char TX stations. I wonder if you'd be legal using N_1_D and if that would fix the problem? On 4/19/22 09:30, Bruce

I am (attempting) to run a special event WSPR beacon with "N1D" for the call sign. So far the only spots I see are for Kiwi 1.3 decoders...so I suspect that using a 3 letter call sign is not

Relative to Phil's comments... same commands and wav file used for all. SNR was modest for those sigs decoded On 4/12/22 12:23, Jim Lill wrote:

I wrote the Fano decoder in wsprd. The Fano decoder is one of a family of 'sequential' decoding algorithms where decoding time increases as SNR decreases. More specifically, it is a Pareto-distributed

Here are some results, timed to the nearest second: XU4 5 secs 10W needs fan for 26 channels, max reliable channel count Atomic Pi 3 secs 15W no fan channel count TBD Intel©