Re: Sending a signal to a USRP N200

[Paul Boven]

Hi Isaac,

On 9/6/21 6:02 PM, isaac mario tupac davila wrote:
I'm Isaac. I am trying to discover what is happening with my USRP N200. 
I'm sending a signal of 100mVpp and 1MHz from a signal generator to 
channel RF 2 of my USRP N200 but I receive a 0v signal and a constant 
-230db (if I see it in a FFT block).


Please include which RX daughterboard you are using with the N200? What 
is RF2 connected to internally in the USRP? Does channel RF1 work for you?


In your flowchart, you're using a center frequency of 1 MHz with a 
sampling rate of 10 MS/s, which is a bit odd, 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' and 'uhd_usrp_probe'.


Regards, Paul Boven.

Re: Strange FFT AUDIO

[Paul Boven]

Hi everyone,

On 4/19/21 9:03 PM, Kevin Reid wrote:

For viewing purposes, just ignore the other side of the spectrum. (It would 
be nice if the QT GUI Frequency Sink had an option to hide it when given 
float input, but as far as I know, it doesn't.)


But it does! Just switch the input to real (float), and it will get the 
option 'Spectrum Width' in the GUI, where you can select 'Full' or 'Half'.


Regards, Paul Boven.

Re: Missing Positive Spectrum

[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 then 
view it through a sink block that also has an FFT resolution of 128 
channels. This means that the block will pick exactly 128 samples, and 
display only those. With everything a nice power of two, there is a 
potential that you're always seeing the FFT of the same part of your 
packet, which is exactly what was happening here.


Let's look at your original 'Occupied Carriers':


[np.arange(-ncarrier/2,0)]+[np.arange(1,ncarrier/2+1)]

Which produces:

[array([-16., -15., -14., -13., -12., -11., -10.,  -9.,  -8.,  -7., 
-6., -5.,  -4.,  -3.,  -2.,  -1.]),

 array([ 1.,  2.,  3.,  4.,  5.,  6.,  7.,  8.,  9., 10., 11., 12., 13.,
14., 15., 16.])]

So you have a vector of vectors, with the first inner vector running 
from -16 to -1, and the second one running from 1 to 16.


This means that the OFDM block will first consume 16 symbols and put 
them at the negative frequencies, and then it will consume another 16 
symbols, and put those at the positive frequencies. But, due to the QT 
sink block running in lockstep with all this, you only ever saw the 
negative half.


You can easily verify this by changing the QT GUI sink to have a 
resolution of e.g. 1024. You will suddenly see a symmetric spectrum. But 
don't be fooled by this either, because actually you are alternatingly 
outputting a negative (-16 ... -1) spectrum, and then a positive (1 ... 
16) spectrum.


You can prove this by adding a 'Denterleave' block with a block size of 
128, and then use two QT GUI Sink blocks (at 128 resolution again). You 
must also set the Cyclic Prefix length to zero for this demonstration to 
work. You'll see one spectrum that only has negative frequency 
components, and the other one only has positive frequency components - 
they are alternating! Clearly not what you want your OFDM signal to look 
like. The vector at the top of this mail should solve that.


Regards, Paul Boven.

Re: Missing Positive Spectrum

[Paul Boven]

Hi Jay,

On 2/12/21 12:08 AM, Jay Patel wrote:
I am trying to create an OFDM transmitter using GNU Radio Companion and 
an Analog Devices ADALM-Pluto SDR (attached my *grc file). It looks like 
i am missing something. When i visualize my spectrum, it only have 
negative side, I am expecting both side of spectrum (something like 
attached).


The problem seems to be with your 'Occupied Carriers'. This should be a 
vector of vectors of indexes, so I'm assuming that it should be 
integers, whereas arange gives you floats.


Try: [list(range(-15, 0)) + list(range(1, 16))]

This results in a symmetric spectrum.

Likewise, the format of the Pilot Carriers should be as a vector of 
vector of integers: [[-(ncarrier+1),(ncarrier+1)]]


Note that this puts the pilot carriers quite far away from your main 
signal, you may want to use some form of ncarrier//2 there. To actually 
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.

Re: Variable delay

[Paul Boven]

Hi Hassan,

On 11/25/20 6:27 PM, Hassan Khalili wrote:
I have a delay block in my flowgraph. Is it possible to change the delay 
programmatically based on a stream output further down (in a feedback 
fasion)? Or do I have to implement my own delay block with an additional 
input for a delay 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.

Re: Ho to use Limesdr and rtl dongles with GNURadio 3.8.2

[Paul Boven]

Hi Christophe,

This is unfortunately a known problem. The way GNU Radio was packaged in 
Ubuntu 20.04 is (to me) a bit odd, with the version number as part of 
the package name for most of the libraries.


If you install GR from the PPA, you will now get version 3.8.2, which is 
great. This will also include all the libraries. But if you then try to 
install a package from the regular Ubuntu repository, e.g. gr-osmosdr, 
this will pull in gnuradio-3.8.1 libraries. So now you end up with two 
versions of the gnuradio libraries installed on your system. Your 
gr-osmosdr (from the Ubuntu repositories) is linked against the 3.8.1 
versions of the libraries, whereas the gnuradio on your system links 
against the 3.8.2 version of the libraries. Then, when you try to use 
the two together, mayhem ensues.


The result of this, is that the 3.8.2 on the PPA only works with itself, 
but not with the other packages from the regular Ubuntu LTS release. 
Unfortunately, the PPA is simply broken at this time.


Fixing this is not easy, because to solve the root cause, we'd have to 
figure out how to properly package GR for Ubuntu, and then convince 
Ubuntu to upgrade the version of GNU 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/ubuntu). Version 
3.8.2 is the latest in this PPA and is installed by default.


I also installed gr-osmosdr gr-limesdr and gr-rds using sudo apt install.

Gnuradio is running fine in most cases. However, each time I run a 
flowgraph involving  SDR or LimeSDR Dongle I get the classical error:


     File "/home/-/rds_rx.py", line 571, in __init__
     self.audio_sink_1 = audio.sink(audio_rate, '', True)
     AttributeError: 'int' object has no attribute 'sink'

Looking into library folder /usr/lib/x86_64-linux-gnu I found that some 
3.8.1.1 and 3.8.0 libraries are installed and probably conflicting with 
3.8.2.0 libraries. For example, command/ll libgnuradio-runtime*/ gives


     lrwxrwxrwx 1 root root  28 aug.  22 14:29 
libgnuradio-runtime.so -> libgnuradio-runtime.so.3.8.2
     lrwxrwxrwx 1 root root  30 juil. 31 15:23 
libgnuradio-runtime.so.3.8.1 -> libgnuradio-runtime.so.3.8.1.0
     -rw-r--r-- 1 root root 1077632 juil. 31 15:23 
libgnuradio-runtime.so.3.8.1.0
     lrwxrwxrwx 1 root root  30 aug.  22 14:29 
libgnuradio-runtime.so.3.8.2 -> libgnuradio-runtime.so.3.8.2.0
     -rw-r--r-- 1 root root 1077632 aug.  22 14:29 
libgnuradio-runtime.so.3.8.2.0


It looks like 3.8.1 and 3.8.0 libraries have been installed when 
installing gr-osmosdr gr-limesdr and gr-rds


     installed libraries during gr-osmosdr install

     libgnuradio-audio.so.3.8.1

     libgnuradio-blocks.so.3.8.1

     libgnuradio-pmt.so.3.8.1

     libgnuradio-runtime.so.3.8.1

     libgnuradio-fcdproplus.so.3.8.0

     libgnuradio-iqbalance.so.3.8.0

     ilbgnuradio-uhd.so.3.8.0

     ibgnuradio-fosphor.so.3.8.0

     installed libraries during gr-rds install

     libgnuradio-analog.so.3.8.1

     libgnuradio-digital.so.3.8.1

     libgnuradio-filter.so.3.8.1


I also notice that gr-osmosdr and gr-limesdr depend on libgnuradio-xxx 
 >= 3.8.1.0~rc1. So I don't understand why 3.8.1 libraries have been 
installed after 3.8.2 libraries


Here are my questions:

  * Is the existence of these multiple libraries versions the cause of
errors?
  * Could someone please provide some link to PPA or source to compile
(for gr-osmosdr and gr-limesdr) which are compatible with GNURadio
3.8.2.0?
  * Should I reverse to GNURadio 3.8.1 using PPA
http://ppa.launchpad.net/gnuradio/gnuradio-releases/ubuntu?



Regards, Christophe

Re: apt-get breaks gnuradio 3.8.1.0

[Paul Boven]

Hi Josh, everyone,

On 7/31/20 1:31 PM, Josh wrote:
I think Paul is right - we stepped the PPA version up with the correct 
numbering scheme, but that seems to conflict with the dependencies of 
OOTs.  There are a couple of ways to deal with OOTs in the future, but 
we don't have an immediate solution other than don't mix the PPA with 
the packaged OOTs.


As far as I can see, getting a fixed GR into Ubuntu stable is going to 
take some time. Both packaging (and having a good discussion about *how* 
we want it packaged, in terms of filenames and the like), and getting it 
accepted into ubuntu-updates for 20.04.


As a short term solution, I propose to add all the packages that depend 
on the GNU Radio libraries in Ubuntu 20.04 as part of the PPA, because 
the PPA version of those libraries conflict and prevents them from 
getting installed. These can be found by running:


apt-cache rdepends libgnuradio-runtime3.8.1

The other option would be to rebuild the current PPA, with all the 
pacakges having '3.8.1' at the end of their name, and a version number 
that is higher than current PPA and release versions. Currently, the 
'official' Ubuntu library 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.

Re: apt-get breaks gnuradio 3.8.1.0

[Paul Boven]

Hi Bradley,

Unfortunately, the PPA repository is in a bit of a broken state at the 
moment: You can install GNU Radio itself from the repository, and it 
works fine, but anything like gr-osmosdr which is not in the repository 
will be dependent on the libraries as shipped with the Ubuntu release.


At the moment, you can't combine those. So if you need those, you might 
have to forego the repository.


There has been some discussion on how to properly fix this, either in 
the repository, or by getting Ubuntu 20.04 to ship a more recent build 
of GR.


What you should be able to 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 update
my gnuradio package that was installed originally from 
http://ppa.launchpad.net/gnuradio/gnuradio-releases/ubuntu seems to 
somehow be ahead of its dependencies. This has made the package corrupt, 
and I can't remove it, because apt does not want to let the package 
exist in this broken state. How should I start to fix this?

Whenever I try to install a package or upgrade, I get this error message:

$ sudo apt-get --fix-missing install
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
  gnuradio : Depends: libgnuradio-analog (>= 3.8.1.0-0~gnuradio~focal) 
but it is not installed
             Depends: libgnuradio-audio (>= 3.8.1.0-0~gnuradio~focal) 
but it is not installed

Re: gr-modtool does not seem to work in gnuradio 3.8.1 package in ubuntu 20.04

[Paul Boven]

Hi Martin, Jay, everyone,

The commit (as mentioned in your other mail) is included in the GR PPA 
package for Ubuntu (just verified this in my install).


So switching to the PPA should resolve the issue, but note that at the 
moment, the PPA doesn't play nice with e.g. gr-osmosdr, gr-iio etc.


Actually getting the Ubuntu package updated is going to require some 
paperwork. The process to update a stable release (SRU update in Ubuntu 
acronym-speak) is detailed in this page:


https://wiki.ubuntu.com/StableReleaseUpdates

Looking at the document, we should probably file bug reports 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 patch for this issue in anouther message (see my other email 
from e few minites ago).


I need to patch the installed gr_modtool add.py code from the gnuradio 
package.


Would be nice to fix the broken ubuntu package, but I don't know how to 
initiate that.


Best regards,

Martin


On 28-07-2020 16:52, Tom McDermott wrote:

 >Message: 3
 >Date: Tue, 28 Jul 2020 16:07:06 +0200
 >From: Martin <mailto:gnuradiom...@olifantasia.com>>

 >To: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org>
 >Subject: gr-modtool does not seem to work in gnuradio 3.8.1 package in
 >        ubuntu 20.04
 >Message-ID: <2df7bef0-8270-750f-7bb4-73a112914...@olifantasia.com 
<mailto:2df7bef0-8270-750f-7bb4-73a112914...@olifantasia.com>>

 >Content-Type: text/plain; charset=utf-8; format=flowed
 >
 >Hi,
 >I am trying to get my out of tree module to build and work on ubuntu
 >20.04 with the default gnuradio package gnuradio 3.8.1.0-rc1-2build2
 >
 >
 >When I use gr_modtool to create an out of tree module with an empty
 >source block then cmake gives an error.
 >
 >CMake Error at lib/CMakeLists.txt:85:
 >   Parse error.  Expected a command name, got unquoted argument with 
text

 >   "${CMAKE_CURRENT_SOURCE_DIR}/qa_testsource.cc".

I've had the same problem.   gr_modtool is generating broken cmake for 
.cc qa tests.
It was necessary to strip out all cc qa tests and files for an OOT 
project I ported to 3.8 to get it to build.
By looking at the cmake code, it's not clear what it should have 
generated, someone skilled

in cmake would probably quickly know what was meant.

The .py qa generated cmake file is correct and builds fine, so the 
error is likely in

a small area.

-- Tom, N5EG

Re: GRC max sample rate

[Paul Boven]

Hi Koyel,

I was attempting to explain why the output of the USRP block (Complex 
Int16) doesn't directly connect to other blocks. Although no other block 
in GNU radio seems to use the type 'Complex Int16', it is actually just 
a vector of size 2, containing the I and Q samples as 16 bits int.


It is possible to connect the USRP source block directly to the File 
Sink block: you just need to set Vec Length to 2 in the File Sink block, 
and set the data type to 'short'.


Other blocks in GNU Radio can use either the 'Short' or the 'IShort' 
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 7/25/20 10:22 AM, Koyel Das (Vehere) wrote:

Hi Paul,

Thanks for your help. Can you please give an example? Like if usrp 
source outputs 16 bit complex as I Q I Q I Q I Q for 4 IQ samples where 
I and Q are 16 bit complex then what will be the change in the format 
after vector to stream conversion? I understood that usrp source block 
already gives binary file where I and Q are written alternately as above 
or interleaved. So I am unable to understand when you say vector to 
stream will interleave I and Q samples.


Regards,
Koyel

Get Outlook for iOS <https://aka.ms/o0ukef>

*From:* Discuss-gnuradio 
 on behalf of 
Paul Boven 

*Sent:* Saturday, July 25, 2020 1:31:20 PM
*To:* discuss-gnuradio@gnu.org 
*Subject:* Re: GRC max sample rate
Hi Koyel,

On 7/25/20 9:19 AM, Koyel Das (Vehere) wrote:
Will there be packet drops if USRP source is set at 32 bit complex float 
in grc when receiving at 100 MSPS each from two channels? That makes 
2*100e6*64 (32 bit I and 32 bit Q) = 12800e6 or 12.8 gbps. I am unable 
to set usrp source block to 16 bit complex as then the usrp source block 
is not compatible with file sink which doesn’t have option for 16 bit 
complex.


The USRP block is (as far as I could find) the only block in all of GNU
Radio that uses the 'Complex Int16' type. Which is a bit confusing, but
it is just a vector with a length of 2, alternating the I and Q channels
as 16 bit shorts.

You can simply convert it to interleaved int16 by using a 'Vector to
Stream' block, with these settings:

io_type: short
num_items: 2
vec_length: 1

These 16 bit integers can then be written to disk (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.

Re: GRC max sample rate

[Paul Boven]

Hi Koyel,

On 7/25/20 9:19 AM, Koyel Das (Vehere) wrote:
Will there be packet drops if USRP source is set at 32 bit complex float 
in grc when receiving at 100 MSPS each from two channels? That makes 
2*100e6*64 (32 bit I and 32 bit Q) = 12800e6 or 12.8 gbps. I am unable 
to set usrp source block to 16 bit complex as then the usrp source block 
is not compatible with file sink which doesn’t have option for 16 bit 
complex.


The USRP block is (as far as I could find) the only block in all of GNU 
Radio that uses the 'Complex Int16' type. Which is a bit confusing, but 
it is just a vector with a length of 2, alternating the I and Q channels 
as 16 bit shorts.


You can simply convert it to interleaved int16 by using a 'Vector to 
Stream' block, with these settings:


io_type: short
num_items: 2
vec_length: 1

These 16 bit integers can then be written to disk (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.

Re: Looking for a way to plot V_LSR vs intensity in GNU Radio

[Paul Boven]

Hi Ellie,

On 7/24/20 5:09 PM, Ellie White wrote:
My question is this: do any of you know of a method -- or a GNU Radio 
module -- compatible with GR version 3.8 that allows you to plot raw 
data from a USRP and get a plot of intensity versus velocity with 
respect to the local standard of rest (V_LSR) -- instead of intensity 
versus frequency, as given by the time sink block?


We solved this somewhat differently: I wrote some Python code that, 
given Ra/Dec (which we can get from the telescope) and 
date/time/position, calculates the V_LSR for that viewing direction. The 
calculation itself is done in Astropy, hence the need for Python3, and 
the reason we upgraded to GR 3.8 as soon as we could. One of our other 
volunteers wrote a Telescope class that can be queried for pointing 
direction and the like.


The frequency offset is calculated every second, and sent back into the 
flowchart using ZMQ. The ZMQ sink sends the tuning commands to a 
frequency-translating-fir block to shift the received frequency 
automatically. The advantage of using this method is that the frequency 
bins for the FFT integration stay at the same V_LSR during long 
observations, or observations carried out at another date/time, so you 
don't need to resample/interpolate to compare.


As we show the integrated spectrum using the Vector Sink anyway, it's 
very easy to have it calculate the x-axis labels in terms of doppler 
velocity, instead of frequency.


We took some extra effort 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.

Ubuntu PPA gnuradio-releases doesn't actually install

[Paul Boven]

Hi everyone,

Ubuntu 20.04 (Focal) ships with GNU Radio 3.8.1.0~rc1-2build2. I have 
added the gnuradio-releases PPA on my machine, assuming that it would 
get me the slightly newer release version of 3.8.1.0. However, after 
adding the PPA, the Ubuntu provided release candidate version still gets 
installed, not the PPA version.


apt policy gnuradio:
  Installed: 3.8.1.0~rc1-2build2
  Candidate: 3.8.1.0~rc1-2build2
  Version table:
 *** 3.8.1.0~rc1-2build2 500
500 http://nl.archive.ubuntu.com/ubuntu focal/universe amd64 
Packages

100 /var/lib/dpkg/status
 3.8.1.0~gnuradio~focal-1 500
500 http://ppa.launchpad.net/gnuradio/gnuradio-releases/ubuntu 
focal/main amd64 Packages


So the package is seen as available, but the OS prefers the rc1 version. 
Is this because the version number string is considered 'higher' 
alphabetically than the version string of the PPA version? 
(3.8.1.0~rc1-2build2 against 3.8.1.0~gnuradio~focal-1). Did we get the 
naming or version numbering convention wrong in the PPA?


After some research, I managed to install the PPA version:
sudo apt install gnuradio=3.8.1.0~gnuradio~focal-1

This fails at first, because all of the Ubuntu provided gnuradio library 
packages have 3.8.1.0 in their name, whereas the PPA packages don't - so 
they are not seen as up/downgrades, and instead, massive file conflicts 
ensue. These can be resolved by first removing the gnuradio package, and 
all its dependencies, and then installing the gnuradio from the PPA. 
This will then pull in all the dependencies from the PPA as well.


But on the next 'apt upgrade', the PPA version will be replaced again by 
the OS version (causing the same level of mayhem), unless I start 
pinning stuff.


(I don't particularly 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.

Re: analog_pll_carriertracking_cc bug

[Paul Boven]

Hi David, list,

On 4/4/20 10:18 PM, David Hagood wrote:
I applied your correction of multiplying by 2pi, and while it locks now, 
it also doesn't seem to be very clean - there's a lot of noise on the 
signal, and the phase compared to the reference still is running through 
the unit circle. I've tried increasing and decreasing the loop 
bandwidth, and I cannot get what I would consider a clean signal out.


The PLL blocks took a bit of tinkering for me to get them to work. As 
Michael already explained, frequency is listed in radians per sample, 
instead of Herz. That leaves setting your start and stop frequency, and 
the loop bandwidth.


Although the documentation suggest to use values between pi/200 and 
2pi/100, I've found that you need to go to much lower values to get it 
to do proper filtering.


As an example: To track the FM Stereo pilot signal at 19kHz, I'm using 
these settings:


Sample Rate: 250 kHz
Max Freq: (19000 + 100)*np.pi*2/samp_rate
Min Freq: (19000 - 100)*np.pi*2/samp_rate
Loop Bandwidth: np.pi/2

I am using the 'PLL Ref Out' block, but that works just the same way as 
the one you are looking at, it just outputs the locked signal at its 
original frequency, instead of at DC.


In the attached graph, you can see the input signal (Data 0, in blue), 
and the PLL filtered 19kHz (in red). The peak of the input and output 
match perfectly, and you can see that the output (Red, Data 1) is much 
cleaner. If I decrease 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.

Re: Weird behaviour of the analog signal source

[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.

Re: Weird behaviour of the analog signal source

[Paul Boven]

Hi Lukas,

On 03/03/2020 16:52, Lukas Haase wrote:

3.) What would you do if you would want to create precise timing signals? Is a 
custom block really the only way? And then, how would you implement it?


This is a problem that I've run into as well in the past. You don't have 
to create a custom block to work around it. You can simply create a 
vector with your samples, and play that back on repeat. Use the 'Vector 
Source' instead of the Signal Source.


Create an 'Import' block, with contents for the import field:
import numpy as np

Create a 'Variable' block, with Id 'Sine', and Value:
np.sin(np.linrange(0, 2*np.pi, samp_rate, endpoint=False)

Create a 'Vector Source' block, set 'Sine' as the Vector, Repeat = Yes, 
Output Type = Float, Vector Length = 1.


Include the 'Throttle' and other blocks as before.

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.

Re: Question about phase synchronization with X310 and two UBX 40

[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, Masatetsu Wake wrote:

Hello all,

My customer is using X310 with two UBX 40 daugther boards and would like 
to know how he can synchronize the phase.


Below is the some of the steps he is trying:

1.
I add "dboard_clock_rate=20e6" to the "device arguments" field of
the property for the UHD Source block, as the following URL
shows.
<<https://kb.ettus.com/UBX 
<https://urldefense.com/v3/__https:/kb.ettus.com/UBX__;!!FbZ0ZwI3Qg!-iZCEFpd1GU9lieXJ1xUlTGGU5pT1_gVKZxwV5kBn_Bvh4NhUZaZoAVt9Oc4ZBXz$>>>

2.
Octoclock is connected to all of the four receivers (X310),
and "clock_source" and "time_source" are "external" in the
UHD Source block.
3.
Each channel adds phase bias (value is random) everytime the program starts.

He would like the phase bias to be constant.

My customer can not share his code since he needs approvl to send 
program outside of the company.


It is possible to share sample code (e.g. grc file) for phase 
synchronization.


Thank you,

Masatetsu Wake

Account Manager

National Instruments Japan

M +81.80.5174.9003

masatetsu.w...@ni.com

Re: Synchronous recording with two USRP B210

[Paul Boven]

Hi Ali,

Your CDA-2990 (OctoClock?) distributes both a frequency reference signal 
(10MHz) and a time reference signal (1PPS). To get both USRP to record 
at the same time, you need to first get them to run on the same time 
internally, and then tell them both, in advance, at what time to start 
streaming.


Unfortunately, that will take a bit of tinkering, and cannot be done 
from just regular GRC blocks at the moment.


The first half of the problem, getting them to run at the same time, is 
a bit more difficult than it should be, as it involves writing some code 
to turn your 'unknown PPS' into a know PPS. Basically, you read out the 
PPS status from one of the USRPs, and once you see that it changes (i.e. 
a PPS edge has just been detected by it) you read out the time on your 
PC, add one second to it, and tell both USRPs that they have to set 
themselves to this time value at their next PPS. For more details, see:


https://files.ettus.com/manual/page_sync.html

Once you have this done, you can send a command to each USRP to start 
streaming at a particular second. This could be done either from two 
separate applications, or just one that talks to both USRPs, using two 
UHD source blocks.


I've 'hacked' the required statements into the python code that gets 
generated when your GRC file is compiled. That has the huge drawback of 
having to re-patch it every time you change the flowgraph. This approach 
gets more convenient if you write your 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 PM, alireza nazari wrote:

Hi,

I am trying to use GNURadio to receive signals and record them to files 
from two USRP B210(each has two channels). Both SDRs are connected to an 
CDA-2990 external clock. In gnuRadio I had to put two UHD source blocks 
and use "serial=xxx" to point them to each SDR and connect each output 
channel to 4 file Sink blocks. I also changed the clock and time source 
to "external" and synced to "unknown PPS".  However, a couple of files 
are different in size from the other couple. Apparently if I want to 
start them synchronously, all four channels should be in one source 
block, but how can I do that and point out each 2 channels come from a 
different device? When I try one USRP source block 
with "serial0=31A3C93,serial1=31A3D4B", I face an error bellow:

/Traceback (most recent call last):
   File "E:\Alireza\sdr_A20\top_block.py", line 207, in 
     main()
   File "E:\Alireza\sdr_A20\top_block.py", line 201, in main
     tb = top_block_cls()
   File "E:\Alireza\sdr_A20\top_block.py", line 125, in __init__
     self.uhd_usrp_source_0.set_clock_source('external', 1)
   File "E:\Program 
Files\PothosSDR\lib\python2.7\site-packages\gnuradio\uhd\uhd_swig.py", 
line 2987, in set_clock_source
     return _uhd_swig.usrp_source_sptr_set_clock_source(self, source, 
mboard)
RuntimeError: LookupError: IndexError: multi_usrp::mb_root(1) - 
LookupError: IndexError: multi_usrp::mb_root(1) - path not found

/

Is there any example available on how I can synchronously start 
recording from different devices? I assume this is a trivial task but I 
have been searching for this for a few days right now and I can't find 
any helpful answer. I am attaching my .grc files.


Thank you,
Ali

Re: [Discuss-gnuradio] Determine index of max value in FFT

[Paul Boven]

Hi Tom,

On 9/30/19 3:27 PM, tom sutherland via Discuss-gnuradio wrote:
How do you determine the index of the maximum value of the output of a 
FFT? e.g. I have a FFT  and then a "ComplexToMag^2" block and I want to 
know the max value and its corresponding index (i.e. for a 4096 point 
FFT the index occured at 63).


The argmax block will give you the index to the vector element with the 
largest value. Set its number of inputs to 1, and the vector length as 
appropriate. The 'max_vec' output gives the number you are looking for.


As there is only one vector, the '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.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Sending Data/Messages to GNU Radio via Python Application

[Paul Boven]

Hi,

On 08/09/2019 21:29, Rajen Goradia wrote:
I am trying to make use of the ZMQ blocks in GNU Radio to act as a 
server and have a separate python client application send data/messages 
to GNU Radio. I was successful in getting data out of GNU Radio and 
using a separate python application such as using the “ZMQ PUSH Sink” 
block in GNU Radio and using the zmq library in Python 
(context.socket(zmq.PULL) function) but I was unable to reverse the 
procedure. Has anybody successfully tried doing this, either with or 
without using the zmq library or the ZMQ blocks in GNU Radio? Please let 
me know and thank you for looking.


Happen to have just done this a few weeks ago, to compensate for doppler 
shift on 21cm (Hydrogen line) observations. What worked for me is listed 
below. This should work with Python 2 and GR 3.7 as well, but I ended up 
using GNU Radio 3.8 because astropy requires python 3. The code sends a 
'freq' message, which you can feed to e.g. the command port of a 
Frequency XLAT FIR filter, see the attached image.


#!/usr/bin/python3
# Note: use Python 2 for older versions of GR
import pmt
import zmq
import time

# Open a ZeroMQ publisher socket on localhost, port 
context = zmq.Context()
socket = context.socket(zmq.PUB)
socket.bind("tcp://127.0.0.1:")

doppler = 0.1

while(1):
  msg = pmt.cons(pmt.intern("freq"), pmt.from_double(doppler))
  sb = pmt.serialize_str(msg)
  socket.send(sb)
  doppler = doppler + 0.1
  time.sleep(1)

# Code ends here

Regards, Paul Boven.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] An obscure cmake bug

[Paul Boven]

Hi everyone,

When building UHD and GNU Radio, I usually opt to use 'make package', to 
then install the resulting debian package on my machine. For me, this 
has the advantage that all the installed filed are registered with the 
package manager, and it is easy to cleanly remove my install again so I 
don't end up with conflicting GR installs.


However, for GNU Radio, 'make package' already for a long time results 
in a .deb that cannot be installed, apt chokes on it with the message 
that the tar file is corrupt. When disassembling the package by hand, 
tar has no issues reading the tar file. It turns out however that the 
tar command within dpkg doesn't implement various tar extensions, and 
one (just one) filename in the resulting tar file is long enough that it 
requires a tar extension block to encode it. Cmake by default used the 
'paxr' format for this.


Because of this, I filed a bug with the maintainers of cmake, who 
quickly addressed the issue.


https://gitlab.kitware.com/cmake/cmake/issues/18620#note_486393

Until this fix actually makes it into cmake installs at end users, a 
workaround would be to add a 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

Re: [Discuss-gnuradio] Passing specific range of I/p signal to o/p

[Paul Boven]

Hi Ayaz,

On 11/11/18 6:38 PM, Ayaz Mahmud wrote:

Repetitive case:
Input signal is : [1,2,3,4………40]
Output signal should be: [21,22,23….30]

Values can be random here, but I want to pass only the position [20:30] 
out of 40.


I have tried with “Keep M in N” block and “Skip Head” block, but this 
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).


Regards, Paul Boven.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Storing temporary data in GNU Radio

[Paul Boven]

Hi Nick,

On 09/18/2018 05:17 AM, Nick Sukhov wrote:

I need to implement following procedure in GNU Radio and I’m lost on how to do 
it. I want to split a stream of data into a vectors, than add up these vectors 
consequently for some time (1000 additions for instance) and then store the 
information into file.


Doesn't the 'integrate' block do exactly what you want? You tell it the 
size of your vector, and how many times to do the addition 
(integration). After enough integrations have happened, it will push out 
the result as a vector and start again, and you can then simply 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

[Discuss-gnuradio] rx_time tags off by 0.7 fs

[Paul Boven]

Hi everyone,

We have an X310 + TwinRX, which is locked to a Rb, which itself is 
synchronized against GPS. I've made some adaptations to uhd_rx_cfile to 
make it use the external clock inputs, to set its clock to 
int(time.time()+1) on the next PPS edge, and to start streaming at the 
next integer second after that.


The rx_time tag correctly starts at an integer second, and there's 100 
tags every second. However, when I look at the tags for the integer 
seconds, I see a small offset of 6.66134e-16 s added for every 
subsequent second. Presumably due to the precision at which the tag is 
printed, the effect is only visible for the integer seconds.


After a lot of head scratching, the cause seems to be that time and/or 
sample rate is actually a floating point number instead of an integer. 
And if you do 100 additions of 0.01s you don't get a full second, you 
get a little more:


t=0.0
for i in range(100):
  t= t + 0.01
print (t - int(t))
Result: 6.66133814775e-16

Now a sub femto-second offset doesn't seem much to get excited about 
(unless you're a time-nut), but we're planning to use this to compare 
atomic clock signals using VLBI. If this effect were real, we might 
detect it in observations of more than a few hours.


A dump of the rx_time header, filtered to just the sample number, 
integer second and fraction of each integer second is below. The 
recording in question was done at a sampling rate of 100MS/s.


 0 1534943079 0
 1 1534943080 6.66134e-16
 2 1534943081 1.33227e-15
 3 1534943082 1.9984e-15
 4 1534943083 2.66454e-15
 5 1534943084 3.33067e-15
 6 1534943085 3.9968e-15
 7 1534943086 4.66294e-15
 8 1534943087 5.32907e-15
 9 1534943088 5.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.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] What to do after binary slicer?

[Paul Boven]

Hi Guilherme,

On 08/14/2018 05:45 PM, Guilherme Theis wrote:
I made this FSK flow and I noticed that my outpout is getting zero 
padded, which means that if I have a bit 1 my output comes as "0001" 
and if I have a bit 0 my output come as "", I suppose that this 
is something related to the binary slicer. How can I delete those extra 
zeros? I thought I could do that with one of those blocks:


1) Binary repack;
2) Packed to unpacked
3) Unpacked to packed

I made some test with those blocks, but I can't understand how they 
work, even if they present a "expected" output. 


The outcome of the slicer will always be a zero or one, and each sample 
is sent as a byte, either 0x00 or 0x01 as you already discovered.


To store them more efficiently, you would use either the 'Unpacked to 
Packed', the 'Pack K bits' blocks or the 'Repack Bits' blocks.


If you use 'Pack K bits' and set K to 8, it neatly packs every 8 bytes 
(with only a 0 or 1 in them) into a single byte. The first bit to arrive 
will get weight 128, then 64, then 32 etc, and the last bit will have a 
weight of 1. The data rate out of 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

Re: [Discuss-gnuradio] multiply const block

[Paul Boven]

Hi Linda,

On 08/04/2018 10:42 PM, Linda20071 wrote:
Can the constant be a complex number? For example, Can I set the 
constant to be 1.0*j, which should rotate the constellation graph by 90 
degrees?


Yes, it can be a complex number. If you hover with the mouse over the 
field, it even says it 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/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] volk float32->int8 kernel and thus float_to_char block round or floor, depending on VOLK machine

[Paul Boven]

Hi again,

I just realised an internal inconsistency in what I wrote, and had to 
dig a bit deeper still:


In Volk, float to int has two behaviours, like described below.

But the Float->Int block does not call the Volk routines. Instead, it 
calls float_array_to_int, which in turn calls llrintf().


https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/float_array_to_int.cc

So both the Float->Int and Float->Short cases will always use actual 
rounding, and the odd one out seems to be the Float->Char 'generic' case.


And with Volk you normally wouldn'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're right. When looking at the Volk libraries, I find:

Int: int() for generic, like rintf() with acceleration
Short: always rintf()
Char: int() for generic, like rintf() with acceleration but occasionally 
int().


The thing that puzzled me is that I cannot get GnuRadio to show 
different behaviour for the Float->Int case, whereas a small test 
program does show different behaviour depending on what's in 
.volk/volk_config.


That mystery is easily solved, because the use of Volk is commented out 
in the float_to_int block:


https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/float_to_int_impl.cc 



// Disable the Volk for now. There is a problem for large 32-bit ints that
// are not properly represented by the precisions of a single float, which
// can cause wrapping from large, positive numbers to negative.
// In gri_float_to_int, the value 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 situation pro-
rounding anymore… argh.
On Sat, 2018-06-09 at 19:24 +, Müller, Marcus (CEL) wrote:

Hi Paul,

I agree with everything you say. Float to char should behave
*exactly*
like float to int and short. Will fix it in that way. Will also have
a
truncating version, maybe. I've just added 3 lines of code to the
current implementation to demonstrate it's trivial to change the
rounding mode. X87 FPUs are darn mighty things.

This brings me to another aspect: As far as I can tell from this
height
is that VOLK code absolutely neglects to configure the FPU to a known
state. If the calling thread decides to do a

_MM_SET_ROUNDING_MODE(_MM_ROUND_TOWARD_ZERO);

before calling volk_32f_s32f_convert_8i, all the kernels behave like
the truncate-to-0 generic kernel. That can't be what we want, nor is
it
documented.

So, that's a bigger issue with VOLK: on one hand, we'd want to set
that
SIMD FPU control register (MXCSR) on every entry into a volk kernel
that uses rounding, under- or overflowing SIMD intrinsics to have
defined behaviour. Since we are nice programmers, we don't want to
have
surprising side effects, so we'd restore it to its original state on
exit... I see pipeline flush and performance bottleneck right there,
but it's IA64 calling convention to save and restore as callee.

Best regards,
Marcus
On Sat, 2018-06-09 at 20:18 +0200, Paul Boven wrote:

Hi Marcus,

I would prefer that when going from float to int, every 'bin'
should
have equal size. So I can think of two ways to do that:

1) zero corresponds to [-0.5 : 0.4999]

or

2) zero corresponds to [0.0 : 0.99]

whereas the 'generic' optimization does

3) zero corresponds to [-1 to 0.99]

The second was actually the behaviour I was expecting, and I was
pleasantly surprised when GnuRadio seemed to do the first - but
then
occasionally it doesn't.

I just did a quick test in python3, and there, the range of int(x)
for
zero runs [-0.99 : 0.99], so I'm expecting most
programming
languages to behave that way.

So, I guess a programmer would expect the behaviour as in the
third
case. Someone who is converting radio signals might want either
the
first or second case, as otherwise you end up with some
interesting
non-linearities.

The gnuplot helpfile states: " The `int(x)` function returns the
integer
part of its argument, truncated toward zero."

But gnuplot also provides functions like 'floor(x)' and ceil(x).

So the real question is still, do we want the behaviour of int(x),
or
the behaviour that an analog to digital converter would have?

Finally, I'd say we want the behaviour to be the same for Int,
Short
and
Char. So I ran a few more tests.

With Volk enabled, Float to Int, Short and Char treat [-0.5 :
0.49]
as zero, with the occasional glitch for Char.

volk_32f_s32f_convert_16i a_avx u_avx
volk_32f_s32f_convert_32i a_avx u_sse2

With these conversions for Int and Short also switched to 'generic
generic', I get the same results:

Short zero: [-0.

Re: [Discuss-gnuradio] volk float32->int8 kernel and thus float_to_char block round or floor, depending on VOLK machine

[Paul Boven]

Hi again,

Ugh, you're right. When looking at the Volk libraries, I find:

Int: int() for generic, like rintf() with acceleration
Short: always rintf()
Char: int() for generic, like rintf() with acceleration but occasionally 
int().


The thing that puzzled me is that I cannot get GnuRadio to show 
different behaviour for the Float->Int case, whereas a small test 
program does show different behaviour depending on what's in 
.volk/volk_config.


That mystery is easily solved, because the use of Volk is commented out 
in the float_to_int block:


https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/float_to_int_impl.cc

// Disable the Volk for now. There is a problem for large 32-bit ints that
// are not properly represented by the precisions of a single float, which
// can cause wrapping from large, positive numbers to negative.
// In gri_float_to_int, the value 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 situation pro-
rounding anymore… argh.
On Sat, 2018-06-09 at 19:24 +, Müller, Marcus (CEL) wrote:

Hi Paul,

I agree with everything you say. Float to char should behave
*exactly*
like float to int and short. Will fix it in that way. Will also have
a
truncating version, maybe. I've just added 3 lines of code to the
current implementation to demonstrate it's trivial to change the
rounding mode. X87 FPUs are darn mighty things.

This brings me to another aspect: As far as I can tell from this
height
is that VOLK code absolutely neglects to configure the FPU to a known
state. If the calling thread decides to do a

_MM_SET_ROUNDING_MODE(_MM_ROUND_TOWARD_ZERO);

before calling volk_32f_s32f_convert_8i, all the kernels behave like
the truncate-to-0 generic kernel. That can't be what we want, nor is
it
documented.

So, that's a bigger issue with VOLK: on one hand, we'd want to set
that
SIMD FPU control register (MXCSR) on every entry into a volk kernel
that uses rounding, under- or overflowing SIMD intrinsics to have
defined behaviour. Since we are nice programmers, we don't want to
have
surprising side effects, so we'd restore it to its original state on
exit... I see pipeline flush and performance bottleneck right there,
but it's IA64 calling convention to save and restore as callee.

Best regards,
Marcus
On Sat, 2018-06-09 at 20:18 +0200, Paul Boven wrote:

Hi Marcus,

I would prefer that when going from float to int, every 'bin'
should
have equal size. So I can think of two ways to do that:

1) zero corresponds to [-0.5 : 0.4999]

or

2) zero corresponds to [0.0 : 0.99]

whereas the 'generic' optimization does

3) zero corresponds to [-1 to 0.99]

The second was actually the behaviour I was expecting, and I was
pleasantly surprised when GnuRadio seemed to do the first - but
then
occasionally it doesn't.

I just did a quick test in python3, and there, the range of int(x)
for
zero runs [-0.99 : 0.99], so I'm expecting most
programming
languages to behave that way.

So, I guess a programmer would expect the behaviour as in the
third
case. Someone who is converting radio signals might want either
the
first or second case, as otherwise you end up with some
interesting
non-linearities.

The gnuplot helpfile states: " The `int(x)` function returns the
integer
part of its argument, truncated toward zero."

But gnuplot also provides functions like 'floor(x)' and ceil(x).

So the real question is still, do we want the behaviour of int(x),
or
the behaviour that an analog to digital converter would have?

Finally, I'd say we want the behaviour to be the same for Int,
Short
and
Char. So I ran a few more tests.

With Volk enabled, Float to Int, Short and Char treat [-0.5 :
0.49]
as zero, with the occasional glitch for Char.

volk_32f_s32f_convert_16i a_avx u_avx
volk_32f_s32f_convert_32i a_avx u_sse2

With these conversions for Int and Short also switched to 'generic
generic', I get the same results:

Short zero: [-0.5 : 0.49]
Int zero:   [-0.5 : 0.49]

So, assuming I carried out these tests correctly, the odd one out
seems
to be the generic case for float to char conversion.

Note that Volk in the 16 bit and 32 bit case uses a function
called
'rintf' in the conversions. From its manpage:

"(...) round  their argument  to  an integer value in floating-
point
format".

So I say this boils down to a bug in the 'generic' float to char
case.

This is not a fix to make lightly, because somebody is going to
have
their flowchart break because of this. Then again, in the current
situation the outcome depends on which optimizations your machine
happens to have available, 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 availab

Re: [Discuss-gnuradio] volk float32->int8 kernel and thus float_to_char block round or floor, depending on VOLK machine

[Paul Boven]

Hi Marcus,

I would prefer that when going from float to int, every 'bin' should 
have equal size. So I can think of two ways to do that:


1) zero corresponds to [-0.5 : 0.4999]

or

2) zero corresponds to [0.0 : 0.99]

whereas the 'generic' optimization does

3) zero corresponds to [-1 to 0.99]

The second was actually the behaviour I was expecting, and I was 
pleasantly surprised when GnuRadio seemed to do the first - but then 
occasionally it doesn't.


I just did a quick test in python3, and there, the range of int(x) for 
zero runs [-0.99 : 0.99], so I'm expecting most programming 
languages to behave that way.


So, I guess a programmer would expect the behaviour as in the third 
case. Someone who is converting radio signals might want either the 
first or second case, as otherwise you end up with some interesting 
non-linearities.


The gnuplot helpfile states: " The `int(x)` function returns the integer 
part of its argument, truncated toward zero."


But gnuplot also provides functions like 'floor(x)' and ceil(x).

So the real question is still, do we want the behaviour of int(x), or 
the behaviour that an analog to digital converter would have?


Finally, I'd say we want the behaviour to be the same for Int, Short and 
Char. So I ran a few more tests.


With Volk enabled, Float to Int, Short and Char treat [-0.5 : 0.49] 
as zero, with the occasional glitch for Char.


volk_32f_s32f_convert_16i a_avx u_avx
volk_32f_s32f_convert_32i a_avx u_sse2

With these conversions for Int and Short also switched to 'generic 
generic', I get the same results:


Short zero: [-0.5 : 0.49]
Int zero:   [-0.5 : 0.49]

So, assuming I carried out these tests correctly, the odd one out seems 
to be the generic case for float to char conversion.


Note that Volk in the 16 bit and 32 bit case uses a function called 
'rintf' in the conversions. From its manpage:


"(...) round  their argument  to  an integer value in floating-point 
format".


So I say this boils down to a bug in the 'generic' float to char case.

This is not a fix to make lightly, because somebody is going to have 
their flowchart break because of this. Then again, in the current 
situation the outcome depends on which optimizations your machine 
happens to have available, 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 PM, Müller, Marcus (CEL) wrote:

Hi Paul,

yes, this seems to be the case where the "naive" C implementation
behaves differently from all the SIMD ones:

As far as I know – but I'm desparately looking for any standards
document that specifies that – doing a

int8_t val = (int8_t) 8.8f;

will always lead to 8, whereas

int8_t val = (int8_t) -8.8f;

would always lead to -8.

Now, for the conversion operations used in the SIMD kernels, it depends
on specific flags being set in FPU-control registers (MXCSR, it seems).
U. Noone set these to give identical results as the native C
conversion above, so if I set the tolerance in the kernel unit test to
0 instead of 1 (which it always should have been), I get a whole lot of
failures. Great.

Normally, we'd stick with the what the generic version of a kernel
gives us.

I'd do that here, too. But: that would lead to a non-rounding
behaviour... I'm breaking someone's porcelain here, no matter what I
do.

Any ideas?

Best regards,
Marcus

On Sat, 2018-06-09 at 18:24 +0200, Paul Boven wrote:

Hi Marcus,

Just reran the test after editing volk_config, and the result is
somewhat surprising:

Every float in [-1:1] now converts to zero. Every float in [1:2] now
converts to 1. Whereas it should be [-0.5:0.5] and [0.5:1.5].

It seems that most of the time, the u_sse2 converter is used, but at
the
end of each multiple of 8192 bytes, a few are done with the
'generic'
converter - that would match perfectly with the observed behaviour.

It was also pointed out to me (on irc, unfortunately no longer in my
history) that it is strange that for some acceleration types, 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_s3
2f_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.

On 06/09/2018 06:08 PM, Müller, Marcus (CEL) wrote:

I can reproduce these, but do the errors disappear for you if you
replace "u_sse2 u_sse2" with "generic generic" on that line?


Best regards,
Marcus
On Sat, 2018-06-09 at 18:04 +0200, Paul Boven wrote:

Hi Marcus,

This machine did not yet have a volk_config when I ran these
tests.

I have since run volk_profile and rebooted, and the Float->Char
quantization bug still occurs.

Re: [Discuss-gnuradio] Incorrect quantizations when converting from float to char

[Paul Boven]

Hi Marcus,

Just reran the test after editing volk_config, and the result is 
somewhat surprising:


Every float in [-1:1] now converts to zero. Every float in [1:2] now 
converts to 1. Whereas it should be [-0.5:0.5] and [0.5:1.5].


It seems that most of the time, the u_sse2 converter is used, but at the 
end of each multiple of 8192 bytes, a few are done with the 'generic' 
converter - that would match perfectly with the observed behaviour.


It was also pointed out to me (on irc, unfortunately no longer in my 
history) that it is strange that for some acceleration types, 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.

On 06/09/2018 06:08 PM, Müller, Marcus (CEL) wrote:

I can reproduce these, but do the errors disappear for you if you
replace "u_sse2 u_sse2" with "generic generic" on that line?


Best regards,
Marcus
On Sat, 2018-06-09 at 18:04 +0200, Paul Boven wrote:

Hi Marcus,

This machine did not yet have a volk_config when I ran these tests.

I have since run volk_profile and rebooted, and the Float->Char
quantization bug still occurs.

$ volk-config-info --machine
avx2_64_mmx_orc

$ grep volk_32f_s32f_convert_8i .volk/volk_config
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 of `volk-config-info --machine` is?

Thanks,
Marcus

On Sat, 2018-06-09 at 17:13 +0200, Paul Boven wrote:

Hi everyone,

I'm trying to perform 2 bit sampling of an RF signal. In one
approach,
I'm using a float->char block, and noticed that around zero, a
number
of
float inputs become quantized in a bin that's one off from the
correct
value. The ones that are wrong are always off by one, with their
quantization error always in the direction of zero.

The problem can be demonstrated with a really simple flowchart,
using
the following blocks:

* Noise Source (Noise Type: Gaussian, Amplitude: 1, Seed: 0,
Output
type: Float)
* Throttle
The throttle is then connected to two blocks:
* A file-sink (Type Float) and a
* 'Float to Char' block.
* The float to char block is again connected to a File Sink, now
of
type
Char.

As an example, I've plotted all the samples that quantized as
zero.
These should fall in the range [-0.5:0.5], but occasionally we
also
get
hits that lie within [-1:1]. These mishaps are rare (about one in
2000).
It also shows that they only occur at multiples of 8192 samples,
and
zooming in reveals that they always happen shortly before the
next
multiple of 8192, not after.

For other values than 0, the same applies, but the
misquantizations
are
only in one direction, ending up in a lower bin if the input is
positive, or in a higher bin if the input is negative. Again, the
misquantizations only occur in half the bin: For a value of 1,
the
float
value should be in [0.5:1.5], but occasionally a value in [1.5:2]
also
ends up being quantized as 1.

This seems to me a bug that is somehow related to internal block
boundaries, but I'm not familiar enough with the internals of
GnuRadio
to figure out just what's going wrong.

The problem does NOT occur when converting to Short or Int.

This is using GnuRadio 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





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Incorrect quantizations when converting from float to char

[Paul Boven]

Hi Marcus,

This machine did not yet have a volk_config when I ran these tests.

I have since run volk_profile and rebooted, and the Float->Char 
quantization bug still occurs.


$ volk-config-info --machine
avx2_64_mmx_orc

$ grep volk_32f_s32f_convert_8i .volk/volk_config
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 of `volk-config-info --machine` is?

Thanks,
Marcus

On Sat, 2018-06-09 at 17:13 +0200, Paul Boven wrote:

Hi everyone,

I'm trying to perform 2 bit sampling of an RF signal. In one
approach,
I'm using a float->char block, and noticed that around zero, a number
of
float inputs become quantized in a bin that's one off from the
correct
value. The ones that are wrong are always off by one, with their
quantization error always in the direction of zero.

The problem can be demonstrated with a really simple flowchart,
using
the following blocks:

* Noise Source (Noise Type: Gaussian, Amplitude: 1, Seed: 0, Output
type: Float)
* Throttle
The throttle is then connected to two blocks:
* A file-sink (Type Float) and a
* 'Float to Char' block.
* The float to char block is again connected to a File Sink, now of
type
Char.

As an example, I've plotted all the samples that quantized as zero.
These should fall in the range [-0.5:0.5], but occasionally we also
get
hits that lie within [-1:1]. These mishaps are rare (about one in
2000).
It also shows that they only occur at multiples of 8192 samples, and
zooming in reveals that they always happen shortly before the next
multiple of 8192, not after.

For other values than 0, the same applies, but the misquantizations
are
only in one direction, ending up in a lower bin if the input is
positive, or in a higher bin if the input is negative. Again, the
misquantizations only occur in half the bin: For a value of 1, the
float
value should be in [0.5:1.5], but occasionally a value in [1.5:2]
also
ends up being quantized as 1.

This seems to me a bug that is somehow related to internal block
boundaries, but I'm not familiar enough with the internals of
GnuRadio
to figure out just what's going wrong.

The problem does NOT occur when converting to Short or Int.

This is using GnuRadio 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



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio