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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
