[USRP-users] USRP B200 phase difference between TX and RX LO

[Ismael Peruga via USRP-users]

Hello everyone,

I am developing a radar application with the USRP B200. For that purpose,
it is necessary that the phase difference between the TX and the RX local
oscillator remains constant in different frequencies (that is, I send a
pulse in a frequency, and after that, I change the frequency and send
another pulse, and so on...). The problem is that this phase difference is
not constant (even if I send the same frequency after I launch the program
two times).

I've tried to find information, and it seems that it is a hardware
limitation. However I still think that this should be possible (maybe is it
possible to use an external oscillator for both TX and RX?)

Thanks in advance,

Best regards,

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

Re: [USRP-users] USRP B200 phase difference between TX and RX LO

[Derek Kozel via USRP-users]

Hello Ismael,

With the B200 it is not possible to get the same phase offset at all
frequencies, in fact that is not possible to obtain with any USRP. Some,
such as the UBX and TwinRX, provide the ability to have the same phase
offset every time you tune to a specific frequency. That allows the USRP to
be calibrated once so you can remove the phase offset. With the B200 it is
necessary to do a calibration every time it is tuned as there is no
synchronization of the LO output phase with regards to the reference
frequency. The B200 does not support the use of an external local
oscillator for driving the mixers. You may be able to do the calibration
without additional hardware by using the TX to RX leakage and timed
commands to receive a test tone, but it will require appreciable work to
calibrate out the various sources of time offsets and phase shifts.

This application note discusses the different USRPs and different levels of
synchronization.
https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices

Regards,
Derek

On Tue, May 22, 2018 at 9:58 AM, Ismael Peruga via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello everyone,
>
> I am developing a radar application with the USRP B200. For that purpose,
> it is necessary that the phase difference between the TX and the RX local
> oscillator remains constant in different frequencies (that is, I send a
> pulse in a frequency, and after that, I change the frequency and send
> another pulse, and so on...). The problem is that this phase difference is
> not constant (even if I send the same frequency after I launch the program
> two times).
>
> I've tried to find information, and it seems that it is a hardware
> limitation. However I still think that this should be possible (maybe is it
> possible to use an external oscillator for both TX and RX?)
>
> Thanks in advance,
>
> Best regards,
>
> Ismael.
>
> ___
> 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] USRP B200 phase difference between TX and RX LO

[Derek Kozel via USRP-users]

Hello Ismael,

No, the AD9361 transceiver chip which the B200 uses does not support that.

Regards,
Derek

On Tue, May 22, 2018 at 12:00 PM, Ismael Peruga  wrote:

> Hello Derek,
>
> Thank you for your answer. Is it possible to use the same LO for transmit
> and receive? That would fix the problem...
>
> Best regards,
> Ismael.
>
> On Tue, May 22, 2018 at 12:35 PM, Derek Kozel 
> wrote:
>
>> Hello Ismael,
>>
>> With the B200 it is not possible to get the same phase offset at all
>> frequencies, in fact that is not possible to obtain with any USRP. Some,
>> such as the UBX and TwinRX, provide the ability to have the same phase
>> offset every time you tune to a specific frequency. That allows the USRP to
>> be calibrated once so you can remove the phase offset. With the B200 it is
>> necessary to do a calibration every time it is tuned as there is no
>> synchronization of the LO output phase with regards to the reference
>> frequency. The B200 does not support the use of an external local
>> oscillator for driving the mixers. You may be able to do the calibration
>> without additional hardware by using the TX to RX leakage and timed
>> commands to receive a test tone, but it will require appreciable work to
>> calibrate out the various sources of time offsets and phase shifts.
>>
>> This application note discusses the different USRPs and different levels
>> of synchronization.
>> https://kb.ettus.com/Synchronization_and_MIMO_Capability_
>> with_USRP_Devices
>>
>> Regards,
>> Derek
>>
>> On Tue, May 22, 2018 at 9:58 AM, Ismael Peruga via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello everyone,
>>>
>>> I am developing a radar application with the USRP B200. For that
>>> purpose, it is necessary that the phase difference between the TX and the
>>> RX local oscillator remains constant in different frequencies (that is, I
>>> send a pulse in a frequency, and after that, I change the frequency and
>>> send another pulse, and so on...). The problem is that this phase
>>> difference is not constant (even if I send the same frequency after I
>>> launch the program two times).
>>>
>>> I've tried to find information, and it seems that it is a hardware
>>> limitation. However I still think that this should be possible (maybe is it
>>> possible to use an external oscillator for both TX and RX?)
>>>
>>> Thanks in advance,
>>>
>>> Best regards,
>>>
>>> Ismael.
>>>
>>> ___
>>> 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] B210 Frequency Offset

[Teemu Veijalainen via USRP-users]

Hi,

I've 2x USRP B210 with board mounted GPSDO (TCXO). I'm controlling the USRP's 
with MATLAB and configured the other to send CW at 3.75GHz and other to receive 
with the same frequency. The radios are connected with 50cm SMA cable and 30 dB 
attenuator.

I know there should be some frequency offset, however the received signal is 
around 1.7 kHz off and I think that is too much. The GPSDO should provide 
accuracy of 75 ppb in unlocked condition so I'm expecting to see frequency 
offset maximum a few hundred Hz. Therefore, I'm asking is this normal or am I 
missing something?

Br,
Teemu

USRP Configuration

  *   Tx&Rx InterpolationFactor=512
  *   Tx&Rx MasterClockRate=512
  *   Tx Gain=55 & Rx Gain=64


[cid:image002.png@01D3F1DA.F06C4BB0]
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 Frequency Offset

[Derek Kozel via USRP-users]

Hello Teemu,

Have you set the B200 to use the GPSDO as the time and frequency source?
Not doing so could be the cause of the frequency offset.
http://files.ettus.com/manual/page_sync.html

Regards,
Derek

On Tue, May 22, 2018 at 12:41 PM, Teemu Veijalainen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
>
>
> I’ve 2x USRP B210 with board mounted GPSDO (TCXO). I’m controlling the
> USRP’s with MATLAB and configured the other to send CW at 3.75GHz and other
> to receive with the same frequency. The radios are connected with 50cm SMA
> cable and 30 dB attenuator.
>
>
>
> I know there should be some frequency offset, however the received signal
> is around 1.7 kHz off and I think that is too much. The GPSDO should
> provide accuracy of 75 ppb in unlocked condition so I’m expecting to see
> frequency offset maximum a few hundred Hz. Therefore, I’m asking is this
> normal or am I missing something?
>
>
>
> Br,
>
> Teemu
>
>
>
> USRP Configuration
>
>- Tx&Rx InterpolationFactor=512
>- Tx&Rx MasterClockRate=512
>- Tx Gain=55 & Rx Gain=64
>
>
>
>
>
>
> ___
> 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] B210 Frequency Offset

[Teemu Veijalainen via USRP-users]

Hi,

And thx for the reply.

The manual (http://files.ettus.com/manual/page_gpsdo_b2x0.html) states that the 
GPSDO is detected automatically so I think I don’t have to configure it:

  *   “By default, if a GPSDO is detected at startup, the USRP will be 
configured to use it as a frequency and time reference
Also, when probing the USRP it returns:

  *   “Detecting internal GPSDO Found an internal GPSDO: GPSTCXO , Firmware 
Rev 0.929a”.
So looks like it is detected.

The manual also states that the GPSDO is initialized to GPS time :

  *   “The internal VITA timestamp will be initialized to the GPS time, and the 
internal oscillator will be phase-locked to the 10MHz GPSDO reference. If the 
GPSDO is not locked to satellites, the VITA time will not be initialized.”
I’m not using GPS antenna, and I assumed that since the GPSDO provides GPS 
unlocked refence of 75ppb and GPS locked reference of <1ppb then I don’t need 
GPS to initialize. However, the above sentence from the manual doesn’t state 
clearly that the GPSDO can be used without initialed by GPS, could it be e.g. 
that GPS is needed to initialize the GPSDO and then GPS signal can be lost to 
get the unlocked accuracy? Or could there be still some other reason?

Br, Teemu

From: Derek Kozel [mailto:derek.ko...@ettus.com]
Sent: Tuesday, May 22, 2018 3:07 PM
To: Teemu Veijalainen 
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] B210 Frequency Offset

Hello Teemu,
Have you set the B200 to use the GPSDO as the time and frequency source? Not 
doing so could be the cause of the frequency offset.
http://files.ettus.com/manual/page_sync.html
Regards,
Derek

On Tue, May 22, 2018 at 12:41 PM, Teemu Veijalainen via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Hi,

I’ve 2x USRP B210 with board mounted GPSDO (TCXO). I’m controlling the USRP’s 
with MATLAB and configured the other to send CW at 3.75GHz and other to receive 
with the same frequency. The radios are connected with 50cm SMA cable and 30 dB 
attenuator.

I know there should be some frequency offset, however the received signal is 
around 1.7 kHz off and I think that is too much. The GPSDO should provide 
accuracy of 75 ppb in unlocked condition so I’m expecting to see frequency 
offset maximum a few hundred Hz. Therefore, I’m asking is this normal or am I 
missing something?

Br,
Teemu

USRP Configuration

  *   Tx&Rx InterpolationFactor=512
  *   Tx&Rx MasterClockRate=512
  *   Tx Gain=55 & Rx Gain=64


[cid:image001.png@01D3F1E2.5F492B50]

___
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] Race Condition Issue?

[cbecker via USRP-users]

Hi,

While running C++ code that worked with older versions of GNU 
Radio/UHD/Boost, after pulling the latest version from github we are 
only able to run the code sometimes. Below I am including three separate 
partial stack traces of failed runs. We are getting a segmentation fault 
that technically occurs in Boost ASIO code. However, the amount of UHD 
code that executes seems to vary, suggesting that the issue is something 
in UHD.


We are using a fresh install of Xubuntu 16.04; GNU C++ version 5.4.0 
20160609; Boost_105800; UHD_3.11.1.0-0-gad6b0935.


#0  0x765cd9ab in boost::asio::io_service::service* 
boost::asio::detail::service_registry::create 
>(boost::asio::io_service&) () from /usr/local/lib/libuhd.so.3
#1  0x7659f5d8 in 
boost::asio::detail::service_registry::do_use_service(boost::asio::io_service::service::key 
const&, boost::asio::io_service::service* (*)(boost::asio::io_service&)) 
() from /usr/local/lib/libuhd.so.3
#2  0x76613bb0 in 
udp_simple_impl::udp_simple_impl(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, 
std::__cxx11::basic_string, 
std::allocator > const&, bool, bool) ()

   from /usr/local/lib/libuhd.so.3
#3  0x76612186 in 
uhd::transport::udp_simple::make_connected(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, 
std::__cxx11::basic_string, 
std::allocator > const&) ()

   from /usr/local/lib/libuhd.so.3
#4  0x7645cde9 in 
x300_impl::determine_max_frame_size(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, 
x300_impl::frame_size_t const&) () from /usr/local/lib/libuhd.so.3
#5  0x76472725 in x300_impl::setup_mb(unsigned long, 
uhd::device_addr_t const&) () from /usr/local/lib/libuhd.so.3
#6  0x7647c4a6 in x300_impl::x300_impl(uhd::device_addr_t 
const&) () from /usr/local/lib/libuhd.so.3
#7  0x7647dd52 in x300_make(uhd::device_addr_t const&) () from 
/usr/local/lib/libuhd.so.3
#8  0x762f6df0 in 
boost::detail::function::function_invoker1 
(*)(uhd::device_addr_t const&), boost::shared_ptr, 
uhd::device_addr_t 
const&>::invoke(boost::detail::function::function_buffer&, 
uhd::device_addr_t const&)

() from /usr/local/lib/libuhd.so.3
#9  0x766298fc in uhd::device::make(uhd::device_addr_t const&, 
uhd::device::device_filter_t, unsigned long) () from 
/usr/local/lib/libuhd.so.3
#10 0x7604e536 in uhd::usrp::multi_usrp::make(uhd::device_addr_t 
const&) () from /usr/local/lib/libuhd.so.3




#0  0x765cd9ab in boost::asio::io_service::service* 
boost::asio::detail::service_registry::create 
>(boost::asio::io_service&) () from /usr/local/lib/libuhd.so.3
#1  0x7659f5d8 in 
boost::asio::detail::service_registry::do_use_service(boost::asio::io_service::service::key 
const&, boost::asio::io_service::service* (*)(boost::asio::io_service&)) 
() from /usr/local/lib/libuhd.so.3
#2  0x765cfb9c in 
udp_zero_copy_asio_impl::udp_zero_copy_asio_impl(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, 
std::__cxx11::basic_string, 
std::allocator > const&, uhd::transport::zero_copy_xport_params 
const&) () from /usr/local/lib/libuhd.so.3
#3  0x765cbaba in 
uhd::transport::udp_zero_copy::make(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, 
std::__cxx11::basic_string, 
std::allocator > const&, uhd::transport::zero_copy_xport_params 
const&, uhd::transport::udp_zero_copy::buff_params&, uhd::device_addr_t 
const&) () from /usr/local/lib/libuhd.so.3
#4  0x76467a32 in x300_impl::make_transport(uhd::sid_t const&, 
uhd::usrp::device3_impl::xport_type_t, uhd::device_addr_t const&) () 
from /usr/local/lib/libuhd.so.3
#5  0x762c313f in 
uhd::usrp::device3_impl::enumerate_rfnoc_blocks(unsigned long, unsigned 
long, unsigned long, uhd::sid_t const&, uhd::device_addr_t) () from 
/usr/local/lib/libuhd.so.3
#6  0x764765ec in x300_impl::setup_mb(unsigned long, 
uhd::device_addr_t const&) () from /usr/local/lib/libuhd.so.3
#7  0x7647c4a6 in x300_impl::x300_impl(uhd::device_addr_t 
const&) () from /usr/local/lib/libuhd.so.3
#8  0x7647dd52 in x300_make(uhd::device_addr_t const&) () from 
/usr/local/lib/libuhd.so.3
#9  0x762f6df0 in 
boost::detail::function::function_invoker1 
(*)(uhd::device_addr_t const&), boost::shared_ptr, 
uhd::device_addr_t 
const&>::invoke(boost::detail::function::function_buffer&, 
uhd::device_addr_t const&)

() from /usr/local/lib/libuhd.so.3
#10 0x766298fc in uhd::device::make(uhd::device_addr_t const&, 
uhd::device::device_filter_t, unsigned long) () from 
/usr/local/lib/libuhd.so.3
#11 0x7604e536 in uhd::usrp::multi_usrp::make(uhd::device_addr_t 
const&) () from /usr/local/lib/libuhd.so.3




#0  0x765cd9ab in boost::asio::io_service::service* 
boost::asio::detail::service_registry::create 
>(boost::asio::io_service&) () from /usr/local/lib/libuhd.so.3
#1  0x7ff

Re: [USRP-users] B210 Frequency Offset

[Marcus D. Leech via USRP-users]

On 05/22/2018 08:42 AM, Teemu Veijalainen via USRP-users wrote:


Hi,

And thx for the reply.

The manual (http://files.ettus.com/manual/page_gpsdo_b2x0.html) states 
that the GPSDO is detected automatically so I think I don’t have to 
configure it:


  * /“By default, if a GPSDO is detected at startup, the USRP will be
configured to use it as a frequency and time reference/

Also, when probing the USRP it returns:

  * “Detecting internal GPSDO Found an internal GPSDO: GPSTCXO ,
Firmware Rev 0.929a”.

So looks like it is detected.

The manual also states that the GPSDO is initialized to GPS time :

  * /“The internal VITA timestamp will be initialized to the GPS time,
and the internal oscillator will be phase-locked to the 10MHz
GPSDO reference. If the GPSDO is not locked to satellites, the
VITA time will not be initialized.”///

I’m not using GPS antenna, and I assumed that since the GPSDO provides 
GPS unlocked refence of 75ppb and GPS locked reference of <1ppb then I 
don’t need GPS to initialize. However, the above sentence from the 
manual doesn’t state clearly that the GPSDO can be used without 
initialed by GPS, could it be e.g. that GPS is needed to initialize 
the GPSDO and then GPS signal can be lost to get the unlocked 
accuracy? Or could there be still some other reason?


Br, Teemu


My suspicion is that a GPSDO that has "never seen the sky" will not be 
as good as one that has, and is operating in holdover mode.


The stated 1.7kHz in 3.75GHz, is about 400PPB, which is what I would 
expect from an undisciplined TCXO.



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

[USRP-users] Disable automatic dc offset and IQ imbalance corrections

[kunal sankhe via USRP-users]

Hi,

I want to disable automatic calibration of DC offset and IQ imbalance in
USRP Source block.

I am aware that I need to pass bool value 'false' as the argument to
*set_auto_dc_offset* and *set_auto_iq_balance*. The USRP Source block
itself provide this facility in the tab *FE Corrections*. However, it does
not seem to work. By providing 0 (boolean false) value in Enable DC Offset
Correction and Enable IQ Imbalance Correction do not disable the automation
DC offset and IQ Imbalance correction. I tested this with USRP N210 by
simply using USRP Source block centered at frequency 915MHz connected with
WX GUI FFT Sink. The spectrum plot does not show any changes in both cases.

If I want to force these changes in the UHD code (usrp_source_impl.cc and
usrp_source_impl.h), what changes do I need to make?


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

Re: [USRP-users] Disable automatic dc offset and IQ imbalance corrections

[Derek Kozel via USRP-users]

Hello Kunal,

What daughterboard do you have? I do not believe that there is an IQ
balance function on the N210. Those functions apply to the E31x, B2xx, and
possibly N310 USRPs. There should be a DC notch filter which is selected on
and off, but I would have to check to see if that applies to the N210.

What difference in the spectrum are you expecting? What signals are you
observing while doing these tests?

Regards,
Derek

On Tue, May 22, 2018 at 4:06 PM, kunal sankhe via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I want to disable automatic calibration of DC offset and IQ imbalance in
> USRP Source block.
>
> I am aware that I need to pass bool value 'false' as the argument to
> *set_auto_dc_offset* and *set_auto_iq_balance*. The USRP Source block
> itself provide this facility in the tab *FE Corrections*. However, it
> does not seem to work. By providing 0 (boolean false) value in Enable DC
> Offset Correction and Enable IQ Imbalance Correction do not disable the
> automation DC offset and IQ Imbalance correction. I tested this with USRP
> N210 by simply using USRP Source block centered at frequency 915MHz
> connected with WX GUI FFT Sink. The spectrum plot does not show any changes
> in both cases.
>
> If I want to force these changes in the UHD code (usrp_source_impl.cc and
> usrp_source_impl.h), what changes do I need to make?
>
>
> Thanks,
> Kunal
>
>
>
>
>
> ___
> 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] Disable automatic dc offset and IQ imbalance corrections

[Marcus D. Leech via USRP-users]

On 05/22/2018 11:25 AM, Derek Kozel via USRP-users wrote:

Hello Kunal,

What daughterboard do you have? I do not believe that there is an IQ 
balance function on the N210. Those functions apply to the E31x, B2xx, 
and possibly N310 USRPs. There should be a DC notch filter which is 
selected on and off, but I would have to check to see if that applies 
to the N210.


What difference in the spectrum are you expecting? What signals are 
you observing while doing these tests?


Regards,
Derek
The N210 does indeed have DC offset and I/Q balance correction.  The I/Q 
balance correction is based on a calibration file (which is what the cal_*

  utilities are for).

But the DC-offset correction is board agnostic.




On Tue, May 22, 2018 at 4:06 PM, kunal sankhe via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Hi,

I want to disable automatic calibration of DC offset and IQ
imbalance in USRP Source block.

I am aware that I need to pass bool value 'false' as the argument
to *set_auto_dc_offset* and *set_auto_iq_balance*. The USRP Source
block itself provide this facility in the tab *FE Corrections*.
However, it does not seem to work. By providing 0 (boolean false)
value in Enable DC Offset Correction and Enable IQ Imbalance
Correction do not disable the automation DC offset and IQ
Imbalance correction. I tested this with USRP N210 by simply using
USRP Source block centered at frequency 915MHz connected with WX
GUI FFT Sink. The spectrum plot does not show any changes in both
cases.
If I want to force these changes in the UHD code
(usrp_source_impl.cc and usrp_source_impl.h), what changes do I
need to make?


Thanks,
Kunal




___
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] B200mini sc12 wire format broken?

[Emanuel via USRP-users]

Dear Neel,

please find below the output of my flowgraph in Gnuradio and the error message. 
I use the latest Gnuradio version. I have a setup of 8 mini-computer with 
B200mini attached. Only two of them show this error, and I still did not figure 
out why. Once I set the wire-format for the USRP source block in Gnuradio to 
"automatic" instead of "sc12", the error is gone. Manually setting "sc8" and 
"sc16" works without giving errors. From my understanding of the B200mini, the 
"automatic" wire-format is the "sc12" format.

Best Regards,
Emanuel

./top_block.py
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_3.11.0.HEAD-0-ga1b5c4ae
[INFO] [B200] Detected Device: B200mini
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [AD936X] Performing CODEC loopback test...
[INFO] [AD936X] CODEC loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.00 MHz...
[INFO] [B200] Actually got clock rate 16.00 MHz.
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [B200] Asking for clock rate 25.00 MHz...
[INFO] [B200] Actually got clock rate 25.00 MHz.
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [MULTI_USRP] 1) catch time transition at pps edge
[INFO] [MULTI_USRP] 2) set times next pps (synchronously)
[INFO] [MULTI_USRP] 1) catch time transition at pps edge
[INFO] [MULTI_USRP] 2) set times next pps (synchronously)
Press Enter to quit: [ERROR] [STREAMER] The receive packet handler caught a 
value exception.
ValueError: bad vrt header or packet fragment
WARN: USRP Source Block caught rx error code: 15
[ERRORWARN: USRP Source Block caught rx error code: 15
] [STREAMER] The receive packet handler caught a value exception.
ValueError: bad vrt header or packet fragment
[WARN: USRP Source Block caught rx error code: 15
ERROR] [STREAMER] The receive packet handler caught a value exception.
ValueError: bad vrt header or packet fragment
[ERROR] [STREAMER] The receive packet handler caught a value exception.
ValueError: bad vrt header or packet fragment
WARN: USRP Source Block caught rx error code: 15
[ERROR] [STREAMER] The receive packet handler caught a value exception.
ValueError: bad vrt header or packet fragment
WARN: USRP Source Block caught rx error code: 15
[ERROR] WARN: USRP Source Block caught rx error code: 15
[STREAMER] The receive packet handler caught a value exception.
ValueError: bad vrt header or packet fragment
[ERROR] [STREAMER] The receive packet handler caught a value exception.
ValueError: bad vrt header or packet fragment
WARN: USRP Source Block caught rx error code: 15
[ERROR] [STREAMER] The receive packet handler caught a value exception.
ValueError: bad vrt header or packet fragment
WARN: USRP Source Block caught rx error code: 15
WARN: USRP Source Block caught rx error code: 15
[ERROR] [STREAMER] The receive packet handler caught a value exception.
ValueError: bad vrt header or packet fragment
WARN: USRP Source Block caught rx error code: 15






Von: Neel Pandeya [neel.pand...@ettus.com]
Gesendet: Samstag, 19. Mai 2018 20:17
An: Staudinger, Emanuel
Cc: usrp-users
Betreff: Re: [USRP-users] B200mini sc12 wire format broken?

Hello Emanuel:

Could you please post the error message from the console?

Does this error persist in UHD 3.11.1.0?

--​Neel Pandeya




On 4 May 2018 at 06:51, Marcus D. Leech via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
On 05/04/2018 01:45 AM, Emanuel via USRP-users wrote:
Hi,

I switched from UHD release 3.10.2.0 to the latest release 3.11.0.0 and 
recognized in my Gnuradio application, that UHD gives errors when using the 
sc12 wire format. However, only when I use the USRP in receive mode. In 
transmit mode, the sc12 format works. The sc8 and sc16 wire format work well 
for the receive mode. The same issue comes with 3.11.0.1.
Release 3.10.2.0 does not show this error.

Did anyone else experience that?

Best regards,
Emanuel




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


Could you perhaps share the error log?  That would help developers and others...




___
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] Disable automatic dc offset and IQ imbalance corrections

[Derek Kozel via USRP-users]

Hi Marcus,

Yes, thanks for that clarification. I'd been thinking about automatic IQ
correction, which the AD9361/9364/9371 support. The file based IQ
correction will only be applied if the calibration utilities have already
been run on that daughterboard and system before.
http://files.ettus.com/manual/page_calibration.html

Regards,
Derek

On Tue, May 22, 2018 at 4:44 PM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 05/22/2018 11:25 AM, Derek Kozel via USRP-users wrote:
>
> Hello Kunal,
>
> What daughterboard do you have? I do not believe that there is an IQ
> balance function on the N210. Those functions apply to the E31x, B2xx, and
> possibly N310 USRPs. There should be a DC notch filter which is selected on
> and off, but I would have to check to see if that applies to the N210.
>
> What difference in the spectrum are you expecting? What signals are you
> observing while doing these tests?
>
> Regards,
> Derek
>
> The N210 does indeed have DC offset and I/Q balance correction.  The I/Q
> balance correction is based on a calibration file (which is what the cal_*
>   utilities are for).
>
> But the DC-offset correction is board agnostic.
>
>
>
> On Tue, May 22, 2018 at 4:06 PM, kunal sankhe via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi,
>>
>> I want to disable automatic calibration of DC offset and IQ imbalance in
>> USRP Source block.
>>
>> I am aware that I need to pass bool value 'false' as the argument to
>> *set_auto_dc_offset* and *set_auto_iq_balance*. The USRP Source block
>> itself provide this facility in the tab *FE Corrections*. However, it
>> does not seem to work. By providing 0 (boolean false) value in Enable DC
>> Offset Correction and Enable IQ Imbalance Correction do not disable the
>> automation DC offset and IQ Imbalance correction. I tested this with USRP
>> N210 by simply using USRP Source block centered at frequency 915MHz
>> connected with WX GUI FFT Sink. The spectrum plot does not show any changes
>> in both cases.
>>
>> If I want to force these changes in the UHD code (usrp_source_impl.cc and
>> usrp_source_impl.h), what changes do I need to make?
>>
>>
>> Thanks,
>> Kunal
>>
>>
>>
>>
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
> ___
> 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

Re: [USRP-users] UHD and process forking

[Keith k via USRP-users]

Hello Marcus

I'm trying to run 16 N200s with LFTX/LFRX boards. I want to use all 16 TX
channel and 20 RX channels at 10 MHz sampling rate. I will be streaming
continuous on RX and sending bursts on TX. The problem I'm having is that
the RX threads really don't like being preempted too often or they go into
a unstable state where they continually drop samples. I've got a computer
with a core i9 and I've isolated 70% of the cpu cores purely to my process,
but when it comes to scheduling the threads the best I can do is evenly
distribute them since I'm not aware of a mechanism to get the TID of only
the UHD RX threads. Using isolcpus and taskset with basic round robin cpu
affinity, I can get all 16 TX channels and 12 RX channels working for a
period of a few hours, but I think if I could properly schedule the RX
threads, I would be able to get them all working without dropped samples.
In theory the fork would work for me since I could use a child process for
only TX or RX threads and I could manually schedule them, but practically I
know there would be problems with the multi-usrp object.

Right now I'm scheduling using command line utilities once my application
is running, but I've now been considering querying the OS for TIDs before
and after each streamer is created from within my application. I should be
able use this information to isolate which set of threads are for RX or TX.
Do you have any thoughts on the best approach to scheduling for UHD or
operating high data rate multiusrp configurations?

On Sat, May 19, 2018 at 9:05 AM, Marcus Müller 
wrote:

> Hi Keith,
>
> in principle, you could continue using the multi_usrp in **one** of the
> processes. The real problem stems from the question of who inherits the
> sockets (in the case of network USRPs), the USB handles, or kernel ring
> buffer handles.
> In the end, only one process might react to packets coming from the USRP.
> Also, this is C++, so if you don't watch out in your main process, and your
> multi_usrp loses scope, its destructor would be called, with devastating
> effects on the state of your USRP.
>
> On the other hand, there is, at least as far as I can remember from the
> top of my head, nothing to react to until you start a streamer. But I
> wouldn't recommend relying on that as kind of API; I don't think we
> guarantee usability of a multi_usrp after forking, but the last word on
> that is Martin's.
>
> Maybe if you described your use case, we could chime in with approaches.
>
> Best regards,
> Marcus
>
> On 14 May 2018 18:09:51 GMT+02:00, Keith k via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>>
>> Hello all
>>
>> My intuition tells me this would be a bad idea, but before I try anything
>> with this, does anyone have any thoughts about how the multi-usrp object
>> would react in a situation where the process has been forked? I know that
>> the call to create a multi-usrp object will fail if called in a second
>> process, so I imagine it won't like being in 2 separate address spaces.
>>
>
> --
> This was written on my cellular phone. whilst an impressive piece of
> engineering, this might not be the perfect device to write emails on -
> please excuse my brevity.
>



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

Re: [USRP-users] Disable automatic dc offset and IQ imbalance corrections

[Derek Kozel via USRP-users]

Hello Kunal,

Please keep the mailing list included so that others can assist in
answering the questions or learn from the responses.
The set_rx_dc_offset function still exists. Here is the C++ API for that
function.
http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#
a7beb49c1a04a81b3e7569db482453746

The page you link to contains mostly C++ code examples, so my guess would
be that the previous author (four years ago) was making changes to the
gr-uhd source code to set the DC and IQ offsets manually.
The functions also are exposed in gr-uhd in C++ and python:

https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html#
ae3a31eb295e486c17c9e3d4b051e2ba8
https://www.gnuradio.org/doc/sphinx/uhd_blocks.html#
gnuradio.uhd.usrp_source_sptr.set_dc_offset

In order to use these you'll have to add either Python or C++ code to your
GNU Radio flowgraph.

If you really want to make these changes in UHD we can point you into the
source, but it's going to be much simpler and easier to do so using the
existing APIs.

Regards,
Derek


On Tue, May 22, 2018 at 5:22 PM, kunal sankhe  wrote:

> Hi Derek,
>
> Thanks for the prompt reply.
>
> I have tested with both USRP N210 + WBX daughterboard and USRP B210, but
> it does not seem the dc offset and IQ imbalance are disabled in both the
> cases. I am referring a section '*Parameter estimation and UHD
> implementation*' from the website http://shannon.ece.ufl
> .edu:6528/index.php/USRP_Transceiver_Tuning_and_Calibration. I am trying
> to reproduce similar results as shown by FFT spectra when receiver dc
> offset is enabled and disabled.
>
> They have used a function *set_rx_dc_offset()* to disable DC offset.
> However, this function seems to be replaced with *set_auto_dc_offset() *in
> USRP Source block.
>
> *What difference in the spectrum are you expecting? What signals are you
> observing while doing these tests?*
>
> Answer: I am expecting a rise in the dc value in the spectrum, when DC
> offset calibration is disabled. I am simply connecting USRP sink with FFT
> sink connected to it. No signal has been transmitted.
>
> Again, if I want to force these changes in the UHD code
> (usrp_source_impl.cc and usrp_source_impl.h), what changes do I need to
> make?
>
>
> Thanks,
> Kunal
>
>
> On Tue, May 22, 2018 at 11:25 AM, Derek Kozel 
> wrote:
>
>> Hello Kunal,
>>
>> What daughterboard do you have? I do not believe that there is an IQ
>> balance function on the N210. Those functions apply to the E31x, B2xx, and
>> possibly N310 USRPs. There should be a DC notch filter which is selected on
>> and off, but I would have to check to see if that applies to the N210.
>>
>> What difference in the spectrum are you expecting? What signals are you
>> observing while doing these tests?
>>
>> Regards,
>> Derek
>>
>> On Tue, May 22, 2018 at 4:06 PM, kunal sankhe via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi,
>>>
>>> I want to disable automatic calibration of DC offset and IQ imbalance in
>>> USRP Source block.
>>>
>>> I am aware that I need to pass bool value 'false' as the argument to
>>> *set_auto_dc_offset* and *set_auto_iq_balance*. The USRP Source block
>>> itself provide this facility in the tab *FE Corrections*. However, it
>>> does not seem to work. By providing 0 (boolean false) value in Enable DC
>>> Offset Correction and Enable IQ Imbalance Correction do not disable the
>>> automation DC offset and IQ Imbalance correction. I tested this with USRP
>>> N210 by simply using USRP Source block centered at frequency 915MHz
>>> connected with WX GUI FFT Sink. The spectrum plot does not show any changes
>>> in both cases.
>>>
>>> If I want to force these changes in the UHD code (usrp_source_impl.cc
>>> and usrp_source_impl.h), what changes do I need to make?
>>>
>>>
>>> Thanks,
>>> Kunal
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> 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 3.11.1.0 Release Announcement

[Michael West via USRP-users]

Hello all,

UHD 3.11.1.0 is now available. This is an update to the main series of
releases.

The tag for this release is located here:
https://github.com/EttusResearch/uhd/releases/tag/v3.11.1.0

Installers for Windows and Fedora are available here:
http://files.ettus.com/binaries/uhd/uhd_003.011.001.000-release/

The PPA for Ubuntu are available:
https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd


There have been 107 commits since the last release which can be viewed here:
https://github.com/EttusResearch/uhd/compare/v3.11.0.1...v3.11.1.0

CHANGELOG:

## 003.011.001.000
* N310: fix compiler warnings
* N310: Implement digital loopback
* N3xx: Add N3xx devtest
* X300: Properly coerce master clock rate (tick rate)
* X300: handle bad weak_ptr during pcie discovery
* X300: handle bad weak_ptr during pcie discovery
* X300: Fix check_radio_config() to fix errors when using a single dboard
in slot A
* B200: docs: Suggest modifying recv_frame_size for more stability
* B200: Fix bandwidth warnings and ranges
* N2xx: Fix regression issue that limited tuning range
* UBX: Change antenna functions to coercers on antenna/value properties
* adf4002: Fix register programming for power down bit
* UHD: Fix config file path for some Windows builds
* UHD: Add operators == and != for uhd::dict
* UHD: Add device_addr_t constructor from map
* UHD: Fix range of gain group to skip gains with zero step
* UHD: Changes to support Boost 1.67
* UHD: Correctly set end of burst flag in RX metadata
* UHD: Reduce usage of boost::assign, boost::this_thread::sleep, and
boost:bind
* UHD: Update multi_usrp::get_usrp_?x_info() for MPM devices
* UHD: Refactor static const values to fix linker errors in niusrprio
* mpm: cmake: Add git hash and version info to Python module
* mpm: Add reference counters to UIO
* mpm: Add offset to EEPROM reads
* mpm: Disable PPS out during initialization
* mpm: Update cmake to find the correct python3
* mpm: Bump maximum supported revision to 5 (Rev F)
* mpm: Fixed db slot typo in db-id
* mpm: Increased claim timeout, made a separate RPC connection for claim,
and
   added asyn calls for long RPC executions
* mpm: Improve xport<->SFP mapping algorithm
* mpmd: Improved find routine to fail fast and verify correct device is
reachable
* mpmd: Add missing virtual destructors
* rfnoc/x300: Make sure peek32() and peek64() are called with actual
addresses
* rfnoc: ctrl_iface cleanup
* rfnoc radio: Improve warning for too many samples requested
* rfnoc radio: get_rx_stream resets sequence num
* examples: Increase settling time, increase buffer fill time, and fix
subdevice
selection in txrx_loopback_to_file
* examples: Improvements to benchmark_rate
* utils: downloader supports multiple RegExs
* utils: Added code to handle underruns during self calibration
* utils: Fix 30s tiemout in query_gpsdo_sensors
* logging: Improve style consistency and demote some messages
* logging: Fix UHD_LOG_FILE cmake variable
* Docs: Add Known Issues section to USRP1, B100, and USRP2/N2x0
* Docs: Hide dependencies directory from Doxygen
* Docs: Clarify subdev specs and magnesium driver usage for N300/N310
* cmake: Improve warning for missing requests
* cmake: update NSIS template
* cmake: Remove images downloader section (replaced by manifest)

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

[USRP-users] Problem with reading from two rfnoc blocks

[Taliver Heath via USRP-users]

Greetings!

I'm having some issues with talking to two channels at the same time.  I'm
building from the maint branch, and if I use just one channel, I get
readings, but if I do two channels, the device simply hangs and never
responds.

The following is the sample code for this:
// Compile with:
// g++ -DZERO -o /tmp/channels channels.cc -luhd -lboost_system
// or
// g++ -DONE -o /tmp/channels channels.cc -luhd -lboost_system
// or
// g++ -DBOTH -o /tmp/channels channels.cc -luhd -lboost_system

#include 

#include 
#include 

using ::boost::uint32_t;
using ::std::cout;
using ::std::vector;

using uhd::rfnoc::radio_ctrl;

constexpr double kTimeout_sec = 20;
constexpr int kSPP = 1000;

void Report(int samples_read, const uhd::rx_metadata_t &md) {
  cout << "Read : " << samples_read
   << " sample\n Metadata is: " << md.to_pp_string(false) << "\n";
}

int main(int argc, char *argv[]) {
  uhd::device3::sptr usrp = uhd::device3::make(std::string(argv[1]));
  int samples_to_read = 10;
  uhd::device_addr_t streamer_args(std::string(""));
  uhd::stream_args_t stream_args("sc16", "sc16");

#ifdef ZERO
  uhd::rfnoc::block_id_t radio_ctrl_id0(0, "Radio");
  radio_ctrl::sptr radio0 =
usrp->get_block_ctrl(radio_ctrl_id0);
  radio0->set_arg(std::string("spp"), kSPP);
  streamer_args["block_id"] = radio_ctrl_id0.to_string();
  stream_args.channels = {0};
  vector> buffs(1, vector(samples_to_read));
#endif

#ifdef ONE
  uhd::rfnoc::block_id_t radio_ctrl_id1(0, "Radio", 1);
  radio_ctrl::sptr radio1 =
usrp->get_block_ctrl(radio_ctrl_id1);
  radio1->set_arg(std::string("spp"), kSPP);
  streamer_args["block_id"] = radio_ctrl_id1.to_string();
  stream_args.channels = {1};
  vector> buffs(1, vector(samples_to_read));
#endif

#ifdef BOTH
  uhd::rfnoc::block_id_t radio_ctrl_id0(0, "Radio");
  uhd::rfnoc::block_id_t radio_ctrl_id1(0, "Radio", 1);
  radio_ctrl::sptr radio0 =
usrp->get_block_ctrl(radio_ctrl_id0);
  radio_ctrl::sptr radio1 =
usrp->get_block_ctrl(radio_ctrl_id1);
  radio0->set_arg(std::string("spp"), kSPP);
  radio1->set_arg(std::string("spp"), kSPP);
  streamer_args["block_id0"] = radio_ctrl_id0.to_string();
  streamer_args["block_id1"] = radio_ctrl_id1.to_string();
  stream_args.channels = {0, 1};
  vector> buffs(2, vector(samples_to_read));
#endif

  stream_args.args = streamer_args;
  streamer_args["block_port"] = std::string("0");
  stream_args.args["spp"] = boost::lexical_cast(kSPP);
  uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);
  uhd::stream_cmd_t
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
  stream_cmd.stream_now = true;
  rx_stream->issue_stream_cmd(stream_cmd);
  vector buff_ptrs;
  for (auto &b : buffs) buff_ptrs.push_back(b.data());

  uhd::rx_metadata_t md;
  int samples_read =
  rx_stream->recv(buff_ptrs, samples_to_read, md, kTimeout_sec);
  Report(samples_read, md);
  stream_cmd.stream_mode = uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS;
  stream_cmd.stream_now = true;
  rx_stream->issue_stream_cmd(stream_cmd);
  return EXIT_SUCCESS;
}


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

Re: [USRP-users] Question regarding the term "wrt A/D full scale" on OpenBTS

[Nick Foster via USRP-users]

Neither. It will depend on the gain setting and individual variation in the
device. It is not calibrated to any specific dBm value and if you require
dBm you must calibrate your readings against a known source. The listed
maximum power figure is a maximum to avoid damage to the device.

Nick

On Mon, May 21, 2018 at 10:35 AM oscar llerena via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone
>
> On the following OpenBTS parameter:
>
> OpenBTS> devconfig GSM.Radio.RSSITarget
> GSM.Radio.RSSITarget -50 [default]
> - description:  Target uplink RSSI (Received Signal Strength
> Indication) for MS power control loop, in dB wrt to A/D full scale.
>
> The description indicates that the RSSI value is minus 50 dB with respect
> to the A/D full scale. Now, according to Ettus on link [1] the USRP B210
> has a maximum input power of 0 dBm, although other sources [2] state that
> maximum input power is -15dBm. In this case, which dBm power level will
> mean the term "with respect to A/D full scale".
>
> Thanks
>
> [1] https://kb.ettus.com/B200/B210/B200mini/B205mini
> [2] https://files.ettus.com/manual/page_usrp_b200.html
>
>
> --
> Oscar Llerena
> Tlf: 997575596
> ___
> 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] RFNoC FPGA clear_tx_seqnum behavior

[Ashish Chaudhari via USRP-users]

Hi EJ,

Sorry for the delay here. From the FPGA's perspective if you have
something streaming between one set of blocks and then you start
streaming a different application on another set of previously unused
blocks, then the current clear implementation should still work as
long as the new application does not interfere with the first one.
However, to ensure that nothing interferes, we need an overarching UHD
session that can manage the network and has global knowledge. That is
currently not possible with two different gnuradio apps. Going
forward, it is unlikely that we will support two UHD sessions talking
to the same radio but I can see a case where we might have two
gnuradio applications talking to the same UHD session somehow. We will
consider that for the RFNoC roadmap.

Thanks,
Ashish

On Thu, May 3, 2018 at 4:42 PM, EJ Kreinar  wrote:
>
> Hi Ashish,
>
> Awesome! Thanks for clarifying.
>
> Just a thought here...
>
> >If you download an FPGA image, run flow
> >graph A, then without reloading the image you want to run flow graph B
> >with a different topology then the clear signal will ensure that
> >things are cleaned up properly between A and B. Do you really have to
> >switch applications to reconfigure the topology? In theory, no, but we
> >have some work to do on the graph resolution side in software to allow
> >changing the topology on the fly. That feature isn't as high a
> >priority because it is simple enough to just tear down and recreate
> >the graph/device3 in UHD.
>
> I'm not "here" yet, but I (eventually) have a requirement to run rfnoc 
> applications independently and simultaneously on an N310-like device. For 
> example: initialize one gnuradio application attached to one of the 
> noc_block_radios (basically tb.start()) , and then reconfigure a few of the 
> unused rfnoc blocks to bring up and down *different* gnuradio applications 
> using the second noc_block_radio and likely other noc_blocks, while the first 
> application is still streaming.
>
> It looks to me like the fundamental fpga architecture should be able to run 
> this sort of application, but are you saying the current "clear" operations 
> in software will get in the way as-is?
>
> If so, I will be happy to help work on this feature in the next 1-6 months.
>
> Thanks!!
>
> EJ
>
> On Thu, May 3, 2018, 7:28 PM Ashish Chaudhari  
> wrote:
>>
>> Hi EJ,
>>
>> On Thu, May 3, 2018 at 5:06 AM, EJ Kreinar  wrote:
>> > Hi Ashish,
>> >
>> > Thanks for the info about rfnoc changes. Quick question:
>> >
>> >> In rfnoc, we make a
>> >> distinction between reset and clear. A "reset" is meant to reset
>> >> everything in a module to the power-up state. A "clear" only resets
>> >> things that are not software controlled, like settings regs. The
>> >> expectation is that you can configure your block, clear it to re-arm
>> >> packet processing engines, etc and still preserve the settings you
>> >> configured.
>> >
>> > Can you elaborate a little more? I understand that we want reset signal to
>> > reset everything. But in your "cear" example, I expect that settings regs
>> > *are* software controlled (configured via block constructor, for example),
>> > and therefore we would not want them cleared.
>> >
>> > ... As I type this, I realize that is probably what you intended from the
>> > original sentence. Is that correct??
>>
>> Yes, that is correct.
>>
>> > Thanks! Also very interested in hearing updates from Brian's questions...
>>
>> I just responded. Feel free to chime in if you have any follow ups.
>>
>> >
>> > EJ
>> >
>> > On Wed, May 2, 2018 at 7:15 PM, Brian Padalino via USRP-users
>> >  wrote:
>> >>
>> >> Hey Ashish,
>> >>
>> >> On Wed, May 2, 2018 at 7:02 PM Ashish Chaudhari
>> >>  wrote:
>> >>>
>> >>> Hi Brian,
>> >>>
>> >>> >> > Moreover, it seems like axi_wrapper.v uses clear_tx_seqnum to pass
>> >>> >> > out
>> >>> >> > config bus messages, so now that clear_tx_seqnum is set I am not
>> >>> >> > able to
>> >>> >> > use
>> >>> >> > the config bus from the axi_wrapper.
>> >>> >>
>> >>> >> I think this is a side effect of the assumption that data cannot flow
>> >>> >> through the block when it is not in a graph. The AXI-Stream config bus
>> >>> >> uses clear_tx_seqnum to hold itself in reset to you cannot use that
>> >>> >> either when the data-path is disabled. Do you need to use the config
>> >>> >> bus before you connect your block downstream? If so, you can try (as a
>> >>> >> debugging step) to tied the clear signal to 0 here:
>> >>> >>
>> >>> >>
>> >>> >> https://github.com/EttusResearch/fpga/blob/rfnoc-devel/usrp3/lib/rfnoc/axi_wrapper.v#L200.
>> >>> >> If that makes your block work then it would confirm that the
>> >>> >> aforementioned assumption is breaking your block. If so, we will go
>> >>> >> back re-evaluate if we need to apply the clear_tx_seqnum to just the
>> >>> >> data path and leave the control path alone.
>> >>> >
>> >>> >
>> >>> > I re-created the old strobe methodology and fed that version into
>> >>> >