Re: [Discuss-gnuradio] Do embedded python blocks in grc allow for different output than input?

[Sebastian Koslowski]

Yes, however double is not in the list (maybe you want float32?).
Anyway, I fixed that a while a ago, but seemed to have forgotten to
upstream it:
https://github.com/skoslowski/gnuradio/commits/epy_block_port_map

Sebastian

On Mon, Jun 5, 2017 at 5:37 AM G Reina  wrote:

> I see that GRC had an "embedded python" block.  I'd like to take a
> np.complex64 input, process it in Python, and return a np.float64. When I
> try to modify the python code to do this I get the error:
>
> Param - Code(_source_code):
>> Can't map dtype('float64') to GRC port type
>>
>>
> Can having a different input and output type only be done with an OOT
> module?
>
> Thanks.
> -Tony
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Do embedded python blocks in grc allow for different output than input?

[G Reina]

That's great.

Thanks so much.
Tony

On Jun 5, 2017 12:34 AM, "Sebastian Koslowski" <
sebastian.koslow...@gmail.com> wrote:

> Yes, however double is not in the list (maybe you want float32?).
> Anyway, I fixed that a while a ago, but seemed to have forgotten to
> upstream it:
> https://github.com/skoslowski/gnuradio/commits/epy_block_port_map
>
> Sebastian
>
> On Mon, Jun 5, 2017 at 5:37 AM G Reina  wrote:
>
>> I see that GRC had an "embedded python" block.  I'd like to take a
>> np.complex64 input, process it in Python, and return a np.float64. When I
>> try to modify the python code to do this I get the error:
>>
>> Param - Code(_source_code):
>>> Can't map dtype('float64') to GRC port type
>>>
>>>
>> Can having a different input and output type only be done with an OOT
>> module?
>>
>> Thanks.
>> -Tony
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] UHD recv demuxer errors with a simple Python flowgraph

[Pierre Baudry]

Hi,

While working with gr-gsm blocks and examples I ran into some weird UHD
errors.

I tried to reduce as much as possible the flowgraph complexity, and
ended up writing a very simple flowgraph that seems to reliably trigger
the UHD errors.

I uploaded the flowgraph here:
https://gist.github.com/anonymous/d3c0c9f1f72ab7cdc2c3460126682bc6

The point of this flowgraph is to simply tune into a frequency, acquire
some samples and proceed with a new acquisition. This is similar to what
grgsm-scanner does, with the sample analysis removed.

On my hardware (Xeon E5-2650 with USRP B200 on USB3), this flowgraph
will produce a lot of UHD errors every time such as:

> Tuning to 1934.301035 MHz
> Acquisition N° 13 finished
> 
> Tuning to 1619.216092 MHz
> 
> UHD Error:
> recv packet demuxer unexpected sid 0xc449c000
> 
> UHD Error:
> recv packet demuxer unexpected sid 0x44208000
> 
> UHD Error:
> recv packet demuxer unexpected sid 0xc4064000
> 
> UHD Error:
> recv packet demuxer unexpected sid 0xc278
>  snip 

Am I doing something the wrong way ?
Is there a limitation of some kind with the way I retune the USRP ?
I first thought that these errors were tied to the processing power
required but the flowgraph I wrote just trashes received samples so this
is very unlikely.

Best,
Pierre

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] High Water Mark - ZMQ Message Blocks

[Dave NotTelling]

I noticed that the message base ZMQ blocks don't support high water marks
(HWM) but the streaming ones do.  Is there a specific reason for that, or
is it just the way those blocks were developed?

Thanks!
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] usrp_spectrum_sense.py

[Marcus Müller]

>  Does it give
> me the metrics that I need?

No, but that's because the metrics you *describe* are not the metrics
you *need*. Your application is totally underspecified, and because
there can be no single proper estimator for all kinds of modulations, as
I tried to explain in my lengthy answer to which you replied. Please do
your homework and properly design a specification for all your signal
and what you want to measure, and then you'll be able to decide what
needs to be done to sense exactly that.

Also, don't use Nabble, but directly subscribe to the mailing list under
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio .

Best regards,

Marcus



On 02.06.2017 21:09, GNUBeginner wrote:
> Hello Marcus,
>
> Could you please tell me your thoughts about hackrf_sweep code? Does it give
> me the metrics that I need?
>
> Thanks
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/usrp-spectrum-sense-py-tp63994p64111.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Custom C++ blocks on E310

[Marcus Müller]

Hi Jessica,

not 100% sure you're right about timed commands not being supported on
the E310 – yes, things like tuning and setting the gain can't be timed
on the E310, but I thought stream commands should work. Will check.

Best regards,

Marcus


On 02.06.2017 19:16, Jessica Iwamoto wrote:
>
> Hi all,
>
>  
>
> We’re trying to implement a fast sweep over a range of frequencies on
> the E310. Currently, I have a Python block that takes in a stream from
> the USRP Source, counts up the number of samples, and after receiving
> n samples, issues a stream command to the USRP Source to receive n
> more samples. There is currently a delay (of a few ms) between when
> the stream command is issued and when the work function of my custom
> block is called, and we are trying to find ways to shorten this delay.
> We can’t use timed commands because they are not supported in the E310
> and it doesn’t look like you can queue up a series of stream commands
> either. We also can’t use a custom C++ block because of the issues
> discussed previously in this email thread.
>
>  
>
> Does anyone have ideas on what to try? Or, could you point me to the
> relevant UHD code, as it is a bit confusing to follow? Also, are there
> any plans to add support for timed commands in the E310 or for a queue
> of stream commands?
>
>  
>
> Thank you,
>
> Jessica
>
>  
>
>  
>
> *From:*Discuss-gnuradio
> [mailto:discuss-gnuradio-bounces+jessica.iwamoto=aero@gnu.org] *On
> Behalf Of *Marcus Müller
> *Sent:* Wednesday, May 24, 2017 12:26 PM
> *To:* discuss-gnuradio@gnu.org; Philip Balister 
> *Subject:* Re: [Discuss-gnuradio] Custom C++ blocks on E310
>
>  
>
> Hi Jessica,
>
> that's really interesting!
>
> It means that the problem only happens when you use your compiler to
> build your C++ blocks, but not when only using the GNU Radio that's
> already part of your image. Not quite sure what that entails; maybe it
> means that openembedded builds broken SDKs... That shouldn't happen.
> The other thing I could think of would be a slight misconfiguration of
> the compiler (or the linker). Maybe Philip has an idea!
>
> Best regards,
>
> Marcus
>
>  
>
>  
>
> On 24.05.2017 20:51, Jessica Iwamoto wrote:
>
> Hi all,
>
>  
>
> I never found the solution to this problem, but I ended up using a
> work around by writing my custom blocks in Python instead of C++.
>
>  
>
> Jessica
>
>  
>
> *From:*Discuss-gnuradio
> [mailto:discuss-gnuradio-bounces+jessica.iwamoto=aero@gnu.org]
> *On Behalf Of *Jessica Iwamoto
> *Sent:* Monday, May 15, 2017 8:38 AM
> *To:* Ben Hilburn 
> 
> *Cc:* discuss-gnuradio@gnu.org 
> *Subject:* [WARNING: SPOOFED E-MAIL--Non-Aerospace Sender] Re:
> [Discuss-gnuradio] Custom C++ blocks on E310
>
>  
>
> Hi Ben,
>
>  
>
> Here is some of the backtrace from the error. At the top level,
> the error starts in the msg_connect function and it looks like it
> gets tripped up reading something from memory when checking for a
> valid message port.
>
>  
>
> #0  0xb635c67c in fetch_add (order=boost::memory_order_relaxed, v=1,
>
> storage=@0x6: )
>
> at /home /prefix
> 
> /sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:100
>
> #1  fetch_add (order=boost::memory_order_relaxed, v=1, this=0x6)
>
> at /home /prefix
> 
> /sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/atomic/detail/atomic_template.hpp:115
>
> #2  pmt::intrusive_ptr_add_ref (p=0x2)
>
> at /home /prefix /src/gnuradio/gnuradio-runtime/lib/pmt/pmt.cc:69
>
> #3  0xb63e56e4 in intrusive_ptr (rhs=..., this=0xbeffec7c)
>
> at /home /prefix
> 
> /sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/smart_ptr/intrusive_ptr.hpp:92
>
> #4  gr::flowgraph::check_valid_port (this=this@entry=0x10c578, e=...)
>
> at /home /prefix
> /src/gnuradio/gnuradio-runtime/lib/flowgraph.cc:162
>
> #5  0xb63e95d0 in gr::flowgraph::connect
> (this=this@entry=0x10c578, src=...,
>
> dst=...)
>
> at /home /prefix
> /src/gnuradio/gnuradio-runtime/lib/flowgraph.cc:503
>
> #6  0xb63f4c84 in gr::hier_block2_detail::msg_connect (
>
> this=this@entry=0x10c528, src=..., srcport=..., dst=...,
> dstport=...)
>
> at /home /prefix
> /src/gnuradio/gnuradio-runtime/lib/hier_block2_detail.cc:198
>
> #7  0xb63f1b14 in gr::hier_block2::msg_connect
> (this=this@entry=0x0, src=...,
>
> srcport=..., dst=..., dstport=...)
>
> at /home /prefix
> /src/gnuradio/gnuradio-runtime/lib/hier_block2.cc:104
>
> #8  0xb5cd6958 in _wrap_top_block_sptr_primitive_msg_connect__SWIG_1 (
>
> args=)
>
> at /home
> 
> /prefix_new/src/gnuradio/build-arm/gnuradio-runtime/swig/runtime_swigPYTHON_wrap.cxx:47551
>
>  
>
> T

Re: [Discuss-gnuradio] Rational Resampler no output.

[Marcus Müller]

Hi Cor,

Excuse the language, but frk. Ok, looks like we have a bug in
low_pass. Or in GCC. Or SWIG (which does the python-wrapping of the code
in firdes.cc). yay.

So, let's narrow this down: on intel and amd64, same number of taps, right?

Then: If I asked you to use GDB to verify the C++ low_pass function in
gr::filter::firdes::low_pass actually returned the right float values,
would you feel that, with a few hints, be able to do that?

Best regards,

Marcus


On 01.06.2017 07:20, Cor Legemaat wrote:
> Hi:
>
> filter.firdes.low_pass get called with:
>  * fractional_bw = 0.4
>  * trans_width = 0.1
>  * mid_transition_band = 0.45
>  * interpolation = 24
>
> But return: (nan, <788 times nan>)
>
> Regards:
> Cor
>
> On Tue, 2017-05-30 at 00:06 +0200, Marcus Müller wrote:
>> Hi Cor,
>>>  * When using 1 as "taps" there is output.
>>  Aha!!
>> So, here's the thing: something might be going wrong in the python
>> code that sets up the taps automatically if you don't set them
>> explicitly. 
>> Maybe you can figure out where things go wrong; the interesting part
>> (maybe add some `print`s here?) from [1]:
>>
>> # If we don't have user-provided taps, reduce the interp and
>> # decim values by the GCD (if there is one) and then define
>> # the taps from these new values.
>> if taps is None:
>> interpolation = interpolation // d
>> decimation = decimation // d
>> taps = design_filter(interpolation, decimation,
>> fractional_bw)
>>
>> and
>>
>>
>> def design_filter(interpolation, decimation, fractional_bw):
>> """
>> Given the interpolation rate, decimation rate and a fractional
>> bandwidth,
>> design a set of taps.
>>
>> Args:
>> interpolation: interpolation factor (integer > 0)
>> decimation: decimation factor (integer > 0)
>> fractional_bw: fractional bandwidth in (0, 0.5)  0.4 works
>> well. (float)
>> Returns:
>> : sequence of numbers
>> """
>>
>> if fractional_bw >= 0.5 or fractional_bw <= 0:
>> raise ValueError, "Invalid fractional_bandwidth, must be in
>> (0, 0.5)"
>>
>> beta = 7.0
>> halfband = 0.5
>> rate = float(interpolation)/float(decimation)
>> if(rate >= 1.0):
>> trans_width = halfband - fractional_bw
>> mid_transition_band = halfband - trans_width/2.0
>> else:
>> trans_width = rate*(halfband - fractional_bw)
>> mid_transition_band = rate*halfband - trans_width/2.0
>>
>> taps = filter.firdes.low_pass(interpolation,
>> # gain
>>   interpolation,
>> # Fs
>>   mid_transition_band,  
>> # trans mid point
>>   trans_width,  
>> # transition width
>>   filter.firdes.WIN_KAISER,
>>   beta) 
>> # beta
>>
>> return taps
>>
>>
>>
>> Best regards,
>> Marcus
>>
>> [1] https://github.com/gnuradio/gnuradio/blob/master/gr-filter/python
>> /filter/rational_resampler.py
>>
>> On 29.05.2017 19:01, Cor Legemaat wrote:
>>> Hi:
>>>
>>>  * The only warning is about the thread priority but that's on
>>> both.
>>>  * Type "Complex->Complex (Complex Taps)"
>>>  * When using 1 as "taps" there is output.
>>>
>>> I can open it in Nemiver if I know where to put the break point...
>>>
>>> Regards:
>>> Cor
>>>
>>> On Mon, 2017-05-29 at 11:36 +0200, Marcus Müller wrote:
 Hi Cor,
 that's kind of surprising¹. My first bet is that your AMD system
 is
 missing some dependency that the intel system has, so that
 something
 goes wrong during build. But then again, you shouldn't be seeing
 the
 rational resampler block at all in that case. Let's head straight
 to
 debugging:
 * Do you get any warning/console output during the execution of
 that
 flow graph?
 * Which is the input/output type (float or complex, orange or
 blue
 connector in GRC, if using that)
 * If in GRC: when explicitly using [1,] as "taps", do you get
 output?
 Best regards,
 Marcus

 ¹ "wat?!"

 On 29.05.2017 06:35, Cor Legemaat wrote:
> Hi:
>
> I have 2 different hardware setup's with funtoo/gentoo and
> gnuradio
> installed. On the Intel system the "Rational Resampler" is
> working
> correctly but on the AMD system there is no output. This is on
> a
> flow
> graph for an basic wide band fm receiver based on the USPR
> 10min fm
> receiver tutorial.
>
> AMD system:
>  * AMD FX(tm)-8150 Eight-Core Processor
>  * CPU_FLAGS_X86="aes avx fma4 mmx mmxext popcnt sse sse2 sse3
> sse4_1 sse4_2 sse4a ssse3 xop"
>
> Intel system:
>  * Intel(R) Core(TM) i5-2430M CPU @ 2.40GHz
>  * CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3
> sse4_1
>>>

Re: [Discuss-gnuradio] High Water Mark - ZMQ Message Blocks

[Marcus Müller]

Hi Dave,

yep, GR messages are back-pressure-free, so that's by design.

Best regards,

Marcus


On 05.06.2017 15:35, Dave NotTelling wrote:
> I noticed that the message base ZMQ blocks don't support high water
> marks (HWM) but the streaming ones do.  Is there a specific reason for
> that, or is it just the way those blocks were developed?
>
> Thanks!
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD recv demuxer errors with a simple Python flowgraph

[Marcus Müller]

Hi Pierre,

that looks more like a USB communication breakdown than an issue with
your software.

just as a quick test: if you set the sampling rate to something USB2 can
handle (e.g. 8 MHz or lower), does that work with a USB2-only port (ie.
pick one that's not blue)? Some USB3 port controllers just misbehave.

Best regards,

Marcus


On 05.06.2017 15:01, Pierre Baudry wrote:
> Hi,
>
> While working with gr-gsm blocks and examples I ran into some weird UHD
> errors.
>
> I tried to reduce as much as possible the flowgraph complexity, and
> ended up writing a very simple flowgraph that seems to reliably trigger
> the UHD errors.
>
> I uploaded the flowgraph here:
> https://gist.github.com/anonymous/d3c0c9f1f72ab7cdc2c3460126682bc6
>
> The point of this flowgraph is to simply tune into a frequency, acquire
> some samples and proceed with a new acquisition. This is similar to what
> grgsm-scanner does, with the sample analysis removed.
>
> On my hardware (Xeon E5-2650 with USRP B200 on USB3), this flowgraph
> will produce a lot of UHD errors every time such as:
>
>> Tuning to 1934.301035 MHz
>> Acquisition N° 13 finished
>>
>> Tuning to 1619.216092 MHz
>>
>> UHD Error:
>> recv packet demuxer unexpected sid 0xc449c000
>>
>> UHD Error:
>> recv packet demuxer unexpected sid 0x44208000
>>
>> UHD Error:
>> recv packet demuxer unexpected sid 0xc4064000
>>
>> UHD Error:
>> recv packet demuxer unexpected sid 0xc278
>>  snip 
> Am I doing something the wrong way ?
> Is there a limitation of some kind with the way I retune the USRP ?
> I first thought that these errors were tied to the processing power
> required but the flowgraph I wrote just trashes received samples so this
> is very unlikely.
>
> Best,
> Pierre
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD recv demuxer errors with a simple Python flowgraph

[mleech]

You might also try specifying num_recv_frames=128 or 256 in the device
args, to see if that helps the USB subsystem 

On 2017-06-05 15:15, Marcus Müller wrote:

> Hi Pierre,
> 
> that looks more like a USB communication breakdown than an issue with
> your software.
> 
> just as a quick test: if you set the sampling rate to something USB2 can
> handle (e.g. 8 MHz or lower), does that work with a USB2-only port (ie.
> pick one that's not blue)? Some USB3 port controllers just misbehave.
> 
> Best regards,
> 
> Marcus
> 
> On 05.06.2017 15:01, Pierre Baudry wrote: Hi,
> 
> While working with gr-gsm blocks and examples I ran into some weird UHD
> errors.
> 
> I tried to reduce as much as possible the flowgraph complexity, and
> ended up writing a very simple flowgraph that seems to reliably trigger
> the UHD errors.
> 
> I uploaded the flowgraph here:
> https://gist.github.com/anonymous/d3c0c9f1f72ab7cdc2c3460126682bc6
> 
> The point of this flowgraph is to simply tune into a frequency, acquire
> some samples and proceed with a new acquisition. This is similar to what
> grgsm-scanner does, with the sample analysis removed.
> 
> On my hardware (Xeon E5-2650 with USRP B200 on USB3), this flowgraph
> will produce a lot of UHD errors every time such as:
> 
> Tuning to 1934.301035 MHz
> Acquisition N° 13 finished
> 
> Tuning to 1619.216092 MHz
> 
> UHD Error:
> recv packet demuxer unexpected sid 0xc449c000
> 
> UHD Error:
> recv packet demuxer unexpected sid 0x44208000
> 
> UHD Error:
> recv packet demuxer unexpected sid 0xc4064000
> 
> UHD Error:
> recv packet demuxer unexpected sid 0xc278
>  snip  Am I doing something the wrong way ?
> Is there a limitation of some kind with the way I retune the USRP ?
> I first thought that these errors were tied to the processing power
> required but the flowgraph I wrote just trashes received samples so this
> is very unlikely.
> 
> Best,
> Pierre
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] usrp_spectrum_sense.py

[GNUBeginner]

Hello Marcus,

Here is the requirements. I was planning to modify osmocom_spectrum_sense.py
code for these requirements and would appreciate your guidance/support. I am
very new to python and think that there needs to be minor modification such
as adding another class for decimation.

• Tuning Range: It will scan the band from 100 MHz to 6 GHz.  This tuning
range can be configurable. 
• Patches: The scanner will stop at interim frequencies to analyze a 20 MHz
"patch."  This patch width can also be configurable.
• No gaps: The full 5.9 GHz band will be covered presumably with no gaps in
coverage.
• Dynamic Range: It will optimize the effective dynamic range of the
receiver by dynamically controlling the three gains.  This will not be a
manual process but should be implemented as a MIMO feedback loop.  The
fastest loop be the loop farthest from the antenna.  The slowest will be the
loop closest to the antenna.  To keep it simple, each loop could be
implemented as a single pole recursive filter.  
• Metrics:  The scanner will collect samples and then analyze the patch and
compute metrics on emissions within the patch.  Metrics will include the
center frequency or power centroid and the band edges of emissions.
• Thresholding: The threshold used to detect emission will be dynamically
adjusted similarly to the gain controller.  The radio app will likely base
the threshold as some dB level above the noise floor.
• False alarms:  We don't want the radio app to report noise floor
detections, so detection false alarms will be minimized using the threshold
algorithm and perhaps a minimum emitter bandwidth constraint.  It would be
nice to show mathematically that this threshold achieves some false alarm
probability such as 1e-5.  The threshold should be configurable and that the
default is such that the app has a 1e-5 false alarm rate.
• Logging of metrics:  The metrics will be stored to a console and to a
file.  To elaborate this, the metrics will need at a minimum the following
information in order to be useful: time, centroid/center frequency, band
edges of the emitter, band power of the emitter (note that this is an
integrated metric across the emitter bandwidth, not the peak power of the
centroid.)

Thanks,




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/usrp-spectrum-sense-py-tp63994p64141.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] usrp_spectrum_sense.py

[Marcus Müller]

As I said, your "metrics" aren't clear for different kind of signals.
What's the bandwidth of a rectangular pulse-shaped OOK? is it only the
main lobe? Is it multiple lobes? where do you cut off? What about spread
spectrum? What about multicarrier systems?
You use things like "dynamically adjusted", but you first have to come
up with a mathematical definition for what the target of that adjustment
is.
Same goes for your "False Alarms" section: you say you want to have a
false alarm rate of 1e-5. False alarm of detecting *what*, exactly? You
forget that there's not a single type of signal on the air, but all
kinds of different signals!

Best regards,
Marcus

PS: I will not respond to anything posted via Nabble from here on.
On 05.06.2017 21:39, GNUBeginner wrote:
> Hello Marcus,
>
> Here is the requirements. I was planning to modify osmocom_spectrum_sense.py
> code for these requirements and would appreciate your guidance/support. I am
> very new to python and think that there needs to be minor modification such
> as adding another class for decimation.
>
> • Tuning Range: It will scan the band from 100 MHz to 6 GHz.  This tuning
> range can be configurable. 
> • Patches: The scanner will stop at interim frequencies to analyze a 20 MHz
> "patch."  This patch width can also be configurable.
> • No gaps: The full 5.9 GHz band will be covered presumably with no gaps in
> coverage.
> • Dynamic Range: It will optimize the effective dynamic range of the
> receiver by dynamically controlling the three gains.  This will not be a
> manual process but should be implemented as a MIMO feedback loop.  The
> fastest loop be the loop farthest from the antenna.  The slowest will be the
> loop closest to the antenna.  To keep it simple, each loop could be
> implemented as a single pole recursive filter.  
> • Metrics:  The scanner will collect samples and then analyze the patch and
> compute metrics on emissions within the patch.  Metrics will include the
> center frequency or power centroid and the band edges of emissions.
> • Thresholding: The threshold used to detect emission will be dynamically
> adjusted similarly to the gain controller.  The radio app will likely base
> the threshold as some dB level above the noise floor.
> • False alarms:  We don't want the radio app to report noise floor
> detections, so detection false alarms will be minimized using the threshold
> algorithm and perhaps a minimum emitter bandwidth constraint.  It would be
> nice to show mathematically that this threshold achieves some false alarm
> probability such as 1e-5.  The threshold should be configurable and that the
> default is such that the app has a 1e-5 false alarm rate.
> • Logging of metrics:  The metrics will be stored to a console and to a
> file.  To elaborate this, the metrics will need at a minimum the following
> information in order to be useful: time, centroid/center frequency, band
> edges of the emitter, band power of the emitter (note that this is an
> integrated metric across the emitter bandwidth, not the peak power of the
> centroid.)
>
> Thanks,
>
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/usrp-spectrum-sense-py-tp63994p64141.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] High Water Mark - ZMQ Message Blocks

[Dave NotTelling]

Thanks!

On Mon, Jun 5, 2017 at 3:13 PM, Marcus Müller 
wrote:

> Hi Dave,
>
> yep, GR messages are back-pressure-free, so that's by design.
>
> Best regards,
>
> Marcus
>
> On 05.06.2017 15:35, Dave NotTelling wrote:
>
> I noticed that the message base ZMQ blocks don't support high water marks
> (HWM) but the streaming ones do.  Is there a specific reason for that, or
> is it just the way those blocks were developed?
>
> Thanks!
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Question about "Integrate" block/number of samples

[Ellie White]

Hello,

I've taken Marcus's suggestion to use the integration block to average
samples taken with my loop antenna, and that is working extremely well for
my purposes! However, I do have a question about something I don't quite
understand - I'm hoping someone can point me in the right direction.

I've attached the flowgraph I'm using to this email. My sampling rate is
set to 614400 samp/s, and input from the source is run through a
"Stream-to-Vector" block and a 2048 point FFT block. I then take the power
of the output from the FFT block, and pass that on to an Integrate block,
with decimation set to 18000.

So, my question is this. I took data for about hour with this setup, and
then mapped the resulting file to a numpy array. I took the len() of an
element of that array, and it was 2048, as expected. However, the length of
the whole array was 111 (i.e. there were 111 vectors of 2048, or 227328
samples total), and I was expecting it to be 60 based on my calculations.

Here is how I got the value 60: I multiplied 3600*614400=221184 to get
the total number of samples I would expect to collect in an hour without
decimation. Then, I divided this by 2048 to get the number of vectors
produced in an hour (108). Since decimation is set to 18000, I divided
108 by 18000 to determine how many vectors would result from the
integration block, which turned out to be 60. But this is obviously wrong -
it's only about half of the actual number of vectors saved to the file. I'm
sure I'm probably making some kind of silly error with my math or
reasoning, so I would really appreciate hearing anyone's input on this.

Thanks in advance!

Ellie


rtl-sdr.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] IO types in GRC xml files

[Vipin Sharma]

My application requires a custom GRC block. Everything seems to work Ok
except in the last stage where we are supposed to create the xml file so
that the block is visible in the GRC gui.

When I instantiate the custom block in GRC GUI and double click on the
block, I see several errors such as "Type Complex is not a possible type"
in the dialog box that pops up.

I thought Complex is one of the supported types in gnu radio. Why does that
warning show up?

Here is the small excerpt of the xml code:

  
  
EstimatedCh
Complex
  

Vipin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] IO types in GRC xml files

[Moritz Luca Schmid]

Hi Vipin,

My application requires a custom GRC block. Everything seems to work 
Ok except in the last stage where we are supposed to create the xml 
file so that the block is visible in the GRC gui.


When I instantiate the custom block in GRC GUI and double click on the 
block, I see several errors such as "Type Complex is not a possible 
type" in the dialog box that pops up.


I thought Complex is one of the supported types in gnu radio. Why does 
that warning show up?


you are not wrong, complex is a supported type in gr.



Here is the small excerpt of the xml code:

  
  
EstimatedCh
Complex
  


But be careful: XML files are case sensitive, so you should write 
'complex' instead of 'Complex'.


If you are not that familiar with XML files, you can let gr_modtool 
makexml do some work for you.


And if you are not sure about the XML syntax, simply 'use the source' 
and search for an existing gr block's xml file with the same 
parameter/input/output type and check out its use.



Regards
Luca

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio