Re: Sample Rate & Hardware Considerations Tutorial: GNURadio.org

[Marcus D. Leech]

On 05/01/2020 05:17 PM, Barry Duggan wrote:
> James,
>
> 1) Yes, the spec sheets are the answer. For the FunCube Pro+, the only 
> rate is 192kHz.
>
> 2) I REALLY need to revise that section! The use of the term 
> 'multiplier' is misleading. The Rational Resampler is Interpolating 
> and Decimating to create the output sample rate. However, if you look 
> at the Properties for it, those values are not underlined, signifying 
> that you can not change them at run-time. Therefore your slider didn't 
> work.
>
> My approach to picking sample rates would be to look at both ends of 
> the data flow to determine what sample rates are required. For 
> example, if the output is an Audio Sink, you have a maximum of 48kHz 
> (usually). For Wide Band FM you need at least 96kHz, and more is 
> better. As long as you get to set an input sample rate, as most 
> devices allow, then the optimal choice is to pick an integer multiple 
> of the 96kHz. Then you can have an integer value of decimation.
>
> Enjoy GNU Radio!
> ---
> Barry Duggan KV4FV
>
> On 5/1/20 2:09 PM, James Hayek wrote:
> > Well, thank you for creating the documentation! I really look forward 
> > to learning as much as I can comprehend, and pushing my limitations 
> > of understanding. Thanks for you and the teams' hard work.
> >
> > Interesting point on Question-01. Yes, you are correct… 200 kHz 
> > bandwidth. I guess I was considering the guard bands (25 kHz upper 
> > and lower). Thank you for clarifying. I verified here:
> >
> > http://hyperphysics.phy-astr.gsu.edu/hbase/Audio/radio.html
> >
> > I wondered why you used 192k for the FunCube.
> >
> > Follow up question:
> >
> > ·How can I know the max sample rate for each device?
> >
> > oAssumingly, reading the Spec Sheets? (Until I’m clever enough to 
> > build my own!)
> >
> > For Question-02, I was referring to: 
> > https://wiki.gnuradio.org/index.php/Guided_Tutorial_Hardware_Considerations, 
> > apologies for not being explicit.
> >
> > Here, the author used a multiplier of 1.05
> >
> > I.e., for the Rational Resampler Block used:
> >
> > ·*Interpolation:* int(1.05 * (audio_rate * audio_interp))
> >
> > ·*Decimation:* int(samp_rate)
> >
> > I mapped that value of 1.05 to a slider and adjusted it during 
> > playback. It made no difference. I assumed this is because it did not 
> > have enough weight to push the sample rate in or out of range. After 
> > doing the actual math, I see the multiplier I used will never bring 
> > the value to the sample rate I needed for my particular device.
> >
> > To verify, I created a follow up slider where I adjust the sample 
> > rate value. It shows me pretty clearly where the limit lies. Below is 
> > the new flow graph.
> >
> > image.png
> >
> >   For the reference to your name, I was following the Sample Rate 
> > Tutorial you wrote. I must of assumed you also did the follow up 
> > lesson stated above. Your name was attached to:
> >
> > https://wiki.gnuradio.org/index.php/Sample_Rate_Tutorial
> >
> > Sorry for the confusion, but thank you for the help!
> >
> >
> > Many thanks,
> >
> >
> > On Fri, May 1, 2020 at 1:24 PM Barry Duggan <address@hidden 
> > <mailto:address@hidden>> wrote:
> >
> >     James,
> >
> >     Thank you for your comments on our documentation! I started 
> > working on
> >     the docs last year including adding flowgraphs to the block docs and
> >     updating the tutorials to rel 3.8. The
> > https://wiki.gnuradio.org/index.php/Guided_Tutorial_Hardware_Considerations
> >
> >     is one which has been updated recently, but I didn't have the 
> > hardware
> >     to test it. (I will next week).
> >
> >     So, for question 1: that tutorial was written several years ago. I
> >     don't
> >     know why that sample rate was chosen, but some older computers have
> >     trouble with high sample rates. Actually the broadcast FM signal 
> > in the
> >     US is 200kHz with all the SCA, etc. but the minimum for stereo is 
> > less.
> >     If you look at the flowgraph for
> >     https://wiki.gnuradio.org/index.php/WBFM_Receive I use 192kHz 
> > because
> >     that is the rate for a FunCube Pro+.
> >
> >     For question 2: In the tutorial
> > https://wiki.gnuradio.org/index.php/Guided_Tutorial_Hardware_Considerations#A_Working_Software_Radio_Broadcast_FM_Receiver
> >
> >     there is no multiplier, so I am guessing that you are looking at
> >     https://wiki.gnuradio.org/index.php/WBFM_Receive where the multiply
> >     block is the volume control.
> >
> >     You said "In your (Barry Duggan's) example the multiplier helped to
> >     remove his static". Can you tell me which of my examples you are
> >     referring to?
> >
> >     Best regards,
> >     --     Barry Duggan KV4FV
> >
> >
> >
> > --
> > Thanks,
> > James G Hayek
> > Youtube.com/JamesHayek
[Meandering semi-rant warning.  Stop reading now if you find the musings 
of an aging nerd to be offensive or boring...]


Much of what I see in this thread has to do with very *generic* DSP (and 
signals in general) concepts, with "getting used to Gnu Radio" as a kind
  of secondary issue.

This opens up broader questions about how much Gnu Radio tutorials 
should provide detailed "backfill" on concepts that are generic to the
  overall discipline (signal processing and radio and DSP in general), 
vs dealing with the Gnu Radio approach to the issues.

I can use a proximate metaphor.  When you go to use, let's say, GCC (The 
Gnu C/C++ compiler) it is reasonable to expect documentation and
  tutorials and the like on the use of the compiler, and its particular 
quirks.   But as you drift in to questions like "what is an algorithm?" and
  "what are data structures all about, anyway", the documentation for 
the compiler is perhaps not the best place to answer these questions.

I'll use another analogy.  You purchase a shiny-new Boeing B767 with all 
the bells and whistles. But you become frustrated because the
  user manual and 1-800-AIR-CRAF number seem to be utterly silent on 
things like "the principles of flight", "control surface theory",
  "meteorology and navigation", "what the hell is a stall, anyway?".

I've struggled with this for the 15 years or so I've been involved with 
the Gnu Radio project.  Folks arrive at its doorstep, try a few things 
out, and
  then get frustrated and confused because they lack the necessary 
fundamental, background, material to be truly successful.  The question then
  becomes "should the tutorials address this".  My own personal opinion 
is that they shouldn't--there are plenty of books and courses out there
  on radio, signal processing, signals, DSP, programming-and-algorithms 
out there.  The GR tutorials should not, in my opinion, reproduce all
  that "bottom part of the iceberg" material, because it will 
necessarily be cursory and less-wonderful than material that is much 
more specific to
  the disciplines involved.

This is, in a way, compounded by the siren-like call of GRC.  It's very 
Lego(tm)-like, and can lull you into a very-false sense that perhaps you
  don't need to understand any of the fundamentals, and that you can, 
monkey-like, throw things together until they work(ish).   I *love* GRC,
  because as someone who does understand much of the fundamentals, it's 
a great tool for fleshing-out concepts without worrying too much
  about housekeeping details, and I've used it for doing many very 
sophisticated things.  But I can see that it can lull one into a sense 
that deep
  understanding is an unnecessary frill.   Further, having adopted that 
stance, when things don't work "out of the gate", it becomes easy to
  blame the tooling...

Now, this isn't a criticism of anyone or their hard work.  Just an 
observation about what I've seen over the last 15 years....