d 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. Somet
, 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
mail
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 ev
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-us
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++ appli
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 t
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 aft
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
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
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
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&D is aware, and they'
> 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?
>
>
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
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
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
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
/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
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
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/EttusResear
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
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
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 USR
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,
>>
>> we
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
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
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
sens
-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
n 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
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
ime, 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 origina
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
/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:
It says 0.
I guess that is not good.
Any further ideas?
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
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- rtprio99
# End of file
fschwa@rfserv
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 eve
rysik 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:
(...)
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
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
L
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
transmitt
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 ran
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
ttus.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,
&
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:
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
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
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
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 rece
.
>
> 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
>> mai
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
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_co
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.
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
o/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 comm
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
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 execut
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_
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
valu
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-us
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>> wrote:
Hi,
thanks for the great answer.
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
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 sin
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 chan
63 matches
Mail list logo
