As Marcus mentioned, this flowgraph should not really consume that much CPU.
The hackrf does not have a FPGA, although possible with other SDRs, this should really be fine to run on a CPU. One approach I've used in the past with higher bandwidth applications (50MS/s) was to precompute as much as possible and then just play back the file. Depending on what your final objective is, this approach may work. For example you could have a separate flowgraph with parameter blocks inputs that runs headless and take in a wav file name and a signal source freq and have it output a fc32 i/q file. Then preprocess each wav for the channel you want. Another flowgraph could read the IQ file and send it over a ZMQ socket with a pub sink (using ipc://) to the third flowgraph running with ZMQ Sub sources, adding the streams, and then playing it out over the hackrf. On Wed, Oct 14, 2020 at 6:37 PM Ron Economos <w...@comcast.net> wrote: > Your add_blk27 usage seems high. This leads me to believe you may not have > run volk_profile. > > Run volk_profile in terminal. Since it's measuring timing, preferably > without other processes interfering (for example, you should shut down > stuff like web browsers and e-mail clients). > > You could also use a lower final sample rate. You could pack your FM > carriers every 400 kHz, and get away with a sampling rate around 2.4 Msps > for five carriers. You could also try 200 kHz spacing, but your FM receiver > may not like that. > > Ron > On 10/14/20 18:07, Anish Mangal wrote: > > That is what it seems like... > https://pasteboard.co/JvGuqC7.png > > This is on i7-4900MQ. I also updated the gnuradio-companion to 3.8.2.0 > (Python 3.6.9). > > > > On Thu, Oct 15, 2020 at 1:33 AM Ron Economos <w...@comcast.net> wrote: > >> The Rational Resampler uses a lot of CPU cycles. Upgrading to GNU Radio >> 3.8 won't help. >> >> Ron >> On 10/14/20 08:01, Anish Mangal wrote: >> >> Thanks. I'll look at both those points before reverting. :) >> >> On Wed, Oct 14, 2020 at 7:18 PM Marcus Müller <muel...@kit.edu> wrote: >> >>> again, >>> >>> 1. outdated GNU Radio. More modern GNU Radio might perform better. >>> Updating isn't really optional when you're musing about performance. >>> 2. actually benchmark where your CPU is going. `htop` is a good tool if >>> you turn on "thread names" in its settings. >>> >>> Best regards, >>> Marcus >>> >>> On 14/10/2020 15.26, Anish Mangal wrote: >>> > Hi Marcus, >>> > >>> > Thanks for the quick reply. Here's a more complete flow diagram that >>> > doesn't use the block I mentioned above. >>> > >>> > https://pasteboard.co/JvBTisO.png >>> > >>> > This uses up most of my CPU, so I was wondering whether it was >>> possible >>> > to spread this across multiple distinct computers. I'm sorry, that I >>> > can't share my most up to date block diagram which uses actual audio >>> > sources instead of coldplay songs, as it is on another machine which I >>> > dont have access to at the moment, but this gives a fairly good idea >>> > about the number of blocks and processing units. >>> > >>> > Thoughts? >>> > >>> > >>> > >>> > On Wed, Oct 14, 2020 at 6:48 PM Marcus Müller <muel...@kit.edu >>> > <mailto:muel...@kit.edu>> wrote: >>> > >>> > Hi Anish, >>> > >>> > what your subject line says, distributing across CPUs, GNU Radio >>> does >>> > automatically. >>> > >>> > Across multiple distinct computers, you'll need to add some signal >>> > communications between these computers. The ZeroMQ network sinks >>> and >>> > sources do that for you. >>> > >>> > But honestly, the flow graph you show should use nearly no CPU at >>> all. >>> > You should investigate what, in your overall flow graph, not just >>> in >>> > the >>> > excerpt you showed, uses up your CPU. This should really not be a >>> big >>> > task for your computer. >>> > >>> > Also, you're using an outdated version of GNU Radio. Time to >>> update! >>> > >>> > Best regards, >>> > Marcus >>> > >>> > On 14/10/2020 15.07, Anish Mangal wrote: >>> > > Hi, This is my very first post to this mailing list, so hello to >>> > all. I >>> > > am a beginner in experimenting with gnuradio and sdr >>> > (hackrf-one). I am >>> > > working on an application where I want to take multiple audio >>> input >>> > > sources and transmit multiple FM signals over one RF channel >>> via the >>> > > SDR. To this end, I created a basic grc block that looks like >>> this: >>> > > >>> > > https://pasteboard.co/JvBGgj5.png >>> > > >>> > > My plan is to have a top level flow diagram using multiple such >>> > blocks >>> > > and sum them to produce a composite FM signal through the >>> > hackrf-one. >>> > > With my 4th generation intel i7 CPU, with the hackrf's bandwidth >>> > set to >>> > > 6MSPS, I am able to transmit 6 simultaneous fm modulated >>> signals. My >>> > > question is this: >>> > > >>> > > Is it possible to spread this task across multiple computers. >>> If one >>> > > computer could produce the FM modulated signals, and the other >>> > computer >>> > > sum them and transmit via the SDR, the number of simultaneous >>> > streams >>> > > may be increased. >>> > > >>> > > Another approach might be to offload parts of this block diagram >>> > to an >>> > > FPGA processing unit. >>> > > >>> > > My challenge is this. I have no experience of working with an >>> > FPGA, and >>> > > limited experience with gnu-radio in general, but I am prepared >>> > to put >>> > > in the effort required, however, if someone more experienced >>> than >>> > me can >>> > > guide me on the proper approach to go about this, it would be >>> very >>> > > helpful. It may be that I just keep all the processing on ONE >>> > powerful >>> > > CPU, and whatever is the max number of simultaneous streams I >>> can >>> > get, >>> > > that's it. But if there are cost effective ways of making this >>> > design >>> > > more efficient, I'm happy to research and experiment. >>> > > >>> > > 73, >>> > > VU2TVE // Anish >>> > > >>> > >>> >>
