Re: Python embedded block stops working after consume()
I see but no, I'm not processing a finite number of samples. I'm generating a message periodically with a Message Strobe, then the message is encoded and modulated as a WiFi signal using the modules in: https://github.com/bastibl/gr-ieee802-11. Now, I'm trying to detect the signals myself and then decode them with the blocks from the same gr-ieee802-11 repository. The block I'm implementing in python looks like this: class short_sync_blk(gr.sync_block): def __init__(self): gr.sync_block.__init__(self,name='Custom short preamble detection', in_sig=[np.complex64], out_sig=[np.complex64]) <+define some variables+> def work(self, input_items, output_items): print(input_items[0]) # Here is where I see that, after one iteration, input_items[0] is filled with zeros <+some processing+> <+insert a tag+> output_items[0][:] = input_items[0] self.consume_each(len(output_items[0])) return len(output_items[0]) Is this enough? Or should I put all the actual code in here with all the connected blocks? Thanks in advance. Best regards, Verónica
Re: Cannot specify link libraries for target "Python::NumPy"
On Ubuntu 18.04, you have to install pybind11 from source. sudo apt-get purge pybind11-dev git clone https://github.com/pybind/pybind11 cd pybind11 git checkout v2.4.3 -b tmp mkdir build cd build cmake -DCMAKE_BUILD_TYPE=Release -DPYBIND11_TEST=OFF ../ make sudo make install Ron On 10/27/21 2:10 PM, Chad Spooner wrote: Ryan: Thanks much! That got me past the numpy error and landed me in a pybind11 error: -- Python checking for numpy - found -- Python checking for pygccxml - found CMake Error at CMakeLists.txt:334 (message): pybind11 version 2.0.1 < 2.4 2.0.1 is the latest from 'apt-get install pybind11'. I saw some stuff in the git 'issues' but not sure how to proceed. I'm taking on building from source because of all the times (dozen?) I've attempted installation of UHD and gnuradio, the only successful ones are the ones obtained by building from source. C On 10/27/21 1:39 PM, Ryan Volz wrote: Hi Chad, You'll find a fix here, along with a link to the relevant bug report: https://github.com/gnuradio/gnuradio/pull/5256 It's an unanticipated problem with the older version of CMake used with Ubuntu 18.04, but the fix will be in the next release. Cheers, Ryan On 10/27/21 2:50 PM, Chad Spooner wrote: All: I'm building gnuradio from source on an Ubuntu 18.04.6 system. I'm using the instructions from: https://wiki.gnuradio.org/index.php/InstallingGR#From_Source When I get to the step: # Note: In the following command, you can add -DCMAKE_INSTALL_PREFIX=XXX to install GNU Radio into the PREFIX XXX; if not specified, then the PREFIX is /usr/local. See other CMake options in Common cmake flags. cmake -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3 ../ I get an error relating to numpy: -- User set python executable /usr/bin/python3 CMake Error at cmake/Modules/GrPython.cmake:101 (target_link_libraries): Cannot specify link libraries for target "Python::NumPy" which is not built by this project. Call Stack (most recent call first): CMakeLists.txt:318 (include) -- Configuring incomplete, errors occurred! numpy is installed and I can 'import numpy' successfully in python3. (In fact I had issued "apt-get install *numpy*" previously and it was successful.) I tried finding this error in my archive of gnuradio discussion-list emails, but came up empty, as did my google search. Any advice? Thanks, C -- Chad M. Spooner, PhD NorthWest Research Associates 301 Webster Street Monterey, CA 93940 cmspoo...@nwra.com 831 582 4904 cyclostationary.blog
Re: Cannot specify link libraries for target "Python::NumPy"
Ryan: Thanks much! That got me past the numpy error and landed me in a pybind11 error: -- Python checking for numpy - found -- Python checking for pygccxml - found CMake Error at CMakeLists.txt:334 (message): pybind11 version 2.0.1 < 2.4 2.0.1 is the latest from 'apt-get install pybind11'. I saw some stuff in the git 'issues' but not sure how to proceed. I'm taking on building from source because of all the times (dozen?) I've attempted installation of UHD and gnuradio, the only successful ones are the ones obtained by building from source. C On 10/27/21 1:39 PM, Ryan Volz wrote: Hi Chad, You'll find a fix here, along with a link to the relevant bug report: https://github.com/gnuradio/gnuradio/pull/5256 It's an unanticipated problem with the older version of CMake used with Ubuntu 18.04, but the fix will be in the next release. Cheers, Ryan On 10/27/21 2:50 PM, Chad Spooner wrote: All: I'm building gnuradio from source on an Ubuntu 18.04.6 system. I'm using the instructions from: https://wiki.gnuradio.org/index.php/InstallingGR#From_Source When I get to the step: # Note: In the following command, you can add -DCMAKE_INSTALL_PREFIX=XXX to install GNU Radio into the PREFIX XXX; if not specified, then the PREFIX is /usr/local. See other CMake options in Common cmake flags. cmake -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3 ../ I get an error relating to numpy: -- User set python executable /usr/bin/python3 CMake Error at cmake/Modules/GrPython.cmake:101 (target_link_libraries): Cannot specify link libraries for target "Python::NumPy" which is not built by this project. Call Stack (most recent call first): CMakeLists.txt:318 (include) -- Configuring incomplete, errors occurred! numpy is installed and I can 'import numpy' successfully in python3. (In fact I had issued "apt-get install *numpy*" previously and it was successful.) I tried finding this error in my archive of gnuradio discussion-list emails, but came up empty, as did my google search. Any advice? Thanks, C -- Chad M. Spooner, PhD NorthWest Research Associates 301 Webster Street Monterey, CA 93940 cmspoo...@nwra.com 831 582 4904 cyclostationary.blog -- Chad M. Spooner, PhD NorthWest Research Associates 301 Webster Street Monterey, CA 93940 cmspoo...@nwra.com 831 582 4904 cyclostationary.blog smime.p7s Description: S/MIME Cryptographic Signature
Re: Cannot specify link libraries for target "Python::NumPy"
Hi Chad, You'll find a fix here, along with a link to the relevant bug report: https://github.com/gnuradio/gnuradio/pull/5256 It's an unanticipated problem with the older version of CMake used with Ubuntu 18.04, but the fix will be in the next release. Cheers, Ryan On 10/27/21 2:50 PM, Chad Spooner wrote: All: I'm building gnuradio from source on an Ubuntu 18.04.6 system. I'm using the instructions from: https://wiki.gnuradio.org/index.php/InstallingGR#From_Source When I get to the step: # Note: In the following command, you can add -DCMAKE_INSTALL_PREFIX=XXX to install GNU Radio into the PREFIX XXX; if not specified, then the PREFIX is /usr/local. See other CMake options in Common cmake flags. cmake -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3 ../ I get an error relating to numpy: -- User set python executable /usr/bin/python3 CMake Error at cmake/Modules/GrPython.cmake:101 (target_link_libraries): Cannot specify link libraries for target "Python::NumPy" which is not built by this project. Call Stack (most recent call first): CMakeLists.txt:318 (include) -- Configuring incomplete, errors occurred! numpy is installed and I can 'import numpy' successfully in python3. (In fact I had issued "apt-get install *numpy*" previously and it was successful.) I tried finding this error in my archive of gnuradio discussion-list emails, but came up empty, as did my google search. Any advice? Thanks, C -- Chad M. Spooner, PhD NorthWest Research Associates 301 Webster Street Monterey, CA 93940 cmspoo...@nwra.com 831 582 4904 cyclostationary.blog
Re: Python embedded block stops working after consume()
If you are feeding a flowgraph a finite number of samples, there is no guarantee the last samples will be processed before the flowgraph terminates. Could that be what you're seeing? Otherwise, post what you're doing and someone can try to help further. On Wed, Oct 27, 2021 at 3:00 PM Verónica Toro Betancur wrote: > Hi Jeff, > > Thank you for your reply. > > I have tried returning len(output_items[0]) and using it in the consume > function and it still doesn't work. > > Also, if I don't use consume() or consume_each(), it seems like the last > part of the signal is dropped and I can't decode it correctly in the blocks > that come afterwards. > > > Best regards, > Verónica > > El mié., 27 de oct. de 2021 8:16 PM, Jeff Long > escribió: > >> The input vector may contain more items than the scheduler is expecting >> you to return. Use len(output_items[0]) to determine how much to consume >> and return. For reference, here is the autogenerated code for a new module: >> >> def work(self, input_items, output_items): >> in0 = input_items[0] >> out = output_items[0] >> # <+signal processing here+> >> out[:] = in0 >> return len(output_items[0]) >> >> On Wed, Oct 27, 2021 at 11:46 AM Verónica Toro Betancur < >> vetor...@gmail.com> wrote: >> >>> Hi, >>> >>> I've been trying to implement a sync python embedded block that >>> processes all input_items. At the end of the work() function, I call >>> >>> output_items[0][:] = input_items[0] >>> self.consume_each(len(input_items[0])) >>> return len(input_items[0]) >>> >>> This works well the first time and all data is processed correctly, but >>> then, the block stops working, i.e., it doesn't process any new upcoming >>> data and input_items[0] is always filled with zeros. >>> >>> I hope someone could help me with this. >>> >>> Thanks in advance. >>> >>> >>> Best regards, >>> Verónica >>> >>
Re: Python embedded block stops working after consume()
Hi Jeff, Thank you for your reply. I have tried returning len(output_items[0]) and using it in the consume function and it still doesn't work. Also, if I don't use consume() or consume_each(), it seems like the last part of the signal is dropped and I can't decode it correctly in the blocks that come afterwards. Best regards, Verónica El mié., 27 de oct. de 2021 8:16 PM, Jeff Long escribió: > The input vector may contain more items than the scheduler is expecting > you to return. Use len(output_items[0]) to determine how much to consume > and return. For reference, here is the autogenerated code for a new module: > > def work(self, input_items, output_items): > in0 = input_items[0] > out = output_items[0] > # <+signal processing here+> > out[:] = in0 > return len(output_items[0]) > > On Wed, Oct 27, 2021 at 11:46 AM Verónica Toro Betancur < > vetor...@gmail.com> wrote: > >> Hi, >> >> I've been trying to implement a sync python embedded block that processes >> all input_items. At the end of the work() function, I call >> >> output_items[0][:] = input_items[0] >> self.consume_each(len(input_items[0])) >> return len(input_items[0]) >> >> This works well the first time and all data is processed correctly, but >> then, the block stops working, i.e., it doesn't process any new upcoming >> data and input_items[0] is always filled with zeros. >> >> I hope someone could help me with this. >> >> Thanks in advance. >> >> >> Best regards, >> Verónica >> >
Cannot specify link libraries for target "Python::NumPy"
All: I'm building gnuradio from source on an Ubuntu 18.04.6 system. I'm using the instructions from: https://wiki.gnuradio.org/index.php/InstallingGR#From_Source When I get to the step: # Note: In the following command, you can add -DCMAKE_INSTALL_PREFIX=XXX to install GNU Radio into the PREFIX XXX; if not specified, then the PREFIX is /usr/local. See other CMake options in Common cmake flags. cmake -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3 ../ I get an error relating to numpy: -- User set python executable /usr/bin/python3 CMake Error at cmake/Modules/GrPython.cmake:101 (target_link_libraries): Cannot specify link libraries for target "Python::NumPy" which is not built by this project. Call Stack (most recent call first): CMakeLists.txt:318 (include) -- Configuring incomplete, errors occurred! numpy is installed and I can 'import numpy' successfully in python3. (In fact I had issued "apt-get install *numpy*" previously and it was successful.) I tried finding this error in my archive of gnuradio discussion-list emails, but came up empty, as did my google search. Any advice? Thanks, C -- Chad M. Spooner, PhD NorthWest Research Associates 301 Webster Street Monterey, CA 93940 cmspoo...@nwra.com 831 582 4904 cyclostationary.blog smime.p7s Description: S/MIME Cryptographic Signature
Re: Python embedded block stops working after consume()
The input vector may contain more items than the scheduler is expecting you to return. Use len(output_items[0]) to determine how much to consume and return. For reference, here is the autogenerated code for a new module: def work(self, input_items, output_items): in0 = input_items[0] out = output_items[0] # <+signal processing here+> out[:] = in0 return len(output_items[0]) On Wed, Oct 27, 2021 at 11:46 AM Verónica Toro Betancur wrote: > Hi, > > I've been trying to implement a sync python embedded block that processes > all input_items. At the end of the work() function, I call > > output_items[0][:] = input_items[0] > self.consume_each(len(input_items[0])) > return len(input_items[0]) > > This works well the first time and all data is processed correctly, but > then, the block stops working, i.e., it doesn't process any new upcoming > data and input_items[0] is always filled with zeros. > > I hope someone could help me with this. > > Thanks in advance. > > > Best regards, > Verónica >
Re: USRP N210 growing latencies
Hi, > OK I understand that. But is there any solution which permits to reset that > growing propagation delay ? How to reset the flowgraph buffers without > killing the application and restart it ? Is there any method that permits to > purge and resync buffers of the flowgraph ? The USRP supports timestamps for RX and TX. So you get tags for when data was received / is supposed to be transmitted. Using a custom block to modify the RX tags into TX tags ( to change the RX timestamps to TX timestamps a bit into the future ), you should be able to achieve a constant controlled latency. Cheers, Sylvain
Python embedded block stops working after consume()
Hi, I've been trying to implement a sync python embedded block that processes all input_items. At the end of the work() function, I call output_items[0][:] = input_items[0] self.consume_each(len(input_items[0])) return len(input_items[0]) This works well the first time and all data is processed correctly, but then, the block stops working, i.e., it doesn't process any new upcoming data and input_items[0] is always filled with zeros. I hope someone could help me with this. Thanks in advance. Best regards, Verónica
Re: USRP N210 growing latencies
Hi Johannes,
I try on 2 configurations :
- VM Ubuntu 20.04 + GR 3.9.3.0 + UHD 4.1.0.4
- Native LXubuntu 20.04 Prempt kernel + GR 3.9.4.0 + UHD 4.1.0.4
All are built from sources.
RX SR = 5Msps
TX SR = 200ksps
All seem to be supported by N210. Yes I decimate with the write value
(RX SR / TX SR).
On the VM system, I see a lot of underflow that appear randomly. I could
measure up to near a second of propagation delay in the flowgraph after
10min working period : it's unusable.
Indeed, working with a native Preempt linux distribution eliminate near
all underflow. But sometimes, maybe when OS generates an interrupt with
higher priority, I could get one underflow : one underflow in that case
in 8H working period. I can accept that if I can reset the flowgraph
just after without killing it and restart. The question is how ?
Best regards,
Fabien, F4CTZ.
Le 27/10/2021 à 14:47, Johannes Demel a écrit :
Hi Fabien,
unless this is a very specific issue and you know exactly that your OS
is the component that causes an issue, I recommend to stick with your
distros generic kernel image.
I'd need more information but my gut feeling tells me that your issue
is somehow a 2-clock problem.
So let's start with a few questions about your system.
Which Linux distribution do you use? Which exact GNU Radio and UHD
versions do you use? GR 3.9.3? UHD 4.1.0.x? How did you install GNU
Radio. Do you run your flowgraph in a VM or smth similar?
UHD RX sample rate?
UHD TX sample rate?
Are both rates supported by your N210?
Does your flowgraph decimate by some integer value?
Which blocks are in between?
Just to get this out of the way, another hardware block such as an
audio sink might get you into a 2-clock problem situation. Since you
use hardware blocks, I assume you don't use a Throttle block, if so,
remove the Throttle block.
Can you share the flowgraph? It might be easiest to just write down
the exact blocks.
Are there any custom blocks?
Do you need continuous streaming?
How fast does the delay grow?
A lot of questions, I know. The answers to these questions might help
to find your root issue.
Cheers
Johannes
On 26.10.21 21:41, Fabien PELLET wrote:
Hello,
Thanks for the answer Marcus.
OK I understand that. But is there any solution which permits to
reset that growing propagation delay ? How to reset the flowgraph
buffers without killing the application and restart it ? Is there any
method that permits to purge and resync buffers of the flowgraph ?
Even if my application runs on a preempt_rt OS with a good
calculation power, I'm not enough good in Linux tweaking to be sure
that my application will not have a unusable delay after a long time.
So I can accept to loose some time when I catch a PMT message of
underflow to reset the sequencer and buffers. But how without killing
apps ??
Best regards,
Fabien, F4CTZ
Marcus Müller a écrit
Hello!
On 26.10.21 16:12, Fabien PELLET wrote:
>
> Why that propagation delay is always growing ?
>
Exactly *becuause* your underflowing.
Your Receive side produces N samples – but too slow at some point,
leading to your
transmitter needing to "invent" an amount P of samples, because it
simply has a fixed
sample rate.
So, now, from the point of view of the transmitter's DAC, N+P sample
periods have passed,
whereas the receiver's ADC saw N sample periods. This repeats, and
every P > 0. Therefore,
the delay is always only growing.
Best regards,
Marcus
options:
parameters:
author: osboxes
catch_exceptions: 'True'
category: '[GRC Hier Blocks]'
cmake_opt: '""'
comment: ''
copyright: hgjhg
description: hjhghg
gen_cmake: 'On'
gen_linking: dynamic
generate_options: qt_gui
hier_block_src_path: '.:'
id: testcpp
max_nouts: '0'
output_language: python
placement: (0,0)
qt_qss_theme: ''
realtime_scheduling: ''
run: 'True'
run_command: '{python} -u {filename}'
run_options: prompt
sizing_mode: fixed
thread_safe_setters: '1'
title: test
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [8, 8]
rotation: 0
state: enabled
blocks:
- name: samp_rate
id: variable
parameters:
comment: ''
value: '500'
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [184, 12]
rotation: 0
state: enabled
- name: analog_agc2_xx_0
id: analog_agc2_xx
parameters:
affinity: ''
alias: ''
attack_rate: 10e-3
comment: ''
decay_rate: 5e-1
gain: '1.0'
max_gain: '65536'
maxoutbuf: '0'
minoutbuf: '0'
reference: '0.4'
type: complex
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [672, 388.0]
rotation: 0
state: enabled
- name: fir_filter_xxx_0
id: fir_filter_xxx
parameters:
affinity: ''
alias: ''
comment: ''
decim: '25'
maxoutbuf: '0'
Re: USRP N210 growing latencies
Hi Fabien, unless this is a very specific issue and you know exactly that your OS is the component that causes an issue, I recommend to stick with your distros generic kernel image. I'd need more information but my gut feeling tells me that your issue is somehow a 2-clock problem. So let's start with a few questions about your system. Which Linux distribution do you use? Which exact GNU Radio and UHD versions do you use? GR 3.9.3? UHD 4.1.0.x? How did you install GNU Radio. Do you run your flowgraph in a VM or smth similar? UHD RX sample rate? UHD TX sample rate? Are both rates supported by your N210? Does your flowgraph decimate by some integer value? Which blocks are in between? Just to get this out of the way, another hardware block such as an audio sink might get you into a 2-clock problem situation. Since you use hardware blocks, I assume you don't use a Throttle block, if so, remove the Throttle block. Can you share the flowgraph? It might be easiest to just write down the exact blocks. Are there any custom blocks? Do you need continuous streaming? How fast does the delay grow? A lot of questions, I know. The answers to these questions might help to find your root issue. Cheers Johannes On 26.10.21 21:41, Fabien PELLET wrote: Hello, Thanks for the answer Marcus. OK I understand that. But is there any solution which permits to reset that growing propagation delay ? How to reset the flowgraph buffers without killing the application and restart it ? Is there any method that permits to purge and resync buffers of the flowgraph ? Even if my application runs on a preempt_rt OS with a good calculation power, I'm not enough good in Linux tweaking to be sure that my application will not have a unusable delay after a long time. So I can accept to loose some time when I catch a PMT message of underflow to reset the sequencer and buffers. But how without killing apps ?? Best regards, Fabien, F4CTZ Marcus Müller a écrit Hello! On 26.10.21 16:12, Fabien PELLET wrote: > > Why that propagation delay is always growing ? > Exactly *becuause* your underflowing. Your Receive side produces N samples – but too slow at some point, leading to your transmitter needing to "invent" an amount P of samples, because it simply has a fixed sample rate. So, now, from the point of view of the transmitter's DAC, N+P sample periods have passed, whereas the receiver's ADC saw N sample periods. This repeats, and every P > 0. Therefore, the delay is always only growing. Best regards, Marcus
