Bill, your patch is fine. I think that this remaining frequency error is due to
the transmit soundcard. I had forgotten that I compensated for it in my old
setup by applying the offset to the tone frequencies in the .wav file that I
used to transmit my signal. It is apparently somewhat less than
Bill - Thanks! I applied the update only, not the first one. It definitely
helped - my requested frequency is 170 above the bottom of the segment. Before
the patch I was measuring 170.2 and 170.3. After the patch, I’m seeing 170.1.
With my old setup I always got 170.0 (all radios are referenced
Hi Steve,
A minor update to the suggested patch is attached.
73
Bill
G4WJS.
diff --git a/Modulator.cpp b/Modulator.cpp
index dce905b..e4918d7 100644
--- a/Modulator.cpp
+++ b/Modulator.cpp
@@ -43,7 +43,7 @@ Modulator::Modulator (unsigned frameRate, unsigned
periodLengthInSeconds,
}
void Mod
On 24/05/2015 01:53, Steven Franke wrote:
Hi Bill,
Hi Steve,
Thanks for the comments!
IMHO any setting that increases the number of bad decodes is not worth
the time saved unless that time is in danger of being longer than the
available time before the next decode cycle. I say this because
un
Hi Bill,
Thanks for the comments!
> IMHO any setting that increases the number of bad decodes is not worth
> the time saved unless that time is in danger of being longer than the
> available time before the next decode cycle. I say this because
> unfiltered bad decodes cause erroneous outliers
On 24/05/2015 00:03, Steven Franke wrote:
> Hi Joe et al,
Hi Steve,
...
> Here’s a summary of some comparisons between old and new:
>
> 100 test files with -30 dB SNR:
> old “new” wsprd: 66 successful decodes in 30 seconds
> new “new” wsprd: 75 decodes, 2 bad decodes (73 successful decodes) in 26
