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. > > > > >
