3 ms·
Part of why GRC is computationally expensive is multiple reasons... 1. GRC is really just a python front-end. You can see that by generating the .py script
by duckfang 6y ago
Part of why GRC is computationally expensive is multiple reasons...
1. GRC is really just a python front-end. You can see that by generating the .py script for any flow
2. sample mismatch
Note about the sample mismatch... "man rtl_fm defaults to 24Ksps" , whereas the flowgraph for retrieving all the sideband data is set to 2.4Msps. The Gnuradio flow is crunching 100x the data as rtl_fm does.
Now, if detection of each pilot tone is done across 2.4MHz of the total sample on the rtl-sdr, then you could retrieve all the stations in view. However, this is centering on a single channel (106.7MHz), and therefore effectively 'wasting' all the extra retrieved IQ data.
Tl;dr. GRC isn't inherently CPU intensive - chewing through 100x the data IS computationally expensive.
- mikewarot 6y agoThe flowgraphs use decimation filters, which reduces the sample rate while increasing the effective bit depth. Getting the high frequency sidebands takes more than 24k samples/sec.
- duckfang 6y agoThen I would ask that you generate the python script associated to the flow, and look yourself. The data flow is 2.4Msps the whole way through, even with decimation filters. It's one of the inherent issues with using Python in this way.
- mikewarot 6y agoI looked at the generated python code for some of my flows that do decimation. The __init__ section of python code makes connections. Then the main loop calls the GNU Radio libraries and does a wait(). Here's the relevant section of code. def main(top_block_cls=top_block, options=None): tb = top_block_cls() tb.Start(True) tb.Wait() if __name__ == '__main__': main() Note: Each connection has its own sample rate and type, which is implicit in the graph.