Re: [Discuss-gnuradio] Grid/Coordinate placement ('GUI hint' QY/WX) control query
I'm relieved to hear it isn't too arduous, Marcus. I tried to begin GUI development today but appear to have got nowhere, just yet. Mark M0XMH -Original Message- From: Marcus D. Leech [mailto:mle...@ripnet.com] Sent: 24 August 2018 17:24 . . .Years and years ago, before GRC existed, I developed a GUI based on XForms that used Gnu Radio underneath. It wasn't horrid as a process . . . ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] embedded-python block for pocsag paging: help request by first-time GR programer
Hi all, I just did my first steps developing a embedded-python block for GR: a block to generate the data bitstream for sending pocsag paging messages. See here: https://github.com/on1arf/gr-pocsag (.grc-file, just look at the embedded-python block for the python code). (the rest of the flow-graph is shamelessly stolen from the author of gr-mixalot). After trying out some code, I managed to get something "kind-of working", but probably not implemented the correct way. Can somebody please help me with a couple of things I do not yet understand: - Can somebody explain how to implement a source-block using embedded-python? In the code I have now, it is implemented as a sync-block, taking in a signal from a signal-generator block, but that is probably (surely!) not the correct way to do this. I did notice that the signal-generator blocks that exists in GRC do have a input-port that is greyed-out and not connected. I probably need to implement something simular. - is it possible to define a variable in a embedded-python block that can only have a predefined number of possible values (e.g. "bitrate" can only be 512, 1200 or 2400, "inverted" can be true or false)? Or do you allow the user to insert just any value and throw a ValueError in the python block if the value is not correct? - How do you interface your embedded-python code with variables that change during run-time? (e.g. a variable mapped to a GUI slider). How does the embedded-python program known when a variable has changed? - Basically, a pocsag paging-message is a packet, not a continuous stream. It is possible to create a source-block that creates a stream of a limited length and then stop the execution of the graph? (so, in essence, a GRC Also, I've found a couple of presentations online concerning stream-tags. Are there any examples of how to use the stream-tags API inside a embedded-python block? - Anycase, (not strickly speaking not GR-related) ... how do you actually switch a hackRF between RX and TX mode? Thanks in advance for any help. Kristoff - ON1ARF ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] embedded-python block for pocsag paging: help request by first-time GR programer
Some partial answers, from memory and not necessarily correct: On Sun, Aug 26, 2018 at 1:26 PM Kristoff wrote: > - Can somebody explain how to implement a source-block using > embedded-python? > In the code I have now, it is implemented as a sync-block, taking in a > signal from a signal-generator block, but that is probably (surely!) not > the correct way to do this. > A source block is just a block with no inputs. I haven't yet tried it in Python but it *should* be simply specifying in_sig=[] in the __init__. This means that your work function will be called repeatedly rather than only when input data is available. > I did notice that the signal-generator blocks that exists in GRC do have > a input-port that is greyed-out and not connected. I probably need to > implement something simular. > No, gray ports in GRC are message ports for receiving control messages. It is a separate additional feature of that block and not one you have to implement. > - How do you interface your embedded-python code with variables that > change during run-time? (e.g. a variable mapped to a GUI slider). > How does the embedded-python program known when a variable has changed? > The GRC XML file which describes your block to GRC specifies what to do when one of its parameters have changed. GRC then generates code which, when a GRC "variable" or GUI control changes, tells all the blocks that need to know. This looks like, for example, set_center_freq($center_freq) That element in a GRC file means that whenever the parameter center_freq has changed — which might be due to any number of variables, since GRC allows input of expressions — GRC will ensure that the block's .set_center_freq() method is called with the new value. center_freq must have been defined in a element elsewhere in the file. > - Basically, a pocsag paging-message is a packet, not a continuous stream. > It is possible to create a source-block that creates a stream of a > limited length and then stop the execution of the graph? > There are two things you can do depending on what you need. You can return -1 from the work function to indicate you are done. This propagates to downstream blocks, and causes the top_block.wait() call that exists in most GR programs to stop waiting and return, but it can instead choose to (reconfigure and) restart the flow graph if you have an application where that makes sense. If you mean you want to pause work and resume when the next packet comes along, then your source should just block until more data is available. You might need to pad the output with zeroes at the end to ensure the packet isn't cut off by sitting in partial buffers. (I haven't worked with the second approach, so there might be other caveats, and there may be better tools — my work with GNU Radio has been primarily analog/continuous receiving rather than transmitters/transceivers using packets.) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] runtime error while running flowgraph
Icreated a block using gr_modtool add -l python -tsync command, whereI tried to
implement this discussion:[Discuss-gnuradio] Change frequency in USRPsource
automatically(https://lists.gnu.org/archive/html/discuss-gnuradio/2016-03/msg00402.html)
And thenused this block in a flowgraph connecting to the block USRP Source.
when Itried to run the top_block.py block, the following error wasdisplayed:-
root@pglab1-HCL-Desktop:/home/pglab1#python top_block.py
Traceback(most recent call last):
File"top_block.py", line 98, in
main()
File"top_block.py", line 86, in main
tb= top_block_cls()
File"top_block.py", line 64, in __init__
self.tutorial_frew_sweep_v1_f_0 =tutorial.frew_sweep_v1_f()
File"/usr/local/lib/python2.7/dist-packages/tutorial/frew_sweep_v1_f.py",line
40, in __init__
self.set_msg_handler(pmt.intern('clock'),self.handler)
File"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py",line 200,
in set_msg_handler
self.__gateway.set_msg_handler_feval(which_port,handler)
File"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",line
6423, in set_msg_handler_feval
return_runtime_swig.block_gateway_sptr_set_msg_handler_feval(self,which_port,
msg_handler)
RuntimeError:attempt to set_msg_handler_feval() on bad input message port!
Can someone help me to correct this error?Thanking youRensi SamAnna University
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
