60m EU logs 30m stations [fixed in v1.549]
I selected the 60m EU WSPR extension, all looked OK but see this morning I reported many more stations than I expected. Looked at the admin user page and the frequency was showing 30m WSPR yet all stations were reported on 60m.
Running 1,548. have the IWBP wspr function running in another slot, hopefully that one is reporting correctly on the bands it looks at.
(edit added:) Looking at my WSPR reports I also see 160m is abnormally high - I'm the #1 reporter in the world - NOT likely. So that is messing up as well. WSPR has been running without any changes and the number of reports have looked reasonable until today.
73 Don
VE6JY
Comments
Anyone else see this?
The activity page on wsprnet.org is correct when you change bands in the extension. That's all I can easily test from here as I have no reception of WSPR signals (I have no reception of any kind which is pretty ironic).
I'm viewing my spots on http://wspr.rocks/topspotters/index.html and shows me with very inflated 160 and 60m totals. The IWBP scan had been going for days and always seemed to have a logical number of spots. Last evening I enabled a second slot on the 60m EU frequency (IN Canada we now have a 15 khz wide band there now so can legally tx on the 60m Eu slot) so I wanted to report some of the new VE stations on there. And then this morning is when I noted the inflated totals. My usual comment is "what did I do?" and then "why me"....
Are you running the single-frequency and IWBP from the WSPR extension on a normal browser connection? Or via the WSPR autorun mode configured by the admin page, extensions tab? Or it fails both ways?
Only from the admin page, extensions tab.
Sorry for being pedantic, but it's very important: Does that mean it was okay when run from a regular connection or that you never did that and only ever ran it from autorun mode?
The way the WSPR code is invoked as an extension from a normal user connection and from autorun mode is necessarily different. And it's possible there's a bug only associated with autorun mode and not the other.
I never ran it any other way than from the autorun/extension admin page. And the IWBP has been running for days without any perceived issues, it was only when I selected 60m Eu for the second slice (in the 4 rx mode as this KIWI isn't listed) that things started. No problem, I know you need all the clues possible to narrow it down. I worry it's something "stupid" I've done and I'm wasting your time chasing non existent issues.
jimlill.com:8088 correctly breaks down the eu bands rather than merge or ignore them
Thanks for the detailed info. It helps tremendously.
There is nothing you can do that should result in incorrect spot frequencies being reported. That can only be a bug someplace.
I was just experimenting, in admin page, extensions I selected wspr 60m EU for autorun 3 then looked at the status page - it started out on the right freq but when I looked again in a few min it had cycled to 10m and 2 min later had gone to 160m. So it was behaving like it was in IWBP mode. I didn't let it run long enough to report anything, fearing that I'd be adding more errors to the reporting database.
Did the same for autorun 0, started on 60m and in 2 min changed to 30m....
Went to another of my KIWI's, (it had never had IWBP run) in 8 ch mode, put autorun 7 onto 60m Eu and it has run 5 minutes fine without changing frequencies. Then put IWBP on autorun 6. All seemed normal. Then killed both wspr extensions, then added only 60m Eu back, ran for 2 mins then changed to another band, as if it was in IWBP mode.
So at least here, that seems like a repeatable issue. Hope that makes sense.
Okay, I think I found a problem.
But I need a Kiwi to test with. I need the admin page password as well as ssh access + password on port 22 (or other). Change to temporary password values and email to support@kiwisdr.com please. A Kiwi with decent WSPR reception please.
John I sent an email with details on a port-forwarded KiwiSDR you can test with. It's reasonably quiet and unused for anything else at the moment. Wayne
Hi Wayne,
I have nothing from you. Not even in the spam folder. And I checked reception by emailing to support@kiwisdr.com from elsewhere. Double check the address you used maybe? Thank you.
Email looks good, I copied content and sent you a message on the forum
Yeah, who knows these days. Anyway, got your forum message and replied. Thanks again.
Alright, so this was pretty terrible. But also kind of fortunate.
There was a bug where multiple autorun channels could interfere with each other in certain circumstances. For example, if a channel had been set to IWBP autorun, then set to normal operation, then another channel set to fixed-band autorun, the fixed channel would think it was in IWBP hopping mode. Not good obviously.
This should be fixed now. It does make sense sometimes to autorun IWBP and another fixed WSPR band at the same time since not all bands are covered by IWBP (e.g. LF, MF).
But a code review turned up another really interesting bug. A variable that prevents needless recalculation of some computationally-expensive intermediate values had been declared
staticin the original wsprd code. This is dreadfully wrong in the case of multiple channels decoding simultaneously because sharing one copy of that value across the channels effectively defeats its purpose and lots of expensive, unnecessary computation will (may) result. I somehow missed this during the original port of the code many years ago. It's unclear what impact this might have, but as you know the BBG/BBB-based Kiwis need all the help they can get when it comes to cpu cycles for WSPR decoding.There is a change in v1.549 some of you need to know about.
If you process the system log, and pull WSPR spots from it, note the format has changed for spots found by any channel running in autorun IWBP mode.
Previously a log showing this:
Will now show this for spots decoded by autorun IWBP:
So you might have to adjust your processing scripts slightly. I did this to make debugging with a bunch of IWBP and non-IWBP autorun processes running simultaneously easier.