|
On 05/02/2020 09:45 PM, James Hayek
wrote:
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?
I'll note that the Gnu Radio website includes quick background
tutorials:
https://wiki.gnuradio.org/index.php/Guided_Tutorial_Introduction
There's also the "Suggested Reading" page:
https://wiki.gnuradio.org/index.php/SuggestedReading
For generic radio theory, I'd suggest the first few chapters of the
ARRL Handbook for Radio Amateurs, even if you never plan to become
a licensed amateur radio operator, the theory is presented in a
very approachable way.
There are also websites with forums dedicated to DSP:
www.dsprelated.com
www.complextoreal.com
All of this is pointed to, in one way or another, if you start with
the Gnu Radio FAQ page:
https://wiki.gnuradio.org/index.php/FAQ
On Fri, May 1, 2020 at 10:17
PM Marcus D. Leech < address@hidden>
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 <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....
--
Thanks,
James G Hayek
Youtube.com/JamesHayek
|