Re: Thoughts on forming a GNU Radio Amateur Radio monthly meeting group

[Kristoff]

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