Date
1 - 13 of 13
wsprd -C nnnn
|
Jim Lill
I vaguely recall Phil, KA9Q, commenting on the effects of higher values. 500 is the default, I know some are running 10000. Do the odds of false decodes increase with those highers values?
73 Jim WA2ZKD |
|
|
|
Rob Robinett
Since I have 24 Xeon cores at KFS, I have been running -C1000 -o 4 there for weeks with no noticeable increase in false decodes. On Sat, Aug 6, 2022 at 6:12 AM Jim Lill <jim@...> wrote:
--
|
|
|
|
Jim Lill
I am running 5000 and not seeing false stuff that I notice
On 8/6/22 09:47, Rob Robinett wrote:
|
|
|
|
I have changed all mine to C5000 -o 4 and seem to get less errors. On 160 I saw 0 out of 17 and 2TP had 4 out of 15, on MF I had 1 out of 5, 2TP had 3 out of 6. I am going to reduce to C1000 Steve On 8/6/22 14:07, Jim Lill wrote:
|
|
|
|
WA2TP - Tom
I see many false decodes at 10000.
However, does that outweigh the benefit of the number of legitimate deeper decodes?
I think this would be very difficult to validate. As such, having plenty of available cpu, I will leave it at 10000.
KB9AMG monitors “uniques” and to an extent provides some reporting and date on spots that are of question.
Mark also assigns -# alongside the callsign after those spots in question are determined to be invalid to some extent.
On Aug 6, 2022, at 10:23 AM, KD2OM <steve@...> wrote:
|
|
|
|
Gwyn Griffiths
In case an overview of how many decode cycles are actually used might be of interest I've put a histogram Dashboard
(pre-loaded for Tom) http://logs1.wsprdaemon.org:3000/d/lxQIj3zVz/decode-cycles-histogram-ch?orgId=1&from=now-24h&to=now&var-rx_id=WA2TP&var-band_m=20&var-receiver=KIWI_7 log in with usual credentials wdread and JTWSPR2008 Enter your own rx_id and band top left and it'll populate the receiver pull down with the receivers you have active on that band during the time interval set top right. You'll see that very few are into the thousands. Gwyn G3ZIL |
|
|
|
Jim Lill
where are the cycles recorded on a WD system? On 8/7/22 09:09, Gwyn Griffiths via
groups.io wrote:
In case an overview of how many decode cycles are actually used might be of interest I've put a histogram Dashboard |
|
|
|
Andrew Cowan
Rob
Where about are these settings as you know I have increased the horsepower at UDL's so if there is any benefit Great conditions at GM land at the moment. Thanks Andrew |
|
|
|
Rob Robinett
Add this line to your wd.conf file to change the relevant flags to wsprd: WSPRD_CMD_FLAGS="-C 10000 -o 4 -d" -C can vary from 0 to 10000, (wsjt-x default is 500) which permits wsprd to devote more cpu time to each bit -o can vary from 0 to 5. (wsjt-x default is 4). 5 takes up so much cpu time and gains so few spots that I don't run it anywhere.. -o = 3 or even 2 exponentially reduces cpu usage without a dramatic decrease in spot count. WSPRD_CMD_FLAGS is read a the start of each wspr cycle, so you can dynamically change it without needing to restart WD On Sun, Aug 7, 2022 at 7:23 AM Andrew Cowan <gm0udlandrew@...> wrote: Rob --
|
|
|
|
Gwyn Griffiths
Jim
decode_cycles is one of the wsprd 'diagnostic' outputs that Rob makes available in the wsprdaemon_spots_s table. Scroll down at http://wsprdaemon.org/wspr-field-names.html for the list of "Variables available from wsprd ..." The table can be accessed on the logs1.wsprdaemon.org server using any of the methods described in the Timescale guide at http://wsprdaemon.org/ewExternalFiles/Timescale_wsprdaemon_database_queries_V2-2.pdf Gwyn G3ZIL |
|
|
|
Jim Lill
I am assuming that data must be local here on my machine at some
point (?) On 8/7/22 14:03, Gwyn Griffiths via
groups.io wrote:
Jim |
|
|
|
Rob Robinett
Look in the ALL_WSPR.TXT file maintained by each rx channel, e..g.: wd_client@KFS-WD3:/dev/shm/wsprdaemon/recording.d/KIWI_Omni_A/20/W_120$ head ALL_WSPR.TXT 220807 1730 -21 1.52 14.0970970 VE3SAO EN58 23 0 0.18 3 1 0 1 40 1 810 220807 1730 -12 0.11 14.0971016 KG5ZMG EM12 23 0 0.39 2 1 0 0 11 1 375 220807 1730 3 1.35 14.0971032 NK9G EN62 23 -1 0.56 1 1 0 0 3 1 550 220807 1730 -6 0.32 14.0971157 <KR6RG> DM13EM 23 0 0.51 1 1 0 0 3 1 589 220807 1730 -18 0.19 14.0971210 K0CFW EN34 23 0 0.28 2 1 0 0 40 688 -100 220807 1730 -5 0.11 14.0971216 KD6EKQ DM12 20 0 0.57 1 1 0 0 0 1 574 220807 1730 -21 0.02 14.0971298 VK3QN QF22 37 0 0.12 2 1 -8 1 35 1 810 220807 1730 -9 0.49 14.0971343 N0UDM DM78 23 0 0.56 1 1 0 0 1 1 628 220807 1730 -20 0.02 14.0971380 KB0LQJ DN40 20 0 0.16 2 1 0 1 34 1 810 220807 1730 -10 0.45 14.0971419 WE5Q DM81 23 0 0.38 1 1 0 0 17 3 228 wd_client@KFS-WD3:/dev/shm/wsprdaemon/recording.d/KIWI_Omni_A/20/W_120$ On Sun, Aug 7, 2022 at 11:19 AM Jim Lill <jim@...> wrote:
--
|
|
|
|
Gwyn Griffiths
While several of these fields are obvious, others may not be, so, for the record, they are:
date, time, SNR, time offset, frequency, tx_call, tx_loc, power, drift, sync_quality, ipass, blocksize, jitter, decode_type, nhardmin, decode_cycles, metric See http://wsprdaemon.org/wspr-field-names.html for definitions. But note that for those stations that are decoding FST4W then Rob has repurposed the 'metric' field as spectral width in milliHz. Gwyn G3ZIL |
|
|