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
Hi all -
This is a reminder that registration for the 9th Annual GNU Radio
Conference is open! You can purchase your registration here:
https://tickets.gnuradio.org/grcon19/
Student pricing is also available through the same registration link. Note
that we are still in the discounted
Whoops. Realized it was a swig issue. Once I fixed the problem it was fine
again. Hopefully this helps someone else in the future.
From: Jason Matusiak
Sent: Tuesday, April 23, 2019 10:29 AM
To: Ettus Mail List
Subject: RFNoC has no attribute E312
OK, I am
I know this is an older thread, but I am running up against the same issue. Do
you know if you were able to get past it?
Thanks
On Wed, Aug 22, 2018 at 11:12 AM, Andrew Danowitz <
and...@whitefoxdefense.com> wrote:
> Hi,
>
> I rebuilt everything using the latest recipes for rfnoc and
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
OK, I am missing something simple here that I am just overlooking. I have a
particular bitfile that when I do a probe on my E312 using it and its
associated UHD/GR/etc, it runs OK and shows me my RFNoC blocks (it actuall
shows an EnvironmentError: IOError on the radio, but usually those things
Hi,
I am getting a bunch of "Could not determine link speed" warnings when I
run with an N310. Note that I don't get these warnings with an X310 (in
the same setup). Below, you will find the output from "uhd_usrp_probe" for
the N310. Is there any setting that I need to change so that MPMD can
W dniu 22.04.2019 o 18:17, Sylvain Munaut pisze:
> Hi Piotr,
>
> The main issue is that the AUX DAC output swing is between 0.5v and 1V
> (i.e. VDD_GPO-0.3v).
> That's not the right range at all to control the VCXO meaningfully.
>
> Cheers,
>
> Sylvain
>
Thanks Sylvain for the answer.
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
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-
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
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
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
On Tue, Apr 23, 2019 at 2:06 PM Fabian Schwartau via USRP-users <
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,
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
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;
On 04/23/2019 07:35 AM, Guillermo Gancio wrote:
Thanks Marcus for the answer and your time,
This is the part of the code with all the configurationsthe rest
is too messy to share I think..and its based in rx_samples_c.c
The UHD version is...
linux; GNU C++ version 4.8.4; Boost_105400;
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
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,
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
On 04/23/2019 02:02 PM, VINAYAK KARANDIKAR via USRP-users wrote:
Hello everyone,
I have been trying to figure out for a
while why my USRP NI 2954R is not getting detected by the 64 bit ASUS
Laptop with Windows 10 as the OS.
Martin Lulf at
Thanks Marcus,
You are right I misunderstood the concept, I thought that they where
absolute seconds...
After correcting that plus a little other detail it seems to be working
Thanks for your help.
>From Android Device
El mar., abr. 23, 2019 12:23, Marcus D. Leech
escribió:
> On
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,
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
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,
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"
:
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:
27 matches
Mail list logo
