Logging question
Hi,
I'm trying to understand gnuradio's logging.
So I setup a simple flowgraph
signal_source -> throttle-> add const-> time_sink.
To enable debug logging I have to set
[log]
debug_file = stderr
debug_level = debug
log_file = stdout
log_level = debug
in ~/.gnuradio/config.conf
or in $CMAKE_INSTALL_PREFIX/etc/gnuradio/conf.d/gnuradio-runtime.conf
I have to set both debug_level and log_level to debug, to get a debug
log. What's the difference between log_level and debug_level? I can
redirect the output to a file, but only by setting log_file = {filename}.
Setting debug_file to a filename changes nothing.
To restrict the debug output to one block I tried to set the log_level
to info and called set_log_level('debug') for this block and verifying
this setting by log_level(). But it seems that this setting has no
influence.
What am I doing wrong ?
-- Volker
porting OOT to 3.10.5 missing memory.h
Hi, I am trying to port my OOTs from gr 3.8 to 3.10. Following the porting guide and running "gr_modtool bind" work on all our machines running 3.10 except one that is on 3.10.5 where block.h tries to include memory.h which is missing. What's the best way to get around this besides just copying the file over? Thank you for any advice. Grace -- Grace K. Yeung, MS NorthWest Research Associates 301 Webster Street Monterey, CA 93940 gr...@nwra.com https://www.nwra.com smime.p7s Description: S/MIME Cryptographic Signature
Re: porting OOT to 3.10.5 missing memory.h
Do you have pygccxml and castxml installed on this machine? And if so, are they recent versions (pygccxml >= 2.0) When gr_modtool bind is called, pygccxml compiles the project headers then scrapes the symbol information to generate the python bindings. Not finding memory.h sounds like an outdated version of pygccxml. If you are on e.g. Ubuntu 20.04, uninstall pygccxml (apt remove python3-pygccxml) and install it from pip (pip3 install pygccxml) On Mon, Apr 24, 2023 at 12:14 PM Grace Yeung wrote: > Hi, I am trying to port my OOTs from gr 3.8 to 3.10. Following the > porting guide and running "gr_modtool bind" work on all our machines > running 3.10 except one that is on 3.10.5 where block.h tries to include > memory.h which is missing. What's the best way to get around this > besides just copying the file over? Thank you for any advice. > > Grace > > -- > Grace K. Yeung, MS > NorthWest Research Associates > 301 Webster Street > Monterey, CA 93940 > gr...@nwra.com > https://www.nwra.com > >
Re: porting OOT to 3.10.5 missing memory.h
Thank you very much. We will try that. Grace On 4/24/23 09:36, Josh Morman wrote: Do you have pygccxml and castxml installed on this machine? And if so, are they recent versions (pygccxml >= 2.0) When gr_modtool bind is called, pygccxml compiles the project headers then scrapes the symbol information to generate the python bindings. Not finding memory.h sounds like an outdated version of pygccxml. If you are on e.g. Ubuntu 20.04, uninstall pygccxml (apt remove python3-pygccxml) and install it from pip (pip3 install pygccxml) On Mon, Apr 24, 2023 at 12:14 PM Grace Yeung wrote: Hi, I am trying to port my OOTs from gr 3.8 to 3.10. Following the porting guide and running "gr_modtool bind" work on all our machines running 3.10 except one that is on 3.10.5 where block.h tries to include memory.h which is missing. What's the best way to get around this besides just copying the file over? Thank you for any advice. Grace -- Grace K. Yeung, MS NorthWest Research Associates 301 Webster Street Monterey, CA 93940 gr...@nwra.com https://www.nwra.com -- Grace K. Yeung, MS NorthWest Research Associates 301 Webster Street Monterey, CA 93940 gr...@nwra.com https://www.nwra.com smime.p7s Description: S/MIME Cryptographic Signature
Latency due to hardware initialization
Hi all, I'm investigating the factors behind the latency in my simple GRC flow graph, I have a theory and I'd be grateful if someone can confirm it or refute it. Say I have a simple flow graph consisting of a file source connected to a hardware sink. My understanding: when I run the flow graph, the source starts producing samples and storing them in the buffer. In the meantime, the hardware sink is initializing (loading FPGA, etc.). Once the hardware is ready to transmit samples, it starts consuming from the buffer. This initialization delay adds to the overall system latency. Is this correct? or does the source only start producing samples after the hardware is initialized? If my understanding is correct, how can we avoid this delay? Is there a way to ask the file source to wait until the hardware is ready and then start sending samples? Thank you -- Ahmad Oweis
