SDRplay Community Forum

Thanks Jon!

By the way, I found adding mir_sdr_SetDcTrackTime(63) after every mir_sdr_SetDcMode(4,1) pretty much eliminates the DC carrier.
We're very close -- I think there is a decimation occurring somewhere (not sure if it is GQRX or gr-osmosdr) that's messing up the FFT display and bandwidth, preventing demodulation. I can manually set the bandwidth to look good on the screen but it doesn't demodulate anything.



I'm still seeing buffer overflows as well, which may account for the minor frequency shifts visible in the waterfall.

...Doug AH6DL

WORKING!! (but with a few warts...)

I now have an FM GRC receiver working with my modified gr-osmosdr code. There are a few warts, but it is receiving and demodulating signals without errors.



For some reason the DC offset removal is not working as well in Gnuradio companion as it does in GQRX. However, unlike GQRX I can successfully demodulate FM audio and the FFT displays (pre and post filter) show the correct frequencies.

Another thing that's odd is the baseband gain and IF gain settings have no effect. The RF gain does, and I find it acts oddly, but not all the time. Sometimes it starts up with bad IQ balance and offset, but running up the RF gain then backing it down eliminates the image and reduces the relative DC offset.

I'm not getting any buffer overflows or underflows with my program. I think the overflows I were seeing in GQRX were due to mismatched sampling rates, which results in the bad frequency display and inability to demodulate any signals. I had overflow and crashing problems with the FM until I got the decimation ratios right and added the rational resampler before the WBFM demod. FM performance, by the way, is very good. I have an FM station a few miles from me and it causes other SDRs I have some overload problems that I'm not seeing on the SDRplay, making it easier to pull out weak FM signals.

I hope the tech team finds GRC file useful for debugging the gr-osmosdr driver and interface with GQRX.

The GRC code is available at:
http://transmitter.com/sdrplay/sdrplay- ... orking.grc

73...
...Doug

Hi
Any update on the progress of gr-osmosdr support?
(I've submitted a similar post in this forum, but that was for Mac support.
In fact I need to be able to work with SDRPlay from GNURadio on Mac OS X)
Thanks

I think I found the problem. The SDRplay API reads and returns the samples as 16-bit integers left justified. Gr-osmosdr incorrectly considers them right justified. I located this bug by writing samples out to a file and then looking at the waveform in audacity: all the samples had a mid level much higher than zero. Here is the patch:
--------------------------------------------------------------------------------------------------------------------
diff --git a/lib/sdrplay/sdrplay_source_c.cc b/lib/sdrplay/sdrplay_source_c.cc
index 81926a3..5cf11f1 100644
--- a/lib/sdrplay/sdrplay_source_c.cc
+++ b/lib/sdrplay/sdrplay_source_c.cc
@@ -238,7 +238,7 @@ int sdrplay_source_c::work( int noutput_items,
{
for (int i = _buf_offset; i < _dev->samplesPerPacket; i++)
{
- *out++ = gr_complex( float(_bufi) * (1.0f/2048.0f), float(_bufq) * (1.0f/2048.0f) );
+ *out++ = gr_complex( float(_bufi) * (1.0f/32768.0f), float(_bufq) * (1.0f/32768.0f) );
}
cnt -= (_dev->samplesPerPacket - _buf_offset);
}
@@ -248,7 +248,7 @@ int sdrplay_source_c::work( int noutput_items,
mir_sdr_ReadPacket(_bufi.data(), _bufq.data(), &sampNum, &grChanged, &rfChanged, &fsChanged);
for (int i = 0; i < _dev->samplesPerPacket; i++)
{
- *out++ = gr_complex( float(_bufi) * (1.0f/2048.0f), float(_bufq) * (1.0f/2048.0f) );
+ *out++ = gr_complex( float(_bufi) * (1.0f/32768.0f), float(_bufq) * (1.0f/32768.0f) );
}
cnt -= _dev->samplesPerPacket;
}
@@ -259,7 +259,7 @@ int sdrplay_source_c::work( int noutput_items,
mir_sdr_ReadPacket(_bufi.data(), _bufq.data(), &sampNum, &grChanged, &rfChanged, &fsChanged);
for (int i = 0; i < cnt; i++)
{
- *out++ = gr_complex( float(_bufi) * (1.0f/2048.0f), float(_bufq) * (1.0f/2048.0f) );
+ *out++ = gr_complex( float(_bufi[i]) * (1.0f/32768.0f), float(_bufq[i]) * (1.0f/32768.0f) );
}
_buf_offset = cnt;
}

Thanks for the solution, AH6DL. I didn't realize you fixed it already. I can second it at least and give my reason for the bug. 73

Thanks.
I can confirm that the .grc file (sdrplay-test-FM-receiver-20150630-working.grc) works.
OS X 10.10.5
GNURadio Companion 3.7.7
gr-osmosdr (compiled from latest git version and the above patch applied to it)

Hi,

I have compiled gr-osmosdr from latest git version and patch applied. Now I can use
osmocom_fft with good results. Was working before the patch as well, but needed certain
sample rate/bandwith ratios and the spektrum showed the noise level jumping. Playing with
these two parameters caused freezing of the program mostly.
It seems to bee more stable now with the patch. I was also able to get GQRX running and demodulating signals
with good results after I found some sample rates which seem to cause stable operation of GQRX.
But still have the noise floor level jumping up and down in GQRX. So it looks like we're on the right track...

73 de Fred, DL6BAW

Thanks kc2sci for finding the reason my small code change worked!

I hadn't had time to dig into it further. I suspected something like this was the problem after looking at the API sample code and SDR-J. Analyzing the IQ output was a great idea!

I haven't tried the patch with the latest gr-omsosdr release, but hope to have a chance to dig into it this weekend.

One of the things that would be nice to have is the ability to control some of the features present in the new EXTIO using gr-osmosdr's "-a" to feed additional options to the driver. I've been playing with it under Windows when I can take a break from work and have been happy with the performance, especially the option to set the DC removal mode. I got some great pictures from Meteor M-N2 yesterday using 200 kHz bandwidth and zero-IF without an LNA. It would be nice to be able to reliably use the Gnuradio Meteor M-N2 programs.

...Doug AH6DL

Update --

I had a chance to try the i/32768 value in sdrplay.c.cc with the latest gr-osmosdr version and found it didn't resolve the bouncing noise issue. Looking at the SDR-J code, I see they used 2*i/1024 and 2*i/8192 so I tried i/512 and i/4096 with the gr-osmosdr code. It had some problems. Increasing the first i/512 to i/1024 seemed to help, but didn't completely solve the issues. I think part of the problem may be how the I and Q signals are being buffered or read out from the SDRplay. I notice the API supports a synchronous mode. There are also some settings in the mirics API which SDR-J sets but the gr-osmosdr Mirics and SDRplay drivers don't. I wonder if that could be responsible for the variable behavior we're seeing.

It is well beyond my coding skills, but it would be interesting to see if someone could take some key routines from the SDR-J SDRplay input code and try it in gr-osmosdr.

...Doug, AH6DL