Re: [USRP-users] missing rx_freq tags when frequency changes

[Gilad Beeri (ApolloShield) via USRP-users]

Hi David,

UHD should write that rx_freq tag whenever you change the frequency. Maybe
others will know to explain why it doesn't. Which GR version are you using?
Open usrp_source_impl.cc and verify that your version has `_tag_now = true`
in `set_center_freq()` and that `work()` responds to that flag by adding
the `rx_freq` tag (and others).
Using a downstream block will be less accurate then tagging it in UHD
(which, if I understand correctly, isn't accurate by itself but the best
one can get using host code). Think about it this way: you call
set_center_freq which (assuming) tags the next sample to come from the USRP
Source and also tells your block to add that tag. But there are some
samples in the pipeline between USRP Source and your tagging block, which
will be assumed to be from the new freq, but actually aren't. In addition,
it's probable that UHD tags too early (before the RF frontend actually
finished changing frequencies) - but I'm not sure about that as it depends
whether the low-level call is synchronous or not (haven't checked).


Regarding settling time, I asked a similar question a few weeks ago,
regarding the B205mini, which uses the same AD chip as your B200mini:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-October/026851.html



On Wed, Nov 8, 2017 at 4:22 AM David Rose via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I’m programming a USRP B200mini-i in Python.
>
>
>
> When the receiver starts up, it automatically inserts a ‘rx_freq’  tag
> into the stream.
>
>
>
> In my application I periodically change the receiver frequency using a
> command such as: self.uhd_usrp_source_0.set_center_freq(self.rf_freq, 0).
> This does indeed change the frequency, but it doesn’t look like the source
> block is adding new ‘rf_freq’ tags to mark the changes.  Does anyone know
> how to make that happen?
>
>
>
> I tried directly setting a class variable in a downstream block from
> top_block every time I change the frequency.  That sort of works, but I
> don’t think it’s marking the exact right place in the stream, so I assume
> that’s not a recommended approach.
>
>
>
> Finally, does the B200mini-i require any settling time after a frequency
> change, and if so, how much time?  Is there a chance of getting bad samples
> during a frequency transition, or does the stream shut down until things
> stabilize?
>
>
>
> Thanks,
>
>
>
> Dave Rose
>
> Valkyrie Systems Corp.
>
>
>
>
> ___
> 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] missing rx_freq tags when frequency changes

[David Rose via USRP-users]

I'm programming a USRP B200mini-i in Python.

When the receiver starts up, it automatically inserts a 'rx_freq'  tag into the 
stream.

In my application I periodically change the receiver frequency using a command 
such as: self.uhd_usrp_source_0.set_center_freq(self.rf_freq, 0).  This does 
indeed change the frequency, but it doesn't look like the source block is 
adding new 'rf_freq' tags to mark the changes.  Does anyone know how to make 
that happen?

I tried directly setting a class variable in a downstream block from top_block 
every time I change the frequency.  That sort of works, but I don't think it's 
marking the exact right place in the stream, so I assume that's not a 
recommended approach.

Finally, does the B200mini-i require any settling time after a frequency 
change, and if so, how much time?  Is there a chance of getting bad samples 
during a frequency transition, or does the stream shut down until things 
stabilize?

Thanks,

Dave Rose
Valkyrie Systems Corp.


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

Re: [USRP-users] TX power levels. Long term exposure.

[Kevin Hung via USRP-users]

Now I am very tempted to try it out and see how many coworkers believe the
metal hat.

On Tue, Nov 7, 2017 at 3:31 PM, Dan CaJacob  wrote:

> It's a joke :)
>
> On Tue, Nov 7, 2017 at 2:21 PM Kyeong Su Shin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> It will act as a RF shield. (see: https://en.wikipedia.
>> org/wiki/Electromagnetic_shielding )
>>
>> Not a recommended way to protect yourself from strong EM waves, but it
>> does make a good joke.
>>
>> Regards,
>> Kyeong Su Shin
>>
>> On Tue, Nov 7, 2017 at 11:01 AM, Kevin Hung via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hmm, I am just curious. What does the metal hat do?
>>>
>>> On Mon, Nov 6, 2017 at 11:38 PM, Dan CaJacob via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 But if you want to have some fun with your co-workers. Put on a metal
 hat whenever you TX. If they ask what's going on, say "Don't worry about
 it" :)

 On Mon, Nov 6, 2017 at 4:49 PM Bakshi, Arjun via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Thanks for clearing that up.
>
>
> AB
> --
> *From:* Nick Foster 
> *Sent:* Monday, November 6, 2017 3:58:05 PM
> *To:* Bakshi, Arjun
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] TX power levels. Long term exposure.
>
> Don't worry about it. You are several orders of magnitude below any
> sort of permissible exposure limit.
>
> Nick
>
> On Mon, Nov 6, 2017 at 11:21 AM Bakshi, Arjun via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> I'm looking to do long duration experiments in a lab which will have
> people in it while I TX and Rx, and I'd like to know what health and 
> safety
> concerns I should keep in mind.
>
>
> I tried looking at FCC and EU for limits on radiation levels, but
> those specs aren't straightforward to understand. It's also difficult to
> get an estimate of absolute power rxed/txed from the USRPs. So I'd like to
> hear from anyone who knows about this stuff.
>
>
> I'm using SBX (max power 100mW), and I'm thinking of using either the
> 500-700MHz or the 1.2-1.3 GHz band. I'll be transmitting for *5ms
> every second for a few hours*. The room is about 6m x 15m. Then
> antennas will be 1-2 meters away from a few people. TX and RX are about 4m
> apart. With gain set to 25dB, my signal has ~30dB SNR.
>
>
> Sorry if this seems a bit odd/specific.
>
>
> Thank you,
>
>
> AB
>
>
> ___
> 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
>
 --
 Very Respectfully,

 Dan CaJacob

 ___
 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
>>
> --
> Very Respectfully,
>
> Dan CaJacob
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] API for PPS input validation

[Rob Kossler via USRP-users]

Dario,
Perhaps with the time source set to external, you can just check the time
of the last PPS (get_time_last_pps) and if it's more than 1 sec old
(relative to get_time_now), there is no PPS detected.

Rob

On Tue, Nov 7, 2017 at 11:02 AM, Dario Fertonani via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On B210, the function
>
> get_mboard_sensor_names( )
>
> returns only "ref_locked" (output confirmed by "uhd_usrp_probe"), so it
> seems the answer to the question in this thread is negative. Can anybody
> please confirm whether this is correct? It would be very useful to know if
> the PPS signal input is actually being used.
>
> Thanks,
> Dario
>
> On Sat, Nov 4, 2017 at 9:50 AM, Dario Fertonani  > wrote:
>
>> I was wondering if it's possible to check via software API whether the
>> PPS reference input is connected. Something along the lines of the API that
>> checks whether the 10 MHz reference input is connected (see red part of the
>> snippet below).
>>
>> Thanks,
>> Dario
>>
>> rfBoardPtr->set_clock_source( "external" );
>> //more code, and give the board time to lock to the reference input
>> assert( rfBoardPtr->get_mboard_sensor( "ref_locked" ).to_bool( ) );
>>
>
>
> ___
> 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] Phantom USRP X300 Detections from uhd::device::find

[Perelman, Nathan via USRP-users]

My application runs uhd::device::find() (with no arguments) every 5 seconds
or so to detect when a user has plugged in a new USRP. Rarely (on the order
of once or twice per day), this reports detecting an X300 with an IP address
matching the IP address of the computer the application is running on, with
no name or serial filled in. As this is obviously not a correct detection of
an X300, attempting to connect to it fails. This is with UHD 3.10.1.1. Any
ideas as to what might be causing this or how to stop it from happening?

-Nathan



smime.p7s
Description: S/MIME cryptographic signature
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] TX power levels. Long term exposure.

[Kyeong Su Shin via USRP-users]

It will act as a RF shield. (see:
https://en.wikipedia.org/wiki/Electromagnetic_shielding )

Not a recommended way to protect yourself from strong EM waves, but it does
make a good joke.

Regards,
Kyeong Su Shin

On Tue, Nov 7, 2017 at 11:01 AM, Kevin Hung via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hmm, I am just curious. What does the metal hat do?
>
> On Mon, Nov 6, 2017 at 11:38 PM, Dan CaJacob via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> But if you want to have some fun with your co-workers. Put on a metal hat
>> whenever you TX. If they ask what's going on, say "Don't worry about it" :)
>>
>> On Mon, Nov 6, 2017 at 4:49 PM Bakshi, Arjun via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Thanks for clearing that up.
>>>
>>>
>>> AB
>>> --
>>> *From:* Nick Foster 
>>> *Sent:* Monday, November 6, 2017 3:58:05 PM
>>> *To:* Bakshi, Arjun
>>> *Cc:* usrp-users@lists.ettus.com
>>> *Subject:* Re: [USRP-users] TX power levels. Long term exposure.
>>>
>>> Don't worry about it. You are several orders of magnitude below any sort
>>> of permissible exposure limit.
>>>
>>> Nick
>>>
>>> On Mon, Nov 6, 2017 at 11:21 AM Bakshi, Arjun via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>> I'm looking to do long duration experiments in a lab which will have
>>> people in it while I TX and Rx, and I'd like to know what health and safety
>>> concerns I should keep in mind.
>>>
>>>
>>> I tried looking at FCC and EU for limits on radiation levels, but those
>>> specs aren't straightforward to understand. It's also difficult to get an
>>> estimate of absolute power rxed/txed from the USRPs. So I'd like to hear
>>> from anyone who knows about this stuff.
>>>
>>>
>>> I'm using SBX (max power 100mW), and I'm thinking of using either the
>>> 500-700MHz or the 1.2-1.3 GHz band. I'll be transmitting for *5ms every
>>> second for a few hours*. The room is about 6m x 15m. Then antennas will
>>> be 1-2 meters away from a few people. TX and RX are about 4m apart. With
>>> gain set to 25dB, my signal has ~30dB SNR.
>>>
>>>
>>> Sorry if this seems a bit odd/specific.
>>>
>>>
>>> Thank you,
>>>
>>>
>>> AB
>>>
>>>
>>> ___
>>> 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
>>>
>> --
>> Very Respectfully,
>>
>> Dan CaJacob
>>
>> ___
>> 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] 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, );
>>>   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, _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(_stream) and
>>> uhd_usrp_get_rx_stream(usrp, _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, );
>>   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, _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(_stream) and
>> uhd_usrp_get_rx_stream(usrp, _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] API for PPS input validation

[Dario Fertonani via USRP-users]

On B210, the function

get_mboard_sensor_names( )

returns only "ref_locked" (output confirmed by "uhd_usrp_probe"), so it
seems the answer to the question in this thread is negative. Can anybody
please confirm whether this is correct? It would be very useful to know if
the PPS signal input is actually being used.

Thanks,
Dario

On Sat, Nov 4, 2017 at 9:50 AM, Dario Fertonani 
wrote:

> I was wondering if it's possible to check via software API whether the PPS
> reference input is connected. Something along the lines of the API that
> checks whether the 10 MHz reference input is connected (see red part of the
> snippet below).
>
> Thanks,
> Dario
>
> rfBoardPtr->set_clock_source( "external" );
> //more code, and give the board time to lock to the reference input
> assert( rfBoardPtr->get_mboard_sensor( "ref_locked" ).to_bool( ) );
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] UBX-160 with X310 communication issue

[Mark Koenig via USRP-users]

I would like to revisit this topic….the more I delve into this, it seems that 
the communications change came when I moved from working with the N210 to the 
X310.

A stark difference I notice between the N20 and X310 is the time it takes for a 
ping to respond.

The N210 ping is a little erratic and shows the following statistics.
rtt min/avg/max/mdev = 1.223/1.524/2.370/0.227 ms

The X310 ping is very erratic and shows the following statistics.
rtt min/avg/max/mdev = 0.521/1.101/2.628/0.625 ms


Is there an architecture change in comms between the X310 and N210?

Thank you.

Mark

From: Neel Pandeya 
Date: Thursday, October 26, 2017 at 2:49 PM
To: Mark Koenig 
Cc: Nate Temple , "usrp-users@lists.ettus.com" 

Subject: Re: [USRP-users] UBX-160 with X310 communication issue

Hello Mark:

We do not have any document listing the changes between the hardware revisions 
of the UBX, but they do not fundamentally affect the operation or capabilities 
of the device.

Could you please elaborate on what you mean by "communication anomalies", and 
describe the issue in detail?

Thanks!

--​Neel Pandeya



On 26 October 2017 at 10:25, Mark Koenig via USRP-users 
> wrote:
Hi Nate, just following up on this.

Thank you

Mark

From: Mark Koenig 
>
Date: Thursday, October 19, 2017 at 12:30 PM
To: Nate Temple >

Cc: "usrp-users@lists.ettus.com" 
>
Subject: Re: [USRP-users] UBX-160 with X310 communication issue

Nate,

There seems to be a number of differences between the UBX-40 v1, UBX-40 v2 and 
UBX-160 v1, UBX-160 v2.  Is there any documentation describing the difference 
between the v1 and v2 daughtercards?  I am also noticing some communication 
anomalies when using the v2 daugtercard.

Thank you

Mark

From: Nate Temple >
Date: Tuesday, October 17, 2017 at 5:19 PM
To: Mark Koenig 
>
Cc: "usrp-users@lists.ettus.com" 
>
Subject: Re: [USRP-users] UBX-160 with X310 communication issue

Hi Mark,

The UBX v2 is not supported using UHD 3.9.3. Support for the UBX v2 was added 
with UHD 3.9.5 and UHD 3.10.2.0. Can you please try updating to the newest UHD, 
such as 3.9.7 or 3.10.2.0 and try probing USRP/DBs again?

Regards,
Nate Temple

On Tue, Oct 17, 2017 at 1:01 PM, Mark Koenig via USRP-users 
> wrote:
Hello,

I am looking for some help with respect to the UBX-160.  I have two version 2 
daughtercards which were purchased a couple of months ago.

I am running on CentOS 7.2 and CentOS 6.5 with GNU radio version 3.7.4 and UHD 
version 003.009.003.

I can ping the USRP and also return information on the uhd_find_devices 
command, however, when I run the uhd_usrp_probe command I do not get a return 
for the daughtercards.  The example output is below.

Any help would be EXTREMELY appreciated.

Thank you
Mark

linux; GNU C++ version 4.4.7 20120313 (Red Hat 4.4.7-16); Boost_105300; 
UHD_003.009.004-0-g2b5a88bb

-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Detecting internal GPSDO Found an internal GPSDO
-- Initialize Radio0 control...
-- Performing register loopback test... pass
-- Initialize Radio1 control...
-- Performing register loopback test... pass
  _
/
|   Device: X-Series Device
| _
|/
|   |   Mboard: X310
|   |   revision: 11
|   |   revision_compat: 7
|   |   product: 30818
|   |   mac-addr0: 00:80:2f:17:43:3f
|   |   mac-addr1: 00:80:2f:17:43:40
|   |   gateway: 192.168.10.1
|   |   ip-addr0: 192.168.10.2
|   |   subnet0: 255.255.255.0
|   |   ip-addr1: 192.168.20.2
|   |   subnet1: 255.255.255.0
|   |   ip-addr2: 192.168.30.2
|   |   subnet2: 255.255.255.0
|   |   ip-addr3: 192.168.40.2
|   |   subnet3: 255.255.255.0
|   |   serial: 311FF4E
|   |   FW Version: 4.0
|   |   FPGA Version: 19.0
|   |
|   |   Time sources: internal, external, gpsdo
|   |   Clock sources: internal, external, gpsdo
|   |   Sensors: gps_gpgga, gps_gprmc, gps_time, gps_locked, gps_servo, 
ref_locked
|   | _
|   |/
|   |   |   RX DSP: 0
|   |   |   Freq range: -100.000 to 100.000 MHz
|   | 

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, );
>   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, _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(_stream) and
> uhd_usrp_get_rx_stream(usrp, _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, );
  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, _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(_stream) and
uhd_usrp_get_rx_stream(usrp, _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] Cross compiling uhd+rfnoc for use on e310, bulds and installs but fails when used

[Jack Ziegler via USRP-users]

I've been struggling with the exact same bug with uhd on the e310.  I'm
trying to compile it to use RFNOC.  Has a fix for this been resolved?  I'm
new to using the e310 and have no idea how to get past this.  Unlike the
the original poster, I am unable to run anything with uhd, the examples
stop before they finish with this error.  Also of note, I am using a newer
e310 from the e313 if that makes a difference.  I've gone through the
directions multiple times to see if I've missed anything,

Thanks in advance,

Jack Ziegler


[USRP-users] [RFNOC][UHD] Error in uhd_usrp_probe*Jonathon Pendlum*
jonathon.pendlum
at ettus.com

*Mon Mar 6 11:59:04 EST 2017*


   - Previous message (by thread): [USRP-users] [RFNOC][UHD] Error in
   uhd_usrp_probe
   

   - Next message (by thread): [USRP-users] Probably bug in USRP stream
   commands
   

   - *Messages sorted by:* [ date ]
   

[ thread ]
   

[ subject ]
   

[ author ]
   


--

Hi,

I have made an issue in our bug tracker for that. While it is an error, it
actually doesn't appear to prevent you from running any UHD apps or GNU
Radio RFNoC flowgraphs.



Jonathon

On Mon, Mar 6, 2017 at 9:55 AM, Rubén Vogel via USRP-users http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>>
wrote:

>* Hello everyone,
*>>* I trying to cross-compile UHD + GNURADIO + GR_ETTUS to USRP E310. The
*>* versions of each one are:
*>>* UHD: UHD_4.0.0.rfnoc-0-unknown
*>>* GNURADIO: 3.7.9.3
*>>* GR_ETTUS: branch master/
*>>* I use the next script to compile it:
*>>>* 
*>* ---
*>* #!/bin/bash
*>>* cd ~/e310
*>* source environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
*>* echo $CC
*>>* echo ## BUILDING UHD ###
*>* cd ~/e310/sources/uhd-rfnoc-devel/host/build
*>* cmake -Wno-dev
-DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake
*>* -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_DOXYGEN=False -DENABLE_E300=ON ..
*>* make
*>>* echo ## INSTALLING UHD ###
*>* make install DESTDIR=~/e310/sshfs
*>* make install DESTDIR=~/e310/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/
*>>* echo ## BUILDING GNURADIO ###
*>* cd ~/e310/sources/gnuradio-3.7.9.3/build
*>* cmake -Wno-dev -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/oe-sdk_cross.cmake
*>* -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_GR_VOCODER=OFF -DENABLE_GR_ATSC=OFF
*>* -DENABLE_GR_WXGUI=OFF -DENABLE_GR_DTV=OFF -DENABLE_DOXYGEN=False
*>* -DENABLE_GR_AUDIO=ON -DENABLE_GR_BLOCKS=ON -DENABLE_GR_DIGITAL=ON
*>* -DENABLE_GR_FEC=ON -DENABLE_GR_FFT=ON -DENABLE_GR_FILTER=ON
*>* -DENABLE_GR_QTGUI=ON -DENABLE_GR_UHD=ON -DENABLE_PYTHON=ON -DENABLE_VOLK=ON
*>* -DENABLE_GRC=ON ..
*>* make
*>>* echo ## INSTALLING GNURADIO ###
*>* make install DESTDIR=~/e310/sshfs
*>* make install DESTDIR=~/e310/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/
*>>* echo ## BUILDING GR-ETTUS ###
*>* cd ~/e310/sources/gr-ettus-master/build
*>* cmake -Wno-dev
-DCMAKE_TOOLCHAIN_FILE=../../gnuradio-3.7.9.3/cmake/Toolchains/oe-sdk_cross.cmake
*>* -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_DOXYGEN=OFF ..
*>* make
*>>* echo ## INSTALLING GR-ETTUS ###
*>* make install DESTDIR=~/e310/sshfs
*>* make install DESTDIR=~/e310/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/
*>* 
*>* ---
*>>* *The sshfs directory was used to clone the Ettus file system, and the
*>* files were installed directly on this directory. *
*>>* *The process was successful!!*
*>>* In Ettus, the images were downloaded and checked the gnuradio version and
*>* executed the "uhd_usrp_probe" command.
*>>* root at ettus-e3xx-sg1
:~#
*gnuradio-config-info -v *
*>>* 3.7.9.3
*>>* root at ettus-e3xx-sg1
:~#
*uhd_usrp_probe *
*>>* [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700;
*>* UHD_4.0.0.rfnoc-0-unknown
*>>* [INFO] [E300] Loading FPGA image:
/usr/share/uhd/images/usrp_e310_fpga.bit...
*>>>* [INFO] [E300] FPGA image loaded
*>>* [INFO] [E300] Initializing core control (global registers)...
*>>* [INFO] [E300]