Re: [USRP-users] B205-mini GPIO

[Derek Kozel via USRP-users]

Hello Arun,

The gpio example is the first place to look for a reference.
https://github.com/EttusResearch/uhd/blob/master/host/examples/gpio.cpp

A description of the GPIO header on the B20xmini can be found here
http://files.ettus.com/manual/page_usrp_b200.html#b200_hw_ref_ext

Regards,
Derek

On Thu, Aug 30, 2018 at 7:43 PM, Arun kumar Verma via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi
>
> We brought B205mini recently and we want to use three GPIO to control some
> external device which require SPI interface, in the schematics the header
> mentioned is J5 for GPIO while website USRP Hardware Driver and USRP
> Manual: USRP B2x0 Series
>  is mentioning J6 as
> GPIO header. Can you please suggest some example source code for GPIO, so
> that we can incorporate in our software.
>
> Arun Verma
>
> USRP Hardware Driver and USRP Manual: USRP B2x0 Series
> 
>
>
> ___
> 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] [Discuss-gnuradio] USRP N200 issues and fault troubleshooting

[Derek Kozel via USRP-users]

Hi Ayaz,

This is a USRP question rather than a GNU Radio one so I've copied your
message over to the other list. If you're not a member of the usrp-users
mailing list you should join that so you can see the responses.

It looks like you have BasicRX and BasicTX daugtherboards installed, is
that correct? Those daughterboards expose the I and Q channels
independently to SMA connectors. You can read about how to use them in
different configurations on this page in the manual.
http://files.ettus.com/manual/page_dboards.html#dboards_basicrx

Regards,
Derek

On Thu, Aug 2, 2018 at 8:32 PM, Ayaz Mahmud  wrote:

> Hi,
>
>
>
> In addition, I have done the following troubleshooting steps as mentioned
> in the page:
>
>
>
> Fan spin (checked)
>
> Front Panel LEDs (D & F always ON), C (On while Receiving)
>
> Voltages : J105 (2.5v), J104 (3.3c), J107(1.2v) – all OK
>
> Did not found any other LED on motherboard ON except D202
>
>
>
> Thanks,
>
> Ayaz
>
>
>
> *From: *Ayaz Mahmud 
> *Sent: *Thursday, August 2, 2018 11:44 AM
> *To: *discuss-gnura...@gnu.org
> *Subject: *[Discuss-gnuradio] USRP N200 issues and fault troubleshooting
>
>
>
> Hello,
>
>
>
>1. *“uhd_usrp_probe” *(attached) gives the attached output, where I
>see the Antennas & Sensors field are showing blank. Is this normal (N200) ?
>Because for other devices I am using like B210 it shows the Antenna names.
>
>
>
>1. For testing purpose if I run the below command which gives error in
>antenna naming. But if I skip the (-A RX2) it runs without any error.
>
>
>
> *“uhd_fft –args “addr=192.168.10.2” -A RX2 -s 10e6 -g 10 -f 100e6”*
>
>
>
> Traceback (most recent call last):
>
>   File "/usr/local/bin/uhd_fft", line 448, in 
>
> main()
>
>   File "/usr/local/bin/uhd_fft", line 431, in main
>
> tb = uhd_fft(args)
>
>   File "/usr/local/bin/uhd_fft", line 128, in __init__
>
> self.setup_usrp(uhd.usrp_source, args)
>
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_app.py",
> line 156, in setup_usrp
>
> self.vprint("[ERROR] {} is not a valid antenna name for this USRP
> device!".format(ant))
>
> NameError: global name 'ant' is not defined
>
>
>
>1. To make sure if the receiver is working or not, I have designed a
>flow graph for fm radio. I can get a clear signal in my B210 device, but at
>the same configuration it just noise in N200.
>
>
>
> What should be my next step to troubleshoot ? Or how can I be sure that it
> is a faulty device?
>
>
>
> Thanks
>
> Ayaz
>
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> discuss-gnura...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Changing phase with TX->RX loopback

[Derek Kozel via USRP-users]

Hi Andreas,

The timekeeper lives inside of the Radio block. However, after looking more
into the code, the DUC and DDC do already read the timestamp data from the
CHDR packets. You could modify the DUC and DDC to use the timestamp data to
jump the phase accumulator's value to compensate for the idle time between
bursts. My experience is much more on the host side code, but if you do
choose to pursue this modification I think it could be of interest to
others on the mailing list who have more knowledge of HDL.

Regards,
Derek

On Tue, Jul 31, 2018 at 8:48 AM, Andreas Leuenberger <
andreas.leuenber...@palindrome-rs.ch> wrote:

> Thank you Derek for the explanations,
>
> As workaround I will have to send continuously.
> Just a curiosity, as I am very new in rfnoc development: Where is the
> timing of the bursts done in the FPGA? In the DmaFIFO block? And would it
> be possible to modify this block such that it sends zeros while no burst is
> 'active'?
>
> Best regards,
> andreas
>
>
>
> On 24.07.2018 16:46, Derek Kozel wrote:
>
> Hello Andreas,
>
> The digital frequency offset is handled in the DUC block which does not
> run in the same clock domain as the Radio block. The phase accumulator
> register will only increment when samples are being processed. The simplest
> way to cause the phase accumulator to continuously run (from the timing
> perspective of the DAC) is to send samples continuously rather than in
> bursts. This incurs a potentially significant downside of having to push
> out the extra samples from the computer. Since the DUC does not have
> knowledge of the timestamp data of each sample it would require invasive
> changes to make the phase accumulator look as if it were continuously
> running between bursts.
>
> Regards,
> Derek
>
> On Mon, Jul 16, 2018 at 2:20 PM, Andreas Leuenberger via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello all,
>>
>> I am using a USRP X310 with a UBX-160 daughterboard. The transmit signal
>> on port TX/RX is attenuated and looped back to the receiver on port RX2.
>>
>> Every millisecond I am sending a short rectangular pulse (about 10 us
>> long)
>> using the 'time_spec' attribute of the transmit meta-data
>> ('start_of_burst' and
>> ''end_of_burst are true).
>>
>> The frequencies of the transmit and receive LO's are set to the same
>> frequency. Also the digital transmit and receive frequencies offsets are
>> set
>> to the same value.
>>
>> I receive continuously and monitor the phase difference between the
>> transmitted
>> and received pulses.
>> If the digital frequency offset is zero, the phase difference of
>> consecutive
>> pulses stays constant, as expected.
>> If the digital frequency offset is different from zero, the phase
>> difference
>> of consecutive pulses jumps.
>>
>> What causes this phase jumps?
>> Maybe the digital oscillator of the transmitter is running only while
>> sending. If yes,
>> is there a way to force the transmit digital oscillator to run
>> continuously?
>>
>> I am using the following software versions:
>> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>> UHD_4.0.0.rfnoc-devel-788-g1f8463cc
>>
>> Thanks in advance,
>> andreas
>>
>>
>> ___
>> 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] Latency between multiple daughter boards on one USRP X310

[Derek Kozel via USRP-users]

Hello Fabian and Young,

The suggestion about timed commands is on point, I think that is what is
missing. Using unknown PPS will not hurt as there are two radio blocks with
timekeepers and using the unknown PPS setting, or external or gpsdo if
installed, will ensure that they are aligned.

> 3) If that does not work, maybe the FPGA can handly only one command at a
time - even if you tell him to execute two. Then it may be possible to
start one command timed before the other and extend that sequence of
samples with the correct amount of zeros.

Each radio channel has it's own queue for timed commands so it is possible
to schedule all channels simultaneously.

Derek

On Mon, Jul 30, 2018 at 8:08 AM, Fabian Schwartau via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Young,
>
> I am not an expert, but I have three suggestions:
> 1) Using 'Unknown PSS' or any other sync method should not have no affect,
> as this is for syncing two or more USRPs. You have only one FPGA and that
> is in sync with itself ;)
> 2) Did you tried using timed commands? (see function set_command_time())
> 3) If that does not work, maybe the FPGA can handly only one command at a
> time - even if you tell him to execute two. Then it may be possible to
> start one command timed before the other and extend that sequence of
> samples with the correct amount of zeros.
>
> Best regards,
> Fabian
>
> Am 30.07.2018 um 08:34 schrieb YoungC_Park via USRP-users:
>
>> Hi all,
>>
>> I hope someone could help me on my situation. I could not find similar
>> cases on the usrp archive.
>>
>> I have one USRP X310 that has UBX-160(slot A) , LFTX board(slot B) and
>> GPS module installed.
>>
>> - my UHD is 3.11.0
>>
>> - Using uhd API based on tx_samples from_file.cpp, I can generate dual
>> output bursts from UBX160 and LFTX with 200MHz master clock and 100Msps on
>> USRP X310.
>>
>> - However, the second output (ch 1, red in the picture) is lagged from
>> the first one (ch 0, yellow) by about (~10us with +-4us uncertainty)
>>
>> - The baseband burst is a sawtooth waveform of two cycles(2000 samples
>> long). and UBX160 modulates it into fc = 1GHz whereas LFTX generates it as
>> is.
>>
>> - This lagging is quite constant (10us) even if I change the sampling
>> rate (10,20,50, 100MSps).
>>
>> - Tried 'Unknown PPS', 'gpsdo', 'internal',,, but no difference.
>>
>> - When I switch the order of channels to (1,0) as opposed to (0,1), then
>> the ch0 lags behind the ch1, which seems that this is related to some
>> sequenced process…
>>
>> We are seeking for helps on the cause and cure about this lagging…
>>
>> Thanks,
>>
>> Young C. Park
>>
>>
>>
>> ___
>> 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] ALSA audio problem

[Derek Kozel via USRP-users]

Hello Mr Munir,

Yes, GNU Radio will work with a 12 core CPU. Problems with the audio sink
are usually a clock crossing issue. Your sound card is running at a
slightly different sample rate than whatever the source of your samples is.
Do you have a throttle block or a piece of hardware such as a radio which
is the source of the samples GNU Radio is processing?

Derek

On Mon, Jul 9, 2018 at 11:11 AM, Muhammad Munir via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear All,
> I am facing problem with audio sink block on Gnuradio. When I run
> application, there is a clear sound for about 8 to 10 minutes. After that
> sound becomes choppy with knocking sound. I tried different sample rate
> including 16kHz, 24kHz, 44.1kHz, 48kHz, and 96kHz with appropreate
> resampling. When I record .wav file the signal during that choppy sound and
> play it in player , it playback with no error.
> I am using Core i7 8th Generation 12 core processor. I have attached a
> picture. When i test the sound application in sound setting, it shows a
> flickering of ALSA plug-in [Python 2.7].
> My queries are
> i. Is it a problem with sound card of the motherboard?
> ii. Does Gnuradio version 3.7.10 supported at 12 core processor? because
> when I run the same application at 8 core processor, it has no issue of
> audio.
> iii. Suggest solutions to this problem.
>
> Regards,
> M. Munir
>
> ___
> 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] Changing phase with TX->RX loopback

[Derek Kozel via USRP-users]

Hello Andreas,

The digital frequency offset is handled in the DUC block which does not run
in the same clock domain as the Radio block. The phase accumulator register
will only increment when samples are being processed. The simplest way to
cause the phase accumulator to continuously run (from the timing
perspective of the DAC) is to send samples continuously rather than in
bursts. This incurs a potentially significant downside of having to push
out the extra samples from the computer. Since the DUC does not have
knowledge of the timestamp data of each sample it would require invasive
changes to make the phase accumulator look as if it were continuously
running between bursts.

Regards,
Derek

On Mon, Jul 16, 2018 at 2:20 PM, Andreas Leuenberger via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello all,
>
> I am using a USRP X310 with a UBX-160 daughterboard. The transmit signal
> on port TX/RX is attenuated and looped back to the receiver on port RX2.
>
> Every millisecond I am sending a short rectangular pulse (about 10 us long)
> using the 'time_spec' attribute of the transmit meta-data
> ('start_of_burst' and
> ''end_of_burst are true).
>
> The frequencies of the transmit and receive LO's are set to the same
> frequency. Also the digital transmit and receive frequencies offsets are
> set
> to the same value.
>
> I receive continuously and monitor the phase difference between the
> transmitted
> and received pulses.
> If the digital frequency offset is zero, the phase difference of
> consecutive
> pulses stays constant, as expected.
> If the digital frequency offset is different from zero, the phase
> difference
> of consecutive pulses jumps.
>
> What causes this phase jumps?
> Maybe the digital oscillator of the transmitter is running only while
> sending. If yes,
> is there a way to force the transmit digital oscillator to run
> continuously?
>
> I am using the following software versions:
> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_4.0.0.rfnoc-devel-788-g1f8463cc
>
> Thanks in advance,
> andreas
>
>
> ___
> 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] Probe N310 on Windows OS

[Derek Kozel via USRP-users]

Hi Jorge,

The N310 requires that one of the SFP+ connections is used, not just the
RJ45 GigE connection. Info on setting up those connections is here in the
Getting Started guide.
https://kb.ettus.com/N300/N310_Getting_Started_Guides#Setting_Up_a_Streaming_Connection

Regards,
Derek

On Tue, Jul 24, 2018 at 12:16 PM, Jorge Chen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi USRP Users
>
> I got the new N310, and followed the online Getting Started Guides step by
> step,
> and I'm able to run the  rx_ascii_art_dft  and some example programs on
> Ubuntu.
>
> However, while I tried it on Windows OS,
> I can ping the address (192.168.10.2) and find it using
> uhd_find_devices.exe, but cannot probe it.
>
> C:\Program Files\UHD\bin>uhd_find_devices.exe
> [INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_105900;
> UHD_3.12.0.0-release
> --
> -- UHD Device 0
> --
> Device Address:
> serial: 315A370
> claimed: False
> mgmt_addr: 192.168.10.2
> product: n310
> reachable: No
> type: n3xx
>
>
> C:\Program Files\UHD\bin>uhd_usrp_probe.exe
> [INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_105900;
> UHD_3.12.0.0-release
> [INFO] [MPMD FIND] Found MPM devices, but none are reachable for a UHD
> session. Specify find_all to find all devices.
> Error: LookupError: KeyError: No devices found for ->
> Empty Device Address
>
> I noticed that there's a reachable status while executing uhd_find_devices
> on Windows,
> I wonder if it corresponded to the message   Found MPM devices, but none
> are reachable for a UHD session. in the uhd_usrp_probe log.
>
> Are there some other settings I should take care about? or the environment
> settings?
>
> Any suggestion would be appreciated.
> Thanks!
>
> Jorge
>
> ___
> 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] use X310 Ref Out for sync

[Derek Kozel via USRP-users]

Hello Johannes,

Yes, in that case you can take the 10 MHz Ref Out from the primary X310 and
connect it to the 10 MHz Ref in of the second X310. What cannot be done is
extend that to a third X310 by daisy chaining or use the 1 PPS to achieve
the exact timing sync needed for precise phase alignment of multiple X310s.

Regards,
Derek

On Mon, Jul 23, 2018 at 10:17 AM, Johannes Demel via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> we have 2 USRP X310 which we need to synchronize. Hopefully to make things
> easier, we only need frequency synchronization. Is it possible to connect
> 'Ref Out' to 'Ref In' on another X310 for that purpose?
> Previously, we used a signal generator to supply two USRPs with a
> reference 10MHz signal. If we could get rid of the signal generator, that
> would be really helpful.
>
> Cheers
> Johannes
>
> ___
> 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 Radio Loopback

[Derek Kozel via USRP-users]

Hello Alex,

Dave is correct that RFNoC does not currently support a loopback that does
not include the host. This is a functionality which Ettus is aware is
keenly desired by some users but we do not have a timeline for it being
natively supported. The post that Dave linked to describes how to make such
a loopback work currently.

Regards,
Derek

On Wed, Jul 11, 2018 at 12:39 PM, Dave NotTelling via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I seem to recall that you can't actually do a loopback like that in
> RFNoC.  I think you have to send samples to the host at some point.  A
> quick Google search came up with [1].  I'd be really interested if there
> were a way to do a HW only loopback with RFNoC natively.
>
> [1] https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
>
> On Mon, Jul 9, 2018 at 4:21 PM Weihan Chen via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi,
>>
>> I'm new to RFNOC development. I have an X310 with an SBX on slot A, and I
>> want to do a loopback from antenna port RX2 to TX/RX using RFNOC blocks. I
>> tried connecting 0/Radio_0 ==> 0/DDC_0 ==> 0/DUC_0 ==> 0/Radio_0 by the
>> following commands:
>>
>> rx_graph->connect(radio_ctrl->get_block_id(), ddc_ctrl->get_block_id());
>> rx_graph->connect(ddc_ctrl->get_block_id(),
>> ​duc​
>> _ctrl->get_block_id());
>> rx_graph->connect(duc_ctrl->get_block_id(), radio_ctrl->get_block_id());
>>
>> and UHD gives me Error: RuntimeError: On node 0/Radio_0, output port 0 is
>> already connected.
>>
>> What am I doing wrong here? Please help.
>>
>> Regards,
>> Alex
>> ___
>> 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] Detecting and sampling short bursts of signals at full sampling rate of USRP X310 for longer period of time

[Derek Kozel via USRP-users]

Hi Tarik,

I regularly stream 800 MS/s to my desktop from a pair of X310s and display
the data using GNU Radio's Frequency Sink blocks. I rarely try saving data
at a rate above 100 MS/s. Since DSP tasks can vary so much it is
essentially impossible for us to say what your maximum achievable sample
rate will be for a given computer.

If you have FPGA development experience then RFNoC is relatively
straightforward. You would have a few options for receiving data which we
could talk about if you do choose to go that route. It is usually faster to
develop host computer code than FPGA based processing, as you've likely
found.

No matter where you do the signal detection you will need to determine your
average data rate that you want to save to disk. Burst length, repetition
rate, sample rate, etc will determine that.

Regards,
Derek


On Mon, Jul 9, 2018 at 11:56 AM, Tarik Kazaz  wrote:

> Hi Derek,
>
>
> Thank you for the advice and comments. So UHD requires connection of Dual
> 10GBe interface to
>
> single PC.
>
>
> I have experience with FPGA and debugging. However, I did not explore
> RFNoC FPGA design (I did read few papers about RFNoC).
>
> If it really complicated I would like to avoid implementing signal
> detection there.
>
>
> However, I am still wondering will PC be able to process 400Msps of data
> in burst mode.
>
> Did you guys do similar experiments at ettus?
>
>
> What we want is to test our signal processing algorithm for localization.
> For that, we transmit wideband signals
>
> (of 320MHz, two UBX card are stitched together) from several anchor nodes
> to the mobile node which we want to
>
> localize (this node also has USRP X310 with two UBX cards).
>
>
> While sending signals from 320 MHz from anchor should not cause us issues
> (as signals are same all the time,so we can store it in USRP itself).
>
> I am worried how PC and USRP will behave in case of the receiver (mobile
> node) as there we need to us PC to store our samples.
>
>
> Kind Regards,
>
>
> Tarik
>
>
>
> --
> *From:* Derek Kozel 
> *Sent:* Monday, July 9, 2018 12:37:16 PM
> *To:* Tarik Kazaz
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] Detecting and sampling short bursts of
> signals at full sampling rate of USRP X310 for longer period of time
>
> Hello Tarik,
>
> Just stepping in to respond that UHD does not support splitting the 10
> GigE interfaces to two computers.
>
> The X310 supports RFNoC which you could use to create an energy detection
> block which only streams samples back to the computer when your criteria
> are met. However it is likely simplest for you to do the energy detection
> on the host computer, streaming the full bandwidth to the computer but then
> only saving samples long term if your detector identifies a signal of
> interest. Host coding is almost invariably faster and simpler to debug than
> FPGA code, though of course there are cases where putting processing in the
> FPGA is either more efficient or provides unique benefits. In this case you
> could see some very good efficiency benefits if the FPGA DSP could limit
> the number of samples that are actually sent to the host, but it is an
> efficiency gain you likely don't need.
>
> Regards,
> Derek
>
>
>
> On Mon, Jul 9, 2018 at 11:01 AM, Tarik Kazaz via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi All,
>>
>> I am giving up hope of sampling signals of full BW of two UBX-160 cards,
>> and storing those streams in the PC.
>> Based on my calculations (one of the previous posts) in order to be able
>> to do that I would need to write to
>> memory with the speed of 1.6GBps.
>>
>> However, now I am interested in sampling short bursts of signals with the
>> full bandwidth of USRP x310 (so 2(cards)x2(IQ)x200MSPs)
>> and then storing them into PC memory for the period of 10 minutes.
>>
>> The idea would be to stream bursty signal when the signal is in the air.
>>
>> For this, I would probably need to have some sort of energy detector in
>> the FPGA. The idea would be that energy detector signalizes when the
>>
>> signal is in the air and to trigger streaming samples towards PC.
>>
>>
>> In this way, I would try to lower requirements on the speed of memory
>> write in the PC.
>>
>> Does anyone have experience with doing the same?
>>
>> Previously, I was interested in the possibility to connect single
>> USRP-X310 to two separate PCs over 10GBe interfaces
>>  (to split dual 10GBe connection to two PCs with NVMe SSDs). In that way,
>> there would be a possibility to lower down
>> requirements on memory writing speed to 0.8GBps. These memory writing
>> speeds should be supported by modern
>> NVMe SSDs. Probably this is not straightforward to achieve as I did not
>> get too many replies on my previous post. More details about
>>
>> my previous posts are available here https://www.mail-archive.
>> com/usrp-users@lists.ettus.com/msg05579.html.
>>
>>
>>
>> Cheers,
>> Tarik
>>
>> 

Re: [USRP-users] Detecting and sampling short bursts of signals at full sampling rate of USRP X310 for longer period of time

[Derek Kozel via USRP-users]

Hello Tarik,

Just stepping in to respond that UHD does not support splitting the 10 GigE
interfaces to two computers.

The X310 supports RFNoC which you could use to create an energy detection
block which only streams samples back to the computer when your criteria
are met. However it is likely simplest for you to do the energy detection
on the host computer, streaming the full bandwidth to the computer but then
only saving samples long term if your detector identifies a signal of
interest. Host coding is almost invariably faster and simpler to debug than
FPGA code, though of course there are cases where putting processing in the
FPGA is either more efficient or provides unique benefits. In this case you
could see some very good efficiency benefits if the FPGA DSP could limit
the number of samples that are actually sent to the host, but it is an
efficiency gain you likely don't need.

Regards,
Derek



On Mon, Jul 9, 2018 at 11:01 AM, Tarik Kazaz via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi All,
>
> I am giving up hope of sampling signals of full BW of two UBX-160 cards,
> and storing those streams in the PC.
> Based on my calculations (one of the previous posts) in order to be able
> to do that I would need to write to
> memory with the speed of 1.6GBps.
>
> However, now I am interested in sampling short bursts of signals with the
> full bandwidth of USRP x310 (so 2(cards)x2(IQ)x200MSPs)
> and then storing them into PC memory for the period of 10 minutes.
>
> The idea would be to stream bursty signal when the signal is in the air.
>
> For this, I would probably need to have some sort of energy detector in
> the FPGA. The idea would be that energy detector signalizes when the
>
> signal is in the air and to trigger streaming samples towards PC.
>
>
> In this way, I would try to lower requirements on the speed of memory
> write in the PC.
>
> Does anyone have experience with doing the same?
>
> Previously, I was interested in the possibility to connect single
> USRP-X310 to two separate PCs over 10GBe interfaces
>  (to split dual 10GBe connection to two PCs with NVMe SSDs). In that way,
> there would be a possibility to lower down
> requirements on memory writing speed to 0.8GBps. These memory writing
> speeds should be supported by modern
> NVMe SSDs. Probably this is not straightforward to achieve as I did not
> get too many replies on my previous post. More details about
>
> my previous posts are available here https://www.mail-archive.
> com/usrp-users@lists.ettus.com/msg05579.html.
>
>
>
> Cheers,
> Tarik
>
> ___
> 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] N3XX GRC Host Connectivity

[Derek Kozel via USRP-users]

Hello Walter,

I predominantly work from the C++ UHD driver downwards, so let us hope we
can meet in the middle.

The RFNoC Crossbar in the FPGA handles the routing of data and command
packets from one CE to another. The SFP+ based Ethernet connections are
ports on the crossbar as is the radio block. UHD, whether running on a host
computer or on the embedded processor creates a graph of connections
between blocks, usually starting with the host and ending with the radio
block. UHD then uses this graph to program the RFNoC crossbar's routing to
control the flow of packets.

You are correct that when using GNU Radio or UHD directly the selection of
which SFP+ data is streamed to/from is done by IP address, or automatically
if you do not specify an IP address. When both SFP+ connections are
attached between host and USRP both IP addresses can be specified and UHD
will handle the mapping of data streams to SFP+ transports behind the
scenes. Currently data for a single stream will not be split across more
than one connection. This means that you cannot stream one channel of 50
MS/s 16 bit complex samples over a pair of 1 GigE connections for instance
even though the aggregate throughput would be sufficient. Two streams of 25
MS/s would work though as each will (close to) saturate a 1 GigE
connection. Because of the RFNoC crossbar's architecture and UHD's handling
of the data streams it is not usually important to know which SFP+
connection is used, the automatic routing will handle it transparently.

There is a separate DRAM FIFO block on the X310 and N310 which is used to
absorb network latency and improve streaming stability at high sample
rates. It does not require PS intervention during data streaming.

You're clearly digging in depth into RFNoC and have been using the E310, so
these are probably familiar resources. Some of the presentations and videos
describe the behavior of the crossbar and data routing. Most of the
examples are focused on the X310 style data flow with data being
transported out of the SFP+ connections. Any X310 example that is not
daughterboard specific will run on the N310.
https://kb.ettus.com/RFNoC#RFNoC_Resources

Regards,
Derek



On Fri, Jul 6, 2018 at 5:54 AM, Walter Maguire 
wrote:

> Hi Derek,
>
> Thanks for your detailed response, much appreciated.   I am predominately
> FPGA focused so I tend to start there and work my way up hill.
>
> I think part of my confusion is reconciling what is on the GNURadio GRC
> versus what is happening in the FPGA.  I think this is where the UHD
> "magic" takes place.   I also think part of the misunderstanding concerns
> the large amount of Ettus devices which are similar in many ways but also
> quite different.   As mentioned in an earlier email we are familiar withe
> E310 which uses a Zynq and a PS based Ethernet which has limited BW.   We
> are currently considering moving to a N3XX device which in my
> understanding  is sort of similar to a E3XX (Zynq based PS)  and X3XX
> device (eg SFPs).   I have been using the gr-ettus X3XX grc examples as (I
> could be wrong here) I don't seem to be able to locate any N3XX grc
> examples.   For an E310 there is only one option for the streaming Ethernet
> connection and therefore I can understand how the UHD is able to associate
> the RJ45 as the link .   For a X3XX there are 2 SFPs  and on a N3XX one
> RJ45 PS link and 2 SFPs. From the GRC UDP block configuration perspective I
> don't see any means of selecting which SFP to use based on the gr-ettus
> X3XX examples.   I suppose (I don't have any hw to work with) the UHD
> driver would detect the SFP ports when probing the X3XX device. If two are
> detected does it use the ip addresses to determine which one to connect
> to?If for example a N3XX was configured to have two 10GBit SFPs which
> SFP  is used to provide the streaming?
>
> My mentioning of the DMAs is based on the use of DMA to drive the SFPs and
> all the ADI DMACs that appear in Vivado board design for the N3XX.   This
> also appears to be evident in the elaborated design and the partitioning of
> memory addresses provided below. Looking at the PS addresses on the
> associated board design, the elaborated design it appears to me that the
> RFNoC  blocks are not connected directly to the SFPs and need to transfer
> data across several axi interfaces.   There are 2 HP ports which deal
> directly with the SFP wrapper cores interfacing via DMA blocks.I think,
> that in order to get data from a RFNoC CE  block contained in the
> n3xx_core to a SFP port data needs to be transferred to ddr3 memory and
> then transferred from ddr3 memory to the SFP wrappers.   Alternatively, it
> might be possible to configure the PS ADI dmacs to address the DMA blocks
> which directly connect to the SFPs, don't know.
>
> If there is no direct connection between the RFNoC CE blocks contained in
> the n3xx_cores and the associated communications SFPs , my concern is the
> amount of embedded processor 

Re: [USRP-users] UHD installation

[Derek Kozel via USRP-users]

Hello Alejandra,

Both of the instructions are correct. The confusion is that the manual
copies the file from the installed version of UHD and the application note
copies it from the source code directory. By default the install location
will be "/usr/local/" so the full path in [1] would be
/usr/local/lib/uhd/utils.

The app note does include the instructions for configuring non-root USB
access.
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux#Configuring_USB

It also includes the notes about threading priority at the end.
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux#Thread_priority_scheduling

I'll have a think about how to make it clear that those sections are
necessary reads after finishing the base installation process. A note at
the end of the UHD installation section makes sense.

Best regards,
Derek

On Thu, Jul 5, 2018 at 5:03 PM, Alejandra Mercado via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I believe these instructions are all the more necessary, since they (the
> instructions) seem to be unstable.
>
> For example, [1] says to change folder to /lib/uhd/utils
>
> But there is no such path (at least in UHD version 3.9.7). The closest is
>workarea-uhd/uhd/host/lib/utils
>
> Which, though easy enough to find, begs the question if other paths have
> changed then will some of these batches help or hurt?
>
> Thanks and regards
>
>
>
> On Thu, Jul 5, 2018 at 11:56 AM Alejandra Mercado 
> wrote:
>
>> Dear USRP folks,
>>
>> If the steps in [1] and [2] are needed to prevent the sudo requirement (I
>> have the same problem, Hojoon), then could Ettus please add those commands
>> to the installation instructions in
>>
>> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-
>> Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux
>>
>> If it had not been for Hojoon's post, I would be at sea as to how to
>> solve it.
>>
>> Regards
>>
>> On Tue, May 8, 2018 at 1:37 AM Nicolas Cuervo via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> All that you are seeing is part of the normal behavior. The warnings are
>>> fairly descriptive on telling you what is happening. As you did, you set
>>> the Udev rules as depicted in our manual [1]. Later, you see the thread
>>> priority and you are encouraged to go to the manual again, where you will
>>> find the description of that warning and what to do to set the thread
>>> priority [2].
>>>
>>> -Nicolas
>>>
>>> [1] https://files.ettus.com/manual/page_transport.html#
>>> transport_usb_udev
>>> [2] https://files.ettus.com/manual/page_general.html#
>>> general_threading_prio
>>>
>>> On Tue, May 8, 2018 at 6:15 AM, Hojoon Yang via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hi, I resolved the "[ERROR] [USB] USB open failed: insufficient
 permissions." problem


 by the following commands,


 sudo cp uhd-usrp.rules /etc/udev/rules.d/

 sudo udevadm control --reload-rules

 sudo udevadm trigger


 However, I still get the warning if I executed the uhd example programs
 without "sudo"


 [WARNING] [UHD] Unable to set the thread priority. Performance may be
 negatively affected.

 Please see the general application notes in the manual for instructions.

 EnvironmentError: OSError: error in pthread_setschedparam



 For example,



 sudo ./tx_waveforms .. -> No such warning

 ./tx_waveforms .. -> [WARNING] [UHD ].



 Is this a bug? or normal behavior?



 Regards,

 Hojoon



 ---Original Message---
 From: Hojoon Yangvia USRP-users 
 To: "Marcus D. Leech via USRP-users" 
 Sent date: 2018-05-08 11:33:40 GMT +0900 (Asia/Seoul)
 Subject: Re: [USRP-users]UHD installation

 Thanks Marcus.



 I did it. But, nothing changed. I will re-install the uhd and come back
 if still have problems.



 But, is there any relationship between kernel version and uhd version?
 I use UHD 3.11.



 currently, I use Ubuntu 14.04.5 LTS and the kernel version is
 4.2.0-42-generic


 Because, the latest kernel version NI RIO supports is 4.2.x. I need it
 for USRP X310.


 Regards,


 Hojoon



 ---Original Message---
 From: "Marcus D. Leech via USRP-users" 
 To: usrp-users@lists.ettus.com
 Sent date: 2018-05-08 10:47:47 GMT +0900 (Asia/Seoul)
 Subject: Re: [USRP-users] UHD installation
 On 05/07/2018 09:42 PM, Hojoon Yang via USRP-users wrote:

 Hi,



 When I executed the "uhd_find_devices"



 I got "[ERROR] [USB] USB open failed: insufficient permissions."


 However, when I put 

Re: [USRP-users] timed transmission LATE issue

[Derek Kozel via USRP-users]

Hello Hojoon,

The problem is a mix of PC hardware and OS, so it is not as simple as
saying that changing the OS will improve the latency to meet your need. It
will likely help. Increasing the CPU speed would also improve the latency
since context switches and all other actions will run faster, but you
cannot get a CPU that is 5x faster than your current 4.7 GHz! Also not all
the latency would be improved by increasing the CPU speed, some of the time
is in the network interface card, some in fixed delays.

Also improving performance in any application will encounter Amdahl's Law.
Speeding up one area will meet diminishing returns if there is time spent
in other areas.
https://en.wikipedia.org/wiki/Amdahl%27s_law

Moving from 20 ms to 5 ms will require a 75% reduction, already
challenging. Moving from 5 ms to 3 ms is a further 40% reduction, but
you'll have already eliminated all the easy (and some hard!) optimizations.
I do not have personal experience in pushing the latency that low, I hope
that others with experience will offer suggestions and their results.

Make sure your CPU is fixed in performance mode. Depending on what network
card you have, check if the vendor supplies any advice on tuning
performance. If your sample rate is lower, then changing the samples per
packet can help packets be dispatched more often, reducing some latency
there.
http://files.ettus.com/manual/page_transport.html

Regards,
Derek


On Thu, Jul 5, 2018 at 3:25 PM, Hojoon Yang  wrote:

> Hi, Derek.
>
> Thanks for detailed answer.
>
>
>
> I'm using ubuntu 14.04 and kernel version 4.2.0-42-generic and USRP X300
> with two UBX-160 which is connected to the host PC via 1G ethernet.
>
>
> In my application, the lowest delta value that works reliably is 20ms. The
> definition of reliability means that there is no 'L' for one minute during
> the execution of the application.
>
>
> I want the delta value to be 3~4 ms.
>
>
> so, since the problem is latency in OS side, I cannot improve the delta
> value even if I upgrade my host PC to good one. Am I right?
>
>
> the number of thread in the application may affect the latency? My
> application use two thread only. Since there are 4 cores in my host PC, I
> believe it barely affects the latency.
>
>
> To sum it up, to achieve 3~4 ms delta value (based on your delta
> value(5~20ms), I believe 3~4ms delta can be achieved), I should change
> the OS in the host PC to low latency linux kernel.
>
>
> Please correct me if I'm wrong. Thanks again!
>
>
>
>
>
> ---Original Message---
> From: Derek Kozel 
> To: Hojoon Yang 
> CC: usrp-users 
> Sent date: 2018-07-05 22:11:03 GMT +0900 (ROK)
> Subject: Re: [USRP-users] timed transmission LATE issue
> Hello Hojoon,
>
> You will have to profile your system to determine the minimum delta that
> works reliably on your system, as well as choosing a definition for
> reliable. Networking stacks nearly always have stochastic delays due to the
> various context switches and scheduling issues with transferring data to
> and from a user program and the actual network hardware. On the USRP side
> the FPGA provides a much more deterministic behavior because the logic is
> exclusively serving the network traffic. The DRAM buffer on the transmit
> side is there to absorb some of the variability of the host computer
> network stack, but it can only do that if there is enough time delay
> between samples being sent by the program and when the DAC must be
> producing the associated analog signal.
>
> In practice I have always used a few (5-20) ms and found it to be reliable
> for transmissions lasting up to an hour, but you will have to test your
> specific setup. Different OS network stacks have different options for
> tuning to reduce both the average and peak latency of the network drivers.
> I'm not an expert in them but there are a variety of good resources online.
> In applications demanding both small latency and high reliability moving to
> a realtime Linux environment can help in meeting those hard deadlines. I
> believe that some of the LTE and GSM projects have been successful with
> that approach.
>
> Regards,
> Derek
>
> On Thu, Jul 5, 2018 at 12:34 PM, Hojoon Yang via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi,
>>
>>
>>
>> I am using USRP X310 with two UBX-160 daughterboards.
>>
>>
>>
>> In my application, I am using timed transmission, for example,
>>
>>
>>
>> start transmission at (usrp_get_time_now() + delta)
>>
>>
>>
>> My question is, what is the smallest delta value that can be successful
>> in the *real world*? Theoretically, the delta can be any value, if the
>> host can send the packet to the USRP fast enough.
>>
>>
>> Suppose we have a PC which have i7-8700k CPU and the PC only runs this
>> application. when I set the delta 1ms, Can I avoid late 'L'?
>>
>>
>> Best regards,
>>
>> Hojoon
>>
>> __ _
>> USRP-users mailing list
>> 

Re: [USRP-users] timed transmission LATE issue

[Derek Kozel via USRP-users]

Hello Hojoon,

You will have to profile your system to determine the minimum delta that
works reliably on your system, as well as choosing a definition for
reliable. Networking stacks nearly always have stochastic delays due to the
various context switches and scheduling issues with transferring data to
and from a user program and the actual network hardware. On the USRP side
the FPGA provides a much more deterministic behavior because the logic is
exclusively serving the network traffic. The DRAM buffer on the transmit
side is there to absorb some of the variability of the host computer
network stack, but it can only do that if there is enough time delay
between samples being sent by the program and when the DAC must be
producing the associated analog signal.

In practice I have always used a few (5-20) ms and found it to be reliable
for transmissions lasting up to an hour, but you will have to test your
specific setup. Different OS network stacks have different options for
tuning to reduce both the average and peak latency of the network drivers.
I'm not an expert in them but there are a variety of good resources online.
In applications demanding both small latency and high reliability moving to
a realtime Linux environment can help in meeting those hard deadlines. I
believe that some of the LTE and GSM projects have been successful with
that approach.

Regards,
Derek

On Thu, Jul 5, 2018 at 12:34 PM, Hojoon Yang via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
>
>
> I am using USRP X310 with two UBX-160 daughterboards.
>
>
>
> In my application, I am using timed transmission, for example,
>
>
>
> start transmission at (usrp_get_time_now() + delta)
>
>
>
> My question is, what is the smallest delta value that can be successful in
> the *real world*? Theoretically, the delta can be any value, if the host
> can send the packet to the USRP fast enough.
>
>
> Suppose we have a PC which have i7-8700k CPU and the PC only runs this
> application. when I set the delta 1ms, Can I avoid late 'L'?
>
>
> Best regards,
>
> Hojoon
>
> ___
> 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] N3XX GRC Host Connectivity

[Derek Kozel via USRP-users]

Hello Walter,

The N310's streaming architecture is much closer (nearly identical) to the
X310 for your use case of connecting it to a host computer. It can stream
full bandwidth of all channels out of the SFP+ connections when using 10
Gigabit Ethernet. All UHD examples can be run on a host computer, including
all GNU Radio flowgraphs, and use the full capabilities of the N310.

The RJ45 connector on the N310 is connected directly to the Zynq PS, the
same as the E310, and cannot be used to directly stream samples to a remote
computer without using the ZMQ or similar approach of using a program to
"forward" the samples. Such an approach would also have the same bottleneck
as the E310. You are correct that the bottleneck for the E310 remote
streaming functionality is the Zynq PS processing power. The E310 was not
designed to stream high bandwidth signals on and off of the device. The
upcoming E320 addresses that by adding the same 10 GigE SFP+ connection as
the X310 and N310. Your observations about the limitations of the E310 are
not unique and were listened to when defining the E320.

Regards,
Derek


On Wed, Jul 4, 2018 at 8:32 AM, Walter Maguire via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> As a follow up to my post which appears in Vol 95, Issue 1, I would be
> very grateful if might be able to provide me with some answers to my
> questions.  A copy the email is provided below.
>
> We currently are looking at purchasing a N3XX device but are concerned
> about the practical data rates that can be achieved by the unit.   We have
> a E310 and the limit on this unit appears to be around the 1MSps over the
> Internet connection before significant overruns occur.  The test just uses
> a  RFNoC Radio configured as a receiver and connected to an RFNoC FIFO
> prior to PS based ZMQ push sink.   The E310 grc is run with no gui using
> the python generated script.  We use a rf signal generator tunned to the
> signal of interest plus a few Hz with carrier only.   We then observe the
> resulting sine waves on and external the (I7 8 core host with the mtu set
> to 8000) and the overrun messages on the E310.
>
> Our observations are as follows;
>
> 1. We are unable to alter the MTU size on the E310 above 1500. Could be a
> kernel issue on the version we are using.
>
> 2. Changing the number of samples in a GNURadio complex vector (FIFO
> length) seems to have no discernible change in the distortion on the
> observed sine waves or the amount of overrun messages.
>
> 3. The distortion on the sine waves is due to system not been able to
> supply samples continuously.  This occurs a low sample rates as well.
>
> 4. We think the bottle neck is largely the Zynq PS processing power.
>
> 5. As the E310 uses the same Zynq PS as the N3XX we are concerned that the
> Internet throughput will be as slow as the E310 unless it is possible to
> bypass the Zynq processing system and send RFNoC samples directly over the
> SFPs.   I think this is done on the X3XX series where the micro blaze seems
> to be used to set up the SFPs. I seek clarification for how it is done on
> the N3XX series of devices as they are not cheap and need to be sure of
> practical achievable continuous real time sample performance.
>
>
> Regards
>
>
>
> Walter
>
>
> Hi all,
>
>
> Are there any RFNoC GRC examples available for the N3XX device streaming
> data to a host using a SFP port??? Is the N3XX like a E3XX series in
> that the GRC has to be run on the Zynq arm device or can it be
> configured to run like a X3XX device where the external Host PC runs the
> GNURadio, connecting the various CE blocks on the X3XX??? I assume the
> Host needs to be controlling the ARM for configuration on the RJ45 port
> prior to setting up communications on the SFP ports?? Does the N3XX need
> to use the same approach
> (https://kb.ettus.com/Streaming_processed_data_from_the_
> E31x_with_GNU_Radio_and_ZMQ)
> as the ZMQ example to transport data to an external Host for GNURadio
> processing?
>
> I have been trying to figure out from the FPGA build and UHD driver how
> it operates.? The CE engines seem to go via ADI DMAC cores where the
> destination appears to be either other RFNoC CE engines on the bus or
> the ARM external DDR3 memory.? Can these address the DMAs associated
> with the SFPs and skip the external ARM memory DMA stage?
>
> A top level description of how the various ingress /egress bus
> communications are addressed by RFNoC would be very helpful.
>
>
> Regards
>
>
>
> Walter
>
>
> ___
> 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 Relay

[Derek Kozel via USRP-users]

Hello Dr Henarejos,

Currently an RFNoC only flowgraph is not fully supported. What is missing
is the issuing of the commands to start streaming and a mechanism to handle
timestamps. Some modifications are needed to make these work.
Nick Foster has done a write up on a few different ways of handling the
necessary modifications.

https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/

Regards,
Derek

On Fri, Jun 22, 2018 at 10:10 AM, Pol Henarejos via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear all,
>
> I am playing with RFNoC on a USRP X300. I built a custom RFNoC FPGA image
> with the blocks that I need successfully and everything goes smooth.
> However, if I want to use a flowgraph with only RFNoC blocks (RFNoC Radio
> RX --> DmaFIFO --> RFNoC Radio TX), it does not work. The USRP does nothing
> (no blinking leds, no error messages, nothing). If I replace the DmaFIFO
> block with a Copy block, then it works but, as expected, this is not
> efficient since all the samples go to the host and go back to the USRP. I
> would want to perform a relay by using only RFNoC blocks. My impression is
> that a command to the USRP might be needed (a streaming command or so), but
> I have no idea what is wrong.
>
> I attach the flowgraph.
>
> (only RFNoC blocks does not work)
>
> (flowing samples to host and going back to USRP does work but it is
> extremely inefficient)
>
> Thank you.
>
>
> --
>
> Dr. Pol Henarejos
> Researcher
> Array and Multi-Sensor Processing Department, Communication Systems 
> divisionpol.henare...@cttc.cat
>
> Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
> Av. Carl Friedrich Gauss, 7
> 08860 Castelldefels, Barcelona (Spain)
> Tel: +34 93 645 29 00  Ext: 2177www.cttc.cat
>
>
> ___
> 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] Is it possible to set frequency along with a timed command for frequency hopping application?

[Derek Kozel via USRP-users]

Yes. Almost every command can be made timed on the X3x0s.

On Wed, Jun 20, 2018 at 6:17 PM, Felipe Augusto Pereira de Figueiredo <
zz4...@gmail.com> wrote:

> Many thanks Derek, I think it worked!
>
> Is it also possible to schedule gains to be applied into the future?
>
> Kind Regards,
>
> Felipe Augusto
>
> On Tue, Jun 19, 2018 at 6:24 PM, Derek Kozel 
> wrote:
> > Yes, I believe all of those commands are exposed in the C API.
> >
> > For instance,
> > https://github.com/EttusResearch/uhd/blob/maint/
> host/examples/rx_samples_c.c#L175
> >
> > If you have the ability to use the C++ API for your application I would
> > generally recommend that as it is the native API for UHD. The C and
> Python
> > APIs are derived so sometimes do not follow the most idiomatic
> conventions
> > of the language. Also the C++ API has the most functionality as not all
> > functions and classes are available in the derived APIs.
> >
> > Regards,
> > Derek
> >
> >
> > On Tue, Jun 19, 2018 at 5:10 PM, Felipe Augusto Pereira de Figueiredo
> >  wrote:
> >>
> >> Dear Derek, thanks!
> >>
> >> Last question, are there any commands in the C API that do the same as
> >> the following ones?
> >>
> >> //we will tune the frontends in 100ms from now
> >> uhd::time_spec_t cmd_time = usrp->get_time_now() +
> uhd::time_spec_t(0.1);
> >> //sets command time on all devices
> >> //the next commands are all timed
> >> usrp->set_command_time(cmd_time);
> >> //tune channel 0 and channel 1
> >> usrp->set_rx_freq(1.03e9, 0); // Channel 0
> >> usrp->set_rx_freq(1.03e9, 1); // Channel 1
> >> //end timed commands
> >> usrp->clear_command_time();
> >>
> >> Kind Regards,
> >>
> >> Felipe
> >>
> >> On Tue, Jun 19, 2018 at 4:52 PM, Derek Kozel 
> >> wrote:
> >> > Hello Felipe,
> >> >
> >> > The oscillator will *start* tuning at the time stamp you specify. You
> >> > will
> >> > have to characterize the settling time for your frequency hops and
> >> > schedule
> >> > the tunes in advance of when you need to be at the new frequency.
> >> > Depending
> >> > on what frequencies you are moving between and which daughterboard you
> >> > are
> >> > using the settling time changes. It is important to note that timed
> >> > commands
> >> > are executed in the order the are issued, not in chronological order,
> so
> >> > you
> >> > must issue them in chronological order for to get the expected
> behavior.
> >> >
> >> > Regards,
> >> > Derek
> >> >
> >> > On Tue, Jun 19, 2018 at 3:45 PM, Felipe Augusto Pereira de Figueiredo
> >> >  wrote:
> >> >>
> >> >> Dear Derek, thanks for your prompt reply!
> >> >>
> >> >> I'm using an x310.
> >> >>
> >> >> Just to clarify, I want to make sure that the frequency I'm setting
> is
> >> >> only valid and guaranteed for that specific starting point (the
> >> >> timestamp into the future). Right now, when I send just the time
> >> >> command and change the frequency for the next packet I see with the
> >> >> spectrum analyser that the packets do not have the right frequency,
> >> >> instead, they are spread over the spectrum as the oscillator might be
> >> >> still under configuration, calibration, etc.
> >> >>
> >> >> Therefore, I hope that with the timed commands I will be able to have
> >> >> a better control over freq/time resources.
> >> >>
> >> >> Thanks and Kind Regards,
> >> >>
> >> >> Felipe
> >> >>
> >> >> On Tue, Jun 19, 2018 at 4:37 PM, Derek Kozel 
> >> >> wrote:
> >> >> > Hello Felipe,
> >> >> >
> >> >> > Yes it is possible. What USRP are you using? Some, such as the B200
> >> >> > and
> >> >> > E310
> >> >> > cannot set the frequency using timed commands as the tuning is done
> >> >> > by
> >> >> > the
> >> >> > RFIC rather than the FPGA. There is a small example of tuning in
> the
> >> >> > manual.
> >> >> > http://files.ettus.com/manual/page_sync.html#sync_phase_lo
> >> >> >
> >> >> > And a longer program using timed commands in the examples.
> >> >> >
> >> >> >
> >> >> > https://github.com/EttusResearch/uhd/blob/maint/
> host/examples/test_timed_commands.cpp#L74
> >> >> >
> >> >> > The TwinRX fast frequency hopping example does not show the use of
> >> >> > timed
> >> >> > commands for changing the local oscillator frequency, but does show
> >> >> > very
> >> >> > efficient burst reception.
> >> >> >
> >> >> >
> >> >> > https://github.com/EttusResearch/uhd/blob/maint/
> host/examples/twinrx_freq_hopping.cpp
> >> >> >
> >> >> > Regards,
> >> >> > Derek
> >> >> >
> >> >> >
> >> >> > On Tue, Jun 19, 2018 at 3:15 PM, Felipe Augusto Pereira de
> Figueiredo
> >> >> > via
> >> >> > USRP-users  wrote:
> >> >> >>
> >> >> >> Dear All,
> >> >> >>
> >> >> >> I've seen that with the gnuradio API it is possible to set a
> >> >> >> frequency
> >> >> >> and time in the future for a bursty transmission. With that
> feature
> >> >> >> it
> >> >> >> is possible to implement frequency hopping without any big
> trouble.
> >> >> >>
> >> >> >> I'd like to know if the same is possible with the UHD API, and if
> >> >> >> so,
> >> >> >> how 

Re: [USRP-users] Is it possible to set frequency along with a timed command for frequency hopping application?

[Derek Kozel via USRP-users]

Yes, I believe all of those commands are exposed in the C API.

For instance,
https://github.com/EttusResearch/uhd/blob/maint/
host/examples/rx_samples_c.c#L175

If you have the ability to use the C++ API for your application I would
generally recommend that as it is the native API for UHD. The C and Python
APIs are derived so sometimes do not follow the most idiomatic conventions
of the language. Also the C++ API has the most functionality as not all
functions and classes are available in the derived APIs.

Regards,
Derek

On Tue, Jun 19, 2018 at 5:10 PM, Felipe Augusto Pereira de Figueiredo <
zz4...@gmail.com> wrote:

> Dear Derek, thanks!
>
> Last question, are there any commands in the C API that do the same as
> the following ones?
>
> //we will tune the frontends in 100ms from now
> uhd::time_spec_t cmd_time = usrp->get_time_now() + uhd::time_spec_t(0.1);
> //sets command time on all devices
> //the next commands are all timed
> usrp->set_command_time(cmd_time);
> //tune channel 0 and channel 1
> usrp->set_rx_freq(1.03e9, 0); // Channel 0
> usrp->set_rx_freq(1.03e9, 1); // Channel 1
> //end timed commands
> usrp->clear_command_time();
>
> Kind Regards,
>
> Felipe
>
> On Tue, Jun 19, 2018 at 4:52 PM, Derek Kozel 
> wrote:
> > Hello Felipe,
> >
> > The oscillator will *start* tuning at the time stamp you specify. You
> will
> > have to characterize the settling time for your frequency hops and
> schedule
> > the tunes in advance of when you need to be at the new frequency.
> Depending
> > on what frequencies you are moving between and which daughterboard you
> are
> > using the settling time changes. It is important to note that timed
> commands
> > are executed in the order the are issued, not in chronological order, so
> you
> > must issue them in chronological order for to get the expected behavior.
> >
> > Regards,
> > Derek
> >
> > On Tue, Jun 19, 2018 at 3:45 PM, Felipe Augusto Pereira de Figueiredo
> >  wrote:
> >>
> >> Dear Derek, thanks for your prompt reply!
> >>
> >> I'm using an x310.
> >>
> >> Just to clarify, I want to make sure that the frequency I'm setting is
> >> only valid and guaranteed for that specific starting point (the
> >> timestamp into the future). Right now, when I send just the time
> >> command and change the frequency for the next packet I see with the
> >> spectrum analyser that the packets do not have the right frequency,
> >> instead, they are spread over the spectrum as the oscillator might be
> >> still under configuration, calibration, etc.
> >>
> >> Therefore, I hope that with the timed commands I will be able to have
> >> a better control over freq/time resources.
> >>
> >> Thanks and Kind Regards,
> >>
> >> Felipe
> >>
> >> On Tue, Jun 19, 2018 at 4:37 PM, Derek Kozel 
> >> wrote:
> >> > Hello Felipe,
> >> >
> >> > Yes it is possible. What USRP are you using? Some, such as the B200
> and
> >> > E310
> >> > cannot set the frequency using timed commands as the tuning is done by
> >> > the
> >> > RFIC rather than the FPGA. There is a small example of tuning in the
> >> > manual.
> >> > http://files.ettus.com/manual/page_sync.html#sync_phase_lo
> >> >
> >> > And a longer program using timed commands in the examples.
> >> >
> >> > https://github.com/EttusResearch/uhd/blob/maint/host/
> examples/test_timed_commands.cpp#L74
> >> >
> >> > The TwinRX fast frequency hopping example does not show the use of
> timed
> >> > commands for changing the local oscillator frequency, but does show
> very
> >> > efficient burst reception.
> >> >
> >> > https://github.com/EttusResearch/uhd/blob/maint/host/
> examples/twinrx_freq_hopping.cpp
> >> >
> >> > Regards,
> >> > Derek
> >> >
> >> >
> >> > On Tue, Jun 19, 2018 at 3:15 PM, Felipe Augusto Pereira de Figueiredo
> >> > via
> >> > USRP-users  wrote:
> >> >>
> >> >> Dear All,
> >> >>
> >> >> I've seen that with the gnuradio API it is possible to set a
> frequency
> >> >> and time in the future for a bursty transmission. With that feature
> it
> >> >> is possible to implement frequency hopping without any big trouble.
> >> >>
> >> >> I'd like to know if the same is possible with the UHD API, and if so,
> >> >> how can I do that? One example would be great.
> >> >>
> >> >> Thanks and Kind Regards,
> >> >>
> >> >> Felipe Augusto
> >> >>
> >> >> ___
> >> >> 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] Is it possible to set frequency along with a timed command for frequency hopping application?

[Derek Kozel via USRP-users]

Hello Felipe,

Yes it is possible. What USRP are you using? Some, such as the B200 and
E310 cannot set the frequency using timed commands as the tuning is done by
the RFIC rather than the FPGA. There is a small example of tuning in the
manual.
http://files.ettus.com/manual/page_sync.html#sync_phase_lo

And a longer program using timed commands in the examples.
https://github.com/EttusResearch/uhd/blob/maint/host/examples/test_timed_commands.cpp#L74

The TwinRX fast frequency hopping example does not show the use of timed
commands for changing the local oscillator frequency, but does show very
efficient burst reception.
https://github.com/EttusResearch/uhd/blob/maint/host/examples/twinrx_freq_hopping.cpp

Regards,
Derek


On Tue, Jun 19, 2018 at 3:15 PM, Felipe Augusto Pereira de Figueiredo via
USRP-users  wrote:

> Dear All,
>
> I've seen that with the gnuradio API it is possible to set a frequency
> and time in the future for a bursty transmission. With that feature it
> is possible to implement frequency hopping without any big trouble.
>
> I'd like to know if the same is possible with the UHD API, and if so,
> how can I do that? One example would be great.
>
> Thanks and Kind Regards,
>
> Felipe Augusto
>
> ___
> 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 X300 and phase alignment

[Derek Kozel via USRP-users]

Hello Alice,

A single 10 GigE connection should be able to carry two channels of 100
MS/s. Here is a link to some advice for tuning the Ethernet performance of
your computer.
http://files.ettus.com/manual/page_transport.html

Your current program has no use of timed commands so the phase offset will
be random for each tune. Here is the manual page on synchronization. You
will need to add the commands to your program.
http://files.ettus.com/manual/page_sync.html

Regards,
Derek

On Fri, Jun 15, 2018 at 12:33 PM, Alice Lo Valvo 
wrote:

> Hi Derek,
>
> thank you for your answer. My answers are below.
>
> Il 15/06/18 13:08, Derek Kozel ha scritto:
>
> Hello Alice,
>
> I think you have two different issues. You should not be encountering Late
> errors. How do you schedule your timed commands? What connection to the
> host computer are you using? 10 GigE should be able to handle 100 MS/s, are
> you using 1 GigE?
>
> I attached the python file that I created. I use 10GigE, but the channel
> bandwidth for each channel is 100MHz.. should't it be a problem?
>
> Separately, there will always be a phase offset between channels, even
> when using timed commands. Which daughterboards are you using? The
> requirements to achieve a repeatable phase offsets are different between
> boards.
>
> I'm using SBX 120...
>
> Regards,
> Alice
>
>
> Regards,
> Derek
>
> On Fri, Jun 15, 2018 at 11:13 AM, Alice Lo Valvo via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all,
>> I have to transmit two flows with the same "start trigger".
>> I used one USRP X300 with two channels, but because of the large
>> bandwidth (100MHz), there is the L error.
>> So, I tried to use two USRPs X300 with the OctoClock, but when I record
>> the transmitted signal they are not synchronize.. One signal starts before
>> the other one.. there is a costant offset phase, I think.
>> Any suggestion?
>>
>> Thank you in advance,
>>
>> Alice
>>
>>
>> ___
>> 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 N310 & RFNOC

[Derek Kozel via USRP-users]

Hello Dr Henarejos,

The N310 has the same level of RFNoC support as the X310, the same blocks
can be used on either. They use a common architecture so the structure and
properties are essentially unchanged. The uhd_image_builder is in the
process of having N310 support added, that should be released very soon.

Regards,
Derek

On Fri, Jun 15, 2018 at 11:38 AM, Pol Henarejos via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear all,
>
> - Which is the state of development of RFNOC in the new USRP N310? I
> cannot find any reference to N310 in the RFNOC documentation.
> - Which is the number of RFNOC blocks available in the N310 images?
> - Is uhd_image_builder_gui prepared for N310?
>
> Regards.
>
> --
>
> Dr. Pol Henarejos
> Researcher
> Array and Multi-Sensor Processing Department, Communication Systems
> Division
> pol.henare...@cttc.cat
>
> Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
> Av. Carl Friedrich Gauss, 7
> 08860 Castelldefels, Barcelona (Spain)
> Tel: +34 93 645 29 00  Ext: 2177
> www.cttc.cat
>
>
>
> ___
> 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 X300 and phase alignment

[Derek Kozel via USRP-users]

Hello Alice,

I think you have two different issues. You should not be encountering Late
errors. How do you schedule your timed commands? What connection to the
host computer are you using? 10 GigE should be able to handle 100 MS/s, are
you using 1 GigE?

Separately, there will always be a phase offset between channels, even when
using timed commands. Which daughterboards are you using? The requirements
to achieve a repeatable phase offsets are different between boards.

Regards,
Derek

On Fri, Jun 15, 2018 at 11:13 AM, Alice Lo Valvo via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
> I have to transmit two flows with the same "start trigger".
> I used one USRP X300 with two channels, but because of the large bandwidth
> (100MHz), there is the L error.
> So, I tried to use two USRPs X300 with the OctoClock, but when I record
> the transmitted signal they are not synchronize.. One signal starts before
> the other one.. there is a costant offset phase, I think.
> Any suggestion?
>
> Thank you in advance,
>
> Alice
>
>
> ___
> 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] Bypass Ettus E310 samples to external host

[Derek Kozel via USRP-users]

Hello Lucas,

The E310's ethernet connection is directly linked to the ARM side of the
processor so it is not possible to directly stream samples to the host. We
do have an application note describing how to forward samples to and from a
host computer from the E310.
https://kb.ettus.com/Streaming_processed_data_from_the_E31x_with_GNU_Radio_and_ZMQ

Unfortunately due to the limitations of the ARM streaming sample rates of
above ~10 MS/s are generally not possible over the 1 GigE link.

The upcoming E320 has a 10 GigE SFP connection, similar to the X310 and
N310, which is linked to the FPGA fabric and so provides the option of high
speed streaming to a remote host. You can compare the high level block
diagrams in these two files. More information will be available once the
E320 is released, which I do not have a date for.
https://files.ettus.com/marcomm/MUhm_GRCon17_Final.pdf
http://files.ettus.com/schematics/e310/e310.pdf

Regards,
Derek


On Fri, Jun 15, 2018 at 10:58 AM, Lucas Val Terrón via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello all,
>
> I am wondering if there is any way tested to transmit samples from Ettus
> E310 to an external host to process them.
>
> Two options in mind:
>
>1. Transmit samples by Ethernet interface.
>2. Bypass samples directly from the FPGA.
>
> 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] X310 Transmitting Energy on Zero Input

[Derek Kozel via USRP-users]

Hi Steve,

You're seeing LO leakage, a normal effect of transmitters. You can use an
lo offset to move the leakage away from your center frequency.
http://files.ettus.com/manual/page_general.html#general_tuning_process

Since you're using an RFNoC based flow (correct?) you'll need to add the
DUC block inline after the FIFO and use it to shift your baseband signal
away from DC. Then change the USRP Radio's frequency to cancel the DDC's
frequency shift.

Regards,
Derek

On Thu, Jun 14, 2018 at 9:55 AM, shachar J. brown via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi All,
>
> I've tried the following simple experiment with my brand new X310 (UBX-160
> daughterboards):
>
> GRC Signal Source   -->>   Throttle   -->>   DMA FIFO
>  -->>   USRP Radio
>
> I assigned ZERO AMPLITUDE to the signal source, USRP had central frequency
> of 1.5 [GHz] and gain of 20. Although the amplitude assigned was 0, I
> received a strong signal (-32[db]) at the center frequency in a spectrum
> analyzer. This unexpected energy is very bothersome and corrupts results of
> other applications of mine.
>
> Does anyone know what's going on and how can I prevent it?
>
> Thanks,
> Steve
>
>
>
>
>
>
> ___
> 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] Spectrum analyzer not picking up any signal from USRP-GNU Radio

[Derek Kozel via USRP-users]

Hello Ayaz,

UHD will log to standard out by default. You should be seeing it in the
console section of the GNU Radio Companion, at the bottom.

Multiplying by 500 will almost certainly lead to the signal clipping at the
DAC, completely corrupting your signal. The USRP Sink block expects values
between -1.0 and 1.0. The sample rate of 32kHz is very low. It should work,
but the general guidance is to use a somewhat higher rate as this helps
lessen the impact of the FPGA's filters on your passband signal.

Have you observed any signal from the USRP on your spectrum analyzer?
Starting with uhd_siggen_gui and making sure your spectrum analyzer is
setup correctly may be the best place to start, then your own GNU Radio
flowgraph with just the signal source going into the USRP Sink, then add
the OFDM modulation once all the rest is working.

Regards,
Derek


On Mon, Jun 11, 2018 at 9:47 PM, Ayaz Mahmud  wrote:

> Hi Derek,
>
>
>
> Thanks for pointing, I initially thought as the throttle was connected to
> WX GUI FFT it won’t affect the USRP sink.
>
>
>
> But the issue does not get resolves even after the throttle is removed. I
> tried increasing the gain to 30 and adding a multiply constant of 500 after
> the OFDM Mod block.
>
>
>
> As a beginner I did not knew about the log file. As I check the
> documentation the file is */usr/include/uhd/utils/log.hpp* but I am not
> sure how to run/see this logging. Any document link that you can provide as
> an example?
>
>
>
> On another hand I have tried implementing the exact same flow as in the
> link https://wiki.gnuradio.org/index.php/Guided_Tutorial_
> Hardware_Considerations - “The PSK Mod with USRP sink” one. And I am
> unable to get any output in spectrum analyzer as shown.
>
>
>
> Thanks,
>
> Ayaz
>
>
>
> *From:* Derek Kozel 
> *Sent:* Monday, June 11, 2018 1:34:01 PM
> *To:* Ayaz Mahmud
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] Spectrum analyzer not picking up any signal
> from USRP-GNU Radio
>
>
>
> Hello Ayaz,
>
> Because you have hardware in your flowgraph (the B210) you should not
> include a throttle block. Check your log output, it is very likely that UHD
> is reporting underflows.
>
> I'd recommend quickly running through the GNU Radio tutorial on using
> hardware.
> https://wiki.gnuradio.org/index.php/Guided_Tutorial_
> Hardware_Considerations
>
> Also the UHD manual has some general guidance which will help you to
> understand UHD's messages.
> http://files.ettus.com/manual/page_general.html
>
> Regards,
>
> Derek
>
>
>
> On Mon, Jun 11, 2018 at 8:26 PM, Ayaz Mahmud via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hi,
>
>
>
> GNU Radio version 3.7.11
>
> USRP B210 with 1 x 2.4GHz antenna
>
> Spectrum Analyzer with 2.4 GHz antenna
>
> I am trying to transmit the below flowgraph through USRP and receive a
> signal with Spectrum Analyzer. Though the Spectrum analyzer will not be
> able to demodulate it should show a stable frequency. Unfortunately, the
> spectrum analyzer does not pick any signal while calibrated at Center Freq:
> 2.412 GHz.
>
> GNU-Radio console warning:
>
> gr::log :WARN: ofdm_mapper_bcv0 - The gr::digital::ofdm_mapper_bcv block has 
> been deprecated.
>
> gr::log :WARN: ofdm_insert_preamble0 - The gr::digital::ofdm_insert_preamble 
> block has been deprecated.
>
>
>
>
> GNU Radio version 3.7.11
>
> USRP B210 with 1 x 2.4GHz antenna
>
> Spectrum Analyzer with 2.4 GHz antenna
>
> Block diagram attached.
>
> I am trying to transmit the below flowgraph through USRP and receive a
> signal with Spectrum Analyzer. Though the Spectrum analyzer will not be
> able to demodulate it should show a stable frequency. Unfortunately, the
> spectrum analyzer does not pick any signal while calibrated at Center Freq:
> 2.412 GHz.
>
> GNU-Radio console warning:
>
> gr::log :WARN: ofdm_mapper_bcv0 - The gr::digital::ofdm_mapper_bcv block has 
> been deprecated.
>
> gr::log :WARN: ofdm_insert_preamble0 - The gr::digital::ofdm_insert_preamble 
> block has been deprecated.
>
>
>
> Where can this possibly go wrong?
>
>
>
>
>
>
>
> Thanks,
>
> Ayaz
>
>
>
>
> ___
> 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] Spectrum analyzer not picking up any signal from USRP-GNU Radio

[Derek Kozel via USRP-users]

Hello Ayaz,

Because you have hardware in your flowgraph (the B210) you should not
include a throttle block. Check your log output, it is very likely that UHD
is reporting underflows.
I'd recommend quickly running through the GNU Radio tutorial on using
hardware.
https://wiki.gnuradio.org/index.php/Guided_Tutorial_Hardware_Considerations

Also the UHD manual has some general guidance which will help you to
understand UHD's messages.
http://files.ettus.com/manual/page_general.html

Regards,
Derek

On Mon, Jun 11, 2018 at 8:26 PM, Ayaz Mahmud via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
>
>
> GNU Radio version 3.7.11
>
> USRP B210 with 1 x 2.4GHz antenna
>
> Spectrum Analyzer with 2.4 GHz antenna
>
> I am trying to transmit the below flowgraph through USRP and receive a
> signal with Spectrum Analyzer. Though the Spectrum analyzer will not be
> able to demodulate it should show a stable frequency. Unfortunately, the
> spectrum analyzer does not pick any signal while calibrated at Center Freq:
> 2.412 GHz.
>
> GNU-Radio console warning:
>
> gr::log :WARN: ofdm_mapper_bcv0 - The gr::digital::ofdm_mapper_bcv block has 
> been deprecated.
>
> gr::log :WARN: ofdm_insert_preamble0 - The gr::digital::ofdm_insert_preamble 
> block has been deprecated.
>
>
>
>
> GNU Radio version 3.7.11
>
> USRP B210 with 1 x 2.4GHz antenna
>
> Spectrum Analyzer with 2.4 GHz antenna
>
> Block diagram attached.
>
> I am trying to transmit the below flowgraph through USRP and receive a
> signal with Spectrum Analyzer. Though the Spectrum analyzer will not be
> able to demodulate it should show a stable frequency. Unfortunately, the
> spectrum analyzer does not pick any signal while calibrated at Center Freq:
> 2.412 GHz.
>
> GNU-Radio console warning:
>
> gr::log :WARN: ofdm_mapper_bcv0 - The gr::digital::ofdm_mapper_bcv block has 
> been deprecated.
>
> gr::log :WARN: ofdm_insert_preamble0 - The gr::digital::ofdm_insert_preamble 
> block has been deprecated.
>
>
>
> Where can this possibly go wrong?
>
>
>
>
>
>
>
> Thanks,
>
> Ayaz
>
>
>
> ___
> 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] X310 Register's Memory Capability

[Derek Kozel via USRP-users]

I'm not an FPGA expert by a long shot so I'm afraid I can't point at
anything specific. The DRAM FIFO may offer some inspiration or the SRAM
FIFOs. How and where you need to access the data will influence what the
best solution is. Can you say anything more about your application? That
would likely help other, more experienced, people on the list to give you
more specific advice.

Derek

On Fri, Jun 8, 2018 at 12:06 PM, shachar J. brown 
wrote:

> Thank you Jonathon and Derek,
>
> Derek, you are absolutely correct. I'm not planning on storing filter taps
> but rather generic data, and lots of it. Likewise, I'm planning on changing
> the data on the run. What's your suggestion for the most efficient way on
> doing this? (By efficient, I mean a way that doesn't clog the 128 available
> registers).
>
> Thanks again,
> Steve
>
> On Fri, Jun 8, 2018 at 9:57 AM, Derek Kozel  wrote:
>
>> Hi Steve,
>>
>> As an addon to Jonathon's email, you haven't actually said that you want
>> to store filter taps. If you are storing generic data then the embedded
>> regs are unlikely to be helpful for you because you are not going to be
>> using the data with DSP48s.
>>
>> Regards,
>> Derek
>>
>> On Fri, Jun 8, 2018 at 6:04 AM, Jon Pendlum via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi Steve,
>>>
>>> USE_EMBEDDED_REGS_COEFFS means that the filter will attempt to infer
>>> the DSP48's embedded registers (specifically register B) for storing
>>> coefficients. You should refer to Xilinx's DSP48 design doc
>>> https://www.xilinx.com/support/documentation/user_guides/ug4
>>> 79_7Series_DSP48E1.pdf.
>>>
>>> Using embedded registers is more efficient, because those registers
>>> come for free as part of the DSP48. However, the embedded registers
>>> only have a reset and will initialize to all 0s (instead of the
>>> coefficients in COEFFS_VEC). At startup, the coefficients must be
>>> loaded via the settings register bus for the filter to be useful. This
>>> is not a big deal though, since the block controller for
>>> noc_block_fir_filter does that. Also, since the embedded registers are
>>> chained like shift register (via BCOUT output to B input), loading new
>>> coefficients while streaming causes the FIR filter output to be
>>> corrupted until all the new coefficients have been loaded.
>>>
>>> If you set USE_EMBEDDED_REGS_COEFFS = 0, then regular registers will
>>> be instantiated. Those registers will be initialized with COEFFS_VEC
>>> and the filter will always be ready to go. Also, the output will not
>>> be corrupted while loading new coefficients.
>>>
>>> I would suggest enabling USE_EMBEDDED_REGS_COEFFS unless you plan to
>>> constantly change coefficients and are worried about the filter output
>>> being corrupted.
>>>
>>> Jonathon
>>>
>>> On Fri, Jun 8, 2018 at 12:06 AM, shachar J. brown via USRP-users
>>>  wrote:
>>> > After examining the files in depth, I realized I need some help
>>> > understanding core concepts in FPGA programming:
>>> >
>>> > In "axi_fir_filter.v" there is a parameter named
>>> "USE_EMBEDDED_REGS_COEFFS",
>>> > and explained in comment: " Reduce register usage by only using
>>> embedded
>>> > registers in DSP slices".
>>> >
>>> > - What is the actual difference between registers and embedded
>>> registers?
>>> > - Does the implementation of the two only differ in usage of "wire" vs.
>>> > "reg"?
>>> >
>>> > Thanks for your time,
>>> > Steve
>>> >
>>> > On Thu, Jun 7, 2018 at 11:28 AM, Nick Foster 
>>> wrote:
>>> >>
>>> >> It's going to depend on how much block RAM the image is already
>>> using, and
>>> >> how much more you can use while still getting the image to route. The
>>> >> easiest way to find out will be to try it.
>>> >>
>>> >> On Thu, Jun 7, 2018, 9:14 AM shachar J. brown <
>>> shachar.br...@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> Thanks Nick, that's an excellent example.
>>> >>> Do you know what are the memory size restrictions of the
>>> configuration
>>> >>> data?
>>> >>>
>>> >>> On Thu, Jun 7, 2018 at 10:50 AM, Nick Foster 
>>> >>> wrote:
>>> 
>>>  Look at the RFNoC FIR filter block for a good example of pushing
>>>  configuration data into a block via the settings bus.
>>> 
>>>  On Thu, Jun 7, 2018, 8:25 AM shachar J. brown via USRP-users
>>>   wrote:
>>> >
>>> > Hi all,
>>> >
>>> > I'm working on an X310.
>>> >
>>> > I have large data (tables of 1-3 K of variables) I would like to
>>> insert
>>> > into the FPGA's memory registers while running.
>>> >
>>> > How much space is available in the FPGA? Seemingly, the Address
>>> for the
>>> > "set_register" is only 8 bits long, and the first 128 addresses
>>> are reserved
>>> > for the Noc_Shell. So... Does that mean I can store only 128
>>> variables at a
>>> > time?
>>> >
>>> > (Just to clarify: I want to change the data while running, and I'd
>>> like
>>> > it to be inside the FPGA for performance issues).
>>> >
>>> > Thank a 

Re: [USRP-users] NI USRP-2944R with PCIe Connectivity.

[Derek Kozel via USRP-users]

Hello Felix,

Currently the documentation is correct, the PCIe driver is not supported on
the 4.4.x kernel. We are working to get it updated and hope to have a
timeline for its release soon.

Is there a problem that I can help with to make your 10 Gigabit Ethernet
connection work? Ethernet is a better choice in most scenarios. I am not
familiar with the requirements of the Open Air Interface software so it is
possible that it is one of the applications where PCIe does have benefits.

Regards,
Derek

On Fri, Jun 8, 2018 at 10:12 AM, Felix Dsouza via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear OAI community,
>
> I am trying to use USRP RIO (NI 2944R) using PCIe 10Gigabit Ehternet card
> for Desktop but I have errors installing the PCIe drivers on Ubuntu 16.04.
>
> The kernel version recommended is *4.2.x* on the webpage whereas the
> Ubuntu 16.04 runs kernel version over *4.4.x *and the application I use
> with the USRP requires ubuntu version 16.04
>
> [nikal.ko] Error 2: ERROR:  failed to build nikal
>
> I am following the Ettus link for the installation:
> https://files.ettus.com/manual/page_ni_rio_kernel.html
>
> I was bale able to connect it using Ethernet, but PCIe does not work for
> me.
>
> Can you please guide me on where I am going wrong, or if you could provide
> the right set of drivers for it.
>
> Best regards,
> Felix Dsouza
>
>
> ___
> 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 E313

[Derek Kozel via USRP-users]

Hello Ivan,

The antenna ports are named TX/RX and RX2 for channel 0 and 1, the same as
the B210. The standard USRP Source and Sink block will allow you to select
these antennas. This assumes that you are running GNU Radio on the USRP.
The ZMQ application note provides a way to move lower sample rate streams
to a remote computer.

Regards,
Derek

On Fri, Jun 8, 2018 at 10:13 AM, Ivan Zahartchuk 
wrote:

> Thanks for the help. Could you tell me more about how to access the ports
> of RХ1, RX2 and ТХ1 ТХ2 in the gnuradio?
>
> 2018-06-06 12:17 GMT+03:00 Derek Kozel :
>
>> Hello Ivan,
>>
>> Here are a few links to get you started. As an embedded computing device
>> you'll find the experience somewhat different from a B200.
>>
>> https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_Getting
>> _Started_Guides
>> https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_Hardware_Resources
>>
>> https://kb.ettus.com/Software_Development_on_the_E310_and_E312
>> https://kb.ettus.com/Streaming_processed_data_from_the_E31x_
>> with_GNU_Radio_and_ZMQ
>>
>> Regards,
>> Derek
>>
>> On Wed, Jun 6, 2018 at 8:40 AM, Ivan Zahartchuk via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello. Recently I fell into the hands of the USRP E313. I'm interested
>>> in a few questions about it.
>>> 1. Is it possible to visualize the data that it processes?
>>> 2. Is there any instruction for working and programming boards of this
>>> kind?
>>> I used to work with the USRP B200, but everything is a bit simpler there.
>>>
>>> ___
>>> 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] X310 Register's Memory Capability

[Derek Kozel via USRP-users]

Hi Steve,

As an addon to Jonathon's email, you haven't actually said that you want to
store filter taps. If you are storing generic data then the embedded regs
are unlikely to be helpful for you because you are not going to be using
the data with DSP48s.

Regards,
Derek

On Fri, Jun 8, 2018 at 6:04 AM, Jon Pendlum via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Steve,
>
> USE_EMBEDDED_REGS_COEFFS means that the filter will attempt to infer
> the DSP48's embedded registers (specifically register B) for storing
> coefficients. You should refer to Xilinx's DSP48 design doc
> https://www.xilinx.com/support/documentation/user_
> guides/ug479_7Series_DSP48E1.pdf.
>
> Using embedded registers is more efficient, because those registers
> come for free as part of the DSP48. However, the embedded registers
> only have a reset and will initialize to all 0s (instead of the
> coefficients in COEFFS_VEC). At startup, the coefficients must be
> loaded via the settings register bus for the filter to be useful. This
> is not a big deal though, since the block controller for
> noc_block_fir_filter does that. Also, since the embedded registers are
> chained like shift register (via BCOUT output to B input), loading new
> coefficients while streaming causes the FIR filter output to be
> corrupted until all the new coefficients have been loaded.
>
> If you set USE_EMBEDDED_REGS_COEFFS = 0, then regular registers will
> be instantiated. Those registers will be initialized with COEFFS_VEC
> and the filter will always be ready to go. Also, the output will not
> be corrupted while loading new coefficients.
>
> I would suggest enabling USE_EMBEDDED_REGS_COEFFS unless you plan to
> constantly change coefficients and are worried about the filter output
> being corrupted.
>
> Jonathon
>
> On Fri, Jun 8, 2018 at 12:06 AM, shachar J. brown via USRP-users
>  wrote:
> > After examining the files in depth, I realized I need some help
> > understanding core concepts in FPGA programming:
> >
> > In "axi_fir_filter.v" there is a parameter named
> "USE_EMBEDDED_REGS_COEFFS",
> > and explained in comment: " Reduce register usage by only using embedded
> > registers in DSP slices".
> >
> > - What is the actual difference between registers and embedded registers?
> > - Does the implementation of the two only differ in usage of "wire" vs.
> > "reg"?
> >
> > Thanks for your time,
> > Steve
> >
> > On Thu, Jun 7, 2018 at 11:28 AM, Nick Foster 
> wrote:
> >>
> >> It's going to depend on how much block RAM the image is already using,
> and
> >> how much more you can use while still getting the image to route. The
> >> easiest way to find out will be to try it.
> >>
> >> On Thu, Jun 7, 2018, 9:14 AM shachar J. brown 
> >> wrote:
> >>>
> >>> Thanks Nick, that's an excellent example.
> >>> Do you know what are the memory size restrictions of the configuration
> >>> data?
> >>>
> >>> On Thu, Jun 7, 2018 at 10:50 AM, Nick Foster 
> >>> wrote:
> 
>  Look at the RFNoC FIR filter block for a good example of pushing
>  configuration data into a block via the settings bus.
> 
>  On Thu, Jun 7, 2018, 8:25 AM shachar J. brown via USRP-users
>   wrote:
> >
> > Hi all,
> >
> > I'm working on an X310.
> >
> > I have large data (tables of 1-3 K of variables) I would like to
> insert
> > into the FPGA's memory registers while running.
> >
> > How much space is available in the FPGA? Seemingly, the Address for
> the
> > "set_register" is only 8 bits long, and the first 128 addresses are
> reserved
> > for the Noc_Shell. So... Does that mean I can store only 128
> variables at a
> > time?
> >
> > (Just to clarify: I want to change the data while running, and I'd
> like
> > it to be inside the FPGA for performance issues).
> >
> > Thank a ton!
> > Steve
> > ___
> > 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] USRP N310's schematics

[Derek Kozel via USRP-users]

Hello Jon,

The schematics are still being readied for posting to the website. I'm
sorry for the delay in having them available. Do you have any specific
questions that I might be able to answer in the meanwhile? The files will
be posted to the Knowledge Base when they are ready.
https://kb.ettus.com/N300/N310

Regards,
Derek

On Fri, Jun 8, 2018 at 2:19 AM, liu Jong via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
> Could you tell us where we can download USRP N310's schematics.
> Thank you.
>
> best regards
> Jon
>
> ___
> 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] IQ Calibration - CPU Performance Impact?

[Derek Kozel via USRP-users]

Dave,

It is most tunes (as often as needed when changing the frequency would
change the IQ correction value). The overhead is, I believe, just a single
write and thus completely inconsequential when compared to the usual length
of synthesizer SPI writes and switch selection that tuning can cause.

Regards,
Derek

On Thu, Jun 7, 2018 at 7:08 PM, Dave NotTelling via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Robin,
>  Thanks for your feedback!
>
> Marcus,
>  And that overhead is just on the initial tune, or for all tunes?  I
> do mostly timed commands, so should I allow for a little more time before
> the deadline to send the timed command out?
>
> Thanks all!
>
> On Thu, Jun 7, 2018 at 1:56 PM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 06/07/2018 01:04 PM, Dave NotTelling via USRP-users wrote:
>> > Is there a processing requirement impact to using the calibration CSV
>> > file?  Does using the cal data have any impact on tuning time for the
>> > radio itself?
>> >
>> > Thanks!
>> >
>> The calibration values are stuffed into some machinery in the FPGA when
>> tuning happens.  So, there's a little extra command-channel overhead.
>>
>>
>>
>> ___
>> 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] Consequences of late command

[Derek Kozel via USRP-users]

Hello Fabian,

Commands which are late will be executed anyways and return the error
notification which you are seeing. Commands after it are also executed.
Depending on your application it is often possible to structure the
commands such that get_time_now only needs to be called in the beginning
and the act of receiving can be used to keep track of the device time. The
TwinRX fast frequency hopping example does this, allowing for continuous
and stable frequency hopping and burst receiving at a very high rate.

Regards,
Derek

On Thu, Jun 7, 2018 at 12:12 PM, Fabian Schwartau via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone,
>
> I am currently working with timed commands to perform synchronized
> reception of multiple channels. As the timing is quite critilical I would
> like to use quite low delay I add to usrp->get_time_now() for the next
> command(s). However, sometimes it happens (even with quite high values like
> 20ms) that I get an late command error when reading the data from the
> stream. I guess this can happen from time to time if the thread was
> interrupted by the OS to do other stuff. And this is not a problem, if it
> happens just from time to time. But I don't know how to handle the problem.
> Is the command that was too late executed anyway? What about the commands
> after that?
> Is there is simple way to get in a clean state after receiving this error?
> Like delete all commands in the queue and clear all buffers?
>
> I am using two USRP X310 with each 2 TwinRX. PPS, 10 MHz and LOs are
> synchronized over all boards.
>
> Best regards,
> Fabian
>
> ___
> 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] Building the UHD for N3XX devices.

[Derek Kozel via USRP-users]

Hello Walter,

The N310 uses MPMD as it's host side interface so the appropriate flag is
-DENABLE_MPMD. I'll see about documenting that better. The E3xx build flag
is entirely separate.
http://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_software_dev_uhd

Regards,
Derek

On Thu, Jun 7, 2018 at 5:14 AM, Walter Maguire via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> When building the UHD for the E300 devices cmake uses the option
>
> -DENABLE_E300=ON
>
> However, when building for the N3XX devices there is no cmake option
>
> (Checked with cmake -LAH) to target the N3XX devices.
>
> git status returns
>
> Your branch is up-to-date with 'origin/rfnoc-devel'
>
> I was expecting to see a cmake option like
>
> -DENABLE_N300, -DENABLE_N310 or -DENABLE_N3XX.
>
> As both the N3XX and E3XX devices use zynq parts can we assume building
> for the -DENABLE_E300=ON will be sufficient for the N3XX devices?
>
> Are you planning on updating the build systems to target the N3XX parts
> directly?
>
>
> Regards
>
>
>
> Walter
>
>
> ___
> 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 E313

[Derek Kozel via USRP-users]

Hello Ivan,

Here are a few links to get you started. As an embedded computing device
you'll find the experience somewhat different from a B200.

https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_Getting_Started_Guides
https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_Hardware_Resources

https://kb.ettus.com/Software_Development_on_the_E310_and_E312
https://kb.ettus.com/Streaming_processed_data_from_the_E31x_with_GNU_Radio_and_ZMQ

Regards,
Derek

On Wed, Jun 6, 2018 at 8:40 AM, Ivan Zahartchuk via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello. Recently I fell into the hands of the USRP E313. I'm interested in
> a few questions about it.
> 1. Is it possible to visualize the data that it processes?
> 2. Is there any instruction for working and programming boards of this
> kind?
> I used to work with the USRP B200, but everything is a bit simpler there.
>
> ___
> 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] Synchronized frequency hopping

[Derek Kozel via USRP-users]

You should use a tune_request_t to manually specify the DSP frequency. The
issue is that only the master (LO source) channel knows about the actual
frequency error in the LO and will automatically use the DDC to compensate
for that error. The other channels must have the same correction applied
manually.
http://files.ettus.com/manual/page_general.html#general_tuning

The GNU Radio UHD interface automatically does this. It is in Python, but
the concept is fairly well illustrated.
https://github.com/gnuradio/gnuradio/blob/34f7e66e82079ef25b72ba6d6931fac05cfb968a/gr-uhd/apps/uhd_app.py#L219

Regards,
Derek

On Mon, Jun 4, 2018 at 1:14 PM, Fabian Schwartau via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Derek,
>
> I think I got that. Is the DDC frequency + offset aligned automatically if
> I use a timed command for usrp->set_rx_freq()? Or is there some other
> command I missed?
>
> Best regards,
> Fabian
>
> Am 04.06.2018 um 13:20 schrieb Derek Kozel:
>
>> Fabian,
>>
>> Timed commands, carefully and correctly used along with common 10 MHz and
>> 1PPS, can give you time aligned reception with an accuracy of one sample
>> clock period. They are used by many projects for this. To have repeatable
>> phase relationships between channels you must also use timed commands to
>> set the DDC frequency offset and decimation. This ensures that you have
>> exactly matching frequency on all channels and exactly the number of
>> samples produced on each stream so they stay inline. With the TwinRX you
>> must use LO sharing between all channels to have repeatable phase offsets.
>>
>> The LOs take approximately 5mS to settle on the TwinRX, so for your
>> application you can issue a tune command for time X, then a stream command
>> for X + 5mS.
>> https://github.com/EttusResearch/uhd/blob/maint/host/
>> examples/twinrx_freq_hopping.cpp
>>
>> Regards,
>> Derek
>>
>> On Mon, Jun 4, 2018 at 11:47 AM, Fabian Schwartau via USRP-users <
>> usrp-users@lists.ettus.com > wrote:
>>
>> Hello Derek,
>> thank you very much.
>> So is it correct, that the timing using the set_comman_time()
>> function is so precise that I can do MIMO with it? That would be
>> great :)
>>
>> Best regards,
>> Fabian
>>
>> Am 04.06.2018 um 10:52 schrieb Derek Kozel:
>>
>> Hello Fabien,
>>
>> Yes, it is possible to queue commands, however there are two
>> important things to keep in mind. The commands will block any
>> other commands in the same queue from executing until the
>> current one's time is reached. So commands must be sent in order
>> (100, then 120, 140 ...). Second, the queue has finite length
>> and if too many commands are sent it will backup into the host.
>>
>> The TwinRX frequency hopping example will be a good reference
>> for you to look at. It implements a different strategy where
>> only one channel is used to receive and the second channel is
>> used as a secondary LO source, but its inner loop shows how to
>> use burst receiving and timed commands to have sample accurate
>> timing and do a precise sweep across a list of frequencies.
>>
>> Regards,
>> Derek
>>
>> On Mon, Jun 4, 2018 at 8:40 AM, Fabian Schwartau via USRP-users
>> mailto:usrp-users@lists.ettus.com>
>> >
>> >> wrote:
>>
>>  Hi,
>>
>>  thanks for the great answer.
>>  One more question: Is it possible to send multiple commands
>> for
>>  different times right after each other? So for example if the
>>  current time is 100, I execute the code you provided for
>> 120, 140
>>  and 160 at once without waiting for the command at 120 to
>> be executed.
>>
>>  Best regards,
>>  Fabian
>>
>>
>>  Am 03.06.2018 um 12:44 schrieb Marcus Müller:
>>
>>  Hello Fabian,
>>
>>  the issue can be overcome using what we call timed
>> commands – simply
>>  tell your USRP to tune that LO at time X, and it'll do
>> exactly that!
>>
>>  A bit of example code:
>>
>>  //we will tune the frontends in 500ms from now
>>  uhd::time_spec_t cmd_time = usrp->get_time_now() +
>>  uhd::time_spec_t(0.5);
>>
>>  //sets command time on all devices
>>  //the next commands are all timed
>>  usrp->set_command_time(cmd_time);
>>
>>  //tune channel 0 and channel 1
>>  usrp->set_rx_freq(1.03e9, 0); // Channel 0
>>  usrp->set_rx_freq(1.03e9, 1); // Channel 1
>>
>>  //end timed commands
>>  usrp->clear_command_time();
>>
>>  You can also 

Re: [USRP-users] Synchronized frequency hopping

[Derek Kozel via USRP-users]

Fabian,

Timed commands, carefully and correctly used along with common 10 MHz and
1PPS, can give you time aligned reception with an accuracy of one sample
clock period. They are used by many projects for this. To have repeatable
phase relationships between channels you must also use timed commands to
set the DDC frequency offset and decimation. This ensures that you have
exactly matching frequency on all channels and exactly the number of
samples produced on each stream so they stay inline. With the TwinRX you
must use LO sharing between all channels to have repeatable phase offsets.

The LOs take approximately 5mS to settle on the TwinRX, so for your
application you can issue a tune command for time X, then a stream command
for X + 5mS.
https://github.com/EttusResearch/uhd/blob/maint/host/examples/twinrx_freq_hopping.cpp

Regards,
Derek

On Mon, Jun 4, 2018 at 11:47 AM, Fabian Schwartau via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello Derek,
> thank you very much.
> So is it correct, that the timing using the set_comman_time() function is
> so precise that I can do MIMO with it? That would be great :)
>
> Best regards,
> Fabian
>
> Am 04.06.2018 um 10:52 schrieb Derek Kozel:
>
>> Hello Fabien,
>>
>> Yes, it is possible to queue commands, however there are two important
>> things to keep in mind. The commands will block any other commands in the
>> same queue from executing until the current one's time is reached. So
>> commands must be sent in order (100, then 120, 140 ...). Second, the queue
>> has finite length and if too many commands are sent it will backup into the
>> host.
>>
>> The TwinRX frequency hopping example will be a good reference for you to
>> look at. It implements a different strategy where only one channel is used
>> to receive and the second channel is used as a secondary LO source, but its
>> inner loop shows how to use burst receiving and timed commands to have
>> sample accurate timing and do a precise sweep across a list of frequencies.
>>
>> Regards,
>> Derek
>>
>> On Mon, Jun 4, 2018 at 8:40 AM, Fabian Schwartau via USRP-users <
>> usrp-users@lists.ettus.com > wrote:
>>
>> Hi,
>>
>> thanks for the great answer.
>> One more question: Is it possible to send multiple commands for
>> different times right after each other? So for example if the
>> current time is 100, I execute the code you provided for 120, 140
>> and 160 at once without waiting for the command at 120 to be executed.
>>
>> Best regards,
>> Fabian
>>
>>
>> Am 03.06.2018 um 12:44 schrieb Marcus Müller:
>>
>> Hello Fabian,
>>
>> the issue can be overcome using what we call timed commands –
>> simply
>> tell your USRP to tune that LO at time X, and it'll do exactly
>> that!
>>
>> A bit of example code:
>>
>> //we will tune the frontends in 500ms from now
>> uhd::time_spec_t cmd_time = usrp->get_time_now() +
>> uhd::time_spec_t(0.5);
>>
>> //sets command time on all devices
>> //the next commands are all timed
>> usrp->set_command_time(cmd_time);
>>
>> //tune channel 0 and channel 1
>> usrp->set_rx_freq(1.03e9, 0); // Channel 0
>> usrp->set_rx_freq(1.03e9, 1); // Channel 1
>>
>> //end timed commands
>> usrp->clear_command_time();
>>
>> You can also instruct the RX streamer to start streaming at a
>> specific
>> time, so that you either know beforehand, at which sample count
>> the
>> tuning happened.
>> Alternatively, the rx_metadata coming from the USRP contains
>> timestamps
>>of the first sample in the sample packet, so you can use that
>> to
>> calculate at which sample the tuning happens.
>>
>> Best regards,
>> Marcus
>>
>> On Sun, 2018-06-03 at 11:35 +0200, Fabian Schwartau via USRP-users
>> wrote:
>>
>> Hello everyone,
>>
>> I have a question about frequency hopping in a synchronized
>> scenario.
>> I
>> have two USRP X310, each equipped with two TwinRX. The LOs are
>> generated
>> by one of the TwinRX and are distributed to all the others
>> (even
>> across
>> the two motherboards). 10 MHz and 1PPS are also coming from
>> a single
>> source. Then I use the "unknown PPS" method to sync the
>> ADCs. This
>> works
>> perfectly.
>> Now I listen to a single frequency on all channels and
>> change this
>> frequency frequently. I would like to hop the frequency
>> every 20ms or
>> faster. In order not to loose the ADC synchronization, I
>> start a
>> continuous stream and switch the frequency while receiving.
>> This
>> works
>> in principle, but I am not able 

Re: [USRP-users] Synchronized frequency hopping

[Derek Kozel via USRP-users]

Hello Fabien,

Yes, it is possible to queue commands, however there are two important
things to keep in mind. The commands will block any other commands in the
same queue from executing until the current one's time is reached. So
commands must be sent in order (100, then 120, 140 ...). Second, the queue
has finite length and if too many commands are sent it will backup into the
host.

The TwinRX frequency hopping example will be a good reference for you to
look at. It implements a different strategy where only one channel is used
to receive and the second channel is used as a secondary LO source, but its
inner loop shows how to use burst receiving and timed commands to have
sample accurate timing and do a precise sweep across a list of frequencies.

Regards,
Derek

On Mon, Jun 4, 2018 at 8:40 AM, Fabian Schwartau via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> thanks for the great answer.
> One more question: Is it possible to send multiple commands for different
> times right after each other? So for example if the current time is 100, I
> execute the code you provided for 120, 140 and 160 at once without waiting
> for the command at 120 to be executed.
>
> Best regards,
> Fabian
>
>
> Am 03.06.2018 um 12:44 schrieb Marcus Müller:
>
>> Hello Fabian,
>>
>> the issue can be overcome using what we call timed commands – simply
>> tell your USRP to tune that LO at time X, and it'll do exactly that!
>>
>> A bit of example code:
>>
>> //we will tune the frontends in 500ms from now
>> uhd::time_spec_t cmd_time = usrp->get_time_now() +
>> uhd::time_spec_t(0.5);
>>
>> //sets command time on all devices
>> //the next commands are all timed
>> usrp->set_command_time(cmd_time);
>>
>> //tune channel 0 and channel 1
>> usrp->set_rx_freq(1.03e9, 0); // Channel 0
>> usrp->set_rx_freq(1.03e9, 1); // Channel 1
>>
>> //end timed commands
>> usrp->clear_command_time();
>>
>> You can also instruct the RX streamer to start streaming at a specific
>> time, so that you either know beforehand, at which sample count the
>> tuning happened.
>> Alternatively, the rx_metadata coming from the USRP contains timestamps
>>   of the first sample in the sample packet, so you can use that to
>> calculate at which sample the tuning happens.
>>
>> Best regards,
>> Marcus
>>
>> On Sun, 2018-06-03 at 11:35 +0200, Fabian Schwartau via USRP-users
>> wrote:
>>
>>> Hello everyone,
>>>
>>> I have a question about frequency hopping in a synchronized scenario.
>>> I
>>> have two USRP X310, each equipped with two TwinRX. The LOs are
>>> generated
>>> by one of the TwinRX and are distributed to all the others (even
>>> across
>>> the two motherboards). 10 MHz and 1PPS are also coming from a single
>>> source. Then I use the "unknown PPS" method to sync the ADCs. This
>>> works
>>> perfectly.
>>> Now I listen to a single frequency on all channels and change this
>>> frequency frequently. I would like to hop the frequency every 20ms or
>>> faster. In order not to loose the ADC synchronization, I start a
>>> continuous stream and switch the frequency while receiving. This
>>> works
>>> in principle, but I am not able to identify at which frequency the
>>> data
>>> that currently comes in was recorded. I tried using a constant time
>>> from
>>> setting the new frequency to when I assume the new data to be at the
>>> new
>>> frequency. But even with a timeout of ~50ms the results in data
>>> indicate
>>> the the delay was not enough in a very few cases.
>>> I know there is the locked_lo sensor, but this also does not help. I
>>> guess this is caused by buffers which cause a more or less random
>>> delay
>>> between setting the frequency and receiving the data. This depends on
>>> CPU load and other things, so it is quite random.
>>> Is there a way to solve this issue? E.g. by embedding information
>>> about
>>> the LO state in the data. Or defining an exact time when to execute
>>> the
>>> frequency switch, so that I can use the metadata timestamp in the
>>> receive stream to identify the exact point when the frequency was
>>> switched (I know that the locking can take a few ms - so I would
>>> discard
>>> the data between the switch and the signalling+locking offset). Or is
>>> it
>>> possible to perform multiple time limited captures without having to
>>> sync the ADCs again?
>>> In an ideal situation I would like the FPGA to switch frequency, wait
>>> for LOs to lock, take a single shot synchronized measurement (~1ms of
>>> data), transmit the data to the PC (I am using 10G link) and continue
>>> with the next frequency. Is that possible without touching the FPGA
>>> code?
>>>
>>> Best regards,
>>> Fabian
>>>
>>> ___
>>> 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
> 

Re: [USRP-users] UHD use

[Derek Kozel via USRP-users]

Hello Joseph,

The name of each example is accurate as a brief description of it's
function. Are there any which you have a question about? The
rx_samples_to_file and tx_samples_from_file are very simple programs that
show receiving and transmitting. benchmark_rate can do both at the same
time but focuses on the throughput of samples rather than configuring any
RF settings.

Regards,
Derek

On Tue, May 29, 2018 at 5:17 PM, Joseph Paucar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello everyone
> I am new to using USRP
> I have installed UHD and GNURadio, and I have transmitted files using
> GNURadio, and it works normal, but I want to transmit and receive using UHD.
> Can someone give me a brief explanation of what each example of the UHD
> does?
>
> https://github.com/EttusResearch/uhd/tree/maint/host/examples
>
>   Thank you
>
>
>
>
> ___
> 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] Using ZMQ

[Derek Kozel via USRP-users]

Oops, re-added the wrong list there. Reposting to usrp-users with GNU Radio
as BCC.

On Mon, May 28, 2018 at 2:24 PM, Derek Kozel  wrote:

> Hello Steve,
>
> Please keep the mailing list included unless you are talking about
> something which requires privacy. GNU Radio runs natively on Windows. It is
> not as well supported from an end developer stand point, but it is
> available and with a bit of work can be a very viable answer.
> https://wiki.gnuradio.org/index.php/InstallingGR#Windows
>
> Regards,
> Derek
>
> On Mon, May 28, 2018 at 1:10 PM, shachar J. brown  > wrote:
>
>> Hi Derek,
>>
>> I am unfamiliar with such functionality:
>> How can I run a full gnuradio flow graph via windows?
>>
>> Thanks,
>> Steve
>>
>> On Mon, May 28, 2018 at 3:02 PM, Derek Kozel 
>> wrote:
>>
>>> Hello Steve,
>>>
>>> Can you directly use the X310 from the Windows PC? UHD is fully
>>> supported on Windows 7 to 10.
>>>
>>> Regards,
>>> Derek
>>>
>>> On Mon, May 28, 2018 at 12:09 PM, shachar J. brown via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Thanks Marcus, I got it to work just fine.

 Your remark is a little concerning... is there any more efficient way
 to send data over the internet?

 Furthermore, I actually don't necessarily need to pass the samples over
 the internet. I simply need to send the samples directly from the X310 to a
 windows PC at high rate (Employer's demands, non-negotiable).
 Is there any way to get around this problem? for instance, instead of
 the internet to construct some communication box? I've never dealt with
 such things before

 Thanks again,
 Steve

 On Mon, May 28, 2018 at 12:37 AM, Marcus Müller <
 marcus.muel...@ettus.com> wrote:

> Hi Steve,
>
> That's a pretty network-centric question!
>
> So, first of all, you need to make sure you can actually send IP
> packets from one computer to the other - that will require figuring out 
> the
> public IP address of the server end of the connection, making sure the
> firewall on that computer allows for connections to that port, and also
> make sure that if any routers are in between (especially if they do
> NAT/masquerading), that these will forward the packets.
>
> As a side remark: even the lowest sample rate possible on an X310,
> which is 195.3125 kS/s, will require that the sending end has more than
> 6.25 Mb/s of continuously available uplink. That is actually not that
> little, so unprocessed samples are seldom what you'd want to send over the
> internet!
>
> Best regards,
> Marcus
>
> On 27 May 2018 16:45:22 GMT+02:00, "shachar J. brown via USRP-users" <
> usrp-users@lists.ettus.com> wrote:
>>
>> Hi all,
>>
>> Disclaimer: I have never used zmq before.
>>
>> My goal is to control a X310 from a remote PC, and receive data.
>> using ZMQ.
>>
>> I downloaded the simple example zmq_stream.grc:
>> https://github.com/gnuradio/gnuradio/blob/master/gr-zeromq/e
>> xamples/zmq_stream.grc
>>
>> I ran the flow-graph on two different pc's, both connected to the
>> web. The first pc had the PUB/PUSH/REP blocks, while the second had the
>> SUB/PULL/REQ blocks. Quite frankly, the signal hasn't reached the second 
>> pc.
>>
>> How do I ensure both pc's are subscribed one to another?
>> Anything else I got wrong?
>>
>> TIA,
>> Steve
>>
>
> --
> 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.
>


 ___
 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] Using X310 without RFNoC

[Derek Kozel via USRP-users]

Hello Koen,

To extend Marcus' answer, here is a link to the example with three areas of
particular interest highlighted.

https://github.com/EttusResearch/uhd/blob/rfnoc-devel/host/examples/rfnoc_rx_to_file.cpp#L292
https://github.com/EttusResearch/uhd/blob/rfnoc-devel/host/examples/rfnoc_rx_to_file.cpp#L370
https://github.com/EttusResearch/uhd/blob/rfnoc-devel/host/examples/rfnoc_rx_to_file.cpp#L393

Regards,
Derek

On Wed, May 23, 2018 at 8:24 PM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 05/23/2018 04:55 AM, TIMMEN Koen via USRP-users wrote:
>
>
> All online help I could find explains me how to create custom IP and use
> this in combination with the target images provided, which then require me
> to use gnuradio again. If someone could verify or correct my current
> understanding of the project or perhaps point me to resources I overlooked,
> it would be greatly appreciated.
>
>
>
> Kind regards,
>
>
>
> Koen
>
> There is no requirement to use Gnu Radio to manage RFNoC signal flows.
>
> There are examples in UHD, like:
>
> rfnoc_rx_to_file
>
> And there are probably others on this list who have done RFNoC work
> without Gnu Radio at all who might be able to share example code.
>
>
>
>
>
>
> ___
> 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]

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

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] 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] 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 InterpolationFactor=512
>- Tx 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] 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

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] Can not disable log info in usrp B210

[Derek Kozel via USRP-users]

Hello,

Can you please share the complete output of running cmake on the laptop
with -DUHD_LOG_CONSOLE_DISABLE=TRUE included? Also how are you calling
set_logger_level? I think you may want to call set_console_level instead
with severity_level off.

Regards,
Derek

On Mon, May 21, 2018 at 10:15 AM, Paula Taboada Troitiño <
ptabo...@gradiant.org> wrote:

> Hi,
> I have the same version in both computers; it is the UHD_3.11.0.0-release.
> I was searching if I have multiple copies and I found the same library in
> different places, but I deleted the incorrect and I had the same error
> too...
> Thank you
>
> 2018-05-21 11:09 GMT+02:00 Derek Kozel :
>
>> Hello Paula,
>>
>> Can please let us know the version of UHD on your PC and also on your
>> laptop? Is it possible that you have an older version on the laptop, or
>> multiple copies? Setting the log level to off or using the compile time
>> disable should both work.
>>
>> Regards,
>> Derek
>>
>> On Mon, May 21, 2018 at 9:46 AM, Paula Taboada Troitiño via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi,
>>>
>>> I am trying to disable the log info in my usrp B210, because I want not
>>> to see this:
>>>
>>> [INFO] [CORES] Performing timer loopback test...
>>> [INFO] [CORES] Timer loopback test passed
>>> [INFO] [CORES] Performing timer loopback test...
>>> [INFO] [CORES] Timer loopback test passed
>>> [INFO] [B200] Asking for clock rate 52.00 MHz...
>>> [INFO] [B200] Actually got clock rate 52.00 MHz.
>>> [INFO] [CORES] Performing timer loopback test...
>>> .
>>> .
>>> .
>>>
>>> I used the set_logger_level function and It works fien in my PC, but
>>> when I try to compile in my laptop (with the same g++ version), I have the
>>> next error:
>>>
>>> (.text+0xcd8):  `uhd::log::set_logger_level(std::__cxx11::basic_string>> std::char_traits, std::allocator > const&,
>>> uhd::log::severity_level)' not referenced
>>>
>>> Other option I try was to include the flag -DUHD_LOG_CONSOLE_DISABLE at
>>> my makfile but it does not works.
>>>
>>> Could you help me to sisable the logging?
>>> Thank you
>>>
>>> [image: logo_170x100px.png] 
>>>
>>>
>>>
>>> Paula Taboada Troitiño
>>> Investigadora - Desarrolladora | Área de Comunicaciones Avanzadas
>>> Researcher - Developer | Advanced Communications Department
>>>
>>>
>>>
>>> Ph. (+34) 986 120 430  Ext. 3016
>>>
>>> ptabo...@gradiant.org | www.gradiant.org
>>>
>>> [image: Iconos Redes Sociales GRD Firma email-01]
>>>   [image: Iconos Redes Sociales
>>> GRD Firma email-02]   [image: Iconos
>>> Redes Sociales GRD Firma email-03]
>>>   [image: Iconos Redes
>>> Sociales GRD Firma email-04]
>>> 
>>> Take care of the environment. Try not to print this email.
>>> The information contained in this email message may be confidential
>>> information, and may also be the subject of legal professional privilege.
>>> If you are not the intended recipient, any use, interference with,
>>> disclosure or copying of this material is unauthorized and prohibited.
>>> Please inform us immediately and destroy the email. Thank you for your
>>> cooperation.
>>>
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
>
> --
>
> [image: logo_170x100px.png] 
>
>
>
> Paula Taboada Troitiño
> Investigadora - Desarrolladora | Área de Comunicaciones Avanzadas
> Researcher - Developer | Advanced Communications Department
>
>
>
> Ph. (+34) 986 120 430  Ext. 3016
>
> ptabo...@gradiant.org | www.gradiant.org
>
> [image: Iconos Redes Sociales GRD Firma email-01]
>   [image: Iconos Redes Sociales
> GRD Firma email-02]   [image: Iconos Redes
> Sociales GRD Firma email-03]
>   [image: Iconos Redes
> Sociales GRD Firma email-04]
> 
> Take care of the environment. Try not to print this email.
> The information contained in this email message may be confidential
> information, and may also be the subject of legal professional privilege.
> If you are not the intended recipient, any use, interference with,
> disclosure or copying of this material is unauthorized and prohibited.
> Please inform us immediately and destroy the email. Thank you for your
> cooperation.
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] [Discuss-gnuradio] USRP DDC and GNURadio Bandwidth Problem

[Derek Kozel via USRP-users]

Hello Ali,

The bandwidth parameter will select the Analog RF filters where possible.
For the X310 the daughterboards do not have configurable filters so you
will have to add a lowpass filter to your flowgraph.

Regards,
Derek

On Thu, May 17, 2018 at 2:10 PM, Ali via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I don't want my sampling rate to be 25 kHz. My sampling rate is already
> 195312 Hz which is I think the minimum sampling rate for X310.
>
> What I want is to filter out the frequencies which are at least 25 kHz
> away from my center frequency. For example I don't want to see a
> transmission which is 50 kHz away from my center frequency. Is it possible?
> How does the "bandwidth" parameter in UHD Source Block in GNURadio affect
> the captured IQ data?
>
> Regards,
> Ali
>
> 2018-05-14 12:19 GMT+03:00 Derek Kozel :
>
>> Hello Ali,
>>
>> To extend what Marcus has said, here is a link to the UHD manual page
>> about sample rates.
>> http://files.ettus.com/manual/page_general.html#general_sampleratenotes
>>
>> Regards,
>> Derek
>>
>> On Mon, May 14, 2018 at 8:54 AM, Müller, Marcus (CEL) 
>> wrote:
>>
>>> Hi Ali,
>>>
>>> just like the console will tell you, 25 kS/s is simply impossible with
>>> an X310; instead, the minimum possible rate was used.
>>>
>>> You should probably just configure your X310 to get you e.g. 500 kS/s,
>>> and then resample in digital domain. If you're hesitant to design your
>>> own decimating filter, use the "rational resampler" block and configure
>>> it to decimate by (500/25)=20.
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On Mon, 2018-05-14 at 10:18 +0300, Ali wrote:
>>> > Hi to all,
>>> >
>>> > I am using GNURadio to control an X310. I want to get IQ samples for
>>> only 25 kHz bandwidth.
>>> >
>>> > When I wrote 25 kHz to the bandwidth line in UHD-Source block in
>>> GNURadio, I still see the signals at 50 kHz or 75 kHz away from the center.
>>> My sampling rate is 195312 Hz. When checked in MATLAB, the signals are
>>> there. It looks like I cannot control the bandwidth with GNURadio.
>>> >
>>> > I suspected that there is not any DDC filter for this bandwidth. If it
>>> is so, what is the minimum bandwidth for USRPs? Are the bandwidths that I
>>> can use discrete? I am confused.
>>> >
>>> > Thanks in advance,
>>> > Ali
>>> >
>>> > ___
>>> > Discuss-gnuradio mailing list
>>> > discuss-gnura...@gnu.org
>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> ___
>>> Discuss-gnuradio mailing list
>>> discuss-gnura...@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>
> ___
> 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] Request information for UHD on WINDOWS 10

[Derek Kozel via USRP-users]

Hello Daniele,

Yes, UHD installs and runs correctly on Windows 10. The installer is the
same for all versions of Windows which are supported.

Here is the build guide for Windows.
https://kb.ettus.com/Building_and_Installing_the_USRP_Open_Source_Toolchain_(UHD_and_GNU_Radio)_on_Windows

Regards,
Derek

On Wed, May 16, 2018 at 3:36 PM, Disco Daniele via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi!
>
> I would like to know if it is possible to install UHD on Windows 10.
>
> Looking here https://files.ettus.com/manual/page_install.html , following
> the link: http://files.ettus.com/binaries/uhd/latest_release you can find
> UHD for WINDOWS 7 32/64 bits.
>
>
>
> I was also thinking to MSYS2 that build a sort of unix environment under
> Windows (also 10).
>
>
>
> Probably the problems is install the dependences (libboost, cmake, etc.)
> because it is necessary to start from sources.
>
> Thank You
>
> _
>
> [image: logo1]
>
> Direzione e Coordinamento Vivendi SA
>
>
> *Daniele Disco*
> *T.I.MF.WSA* Wireless Innovation
>
>
> Via Reiss Romoli, 274 – 10148 Torino
> tel . +39 011 228 7271
> cell. +39 331 600 1113
>
> Fax. +39 06 4186 5196
> Tim Official: *Facebook*  -
> *Twitter* 
> *www.tim.it* 
>
>
>
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
>
> * This e-mail and any attachments is confidential and may contain
> privileged information intended for the addressee(s) only. Dissemination,
> copying, printing or use by anybody else is unauthorised. If you are not
> the intended recipient, please delete this message and any attachments and
> advise the sender by return e-mail, Thanks. *
>
> *Rispetta l'ambiente. Non stampare questa mail se non è necessario.*
>
> ___
> 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] [Discuss-gnuradio] USRP DDC and GNURadio Bandwidth Problem

[Derek Kozel via USRP-users]

Hello Ali,

To extend what Marcus has said, here is a link to the UHD manual page about
sample rates.
http://files.ettus.com/manual/page_general.html#general_sampleratenotes

Regards,
Derek

On Mon, May 14, 2018 at 8:54 AM, Müller, Marcus (CEL) 
wrote:

> Hi Ali,
>
> just like the console will tell you, 25 kS/s is simply impossible with
> an X310; instead, the minimum possible rate was used.
>
> You should probably just configure your X310 to get you e.g. 500 kS/s,
> and then resample in digital domain. If you're hesitant to design your
> own decimating filter, use the "rational resampler" block and configure
> it to decimate by (500/25)=20.
>
> Best regards,
> Marcus
>
> On Mon, 2018-05-14 at 10:18 +0300, Ali wrote:
> > Hi to all,
> >
> > I am using GNURadio to control an X310. I want to get IQ samples for
> only 25 kHz bandwidth.
> >
> > When I wrote 25 kHz to the bandwidth line in UHD-Source block in
> GNURadio, I still see the signals at 50 kHz or 75 kHz away from the center.
> My sampling rate is 195312 Hz. When checked in MATLAB, the signals are
> there. It looks like I cannot control the bandwidth with GNURadio.
> >
> > I suspected that there is not any DDC filter for this bandwidth. If it
> is so, what is the minimum bandwidth for USRPs? Are the bandwidths that I
> can use discrete? I am confused.
> >
> > Thanks in advance,
> > Ali
> >
> > ___
> > Discuss-gnuradio mailing list
> > discuss-gnura...@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> ___
> Discuss-gnuradio mailing list
> discuss-gnura...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310: Flashing failed with different UHD versions because of a runtime error

[Derek Kozel via USRP-users]

Hello Andreas,

Is there a switch or router connected between the USRP and the computer
running uhd_image_loader? If so, can you try rerunning the steps with a
direct ethernet connection? The uhd_image_loader and usrp_burn_mb_eeprom
utilities can be used to restore to the factory settings, but they rely on
the use of the JTAG interface to restore a working image if needed.

Regards,
Derek

On Thu, May 3, 2018 at 10:56 AM, Andreas Bauer via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I have the problem that I am unable to write a new FGPA-image to the
> usrp's flash. I have a X310 with a TwinRX daughterbard, I use a Ubuntu
> 16.04 LTS distribution and my default UHD version is 3.11.0 but I am also
> able to use the UHD 4.0.0.
>
> Because of an incorrect loaded FPGA image (a wrongly flashed XG version
> instead of the correct HG version - the flash process itself was not
> interrupted) I am unable to communicate with the USRP.
>
> I followed the X310 Device Recovery (which is decribed here:
> https://kb.ettus.com/X300/X310_Device_Recovery) and I was successful
> until I reached the step where the new image should be loaded into the
> flash via the *uhd_image_loader* tool. At this point I get a unspecific
> runtime error:
> > [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.11.0.0-release
> > Unit: USRP X310 (3140F8E, 10.13.17.23)
> > FPGA Image: /home/bauer/sandbox/uhd-maint_2018-04-27_install_01/share/
> uhd/images/usrp_x310_fpga_HG.bit
> > failed.
> > Error: RuntimeError: Device reported an error during initialization.
>
> I tried to flash the USRP with UHD-3.11.00 and with UHD-4.0.0 but the
> behavior and error keeps the same. I am still able to load FPGA images
> temporarily via Vivado over the JTAG interface but these images will
> logically be forgotten after a power reset of the USRP.
>
> Has anybody experiences with this topic and know how this can be fixed?
>
> Is it possible to get a "true" factory reset of the USRP?
>
>
> Best regards
>
> Andreas
>
> ___
> 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] (no subject)

[Derek Kozel via USRP-users]

Hello Kazem,

Did you get my previous message?
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056283.html

You are correct that you need to upgrade the USRP's FPGA image.

Please run:

 "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
 "/usr/local/bin/uhd_image_loader" \
--args="type=usrp2,addr=192.168.10.3"

Here is the manual page.
http://files.ettus.com/manual/page_usrp2.html#usrp2_loadflash

Regards,
Derek


On Sat, Apr 28, 2018 at 7:14 AM, kazem chm via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Good day dear Sir,
> I am a new user of Ubuntu and USRP. I'm trying to connect my PC to USRP
> N200, but I have encountered the error below. I have installed  and
> uninstalled my GNU radio and UHD several times, but what I get is still the
> latest version in which is not compatible with my FPGA. I guess I need to
> upgrade my FPGA on USRP but I have no idea how to do that. Please give me a
> step by step guide to solve this problem.
>
> warm regards,
> Kazem
>
> The error:
> RuntimeError:
> Please update the firmware and FPGA images for your device.
> See the application notes for USRP2/N-Series for instructions.
> Expected FPGA compatibility number 11, but got 10:
> The FPGA build is not compatible with the host code build.
> Please run:
>
>  "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
>  "/usr/local/bin/uhd_image_loader" \
> --args="type=usrp2,addr=192.168.10.3"
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> ___
> 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 FPGA Code

[Derek Kozel via USRP-users]

Hello Yeo Jin Kuang Alvin,

I am not Ettus' expert in the B210 FPGA, but it would be highly unusual if
there were arbitrary bit width changes. I believe that the GPIF bus is 16
bits of I and Q in parallel. The FX3 GPIF bus definition is included in the
source and you can use Cypress's tools to look at the configuration of the
bus in addition to the FPGA source code. There is considerable DSP
implemented in the FPGA, including the decimation, interpolation, and
frequency shifting operations. At minimum you would have to make changes to
the UHD driver to remove support for those features if you bypass them.

My apologies if I've missed this in another email, but what is your goal
with these changes?

Regards,
Derek

On Thu, Apr 26, 2018 at 10:18 AM, Yeo Jin Kuang Alvin (IA) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone!
>
>
>
> For the FPGA source code written for b210, I noticed that the input to the
> *GPIF_D* that is *32 bits*, and then in went through some FIFOs up
> converting to *64 bits* and then down to *12 bits* output (*tx_codec_d*).
>
>
>
> May I know what is the purpose of up converting and then down convert
> again?
>
>
>
> Will it affect anything if I remove all these and just connect *GPIF_D *(*32
> bits*) input and take *12 bits MSB *(truncation) and connect directly to 
> *tx_codec_d
> *(*12 bits*) ?
>
>
>
> Thanks in advance!
>
> ___
> 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] RuntimeError: Firmware and FPGA image update

[Derek Kozel via USRP-users]

Hello Kazem,

Have you run the step by step commands which are printed in the error? If
they did not work, can you please share the errors from running them?

Also, though those are the correct commands, here is the manual page for
reference.
http://files.ettus.com/manual/page_usrp2.html#usrp2_loadflash

Regards,
Derek

On Thu, Apr 19, 2018 at 2:25 AM, kazem chm via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Good day dear Sir,
> I am a new user of Ubuntu and USRP. I'm trying to connect my PC to USRP
> N200, but I have encountered the error below. I have installed  and
> uninstalled my GNU radio and UHD several times, but what I get is still the
> latest version in which is not compatible with my FPGA. I guess I need to
> upgrade my FPGA on USRP but I have no idea how to do that. Please give me a
> step by step guide to solve this problem.
>
> warm regards,
> Kazem
>
> The error:
> RuntimeError:
> Please update the firmware and FPGA images for your device.
> See the application notes for USRP2/N-Series for instructions.
> Expected FPGA compatibility number 11, but got 10:
> The FPGA build is not compatible with the host code build.
> Please run:
>
>  "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
>  "/usr/local/bin/uhd_image_loader" \
> --args="type=usrp2,addr=192.168.10.3"
>
>
> ___
> 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] How can I upgrade a standard Octoclock CDA-2990 to a Octoclock-G CDA-2990?

[Derek Kozel via USRP-users]

Hello Martin,

Yes, you can just install the GPSDO in and have the full functionality. The
switch is used to tell the onboard software which reference source is
*preferred*. Switching to internal when there is no internal source will
fail (there is active detection of the reference signal) and the octoclock
will default back to external. Once you have a GPSDO plugged into the
internal socket you will be able to switch to internal.

Regards,
Derek

On Tue, Apr 17, 2018 at 9:39 AM, Martin via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> How can I upgrade a standard Octoclock CDA-2990 to a Octoclock-G CDA-2990?
> Can I just put in the GPSDO. Or do I need to do more?
>
> I already have a Board Mounted 783173-01 GPSDO (OCXO) (LC_XO with OCXO)
>
> The documentation says:
>
> http://files.ettus.com/manual/page_octoclock.html
>
>> Both OctoClock models can input a 10 MHz reference and a 1 PPS signal via
>> the SMA connectors EXT 10 MHZ INPUT and EXT PPS INPUT, respectively,
>> located on the front of the device. Additionally, the OctoClock-G contains
>> an internal GPSDO which provides its own internal references to the device.
>>
>> There is a switch on the front panel of the device with two positions
>> INTERNAL and EXTERNAL that specifies which reference will be used, when
>> applicable. For the OctoClock, there is no internal timing or clocking
>> source, so the OctoClock will always use external 10 MHz and 1 PPS sources,
>>
>
> Is the switch not connected on the Octoclock?
> Or is it a software/firmware/EEPROM setting?
>
>
> Thanks in advance?
>
> Martin
>
> ___
> 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 support for maint branch

[Derek Kozel via USRP-users]

Hello Leo,

You are correct, use of custom RFNoC blocks is only supported on the
rfnoc-devel branch at this time. The full RFNoC support will be exposed on
the main branches in the future, the UHF 4.0.0.0 release is the currently
planned time for doing that.

Regards,
Derek

On Wed, Apr 11, 2018 at 6:39 PM, Leandro Echevarría via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey everybody,
>
> I was able to make an example block by installing uhd+gr-ettus with
> PyBombs rfnoc-devel recipes, then using rfnocmodtool, generating .xml and
> .v files, and then "compiling and installing" the block from the
> previously generated makefiles.
> I also included the block in the FPGA code, and uhd_usrp_probe finds it
> without an issue.
>
> The thing is this works only inside a sandboxed version of UHD (from
> branch rfnoc-devel). If I run uhd_usrp_probe from my system version
> (compiled from the last release of maint branch), the new block appears
> only as Block_0.
>
> Is there any way for UHD v3.1.0.1 to recognize my block properly (beyond
> its name, I'm of course intersted in it recognizing all its ports and
> registers). I tried copying the .xml declaration file to
> /usr/local/share/uhd/rfnoc/blocks/, but that doesn't seem to be enough.
> Should I recompile some library? Or is there no other way than using
> rfnoc-devel?
>
> Thank you again,
>
> Leo
>
> ___
> 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] Remote access to the X310

[Derek Kozel via USRP-users]

Hello Ishai,

Eino is correct. The UHD API requires a host computer to be connected to
the USRP to control the X310. Many users take this API and use it to write
applications exposing the processed data to remote clients. GNU Radio
provides some foundations such as ControlPort and ZMQ to support
applications like that.

Regards,
Derek

On Tue, Mar 27, 2018 at 4:09 PM, Eino Virtanen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> The common approach would probably be to connect the X310 to a PC.
> Said PC can then be accessed via internet.
>
> You can pipe data through that PC to wherever, but be sure to consider
> your latency and bandwidth requirements and your systems'
> capabilities.
>
> On 27 March 2018 at 09:45, Allouche Ishai via USRP-users
>  wrote:
> > Hi all,
> >
> >
> >
> > I’m quite new to USRP world.
> >
> > I would like to know if it is possible to remotely connect to the X310.
> >
> > In other words, can I connect the X310 to the internet, and control it \
> > receive data remotely via the web?
> >
> >
> >
> > Thanks for your time,
> >
> > Ishai
> >
> >
> > The information in this e-mail transmission contains proprietary and
> > business
> > sensitive information.  Unauthorized interception of this e-mail may
> > constitute
> > a violation of law. If you are not the intended recipient, you are hereby
> > notified that any review, dissemination, distribution or duplication of
> this
> > communication is strictly prohibited. You are also asked to contact the
> > sender
> > by reply email and immediately destroy all copies of the original
> message.
> >
> > ___
> > 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] X300 new user

[Derek Kozel via USRP-users]

This function in UHD will first look for the environmental variable and
then use the UHD installation path to look for the xml files.
https://github.com/EttusResearch/uhd/blob/8bb15ee133ea98d6755d392b8493966c785291dd/host/lib/rfnoc/blockdef_xml_impl.cpp#L155

which calls
https://github.com/EttusResearch/uhd/blob/13c32cefcd6ea45e20e2eca97159ca26603ca533/host/lib/utils/paths.cpp#L176

The UHD_PKG_PATH default is generated by cmake here:
https://github.com/EttusResearch/uhd/blob/a06eaad1f0133524daf0a40100ebeb3e06fd7498/host/lib/utils/CMakeLists.txt#L136

On Fri, Mar 23, 2018 at 7:21 PM, Rob Kossler <rkoss...@nd.edu> wrote:

> Hi Derek,
> Yesterday, I did a "git pull" and "make" of the "maint" HEAD.  This was on
> a computer that had not been used in several months.  The  previous version
> was definitely 3.10, but I don't know how old.  Anyway, following the
> build, I could run the examples without getting any error message.  Today,
> however, when I opened a new command prompt and tried to run the example
> programs, I got the error message.  BTW, my typical process is to "source"
> a "setup_env.sh" file.  After adding  the UHD_RFNOC_LOC export to my file,
> everything worked fine.
>
> What do you mean mean you say the the default path for UHD_RFNOC_DIR is
> configured automatically at build time?
>
> Rob
>
>
> On Fri, Mar 23, 2018 at 3:08 PM, Derek Kozel <derek.ko...@ettus.com>
> wrote:
>
>> Hi Rob,
>>
>> The default path for UHD_RFNOC_DIR is configured automatically at build
>> time.  The requirement has not changed since UHD 3.10. What version of UHD
>> were you building when you encountered the problem. It is not impossible
>> that this is a bug, though I do not believe that there have been any
>> changes to that area of code recently.
>>
>> I agree with Marcus that Matis at least probably had another version of
>> UHD installed using a prebuilt package. By default source builds end up
>> installed to /usr/local, not /usr.
>>
>> Matis, can you check if after running make install there is now a
>> /usr/local/share/uhd/rfnoc/blocks directory? If so, then you have two
>> versions of UHD installed and are likely to encounter errors in the future
>> where software may confuse the two. If one was installed using apt or your
>> package manager then it should be removed the same way.
>>
>> Regards,
>> Derek
>>
>>
>> On Fri, Mar 23, 2018 at 6:23 PM, Rob Kossler <rkoss...@nd.edu> wrote:
>>
>>> This necessity for setting UHD_RFNOC_DIR should probably be added to the
>>> UHD manual.
>>>
>>> On Fri, Mar 23, 2018 at 2:15 PM, Derek Kozel via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>>> Hello Matis,
>>>>
>>>> UHD uses RFNoC internally at all times since the 3.10.0.0 release. The
>>>> XML files are needed for standard operation. It does not expose the full
>>>> API or set of features unless the rfnoc-devel branch is used.
>>>>
>>>> Regards,
>>>> Derek
>>>>
>>>> On Fri, Mar 23, 2018 at 6:05 PM, Matis Alun via USRP-users <
>>>> usrp-users@lists.ettus.com> wrote:
>>>>
>>>>> yes, I missed the make install because I thought that it was
>>>>> optionnal.
>>>>>
>>>>> Tell me if I wrong: RFnoc is not used since we use multi_usrp wright ?
>>>>> in this case, xml files are also needed ?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> matis
>>>>>
>>>>> Le 23/03/2018 à 17:35, Marcus D. Leech via USRP-users a écrit :
>>>>>
>>>>> On 03/23/2018 12:30 PM, Matis Alun via USRP-users wrote:
>>>>>
>>>>> yes of course:
>>>>>
>>>>> total 76
>>>>> -rw-r--r--. 1 root root 1433  2 nov.   2016 addsub.xml
>>>>> -rw-r--r--. 1 root root  363  2 nov.   2016 block.xml
>>>>> -rw-r--r--. 1 root root 2944  2 nov.   2016 ddc_single.xml
>>>>> -rw-r--r--. 1 root root 3875  2 nov.   2016 ddc.xml
>>>>> -rw-r--r--. 1 root root 1677  2 nov.   2016 dma_fifo.xml
>>>>> -rw-r--r--. 1 root root 2393  2 nov.   2016 duc.xml
>>>>> -rw-r--r--. 1 root root 3845  2 nov.   2016 fft.xml
>>>>> -rw-r--r--. 1 root root  899  2 nov.   2016 fifo.xml
>>>>> -rw-r--r--. 1 root root  365  2 nov.   2016 fir.xml
>>>>> -rw-r--r--. 1 root root 4500  2 nov.   2016 fosphor.xml
>>>>> -rw-r--r--. 1 roo

Re: [USRP-users] X300 new user

[Derek Kozel via USRP-users]

Hi Rob,

The default path for UHD_RFNOC_DIR is configured automatically at build
time.  The requirement has not changed since UHD 3.10. What version of UHD
were you building when you encountered the problem. It is not impossible
that this is a bug, though I do not believe that there have been any
changes to that area of code recently.

I agree with Marcus that Matis at least probably had another version of UHD
installed using a prebuilt package. By default source builds end up
installed to /usr/local, not /usr.

Matis, can you check if after running make install there is now a
/usr/local/share/uhd/rfnoc/blocks directory? If so, then you have two
versions of UHD installed and are likely to encounter errors in the future
where software may confuse the two. If one was installed using apt or your
package manager then it should be removed the same way.

Regards,
Derek


On Fri, Mar 23, 2018 at 6:23 PM, Rob Kossler <rkoss...@nd.edu> wrote:

> This necessity for setting UHD_RFNOC_DIR should probably be added to the
> UHD manual.
>
> On Fri, Mar 23, 2018 at 2:15 PM, Derek Kozel via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello Matis,
>>
>> UHD uses RFNoC internally at all times since the 3.10.0.0 release. The
>> XML files are needed for standard operation. It does not expose the full
>> API or set of features unless the rfnoc-devel branch is used.
>>
>> Regards,
>> Derek
>>
>> On Fri, Mar 23, 2018 at 6:05 PM, Matis Alun via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> yes, I missed the make install because I thought that it was optionnal.
>>>
>>> Tell me if I wrong: RFnoc is not used since we use multi_usrp wright ?
>>> in this case, xml files are also needed ?
>>>
>>> Thanks.
>>>
>>> matis
>>>
>>> Le 23/03/2018 à 17:35, Marcus D. Leech via USRP-users a écrit :
>>>
>>> On 03/23/2018 12:30 PM, Matis Alun via USRP-users wrote:
>>>
>>> yes of course:
>>>
>>> total 76
>>> -rw-r--r--. 1 root root 1433  2 nov.   2016 addsub.xml
>>> -rw-r--r--. 1 root root  363  2 nov.   2016 block.xml
>>> -rw-r--r--. 1 root root 2944  2 nov.   2016 ddc_single.xml
>>> -rw-r--r--. 1 root root 3875  2 nov.   2016 ddc.xml
>>> -rw-r--r--. 1 root root 1677  2 nov.   2016 dma_fifo.xml
>>> -rw-r--r--. 1 root root 2393  2 nov.   2016 duc.xml
>>> -rw-r--r--. 1 root root 3845  2 nov.   2016 fft.xml
>>> -rw-r--r--. 1 root root  899  2 nov.   2016 fifo.xml
>>> -rw-r--r--. 1 root root  365  2 nov.   2016 fir.xml
>>> -rw-r--r--. 1 root root 4500  2 nov.   2016 fosphor.xml
>>> -rw-r--r--. 1 root root 1374  2 nov.   2016 keep_one_in_n.xml
>>> -rw-r--r--. 1 root root 1262  2 nov.   2016 logpwr.xml
>>> -rw-r--r--. 1 root root  554  2 nov.   2016 nullblock.xml
>>> -rw-r--r--. 1 root root  624  2 nov.   2016 ofdmeq.xml
>>> -rw-r--r--. 1 root root 1531  2 nov.   2016 packetresizer.xml
>>> -rw-r--r--. 1 root root 1582  2 nov.   2016 radio_x300.xml
>>> -rw-r--r--. 1 root root 3432  2 nov.   2016 siggen.xml
>>> -rw-r--r--. 1 root root 1170  2 nov.   2016 window.xml
>>>
>>> I think what you did was you *built* the new version of UHD, but never
>>> actually installed it, via sudo make install, so when you are executing
>>> bits and
>>>pieces from the built-but-not-yet-installed files, they're naturally
>>> expecting to find config files, and xml files, etc, in their "natural"
>>> places.
>>>
>>> You'll have to uninstall the UHD you already have, which was likely
>>> installed from a  pre-packaged release (via a PPA?), and then run the
>>>   sudo make install in the source tree.
>>>
>>>
>>>
>>> Le 23/03/2018 à 17:18, Marcus D. Leech via USRP-users a écrit :
>>>
>>> On 03/23/2018 11:30 AM, Matis Alun via USRP-users wrote:
>>>
>>> yes, I have  a /usr/share/uhd/rfnoc/blocks directory with several xml
>>> files.
>>>
>>> matis
>>>
>>> Could you do an ls -l   on that directory and share it with us?
>>>
>>>
>>> Le 23/03/2018 à 16:20, Marcus D. Leech via USRP-users a écrit :
>>>
>>> On 03/23/2018 10:32 AM, Matis Alun via USRP-users wrote:
>>>
>>> Hi,
>>>
>>> I've been working with N210 for a long time now with very successful
>>> story.
>>>
>>> I recently buy an x300 with TwinRX and I try do run the demo examples
>>> (so I am in the very first stage of testing).
>>> I compiled the uhd 3.0

Re: [USRP-users] X300 new user

[Derek Kozel via USRP-users]

Hello Matis,

UHD uses RFNoC internally at all times since the 3.10.0.0 release. The XML
files are needed for standard operation. It does not expose the full API or
set of features unless the rfnoc-devel branch is used.

Regards,
Derek

On Fri, Mar 23, 2018 at 6:05 PM, Matis Alun via USRP-users <
usrp-users@lists.ettus.com> wrote:

> yes, I missed the make install because I thought that it was optionnal.
>
> Tell me if I wrong: RFnoc is not used since we use multi_usrp wright ?
> in this case, xml files are also needed ?
>
> Thanks.
>
> matis
>
> Le 23/03/2018 à 17:35, Marcus D. Leech via USRP-users a écrit :
>
> On 03/23/2018 12:30 PM, Matis Alun via USRP-users wrote:
>
> yes of course:
>
> total 76
> -rw-r--r--. 1 root root 1433  2 nov.   2016 addsub.xml
> -rw-r--r--. 1 root root  363  2 nov.   2016 block.xml
> -rw-r--r--. 1 root root 2944  2 nov.   2016 ddc_single.xml
> -rw-r--r--. 1 root root 3875  2 nov.   2016 ddc.xml
> -rw-r--r--. 1 root root 1677  2 nov.   2016 dma_fifo.xml
> -rw-r--r--. 1 root root 2393  2 nov.   2016 duc.xml
> -rw-r--r--. 1 root root 3845  2 nov.   2016 fft.xml
> -rw-r--r--. 1 root root  899  2 nov.   2016 fifo.xml
> -rw-r--r--. 1 root root  365  2 nov.   2016 fir.xml
> -rw-r--r--. 1 root root 4500  2 nov.   2016 fosphor.xml
> -rw-r--r--. 1 root root 1374  2 nov.   2016 keep_one_in_n.xml
> -rw-r--r--. 1 root root 1262  2 nov.   2016 logpwr.xml
> -rw-r--r--. 1 root root  554  2 nov.   2016 nullblock.xml
> -rw-r--r--. 1 root root  624  2 nov.   2016 ofdmeq.xml
> -rw-r--r--. 1 root root 1531  2 nov.   2016 packetresizer.xml
> -rw-r--r--. 1 root root 1582  2 nov.   2016 radio_x300.xml
> -rw-r--r--. 1 root root 3432  2 nov.   2016 siggen.xml
> -rw-r--r--. 1 root root 1170  2 nov.   2016 window.xml
>
> I think what you did was you *built* the new version of UHD, but never
> actually installed it, via sudo make install, so when you are executing
> bits and
>pieces from the built-but-not-yet-installed files, they're naturally
> expecting to find config files, and xml files, etc, in their "natural"
> places.
>
> You'll have to uninstall the UHD you already have, which was likely
> installed from a  pre-packaged release (via a PPA?), and then run the
>   sudo make install in the source tree.
>
>
>
> Le 23/03/2018 à 17:18, Marcus D. Leech via USRP-users a écrit :
>
> On 03/23/2018 11:30 AM, Matis Alun via USRP-users wrote:
>
> yes, I have  a /usr/share/uhd/rfnoc/blocks directory with several xml
> files.
>
> matis
>
> Could you do an ls -l   on that directory and share it with us?
>
>
> Le 23/03/2018 à 16:20, Marcus D. Leech via USRP-users a écrit :
>
> On 03/23/2018 10:32 AM, Matis Alun via USRP-users wrote:
>
> Hi,
>
> I've been working with N210 for a long time now with very successful story.
>
> I recently buy an x300 with TwinRX and I try do run the demo examples (so
> I am in the very first stage of testing).
> I compiled the uhd 3.010.003 with succes and I can pinf the X300 at ip
> 192.168.10.2.
> I upload the fpga image usrp_x300_fpga_HG.bit on the board.
>
> Runing uhd_find_device gives:
>
> --
> -- UHD Device 0
> --
> Device Address:
> type: x300
> addr: 192.168.10.2
> fpga: HG
> name:
> serial: 31402AC
> product: X300
>
> But runing uhd_usrp_probe gives:
>
> linux; GNU C++ version 7.3.1 20180303 (Red Hat 7.3.1-5); Boost_106400; 
> UHD_003.010.003.000-0-unknown
>
> -- X300 initialization sequence...
> -- Determining maximum frame size... 1472 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> Error: AssertionError: Failed to find a valid XML path for RFNoC blocks.
> Try setting the enviroment variable UHD_RFNOC_DIR to the correct location
> [ravard@starduck utils]$ ./uhd_usrp_probe --args "type=x300,addr=192.168.10.2"
> linux; GNU C++ version 7.3.1 20180303 (Red Hat 7.3.1-5); Boost_106400; 
> UHD_003.010.003.000-0-unknown
>
> -- X300 initialization sequence...
> -- Determining maximum frame size... 1472 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> Error: AssertionError: Failed to find a valid XML path for RFNoC blocks.
> Try setting the enviroment variable UHD_RFNOC_DIR to the correct location
>
> Can someone tell me what is the problem ?
>
> Thanks
>
> Matis
>
> Do you have a /usr/local/share/uhd/rfnoc/blocks directory?   Or a
> /usr/share/uhd/rfnoc/blocks  directory?
>
>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://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
>
>
>
>
> ___
> 

Re: [USRP-users] USRP b210 time tagging

[Derek Kozel via USRP-users]

Yes, the data is timestamped. By default it will be times relative to when
the USRP was first turned on, but the set_time_next_pps function can be
used to align the internal time with an external or GPSDO based reference.

http://files.ettus.com/manual/page_sync.html#sync_time

There are examples for transmitting and receiving at set times included
with UHD.
https://github.com/EttusResearch/uhd/blob/8bb15ee133ea98d6755d392b8493966c785291dd/host/examples/rx_timed_samples.cpp#L93
https://github.com/EttusResearch/uhd/blob/8bb15ee133ea98d6755d392b8493966c785291dd/host/examples/tx_timed_samples.cpp#L75

Regards,
Derek

On Thu, Mar 22, 2018 at 8:27 PM, Cho, Daniel J (332C) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello –
>
>
>
> I am using the USRP b210 but this questions can be for all USRPs.  Do they
> provide time tagging of the data transmitted and received or is that
> something that I would have to create myself.
>
>
>
> Thanks,
>
> Daniel Cho
>
> ___
> 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 Support for TwinRX

[Derek Kozel via USRP-users]

Hello Adams,

Yes, the TwinRX Rev A and B work with RFNoC, but the rfnoc-devel branch may
currently have some regressions. We are in the process of updating the
rfnoc-devel branch with many changes from the master branch including
support for the TwinRX Rev C. We will be doing regression testing of the
rfnoc-devel branch with all revisions of the TwinRX next week. I do not
know the timeline for pushing the updated rfnoc-devel branch to the public
repository, but I believe that it will be shortly after the testing.

Regards,
Derek

On Thu, Mar 22, 2018 at 5:55 PM, Adams, Andrew L. via USRP-users <
usrp-users@lists.ettus.com> wrote:

> We are currently using a TwinRX daughterboard on a X310 USRP.  We have had
> little success using rfnoc-devel branches of UHD (software and FPGA
> repositories) with the TwinRX card.  Using the latest rfnoc-devel code, the
> TwinRX card only works (i.e., we see our signal coming from the radio)
> about 10-20% of the time.  When it doesn’t work, the flowgraph continues to
> run as if nothing is wrong, but there is no signal present (I/Q samples
> don’t seem valid; they are very close to zero).  This issue can also be
> reproduced with the simplest flowgraph.  This issue led us to believe that
> it is an incompatibility issue between the hardware and the latest
> rfnoc-devel version.  Therefore, we began experimenting with the formal
> release of UHD: 3.10.3.  The daughterboard appears to function correctly
> with the 3.10.3 release.  Is the TwinRX daughterboard supported by RFNOC?
>
>
>
> Andrew Adams
>
>
>
> ___
> 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 B210 issues with sample rate and Tx bandwidth

[Derek Kozel via USRP-users]

Hello Lucas,

I'll address your last question. The limitation is a hardware one as the
FPGA is connected to the AD9361 using the CMOS interface and the bandwidth
is split between the channels. This cannot be changed on the B210.

Regards,
Derek

On Thu, Mar 15, 2018 at 11:57 AM, Lucas Val Terrón via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Over the uhd example tx_waveforms.cpp (without any modificaiton), the
> exact invocation I'm using is the following:
>
> ./tx_waveforms --rate 6144 --bw 5000 --freq 244000 --channels
> "0" --wave-type SINE --wave-freq 10 --gain 60
>
> and its output:
>
> --
> [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.11.0.git-208-g1da86f9c]
> [INFO] [B200] Detected Device: B210
> [INFO] [B200] Operating over USB 3.
> [INFO] [B200] Initialize CODEC control...
> [INFO] [B200] Initialize Radio control...
> [INFO] [B200] Performing register loopback test...
> [INFO] [B200] pass
> [INFO] [B200] Performing register loopback test...
> [INFO] [B200] pass
> [INFO] [AD936X] Performing CODEC loopback test...
> [INFO] [AD936X] CODEC 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] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> Using Device: Single USRP:
>   Device: B-Series Device
>   Mboard 0: B210
>   RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: FE-RX2
>   RX Channel: 1
> RX DSP: 1
> RX Dboard: A
> RX Subdev: FE-RX1
>   TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: FE-TX2
>   TX Channel: 1
> TX DSP: 1
> TX Dboard: A
> TX Subdev: FE-TX1
>
> Setting TX Rate: 61.44 Msps...
> [INFO] [B200] Asking for clock rate 61.44 MHz...
> [INFO] [B200] Actually got clock rate 61.44 MHz.
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> Actual TX Rate: 61.44 Msps...
>
> Setting TX Freq: 2440.00 MHz...
> Actual TX Freq: 2440.00 MHz...
>
> Setting TX Gain: 60.00 dB...
> Actual TX Gain: 60.00 dB...
>
>
> *Setting TX Bandwidth: 5000.00 MHz...Actual TX Bandwidth:
> 4000.00 MHz...*
>
>
> *[WARNING] [AD936X] Selected Tx bandwidth (61.44 MHz) exceedsanalog
> frontend filter bandwidth (56 MHz).*
> Setting device timestamp to 0...
> Checking TX: LO: locked ...
> Press Ctrl + C to stop streaming...
> --
>
> The invocation does not produce any error, but there is a warning that
> makes believe that somewhere inside the code something is trying to set th
> BW to the same value as the sample rate. Furthermore, you can also see that
> although the BW inserted is 50MHz, the value is finally set to 40MHz...
>
>
> If you don't mind, let me take the opportunity to ask you about a doubt
> related to the sample rate and dual channel transmission. Looking in the
> documentation I found here (https://files.ettus.com/manua
> l/page_usrp_b200.html#b200_mcr), that there is a limitation of 30.72 MHz
> in the clock rate for dual-channel mode. What is this limitation related
> to? Host, UHD, FPGA, AD9361 chip? Is there any way to increase this value?
>
> [image: logo_170x100px.png] 
>
>
>
> Lucas Val Terrón
> Investigador - Desarrollador | Área de Comunicaciones Avanzadas
>
> Researcher - Developer | Advanced Communications Department
>
>
>
> Ph. (+34) 986 120 430 <+34%20986%2012%2004%2030>  Ext. 3016
> l...@gradiant.org  |  www.gradiant.org
>
> [image: Iconos Redes Sociales GRD Firma email-01]
>   [image: Iconos Redes Sociales
> GRD Firma email-02]   [image: Iconos Redes
> Sociales GRD Firma email-03]
>   [image: Iconos Redes
> Sociales GRD Firma email-04]
> 
>
> Take care of the environment. Try not to print this email.
> The information contained in this email message may be confidential
> information, and may also be the subject of legal professional privilege.
> If you are not the intended recipient, any use, interference with,
> disclosure or copying of this material is unauthorized and prohibited.
> Please inform us immediately and destroy the email. Thank you for your
> cooperation.
>
> 2018-03-14 10:36 GMT+01:00 Lucas Val Terrón :
>
>> Hi all,
>>
>> Working with the example "tx_waveforms.cpp" provided in the uhd, i found
>> myself with two problems trying to set the sample rate and the tx bandwith
>> of the USRP B210 (UHD_3.11.0).
>>
>> 

Re: [USRP-users] Configurating B210 transmitter into two different central frequencies.

[Derek Kozel via USRP-users]

Hello Jose,

The B210's two channels use a common local oscillator so cannot tune to two
separate analog frequencies.
http://files.ettus.com/manual/page_usrp_b200.html#b200_fe

However if your two center frequencies are relatively close together, such
that the minimum and maximum frequencies of your modulated waveforms are
less than 30.72 MHz apart the FPGA's frequency shifters can be used to
digitally tune each channel's center frequency. The basics of this are
described on this page in the manual. We'd be happy to describe the process
in more detail if it fits your application.
http://files.ettus.com/manual/page_general.html#general_tuning_process

Regards,
Derek


On Thu, Mar 15, 2018 at 1:22 PM, Jose Benito Diéguez Teixeira via
USRP-users  wrote:

> Hello usrp users,
>
> We are using a B210 SDR device for our application. This device has two RF
> frontends, but we are in doubt about their mutual independence. We need to
> transmit two different waveforms, each into its own frequency.
>
> We have tried to create two tx_streamers, but the creation of the second
> one seems to overwrite the first streamer. Is this approach the correct way
> to implement the dual frequency transmittion?
>
> Or more focused on the hardaware, is it possible to set two different
> transmittion frequencies with the B210?
>
> Thanks in advance,
>
>
> --
>
>
> 
>
>
>
> José Benito Diéguez Teixeira
>
> ___
> 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] Align LOs in the front-end for Tx

[Derek Kozel via USRP-users]

Hello,

Yes, the same use of timed commands applies for the transmit side tuning.
Just use set_tx_freq instead of set_rx_freq. The timed command
functionality applies to many features on the X310 such as setting the
gain, selecting antennas, and other commands.

Regards,
Derek

On Thu, Mar 15, 2018 at 10:30 AM, Hojoon Yang via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all.
>
>
>
> Let's say we have one USRP X310 and two UBX-160 daughterboards.
>
>
>
> According to the page_sync manual(i.e. https://files.
> ettus.com/manual/page_sync.html), there is a code snippet for aligning
> LOs.
>
>
> Do I need to execute the same thing for Tx? Because the code only
> describes for Rx case.
>
>
>
> Regards,
>
> ___
> 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] TwinRx Channel Alignment

[Derek Kozel via USRP-users]

Hello,

Yes, that is the purpose of the set_time_next_pps function. When combined
with common 10 MHz and 1 PPS references this allows for stable time
synchronization of 1 sample clock cycle, 5 ns at 200 MS/s. I recommend
reading through the examples which show using all these commands and others
related to streaming multiple channels.
https://github.com/EttusResearch/uhd/tree/maint/host/examples

The manual also covers these topics.
http://files.ettus.com/manual/page_sync.html

Derek

On Thu, Mar 8, 2018 at 11:02 PM, Zhongyuan Zhao <zhz...@cse.unl.edu> wrote:

> Hi Derek,
>
> If USRPs A & B clocked by an Octoclock, are connected to the same host, I
> want calibrate the counter values from USRPs A and B. How can I do it? Is
> this function supported by UHD? If not, could I update the counter values
> in the FPGA Radio blocks? or I can only keep an calibration table of
> counter value offsets on my host?
>
> Thanks!
>
> Zhongyuan Zhao
>
> PhD Candidate,
> Department of Computer Science & Engineering,
> University of Nebraska-Lincoln
> Office Hour: WF 9:30-10:00am, Avery Hall 12,
> Suite 117, Schorr Center,
> Lincoln, Nebraska 68588-0115
>
>
> On Thu, Mar 8, 2018 at 4:42 PM, Derek Kozel <derek.ko...@ettus.com> wrote:
>
>> Hello,
>>
>> The same commands are available in the GNU Radio environment and I
>> believe are exposed in the pre-release Python API branch.
>>
>> The FPGA radio blocks contain a timekeeper which is a counter which
>> increments at the same rate as the master_clock_rate which is the effective
>> ADC/DAC sample rate. This allows for commands to be executed with very fine
>> temporal precision.
>>
>> Regards,
>> Derek
>>
>> On Thu, Mar 8, 2018 at 10:12 PM, Zhongyuan Zhao <zhz...@cse.unl.edu>
>> wrote:
>>
>>> Hi Derek,
>>>
>>> I have two questions about the rx timed samples example,
>>> 1. is there python version for timed command?
>>> 2. Is the time stamp from the clock on USRP or on the host?
>>>
>>> Thanks
>>>
>>> Zhongyuan Zhao
>>>
>>> PhD Candidate,
>>> Department of Computer Science & Engineering,
>>> University of Nebraska-Lincoln
>>> Office Hour: WF 9:30-10:00am, Avery Hall 12,
>>> Suite 117, Schorr Center,
>>> Lincoln, Nebraska 68588-0115
>>>
>>>
>>> On Thu, Mar 8, 2018 at 3:27 PM, Derek Kozel via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>>> The stream command object has a field for a time spec of when to start
>>>> streaming and a boolean flag for whether to make use of that time spec.
>>>> http://files.ettus.com/manual/structuhd_1_1stream__cmd__t.html
>>>>
>>>> Here we can see it used in an rx example.
>>>> https://github.com/EttusResearch/uhd/blob/maint/host/example
>>>> s/rx_timed_samples.cpp#L92-L93
>>>>
>>>> Usually it is most practical to make a call to get_time_now() and then
>>>> add an offset from that time which is returned. The minimum offset would be
>>>> the roundtrip command time, usually a few milliseconds.
>>>>
>>>> Regards,
>>>> Derek
>>>>
>>>> On Thu, Mar 8, 2018 at 9:03 PM, Andrew Thommesen <
>>>> andrewjoh...@outlook.com> wrote:
>>>>
>>>>> No, how do you do that?
>>>>>
>>>>>
>>>>> Sent from Outlook <http://aka.ms/weboutlook>
>>>>> --
>>>>> *From:* Derek Kozel <derek.ko...@ettus.com>
>>>>> *Sent:* 08 March 2018 20:58:38
>>>>> *To:* Andrew Thommesen
>>>>> *Cc:* usrp-users
>>>>> *Subject:* Re: [USRP-users] TwinRx Channel Alignment
>>>>>
>>>>> Hello Andrew,
>>>>>
>>>>> Are you starting the streaming with timed commands?
>>>>>
>>>>> Regards,
>>>>> Derek
>>>>>
>>>>> On Mar 8, 2018 7:32 PM, "Andrew Thommesen via USRP-users" <
>>>>> usrp-users@lists.ettus.com> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>>
>>>>> I have an x310 with a twinRx and would like to process coherent,
>>>>> time aligned data within the FPGA. However, the data is not currently time
>>>>> aligned and there is an offset of ~400 samples between the two channels.
>>>>>
>>>>>
>>>>> The RFNoC radio b

Re: [USRP-users] TwinRx Channel Alignment

[Derek Kozel via USRP-users]

Hello,

The same commands are available in the GNU Radio environment and I believe
are exposed in the pre-release Python API branch.

The FPGA radio blocks contain a timekeeper which is a counter which
increments at the same rate as the master_clock_rate which is the effective
ADC/DAC sample rate. This allows for commands to be executed with very fine
temporal precision.

Regards,
Derek

On Thu, Mar 8, 2018 at 10:12 PM, Zhongyuan Zhao <zhz...@cse.unl.edu> wrote:

> Hi Derek,
>
> I have two questions about the rx timed samples example,
> 1. is there python version for timed command?
> 2. Is the time stamp from the clock on USRP or on the host?
>
> Thanks
>
> Zhongyuan Zhao
>
> PhD Candidate,
> Department of Computer Science & Engineering,
> University of Nebraska-Lincoln
> Office Hour: WF 9:30-10:00am, Avery Hall 12,
> Suite 117, Schorr Center,
> Lincoln, Nebraska 68588-0115
>
>
> On Thu, Mar 8, 2018 at 3:27 PM, Derek Kozel via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> The stream command object has a field for a time spec of when to start
>> streaming and a boolean flag for whether to make use of that time spec.
>> http://files.ettus.com/manual/structuhd_1_1stream__cmd__t.html
>>
>> Here we can see it used in an rx example.
>> https://github.com/EttusResearch/uhd/blob/maint/host/
>> examples/rx_timed_samples.cpp#L92-L93
>>
>> Usually it is most practical to make a call to get_time_now() and then
>> add an offset from that time which is returned. The minimum offset would be
>> the roundtrip command time, usually a few milliseconds.
>>
>> Regards,
>> Derek
>>
>> On Thu, Mar 8, 2018 at 9:03 PM, Andrew Thommesen <
>> andrewjoh...@outlook.com> wrote:
>>
>>> No, how do you do that?
>>>
>>>
>>> Sent from Outlook <http://aka.ms/weboutlook>
>>> --
>>> *From:* Derek Kozel <derek.ko...@ettus.com>
>>> *Sent:* 08 March 2018 20:58:38
>>> *To:* Andrew Thommesen
>>> *Cc:* usrp-users
>>> *Subject:* Re: [USRP-users] TwinRx Channel Alignment
>>>
>>> Hello Andrew,
>>>
>>> Are you starting the streaming with timed commands?
>>>
>>> Regards,
>>> Derek
>>>
>>> On Mar 8, 2018 7:32 PM, "Andrew Thommesen via USRP-users" <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>> Hi all,
>>>
>>>
>>> I have an x310 with a twinRx and would like to process coherent,
>>> time aligned data within the FPGA. However, the data is not currently time
>>> aligned and there is an offset of ~400 samples between the two channels.
>>>
>>>
>>> The RFNoC radio block is configured to receive data on both channels,
>>> with the LO of channel 1 set to companion. The output of the radio block
>>> then passes through the RFNoC DDC block that decimates from 100MSPS to
>>> 50MSPS. The decimated data then passes to a custom RFNoC block that strips
>>> out the timestamps (for loopback). It is within this custom block that the
>>> the offset is detected at the output of the AXI wrapper before any
>>> processing has taken place.
>>>
>>>
>>> Any ideas?
>>>
>>>
>>> Andy
>>>
>>>
>>>
>>>
>>> Sent from Outlook <http://aka.ms/weboutlook>
>>>
>>> ___
>>> 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] TwinRx Channel Alignment

[Derek Kozel via USRP-users]

The stream command object has a field for a time spec of when to start
streaming and a boolean flag for whether to make use of that time spec.
http://files.ettus.com/manual/structuhd_1_1stream__cmd__t.html

Here we can see it used in an rx example.
https://github.com/EttusResearch/uhd/blob/maint/host/examples/rx_timed_samples.cpp#L92-L93

Usually it is most practical to make a call to get_time_now() and then add
an offset from that time which is returned. The minimum offset would be the
roundtrip command time, usually a few milliseconds.

Regards,
Derek

On Thu, Mar 8, 2018 at 9:03 PM, Andrew Thommesen 
wrote:

> No, how do you do that?
>
>
> Sent from Outlook 
> --
> *From:* Derek Kozel 
> *Sent:* 08 March 2018 20:58:38
> *To:* Andrew Thommesen
> *Cc:* usrp-users
> *Subject:* Re: [USRP-users] TwinRx Channel Alignment
>
> Hello Andrew,
>
> Are you starting the streaming with timed commands?
>
> Regards,
> Derek
>
> On Mar 8, 2018 7:32 PM, "Andrew Thommesen via USRP-users" <
> usrp-users@lists.ettus.com> wrote:
>
> Hi all,
>
>
> I have an x310 with a twinRx and would like to process coherent,
> time aligned data within the FPGA. However, the data is not currently time
> aligned and there is an offset of ~400 samples between the two channels.
>
>
> The RFNoC radio block is configured to receive data on both channels, with
> the LO of channel 1 set to companion. The output of the radio block then
> passes through the RFNoC DDC block that decimates from 100MSPS to 50MSPS.
> The decimated data then passes to a custom RFNoC block that strips out the
> timestamps (for loopback). It is within this custom block that the the
> offset is detected at the output of the AXI wrapper before any processing
> has taken place.
>
>
> Any ideas?
>
>
> Andy
>
>
>
>
> Sent from Outlook 
>
> ___
> 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] TwinRx Channel Alignment

[Derek Kozel via USRP-users]

Hello Andrew,

Are you starting the streaming with timed commands?

Regards,
Derek

On Mar 8, 2018 7:32 PM, "Andrew Thommesen via USRP-users" <
usrp-users@lists.ettus.com> wrote:

Hi all,


I have an x310 with a twinRx and would like to process coherent,
time aligned data within the FPGA. However, the data is not currently time
aligned and there is an offset of ~400 samples between the two channels.


The RFNoC radio block is configured to receive data on both channels, with
the LO of channel 1 set to companion. The output of the radio block then
passes through the RFNoC DDC block that decimates from 100MSPS to 50MSPS.
The decimated data then passes to a custom RFNoC block that strips out the
timestamps (for loopback). It is within this custom block that the the
offset is detected at the output of the AXI wrapper before any processing
has taken place.


Any ideas?


Andy




Sent from Outlook 

___
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] FPGA and Firmware Development Platform

[Derek Kozel via USRP-users]

Hello Zhongyuan Zhao,

Doing FPGA development on the X310 almost never requires interacting with
the ZPU. The ZPU is used with the UHD driver to provide underlying system
support. The recommended way to add DSP operations to the FPGA is to
construct or modify RFNoC blocks.
I'd recommend reading the application note on RFNoC development and/or
watching this video which covers much the same content.

https://kb.ettus.com/Getting_Started_with_RFNoC_Development
https://www.youtube.com/watch?v=j-EfyPVpaJ8

In short, development requires a license to Vivado 2017.4 and the X310s
have JTAG and Chipscope capability exposed to Vivado via the frontpanel USB
socket. We'd be happy to answer any questions you have about RFNoC
development.

Regards,
Derek

On Thu, Mar 8, 2018 at 5:50 PM, Zhongyuan Zhao via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I wanna customize the USRP FPGA code on X310/N310. I found out that FPGA
> code is structured as a softcore ZPU controlling peripherals.
>
> The FPGA code can be developed on ISE and Vivado, and the firmware of ZPU
> can be compiled via ZPUGCC. But this seems to be insufficient for
> development, especially debugging.
>
> What is the recommeded workflow/tools to debug the FPGA and firmware code?
> Is there any JTAG/emulator/simulator for ZPU so that we can step into the
> code, and examine the registers?
>
> Does ZPU provide features similar to RS232 offered by many embedded system
> to print out check points in the program?
>
> Thanks!
>
> Zhongyuan Zhao
>
> PhD Candidate,
> Department of Computer Science & Engineering,
> University of Nebraska-Lincoln
> Office Hour: WF 9:30-10:00am, Avery Hall 12,
> Suite 117, Schorr Center,
> Lincoln, Nebraska 68588-0115
>
>
> ___
> 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] [Discuss-gnuradio] Regarding Tempest implementation in GNURadio.

[Derek Kozel via USRP-users]

Hello Kushagra,

I can't. I've never looked into the details of digital video signals and so
I would be starting where you are. As I said, I would start by trying to
run the existing code and getting it working. From there you can research
online for information about the video signals inside your test setup then
start comparing that with the signals received by the working application.
When you get to that point and have questions we may be able to better help
you with specific questions.

I hope you do choose this or another project involving GNU Radio for your
final year presentation. We'd be very interested in hearing how the project
goes.

Best of luck,
Derek

On Thu, Mar 8, 2018 at 11:04 AM, Kushagra Dixit 
wrote:

> Hello Derek,
>
> Thanks for the reply.
> Can you suggest some book or something to understand the nature of the
> signals used in Tempest ?
>
> Best Regards,
> Kushagra Dixit
>
> On Thu, Mar 8, 2018 at 4:30 PM, Derek Kozel  wrote:
>
>> Hello Kushagra,
>>
>> This is a very broad question which is probably why no one has responded
>> yet, we simply don't have a good answer for you. Based on a quick look at
>> that project it seems like it already supports LCDs, it is shown to work
>> with DVI signals. Do you believe that it doesn't?
>>
>> As for a way to approach the problem, all I can offer are generic steps
>> I'd take to solve most problems. First, you have a working codebase which
>> does (almost?) what you want. Get it working and then study how it does the
>> signal processing. This will probably involve finding and understanding
>> some documents about the types of video signals which it supports decoding.
>> Then, if it doesn't do what you want, look for similar documents for the
>> video signals you want to decode and look at extending the module to
>> support the extra signal processing.
>>
>> Regards,
>> Derek
>>
>> On Sun, Mar 4, 2018 at 9:45 AM, Kushagra Dixit <
>> dixitkushagra...@gmail.com> wrote:
>>
>>> Hello Everybody,
>>>
>>> I am currently a third year Bachelors in Electronics student from India.
>>> I have had signals and systems and digital signal processing in my course
>>> already. I have used different GNURadio projects (gr-gsm, openBTS) in the
>>> past and have gone through Micheal Ossmann's Videos. I am very interested
>>> in making a GNURadio implementation of Tempest (
>>> https://github.com/martinmarinov/TempestSDR) for LCD screens. What
>>> would be the correct way of approaching the problem ? Also what all will I
>>> need to learn to do it efficiently ? The languages I know are C, Java and
>>> Python. I have a USRP B210.
>>>
>>> P.S. Also is there any definitive guide to such signals I cannot find
>>> any reading material on them.
>>>
>>> Any help would be greatly appreciated. This project will be for my final
>>> year presentation.
>>>
>>> Best Regards,
>>> Kushagra Dixit
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> discuss-gnura...@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] set_rx_lo_source

[Derek Kozel via USRP-users]

Hello,

Setting the LO source does not tune the synthesizers so the actual command
duration should be very short. How are you measuring the durations?

I looked at why the twinrx_freq_hopping demo is not built by default on
Windows and it is because of an optional feature which requires a library
which Windows does not include, Curses. By removing the ascii_art_dft.hpp
include and the write_fft_to_file function the example should compile and
run with no other changes on Windows. Doing this would be a good test as it
would help isolate if there is a performance issue or an issue with how the
API is being used in your current test program. The example is very
carefully constructed so that there are minimal delays and so commands are
already queued on the FPGA before their scheduled execution time.

If you have a custom C program could you share the code? It would be useful
to see the order of operations.

Regards,
Derek


On Tue, Feb 27, 2018 at 3:08 PM, Андрей 1 via USRP-users <
usrp-users@lists.ettus.com> wrote:

>
> Hello
>
> 
>
> In the previous post(twinrx_freq_hopping example
> ),
> I wrote that I could not get time in 5 ms for example twinrx_freq_hopping.
> I measure the commands execute time  in the recieve loop and found with
> surprise that the set_rx_lo_source function for the first time worked 0 ms
> and the next time more than 40 ms.
> It is because of this that a large tuning time in the frequency range is
> obtained.
> Can someone explain to me why this can happen?
>
>
> Thank you
>
>
> ___
> 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] X300 sample rate

[Derek Kozel via USRP-users]

Hello,

You are receiving the maximum possible sample rate. The TwinRX is able to
provide two channels of data compared to the usual 1 per daughterboard
because it uses the 200 MS/s ADC to do real mode sampling on the two
channels. The FPGA then does a conversion to 100 MS/s Complex samples for
each of the two channels since all the rest of the DSP chain is designed
for complex signals. There is no way to bypass this real to complex
conversion in the prebuilt FPGA images.

The TwinRX only supports the use of the 200 MHz master clock rate. The IF
passband filter provides 80 MHz of bandwidth per channel which follows the
general convention of usable bandwidth being 80% of the sample rate when
using complex samples. If the sample rate is reduced below 200 MS/s real
(100 MS/s complex) then that IF filtering is insufficient and aliasing will
occur. Additionally the IP for doing the final conversion to baseband is
based on having that full bandwidth available.

Regards,
Derek



On Fri, Mar 2, 2018 at 2:57 PM, Андрей 1 via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I right now started benchmark_rate with sample rate 200 but got 100
> MHz(see png).
> Can I get data without decimation on a clock 200 MHz?
>
> Thank you.
>
> 02.03.2018, 16:30, Daniel Jepson 
> Hi,
>
> The X300/X310 supports three Sampling Rates: 120MHz, 184.32MHz, and
> 200MHz. Your rate was most likely coerced to the most common rate of 200M.
> The FPGA then performs decimation and interpolation such that the host
> doesn't have to stream all that bandwidth (nor can it in most cases). The
> streaming rate called out in your screen shots is 10.0Msps.
>
> Does that answer your question?
>
> -Daniel
>
> On Fri, Mar 2, 2018 at 7:57 AM, Андрей 1 via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>
> Hello
>
> When I open  device with uhd_usrp_make in the terminal I see a message
> "invalid sample rate 100 MHz actual rate is 200 MHz".The same message I see
> when running application from uhd samples folder.
> If I set sample rate 200 MHz and then read them from device I got 100 MHz.
>
> What does this mean and what is the maximum clock of the X300 in single
> and multichannel mode?
>
> See png for detail.
>
> Thank you
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com 
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> --
>
> Daniel Jepson
>
> Digital Hardware Engineer
>
> National Instruments
>
>
>
> O: +1.512.683.6163 <(512)%20683-6163>
>
> daniel.jep...@ni.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] OctoClock CDA-2990 FAQ missing link

[Derek Kozel via USRP-users]

Hello Professor Mercado,

In addition to Neel's link for the Octoclock, here is one for the B210.
http://files.ettus.com/manual/page_usrp_b200.html

Also an application note about getting started with the C++ UHD API to
USRPs.
https://kb.ettus.com/Getting_Started_with_UHD_and_C%2B%2B

Regards,
Derek

On Thu, Mar 1, 2018 at 4:45 PM, Neel Pandeya via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello Professor Mercado:
>
> Our apologies, you have stumbled on a typo in our documentation on the
> Knowledge Base (KB), which I'll fix shortly. The correct link is listed
> below.
>
> http://files.ettus.com/manual/page_octoclock.html
>
> Please let me know if you have any further questions.
>
> --​Neel Pandeya
>
>
>
>
> On 1 March 2018 at 08:39, Mercado, Alejandra via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Dear OctoClock CDA-2990 users/support,
>>
>> Just got mine in the mail today. I'm reading https://kb.ettus.com/O
>> ctoClock_CDA-2990
>>
>> and was happy to see under the FAQ subheading:
>>
>>
>>- *Where can I find user manuals for the OctoClock and USRP*
>>
>> Here is helpful document. Sync. and MIMO w/ the USRP
>>
>> Also, here is some documentation on how to use UHD™ to interact with
>> multi-USRP systems.
>>
>>
>> However, there are no links in either of those lines.
>>
>> So, where do I find the helpful document and the documentation on how to
>> use the UHD to interact with my B210 devices?
>>
>> Regards
>>
>> ===
>> Dr. Alejandra Mercado
>> Associate Director
>> Electrical and Computer Engineering
>> Master's in Telecommunications Program
>> A.V. Williams Building
>> University of Maryland at College Park
>> College Park, MD 20742
>> ===
>>
>> ___
>> 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] USRP-users help needed

[Derek Kozel via USRP-users]

Hello Joe,

The source code for both the driver and FPGA HDL are hosted on GitHub. Here
are links to them:
https://github.com/EttusResearch/uhd
https://github.com/EttusResearch/fpga

The manual has a short section about sample rate options:
http://files.ettus.com/manual/page_general.html#general_sampleratenotes

The B200mini's decimation is provided by its DDC. The host controls are in
this file:
https://github.com/EttusResearch/uhd/blob/7ac01c7f979aab8fac5e62f596ff0af52cedec40/host/lib/usrp/cores/rx_dsp_core_3000.cpp

You are probably most interested in this function:
https://github.com/EttusResearch/uhd/blob/7ac01c7f979aab8fac5e62f596ff0af52cedec40/host/lib/usrp/cores/rx_dsp_core_3000.cpp#L148

On the FPGA side
https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/dsp/ddc_chain.v

Did you have specific questions?

Regards,
Derek


On Mon, Feb 26, 2018 at 5:07 PM, Stern, Joseph via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear USRP users:
>
>
>
> We have been trying to understand the low-level details of the USRP
> architecture (namely, for the B200mini); there seems very little explicit
> insight provided on the Ettus web site into how decimation is performed in
> the FPGA (and commanded from the driver side).  I also cannot locate the
> open-source and freely available FPGA code.  Could someone assist me in
> gaining this insight?
>
>
>
> Thank you very much!
>
>
>
> Joe Stern
> This message and any enclosures are intended only for the addressee.
> Please
> notify the sender by email if you are not the intended recipient. If you
> are
> not the intended recipient, you may not use, copy, disclose, or distribute
> this
> message or its contents or enclosures to any other person and any such
> actions
> may be unlawful. Ball reserves the right to monitor and review all
> messages
> and enclosures sent to or from this email address.
>
> ___
> 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] twinrx_freq_hopping example

[Derek Kozel via USRP-users]

I'm not sure how you are responding, but it is still not threading
correctly. Thanks for trying though.

I would not expect the C API to make a performance difference like that
since it is only a wrapper. Are you still using timed commands? If not then
the additional overhead of sending commands from the host computer to the
USRP and back could account for some of the performance difference.

On Mon, Feb 26, 2018 at 3:53 PM, Андрей 1 via USRP-users <
usrp-users@lists.ettus.com> wrote:
Thank you for the clarification about set_rx_lo_freq.

Can the problem with long setup time arise due to the fact that I use C API?

Thank you


On Mon, Feb 26, 2018 at 3:44 PM, Derek Kozel  wrote:

> Hello,
>
> Please can you keep your emails in a single thread so it is easier to read.
>
> The goal with the frequency hopping example is to instantly jump between
> frequencies. Normally those 3-5 ms of tuning would be dead time, no
> meaningful signal could be received. By using the RF synthesizers of both
> channels and switching the LO source back and forth you are always jumping
> to a frequency after the synthesizers have already tuned and settled.
>
> The text written at the top of the example should be rewritten to be a bit
> clearer. There are other situations, such as using an external LO, where
> the set_rx_lo_freq call is useful. In this example however the benefit
> comes from tuning the unused synthesizers. If all the frequencies which you
> wish to tune to the receiver to are known ahead of time it would be
> possible to have UHD pre-calculate all the LO frequencies, store them in
> your application, and then save a few microseconds by using the
> set_rx_lo_freq function to avoid UHD doing extra work to configure the
> filters on the unused channel. This is almost never useful since there is
> some margin in the 5 ms frequency hopping time. Also often applications
> will actually want to sit on one frequency longer than 5 ms and are only
> using the LO source swapping ability to avoid the dead time of synthesizer
> tuning.
>
> Regards,
> Derek
>
> On Mon, Feb 26, 2018 at 3:21 PM, Андрей 1 via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> I have no any error in twinrx_recv.
> If the tuning frequency is already sufficiently small, then why these
> special calls(set_rx_lo_freq) for twinRX?
>
> Thank you
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> On Mon, Feb 26, 2018 at 3:08 PM, Андрей 1  wrote:
>
>> Im using UHD 3.10.3 and have no error in twinrx_recv
>>
>>
>> 26.02.2018, 17:01, Derek Kozel 
>> Hello,
>>
>> The tuning time is approximately 5 ms, which is why the example uses that
>> number. The example should work the same on either Windows or Linux. What
>> version of UHD are you using on Windows which does not include it?
>>
>> Are you seeing any streaming errors on Windows?
>>
>> Regards,
>> Derek
>>
>> On Mon, Feb 26, 2018 at 2:53 PM, Андрей 1 via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>
>> Hello
>>
>> Im using X300+TwinRX in Windows.
>> In source UHD 3.10.3 for linux I found example twinrx_freq_hopping.
>> How much I understand in this example the receiver is tuned with the
>> period 5ms.As written in the title of the example, I need to use
>> set_rx_lo_freq.But it is not in the source code of the example.
>> When I compile and run this example in windows I found much more begger
>> times (about 30-40 ms) to receive correct spectrum.(If I leave the time as
>> in the example, then there are no parts of the spectrum and so the receiver
>> does not have time to tune in).
>>
>> My questions
>>
>> What minimum tuning time for TwinRX+X300?
>> Why is there no such example for Windows?
>> Is it necessary to use set_rx_lo_freq to reduce setup time?
>>
>> Thank you
>>
>> .
>>
>>
>> ___
>> 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] twinrx_freq_hopping example

[Derek Kozel via USRP-users]

Hello,

Please can you keep your emails in a single thread so it is easier to read.

The goal with the frequency hopping example is to instantly jump between
frequencies. Normally those 3-5 ms of tuning would be dead time, no
meaningful signal could be received. By using the RF synthesizers of both
channels and switching the LO source back and forth you are always jumping
to a frequency after the synthesizers have already tuned and settled.

The text written at the top of the example should be rewritten to be a bit
clearer. There are other situations, such as using an external LO, where
the set_rx_lo_freq call is useful. In this example however the benefit
comes from tuning the unused synthesizers. If all the frequencies which you
wish to tune to the receiver to are known ahead of time it would be
possible to have UHD pre-calculate all the LO frequencies, store them in
your application, and then save a few microseconds by using the
set_rx_lo_freq function to avoid UHD doing extra work to configure the
filters on the unused channel. This is almost never useful since there is
some margin in the 5 ms frequency hopping time. Also often applications
will actually want to sit on one frequency longer than 5 ms and are only
using the LO source swapping ability to avoid the dead time of synthesizer
tuning.

Regards,
Derek

On Mon, Feb 26, 2018 at 3:21 PM, Андрей 1 via USRP-users <
usrp-users@lists.ettus.com> wrote:
I have no any error in twinrx_recv.
If the tuning frequency is already sufficiently small, then why these
special calls(set_rx_lo_freq) for twinRX?

Thank you

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

On Mon, Feb 26, 2018 at 3:08 PM, Андрей 1  wrote:

> Im using UHD 3.10.3 and have no error in twinrx_recv
>
>
> 26.02.2018, 17:01, Derek Kozel 
> Hello,
>
> The tuning time is approximately 5 ms, which is why the example uses that
> number. The example should work the same on either Windows or Linux. What
> version of UHD are you using on Windows which does not include it?
>
> Are you seeing any streaming errors on Windows?
>
> Regards,
> Derek
>
> On Mon, Feb 26, 2018 at 2:53 PM, Андрей 1 via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>
> Hello
>
> Im using X300+TwinRX in Windows.
> In source UHD 3.10.3 for linux I found example twinrx_freq_hopping.
> How much I understand in this example the receiver is tuned with the
> period 5ms.As written in the title of the example, I need to use
> set_rx_lo_freq.But it is not in the source code of the example.
> When I compile and run this example in windows I found much more begger
> times (about 30-40 ms) to receive correct spectrum.(If I leave the time as
> in the example, then there are no parts of the spectrum and so the receiver
> does not have time to tune in).
>
> My questions
>
> What minimum tuning time for TwinRX+X300?
> Why is there no such example for Windows?
> Is it necessary to use set_rx_lo_freq to reduce setup time?
>
> Thank you
>
> .
>
>
> ___
> 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] twinrx_freq_hopping example

[Derek Kozel via USRP-users]

Hello,

The tuning time is approximately 5 ms, which is why the example uses that
number. The example should work the same on either Windows or Linux. What
version of UHD are you using on Windows which does not include it?

Are you seeing any streaming errors on Windows?

Regards,
Derek

On Mon, Feb 26, 2018 at 2:53 PM, Андрей 1 via USRP-users <
usrp-users@lists.ettus.com> wrote:

>
> Hello
>
> Im using X300+TwinRX in Windows.
> In source UHD 3.10.3 for linux I found example twinrx_freq_hopping.
> How much I understand in this example the receiver is tuned with the
> period 5ms.As written in the title of the example, I need to use
> set_rx_lo_freq.But it is not in the source code of the example.
> When I compile and run this example in windows I found much more begger
> times (about 30-40 ms) to receive correct spectrum.(If I leave the time as
> in the example, then there are no parts of the spectrum and so the receiver
> does not have time to tune in).
>
> My questions
>
> What minimum tuning time for TwinRX+X300?
> Why is there no such example for Windows?
> Is it necessary to use set_rx_lo_freq to reduce setup time?
>
> Thank you
>
> .
>
>
> ___
> 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] B200 Noise Figure Meter

[Derek Kozel via USRP-users]

Hi Dan,

The E310/E312 has the switchable set of receive and transmit filters which
the B2xx does not. This will impact the noise figure due to the additional
losses of the switches and filters. As with most receivers an external LNA
and filter matched to a frequency of interest will reduce the total system
noise figure.

Derek

On Sun, Feb 4, 2018 at 5:55 PM, Dan CaJacob via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Yep, I am aware of that document and I am using the Y-factor method.
>
> The 3 dB attenuator was calibrated with the B200 - i.e. I measured the NF
> of the USRP + 3dB attenuator as a system. That data then serves as the
> calibration data to correct for it's contribution to the subsequent NF
> measurement of the B200 + 3dB pad + DUT.
>
> I saw the same poor performance below 1 GHz when using the 3dB pad.
>
> On Sun, Feb 4, 2018 at 11:44 AM David Bengtson 
> wrote:
>
>> A 3dB attenuation will really improve the reflection coefficient.
>> Using this calculator
>> http://www.rfcafe.com/references/calculators/vswr-return-loss-conversion-
>> calculator.htm
>> you can see that a 3 dB attenuation will improve a 3:1 VSWR to 1.7:2,
>> or a 6 dB return loss to 12 dB, so you've really improved the match.
>> The gory details of noise figure and match are in here
>> http://literature.cdn.keysight.com/litweb/pdf/5952-3706E.pdf and
>> Keysight has a spreadsheet to do the calculations here
>> https://www.keysight.com/main/editorial.jspx?cc=US=eng;
>> ckey=96887=-34815.0.00=96887
>> (Probably more detail than needed)
>>
>> Did you add the 3dB attenuator to the noise figure?
>>
>> Dave
>>
>>
>>
>> On Sat, Feb 3, 2018 at 10:41 AM, Dan CaJacob via USRP-users
>>  wrote:
>> > I saw no improvement when including a 3dB 50 Ohm attenuator as part of
>> the
>> > B200 NF meter. I guess I could try higher attenuator values.
>> >
>> > On Thu, Feb 1, 2018 at 9:16 PM Dan CaJacob 
>> wrote:
>> >>
>> >> I was gonna say, there's actually three of them ;)
>> >>
>> >>
>> >> On Thu, Feb 1, 2018, 9:06 PM Robin Coxe via USRP-users
>> >>  wrote:
>> >>>
>> >>> On p.8 of B200 schematic:
>> >>> T801 is Macom ETC1-1-13TR (RF2)
>> >>> T800 is Minicircuits TC1-1-43A+ (RF3)
>> >>> U802 is Anaren BD3150L50100AHF (RF1)
>> >>>
>> >>> On Thu, Feb 1, 2018 at 5:45 PM, Ron Economos via USRP-users
>> >>>  wrote:
>> 
>>  There's also a balun on the AD9361 input. Unfortunately, the balun
>> part
>>  number for the low frequency path is not on the schematic.
>> 
>>  Ron
>> 
>>  On 02/01/2018 05:39 PM, Dan CaJacob via USRP-users wrote:
>> 
>>  That's an interesting thought. The 9361 does have a pretty bad match.
>>  I'll try adding a 50 Ohm attenuator and see if that helps.
>> 
>>  On Thu, Feb 1, 2018 at 5:14 PM Robin Coxe 
>> wrote:
>> >
>> > Hi Dan.   Both the B200 and the E312 use the Analog Devices AD9361
>> RF
>> > integrated transceiver. This chip does have an integrated LNA.
>>  Perhaps
>> > there's some sort of mismatch between your DUTs and this integrated
>> LNA at
>> > <1 GHz?
>> >
>> > ADI publishes the RX S-parameters:
>> > https://ez.analog.com/thread/41208#137929
>> >
>> > -Robin
>> >
>> > On Thu, Feb 1, 2018 at 7:46 AM, Dan CaJacob via USRP-users
>> >  wrote:
>> >>
>> >> Hey guys,
>> >>
>> >> I have put together a noise figure meter application that uses a
>> USRP
>> >> as the sensing device. It started off as a way to measure the NF
>> of the USRP
>> >> itself. I have a calibrated noise source from an HP 8970B Noise
>> Figure
>> >> Meter. To test the NF of the USRP, I connect the head to the USRP
>> input. My
>> >> GNURadio flowgraph maximizes the USRP gain and measures a moving
>> average of
>> >> the received power while I switch the noise source on and off. The
>> >> difference in the received power level, in addition to the ENR
>> table from
>> >> the noise source, can then be used to calculate the NF of the USRP
>> itself
>> >> using the y-factor method.
>> >>
>> >> Once you have the NF for the USRP at many frequencies (I test
>> every 50
>> >> MHz from 50 MHz - 6000 MHz), you can modify the same procedure to
>> test the
>> >> NF of a Device Under Test (DUT) which is connected between the
>> noise source
>> >> and the (now calibrated) USRP. You can use the USRP cal table we
>> generated
>> >> in the previous step to derive the NF of the DUT corrected for the
>> NF of the
>> >> USRP.
>> >>
>> >> In short, this all works incredibly well and garners very
>> repeatable
>> >> results. One complication is that you will see wild NF at certain
>> >> frequencies due to local interference like LTE and WIFI. I've also
>> compared
>> >> the results to that 

Re: [USRP-users] Unable to ping USRP X310/NI 2952R after flash image update

[Derek Kozel via USRP-users]

Hello Akshatha,

What ethernet connection are you using between the USRP and the host
computer? The IP address of the USRP will depend on which SFP+ port and
what FPGA image you are using.
http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_setup_network

Regards,
Derek

On Thu, Feb 15, 2018 at 6:53 AM, Akshatha Nayak via USRP-users <
usrp-users@lists.ettus.com> wrote:

>
> Hi Community,
>
> We have been trying to interface the USRP X310 (NI-2952R) with LTE stack on an
> Ubuntu machine. The USRP is detected when we run the command 
> "uhd_find_devices". When we
> execute the command "uhd_usrp_probe", it prompts us to update the fpga
> image on the system. PFA the logs in the file "uhd_usrp_ptobe.txt". After
> following the instructions given in the link, we are not longer able to
> ping the device. We also tried device recovery options from Ettus and NI
> sites using the JTAG interface. PFA the file "Usrp_jtag_dump.txt" for the
> logs.
>
> We also tried with Xilinx Vivado tool to flash the image as  per the ettus
> site- https://kb.ettus.com/X300/X310_Device_Recovery
>
> We also followed this post 
> --http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-November/016600.html
> but facing same issue as with the post.
>
>
>
> Please advise us on the future course of action
>
> --
>
> Regards,
> Akshatha
>
> ___
> 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] IF filtering of X310

[Derek Kozel via USRP-users]

Hello Fabian,

The set_rx_bandwidth() function does not work with the TwinRX. If the value
returned by get_rx_bandwidth is changing then that is a bug which I will
look into. It is used for the B2xx and E3xx series, as well as the brand
new N310, which have RFICs with programmable bandpass filters.

The TwinRX gets two channels of 100 MS/s complex samples by running the
ADCs at 200 MS/s real value sampling and doing a conversion to half rate
complex with appropriate filtering. Yes, there is a digital frequency shift
of + or - 50 MHz (equivalent to 150 MHz) to bring the final IF to baseband
and correct for mirroring caused by the various mixing possibilities.

The DDC contains a set of halfband filters and a CIC filter. This is
described in detail in the manual. The DDC will appropriately filter for
its decimation factor.
http://files.ettus.com/manual/page_general.html#general_sampleratenotes

Regards,
Derek

On Thu, Feb 15, 2018 at 1:40 PM, Fabian S. via USRP-users <
usrp-users@lists.ettus.com> wrote:

>
> Hi everyone,
>
> I am currently working with the X310 and two TwinRX daugerboards and have
> a problem understanding the processing done in the FPGA.
> As far as I understood the TwinRX works as a super-het and has the second
> (ADC) IF at 150 MHz with 80 MHz bandwidth (according to the block diagram
> in the schematics). The ADC of the X310 runs at 200 Msps, so it is working
> with undersampling I guess?
> Now I am missing a block diagram of what is happening in the FPGA. My
> guess is that he will mix the ADC signal with a complex sine-wave so that
> the 150 MHz will be at zero -> exp(-j*2*pi*150MHz*t). After that there has
> to be some sort of filtering and downsampling. But which exactly? According
> to the warning message I get depending on the sample rate I set, I guess
> there are multiple half-band filters and an CIC filter which are used in
> different combinations to get the required sample rate. Is there somewhere
> a block diagram and rules for that?
> Now to my main problem: I get a lot of aliasing. For example I have set my
> sample rate to 10e6, I can tune my generator several times the bandwidth
> above the center frequency and will still see it with barely any atenuation.
> Additionally I noticed setting the RX bandwidth has no effect. Even if I
> set it to a very low value (100kHz) at 10Msps, I see no effect.
> Do I have to implement the digital filters my own using RFNoC? What is the
> set_rx_bandwidth() function good for? I know there are board which do not
> support this function but as far as I understood then the board will report
> the currently used bandwidth when calling get_rx_bandwidth() - mine always
> reports the value I set.
>
> Best regards,
>
> Fabian
>
>
> ___
> 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] A capable Laptop with 10Gb Lan support for USRP X310?

[Derek Kozel via USRP-users]

Hello Mark,

Yes, people have used external Thunderbolt to 10 GigE SFP+ adapters
successfully in the past.
https://www.youtube.com/watch?v=w9wlKYDEOUU

I do not have up to date information about the level of performance to be
expected in such a setup however. In the video Balint is streaming at 100
MS/s, half the potential bandwidth of one channel, and only receiving. I
believe we may have some more recent testing results and will try to find
those for you.

Regards,
Derek

On Wed, Feb 14, 2018 at 12:43 PM, Mark Luscombe via USRP-users <
usrp-users@lists.ettus.com> wrote:

> For the development of a RFNoC project I have a powerful tower PC with an
> Intel X520-DA2 PCIe card which features dual 10Gb SPF+ ports. With some
> Cisco SFP 10G Copper Twinax cable this matches the USRP X310’s network
> connectivity well.
>
>
>
> We are considering taking the project on the road, and it would be really
> nice to have something a bit more portable than the tower PC. Has anybody
> investigated a Laptop solution that includes 10Gb Lan support? A quick
> Google highlights Laptops with Thunderbolt 3 interfaces (USB Type-C 3.1),
> and external Thunderbolt 3 to 10Gb SPF+ adapters like the following.
>
>
>
> http://www.sonnettech.com/product/twin10g-sfp-thunderbolt3.html
>
>
>
> https://www.atto.com/products/thunderbolt-adapters/
> thunderlink/thunderbolt-to-ethernet/TLNS-3102-D00
>
>
>
> Has anybody considered something like this, or got an alternative Laptop
> solution?
>
>
>
> Thanks in advance, Mark.
>
>
>
> ___
> 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 B210 TX-Issues

[Derek Kozel via USRP-users]

Hello Jonathan,

The gain setting in the USRPs are indexed from minimum gain. On most this
means a gain of 0 is actually an attenuation of the signal. The N210's gain
range is based on what amplifiers and attenuators are on the daughterboard
that is installed. The ranges aren't calibrated to be aligned across
different USRP products so what you are seeing is completely normal.

On Feb 12, 2018 10:21 PM, "Jonathan B via USRP-users" <
usrp-users@lists.ettus.com> wrote:

Hi Marcus,

Thanks! Didn't realise there was a larger range for the B2xx family. At
60dB it seems to perform as well as 20dB on the N210. Is that normal?

But either way - something I can work with. Thanks.


Virus-free.
www.avast.com

<#m_-3868461721852336890_m_4051027392395733961_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2018-02-09 20:53 GMT+01:00 Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com>:

> On 02/09/2018 02:48 PM, Jonathan B via USRP-users wrote:
>
> Hi Jeff,
>
> Thanks for the response.
>
> In both cases a gain of 20dB.
>
> Best,
> Jonathan
>
> The total gain-control range on the B2xx family is larger (80dB) than on
> the cards used on X3xxx, N2xx, etc (typically 30.5dB)
>
> Try larger gain values on the B210, like 40 or 50dB.
>
>
>
> On Feb 9, 2018 8:23 PM, "Jeff Long via USRP-users" <
> usrp-users@lists.ettus.com> wrote:
>
>> What are you using for gain settings?
>>
>> On 02/09/2018 01:09 PM, Jonathan B via USRP-users wrote:
>>
>>> Hi everyone,
>>>
>>> I seem to be having issues with the B210 transmitting at an incredibly
>>> low power.
>>>
>>> I seem to be getting a 60db difference at the receiver (spectrum
>>> analyzer) between the B210 and N210 with perfectly identically configured
>>> transmissions using the simple uhd "tx_waveform" example program.
>>>
>>> Has anyone experienced such an issue. I have two B210s that seem to be
>>> acting the same way.
>>>
>>> Thanks in advance.
>>>
>>> Best Regards,
>>> Jonathan
>>>
>>> -
>>>
>>> Probe Output of the B210:
>>>
>>> -- Loading firmware image: C:\Program Files\GNURadio-3.7\share\uhd\i
>>> mages\usrp_b200_fw.hex...
>>> -- Detected Device: B210
>>> -- Loading FPGA image: C:\Program 
>>> Files\GNURadio-3.7\share\uhd\images\usrp_b210_fpga.bin...
>>> done
>>> -- Operating over USB 3.
>>> -- Detecting internal GPSDO No GPSDO found
>>> -- Initialize CODEC control...
>>> -- Initialize Radio control...
>>> -- Performing register loopback test... pass
>>> -- Performing register loopback test... pass
>>> -- Performing CODEC loopback test... pass
>>> -- Performing CODEC loopback test... pass
>>> -- Setting master clock rate selection to 'automatic'.
>>> -- Asking for clock rate 16.00 MHz...
>>> -- Actually got clock rate 16.00 MHz.
>>> -- Performing timer loopback test... pass
>>> -- Performing timer loopback test... pass
>>>_
>>>   /
>>> |   Device: B-Series Device
>>> | _
>>> |/
>>> |   |   Mboard: B210
>>> |   |   revision: 4
>>> |   |   product: 2
>>> |   |   serial: 3113A66
>>> |   |   name: MyB210
>>> |   |   FW Version: 8.0
>>> |   |   FPGA Version: 14.0
>>> |   |
>>> |   |   Time sources:  none, internal, external, gpsdo
>>> |   |   Clock sources: internal, external, gpsdo
>>> |   |   Sensors: ref_locked
>>> |   | _
>>> |   |/
>>> |   |   |   RX DSP: 0
>>> |   |   |
>>> |   |   |   Freq range: -8.000 to 8.000 MHz
>>> |   | _
>>> |   |/
>>> |   |   |   RX DSP: 1
>>> |   |   |
>>> |   |   |   Freq range: -8.000 to 8.000 MHz
>>> |   | _
>>> |   |/
>>> |   |   |   RX Dboard: A
>>> |   |   | _
>>> |   |   |/
>>> |   |   |   |   RX Frontend: A
>>> |   |   |   |   Name: FE-RX2
>>> |   |   |   |   Antennas: TX/RX, RX2
>>> |   |   |   |   Sensors: temp, rssi, lo_locked
>>> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
>>> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
>>> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
>>> |   |   |   |   Connection Type: IQ
>>> |   |   |   |   Uses LO offset: No
>>> |   |   | _
>>> |   |   |/
>>> |   |   |   |   RX Frontend: B
>>> |   |   |   |   Name: FE-RX1
>>> |   |   |   |   Antennas: TX/RX, RX2
>>> |   |   |   |   Sensors: temp, rssi, lo_locked
>>> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
>>> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
>>> |   |   |   |   Bandwidth range: 20.0 to 

Re: [USRP-users] NI USRP / PCIe interface and RFNoC FPGA images

[Derek Kozel via USRP-users]

Hi Tarik,

I'm glad you got that working. Yes, modifying UHD is certainly a way that
you can specify a custom file. I didn't mention it because the device
arguments method works in nearly all software. For instance, the path to
the bitstream can certainly be supplied as a parameter in GNU Radio
Companion as I said earlier. I've attached a screenshot of the USRP Source
block in GRC with an FPGA image specified.

The device arguments are covered in the manual here.
http://files.ettus.com/manual/page_configuration.html

On Tue, Jan 30, 2018 at 2:34 PM, Tarik Kazaz  wrote:

> Hello Derek,
>
>
>
> I managed to specify custom bistream file by editing one of uhd source
> files ( “/rfnoc/src/uhd/host/build/lib/transport/nirio/lvbitx/
> x310_lvbitx.cpp”)
>
> Changing line 50 to
>
> std::string fpga_file = “usrp_x310_fpga_RFNOC_” + option + “.lvbitx”;
>
>
>
> and then calling in folder “/rfnoc/src/uhd/host/build$”
>
>
>
> make
>
> make install
>
>
>
> in order to compile new code.
>
>
>
> In this way I redirected path to RFNOC bitstream.
>
>
>
> Thank you for your help.
>
> Indeed I think this is really confusing. Based on documentation, I could
> not figure out what is going on.
>
> I think it would be good to be able to specify path to bit stream as
> parameter in gnuradio-companion.
>
>
>
> Thank you agin,
>
>
>
> Tarik
>
>
>
>
>
>
>
>
>
> *From:* Derek Kozel [mailto:derek.ko...@ettus.com]
> *Sent:* dinsdag 30 januari 2018 14:33
>
> *To:* Tarik Kazaz
> *Cc:* Martin Braun; USRP-users@lists.ettus.com
> *Subject:* Re: [USRP-users] NI USRP / PCIe interface and RFNoC FPGA images
>
>
>
> Hi Tarik,
>
> The USRP source in GNU Radio has a spot for specifying device arguments.
> The osmocom_fft application has a "--args" option the same as the UHD
> utilities. There is not currently the ability to specify a custom default
> FPGA image but it is a feature we agree would be useful.
>
> Regards,
>
> Derek
>
>
>
> On Tue, Jan 30, 2018 at 12:24 PM, Tarik Kazaz  wrote:
>
> Hello Derek,
>
>
>
> I got you. Thank you.
>
>
>
> I have one more question, where can I specify default bit stream location?
>
>
>
> What happen now is that by calling
>
>
>
> uhd_usrp_probe –args =”fpga=/path/to/image.lvbitx”
>
>
>
> I am able to flash USRP with RFNoC design. However, after I run gnuradio
> fosphor program it again roles
>
> back to previous bitstream. Which is logical based on your advices.
>
>
>
> However where can I specify path to default bitstream. In which file I
> should do it?
>
>
>
> Thx for comments related to 10Gbe. Then I think we will need to order also
> 10 Gbe interface.
>
>
>
> Kind Regards,
>
>
>
> Tarik Kazaz
>
>
>
> *From:* Derek Kozel [mailto:derek.ko...@ettus.com]
> *Sent:* dinsdag 30 januari 2018 11:50
> *To:* Tarik Kazaz
> *Cc:* Martin Braun; USRP-users@lists.ettus.com
>
>
> *Subject:* Re: [USRP-users] NI USRP / PCIe interface and RFNoC FPGA images
>
>
>
> Hi Tarik,
>
> Your steps are based on the misunderstanding of how the image loading
> occurs in each of these scenarios.
>
> When using PCIe the FPGA will always be reloaded from the host computer.
> Every program you run using the PCIe link needs the
> "fpga=/path/to/image.lvbitx" string added to the device arguments. The
> image loading is very fast compared to other methods. For example:
>
> uhd_usrp_probe --args="fpga=/path/to/image.lvbitx"
>
> When using JTAG an image is loaded into RAM on the FPGA. This will be
> overwritten if PCIe is used and forgotten (the RAM will clear) when the
> device is turned off. This is useful for rapid testing when using Ethernet
> connections since JTAG is faster than writing to flash, and for recovering
> when an image with an error has been written to the flash.
>
> When using the uhd_image_loader the image is written to flash and will be
> used the next time the device is turned off and on again. This is useful
> for loading a persistent image when using the Ethernet interfaces. PCIe
> will still load and use an image from the host every time.
>
> Can you please try the uhd_usrp_probe with the device arguments specifying
> the FPGA image to use?
>
> As for 2x10 GigE vs PCIe, No, they do not have the same throughput. The
> PCIe is equivalent to 1x 10 GigE. In order to get the full bandwidth of the
> X3x0, which is 2x 200 MS/s on receive, you would need to use both 10 GigE
> connections.
> https://kb.ettus.com/X300/X310#Choosing_a_Host_Interface
>
> Regards,
>
> Derek
>
>
>
> On Tue, Jan 30, 2018 at 10:01 AM, Tarik Kazaz via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hello Martin,
>
> I hope I am replying now correctly (I am using reply all to you and
> mailing list).
> I am still not able to flash RFNoC bit stream on FPGA. Here is what I am
> doing:
>
> 1. First step - Check status of device
>
> Call:   uhd_usrp_probe
> Output:   [INFO] [X300] Using LVBITX bitfile
> /home/cas-sdr/rfnoc/share/uhd/images/usrp_x310_fpga_XG.lvbitx...
>

Re: [USRP-users] NI USRP / PCIe interface and RFNoC FPGA images

[Derek Kozel via USRP-users]

Hi Tarik,

The USRP source in GNU Radio has a spot for specifying device arguments.
The osmocom_fft application has a "--args" option the same as the UHD
utilities. There is not currently the ability to specify a custom default
FPGA image but it is a feature we agree would be useful.

Regards,
Derek

On Tue, Jan 30, 2018 at 12:24 PM, Tarik Kazaz  wrote:

> Hello Derek,
>
>
>
> I got you. Thank you.
>
>
>
> I have one more question, where can I specify default bit stream location?
>
>
>
> What happen now is that by calling
>
>
>
> uhd_usrp_probe –args =”fpga=/path/to/image.lvbitx”
>
>
>
> I am able to flash USRP with RFNoC design. However, after I run gnuradio
> fosphor program it again roles
>
> back to previous bitstream. Which is logical based on your advices.
>
>
>
> However where can I specify path to default bitstream. In which file I
> should do it?
>
>
>
> Thx for comments related to 10Gbe. Then I think we will need to order also
> 10 Gbe interface.
>
>
>
> Kind Regards,
>
>
>
> Tarik Kazaz
>
>
>
> *From:* Derek Kozel [mailto:derek.ko...@ettus.com]
> *Sent:* dinsdag 30 januari 2018 11:50
> *To:* Tarik Kazaz
> *Cc:* Martin Braun; USRP-users@lists.ettus.com
>
> *Subject:* Re: [USRP-users] NI USRP / PCIe interface and RFNoC FPGA images
>
>
>
> Hi Tarik,
>
> Your steps are based on the misunderstanding of how the image loading
> occurs in each of these scenarios.
>
> When using PCIe the FPGA will always be reloaded from the host computer.
> Every program you run using the PCIe link needs the
> "fpga=/path/to/image.lvbitx" string added to the device arguments. The
> image loading is very fast compared to other methods. For example:
>
> uhd_usrp_probe --args="fpga=/path/to/image.lvbitx"
>
> When using JTAG an image is loaded into RAM on the FPGA. This will be
> overwritten if PCIe is used and forgotten (the RAM will clear) when the
> device is turned off. This is useful for rapid testing when using Ethernet
> connections since JTAG is faster than writing to flash, and for recovering
> when an image with an error has been written to the flash.
>
> When using the uhd_image_loader the image is written to flash and will be
> used the next time the device is turned off and on again. This is useful
> for loading a persistent image when using the Ethernet interfaces. PCIe
> will still load and use an image from the host every time.
>
> Can you please try the uhd_usrp_probe with the device arguments specifying
> the FPGA image to use?
>
> As for 2x10 GigE vs PCIe, No, they do not have the same throughput. The
> PCIe is equivalent to 1x 10 GigE. In order to get the full bandwidth of the
> X3x0, which is 2x 200 MS/s on receive, you would need to use both 10 GigE
> connections.
> https://kb.ettus.com/X300/X310#Choosing_a_Host_Interface
>
> Regards,
>
> Derek
>
>
>
> On Tue, Jan 30, 2018 at 10:01 AM, Tarik Kazaz via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hello Martin,
>
> I hope I am replying now correctly (I am using reply all to you and
> mailing list).
> I am still not able to flash RFNoC bit stream on FPGA. Here is what I am
> doing:
>
> 1. First step - Check status of device
>
> Call:   uhd_usrp_probe
> Output:   [INFO] [X300] Using LVBITX bitfile
> /home/cas-sdr/rfnoc/share/uhd/images/usrp_x310_fpga_XG.lvbitx...
>   ...
>   |   |   |   RFNoC blocks on this
> device:
>   |   |   |
>   |   |   |   * DmaFIFO_0
>   |   |   |   * Radio_0
>   |   |   |   * Radio_1
>   |   |   |   * DDC_0
>   |   |   |   * DDC_1
>   |   |   |   * DUC_0
>   |   |   |   * DUC_1
>
> 2. Second step: Load new FPGA image - usrp_x310_fpga_RFNOC_XG.lvbitx:
>
> Call:   uhd_image_loader
> --args="type=x300,RESOURCES=RIO0" --fpga-path="/xyz/xyz/rfnoc/sh
> are/uhd/images
>
>  /usrp_x310_fpga_RFNOC_XG.lvbitx"
>
> Output:
>   [INFO] [UHDlinux; GNU C++ version 4.8.4;
> Boost_105400; UHD_4.0.0.rfnoc-devel-409-gec9138eb]
>   [INFO] [NIRIO] rpc_client stopping...
>   [INFO] [NIRIO] rpc_client stopped.
>   [INFO] [NIRIO] rpc_client stopping...
>   [INFO] [NIRIO] rpc_client stopped.
>   [INFO] [NIRIO] rpc_client stopping...
>   [INFO] [NIRIO] rpc_client stopped.
>   [INFO] [NIRIO] rpc_client stopping...
>   [INFO] [NIRIO] rpc_client stopped.
>   Unit: USRP X310 (3114FC4, RIO0)
>   FPGA 

Re: [USRP-users] NI USRP / PCIe interface and RFNoC FPGA images

[Derek Kozel via USRP-users]

Hi Tarik,

Your steps are based on the misunderstanding of how the image loading
occurs in each of these scenarios.

When using PCIe the FPGA will always be reloaded from the host computer.
Every program you run using the PCIe link needs the
"fpga=/path/to/image.lvbitx" string added to the device arguments. The
image loading is very fast compared to other methods. For example:
uhd_usrp_probe --args="fpga=/path/to/image.lvbitx"

When using JTAG an image is loaded into RAM on the FPGA. This will be
overwritten if PCIe is used and forgotten (the RAM will clear) when the
device is turned off. This is useful for rapid testing when using Ethernet
connections since JTAG is faster than writing to flash, and for recovering
when an image with an error has been written to the flash.

When using the uhd_image_loader the image is written to flash and will be
used the next time the device is turned off and on again. This is useful
for loading a persistent image when using the Ethernet interfaces. PCIe
will still load and use an image from the host every time.

Can you please try the uhd_usrp_probe with the device arguments specifying
the FPGA image to use?


As for 2x10 GigE vs PCIe, No, they do not have the same throughput. The
PCIe is equivalent to 1x 10 GigE. In order to get the full bandwidth of the
X3x0, which is 2x 200 MS/s on receive, you would need to use both 10 GigE
connections.
https://kb.ettus.com/X300/X310#Choosing_a_Host_Interface

Regards,
Derek

On Tue, Jan 30, 2018 at 10:01 AM, Tarik Kazaz via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello Martin,
>
> I hope I am replying now correctly (I am using reply all to you and
> mailing list).
> I am still not able to flash RFNoC bit stream on FPGA. Here is what I am
> doing:
>
> 1. First step - Check status of device
>
> Call:   uhd_usrp_probe
> Output:   [INFO] [X300] Using LVBITX bitfile
> /home/cas-sdr/rfnoc/share/uhd/images/usrp_x310_fpga_XG.lvbitx...
>   ...
>   |   |   |   RFNoC blocks on this
> device:
>   |   |   |
>   |   |   |   * DmaFIFO_0
>   |   |   |   * Radio_0
>   |   |   |   * Radio_1
>   |   |   |   * DDC_0
>   |   |   |   * DDC_1
>   |   |   |   * DUC_0
>   |   |   |   * DUC_1
>
> 2. Second step: Load new FPGA image - usrp_x310_fpga_RFNOC_XG.lvbitx:
>
> Call:   uhd_image_loader
> --args="type=x300,RESOURCES=RIO0" --fpga-path="/xyz/xyz/rfnoc/sh
> are/uhd/images
>
>  /usrp_x310_fpga_RFNOC_XG.lvbitx"
>
> Output:
>   [INFO] [UHDlinux; GNU C++ version 4.8.4;
> Boost_105400; UHD_4.0.0.rfnoc-devel-409-gec9138eb]
>   [INFO] [NIRIO] rpc_client stopping...
>   [INFO] [NIRIO] rpc_client stopped.
>   [INFO] [NIRIO] rpc_client stopping...
>   [INFO] [NIRIO] rpc_client stopped.
>   [INFO] [NIRIO] rpc_client stopping...
>   [INFO] [NIRIO] rpc_client stopped.
>   [INFO] [NIRIO] rpc_client stopping...
>   [INFO] [NIRIO] rpc_client stopped.
>   Unit: USRP X310 (3114FC4, RIO0)
>   FPGA Image:
> /xyz/xyz/rfnoc/share/uhd/images/usrp_x310_fpga_RFNOC_XG.lvbitx
>   -- Loading XG FPGA image (this will take
> 5-10 minutes)...[INFO] [NIRIO] rpc_client stopping...
>   [INFO] [NIRIO] rpc_client stopped.
>
>   After few minutes I get:
>   successful.
>   Power-cycle the USRP X310 to use the new
> image.
>   [INFO] [NIRIO] rpc_client stopping...
>   [INFO] [NIRIO] rpc_client stopped.
>
> 3. Third step: power cycle USRP and PC
>
> Call:   sudo /usr/local/bin/niusrprio_pcie stop
>   Power cycle USRP
>   Power cycle PC
>
>
> 4. Forth step: power up USRP and PC, check status of USRP
>
>Call:  Power UP USRP
> Power UP PC
>uhd_usrp_probe
> Output:   [INFO] [X300] Using LVBITX bitfile
> /home/cas-sdr/rfnoc/share/uhd/images/usrp_x310_fpga_XG.lvbitx...
>   ...
>   |   |   |   RFNoC blocks on this
> device:
>   |   |   |
>   

Re: [USRP-users] Twin Rx LO Source

[Derek Kozel via USRP-users]

Hello Andy,

The LO source is for an external or internal RF source and is fed directly
to the mixers. You are looking for the set_clock_source call which will
allow you to set the USRP to use an external 10 MHz reference.

Regards,
Derek

On Thu, Jan 25, 2018 at 7:53 PM, Andrew Thommesen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
>
> I am using an Ettus X310 with a twin RX card. How do I configure this card
> to use an external 10MHz clock? In GNU Radio I have changed the LO source
> of the RFNoC radio block to external, but this results in strange behavior:
>
>
> If I inject a CW tone into the twin RF and observe the output on a GUI GUI
> Frequency sink I get the expected output when the LO source is internal.
> When I switch to external the tone is no longer visible but I get a small
> DC offset.
>
>
> Can anyone explain this? There is a 10dBm 10MHz sinusoid connected to the
> Ref In.
>
>
> Thanks,
>
>
> Andy
>
>
> Sent from Outlook 
>
> ___
> 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] TwinRX dead on arrival?

[Derek Kozel via USRP-users]

Hello Anon,

I can confirm that your issue is due to software and not a hardware issue.
The fix is released on the maint branch and will be out on the master
branch very shortly.
https://github.com/EttusResearch/uhd/commit/f76762c6e9cd7d7e308c589d57cb89
1eda45a4e8

Can you please apply the one character edit here and rerun your test?
Otherwise you should be able to pull the master branch update in the next
day or two to have the relevant fix commit. I apologize for the
inconvenience and time you've spent debugging.

Regards,
Derek

On Mon, Jan 15, 2018 at 11:14 PM, Nate Temple via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Anon,
>
> Can you try running these tests with a tagged release of UHD, such as
> "release_003_010_002_000" instead of the master branch? You may need to
> recompiled GNU Radio against this version of UHD. It is important to
> download and flash the 3.10.2.0 FPGA image before running the tests.
>
> If 3.10.2.0 shows the same results, please email supp...@ettus.com and we
> can start a RMA.
>
> Regards,
> Nate Temple
>
> On Mon, Jan 15, 2018 at 11:36 AM, Anon Lister 
> wrote:
>
>> Nate,
>>
>> Roger. I set gain to absolute 70dB with no change. Also plotted RX1
>> and RX2(twinrx_ubx_text2.grc). Antenna attached to RX1. Same deal.
>> (test_flowgraph2.png).
>>
>> Also swapped to different X300 chassis as a longshot, but no change.
>>
>> Looks pretty dead with your attached flowgraph too. (after editing to
>> disable the blocks for channel 3/4 since we only have 1 TwinRX)
>> (twinrx_front_panel.png)
>>
>> Same for uhd_fft See attached, also did same command with UBX for
>> comparison of spectrum. For the ubx comparison i modified the command
>> to reference the TX/RX antenna. (uhd_fft_*.png)
>>
>> Also attached uhd_usrp_probe incase that is of any use.
>>
>> Anything else to try, or should I contact Ettus directly for RMA?
>>
>> Thanks!.
>>
>> On Mon, Jan 15, 2018 at 1:32 PM, Nate Temple 
>> wrote:
>> > Hi Anon,
>> >
>> > The TwinRX will work fine with the Osmocom Source, however, there is
>> more functionality exposed via the UHD Source/Sinks, especially for the
>> TwinRX (LO Controls for example).
>> >
>> > Can you try using the GNU Radio application uhd_fft to test the TwinRX?
>> A command such as below should display your local WBFM.
>> >
>> > uhd_fft -f 100e6 -s 10e6 -g 60 -A RX1
>> >
>> > One important note with the TwinRX is the antenna names, “RX1” and
>> “RX2”. Also subdev specs need to be set to use multiple channels, “A:0 A:1”
>> for a single card. “A:0 A:1 B:0 B:1” for a pair of TwinRXs.
>> >
>> > Attached is a example flowgraph for a 4 channel configuration with a
>> X3xx over 10Gb + two TwinRXs. You can use this as a reference and disable
>> the blocks for channels 2-4 if you would like to only use a single channel.
>> >
>> >
>> > Regards,
>> > Nate Temple
>> >
>> >
>> >
>> >
>> >> On Jan 15, 2018, at 10:13 AM, Anon Lister via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>> >>
>> >> Hey all,
>> >>
>> >> We recently purchased an X300 with a pair of UBX boards and a TwinRX
>> >> board. The UBX works great, but the TwinRX is completely deaf. It acts
>> >> as if something in the RF path is broken. Command and control side
>> >> seem to work fine. I have attached two screenshots of the FM band with
>> >> both TwinRX and UBX, same flowgraph, same X300, same antenna cable.
>> >>
>> >> I tried:
>> >> swapping daughterboard slot on x300. no change
>> >> swapping RX port on TwinRX. no change
>> >> swapping out SMA-mcx cable on TwinRX. no change
>> >> tuning to different areas. get basically nothing anywhere except
>> >> slight changes in noise floor amplitude.
>> >>
>> >>
>> >> UHD:
>> >> UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
>> >> UHD_3.11.0.git-230-gfc8cd827
>> >> Only one daughterboard was in X300 at at time.
>> >>
>> >> Is there something special you have to do with the configuration of
>> >> the TwinRX(See attached flowgraph)? Or do we need to RMA this
>> >> daughterboard?
>> >>
>> >> 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
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] making the UHD

[Derek Kozel via USRP-users]

Hi Ale,

I've added back on the list. It's usually best to keep the list included so
you can get faster responses from a larger group of experienced people.

That example isn't installed into the default PATH like the core UHD
programs are. The binary can be found at (by default on Ubuntu)
/usr/local/lib/uhd/utils/query_gpsdo_sensors

I used the following command to search for the binary just to confirm the
location.
find /usr -name query_gpsdo_sensors

Regards,
Derek

On Jan 10, 2018 7:49 PM, "Mercado, Alejandra"  wrote:

Hi Derek,

Thanks for responding.

It must not have been compiled, since I can't run it ("command not found").

So, all those warnings are known and not to worry about... so they have
nothing to do with the failed test:

99% tests passed, 1 tests failed out of 212

Total Test time (real) = 140.04 sec

The following tests FAILED:
209 - qa_zeromq_pub (Failed)
Errors while running CTest
Makefile:149: recipe for target 'test' failed
make: *** [test] Error 8


What do I do abut the failed test, then?

Regards,
Ale


===
Dr. Alejandra Mercado
Associate Director
Electrical and Computer Engineering
Master's in Telecommunications Program
A.V. Williams Building
University of Maryland at College Park
College Park, MD 20742
===

On Wed, Jan 10, 2018 at 2:46 PM, Derek Kozel  wrote:

> Hello Ale,
>
> That left shift is intentional behavior. Here is the comment on that line
> of code.
> https://github.com/EttusResearch/uhd/blob/maint/host/include
> /uhd/utils/soft_register.hpp#L100
>
> When you say you "tried to run query_gpsdo_sensors, that one was not
> finalized" do you mean that it was not compiled? There should be an error
> in your build log then.
>
> Regards,
> Derek
>
> On Wed, Jan 10, 2018 at 7:08 PM, Mercado, Alejandra via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Follow-up to my previous post:
>> Hi again, folks,
>> When I followed instructions to make both the UHD and the GNURadio, I got
>> a slew of warnings. Later I ran the GnuRadio test and got one error:
>> 99% tests passed, 1 tests failed out of 212
>>
>> Total Test time (real) = 140.04 sec
>>
>> The following tests FAILED:
>> 209 - qa_zeromq_pub (Failed)
>> Errors while running CTest
>> Makefile:149: recipe for target 'test' failed
>> make: *** [test] Error 8
>>
>> Any suggestions?
>>
>> Ale
>>
>> ===
>> Dr. Alejandra Mercado
>> Associate Director
>> Electrical and Computer Engineering
>> Master's in Telecommunications Program
>> A.V. Williams Building
>> University of Maryland at College Park
>> College Park, MD 20742
>> ===
>>
>> On Wed, Jan 10, 2018 at 12:21 PM, Mercado, Alejandra > > wrote:
>>
>>> Hi folks,
>>>
>>> I'm worried about something; while maiking the UHD, it ran across
>>> something that looked like an error:
>>>
>>> [ 22%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/multi_usrp.cpp.o
>>> In file included from /home/ents622/workarea-uhd/uhd
>>> /host/lib/usrp/multi_usrp.cpp:29:0:
>>> /home/ents622/workarea-uhd/uhd/host/include/uhd/utils/soft_register.hpp:
>>> In instantiation of ‘data_t uhd::soft_reg_field::mask(uhd::soft_reg_field_t)
>>> [with data_t = short unsigned int; uhd::soft_reg_field_t = unsigned int]’:
>>> /home/ents622/workarea-uhd/uhd/host/include/uhd/utils/soft_register.hpp:191:69:
>>>  required from ‘void uhd::soft_register_t>> writable>::set(uhd::soft_reg_field_t, reg_data_t) [with reg_data_t =
>>> short unsigned int; bool readable = true; bool writable = true;
>>> uhd::soft_reg_field_t = unsigned int]’
>>> /home/ents622/workarea-uhd/uhd/host/include/uhd/utils/soft_register.hpp:256:12:
>>>  required from ‘void uhd::soft_register_t>> writable>::write(uhd::soft_reg_field_t, reg_data_t) [with reg_data_t =
>>> short unsigned int; bool readable = true; bool writable = true;
>>> uhd::soft_reg_field_t = unsigned int]’
>>> /home/ents622/workarea-uhd/uhd/host/lib/usrp/multi_usrp.cpp:1614:119:
>>>  required from here
>>> /home/ents622/workarea-uhd/uhd/host/include/uhd/utils/soft_register.hpp:106:27:
>>> warning: left shift of negative value [-Wshift-negative-value]
>>>  return (0-ONE)<>> ~~~^~
>>> [ 22%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/subdev_spec.cpp.o
>>>
>>> Should I be worried about this? Is some part not working properly?
>>>
>>> The reason I ask is because the last time I installed this on another
>>> computer, when I tried to run query_gpsdo_sensors, that one was not
>>> finalized. Admittedly, that one was on Ubuntu 16.04, and this last one is
>>> on Ubuntu 17.04, so the dependencies command was different.
>>>
>>> Regards,
>>> Ale
>>> ===
>>> Dr. Alejandra Mercado
>>> Associate Director
>>> Electrical and Computer Engineering
>>> Master's in 

Re: [USRP-users] making the UHD

[Derek Kozel via USRP-users]

Hello Ale,

That left shift is intentional behavior. Here is the comment on that line
of code.
https://github.com/EttusResearch/uhd/blob/maint/host/include/uhd/utils/soft_register.hpp#L100

When you say you "tried to run query_gpsdo_sensors, that one was not
finalized" do you mean that it was not compiled? There should be an error
in your build log then.

Regards,
Derek

On Wed, Jan 10, 2018 at 7:08 PM, Mercado, Alejandra via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Follow-up to my previous post:
> Hi again, folks,
> When I followed instructions to make both the UHD and the GNURadio, I got
> a slew of warnings. Later I ran the GnuRadio test and got one error:
> 99% tests passed, 1 tests failed out of 212
>
> Total Test time (real) = 140.04 sec
>
> The following tests FAILED:
> 209 - qa_zeromq_pub (Failed)
> Errors while running CTest
> Makefile:149: recipe for target 'test' failed
> make: *** [test] Error 8
>
> Any suggestions?
>
> Ale
>
> ===
> Dr. Alejandra Mercado
> Associate Director
> Electrical and Computer Engineering
> Master's in Telecommunications Program
> A.V. Williams Building
> University of Maryland at College Park
> College Park, MD 20742
> ===
>
> On Wed, Jan 10, 2018 at 12:21 PM, Mercado, Alejandra 
> wrote:
>
>> Hi folks,
>>
>> I'm worried about something; while maiking the UHD, it ran across
>> something that looked like an error:
>>
>> [ 22%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/multi_usrp.cpp.o
>> In file included from /home/ents622/workarea-uhd/uhd
>> /host/lib/usrp/multi_usrp.cpp:29:0:
>> /home/ents622/workarea-uhd/uhd/host/include/uhd/utils/soft_register.hpp:
>> In instantiation of ‘data_t uhd::soft_reg_field::mask(uhd::soft_reg_field_t)
>> [with data_t = short unsigned int; uhd::soft_reg_field_t = unsigned int]’:
>> /home/ents622/workarea-uhd/uhd/host/include/uhd/utils/soft_register.hpp:191:69:
>>  required from ‘void uhd::soft_register_t> writable>::set(uhd::soft_reg_field_t, reg_data_t) [with reg_data_t =
>> short unsigned int; bool readable = true; bool writable = true;
>> uhd::soft_reg_field_t = unsigned int]’
>> /home/ents622/workarea-uhd/uhd/host/include/uhd/utils/soft_register.hpp:256:12:
>>  required from ‘void uhd::soft_register_t> writable>::write(uhd::soft_reg_field_t, reg_data_t) [with reg_data_t =
>> short unsigned int; bool readable = true; bool writable = true;
>> uhd::soft_reg_field_t = unsigned int]’
>> /home/ents622/workarea-uhd/uhd/host/lib/usrp/multi_usrp.cpp:1614:119:
>>  required from here
>> /home/ents622/workarea-uhd/uhd/host/include/uhd/utils/soft_register.hpp:106:27:
>> warning: left shift of negative value [-Wshift-negative-value]
>>  return (0-ONE)<> ~~~^~
>> [ 22%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/subdev_spec.cpp.o
>>
>> Should I be worried about this? Is some part not working properly?
>>
>> The reason I ask is because the last time I installed this on another
>> computer, when I tried to run query_gpsdo_sensors, that one was not
>> finalized. Admittedly, that one was on Ubuntu 16.04, and this last one is
>> on Ubuntu 17.04, so the dependencies command was different.
>>
>> Regards,
>> Ale
>> ===
>> Dr. Alejandra Mercado
>> Associate Director
>> Electrical and Computer Engineering
>> Master's in Telecommunications Program
>> A.V. Williams Building
>> University of Maryland at College Park
>> College Park, MD 20742
>> ===
>>
>
>
> ___
> 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] Independent use of ethernet ports on Ettus x310?

[Derek Kozel via USRP-users]

Hello Chad,

You'll need a program which can receive from both channels at once. The
claiming means that two processes cannot access the same USRP at the same
time. The rx_multi_samples shows receiving two sample streams on the same
frequency and the same rate. You'll likely need to write your own program
which implements the behavior you want. It is absolutely possible to start
and stop the two receive channels when you want, separately from each
other. No example shows this, but it is very easy and particularly in GNU
Radio it is easy to put together in just a few minutes once you're used to
the environment.

It is possible for the X300/X310 to have both SFP+ ports as 1 gigabit
Ethernet, but this hasn't been requested often and pre-built images aren't
available. Most of the time moving to 10 Gigabit Ethernet is an easier and
better option. Far higher sample rates, and thus bandwidths, are possible.
Thank you for pointing out those two places where it is described. We will
talk internally about how best to describe that functionality.

The USRP Sink block can be used to transmit, I see you already have a
working flowgraph and an understanding of the subdevice specifications.

Since you're using GNU Radio, all you need to do is put down one USRP
source and use the subdevice specification to select the A or B side of the
X310, to choose the SBX to receive from. Selecting when to save the samples
to disk can be as simple as a push button, a small amount of python, and a
file sink. There was an example of this on this or the GNU Radio list last
year, I'll try and find it but the logic was pretty simple. The copy block
can be used to selectively throw away or pass through samples. This is
followed by the file sink and have the filename be created dynamically by
putting an python expression in the filename field. You may be best served
by moving to a direct Python program rather than just GNU Radio Companion
since it will give you more control and flexibility.


On Fri, Nov 17, 2017 at 5:28 PM, Chad Spooner via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Neel:
>
> But what does Ettus mean by "Dual 1 Gigabit Ethernet" on those links? (Not
> "Dual 10 Gigabit Ethernet".)
> See attached screen shots from the Ettus.com links I sent previously.
>
> I am currently using the UHD Source block with the SBX and a UHD Sink
> block with the WBX in the
> working flowgraph. What I want to do is occasionally obtain complex
> samples from the SBX and process
> them outside of GRC. I can think of two ways to get data from the SBX to a
> file. The first is through
> uhd_rx_cfile and the second is through the use of a File Sink in the
> flowgraph. But while the flowgraph
> is running, I can't successfully call uhd_rx_cfile. If I use the File
> Sink, I'll have to be able to grab samples
> at irregular intervals outside of GRC, and I'm not sure if that will cause
> a problem for the function
> that is continuously writing to the file. I'll try.
>
> Plan B could be to just use a second USRP.
>
> Thanks,
>
> C
>
> On Fri, 2017-11-17 at 09:00 -0800, Neel Pandeya wrote:
>
> Hello Chad:
>
> By "dual 10 Gigabit Ethernet", we mean that both Port 0 and Port 1 are
> being used with 10 Gigabit Ethernet links simultaneously. Both links must
> connect to the same host computer; you cannot have one link connected to
> system A, and the other link connected to system B.
>
> In GNU Radio, you can receive from your SBX by using a USRP UHD Source
> block, and you can transmit with your WBX by using a USRP UHD Sink block.
>
> --Neel Pandeya
>
>
>
> On 17 November 2017 at 08:33, Chad Spooner  wrote:
>
> Neel:
>
> Thanks very much for the helpful reply.
>
> MY x310 has both a SBX and a WBX installed. The working configuration I
> mentioned
> has the WBX transmitting and the SBX receiving simultaneously. But how do
> I get
> data chunks from the SBX while the flowgraph that implements this
> simultaneous
> operation is running? I suppose I can use a File Sink, but I'm not sure
> how to read
> segments of the growing file while it is constantly being written to by
> the SDR/host.
>
> I think something that confuses me about the Ettus online documentation is
> the
> use of the phrases "Dual 1 Gigabit Ethernet" and "Dual 10 Gigabit
> Ethernet." These
> both appear, for example, on the following links:
>
> https://www.ettus.com/product/details/X310-KIT
> https://kb.ettus.com/X300/X310
>
> I thought I understood the "Dual 10 Gigabit Ethernet" from further
> reading, and that
> understanding is consistent with what you say below. But then what does
> Ettus mean
> by "Dual 1 Gigabit Ethernet"?
>
> Thanks again,
>
> C
>
> On Thu, 2017-11-16 at 17:08 -0800, Neel Pandeya wrote:
>
> Hello Chad:
>
> If you are using 1 Gigabit Ethernet, then only one of two SFP ports in the
> rear of the X300/X310 can be used. If you have 10 Gigabit Ethernet, then
> the second SFP port can be used. Please see the link below. The SFP ports
> are configured 

Re: [USRP-users] spectrum analyzer USRP N210

[Derek Kozel via USRP-users]

I've added back on the mailing list, just include usrp-users@lists.ettus.com
as a to: address. If you use reply-all in the future it will keep the list
up to date.

The "n" value needs to be adjusted now that the step size is 20% smaller.

On Thu, Nov 16, 2017 at 9:34 AM, Ivan Zahartchuk 
wrote:

> Yes, thanks to the spectrum is much better. the only negative is the
> central frequencies they are formed in the USRP itself. This can be seen
> on the graph in the time domain. Unfortunately I do not know how to add
> more people to this discussion. If you can do this I will be very grateful
>
> 2017-11-16 11:26 GMT+02:00 Derek Kozel :
>
>> Your spectrum looks far better, good. Are you happy with it?
>>
>> The large noiseless signals between each step look too identical and
>> clean. I recommend taking the samples from a single window and examining
>> the FFT at full bandwidth, at 80% bandwidth, and after your fftshift and
>> seeing if you can identify when that occurs.
>>
>> I recommend adding the usrp-users mailing list back onto this thread and
>> seeing anyone else can give advice on further improvements.
>>
>> On Thu, Nov 16, 2017 at 8:52 AM, Ivan Zahartchuk 
>> wrote:
>>
>>> Hi,
>>> Derek
>>> I did as you said. Here's what I got:
>>>
>>> n = int(math.ceil((config.stop_freq - config.start_freq) / config.band))
>>> fft1 = np.array([], dtype=np.complex64)
>>> fft2 = np.array([], dtype=np.complex64)
>>> for i in range(0, n):
>>> usrp.set_rx_freq(lib.types.tune_request(config.start_freq + config.band 
>>> / 2 + (config.band*0.8) * i), 0)
>>> streamer.recv(recv_buff, config.metadata)
>>> if config.metadata.error_code == 
>>> lib.types.rx_metadata_error_code.timeout:
>>> print ("ERRROR")
>>> elif config.metadata.error_code == 
>>> lib.types.rx_metadata_error_code.late:
>>> print ("ERR1")
>>> elif config.metadata.error_code == 
>>> lib.types.rx_metadata_error_code.broken_chain:
>>> print ("ERR2")
>>> elif config.metadata.error_code == 
>>> lib.types.rx_metadata_error_code.overflow:
>>> print ("ERR3")
>>> elif config.metadata.error_code == 
>>> lib.types.rx_metadata_error_code.alignment:
>>> print ("ERR4")
>>> elif config.metadata.error_code == 
>>> lib.types.rx_metadata_error_code.bad_packet:
>>> print ("ERR5")
>>>   # np.array(recv_buff,dtype=np.float16)
>>> prom1 = np.fft.fft(recv_buff)
>>> prom1[0:5]=0
>>> prom1[num_samps-5:num_samps]=0
>>> prom1=np.fft.fftshift(prom1)
>>> prom1= 
>>> prom1[math.ceil(num_samps*0.1):num_samps-math.ceil(num_samps*0.1)]
>>>
>>> #prom1= np.fft.fftshift(prom1)*w
>>> fft1 = np.hstack((fft1,prom1))
>>> #print(fft1.shape)
>>> stream_cmd.time_spec = lib.types.time_spec(0)
>>> streamer.issue_stream_cmd(stream_cmd)
>>>
>>>
>>> 2017-11-15 15:56 GMT+02:00 Derek Kozel :
>>>
 Hello Ivan,

 The rule of thumb is that the digital filters are flat over 80% of the
 passband. A good start would be to exclude the first and last 10% of each
 FFT and reduce your frequency step size to 80% of the sample rate. This
 will flatten your spectrum considerably.

 USRPs have a calibration routine for many of the daughterboards, which
 one are you using? Some DC offset spur is usually inevitable, but there are
 correction algorithms built into the USRP's FPGA. The tool will calculate
 values for these APIs but also they can be set manually.
 http://files.ettus.com/manual/page_calibration.html
 http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usr
 p.html#a263ab7f0364c03e8a6e330c546769e4f
 http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usr
 p.html#a586c52db545664cb2caf830ac90c051e

 Regards,
 Derek



 On Wed, Nov 15, 2017 at 1:26 PM, Ivan Zahartchuk via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Hello. I'm trying to make a broadband spectrum analyzer. I
> encountered some difficulties with the USRP N210 board. At certain
> frequencies, I get such a picture. And there are problems with the
> presence of central frequencies. Advise me how to remove these
> shortcomings.
> My code:
>
> n = int(math.ceil((config.stop_freq - config.start_freq) / config.band))
> fft1 = np.array([], dtype=np.complex64)
> for i in range(0, n):
> usrp.set_rx_freq(lib.types.tune_request(config.start_freq + 
> config.band / 2 + config.band * i), 0)
> streamer.recv(recv_buff, config.metadata)
> if config.metadata.error_code == 
> lib.types.rx_metadata_error_code.timeout:
> print ("ERRROR")
> elif config.metadata.error_code == 
> lib.types.rx_metadata_error_code.late:
> print ("ERR1")
> elif config.metadata.error_code == 
> lib.types.rx_metadata_error_code.broken_chain:
> 

Re: [USRP-users] Sync two USRP devices to sense 100MHz of spectrum

[Derek Kozel via USRP-users]

Hello Wahhab,

I do not know about using the MIMO cable between a USRP2 and a N2x0, the
USRP2 became end of life before I started at Ettus. I think it would work,
but cannot test it myself. Others at Ettus may know the answer.

You will need at least two 1 Gigabit connections to your host computer. The
other option would be a Gigabit Switch with a 10 Gigabit Ethernet
connection to the host, but it is usually less expensive and easier to get
an extra Ethernet Card for your host computer. It is simply not possible to
carry 100 MS/s, even at 8 bits, over a 1 GigE connection. (100
Megasamples/second * (2 * 8) bits / complex sample = 1.6 Gigabits per
second).

Yes, you can use two B210s to monitor 100 MHz of bandwidth. USB 3 can carry
over 50 MS/s in 16 bit samples in theory but some computers cannot handle
it. The benchmark_rate program included with the USRP driver is good tool
for testing if your computer can handle the data rate. In order to
frequency and time synchronize them you would have to supply 10 MHz and 1
PPS references from an external source. Ettus sells the Octoclock which can
synchronize up to 8 devices. It comes with or without a GPS reference
inside to supply the signals. There are other hardware options available if
you look around, the requirements for the reference signals are on the
knowledge base. There are app notes about doing synchronization as well on
there.
https://kb.ettus.com/B200/B210/B200mini/B205mini#Timing_Reference_Input

Regards,
Derek

On Thu, Nov 9, 2017 at 2:46 PM, Wahhab Albazrqaoe  wrote:

> Thank you Derek for the comments.
> I just want to clarify this point about connecting two USRP devices;
> first, it seems to be fine to connect a USRPN200 with USRP2 (via a MIMO
> cable), right?
> Second, by connecting two devices via MIMO cable, I need to connect their
> GigaBit Ethenet cables to a GigaBit switch, which feeds the host, right? Is
> there an example (i.e. code) on how to do such configuration? What
> parameters to send to each device?
> I also don't have an external source, like 10MHz and 1 PPS references; my
> plan is just to use MIMO cable; it seems from your reply it is doable.
>
> Another question, I have two USRPB210 devices, is it possible to use these
> devices instead of USRPN/2? Is there an extra hardware/software that we
> need to use with USRPB210 to get the two devices sync in time and freq?
>
> Best,
> Wahhab
>
> On Thu, Nov 9, 2017 at 9:34 AM, Derek Kozel  wrote:
>
>> Hello Wahhab Albazrqaoe,
>>
>> It is certainly possible to configure each USRP to be tuned to a
>> different frequency and to be synchronized closely in time. A 1 Gigabit
>> Ethernet connection can carry approximately 25 MS/s of 16 bit samples and
>> 50 MS/s of 8 bit samples. We do not support sending 4 bit samples so it is
>> not possible to carry 100 MHz worth of spectrum over the 1 GigE cable of an
>> N2x0 or USRP2. You should operate in Dual Ethernet mode using the MIMO
>> cable to share clock and time references. If you already have external 10
>> MHz and 1 PPS references that you can send to both then the MIMO cable
>> gives you little benefit in this situation.
>> http://files.ettus.com/manual/page_usrp2.html#usrp2_mimocable
>> 
>>
>> You will be limited to 8 bit samples so you should check that you
>> application will be ok with that limitation. Newer USRPs use faster
>> connections such as USB 3 and 10 Gigabit Ethernet to pass higher resolution
>> samples at higher rates.
>>
>> Regards,
>> Derek
>>
>>
>> On Thu, Nov 9, 2017 at 2:07 PM, Wahhab Albazrqaoe via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Dear All,
>>> We would like to sense (i.e. sample) 100 MHz of 2.4GHz spectrum. My idea
>>> is to connect 2 USRPs (USRPN200 and USRP2) via a MIMO cable (available at
>>> ettus.com
>>> ).
>>> Then, we configure each USRP separately to monitor 50MHz of bandwidth (8bit
>>> per sample).
>>>
>>> My question:
>>> 1- is it possible to configure each USRP separately to monitor different
>>> spectrum segment? Example, USRPN200 senses 2400MHz to 2450MHz and USRP2
>>> sense 2450MHz up to 2500MHz.
>>> If this is possible, is it possible to get the samples over one GigaBit
>>> Ethernet cable (i.e. connected to one USRP device)? Or we may need to take
>>> a cable out of each device and connect them to a switch, which feeds the
>>> host ?
>>>
>>> 2- is it possible to connect USRPN200 with USRP2 via a MIMO cable? Or we
>>> need to use two USRP devices 

Re: [USRP-users] feedback from a USRP message

[Derek Kozel via USRP-users]

The error checking of the parameter range will happen inside of UHD rather
than in the GNU Radio wrapper. The existing check is only for the type of
the parameter, in the gain case a numerical value is supplied so it passes
the check.

The first command will result in a tune to 2.4 GHz.
The second command will result in maximum gain as UHD will coerce the value
by limiting it to the valid range. The value actually set can be read using
the API, but isn't readily available in GRC, you'd have to use a function
probe or custom python block to call it.

The third case should be caught and logged as an error, it looks like a
check is missing from this `if` statement. There might be a good reason,
but that's something I'll check on. In the meantime you can try adding a
GR_LOG_ALERT or ERROR statement to this block.
https://github.com/gnuradio/gnuradio/blob/a0adcd3347c7ffd6ef3c42ce7705a23978774d3b/gr-uhd/lib/usrp_block_impl.cc#L558

Derek

On Mon, Oct 30, 2017 at 4:18 PM, Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> Thanks Derek, that last link helped get me in the right direction.  I set
> both to debug level (to try to get as much output as I can.  What bothers
> me is that I get this message for sending what I feel like is a valid
> command:
> gr::debug :DEBUG: gr uhd usrp source0 - Processing command message ((chan
> . 0) (freq . 24))
>
> but I get the same message for what should be a bad command (and i feel
> like should probably print that out):
> gr::debug :DEBUG: gr uhd usrp source0 - Processing command message ((chan
> . 0) (gain . 24))
>
> or even a total made up key:
> gr::debug :DEBUG: gr uhd usrp source0 - Processing command message ((chan
> . 0) (badData . 24))
>
> Am I giving too much credit to how the USRP error checks messages?
>
>
>
>
> On 10/30/2017 11:30 AM, Derek Kozel wrote:
>
> Hi Jason,
>
> The command message handling in the USRP source in GNU Radio is a bit
> interesting. The command may contain many pairs of key->value, most of
> which end up in a call to their own handler. There is a debug message
> printed for each of these handlers if you have GNU Radio debug messages
> enabled.
>
> List of supported keys
> https://github.com/gnuradio/gnuradio/blob/a0adcd3347c7ffd6ef3c42ce7705a2
> 3978774d3b/gr-uhd/lib/usrp_block_impl.cc#L30
>
> There is also error reporting if the command type isn't correct.
> https://github.com/gnuradio/gnuradio/blob/a0adcd3347c7ffd6ef3c42ce7705a2
> 3978774d3b/gr-uhd/lib/usrp_block_impl.cc#L538
>
> If you aren't seeing the debug messages then try changing your GNU Radio
> logging settings.
> https://gnuradio.org/doc/doxygen/page_logger.html
>
> Regards,
> Derek
>
> On Mon, Oct 30, 2017 at 2:54 PM, Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Is there anyway to get feedback from a sent message command to a USRP
>> source in GR?  I was sending some commands and was *pretty* sure I was
>> doing it right, but to know for sure I sent a bogus command, and it didn't
>> complain (I expected to see something on the terminal).  Is there anyway to
>> turn on some sort of print-out to see that it accepted the commands I am
>> sending (like changing freqs)?  Or at the very least see when a bad command
>> was sent?
>>
>> ___
>> 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] USRPB210 master clock rate and RF front end bandwidth

[Derek Kozel via USRP-users]

Hi Wahhab,

It sounds like you are expecting a configuration which is not possible.

With an ADC sampling rate of 2 MS/s complex your application will receive
valid information about 2 MHz of bandwidth. Setting the analog bandwidth to
2 MHz or 56 MHz will not change this. In order to receive information about
all 56 MHz of bandwidth the ADC rate must also be at least 56 MS/s.

A good way of checking the configuration would be to visualize the
streaming sample data. There are many applications which will read the IQ
data file produced by your above command and display an FFT. GNU Radio is
one of the most common ones, but Matlab/Octave works too as does
Inspectrum, SDR#, baudline, and others.


As a final note, it is generally preferable to use a high master_clock_rate
and then use the USRP's FPGA to decimate to a lower rate. This gives you
the benefit of oversampling and faster responsiveness as most of the
digital logic and the transceiver run at the master clock rate.

Regards,
Derek

On Mon, Oct 30, 2017 at 1:20 PM, Wahhab Albazrqaoe via USRP-users <
usrp-users@lists.ettus.com> wrote:

> ​​I have USRPB210 and would like to set the bandwidth of the RF front to a
> high value, like 56MHz or 61.44MHz (which I think the max value supported
> by B210). At the same time, I would like to set the sampling rate of ADC to
> 2MHz. I used the following cmd to do so:
> ./rx_sample_to_file --args master_clock_rate 2MHz --bw=56MHz --freq=2410e6
>
> when I run the program, I got a message says that
> the sampling rate is 2. MHz
> Actual Rx bandwidth is 56MHz
>
> These messages say show the configuration of USRPB210. However, I think
> this configuration is not real. How do I check it?
> I have a program (call it P) that monitors Bluetooth packets and there are
> two cases to check:
> Case1: --args master_clock_rate 2MHz --bw=2MHz, here we expect P to get j
> Bluetooth packets.
> Case2: --args master_clock_rate 2MHz --bw=56MHz, here we expect P to get
> (56/2=28) x j Bluetooth packets. That is, the number of packets is (28
> times j) as P monitors more Bluetooth channels.
>
> In reality, P got only j packet in Case2. This confirms that the RF front
> end (or something else in USRPB210) is not configured correctly as 56MHz.
>
> I did another check on USRPB210 to confirm. In particular, I used the
> following settings (let's call it Case3):  --args master_clock_rate 56MHz
> --bw=56MHz. In this case, P got (28 times j) Bluetooth packets, which
> confirms my checking procedure above.
>
> I appreciate if anyone could help me to configure USRPB210 just like Case2
> correctly.
>
> Wahhab Albaz​
>
>
> ___
> 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] feedback from a USRP message

[Derek Kozel via USRP-users]

Hi Jason,

The command message handling in the USRP source in GNU Radio is a bit
interesting. The command may contain many pairs of key->value, most of
which end up in a call to their own handler. There is a debug message
printed for each of these handlers if you have GNU Radio debug messages
enabled.

List of supported keys
https://github.com/gnuradio/gnuradio/blob/a0adcd3347c7ffd6ef3c42ce7705a23978774d3b/gr-uhd/lib/usrp_block_impl.cc#L30

There is also error reporting if the command type isn't correct.
https://github.com/gnuradio/gnuradio/blob/a0adcd3347c7ffd6ef3c42ce7705a23978774d3b/gr-uhd/lib/usrp_block_impl.cc#L538

If you aren't seeing the debug messages then try changing your GNU Radio
logging settings.
https://gnuradio.org/doc/doxygen/page_logger.html

Regards,
Derek

On Mon, Oct 30, 2017 at 2:54 PM, Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Is there anyway to get feedback from a sent message command to a USRP
> source in GR?  I was sending some commands and was *pretty* sure I was
> doing it right, but to know for sure I sent a bogus command, and it didn't
> complain (I expected to see something on the terminal).  Is there anyway to
> turn on some sort of print-out to see that it accepted the commands I am
> sending (like changing freqs)?  Or at the very least see when a bad command
> was sent?
>
> ___
> 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] Advise on how to modifying HDL design E310 to add custom blocks

[Derek Kozel via USRP-users]

Hello Brais,

Sorry for the long delay. Yes, the B210 has a Spartan 6 which is not
supported by Vivado so the design uses ISE. This, and the smaller size of
the B210's FPGA, is why RFNoC support has not been added to it. All third
generation USRPs support RFNoC and so will all planned future USRPs.

I hope your project is going well and that it is a success.

Regards,
Derek

On Tue, Oct 3, 2017 at 6:22 PM, Brais Ares  wrote:

> Thank you Derek,
>
> I was playing around with E300 design, but we actually need to use B2X0
> devices, apparently not supported by RFNoC. Also we need to implement some
> complex decimation and filtering so that FIR block will not be enough.
>
> I guess, if I'm not mistaken, our only choice is to use Xilinx ISE to
> modify the hdl design.
>
> Regards,
> Brais.
>
>
>
> 2017-10-03 12:45 GMT+02:00 Derek Kozel :
>
>> Hello Brais,
>>
>> The HDL design does have a top block and is composed of usefully divided
>> sub blocks. It is not however designed using the graphical Vivado workflow,
>> but a source based one. Here is the top block:
>> https://github.com/EttusResearch/fpga/blob/maint/usrp3/top/e300/e310.v
>>
>> Your application however sounds exactly like what the RFNoC architecture
>> was designed for. This architecture, which the E310 implements, allows you
>> to add in a self contained block of functional logic wrapped by an
>> interface supplied by Ettus. I recommend reading this application note and
>> possibly watching this video which introduces the architecture and leads
>> through the creation of a sample RFNoC block.
>>
>> https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>> https://www.youtube.com/watch?v=j-EfyPVpaJ8
>>
>> If you only want to add a filter or two there is already an FIR block
>> which you could either directly make use of or make hopefully minor
>> modifications to meet your needs.
>> https://github.com/EttusResearch/fpga/blob/6996ed662e5ae170e
>> 60ab8cb6de54c362cecf8d2/usrp3/lib/rfnoc/noc_block_fir_filter.v#L141
>>
>> Regards,
>> Derek
>>
>>
>> On Thu, Sep 21, 2017 at 4:48 PM, Brais Ares via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello,
>>>
>>> We want to add some blocks to HDL design in E310 device. We followed the
>>> instructions to build Vivado project and it worked okay.
>>>
>>> Thing is the built design when opened in Vivado looks this way
>>>  ...
>>> where design sources hierarchy is kind of complex. I was expecting a top
>>> module or at least not that much sources.
>>>
>>> Is there no way to see the design as a block design (like in a typical
>>> Vivado workflow)?
>>>
>>> Adding just a few filters to this design implies reverse-engineering
>>> what is going on in most of these source files...
>>>
>>> ​Any advice in how to proceed/start is appreciated.
>>> Regards,
>>> Brais.​
>>>
>>>
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
>
> --
>
> [image: logo_170x100px.png] 
>
> Brais Ares Fernández
> Investigador - Desarrollador | Área de Comunicaciones Avanzadas
> Researcher - Developer | Advanced Communications Department
>
> Ph. (+34) 986 120 430 <+34%20986%2012%2004%2030>  Ext. 3019
> ba...@gradiant.org  |  www.gradiant.org
>
> [image: Iconos Redes Sociales GRD Firma email-01]
>   [image: Iconos Redes Sociales
> GRD Firma email-02]   [image: Iconos Redes
> Sociales GRD Firma email-03]
>   [image: Iconos Redes
> Sociales GRD Firma email-04]
> 
> Take care of the environment. Try not to print this email.
> The information contained in this email message may be confidential
> information, and may also be the subject of legal professional privilege.
> If you are not the intended recipient, any use, interference with,
> disclosure or copying of this material is unauthorized and prohibited.
> Please inform us immediately and destroy the email. Thank you for your
> cooperation.
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Still having problems receiving multiple channels

[Derek Kozel via USRP-users]

Hi Janos,

What daughtercards are you using? Can you include the console output of
your program when it runs? It looks like you have useful log messages.

Thanks,
Derek

On Tue, Oct 17, 2017 at 11:32 AM, Janos Buttgereit via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello everybody,
>
> I wrote to the mailing list some month ago as I had problems setting up a
> multi_usrp from four USRP N210 with the help of the C++ API. As there are
> other projects with higher priority, I’m just working on the USRP-based
> stuff from time to time, that explains why there is a problem unsolved for
> months now. In the end some specifications changed, so I dropped the N210
> and I’m now working with a pair of X300 devices.
>
> The problem I still have after having solved a lot of other things with
> your help, is that there’s always only valid data from the first channel.
> To make sure that there is no bug in my fairly big code, I created a simple
> command line application, that just records four channels to four .bin
> files. These files are then loaded in gnu octave In this scenario, both
> X300 devices are clocked and time synced by an external OctoClock and fed
> with the same sine-wave, generated by a Signal Generator and split by a
> power splitter.
>
> I pasted my code and a plot of what the received data looks like here:
> https://gist.github.com/JanosGit/af51ae66c3a5c8a90119ec5f98e01162
>
> By the way, a modified version of the rx_multi_samples example which I
> modified to output the samples to a file instead of dropping them showed
> the exactly same result.
>
> For your Information: I’m working on a fresh Ubuntu installation with the
> X300 devices connected over SFP Cables to a dual 10GBit Ethernet PCIe Card.
> Receiving valid data on all four channels works with the same hardware but
> a slightly older Ubuntu installation on a second computer when using gnu
> radio (never change a running system), so I don’t think there is any
> hardware defect. I just need to up- or downgrade the FPGA Image when
> switching between both systems. While executing the application linked
> above, all four green LEDs underneath the RX2 Ports are lit.
>
> I’m really looking forward to finding a solution with your help!
>
> Regards
> Janos Buttgereit
>
> ___
> 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