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 Em sex, 25 de set de 2020 20:03, Kristoff <krist...@skypro.be> escreveu: > 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 > > > >
