Re: [Discuss-gnuradio] usrp_spectrum_sense.py

[Marcus Müller]

Hi Murat,

a few quick comments:

On 23.05.2017 20:24, MuratCA77 wrote:
> The current outputs produced by the usrp_spectrum_sense.py code do not
> provide the bin metrics that are required for my application.
Yeah, usrp_spectrum_sense hasn't aged all that well. I think if I were
to implement that today, it would look totally different internally.
> The metrics are 
> detection time,
that might actually be pretty interesting to implement; as far as I
know, the HackRF currently doesn't support time-stamping (don't know,
though – this might have changed or will be changing).
>  true detection power, 
That's a hard one! You'll need to calibrate your receiver first; none of
the "popular" SDR devices, including USRPs and HackRF, are calibrated
power measurement devices. Thus, you'll need to generate a signal of
interest for a few known powers at every frequency that you want to step
to, or else you won't get a physical power, just digital numbers (which
might or might not, in general the latter, be comparable between
different frequencies!).

> the center frequency of the
> transmission, the centroid,
Good news: for all practical single-carrier systems, transmission
centroid and center frequency usually are the same. If you think about
it, that makes sense: you have finite energy to spend on transmitting,
so you'll use your bandwidth to the fullest extent. From an
information-theoretical point of view: Anything that makes the spectrum
look skewed means there's redundant info that shouldn't be transmitted.
>  and transmission bandwidth. 
You'd first have to define what "bandwidth" is – a definition of
bandwidth that works well for e.g. a given GMSK signal (e.g. 2G) might
be totally inappropriate e.g. for a CDMA signal (3G, WiFi) and might not
be overly helpful in understanding multicarrier waveforms (as OFDM, eg.
4G, WiFi). Also, when you observe an FM audio station for a short time
while the audio source is relatively quiet, you'll see a smaller
bandwidth than midst-song when everything is loud and the frequency
deviation gets large!
So, you'd first have to restrict the types of signals you're looking
for; later, you can implement more cases, but what you want to build is
a fully-fledged signal classificator, and well, those things are a lot
of work, and you'll have to define a reasonable observation time vs.
speed tradeoff to ensure proper detection of the signal you're looking
at whilst keeping the likelihood of simply missing transmissions (by not
scanning over them at all while they're active).

I think you might want to look at https://github.com/gnuradio/gr-inspector

Best regards,
Marcus