Hi Kristoff,
I undestand your point, but it is function of the developer to turn as easy as possible the use of a technology. In this way, I like to contribute by giving high level short courses to amateur-radios. I think that depending on the interest of the audience, we can provide e view that the user can know what is the block and the parameters, like a Black box,
Edmar
PU7-ESE
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
>