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
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/2
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'.
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 S
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 Tor
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
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 t
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]
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 supp
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
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
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
12 matches
Mail list logo
