> What period are you averaging over and are they all sampled at the same LOCAL time on each SDR to compensate for day night variation in propagation ?
For now it's not averaged over time. This was all taken from a single run of the script around 2100z yesterday. So as you point out it's really not compensated as it should, and for now I'm not really sure how to go forward technically to automate this from there. The samples are averaged over a couple seconds during data capture when the script is run, but that's it.
Maybe each KiWi should perform its own measurement based on this method ?
This could be collected and averaged over a period by sites such as sdr.hu.
It would also be a useful 'real time' statistic for KiWi admins allowing them to optimise the receive performance.
Some mechanism also needs to be found to weight the score with ADC overloads too, as otherwise you could have a sdr with a very good S/N and lots of very strong signals but lots of unwanted low level IMD.
> Maybe each KiWi should perform its own measurement based on this method ?
Yes, I think so. There are several advantages: it's distributed, it scales better, each receiver can readily use or offer its measurement without the need of an external or central party. Also possibly the code is simpler, if the receiver can grab directly a free channel without going through websockets and protocol compression. It could be added in web/services.c and run for a few seconds every hour (when a channel is available). Then it could be advertised directly in the status info, and pushed as icons to sdr.hu.
> This could be collected and averaged over a period by sites such as sdr.hu.
I don't think that's what I would do. I would push what I just said above further, and let the KiwiSDR average the score itself. For example every time a new score it calculated, it's merged into the averaged score, combining 2% new score and 98% old score; or something else, depending how often it's updated and how slow the evolution should be.
> It would also be a useful 'real time' statistic for KiWi admins allowing them to optimise the receive performance.
Yes, definitely. If the score is calculated by the receiver itself, it's easy to display it in the admin panel, both instant and averaged score. It gives an incentive to operators to improve their setup to see their score go up! It can be part of a help page or checklist of tips and steps to follow when installing and tuning the setup.
> Some mechanism also needs to be found to weight the score with ADC overloads too, as otherwise you could have a sdr with a very good S/N and lots of very strong signals but lots of unwanted low level IMD.
I hear overload events are exposed to the user through the audio websocket, and my script only opens a waterfall socket, so it's not going to be able to handle these. It seems overloads are a server-wide flag on the receiver, easy to access, so that's another reason to do it on the KiwiSDR side I guess there should be a counter to keep track of the number of overload events over time. It can be exposed by itself to the operator in the admin panel. I don't know if it should be accounted for as part of the SNR score. The most generic approach would be to keep and expose all these scores separately, and also possibly to merge them into a single general quality metric as a second step.
The overload event and OV flag on the S-meter are not optimal at the moment. If the ADC reports even ONE overflow during sampling an overload event is signaled (and latched until cleared by software). This of course is way too pessimistic. There will be plenty of cases where all the sine waves from all the 0 - 30 MHz signals just happen to "line up" to create an overflow condition without there being a chronic overload condition that is observed as splatter and IMD across the band.
The FPGA logic really needs to be accumulating a ratio of overflow counts to sample counts. Then the software needs to signal overload only when a threshold value is exceeded, maybe even time averaged. But this will take some work and careful testing.
I like the idea of SNR stats but if you average over the spectrum you lose the actual practical frequency coverage which may be more of an antenna and location factor.
I see that we can now see which frequency is being tuned by the other users of the receivers. It would be good to have an SNR value for that frequency, to get the capabilities of each setup. I wonder if that data is being collected at this point? If John collected the stats on what frequencies were used for any length of time for each receiver, we could build a list that included a capability score for any given frequency.
I am new here. Is there an API to the receiver that would return info without returning the entire page and making a full receiver connection? I am thinking of a script that could check receivers and get back info on how they are being used without actually using them in order to create a better list.
I was also thinking about how to list geographically in a better way. My thought is to create a map like the Azimuthal one - http://ve3sun.com/AzMap/point.php?Lat=32.81760541789164&Lon=16.922743320465088&call=CS3B so if you move the map to center on where you would like to find a receiver it populates a list sorted by distance from the center of the map. The list would also be sortable by other factors such as SNR if that had been collected. Any interest?
Longer term, I would like to incorporate VOACAP propagation predictions so you could point to a transmitter and a frequency and the list would be sorted by expected SNR. I have incorporated this in DX Monitor, so the code is available to me already.
OpenWebRX and KiwiSDR are getting my juices going...
> I like the idea of SNR stats but if you average over the spectrum you lose the actual practical frequency coverage which may be more of an antenna and location factor.
Yes. I'm still considering some multi-band scoring if this can work.
> I see that we can now see which frequency is being tuned by the other users of the receivers. It would be good to have an SNR value for that frequency, to get the capabilities of each setup. I wonder if that data is being collected at this point? If John collected the stats on what frequencies were used for any length of time for each receiver, we could build a list that included a capability score for any given frequency.
That wouldn't be very friendly towards privacy concerns I for one wouldn't like to know that what I'm listening to is getting actively tracked, and other user data collection. That seems like a very partial and scattered way to measure capabilities.
> I am new here. Is there an API to the receiver that would return info without returning the entire page and making a full receiver connection? I am thinking of a script that could check receivers and get back info on how they are being used without actually using them in order to create a better list.
There's the /status page on each KiwiSDR, like http://kiwisdr.jks.com:8073/status That's the page that gets probed to check receivers for making lists. That's where I would add a SNR score.
> I was also thinking about how to list geographically in a better way. My thought is to create a map like the Azimuthal one - http://ve3sun.com/AzMap/point.php?Lat=32.81760541789164&Lon=16.922743320465088&call=CS3B so if you move the map to center on where you would like to find a receiver it populates a list sorted by distance from the center of the map. The list would also be sortable by other factors such as SNR if that had been collected. Any interest?
I think that could be interesting as an alternative view to the normal map projection. This implementation in the link doesn't work for me for lack of WebGL support though. For now I'll just stick to the simple map implementation readily provided by Google Maps.
> Longer term, I would like to incorporate VOACAP propagation predictions so you could point to a transmitter and a frequency and the list would be sorted by expected SNR. I have incorporated this in DX Monitor, so the code is available to me already.
I've received a suggestion about VOACAP before: VOACAP predictions being overlaid on the map view. Not a bad idea, but a bit involved and far down the road. It would be nice to have a widget on the list that queries VOACAP scores for each receiver and sorts them, but that's a bit of web developer work too
You can sort by country, or longitude (grid square), etc. The map link shows the world as seen from the receive on the Azimuthal projection (sorry if you can't see it).
Just a quick experiment on a sortable view. I will probably add the map/distance selector to see how it feels.
I think the ability to sort your list is a nice plus, yes! I think we can use a bit of web development to add that kind of stuff, I'm happy to see people contributing to this Maybe it would also be nice to be able to filter on a given value or sort by two columns at the same time. Just ideas.
Yes, you would need permission from John. Databases and collections of data are protected by copyright, so you need permission to make a derivative work based on the listing data. Also, you would need permission or at least it's nice to ask about accessing the web page to scrape the data in an automated way.
You have it. And so does anyone else who wants to implement a useful/alternate UI looking at the data.
At the moment each Kiwi only updates the database every 30 minutes. This is because kiwisdr.com is hosted on a single Beagle on my home network. Now that I have some experience running a VPS with the reverse proxy service I plan to move kiwisdr.com to a VPS and increase the /status update rate.
> filter on a given value or sort by two columns at the same time
Given most of the receivers purport to cover 0-30 MHz, it hardly helps to filter right now. What would be useful is to know how effective they are at a given frequency. I am going to ponder ways to find that.
If you click on country it sorts by available slots as a sub-sort for now.
Your Trask antenna is seems quite good on VLF ! Your KiwiSDR is the best, in my opinion.
So what are the stickers about on sdr.hu? It would seem that GPS, VLF, and RX are available on all of them, although they will work without a GPS. So what is it about?
Well, I am not very sure what is this all about "sort" and "rate" the receivers, and I am not very sure that I've understood what do the icons indicate for some (not all) receivers, but according to my opinion the best criteria for sorting the receivers is how many listeners and for how long they stay to a particular receiver. For those that they "transmit" through Shoutcast or Icecast, is familiar that the Centrova has a very good stats graph, which indicate the total number of listeners, total number of hits, average listening time etc. etc.Only the listeners can evaluate the "popularity" of a receiver....
I am convinced that the popularity of the receivers and the SDR.hu network will get higher if we find a way to increase the listeners slots. So please make some efforts to give more slots.
(I grabbed RX3.) The operator or someone local has been staying on 3 out of 4 slots for nearly 5 days straight now, running WSPR. However this high usage piece of statistics really isn't indicative of popularity or quality.
> I am convinced that the popularity of the receivers and the SDR.hu network will get higher if we find a way to increase the listeners slots. So please make some efforts to give more slots.
Definitely. However this is a hardware limitation, so any improvement would be a whole new design project to launch into.
I think the model that was setup by sites using PA3FWM's web sdr software that lets a lot of concurrent listeners using the same sdr (lots of users on few expensive to setup and run sdr's) is different to the KiWi sdr distributed model (lots of low cost sdr's that only allow a few users each).
PA3FWM is very careful about who he allows to use his software. He does this to ensure that good sites are used and that they are engineered properly, as he doesn't want his reputation and software to be tarnished by poor performance.
KiWi sdrs are sold to whoever wishes to buy them, and so it is inevitable that some admins will not have an RF engineering background, or an understanding of what is required to improve S/N performance either by reducing unwanted interference, improving antennas or preventing overloading (or all of these)
Q. Why do a few Kiwi's (perhaps 20% ? my estimate) get so much use in comparison to the others (perhaps 80% ? again my estimate) and why do the busy ones have so few available slots ?
A. Easy - folks use the sdr's with the best receivers. The trick is not to add more slots per receiver (which is not possible because of the hardware limitations), but to encourage admins with under performing sdr's to take steps to improve them.
This is really what the rating system is about. To help 'name and shame' the poor sdr's so that their admins are encouraged to try and make them better.
If we could reduce the 80% of poor performers down to say just 20%, then there would be plenty of good sdr's to go around.
What does this mean "best receivers"? Most listeners define their needs according to their interests. Some of them want to hear VLF or radio broadcasting, some other want to check the propagation to different areas, other radioamateurs use to make logh distance QSOs using SDR receivers because their own reception is rather poor (unfortunately very popular and common practice during the last years), there is a number of listeners that they prefer to listen to "illegal" AM stations or exotic communications outside ham bands, there are also ham (or "illegal") amateurs that they use SDRs to test their transmission, modulation, power, antenna etc. etc. And all of them will choose the most "proper" SDR to cover their needs, but in a strict, personal way!
So, the discussion "which are the best receivers" includes many arguments.
I can understand "hardware limitations" and I hope that the next generation of Kiwi will overcome these limitations.
RX0: (Zurich, Switzerland) 27527.05 kHz usb z4 1:32:14
RX3: (Marconne, France) 11175.00 kHz usb z9 1:21:37
It doesn't stop listeners from occupying receivers for long periods of time, just makes them swipe the waterfall/zoom in/zoom out/re-tune for a moment every a few minutes.
> If we could reduce the 80% of poor performers down to say just 20%, then there would be plenty of good sdr's to go around.
I'm afraid you're fighting against the statistical reality of Pareto distributions and Sturgeon's law. Improvement is desirable and possible, but the 80-20 principle is something we have to accept and embrace
@Daniel, if there is a slight activity (e.g 1KHz qsy), the "counter" is starting again to count the time limit. That's why the timeout does not function as expected.
I understand the points you are making, but to be honest there are some KiWi's that are practically unusable due to the low level of wanted signals and high levels of interference.
The current vote based rating system on sdr.hu does not reflect this.
I got a response from Andras this afternoon. He says he's changed the sorting algorithm (and my Kiwi jumped multiple places so it must be a good one!), and he's planning to implement features like sorting on geographical area. So we'll see, but as he says: "It's the Internet, stuff like this happens".
It has been awhile since I've heard any updates to this thread. I check rx.linkfanel.net often and it is easy to use. I do notice that the scoring system does not necessarily reflect the expected quality of the receiver, so I wonder if any scoring methods or averaging have been invented to make the page more accurate? I mostly use the page to find a receiver on the map that might connect to the station of interest. Ron KA7U
Comments
Today I bring a crude temporary page exposing my scoring attempts: http://rx.linkfanel.net/snr.html
However today's solar activity will really mess it up :-(
What period are you averaging over and are they all sampled at the same LOCAL time on each SDR to compensate for day night variation in propagation ?
Regards,
Martin - G8JNJ
LOCAL time on each SDR to compensate for day night variation in
propagation ?
For now it's not averaged over time. This was all taken from a single run of the script around 2100z yesterday. So as you point out it's really not compensated as it should, and for now I'm not really sure how to go forward technically to automate this from there. The samples are averaged over a couple seconds during data capture when the script is run, but that's it.
This could be collected and averaged over a period by sites such as sdr.hu.
It would also be a useful 'real time' statistic for KiWi admins allowing them to optimise the receive performance.
Some mechanism also needs to be found to weight the score with ADC overloads too, as otherwise you could have a sdr with a very good S/N and lots of very strong signals but lots of unwanted low level IMD.
Regards,
Martin - G8JNJ
Yes, I think so. There are several advantages: it's distributed, it scales better, each receiver can readily use or offer its measurement without the need of an external or central party. Also possibly the code is simpler, if the receiver can grab directly a free channel without going through websockets and protocol compression. It could be added in web/services.c and run for a few seconds every hour (when a channel is available). Then it could be advertised directly in the status info, and pushed as icons to sdr.hu.
> This could be collected and averaged over a period by sites such as sdr.hu.
I don't think that's what I would do. I would push what I just said above further, and let the KiwiSDR average the score itself. For example every time a new score it calculated, it's merged into the averaged score, combining 2% new score and 98% old score; or something else, depending how often it's updated and how slow the evolution should be.
> It would also be a useful 'real time' statistic for KiWi admins allowing them to optimise the receive performance.
Yes, definitely. If the score is calculated by the receiver itself, it's easy to display it in the admin panel, both instant and averaged score. It gives an incentive to operators to improve their setup to see their score go up! It can be part of a help page or checklist of tips and steps to follow when installing and tuning the setup.
> Some mechanism also needs to be found to weight the score with ADC
overloads too, as otherwise you could have a sdr with a very good S/N
and lots of very strong signals but lots of unwanted low level IMD.
I hear overload events are exposed to the user through the audio websocket, and my script only opens a waterfall socket, so it's not going to be able to handle these. It seems overloads are a server-wide flag on the receiver, easy to access, so that's another reason to do it on the KiwiSDR side
lose the actual practical frequency coverage which may be more of an
antenna and location factor.
Yes. I'm still considering some multi-band scoring if this can work.
> I see that we can now see which frequency is being tuned by the other
users of the receivers. It would be good to have an SNR value for that
frequency, to get the capabilities of each setup. I wonder if that data
is being collected at this point? If John collected the stats on what
frequencies were used for any length of time for each receiver, we could
build a list that included a capability score for any given frequency.
That wouldn't be very friendly towards privacy concerns
> I am new here. Is there an API to the receiver that would return info
without returning the entire page and making a full receiver connection?
I am thinking of a script that could check receivers and get back info
on how they are being used without actually using them in order to
create a better list.
There's the /status page on each KiwiSDR, like http://kiwisdr.jks.com:8073/status That's the page that gets probed to check receivers for making lists. That's where I would add a SNR score.
> I was also thinking about how to list geographically in a better way. My thought is to create a map like the Azimuthal one - http://ve3sun.com/AzMap/point.php?Lat=32.81760541789164&Lon=16.922743320465088&call=CS3B
so if you move the map to center on where you would like to find a
receiver it populates a list sorted by distance from the center of the
map. The list would also be sortable by other factors such as SNR if
that had been collected. Any interest?
I think that could be interesting as an alternative view to the normal map projection. This implementation in the link doesn't work for me for lack of WebGL support though. For now I'll just stick to the simple map implementation readily provided by Google Maps.
> Longer term, I would like to incorporate VOACAP propagation predictions
so you could point to a transmitter and a frequency and the list would
be sorted by expected SNR. I have incorporated this in DX Monitor, so
the code is available to me already.
I've received a suggestion about VOACAP before: VOACAP predictions being overlaid on the map view. Not a bad idea, but a bit involved and far down the road. It would be nice to have a widget on the list that queries VOACAP scores for each receiver and sorts them, but that's a bit of web developer work too
> Do I need permission to use the http://kiwisdr.com/public data?
Yes, you would need permission from John. Databases and collections of data are protected by copyright, so you need permission to make a derivative work based on the listing data. Also, you would need permission or at least it's nice to ask about accessing the web page to scrape the data in an automated way.
how many listeners and for how long they stay to a particular receiver
Here is an example of where this might not hold, going on right now on the Pardinho KiwiSDR:
RX0: (Pardinho, Brazil) 14097.10 kHz usb z14 wspr 117:13:52
RX1: (Pardinho, Brazil) 7040.10 kHz usb z14 wspr 117:13:50
RX2: (Pardinho, Brazil) 3594.10 kHz usb z14 wspr 117:09:41
(I grabbed RX3.) The operator or someone local has been staying on 3 out of 4 slots for nearly 5 days straight now, running WSPR. However this high usage piece of statistics really isn't indicative of popularity or quality.
> I am convinced that the popularity of the
receivers and the SDR.hu network will get higher if we find a way to
increase the listeners slots. So please make some efforts to give more
slots.
Definitely. However this is a hardware limitation, so any improvement would be a whole new design project to launch into.
I'm afraid you're fighting against the statistical reality of Pareto distributions and Sturgeon's law. Improvement is desirable and possible, but the 80-20 principle is something we have to accept and embrace
I understand the points you are making, but to be honest there are some KiWi's that are practically unusable due to the low level of wanted signals and high levels of interference.
The current vote based rating system on sdr.hu does not reflect this.
Regards,
Martin - G8JNJ
Happy New Year!
It has been awhile since I've heard any updates to this thread. I check rx.linkfanel.net often and it is easy to use. I do notice that the scoring system does not necessarily reflect the expected quality of the receiver, so I wonder if any scoring methods or averaging have been invented to make the page more accurate? I mostly use the page to find a receiver on the map that might connect to the station of interest.
Ron
KA7U
http://sibamanna.duckdns.org/sdr_map.html
It's not 100% accurate as some types of interference can be interpreted as genuine signals, but it does give some guidance.
The http://rx.linkfanel.net/ map also gives S/N values but you have to hover over the SDR to see the notes and it's a composite value for all bands.
VE3SUN's KiWi page is also quite useful if you want to find a KiWi with propagation to a certain target area.
http://ve3sun.com/KiwiSDR/
It also has a listing of a few contributed DX.json files
http://ve3sun.com/KiwiSDR/Transmitters.php
Regards,
Martin - G8JNJ