On Thu, Oct 15, 2020 at 10:01 AM Ron Economos <w6rz@comcast.net> wrote:
The Rational Resampler is definitely CPU intensive. Here's what a seven channel version of the flow graph looks like on my system (Xeon E5-1607).
Ron
On 10/14/20 19:42, Nate Temple wrote:
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 <w6rz@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...
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 <w6rz@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 <mueller@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 <mueller@kit.edu
> <mailto:mueller@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
> >
>