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
unfiltered bad decodes cause erroneous outliers, e.g. open path plots,
that will easily mislead naive users trying to interpret result data.
Yes, I agree that bad decodes have annoying consequences - but as you said,
many of them can be taken care of by better validation of the decoded callsign
and grid.
I don’t think that time is a factor --- the decoder is quite fast now and even
the smallest computers should have no trouble keeping up with a single instance
of wspr. My observation, based on a small set of tests, is that the bias
setting has a negligible impact on the running time. Changing the maximum cycle
count would have a much more direct impact on running time.
My preference is to skootch the bias down a bit to make the decoder more
agressive so that I get to see the 20 or so extra spots per hour that I
wouldn’t have seen otherwise. I’m willing to have to recognize and discard one
or two bad spots in order to maximize the probability of seeing that exciting
long-path, or TEP, or double hop Es or (fill in the blank) spot.
Agreed, and validation using callsign vs grid would seem to be the best
option overall.
Please let me know if you think that I’ve set the default bias too far on the
aggressive side. For the record, setting it to something like 0.48 should make
the performance roughly the same as what we had before. Setting it to 0.5 makes
it slightly more conservative than what we had before.
On a separate matter, I've measured the frequency of the transmitted WSPR
signals using a separate receiver and this latest decoder. The transmitted
signal measures 0.2-0.3 Hz high (the decoder has 0.1 Hz resolution), as
expected, given the 1 Hz resolution of the Modulator. Is this something that
would be easy to change? I have to admit that it bothers me to be transmitting
0.1973 Hz off frequency!
I don't see any reason why the base audio frequency should not be passed
to the modulator as a floating point number, it is converted to floating
point before use anyway. Until now due to the DF controls for other
modes being an integral number referenced to the lowest tone this has
not been an issue.
Attached is a small patch you can try that should centre the WSPR
transmitted signal on the requested frequency.
73 Steve k9an
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 Modulator::start (unsigned symbolsLength, double framesPerSymbol,
- unsigned frequency, double toneSpacing,
+ double frequency, double toneSpacing,
SoundOutput * stream, Channel channel,
bool synchronize, double dBSNR)
{
diff --git a/Modulator.hpp b/Modulator.hpp
index 630d33e..3c77f2c 100644
--- a/Modulator.hpp
+++ b/Modulator.hpp
@@ -32,10 +32,10 @@ public:
void setSpread(double s) {m_fSpread=s;}
void setPeriod(unsigned p) {m_period=p;}
- Q_SLOT void start (unsigned symbolsLength, double framesPerSymbol, unsigned
frequency, double toneSpacing, SoundOutput *, Channel = Mono, bool synchronize
= true, double dBSNR = 99.);
+ Q_SLOT void start (unsigned symbolsLength, double framesPerSymbol, double
frequency, double toneSpacing, SoundOutput *, Channel = Mono, bool synchronize
= true, double dBSNR = 99.);
Q_SLOT void stop (bool quick = false);
Q_SLOT void tune (bool newState = true);
- Q_SLOT void setFrequency (unsigned newFrequency) {m_frequency =
newFrequency;}
+ Q_SLOT void setFrequency (double newFrequency) {m_frequency = newFrequency;}
Q_SIGNAL void stateChanged (ModulatorState) const;
protected:
diff --git a/mainwindow.cpp b/mainwindow.cpp
index 5bdda3d..65a61c6 100644
--- a/mainwindow.cpp
+++ b/mainwindow.cpp
@@ -3696,7 +3696,7 @@ void MainWindow::transmit (double snr)
if (m_mode=="WSPR-2") { //### Similar
code needed for WSPR-15 ###
Q_EMIT sendMessage (NUM_WSPR_SYMBOLS, 8192.0,
- ui->TxFreqSpinBox->value()-2, m_toneSpacing,
+ ui->TxFreqSpinBox->value() - 1.5 * 12000 / 8192,
m_toneSpacing,
&m_soundOutput, m_config.audio_output_channel(),
true, snr);
}
diff --git a/mainwindow.h b/mainwindow.h
index 2358415..8dea8c2 100644
--- a/mainwindow.h
+++ b/mainwindow.h
@@ -246,11 +246,11 @@ private:
Q_SIGNAL void startDetector (AudioDevice::Channel) const;
Q_SIGNAL void detectorClose () const;
Q_SIGNAL void finished () const;
- Q_SIGNAL void transmitFrequency (unsigned) const;
+ Q_SIGNAL void transmitFrequency (double) const;
Q_SIGNAL void endTransmitMessage (bool quick = false) const;
Q_SIGNAL void tune (bool = true) const;
Q_SIGNAL void sendMessage (unsigned symbolsLength, double framesPerSymbol,
- unsigned frequency, double toneSpacing,
+ double frequency, double toneSpacing,
SoundOutput *, AudioDevice::Channel = AudioDevice::Mono,
bool synchronize = true, double dBSNR = 99.) const;
Q_SIGNAL void outAttenuationChanged (qreal) const;
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
