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?

[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

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?

[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

Re: [USRP-users] B205 PPS Sync

[Guillermo Gancio via USRP-users]

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 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;
> UHD_003.010.003.HEAD-0-gef157678
> >
> > Thanks!
> I would update to a newer UHD, but also I think you have a logic error
> in your code that causes the start time to be in the past--
>you sleep for 1.5 seconds after setting the USRP time to zero, which
> means that there's some possibility that when you ask for
>an absolute time of 2 on the stream command, that time has already
> passed.
>
>
> >
> > // Set up of the B2xx
> > board-
> >  // Create USRP
> >  uhd_usrp_handle usrp;
> >  fprintf(stderr, "Creating USRP with args \"%s\"...\n", device_args);
> >  EXECUTE_OR_GOTO(free_option_strings,
> >  uhd_usrp_make(&usrp, device_args)
> >  )
> >
> >  // Create RX streamer
> >  uhd_rx_streamer_handle rx_streamer;
> >  EXECUTE_OR_GOTO(free_usrp,
> >  uhd_rx_streamer_make(&rx_streamer)
> >  )
> >
> >  // Create RX metadata
> >  uhd_rx_metadata_handle md;
> >  EXECUTE_OR_GOTO(free_rx_streamer,
> >  uhd_rx_metadata_make(&md)
> >  )
> >
> >  // Create other necessary structs
> >  uhd_tune_request_t tune_request = {
> >  .target_freq = freq,
> >  .rf_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO,
> >  .dsp_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO,
> >  };
> >  uhd_tune_result_t tune_result;
> >  uhd_stream_args_t stream_args = {
> >  .cpu_format = "sc16",  //sc16
> >  .otw_format = "sc8",   //sc8
> >  .args = "",
> >  .channel_list = &channel,
> >  .n_channels = 0
> >  };
> > // Set rate
> >  fprintf(stderr, "Setting RX Rate: %f...\n", rate);
> >  EXECUTE_OR_GOTO(free_rx_metadata,
> >  uhd_usrp_set_rx_rate(usrp, rate, channel)
> >  )
> >
> >  // See what rate actually is
> >  EXECUTE_OR_GOTO(free_rx_metadata,
> >  uhd_usrp_get_rx_rate(usrp, channel, &rate)
> >  )
> >  fprintf(stderr, "Actual RX Rate: %f...\n", rate);
> >
> >  // Set gain
> >  fprintf(stderr, "Setting RX Gain: %f dB...\n", gain);
> >  EXECUTE_OR_GOTO(free_rx_metadata,
> >  uhd_usrp_set_rx_gain(usrp, gain, channel, "")
> >  )
> >
> >  // See what gain actually is
> >  EXECUTE_OR_GOTO(free_rx_metadata,
> >  uhd_usrp_get_rx_gain(usrp, channel, "", &gain)
> >  )
> >  fprintf(stderr, "Actual RX Gain: %f...\n", gain);
> >
> >
> >  // Set frequency
> >  fprintf(stderr, "Setting RX frequency: %f MHz...\n", freq/1e6);
> >  EXECUTE_OR_GOTO(free_rx_metadata,
> >  uhd_usrp_set_rx_freq(usrp, &tune_request, channel, &tune_result)
> >  )
> >
> >  // See what frequency actually is
> >  EXECUTE_OR_GOTO(free_rx_metadata,
> >  uhd_usrp_get_rx_freq(usrp, channel, &freq)
> >  )
> > int64_t aux_secs=0,aux_secs_loop=0;
> > double aux_frac_secs=0.0;
> > uhd_rx_metadata_error_code_t error_code;
> >  if(use_PPS)
> >  {
> >  printf("Using PPS\n");
> >  EXECUTE_OR_GOTO(free_rx_metadata,
> >  uhd_usrp_set_time_source(usrp, "external",channel)
> >  )
> >  sleep(0.25);
> >  EXECUTE_OR_GOTO(free_rx_metadata,
> >  uhd_usrp_set_clock_source(usrp, "internal",channel)
> >  )
> >  sleep(1.5);
> >  EXECUTE_OR_GOTO(free_rx_metadata,
> >  uhd_usrp_get_time_last_pps(usrp, channel,
> > &aux_secs,&aux_frac_secs)
> >  )
> >  printf("Get Last PPS.%d -
> > %f\n",(int)aux_secs,aux_frac_secs);
> >  do{
> >  EXECUTE_OR_GOTO(free_rx_metadata,
> >  uhd_usrp_get_time_last_pps(usrp, channel,
> > &aux_secs_loop,&aux_frac_secs)
> >  )
> >  sleep(0.25);
> >  }while(aux_secs==aux_secs_loop);
> >  sleep(1.5);
> >  EXECUTE_OR_GOTO(free_rx_metadata,
> >  uhd_usrp_set_time_next_pps(usrp,0,0.0,channel)
> >  )
> >  sleep(1.5);
> >  }
> >  EXECUTE_OR_GOTO(free_rx_metadata,
> >  uhd_usrp_get_time_now(usrp, channel,
> > &aux_secs_loop,&aux_frac_secs)
> >  )
> >  

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

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

[Brian Padalino via USRP-users]

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, 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

Re: [USRP-users] No UHD devices found.

[Marcus D. Leech via USRP-users]

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 "http://www.nav.ei.tum.de/index.php?id=105"; has just 
told me the following:


"Besides the example binaries the installer should also have build a
"uhd_find_devices.exe". This is a small program that comes with the UHD
driver and will search for any USRP and show it. If that program also
does not find your USRP, write to the USRP mailing list and explain them
that you have a USRP connected, but the uhd_find_devices binary does not
find it. That is a 100% USRP/UHD problem. It has nothing to do with
MEX/Matlab or anything else. "

I attach a screenshot to point the same.

Now, so, following his advice, i receive the error, in command prompt, 
the following:


"No UHD devices found"

I attach a screenshot of that error too.

What might be happening?

Just for everyone's information, i have installed(only, not built and 
all) the UHD version 3.10.2, and this can also be seen from the 
screenshot.


Thanks a lot,
Vinayak Anant Karandikar


What is the address of your USRP?  Does the host IP configuration 
correspond to the USRP address?


If you ping the USRP at the default address, does that work?




___
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

[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

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

[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

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

[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

Re: [USRP-users] B205 PPS Sync

[Marcus D. Leech via USRP-users]

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; UHD_003.010.003.HEAD-0-gef157678

Thanks!
I would update to a newer UHD, but also I think you have a logic error 
in your code that causes the start time to be in the past--
  you sleep for 1.5 seconds after setting the USRP time to zero, which 
means that there's some possibility that when you ask for
  an absolute time of 2 on the stream command, that time has already 
passed.





// Set up of the B2xx
board-
 // Create USRP
 uhd_usrp_handle usrp;
 fprintf(stderr, "Creating USRP with args \"%s\"...\n", device_args);
 EXECUTE_OR_GOTO(free_option_strings,
 uhd_usrp_make(&usrp, device_args)
 )

 // Create RX streamer
 uhd_rx_streamer_handle rx_streamer;
 EXECUTE_OR_GOTO(free_usrp,
 uhd_rx_streamer_make(&rx_streamer)
 )

 // Create RX metadata
 uhd_rx_metadata_handle md;
 EXECUTE_OR_GOTO(free_rx_streamer,
 uhd_rx_metadata_make(&md)
 )

 // Create other necessary structs
 uhd_tune_request_t tune_request = {
 .target_freq = freq,
 .rf_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO,
 .dsp_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO,
 };
 uhd_tune_result_t tune_result;
 uhd_stream_args_t stream_args = {
 .cpu_format = "sc16",  //sc16
 .otw_format = "sc8",   //sc8
 .args = "",
 .channel_list = &channel,
 .n_channels = 0
 };
// Set rate
 fprintf(stderr, "Setting RX Rate: %f...\n", rate);
 EXECUTE_OR_GOTO(free_rx_metadata,
 uhd_usrp_set_rx_rate(usrp, rate, channel)
 )

 // See what rate actually is
 EXECUTE_OR_GOTO(free_rx_metadata,
 uhd_usrp_get_rx_rate(usrp, channel, &rate)
 )
 fprintf(stderr, "Actual RX Rate: %f...\n", rate);

 // Set gain
 fprintf(stderr, "Setting RX Gain: %f dB...\n", gain);
 EXECUTE_OR_GOTO(free_rx_metadata,
 uhd_usrp_set_rx_gain(usrp, gain, channel, "")
 )

 // See what gain actually is
 EXECUTE_OR_GOTO(free_rx_metadata,
 uhd_usrp_get_rx_gain(usrp, channel, "", &gain)
 )
 fprintf(stderr, "Actual RX Gain: %f...\n", gain);


 // Set frequency
 fprintf(stderr, "Setting RX frequency: %f MHz...\n", freq/1e6);
 EXECUTE_OR_GOTO(free_rx_metadata,
 uhd_usrp_set_rx_freq(usrp, &tune_request, channel, &tune_result)
 )

 // See what frequency actually is
 EXECUTE_OR_GOTO(free_rx_metadata,
 uhd_usrp_get_rx_freq(usrp, channel, &freq)
 )
int64_t aux_secs=0,aux_secs_loop=0;
double aux_frac_secs=0.0;
uhd_rx_metadata_error_code_t error_code;
 if(use_PPS)
 {
 printf("Using PPS\n");
 EXECUTE_OR_GOTO(free_rx_metadata,
 uhd_usrp_set_time_source(usrp, "external",channel)
 )
 sleep(0.25);
 EXECUTE_OR_GOTO(free_rx_metadata,
 uhd_usrp_set_clock_source(usrp, "internal",channel)
 )
 sleep(1.5);
 EXECUTE_OR_GOTO(free_rx_metadata,
 uhd_usrp_get_time_last_pps(usrp, channel,
&aux_secs,&aux_frac_secs)
 )
 printf("Get Last PPS.%d -
%f\n",(int)aux_secs,aux_frac_secs);
 do{
 EXECUTE_OR_GOTO(free_rx_metadata,
 uhd_usrp_get_time_last_pps(usrp, channel,
&aux_secs_loop,&aux_frac_secs)
 )
 sleep(0.25);
 }while(aux_secs==aux_secs_loop);
 sleep(1.5);
 EXECUTE_OR_GOTO(free_rx_metadata,
 uhd_usrp_set_time_next_pps(usrp,0,0.0,channel)
 )
 sleep(1.5);
 }
 EXECUTE_OR_GOTO(free_rx_metadata,
 uhd_usrp_get_time_now(usrp, channel,
&aux_secs_loop,&aux_frac_secs)
 )
 printf("Get Time NOW.%d -
%f\n",(int)aux_secs_loop,aux_frac_secs);
 // Set up buffer
 samps_per_buff_2=samps_per_buff;
 EXECUTE_OR_GOTO(free_rx_streamer,
 uhd_rx_streamer_max_num_samps(rx_streamer, &samps_per_buff_2)
 )

 uhd_stream_cmd_tstream_cmd = {
 .stream_mode = UHD_STREAM_MODE_START_CONTINUOUS,
 .num_samps = 0,
 .stream_now = false,
 .time_spec_full_secs = 2
 };

 EXECUTE_OR_GOTO(free_rx_streamer,
 uhd_usrp_get_rx_stream(usrp, &stream_args, rx_streamer)
 )

 EXECUTE_OR_GOTO(free_buffer,
 uhd_rx_streamer_issue_stream_cmd(rx_streamer, &stream_cmd)
 )
// Ettus B2xx Read loop
for(loop_samps=0;loop_samps) escribió:

On

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

Re: [USRP-users] ValueError: recv_buff_size must be larger than the recv_frame_size.

[Jason Matusiak via USRP-users]

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 e3xx-rfnoc.
> Now when I try to run any rfnoc flow-chart on the e310, I get the following
> error:
>
> ValueError: recv_buff_size must be larger than the recv_frame_size.
>
> Even if I just take an rfnoc: radio block and connect it directly to a qt
> time sink, I get:
>
> Initializing block control (NOC ID: 0x5B888C918ACDF7F3)
> thread[thread-per-block[0]: ]: ValueError:
> recv_buff_size must be larger than the recv_frame_size.
>
> Has anyone run into this before? Where are these buffer and frame sizes
> set?
>
> Thanks,
> Andrew
>

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

Re: [USRP-users] RFNoC has no attribute E312

[Jason Matusiak via USRP-users]

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 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 seem 
to be ignored).

But if I use the bitfile in my flowgraph it starts to set stuff up and then 
crashes with this error:
AttributeError: 'module' object has no attribute 'vustomBlock'

Why did it see it with the probe, but not with the flowgraph?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] GRCon19 Registration Open

[Ben Hilburn via USRP-users]

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 registration period, which ends on May
1st.

The conference is being held at the Huntsville Marriott at the Space &
Rocket Center in Huntsville, Alabama, from September 16th - September 20th.
More info about the conference can be found on the homepage, here: GRCon19
.

*Submissions*
The deadline for submissions is July 1st. As in previous years, there are
three types of submissions:

   - Talks: Presented during the conference program.
   - Poster: Presented during the several poster sessions.
   - Paper: Published in the GRCon Technical Proceedings
   

Please remember that you do *not* need to present in order to publish, nor
do you need to publish in order to present. We do encourage you to do both,
but do not require it.

To make a submission, please use the following portal. Authors will be
notified of acceptance in early July. Peer reviews of talks and papers are
conducted using a double-blind process. If you submit a paper draft and are
accepted, the camera-ready date will be in late August.

https://openconf.org/GRCon19/openconf.php

*Sponsors*
GRCon is only possible every year thanks to our sponsors! Importantly,
remaining funds from the conference are put back into the project, directly
funding the efforts of the GNU Radio community. If you are interested in
learning more about sponsoring, please reach out to the organizing
committee: gr...@gnuradio.org

*See you in Rocket City!*
If you have any questions, please don't hesitate to get in touch with the
conferencing organizers, whom you can reach using gr...@gnuradio.org.

Cheers,
The GRCon Team
___
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

[Tillson, Bob (US) via USRP-users]

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] RFNoC has no attribute E312

[Jason Matusiak via USRP-users]

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 seem 
to be ignored).

But if I use the bitfile in my flowgraph it starts to set stuff up and then 
crashes with this error:
AttributeError: 'module' object has no attribute 'vustomBlock'

Why did it see it with the probe, but not with the flowgraph?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] N310 MPMD link speed warnings

[Rob Kossler via USRP-users]

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
determine the link speed?  Note that even though the warning mentions 1GbE,
the max speed shown greatly exceeds 1GbE and in fact I am able to stream a
full rates despite the warning.
Rob

Details:
- Ubuntu 16.04 LTS
- Host NIC: Intel XL710 with single-mode optical transceiver
- USRP SFP+ transceiver: Fiberstore SFP-10GLR-31
- UHD version: (see below)


$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_3.15.0.git-89-gf93c5227
[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=192.168.60.2,type=n3xx,product=n310,serial=3144673,claimed=False,addr=192.168.60.2
[INFO] [MPM.PeriphManager] init() called with device args
`mgmt_addr=192.168.60.2,product=n310'.
[WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
12500
[WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
12500
[WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
12500
[WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
12500
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D004)
[WARNING] [0/DmaFIFO_0] Non-critical minor compat number mismatch for
`noc_shell': Expecting 5.1, got 5.0.
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1355 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1340 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1356 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1354 MB/s)
[WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
12500
[WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
12500
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312)
[WARNING] [0/Radio_0] Non-critical minor compat number mismatch for
`noc_shell': Expecting 5.1, got 5.0.
[WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
12500
[WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
12500
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312)
[WARNING] [0/Radio_1] Non-critical minor compat number mismatch for
`noc_shell': Expecting 5.1, got 5.0.
[WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
12500
[WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
12500
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
[WARNING] [0/DDC_0] Non-critical minor compat number mismatch for
`noc_shell': Expecting 5.1, got 5.0.
[WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
12500
[WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
12500
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
[WARNING] [0/DDC_1] Non-critical minor compat number mismatch for
`noc_shell': Expecting 5.1, got 5.0.
[WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
12500
[WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
12500
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
[WARNING] [0/DUC_0] Non-critical minor compat number mismatch for
`noc_shell': Expecting 5.1, got 5.0.
[WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
12500
[WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
12500
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2)
[WARNING] [0/DUC_1] Non-critical minor compat number mismatch for
`noc_shell': Expecting 5.1, got 5.0.
  _
 /
|   Device: N300-Series Device
| _
|/
|   |   Mboard: ni-n3xx-3144673
|   |   eeprom_version: 1
|   |   pid: 16962
|   |   product: n310
|   |   rev: 3
|   |   rpc_connection: remote
|   |   serial: 3144673
|   |   type: n3xx
|   |   MPM Version: 1.2
|   |   FPGA Version: 5.3
|   |   FPGA git hash: UNKNOWN
|   |   RFNoC capable: Yes
___
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] Adjusting VCTCXO of B210 with use of AD9361 DAC output

[Piotr Krysik via USRP-users]

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. It's probably not worth the effort to
create some circuit that will amplify that DAC output - especially every
user would have to do this as well.

USRP B200mini looks much more appealing in comparison. Just checked the
schematics and it has separate DAC connected to the FPGA, intended for
controlling VCTCXO. I need to learn how to control it.

--
Best Regards,
Piotr Krysik

___
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]

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