Hi Barry,
Concerning the discuss-gnuradio list, the thing is simply that I
try to
stay as much on-topic as I can.
Otherwise, It's a bit like asking help on to write a novel in a
mailing-list on LibreOffice-write. :-)
For me, a mailing-list and a chatroom are complimentary: one is
more
real-time, the other gives more time to write out and explain
issues.
For GNU Radio and radio-amateurs, I think there are several
questions to
ask:
- what is the audience? Only radio-amateurs, or everybody that is
interested in signals?
(i.e. do you also want to use SDR as a tool to promote amateur-
radio?)
- Are you targetting people using SDR (i.e. setting up a SDR-based
system for a particular application, e.g. a raspberry-pi + RTL-
dongle to
receive weather satellites), or at you looking at people who want
to
develop SDR applications? (e.g. a GNU Radio flowgraph to
decode/encode
a particular type of signal) ?
- Do the people understand that SDR is fundamentally SDR and
signal-processing applied to radio-signals?
This means that, to understand SDR (which in GNU Radio translates
into
"what blocks do I need to use for this function?' and "what values
do I
need to fill in in that block?"), you do need to have basic
understanding of SDR and signal-processing, which usually requires
some
math.
- And, -as a consequence- what is the level of knowledge of the
people
you are targetting?
I am trying to organise a small GNU Radio workshop for our SDR
group. (5
sessions or so), and I am struggling on how to do this.
The core issue is to make sure that people gave the correct
expectation
about SDR development is and requires.
GNU Radio is a tool, and sometimes ... a tool that is actually
too
good. Somebody who sees GRC for the first time might think .. "ah
..
that is easy. It is just putting blocks that represent parts of a
receiver behind each other, and that is it. It just a question of
learning what block does what".
That is not true. This may work for certain simple things (like a
FSK
demodulator), but it quickly become much harder and requires a lot
more
background knowledge then expected.
I usually compare it to the arduino environment.
The arduino is designed in an art university to let art students
create
(e.g.) interactive art, without much knowledge of embedded
computing.
And, for the arduino, if it works, it works great! It's simple:
First project: add a sensor to an arduino, load a library, ... and
it works.
Second project: add a radio-module to an arduino .. load the
library ..
and it works! Great!
But then,... they combine both the sensor and the radio-module in
one
project, and ... it does not work anymore.
Why? "No idea? Both libraries work .. so no idea what is the
problem!"
The problem might be (e.g.) that both the radio-module and the
sensor
use the same hardware interrupt, or same SPI bus, ... or whatever.
But
if the user does not know what a hardware-interrupt is (as all the
complexity of the embedded device has been hidden in the library),
that
he/she is stuck!
I have the impression the same applies to GNU Radio.
If it works, it works great.
But, if it does not (e.g. because some parameter of a block is not
correct).. well, if you do not have the background knowledge of
what all
these blocks do (e.g. you have some background on DSP,
signal-processing, parameters of PLL loops, ....), then you are
stuck.
(especially as some parameters of certain functions are not just
numbers, but actually python functions by themself!)
This is something that I have noticed with quite a few hams: they
replicate a flowgraph as found on the internet and that works
great.
But -unless it is a relative simple graph-, once they try building
a
project by themself, they hit a brick wall pretty soon.
So, I am still puzzled how to organise this workshop.
In a uni, it is pretty simple: first they will your head with a lot
of
theory (based on a lot of math), and then use tools like mathlab
and GR
to apply that theory.
That is a model that is complete useless in the amateur-radio
community. :-)
So I am looking for an alternative. I think I might need something
like
this:
- a series of (say) 5 or 6 workshops
- for every workshop:
-> first ask people to read some articles or watch some videos to
get
some background knowledge (max 1 or 2 hours)
-> then do the workshop
-> let the workshop be a combination of practical skills and some
theory
- Afterwards, design a small CTF, based on the things learned at
the
workshop, to provide an extra incentive to who wants to learn more
- In addition, I also want to add a few 'hands-on' elements, .. as
hams
do like to build things themselves! One possible project is a
simple SDR
receiver with tayloe detector.
For the actual content of the workshops, I am still looking for
somebody
who has good knowledge of SDR, DSP, GR .. and teaching (if
possible
teaching to radio amateurs) to help me with that.
I really like GNU Radio and I think it by far the best tool to get
people to learn about signals, .. but it is important that people
do it
step by step and do not understand that they will be able to decode
some
random PSK-signal by just connecting some blocks together in GRC!
If you plan to start the new mailing-list, please let me know as I
am
really interested!
73
kristoff - ON1ARF
On 24/09/2020 22:53, Barry Duggan wrote:
Hi kristoff,
Thank you for your thoughts. I am curious about your saying that
"I
have been hesitant to post here in the GR list as it's more
about
signal-process then about GNU Radio." Have you tried and not
gotten
good responses, or have you just assumed it was not the
appropriate
place? I hope we have not discouraged people from asking valid
questions here.
As an alternate to creating another mailing list, we have a Ham
Radio
chat room which grew out of a GRCon20 Breakout session. It can
be
accessed by Matrix using the Element (previously Riot) desktop
or
phone app.
server: gnuradio.matrix.ungleich.cloud
room: #HamRadio:gnuradio.org
you also can join the #gnuradio:gnuradio.org room for the more
specific GR questions.
I will soon be posting a news item here and on the gnuradio.org
home
page about our first video meeting.
73,
---
Barry Duggan KV4FV
https://github.com/duggabe
On Tue, 22 Sep 2020 22:24:49 +0200, kristoff wrote:
Hi Barry,
Concerning the separate GR-ham mailing-list, I don't know if it
really
needs to be a "GR ham-radio" list, but what I think would be
useful
is a separate mailing-list to discuss signal-processing (that
happen
to use GNU Radio), separate of the 'discuss-gnuradio' list that
is
more related to questions on GNU Radio itself.
I am also still learning SDR, and I have a number of question on
how
to decode signals (e.g. "I want to decode RTTY with 1.5 stop-
bits,
what's the best way to handle that half a bit at the end without
impacting the clock-recovery block?") here I have been hesitant
to
post here in the GR list as it's more about signal-process then
about
GNU Radio. When talking to fellow hams who tried GNU Radio, a lot
of
them have the same problem: how to create a working flowgraph?
What
blocks to use? What do all the parameters of that block really do
and
what do I value should I put in there?
So, yes, a separate list would be nice. .. but I don't know if a
"GR
Ham Radio" is the best combination.
- Why only Ham radio?
SDR and GNU Radio seams to me one of the best tools to promotion
amateur-radio, especially if you target people from the open-
source /
hackerspace / maker scene. Focussing to much on amateur-radio
will -I
think- might mean you lose this opportunity.
- For the amateur-radio community, focussing to much on GNU
Radio
might not be ideal neither. For me, the main topic here is SDR,
signal-processing, DSP and data-communication, ... GNU Radio is
only
part (be it, a very big and important part) of that. Most hams
start
out with a simple RTL-SDR dongle and just *use* it for some
project:
APRS receiver, beacon receiver, to track HABs to listen to
weather-satellites, listen to QO100, ... It's usually only in a
later
stage that they move to GNU Radio, when they are comfortable
with
using SDR and are interesting going the next step: learn how SDR
works
internally and develop SDR applications themselves.
73
kristoff - ON1ARF