GR HAM, Apparently late to this thread, but I would also be interested in a monthly.
Jared (KM6MRG). On Mon, Sep 28, 2020 at 11:07 AM Kristoff <krist...@skypro.be> wrote: > Hi Markus, Edmar, Barry, all, > > > Sorry for the late reply (you know .. weekend), > > > Yes, I think it will be interesting do have a small video-chat on this > subject. > > I have the impression that everybody who is looking into getting more > radio-amateurs into SDR seams to have a similar issue. > At first, it looks to be "doable" if you orient the classes towards the > top 5 % hams that have a background that is compatible with looking at > electronics as signals and as mathematical formulas, but -indeed- it > becomes a lot more difficult to create a course for 'the average OM' > especially as amateur-radio has always been a lot more about > experimentation then 'detailed theory'. > > Perhaps the most easy option is now to do something for the former > group and work from there on. > > Concerning the difference between ham-radio courses and the academia. I > agree with your analysis but I think we do need to keep in mind that not > only the audience is very different, but also the goal. After all, our > goal is (I think) to get more hams to understand SDR. It is not to train > people to become telecom-engineers that are able to design 5G modems. :-) > > > > Two more remarks: > > - one think I do think that can help is a 'self-learning path' for > people who want to learn by themself. > > There is a lot of information on the internet about signal-processing, > DSP and SDR (free and paying), and -based on the answers I got on the > questionnaire I did in the SDR Belgium list- people who do are > interested in these subjects do find them quite useful. So there might > be no need to 'reinvent the hot water' (as they say in Dutch) > > > That's also how I got started. > I wanted to understand the code of Jonathan G4KLX from his pcrepeater > project, so I needed a book on DSP to understand the code for the LPFs. > I started with the dspguide (http://dspguide.com) and then the RIchard > Lyons book. Next up where the 'SDR with the HackRF' videos by Michael > Ossman, and I now going through the 'wireless-pi' course by Qasim > Chadhari (when I have time for it). > > I have a list of interesting resources (*), but I do think that a more > structured 'path' can be quite useful for people. > This applies for people starting out with SDR, or people who have done > your 'hamradio course' of SDR and want to really go further in this topic. > > > (*) https://github.com/on1arf/sdr/blob/master/links.md > > > - another element that can help is getting more people to use GNU Radio, > just as an educational tool. > > I once used GNU Radio to demonstrate how you can 'filter a signal out of > noise' (like WSPR, FT8, ... do) by 'averaging out' the noise during out > weekly jitsi-session of our local radioclub. > There is a very good video of Tom Rondeau explaining convolution and > matched filters at TAPR 2012, using GNU Radio as a visual educational > tool (*) > It's not about the visual / educational element itself. It also makes > GNU Radio better known by both the students and the teachers (even > outside the context of SDR), and let them appreciate the tool. > > So it might be just as important to teach the trainers of the > amateur-radio courses to use the tools out there that can really help > them to explain things to their students, including GNU Radio. (**) > > > (*) https://youtu.be/cg3TA3EDx78?t=119 > (**) Note that this does only apply to GNU Radio, but also > antenna-simulation / visualisation tools, math tools like > octave/scilab/scipy/numpy, or the "falstad" online circuit analysis: > https://www.falstad.com/circuit/ > > > > Anycase, > I am very interested in the details your course on SDR and your plans on > how to do this practically. > Is this a pure 'class' course or a workshop? How many hours of study > would be needed for this? > > So, if you would plan to do a video-conference on this topic, I think > there would be quite some interest by some people I know on this topic. > > > > > 73 > kristoff - ON1ARF > > > > On 26/09/2020 12:17, Markus Heller wrote: > > Dear list, > > > > here in Germany we've been working on a standard class to teach SDR to > > radio amateurs. We see that the learning path is quite steep for the > > ordinary OM. > > > > In the academa you have several semesters time to learn everything you > > need, including complex maths. But the ordinary OM has very little time > > compared to a student, and moreover, we don't want to forget those who > > do not have an academic background. And yes, theree are many who are > > interested in SDR but are not proficient in English (same in Belgium, > > I've been discussing this with Kristoff). Probably this also applies to > > many other countries. So generally I'm glad we have a common language > > here. > > > > There is not much that speaks against preparing a standard class in > > other languages as well. Here is our structure: > > > > 1.) Digital Signal Processing (introduction) > > 2.) Maths, operations on complex numbers > > 3.) GNURadio introduction > > 4.) NumPy, SciPy, Matlab, Octave > > 5.) Digital Signal Processing (advanced topics) > > 6.) ADCs, DACs > > 7.) Filter design > > 8.) GNURadio (advanced 1) > > 9.) GNURadio (advanced 2) > > 10.) FPGA fundamentals > > 11.) Data transmissions > > 12.) Review of current hardware and their properties > > > > We also see that there are very few people who can support such a > > training plan as teachers. The question will be how to roll out such a > > plan with an extremely limited number of helpers. We probably can run > > such a class once or maybe twice, but I would like to spread such > > knowledge much further in our national club DARC. > > > > Now I come to the problem you all have, around the world: At some point > > in the future the HAM RADIO examination administrations will demand > > some update in their exam questions, and there will be a point where > > the officials will ask for SDR topics. > > > > One they ask for SDR topics, there will be the need to have skilled > > teachers who can teach this kind of knowledge. And we have around 100 > > local clubs in Germany that train applicants for the exam, but very > > very few of them can train people to answer SDR questions on a > > reasonable level. Our trainers are brilliant experts for analog > > electronics and legacy ham radio things, but very often they have not > > received according higher education on complex maths and they are not > > very deep into digital signal processing. We need to give them a chance > > to learn these things to such a degree that they can teach. > > > > So I'd strongly advocate to turn GNURadio into a standard topic of > > world wide amateur radio education and exams, because it is Open Source > > and a wonderful platform to understand and learn how things work. > > > > Ideally we could define a level of knowledge we recommend for trainers > > to reach and set a path to go there within a limited amount of time, > > maybe with such a class structure as we have defined above. > > > > What do you think? > > > > vy73 > > markus > > dl8rds > > > > > > > > Am Samstag, den 26.09.2020, 06:44 -0300 schrieb Edmar Candeia Gurjão: > >> 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 > >>>> > >
