V 1.214 WSPR-autorun on 8 channels not so effective as on 4 channels [known limitation]

WernererichWernererich
edited October 2018 in Problems Now Fixed
Hello,
it seems that WSPR-autorun decoded on 8 channels less spots per channel or is less sensitive then WSPR-autorun on 4 channels.

Can anybody confirm this?

Vy73 de Wernererich

Comments

  • jksjks
    I think the Beagle is just plain out of cpu cycles with so many WSPR decoders running. The multiple decoder instances don't cooperate at all which can lead to inefficient use of the cpu. Each decoder (operating on different bands) starts with a range of signal targets from strong to weak. But if some decoders get through decoding the strong targets before the others then they are wasting time trying to decode what might be noise when those cpu cycles could be better spent on the other channels working on more promising targets. The argument against that is that you don't want to change the algorithm such that it's always favoring the decoding of strong signals across all bands. So it's a compromise.

    That's why Rob's solution feeding 8 channels of IQ via kiwirecorder to one of the newer multi-core Raspberry Pis works so well. There is no cpu bottleneck and full decoding takes place without anything being "left on the table".

    But it's always possible there is a problem between 4 and 8 channel modes. My antenna is down at the moment. What we really need is for someone to run an experiment where one antenna feeds two Kiwis. One running 4 auto-run sessions in 4 channel mode and the other running 4 auto-run sessions in 8 channel mode and see if the decode counts disagree significantly.
  • WernererichWernererich
    Hello, thank you for the information. Is there a new KiwiSDR with more CPU-Power in planning?

    73 de Wernererich
  • jksjks
    Is there a new KiwiSDR with more CPU-Power in planning?
    Not really. I think most people want me to work on the software instead. I do think about the hardware. But when you take all the issues into consideration it is not clear what should be done, if anything.
  • G8JNJG8JNJ
    Hi All,

    I think that maybe we are all loosing sight of what the KiWi was originally designed to do and what it is now capable of.

    A while ago John posted a link https://en.wikipedia.org/wiki/No_good_deed_goes_unpunished

    Which I think nicely sums up the situation today. John has managed to achieve a fantastic amount of functionality in the KiWi, but unfortunately human nature being what it is, this just leads to us all (well me certainly) tending to want even more, no matter how technically difficult and no matter how much Scotty would have protested that “Ye cannae change the laws of physics”.

    I suspect that we have now well gone past the point of 'diminishing returns' https://en.wikipedia.org/wiki/Diminishing_returns so perhaps we need to be more realistic about what is desirable, possible, or what is likely to cause John to "spontaneously combust" https://en.wikipedia.org/wiki/Spontaneous_human_combustion if we carry on urging him to try and do even more with less.

    My apologies to John, for all my reduculous requests and crazy suggestions, and I hope that's enough metaphor's in one posting for folks to consider :-)

    Regards,

    Martin - G8JNJ
    Powernumpty
  • G8JNJG8JNJ
    After all that I forgot to raise the point that I originally intended.

    I think the built in WSPR decoder is adequate for casual users. It's a bit like the FSK and Fax decoders. They are perfectly OK for a quick 'look see' but serious users would probably use an external decoder fed via a sound-card loop-back or VAC.

    At lest there is a good technical workaround for WSPR and 'serious' users now have the option of being able to use up to 8 RX channels too, which I think is a very good solution.

    Regards,

    Martin - G8JNJ
    Powernumpty
  • WernererichWernererich
    Then it's good that we now know what serious users are doing.
    Thanks for the clarification.

    73 Wernererich
  • jksjks
    edited August 2018
    I looked into this question last night: Why is the RPi-3B/3B+ so fast? The answer is that the Pis have used a progression of Broadcom SOCs from the BCM2835 ARM-1176 @700MHz to BCM2836 Cortex-A7 @900M to now the BCM2837 Cortex-A53 @900M/1.2G/1.4G. The BCM A7 and A53 are both quad-core which is very significant.

    Over the same time period (2013-) the Beaglebone Black (and variants) have all used a TI Sitara AM3358/9 single-core Cortex-A8 at mostly 1GHz. There is the BeagleBoard-X15 (US $270) that uses the AM5728 dual-core Cortex-A15 @ 1.5GHz. It is not physically compatible with the BBB. And at that price it doesn't matter.

    So both the BeagleBone and TI are behind the curve. The Broadcom parts don't have Ethernet MACs for some reason, but otherwise kudos to them.
  • WernererichWernererich
    Thanks for your info, but I'm not that big computer specialist.
    I tested the kiwi over night with only 6 WSPR channels and lo and behold, the result was much better.

    73 Wernererich
  • jksjks
    edited August 2018
    Okay, good to know.

    I wrote up the details in case anyone was interested in the BeagleBone Black/Green vs RPi story. The situation was reversed in 2013 when work began on the Kiwi. The RPi-A1 was terrible and the BBB was the clear winner. This improved with the lower cost BBG by the time we got to the Kickstarter and Seeed taking over manufacturing. But things started changing in late 2016 with the RPi-B2/v1.2
  • PowernumptyPowernumpty
    Devices are never quite enough for the ideas of the next user/version. Getting this out to market and being able to handle decoding externally has moved the field on.
    It has been a breath of fresh air to be able to see the RF world from so many devices. There is a fair possibility that with the increasing CPU and interface speeds EMI becomes more of an issue and you may have ended up having to avoid certain RPi versions or peripherals that just can't be used on the BB.
    Also the myriad software platforms available on the RPi would have meant constantly fielding the "can it run at the same time as software X, on OS Y version 0.4.3.8?".
    I think there is something to be said for just enough for the task.
  • rrobinetrrobinet
    You can work around the Kiwi's autowspr CPU limits in both 4 and 8 channel mode by running on a Pi the kiwiwspr.sh script I have just published to the "Problems Solved' forum. I have tested the script on a Pi and it can capture 20+ streams from 3 Kiwis at once and decode and post them using the WSJT-x 1.9.1 'wsprd' application.
    WA2ZKD
Sign In or Register to comment.