SDRplay with gr-osmosdr: a few answers, many questions

[AH6DL]

I've been doing some more work trying to get SDRplay working with gr-osmosdr and think I've uncovered some of the reasons why people are having trouble making it work with gqrx and other GNUradio based software that relies on gr-osmosdr. The problem appears to be the way gr-osmosdr initializes the SDRplay. If we can get that correct, I think we'll have a workable solution for GNUradio and gqrx, but I'll need some more information to figure it out. I'd like to know if any one is successfully using gr-osmosdr with SDRplay and if so, how they are sending the initialization parameters to SDRplay and what parameters are they using?

Here's what I've discovered using the oscomcom_fft program. Running this without parameters returns an error:

Code: Select all

mir_sdr_Init started
mir_sdr_Init: starting hardware initialization
mir_sdr_Init: gR=60dB fs=2.000MHz rf=200.000MHz bw=5.000MHz if=0.000MHz

mir_sdr_Init: Fs=2000000Hz is too low for Lif=0 and Bw=5000000 - minimum required 5000000
reinit_device end

I was able to get a display using these parameters:

Code: Select all

dl@t520 ~]$ osmocom_fft -s 5e6 -f 100e6
linux; GNU C++ version 5.1.0; Boost_105800; UHD_003.008.004-0-unknown

gr-osmosdr v0.1.4-45-g46e95395 (0.1.5git) gnuradio 3.7.7
built-in source types: file fcd rtl rtl_tcp uhd sdrplay hackrf bladerf rfspace airspy 
get_devices started
mir_sdr_Init: starting hardware initialization
mir_sdr_Init: gR=60dB fs=2.048MHz rf=200.000MHz bw=1.536MHz if=0.000MHz
mir_sdr_usb_USB DLL: Revision 0.1.1
mir_sdr_2500_Init: fnaddr = 2 detected, trying to change...
mir_sdr_2500_Init: fnaddr = 6

mir_sdr_2500_Init: adjusting squelch trim 0x1, rx gating enable 1, tx_trim 0, reg2 = 0x4801
initHw: Register7 = 0x000005
initHw: Tuner Register0 = 0x04f440
mir_sdr_SetFs: Sample Freq requested 2047999.978065
mir_sdr_SetFs: Fs->FsNomHz+dFsHz=2048000.0+0.0Hz=2048000.0Hz FsToggle->1
mir_sdr_SetRf: f->200000000.000Hz (int=21 frac=3e8 afc=0) fSynth:3200000000.000
mir_sdr_SetRf: Rf->RfNomHz+dRfHz+LifHz+Lif1Hz=200000000.0+0.0+0.0Hz+0.0Hz=200000000.0Hz RfToggle->1
mir_sdr_SetGr: GR->60[36,24,0,0] gRset->0x224 DCCALmode=4 DCCALspd=1 GrToggle->1
setToggleStates: initialising sampNum=0x04f48e34, gainSetting=0x224, FsToggle=1, RfToggle=1, GrToggle=1
setToggleStates: initialising Fs=2047999.978, Rf=200000000.000, Gr=60
mir_sdr_Init: already initialised
Device count: 1
sdrplay=0,label='SDRplay RSP'
get_devices end
get_num_channels: 1
[repeated lines removed]
set_gain started
gain = 47
set_gain end
set_sample_rate start
rate = 5e+06
diff = 2.952e+06
set_sample_rate end
get_num_channels: 1
[repeated lines removed]
Using Volk machine: avx_64_mmx_orc
get_num_channels: 1
[repeated lines removed]
set_center_freq start
freq = 1e+08
diff = -1e+08
set_center_freq end
reinit_device started
after mutex.lock
mir_sdr_Init started
mir_sdr_Init: starting hardware initialization
mir_sdr_Init: gR=60dB fs=5.000MHz rf=100.000MHz bw=5.000MHz if=0.000MHz

mir_sdr_usb_USB DLL: Revision 0.1.1
mir_sdr_2500_Init: fnaddr = 2 detected, trying to change...
mir_sdr_2500_Init: fnaddr = 6
mir_sdr_2500_Init: adjusting squelch trim 0x1, rx gating enable 1, tx_trim 0, reg2 = 0x4801
initHw: Register7 = 0x000094
initHw: Tuner Register0 = 0x053420
mir_sdr_SetFs: Sample Freq requested 5000000.000000
mir_sdr_SetFs: Fs->FsNomHz+dFsHz=5000000.0+0.0Hz=5000000.0Hz FsToggle->1
mir_sdr_SetRf: f->100000000.000Hz (int=21 frac=3e8 afc=0) fSynth:3200000000.000
mir_sdr_SetRf: Rf->RfNomHz+dRfHz+LifHz+Lif1Hz=100000000.0+0.0+0.0Hz+0.0Hz=100000000.0Hz RfToggle->1
mir_sdr_SetGr: GR->60[36,24,0,0] gRset->0x224 DCCALmode=4 DCCALspd=1 GrToggle->1
setToggleStates: initialising sampNum=0x00017a02, gainSetting=0x224, FsToggle=1, RfToggle=0, GrToggle=0
setToggleStates: initialising Fs=5000000.000, Rf=100000000.000, Gr=60
reinit_device end

The resulting display correctly shows signals from local FM stations and the DC carrier at 100 MHz. However, as with the gqrx display, the noise floor level is jumping up and down. Changing to a less used bit of spectrum shows the same behavior, but it is easier to see that the noise is being generated around the DC carrier:



I think the problem is the initialization data being sent to the SDRplay is not correct. I tried using the "-a" command line argument to pass initialization arguments as outlined in the SDRplay API documentation but I'm not seeing any indication they being used (at least so far). There is probably a way to do this -- I just haven't figured it out yet. Any help would be appreciated.

I see that Dimitri Stolnikov doesn't have an SDRplay and so hasn't been able to test and tweak the gr-osmosdr implementation of the API. Anyone interested in joining with me to ship Dimitri an SDRplay to work with? Once we get gr-osmosdr working well with SDRplay, gqrx should work as well!

...Doug AH6DL

[AH6DL]

I may be headed down the wrong path, but to me it appears the gr-osmosdr sdrplay module is not providing the correct initialization to the API.

Here is the terminal readout from the sdr-j-fm-receiver-0.98 initialization:

Code: Select all

mir_sdr_Init: starting hardware initialization
mir_sdr_Init: gR=40dB fs=2.000MHz rf=91.700MHz bw=1.536MHz if=0.000MHz

mir_sdr_usb_USB DLL: Revision 0.1.1

mir_sdr_2500_Init: fnaddr = 2 detected, trying to change...

mir_sdr_2500_Init: fnaddr = 10

mir_sdr_2500_Init: adjusting squelch trim 0x1, rx gating enable 1, tx_trim 0, reg2 = 0x4801
initHw: Register7 = 0x000014
initHw: Tuner Register0 = 0x04f420
mir_sdr_SetFs: Sample Freq requested 2000000.000000
mir_sdr_SetFs: Fs->FsNomHz+dFsHz=2000000.0+0.0Hz=2000000.0Hz FsToggle->1
mir_sdr_SetRf: f->91699996.948Hz (int=1e frac=6a3 afc=ff3) fSynth:2934399902.344
mir_sdr_SetRf: Rf->RfNomHz+dRfHz+LifHz+Lif1Hz=91699996.9+0.0+0.0Hz+0.0Hz=91699996.9Hz RfToggle->1
mir_sdr_SetGr: GR->40[16,24,0,0] gRset->0x210 DCCALmode=4 DCCALspd=1 GrToggle->1
setToggleStates: initialising sampNum=0x05c1f467, gainSetting=0x210, FsToggle=1, RfToggle=0, GrToggle=0
setToggleStates: initialising Fs=2000000.000, Rf=91699996.948, Gr=40
mir_sdr_SetDcMode: DCCAL: mode->4 speedup->1
mir_sdr_SetDcTrackTime: DCTRK_TIM->63
Starting 1

mir_sdr_SetSyncUpdatePeriod: 1000000
mir_sdr_SetSyncUpdateSampleNum: 252
mir_sdr_SetGr: GR->27[27,0,0,0] gRset->0x1B DCCALmode=4 DCCALspd=1 GrToggle->1
mir_sdr_ReadPacket: Gain update confirmed: Gr=27dB GrToggle=1 gset=0x1b
fsc = 0, rfc = 0, grc = 1
size = 512
Ready to run
we are running

Note that sdr-j sets some parameters that I don't see any reference to in sdrplay_source_c.cc:
mir_sdr_SetDcTrackTime: DCTRK_TIM->63
mir_sdr_SetSyncUpdatePeriod: 1000000
mir_sdr_SetSyncUpdateSampleNum: 252

When I get some of the other work I should be doing this weekend accomplished, I'll try adding those settings to sdrplay_source_c.cc and see if it makes a difference. I'm fairly new at this, so any help or suggestions would be appreciated!

...Doug AH6DL

[AH6DL]

Here's an update on where I stand trying to get gr-osmosdr to work with the SDRplay. Adding the additional lines I mentioned in the last email didn't help.

I now think the problem output packets are getting lost or corrupted. Doing some testing with a sample GRC program (SDRplay source box and FFT sink) I noticed that sometimes the spectrum display would briefly look normal when the program started before going to the high DC offset and jumping amplitude I displayed earlier in the screen capture. Moving the connection to a USB 3.0 port seemed to reduce the fluctuation slightly. Corrupted IQ data would explain the noise, frequency shift and other problems reported with GQRX.

I'm going to look at the buffer size next and see if increasing it helps. It appears gr-omsosdr sets the I and Q buffer to 504. I'll see what sdr-j is using and do some more testing with some modified values after work today.

As I said before, any help would be appreciated! We have to get gr-osmosdr working before GQRX and other GNUradio based programs will work with the SDRplay.

73...
...Doug

[AH6DL]

Another update --

I tried changing the buffer size in the gr-osmosdr/lib/sdr source code from 504 all the way up to 16384 and didn't see any noticeable change, so that isn't the issue. At times I thought it was improving, but comparing the 504 version to the 16384 byte versions didn't make a difference -- just the normal randomness. To make sure it wasn't my grc test program causing the problem, I changed the sample rate to 2.5e6 and tested it with my Airspy unit and the simple program worked as expected -- a clean display of a received FM signal and no DC offset.

As someone noted in the GQRX discussion, the SDRplay spectrum output looks like it is overloaded, but removing the antenna doesn't change anything so that seems unlikely. I can clearly see the impact of the different IF bandwidths and narrower bandwidths noticeably improve performance - the received signal starts to come up to the level of the DC offset, but the instability and noise moving through are still there.

One thing I did notice is that using the gain settings in the gr-osmosdr source block (manual) I had to set them all to "0" even with a medium strength signal. The gain reduction may not be working properly in gr-osmosdr.

My next step will be to do a more detailed comparison of the commands sdr-j (the working program) and gr-osmosdr (the buggy program) are sending to the SDRplay to see if I missed something in my first comparison.

Again, any help or suggestions of things to try would be appreciated! So far I've only tried modifications to http://cgit.osmocom.org/gr-osmosdr/tree ... ource_c.cc. Should I be looking at any other files?

...Doug

[kg7bux]

Doug,

I am experiencing the same thing you are. Bouncing noise floor and a huge LO spike (actually more like an LO Eiffel Tower, because the bottom is so wide). I also tried increasing the buffer size from 504, but I went all the way to 1048576 (1024 * 1024). I couldn't tell any difference.

In GQRX I did notice that if I select the mirics driver instead of the sdrplay driver that the noise floor is no longer bouncing, and the spike is more like I would expect (a small spike instead of the Eiffel Tower). So looking at the miri_source_c.[ch] files may yield some clues. I suspect that using the mirics driver would not correctly select the front end filters as these are unique to the RSP.

I have tried with no success to compile sdr-j. I am having issues getting the right version of QT and QWT installed on Ubuntu 15.04. But it is reassuring to see the success others have had with sdr-j. At least there is hope in getting this running smoothly with gnuradio apps and Linux.

I would be willing to donate to the cause of getting Dimitri Stolnikov an RSP if that would help.

-Aaron
kg7bux

[Tech_Support]

Please bear in mind that Dimitri didn't develop the latest osmosdr library. We did, so it is asking a bit much to expect him to fix the issues. We are aware that there are problems with GQRX, and we will fix it, so please bear with us.

The Mirics library does not support the necessary front end switching, nor does it correctly provide the necessary control over the various gain stages.

Yours sincerely

SDRplay Tech_Support

[AH6DL]

I'm happy to see SDRplay Tech_Support is working on this, as I've exhausted all the simple source code changes to test that I could find. Also happy to hear we don't need to send Dimitri an SDRplay!

Kg7bux, thanks for the tip on the mirics source. I'm having a hard time following what's going on in sdr-j's CPP code and the mirics source should be much easier to compare to the sdrplay source. One side effect of trying to fix this is I'm learning more about how the SDRplay API works, which may be useful and with this info I'll take another look and see if I can see anything obvious.

73...
...Doug AH6DL

[AH6DL]

After hearing Kg7bux's better luck with GQRX and the miri driver, I gave it a try. It seemed a bit more stable, but using 1536e3 and 2e6 sample rates I saw USB buffer overflow messages. I hadn't noticed those on GRC but that certainly could cause the problems we've been seeing. The SDRplay didn't come with a USB cable and the only one I had that had a type "B" USB connector on it was left over from very old piece of gear now departed. It wasn't USB 2.0. I've ordered a USB 2.0 cable from DigiKey (the selection on A to B cables is limited) and we'll see if that makes a difference.

However, SDR-J does work fine with no buffer overflow messages, even on the antique USB cable, so there is a problem with the qr-osmosdr source code. Considering my issues with the miri gr-omsosdr code as well, I can see why this might be giving the SDRplay tech support folks some headaches. I really hope they can get it to work. SDR-J works okay but it is limited very limited in what it can do compared with the wide range of applications supporting gr-osmosdr.

Doing some comparisons with the FiFi-SDR (using Quisk) and SDRplay (using SDR-J) on the HF bands, the SDRplay holds up well on shortwave. MW and LW doesn't appear to be quite as good, although I'm still learning all the controls in SDR-J so it may not be the SDRplay's fault is doesn't seem to pick up KNX 1070 kHz from 2,500 miles away quite a cleanly as Quisk does at my location. (Summer-time propagation isn't that great anyway...)

...Doug AH6DL

[AH6DL]

Partial success!!

I compared the SDR-J code with the gr-osmosdr sdrplay_source.c.cc and found if I changed the 4096.0f in the output portion of the code to 32768.0f I had fewer hits. SDR-J only uses 32768.0f. I don't know enough about the API to know why 4096.0f was used in some cases and 32768.0f in others in the gr-osmosdr code. Perhaps tech support can explain, but I don't want to pull them away from their fixes!

Code: Select all

   if (_buf_offset)
   {
      for (int i = _buf_offset; i < _dev->samplesPerPacket; i++)
      {
         *out++ = gr_complex( float(_bufi[i]) * (1.0f/32768.0f), float(_bufq[i]) * (1.0f/32768.0f) );
      }
      cnt -= (_dev->samplesPerPacket - _buf_offset);
   }

   while ((cnt - _dev->samplesPerPacket) >= 0)
   {
      mir_sdr_ReadPacket(_bufi.data(), _bufq.data(), &sampNum, &grChanged, &rfChanged, &fsChanged);
      for (int i = 0; i < _dev->samplesPerPacket; i++)
      {
         *out++ = gr_complex( float(_bufi[i]) * (1.0f/32768.0f), float(_bufq[i]) * (1.0f/32768.0f) );
      }
      cnt -= _dev->samplesPerPacket;
   }

   _buf_offset = 0;
   if (cnt)
   {
      mir_sdr_ReadPacket(_bufi.data(), _bufq.data(), &sampNum, &grChanged, &rfChanged, &fsChanged);
      for (int i = 0; i < cnt; i++)
      {
         *out++ = gr_complex( float(_bufi[i]) * (1.0f/32768.0f), float(_bufq[i]) * (1.0f/32768.0f) );
      }
      _buf_offset = cnt;
   }
   _buf_mutex.unlock();

   return noutput_items;

I was still taking some hits on the data, but unlike the first experiments changing the buffer size, this time it seemed to make a difference:

Code: Select all

#define SDRPLAY_MAX_BUF_SIZE 524288

With these modifications I get a more stable display in GNURadio companion and GQRX almost works!



I'm still getting USB buffer overflow errors in GQRX, but not as many as before. The main problem now seems to be the total disconnect between what GQRX thinks it is getting and what gr-osmosdr is providing. Note that the sample rate is 2e6 (2 MHz) and the bandwidth is 0.6 MHz, but the display shows the span being around 96 kHz, even though the pedestal from the 600 kHz SDRplay filter is clearly visible. GQRX can't demodulate the signal.

I think I'm getting closer to a solution, but I'm now getting far deeper into the code than i intended to. Right now I see two issues -- USB output control (maybe a fifo is needed, as SDR-J uses) and communicating the right receiver state to GQRX.

By the way, I did have a chance to test it in Windows using the EXTIO plug-in and HDSDR and was very impressed with the performance from longwave (332 kHz beacon) to VHF (distant NOAA weather station at 162.4 MHz). Looking forward to having this unit working under Linux with something other than SDR-J!

Maybe my findings will help the tech support people.

73...
...Doug

[jon]

Hi Doug, many thanks for the update. I know our tech guys are working hard in parallel - this will spur them on.

Best regards, Jon