The GRC start button is disabled if validation on blocks and connections fails. You could force validation to fail by requiring a certain condition in a yml file. For example, you can specify that a field is non-zero. It is possible you could wire some expression related to student progress into a block with a dependent variable ... as long as the student doesn't just disable the block doing the validation.
There's a PR to add a hyperlink to the doc tab on the block properties dialog. It doesn't seem like it would be too hard to put a field somewhere in a Note block. GRC doesn't know that a Note is different than any other block. How would you have it work? Clicks are used for all kinds of things, so it can't just be a click on the block.
Your ideas are great, not pushy! Sometimes there's an easier way to do things than to change the app, and GRC only gets a fraction of a developer worth of time. It's largely due to GRC (and distro packaging) that so many new users are trying out GNU Radio.
On Sat, Nov 14, 2020 at 2:54 PM Kristoff <kristoff@skypro.be> wrote:
Hi Jeff,
For item 1 and 2.
Yep. I just did some more tests and I agree. I think I will just create
one giant tarball with all the GRCs, i/q files and perhaps other stuff,
and then run grc with the names of all the *grc-files. That should do
the trick.
Good idea. Thx!
For item 3, well I did say that was probably the most difficult thing,
didn't I? :-)
I got my idea based on how the 'start' button operates in GRC.
That button is only enabled if the flow meets certain criteria. There
seams to be some kind of test that is done every time you change the
flowgraph, which enables or disabled the start button,
I do not know the coding logic behind gnuradio-companion, not what gtk
can provide for this, but I was wondering if this idea could also be
applied the same logic to a complete tab: do a test and -if it fails-
disable the flowgraph in that tab. (i.e. hide or disable all blocks)
But, I guess this would require two additional elements:
- the test will need to be based on rules that are provided by the flowgraph
- the test should be able to access resources from tabs. (e.g. the test
for "tab2" could be "tab1.var.sampl_rate.value == 1200")
As said, I have never worked with gtk, so I have no idea if this is
possible.
Just out of interest.
How to the test to determine if the 'start' button is enabled actually work?
I guess there must be some mechanism that parses the structure of the
flow-graph and then perform some tests on that to check if it is ok?
Note, please do not get me wrong. I do not want to be 'pushy'. I'm just
trying to view this from an "education" point of view.
I have now given a number of GNU Radio demo's. I started out with
"standard" presentation: I-as presenter- demonstrate a GNU Radio flow
and that the audience just needs to "watch and understand".
All very nice, except that, ... most people had already forgotten almost
everything 5 minutes after the demonstration had ended. If people do not
need to do or think themself, they are simply not sufficient engaged and
-although they do get an idea of GNU Radio can do- the actual process of
creating a flow-graph does not stick.
That is why I started looking into CTFs and now also this
"getting-started" workshop.
So, let's then conciser a "howto" or a "workshop" that people can do by
themself by downloading it from the web, things become even more
difficult as there is not even a teacher to help them.
If you create a "howto" and just provide people with a number of
flow-graphs, even a separate GRC for every step, I see very little
incentive for people not immediately go to the final GRC and try at the
end-result as soon as they hits a snag.
For that reason, I am more a fan of the model of -say- jupyter notebooks
where people are forced to follow the complete flow of the training,
step by step, and cannot just jump to the end of the training.
So, in fact, I am trying to figure out who to create the forced
step-by-step learning model of a jupyter notebook, using GRC.
Concerning item 4:
Is it possible in gtk that, if a part of the text in a note-block is a
URL (https://...), that GRC would starts a web browser if people click
on it?
It would be nice to be able to incorporate external references (e.g. a
video) in the notes of a flow-graph.
73
kristoff - ON1ARF
On 14/11/2020 17:21, Jeff Long 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 <http://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 <kristoff@skypro.be
> <mailto:kristoff@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 <http://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
>
>
No comments:
Post a Comment