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 <weizar...@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 > > Marcus Müller <mmuel...@gnuradio.org> 于2021年7月9日周五 下午5:59写道： >> 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 <patchvonbr...@gmail.com <mailto:patchvonbr...@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 <weizar...@gmail.com <mailto:weizar...@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. >> > >> >
