wsprdaemon bandwidth & audio?
I am considering setting up a Pi4 to run wsprdaemon. I am wondering what the network bandwidth usage is for each WSPR receiver that is set up, on the chance I could also run it over a WAN on occasion.
Also, is the audio stream that is accessed by wspardaemon essentially the same that is output to a browser from a KiwiSDR? In other words, would piping the browser audio output into WSJT-x software yield a similar spot count as from wsprdaemon?
Comments
Remember also there is a dedicated forum for wsprdaemon in case you don't get a sufficient answer here: https://groups.io/g/wsprdaemon/topics
During my previous effort to compare receivers, I captured wav files (at appropriate levels) and then in non-real time fed them to wsprd which is the standalone wspr decoder use din wsjt-x.
I have successfully run 14 channels of wsprdaemon on the same RPI4 host that ran FlyDog. I found the RPI4 to be capable even with busy bands but the Flydog needing a great deal of help to become competitive with the stock BBG/Kiwi.
Wsprdaemon receives a wav file from each of the selected receivers using kiwirecorder.py and then decodes, merges, filters and posts to wsprdaemon.org as well as wsprnet.org. It can also post noise data for each of the rx channels. I've had no problem doing all of this using an RPI but, as mentioned, did have to make major changes/improvements in the RPI/FlyDog to get RF performance to start to approach the BBG/Kiwi.
While it is possible to pipe browser audio (from a browser running on a separate host, no doubt) that is probably not the best way to get multiple simultaneous WSPR bands from a Kiwi/RPI. If the decoder was a new one, like wsprdaemon uses, I suspect spots would be the same but it likely takes more pieces to accomplish this. I'd recommend trying a stock Kiwi adapted for an RPI4 running wsprdaemon as a way to get 14 bands while running only a single host - the same one running the Kiwi. This can be done with a WiFi network interface which can help mitigate common mode noise impairment that a BBG/Kiwi might induce.
Glenn
Much appreciate the useful and detailed responses to my original post, and I've added the groups.io for wsprdaemon to my ever expanding list of forums.
The only piece of missing information I am still seeking revolves around the network bandwidth usage - has any one ever measured how much bandwidth is required to feed each receiver channel to wsprdaemon? For the browser interface, listening to a single frequency appears to require about 500 kbps upstream from the KiwiSDR. if it is similar for wsprdaemon that implies about 4 megabits/second upstream from the KiwiSDR to utilize all 8 receivers (the limit?) at the same time. Which reinforces the need to co-locate a Pi4 on the LAN with the SDR...given the upstream WAN bandwidth of about 0.7 megabits where I am setting up the Kiwi. I do wonder if the reduced audio bandpass (1300-1700 Hz) cuts the per receiver bitrate requirement.
I briefly tried a FlydogSDR but returned it when it became obvious that the waterfall could not be rid of a large collection of permanent "birdies", even with the antenna port terminated with a 50 ohm load, regardless of the power supply used.
Each uncompressed wpsr 12 Ksps rx channel audio consumes about 220 Kbps. My KPH Kiwis output 1.53 Mbps for the 7 channel Kiwi and 1.31 Mbps for the 6 channel. Compressed audio consumes about 60 Kbps but for WSPR decoding you need uncompressed.
rrobinet,
Thank you for the bandwidth values, exactly what I was curious to know about. So I definitely MUST have the Pi co-located on the LAN. Right now the only Pi I have is in another state, running OpenwebRX with a couple of SDRs. Just for fun I should try installing wsprdaemon on that Pi and see if I could run it with a couple of WSPR channels from the KiwiSDR (440 kbps upstream). Based on what n6gn said it should be able to handle openwebrx and wsprdaemon tasks at the same time.
Bruce KX4AZ