Re: Overrun using GRC Python block and USRP

[Marcus Müller]

It might be faster, and it will not compete with the rest of Python for the 
single Python
global interpreter lock.

Important point: you usually do *not* develop your software directly on the 
embedded
platform (ie. your pi); you'd normally start on a PC, develop, figure out how 
fast it runs
there, identify the bottlenecks and then move it to the raspberry Pi when you 
are somewhat
confident that it would still work on a slower machine than your PC.

However: 100 MS/s is definitely so far from possible to do on a processor like 
the
raspberry Pi's that you don't even have to try, sorry. Also, the Raspberry Pi 
has no
interface fast enough to even transport 100 MS/s, i.e. there's not even a USRP 
that does
100MS/s that has an interface that would allow you to connect it to the 
raspberry Pi. You
might want to explain what you're trying to build here! Maybe we have some 
recommendations
on how to get you closer to what you need.

Best regards,

Marcus

On 09.07.21 18:33, Huang Wei wrote:
> Thank you for the quick reply, so if I write the block in C++ or C, it may 
> work at a
> higher rate?
>
> Regards,
> Wei
>
> Marcus D. Leech <patchvonbraun@gmail.com <mailto:patchvonbraun@gmail.com>>
> 于2021年7月9日周五 下午5:29写道：
>
>     On 07/09/2021 12:05 PM, Huang Wei wrote:
>>     Sorry, I mean it's the underrun problem
>>
>>     Huang Wei <weizardry@gmail.com <mailto:weizardry@gmail.com>> 于2021年7月9日周五
>>     下午5:02写道：
>>
>>         Hello everyone,
>>
>>         I am using the embedded python block in GRC to realize some simple 
>> functions.
>>         All works fine in the GRC local set-up. However, if I connect a USRP 
>> sink to
>>         the flowgraph which includes that python block, and set the sample 
>> rate more
>>         than 20 MHz (I need 100 MHz in my case), it will keep output 
>> "UUUUUUUU....",
>>         and then GRC will stop working. 
>>         I tried the defaulted python block, where the output is simply 
>> multiplied by a
>>         factor k, the same overrun problem happened. And GRC works fine with 
>> the USRP
>>         sink if the python block is not used.
>>
>>         Does anyone know what could be the problem? 
>>         Thank you!
>>
>>         Regards,
>>         Wei
>>
>     Because there's absolutely no way a Python-based work function is ever 
> going to keep
>     up at multi-MSPS rates.
>
>