|
Ok Marcus
I had heard , there was no connection to
the Ae , it was just carrier leakage
'judge' : )
In the latest version 1-5-6 , Jose has
added a tech note as to the processing
time .
Note Deep search spots have a delay about 2-5 minutes in
Op32.
This delay is used by the algorithm to eliminate possible false
spots,
and enable reach a realistic 5 dB extra
sensivity
The chances of a simultaneous event are
1/minimal !, dcf39 is not very strong at
this location , probably not too high in SV either
,
One point that is missed , the detection
system is facilitated by the signal purity ,
during testing , the same equipment was used
, but once on general release , then various
systems and combinations , produced differing results
any one who is set up for your opds
system could see shorter processing times ,
simply due to reductions in the decision process
Up to now , false spots seem to be
minimal ?, the 2 for 1 check is not
showing very often , other than the JA test
that seems to be low power ? , giving
a single detection/opera decode
73-G,
Sent: Saturday, January 10, 2015 11:18 AM
Subject: Re: LF: MF OPERA BAD
Hi Graham,
as far as I know, Stefan's RF power is actually
lower than that of many other LF stations, eg. those
running ex-Decca modules. But maybe he does have a more efficient antenna
than most ;-)
I have indeed been wondering about those two
simultaneous WD2XNS deep-search detections the other night. The statistical
probability of simultaneous false positives would indeed be very low if were
only due to noise. The problem is however that falses rarely pop out of the
pure noise but are often triggered by real or spurious signals,
eg. other intended transmissions or interference (like DCF39
crossmodulation). These may be in common view of several receivers. If
the waveform of any of such signals happens to bear similarity to one
of the sequences in the search list, they are likely to pop up as
false correlations.
Having an accurate frequency readout would
help to diagnose the source of the problem. For example, I got a number of reproducable opds
falses for R7NT, which turned out to be reproducably
triggered by one PA station who transmittied WSPR-15 sequences at
these times. The pattern on one of the WSPR frequencies code just happened
to bear similarity to R7NT's Opera sequence. This one was relatively easy
to sort out from to the out-of-band frequency and the quarter-hour timing.
Here's the excerpt from https://dl.dropboxusercontent.com/u/26404526/opds32_archive.txt :
2014-01-26 11:00:39 R7NT 2060km
137602.968Hz 3mHz -42.2dBOp 94% 15.2dB ?
2014-01-26 09:00:39 R7NT 2060km
137602.969Hz 2mHz -42.3dBOp 63% 15.1dB ?
...
2014-01-25 06:15:39 R7NT 2060km
137602.969Hz 3mHz -41.9dBOp 79% 15.4dB ?
2014-01-25
05:45:39 R7NT 2060km 137602.969Hz 4mHz
-45.6dBOp 79% 15.2dB ?
...
2014-01-24 13:30:38 R7NT 2060km
137602.968Hz 3mHz -44.3dBOp 64% 15.7dB ?
2014-01-24
09:00:42 R7NT 2060km 137602.968Hz 2mHz
-45.6dBOp 95% 15.0dB ?
...
2013-09-11 21:30:43 R7NT 2060km
137604.888Hz 10mHz -42.2dBOp 91% 15.0dB ?
Sent: Saturday, January 10, 2015 1:43 AM
Subject: Re: LF: MF OPERA BAD
Yes the quality check is performed
by the web linked server .. as is the
dynamic call list . unique decoded
calls are not added to the list
. only if 2 from independent stations
...or If using opera to Tx , then the
web beacon is directly added
So your local decode will only show
as to what your right/wrongly detected
, for dynamic false detections will all ways
be a valid call , but the system
automatically validates it , and will
show in the web-linked spots
The probability of TWO spontaneous
detections occurring at or close to
the same time are quite astronomic ,
possibly larger than Stefan's RF power on 136 ?
73-G,
...
| 