Item 4 - better notes/annotations would be useful to beginners and experts. They could be attached to blocks or connections, freestanding, expand-on-hover, etc. Graphics layout is hard, unless we were to adopt an existing layout package.
On Sat, Nov 14, 2020 at 11:21 AM Jeff Long <willco...@gmail.com> wrote: > Looking for the simplest (maybe not the best) solution: > > Item1 - A shell/batch script could run gnuradio-companion 1.grc 2.grc 3.grc > > Item 2 - files can be relative, e.g, ./sample.iq. So, if you tar or zip > the grc files and the sample files, everything should be runnable from a > single directory, no searching around required. > > Item 3 - I think this is pretty far out of scope for GRC. > > On Sat, Nov 14, 2020 at 11:15 AM Kristoff <krist...@skypro.be> wrote: > >> HI all, >> >> Yesterday-evening, we did a small workshop 'getting started to GNU Radio >> for CTFs', to 'kickstart' some people using GNU Radio. >> >> >> Afterwards, I was thinking that workshops do take up quite a bit of >> time, and not every student has time to do a workshop during the >> timeslot that is there is a teacher available; so perhaps we can also do >> this in another way. >> >> One thing -I think- would help for this, is the possibility to create >> 'interactive getting started guides' for GR. That way, we should be able >> to reach more people. >> >> The idea I have in mind is to create 'interactive learning-flows'. To >> allow people to learn GNU Radio -step by step- how to use GRC, how to >> analyse a CTF, how to create signals, ... >> >> >> The model is a 'learning-flow', a course is divided into multiple GRC >> flow-graphs, and where every 'tab' on GRC is the next step in process to >> build/ explain/ ... a GRC flow-graph. >> - GRC tab 1: option-block + 'samp_rate' var block + file source >> - GRC tab 2: option-block + 'samp_rate' var block + file source + >> throttle-block >> - GRC tab 3: option-block + 'samp_rate' var block + file source + >> throttle-block + QT time sink >> - GRC tab 3: option-block + 'samp_rate' var block + file source + >> throttle-block + complex-to-amp2 + QT time sink >> (...) >> >> >> >> So, my question. Could it be possible to change / enhance GRC a little >> it to make it better suited for creating this kind of interactive >> learning courses? >> >> (Perhaps some of the things noted below are already possible. So please >> excuse my ignorance) >> >> >> Find below some 'feature-requests' for GRC that I think would help to >> make this possible (or at least, more easy): >> >> 1. GRC has the ability to use tabs, multiple flowgraphs loaded into GRC. >> However, every flowgraph is independent, and you can can load/save every >> one of them independently. >> >> Would it be possible to create the concept of a 'flowgraph bundle', i.e. >> a number of flowgraphs that are groups together, and that are combined >> in one file. >> >> When you load the 'bundle', all flow-graphs will be loaded at different >> tabs of GRC, in a predefined order as documented in the bundle. >> >> >> >> 2. Most workshops / how-tos use files. (e.g. i/q files) >> >> Currently, this means that you must distribute that i/q file separately, >> and you must tell the user 'now point the file-sink block to the i/q >> file you have downloaded. It can be in Downloads, or in documents, or in >> your home-folder so look around if you do not find it immediately'. >> >> This is kind-of OK in a real 'live' workshop, but -I think- not what you >> would want in a learning-project somebody has downloaded from the >> internet and doing this without the 'live' aid of a teacher. >> >> >> So, considering the bundles mentioned about, would it be possible to >> have them also include -say- an i/q files? >> When the user loads a bundle into GRC, this should then also place that >> the i/q file in a predefined location on the computer of the student. >> >> - The goal would be to be able to pre-configure the file-source block >> in such a way that it will find that I/q file, no matter what the >> directory-structure of the user's computer might be. >> - And it would make distributing a learning-flow a lot easier as you >> only have to distribute one single file. >> >> >> 3/ (This is probably a lot more difficult) >> To create a real 'step by step' flow, it would be interesting that the >> student can only access a certain tab (i.e. a step in the learning >> path), when the flow-graph of the previous tab has been 'finished' >> >> To give an example: >> >> Tab 1: options block, variable block 'samp-rate' and file-source block >> + a "note" block with this text: >> >> - "when loading a file into GRC, the data-type of the file-source output >> port should corresponds to the signal in the file. >> The example-file has the extension 'iq', so the datatype is 'complex'. >> Change the datatype of the file-source block to the correct setting" >> >> - "One of the most important features of a stream is it sample-rate. The >> example-file is called file1_48000sps.iq >> What is the sample-rate of the signal in that file. Set the variable >> samp_rate to the correct value" >> >> >> Only when those two conditions are met, then the student should be able >> to access the 2nd tab. >> >> >> Tab 2: >> >> Comment block "When creating a GRC without any actual hardware, you need >> to add a throttle-block. If not, GRC will use all CPU-cycles of your >> computer when run. Please add a throttle-block after the file-source >> block, connect these two blocks and then go to tab3." >> >> ... >> >> (But I guess that this kind of requirement is a lot harder then points 1 >> and 2 above). >> >> >> 4/ Can you please make the 'note' block larger, and to allow multiple >> lines of text? >> >> Currently, it is quite small, so it is not really possible to add the >> kind of comments (see 3/ above) to the graph. >> >> What would also be nice is the ability to add URLs in the note blocks. >> This would allow the note to link to -say- a video: " Change the >> datatype of the file-source block to the correct setting. Click here for >> a video on the different data-types used in GNU Radio" >> >> >> >> I know that some of these feature-requests are probably not that easy. >> But as the quite steep learning-curve of GNU Radio is the main reason >> people are scared away from GR, I do think that providing a good >> learning-tool can be one of the best ways to get the, over that hurdle. >> >> >> >> 73 >> >> kristoff - ON1ARF >> >> >>
