Haha! Marcus, an aging nerd is better than a dead nerd!
Yup, generic is me. Noob is me. I work in a boring RF field
where we deal with prebuilt systems. I need to know more…. I am tired of
the bullshit my job provides. There is no outlet to learn real RF
Engineering. Yet, here I am. Because here, I can learn *REAL* engineering.
Rants welcome.
The backfill question is important. I think one should have a foundation in
EE, but not necessarily DSP.
Providing links for reference and reading is important and maybe even a
forum for those types of questions. Stating to just RTFM is understandable,
but hopefully not the norm. Teachers teach.
Hopefully the inquisitive learn.
Boeing? (BA) Buy the stock at 120. I got a bunch at 98… okay enough of *my*
rant.
I do understand your point. But, for those who have an interest, where do
they begin?
Does it behoove GNU to train those from the ground up? Maybe. But, I really
don’t know. I hope so.
I am a noob (though about to enter my Masters in DSP and FPGA where I came
from a general ECEE background). I guess it all depends on supply vs
demand…
Charge for lessons. Let the invisible hand work its magic before we all
become socialists and Adam Smith becomes nothing but a ghost of the past.
John Maynard Keynes would be so proud. Full employment is slipping.
Education is on the rise.
A decade and a half bring much experiences. What can you do to share it?
On Fri, May 1, 2020 at 10:17 PM Marcus D. Leech <patchvonbr...@gmail.com>
wrote:
> 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 <ba...@dcsmail.net
> >> <mailto:ba...@dcsmail.net>> 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....
>
>
>
>
--
Thanks,
James G Hayek
Youtube.com/JamesHayek
