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 err
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 "Typ
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'
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
> (
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"
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 Rang
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
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 ju
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 i
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
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
> 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 t
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
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/a
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/
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 "e
16 matches
Mail list logo
