| Supporting 100Msps rates on an ordinary PC is exceedingly challenging for any but the most trivial signal processing.
Even the most simple mathematical operation uses 10s or 100s of instructions once you factor all the overhead of moving samples around, etc.
Sent from my iPhone On Jul 9, 2021, at 1:47 PM, Huang Wei <weizardry@gmail.com> wrote:
Thank you
Marcus! I am not using a Raspberry Pi, I use a PC directly connecting to the USRP (sorry I confused you saying embedded python block). So I suppose I can try C instead of python to speed it up, or maybe FPGA, then I need time learn....
Best regards, Wei 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.
>
>
|