Hi Anil,
You can fix the buffer size using the Min Output Buffer parameter (under
the Advanced tab in your block, assuming you're using GRC).
[image: Inline image 1]
Regards,
Ernest
On Thu, Nov 16, 2017 at 1:56 PM, Anil Kumar Yerrapragada <
yanilkumar2...@gmail.com> wrote:
> Hi all
>
>
> I am
Hi all
I am experimenting with my own python block. I started by simply
interrogating each variable to see their types and shapes.
I connected a vector source that just generates increasing numbers (0, 1,
2, 3, 4, 5 and so on upto a big number).
I noticed that the length of (input_items[0]) s
Quick reminder that our montly project call is happening tomorrow, 10 AM
Pacific, 19:00 CET, in the usual place.
Cheers,
Martin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hi Derek,
Thanks for the advice. I tried adding in a sleep command, but the radio
still is not waiting the 15 seconds. I feel like it is an issue on the
software side since I never see a start time tagged in the packets from the
PC.
I have been digging into the GNUradio source code to see if I ca
Any updates on the videos getting posted to YouTube?
On Wed, Sep 20, 2017 at 10:03 AM, Ben Hilburn wrote:
> Hey all -
>
> Ron is exactly right. I meant to post the link to the slidedecks, which
> are now live.
>
> We are still waiting on the videos, which will get posted to YouTube once
> we rec
On 11/14/2017 02:20 PM, Marcus D. Leech wrote:
My real question is whether it's safe to assume that a flowgraph is
entirely clocked by the samples from its hardware source, and
consequently that processing within the flowgraph (e.g., oscillator
and mixer for tuning) does not introduce potentia
Hello Reggie,
I believe the issue you are encountering is that the streaming starts
before the next PPS edge arrives and resets the USRP time to 0. Try adding
a sleep for one second between the set_time_next_pps and the
set_start_time. Some RFNoC features are not fully exposed in GNU Radio, but
mo
