Re: [USRP-users] Enable AGC in USRP E320 with RFNoC using GNURadio

[Julian Arnold via USRP-users]

Maria,

So, if I understand correctly, I have to put there also something like 
"self.ettus_rfnoc_rx_radio_0.set_rx_agc(enable,0)" isn't it?


Exactly! Take a look at [1] for the correct syntax.

[1] 
https://github.com/EttusResearch/gr-ettus/blob/1038c4ce5135a2803b53554fc4971fe3de747d9a/include/ettus/rfnoc_rx_radio.h#L97


Let me know if that worked out for you.

Cheers,
Julian


On 3/10/21 9:59 AM, Maria Muñoz wrote:

Hi Julian,

Thanks for the quick answer.

I think you might be right about the possible bug turning on the AGC 
from GRC. I have checked the flow graph generated and there's no 
set_rx_agc enable option (I checked the c++ definition block where this 
option did appear but I hadn't look at the python generated).


The lines related to the radio in my flowgraph are these:

/self.ettus_rfnoc_rx_radio_0 = ettus.rfnoc_rx_radio(
             self.rfnoc_graph,
             uhd.device_addr(''),
             -1,
             -1)
         self.ettus_rfnoc_rx_radio_0.set_rate(samp_rate)
         self.ettus_rfnoc_rx_radio_0.set_antenna('RX2', 0)
         self.ettus_rfnoc_rx_radio_0.set_frequency(cf, 0)
         self.ettus_rfnoc_rx_radio_0.set_gain(gain, 0)
         self.ettus_rfnoc_rx_radio_0.set_bandwidth(samp_rate, 0)
         self.ettus_rfnoc_rx_radio_0.set_dc_offset(True, 0)
         self.ettus_rfnoc_rx_radio_0.set_iq_balance(True, 0)/

So, if I understand correctly, I have to put there also something like 
"self.ettus_rfnoc_rx_radio_0.set_rx_agc(enable,0)" isn't it?


Kind Regards,

Maria

El mié, 10 mar 2021 a las 9:16, Julian Arnold (>) escribió:


Maria,

I might not be the right person to answer this, as my experience with
UHD 4.0 is relatively limited at the moment.

However, I cant tell you that the AGC on B2x0 devices is controlled via
software (using set_rx_agc()). There is no need to directly modify the
state of any pins of the FPGA.

I vaguely remember that there was a bug in an earlier version of gr-uhd
(somewhere in 3.7) that made it difficult to turn on the AGC using GRC.
That particular one is fixed in gr-uhd. Not sure about gr-ettus, though.

Maybe try using set_rx_agc() manually in you flow-graph (*.py) and see
if that helps.

Cheers,
Julian

On 3/9/21 5:11 PM, Maria Muñoz via USRP-users wrote:
 > Hi all,
 >
 > I was wondering if it is possible to enable AGC from the RFNoC radio
 > block in GNURadio. I use UHD 4.0 version and GNURadio 3.8 with
gr-ettus.
 >
 > I see that the RFNoC Rx radio block has an enable/disable/default
AGC
 > option in the GNURadio block which I assume calls the UHD function
 > "set_rx_agc"
 >

(https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#abdab1f6c3775a9071b15c9805f866486)
 >
 > I have also checked on the FPGA side that there is a pin from
FPGA to
 > AD9361 called XCVR_ENA_AGC which is set always to 1 on the top
level of
 > the FPGA image (see attached file "e320.v", line 872). This pin,
 > according to
 >

https://www.analog.com/media/en/technical-documentation/data-sheets/AD9361.pdf

 > is the "Manual Control Input for Automatic Gain Control (AGC)".
 > Must be this pin set to 0 to have AGC working?
 > If not, how can I get AGC working? I've made some tests
 > enabling/disabling this option but I do not see any changes
between the
 > waveforms received.
 >
 > Any help would be appreciated.
 >
 > Kind Regards,
 >
 > Maria
 >
 > ___
 > 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] Enable AGC in USRP E320 with RFNoC using GNURadio

[Julian Arnold via USRP-users]

Maria,

I might not be the right person to answer this, as my experience with 
UHD 4.0 is relatively limited at the moment.


However, I cant tell you that the AGC on B2x0 devices is controlled via 
software (using set_rx_agc()). There is no need to directly modify the 
state of any pins of the FPGA.


I vaguely remember that there was a bug in an earlier version of gr-uhd 
(somewhere in 3.7) that made it difficult to turn on the AGC using GRC.

That particular one is fixed in gr-uhd. Not sure about gr-ettus, though.

Maybe try using set_rx_agc() manually in you flow-graph (*.py) and see 
if that helps.


Cheers,
Julian

On 3/9/21 5:11 PM, Maria Muñoz via USRP-users wrote:

Hi all,

I was wondering if it is possible to enable AGC from the RFNoC radio 
block in GNURadio. I use UHD 4.0 version and GNURadio 3.8 with gr-ettus.


I see that the RFNoC Rx radio block has an enable/disable/default AGC 
option in the GNURadio block which I assume calls the UHD function 
"set_rx_agc" 
(https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#abdab1f6c3775a9071b15c9805f866486)


I have also checked on the FPGA side that there is a pin from FPGA to 
AD9361 called XCVR_ENA_AGC which is set always to 1 on the top level of 
the FPGA image (see attached file "e320.v", line 872). This pin, 
according to 
https://www.analog.com/media/en/technical-documentation/data-sheets/AD9361.pdf 
is the "Manual Control Input for Automatic Gain Control (AGC)".

Must be this pin set to 0 to have AGC working?
If not, how can I get AGC working? I've made some tests 
enabling/disabling this option but I do not see any changes between the 
waveforms received.


Any help would be appreciated.

Kind Regards,

Maria

___
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] Receiving on multiple subdevs using USRP B210

[Julian Arnold via USRP-users]

Saptarshi,

Ok, I see, you did not set set analog filter bandwidth of your USRP to 5 
MHz but your signal has 5 MHz bandwidth. This, in combination with the 
20 MHz MCR should then be absolutely fine.


I'm still not sure how you are trying to detect your signal. Maybe you 
could share the relevant parts of you flow-graph here?


I just tested what I thing you are doing (see attached image of 
flow-graph) and as far as I can tell, it is working as expected.
I'm feeding in a tone at 2.48 GHz on channel A and a tone at 2.475 GHz 
on channel B. After the message strobe triggered

(pmt.to_pmt({"chan":0, "lo_freq":2.475e9, "dsp_freq": -5e6}))
I receive both tones just fine.
I'm using GNU Radio 3.8.2 and UHD 3.15.

Cheers,
Julian


On 12/9/20 7:03 PM, saptarshiv2ha...@gmail.com wrote:

Hi Julian,

Thanks for your reply.
I am basically trying to receive signals of BW 5MHz at two different centre 
frequencies (2.475GHz and 2.48GHz) using the two subdevs of the B210.

The master clock rate gets set to 20MHz which makes me assume that the analog 
bandwidth for the USRP source is 20 MHz.
With a centre frequency of 2.475GHz, it should cover from 2.465GHz to 2.485GHz.

The main problem I have difficulty understanding is why it works in Case 1 and 
why it behaves randomly in Case 2.

Thanks,
Saptarshi


On 9 Dec 2020, at 15:49, Julian Arnold  wrote:

Saptarshi,

I'm not entirely sure I fully understand what you are doing. You probably need 
to provide some more details.

However, in general, depending on what you master-clock-rate is,
doing a 5MHz shift in the DSP does not make much sense if your
sample-rate and your analog bandwidth are only 5 MHz. There is just no signal 
at your 5MHz offset you could possibly shift down to base-band.

Cheers,
Julian

On 12/9/20 10:41 AM, Saptarshi Hazra via USRP-users wrote:

Hi,
I am trying to receive on two different centre frequencies (2.475e9 and 2.48e9) 
using the two receiver chains on B210. Since they are close by, I thought  can 
receive them by setting the “dsp_freq” parameter.
Case 1:
Subdev: A:A or A:B
Nchannel : 1
Centre Frequency: 2.475e9
Sampling Rate: 5e6
BW: 5e6
If I use the command port the USRP source block to pass a pmt dictionary:
pmt.to_pmt({“lo_freq”:2.475e9, “dsp_freq”: -5e6})
I am able to receive radio packets sent by nodes on 2.48e9 Hz
Case 2:
Subdev: A:A  A:B
Nchannel : 2
Sampling Rate: 5e6
Centre Frequency 1: 2.475e9
Centre Frequency 2: 2.475e9
BW: 5e6
I use the pmt dictionary:
pmt.to_pmt({“chan”:0, “lo_freq”:2.475e9, “dsp_freq”: -5e6})
When I do this sometimes I receive data from nodes transmitting on 2.48e9Hz.  
and sometimes on 2.475Hz. The behaviour becomes entirely random.
I would really appreciate any help in figuring out how to receive 
simultaneously on these two centre frequencies.
Thanks,
Saptarshi
___
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] Receiving on multiple subdevs using USRP B210

[Julian Arnold via USRP-users]

Saptarshi,

I'm not entirely sure I fully understand what you are doing. You 
probably need to provide some more details.


However, in general, depending on what you master-clock-rate is,
doing a 5MHz shift in the DSP does not make much sense if your
sample-rate and your analog bandwidth are only 5 MHz. There is just no 
signal at your 5MHz offset you could possibly shift down to base-band.


Cheers,
Julian

On 12/9/20 10:41 AM, Saptarshi Hazra via USRP-users wrote:

Hi,

I am trying to receive on two different centre frequencies (2.475e9 and 
2.48e9) using the two receiver chains on B210. Since they are close by, 
I thought  can receive them by setting the “dsp_freq” parameter.


Case 1:

Subdev: A:A or A:B
Nchannel : 1
Centre Frequency: 2.475e9
Sampling Rate: 5e6
BW: 5e6

If I use the command port the USRP source block to pass a pmt dictionary:

pmt.to_pmt({“lo_freq”:2.475e9, “dsp_freq”: -5e6})


I am able to receive radio packets sent by nodes on 2.48e9 Hz

Case 2:

Subdev: A:A  A:B
Nchannel : 2
Sampling Rate: 5e6
Centre Frequency 1: 2.475e9
Centre Frequency 2: 2.475e9
BW: 5e6

I use the pmt dictionary:

pmt.to_pmt({“chan”:0, “lo_freq”:2.475e9, “dsp_freq”: -5e6})



When I do this sometimes I receive data from nodes transmitting on 
2.48e9Hz.  and sometimes on 2.475Hz. The behaviour becomes entirely random.
I would really appreciate any help in figuring out how to receive 
simultaneously on these two centre frequencies.


Thanks,
Saptarshi

___
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] Direction finding based on USRP E310 board

[Julian Arnold via USRP-users]

Ivan,

to the best of my knowledge, there should not be any RX1 port.
Instead, you should have two (coherent) channels "A" and "B" both 
allowing you to select one out of two available antenna ports when 
receiving ("TX/RX" or "RX2").


Cheers,
Julian

On 11/18/20 10:31 AM, Ivan Zahartchuk via USRP-users wrote:


Another question of interest is which channels are coherent? Rx1 and RX2 
or RX1 and RX / TX?


вт, 17 нояб. 2020 г. в 01:56, Ivan Iudice >:


Right!
Be careful, DOA estimation using only 2 antennas works but it’s not
so accurate.
Enjoy!

Ivan

 > Il giorno 17 nov 2020, alle ore 00:35, Ivan Zahartchuk
mailto:adray0...@gmail.com>> ha scritto:
 >
 > 
 >
 >
 >
 > That is, in theory, I can simply start two streams from two
channels and further process them using certain direction finding
algorithms?
 >
 >


___
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] List of filters and where they are located

[Julian Arnold via USRP-users]

David,

unfortunately not. The filter API does only export the filters internal 
to the AD9361 on B2xx series devices.
However, if you let MCR = sample rate you should basically only have 
filters inside the AD9361 active.


Cheers,
Julian

On 8/26/20 6:16 AM, David Carsenat wrote:

Ok thanks a lotJulian, this is very helpful.
Does your example allow to list FPGA filters also ?

Le mar. 25 août 2020 à 21:57, Julian Arnold > a écrit :


David,

take a look at the ad9361 user guide [1]. It has all the information
you
are looking for.

If you want to know which filters you can configure and how, take a
look
at [2]. It's a simple example I wrote quite a while back but it should
still be good to get you started.

Hope that helps!

Cheers,
Julian

[1]

https://form.analog.com/Form_Pages/Catalina/CatalinaDesign.aspx?prodid=AD9361
[2] https://github.com/jarn0ld/uhd-filter-tool

On 8/25/20 9:09 PM, David Carsenat via USRP-users wrote:
 > Hi, I am using a B205 and I'd just like to know what are the
 > difference filter stages (analog and digital) seen by the signal
(both
 > Tx and Rx), in the AD936x and in the FPGA.
 > Another way to help me, should be to have a description of the
filter
 > that I can address with the filter.hpp functions : Can I address and
 > change filters behaviours that are part only on FPGA or also the
AD9361
 > filters ?
 >
 > Many thanks
 >
 > David
 >
 >
 >
 >
 > ___
 > 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] List of filters and where they are located

[Julian Arnold via USRP-users]

David,

take a look at the ad9361 user guide [1]. It has all the information you 
are looking for.


If you want to know which filters you can configure and how, take a look 
at [2]. It's a simple example I wrote quite a while back but it should 
still be good to get you started.


Hope that helps!

Cheers,
Julian

[1] 
https://form.analog.com/Form_Pages/Catalina/CatalinaDesign.aspx?prodid=AD9361

[2] https://github.com/jarn0ld/uhd-filter-tool

On 8/25/20 9:09 PM, David Carsenat via USRP-users wrote:
Hi, I am using a B205 and I'd just like to know what are the 
difference filter stages (analog and digital) seen by the signal (both 
Tx and Rx), in the AD936x and in the FPGA.
Another way to help me, should be to have a description of the filter 
that I can address with the filter.hpp functions : Can I address and 
change filters behaviours that are part only on FPGA or also the AD9361 
filters ?


Many thanks

David




___
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] E310 filter settings and LO lock question

[Julian Arnold via USRP-users]

Jorn,

while tuning, samples will continue to flow from the device to your host 
(if your recv loop is running in a separate thread).
However, while UHD is processing your call to 'set_rx_freq' there will 
be some transient behavior visible in the received samples.
Thus, you should probably discard all received samples while waiting for 
'set_rx_freq' to finish.


The tuning process on the E310/B210 is actually relatively involved 
(calibration wise). The front-end IC has to perform calibration of 
several stages when changing frequency. Some of those calibration steps 
only happen every 100 MHz which is why you will notice that some calls 
to 'set_rx_freq' will take considerably longer than others.


While 'set_rx_freq' is blocking during this calibration process, there 
are other parts in the front-end that might (depending on you input) 
take some more time to settle (the DC offset and IQ imbalance 
correction, for example).
So it's not a bad idea to give the device some extra time after 
'set_rx_freq' is done before processing samples again.


Hope this helps. Let me know if you have any further questions.
Cheers,
Julian

On 16.09.19 15:38, Skorstad,Jørn via USRP-users wrote:

Many thanks for your answers. Do you know if the E310 will halt the data stream 
while changing filter/frequency, or do I need to take this into account in the 
software while changing frequencies?


Jorn,

regarding your other question, filter selection on the E310 is handled by UHD, 
internally.

Cheers,
Julian

On 15.09.19 20:54, Marcus D Leech via USRP-users wrote:

My recollection is that the AD9361 RF chip doesn’t have an external lock 
indicator.

Sent from my iPhone


On Sep 15, 2019, at 9:17 AM, Skorstad,Jørn via USRP-users 
 wrote:

Hi all,



I am currently working on a project using a USRP E310 to output an FFT plot 
over a given frequency range (usually bigger than the possible sample rate). 
The program is written in C++ using the UHD library. Frequency range is 
achieved by changing the LO frequency regularly. The program seems to work, 
however I have two questions I can’t find the answer to in the UHD manual:



The E310 has analog filters on the RX and TX ports. The documentation is a 
little short on how these filters are controlled. Are they selected 
automatically based on the LO frequency, or do they need to be manually 
selected? If so, how? And what would be the (estimated) changeover time between 
filters?



LO lock – I tried to detect if LO is locked after a tune request using the UHD 
manual as a reference. If I include the following directly after a tune request 
nothing is printed:

   while (!usrp->get_rx_sensor("lo_locked").to_bool()) std::cout <<
"PLL unlocked!" << std::endl;



Is there some other way to detect LO lock?



Regards,

Jorn

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


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


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



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

Re: [USRP-users] E310 filter settings and LO lock question

[Julian Arnold via USRP-users]

Jorn,

regarding your other question, filter selection on the E310 is handled 
by UHD, internally.


Cheers,
Julian

On 15.09.19 20:54, Marcus D Leech via USRP-users wrote:

My recollection is that the AD9361 RF chip doesn’t have an external lock 
indicator.

Sent from my iPhone


On Sep 15, 2019, at 9:17 AM, Skorstad,Jørn via USRP-users 
 wrote:

Hi all,



I am currently working on a project using a USRP E310 to output an FFT plot 
over a given frequency range (usually bigger than the possible sample rate). 
The program is written in C++ using the UHD library. Frequency range is 
achieved by changing the LO frequency regularly. The program seems to work, 
however I have two questions I can’t find the answer to in the UHD manual:



The E310 has analog filters on the RX and TX ports. The documentation is a 
little short on how these filters are controlled. Are they selected 
automatically based on the LO frequency, or do they need to be manually 
selected? If so, how? And what would be the (estimated) changeover time between 
filters?



LO lock – I tried to detect if LO is locked after a tune request using the UHD 
manual as a reference. If I include the following directly after a tune request 
nothing is printed:

  while (!usrp->get_rx_sensor("lo_locked").to_bool()) std::cout << "PLL unlocked!" 
<< std::endl;



Is there some other way to detect LO lock?



Regards,

Jorn

___
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] B210 bypass Tx FIR filter

[Julian Arnold via USRP-users]

Sean,

if I remember correctly, the filter configuration (whether or not a filter is 
bypassed) is determined by the ratio of DAC rate to master-clock rate (the 
interpolation that needs to happen inside the ad9361) thus, you can only 
somewhat,
indirectly, control it by changing the master-clock rate.

However, if you can live with the interpolation inside the FIR, you can 
reprogram the fir taps to whatever suits your needs.

For examples take a look at:

https://github.com/jarn0ld/uhd-filter-tool

Hope that helps.

Cheers,
Julian

Julian Arnold, M.Sc

> On 10. Apr 2019, at 22:30, S Hamilton via USRP-users 
>  wrote:
> 
> We'd like to bypass the Tx FIR filter and I'm wondering how to go about this 
> using the C++ api.
> For the filter_base_info class there is the is_bypassed() function to read 
> the state, but no function to set it.
> Should we be creating a new filter pointer with bypass set, and then using it 
> to overwrite the filter via uhd::usrp::multi_usrp::set_filter ?
> Does anyone have some sample code that sets the bypass on FIR or HB1/HB2 ?
> 
> Thanks,
> Sean Hamilton
> ___
> 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] Rssi reading on b205/b210

[Julian Arnold via USRP-users]

Hey, 

Since release 3.8.2 the RSSI is exposed as a frontend sensor.
You should be able to read it using the usual sensor read-back mechanism
(look at get_rx_senor_names and get_rx_sensor())

Cheers,
Julian

> On 21. Sep 2018, at 17:04, Chintan Patel via USRP-users 
>  wrote:
> 
> Hi,
> 
> Is there a function/script in the uhd driver to read the rssi for the 
> b205/b210?
> 
> Thanks
> ___
> 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] Time alignment failure for four channels coherent receiver in X310

[Julian Arnold via USRP-users]

Hey,

have you tried starting the RX streamer a little bit in the future, i.e 
change the following lines:


stream_cmd.stream_now = true;
stream_cmd.time_spec = uhd::time_spec_t();

to something like (out of the top of my head):

stream_cmd.stream_now = false;
stream_cmd.time_spec = usrp->get_time_now() + 0.05;

?

I have seen the same behavior on my B210 in dual channel RX setups when 
starting the streamer immediately. So maybe this helps.


Cheers,
Julian

On 29.07.2018 21:23, Jack Yang via USRP-users wrote:

Hi Marcus,

Even I used 1Msps or less than this sampling rate, I still saw this time 
alignment issue. When I am using GNURadio system with python script 
instead of using UHD API, I can run 10Msps for my 4 channel phase array 
receiver without any problems. My final goal is to have 50Msps for my 4 
channel phase array receiver with dual 10 GiGe cable setup and CDUA 
computation for wideband AoA detection. My desktop spec is Processors: 
Intel Core i9 7900X 10-Core 3.3GHz (4.3GHz TurboBoost), Memory: 32GB 
ORIGIN PC DDR4 Powered by Kingston 3000MHz (4 X 8GB),.


Thanks!

All Best,
Jack






On Sun, Jul 29, 2018 at 11:59 AM, Marcus D. Leech > wrote:


On 07/29/2018 12:56 PM, Jack Yang wrote:

Hi Marcus,

Thanks for your mail. Yes, I am using 10GiGe interface to run the
UHD C++ code.
Any thoughts or suggestions?

All Best,
Jack

On Sun, Jul 29, 2018 at 9:35 AM, Marcus D. Leech via USRP-users
mailto:usrp-users@lists.ettus.com>>
wrote:

On 07/29/2018 12:52 AM, Jack Yang via USRP-users wrote:

Hi,

I have rewrote "rx_samples_to_file.cpp" for making four
channel coherent receiver (phased-array receiver) in X310.
When I executed my code, the terminal showed that

*[ERROR] [STREAMER] The receive packet handler failed to
time-align packets. 1002 received packets were processed by
the handler. However, a timestamp match could not be determined.*

I have attached my code as the following link

(https://www.dropbox.com/s/x0u0tw5e65iaual/rx_samples_X310_TwinRx.cpp?dl=0

).
The info for my UHD version is shown in below
*"[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609;
Boost_105800; UHD_3.11.0.HEAD-0-ga1b5c4ae"*

Could someone guide me how to fix this issue? I am using two
TwinRx with a X310 for my coherent receiver. I basically
followed gr-doa python configuration to set up the USRP
device in C++ code. However, I cannot find out why the time
alignment is failed in here.

The detailed print-out message is also listed here

Thanks!

All Best,
Jack

Creating the usrp device with: addr=192.168.40.2...
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609;
Boost_105800; UHD_3.11.0.HEAD-0-ga1b5c4ae
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Determining maximum frame size...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Setup basic communication...
[INFO] [X300] Loading values from EEPROM...
[INFO] [X300] Setup RF frontend clocking...
[INFO] [X300] Radio 1x clock:200
[INFO] [RFNOC DMA FIFO] Running BIST for FIFO 0...
[INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1299 MB/s)
[INFO] [RFNOC DMA FIFO] Running BIST for FIFO 1...
[INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1316 MB/s)
[WARNING] [RFNOC] [0/Radio_0] defines 2 input buffer sizes,
but 1 input ports
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[WARNING] [RFNOC] [0/Radio_1] defines 2 input buffer sizes,
but 1 input ports
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
Using Device: Single USRP:
Device: X-Series Device
Mboard 0: X310
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: TwinRX RX0
RX Channel: 1
RX DSP: 1
RX Dboard: A
RX Subdev: TwinRX RX1
RX Channel: 2
RX DSP: 0
RX Dboard: B
RX Subdev: TwinRX RX0
RX Channel: 3
RX DSP: 1
RX Dboard: B
RX Subdev: TwinRX RX1
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: Unknown (0x0094) - 0
TX Channel: 1
TX DSP: 0
TX Dboard: B
TX Subdev: Unknown (0x0094) - 0

Setting RX Rate: 10.00 Msps...
Actual RX Rate: 10.00 Msps...

[INFO] 

Re: [USRP-users] B210 -- AD9361 low-level access and changing filter configuration

[Julian Arnold via USRP-users]

Hey,

In case you haven't already adopted the straight forward approach mentioned by
Sylvain I just dug out the tool I mentioned and moved
it to my github account [1].

I quickly compiled and linked against a recent version of UHD (3.9.6) to 
confirm that it still works.

Build as usual:
mkdir build
cd build
cmake ..
make

You can then run the "main" program as follows:

./main --list

to see a list of all available filters with their corresponding paths.
Then, you can write new filter coefficients with:

./main --write_fir --path=
e.g.:
./main --write_fir --path=/mboards/0/dboards/A/rx_frontends/A/filters/FIR_1

this will update the coefficients of FIR_1 and then read the filter again to 
check if the coefficients have been updated.
However, the tool is definitely not polished in any way and does not check 
whether or not the new coefficients actually take effect. 
If they still don't then let me know and I'll try to create a more complete 
example application.

[1] https://github.com/jarn0ld/uhd-filter-tool

Cheers,
Julian

On Tuesday, September 12, 2017 5:16:56 PM CEST Sylvain Munaut wrote:
> Personally I'm using a patched UHD where I expose the SPI device :
> 
> 
> diff --git a/host/lib/usrp/b200/b200_impl.cpp
> b/host/lib/usrp/b200/b200_impl.cpp index a513e1336..01c1e3b51 100644
> --- a/host/lib/usrp/b200/b200_impl.cpp
> +++ b/host/lib/usrp/b200/b200_impl.cpp
> @@ -549,6 +549,8 @@ b200_impl::b200_impl(const uhd::device_addr_t&
> device_addr, usb_device_handle::s
>  _adf4001_iface = boost::make_shared(_spi_iface);
> }
> 
> +_tree->create(mb_path / ("spi")).set(_spi_iface);
> +
>  
>  // Init codec - turns on clocks
>  
> 
> 
> Then in my code I can get the SPI object :
> 
> uhd::spi_iface::sptr spi =
> usrp->get_device()->get_tree()->access("/mboards/0/spi
> ").get();
> 
> and use read_spi / write_spi to control any register I want.
> 
> 
> Cheers,
> 
> Sylvain


-- 
Julian Arnold, M.Sc.

Institute for Networked Systems
RWTH Aachen University
Kackertstrasse 9
52072 Aachen
Germany

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

Re: [USRP-users] B210 -- AD9361 low-level access and changing filter configuration

[Julian Arnold via USRP-users]

Hey Rob,

I remember creating a small example tool to use the filter API and to write to 
the RX FIR. 
If you can wait till the evening I'll dig it out at home and share it with you.

Cheers,
Julian

Julian Arnold, M.Sc
Institute for Networked Systems 
RWTH-Aachen University
Kackertstrasse 9
52072 Aachen
Germany

> On 12. Sep 2017, at 07:01, Rob Heig via USRP-users 
>  wrote:
> 
> Hi,
> 
> I have been playing a bit with the API of UHD and I wonder if it is possible 
> to have a low-level access to the underlying, low-level AD9361 API. In 
> effect, what I would love to do is to play with the filters (the RX FIR 
> filter in particular), but so far I haven't been that lucky (all I've managed 
> to do is to make the software crash badly).
> In particular, I have experimented a bit with the set_taps() function call 
> (after some very ugly casts), but either the system ignores it (re-reading 
> the coefficients shows me that they're all zeros), or it makes the 
> application crash (memory corruption).
> Can anyone point me to a good direction (besides the UHD manual), please?
> Thanks a lot in advance!
> RH
> ___
> 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] help with receivng multiple frequencies

[Julian Arnold via USRP-users]

Also, please don't open a new thread if you have already opened one for
the same issue ([USRP-users] Help with rx_multi_sample) that is waiting
for details from your side.

On 08/09/2017 05:40 PM, Marcus D. Leech via USRP-users wrote:
> On 08/09/2017 10:29 AM, Snehasish Kar via USRP-users wrote:
>>
>> Hi
>>
>> I am trying to receive multiple frequencies with one usro x310
>> separately from two daughter boards. But not able to receive it
>> properly. Below is my code. Please help me with it.
>>
> Could you describe what you mean by "not properly receive it"? 
>
>>
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include "../include/conf.hpp"
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> static bool stop_signal_called = false;
>> void sig_int_handler(int){
>> stop_signal_called = true;
>> }
>>
>> void startStreaming(uhd::rx_streamer::sptr rx_stream,
>> uhd::usrp::multi_usrp::sptr usrp){
>> //setup streaming
>> size_t total_num_samps = 1;
>> double seconds_in_future = 1.5;
>> std::cout << std::endl;
>> std::cout << boost::format(
>>   "Begin streaming %u samples, %f seconds in the future..."
>> ) % total_num_samps % seconds_in_future << std::endl;
>> uhd::stream_cmd_t stream_cmd((total_num_samps ==0)?
>> uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS:uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
>> stream_cmd.num_samps = size_t(total_num_samps);
>> stream_cmd.stream_now = true; //true
>> stream_cmd.time_spec = uhd::time_spec_t();
>> rx_stream->issue_stream_cmd(stream_cmd); //tells all channels to
>> stream
>>
>> //meta-data will be filled in by recv()
>> uhd::rx_metadata_t md;
>>
>> //allocate buffers to receive with samples (one buffer per channel)
>> const size_t samps_per_buff = rx_stream->get_max_num_samps();
>> std::vector >
>> buffs(usrp->get_rx_num_channels(), std::vector> >(samps_per_buff));
>>
>> //create a vector of pointers to point to each of the channel buffers
>> std::vector buff_ptrs;
>> for (size_t i = 0; i < buffs.size(); i++)
>> buff_ptrs.push_back([i].front());
>> double timeout = 3.0;//seconds_in_future + 0.1; //timeout (delay
>> before receive + padding)
>> size_t num_acc_samps = 0; //number of accumulated samples
>> while(num_acc_samps < total_num_samps){
>>  //receive a single packet
>>  size_t num_rx_samps = rx_stream->recv(buff_ptrs, samps_per_buff,
>> md, timeout);
>>  //use a small timeout for subsequent packets
>>  timeout = 0.1;
>>  //handle the error code
>>  if (md.error_code == uhd::rx_metadata_t::ERROR_CODE_TIMEOUT) break;
>>  if (md.error_code != uhd::rx_metadata_t::ERROR_CODE_NONE){
>>   throw std::runtime_error(str(boost::format("Receiver error %s")
>> % md.strerror()));
>>  }
>>  std::cout << boost::format("Received packet: %u samples, %u full
>> secs, %f frac secs") % num_rx_samps % md.time_spec.get_full_secs() %
>> md.time_spec.get_frac_secs() << std::endl;
>>   num_acc_samps += num_rx_samps;
>>  }
>>  if (num_acc_samps < total_num_samps) std::cerr << "Receive
>> timeout before all samples received..." << std::endl;
>>  //finished
>>  std::cout << std::endl << "Done!" << std::endl << std::endl;
>> }
>>
>> typedef boost::function
>> get_sensor_fn_t;
>>
>> bool check_locked_sensor(std::vector sensor_names, const
>> char* sensor_name, get_sensor_fn_t get_sensor_fn, double setup_time){
>> if (std::find(sensor_names.begin(), sensor_names.end(),
>> sensor_name) == sensor_names.end())
>> return false;
>>
>> boost::system_time start = boost::get_system_time();
>> boost::system_time first_lock_time;
>>
>> std::cout << boost::format("Waiting for \"%s\": ") % sensor_name;
>> std::cout.flush();
>>
>> while (true) {
>> if ((not first_lock_time.is_not_a_date_time()) and
>> (boost::get_system_time() > (first_lock_time +
>> boost::posix_time::seconds(setup_time
>> {
>> std::cout << " locked." << std::endl;
>> break;
>> }
>> if (get_sensor_fn(sensor_name).to_bool()){
>> if (first_lock_time.is_not_a_date_time())
>> first_lock_time = boost::get_system_time();
>> std::cout << "+";
>> std::cout.flush();
>> }
>> else {
>> first_lock_time = boost::system_time();//reset to
>> 'not a date time'
>>
>> if (boost::get_system_time() > (start +
>> boost::posix_time::seconds(setup_time))){
>> std::cout << std::endl;
>> throw std::runtime_error(str(boost::format("timed out
>> waiting for consecutive locks on sensor \"%s\"") % sensor_name));
>> }
>> std::cout << "_";
>> 

Re: [USRP-users] Help with rx_multi_sample

[Julian Arnold via USRP-users]

Hey,

it would be good if you could give a little bit more information.
How does your initialization look like?
How does your stream command look like?

Cheers,

On 08/07/2017 04:30 PM, Snehasish Kar wrote:
>
> Hey
>
> Thanks that worked, there was problem in
> initializing stream_args_rx.channels
>
>
> Now a new error is popping up. Can you please help with that.
>
>
>
> UHD Error:
> The receive packet handler failed to time-align packets.
> 1002 received packets were processed by the handler.
> However, a timestamp match could not be determined.
>
> BR
>
> Snehasish
>
> 
> *From:* Julian Arnold 
> *Sent:* Monday, August 7, 2017 5:42:55 PM
> *To:* Snehasish Kar; usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] Help with rx_multi_sample
>  
> Hey,
>
> how do you initialize your usrp and the streamer?
> Do you specify two channels when creating the streamer? E.g.:
>
> uhd::stream_args_t stream_args_rx("fc32", "sc16");
> stream_args_rx.channels = {0ul,1ul};
> this->rx_streamer = this->usrp->get_rx_stream(stream_args_rx);
>
> Cheers,
>
> On 08/07/2017 01:52 PM, Snehasish Kar wrote:
> >
> > But when I am setting so, I see only the LED of one daughter board
> > glowing. So it still receiving data from one daughter board. Please
> > help me with it.
> >
> >
> > BR
> >
> > Snehasish
> >
> > 
> > *From:* Julian Arnold 
> > *Sent:* Monday, August 7, 2017 4:46:14 PM
> > *To:* Snehasish Kar; usrp-users@lists.ettus.com
> > *Subject:* Re: [USRP-users] Help with rx_multi_sample
> > 
> > Hey Snehasish,
> >
> > it should be A:0 B:0 instead of 0:A 0:B.
> > E.g.: usrp->set_rx_subdev_spec(uhd::usrp::subdev_spec_t("A:0 B:0"));
> >
> > Cheers,
> > Julian
> >
> > On 08/07/2017 12:39 PM, Snehasish Kar via USRP-users wrote:
> > >
> > > Hello
> > >
> > >
> > > I tried setting subdev to subdev("0:A 0:B") as described in the
> > > example "rx_multi_samples" . But its giving me an error saying Invalid
> > > daughter-board frontend name : A. I am using NI USRP 2954R.
> > >
> > >
> > > Please help me with it.
> > >
> > >
> > > BR
> > >
> > > Snehasish
> > >
> > >
> > >
> > >
> > > ___
> > > USRP-users mailing list
> > > USRP-users@lists.ettus.com
> > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> > --
> > Julian Arnold, M.Sc.
> >
> > Institute for Networked Systems
> > RWTH Aachen University
> >
> > Kackertstrasse 9
> > 52072 Aachen
> > Germany
> >
>
> -- 
> Julian Arnold, M.Sc.
>
> Institute for Networked Systems
> RWTH Aachen University
>
> Kackertstrasse 9
> 52072 Aachen
> Germany
>

-- 
Julian Arnold, M.Sc.

Institute for Networked Systems
RWTH Aachen University

Kackertstrasse 9
52072 Aachen
Germany


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

Re: [USRP-users] Help with rx_multi_sample

[Julian Arnold via USRP-users]

Hey,

how do you initialize your usrp and the streamer?
Do you specify two channels when creating the streamer? E.g.:

uhd::stream_args_t stream_args_rx("fc32", "sc16");
stream_args_rx.channels = {0ul,1ul};
this->rx_streamer = this->usrp->get_rx_stream(stream_args_rx);

Cheers,

On 08/07/2017 01:52 PM, Snehasish Kar wrote:
>
> But when I am setting so, I see only the LED of one daughter board
> glowing. So it still receiving data from one daughter board. Please
> help me with it.
>
>
> BR
>
> Snehasish
>
> 
> *From:* Julian Arnold 
> *Sent:* Monday, August 7, 2017 4:46:14 PM
> *To:* Snehasish Kar; usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] Help with rx_multi_sample
>  
> Hey Snehasish,
>
> it should be A:0 B:0 instead of 0:A 0:B.
> E.g.: usrp->set_rx_subdev_spec(uhd::usrp::subdev_spec_t("A:0 B:0"));
>
> Cheers,
> Julian
>
> On 08/07/2017 12:39 PM, Snehasish Kar via USRP-users wrote:
> >
> > Hello
> >
> >
> > I tried setting subdev to subdev("0:A 0:B") as described in the
> > example "rx_multi_samples" . But its giving me an error saying Invalid
> > daughter-board frontend name : A. I am using NI USRP 2954R.
> >
> >
> > Please help me with it.
> >
> >
> > BR
> >
> > Snehasish
> >
> >
> >
> >
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> -- 
> Julian Arnold, M.Sc.
>
> Institute for Networked Systems
> RWTH Aachen University
>
> Kackertstrasse 9
> 52072 Aachen
> Germany
>

-- 
Julian Arnold, M.Sc.

Institute for Networked Systems
RWTH Aachen University

Kackertstrasse 9
52072 Aachen
Germany


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

Re: [USRP-users] Help with rx_multi_sample

[Julian Arnold via USRP-users]

Hey Snehasish,

it should be A:0 B:0 instead of 0:A 0:B.
E.g.: usrp->set_rx_subdev_spec(uhd::usrp::subdev_spec_t("A:0 B:0"));

Cheers,
Julian

On 08/07/2017 12:39 PM, Snehasish Kar via USRP-users wrote:
>
> Hello
>
>
> I tried setting subdev to subdev("0:A 0:B") as described in the
> example "rx_multi_samples" . But its giving me an error saying Invalid
> daughter-board frontend name : A. I am using NI USRP 2954R.
>
>
> Please help me with it.
>
>
> BR
>
> Snehasish
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-- 
Julian Arnold, M.Sc.

Institute for Networked Systems
RWTH Aachen University

Kackertstrasse 9
52072 Aachen
Germany


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