[USRP-users] packet size in uhd_rx_streamer_recv

[Sivan Toledo via USRP-users]

I have a code that has been running fine for several years. It
calls uhd_rx_streamer_recv and expects the same # of packets as in the
first call, which is typically 2044 samples.

I am porting the code now to an NVDIA Jeston TX2 platform (the CPU is
64-bit multicore ARM) and I am getting a lot of cases where I get shorter
packets, 651 samples.

This is with a B210.

Is there something I can do to get it to deliver the same # samples in
every packet (this will keep my code simple) or do I have to expect UHD to
deliver a variable # of samples per packet?

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

Re: [USRP-users] uhd_usrp_set_time_next_pps problems on B200

[Sivan Toledo via USRP-users]

Seems like we are getting closer.

The code I use to set the time source is
uhd_usrp_set_clock_source(usrp, "external", ALL_MBOARDS);
uhd_usrp_set_time_source(usrp, "_external_", ALL_MBOARDS);

Maybe it should not be _external_ by "external" without the "_"s? At least
on N200 _external_ works. I don't remember where I got the string, maybe
from reading the UHD sources or from the UHD documentation (this was a few
years ago).

Regarding the ref_locked: no, I am not using the external reference input
but the GPSDO. So I will remove the test on this in my code. On N200 it
seems okay to test because I think there it tests whether the PLL is locked
to whatever clock source is selected. Is that right?

Thanks, Sivan

On Thu, Jan 3, 2019 at 8:29 PM Marcus D. Leech 
wrote:

> On 01/03/2019 08:53 AM, Sivan Toledo wrote:
>
> Hundreds of milliseconds, which I think imply that either the PPS is
> arriving at a random time (not likely), or that the function that sets the
> time at the next PPS actually sets it immediately.
>
> The only thing i can think of is a setup error.  Like not actually
> requesting the time source be set to "external" for the B200 case.
>
>
> Otherwise your assumptions about my setting is correct, an N200 and a B200
> each with its own Ettus GPSDO.
>
> I also noticed another thing that is strange, but maybe not the cause of
> my problem; the ref_locked sensor returns false on the B200 (even after I
> do all the procedure to set the clock at the next PPS) but true on the
> N200. Maybe the B200 simply does not have that hardware feature to check?
> Or does this indicates a problem?
>
> I think on the B200 "ref locked" refers to the external front-panel
> reference in.   BTW if you are using the external REF-IN on a B200/B210
>   you have to remove the internal GPSDO, due to electrical cross-talk on
> the REF lines.
>
>
>
> On Wed, Jan 2, 2019 at 7:53 PM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 01/02/2019 05:37 AM, Sivan Toledo via USRP-users wrote:
>> > Hi,
>> >
>> > I have a code that reads the GPS time and sets the time on the next
>> > PPS using uhd_usrp_set_time_next_pps. The code is based on advice from
>> > Ettus (we wait for PPS, wait 200ms, read the time, repeat 3 times, and
>> > then set the time correctly for the next PPS after checking that there
>> > are at least 200ms left in the second) and it works fine on N200 with
>> > GPSDO.
>> >
>> > The same code causes trouble on B200 with the TCXO based GPSDO. The
>> > GPS seems fine and we get a fix, and the code works fine, but the
>> > clocks are not synchronized with those of N200s.
>> >
>> > Is there a known problem with this function on N200s?
>> >
>> > Thanks, Sivan Toledo
>> >
>> Just to clarify the picture here, you have an N200 and a B200, each with
>> their own GPSDO.  You're trying your best to synchronize them
>>using the PPS pulse from their respective GPSDOS?
>>
>> What scale is the lack-of-synchronization?  Are we talking nanosecond,
>> microsecond, millisecond?
>>
>>
>>
>> ___
>> 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] uhd_usrp_set_time_next_pps problems on B200

[Sivan Toledo via USRP-users]

Hundreds of milliseconds, which I think imply that either the PPS is
arriving at a random time (not likely), or that the function that sets the
time at the next PPS actually sets it immediately.

Otherwise your assumptions about my setting is correct, an N200 and a B200
each with its own Ettus GPSDO.

I also noticed another thing that is strange, but maybe not the cause of my
problem; the ref_locked sensor returns false on the B200 (even after I do
all the procedure to set the clock at the next PPS) but true on the N200.
Maybe the B200 simply does not have that hardware feature to check? Or does
this indicates a problem?

On Wed, Jan 2, 2019 at 7:53 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 01/02/2019 05:37 AM, Sivan Toledo via USRP-users wrote:
> > Hi,
> >
> > I have a code that reads the GPS time and sets the time on the next
> > PPS using uhd_usrp_set_time_next_pps. The code is based on advice from
> > Ettus (we wait for PPS, wait 200ms, read the time, repeat 3 times, and
> > then set the time correctly for the next PPS after checking that there
> > are at least 200ms left in the second) and it works fine on N200 with
> > GPSDO.
> >
> > The same code causes trouble on B200 with the TCXO based GPSDO. The
> > GPS seems fine and we get a fix, and the code works fine, but the
> > clocks are not synchronized with those of N200s.
> >
> > Is there a known problem with this function on N200s?
> >
> > Thanks, Sivan Toledo
> >
> Just to clarify the picture here, you have an N200 and a B200, each with
> their own GPSDO.  You're trying your best to synchronize them
>using the PPS pulse from their respective GPSDOS?
>
> What scale is the lack-of-synchronization?  Are we talking nanosecond,
> microsecond, millisecond?
>
>
>
> ___
> 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] uhd_usrp_set_time_next_pps problems on B200

[Sivan Toledo via USRP-users]

Hi,

I have a code that reads the GPS time and sets the time on the next PPS
using uhd_usrp_set_time_next_pps. The code is based on advice from Ettus
(we wait for PPS, wait 200ms, read the time, repeat 3 times, and then set
the time correctly for the next PPS after checking that there are at least
200ms left in the second) and it works fine on N200 with GPSDO.

The same code causes trouble on B200 with the TCXO based GPSDO. The GPS
seems fine and we get a fix, and the code works fine, but the clocks are
not synchronized with those of N200s.

Is there a known problem with this function on N200s?

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

Re: [USRP-users] C API call in Windows fails with no last_error

[Sivan Toledo via USRP-users]

I think I resolved it; must specify num_samps in the struct (as 0) even if
you want to stream continuously.

On Tue, Nov 7, 2017 at 1:21 PM, Sivan Toledo  wrote:

> Before this code runs, the TX antenna is set to TX/RX, the RX antenna to
> RX2. The radio is a B200.
>
> On Tue, Nov 7, 2017 at 1:18 PM, Sivan Toledo  wrote:
>
>> A bit of progress. The error_string might have been used by two threads,
>> so I allocated a new buffer for error messages in the thread that starts
>> streaming and receives samples. This revealed the error message: TX/RX.
>> What is is error?
>>
>> On Tue, Nov 7, 2017 at 1:06 PM, Sivan Toledo  wrote:
>>
>>> Hi,
>>>
>>> I've ported a code from the C++ API to the C API; it runs okay on Linux
>>> but fails on Windows. The failure occurs at the function:
>>>
>>> void radioRxStartStreaming(void) {
>>>   uhd_stream_cmd_t stream_cmd;
>>>
>>>   size_t n;
>>>   uhd_rx_streamer_max_num_samps(rx_stream, &n);
>>>   fprintf(stderr,"### UHD max samples %d ###\n",n);
>>>
>>>   fprintf(stderr,"### starting rx streaming ###\n");
>>>
>>>   stream_cmd.stream_mode = UHD_STREAM_MODE_START_CONTINUOUS;
>>>   stream_cmd.stream_now = true;
>>>
>>>   if (uhd_rx_streamer_issue_stream_cmd(rx_stream, &stream_cmd)) {
>>> uhd_rx_streamer_last_error(rx_stream, error_string,
>>> ERROR_STRING_LENGTH);
>>> fprintf(stderr,"### cannot start UHD rx streamer: <%s>
>>> ###\n",error_string);
>>>   } else {
>>> fprintf(stderr,"### started rx streaming ###\n");
>>>   }
>>> }
>>>
>>> issue_stream_command fails but last_error returns an empty string.
>>> The functions uhd_rx_streamer_make(&rx_stream) and
>>> uhd_usrp_get_rx_stream(usrp, &stream_args, rx_stream) are called prior to
>>> the attempt to start the stream, but from another thread. I am using
>>> pthreads in both Linux and Windows (using a pthreads library) and have not
>>> had a problem with this with the C++ API.
>>>
>>> I'm using UHD 3.9.7, installed from uhd_3.9.7-release_Win64_VS2013.exe
>>> .
>>> The code is linked against visual studio 12.0 (which I think is VS2013)
>>>
>>> Any idea what might be going wrong? It's difficult to debug when the
>>> error message is empty.
>>>
>>> Thanks, Sivan
>>>
>>>
>>>
>>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] C API call in Windows fails with no last_error

[Sivan Toledo via USRP-users]

More progress: there is no error message but the error code is 40 (
UHD_ERROR_ASSERTION

=
40)

On Tue, Nov 7, 2017 at 1:18 PM, Sivan Toledo  wrote:

> A bit of progress. The error_string might have been used by two threads,
> so I allocated a new buffer for error messages in the thread that starts
> streaming and receives samples. This revealed the error message: TX/RX.
> What is is error?
>
> On Tue, Nov 7, 2017 at 1:06 PM, Sivan Toledo  wrote:
>
>> Hi,
>>
>> I've ported a code from the C++ API to the C API; it runs okay on Linux
>> but fails on Windows. The failure occurs at the function:
>>
>> void radioRxStartStreaming(void) {
>>   uhd_stream_cmd_t stream_cmd;
>>
>>   size_t n;
>>   uhd_rx_streamer_max_num_samps(rx_stream, &n);
>>   fprintf(stderr,"### UHD max samples %d ###\n",n);
>>
>>   fprintf(stderr,"### starting rx streaming ###\n");
>>
>>   stream_cmd.stream_mode = UHD_STREAM_MODE_START_CONTINUOUS;
>>   stream_cmd.stream_now = true;
>>
>>   if (uhd_rx_streamer_issue_stream_cmd(rx_stream, &stream_cmd)) {
>> uhd_rx_streamer_last_error(rx_stream, error_string,
>> ERROR_STRING_LENGTH);
>> fprintf(stderr,"### cannot start UHD rx streamer: <%s>
>> ###\n",error_string);
>>   } else {
>> fprintf(stderr,"### started rx streaming ###\n");
>>   }
>> }
>>
>> issue_stream_command fails but last_error returns an empty string.
>> The functions uhd_rx_streamer_make(&rx_stream) and
>> uhd_usrp_get_rx_stream(usrp, &stream_args, rx_stream) are called prior to
>> the attempt to start the stream, but from another thread. I am using
>> pthreads in both Linux and Windows (using a pthreads library) and have not
>> had a problem with this with the C++ API.
>>
>> I'm using UHD 3.9.7, installed from uhd_3.9.7-release_Win64_VS2013.exe
>> .
>> The code is linked against visual studio 12.0 (which I think is VS2013)
>>
>> Any idea what might be going wrong? It's difficult to debug when the
>> error message is empty.
>>
>> Thanks, Sivan
>>
>>
>>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] C API call in Windows fails with no last_error

[Sivan Toledo via USRP-users]

I made a mistake; the error message from last_error is empty, even if I use
a dedicated buffer for it. The TX/RX was a leftover from the antenna query.

But the question still stands: issue_stream_cmd in the C api on Windows
still fails with no explanation message on a B200.

On Tue, Nov 7, 2017 at 1:18 PM, Sivan Toledo  wrote:

> A bit of progress. The error_string might have been used by two threads,
> so I allocated a new buffer for error messages in the thread that starts
> streaming and receives samples. This revealed the error message: TX/RX.
> What is is error?
>
> On Tue, Nov 7, 2017 at 1:06 PM, Sivan Toledo  wrote:
>
>> Hi,
>>
>> I've ported a code from the C++ API to the C API; it runs okay on Linux
>> but fails on Windows. The failure occurs at the function:
>>
>> void radioRxStartStreaming(void) {
>>   uhd_stream_cmd_t stream_cmd;
>>
>>   size_t n;
>>   uhd_rx_streamer_max_num_samps(rx_stream, &n);
>>   fprintf(stderr,"### UHD max samples %d ###\n",n);
>>
>>   fprintf(stderr,"### starting rx streaming ###\n");
>>
>>   stream_cmd.stream_mode = UHD_STREAM_MODE_START_CONTINUOUS;
>>   stream_cmd.stream_now = true;
>>
>>   if (uhd_rx_streamer_issue_stream_cmd(rx_stream, &stream_cmd)) {
>> uhd_rx_streamer_last_error(rx_stream, error_string,
>> ERROR_STRING_LENGTH);
>> fprintf(stderr,"### cannot start UHD rx streamer: <%s>
>> ###\n",error_string);
>>   } else {
>> fprintf(stderr,"### started rx streaming ###\n");
>>   }
>> }
>>
>> issue_stream_command fails but last_error returns an empty string.
>> The functions uhd_rx_streamer_make(&rx_stream) and
>> uhd_usrp_get_rx_stream(usrp, &stream_args, rx_stream) are called prior to
>> the attempt to start the stream, but from another thread. I am using
>> pthreads in both Linux and Windows (using a pthreads library) and have not
>> had a problem with this with the C++ API.
>>
>> I'm using UHD 3.9.7, installed from uhd_3.9.7-release_Win64_VS2013.exe
>> .
>> The code is linked against visual studio 12.0 (which I think is VS2013)
>>
>> Any idea what might be going wrong? It's difficult to debug when the
>> error message is empty.
>>
>> Thanks, Sivan
>>
>>
>>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] C API call in Windows fails with no last_error

[Sivan Toledo via USRP-users]

Before this code runs, the TX antenna is set to TX/RX, the RX antenna to
RX2. The radio is a B200.

On Tue, Nov 7, 2017 at 1:18 PM, Sivan Toledo  wrote:

> A bit of progress. The error_string might have been used by two threads,
> so I allocated a new buffer for error messages in the thread that starts
> streaming and receives samples. This revealed the error message: TX/RX.
> What is is error?
>
> On Tue, Nov 7, 2017 at 1:06 PM, Sivan Toledo  wrote:
>
>> Hi,
>>
>> I've ported a code from the C++ API to the C API; it runs okay on Linux
>> but fails on Windows. The failure occurs at the function:
>>
>> void radioRxStartStreaming(void) {
>>   uhd_stream_cmd_t stream_cmd;
>>
>>   size_t n;
>>   uhd_rx_streamer_max_num_samps(rx_stream, &n);
>>   fprintf(stderr,"### UHD max samples %d ###\n",n);
>>
>>   fprintf(stderr,"### starting rx streaming ###\n");
>>
>>   stream_cmd.stream_mode = UHD_STREAM_MODE_START_CONTINUOUS;
>>   stream_cmd.stream_now = true;
>>
>>   if (uhd_rx_streamer_issue_stream_cmd(rx_stream, &stream_cmd)) {
>> uhd_rx_streamer_last_error(rx_stream, error_string,
>> ERROR_STRING_LENGTH);
>> fprintf(stderr,"### cannot start UHD rx streamer: <%s>
>> ###\n",error_string);
>>   } else {
>> fprintf(stderr,"### started rx streaming ###\n");
>>   }
>> }
>>
>> issue_stream_command fails but last_error returns an empty string.
>> The functions uhd_rx_streamer_make(&rx_stream) and
>> uhd_usrp_get_rx_stream(usrp, &stream_args, rx_stream) are called prior to
>> the attempt to start the stream, but from another thread. I am using
>> pthreads in both Linux and Windows (using a pthreads library) and have not
>> had a problem with this with the C++ API.
>>
>> I'm using UHD 3.9.7, installed from uhd_3.9.7-release_Win64_VS2013.exe
>> .
>> The code is linked against visual studio 12.0 (which I think is VS2013)
>>
>> Any idea what might be going wrong? It's difficult to debug when the
>> error message is empty.
>>
>> Thanks, Sivan
>>
>>
>>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] C API call in Windows fails with no last_error

[Sivan Toledo via USRP-users]

A bit of progress. The error_string might have been used by two threads, so
I allocated a new buffer for error messages in the thread that starts
streaming and receives samples. This revealed the error message: TX/RX.
What is is error?

On Tue, Nov 7, 2017 at 1:06 PM, Sivan Toledo  wrote:

> Hi,
>
> I've ported a code from the C++ API to the C API; it runs okay on Linux
> but fails on Windows. The failure occurs at the function:
>
> void radioRxStartStreaming(void) {
>   uhd_stream_cmd_t stream_cmd;
>
>   size_t n;
>   uhd_rx_streamer_max_num_samps(rx_stream, &n);
>   fprintf(stderr,"### UHD max samples %d ###\n",n);
>
>   fprintf(stderr,"### starting rx streaming ###\n");
>
>   stream_cmd.stream_mode = UHD_STREAM_MODE_START_CONTINUOUS;
>   stream_cmd.stream_now = true;
>
>   if (uhd_rx_streamer_issue_stream_cmd(rx_stream, &stream_cmd)) {
> uhd_rx_streamer_last_error(rx_stream, error_string,
> ERROR_STRING_LENGTH);
> fprintf(stderr,"### cannot start UHD rx streamer: <%s>
> ###\n",error_string);
>   } else {
> fprintf(stderr,"### started rx streaming ###\n");
>   }
> }
>
> issue_stream_command fails but last_error returns an empty string.
> The functions uhd_rx_streamer_make(&rx_stream) and
> uhd_usrp_get_rx_stream(usrp, &stream_args, rx_stream) are called prior to
> the attempt to start the stream, but from another thread. I am using
> pthreads in both Linux and Windows (using a pthreads library) and have not
> had a problem with this with the C++ API.
>
> I'm using UHD 3.9.7, installed from uhd_3.9.7-release_Win64_VS2013.exe
> .
> The code is linked against visual studio 12.0 (which I think is VS2013)
>
> Any idea what might be going wrong? It's difficult to debug when the error
> message is empty.
>
> Thanks, Sivan
>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] C API call in Windows fails with no last_error

[Sivan Toledo via USRP-users]

Hi,

I've ported a code from the C++ API to the C API; it runs okay on Linux but
fails on Windows. The failure occurs at the function:

void radioRxStartStreaming(void) {
  uhd_stream_cmd_t stream_cmd;

  size_t n;
  uhd_rx_streamer_max_num_samps(rx_stream, &n);
  fprintf(stderr,"### UHD max samples %d ###\n",n);

  fprintf(stderr,"### starting rx streaming ###\n");

  stream_cmd.stream_mode = UHD_STREAM_MODE_START_CONTINUOUS;
  stream_cmd.stream_now = true;

  if (uhd_rx_streamer_issue_stream_cmd(rx_stream, &stream_cmd)) {
uhd_rx_streamer_last_error(rx_stream, error_string,
ERROR_STRING_LENGTH);
fprintf(stderr,"### cannot start UHD rx streamer: <%s>
###\n",error_string);
  } else {
fprintf(stderr,"### started rx streaming ###\n");
  }
}

issue_stream_command fails but last_error returns an empty string.
The functions uhd_rx_streamer_make(&rx_stream) and
uhd_usrp_get_rx_stream(usrp, &stream_args, rx_stream) are called prior to
the attempt to start the stream, but from another thread. I am using
pthreads in both Linux and Windows (using a pthreads library) and have not
had a problem with this with the C++ API.

I'm using UHD 3.9.7, installed from uhd_3.9.7-release_Win64_VS2013.exe
.
The code is linked against visual studio 12.0 (which I think is VS2013)

Any idea what might be going wrong? It's difficult to debug when the error
message is empty.

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

Re: [USRP-users] ֻC API questions

[Sivan Toledo via USRP-users]

Thanks Marcus.

The dependency of UHD on boost is not an issue; if they are both installed
from Ubuntu packages, they link without a problem. The problem was that my
code, compiled on one machine, did not link (wrong .so files) with a
different version of boost. I think that I can fix that in my C++ client by
removing the depenency on boost in my code.

This still leaves another binary compatibility problem that I encountered,
that gcc in different versions of Ubuntu generates different symbols for
C++ functions, causing linking problems when an .so file from one version
of Ubuntu is used on another version.

Hopefully the move to the C API will resolve the second problem. The first
is indeed easier to solve.

On Sun, Jul 16, 2017 at 12:31 PM, Marcus Müller 
wrote:

> Hello Sivan Toledo,
>
> I'm sorry I'm a bit late to react, but:
>
> since UHD internally still uses Boost, I'm a little afraid that using the
> C API is not a good solution here
> Best regards,
> Marcus
>
> On 07/15/2017 12:46 PM, Sivan Toledo via USRP-users wrote:
>
> I'm converting a CPP code from UHD 3.8.5 to the C api for 3.10. (The main
> reason for the conversion is that I binaries of my CPP programs don't run
> on both Ubuntu 14 and 16 because of incompatible libboost; hopefully using
> the C API and the Ubuntu uhd-host package will resolve this).
>
> I have a few questions:
>
> 1. Is the following correct, or do I have to "make" the
> string_vector_handle before I pass it to get_rx_gain_names? The manual says
> to always make, but my intuition is that get_rx_gain_names will make it for
> me, given that it gets a pointer to the handle, not the handle itself.
>
>   uhd_string_vector_handle gain_names;
>   uhd_usrp_get_rx_gain_names(usrp, 0 /* channel */, &gain_names);
>
> 2. Is there a C api version of set_rx_gain
> <https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a8234968ad1fefef299ef9541cc193915>
>  (double
> gain, size_t chan=0)? In the header files I found only set_rx_gain but
> with a gain_name argument. The CPP api has two overloaded methods, one with
> a gain-name argument and the other without it. Is the convenience method
> missing from the C API? Can I invoke it by passing NULL for the gain name?
>
> Thanks, Sivan Toledo
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://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] ֻC API questions

[Sivan Toledo via USRP-users]

OK, tried it and I clearly need to call the "make" functions, otherwise the
code segfaults.

On Sat, Jul 15, 2017 at 7:02 PM, Sivan Toledo  wrote:

> Like question 1:
>
> Do I need to "make" the uhd_meta_range_handle or will the call
> to uhd_usrp_get_rx_gain_range make it?
>
> If I need to make it, I assume that I also need to free it.
> If I don't need to make it, do I still need to free it?
>
> On Sat, Jul 15, 2017 at 1:46 PM, Sivan Toledo  wrote:
>
>> I'm converting a CPP code from UHD 3.8.5 to the C api for 3.10. (The main
>> reason for the conversion is that I binaries of my CPP programs don't run
>> on both Ubuntu 14 and 16 because of incompatible libboost; hopefully using
>> the C API and the Ubuntu uhd-host package will resolve this).
>>
>> I have a few questions:
>>
>> 1. Is the following correct, or do I have to "make" the
>> string_vector_handle before I pass it to get_rx_gain_names? The manual says
>> to always make, but my intuition is that get_rx_gain_names will make it for
>> me, given that it gets a pointer to the handle, not the handle itself.
>>
>>   uhd_string_vector_handle gain_names;
>>   uhd_usrp_get_rx_gain_names(usrp, 0 /* channel */, &gain_names);
>>
>> 2. Is there a C api version of set_rx_gain
>> 
>>  (double
>> gain, size_t chan=0)? In the header files I found only set_rx_gain but
>> with a gain_name argument. The CPP api has two overloaded methods, one with
>> a gain-name argument and the other without it. Is the convenience method
>> missing from the C API? Can I invoke it by passing NULL for the gain name?
>>
>> Thanks, Sivan Toledo
>>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] ֻC API questions

[Sivan Toledo via USRP-users]

Like question 1:

Do I need to "make" the uhd_meta_range_handle or will the call
to uhd_usrp_get_rx_gain_range make it?

If I need to make it, I assume that I also need to free it.
If I don't need to make it, do I still need to free it?

On Sat, Jul 15, 2017 at 1:46 PM, Sivan Toledo  wrote:

> I'm converting a CPP code from UHD 3.8.5 to the C api for 3.10. (The main
> reason for the conversion is that I binaries of my CPP programs don't run
> on both Ubuntu 14 and 16 because of incompatible libboost; hopefully using
> the C API and the Ubuntu uhd-host package will resolve this).
>
> I have a few questions:
>
> 1. Is the following correct, or do I have to "make" the
> string_vector_handle before I pass it to get_rx_gain_names? The manual says
> to always make, but my intuition is that get_rx_gain_names will make it for
> me, given that it gets a pointer to the handle, not the handle itself.
>
>   uhd_string_vector_handle gain_names;
>   uhd_usrp_get_rx_gain_names(usrp, 0 /* channel */, &gain_names);
>
> 2. Is there a C api version of set_rx_gain
> 
>  (double
> gain, size_t chan=0)? In the header files I found only set_rx_gain but
> with a gain_name argument. The CPP api has two overloaded methods, one with
> a gain-name argument and the other without it. Is the convenience method
> missing from the C API? Can I invoke it by passing NULL for the gain name?
>
> Thanks, Sivan Toledo
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] ֻC API questions

[Sivan Toledo via USRP-users]

I'm converting a CPP code from UHD 3.8.5 to the C api for 3.10. (The main
reason for the conversion is that I binaries of my CPP programs don't run
on both Ubuntu 14 and 16 because of incompatible libboost; hopefully using
the C API and the Ubuntu uhd-host package will resolve this).

I have a few questions:

1. Is the following correct, or do I have to "make" the
string_vector_handle before I pass it to get_rx_gain_names? The manual says
to always make, but my intuition is that get_rx_gain_names will make it for
me, given that it gets a pointer to the handle, not the handle itself.

  uhd_string_vector_handle gain_names;
  uhd_usrp_get_rx_gain_names(usrp, 0 /* channel */, &gain_names);

2. Is there a C api version of set_rx_gain

(double
gain, size_t chan=0)? In the header files I found only set_rx_gain but with
a gain_name argument. The CPP api has two overloaded methods, one with a
gain-name argument and the other without it. Is the convenience method
missing from the C API? Can I invoke it by passing NULL for the gain name?

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

Re: [USRP-users] Input power limit for B2x0 series

[Sivan Toledo via USRP-users]

Thanks Marcus!

The 0dBm limit is much easier to work with than the -15. I indeed can add a
3 or 6dB attenuator to ensure that this is the case. Thanks a lot for the
clarification regarding U800 and U813.

I don't mind sharing the frequency band and the details of the receive
chain.

We operate at 434MHz, we use an LNA with a gain of 17dB and noise figure of
0.5dB, then a cable (up to 50m of LMR400), then a 6dBm limiter and a saw
filter with about 3dB insertion loss. I guess that an attenuator will not
have a dramatic influence on the noise figure.

To Dan and others: The LNA is a high linearity LNA which automatically
implies that it can generate a lot of power (about 1/4W); that's where my
concern comes from.

Sivan


On Sun, Jul 9, 2017 at 11:55 AM, Marcus Müller via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Sivan,
>
> to add to what Dan already said: You're right, the -15 dBm limit is a bit
> overzealous (though I really must stress it's better to be safe than sorry
> on that side).
>
> We're actually in the process of relaxing the limits we're stating for
> this; compare [1], where we already spec a maximum input power of 0dBm. Of
> course, it's absolutely correct that the maximum input power is what we can
> be sure that, even under maximum gain, will not lead to damage.
>
> Regarding U800/U813: these are ESD protection, not power limiter diodes!
>
> Now, at +0dBm power (and even more so at +3dBm), the signal will not be
> distorted only on the very lowest gain settings. Consider adding a simple
> attenuator; Friis' noise formulas contradict that (having attenuation (i.e.
> reducing gain) should happen as late as possible in the signal chain to
> minimize overall Noise Figure), but these assume amplifiers are still
> linear, and you'd probably break that condition.
>
> If you could share the frequency bands you're working on (if preferable,
> also in confidentiality directly with me), we can try to come up with a
> NF-vs-gain and IIP3-vs-gain relationship that would help you choose the
> optimal operating point.
>
> Best regards,
>
> Marcus
>
> [1] https://kb.ettus.com/B200/B210/B200mini/B205mini#RF_Specifications
>
> On 08.07.2017 10:03, Sivan Toledo via USRP-users wrote:
>
> Hi, I am trying to understand the input-port limit of the B2X0 series,
> which is specified as -15dBm in the User's Manual (http://files.ettus.com/
> manual/page_usrp_b200.html).
>
> The issue is that if I use external front-end components (masthead LNA and
> a saw filter), it is difficult to limit power to -15dBm (limiting to a 0 or
> single-digit dBm is possible with common limiters).
>
> Is the -15dBm the limit that will cause overload and distortion even on
> the lowest gain setting, or is it a safely limit above which the unit may
> get damanged?
>
> Looking at the schematics of the B210, the input if fed to a switch that
> can sustain almost 1W, then through something that looks like a limiter
> (U800 and U813), then through another switch, and then to the inputs of the
> AD9361, which can tolerate up to 2.5dBm. So it's hard to see why anything
> up to 2.5dBm will damage the B2x0, and assuming that U800 and U813 do have
> some useful limiting function, maybe much more is safe.
>
> Can you please clarify? I am considering using B2x0 for an application
> that may subject them to about 3dBm, maybe 3.5dBm (we use an LNA, followed
> by a 6dBm-max limiter, then a SAW filter with an insertion loss around
> 3dB), and I want to make sure that this is safe.
>
> Thanks, Sivan Toledo
>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://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] Input power limit for B2x0 series

[Sivan Toledo via USRP-users]

Hi, I am trying to understand the input-port limit of the B2X0 series,
which is specified as -15dBm in the User's Manual (
http://files.ettus.com/manual/page_usrp_b200.html).

The issue is that if I use external front-end components (masthead LNA and
a saw filter), it is difficult to limit power to -15dBm (limiting to a 0 or
single-digit dBm is possible with common limiters).

Is the -15dBm the limit that will cause overload and distortion even on the
lowest gain setting, or is it a safely limit above which the unit may get
damanged?

Looking at the schematics of the B210, the input if fed to a switch that
can sustain almost 1W, then through something that looks like a limiter
(U800 and U813), then through another switch, and then to the inputs of the
AD9361, which can tolerate up to 2.5dBm. So it's hard to see why anything
up to 2.5dBm will damage the B2x0, and assuming that U800 and U813 do have
some useful limiting function, maybe much more is safe.

Can you please clarify? I am considering using B2x0 for an application that
may subject them to about 3dBm, maybe 3.5dBm (we use an LNA, followed by a
6dBm-max limiter, then a SAW filter with an insertion loss around 3dB), and
I want to make sure that this is safe.

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