We seek to understand and document all radio transmissions, legal and otherwise, as part of the radio listening hobby. We do not encourage any radio operations contrary to regulations. Always consult with the appropriate authorities if you have questions concerning what is permissable in your locale.

Author Topic: SDRUno 1.24  (Read 2628 times)

Offline Josh

  • DXing Phenomena
  • *******
  • Posts: 4164
    • View Profile
SDRUno 1.24
« on: August 27, 2018, 2253 UTC »
Just a note to say I've been playing with SDRuno 1.24 (on a RSP2 SDR) a bit today and have it running with as low or even lower cpu usage than HDSDR, no mean feat considering before the average was 11 percent cpu at all times. This is with just one vrx operating, most of my operating is in single channel mode.

This is very nice, normally I employed HDSDR for most uses simply because of the low cpu use and the intuitive controls, but now that SDRuno offers reduced cpu usage there's little reason to fire up HDSDR, reason being SDRuno offers far more decimation levels, the more decimation - the higher the dynamic range without sacrificing sensitivity, what you trade off is received bandwidth. These are the particulars for SDRuno here; 32 decimation, low IF mode, IF Bandwidth of 200KHz, IF agc off and set to 55Db, final sample rate of 62500. I suspect this places the dynamic range of the RSP2 in the same range as the RSP1A, possibly a good bit better dynamics than the typical user is running their RSP2 in.

Case in point, a relatively huge ALE sig just popped up on the screen on 11181 (tuned to 11175) yet I never would have known it was there if I hadn't seen it on the waterfall. Normally when the RSP2 is tuned to 11175 USB in SDR Console V3 or HDSDR, an ALE sig on 11181 will cause noise on 11175 as well as a noticeably raised noise floor - not anymore. HDSDR only offers decimation up to 8 in low IF mode, as far as I can tell. Anyway, I feel SDRuno has the best agc and audio out of the SDR apps I use so this just makes it more likely I'll be using it much more often than before.

I must mention that I probably use the RSP2 unlike most other users in that I mostly concentrate on a single channel and do not need or want huge swaths of spectrum on display. Many if not most RSP users want the most waterfall spectrum on screen they can and willingly sacrifice dynamic range to get this, I'm trying to get as much dynamic range as possible out of the 12bit (10enob) RSP2 adc that I can get.

You can read my review of the RSP2 here;
http://www.udxf.nl/SDRPlay_RSP2_SDR.pdf

SDRuno also runs RTL SDRs too.

Get SDRuno
https://www.sdrplay.com/windl2.php

Decimation is good for you.... but not if you were a Roman legionary!
https://www.youtube.com/watch?v=zcs7qw1gEDI

http://www.qsl.net/z33t/dynamic_range_eng.html

The relevant bits on decimation, the case given is for a 10MHz clock 12bit SDR;
- With 0 decimation alias-free spectrum bandwidth is 8 MHz and dynamic range is about 74 dB.

- With 2x decimation alias-free spectrum bandwidth will be 4 MHz, processing gain will increase by 3 dB and dynamic range will be 77 dB.

- With 4x decimation alias-free spectrum bandwidth will be 2 MHz, processing gain will increase by 6 dB and dynamic range will be 80 dB.

- WIth 8x decimation alias-free spectrum bandwidth will be 1 MHz, processing gain will increase by 9 dB and dynamic range will be 83 dB.

- With 16x decimation alias-free spectrum bandwidth will be 500 kHz, processing gain will increase by 12 dB and dynamic range will be 86 dB.

- With 32x decimation alias-free spectrum bandwidth will be 250 kHz, processing gain will increase by 15 dB and dynamic range will be 89 dB.

- With 64x decimation alias-free spectrum bandwidth will be 125 kHz, processing gain will increase by 18 dB and dynamic range will be 92 dB.
We do not encourage any radio operations contrary to regulations.

Offline Josh

  • DXing Phenomena
  • *******
  • Posts: 4164
    • View Profile
Re: SDRUno 1.24
« Reply #1 on: August 31, 2018, 0350 UTC »
I must correct a statement I made in the above post. I found out where sdrplay is hiding the cpu time used by SDRuno. It's in the api.

If you fire up task manager you see the cpu time and memory used. In this case I hadn't noted that the other 10 percent cpu time that was displayed across all cores stemmed from the sdruno api, so the actual cpu time for the app is still around 13 percent, however the decimation options are still compelling. If hdsdr had more decimation levels I'd be using that, 64 decimation and 2 percent cpu time would be lovely.
We do not encourage any radio operations contrary to regulations.