Re: [USRP-users] Libuhd issues - "uhd_find_devices: error while loading shared libraries"

[Fabian Schwartau via USRP-users]

Ohh sorry,
just read the error message properly :D
You have an empty device string in your software when opening it.

Am 10.12.2019 um 00:06 schrieb Saeid Hashemi:

Thank you for your advice Fabian!

It seems there is no package called libuhd, just the following versions:
libuhd003     libuhd3.14.0  libuhd-dev

So I did:

$ sudo dpkg -P libuhd3.14.0
(Reading database ... 291299 files and directories currently installed.)
Removing libuhd3.14.0:amd64 (3.14.0.0-0ubuntu1~trusty1) ...
Purging configuration files for libuhd3.14.0:amd64 
(3.14.0.0-0ubuntu1~trusty1) ...

Processing triggers for libc-bin (2.19-0ubuntu6.15) ...
$ sudo apt-get install libuhd3.14.1

And now UHD tools work, also within the LTE software, but they won't 
find my B210 saying:


[INFO] [UHD] linux; GNU C++ version 4.8.4; Boost_105400; 
UHD_3.14.1.1-release

Error: LookupError: KeyError: No devices found for ->
Empty Device Address

Regards,
Saeid




On Fri, Dec 6, 2019 at 2:58 AM Fabian Schwartau via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


You have an old version of libuhd already installed. Uninstall it using:
$ sudo dpkg -P libuhd
Then retry installing it. Sometimes libraries are not found and you
have
to run
$ sudo ldconfig
but that is usually done by dpkg.

Am 06.12.2019 um 00:31 schrieb Saeid Hashemi via USRP-users:
 > Hello everyone,
 >
 > I have an Intel NUC running Ubuntu 16.04 and a low latency kernel
which
 > I use for OAI LTE software on top of UHD.
 >
 > After updating my system repositories, UHD broke somehow with the
 > following result:
 >
 > nuc8-3@nuc83-NUC8i7BEH:~$ uhd_find_devices
 > uhd_find_devices: error while loading shared libraries:
 > libuhd.so.3.14.1: cannot open shared object file: No such file or
directory
 >
 > Attempting to manually install the version cited in the error
gives me this:
 >
 > Unpacking libuhd3.14.1:amd64 (3.14.1.1-0ubuntu1~trusty1) ...
 > dpkg: error processing archive
 >
/var/cache/apt/archives/libuhd3.14.1_3.14.1.1-0ubuntu1~trusty1_amd64.deb

 > (--unpack):
 >   trying to overwrite
'/usr/share/uhd/rfnoc/blocks/keep_one_in_n.xml',
 > which is also in package libuhd3.14.0:amd64 3.14.0.0-0ubuntu1~trusty1
 > dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
 > Errors were encountered while processing:
 > 
  /var/cache/apt/archives/libuhd3.14.1_3.14.1.1-0ubuntu1~trusty1_amd64.deb

 > E: Sub-process /usr/bin/dpkg returned an error code (1)
 >
 >
 > Would anyone have any recommendations on what to do to make sure
I have
 > the right version of everything present?
 >
 >
 > ___
 > USRP-users mailing list
 > USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
 > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
 >

-- 
--

M.-Sc. Fabian Schwartau
Technische Universität Braunschweig
Institut für Hochfrequenztechnik
Schleinitzstr. 22
38106 Braunschweig
Germany

Tel.:   +49-(0)531-391-2017
Fax:    +49-(0)531-391-2045
Email: fabian.schwar...@ihf.tu-bs.de
<mailto:fabian.schwar...@ihf.tu-bs.de>
WWW: http://www.tu-braunschweig.de/ihf
--

___
USRP-users mailing list
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



--
--
M.-Sc. Fabian Schwartau
Technische Universität Braunschweig
Institut für Hochfrequenztechnik
Schleinitzstr. 22
38106 Braunschweig
Germany

Tel.:   +49-(0)531-391-2017
Fax:+49-(0)531-391-2045
Email:  fabian.schwar...@ihf.tu-bs.de
WWW:http://www.tu-braunschweig.de/ihf
--

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Libuhd issues - "uhd_find_devices: error while loading shared libraries"

[Fabian Schwartau via USRP-users]

Hi,
sorry for the delay.
This might be a permission issue. If it works as root, it is.
You have to add some rules to udev to allow access for a normal user. I 
don't know the exact configuration required, just search for udev and 
uhd and you will find what you need.


Best regards,
Fabian

Am 10.12.2019 um 00:06 schrieb Saeid Hashemi:

Thank you for your advice Fabian!

It seems there is no package called libuhd, just the following versions:
libuhd003     libuhd3.14.0  libuhd-dev

So I did:

$ sudo dpkg -P libuhd3.14.0
(Reading database ... 291299 files and directories currently installed.)
Removing libuhd3.14.0:amd64 (3.14.0.0-0ubuntu1~trusty1) ...
Purging configuration files for libuhd3.14.0:amd64 
(3.14.0.0-0ubuntu1~trusty1) ...

Processing triggers for libc-bin (2.19-0ubuntu6.15) ...
$ sudo apt-get install libuhd3.14.1

And now UHD tools work, also within the LTE software, but they won't 
find my B210 saying:


[INFO] [UHD] linux; GNU C++ version 4.8.4; Boost_105400; 
UHD_3.14.1.1-release

Error: LookupError: KeyError: No devices found for ->
Empty Device Address

Regards,
Saeid




On Fri, Dec 6, 2019 at 2:58 AM Fabian Schwartau via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


You have an old version of libuhd already installed. Uninstall it using:
$ sudo dpkg -P libuhd
Then retry installing it. Sometimes libraries are not found and you
have
to run
$ sudo ldconfig
but that is usually done by dpkg.

Am 06.12.2019 um 00:31 schrieb Saeid Hashemi via USRP-users:
 > Hello everyone,
 >
 > I have an Intel NUC running Ubuntu 16.04 and a low latency kernel
which
 > I use for OAI LTE software on top of UHD.
 >
 > After updating my system repositories, UHD broke somehow with the
 > following result:
 >
 > nuc8-3@nuc83-NUC8i7BEH:~$ uhd_find_devices
 > uhd_find_devices: error while loading shared libraries:
 > libuhd.so.3.14.1: cannot open shared object file: No such file or
directory
 >
 > Attempting to manually install the version cited in the error
gives me this:
 >
 > Unpacking libuhd3.14.1:amd64 (3.14.1.1-0ubuntu1~trusty1) ...
 > dpkg: error processing archive
 >
/var/cache/apt/archives/libuhd3.14.1_3.14.1.1-0ubuntu1~trusty1_amd64.deb

 > (--unpack):
 >   trying to overwrite
'/usr/share/uhd/rfnoc/blocks/keep_one_in_n.xml',
 > which is also in package libuhd3.14.0:amd64 3.14.0.0-0ubuntu1~trusty1
 > dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
 > Errors were encountered while processing:
 > 
  /var/cache/apt/archives/libuhd3.14.1_3.14.1.1-0ubuntu1~trusty1_amd64.deb

 > E: Sub-process /usr/bin/dpkg returned an error code (1)
 >
 >
 > Would anyone have any recommendations on what to do to make sure
I have
 > the right version of everything present?
 >
 >
 > ___
 > USRP-users mailing list
 > USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
 > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
 >

-- 
--

M.-Sc. Fabian Schwartau
Technische Universität Braunschweig
Institut für Hochfrequenztechnik
Schleinitzstr. 22
38106 Braunschweig
Germany

Tel.:   +49-(0)531-391-2017
Fax:    +49-(0)531-391-2045
Email: fabian.schwar...@ihf.tu-bs.de
<mailto:fabian.schwar...@ihf.tu-bs.de>
WWW: http://www.tu-braunschweig.de/ihf
--

___
USRP-users mailing list
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



--
--
M.-Sc. Fabian Schwartau
Technische Universität Braunschweig
Institut für Hochfrequenztechnik
Schleinitzstr. 22
38106 Braunschweig
Germany

Tel.:   +49-(0)531-391-2017
Fax:+49-(0)531-391-2045
Email:  fabian.schwar...@ihf.tu-bs.de
WWW:http://www.tu-braunschweig.de/ihf
--

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Libuhd issues - "uhd_find_devices: error while loading shared libraries"

[Fabian Schwartau via USRP-users]

You have an old version of libuhd already installed. Uninstall it using:
$ sudo dpkg -P libuhd
Then retry installing it. Sometimes libraries are not found and you have 
to run

$ sudo ldconfig
but that is usually done by dpkg.

Am 06.12.2019 um 00:31 schrieb Saeid Hashemi via USRP-users:

Hello everyone,

I have an Intel NUC running Ubuntu 16.04 and a low latency kernel which 
I use for OAI LTE software on top of UHD.


After updating my system repositories, UHD broke somehow with the 
following result:


nuc8-3@nuc83-NUC8i7BEH:~$ uhd_find_devices
uhd_find_devices: error while loading shared libraries: 
libuhd.so.3.14.1: cannot open shared object file: No such file or directory


Attempting to manually install the version cited in the error gives me this:

Unpacking libuhd3.14.1:amd64 (3.14.1.1-0ubuntu1~trusty1) ...
dpkg: error processing archive 
/var/cache/apt/archives/libuhd3.14.1_3.14.1.1-0ubuntu1~trusty1_amd64.deb 
(--unpack):
  trying to overwrite '/usr/share/uhd/rfnoc/blocks/keep_one_in_n.xml', 
which is also in package libuhd3.14.0:amd64 3.14.0.0-0ubuntu1~trusty1

dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
  /var/cache/apt/archives/libuhd3.14.1_3.14.1.1-0ubuntu1~trusty1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


Would anyone have any recommendations on what to do to make sure I have 
the right version of everything present?



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



--
--
M.-Sc. Fabian Schwartau
Technische Universität Braunschweig
Institut für Hochfrequenztechnik
Schleinitzstr. 22
38106 Braunschweig
Germany

Tel.:   +49-(0)531-391-2017
Fax:+49-(0)531-391-2045
Email:  fabian.schwar...@ihf.tu-bs.de
WWW:http://www.tu-braunschweig.de/ihf
--

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] One sample - 5 ns delay between the two RF signals/ X310

[Fabian Schwartau via USRP-users]

No, it was a 3.3V CMOS variant of that IC. I cannot figure it out as I 
would have to take the hardware apart.


Am 27.09.2019 um 09:30 schrieb Daniel Jepson via USRP-users:

Fabian,

I noticed on the SN74LS125A datasheet the minimum input voltage is 
4.75V. Is this the correct part that you're using?


-Daniel

On Fri, Sep 27, 2019 at 9:27 AM Daniel Jepson <mailto:daniel.jep...@ettus.com>> wrote:


Thanks Fabian. As long as the input PPS is driven by the same RefClk
that is provided to the X310, this system should be ok. You might
also consider driving the PPS on the falling edge of the RefClk to
ensure timing is met at the X310. There are some timing constraints
here that might affect performance, but I wouldn't expect to see a
10 ns shift.

-Daniel

On Thu, Sep 26, 2019 at 3:18 PM Fabian Schwartau via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:

It is a self build device using a 74LS125D as buffer. The level
is 3.3V
digital.
As there were no specifications around for the required input
levels at
the time we needed the device, we just measured the levels
coming from
the 1PPS output and replicated them.

Am 26.09.2019 um 13:51 schrieb Daniel Jepson via USRP-users:
 > Hi Fabian, Cherif,
 >
 > What is the external PPS device you are using?
 >
 > -Daniel
 >
 > On Thu, Sep 26, 2019 at 9:18 AM Fabian Schwartau via USRP-users
 > mailto:usrp-users@lists.ettus.com>
<mailto:usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>>> wrote:
 >
 >     Hi,
 >     I have very similar problem with X310. I am running a C++
application,
 >     so I have a bit more flexibility I guess. After I do the
 >     set_time_unknown_pps to sync to the 1PPS signal, I run
the function
 >     get_time_last_pps and it sometimes has an offset of 10ns
(it was 5ns
 >     for
 >     an old firmware due to a bug, which was fixed a few weeks
ago). If that
 >     is the case I just do the sync again until the offset is
zero.
 >     I don't know if it is an firmawre problem or if it is
because the
 >     signal
 >     integrety of the 1PPS signal is not good enough.
 >     Maybe that is also a solution for you.
 >     Best regards,
 >     Fabian
 >
 >     Am 25.09.2019 um 11:16 schrieb Cherif Diouf via USRP-users:
 >      > Hello,
 >      > I am working with the X310 USRP. I have two identical
custom blocks
 >      > feeding the RF frontends.
 >      >
 >      > flowchart
 >      > -
 >      > HW Block1 -> RF0-TX1 |---<
 >      > HW Block2 -> RF1-TX1 |---<
 >      >
 >      > The system is synchronized to an external PPS
reference. The
 >     sampling
 >      > rate is 200 MSps and the signal bandwidth is 160 MHz
for both
 >     channels.
 >      > The two HW blocks start  transmitting at the exactly
same time. Time
 >      > resolution is 5ns.
 >      > In most cases the two outgoing RF signals present a
1ns time offset.
 >      > Which can be understood as a phase offset.
 >      >
 >      > But From time to time there is a 6ns delay between the
channels. I
 >      > assume this 6ns comprises the 1ns delay due to phase
offset + 5
 >     ns delay
 >      > due to misalignment of outgoing samples.
 >      >
 >      > What could be the origin of this one sample
misalignement? Is it
 >     a way
 >      > to fix it? Or working close to the limits of the
device should such
 >      > behavior be expected?
 >      >
 >      > Thanks in advance
 >      >
 >      > Best Regards
 >      > Cherif
 >      >
 >      >
 >      > ___
 >      > USRP-users mailing list
 >      > USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>
<mailto:USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>>
 >      >
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
 >      >
 >
 >     --
 >     --

Re: [USRP-users] One sample - 5 ns delay between the two RF signals/ X310

[Fabian Schwartau via USRP-users]

It is a self build device using a 74LS125D as buffer. The level is 3.3V 
digital.
As there were no specifications around for the required input levels at 
the time we needed the device, we just measured the levels coming from 
the 1PPS output and replicated them.


Am 26.09.2019 um 13:51 schrieb Daniel Jepson via USRP-users:

Hi Fabian, Cherif,

What is the external PPS device you are using?

-Daniel

On Thu, Sep 26, 2019 at 9:18 AM Fabian Schwartau via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Hi,
I have very similar problem with X310. I am running a C++ application,
so I have a bit more flexibility I guess. After I do the
set_time_unknown_pps to sync to the 1PPS signal, I run the function
get_time_last_pps and it sometimes has an offset of 10ns (it was 5ns
for
an old firmware due to a bug, which was fixed a few weeks ago). If that
is the case I just do the sync again until the offset is zero.
I don't know if it is an firmawre problem or if it is because the
signal
integrety of the 1PPS signal is not good enough.
Maybe that is also a solution for you.
Best regards,
Fabian

Am 25.09.2019 um 11:16 schrieb Cherif Diouf via USRP-users:
 > Hello,
 > I am working with the X310 USRP. I have two identical custom blocks
 > feeding the RF frontends.
 >
 > flowchart
 > -
 > HW Block1 -> RF0-TX1 |---<
 > HW Block2 -> RF1-TX1 |---<
 >
 > The system is synchronized to an external PPS reference. The
sampling
 > rate is 200 MSps and the signal bandwidth is 160 MHz for both
channels.
 > The two HW blocks start  transmitting at the exactly same time. Time
 > resolution is 5ns.
 > In most cases the two outgoing RF signals present a 1ns time offset.
 > Which can be understood as a phase offset.
 >
 > But From time to time there is a 6ns delay between the channels. I
 > assume this 6ns comprises the 1ns delay due to phase offset + 5
ns delay
 > due to misalignment of outgoing samples.
 >
 > What could be the origin of this one sample misalignement? Is it
a way
 > to fix it? Or working close to the limits of the device should such
 > behavior be expected?
 >
 > Thanks in advance
 >
 > Best Regards
 > Cherif
 >
 >
 > ___
 > USRP-users mailing list
 > USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
 > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
 >

-- 
--

M.-Sc. Fabian Schwartau
Technische Universität Braunschweig
Institut für Hochfrequenztechnik
Schleinitzstr. 22
38106 Braunschweig
Germany

Tel.:   +49-(0)531-391-2017
Fax:    +49-(0)531-391-2045
Email: fabian.schwar...@ihf.tu-bs.de
<mailto:fabian.schwar...@ihf.tu-bs.de>
WWW: http://www.tu-braunschweig.de/ihf
--

___
USRP-users mailing list
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



--

Daniel Jepson

Digital Hardware Engineer

National Instruments

O: +1.512.683.6163

daniel.jep...@ni.com <mailto:daniel.jep...@ni.com>


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



--
--
M.-Sc. Fabian Schwartau
Technische Universität Braunschweig
Institut für Hochfrequenztechnik
Schleinitzstr. 22
38106 Braunschweig
Germany

Tel.:   +49-(0)531-391-2017
Fax:+49-(0)531-391-2045
Email:  fabian.schwar...@ihf.tu-bs.de
WWW:http://www.tu-braunschweig.de/ihf
--

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] One sample - 5 ns delay between the two RF signals/ X310

[Fabian Schwartau via USRP-users]

Hi,
I have very similar problem with X310. I am running a C++ application, 
so I have a bit more flexibility I guess. After I do the 
set_time_unknown_pps to sync to the 1PPS signal, I run the function 
get_time_last_pps and it sometimes has an offset of 10ns (it was 5ns for 
an old firmware due to a bug, which was fixed a few weeks ago). If that 
is the case I just do the sync again until the offset is zero.
I don't know if it is an firmawre problem or if it is because the signal 
integrety of the 1PPS signal is not good enough.

Maybe that is also a solution for you.
Best regards,
Fabian

Am 25.09.2019 um 11:16 schrieb Cherif Diouf via USRP-users:

Hello,
I am working with the X310 USRP. I have two identical custom blocks 
feeding the RF frontends.


flowchart
-
HW Block1 -> RF0-TX1 |---<
HW Block2 -> RF1-TX1 |---<

The system is synchronized to an external PPS reference. The sampling 
rate is 200 MSps and the signal bandwidth is 160 MHz for both channels.
The two HW blocks start  transmitting at the exactly same time. Time 
resolution is 5ns.
In most cases the two outgoing RF signals present a 1ns time offset. 
Which can be understood as a phase offset.


But From time to time there is a 6ns delay between the channels. I 
assume this 6ns comprises the 1ns delay due to phase offset + 5 ns delay 
due to misalignment of outgoing samples.


What could be the origin of this one sample misalignement? Is it a way 
to fix it? Or working close to the limits of the device should such 
behavior be expected?


Thanks in advance

Best Regards
Cherif


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



--
--
M.-Sc. Fabian Schwartau
Technische Universität Braunschweig
Institut für Hochfrequenztechnik
Schleinitzstr. 22
38106 Braunschweig
Germany

Tel.:   +49-(0)531-391-2017
Fax:+49-(0)531-391-2045
Email:  fabian.schwar...@ihf.tu-bs.de
WWW:http://www.tu-braunschweig.de/ihf
--

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] No respone packet error caused by timed frequency switching

[Fabian Schwartau via USRP-users]

Hi everyone,

I already asked this the ettus support, but they did not got back to me 
yet, maybe someone here can help me.
I am working on X310 with TwinRX boards. I use a lot of timed commands 
and since upgrading the firmware from 003.010.002.000 to 003.014.001.001 
I get this error message after a few minutes/seconds, depending on what 
I am doing:

terminate called after throwing an instance of 'uhd::io_error'
  what():  EnvironmentError: IOError: Block ctrl (CE_01_Port_40) no 
response packet - AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) 
[with uhd::endianness_t _endianness = (uhd::endianness_t)0u; uint64_t = 
long unsigned int]
  at 
/home/fschwa/src/uhd_20191010_3.14.1.1-RC1/host/lib/rfnoc/ctrl_iface.cpp:142 



I know there is a very similar (same?) problem when requesting rx_stream 
in a loop, but I am not doing that. In my actual program I have only on 
rx_stream. I was able to boil that problem down to a few lines of code, 
which set the rx frequency in a loop (what I am doing in my actual 
program). When doing this with timed commands, the error occures after a 
few dozens of iterations. Leaving out the timed command, everything 
works fine. Find the small program attached.
After I ran into the problem the USRP is completely unresponsive. I have 
to power cycle it, to get it working again.

Does anyone know a solution/workaround or has seen that before?

Best regards,
Fabian
--
--
M.-Sc. Fabian Schwartau
Technische Universität Braunschweig
Institut für Hochfrequenztechnik
Schleinitzstr. 22
38106 Braunschweig
Germany

Tel.:   +49-(0)531-391-2017
Fax:+49-(0)531-391-2045
Email:  fabian.schwar...@ihf.tu-bs.de
WWW:http://www.tu-braunschweig.de/ihf
--
// Compile with:
// g++ -std=c++14 -O2 UHDIOError2.cpp -luhd -lboost_system -o UHDIOError2

#include 
#include 
#include 
#include 

using namespace std;

int UHD_SAFE_MAIN(int argc, char** argv)
{
uhd::set_thread_priority_safe();

std::string args="addr=192.168.42.2";
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
std::string subdev_spec="A:0";
usrp->set_rx_subdev_spec(subdev_spec);
usrp->set_rx_rate(25e6, 0);
usrp->set_rx_freq(1240e6, 0);
usrp->set_rx_gain(50.0, 0);
usrp->set_rx_antenna("RX1", 0);

uhd::time_spec_t nextCommandTime = usrp->get_time_now();
nextCommandTime += uhd::time_spec_t(0.5);

for (int iteration=0; iteration<1000; iteration++) {
usrp->set_command_time(nextCommandTime);
usrp->set_rx_freq(1000e6, 0);
nextCommandTime += uhd::time_spec_t(0.02);
cout << "iteration: "<< iteration << endl;
}
return 0;
}

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRPs time wrong by factor of two

[Fabian Schwartau via USRP-users]

I jost got a response from Ettus. The problem is fixed commit 5f75f73 
(release 3.14.1.0). I tested it with my earlier supplied script and it 
works.

Maybe this info will be helpful for someone else.

Am 04.06.2019 um 09:54 schrieb Fabian Schwartau via USRP-users:

Does anyone know if this problem is fixed in the current master?

Am 13.05.2019 um 12:41 schrieb Fabian Schwartau via USRP-users:

Thanks for that. IT is quite interesting, that it also does not work
with their own example. I would expect that all examples would be run on
different test beds before releasing "stable" software versions...
However, please keep us up to date, if you get any new information.

Best regards,
Fabian

Am 09.05.19 um 19:33 schrieb Rob Kossler:

Fabian,
My colleague also encountered this "factor of 2" bug and determined that
it is present starting in 3.14. It's related to the tick/sample rates in
the TwinRx Radio, and does affect timed commands as you suggest. In
fact, the issue can actually be demonstrated using Ettus's example
program "test_timed_commands", which does not run successfully for a
TwinRx in 3.14 and later. He actually just submitted this issue to
supp...@ettus.com <mailto:supp...@ettus.com> a few days ago and is
currently waiting on a response from them.
Rob


On Thu, May 9, 2019 at 9:06 AM Fabian Schwartau via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:

 Hi,
 is there any update regarding this issue?

     Am 26.04.2019 um 11:27 schrieb Fabian Schwartau via USRP-users:
 > Hi,
 >
 > is it to be expected that this will be fixed soon? Is someone at
 Ettus
 > working on this?
 >
 > Best regards,
 > Fabian
     >
     > Am 23.04.2019 um 19:34 schrieb Fabian Schwartau via USRP-users:
 >> OK, I just reverted the system to the old version and that works
 >> perfectly. The USRP time is incremented in full seconds like
 expected.
 >> So something changed somewhere in the lib/fpga image.
 >> The version I am using now is:
 >> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
 >> UHD_003.010.002.HEAD-0-gbd6e21dc
 >> Hope that helps.
     >>
     >> Am 23.04.2019 um 19:12 schrieb Marcus D. Leech via USRP-users:
 >>> On 04/23/2019 01:10 PM, Fabian Schwartau via USRP-users wrote:
 >>>> Will the fpga image downloader from the old version also 
download

 >>>> the old fpga images? Or where can I get them?
 >>>> I don't know if I will do it. I am afraid of breaking my 
system
 >>>> and/or investing a lot of time with this as I am under 
quite a lot

 >>>> of time preasure and I am basically working on the production
 system
 >>>> which has to bo rolled out in a few days. If I brick it, I 
will

 get
 >>>> in trouble ;)
 >>> The uhd_images_downloader tool will always download the 
images that

 >>> match the library version.
 >>>
 >>>
 >>>>
 >>>> Am 23.04.2019 um 18:51 schrieb Marcus D. Leech via USRP-users:
 >>>>> On 04/23/2019 11:48 AM, Fabian Schwartau via USRP-users 
wrote:

 >>>>>> Hi,
 >>>>>> its the same. I found the bug because the timed commands 
took

 much
 >>>>>> longer than expected, so the USRP clock is actually 
running at a
 >>>>>> lower rate. However, the spectra looked ok and everything 
else

 >>>>>> seems to be working as usual, except there is a larger delay
 >>>>>> between the commands. So the USRP is not running at a wrong
 clock
     >>>>>> or something like that. That would probably cause much 
larger

 issues.
 >>>>>>
 >>>>>> Best regards,
 >>>>>> Fabian
 >>>>> If you revert to a previous release, does the problem go 
away?

 >>>>>
 >>>>>
 >>>>>>
 >>>>>>
 >>>>>> Am 23.04.2019 um 17:27 schrieb Marcus D. Leech via 
USRP-users:
 >>>>>>> On 04/23/2019 09:47 AM, Fabian Schwartau via USRP-users 
wrote:

 >>>>>>>> Hi everyone,
 >>>>>>>>
 >>>>>>>> I just found a very strage bug and would like to 
confirm that

 >>>>>>>> this is a bug and if someone can explain/fix this.
 >>>>>>>> I read the time from the USRP using get_time_now() and 
do a

 lot
 >>>>>>>> of stuff with it. Mainly to time commands like frequency
 hopping
 

[USRP-users] unsubscribe

[Fabian Schwartau via USRP-users]

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRPs time wrong by factor of two

[Fabian Schwartau via USRP-users]

Does anyone know if this problem is fixed in the current master?

Am 13.05.2019 um 12:41 schrieb Fabian Schwartau via USRP-users:

Thanks for that. IT is quite interesting, that it also does not work
with their own example. I would expect that all examples would be run on
different test beds before releasing "stable" software versions...
However, please keep us up to date, if you get any new information.

Best regards,
Fabian

Am 09.05.19 um 19:33 schrieb Rob Kossler:

Fabian,
My colleague also encountered this "factor of 2" bug and determined that
it is present starting in 3.14. It's related to the tick/sample rates in
the TwinRx Radio, and does affect timed commands as you suggest. In
fact, the issue can actually be demonstrated using Ettus's example
program "test_timed_commands", which does not run successfully for a
TwinRx in 3.14 and later. He actually just submitted this issue to
supp...@ettus.com <mailto:supp...@ettus.com> a few days ago and is
currently waiting on a response from them.
Rob


On Thu, May 9, 2019 at 9:06 AM Fabian Schwartau via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:

 Hi,
 is there any update regarding this issue?

 Am 26.04.2019 um 11:27 schrieb Fabian Schwartau via USRP-users:
 > Hi,
 >
 > is it to be expected that this will be fixed soon? Is someone at
 Ettus
 > working on this?
 >
 > Best regards,
 > Fabian
     >
     > Am 23.04.2019 um 19:34 schrieb Fabian Schwartau via USRP-users:
 >> OK, I just reverted the system to the old version and that works
 >> perfectly. The USRP time is incremented in full seconds like
 expected.
 >> So something changed somewhere in the lib/fpga image.
 >> The version I am using now is:
 >> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
 >> UHD_003.010.002.HEAD-0-gbd6e21dc
 >> Hope that helps.
 >>
     >> Am 23.04.2019 um 19:12 schrieb Marcus D. Leech via USRP-users:
 >>> On 04/23/2019 01:10 PM, Fabian Schwartau via USRP-users wrote:
 >>>> Will the fpga image downloader from the old version also download
 >>>> the old fpga images? Or where can I get them?
 >>>> I don't know if I will do it. I am afraid of breaking my system
 >>>> and/or investing a lot of time with this as I am under quite a lot
 >>>> of time preasure and I am basically working on the production
 system
 >>>> which has to bo rolled out in a few days. If I brick it, I will
 get
 >>>> in trouble ;)
 >>> The uhd_images_downloader tool will always download the images that
 >>> match the library version.
 >>>
 >>>
 >>>>
 >>>> Am 23.04.2019 um 18:51 schrieb Marcus D. Leech via USRP-users:
 >>>>> On 04/23/2019 11:48 AM, Fabian Schwartau via USRP-users wrote:
 >>>>>> Hi,
 >>>>>> its the same. I found the bug because the timed commands took
 much
 >>>>>> longer than expected, so the USRP clock is actually running at a
 >>>>>> lower rate. However, the spectra looked ok and everything else
 >>>>>> seems to be working as usual, except there is a larger delay
 >>>>>> between the commands. So the USRP is not running at a wrong
 clock
     >>>>>> or something like that. That would probably cause much larger
 issues.
 >>>>>>
 >>>>>> Best regards,
 >>>>>> Fabian
 >>>>> If you revert to a previous release, does the problem go away?
 >>>>>
 >>>>>
 >>>>>>
 >>>>>>
 >>>>>> Am 23.04.2019 um 17:27 schrieb Marcus D. Leech via USRP-users:
 >>>>>>> On 04/23/2019 09:47 AM, Fabian Schwartau via USRP-users wrote:
 >>>>>>>> Hi everyone,
 >>>>>>>>
 >>>>>>>> I just found a very strage bug and would like to confirm that
 >>>>>>>> this is a bug and if someone can explain/fix this.
 >>>>>>>> I read the time from the USRP using get_time_now() and do a
 lot
 >>>>>>>> of stuff with it. Mainly to time commands like frequency
 hopping
 >>>>>>>> and starting of streams. I noticed that the time in the USRP
 >>>>>>>> seemed to run slower than expected, actually by a factor of
 two.
 >>>>>>>> Please find a program attached that demonstrates this

Re: [USRP-users] Timed frequency switching on multiple channels not possible

[Fabian Schwartau via USRP-users]

Is there any update from Ettus on this issue? It is bothering me quite a 
lot...


Am 09.05.2019 um 20:01 schrieb Marcus D. Leech via USRP-users:

On 05/09/2019 09:05 AM, Fabian Schwartau via USRP-users wrote:

Hi,
is there any update regarding this issue?

Ettus R is aware, and they're being looked at.




Am 06.05.2019 um 10:36 schrieb Fabian Schwartau via USRP-users:

Sorry for the late answer, I was busy.
I tried that including a one second sleep after it but it does not help.

Am 26.04.2019 um 18:30 schrieb Marcus D. Leech via USRP-users:

On 04/26/2019 12:07 PM, Fabian Schwartau via USRP-users wrote:
Ohh.. you are right, I did not do that in the example code. But the 
problem is the same in my main application, where I do. As I said, 
the 180° phase shift is probably somehow related and not that easy 
to reporduce. So the spectrum or I/Q swap should be the main issue 
here and I hope that this will also solve the 180° phase swap.
Interestingly the phase is correct, if I set the frequency twice 
for each channel with a little delay in between.
Could you try something?   Insert a set_time_next_pps() into the 
code in initalization--this should align the TOD clocks in both 
internal DSP radio

   modules.




Am 26.04.2019 um 18:02 schrieb Marcus D. Leech via USRP-users:

On 04/26/2019 11:36 AM, Fabian Schwartau via USRP-users wrote:

Hi,

I am am using LO sharing. So there should not be any phase offset 
and no mirrored spectrum, no matter when the USRP comes around to 
change the frequency. Even not using LO-sharing, the spectrum 
should NOT be mirrored.
The apparent I/Q swap issue I agree should not happen, and I have 
a query in to R about it.





Am 26.04.2019 um 17:12 schrieb Marcus D. Leech via USRP-users:

On 04/26/2019 05:13 AM, Fabian Schwartau via USRP-users wrote:

Hi,

a couple of days ago I filed a bug report which caused the 
USRPs to switch but noone has responded yet. I did now 
encountered other problems wich might be related to that issue. 
Can somone from Ettus (or someone else) take a look at that?
Bug report is here: 
https://github.com/EttusResearch/uhd/issues/271


Best regards,

Fabian


So, the original design reason for timed-commands was to support 
simultaneous tuning (and assertion of a resynch pulse) across 
*multiple USRPs*,
   in support of reducing/eliminating mutual phase offset among 
identically-hardwared USRPs, for daughtercards that supported 
phase-resynch.


When you use timed commands within a single USRP, hoping for 
similar effects, you won't get them, because the commands in the 
queue
   are *necessarily* executed sequentially.  Even if there was a 
"parallel execution" structure within the FPGA to handle the 
commands, most of
   the commands you care about ultimately end up on an SPI or 
I2C bus, and those are inherently serial, and multiple devices 
(synthesizers,
   variable-gain amplifiers, clock-plls) typically share a 
single such bus on a per-slot basis.  In order to have "true 
parallelism" *within* a single
   USRP, you'd need dedicated control buses to each device that 
is controlled by I2C/SPI/whatever, *in addition* to parallel 
execution within the

   FPGA.

When you're setting a bunch of PLL synthesizers sequentially, 
you can expect that they won't agree on phase, even when being 
driven
   by a common clock.   The mechanism for achieving phase 
coherence with TwinRx is to use LO sharing.


https://kb.ettus.com/TwinRX

This app-note talks about LO sharing with TwinRX

https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2 






___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRPs time wrong by factor of two

[Fabian Schwartau via USRP-users]

Thanks for that. IT is quite interesting, that it also does not work
with their own example. I would expect that all examples would be run on
different test beds before releasing "stable" software versions...
However, please keep us up to date, if you get any new information.

Best regards,
Fabian

Am 09.05.19 um 19:33 schrieb Rob Kossler:
> Fabian,
> My colleague also encountered this "factor of 2" bug and determined that
> it is present starting in 3.14. It's related to the tick/sample rates in
> the TwinRx Radio, and does affect timed commands as you suggest. In
> fact, the issue can actually be demonstrated using Ettus's example
> program "test_timed_commands", which does not run successfully for a
> TwinRx in 3.14 and later. He actually just submitted this issue to
> supp...@ettus.com <mailto:supp...@ettus.com> a few days ago and is
> currently waiting on a response from them.
> Rob
> 
> 
> On Thu, May 9, 2019 at 9:06 AM Fabian Schwartau via USRP-users
> mailto:usrp-users@lists.ettus.com>> wrote:
> 
> Hi,
> is there any update regarding this issue?
> 
> Am 26.04.2019 um 11:27 schrieb Fabian Schwartau via USRP-users:
> > Hi,
> >
> > is it to be expected that this will be fixed soon? Is someone at
> Ettus
> > working on this?
> >
> > Best regards,
> > Fabian
> >
> > Am 23.04.2019 um 19:34 schrieb Fabian Schwartau via USRP-users:
> >> OK, I just reverted the system to the old version and that works
> >> perfectly. The USRP time is incremented in full seconds like
> expected.
> >> So something changed somewhere in the lib/fpga image.
> >> The version I am using now is:
> >> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> >> UHD_003.010.002.HEAD-0-gbd6e21dc
> >> Hope that helps.
> >>
> >> Am 23.04.2019 um 19:12 schrieb Marcus D. Leech via USRP-users:
> >>> On 04/23/2019 01:10 PM, Fabian Schwartau via USRP-users wrote:
> >>>> Will the fpga image downloader from the old version also download
> >>>> the old fpga images? Or where can I get them?
> >>>> I don't know if I will do it. I am afraid of breaking my system
> >>>> and/or investing a lot of time with this as I am under quite a lot
> >>>> of time preasure and I am basically working on the production
> system
> >>>> which has to bo rolled out in a few days. If I brick it, I will
> get
> >>>> in trouble ;)
> >>> The uhd_images_downloader tool will always download the images that
> >>> match the library version.
> >>>
> >>>
> >>>>
> >>>> Am 23.04.2019 um 18:51 schrieb Marcus D. Leech via USRP-users:
> >>>>> On 04/23/2019 11:48 AM, Fabian Schwartau via USRP-users wrote:
> >>>>>> Hi,
> >>>>>> its the same. I found the bug because the timed commands took
> much
> >>>>>> longer than expected, so the USRP clock is actually running at a
> >>>>>> lower rate. However, the spectra looked ok and everything else
>     >>>>>> seems to be working as usual, except there is a larger delay
> >>>>>> between the commands. So the USRP is not running at a wrong
> clock
> >>>>>> or something like that. That would probably cause much larger
> issues.
> >>>>>>
> >>>>>> Best regards,
> >>>>>> Fabian
> >>>>> If you revert to a previous release, does the problem go away?
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> Am 23.04.2019 um 17:27 schrieb Marcus D. Leech via USRP-users:
> >>>>>>> On 04/23/2019 09:47 AM, Fabian Schwartau via USRP-users wrote:
> >>>>>>>> Hi everyone,
> >>>>>>>>
> >>>>>>>> I just found a very strage bug and would like to confirm that
> >>>>>>>> this is a bug and if someone can explain/fix this.
> >>>>>>>> I read the time from the USRP using get_time_now() and do a
> lot
> >>>>>>>> of stuff with it. Mainly to time commands like frequency
> hopping
> >>>>>>>> and starting of streams. I noticed th

Re: [USRP-users] Timed frequency switching on multiple channels not possible

[Fabian Schwartau via USRP-users]

Hi,
is there any update regarding this issue?

Am 06.05.2019 um 10:36 schrieb Fabian Schwartau via USRP-users:

Sorry for the late answer, I was busy.
I tried that including a one second sleep after it but it does not help.

Am 26.04.2019 um 18:30 schrieb Marcus D. Leech via USRP-users:

On 04/26/2019 12:07 PM, Fabian Schwartau via USRP-users wrote:
Ohh.. you are right, I did not do that in the example code. But the 
problem is the same in my main application, where I do. As I said, 
the 180° phase shift is probably somehow related and not that easy to 
reporduce. So the spectrum or I/Q swap should be the main issue here 
and I hope that this will also solve the 180° phase swap.
Interestingly the phase is correct, if I set the frequency twice for 
each channel with a little delay in between.
Could you try something?   Insert a set_time_next_pps() into the code 
in initalization--this should align the TOD clocks in both internal 
DSP radio

   modules.




Am 26.04.2019 um 18:02 schrieb Marcus D. Leech via USRP-users:

On 04/26/2019 11:36 AM, Fabian Schwartau via USRP-users wrote:

Hi,

I am am using LO sharing. So there should not be any phase offset 
and no mirrored spectrum, no matter when the USRP comes around to 
change the frequency. Even not using LO-sharing, the spectrum 
should NOT be mirrored.
The apparent I/Q swap issue I agree should not happen, and I have a 
query in to R about it.





Am 26.04.2019 um 17:12 schrieb Marcus D. Leech via USRP-users:

On 04/26/2019 05:13 AM, Fabian Schwartau via USRP-users wrote:

Hi,

a couple of days ago I filed a bug report which caused the USRPs 
to switch but noone has responded yet. I did now encountered 
other problems wich might be related to that issue. Can somone 
from Ettus (or someone else) take a look at that?

Bug report is here: https://github.com/EttusResearch/uhd/issues/271

Best regards,

Fabian


So, the original design reason for timed-commands was to support 
simultaneous tuning (and assertion of a resynch pulse) across 
*multiple USRPs*,
   in support of reducing/eliminating mutual phase offset among 
identically-hardwared USRPs, for daughtercards that supported 
phase-resynch.


When you use timed commands within a single USRP, hoping for 
similar effects, you won't get them, because the commands in the 
queue
   are *necessarily* executed sequentially.  Even if there was a 
"parallel execution" structure within the FPGA to handle the 
commands, most of
   the commands you care about ultimately end up on an SPI or I2C 
bus, and those are inherently serial, and multiple devices 
(synthesizers,
   variable-gain amplifiers, clock-plls) typically share a single 
such bus on a per-slot basis.  In order to have "true parallelism" 
*within* a single
   USRP, you'd need dedicated control buses to each device that is 
controlled by I2C/SPI/whatever, *in addition* to parallel 
execution within the

   FPGA.

When you're setting a bunch of PLL synthesizers sequentially, you 
can expect that they won't agree on phase, even when being driven
   by a common clock.   The mechanism for achieving phase 
coherence with TwinRx is to use LO sharing.


https://kb.ettus.com/TwinRX

This app-note talks about LO sharing with TwinRX

https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2 






___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRPs time wrong by factor of two

[Fabian Schwartau via USRP-users]

Hi,
is there any update regarding this issue?

Am 26.04.2019 um 11:27 schrieb Fabian Schwartau via USRP-users:

Hi,

is it to be expected that this will be fixed soon? Is someone at Ettus 
working on this?


Best regards,
Fabian

Am 23.04.2019 um 19:34 schrieb Fabian Schwartau via USRP-users:
OK, I just reverted the system to the old version and that works 
perfectly. The USRP time is incremented in full seconds like expected. 
So something changed somewhere in the lib/fpga image.

The version I am using now is:
linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_003.010.002.HEAD-0-gbd6e21dc

Hope that helps.

Am 23.04.2019 um 19:12 schrieb Marcus D. Leech via USRP-users:

On 04/23/2019 01:10 PM, Fabian Schwartau via USRP-users wrote:
Will the fpga image downloader from the old version also download 
the old fpga images? Or where can I get them?
I don't know if I will do it. I am afraid of breaking my system 
and/or investing a lot of time with this as I am under quite a lot 
of time preasure and I am basically working on the production system 
which has to bo rolled out in a few days. If I brick it, I will get 
in trouble ;)
The uhd_images_downloader tool will always download the images that 
match the library version.





Am 23.04.2019 um 18:51 schrieb Marcus D. Leech via USRP-users:

On 04/23/2019 11:48 AM, Fabian Schwartau via USRP-users wrote:

Hi,
its the same. I found the bug because the timed commands took much 
longer than expected, so the USRP clock is actually running at a 
lower rate. However, the spectra looked ok and everything else 
seems to be working as usual, except there is a larger delay 
between the commands. So the USRP is not running at a wrong clock 
or something like that. That would probably cause much larger issues.


Best regards,
Fabian

If you revert to a previous release, does the problem go away?





Am 23.04.2019 um 17:27 schrieb Marcus D. Leech via USRP-users:

On 04/23/2019 09:47 AM, Fabian Schwartau via USRP-users wrote:

Hi everyone,

I just found a very strage bug and would like to confirm that 
this is a bug and if someone can explain/fix this.
I read the time from the USRP using get_time_now() and do a lot 
of stuff with it. Mainly to time commands like frequency hopping 
and starting of streams. I noticed that the time in the USRP 
seemed to run slower than expected, actually by a factor of two.
Please find a program attached that demonstrates this effect. It 
prints the internal USRP time roughly every second (using sleep) 
but the USRP time increments only by 0.5 seconds in each step. 
What is going on?


The program can be compiled using:
g++ -std=c++14 -O2 main.cpp -luhd -lboost_system -o main

I am using a single (or multiple - does not have an effect) X310 
with two TwinRX. UHD is "linux; GNU C++ version 5.5.0 20171010; 
Boost_105800; UHD_3.15.0.git-89-gf93c5227" from yesterday. FPGA 
image is also from yesterday using the download script - where 
can I find the version number? I am running an up-to-date Ubuntu 
16.04.
Could you try the print as a get_frac_secs() and get_full_secs() 
instead?   To disambiguate whether this is an actual hardware 
clock management

   issue or just a formatting issue.



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Timed frequency switching on multiple channels not possible

[Fabian Schwartau via USRP-users]

Sorry for the late answer, I was busy.
I tried that including a one second sleep after it but it does not help.

Am 26.04.2019 um 18:30 schrieb Marcus D. Leech via USRP-users:

On 04/26/2019 12:07 PM, Fabian Schwartau via USRP-users wrote:
Ohh.. you are right, I did not do that in the example code. But the 
problem is the same in my main application, where I do. As I said, the 
180° phase shift is probably somehow related and not that easy to 
reporduce. So the spectrum or I/Q swap should be the main issue here 
and I hope that this will also solve the 180° phase swap.
Interestingly the phase is correct, if I set the frequency twice for 
each channel with a little delay in between.
Could you try something?   Insert a set_time_next_pps() into the code in 
initalization--this should align the TOD clocks in both internal DSP radio

   modules.




Am 26.04.2019 um 18:02 schrieb Marcus D. Leech via USRP-users:

On 04/26/2019 11:36 AM, Fabian Schwartau via USRP-users wrote:

Hi,

I am am using LO sharing. So there should not be any phase offset 
and no mirrored spectrum, no matter when the USRP comes around to 
change the frequency. Even not using LO-sharing, the spectrum should 
NOT be mirrored.
The apparent I/Q swap issue I agree should not happen, and I have a 
query in to R about it.





Am 26.04.2019 um 17:12 schrieb Marcus D. Leech via USRP-users:

On 04/26/2019 05:13 AM, Fabian Schwartau via USRP-users wrote:

Hi,

a couple of days ago I filed a bug report which caused the USRPs 
to switch but noone has responded yet. I did now encountered other 
problems wich might be related to that issue. Can somone from 
Ettus (or someone else) take a look at that?

Bug report is here: https://github.com/EttusResearch/uhd/issues/271

Best regards,

Fabian


So, the original design reason for timed-commands was to support 
simultaneous tuning (and assertion of a resynch pulse) across 
*multiple USRPs*,
   in support of reducing/eliminating mutual phase offset among 
identically-hardwared USRPs, for daughtercards that supported 
phase-resynch.


When you use timed commands within a single USRP, hoping for 
similar effects, you won't get them, because the commands in the queue
   are *necessarily* executed sequentially.  Even if there was a 
"parallel execution" structure within the FPGA to handle the 
commands, most of
   the commands you care about ultimately end up on an SPI or I2C 
bus, and those are inherently serial, and multiple devices 
(synthesizers,
   variable-gain amplifiers, clock-plls) typically share a single 
such bus on a per-slot basis.  In order to have "true parallelism" 
*within* a single
   USRP, you'd need dedicated control buses to each device that is 
controlled by I2C/SPI/whatever, *in addition* to parallel execution 
within the

   FPGA.

When you're setting a bunch of PLL synthesizers sequentially, you 
can expect that they won't agree on phase, even when being driven
   by a common clock.   The mechanism for achieving phase coherence 
with TwinRx is to use LO sharing.


https://kb.ettus.com/TwinRX

This app-note talks about LO sharing with TwinRX

https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2 






___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Timed frequency switching on multiple channels not possible

[Fabian Schwartau via USRP-users]

Ohh.. you are right, I did not do that in the example code. But the 
problem is the same in my main application, where I do. As I said, the 
180° phase shift is probably somehow related and not that easy to 
reporduce. So the spectrum or I/Q swap should be the main issue here and 
I hope that this will also solve the 180° phase swap.
Interestingly the phase is correct, if I set the frequency twice for 
each channel with a little delay in between.


Am 26.04.2019 um 18:02 schrieb Marcus D. Leech via USRP-users:

On 04/26/2019 11:36 AM, Fabian Schwartau via USRP-users wrote:

Hi,

I am am using LO sharing. So there should not be any phase offset and 
no mirrored spectrum, no matter when the USRP comes around to change 
the frequency. Even not using LO-sharing, the spectrum should NOT be 
mirrored.
The apparent I/Q swap issue I agree should not happen, and I have a 
query in to R about it.





Am 26.04.2019 um 17:12 schrieb Marcus D. Leech via USRP-users:

On 04/26/2019 05:13 AM, Fabian Schwartau via USRP-users wrote:

Hi,

a couple of days ago I filed a bug report which caused the USRPs to 
switch but noone has responded yet. I did now encountered other 
problems wich might be related to that issue. Can somone from Ettus 
(or someone else) take a look at that?

Bug report is here: https://github.com/EttusResearch/uhd/issues/271

Best regards,

Fabian


So, the original design reason for timed-commands was to support 
simultaneous tuning (and assertion of a resynch pulse) across 
*multiple USRPs*,
   in support of reducing/eliminating mutual phase offset among 
identically-hardwared USRPs, for daughtercards that supported 
phase-resynch.


When you use timed commands within a single USRP, hoping for similar 
effects, you won't get them, because the commands in the queue
   are *necessarily* executed sequentially.  Even if there was a 
"parallel execution" structure within the FPGA to handle the 
commands, most of
   the commands you care about ultimately end up on an SPI or I2C 
bus, and those are inherently serial, and multiple devices 
(synthesizers,
   variable-gain amplifiers, clock-plls) typically share a single 
such bus on a per-slot basis.  In order to have "true parallelism" 
*within* a single
   USRP, you'd need dedicated control buses to each device that is 
controlled by I2C/SPI/whatever, *in addition* to parallel execution 
within the

   FPGA.

When you're setting a bunch of PLL synthesizers sequentially, you can 
expect that they won't agree on phase, even when being driven
   by a common clock.   The mechanism for achieving phase coherence 
with TwinRx is to use LO sharing.


https://kb.ettus.com/TwinRX

This app-note talks about LO sharing with TwinRX

https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2 






___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Timed frequency switching on multiple channels not possible

[Fabian Schwartau via USRP-users]

Hi,

I am am using LO sharing. So there should not be any phase offset and no 
mirrored spectrum, no matter when the USRP comes around to change the 
frequency. Even not using LO-sharing, the spectrum should NOT be mirrored.


Am 26.04.2019 um 17:12 schrieb Marcus D. Leech via USRP-users:

On 04/26/2019 05:13 AM, Fabian Schwartau via USRP-users wrote:

Hi,

a couple of days ago I filed a bug report which caused the USRPs to 
switch but noone has responded yet. I did now encountered other 
problems wich might be related to that issue. Can somone from Ettus 
(or someone else) take a look at that?

Bug report is here: https://github.com/EttusResearch/uhd/issues/271

Best regards,

Fabian


So, the original design reason for timed-commands was to support 
simultaneous tuning (and assertion of a resynch pulse) across *multiple 
USRPs*,
   in support of reducing/eliminating mutual phase offset among 
identically-hardwared USRPs, for daughtercards that supported 
phase-resynch.


When you use timed commands within a single USRP, hoping for similar 
effects, you won't get them, because the commands in the queue
   are *necessarily* executed sequentially.  Even if there was a 
"parallel execution" structure within the FPGA to handle the commands, 
most of
   the commands you care about ultimately end up on an SPI or I2C bus, 
and those are inherently serial, and multiple devices (synthesizers,
   variable-gain amplifiers, clock-plls) typically share a single such 
bus on a per-slot basis.  In order to have "true parallelism" *within* a 
single
   USRP, you'd need dedicated control buses to each device that is 
controlled by I2C/SPI/whatever, *in addition* to parallel execution 
within the

   FPGA.

When you're setting a bunch of PLL synthesizers sequentially, you can 
expect that they won't agree on phase, even when being driven
   by a common clock.   The mechanism for achieving phase coherence with 
TwinRx is to use LO sharing.


https://kb.ettus.com/TwinRX

This app-note talks about LO sharing with TwinRX

https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2 






___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRPs time wrong by factor of two

[Fabian Schwartau via USRP-users]

Hi,

is it to be expected that this will be fixed soon? Is someone at Ettus 
working on this?


Best regards,
Fabian

Am 23.04.2019 um 19:34 schrieb Fabian Schwartau via USRP-users:
OK, I just reverted the system to the old version and that works 
perfectly. The USRP time is incremented in full seconds like expected. 
So something changed somewhere in the lib/fpga image.

The version I am using now is:
linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_003.010.002.HEAD-0-gbd6e21dc

Hope that helps.

Am 23.04.2019 um 19:12 schrieb Marcus D. Leech via USRP-users:

On 04/23/2019 01:10 PM, Fabian Schwartau via USRP-users wrote:
Will the fpga image downloader from the old version also download the 
old fpga images? Or where can I get them?
I don't know if I will do it. I am afraid of breaking my system 
and/or investing a lot of time with this as I am under quite a lot of 
time preasure and I am basically working on the production system 
which has to bo rolled out in a few days. If I brick it, I will get 
in trouble ;)
The uhd_images_downloader tool will always download the images that 
match the library version.





Am 23.04.2019 um 18:51 schrieb Marcus D. Leech via USRP-users:

On 04/23/2019 11:48 AM, Fabian Schwartau via USRP-users wrote:

Hi,
its the same. I found the bug because the timed commands took much 
longer than expected, so the USRP clock is actually running at a 
lower rate. However, the spectra looked ok and everything else 
seems to be working as usual, except there is a larger delay 
between the commands. So the USRP is not running at a wrong clock 
or something like that. That would probably cause much larger issues.


Best regards,
Fabian

If you revert to a previous release, does the problem go away?





Am 23.04.2019 um 17:27 schrieb Marcus D. Leech via USRP-users:

On 04/23/2019 09:47 AM, Fabian Schwartau via USRP-users wrote:

Hi everyone,

I just found a very strage bug and would like to confirm that 
this is a bug and if someone can explain/fix this.
I read the time from the USRP using get_time_now() and do a lot 
of stuff with it. Mainly to time commands like frequency hopping 
and starting of streams. I noticed that the time in the USRP 
seemed to run slower than expected, actually by a factor of two.
Please find a program attached that demonstrates this effect. It 
prints the internal USRP time roughly every second (using sleep) 
but the USRP time increments only by 0.5 seconds in each step. 
What is going on?


The program can be compiled using:
g++ -std=c++14 -O2 main.cpp -luhd -lboost_system -o main

I am using a single (or multiple - does not have an effect) X310 
with two TwinRX. UHD is "linux; GNU C++ version 5.5.0 20171010; 
Boost_105800; UHD_3.15.0.git-89-gf93c5227" from yesterday. FPGA 
image is also from yesterday using the download script - where 
can I find the version number? I am running an up-to-date Ubuntu 
16.04.
Could you try the print as a get_frac_secs() and get_full_secs() 
instead?   To disambiguate whether this is an actual hardware 
clock management

   issue or just a formatting issue.



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Timed frequency switching on multiple channels not possible

[Fabian Schwartau via USRP-users]

Hi,

a couple of days ago I filed a bug report which caused the USRPs to 
switch but noone has responded yet. I did now encountered other problems 
wich might be related to that issue. Can somone from Ettus (or someone 
else) take a look at that?

Bug report is here: https://github.com/EttusResearch/uhd/issues/271

Best regards,

Fabian

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] get_time_now() blocking?

[Fabian Schwartau via USRP-users]

Hi,

thanks for clarification.
It would be great if there would be a more detailed description of the 
timed command behaviour on the wiki. For example a list clarifying which 
commands are affected by set_command_time and which are not. The fact 
that switching sample rates using timed commands should jump right in 
your face at multiple points of the documentation in big red letters - 
you know what I mean ;)


Best regards,
Fabian

Am 25.04.2019 um 03:15 schrieb Marcus D. Leech via USRP-users:

On 04/24/2019 04:16 AM, Fabian Schwartau via USRP-users wrote:

To answer my own question: Yes, it does.
Even when calling clear_command_time(), the get_time_now() will be 
executed (and thus return) after the last commited command was 
executed, no matter what command it was. Additionally if the last 
command is too far in the future, get_time_now() will fail and throw 
an exception, saying that the USRP did not respond.
The "waits until the queue has execute" behavior is expected and 
design-intent.


The timeout is probably also, in a sense, design-intent, but fails the 
"least astonishment test".  In the normal case, the command is sent to the
   device, and it is expected that a response packet will come back "in 
a reasonable time".  But in this particular case, the response won't arrive
   until all the commands have executed, and that can exceed the 
protocol-timeout window.


This is, I admit,  "a bit rough", and I suspect that there are other 
cases in timed-commands where this sort of thing happens as well.





Am 23.04.2019 um 22:54 schrieb Fabian Schwartau via USRP-users:
Hmm does this also mean that get_time_now will block if there are 
other commands issued before that with a later execution? That might 
explain my issues.


Am 23. April 2019 22:38:01 MESZ schrieb "Marcus D. Leech via 
USRP-users" :


    On 04/23/2019 02:51 PM, Fabian Schwartau via USRP-users wrote:

    Hi,

    well, ...
    I am recording small slots (up to 2 seconds) of data at 
different

    frequencies, gain, sample rates, etc. I have written a manager
    for the
    USRP where other classes can ask for a certain slot (frequency,
    sample
    count, sample rate, ...). The manager does not know when someone
    will
    ask for data. So it happens that there is nothing to do. In that
    case
    the manager looses track of the current time and does not know
    when to
    start the next command once someone asks for a new slot. In this
    case
    he gets the current time, adds a few hundred ms to be on the
    safe side
    and continues. Even if I would be able to plan that far ahead, I
    found
    out that the USRP is not able to plan commands that are quite
    far in
    the future (it was like 10 seconds or so). Starnge things happen
    and I
    also loose track of the time.
    One more reason is that the USRP is not capable of timed sample
    rate
    switches (was discusses here a few month back) which means 
that the

    manager has to wait until all pending commands are done and the
    data
    is received, then switch the sample rate, get the current time
    (as the
    processing/download of the data in the other thread may take 
some

    time), again add a few hundred ms and continue.
    Actually I am currently quite pissed as I run into one bug after
    another and cannot continue my actual work. I found like another
    three
    critical bugs, but I cannot reporoduce them in smaller programs
    and I
    do not have the time to debug the full UHD library. So I 
write one

    workaround after another.

    Best regards,
    Fabian

    Also, get_time_now() is controlled by set_command_time(). So, for
    example, if you have two threads issuing control commands, and 
one thread

    issues a set_command_time(), and then another thread issues a
    get_time_now() while there's a set_command_time() window pending, 
it will
    be controlled by the set_command_time().   The USRP device 
has zero
    concept of threading, per se, so it's up to the application to 
keep track

    of stuff like this.

    USRP-users mailing list
    USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-

Re: [USRP-users] get_time_now() blocking?

[Fabian Schwartau via USRP-users]

To answer my own question: Yes, it does.
Even when calling clear_command_time(), the get_time_now() will be 
executed (and thus return) after the last commited command was executed, 
no matter what command it was. Additionally if the last command is too 
far in the future, get_time_now() will fail and throw an exception, 
saying that the USRP did not respond.


Am 23.04.2019 um 22:54 schrieb Fabian Schwartau via USRP-users:
Hmm does this also mean that get_time_now will block if there are other 
commands issued before that with a later execution? That might explain 
my issues.


Am 23. April 2019 22:38:01 MESZ schrieb "Marcus D. Leech via USRP-users" 
:


On 04/23/2019 02:51 PM, Fabian Schwartau via USRP-users wrote:

Hi,

well, ...
I am recording small slots (up to 2 seconds) of data at different
frequencies, gain, sample rates, etc. I have written a manager
for the
USRP where other classes can ask for a certain slot (frequency,
sample
count, sample rate, ...). The manager does not know when someone
will
ask for data. So it happens that there is nothing to do. In that
case
the manager looses track of the current time and does not know
when to
start the next command once someone asks for a new slot. In this
case
he gets the current time, adds a few hundred ms to be on the
safe side
and continues. Even if I would be able to plan that far ahead, I
found
out that the USRP is not able to plan commands that are quite
far in
the future (it was like 10 seconds or so). Starnge things happen
and I
also loose track of the time.
One more reason is that the USRP is not capable of timed sample
rate
switches (was discusses here a few month back) which means that the
manager has to wait until all pending commands are done and the
data
is received, then switch the sample rate, get the current time
(as the
processing/download of the data in the other thread may take some
time), again add a few hundred ms and continue.
Actually I am currently quite pissed as I run into one bug after
another and cannot continue my actual work. I found like another
three
critical bugs, but I cannot reporoduce them in smaller programs
and I
do not have the time to debug the full UHD library. So I write one
workaround after another.

Best regards,
Fabian

Also, get_time_now() is controlled by set_command_time().  So, for
example, if you have two threads issuing control commands, and one thread
issues a set_command_time(), and then another thread issues a
get_time_now() while there's a set_command_time() window pending, it will
be controlled by the set_command_time().   The USRP device has zero
concept of threading, per se, so it's up to the application to keep track
of stuff like this.

USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] get_time_now() blocking?

[Fabian Schwartau via USRP-users]

Hmm does this also mean that get_time_now will block if there are other 
commands issued before that with a later execution? That might explain my 
issues. 

Am 23. April 2019 22:38:01 MESZ schrieb "Marcus D. Leech via USRP-users" 
:
>On 04/23/2019 02:51 PM, Fabian Schwartau via USRP-users wrote:
>> Hi,
>>
>> well, ...
>> I am recording small slots (up to 2 seconds) of data at different 
>> frequencies, gain, sample rates, etc. I have written a manager for
>the 
>> USRP where other classes can ask for a certain slot (frequency,
>sample 
>> count, sample rate, ...). The manager does not know when someone will
>
>> ask for data. So it happens that there is nothing to do. In that case
>
>> the manager looses track of the current time and does not know when
>to 
>> start the next command once someone asks for a new slot. In this case
>
>> he gets the current time, adds a few hundred ms to be on the safe
>side 
>> and continues. Even if I would be able to plan that far ahead, I
>found 
>> out that the USRP is not able to plan commands that are quite far in 
>> the future (it was like 10 seconds or so). Starnge things happen and
>I 
>> also loose track of the time.
>> One more reason is that the USRP is not capable of timed sample rate 
>> switches (was discusses here a few month back) which means that the 
>> manager has to wait until all pending commands are done and the data 
>> is received, then switch the sample rate, get the current time (as
>the 
>> processing/download of the data in the other thread may take some 
>> time), again add a few hundred ms and continue.
>> Actually I am currently quite pissed as I run into one bug after 
>> another and cannot continue my actual work. I found like another
>three 
>> critical bugs, but I cannot reporoduce them in smaller programs and I
>
>> do not have the time to debug the full UHD library. So I write one 
>> workaround after another.
>>
>> Best regards,
>> Fabian
>>
>Also, get_time_now() is controlled by set_command_time().  So, for 
>example, if you have two threads issuing control commands, and one
>thread
>   issues a set_command_time(), and then another thread issues a 
>get_time_now() while there's a set_command_time() window pending, it
>will
>   be controlled by the set_command_time().   The USRP device has zero 
>concept of threading, per se, so it's up to the application to keep
>track
>   of stuff like this.
>
>
>
>___
>USRP-users mailing list
>USRP-users@lists.ettus.com
>http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] get_time_now() blocking?

[Fabian Schwartau via USRP-users]

I have only one thread sending commands and another one receiving the data. So 
there should be no issue. 

Am 23. April 2019 22:38:01 MESZ schrieb "Marcus D. Leech via USRP-users" 
:
>On 04/23/2019 02:51 PM, Fabian Schwartau via USRP-users wrote:
>> Hi,
>>
>> well, ...
>> I am recording small slots (up to 2 seconds) of data at different 
>> frequencies, gain, sample rates, etc. I have written a manager for
>the 
>> USRP where other classes can ask for a certain slot (frequency,
>sample 
>> count, sample rate, ...). The manager does not know when someone will
>
>> ask for data. So it happens that there is nothing to do. In that case
>
>> the manager looses track of the current time and does not know when
>to 
>> start the next command once someone asks for a new slot. In this case
>
>> he gets the current time, adds a few hundred ms to be on the safe
>side 
>> and continues. Even if I would be able to plan that far ahead, I
>found 
>> out that the USRP is not able to plan commands that are quite far in 
>> the future (it was like 10 seconds or so). Starnge things happen and
>I 
>> also loose track of the time.
>> One more reason is that the USRP is not capable of timed sample rate 
>> switches (was discusses here a few month back) which means that the 
>> manager has to wait until all pending commands are done and the data 
>> is received, then switch the sample rate, get the current time (as
>the 
>> processing/download of the data in the other thread may take some 
>> time), again add a few hundred ms and continue.
>> Actually I am currently quite pissed as I run into one bug after 
>> another and cannot continue my actual work. I found like another
>three 
>> critical bugs, but I cannot reporoduce them in smaller programs and I
>
>> do not have the time to debug the full UHD library. So I write one 
>> workaround after another.
>>
>> Best regards,
>> Fabian
>>
>Also, get_time_now() is controlled by set_command_time().  So, for 
>example, if you have two threads issuing control commands, and one
>thread
>   issues a set_command_time(), and then another thread issues a 
>get_time_now() while there's a set_command_time() window pending, it
>will
>   be controlled by the set_command_time().   The USRP device has zero 
>concept of threading, per se, so it's up to the application to keep
>track
>   of stuff like this.
>
>
>
>___
>USRP-users mailing list
>USRP-users@lists.ettus.com
>http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] get_time_now() blocking?

[Fabian Schwartau via USRP-users]

How am I supposed to keep track of the time from the meta data of the received 
packets if I do not receive packets? As I said, I sometimes have long times of 
not receiving anything when the old data is being processed. 

Am 23. April 2019 22:22:52 MESZ schrieb "Marcus D. Leech via USRP-users" 
:
>On 04/23/2019 02:51 PM, Fabian Schwartau via USRP-users wrote:
>> Hi,
>>
>> well, ...
>> I am recording small slots (up to 2 seconds) of data at different 
>> frequencies, gain, sample rates, etc. I have written a manager for
>the 
>> USRP where other classes can ask for a certain slot (frequency,
>sample 
>> count, sample rate, ...). The manager does not know when someone will
>
>> ask for data. So it happens that there is nothing to do. In that case
>
>> the manager looses track of the current time and does not know when
>to 
>> start the next command once someone asks for a new slot. In this case
>
>> he gets the current time, adds a few hundred ms to be on the safe
>side 
>> and continues. Even if I would be able to plan that far ahead, I
>found 
>> out that the USRP is not able to plan commands that are quite far in 
>> the future (it was like 10 seconds or so). Starnge things happen and
>I 
>> also loose track of the time.
>> One more reason is that the USRP is not capable of timed sample rate 
>> switches (was discusses here a few month back) which means that the 
>> manager has to wait until all pending commands are done and the data 
>> is received, then switch the sample rate, get the current time (as
>the 
>> processing/download of the data in the other thread may take some 
>> time), again add a few hundred ms and continue.
>> Actually I am currently quite pissed as I run into one bug after 
>> another and cannot continue my actual work. I found like another
>three 
>> critical bugs, but I cannot reporoduce them in smaller programs and I
>
>> do not have the time to debug the full UHD library. So I write one 
>> workaround after another.
>>
>> Best regards,
>> Fabian
>>
>So, you do know that every single sample buffer from UHD includes a 
>time-stamp as seen by the USRP?  If you know the sample rate, you know
>   exactly when every single sample arrived, and you can use that as a 
>"clock keeper".
>
>If you cannot reproduce the behavior in smaller programs, then I would 
>humbly suggest that your problems have to do with your
>   overall architecture, and some "buried subtleties".
>
>
>>
>> Am 23.04.2019 um 20:29 schrieb Brian Padalino:
>>> On Tue, Apr 23, 2019 at 2:06 PM Fabian Schwartau via USRP-users 
>>> mailto:usrp-users@lists.ettus.com>>
>wrote:
>>>
>>> Hi everyone,
>>>
>>> I just found another strange thing. Can get_time_now() be in any
>
>>> case
>>> blocking? Like long blocking? It takes more than 1 second to
>return!
>>> I am heavily using timed commands, but I tried a 
>>> clear_command_time()
>>> before calling get_time_now() with no effect. It would also make
>no
>>> sense at all to be able to set a command time for
>get_time_now().
>>> According to documentation the command just reads the registers 
>>> in the
>>> USRPs and returns them - no need to wait for anything.
>>> Any ideas?
>>>
>>>
>>> Reading registers isn't the fastest thing in the world, but you 
>>> shouldn't be utilizing get_time_now() heavily for a real time 
>>> system.  Taking a second sounds like something is wrong, but I'm 
>>> still curious why you're constantly asking for the time.
>>>
>>> The idea behind that is to understand the current time the radio
>has, 
>>> figure out what you want to do when you first start a stream or do 
>>> something, then use sample counting to understand when things are 
>>> supposed to be happening.
>>>
>>> So, why do you keep asking for the time?  What's the use case you're
>
>>> trying to figure out?
>>>
>>> Brian
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>___
>USRP-users mailing list
>USRP-users@lists.ettus.com
>http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] get_time_now() blocking?

[Fabian Schwartau via USRP-users]

Hi,

well, ...
I am recording small slots (up to 2 seconds) of data at different 
frequencies, gain, sample rates, etc. I have written a manager for the 
USRP where other classes can ask for a certain slot (frequency, sample 
count, sample rate, ...). The manager does not know when someone will 
ask for data. So it happens that there is nothing to do. In that case 
the manager looses track of the current time and does not know when to 
start the next command once someone asks for a new slot. In this case he 
gets the current time, adds a few hundred ms to be on the safe side and 
continues. Even if I would be able to plan that far ahead, I found out 
that the USRP is not able to plan commands that are quite far in the 
future (it was like 10 seconds or so). Starnge things happen and I also 
loose track of the time.
One more reason is that the USRP is not capable of timed sample rate 
switches (was discusses here a few month back) which means that the 
manager has to wait until all pending commands are done and the data is 
received, then switch the sample rate, get the current time (as the 
processing/download of the data in the other thread may take some time), 
again add a few hundred ms and continue.
Actually I am currently quite pissed as I run into one bug after another 
and cannot continue my actual work. I found like another three critical 
bugs, but I cannot reporoduce them in smaller programs and I do not have 
the time to debug the full UHD library. So I write one workaround after 
another.


Best regards,
Fabian


Am 23.04.2019 um 20:29 schrieb Brian Padalino:
On Tue, Apr 23, 2019 at 2:06 PM Fabian Schwartau via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Hi everyone,

I just found another strange thing. Can get_time_now() be in any case
blocking? Like long blocking? It takes more than 1 second to return!
I am heavily using timed commands, but I tried a clear_command_time()
before calling get_time_now() with no effect. It would also make no
sense at all to be able to set a command time for get_time_now().
According to documentation the command just reads the registers in the
USRPs and returns them - no need to wait for anything.
Any ideas?


Reading registers isn't the fastest thing in the world, but you 
shouldn't be utilizing get_time_now() heavily for a real time system.  
Taking a second sounds like something is wrong, but I'm still curious 
why you're constantly asking for the time.


The idea behind that is to understand the current time the radio has, 
figure out what you want to do when you first start a stream or do 
something, then use sample counting to understand when things are 
supposed to be happening.


So, why do you keep asking for the time?  What's the use case you're 
trying to figure out?


Brian


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] get_time_now() blocking?

[Fabian Schwartau via USRP-users]

Hi everyone,

I just found another strange thing. Can get_time_now() be in any case 
blocking? Like long blocking? It takes more than 1 second to return!
I am heavily using timed commands, but I tried a clear_command_time() 
before calling get_time_now() with no effect. It would also make no 
sense at all to be able to set a command time for get_time_now().
According to documentation the command just reads the registers in the 
USRPs and returns them - no need to wait for anything.

Any ideas?

Best regards,
Fabian

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRPs time wrong by factor of two

[Fabian Schwartau via USRP-users]

OK, I just reverted the system to the old version and that works 
perfectly. The USRP time is incremented in full seconds like expected. 
So something changed somewhere in the lib/fpga image.

The version I am using now is:
linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_003.010.002.HEAD-0-gbd6e21dc

Hope that helps.

Am 23.04.2019 um 19:12 schrieb Marcus D. Leech via USRP-users:

On 04/23/2019 01:10 PM, Fabian Schwartau via USRP-users wrote:
Will the fpga image downloader from the old version also download the 
old fpga images? Or where can I get them?
I don't know if I will do it. I am afraid of breaking my system and/or 
investing a lot of time with this as I am under quite a lot of time 
preasure and I am basically working on the production system which has 
to bo rolled out in a few days. If I brick it, I will get in trouble ;)
The uhd_images_downloader tool will always download the images that 
match the library version.





Am 23.04.2019 um 18:51 schrieb Marcus D. Leech via USRP-users:

On 04/23/2019 11:48 AM, Fabian Schwartau via USRP-users wrote:

Hi,
its the same. I found the bug because the timed commands took much 
longer than expected, so the USRP clock is actually running at a 
lower rate. However, the spectra looked ok and everything else seems 
to be working as usual, except there is a larger delay between the 
commands. So the USRP is not running at a wrong clock or something 
like that. That would probably cause much larger issues.


Best regards,
Fabian

If you revert to a previous release, does the problem go away?





Am 23.04.2019 um 17:27 schrieb Marcus D. Leech via USRP-users:

On 04/23/2019 09:47 AM, Fabian Schwartau via USRP-users wrote:

Hi everyone,

I just found a very strage bug and would like to confirm that this 
is a bug and if someone can explain/fix this.
I read the time from the USRP using get_time_now() and do a lot of 
stuff with it. Mainly to time commands like frequency hopping and 
starting of streams. I noticed that the time in the USRP seemed to 
run slower than expected, actually by a factor of two.
Please find a program attached that demonstrates this effect. It 
prints the internal USRP time roughly every second (using sleep) 
but the USRP time increments only by 0.5 seconds in each step. 
What is going on?


The program can be compiled using:
g++ -std=c++14 -O2 main.cpp -luhd -lboost_system -o main

I am using a single (or multiple - does not have an effect) X310 
with two TwinRX. UHD is "linux; GNU C++ version 5.5.0 20171010; 
Boost_105800; UHD_3.15.0.git-89-gf93c5227" from yesterday. FPGA 
image is also from yesterday using the download script - where can 
I find the version number? I am running an up-to-date Ubuntu 16.04.
Could you try the print as a get_frac_secs() and get_full_secs() 
instead?   To disambiguate whether this is an actual hardware clock 
management

   issue or just a formatting issue.



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRPs time wrong by factor of two

[Fabian Schwartau via USRP-users]

Will the fpga image downloader from the old version also download the 
old fpga images? Or where can I get them?
I don't know if I will do it. I am afraid of breaking my system and/or 
investing a lot of time with this as I am under quite a lot of time 
preasure and I am basically working on the production system which has 
to bo rolled out in a few days. If I brick it, I will get in trouble ;)


Am 23.04.2019 um 18:51 schrieb Marcus D. Leech via USRP-users:

On 04/23/2019 11:48 AM, Fabian Schwartau via USRP-users wrote:

Hi,
its the same. I found the bug because the timed commands took much 
longer than expected, so the USRP clock is actually running at a lower 
rate. However, the spectra looked ok and everything else seems to be 
working as usual, except there is a larger delay between the commands. 
So the USRP is not running at a wrong clock or something like that. 
That would probably cause much larger issues.


Best regards,
Fabian

If you revert to a previous release, does the problem go away?





Am 23.04.2019 um 17:27 schrieb Marcus D. Leech via USRP-users:

On 04/23/2019 09:47 AM, Fabian Schwartau via USRP-users wrote:

Hi everyone,

I just found a very strage bug and would like to confirm that this 
is a bug and if someone can explain/fix this.
I read the time from the USRP using get_time_now() and do a lot of 
stuff with it. Mainly to time commands like frequency hopping and 
starting of streams. I noticed that the time in the USRP seemed to 
run slower than expected, actually by a factor of two.
Please find a program attached that demonstrates this effect. It 
prints the internal USRP time roughly every second (using sleep) but 
the USRP time increments only by 0.5 seconds in each step. What is 
going on?


The program can be compiled using:
g++ -std=c++14 -O2 main.cpp -luhd -lboost_system -o main

I am using a single (or multiple - does not have an effect) X310 
with two TwinRX. UHD is "linux; GNU C++ version 5.5.0 20171010; 
Boost_105800; UHD_3.15.0.git-89-gf93c5227" from yesterday. FPGA 
image is also from yesterday using the download script - where can I 
find the version number? I am running an up-to-date Ubuntu 16.04.
Could you try the print as a get_frac_secs() and get_full_secs() 
instead?   To disambiguate whether this is an actual hardware clock 
management

   issue or just a formatting issue.



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRPs time wrong by factor of two

[Fabian Schwartau via USRP-users]

Hi,
its the same. I found the bug because the timed commands took much 
longer than expected, so the USRP clock is actually running at a lower 
rate. However, the spectra looked ok and everything else seems to be 
working as usual, except there is a larger delay between the commands. 
So the USRP is not running at a wrong clock or something like that. That 
would probably cause much larger issues.


Best regards,
Fabian


Am 23.04.2019 um 17:27 schrieb Marcus D. Leech via USRP-users:

On 04/23/2019 09:47 AM, Fabian Schwartau via USRP-users wrote:

Hi everyone,

I just found a very strage bug and would like to confirm that this is 
a bug and if someone can explain/fix this.
I read the time from the USRP using get_time_now() and do a lot of 
stuff with it. Mainly to time commands like frequency hopping and 
starting of streams. I noticed that the time in the USRP seemed to run 
slower than expected, actually by a factor of two.
Please find a program attached that demonstrates this effect. It 
prints the internal USRP time roughly every second (using sleep) but 
the USRP time increments only by 0.5 seconds in each step. What is 
going on?


The program can be compiled using:
g++ -std=c++14 -O2 main.cpp -luhd -lboost_system -o main

I am using a single (or multiple - does not have an effect) X310 with 
two TwinRX. UHD is "linux; GNU C++ version 5.5.0 20171010; 
Boost_105800; UHD_3.15.0.git-89-gf93c5227" from yesterday. FPGA image 
is also from yesterday using the download script - where can I find 
the version number? I am running an up-to-date Ubuntu 16.04.
Could you try the print as a get_frac_secs() and get_full_secs() 
instead?   To disambiguate whether this is an actual hardware clock 
management

   issue or just a formatting issue.



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRPs time wrong by factor of two

[Fabian Schwartau via USRP-users]

Hi,

did error checking, no errors.
The sleep also fits quite well with my feeling and in my main program I 
am working on, I am using QThread::currentThread->sleep(1) and 
additionally printing the current system time. So I am very confident 
this is a problem on the USRP side.
I switched to an up to date UHD/FPGA image version just yesterday. 
Before that I was using a version from a bit more than a year ago and I 
am quite sure this did not happen in the old version. It was commit 
bd6e21dc.
If noone has an idea (maybe I am doing something really stupid), I will 
open a bug report.


Best regards,
Fabian

Am 23.04.2019 um 16:31 schrieb Tillson, Bob (US):

While I would not expect sleep to fail consistently, it *can* return a non zero 
value when not sleeping for the entire time.

Try checking the return value for success.  Its not likely this is the cause if 
it happens every time, but error checking is your friend :)

-Original Message-
From: USRP-users  On Behalf Of Fabian 
Schwartau via USRP-users
Sent: Tuesday, April 23, 2019 9:47 AM
To: usrp-users 
Subject: [USRP-users] USRPs time wrong by factor of two

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


Hi everyone,

I just found a very strage bug and would like to confirm that this is a bug and 
if someone can explain/fix this.
I read the time from the USRP using get_time_now() and do a lot of stuff with 
it. Mainly to time commands like frequency hopping and starting of streams. I 
noticed that the time in the USRP seemed to run slower than expected, actually 
by a factor of two.
Please find a program attached that demonstrates this effect. It prints the 
internal USRP time roughly every second (using sleep) but the USRP time 
increments only by 0.5 seconds in each step. What is going on?

The program can be compiled using:
g++ -std=c++14 -O2 main.cpp -luhd -lboost_system -o main

I am using a single (or multiple - does not have an effect) X310 with two TwinRX. UHD is 
"linux; GNU C++ version 5.5.0 20171010; Boost_105800; 
UHD_3.15.0.git-89-gf93c5227" from yesterday. FPGA image is also from yesterday using 
the download script - where can I find the version number? I am running an up-to-date 
Ubuntu 16.04.
--
--
M.-Sc. Fabian Schwartau
Technische Universität Braunschweig
Institut für Hochfrequenztechnik
Schleinitzstr. 22
38106 Braunschweig
Germany

Tel.:   +49-(0)531-391-2017
Fax:+49-(0)531-391-2045
Email:  fabian.schwar...@ihf.tu-bs.de
WWW:http://www.tu-braunschweig.de/ihf
--



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] USRPs time wrong by factor of two

[Fabian Schwartau via USRP-users]

Hi everyone,

I just found a very strage bug and would like to confirm that this is a 
bug and if someone can explain/fix this.
I read the time from the USRP using get_time_now() and do a lot of stuff 
with it. Mainly to time commands like frequency hopping and starting of 
streams. I noticed that the time in the USRP seemed to run slower than 
expected, actually by a factor of two.
Please find a program attached that demonstrates this effect. It prints 
the internal USRP time roughly every second (using sleep) but the USRP 
time increments only by 0.5 seconds in each step. What is going on?


The program can be compiled using:
g++ -std=c++14 -O2 main.cpp -luhd -lboost_system -o main

I am using a single (or multiple - does not have an effect) X310 with 
two TwinRX. UHD is "linux; GNU C++ version 5.5.0 20171010; Boost_105800; 
UHD_3.15.0.git-89-gf93c5227" from yesterday. FPGA image is also from 
yesterday using the download script - where can I find the version 
number? I am running an up-to-date Ubuntu 16.04.

--
--
M.-Sc. Fabian Schwartau
Technische Universität Braunschweig
Institut für Hochfrequenztechnik
Schleinitzstr. 22
38106 Braunschweig
Germany

Tel.:   +49-(0)531-391-2017
Fax:+49-(0)531-391-2045
Email:  fabian.schwar...@ihf.tu-bs.de
WWW:http://www.tu-braunschweig.de/ihf
--

// g++ -std=c++14 -O2 main.cpp -luhd -lboost_system -o main

#include 
#include 
#include 
#include 

using namespace std;

int UHD_SAFE_MAIN(int, char*[])
{
uhd::set_thread_priority_safe();

// Init USRP
std::string args = "addr0=192.168.41.2";
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);

for(int i = 0; i < 10; i++)
{
cout

Re: [USRP-users] Unable to set the thread priority

[Fabian Schwartau via USRP-users]

I finally found the solution. I was working over xrdp which caused the 
problem. This can be solved by adding

sessionrequired   pam_limits.so
to the file /etc/pam.d/common-session.

Maybe this can help someone else.

Am 18.04.2019 um 19:46 schrieb Marcus D. Leech via USRP-users:

On 04/18/2019 11:49 AM, Fabian Schwartau via USRP-users wrote:

It says 0.
I guess that is not good.
Any further ideas?
Well, this is clearly a Linux, rather than UHD/USRP issue.   You'll have 
to do some digging in Linux-support land.





Am 18.04.2019 um 17:39 schrieb Marcus D. Leech via USRP-users:

On 04/18/2019 03:40 AM, Fabian Schwartau via USRP-users wrote:

Hi,

I just double checked the limits configuration. The file seems ok, 
every line except the one I showed earlier is a comment. But I found 
an additional file called /etc/security/limits.d/uhd.conf where the 
same statement was in, but for the group uhd. I changed that to 
plugdev, removed the line in limits.conf and rebooted. Still the 
same warning message.
Is there a way to actuall check the thread priority limits for my 
current user?


Best regards,
Fabian

ulimit -r




Am 17.04.2019 um 17:24 schrieb Marcus D. Leech via USRP-users:

On 04/17/2019 09:10 AM, Fabian Schwartau via USRP-users wrote:

Hi everyone,

for some reasons I suddenly see the error message, that UHD cannot 
set the thread priority. It has been working before.

As you can see below my settings seem to be correct:

fschwa@rfserv:~$ tail -n 3 /etc/security/limits.conf
@plugdev    - rtprio    99

# End of file
fschwa@rfserv:~$ groups
fschwa adm tty dialout cdrom sudo dip plugdev lpadmin sambashare alfa
fschwa@rfserv:~$

The message disappears when running the application as root. What 
could be the cause?

The USRPs are connected using 10G Ethernet, UHD version is 3.10.2.

Best regards,
Fabian


Have you done a system upgrade?

Have you changed /etc/security/limits.conf    recently, and is 
there perhaps a syntax error in it?


If you reboot, does the behavior change?



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Unable to set the thread priority

[Fabian Schwartau via USRP-users]

Hi,

I just double checked the limits configuration. The file seems ok, every 
line except the one I showed earlier is a comment. But I found an 
additional file called /etc/security/limits.d/uhd.conf where the same 
statement was in, but for the group uhd. I changed that to plugdev, 
removed the line in limits.conf and rebooted. Still the same warning 
message.
Is there a way to actuall check the thread priority limits for my 
current user?


Best regards,
Fabian

Am 17.04.2019 um 17:24 schrieb Marcus D. Leech via USRP-users:

On 04/17/2019 09:10 AM, Fabian Schwartau via USRP-users wrote:

Hi everyone,

for some reasons I suddenly see the error message, that UHD cannot set 
the thread priority. It has been working before.

As you can see below my settings seem to be correct:

fschwa@rfserv:~$ tail -n 3 /etc/security/limits.conf
@plugdev    - rtprio    99

# End of file
fschwa@rfserv:~$ groups
fschwa adm tty dialout cdrom sudo dip plugdev lpadmin sambashare alfa
fschwa@rfserv:~$

The message disappears when running the application as root. What 
could be the cause?

The USRPs are connected using 10G Ethernet, UHD version is 3.10.2.

Best regards,
Fabian


Have you done a system upgrade?

Have you changed /etc/security/limits.conf    recently, and is there 
perhaps a syntax error in it?


If you reboot, does the behavior change?



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Unable to set the thread priority

[Fabian Schwartau via USRP-users]

Hi everyone,

for some reasons I suddenly see the error message, that UHD cannot set 
the thread priority. It has been working before.

As you can see below my settings seem to be correct:

fschwa@rfserv:~$ tail -n 3 /etc/security/limits.conf
@plugdev- rtprio99

# End of file
fschwa@rfserv:~$ groups
fschwa adm tty dialout cdrom sudo dip plugdev lpadmin sambashare alfa
fschwa@rfserv:~$

The message disappears when running the application as root. What could 
be the cause?

The USRPs are connected using 10G Ethernet, UHD version is 3.10.2.

Best regards,
Fabian

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Changing sample rate while running.

[Fabian Schwartau via USRP-users]

Hi,

maybe this is related to a very similar problem I had back a few month 
ago. Here is the thread:

http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-July/057308.html

The outcome was basically that the software does not support timed 
sample rate switching. I had to wait for every command to be finished, 
switch the samplerate and restart everything. But maybe that is a bit 
different from your situation as you are not looking for timed commands.


Best regards,
Fabian

Am 08.04.2019 um 17:54 schrieb Chance Tarver via USRP-users:

Hi all,

I am working on a project where I need to change the sampling rate 
occasionally while running my application.


At an event where I need to change the sampling rate, I am currently 
calling the following function:

|set_tx_rate(new_rate, channel)|

The master clock is always set to 30.72MHz and the TX bandwidth is set 
to 20MHz.


When the change occurs, it seems that I am not getting the new sampling 
rate on the spectrum analyzer. I know these sort of changes in sampling 
rates can be weird and depend on how the various clocks are set.


Is there a recommended procedure / series of steps for a change in 
sampling rate to take effect?


I appreciate any guidance.

Thanks,
Chance Tarver
Rice University

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

[Fabian Schwartau via USRP-users]

Hi,
I don't know what this patch does, but there is not software required 
under certain circumstances. The reference clock is 200 MHz and there 
are a few PLLs which are used to generate your LOs. When the PLLs run in 
interger-N mode (which can be defined in the API, when explicitly 
setting the frequencies), and they do not divide the clock, all LOs will 
have the same phase. So in multiples of 200 MHz this should be the case. 
For multiples of 50 MHz you will get 90° random phase jumps after the 
PLLs are locked again.


Best regards,
Fabian

Am 03.04.2019 um 12:36 schrieb Piotr Krysik via USRP-users:

To answer my own question:
https://github.com/EttusResearch/uhd/blob/master/CHANGELOG#L226

it seems the answer is yes.

--
Piotr Krysik
W dniu 03.04.2019 o 12:34, Piotr Krysik via USRP-users pisze:

Hi,

W dniu 03.04.2019 o 12:15, Fabian Schwartau via USRP-users pisze:

(...)
Keep in mind that it is not necessary to use LO-sharing to get a well
defined phase relation between the channels. Depending on your
frequency and bandwidth settings, it is possible to also achive this,
as all LOs are driven from a common 200 MHz reference clock.


Do you mean TwinRXes might have similar initial phase reset capability
that UBXes and SBXes have?

--
Best Regards,
Piotr Krysik



Best regards,
Fabian

Am 03.04.2019 um 12:05 schrieb Piotr Krysik via USRP-users:

Hi Fabian,

W dniu 03.04.2019 o 11:05, Fabian Schwartau via USRP-users pisze:

Hi Piotr,

we once had a very similar issue. But we also saw this on the same
frequency when switching between frequencies. Can you try this as
well? Just switch forth and back between two frequencies and just plot
one of them?

I'm not sure I understand correctly what you mean. You mean that the
result for a given frequency was not stable in your case across many
measurements? In our case this situation was repeating, but the
application doing the recording was restarted for each measurement.


As far as I remember the issue was because we were not using the
LO-Sharing. We were able to get everything running by using a C++
application and not gnuradio (I can see you are using python - which
is basically the same). There was a bug in gnuradio/python causing
this issue.
You can try to remove one of the LO-sharing cables while doing a
measurement and see if the phase suddenly starts to do crazy things
(the signal should also be lost). If that is not the case, you are not
actually using LO-sharing.


Do you know what this bug was exactly? GNU Radio didn't configure
LO-Sharing the way it was specified?

--
Best Regards,
Piotr Krysik



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

[Fabian Schwartau via USRP-users]

Hi,

yes, the result for multiple measurements (start ups of the system) at a 
single frequency was different by multiples of 90°.
We did not investigated the problem any further, but I am quite sure 
that gnuradio was not synchronizing the channels using the LO-sharing, 
although it was selected. So do the test I described. If you see that he 
is not using the LO-sharing, you know where to look further.
Keep in mind that it is not necessary to use LO-sharing to get a well 
defined phase relation between the channels. Depending on your frequency 
and bandwidth settings, it is possible to also achive this, as all LOs 
are driven from a common 200 MHz reference clock.


Best regards,
Fabian

Am 03.04.2019 um 12:05 schrieb Piotr Krysik via USRP-users:

Hi Fabian,

W dniu 03.04.2019 o 11:05, Fabian Schwartau via USRP-users pisze:

Hi Piotr,

we once had a very similar issue. But we also saw this on the same
frequency when switching between frequencies. Can you try this as
well? Just switch forth and back between two frequencies and just plot
one of them?


I'm not sure I understand correctly what you mean. You mean that the
result for a given frequency was not stable in your case across many
measurements? In our case this situation was repeating, but the
application doing the recording was restarted for each measurement.


As far as I remember the issue was because we were not using the
LO-Sharing. We were able to get everything running by using a C++
application and not gnuradio (I can see you are using python - which
is basically the same). There was a bug in gnuradio/python causing
this issue.
You can try to remove one of the LO-sharing cables while doing a
measurement and see if the phase suddenly starts to do crazy things
(the signal should also be lost). If that is not the case, you are not
actually using LO-sharing.


Do you know what this bug was exactly? GNU Radio didn't configure
LO-Sharing the way it was specified?

--
Best Regards,
Piotr Krysik


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

[Fabian Schwartau via USRP-users]

Hi Piotr,

we once had a very similar issue. But we also saw this on the same 
frequency when switching between frequencies. Can you try this as well? 
Just switch forth and back between two frequencies and just plot one of 
them?
As far as I remember the issue was because we were not using the 
LO-Sharing. We were able to get everything running by using a C++ 
application and not gnuradio (I can see you are using python - which is 
basically the same). There was a bug in gnuradio/python causing this issue.
You can try to remove one of the LO-sharing cables while doing a 
measurement and see if the phase suddenly starts to do crazy things (the 
signal should also be lost). If that is not the case, you are not 
actually using LO-sharing.


Best regards,
Fabian


Am 03.04.2019 um 10:40 schrieb Piotr Krysik via USRP-users:

W dniu 03.04.2019 o 10:34, Piotr Krysik via USRP-users pisze:

Hi all,

I'm trying to do calibration of phase offsets between TwinRX channels.

Configuration of X310 is following: two TwinRX'es, all sharing LOs from
fist channel of the second TwinRX.

The same signal is fed to all TwinRX channels through a RF splitter.

What is expected is some additional group delay for TwinRX that gets LO
signal through a cable from the other TwinRX.
This group delay was compensated by using longer RF cables between
splitter and RF inputs of TwinRX1 that uses external LOs from TwinRX2.

However, there is also unexpected effect: there are +/-90 degree phase
difference changes between channels of one TwinRX1 and TwinRX2 in
function of frequency.

Measurements were performed between 100MHz and 500MHz, and here are the
results:

1. 128MHz: +90 degrees
2. 172MHz: -90 degrees
3. 245MHz: +90 degrees
4. 260MHz: -90 degrees
5. 340MHz: +90 degrees

Here is example plot of phase difference fom channel 1 (TwinRX1) to
channels 2 and 3 (TwinRX2): https://imgur.com/4C09MSf
What I would expect (after compensation of LO cable length) was
something (~) flat, but there are these phase jumps by +/-90 degrees.

This effect can be included in calibration. But it would be best to
know: where these phase jumps for different frequencies come from?

Best Regards,
Piotr Krysik


The frequencies here are carrier frequencies that are being set for each
channel. On each carrier frequency measurement is performed - with use
of sine wave or noise signal. Sample rate was 2MS/s.

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Phase after Freq Hopping

[Fabian Schwartau via USRP-users]

Hi,

why do you need to know/define the absolute phase of the transmitted 
signal? Phase is always relative to something. When impleneting a radar, 
you transmit a signal with an unknwon (absolute) phase. But this is not 
a problem, because after reception you will somehow correlate the 
transmitted with the received signal. In FMCW for example you multiply 
both signals, and get only the relative phase between transmitted and 
received signal - and that is the only thing you are interested in. I 
don't know how this works in OFDM, but you probably have to correlate 
the transmitted with the received signal and this will reveal the 
relative phase between both signals.


Hope that helps,
Fabian

Am 18.03.2019 um 11:29 schrieb Patscheider, Dominik via USRP-users:

Hey,

What I wanted to achieve is a stepped OFDM Radar.
To increase the baseband for the radar, I´m splitting the subcarrier and 
transmit them on four center frequencies.
Thus it sends the first symbols on f0 (with an initial phase); afterwards 
increasing the center freq to f1 and transmit the next symbols,...
And obviously the initial phase is changing after reconfiguring the frequency. 
If phase1, phase5, phase9,... phase2,phase6,... isn´t the same, it´s not 
possible to measure any velocity.

Secondly, the time commands to change the freq I knew but didn´t use right now.

Hope this explanation was useful to understand me and thanks for helping :)

Dominik

-Ursprüngliche Nachricht-
Von: USRP-users  Im Auftrag von Piotr 
Krysik via USRP-users
Gesendet: Freitag, 15. März 2019 14:52
An: usrp-users@lists.ettus.com
Betreff: Re: [USRP-users] Phase after Freq Hopping

W dniu 12.03.2019 o 17:49, Patscheider, Dominik via USRP-users pisze:


Hello ,

  


For a Radar I´m transmitting and receiving with the USRP X310 samples
on different frequency steps.

  


For instance, after 4 frames I´m coming back to the first center freq
and continue this a few times. Hope the following description helps…

  


f3       |phase4|   |…|

f2      |phase3|   |…|

f1       |phase2|   |phase6|   …

f0    |phase1|   |phase5|

     t -->

According to the freq adjust every frame starts with a new phase.

Phase 1 ≠Phase 5

  


Is there any possibility to get the same phase after returning to the
same center freq? Phase 1=Phase 5, Phase 2 = Phase 6,…

  




Hi Dominik,

Can you describe what you want to achieve exactly? Probably you need to know 
phase relations because you want to do coherent processing of the signal. But 
from your description I don't know:
-why on your ASCII art the signals transmitted on different frequencies seems 
to be overlapped?
-which you part of it you want to process coherently?

I also often use USRPs for radar transmissions. Issues with predicting initial 
phase difference of the received signal, in relation to digital waveform that 
is being transmitted, are much easier to overcome when you use timed commands 
to set the frequencies on Rx and Tx side synchronously (if you use UBX or SBX 
daughter-boards).

Best Regards,
Piotr Krysik


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Frequency resolution of UBX-160 with integer N mode

[Fabian Schwartau via USRP-users]

Hi,

please double check on that, as I am not 100% sure.
As far as I was able to figure out, the LO is generated from the 
Daughterboard internal 200 MHz reference (which is dirived from the 10 
MHz), but is divided by 4 for some reason, so you get multiples of 50 
MHz. This will also induce a random 90° phase shift between the signals, 
which is a big problem for MIMO stuff.
At least the TwinRX boards we used were able to share the LO between 
multiple channels, which fixed the problem for us.


Best regards,
Fabian

Am 04.03.2019 um 17:23 schrieb Andreas Leuenberger via USRP-users:

Hello all,

I am using a USRP X310 with two daughter boards UBX-160 v2. To get a 
stable phase difference of the two daughter boards, I use the RX LOs in 
integer N mode ("mode_n=integer"). - I have noticed that the frequency 
step of the LO is 50 MHz. As the frequency of the reference signal is 10 
MHz, I would expect a step of 10 MHz.


Is there a way to reduce this frequency step?

Thanks for your help,
andreas


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Bug in timed switching of sample rate

[Fabian Schwartau via USRP-users]

Hi,
thanks for the update.
Where can I access the bugtracker to keep track on this issue? Or is it 
an internal one?

Is there a plan to implement this feature in the near future?

Best regards,
Fabian

Am 29.01.2019 um 16:11 schrieb Marcus D. Leech:

On 01/29/2019 09:23 AM, Fabian Schwartau via USRP-users wrote:

Hi Xavier,

sorry for the late answer. I missed your mail.
It might be related, but I don't know exactly. I am not a software 
expert and it is driving me crazy. In my case it seems like it makes 
no difference if I time the command or not, it is executed right away. 
As the record instruction is set in the future (after the timed sample 
rate switch), the recording fails to too few/many samples as the USRP 
switched the sample rate too early and messed up the record command.


Marcus also did not came back yet, so I am still stucked and I wrote a 
work-a-round to wait for all operations beeing finished before 
executing the sample rate switch. But this is quite bad, as I need a 
lot of time until I can send a new command with the changed sample 
rate. As I am continously switching frequency/sample rate and other 
parameters, waiting for the command buffer to be empty is currently 
cusuming most of the time and my switching rate is very limited.


Hope this can be fixed at some point.

Best regards,
Fabian
Based on the bugtracker data from R, making DDC/DUC rate changes 
(which is sample-rate changes) covered by timed commands is

   a pending feature.




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Bug in timed switching of sample rate

[Fabian Schwartau via USRP-users]

Hi Xavier,

sorry for the late answer. I missed your mail.
It might be related, but I don't know exactly. I am not a software 
expert and it is driving me crazy. In my case it seems like it makes no 
difference if I time the command or not, it is executed right away. As 
the record instruction is set in the future (after the timed sample rate 
switch), the recording fails to too few/many samples as the USRP 
switched the sample rate too early and messed up the record command.


Marcus also did not came back yet, so I am still stucked and I wrote a 
work-a-round to wait for all operations beeing finished before executing 
the sample rate switch. But this is quite bad, as I need a lot of time 
until I can send a new command with the changed sample rate. As I am 
continously switching frequency/sample rate and other parameters, 
waiting for the command buffer to be empty is currently cusuming most of 
the time and my switching rate is very limited.


Hope this can be fixed at some point.

Best regards,
Fabian

Am 03.12.2018 um 10:30 schrieb Xavier Arteaga via USRP-users:

Hi Fabian,
Could it be related with this issue 
<https://www.mail-archive.com/usrp-users@lists.ettus.com/msg06940.html> 
I came across too?


Have you tried an older version?

Regards,
Xavier

On Fri, 30 Nov 2018 at 18:56, Marcus D. Leech via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


On 11/30/2018 06:11 AM, Fabian Schwartau via USRP-users wrote:
 > Hi Marcus,
 >
 > is there any update?
 >
 > Best regards,
 > Fabian
Still being worked.

 >
 > Am 19.11.2018 um 20:22 schrieb Marcus D. Leech via USRP-users:
     >> On 11/19/2018 06:35 AM, Fabian Schwartau via USRP-users wrote:
 >>> Anyone? This is a quite annoying bug and I am having trouble
working
 >>> around it as I cannot meet my timing requirements.
 >> I'm only about 50% certain that sample-rate setting is covered by
 >> timed commands.  I'll talk to R and get back to you on this.
 >>
 >>
 >>>
 >>> Am 20.07.2018 um 11:05 schrieb Fabian Schwartau via USRP-users:
 >>>> Hello everyone,
 >>>>
 >>>> I am experencing some issues when switching the sample rate.
 >>>> I have two synchronized USRP X310 with a total of 4 TwinRX. I am
 >>>> doing timed commands to jump around in the spectrum with all
 >>>> receivers at the same frequency (SIMO stuff).
 >>>> I also need to switch sample rates in between. When I keep the
 >>>> sample rate constant, everything works fine, but once I switch it
 >>>> between two timed receptions, I get very strange errors. Like
I get
 >>>> an end-of-frame after just a part of the samples I requested.
 >>>> It seems like it is not possible to time the sample rate switch
 >>>> command. Here is a debug output of my code which makes it quite
 >>>> clear what happens:
 >>>>
 >>>> (1) Changed sample rate from 1e+07 to 5e+07
 >>>> (2) Requested 32768 Samples
 >>>> (3) Requested 32768 Samples
 >>>> (4) Requested 32768 Samples
 >>>> (5) Changed sample rate from 5e+07 to 1e+07
 >>>> (6) Reading 32768 Samples
 >>>> (7) Got only 6553 of 32768 samples at EOF
 >>>>
 >>>> Commands 1-5 are transmitted to the USRP right away using its
 >>>> command buffer. Then my program starts reading the first
requested
 >>>> 32768 but gets only 6553, which is precisely 1/5th of the
requested
 >>>> samples. I guess this is because he switched sample rate to 1/5th
 >>>> right before executing the first stream command. But the sample
 >>>> rate switch is also timed and should be executed after the three
 >>>> stream commands.
 >>>>
 >>>> I attached the part of the code which is responsible for sending
 >>>> the timed commands to the USRPs. This runs basically in a
while(1)
 >>>> in a seperate thread, while there is a seconds thread
receiving the
 >>>> data blocks, which produced the lines 6-7 of above output.
 >>>>
 >>>> Is this a bug or feature I don't get? Are set_rx_rate commands
not
 >>>> timed when using set_command_time? How can I solve this isse? I
 >>>> need very precise timing and also fast switching between
 >>>> frequencies and sample rates.
 >>>>
 >>>> Best regards,
 >>>> Fabian
 >>>>
   

Re: [USRP-users] twinrx example

[Fabian Schwartau via USRP-users]

Hi,

there is a file called twinrx_freq_hopping.cpp, which is using twinrx.

Best regards,
Fabian

Am 04.12.2018 um 06:28 schrieb Koyel Das (Vehere) via USRP-users:

Hi,


I am not finding an example to receive data for twinrx case of USRP 
x300/310.



I am looking at the following link:


https://github.com/EttusResearch/uhd/tree/master/host/examples





uhd/host/examples at master · EttusResearch/uhd · GitHub 


github.com
The USRP™ Hardware Driver Repository. Contribute to EttusResearch/uhd 
development by creating an account on GitHub.




Can someone please share the link of c++ code for receiving data from 
twinrx for x300/310?



Regards,

Koyel


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Bug in timed switching of sample rate

[Fabian Schwartau via USRP-users]

Hi Marcus,

is there any update?

Best regards,
Fabian

Am 19.11.2018 um 20:22 schrieb Marcus D. Leech via USRP-users:

On 11/19/2018 06:35 AM, Fabian Schwartau via USRP-users wrote:
Anyone? This is a quite annoying bug and I am having trouble working 
around it as I cannot meet my timing requirements.
I'm only about 50% certain that sample-rate setting is covered by timed 
commands.  I'll talk to R and get back to you on this.





Am 20.07.2018 um 11:05 schrieb Fabian Schwartau via USRP-users:

Hello everyone,

I am experencing some issues when switching the sample rate.
I have two synchronized USRP X310 with a total of 4 TwinRX. I am 
doing timed commands to jump around in the spectrum with all 
receivers at the same frequency (SIMO stuff).
I also need to switch sample rates in between. When I keep the sample 
rate constant, everything works fine, but once I switch it between 
two timed receptions, I get very strange errors. Like I get an 
end-of-frame after just a part of the samples I requested.
It seems like it is not possible to time the sample rate switch 
command. Here is a debug output of my code which makes it quite clear 
what happens:


(1) Changed sample rate from 1e+07 to 5e+07
(2) Requested 32768 Samples
(3) Requested 32768 Samples
(4) Requested 32768 Samples
(5) Changed sample rate from 5e+07 to 1e+07
(6) Reading 32768 Samples
(7) Got only 6553 of 32768 samples at EOF

Commands 1-5 are transmitted to the USRP right away using its command 
buffer. Then my program starts reading the first requested 32768 but 
gets only 6553, which is precisely 1/5th of the requested samples. I 
guess this is because he switched sample rate to 1/5th right before 
executing the first stream command. But the sample rate switch is 
also timed and should be executed after the three stream commands.


I attached the part of the code which is responsible for sending the 
timed commands to the USRPs. This runs basically in a while(1) in a 
seperate thread, while there is a seconds thread receiving the data 
blocks, which produced the lines 6-7 of above output.


Is this a bug or feature I don't get? Are set_rx_rate commands not 
timed when using set_command_time? How can I solve this isse? I need 
very precise timing and also fast switching between frequencies and 
sample rates.


Best regards,
Fabian

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Increasing X310 command buffer

[Fabian Schwartau via USRP-users]

Hello everyone,

is there a way to increase the number of timed commands the X310 can 
buffer at once? In the default firmware are only a few (can remember 
exactly, but I think like 5) commands in the queue at maximum which is 
not enough for my application. Or at least it would be much easier if 
the FPGA could hold like 10-20 commands.
I hope I just have to change some constant in the code, synthesize it 
and bring it on the FPGA.


Best regards,
Fabian

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Bug in timed switching of sample rate

[Fabian Schwartau via USRP-users]

Anyone? This is a quite annoying bug and I am having trouble working 
around it as I cannot meet my timing requirements.


Am 20.07.2018 um 11:05 schrieb Fabian Schwartau via USRP-users:

Hello everyone,

I am experencing some issues when switching the sample rate.
I have two synchronized USRP X310 with a total of 4 TwinRX. I am doing 
timed commands to jump around in the spectrum with all receivers at the 
same frequency (SIMO stuff).
I also need to switch sample rates in between. When I keep the sample 
rate constant, everything works fine, but once I switch it between two 
timed receptions, I get very strange errors. Like I get an end-of-frame 
after just a part of the samples I requested.
It seems like it is not possible to time the sample rate switch command. 
Here is a debug output of my code which makes it quite clear what happens:


(1) Changed sample rate from 1e+07 to 5e+07
(2) Requested 32768 Samples
(3) Requested 32768 Samples
(4) Requested 32768 Samples
(5) Changed sample rate from 5e+07 to 1e+07
(6) Reading 32768 Samples
(7) Got only 6553 of 32768 samples at EOF

Commands 1-5 are transmitted to the USRP right away using its command 
buffer. Then my program starts reading the first requested 32768 but 
gets only 6553, which is precisely 1/5th of the requested samples. I 
guess this is because he switched sample rate to 1/5th right before 
executing the first stream command. But the sample rate switch is also 
timed and should be executed after the three stream commands.


I attached the part of the code which is responsible for sending the 
timed commands to the USRPs. This runs basically in a while(1) in a 
seperate thread, while there is a seconds thread receiving the data 
blocks, which produced the lines 6-7 of above output.


Is this a bug or feature I don't get? Are set_rx_rate commands not timed 
when using set_command_time? How can I solve this isse? I need very 
precise timing and also fast switching between frequencies and sample 
rates.


Best regards,
Fabian

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Number of receivers at the same time USRP X-310

[Fabian Schwartau via USRP-users]

No, you have to use the TwinRX daughter boards for that. 

Am 13. November 2018 11:12:12 MEZ schrieb "Maria Jesus Cañavate Sanchez via 
USRP-users" :
>Hi all,
>
>My name is Maria and I have the USRP X-310, which has 4 ports, 2 Tx/Rx 
>and 2 Rx. I would like to ask if you can use the 4 ports as receivers
>at 
>the same time.
>
>Thank you very much in advance!
>
>Best regards,
>
>Maria Jesus
>
>
>___
>USRP-users mailing list
>USRP-users@lists.ettus.com
>http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] FM Spectrum Capture, to many zeros?

[Fabian Schwartau via USRP-users]

Hi,

the recv function has a return value which tells you the amount of
samples returned. Usually you use this value to increase your buffer
pointer and continue writing where you stopped.
You should also try to plot the data to see what is happening.
Hope that helps,

Fabian

Am 04.09.2018 um 17:27 schrieb Jeremy Foran:
> Thanks Fabian,
> 
> I have tried a few different values for timeout as per your
> recommendation and none seem to have an affect:
> 2.0
> 1.0
> 0.5
> 0.25
> 0.001
> 
> All have about the same result of ~50% of the samples contain a zero.
> 
> Ive also tried setting the sample sizes from fc32 to sc16 with more or
> less the same result.
> 
> What would be a normal amount of zeros to receive from a stream like
> this?  %1? %10?
> 
>> On Sep 4, 2018, at 11:11 AM, Fabian Schwartau via USRP-users
>> mailto:usrp-users@lists.ettus.com>> wrote:
>>
>> Hi,
>>
>> maybe your recv runs frequently into timeout. It is the 4th parameter
>> which is optional and set to a default value of 0.1 seconds.
>>
>> Best regards,
>>
>> Fabian
>>
>> Am 04.09.2018 um 16:56 schrieb Jeremy Foran via USRP-users:
>>> Hello All,
>>> I'm new to the community and excited to be a part of it.
>>> I am looking to capture the full FM spectrum for a couple of seconds,
>>> 88Mhz to 108Mhz, using the examples supplied by Ettus.  I seem to be
>>> getting more zeros in the results then I would have expected.  About
>>> half of the complex numbers will have a zero in it.  Is that normal?
>>>  Am I doing something wrong?  Code below:
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> using namespace std::chrono;
>>> static bool stop_signal_called = false;
>>> void sig_int_handler(int){stop_signal_called = true;}
>>> namespace po = boost::program_options;
>>> using namespace std;
>>> int UHD_SAFE_MAIN(int argc, char *argv[]){
>>>     uhd::set_thread_priority_safe();
>>>     //variables to be set by po
>>>     std::string args, file, ant, subdev, ref;
>>>     size_t total_num_samps;
>>>     double rate, freq, gain, bw, duration;
>>>     std::string addr, port;
>>>     uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
>>>     //Lock mboard clocks
>>>     usrp->set_clock_source("internal");
>>>     freq    = 98e6;
>>>     gain    = 2;
>>>     rate    = 1e6;
>>>     bw      = 20e6;
>>>     duration= 8;
>>>     //set the rx sample rate
>>>     usrp->set_rx_rate(rate);
>>>     uhd::tune_request_t tune_request(freq);
>>>     usrp->set_rx_freq(tune_request);
>>>     //set the rx rf gain
>>>     usrp->set_rx_gain(gain);
>>>     //set the analog frontend filter bandwidth
>>>     usrp->set_rx_bandwidth(bw);
>>>     //create a receive streamer
>>>     uhd::stream_args_t stream_args("fc32");
>>>     uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);
>>>     uhd::stream_cmd_t
>>> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
>>>     const size_t samps_per_buff = rx_stream->get_max_num_samps();
>>>     total_num_samps         = rate * duration;
>>>     stream_cmd.num_samps    = total_num_samps;
>>>     stream_cmd.stream_now   = true;
>>> //    int const buff_size     = rx_stream->get_max_num_samps();
>>>     rx_stream->issue_stream_cmd(stream_cmd);
>>>     uhd::rx_metadata_t md;
>>>     std::vector> buff(total_num_samps);
>>>     std::vector> sizeor(samps_per_buff);
>>>     const size_t size_of_buff = sizeor.size();
>>>     cout<<"Number of samples to capture: "<>>     //allow for some setup time
>>>     std::this_thread::sleep_for(std::chrono::seconds(2));
>>> 
>>>     cout<<"Starting Capture."<>>     milliseconds start_time_ms = duration_cast< milliseconds
>>>  >(system_clock::now().time_since_epoch());
>>>     int index=0;
>>>     while (!md.end_of_burst){
>>>         rx_stream->recv( [index * samps_per_buff], size_of_buff,
>>> md);
>>>         index++;
>>>     }
>>>     milliseconds end_t

Re: [USRP-users] FM Spectrum Capture, to many zeros?

[Fabian Schwartau via USRP-users]

Hi,

maybe your recv runs frequently into timeout. It is the 4th parameter 
which is optional and set to a default value of 0.1 seconds.


Best regards,

Fabian

Am 04.09.2018 um 16:56 schrieb Jeremy Foran via USRP-users:

Hello All,

I'm new to the community and excited to be a part of it.

I am looking to capture the full FM spectrum for a couple of seconds, 
88Mhz to 108Mhz, using the examples supplied by Ettus.  I seem to be 
getting more zeros in the results then I would have expected.  About 
half of the complex numbers will have a zero in it.  Is that normal?  Am 
I doing something wrong?  Code below:


#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

using namespace std::chrono;

static bool stop_signal_called = false;
void sig_int_handler(int){stop_signal_called = true;}

namespace po = boost::program_options;

using namespace std;

int UHD_SAFE_MAIN(int argc, char *argv[]){
     uhd::set_thread_priority_safe();
     //variables to be set by po
     std::string args, file, ant, subdev, ref;
     size_t total_num_samps;
     double rate, freq, gain, bw, duration;
     std::string addr, port;
     uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
     //Lock mboard clocks
     usrp->set_clock_source("internal");

     freq    = 98e6;
     gain    = 2;
     rate    = 1e6;
     bw      = 20e6;
     duration= 8;
     //set the rx sample rate
     usrp->set_rx_rate(rate);
     uhd::tune_request_t tune_request(freq);
     usrp->set_rx_freq(tune_request);
     //set the rx rf gain
     usrp->set_rx_gain(gain);

     //set the analog frontend filter bandwidth
     usrp->set_rx_bandwidth(bw);
     //create a receive streamer
     uhd::stream_args_t stream_args("fc32");
     uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);

     uhd::stream_cmd_t 
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);


     const size_t samps_per_buff = rx_stream->get_max_num_samps();
     total_num_samps         = rate * duration;
     stream_cmd.num_samps    = total_num_samps;
     stream_cmd.stream_now   = true;
//    int const buff_size     = rx_stream->get_max_num_samps();
     rx_stream->issue_stream_cmd(stream_cmd);
     uhd::rx_metadata_t md;

     std::vector> buff(total_num_samps);
     std::vector> sizeor(samps_per_buff);
     const size_t size_of_buff = sizeor.size();
     cout<<"Number of samples to capture: "< 


     cout<<"Starting Capture."<     milliseconds start_time_ms = duration_cast< milliseconds 
 >(system_clock::now().time_since_epoch());

     int index=0;
     while (!md.end_of_burst){
         rx_stream->recv( [index * samps_per_buff], size_of_buff, md);
         index++;
     }
     milliseconds end_time_ms = duration_cast< milliseconds 
 >(system_clock::now().time_since_epoch());

     cout<<"Ending Capture."< 


//    int x=1;
     int zero        = 0;
     int zero_all    = 0;
     int real        = 0;
     int imag        = 0;
     for (std::complex p: buff){
         if(p.real() == 0){real++;}
         if(p.imag() == 0){imag++;}
         if( (p.real()) == 0 && (p.imag() == 0) ){zero_all++;}
         if( (p.real()) == 0 || (p.imag() == 0) ){zero++;}
     }
     cout<<"Samps     : "<     cout<<"Total time: "

Re: [USRP-users] Latency between multiple daughter boards on one USRP X310

[Fabian Schwartau via USRP-users]

Hi Young,

I am not an expert, but I have three suggestions:
1) Using 'Unknown PSS' or any other sync method should not have no 
affect, as this is for syncing two or more USRPs. You have only one FPGA 
and that is in sync with itself ;)

2) Did you tried using timed commands? (see function set_command_time())
3) If that does not work, maybe the FPGA can handly only one command at 
a time - even if you tell him to execute two. Then it may be possible to 
start one command timed before the other and extend that sequence of 
samples with the correct amount of zeros.


Best regards,
Fabian

Am 30.07.2018 um 08:34 schrieb YoungC_Park via USRP-users:

Hi all,

I hope someone could help me on my situation. I could not find similar 
cases on the usrp archive.


I have one USRP X310 that has UBX-160(slot A) , LFTX board(slot B) and 
GPS module installed.


- my UHD is 3.11.0

- Using uhd API based on tx_samples from_file.cpp, I can generate dual 
output bursts from UBX160 and LFTX with 200MHz master clock and 100Msps 
on USRP X310.


- However, the second output (ch 1, red in the picture) is lagged from 
the first one (ch 0, yellow) by about (~10us with +-4us uncertainty)


- The baseband burst is a sawtooth waveform of two cycles(2000 samples 
long). and UBX160 modulates it into fc = 1GHz whereas LFTX generates it 
as is.


- This lagging is quite constant (10us) even if I change the sampling 
rate (10,20,50, 100MSps).


- Tried 'Unknown PPS', 'gpsdo', 'internal',,, but no difference.

- When I switch the order of channels to (1,0) as opposed to (0,1), then 
the ch0 lags behind the ch1, which seems that this is related to some 
sequenced process…


We are seeking for helps on the cause and cure about this lagging…

Thanks,

Young C. Park



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Bug in timed switching of sample rate

[Fabian Schwartau via USRP-users]

Hello everyone,

I am experencing some issues when switching the sample rate.
I have two synchronized USRP X310 with a total of 4 TwinRX. I am doing 
timed commands to jump around in the spectrum with all receivers at the 
same frequency (SIMO stuff).
I also need to switch sample rates in between. When I keep the sample 
rate constant, everything works fine, but once I switch it between two 
timed receptions, I get very strange errors. Like I get an end-of-frame 
after just a part of the samples I requested.
It seems like it is not possible to time the sample rate switch command. 
Here is a debug output of my code which makes it quite clear what happens:


(1) Changed sample rate from 1e+07 to 5e+07
(2) Requested 32768 Samples
(3) Requested 32768 Samples
(4) Requested 32768 Samples
(5) Changed sample rate from 5e+07 to 1e+07
(6) Reading 32768 Samples
(7) Got only 6553 of 32768 samples at EOF

Commands 1-5 are transmitted to the USRP right away using its command 
buffer. Then my program starts reading the first requested 32768 but 
gets only 6553, which is precisely 1/5th of the requested samples. I 
guess this is because he switched sample rate to 1/5th right before 
executing the first stream command. But the sample rate switch is also 
timed and should be executed after the three stream commands.


I attached the part of the code which is responsible for sending the 
timed commands to the USRPs. This runs basically in a while(1) in a 
seperate thread, while there is a seconds thread receiving the data 
blocks, which produced the lines 6-7 of above output.


Is this a bug or feature I don't get? Are set_rx_rate commands not timed 
when using set_command_time? How can I solve this isse? I need very 
precise timing and also fast switching between frequencies and sample rates.


Best regards,
Fabian
double freq;
if(!getNextCmdFrequency(freq))
{
firstTime = true;
return;
}
//qDebug()<<"Generating recv 
for"sampleRate)
{
double oldSampleRate = currentSampleRate;
currentSampleRate = receiveBlockList[currentCmdBlockListID]->sampleRate;
deviceConfig.sampleRate = currentSampleRate;
usrpDevice->set_rx_rate(currentSampleRate);
double newSampleRate = usrpDevice->get_rx_rate();
qDebug()<<"Changed sample rate 
from"samplesPerSlot;

ReceiveCmdTime receivecmdTime;
receivecmdTime.blockId = currentCmdBlockListID;
receivecmdTime.slotId = currentCmdSlotListID;
receivecmdTime.time = stream_cmd.time_spec.get_real_secs();
commandTimeMutex.lock();
commandTimeList.append(receivecmdTime);
commandTimeMutex.unlock();
rxStream->issue_stream_cmd(stream_cmd);

// Calcluate time for next slot
stream_cmd.time_spec += 
receiveBlockList[currentCmdBlockListID]->receiveTime + receive_stop_offset_ts;
currentRoundTime += receive_start_offset_ts + 
receiveBlockList[currentCmdBlockListID]->receiveTime + receive_stop_offset_ts;___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] X310 out of sync by 2 cycles

[Fabian Schwartau via USRP-users]

Hi everyone,

I am still working on the synchronization of my two USRP X310. Both get 
the same 10 MHz, 1 PPS and LO signals. I made a small piece of code to 
toggle one of the GPIOs at the Aux I/O of each USRP in a timed manner:


#define GPIOMASK   (1 << 4)
usrpDevice->set_gpio_attr("FP0", "CTRL", 0, GPIOMASK, 0);
usrpDevice->set_gpio_attr("FP0", "DDR", GPIOMASK, GPIOMASK, 0);
usrpDevice->set_gpio_attr("FP0", "CTRL", 0, GPIOMASK, 1);
usrpDevice->set_gpio_attr("FP0", "DDR", GPIOMASK, GPIOMASK, 1);
uhd::time_spec_t cmdTime = usrp->get_time_now() + uhd::time_spec_t(0.1);
while(1)
{
usrp->set_command_time(cmdTime);
usrpDevice->set_gpio_attr("FP0", "OUT", GPIOMASK, GPIOMASK, 0);
usrpDevice->set_gpio_attr("FP0", "OUT", GPIOMASK, GPIOMASK, 1);
cmdTime += uhd::time_spec_t(0.01);
usrp->set_command_time(cmdTime);
usrpDevice->set_gpio_attr("FP0", "OUT", 0, GPIOMASK, 0);
usrpDevice->set_gpio_attr("FP0", "OUT", 0, GPIOMASK, 1);
cmdTime += uhd::time_spec_t(0.01);
}

The code works just fine, and I can clearly see that the USRPs are not 
synchronized every time I start the program. Sometimes they are out of 
sync by 2 FPGA clock cycles (10 ns @ 200 MHz clock), plus or minus. So 
obiously the synchronization is not working properly.
I am using the set_time_unknown_pps() method, and I tried using my own 
signals for 1PPS and 10 MHz or use one of the USRPs as source.

Is this a known problem? Is there a workaround or solution?

Best regards,
Fabian

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Synchronized frequency hopping

[Fabian Schwartau via USRP-users]

Hi Derek,

I did what you suggested, but I have some synchroniziation issue between 
the two USRP. The four channels within each USRP are synchronized, but I 
get one out of three random phases between the two USRP at every start. 
Once initialized, the phases are constant.

My code for setting the frequency looks like this:

uhd::tune_request_t tune_request(frequency, 0e6);
tune_request.dsp_freq_policy = uhd::tune_request_t::POLICY_MANUAL;
tune_request.dsp_freq = 0.0;
for(int i=0; i<8; i++)
{
usrpDevice->set_rx_freq(tune_request, i);
}

Is that correct?

Am 04.06.2018 um 14:45 schrieb Derek Kozel:
You should use a tune_request_t to manually specify the DSP frequency. 
The issue is that only the master (LO source) channel knows about the 
actual frequency error in the LO and will automatically use the DDC to 
compensate for that error. The other channels must have the same 
correction applied manually.

http://files.ettus.com/manual/page_general.html#general_tuning

The GNU Radio UHD interface automatically does this. It is in Python, 
but the concept is fairly well illustrated.

https://github.com/gnuradio/gnuradio/blob/34f7e66e82079ef25b72ba6d6931fac05cfb968a/gr-uhd/apps/uhd_app.py#L219

Regards,
Derek

On Mon, Jun 4, 2018 at 1:14 PM, Fabian Schwartau via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Hi Derek,

I think I got that. Is the DDC frequency + offset aligned
automatically if I use a timed command for usrp->set_rx_freq()? Or
is there some other command I missed?

Best regards,
Fabian

Am 04.06.2018 um 13:20 schrieb Derek Kozel:

Fabian,

Timed commands, carefully and correctly used along with common
10 MHz and 1PPS, can give you time aligned reception with an
accuracy of one sample clock period. They are used by many
projects for this. To have repeatable phase relationships
between channels you must also use timed commands to set the DDC
frequency offset and decimation. This ensures that you have
exactly matching frequency on all channels and exactly the
number of samples produced on each stream so they stay inline.
With the TwinRX you must use LO sharing between all channels to
have repeatable phase offsets.

The LOs take approximately 5mS to settle on the TwinRX, so for
your application you can issue a tune command for time X, then a
stream command for X + 5mS.

https://github.com/EttusResearch/uhd/blob/maint/host/examples/twinrx_freq_hopping.cpp

<https://github.com/EttusResearch/uhd/blob/maint/host/examples/twinrx_freq_hopping.cpp>

Regards,
Derek

On Mon, Jun 4, 2018 at 11:47 AM, Fabian Schwartau via USRP-users
mailto:usrp-users@lists.ettus.com>
<mailto:usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>>> wrote:

     Hello Derek,
     thank you very much.
     So is it correct, that the timing using the set_comman_time()
     function is so precise that I can do MIMO with it? That
would be
     great :)

     Best regards,
     Fabian

     Am 04.06.2018 um 10:52 schrieb Derek Kozel:

         Hello Fabien,

         Yes, it is possible to queue commands, however there
are two
         important things to keep in mind. The commands will
block any
         other commands in the same queue from executing until the
         current one's time is reached. So commands must be sent
in order
         (100, then 120, 140 ...). Second, the queue has finite
length
         and if too many commands are sent it will backup into
the host.

         The TwinRX frequency hopping example will be a good
reference
         for you to look at. It implements a different strategy
where
         only one channel is used to receive and the second
channel is
         used as a secondary LO source, but its inner loop shows
how to
         use burst receiving and timed commands to have sample
accurate
         timing and do a precise sweep across a list of frequencies.

         Regards,
         Derek

         On Mon, Jun 4, 2018 at 8:40 AM, Fabian Schwartau via
USRP-users
         mailto:usrp-users@lists.ettus.com>
<mailto:usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>>
         <mailto:usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>

         <mailto:usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>>>> wrote:

              Hi,

              thanks for the great answer.

[USRP-users] Increase X310 buffer queue size

[Fabian Schwartau via USRP-users]

Hi everyone,

I am still having problems with the "late command" errors.
Is it possible to increase the number of commands an X310 can buffer? I 
need 5 commands to set a new frequency and start the stream, which means 
that I can only plan 3 commands ahead. This seems be be insufficient as 
some commands are too late. Even though I have an extra thread for just 
sending the commands.


Best regards,
Fabian

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] What is a burst?

[Fabian Schwartau via USRP-users]

Hi everyone,

short question: What is a burst in UHD?

I am talking about the flags start_of_burst and end_of_burst you get 
from revc in the meta data. I am using the STREM_MODE_NUM_SAMPS_AND_DONE 
mode and I thought that this is a burst. However, I displayed the two 
flags for each recv I executed and the end_of_burst is true on the end 
of each block of data I receive, however, the start_of_burst is always 
false.

Is that a bug or did I miss something?

Best regards,
Fabian

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Consequences of late command

[Fabian Schwartau via USRP-users]

Hi Darek,

I thought I solved this issue but it came up again.
From time to time I get the late command error. I get it when calling 
the revc method for the receive stream. In that moment there is no data 
returned from the call (return value is 0). I get these results a couple 
of times and after that the error code indicates timeout error and I get 
no more data - never. My program is stuck while waiting for the 
requested data to arrive.
If I understood corretly this should not be the case. I should get the 
data anyway, right?


Best regards,
Fabian

Am 07.06.2018 um 13:47 schrieb Derek Kozel:

Hello Fabian,

Commands which are late will be executed anyways and return the error 
notification which you are seeing. Commands after it are also executed. 
Depending on your application it is often possible to structure the 
commands such that get_time_now only needs to be called in the beginning 
and the act of receiving can be used to keep track of the device time. 
The TwinRX fast frequency hopping example does this, allowing for 
continuous and stable frequency hopping and burst receiving at a very 
high rate.


Regards,
Derek

On Thu, Jun 7, 2018 at 12:12 PM, Fabian Schwartau via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Hi everyone,

I am currently working with timed commands to perform synchronized
reception of multiple channels. As the timing is quite critilical I
would like to use quite low delay I add to usrp->get_time_now() for
the next command(s). However, sometimes it happens (even with quite
high values like 20ms) that I get an late command error when reading
the data from the stream. I guess this can happen from time to time
if the thread was interrupted by the OS to do other stuff. And this
is not a problem, if it happens just from time to time. But I don't
know how to handle the problem.
Is the command that was too late executed anyway? What about the
commands after that?
Is there is simple way to get in a clean state after receiving this
error? Like delete all commands in the queue and clear all buffers?

I am using two USRP X310 with each 2 TwinRX. PPS, 10 MHz and LOs are
synchronized over all boards.

Best regards,
Fabian

___
USRP-users mailing list
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Consequences of late command

[Fabian Schwartau via USRP-users]

Hi everyone,

I am currently working with timed commands to perform synchronized 
reception of multiple channels. As the timing is quite critilical I 
would like to use quite low delay I add to usrp->get_time_now() for the 
next command(s). However, sometimes it happens (even with quite high 
values like 20ms) that I get an late command error when reading the data 
from the stream. I guess this can happen from time to time if the thread 
was interrupted by the OS to do other stuff. And this is not a problem, 
if it happens just from time to time. But I don't know how to handle the 
problem.
Is the command that was too late executed anyway? What about the 
commands after that?
Is there is simple way to get in a clean state after receiving this 
error? Like delete all commands in the queue and clear all buffers?


I am using two USRP X310 with each 2 TwinRX. PPS, 10 MHz and LOs are 
synchronized over all boards.


Best regards,
Fabian

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Synchronized frequency hopping

[Fabian Schwartau via USRP-users]

Hi Derek,

I think I got that. Is the DDC frequency + offset aligned automatically 
if I use a timed command for usrp->set_rx_freq()? Or is there some other 
command I missed?


Best regards,
Fabian

Am 04.06.2018 um 13:20 schrieb Derek Kozel:

Fabian,

Timed commands, carefully and correctly used along with common 10 MHz 
and 1PPS, can give you time aligned reception with an accuracy of one 
sample clock period. They are used by many projects for this. To have 
repeatable phase relationships between channels you must also use timed 
commands to set the DDC frequency offset and decimation. This ensures 
that you have exactly matching frequency on all channels and exactly the 
number of samples produced on each stream so they stay inline. With the 
TwinRX you must use LO sharing between all channels to have repeatable 
phase offsets.


The LOs take approximately 5mS to settle on the TwinRX, so for your 
application you can issue a tune command for time X, then a stream 
command for X + 5mS.

https://github.com/EttusResearch/uhd/blob/maint/host/examples/twinrx_freq_hopping.cpp

Regards,
Derek

On Mon, Jun 4, 2018 at 11:47 AM, Fabian Schwartau via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Hello Derek,
thank you very much.
So is it correct, that the timing using the set_comman_time()
function is so precise that I can do MIMO with it? That would be
great :)

Best regards,
Fabian

Am 04.06.2018 um 10:52 schrieb Derek Kozel:

Hello Fabien,

Yes, it is possible to queue commands, however there are two
important things to keep in mind. The commands will block any
other commands in the same queue from executing until the
current one's time is reached. So commands must be sent in order
(100, then 120, 140 ...). Second, the queue has finite length
and if too many commands are sent it will backup into the host.

The TwinRX frequency hopping example will be a good reference
for you to look at. It implements a different strategy where
only one channel is used to receive and the second channel is
used as a secondary LO source, but its inner loop shows how to
use burst receiving and timed commands to have sample accurate
timing and do a precise sweep across a list of frequencies.

Regards,
Derek

On Mon, Jun 4, 2018 at 8:40 AM, Fabian Schwartau via USRP-users
mailto:usrp-users@lists.ettus.com>
<mailto:usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>>> wrote:

     Hi,

     thanks for the great answer.
     One more question: Is it possible to send multiple commands for
     different times right after each other? So for example if the
     current time is 100, I execute the code you provided for
120, 140
     and 160 at once without waiting for the command at 120 to
be executed.

     Best regards,
     Fabian


     Am 03.06.2018 um 12:44 schrieb Marcus Müller:

         Hello Fabian,

         the issue can be overcome using what we call timed
commands – simply
         tell your USRP to tune that LO at time X, and it'll do
exactly that!

         A bit of example code:

         //we will tune the frontends in 500ms from now
         uhd::time_spec_t cmd_time = usrp->get_time_now() +
         uhd::time_spec_t(0.5);

         //sets command time on all devices
         //the next commands are all timed
         usrp->set_command_time(cmd_time);

         //tune channel 0 and channel 1
         usrp->set_rx_freq(1.03e9, 0); // Channel 0
         usrp->set_rx_freq(1.03e9, 1); // Channel 1

         //end timed commands
         usrp->clear_command_time();

         You can also instruct the RX streamer to start
streaming at a
         specific
         time, so that you either know beforehand, at which
sample count the
         tuning happened.
         Alternatively, the rx_metadata coming from the USRP
contains
         timestamps
            of the first sample in the sample packet, so you can
use that to
         calculate at which sample the tuning happens.

         Best regards,
         Marcus

         On Sun, 2018-06-03 at 11:35 +0200, Fabian Schwartau via
USRP-users
         wrote:

             Hello everyone,

             I have a question about frequency hopping in a
synchronized
             scenario.
             I
             have two USRP X310, each equipped with two TwinRX.
The LOs are
             generated
           

Re: [USRP-users] Synchronized frequency hopping

[Fabian Schwartau via USRP-users]

Hi,

thanks for the great answer.
One more question: Is it possible to send multiple commands for 
different times right after each other? So for example if the current 
time is 100, I execute the code you provided for 120, 140 and 160 at 
once without waiting for the command at 120 to be executed.


Best regards,
Fabian

Am 03.06.2018 um 12:44 schrieb Marcus Müller:

Hello Fabian,

the issue can be overcome using what we call timed commands – simply
tell your USRP to tune that LO at time X, and it'll do exactly that!

A bit of example code:

//we will tune the frontends in 500ms from now
uhd::time_spec_t cmd_time = usrp->get_time_now() +
uhd::time_spec_t(0.5);

//sets command time on all devices
//the next commands are all timed
usrp->set_command_time(cmd_time);

//tune channel 0 and channel 1
usrp->set_rx_freq(1.03e9, 0); // Channel 0
usrp->set_rx_freq(1.03e9, 1); // Channel 1

//end timed commands
usrp->clear_command_time();

You can also instruct the RX streamer to start streaming at a specific
time, so that you either know beforehand, at which sample count the
tuning happened.
Alternatively, the rx_metadata coming from the USRP contains timestamps
  of the first sample in the sample packet, so you can use that to
calculate at which sample the tuning happens.

Best regards,
Marcus

On Sun, 2018-06-03 at 11:35 +0200, Fabian Schwartau via USRP-users
wrote:

Hello everyone,

I have a question about frequency hopping in a synchronized scenario.
I
have two USRP X310, each equipped with two TwinRX. The LOs are
generated
by one of the TwinRX and are distributed to all the others (even
across
the two motherboards). 10 MHz and 1PPS are also coming from a single
source. Then I use the "unknown PPS" method to sync the ADCs. This
works
perfectly.
Now I listen to a single frequency on all channels and change this
frequency frequently. I would like to hop the frequency every 20ms or
faster. In order not to loose the ADC synchronization, I start a
continuous stream and switch the frequency while receiving. This
works
in principle, but I am not able to identify at which frequency the
data
that currently comes in was recorded. I tried using a constant time
from
setting the new frequency to when I assume the new data to be at the
new
frequency. But even with a timeout of ~50ms the results in data
indicate
the the delay was not enough in a very few cases.
I know there is the locked_lo sensor, but this also does not help. I
guess this is caused by buffers which cause a more or less random
delay
between setting the frequency and receiving the data. This depends on
CPU load and other things, so it is quite random.
Is there a way to solve this issue? E.g. by embedding information
about
the LO state in the data. Or defining an exact time when to execute
the
frequency switch, so that I can use the metadata timestamp in the
receive stream to identify the exact point when the frequency was
switched (I know that the locking can take a few ms - so I would
discard
the data between the switch and the signalling+locking offset). Or is
it
possible to perform multiple time limited captures without having to
sync the ADCs again?
In an ideal situation I would like the FPGA to switch frequency, wait
for LOs to lock, take a single shot synchronized measurement (~1ms of
data), transmit the data to the PC (I am using 10G link) and continue
with the next frequency. Is that possible without touching the FPGA
code?

Best regards,
Fabian

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Synchronized frequency hopping

[Fabian Schwartau via USRP-users]

Hello everyone,

I have a question about frequency hopping in a synchronized scenario. I
have two USRP X310, each equipped with two TwinRX. The LOs are generated
by one of the TwinRX and are distributed to all the others (even across
the two motherboards). 10 MHz and 1PPS are also coming from a single
source. Then I use the "unknown PPS" method to sync the ADCs. This works
perfectly.
Now I listen to a single frequency on all channels and change this
frequency frequently. I would like to hop the frequency every 20ms or
faster. In order not to loose the ADC synchronization, I start a
continuous stream and switch the frequency while receiving. This works
in principle, but I am not able to identify at which frequency the data
that currently comes in was recorded. I tried using a constant time from
setting the new frequency to when I assume the new data to be at the new
frequency. But even with a timeout of ~50ms the results in data indicate
the the delay was not enough in a very few cases.
I know there is the locked_lo sensor, but this also does not help. I
guess this is caused by buffers which cause a more or less random delay
between setting the frequency and receiving the data. This depends on
CPU load and other things, so it is quite random.
Is there a way to solve this issue? E.g. by embedding information about
the LO state in the data. Or defining an exact time when to execute the
frequency switch, so that I can use the metadata timestamp in the
receive stream to identify the exact point when the frequency was
switched (I know that the locking can take a few ms - so I would discard
the data between the switch and the signalling+locking offset). Or is it
possible to perform multiple time limited captures without having to
sync the ADCs again?
In an ideal situation I would like the FPGA to switch frequency, wait
for LOs to lock, take a single shot synchronized measurement (~1ms of
data), transmit the data to the PC (I am using 10G link) and continue
with the next frequency. Is that possible without touching the FPGA code?

Best regards,
Fabian

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] IF filtering of X310

[Fabian Schwartau via USRP-users]

Hi Derek,

so you are basically saying that I should not see any or just little 
aliasing?


Best regards,
Fabian Schwartau

Am 15.02.2018 um 17:54 schrieb Derek Kozel:

Hello Fabian,

The set_rx_bandwidth() function does not work with the TwinRX. If the 
value returned by get_rx_bandwidth is changing then that is a bug which 
I will look into. It is used for the B2xx and E3xx series, as well as 
the brand new N310, which have RFICs with programmable bandpass filters.


The TwinRX gets two channels of 100 MS/s complex samples by running the 
ADCs at 200 MS/s real value sampling and doing a conversion to half rate 
complex with appropriate filtering. Yes, there is a digital frequency 
shift of + or - 50 MHz (equivalent to 150 MHz) to bring the final IF to 
baseband and correct for mirroring caused by the various mixing 
possibilities.


The DDC contains a set of halfband filters and a CIC filter. This is 
described in detail in the manual. The DDC will appropriately filter for 
its decimation factor.

http://files.ettus.com/manual/page_general.html#general_sampleratenotes

Regards,
Derek

On Thu, Feb 15, 2018 at 1:40 PM, Fabian S. via USRP-users 
> wrote:



Hi everyone,

I am currently working with the X310 and two TwinRX daugerboards and
have a problem understanding the processing done in the FPGA.
As far as I understood the TwinRX works as a super-het and has the
second (ADC) IF at 150 MHz with 80 MHz bandwidth (according to the
block diagram in the schematics). The ADC of the X310 runs at 200
Msps, so it is working with undersampling I guess?
Now I am missing a block diagram of what is happening in the FPGA.
My guess is that he will mix the ADC signal with a complex sine-wave
so that the 150 MHz will be at zero -> exp(-j*2*pi*150MHz*t). After
that there has to be some sort of filtering and downsampling. But
which exactly? According to the warning message I get depending on
the sample rate I set, I guess there are multiple half-band filters
and an CIC filter which are used in different combinations to get
the required sample rate. Is there somewhere a block diagram and
rules for that?
Now to my main problem: I get a lot of aliasing. For example I have
set my sample rate to 10e6, I can tune my generator several times
the bandwidth above the center frequency and will still see it with
barely any atenuation.
Additionally I noticed setting the RX bandwidth has no effect. Even
if I set it to a very low value (100kHz) at 10Msps, I see no effect.
Do I have to implement the digital filters my own using RFNoC? What
is the set_rx_bandwidth() function good for? I know there are board
which do not support this function but as far as I understood then
the board will report the currently used bandwidth when calling
get_rx_bandwidth() - mine always reports the value I set.

Best regards,

Fabian


___
USRP-users mailing list
USRP-users@lists.ettus.com 
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com





--
--
M.-Sc. Fabian Schwartau
Technische Universität Braunschweig
Institut für Hochfrequenztechnik
Schleinitzstr. 22
38106 Braunschweig
Germany

Tel.:   +49-(0)531-391-2017
Fax:+49-(0)531-391-2045
Email:  fabian.schwar...@ihf.tu-bs.de
WWW:http://www.tu-braunschweig.de/ihf
--

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com