Hi Simone and all,
Can you provide your GRC flow-graph? I think that source of the problem
might be somewhere in this part
"PMT MESSAGE TO FILE SOURCE" as there is message to samples stream
conversion involved here. But it's not clear for me what it actually is
as you described it.
I have problem
On 07/22/2016 04:38 PM, Lakshay Narula wrote:
> Thanks Martin, that was exactly what I was looking for.
>
> Would the following statement be correct: the GNU Radio flowgraph always
> produces samples as fast as the CPU can (irrespective of the set sample
> rate or throttle), and stops producing w
Thanks Martin, that was exactly what I was looking for.
Would the following statement be correct: the GNU Radio flowgraph always
produces samples as fast as the CPU can (irrespective of the set sample
rate or throttle), and stops producing whenever the USRP sink buffer is
full.
Also, does the thr
Eugene,
I've seen something similar, and I'm not even sure it's a PyBOMBS
problem. I think it's more likely an issue with gr-uhd's (or even GNU
Radio's) CMake.
Not sure what the fix is though. I'll post an issue.
Cheers,
M
On 07/18/2016 01:31 PM, Eugene Grayver wrote:
> There's a subtle problem
A basic principle of GNU Radio flow graphs is the concept of
backpressure. Let's ignore the bursts for a second, and assume you set
your USRP to consume at a rate of 200 ksps (so, a very low value). At
its input, you have a signal source, and no other throttling mechanism
(which is the right thing
Simone,
a file source *will* terminate the flow graph once its read the file
(unless you specify 'repeat').
M
On 07/21/2016 12:32 AM, Simone Ciccia S210664 wrote:
> Goodmorning,
> I would like to Know some methods to Close flowgraph automatically when
> it has finished. Some example, stop when U
Hi list,
in week 9 of my GSoC I finally managed to implement a working OFDM
parameter estimation block. Read here about it:
https://grinspector.wordpress.com/2016/07/22/week-9-ofdm-finale/
Next up is a frequency and timing synchronization block.
Cheers
Sebastian
2016-07-18 9:57 GMT+02:00 Sebast
Hi Marcus,
Ok, it is therefore indication of problem with an overflow happening in
rtl-sdr source block on the side of PC (there is no more free buffers to
store incoming sample). I'm aware that with RTL-SDR's it is not possible
(as far as anyone knows) to read how many samples were lost. But any
Hi Piotr,
As far as I grok the gr-osmosdr rtl_souce, this is an overflow
indication purely based on the fact that in the rtl_source itself, the
number of the last used buffer is compared with the maximum number of
buffers that should be – and if that happens, that is an indication that
the softwar
W dniu 22.07.2016 o 09:34, Sylvain Munaut pisze:
> Hi,
>
>> It's a little bit off-topic but if someone will change the gr-osmosdr,
>> it would be great to have other stream tags that we are used to see at
>> the output UHD source. For example if the source prints on the output
>> that there is some
Hi,
> It's a little bit off-topic but if someone will change the gr-osmosdr,
> it would be great to have other stream tags that we are used to see at
> the output UHD source. For example if the source prints on the output
> that there is some problem with transmission it would be great to add a
>
11 matches
Mail list logo
