Linux

Add useful snippets of code or links to entire SDR projects.
Rebel
Posts: 20
Joined: Thu Jan 08, 2015 4:21 pm

Re: Linux

Post by Rebel » Tue Jul 28, 2015 4:41 pm

Compiled and installed the gr-osmosdr again, but with trying to use SDRPlay with GQRX still same issue than before...no change....

73 de Fred, DL6BAW
Last edited by Rebel on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason

Toontje
Posts: 67
Joined: Fri Aug 07, 2015 8:36 am

Re: Linux

Post by Toontje » Sat Aug 22, 2015 1:18 pm

Showing: "/root/untitled.grc"

Generating: "/root/top_block.py"

Executing: "/root/top_block.py"

linux; GNU C++ version 4.9.1; Boost_105500; UHD_003.007.003-0-unknown

Using Volk machine: sse4_2_64_orc
gr-osmosdr 0.1.3 (0.1.3) gnuradio 3.7.5
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy
Using device #0: Mirics MSi2500 default (e.g. VTX3D card)
usb_claim_interface error -6

FATAL: Failed to open mirisdr device.

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.


>>> Done


What's wrong here?


EDIT: One thing i see wrong here is the version of gnuradio. Updating now to 3.7.8.
Last edited by Toontje on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason

sdrplay
Posts: 978
Joined: Wed Jan 07, 2015 7:58 am

Re: Linux

Post by sdrplay » Sun Aug 23, 2015 1:18 am

If you don't see SDRplay support enabled but you see miri, that is an unofficial library that will not control all of the bands of the RSP. You need to make sure gr-osmosdr has been built with SDRplay support enabled.

Best regards,

SDRplay Support
Last edited by sdrplay on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason

AH6DL
Posts: 49
Joined: Sun Jun 14, 2015 7:24 am

Re: Linux

Post by AH6DL » Tue Sep 01, 2015 9:34 pm

I've been toying with the sdrplay_source_c.cc code in gr-osmosdr and am convinced the problem with the static, which leads to the unstable amplitude level, is caused by packets from the SDRplay being corrupted in sdrplay_source_c::work

I noticed that SDR-J, which doesn't experience this problem, handles the incoming packets differently in the sdrplay-worker.cpp code. Notice there is only one spot where the data is stored in the local (ring) buffer, not the three different spots as in the gr-osmosdr code. I suspect that in the gr-osmosdr code the I/Q data is either being dropped or inserted in the wrong place in the buffer, causing the static and, when a packet is completely corrupted, the wild amplitude swings.

Here is the relevant SDR-J code from sdr-j-swreceiver-6.0, sdrplay-worker.cpp file:

Code: Select all

//
//	The actual thread does not do much more than reading the
//	values made available through the Mirics API implementation
//	and passing the values on
//
void	sdrplayWorker:: run (void) {
DSPCOMPLEX	localBuf [sps];
int16_t		xi [sps];
int16_t		xq [sps];
uint32_t	fs;
int16_t		i;
int32_t		grc, rfc, fsc;
int	err;
int32_t		next	= 0;

	functions -> mir_sdr_SetSyncUpdatePeriod ((int)(deviceRate * MHz (1) / 2));
	functions -> mir_sdr_SetSyncUpdateSampleNum (sps);
	while (runnable) {
	   err =  functions ->
	       mir_sdr_ReadPacket (&xi [0], & xq [0], &fs, &grc, &rfc, &fsc);

//	currently, we are not interested in the results other than the actual
//	data
	   for (i = 0; i < sps; i ++) {
	      DSPCOMPLEX tmp = DSPCOMPLEX (xi [i] / 32768.0, xq [i] / 32768.0);
	      if (d_filter -> Pass (tmp, &tmp))
	         localBuf [next ++] 	= tmp;
	   }
	
	   _I_Buffer	-> putDataIntoBuffer (localBuf, next);
	   next		= 0;
//
	if (fsc != 0 || rfc != 0 ||grc != 0)
	   fprintf (stderr, "fsc = %d, rfc = %d, grc = %d\n",
	                     fsc, rfc, grc);
//	OK, data is now stored, now checking for updates
	   while (anyChange != NO_CHANGE) {
	      if (anyChange & FREQ_CHANGE) {
	         functions -> mir_sdr_SetRf (lastFrequency, 1, 0);
	         anyChange &= ~FREQ_CHANGE;
	      }
	      if (anyChange & GAIN_CHANGE) {
	         functions -> mir_sdr_SetGr (lastGain, 1, 0);
	         anyChange &= ~GAIN_CHANGE;
	      }
	      if (anyChange & RATE_CHANGE) {
	        int r =  functions -> mir_sdr_SetFs (deltaRate, 1, 1, 0);
	        if (r == 0)
	           deviceRate = deltaRate / MHz (1);
	         anyChange &= ~RATE_CHANGE;
	      }
	   }
	}
//	fprintf (stderr, "miricshelper now stopped\n");
}
This is used by the main sdrplay.cpp program to process the buffer:

Code: Select all

//
//	The brave old getSamples. For the mirics stick, most of the
//	work is done in the "worker", before putting data into the 
//	buffer
int32_t	sdrplay::getSamples (DSPCOMPLEX *V, int32_t size, uint8_t Mode) { 
int32_t		amount, i;
DSPCOMPLEX	buf [size];

	if (!deviceOK)
	   return 0;

	amount = _I_Buffer	-> getDataFromBuffer (buf, size);
	for (i = 0; i < amount; i ++)  {
	   switch (Mode) {
	      default:
	      case IandQ:
	         V [i] = buf [i];
	         break;

	      case QandI:
	         V [i] = DSPCOMPLEX (imag (buf [i]), real (buf [i]));
	         break;

	      case Q_Only:
	         V [i] = DSPCOMPLEX (real (buf [i]), 0.0);
	         break;

	      case I_Only:
	         V [i] = DSPCOMPLEX (imag (buf [i]), 0.0);
	         break;
	   }
	}
	return amount;
}

This approach seems a bit closer to the Mirics API than the code in gr-osmosdr and provides a completely stable and clean output (in SDR-J).

Unfortunately this is so different from the gr-osmosdr code for SDRplay (and Mirics, which has the same issues) that I haven't been able to figure out how to modify the gr-osmosdr SDRplay code to use this method. Any ideas?

...Doug AH6DL
Last edited by AH6DL on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason

amish
Posts: 6
Joined: Wed Sep 02, 2015 6:17 am

Re: Linux

Post by amish » Wed Sep 02, 2015 6:43 am

Hi Doug,

I have also made a preliminary analysis of gr-osmocom and sdr-j.

I found that gr-osmocom sets a sample rate too low and SDRplay does not accept that. Setting sample rate to 5e+6 makes the Sdrplay reply and I can use osmocom_fft to display the spectrum and verified the presence of local fm station on the spectrum.

Will dig deeper in gr-osmocom first to attempt a fix, hopefully on the weekend.

73,
Amish (VU2AIE)
Last edited by amish on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason

sdrplay
Posts: 978
Joined: Wed Jan 07, 2015 7:58 am

Re: Linux

Post by sdrplay » Wed Sep 02, 2015 2:47 pm

When you say unstable - are you getting USB buffer underruns or overruns?

Also, what sample rate are you having issues with?

Thanks,

SDRplay Support
Last edited by sdrplay on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason

AH6DL
Posts: 49
Joined: Sun Jun 14, 2015 7:24 am

Re: Linux

Post by AH6DL » Wed Sep 02, 2015 3:46 pm

For my testing, I've found setting the sample rate at 1536e3 and the bandwidth to the same amount works, although with the unstable display and static. I've also had luck with 2048e3. I'll try 5e6 and see if that makes a difference.

For what it's worth, after the last changes to the gr-osmosdr SDRplay code I haven't seen any issues with buffer underflow or overflow. That was an issue with the older versions of gr-osmosdr but is fixed in the latest release. I'll probably have to look at the numeric data out of the source block to see exactly what's going on, but with the wider bandwidth and large amount of data may b difficult to analyze. Perhaps using a local FM station and comparing the IQ data from SDR-J and gr-osmosdr might provide some clues as to where the problem is.


...Doug AH6DL
Last edited by AH6DL on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason

AB3XU
Posts: 3
Joined: Wed Sep 02, 2015 6:18 pm

Re: Linux

Post by AB3XU » Wed Sep 02, 2015 8:02 pm

@AH6DL how does SDR-J-FM work for you as compared with SDR-J-SW? I'm asking because the files you are looking at for SW at are dated Sep 22 2014. The ones for FM are Feb 17 2015 and are a fair amount different.

The only decent antenna I have to work with is a 2m ground plane so mostly I'm playing with the 2m band, 70cm and the NOAA stations.

With a out of the box git repository build I get the same static you are talking about, I don't think the osmosdr bw makes a difference.

Below is the flowgraph I'm working with, I didn't seem to be able to attach the grc file.

Doug, I really appreciate all your experimentation and even more so posting your thoughts and results regarding them. I've been looking over all of theposts here but I'm brand new to SDRs and my meager coding skills are mostly with python so when it dives into C++ Im pretty lost.

73
digger, ab3xu
Attachments
2m-fm-04.grc.png
2m-fm-04.grc.png (93.14 KiB) Viewed 33918 times
Last edited by AB3XU on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason

AH6DL
Posts: 49
Joined: Sun Jun 14, 2015 7:24 am

Re: Linux

Post by AH6DL » Wed Sep 02, 2015 10:09 pm

@AB3XU

SDR-J FM works okay but the audio isn't especially clean. As with most SDRs and GQRX, FM stereo is tough without strong signals. Note that the sdr-j shortwave receiver actually does a good job with VHF and UHF NBFM -- it isn't restricted in the frequency range!

I haven't looked at the code in the sdr-j-fm receiver but did look at the spectrum analyzer code. The shortwave code is the most straight-forward (easiest to understand), but the spectrum analyzer code is a little closer to the gr-osmosdr code. I tried modifying the gr-osmosdr code to use parts of the sdrplay input code for the spectrum analyzer. It eliminated the static and the amplitude jumping but introduced a strong alias frequency, probably due to samples being lost somewhere, that made reception difficult.

I may be looking in the wrong place, but it appears the sdr-j code is using functions from the API in its packet reading section that I don't see in the gr-osmosdr code, specifically the mir_sdr_SetSyncUpdatePeriod and mir_sdr_SetUpdateSampleNum. It may be that these are being set to some random value, which is why different people have different experiences with SDRplay and gr-osmosdr.

Python is my language of choice as well. The problem I'm having moving the sdr-j code over to gr-osmosdr is not only are variables, functions and classes named differently, they were written in two slightly different versions of C so the style is different. I've tried modifying the existing code, but it looks like the only thing that's going to solve the problem is replacing the entire sdrplay_source_c::work and changing all the references to it to match the new code.

Once we get gr-osmosdr working in default modes, the next job will be to add code to allow arguments to be passed from gr-osmosdr to the SDRplay. I think SDRplay would work fine with ADSB (gr-airmodes) if I was able to widen the bandwidth. As it is, it defaults to 2e6, which is just a bit too narrow for gr-airmodes. It would be really nice if the SDRplay team could allow a way for all of the values exposed in the latest EXTIO to also be available in gr-osmosdr, even if some have to be manually added to the device string to change them.

...Doug
Last edited by AH6DL on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason

amish
Posts: 6
Joined: Wed Sep 02, 2015 6:17 am

Re: Linux

Post by amish » Thu Sep 03, 2015 6:06 am

I tried with sample rate of 5M and got buffer overflow. Will try with a lower sample rate and update.

Since Osmocom_fft works with out any buffer issue when sample rate is set to 5M, I think I also have to check how gqrx is handling the signal.
Last edited by amish on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason
73
VU2AIE

Post Reply