dd, although it shouldn't
prevent you from seeing the signal.
Your scope plot and FFT plot look as if you're not receiving anything,
not even noise.
You should probably first of all verify whether your PC can even talk to
the USRP properly, e.g. by running 'uhd_find_devices' an
real (float), and it will get the
option 'Spectrum Width' in the GUI, where you can select 'Full' or 'Half'.
Regards, Paul Boven.
Hi again,
The problem turned out to be a bit more insidious...
On 2/12/21 11:58 AM, Paul Boven wrote:
Try: [list(range(-15, 0)) + list(range(1, 17))]
This should of course have been:
[list(range(-16,0)) + list(range(1, 17))]
Part of your problem is that you are doing a 128 channel FFT, and
see the carrier, use a symbol like [[1,1]] so that there's actually some
energy in them.
The documentation of the block uses () whereas in Python, you need [] to
create a vector.
Disclaimer: I know very little about how OFDM works, but this should
help you make some progress.
Regards, Paul Boven.
stream?
You can use a variable in the delay block, and then update it using e.g.
ZMQ or XMLRPC messages. Direct feedback in a GNU Radio flowchart is not
possible, you can't have loops in a flowchart.
Regards, Paul Boven.
Radio (and all dependent packages!)
that are part of the stable release.
Regards, Paul Boven.
On 8/27/20 12:25 PM, Christophe Seguinot wrote:
Hi
I recently switched my computer to Ubuntu 20.04 and installed GNURadio
3.8.2.0 from ppa
(http://ppa.launchpad.net/gnuradio/gnuradio-releases/u
rary packages (except gnuradio itself) have a
suffix of 3.8.1 in their name. So if we were to publish
libgnuradio-runtime3.8.1 instead of libgnuradio-runtime, the higher
version number would work fine for dependent packages. Although that
would create a bit of a mess for current PPA users.
Regards, Paul Boven.
do is remove everything gnu radio related in
one go, as then there is no dependency issue any more. That's how I
resolved it a few days back.
Regards, Paul Boven.
On 7/30/20 4:50 PM, Bradley McFadden wrote:
Hello,
I've been having this problem with my apt on Ubuntu 20.04. After an upd
s for both
the grmodtool bug, and for the XMLRPC bug, indicate that those are fixed
upstream, and follow the rest of the procedure.
Regards, Paul Boven.
On 7/28/20 4:57 PM, Martin wrote:
I already found out I had to remove all CC qa code.
This is a different issue. (python qa code).
I found a
#x27;
data type, where the latter stands for 'Interleaved Short'. Using the
'Vector to Stream' block as described in my previous mail, you can
convert the vector shorts from the USRP block into interleaved shorts
which can then be converted into e.g. floats.
Regards, Paul Boven.
On
k (if it can keep up),
memory, transferred over the network, or turned into floats for further
processing.
We use this to efficiently stream raw samples over the internet using a
ZMQ Pub Sink.
Regards, Paul Boven.
t that the doppler shift calculation can simply
be included in the flowchart, and starts/stops with the flowchart.
Happy to send you some code, although some of it is specific to the
Dwingeloo telescope.
Regards, Paul Boven.
ly need anything that's in the release version,
versus the release candidate version, as far as I know - I was just
surprised that when switching to this PPA, I didn't actually get the
release version and had to investigate).
Regards, Paul Boven.
e the loop bandwidth even more, the loop does
unlock, and you can see that the output phase no longer tracks the input
phase.
Regards, Paul Boven.
Hi again,
Apologies, this is what you get from not using copy/paste...
On 06/03/2020 14:06, Paul Boven wrote:
Create a 'Variable' block, with Id 'Sine', and Value:
np.sin(np.linrange(0, 2*np.pi, samp_rate, endpoint=False)
This needs to be 'linspace', not 'linrange'.
Regards, Paul Boven.
efore.
This gives you a 1 Hz sine wave of unity amplitude.
Of course this only works if your frequency fits an integral number of
times within your sample rate. Then again, you can choose a different
length than samp_rate as well.
Regards, Paul Boven.
Hi,
There are UHD commands for sycnrhonizing your USRP to the octoclock, and
then resetting the CORDIC on each at the same time, which should allow
you to keep the same phase between them.
Please see: https://files.ettus.com/manual/page_sync.html
Regards, Paul Boven.
On 03/12/2019 08:14
flowgraph in Python or C++, and
add the required synchronization commands in there. Most of my
measurements were done with a modified uhd_rx_cfile, where I added the
synchronization logic, and an extra argument for the start time (in unix
epoch seconds).
Regards, Paul Boven.
On 10/29/19 9:04
'max_inp' should be connected to a null
sink. (I would argue that the port in question should disappear when
there's only one input).
For the value itself, there's the 'max' block, set number of inputs and
length of output vector to 1.
Regards, Paul Boven.
_
ime.sleep(1)
# Code ends here
Regards, Paul Boven.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
flag to cmake when setting up GNU Radio:
-DCPACK_DEBIAN_ARCHIVE_TYPE=gnutar
Regards, Paul Boven.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
does not satisfy the case.
Why does 'Keep M in N' not work for you?
I'd configure it with M = 10, N = 40, Initial Offset = 20.
I just made a small flow-chart with those settings, and the output is
indeed a sawtooth/staircase running from 21 to 30 (inclusive).
Rega
mply store
the output in a file.
Regards, Paul Boven.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
9952e-15
10 1534943089 6.66134e-15
11 1534943090 7.32747e-15
12 1534943091 7.99361e-15
13 1534943092 8.65974e-15
14 1534943093 9.32587e-15
15 1534943094 9.99201e-15
16 1534943095 1.06581e-14
Regards, Paul Boven.
__
f that block is therefore only 1/8th of
its input data rate.
You can use that block between your slicer and file source in the flowchart.
Regards, Paul Boven.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
expects a complex vector.
The notation would be: a+bj, so in your case, simply 1j will suffice. So
without the '*'.
Regards, Paul Boven.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listin
x27;t even hit the 'generic' case, but the
sse2 (and other cases) repeat the code from the 'generic' case to
convert any remainders that won't suffice to start a new accelerated block.
Regards, Paul Boven.
On 10/06/2018 00:20, Paul Boven wrote:
Hi again,
Ugh, you'r
alue is first promoted to a 64-bit
// value, clipped, then converted to a float.
Regards, Paul Boven.
On 06/09/2018 09:26 PM, Müller, Marcus (CEL) wrote:
Oh wait, it gets better: while the float->int16 does indeed use rintf,
float->int32 doesn't… now we don't have a majority situatio
, so that's also quite bad.
Possibly there is also an optimization opportunity of never using
'generic' even at the block edge when acceleration is available by
choosing the right size of blocks, but that's probably a small gain.
Regards, Paul Boven.
On 06/09/2018 07:18 P
there is a
cast to int16_t instead of int8_t at the end of the routine, e.g.:
https://github.com/gnuradio/volk/blob/master/kernels/volk/volk_32f_s32f_convert_8i.h#L200
I had not really looked into that before because having run the
volk_profile seemed to make no difference.
Regards, Paul Boven.
fig
volk_32f_s32f_convert_8i u_sse2 u_sse2
Regards, Paul Boven.
On 06/09/2018 05:30 PM, Müller, Marcus (CEL) wrote:
Hi Paul,
hm, OK, considering the actual conversion is done in VOLK, can you tell
us
* whether ~/.volk/volk_config exists (and if so, its contents regarding
volk_32f_s32f_convert_8i )
* what the output
Radio 3.7.11 (as packaged with Ubuntu 18.04).
Regards, Paul Boven.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
32 matches
Mail list logo
