Re: [USRP-users] How to Compile rx_samples_to_file and Generate an Executable

[Derek Kozel via USRP-users]

Hi Altug and Jacob,

Yes, the most recent Visual Studio we are actively supporting is 2015. We
will support 2017 with an upcoming release but as you note Jacob, Boost and
other dependencies are still catching up themselves.

Jacob, Boost 1.64 is not officially supported but great to hear it is
working. We'll be checking compatibility with it as well.

Regards,
Derek

On Thu, Jul 6, 2017 at 4:01 PM, Jacob Knoles  wrote:

> Altug,
>
> Certainly cannot skip boost as UHD requires it. I have tried doing the
> compilation using VS 2017 and could not get it to work, I believe that the
> Ettus team will is working on 2017 support but as of right now, to my
> knowledge, you will need to use VS 2015. As for boost, I am using 1.64.0
> and it works just fine.
>
> -
> Jacob Knoles
>
>
> On Thu, Jul 6, 2017 at 5:49 AM, altuğ kaya via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> First of all, thank you Derek.
>>
>> According to some forums on the net Visual Studio 2017 is not supported
>> by Boost. Should I close my ears and download 1.64.0, or should I just skip
>> boost?
>>
>> I am looking forward to your reply,
>> Altug
>>
>> On Thu, Jul 6, 2017 at 1:18 PM, Derek Kozel 
>> wrote:
>>
>>> Hello Altug,
>>>
>>> We have a guide for building UHD on Windows in the Knowledge Base. It
>>> includes building and installing the library as well as examples.
>>> https://kb.ettus.com/Building_and_Installing_the_USRP_Open_S
>>> ource_Toolchain_(UHD_and_GNU_Radio)_on_Windows
>>>
>>> Regards,
>>> Derek
>>>
>>> On Thu, Jul 6, 2017 at 11:23 AM, altuğ kaya via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hello everyone,

 I downloaded the uhd-master folder (https://github.com/EttusResea
 rch/uhd/tree/master) and I would like to edit one of the example,
 called rx_samples_to_file. However when I try to compile it by using cygwin
 on a windows machine, it cannot find the necessary libraries, such as
 tune_request, etc.

 How can I generate an executable from rx_samples_to_file.cpp?

 Sincerely,
 Altug

 ___
 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 N-series loading FPGA

[Derek Kozel via USRP-users]

Hello Daniel,

No, the storage is non-volatile. The script only needs to be run when
updating the FPGA.

Regards,
Derek

On Thu, Jul 6, 2017 at 9:40 PM, Cho, Daniel J (332C) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello –
>
>
>
> In order to load a custom FPGA, you run the python script “uhd_image_loader
> --args="type=usrp2,addr=" --fw-path=""
> --fpga-path=""” which is then automatically loaded at runtime.
> Is that on-board storage volatile?  Will I have to run this python script
> every time I reboot the USRP N-series for custom 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

[USRP-users] 3.9.7 LTS Release Candidate 1 Announcement

[Derek Kozel via USRP-users]

Hello all,

The release candidate of UHD version 3.9.7 has been tagged and is available
for testing. This is an update to the Long Term Support series and is
planned to be released next Monday, the 17th.

The tag for this release candidate:
https://github.com/EttusResearch/uhd/releases/tag/003_009_007_rc1

There have been 26 commits since the last release which can be viewed here:
https://github.com/EttusResearch/uhd/compare/release_003_009_006...003_009_007_rc1

## 003.009.007

* multi_usrp: Fixed get_normalized_tx_gain.
* E300: Fix for streamer recreation issue
* X300: Fix for network discovery, will now return early when correct
serial is found.
* CBX: Fixed LO LPF behaviour in 1.5-2 GHz range.
* UBX: Fixed dtor SIGABRT issue.
* GPSDO: Improved detection.
* Examples: Added channel param to samps to/from file. sync_to_gps exits
instead of uncaught throw.
* C API: Fixed some missing fields in USRP info.
* Docs: Many minor fixes.
* CMake: Fixed GCC 4.4 compilation issue. Added ability to specify package
names.

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

Re: [USRP-users] Removing the whole LO signal when transmitting

[Derek Kozel via USRP-users]

Hello Brais,

The gain values for USRPs are indexed from 0 dB gain being minimum gain up
to the device's maximum. Usually this means that 0 dB of gain is actually a
large amount of attenuation or loss through the RX chain. The same is true
for TX. It doesn't surprise me that you are seeing those values.

Ideally you will experiment to find an operating point on RX to maximize
the signal quality (minimize Noise Figure and capture the maximum dynamic
range) of your digitized signal. The performance data for the
daughterboards can help with this. There are similar tradeoffs on the TX
side.
http://files.ettus.com/performance_data/

Also be sure to run the self-calibration routines if your daughterboard
supports them. This can improve the signal quality significantly. Marcus
has also mentioned UHD's ability to do LO offsetting to move it outside of
your passband, definitely worth investigating.

Regards,
Derek

On Mon, Jul 17, 2017 at 11:47 AM, Brais Ares via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Ok, I understand!
>
> Also I have to configure a rx_gain of 60 dB, and a tx_gain of 10 dB If I
> want to reconstruct the transmitted signal to the very same power level I
> received it.
>
> The scheme would be:
> ~~~ signal_generator (QPSK at -60 dBm) -> cable(0.3 dB attenuation) ->
> rx_usrp -> tx_usrp -> cable(0.3 dB attenuation) -> Signal analyzer (I want
> to obtain original power here, -60 dBm).
>
> *Is it normal that I have to apply roughly 70 dB of gain to replicate the
> incoming signal?*
>
> @Karan, did this happen to you?
>
> ​Appreciate all the help, guys
> Regards,
> Brais.​
>
>
> ___
> 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 not recieving waveform

[Derek Kozel via USRP-users]

Hello Brandon,

How did you install UHD and GNU Radio? When you say that the USRP is not
receiving the waveform, do you see just noise or does the application not
even start? What file was missing, there should definitely not be anything
missing from those versions.

I recommend ensuring that uhd_usrp_probe runs correctly and shows the X310
and TwinRX, then try using uhd_fft which comes with GNU Radio to see a
spectrum plot. If you are seeing only noise my guess is that you need to
increase the receive gain. The TwinRX has a very large gain range. Starting
around index 70 is usually good.

uhd_fft --freq 2e9 --gain 70

Regards,
Derek

On Mon, Jul 17, 2017 at 9:01 PM, Brandon Dunn via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
> I am fairly new to usrp's and i am having troubles getting a waveform from
> a x310 with one TwinRX daughterboard acting as a receiver. I am using 2
> signal generators to generate the waveform. My UHD version is
> 3.10.something (the newest auto-downloaded version). I am using GNU-radio
> to show this waveform which is version 3.7.11.1. I found that the TwinRX
> .cpp was not in the required folder so i downloaded that from github and
> put it in the correct folder. I don't see what I could be doing wrong. Can
> someone help me?
>
> Thanks,
> Brandon
>
> ___
> 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 not recieving waveform

[Derek Kozel via USRP-users]

Hi Bradon,

The TwinRX should show up as a TwinRX in the RX slot and an unknown
daughterboard in the TX slot. This is a cosmetic issue which we're aware of.

It is possible that you have a revision B TwinRX which has a newer ID than
is supported by your version of UHD. Can you please post the full output of
uhd_usrp_probe? This will have the UHD version information as well as info
on how the daughterboard is identifying.

Since you have installed UHD and GNU Radio many times it sounds like you
may have multiple, potentially conflicting versions installed. It is very
likely that you will need to uninstall all but one of these and get back to
a clean and consistent state. A good place to start there is to check the
outputs of

gnuradio-config-info --prefix -v
uhd_config_info --print-all

and the version string of UHD printed when you run a GNU Radio application.

Clearly we can see that uhd_fft for instance is installed in two places:
/home/wireless/target/bin/uhd_fft
/usr/local/bin/uhd_fft

You can try running `which gnuradio-companion` and `which uhd_usrp_probe`
to see if your paths make sense.

You can run `git describe` in your UHD source trees to see if they are
correctly in a uhd 3.10.x release. If possible it makes sense to update to
the latest stable release, currently 3.10.1.1.

Regards,
Derek


On Tue, Jul 18, 2017 at 3:59 PM, Brandon Dunn  wrote:

> Hi Derek,
> GNUradio starts but the tones(900Mhz and 900.4Mhz) being created by the
> signal generators does not show up where it should near the center
> frequency set(898Mhz). The flow chart works for other radios but this
> twinRx board doesn't want to work. The file I am talking about is the
> db_twinrx.cpp file under uhd/host/lib/usrp/dboard. uhd_usrp_probe runs
> correctly but it shows the board as "unknown" but the correct code is shown
> for the twinrx(x091 - something). I am seeing only noise and center
> frequency but I have increased the gain to 70 and it still showed the same.
> I believe the problem is that GNUradio and UHD has been installed many
> times on the computer i am using with both pybombs and
> gnuradio/build(another method). I can't seem to run uhd_fft as it can't
> find it. I am using ubuntu. When i try to locate uhd_fft i get the
> following.
>
> /home/wireless/Pictures/CPU% for uhd_fft at high sampling rate.png
> /home/wireless/gnuradio/build/gr-uhd/apps/uhd_fft.exe
> /home/wireless/gnuradio/gr-uhd/apps/uhd_fft
> /home/wireless/gnuradio/gr-uhd/apps/uhd_fft_wx
> /home/wireless/gnuradio/gr-uhd/examples/grc/uhd_fft.grc
> /home/wireless/pybombs/src/gnuradio/build/gr-uhd/apps/uhd_fft.exe
> /home/wireless/pybombs/src/gnuradio/gr-uhd/apps/uhd_fft
> /home/wireless/pybombs/src/gnuradio/gr-uhd/examples/grc/uhd_fft.grc
> /home/wireless/target/bin/uhd_fft
> /home/wireless/target/share/gnuradio/examples/uhd/uhd_fft.grc
> /usr/local/bin/uhd_fft
> /usr/local/share/gnuradio/examples/uhd/uhd_fft.grc
>
>
>
>
>
>
> On Tuesday, July 18, 2017 3:41 AM, Derek Kozel 
> wrote:
>
>
> Hello Brandon,
>
> How did you install UHD and GNU Radio? When you say that the USRP is not
> receiving the waveform, do you see just noise or does the application not
> even start? What file was missing, there should definitely not be anything
> missing from those versions.
>
> I recommend ensuring that uhd_usrp_probe runs correctly and shows the X310
> and TwinRX, then try using uhd_fft which comes with GNU Radio to see a
> spectrum plot. If you are seeing only noise my guess is that you need to
> increase the receive gain. The TwinRX has a very large gain range. Starting
> around index 70 is usually good.
>
> uhd_fft --freq 2e9 --gain 70
>
> Regards,
> Derek
>
> On Mon, Jul 17, 2017 at 9:01 PM, Brandon Dunn via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hello,
> I am fairly new to usrp's and i am having troubles getting a waveform from
> a x310 with one TwinRX daughterboard acting as a receiver. I am using 2
> signal generators to generate the waveform. My UHD version is
> 3.10.something (the newest auto-downloaded version). I am using GNU-radio
> to show this waveform which is version 3.7.11.1. I found that the TwinRX
> .cpp was not in the required folder so i downloaded that from github and
> put it in the correct folder. I don't see what I could be doing wrong. Can
> someone help me?
>
> Thanks,
> Brandon
>
> __ _
> 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] 3.9.7 Release Announcement

[Derek Kozel via USRP-users]

Hello all,

The 3.9.7 release of UHD has been posted. This is an update to the Long
Term Support series. There was one commit between the release candidate and
the final release. This added some safety checks to the
uhd_images_downloader script when using custom destination directories.

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

Installers for Windows and Fedora, as well as the source code, are
available here:
http://files.ettus.com/binaries/uhd/uhd_003.009.007-release/

And the LTS PPA for Ubuntu will have updated installers shortly:
https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd-3.9.lts


There have been 28 commits since the last release which can be viewed here:
https://github.com/EttusResearch/uhd/compare/release_003_009_006...release_003_009_007

## 003.009.007

* multi_usrp: Fixed get_normalized_tx_gain.
* E300: Fix for streamer recreation issue
* X300: Fix for network discovery, will now return early when correct
serial is found.
* CBX: Fixed LO LPF behaviour in 1.5-2 GHz range.
* UBX: Fixed dtor SIGABRT issue.
* GPSDO: Improved detection.
* Examples: Added channel param to samps to/from file. sync_to_gps exits
instead of uncaught throw.
* C API: Fixed some missing fields in USRP info.
* Docs: Many minor fixes.
* CMake: Fixed GCC 4.4 compilation issue. Added ability to specify package
names.

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

Re: [USRP-users] DDC's Filters in B210

[Derek Kozel via USRP-users]

Hello Altug,

The CIC can be programed to decimate by a range of integer amounts. If the
ratio is 20 (50 MHz sampling rate, 2.5 MHz output rate) then both half
bands will be used (divide by 2*2) and the CIC will decimate by 5. Odd CIC
rates have poor filter roll off compared to even rates.

Derek

On Wed, Jul 19, 2017 at 10:52 AM, altuğ kaya via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear Martin,
>
> So, CIC's status is a binary one. For example if the ratio is 3, 3%4 = 3
> and because there is a remainder, the CIC is enabled. If the ratio is 20,
> both half-bands will be enabled and CIC is disabled as 20%4 = 0. Did I
> understand correctly?
>
> Regards,
> Altug
>
> On Tue, Jul 18, 2017 at 5:59 PM, Martin Braun via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Altuğ,
>>
>> per channel, there's 2 half-bands and 1 CIC. The rule is: We try and
>> enable as many half-bands as possible, the rest is done by CIC. So, any
>> ratio of sample_rate to master_clock_rate that is divisible by 4 has 2
>> half-bands, any other even ratio has 1 half-band, and the remainder is
>> done in the CIC.
>>
>> Cheers,
>> Martin
>>
>> On 07/18/2017 07:55 AM, altuğ kaya via USRP-users wrote:
>> > Hello everyone,
>> >
>> > In B210 there are 2 half-band filters and 4 CIC filters. As far as I
>> > know we can select how many filters we would like to use by tuning the
>> > ratio between sample_rate and master_clock_rate. What is the rule of it?
>> >
>> > I am looking forward to your answer,
>> > Altug Kaya
>> >
>> >
>> > ___
>> > 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

[USRP-users] 3.10.2.0 Release Candidate 1 Announcement

[Derek Kozel via USRP-users]

Hello all,

The release candidate of UHD version 3.10.2.0 has been tagged and is
available for testing. There have been no API breaking changes necessary
since the last release but a small ABI change means we are incrementing the
ABI number. Updated FPGA and firmware images have been uploaded.

The tag for this release:
https://github.com/EttusResearch/uhd/releases/tag/003_010_002_000_rc1

There have been 83 commits since the last release which can be viewed here:
https://github.com/EttusResearch/uhd/compare/release_003_010_001_001...003_010_002_000_rc1

## 003.010.002.000

* multi_usrp: Fixed get_normalized_tx_gain.
* E300: Fix for streamer recreation issue. Reduced minimum timeout, fixed
potential race condition.
* X300: Fix for network discovery, will now return early when correct
serial is found. Fixed issue with DAC sync. All async messages now go
through single DMA channel on PCIe. Improved TX performance. Fixed page
size acquisition for PCIe. Fixed some FW communication errors. Improved
flow control. Removed MTU throttling. Legacy compat falls back to min spp
for mixed transport types.
* CBX: Fixed LO LPF behaviour in 1.5-2 GHz range.
* UBX: Fixed dtor SIGABRT issue. Better error handling for various dboard
clock rates.
* TwinRX: Added LO reimport feature.
* GPSDO: Improved detection. Improved query_gpsdo sensor.
* RFNoC: Fixed issue with DDC and DUC command tick rate.
* UHD: Fixed potential memory leak in tasks. Fixed
get_normalized_tx_gain(). Fixed default socket buffer size to honor MTU.
* Examples: Added channel param to samps to/from file. sync_to_gps exits
instead of uncaught throw. latency_test improved output. Use next_pps in
test_clock_synch. Added TwinRX FHSS example.
* Utils: Modified behaviour of uhd_images_downloader so it won't delete
dirs when using -i
* Tools: Updates to CHDR dissector. Added set_time_source_out(). Fixed LO
API.
* C API: Fixed some missing fields in USRP info.
* Docs: Many minor fixes. Fixed Doxygen warnings related to /* in files.
* CMake: Fixed GCC 4.4 compilation issue. Added ability to specify package
names.

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

Re: [USRP-users] Using a reference clock on USRP E310/312

[Derek Kozel via USRP-users]

Hello,

To get time and frequency alignment on a pair of E31xs you can supply the
1PPS to both units. The example programs do not all support setting the
time source.
http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_hw_sync

Here is an example which supports setting the time source, you can modify
other examples based on this.
https://github.com/EttusResearch/uhd/blob/maint/host/examples/test_pps_input.cpp#L68

Are you trying to achieve phase synchronization?

Regards,
Derek

On Tue, Jul 25, 2017 at 11:40 PM, Cho, Daniel J (332C) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello –
>
>
>
> I have 2 USRPs (both E310/E312) which I want to sync up using an external
> clock.  I read that the embedded series cannot take in a 10MHz reference
> clock but can take in a 1PPS.  I generated a 1 PPS signal using a signal
> generator and using a power splitter, I sent the 1PPS signal to both USRPs
> via the sync port on the USRPs.  When I try to run an example programs
> (rx_samples_to_file on one USRP and tx_samples_from_file on the other USRP)
> using the ref argument, it says that the ref argument is not supported.
>  How can I sync up the two USRPs?
>
>
>
> 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] 答复: frequency shift of B210

[Derek Kozel via USRP-users]

Hi Jong,

Marcus Leech and Marco have both offered good advice on testing the
frequency stability of the B210 against outside references. Have you tried
either?

Marcus Muller also asked for additional information about your test setup.

Regards,
Derek

On Wed, Jul 26, 2017 at 2:04 AM, john liu via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
> Any suggestions is welcome.
>
> best regards
> Jong
>
> On Mon, Jul 24, 2017 at 5:35 PM, john liu  wrote:
>
>> HI,all,
>> Do you have any suggestions about this?
>> thank you.
>> best regards
>> John
>>
>> On Mon, Jul 24, 2017 at 9:15 AM, 戚科峰(研三 福州) 
>> wrote:
>>
>>> Hi,Marcus,
>>>
>>>
>>>
>>> we use The B210 as a basestation and cc1120 as the tranceiver of UE.
>>>
>>> The B210 uses the Frequency offset estimation algorithm to estimate the
>>> frequency offset of cc1120 and records it.
>>>
>>> there are several UE in the system,UE will receive the B210'signal
>>> periodically and will send a signal to B210 in another period.
>>>
>>> when the phenomenon of the 3.2k frequency shift occured， all UE could
>>> not receive the signal of B210.when time for UE to send a signal，
>>>
>>> B210 would estimate the new frequency shift and found that the Frequency
>>> offset of every UE shifts 3.2k。So we think the shifting occured in B210
>>> instead of UE。
>>>
>>>
>>>
>>> best regards
>>>
>>>
>>>
>>>
>>>
>>> *发件人:* john liu [mailto:johncorad1...@gmail.com]
>>> *发送时间:* 2017年7月21日 16:42
>>> *收件人:* Marcus D. Leech
>>> *抄送:* USRP-users@lists.ettus.com; 戚科峰(研三 福州)
>>> *主题:* Re: frequency shift of B210
>>>
>>>
>>>
>>> Hi,Marcus,
>>>
>>> We calculated this.
>>>
>>> The B210 not only generate a GFSK signal,but also received the signal
>>> from CC1120.The CC1120 and B210 both work in full duplex mode.
>>>
>>> Hi qi,
>>>
>>> Can you describe your test method?I am not clear for that.
>>>
>>>
>>>
>>> best regards
>>>
>>> John
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Jul 21, 2017 at 10:47 AM, Marcus D. Leech 
>>> wrote:
>>>
>>> On 07/20/2017 10:08 PM, john liu wrote:
>>>
>>> i am sorry.
>>>
>>> We generate a GFSK signal with B210 and  received the signal with
>>> multiple cc1120.When frequency shift occurred,the cc1120 can not received
>>> the signal.
>>>
>>> Also, another b210 has been running for several days without such a jump
>>> phenomenon.
>>>
>>> So, sorry to be a bother, but, where did the 3.2kHz frequency shift
>>> measurement come from?   The CC1120 is just a GFSK demodulating digital
>>> receiver.
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Jul 21, 2017 at 9:37 AM, Marcus D. Leech 
>>> wrote:
>>>
>>> No i mean what were you measuring?
>>>
>>>
>>>
>>> Were you using an external signal generator and what were its specs?
>>>
>>>
>>>
>>>
>>> Sent from my iPhone
>>>
>>>
>>> On Jul 20, 2017, at 9:09 PM, john liu  wrote:
>>>
>>> HI Marcus,
>>>
>>> internal with  TCXO.
>>>
>>>
>>>
>>> On Thu, Jul 20, 2017 at 11:31 PM, Marcus D. Leech 
>>> wrote:
>>>
>>> On 07/20/2017 02:22 AM, john liu wrote:
>>>
>>>
>>>
>>> What was your tuned frequency in this case?
>>>
>>>
>>>
>>> Hi,Marcus,
>>>
>>>
>>>
>>> It is 433.05Mhz
>>>
>>> That's about 7PPM.
>>>
>>> What was your signal source?
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jul 20, 2017 at 11:46 AM, john liu 
>>> wrote:
>>>
>>> Hi all,
>>>
>>> We used B210 with TCXO,and run about 2 hours , a 3.2K frequency shift
>>> occurred when the temperature did not change significantly.Is it a normal?
>>>
>>> How can we improve this situation?
>>>
>>>
>>>
>>> thank you.
>>>
>>> best regards
>>>
>>> John
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
> ___
> 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] Disabling CORDIC

[Derek Kozel via USRP-users]

Hello Altug,

If you tune using the tune request with a DSP policy of MANUAL and DSP
frequency of 0.0 then yes, that channel's CORDIC will not alter the samples.

A policy of NONE will leave the DSP in the last configured state, so it is
better to be explicit.

Regards,
Derek


On Wed, Jul 26, 2017 at 12:08 PM, altuğ kaya via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello everyone,
>
> When the full manual tuning policy is selected and 0 Hz rotation is
> configured:
>
>> tune_request.dsp_freq_policy = uhd::tune_request_t::POLICY_MANUAL;
>> tune_request.dsp_freq = 0.0;
>>
>
>  or when the  policy_none is selected;
>
>> tune_request.dsp_freq_policy = uhd::tune_request_t::POLICY_NONE;
>
>
> Are both RX channels' CORDIC  disabled?
>
> Sincerely,
> Altug
>
> ___
> 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 a reference clock on USRP E310/312

[Derek Kozel via USRP-users]

Hello,

Unfortunately the phase offset between channels on separate E31xs is not
repeatable between tunes or runs. In order to use multiple E31xs for
beamforming or other applications needing known phase offsets it is
necessary to supply an external reference signal and use that to measure
the offsets each time they are tuned. This is a limitation of the AD9361
and the USRP's design.

The two RX channels on a single E31x are driven by a single LO, so their
phase offset will be stable without any external references. The same is
true for the TX pair of channels.

The E31x will discipline the internal frequency reference when an external
1PPS signal is supplied. The 1PPS can also be used to set the FPGA's
timestamp very accurately so sample streams from multiple USRPs can be
aligned in time.


After you set the time source for both USRPs then the frequencies will be
aligned.
usrp->set_time_source("external");

You will have to then use the 1PPS signal to set the timestamps. I
recommend reading the manual page on Synchronization, I hope it will
clarify these steps.
http://files.ettus.com/manual/page_sync.html

For MIMO setups with more than two channels the N2x0 and X3x0 USRPs are
recommended. Properly configured these do not require external signals to
be supplied for calibrating out the phase on every tune.
https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices

Regards,
Derek


On Wed, Jul 26, 2017 at 3:43 PM, Cho, Daniel J (332C) <
daniel.j@jpl.nasa.gov> wrote:

> Hello –
>
>
>
> Yes I am trying to achieve phase synchronization.  So once I set the time
> source using the function call if (not time_source.empty()) usrp->
> set_time_source(time_source);, will time and frequency for the two USRPs
> be aligned?  Also, is it true that the USRP E310/E312 cannot use a 10 MHz
> ref clock or can I just set the time source using the 10MHz reference
> instead of the 1PPs?
>
>
>
> Thanks
>
> *From:* Derek Kozel [mailto:derek.ko...@ettus.com]
> *Sent:* Wednesday, July 26, 2017 6:56 AM
> *To:* Cho, Daniel J (332C) 
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] Using a reference clock on USRP E310/312
>
>
>
> Hello,
>
> To get time and frequency alignment on a pair of E31xs you can supply the
> 1PPS to both units. The example programs do not all support setting the
> time source.
> http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_hw_sync
>
> Here is an example which supports setting the time source, you can modify
> other examples based on this.
> https://github.com/EttusResearch/uhd/blob/maint/
> host/examples/test_pps_input.cpp#L68
>
> Are you trying to achieve phase synchronization?
>
> Regards,
>
> Derek
>
>
>
> On Tue, Jul 25, 2017 at 11:40 PM, Cho, Daniel J (332C) via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hello –
>
>
>
> I have 2 USRPs (both E310/E312) which I want to sync up using an external
> clock.  I read that the embedded series cannot take in a 10MHz reference
> clock but can take in a 1PPS.  I generated a 1 PPS signal using a signal
> generator and using a power splitter, I sent the 1PPS signal to both USRPs
> via the sync port on the USRPs.  When I try to run an example programs
> (rx_samples_to_file on one USRP and tx_samples_from_file on the other USRP)
> using the ref argument, it says that the ref argument is not supported.
>  How can I sync up the two USRPs?
>
>
>
> 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] TwinRX + X300 Usage

[Derek Kozel via USRP-users]

Hello Christian,

Your configuration of the LO sharing is all reasonable. You are not using
timed commands so you will not get repeatable phase offsets between the
channels due to the DDC's CORDIC and the RX frontend's IF downconverter not
being synchronously reset. The call to set_rx_freq for each channel should
be executed with the same command time.

Have you tuned the gain to maximize your signal? I do not have a signal
generator connected at the moment, but a gain of 60 sounds like you may
have some more headroom to increase your amplitude. This will improve noise
figure and usually SNR.

When you say that two channels are 45 dB matched, what are you measuring?

Thank you,
Derek

On Wed, Jul 26, 2017 at 10:27 PM, Christian Hahn via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey USRP-users,
>
> I am doing some experiments that involve a USRP x300 + (2) TwinRX
> daughtercards.  I am observing some degraded performance and would like
> some advice on the manner in which I am configuring the receivers /
> mainboard / daughtercards.
>
> The experiment I am conducting involves collection of high-dynamic range
> channel-estimates: similar requirements to a direction-finding problem.  In
> my setup, I have 1 remote transmitter, and 4 receivers.
>
> I am least confident about how I am configuring the daughtercards since
> there are no examples that I could find which use these relatively new
> daughtercards.
>
> The observations I have made indicate abnormally high phase noise and poor
> relative SNR between receivers.  For example, when injecting an identical
> signal into all 4 receivers, receivers 0-1 and 2-3 are 45 dB matched,
> respectively.  However, receivers across daughtercards are not!  This is
> strange since in my configuration of the USRP I intended to share the same
> LO across all four receivers.  Furthermore, the spectrum of each receiver
> is quite spurious.  I am expecting more than 45 dB SNR, at least.  The
> signal level into the receivers is -36 dBm (average).  The PAPR of the
> signal is very low < 5 dB.
>
> This is the code I am using to configure the USRP and take a capture of
> samples.  It is using a thin wrapper written in Python around the
> multi_usrp C++ API.
>
> Thank you very much, any insight is much appreciated!
>
> #
>
> import uhd
> import time
>
> # Some parameters
> freq = 1600.e6
> gain = 60.
> num_samples = int(10.e6)
>
> # Create the USRP object
> usrp = uhd.Uhd('type=x300,addr=192.168.50.2,second_addr=192.168.40.2')
>
> # Configure mainboard
> usrp.set_clock_source('external')
> usrp.set_rx_subdev_spec('A:0 A:1 B:0 B:1')
> usrp.set_rx_rate(100.e6)
>
> # Configure receivers
> source = ['internal', 'companion', 'external', 'external']
> export = [True, False, False, False]
> antenna = ['RX1', 'RX2', 'RX1', 'RX2']
> for chan in range(usrp.get_rx_num_channels()):
> usrp.set_rx_lo_source(source[chan], 'all', chan)
> usrp.set_rx_lo_export_enabled(export[chan], 'all', chan)
> usrp.set_rx_antenna(antenna[chan], chan)
> usrp.set_rx_freq(freq, chan)
> usrp.set_rx_gain(gain, chan)
>
> time.sleep(1.)
>
> # Capture samples
> samps = usrp.receive(num_samples, list(range(usrp.get_rx_num_channels())),
> False)
>
>
> ___
> 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] Windows driver for B210

[Derek Kozel via USRP-users]

Hello Anuja,

That zip contains the USB driver for the B210, it is the same as the B200.
If you encounter an error message then unplug and replug the B210. This is
a non-fatal error that is seen occasionally with different Windows versions.

Regards,
Derek

On Mon, Jul 31, 2017 at 11:54 AM, Anuja Kokil via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> I am working on GRC along with USRP. I tried installing it on Windows 8..
> when it came about USB driver. I downloaded it from
> http://files.ettus.com/binaries/misc/erllc_uhd_winusb_driver.zip . but i
> found that it doesn't support  for B210.
>
> Where can i get USB driver for B210..kindly help me
>
>
> Thanking you
> Anuja.
>
> ___
> 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] Configuration of E310 USRP

[Derek Kozel via USRP-users]

Hello Nauman,

I assume that you are using the X310 rather than the E310.

It is not possible by default to use PCIe for configuration and control and
then to use the SFP+ connections with Aurora for the sample streaming. The
hardware could technically support such a configuration, but it would
require extensive FPGA and host code development. I do not have a lot of
familiarity with LabVIEW FPGA based workflows, but I would suggest looking
into that as it is not impossible that that software stack could be made to
support this.

The base UHD and regular LabVIEW NI-USRP drivers do not support that set of
configurations.

Regards,
Derek

On Mon, Jul 31, 2017 at 2:22 PM, Nauman Iqbal via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
>   I am looking at the UHD’s initialization of radio parameters. Is
> there a possibility if we can use the PCIe interface and Labview comms to
> configure the radios and at same time configure the streamers to be using
> 10gig Ethernet to send/receive baseband streams? So the configuration is
> done totally independently via PCIe and a labiew GUI, plus we want to use
> Aurora instead of the 10G Ethernet for the streamers.
>
>
>
> Regards
>
>
>
> Nauman
>
> ___
> 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] 3.10.2.0 Release Announcement

[Derek Kozel via USRP-users]

Hello all,

The 3.10.2.0 release of UHD has been posted. This is an update to the main
series of releases. There were four commit between the release candidate
and the final release. All were documentation updates except for an
improvement to the query_gpsdo_sensors utility.

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

Installers for Windows and Fedora, as well as the source code, are
available here:
http://files.ettus.com/binaries/uhd/uhd_003.010.002.000-release/

And the PPA for Ubuntu will have updated installers shortly:
https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd


There have been 89 commits since the last release which can be viewed here:
https://github.com/EttusResearch/uhd/compare/release_003_010_001_001...
release_003_010_002_000

## 003.010.002.000

* multi_usrp: Fixed get_normalized_tx_gain.
* E300: Fix for streamer recreation issue. Reduced minimum timeout, fixed
potential race condition.
* X300: Fix for network discovery, will now return early when correct
serial is found. Fixed issue with DAC sync. All async messages now go
through single DMA channel on PCIe. Improved TX performance. Fixed page
size acquisition for PCIe. Fixed some FW communication errors. Improved
flow control. Removed MTU throttling. Legacy compat falls back to min spp
for mixed transport types.
* CBX: Fixed LO LPF behaviour in 1.5-2 GHz range.
* UBX: Fixed dtor SIGABRT issue. Better error handling for various dboard
clock rates.
* TwinRX: Added LO reimport feature.
* GPSDO: Improved detection. Improved query_gpsdo sensor.
* RFNoC: Fixed issue with DDC and DUC command tick rate.
* UHD: Fixed potential memory leak in tasks. Fixed
get_normalized_tx_gain(). Fixed default socket buffer size to honor MTU.
* Examples: Added channel param to samps to/from file. sync_to_gps exits
instead of uncaught throw. latency_test improved output. Use next_pps in
test_clock_synch. Added TwinRX FHSS example.
* Utils: Modified behaviour of uhd_images_downloader so it won't delete
dirs when using -i
* Tools: Updates to CHDR dissector. Added set_time_source_out(). Fixed LO
API.
* C API: Fixed some missing fields in USRP info.
* Docs: Many minor fixes. Fixed Doxygen warnings related to /* in files.
* CMake: Fixed GCC 4.4 compilation issue. Added ability to specify package
names.

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

Re: [USRP-users] Trying to verify Rx MIMO operation of x310

[Derek Kozel via USRP-users]

Hello Mark,

rx_samples_to_file will only receive a single channel. It is a minimal
example.

Try:
rx_multi_samples --channels 0,1

This will receive two channels, a pair of UBXs only has one RX channel per
daughterboard so UHD can infer the sub device specification. The default
sample rate is 100 MS/s so both channels will fit into a single 10 GigE
connection. Make sure to follow the advice of any warnings printed to
improve the throughput of your network interface card.

If you have an external 1PPS source you can add `--sync pps --secs 0.1` to
the above parameters to synchronize the two channels. The example currently
forces an external source when synchronizing. If you remove/comment out
line 98 and recompile it will use the internal source.

Regards,
Derek





On Tue, Aug 1, 2017 at 2:46 PM, Mark Koenig via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I currently have an x310 with a ubx-40 in each of slots A and B.  I have
> one 10Gig Ethernet connection hooked up, and would like to receive on both
> channels A and B.
>
>
>
> I tried using the “rx_multi_samples” function, but I didn’t get a good
> feeling I was collecting on both channels.  I tried using the
> “rx_samples_to_file” function, but didn’t see a coherent collection on A
> and B, when setting the subdev to “A:0 B:0”.
>
> Finally, I tried the “uhd_fft”, and saw collection in channel A, but
> nothing from channel B, while setting subdev=”A:0 B:0”.
>
>
>
> Am I doing something incorrectly, or is there another function I should
> try?
>
>
>
> Thanks
>
>
>
> 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] One USRP device is not connected to the host computer

[Derek Kozel via USRP-users]

Hello Adhitha,

If you are connecting only one USRP at a time directly to the computer and
see one work and one not then my first guess would be that the IP address
has changed on the second one. Try running uhd_find_devices, this will work
if the IP address is different but still on the same subnet. If you do not
see it with this then try increasing your netmask to something like
255.255.0.0 to catch a broader range of possible addresses.

More networking info can be found in the manual.
http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_setup_network

What version of UHD are you using and what operating system?

Regards,
Derek

On Tue, Aug 1, 2017 at 9:49 AM, Adhitha Dias via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I am a new user of USRP and UHD software. I have 2 X310 USRPs but the
> connection is established with only one USRP (first USRP). When I ping the
> other USRP (say second USRP) it gives ICMP destination host unreachable
> message. I am uncertain on how to debug or if there is something wrong with
> its hardware configuration.
>
> I connected one USRP at a time using the same Ethernet cable with the same
> host computer when checking. Any help would be highly appreciated!
>
> Thank you.
>
> Best regards,
> Adhitha Dias
> Undergraduate,
> Department of Electronics and Telecommunication,
> University of Moratuwa,
> Sri Lanka.
>
> ___
> 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] Trying to verify Rx MIMO operation of x310

[Derek Kozel via USRP-users]

Hi Mark,

Unfortunately you're up against the limits of the included examples. There
are no UHD only examples which store multiple channels of samples to a
file. The rx_multi_samples shows the steps involved in setting up the
channels, but doesn't implement the functionality shown in
rx_samples_to_file to write to a file.

Yes, uhd_fft can be used to view multiple channels. GNU Radio's framework
makes it easy to implement the more advanced application layer features.
The arguments will be almost the same as for rx_multi_samples to file.
Check out the help message for uhd_fft to see all the options. Simply
supplying the frequency of interest and the same --channels 0,1 should show
you plots of both channel's spectrum and time series data.

To save data from both channels you will need to construct a flowgraph in
GNU Radio. There are some examples supplied with gr-uhd which demonstrate
the basics of connecting and configuring the USRP source. If you have
trouble let us know here or on the GNU Radio mailing list.

Regards,
Derek

On Tue, Aug 1, 2017 at 3:14 PM, Mark Koenig <
mark.koe...@iubelttechnologies.com> wrote:

> Thanks Derek.
>
>
>
> I was setting up rx_multi_samples the following way:
>
>
>
> ./rx_samples –args=”addr=192.168.40.2” –nsamps=1000 –rate=100e6
> –sync=now –subdev=”A:0 B:0” –channels=”0,1”
>
>
>
> I see a lot of verbose output, like:
>
>
>
> Received Packet:  1996 samples, 1 full secs, 0.50 frac secs
>
>
>
> But, I don’t get any file outputs or anything else.  The collection ends
> and I am left wondering what just happened.  Can I use uhd_fft to look at
> the MIMO stream?
>
>
>
> Also, there is no place to enter a frequency to collect, should there be?
>
>
>
> Mark
>
>
>
> *From: *Derek Kozel 
> *Date: *Tuesday, August 1, 2017 at 10:08 AM
> *To: *Mark Koenig 
> *Cc: *"usrp-users@lists.ettus.com" 
> *Subject: *Re: [USRP-users] Trying to verify Rx MIMO operation of x310
>
>
>
> Hello Mark,
>
> rx_samples_to_file will only receive a single channel. It is a minimal
> example.
>
> Try:
>
> rx_multi_samples --channels 0,1
>
> This will receive two channels, a pair of UBXs only has one RX channel per
> daughterboard so UHD can infer the sub device specification. The default
> sample rate is 100 MS/s so both channels will fit into a single 10 GigE
> connection. Make sure to follow the advice of any warnings printed to
> improve the throughput of your network interface card.
>
> If you have an external 1PPS source you can add `--sync pps --secs 0.1` to
> the above parameters to synchronize the two channels. The example currently
> forces an external source when synchronizing. If you remove/comment out
> line 98 and recompile it will use the internal source.
>
> Regards,
>
> Derek
>
>
>
>
>
>
> On Tue, Aug 1, 2017 at 2:46 PM, Mark Koenig via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> I currently have an x310 with a ubx-40 in each of slots A and B.  I have
> one 10Gig Ethernet connection hooked up, and would like to receive on both
> channels A and B.
>
>
>
> I tried using the “rx_multi_samples” function, but I didn’t get a good
> feeling I was collecting on both channels.  I tried using the
> “rx_samples_to_file” function, but didn’t see a coherent collection on A
> and B, when setting the subdev to “A:0 B:0”.
>
> Finally, I tried the “uhd_fft”, and saw collection in channel A, but
> nothing from channel B, while setting subdev=”A:0 B:0”.
>
>
>
> Am I doing something incorrectly, or is there another function I should
> try?
>
>
>
> Thanks
>
>
>
> 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] One USRP device is not connected to the host computer

[Derek Kozel via USRP-users]

Hi Adhitha,

I'm glad that's worked for you.

Best regards,
Derek

On Tue, Aug 1, 2017 at 4:19 PM, Adhitha Dias 
wrote:

> Hi Derek,
>
> I tried with the large netmask. Now it's working. Thank you so much for
> the help. Really appreciate it!
>
> I am using UHD version 3.10.1.0 in Ubuntu 16.04.2 OS.
>
> Regards,
> Adhitha
>
> On 1 Aug 2017 11:09 p.m., "Derek Kozel"  wrote:
>
>> Hello Adhitha,
>>
>> If you are connecting only one USRP at a time directly to the computer
>> and see one work and one not then my first guess would be that the IP
>> address has changed on the second one. Try running uhd_find_devices, this
>> will work if the IP address is different but still on the same subnet. If
>> you do not see it with this then try increasing your netmask to something
>> like 255.255.0.0 to catch a broader range of possible addresses.
>>
>> More networking info can be found in the manual.
>> http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_setup_network
>>
>> What version of UHD are you using and what operating system?
>>
>> Regards,
>> Derek
>>
>> On Tue, Aug 1, 2017 at 9:49 AM, Adhitha Dias via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi,
>>>
>>> I am a new user of USRP and UHD software. I have 2 X310 USRPs but the
>>> connection is established with only one USRP (first USRP). When I ping the
>>> other USRP (say second USRP) it gives ICMP destination host unreachable
>>> message. I am uncertain on how to debug or if there is something wrong with
>>> its hardware configuration.
>>>
>>> I connected one USRP at a time using the same Ethernet cable with the
>>> same host computer when checking. Any help would be highly appreciated!
>>>
>>> Thank you.
>>>
>>> Best regards,
>>> Adhitha Dias
>>> Undergraduate,
>>> Department of Electronics and Telecommunication,
>>> University of Moratuwa,
>>> Sri Lanka.
>>>
>>> ___
>>> 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] N210 DSP Processing Chain

[Derek Kozel via USRP-users]

Hi Dave,

You're exactly right, there is a decimation operation between the raw ADC
IQ samples and the samples which can be streamed *continuously* across a 1
Gigabit link.
It is very similar to the X310 where the frontend passes the full rate
samples to a DDC chain.
https://github.com/EttusResearch/fpga/blob/maint/
usrp2/sdr_lib/ddc_chain.v#L119

I believe, but am unable to check at the moment, that the full 100 MS/s can
be received in bursts, the limit of each burst being the accumulated
buffers in the FPGA combined with the ethernet link. There are other
operations performed on the IQ samples in the frontend, you can see them in
this HDL file. Some of the compensations can be set to not influence the
samples, but others could not be disabled without rebuilding the FPGA image.
https://github.com/EttusResearch/fpga/blob/maint/usrp2/sdr_lib/rx_frontend.v

Usually that is not desirable though as these corrections generally improve
the spectrum.

Regards,
Derek

On Tue, Aug 1, 2017 at 3:18 PM, Dave NotTelling via USRP-users <
usrp-users@lists.ettus.com> wrote:

> What happens to samples between the ADC and receiving them from UHD?
> Also, is there any way to get the raw IQ off of the ADC itself?  I feel
> like there isn't only because the ADC (to the best of my knowledge) runs at
> 100 MSPS which is too high a rate to send over the 1 Gb/s link.
>
> 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] PPS sync with USRP E310 timeout error

[Derek Kozel via USRP-users]

Hello Daniel,

There is no check in your code to confirm that the time is correctly set.
The 1PPS signal should be a square wave rather than a sine wave. It is a
logic signal rather than an RF one and the sync port is designed to handle
it.
http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_hw_pps

The Octoclock which we use produces a 20% duty cycle square wave with 5V
high and 0V low.

Regards,
Derek

On Wed, Aug 2, 2017 at 2:10 AM, Cho, Daniel J (332C) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello –
>
>
>
> I am using 2 USRP E310 which I would like to frequency sync together.  I
> am using a frequency generator which is generating a 1 PPS (1Hz sine wave)
> signal which I put through a power splitter to provide both USRPs with the
> same 1 PPS signal.  I configured the rx_samples_to_file and
> tx_samples_from_file codes to allow me to use the external 1PPS signal by
> including the following into the code:
>
>
>
> //sleep off if gpsdo detected and time next pps already set
>
> boost::this_thread::sleep(boost::posix_time::seconds(1));
>
> //set time source if specified
>
> if (not time_source.empty()) usrp->set_time_source(time_source);
>
> //set the time at an unknown pps (will throw if no pps)
>
> std::cout << std::endl << "Attempt to detect the PPS and set the time..."
> << std::endl << std::endl;
>
> usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));
>
> std::cout << std::endl << "Success!" << std::endl << std::endl;
>
>
>
> When I run the rx_samples_to_file code with the above code included, I get
> a timeout error.  I found that it was due to the line “usrp->
> set_time_unknown_pps(uhd::time_spec_t(0.0));”
>
> How can I get my two USRPs frequency synced without getting this error?
>
>
>
> Also, I saw that the 1 PPS signal provided to the USRP should be 3.3V –
> 5V.  When I put a 1 PPS signal that strong on the spectrum analyzer, it
> shows a power output above +10 dBm.  I know that the max RX input power is
> -15 dBm so I was hesitant to input a 1 PPS signal that strong.  The 1 PPS
> signal I put into the sync port was 100 mV.  Even with a 1 PPS signal with
> an output power of 100mV, I am still able to run the test_pps_input program
> successfully.
>
>
>
> So in summary, should I just send a 1 PPS signal with a power output above
> +10 dBm which equates to the 3.3V – 5V to the sync port even though I am
> able to run the test_pps_input program successfully with 100mV?  How can I
> get the rx_samples_to_file program to run successfully without giving me a
> timeout error using the above lines of code?
>
>
>
> 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] Trying to verify Rx MIMO operation of x310

[Derek Kozel via USRP-users]

Hi Mark,

I've added back on the list, it's useful to keep everyone in sync with
progress.

The WX FFT only takes one input but the QT Frequency Sync has a
configurable number of inputs. In general the QT GUIs are being promoted
over WX.

Regards,

Derek

On Tue, Aug 1, 2017 at 7:40 PM, Mark Koenig <
mark.koe...@iubelttechnologies.com> wrote:

> Thank you for the reply Derek.
>
>
>
> I set up a flow diagram in GNU radio companion with the USRP Source having
> 2 outputs and I want to route that to a WX GUI FFT sink, which accepts only
> one input.  Do I add an “add” block between the USRP source and GUI FFT
> Sink or a different block?
>
>
>
> Thanks
>
>
>
> Mark
>
>
>
> *From: *Derek Kozel 
> *Date: *Tuesday, August 1, 2017 at 11:11 AM
>
> *To: *Mark Koenig 
> *Cc: *"usrp-users@lists.ettus.com" 
> *Subject: *Re: [USRP-users] Trying to verify Rx MIMO operation of x310
>
>
>
> Hi Mark,
>
> Unfortunately you're up against the limits of the included examples. There
> are no UHD only examples which store multiple channels of samples to a
> file. The rx_multi_samples shows the steps involved in setting up the
> channels, but doesn't implement the functionality shown in
> rx_samples_to_file to write to a file.
>
> Yes, uhd_fft can be used to view multiple channels. GNU Radio's framework
> makes it easy to implement the more advanced application layer features.
> The arguments will be almost the same as for rx_multi_samples to file.
> Check out the help message for uhd_fft to see all the options. Simply
> supplying the frequency of interest and the same --channels 0,1 should show
> you plots of both channel's spectrum and time series data.
>
> To save data from both channels you will need to construct a flowgraph in
> GNU Radio. There are some examples supplied with gr-uhd which demonstrate
> the basics of connecting and configuring the USRP source. If you have
> trouble let us know here or on the GNU Radio mailing list.
>
> Regards,
>
> Derek
>
>
>
> On Tue, Aug 1, 2017 at 3:14 PM, Mark Koenig  iubelttechnologies.com> wrote:
>
> Thanks Derek.
>
>
>
> I was setting up rx_multi_samples the following way:
>
>
>
> ./rx_samples –args=”addr=192.168.40.2” –nsamps=1000 –rate=100e6
> –sync=now –subdev=”A:0 B:0” –channels=”0,1”
>
>
>
> I see a lot of verbose output, like:
>
>
>
> Received Packet:  1996 samples, 1 full secs, 0.50 frac secs
>
>
>
> But, I don’t get any file outputs or anything else.  The collection ends
> and I am left wondering what just happened.  Can I use uhd_fft to look at
> the MIMO stream?
>
>
>
> Also, there is no place to enter a frequency to collect, should there be?
>
>
>
> Mark
>
>
>
> *From: *Derek Kozel 
> *Date: *Tuesday, August 1, 2017 at 10:08 AM
> *To: *Mark Koenig 
> *Cc: *"usrp-users@lists.ettus.com" 
> *Subject: *Re: [USRP-users] Trying to verify Rx MIMO operation of x310
>
>
>
> Hello Mark,
>
> rx_samples_to_file will only receive a single channel. It is a minimal
> example.
>
> Try:
>
> rx_multi_samples --channels 0,1
>
> This will receive two channels, a pair of UBXs only has one RX channel per
> daughterboard so UHD can infer the sub device specification. The default
> sample rate is 100 MS/s so both channels will fit into a single 10 GigE
> connection. Make sure to follow the advice of any warnings printed to
> improve the throughput of your network interface card.
>
> If you have an external 1PPS source you can add `--sync pps --secs 0.1` to
> the above parameters to synchronize the two channels. The example currently
> forces an external source when synchronizing. If you remove/comment out
> line 98 and recompile it will use the internal source.
>
> Regards,
>
> Derek
>
>
>
>
>
> On Tue, Aug 1, 2017 at 2:46 PM, Mark Koenig via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> I currently have an x310 with a ubx-40 in each of slots A and B.  I have
> one 10Gig Ethernet connection hooked up, and would like to receive on both
> channels A and B.
>
>
>
> I tried using the “rx_multi_samples” function, but I didn’t get a good
> feeling I was collecting on both channels.  I tried using the
> “rx_samples_to_file” function, but didn’t see a coherent collection on A
> and B, when setting the subdev to “A:0 B:0”.
>
> Finally, I tried the “uhd_fft”, and saw collection in channel A, but
> nothing from channel B, while setting subdev=”A:0 B:0”.
>
>
>
> Am I doing something incorrectly, or is there another function I should
> try?
>
>
>
> Thanks
>
>
>
> 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] How Do I get a py File Transferred Over to The E310

[Derek Kozel via USRP-users]

Hi Konstantin,

Mike's solution is one of the common answers. Mounting a network share or
remote file system are nice to streamline the process. Our application note
on developing with the E310 has an example of using sshfs to mount a
directory from a host computer onto the E310.
https://kb.ettus.com/Software_Development_on_the_E310_and_E312#Running_the_new_UHD_via_sshfs

Regards,
Derek

On Wed, Aug 2, 2017 at 3:55 PM, Michael Don via USRP-users <
usrp-users@lists.ettus.com> wrote:

>
> What I did was to set up an Ethernet connection and use winSCP for file
> transfer.
>
> https://files.ettus.com/manual/page_usrp_e3x0.html - setting up ethernet
> https://winscp.net/eng/index.php - winSCP
>
> -Mike
>
> On Tue, Aug 1, 2017 at 2:31 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN
> TECHNOLOGIES INC] via USRP-users  wrote:
>
>> To All,
>>
>>
>>
>> I realize this is a rookie question, but I looked all over on the net to
>> find the answer.
>>
>>
>>
>> First off, I realize that thGNU radio and UHD.
>>
>>
>>
>> So, I realize I need to create a pythin file offline via GNU radio
>> Companion on my laptop.  And of course, do not include any graphical
>> functions.
>>
>>
>>
>> I asl was able to connect to the E310 via the USB 2.0 through a Linux
>> terminal…  and when I do a pwd, I am at home/root.
>>
>>
>>
>> I realized cp and mv is the Linux way to copy and paste method for Linux.
>>
>>
>>
>> My question is what is the process to move my python file from the laptop
>> Linux directory to the E310 hardware via the USB 2.0 connection?
>>
>>
>>
>> Likewise, once I move it to a directory on the E310 hardware, do I just
>> type python grcFile.py to run the file on E310 hardware?
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Konstantin
>>
>> ___
>> 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] PPS sync with USRP E310 timeout error

[Derek Kozel via USRP-users]

Hi,

Sorry, I spoke poorly there. set_time_unknown_pps will fail if it does not
see a 1PPS edge within a 1+epsilon second window. However, because you were
using a sine wave the exact time that the "edge" of the pulse could vary.
When distributing a time reference a fast rising edge is key to getting
good temporal accuracy.

If you want to verify that both USRPs are set to the same time you should
call the get_time_last_pps function after setting the time on both
synchronously. The sync_to_gps code has a routine which would be useful.
https://github.com/EttusResearch/uhd/blob/maint/host/examples/sync_to_gps.cpp#L145

Regards,
Derek

On Wed, Aug 2, 2017 at 4:09 PM, Cho, Daniel J (332C) <
daniel.j@jpl.nasa.gov> wrote:

> Hello Derek,
>
>
>
> I thought the “set_time_unknown_pps” checks to confirm that the time is
> correctly set?
>
> If that doesn’t, how do I know that the sync is set correctly without
> using a spectrum analyzer?
>
>
>
> Thanks
>
>
>
> *From:* Derek Kozel [mailto:derek.ko...@ettus.com]
> *Sent:* Wednesday, August 2, 2017 7:33 AM
> *To:* Cho, Daniel J (332C) 
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] PPS sync with USRP E310 timeout error
>
>
>
> Hello Daniel,
>
> There is no check in your code to confirm that the time is correctly set.
> The 1PPS signal should be a square wave rather than a sine wave. It is a
> logic signal rather than an RF one and the sync port is designed to handle
> it.
> http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_hw_pps
>
> The Octoclock which we use produces a 20% duty cycle square wave with 5V
> high and 0V low.
>
>
>
> Regards,
>
> Derek
>
>
>
> On Wed, Aug 2, 2017 at 2:10 AM, Cho, Daniel J (332C) via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hello –
>
>
>
> I am using 2 USRP E310 which I would like to frequency sync together.  I
> am using a frequency generator which is generating a 1 PPS (1Hz sine wave)
> signal which I put through a power splitter to provide both USRPs with the
> same 1 PPS signal.  I configured the rx_samples_to_file and
> tx_samples_from_file codes to allow me to use the external 1PPS signal by
> including the following into the code:
>
>
>
> //sleep off if gpsdo detected and time next pps already set
>
> boost::this_thread::sleep(boost::posix_time::seconds(1));
>
> //set time source if specified
>
> if (not time_source.empty()) usrp->set_time_source(time_source);
>
> //set the time at an unknown pps (will throw if no pps)
>
> std::cout << std::endl << "Attempt to detect the PPS and set the time..."
> << std::endl << std::endl;
>
> usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));
>
> std::cout << std::endl << "Success!" << std::endl << std::endl;
>
>
>
> When I run the rx_samples_to_file code with the above code included, I get
> a timeout error.  I found that it was due to the line “usrp->
> set_time_unknown_pps(uhd::time_spec_t(0.0));”
>
> How can I get my two USRPs frequency synced without getting this error?
>
>
>
> Also, I saw that the 1 PPS signal provided to the USRP should be 3.3V –
> 5V.  When I put a 1 PPS signal that strong on the spectrum analyzer, it
> shows a power output above +10 dBm.  I know that the max RX input power is
> -15 dBm so I was hesitant to input a 1 PPS signal that strong.  The 1 PPS
> signal I put into the sync port was 100 mV.  Even with a 1 PPS signal with
> an output power of 100mV, I am still able to run the test_pps_input program
> successfully.
>
>
>
> So in summary, should I just send a 1 PPS signal with a power output above
> +10 dBm which equates to the 3.3V – 5V to the sync port even though I am
> able to run the test_pps_input program successfully with 100mV?  How can I
> get the rx_samples_to_file program to run successfully without giving me a
> timeout error using the above lines of code?
>
>
>
> 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] Support with UHD C++ API

[Derek Kozel via USRP-users]

Hello Snehasish,

The UHD examples contain all the code to receive a stream of samples at
that rate. What have you tried? We may be able to help better if you
explain what is not working. 50 MS/s is not too high of a load so most
recent computers should have no problem receiving that much data over a 10
Gigabit Ethernet connection.
https://github.com/EttusResearch/uhd/tree/maint/host/examples

Regards,
Derek

On Wed, Aug 2, 2017 at 8:39 PM, Snehasish Kar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello
>
>
> I am trying to receive the entire 25MHz gsm signal using usrp x310 at an
> sample rate of 50MSPS, which i need to receive in the host and send to the
> GPU for demodulation. Please help me how to implement this with minimum
> data loss.
>
>
> BR
>
> Snehasish
>
>
>
> ___
> 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] When ssh'ing Getting prompt for Password Issue

[Derek Kozel via USRP-users]

Hello Konstantin,

The download definitely works on Windows, Mac, and Linux so there must be
some issue with your VM that is causing the issue. That is probably beyond
what we can help with.

On Windows you can use 7zip to extract the xz archive and win32diskimager
for writing the filesystem image onto the SD card. Be careful to select the
correct drive when writing the image.
https://sourceforge.net/projects/win32diskimager/

Regards,
Derek

On Sun, Aug 6, 2017 at 8:51 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN
TECHNOLOGIES INC] via USRP-users  wrote:

> Nate,
>
> Thanks for the instructions...
>
> I am trying to download the tz file from the website using the VM Linux
> OS.  My browser locks up.
>
> I also did download the tx file in Windos, but I am unable to connect with
> the E310 via Ethernet over my Ethernet connection.
>
> Since the installation instructions commands are in Linux, would you
> please assist me as to why I cannot download the file via the VM?
>
> Thanks
>
> Konstantin
>
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com]
> Sent: Friday, August 04, 2017 12:30 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] <
> konstantin.j.math...@nasa.gov>
> Cc: Philip Balister ; usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>
> Hi Konstantin,
>
> In regards to the page not showing instructions, please copy and paste the
> full links listed below. If you note within the screenshot you posted, you
> have the URL of:
>
> "https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_Hardware_Resource";
>
> The full address is:
>
> "https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_
> Hardware_Resources#SD_Card_Images"
>
> In regards to the permission denied prompt that is being given in your
> terminal screenshot -- This is because the command that you are issuing
> "/etc/network/interfaces" is not valid. When you issue a command that is
> the path to a file such as that, the system is attempting to pass the file
> and execute it via the default shell (/bin/sh). I suspect you're attempting
> to edit the file, which can be done with the utility "vi", such as "vi
> /etc/network/interfaces".
>
> I would suggest starting with a fresh "release-4" image for the E310 at
> this point.
>
> You will need to download the .xz file of the release image for the speed
> grade of your device (details are in the link below for which SG you need
> based on the serial number), and then decompress it with a 7z (7zip) or
> other similar tool. You will then need to burn the image to the SD card,
> which can be done with WinDisk32Imager or the Linux utility "dd", or
> "bmaptool".
>
> The default setting for the "release-4" image will give the E310 a static
> IP address of 192.168.10.2. If you then put your VM NIC Settings into a
> Bridged Mode, and set a static IP Address within the VM to "192.168.1.3",
> you should be able to connect to the E310 with the root account and no
> password via SSH.
>
>
> https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_
> Getting_Started_Guides#Serial_Console_Connectivity
> http://files.ettus.com/e3xx_images/
> https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_
> Hardware_Resources#SD_Card_Images
>
>
>
> Regards,
> Nate Temple
>
>
>
> > On Aug 4, 2017, at 9:29 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN
> TECHNOLOGIES INC]  wrote:
> >
> > Nate,
> >
> > I am close to returning this unit.
> >
> > I feel that I am doing everything correctly…
> >
> > 1)  I setup the IP static address correctly in the interfaces via
> the serial cable – proof that I can ping to it from both Linux and Windows
> > 2)  I double checked both sshd_config files in E310 and Linux VM OS
> – both have the permission parameter to have no password for login.
> > 3)  VM is in network bridged mode too, as you suggested.
> >
> > When I hookup the Ethernet, I am able to ping, but when I do the ssh
> command to login, I am still getting the permission denied.
> >
> > Please tell me any last items to double check before I return the unit,
> or if I can get someone on the phone to assist me with this issue.
> >
> > Thanks,
> >
> > Konstantin
> >
> > From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC]
> > Sent: Friday, August 04, 2017 10:11 AM
> > To: 'Nate Temple' 
> > Cc: 'Philip Balister' ;
> > 'usrp-users@lists.ettus.com' 
> > Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password
> > Issue
> >
> > I did the following instructions on the Linux VM, not the E310….  Or
> > did I need to do it to both of them…
> >
> > Right now, I going to retract the VM interfaces alteration I did.
> >
> > These are the instructions I am referring to…
> >
> > https://files.ettus.com/manual/page_usrp_e3x0.html#e3xx_network_config
> > uration
> >
> >
> >
> > From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC]
> > Sent: Friday, August 04, 2017 10:07 AM
> > To: 'Nate Temple' 
> > Cc: 'Philip Balister' ;
> > 'usrp-u

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

[Derek Kozel via USRP-users]

Hi Konstantin,

We have no way of knowing what device the SD Card will enumerate as. There
are many guides online for using utilities like fdisk and dmesg to find the
name of the device.

Using Windows or Linux you will need to remove the micro SD card and use a
USB to micro SD card adapter to mount the disk on your host computer.

I'm sorry you are having such difficulty with the E310. There is a fair
amount of Linux knowledge which is assumed by the manuals and which is
necessary to use the E310 effectively. We can continue helping as possible,
but it will be faster and hopefully somewhat less frustrating to make use
of the many Linux guides available.

Here is one from SparkFun which covers Windows and Linux.
https://learn.sparkfun.com/tutorials/sd-cards-and-writing-images

Regards,
Derek

On Mon, Aug 7, 2017 at 4:42 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN
TECHNOLOGIES INC] via USRP-users  wrote:

>
> Nate,
>
> I was unsuccessful with the Windows approach mainly that the file
> downloaded is a tar
>
> When trying to use the Win32Image software, it did not find the drive to
> connect when I had the E310 hooked up via ethernet...  Even though I was
> able to ping to it through the NIC card.
>
> So, I came up with the option to create a shared drive between my Windows
> and Linux VM OS.  This took a little work to figure out, but now, I was
> able to move the unzipped tar file (done by Win7) to the VM Linux OS.
>
> Now, I can use the commands using this link...  My question is what should
> I use for
>
> http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_upgrade_sd_card
>
>  ?  is it /dev/sdb ?
>
> Thanks
>
> Konstantin
>
>
>
> -Original Message-
> From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC]
> Sent: Sunday, August 06, 2017 3:51 PM
> To: 'Nate Temple' 
> Cc: Philip Balister ; usrp-users@lists.ettus.com
> Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password Issue
>
> Nate,
>
> Thanks for the instructions...
>
> I am trying to download the tz file from the website using the VM Linux
> OS.  My browser locks up.
>
> I also did download the tx file in Windos, but I am unable to connect with
> the E310 via Ethernet over my Ethernet connection.
>
> Since the installation instructions commands are in Linux, would you
> please assist me as to why I cannot download the file via the VM?
>
> Thanks
>
> Konstantin
>
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com]
> Sent: Friday, August 04, 2017 12:30 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] <
> konstantin.j.math...@nasa.gov>
> Cc: Philip Balister ; usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>
> Hi Konstantin,
>
> In regards to the page not showing instructions, please copy and paste the
> full links listed below. If you note within the screenshot you posted, you
> have the URL of:
>
> "https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_Hardware_Resource";
>
> The full address is:
>
> "https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_
> Hardware_Resources#SD_Card_Images"
>
> In regards to the permission denied prompt that is being given in your
> terminal screenshot -- This is because the command that you are issuing
> "/etc/network/interfaces" is not valid. When you issue a command that is
> the path to a file such as that, the system is attempting to pass the file
> and execute it via the default shell (/bin/sh). I suspect you're attempting
> to edit the file, which can be done with the utility "vi", such as "vi
> /etc/network/interfaces".
>
> I would suggest starting with a fresh "release-4" image for the E310 at
> this point.
>
> You will need to download the .xz file of the release image for the speed
> grade of your device (details are in the link below for which SG you need
> based on the serial number), and then decompress it with a 7z (7zip) or
> other similar tool. You will then need to burn the image to the SD card,
> which can be done with WinDisk32Imager or the Linux utility "dd", or
> "bmaptool".
>
> The default setting for the "release-4" image will give the E310 a static
> IP address of 192.168.10.2. If you then put your VM NIC Settings into a
> Bridged Mode, and set a static IP Address within the VM to "192.168.1.3",
> you should be able to connect to the E310 with the root account and no
> password via SSH.
>
>
> https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_
> Getting_Started_Guides#Serial_Console_Connectivity
> http://files.ettus.com/e3xx_images/
> https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_
> Hardware_Resources#SD_Card_Images
>
>
>
> Regards,
> Nate Temple
>
>
>
> > On Aug 4, 2017, at 9:29 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN
> TECHNOLOGIES INC]  wrote:
> >
> > Nate,
> >
> > I am close to returning this unit.
> >
> > I feel that I am doing everything correctly…
> >
> > 1)  I setup the IP static address correctly in the interfaces via
> the serial cable 

Re: [USRP-users] PPS and REF out form a X310 and leakage problem

[Derek Kozel via USRP-users]

Hello Jorge,

The Octoclock is sold in two versions, one with an internal GPSDO and one
that requires an external source.

The X310 and X300 both do not support daisy chaining. There are a few
issues with it, one of the key ones being propagation delay. If the 1PPS
signal was passed from one unit to the next again and again it would arrive
at the different USRPs at different times, ruining synchronization.

The configuration should work with one of the X310s supplying the 10 MHz
and 1 PPS. However it would be better to have the Octoclock's 10 MHz and
1PPS outputs connected to all four of the X310s. The X310 will always
output it's signals so can still be used as the source but by using the
external reference on all USRPs the 1PPS signals will be aligned at all
units rather than having the master be earlier than the others due to
propagation delays.

Do you see the PPS light flashing on the Octoclock? What do the other
lights show?

Which USRP is failing to synchronize? If you only try to synchronize the
slave USRPs does that work?

Regards,
Derek

On Mon, Aug 7, 2017 at 3:28 PM, Jorge Chen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all
>
>
>
> I’d like to build up 8X8 MIMO system using 4 USRP X310.
>
> To synchronize time&freq. between all of them, I used to use a function
> generator to feed both 1 PPS and 10 MHz reference clock to them.
>
> Today, I got an Octoclock which I thought it is able to provide both
> synchronization signal, but it is said that “For the OctoClock, there is
> no internal timing or clocking source, so the OctoClock will always use
> external 10 MHz and 1 PPS sources, regardless of the position of the switch.”
> in the UHD manual.
>
>
>
> So, I plan to use one of the X310 to feed the synchronization signal to
> the Octoclock REF&PPS input and connect other X310s to the REF&PPS output,
> like the block diagram below.
>
>
>
> [image: 內置圖片 1]
>
> 1.
>
> I use the LTS version of UHD (3.9.6).
>
> And I use the commands like:
>
>  //Lock mboard clocks
>
>  tx_usrp->set_clock_source("internal",0);
>
>  tx_usrp->set_clock_source("external",1);
>
> But it always show the error message:
>
> Error: RuntimeError: Reference Clock PLL failed to lock to external source.
>
>
>
> I wonder if the commands or my thought were wrong or this function is not
> supported?Because I found some discussions (March, 2017) in the mailing
> list talked about the X310 is not supported for daisy-chaining. By the way,
> is X300 not supported neither?
>
>
>
>
>
> 2.
>
> The other problem is that when I use a terminator to terminate the TX/RX
> port, I can still discover the signal through the spectrum analyzer by
> connecting an antenna. Is the signal leaked from somewhere? And how to
> prevent it?
>
>
>
>
>
> Thanks in advance!
>
> 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] When ssh'ing Getting prompt for Password Issue

[Derek Kozel via USRP-users]

Hello,

Yes, a micro SD card adapter is needed. I'm going to add to our
documentation to highlight that point. There is no way to overwrite the
entire SD remotely. This is true for nearly every embedded system.

We do not have any recommended micro SD card adapter. There are many from
good brands such as Kingston, Anker, and Transcend on Amazon. I have yet to
encounter an adapter which will not work, including the $2 Kingston one. I
use a USB3 one which supports many different card formats.

Regards,
Derek

On Mon, Aug 7, 2017 at 5:08 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN
TECHNOLOGIES INC]  wrote:

> Again… This was not explained clearly….
>
>
>
> Are you stating I need a micro SD Card adapter/burner to do this?
>
>
>
> I thought I just leave it hooked up to the E310 with the SD card in it and
> this can be done?
>
>
>
> Please clarify… And if I do need a burner, which one do you suggest I buy…
>
>
>
> Thanks….
>
>
>
>
>
>
>
>
>
> *From:* Derek Kozel [mailto:derek.ko...@ettus.com]
> *Sent:* Monday, August 07, 2017 12:03 PM
> *To:* Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] <
> konstantin.j.math...@nasa.gov>
> *Cc:* Nate Temple ; usrp-users@lists.ettus.com
>
> *Subject:* Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>
>
>
> Hi Konstantin,
>
> We have no way of knowing what device the SD Card will enumerate as. There
> are many guides online for using utilities like fdisk and dmesg to find the
> name of the device.
>
> Using Windows or Linux you will need to remove the micro SD card and use a
> USB to micro SD card adapter to mount the disk on your host computer.
>
> I'm sorry you are having such difficulty with the E310. There is a fair
> amount of Linux knowledge which is assumed by the manuals and which is
> necessary to use the E310 effectively. We can continue helping as possible,
> but it will be faster and hopefully somewhat less frustrating to make use
> of the many Linux guides available.
>
> Here is one from SparkFun which covers Windows and Linux.
> https://learn.sparkfun.com/tutorials/sd-cards-and-writing-images
>
>
>
> Regards,
>
> Derek
>
>
>
> On Mon, Aug 7, 2017 at 4:42 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN
> TECHNOLOGIES INC] via USRP-users  wrote:
>
>
> Nate,
>
> I was unsuccessful with the Windows approach mainly that the file
> downloaded is a tar
>
> When trying to use the Win32Image software, it did not find the drive to
> connect when I had the E310 hooked up via ethernet...  Even though I was
> able to ping to it through the NIC card.
>
> So, I came up with the option to create a shared drive between my Windows
> and Linux VM OS.  This took a little work to figure out, but now, I was
> able to move the unzipped tar file (done by Win7) to the VM Linux OS.
>
> Now, I can use the commands using this link...  My question is what should
> I use for
>
> http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_upgrade_sd_card
>
>  ?  is it /dev/sdb ?
>
> Thanks
>
> Konstantin
>
>
>
> -Original Message-
> From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC]
> Sent: Sunday, August 06, 2017 3:51 PM
> To: 'Nate Temple' 
> Cc: Philip Balister ; usrp-users@lists.ettus.com
> Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password Issue
>
> Nate,
>
> Thanks for the instructions...
>
> I am trying to download the tz file from the website using the VM Linux
> OS.  My browser locks up.
>
> I also did download the tx file in Windos, but I am unable to connect with
> the E310 via Ethernet over my Ethernet connection.
>
> Since the installation instructions commands are in Linux, would you
> please assist me as to why I cannot download the file via the VM?
>
> Thanks
>
> Konstantin
>
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com]
> Sent: Friday, August 04, 2017 12:30 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] <
> konstantin.j.math...@nasa.gov>
> Cc: Philip Balister ; usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>
> Hi Konstantin,
>
> In regards to the page not showing instructions, please copy and paste the
> full links listed below. If you note within the screenshot you posted, you
> have the URL of:
>
> "https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_Hardware_Resource";
>
> The full address is:
>
> "https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_
> Hardware_Resources#SD_Card_Images"
>
> In regards to the permission denied prompt that is being given in your
> terminal screenshot -- This is because the command that you are issuing
> "/etc/network/interfaces" is not valid. When you issue a command that is
> the path to a file such as that, the system is attempting to pass the file
> and execute it via the default shell (/bin/sh). I suspect you're attempting
> to edit the file, which can be done with the utility "vi", such as "vi
> /etc/network/interfaces".
>
> I would suggest starting with a fresh "release-4" ima

Re: [USRP-users] XCVR2450 with X310

[Derek Kozel via USRP-users]

Hello Jon,

As you have found in the documentation and see in the output of
uhd_usrp_probe, the XCVR2450 is not supported on the X3x0 family. We are
sorry this is true, but we do not have any current timeline for adding this
support nor do we have any advice right now to give for what changes would
be needed to add the support. The architecture of the second and third
generation USRPs differ in a few ways which mean that the daughterboards
are not always plug and play between the generations. The error you are
seeing has to do with the frequency reference clock being sent to the
daughterboard.

Regards,
Derek

On Tue, Aug 8, 2017 at 4:56 AM, liu Jong via USRP-users <
usrp-users@lists.ettus.com> wrote:

> HI all,
> We run command uhd_usrp_probe,output as below:
>
> -- X300 initialization sequence...
> -- Determining maximum frame size... 1472 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1185.3MB/s)
> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1176.6MB/s)
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
>
> UHD Error:
> The daughterboard manager encountered a recoverable error in init.
> Loading the "unknown" daughterboard implementations to continue.
> The daughterboard cannot operate until this error is resolved.
> RuntimeError: NotImplementedError: x3xx set dboard clock rate does not
> support changing the clock rate
> -- Performing timer loopback test... pass
>
> UHD Error:
> The daughterboard manager encountered a recoverable error in init.
> Loading the "unknown" daughterboard implementations to continue.
> The daughterboard cannot operate until this error is resolved.
> RuntimeError: NotImplementedError: x3xx set dboard clock rate does not
> support changing the clock rate
> -- Performing timer loopback test... pass
>  _
>  /
> |   Device: X-Series Device
> | _
> |/
> |   |   Mboard: X310
> |   |   revision: 24
> |   |   revision_compat: 7
> |   |   product: 30818
> |   |   mac-addr0: 00:80:2f:23:41:c5
> |   |   mac-addr1: 00:80:2f:23:41:c6
> |   |   gateway: 192.168.10.1
> |   |   ip-addr0: 192.168.100.2
> |   |   subnet0: 255.255.255.0
> |   |   ip-addr1: 192.168.20.2
> |   |   subnet1: 255.255.255.0
> |   |   ip-addr2: 192.168.30.2
> |   |   subnet2: 255.255.255.0
> |   |   ip-addr3: 192.168.40.2
> |   |   subnet3: 255.255.255.0
> |   |   serial: 30B867A
> |   |   FW Version: 5.0
> |   |   FPGA Version: 33.0
> |   |   RFNoC capable: Yes
> |   |
> |   |   Time sources:  internal, external, gpsdo
> |   |   Clock sources: internal, external, gpsdo
> |   |   Sensors: ref_locked
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: XCVR2450, XCVR2450 - r2.1 (0x0061)
> |   |   |   Serial: 30656DD
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 0
> |   |   |   |   Name: Unknown (0x) - 0
> |   |   |   |   Antennas:
> |   |   |   |   Sensors:
> |   |   |   |   Freq range: 0.000 to 0.000 MHz
> |   |   |   |   Gain Elements: None
> |   |   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Codec: A
> |   |   |   |   Name: ads62p48
> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
>
>
>
> uhd version:003.010.001.000
>
> Any suggestion is welcome
>
> 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] Problems receiving valid data from a multi_usrp

[Derek Kozel via USRP-users]

Hi Janos,

The problem is that the single rx_streamer is trying to time align the
samples from the four USRPs, but the onboard clocks are not aligned so it
is not finding samples from the same moment. Are you sharing 10 MHz and
1PPS references to all the USRPs? If so you will need to set the clock and
time sources to external and set the USRPs times synchronously. Take a look
at rx_multi_samples.
https://github.com/EttusResearch/uhd/blob/maint/host/examples/rx_multi_samples.cpp#L97

You can also just set the times asynchronously and the large window (67936
packets in your case) is meant to be wide and catch the coarsely aligned
samples. This will result in the four streams pretending to be
synchronized, but keep in mind that the actual time offsets between samples
with the same timestamp will all depend on the computer and network
latencies.

Regards,
Derek

On Wed, Aug 9, 2017 at 8:08 AM, Janos Buttgereit via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello everyone,
>
> I’m an electrical engineering master-degree student from Münster, Germany.
> We have some Ettus devices round here at FH Münster, that were only used
> with GNU Radio until now, but for a bigger project I now try to use the UHD
> C++ API for the first time to build a custom (and hopefully fast) C++
> application. For this application I need four RF Input streams, coming from
> four USRP N120. To achieve this, I bundle them into one multi_usrp object.
> I pasted the relevant lines of code including some comments to a gist to
> keep this email as short as possible - please take a look here:
> https://gist.github.com/JanosGit/5273a550867ef1d966741b6e93cacd55
>
> The application is developed on Mac OS X at the moment but with
> cross-platform compatibility in mind - probably it will be ported to Linux
> sooner or later.
>
> Now, the way I currently set everything up no samples ever get received,
> the call to rxStream->recv blocks for about a minute before an error
> message is printed to the command line:
>
> *UHD Error:*
>
> *The receive packet handler failed to time-align packets.*
>
> *67936 received packets were processed by the handler.*
>
> *However, a timestamp match could not be determined.*
>
> This also happens if I try to use only three or two channels, however,
> when I put just *one* channel into the streamArgs.channel vector,
> continuos receiving will work.
>
> But even if no error is thrown in the one-channel-setup, valid data will
> only be received if I pass channel 0 to the streamArgs.channels vector. For
> test purposes, I connected an oscillator to all four receivers, if I
> receive channel 0, a sine wave appears, but if I put any other channel
> index first into the channel vector, there is something looking like a
> dc-block-capacitor from the analogue front-end charging. I plotted (real
> samples only) both scenarios to make this clear:
>
>
> I tried connecting the oscillator to every possible port of all four
> devices, but I only get this charging curve from all receivers except for
> device 0. I also get a similar curve from device 0 if I disconnect the
> oscillator and just leave the RF port open, so it seems to me as if this is
> the usual response from an open rf port. Now if I swap the IP-Adresses
> passed to multi_usrp::make, so that a different hardware device will
> become channel 0, it stays the same - I’m able to receive valid data from
> channel 0, no matter which hardware device is channel 0 and all other
> channels will provide me the same curve. This makes me sure that it’s no
> hardware error, I got all four hardware devices delivering valid samples as
> long as their IP address is the first one passed to  multi_usrp::make.
>
> I’m not sure if both errors I described are related or if there are two
> completely different reasons for them. Anyway, I’d be glad if you would
> check the pasted code snippet for errors.
>
> And just for your information, I won’t have access to the USRPs for the
> next 2 weeks, but it would be great if I came back in 2 weeks to continue
> working with some fresh ideas and hopefully a solution.
>
> Best regards
> Janos
>
> ___
> 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] Problems receiving valid data from a multi_usrp

[Derek Kozel via USRP-users]

If you do not need any time synchronization then you can use four separate
rx_streamers.

The time source (and clock source) will default to internal. Do you have
MIMO cables between the N210s? Given that you have four that won't save you
from having to have a separate external 10 MHz and PPS to synchronize all
four. I would recommend keeping everything internal or everything external
to start with. This does not seem to account for all four USRPs.
https://gist.github.com/JanosGit/5273a550867ef1d966741b6e93cacd55#file-multi_usrp_error-cpp-L45

What daughterboards do you have installed?

I believe there is a problem in your interpretation of the channels vector.
I think you need to set the subdev spec to "A:0 A:0 A:0 A:0" for four
USRPs. I don't have the hardware on hand to replicate this but provides the
context for "channel 2" to mean something. When you are back with your
hardware that should be quick to try out. uhd_fft is a good utility for
quickly trying these combinations of subdevice spec and channel indexes. I
don't know why you get a (very low magnitude) ramp function.

Derek

On Thu, Aug 10, 2017 at 12:27 PM, Janos Buttgereit <
janos.buttger...@fh-muenster.de> wrote:

> Hi Derek,
>
> thanks for your reply. No, I didn’t share a 10MHz and a PPS reference for
> all four receivers, although we own an OctoClock that should be able to
> easily provide these clocks. I assumed that the multi usrp would be aware
> of the fact that it can not expect any synchronized data when all device
> clocks were configured as internal and so wouldn’t even try to synchronize
> samples. This would have been perfectly okay for me for a first run where
> just collecting any multichannel data was the only goal.
>
> However at some point I also thought of a synchronization error while
> trying to get it working yesterday and so I tried breaking the setup down
> to two receivers linked by a mimo cable. I called
> usrp->set_clock_source („internal“, 0);
> usrp->set_clock_source („mimo“, 1);
>
> to get the second device in sync with the first one. Now when looking at
> the code you linked there is also a setup like this, but the
> clock-source-settings which seem comparable to my approach are followed by
> usrp->set_time_source("mimo", 1);
> //set time on the master (mboard 0)
> usrp->set_time_now(uhd::time_spec_t(0.0), 0);
>
> So I expect setting the time source is what I missed?
> I’ve updated my gist - is it likely that these changes will fix my error
> https://gist.github.com/JanosGit/5273a550867ef1d966741b6e93cacd
> 55#file-multi_usrp_error-cpp-L38 ?
>
> Would you expect this to also solve the other problem regarding receiving
> unusable data from all but the first device illustrated by the image pasted
> in the original mail or is this still another different problem?
>
> Regards,
> Janos
>
> Am 09.08.2017 um 17:44 schrieb Derek Kozel :
>
> Hi Janos,
>
> The problem is that the single rx_streamer is trying to time align the
> samples from the four USRPs, but the onboard clocks are not aligned so it
> is not finding samples from the same moment. Are you sharing 10 MHz and
> 1PPS references to all the USRPs? If so you will need to set the clock and
> time sources to external and set the USRPs times synchronously. Take a look
> at rx_multi_samples.
> https://github.com/EttusResearch/uhd/blob/maint/host/examples/rx_multi_
> samples.cpp#L97
>
> You can also just set the times asynchronously and the large window (67936
> packets in your case) is meant to be wide and catch the coarsely aligned
> samples. This will result in the four streams pretending to be
> synchronized, but keep in mind that the actual time offsets between samples
> with the same timestamp will all depend on the computer and network
> latencies.
>
> Regards,
> Derek
>
> On Wed, Aug 9, 2017 at 8:08 AM, Janos Buttgereit via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello everyone,
>>
>> I’m an electrical engineering master-degree student from Münster,
>> Germany. We have some Ettus devices round here at FH Münster, that were
>> only used with GNU Radio until now, but for a bigger project I now try to
>> use the UHD C++ API for the first time to build a custom (and hopefully
>> fast) C++ application. For this application I need four RF Input streams,
>> coming from four USRP N120. To achieve this, I bundle them into one
>> multi_usrp object. I pasted the relevant lines of code including some
>> comments to a gist to keep this email as short as possible - please take a
>> look here: https://gist.github.com/JanosGit/5273a550867ef1d966741
>> b6e93cacd55
>>
>> The application is developed on Mac OS X at the moment but with
>> cross-platform compatibility in mind - probably it will be ported to Linux
>> sooner or later.
>>
>> Now, the way I currently set everything up no samples ever get received,
>> the call to rxStream->recv blocks for about a minute before an error
>> message is printed to the command line:
>>
>> *UHD Error:*
>>
>> *The receive p

Re: [USRP-users] Multiple RX channels on X310

[Derek Kozel via USRP-users]

Hello Daniele,

If you run uhd_usrp_probe you will see a list of the supported frontends.
The example is for the TVRX2 daughterboard which you are probably not
using. The most common subdev specifications for a single X310 are "A:0
B:0" (First channel of each daughtercard)  and "A:0 A:1 B:0 B:1" (Each of
the four channels of a pair of TwinRX daugherboards).

Regards,
Derek

On Fri, Aug 11, 2017 at 11:24 AM, Disco Daniele via USRP-users <
usrp-users@lists.ettus.com> wrote:

> How to select multiple channel on X310.
>
> On the manual https://files.ettus.com/manual/page_usrp_x3x0.html is
> reported
>
> usrp->set_rx_subdev_spec("A:RX1 A:RX2");
>
> but the program stops with error:
>
> Error: RuntimeError: Invalid daughterboard frontend name : RX1
>
>
>
> Daniele
> 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] UHD Version for New UBX Hardware Rev

[Derek Kozel via USRP-users]

Hello Dave,

This commit added the EEPROM IDs for the updated UBX version.
https://github.com/EttusResearch/uhd/commit/f5a082fd3841571d2a53a9e677b5dfe6d653bd94

It was added August 22nd and 3.9.5 has it. I believe there have been a few
improvement changes since then which are on the 3.9 branch, but basic
support would start from 3.9.5.

Regards,
Derek

On Tue, Aug 15, 2017 at 3:47 PM, Dave NotTelling via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I got a UBX-40 that wouldn't work in my N210 and I remembered seeing
> something on the forums about the older UHD versions not working for the
> new UBX-40 rev.  What is the oldest version of UHD that is guaranteed to
> work with the new UBX-40 rev?  I was running 3.9.4 and when I upgraded to
> 3.9.7 things worked again.  The thing that tipped me off was that the
> UBX-40 didn't show up properly in uhd_usrp_probe.
>
> 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] Receiver Sensitivity of NI USRP 2954R

[Derek Kozel via USRP-users]

Hello Snehasish,

Here is the performance data for the UBX daughtercard and X3x0. The
sensitivity changes with frequency and gain.
http://files.ettus.com/performance_data/ubx/UBX-without-UHD-corrections.pdf

Regards,
Derek

On Wed, Aug 16, 2017 at 8:14 AM, Snehasish Kar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello
>
> What is the Receiver sensitivity of NI USRP 2954R?
>
> BR
> Snehasish
>
> ___
> 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] Support with setting usrp sampling rate to 150MSPS

[Derek Kozel via USRP-users]

Try 200MS/s. The FPGA can only decimate integer amounts from the ADC rate,
which is 200MS/s.

On Tue, Aug 22, 2017 at 5:15 PM, Snehasish Kar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello
> I am trying to receive gsm 1800 band using NI USRP 2954R, but when I am
> trying to set the sampling rate of uhd_source in gnuradio to 150 MSPS, it's
> giving an error message saying hardware does not support sampling rate
> above 100MSPS.
>
> Please help!
>
> BR
> Snehasish
> ___
> 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] Support with setting usrp sampling rate to 150MSPS

[Derek Kozel via USRP-users]

Hello Koyel,

This is a fundamental problem that increasing sample rate takes more
processing power to handle but provides more bandwidth of spectrum. How
wide is the signal you need to process? The general recommendation is that
you sample at 1.25 times your bandwidth. This provides 20% more spectrum
than is necessary, but means that your signal is minimally affected by the
digital filters used in the decimation in the FPGA. This is part of how the
160 MHz bandwidth of the UBX is derived from the 200 MHz sampling rate of
an X310 (what is inside the 2954R).

The default FPGA image is limited to integer decimation rates as described
in the manual.
http://files.ettus.com/manual/page_general.html#general_sampleratenotes

GSM 1800 covers 170 MHz so even with the full sampling rate the outermost
edges will be attenuated by both the analog filters and the digital
filters. If you only want to look at the uplink or downlink individually
then you can observe the 75 MHz bandwidth with 100 MS/s and easily meet the
recommended maximum of 80% occupied bandwidth.

For non-integer decimation rates such as 200e6/150e6 = 4/3 you would have
to implement a rational resampler as a custom RFNoC block to support that
decimation rate, certainly possible but additional work.

Regards,
Derek

On Wed, Aug 23, 2017 at 7:17 AM, Koyel Das  wrote:

> Hi,
>
> Many thanks for your reply. Yes 200 MSps works.
>
> But taking 200 MSps will increase the amount of data considerably and
> increase the processing time and very less amount of data is decoded from
> large amount of input samples compared to lower sampling frequencies. What
> is the solution to these problems?
>
> Regards,
> Koyel
>
> On Tue, Aug 22, 2017 at 9:14 PM, Snehasish Kar 
> wrote:
>
>> Ok I will try that.
>>
>> BR
>> Snehasish
>>
>> On 22-Aug-2017, at 8:51 PM, Derek Kozel  wrote:
>>
>> Try 200MS/s. The FPGA can only decimate integer amounts from the ADC
>> rate, which is 200MS/s.
>>
>> On Tue, Aug 22, 2017 at 5:15 PM, Snehasish Kar via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello
>>> I am trying to receive gsm 1800 band using NI USRP 2954R, but when I am
>>> trying to set the sampling rate of uhd_source in gnuradio to 150 MSPS, it's
>>> giving an error message saying hardware does not support sampling rate
>>> above 100MSPS.
>>>
>>> Please help!
>>>
>>> BR
>>> Snehasish
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>
>
> --
>
> Koyel Das
>
> Senior Product Engineer
>
> Vehere | Proactive Communications Intelligence & Cyber Defence
>
> M: +919051132173 <+91%2090511%2032173> | T: +91 33 24008400
> <+91%2033%202400%208400> | F: +91 33 247988100 | W: www.vehere.com
>
>
> Vehere is the proud recipient of the Fastest Growing Technology Company
> Awards in India & Asia since 2012!
>
>
> The content of this e-mail is confidential and intended solely for the use
> of the addressee. The text of this email (including any attachments) may
> contain information, which is proprietary and/or confidential or privileged
> in nature belonging to Vehere Interactive Pvt Ltd and/or its associates/
> group companies/ subsidiaries. If you are not the addressee, or the person
> responsible for delivering it to the addressee, any disclosure, copying,
> distribution or any action taken or omitted to be taken in reliance on it
> is prohibited and may be unlawful. If you have received this e-mail in
> error, please notify the sender and remove this communication entirely from
> your system. The recipient acknowledges that no guarantee or any warranty
> is given as to completeness and accuracy of the content of the email. The
> recipient further acknowledges that the views contained in the email
> message are those of the sender and may not necessarily reflect those of
> Vehere Interactive Pvt Ltd. Before opening and accessing the attachment
> please check and scan for virus. WARNING: Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
>
>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] How to use RFNoC framework with LFRX daughter board?

[Derek Kozel via USRP-users]

Hello,

Can you please paste a copy of the full output, including the command, for
uhd_usrp_probe? That will include a lot of information which we can use to
offer advice.

Thanks,
Derek

On Wed, Aug 30, 2017 at 11:21 AM, L TP via USRP-users <
usrp-users@lists.ettus.com> wrote:

>
> Hi List,
> I'm trying to use X310 and LFRX daughter board on RFNoC frame work.
> I attached UBX and LFRX boards on X310 and run command "uhd_usrp_probe"
> and found that the app didn't detect antenna of LFRX, so my app can't show
> signal from it.
>
> Could you help me, please?
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] uhd_rx_nogui gets really noisy!

[Derek Kozel via USRP-users]

Hello Ali,

You have not set a gain value in your command. You can check the GRC
example to find the default gain or try values until you see a strong
signal.

Regards,
Derek

On Sat, Sep 9, 2017 at 9:59 AM, Ali The GREAT! via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear all,
>
> I installed GR and UHD and everything works properly in GRC
> but as i wanted to give "uhd_rx_nogui" a try i received a badly noisy
> sound!
>
> the command is this:
> $uhd_rx_nogui -f 104e6 -m FM -A TX/RX
>
> i am using b200mini and i can receive FM via GRC!
> i searched a lot but nothing!
>
> (by the way:
> $gnuradio-config-info -v
> 3.7.12git-231-gefcfde0e
> $uhd_config_info
> linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_003.010.002.000-0-
> gbd6e21dc
> and the OS is ubuntu 16.04, 64-bit
> )
>
> thanks in advance
> regards
> Ali
>
> ___
> 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] 4 Rx channels from an X310

[Derek Kozel via USRP-users]

Hello Joshua,

The default FPGA image now has two DDCs which each have two DSP chains. The
message you link to is from 2014 and we've substantially updated the
contents of the FPGA since then. Currently the TwinRX is the primary
daughtercard making use of these additional DDC chains as the others are
1RX per daughtercard.

Regards,
Derek

On Tue, Sep 12, 2017 at 3:15 AM, Josh Sendall via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I have been looking through some previous posts on the mailing list, for
> example [USRP-users] subdev spec for two channels with USRP X310
> 
> which suggests that it should not be possible to receive 4 channels (with
> the standard FPGA image and UHD) on an X300/X310, due to them only having 2
> DDC blocks.
>
> However I then saw this project 
> (gr-doa),
> which seems to suggest that, using the standard FPGA image, one can run 4
> channels using 2 TwinRx daughter boards. Would that not still require 4 DDC
> blocks, or can a DDC block be configured to process 2 real streams?
>
> Kind regards,
> Joshua Sendall
>
>
> *Joshua Sendall*
> *Radar Signal Analyst*
> Defense, Peace, Safety and Security (DPSS)
> Council for Scientific and Industrial Research (CSIR)
> Building 44 - Room C 433
> CSIR, Meiring Naude Road, Pretoria
> Tel: *012 841 3575*
>
>
> --
> This message is subject to the CSIR's copyright terms and conditions,
> e-mail legal notice, and implemented Open Document Format (ODF) standard.
> The full disclaimer details can be found at http://www.csir.co.za/
> disclaimer.html.
>
> Please consider the environment before printing this email.
>
> ___
> 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 STREAM_MODE_NUM_SAMPS_AND_DONE length limitation

[Derek Kozel via USRP-users]

That assertion is protecting a register in the Radio Block on the FPGA. You
could try modifying that area of the logic which is counting the outputted
samples as they are packetized. I do not believe that other areas of the
code would be impacted (other than that assertion in the host code of
course).

While the continuous mode is less convenient when you need a very specific
number of samples it does not require very much helper code to receive any
arbitrary number of samples and flush any excess ones away. The overhead of
doing so is minimal when only done once every few seconds.

A related note to be aware of is that the num_samps value is actually at
the radio clock sample rate not the final sample rate, so if the DDC is
used to lower the sample rate then the maximum number of samples which can
be received with STREAM_MODE_NUM_SAMPS_AND_DONE is reduced by the
decimation factor.

Regards,
Derek

On Fri, Sep 29, 2017 at 7:53 AM, Vladimir via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> Trying to save more than 2 sec trace with X300 at Fsamp = 100MHz, I
> encounter some block length limit of 0x0fff = 268.4 MSamps, which means
> only 2.6 sec of time. A bit surprised to see this in 64-bit environment...
> The assertion is in module rx_vita_core_3000.cpp:
>
> UHD_ASSERT_THROW(stream_cmd.num_samps <= 0x0fff);
>
> Is this some physical limit, or it can be patched to a larger value? It's
> kind of inconvenient to solve this through continuous streaming when you
> need a trace of a certain length...
>
> Vladimir
>
>
>
> ___
> 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] the rfnoc fifos

[Derek Kozel via USRP-users]

Hi Jason,

Adding FIFOs adds buffering which helps with any transient changes in
throughput, such as over the 10 GigE connection. It gives the flow control
more room to work with before an overflow occurs (on receive). On the
transmit side the DMA FIFO usually fills that role.

On Fri, Sep 29, 2017 at 4:12 AM, Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> OK, thanks Martin.  I guess I am still confused though (no surprise
> there).  You say that they're "generally useful."  In what way?  If I have
> a flow graph that has 3 RFNoC blocks, what is the benefit of adding a FIFO
> or two to it?
>
> Thanks!
>
>
>
> On 09/28/2017 03:10 PM, Martin Braun via USRP-users wrote:
>
> On Wed, Sep 27, 2017 at 01:42:22PM -0400, Jason Matusiak via USRP-users wrote:
>
> OK, dumb question, but I just can't come up with a good answer.  I
> understand that the RFNoC FIFOs are a must if you only have one NoC block
> that you want to use and are using the GNURadio host [1].  So why do pretty
> much most of the examples ALWAYS have at least one, and why would I want to
> fill my bitfile with FIFOs, why not just use one?
>
> Note that this is a gr-ettus limitation, not RFNoC. And also, you only
> need FIFOs if you have only a single block (PC -> Block -> PC).
>
> And you don't need to fill up with FIFOs, they're just generally useful
> and thus we have that option.
>
> -- M
>
>
>
>
> ___
> 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] Advise on how to modifying HDL design E310 to add custom blocks

[Derek Kozel via USRP-users]

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/6996ed662e5ae170e60ab8cb6de54c362cecf8d2/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
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] uhd_usrp message return and Comms issues

[Derek Kozel via USRP-users]

Hello Mark,

It has been some time since I have looked at the probe routine in the 3.8
version of UHD, but it sounds like the discovery packets are having routing
problems. Do you have an N210, N200, or USRP2 anywhere on the network?

We can probably give some assistance to discovering the root cause of those
messages, but it sounds like your real issue is that the retunes are taking
longer than you expect. How long are they taking? How are you measuring the
retune time? What daughtercard are you using?

We usually find that if you are running Centos and an older version of UHD
means that updating is not possible or prohibitively difficult. It does
bear saying that the X310 and daughtercard code bases have advanced over
the past two years. The UHD 3.9 branch provides a nice middle ground where
you can get access to many of these updates without large architectural
changes.

Regards,
Derek

On Mon, Sep 25, 2017 at 4:09 PM, Mark Koenig via USRP-users <
usrp-users@lists.ettus.com> wrote:

> When I run the “uhd_usrp_probe” command I receive an interesting message
> prior to getting all of the information returned.  It is listed below.  I
> am having communication issues with the USRP X310 when changing
> frequencies, as it is taking much longer to retask the X310 than I would
> assume and therefor during my scan some frequencies are being missed.  I am
> using the 10gig bit Ethernet port, with a Chelsio card on a server running
> CentOS 6.5 with UHD rev 003.008.004.
>
>
>
> Any suggestions would be much appreciated.
>
>
>
> Thanks
>
>
>
> UHD  Error:
>
> X300 Network discovery error send_to:  Network is
> unreachable
>
>
>
> UHD  Error:
>
> X300 Network discovery error send_to:  Network is
> unreachable
>
>
>
> UHD  Error:
>
> USRP2 Network discovery error send_to:  Network is
> unreachable
>
>
>
> UHD  Error:
>
> USRP2 Network discovery error send_to:  Network is
> unreachable
>
> -- X300 initiallization sequence…
>
>
>
> Then the rest of the output is the usrp and daughtercard information,
> which is all correct.
>
>
>
>
>
> ___
> 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] warning on UDP buffer size when using Python API

[Derek Kozel via USRP-users]

Hello,

The requested sizes do change a little during the initialization. Also the
settings are not persistent across reboots of your host computer so need to
be re-appled each time you restart or changes made to other configuration
files to make them persistent.

Can you confirm which sizes you are using in your commands at the moment?
For each of the read and write settings you should use the largest size
listed, no warnings should be displayed after that. You can try running
benchmark_rate which is a C++ program to test if this is a Python specific
issue or just a settings problem.

Derek

On Mon, Sep 25, 2017 at 6:41 PM, Osvaldo Alcala (Ozzie) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Im just running the sample python API script to capture samples from the
> receiver. Im using an X310.
>
> I tried running the script directly from command line to make sure nothing
> was changed and I still got the same warning. It’s a bit strange that when
> I change the buffer size to what is requested, it still asks for different
> buffer size. Something changes, but not sure why, as I try to keep
> everything exactly the same in the system.
>
> Any other ideas would be useful
>
> Thank yoU!
>
> O
>
> -Original Message-
> From: Andrej Rode [mailto:m...@andrejro.de]
> Sent: Friday, September 22, 2017 1:56 PM
> To: Osvaldo Alcala (Ozzie) 
> Cc: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] warning on UDP buffer size when using Python API
>
> Hi,
>
> On Fri, Sep 22, 2017 at 08:38:32PM +, Osvaldo Alcala (Ozzie) wrote:
> > Thank you. I should have said that I did try the command that shows in
> the screenshot, but the required buffer size keeps changing: thus I get the
> same error every time.
>
> So maybe in your script/application you have increasing buffer sizes and
> thus the uhd send()/recv() calls try to send bigger buffers?
>
> But that's just guessing. An explanation what you are trying to do with
> the Python API would be helpful, so the root cause (either in UHD or your
> application can be identified)
>
> Cheers,
> Andrej
>
> --
> Andrej Rode
> GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] uhd_usrp message return and Comms issues

[Derek Kozel via USRP-users]

Hi Mark,

I'm glad to hear you were able to update to 3.9. Retuning the UBX takes
approximately 500 usec. This varies based on how far the internal VCO needs
to tune and if there is a band crossing.

A dwell time of 5 seconds (5,000 msec) should be four orders of magnitude
more than is needed to get good data. There is no included utility to
measure the retune time. A quick test to do is to externally generate tones
at two frequencies and, while receiving and saving the samples, tune from
one to the other. The retune time can be seen as the duration between the
loss of the first signal and the stable reception of the second one.

How are you doing your acquisitions? If you look at the TwinRX fast
frequency hopping example it implements an approach where timed commands
are used to tune the channel and another to acquire a specific number of
samples. The commands are scheduled such that there is an appropriate delay
between acquisitions for the synthesizers to settle.
https://github.com/EttusResearch/uhd/blob/122bfae1a09cca732040cbdc5d7d20e68d0d755d/host/examples/twinrx_freq_hopping.cpp

Regards,
Derek

On Tue, Oct 3, 2017 at 12:56 PM, Mark Koenig <
mark.koe...@iubelttechnologies.com> wrote:

> Hi Derek,
>
>
>
> I have recently upgraded to UHD rev 003.009.000 and have everything up and
> running on Centos 6.5.  I am currently working on migrating to Centos 7.2
> and hope to be there in the next couple of days.  I am still seeing the
> retuning issues with the x310, unlike with the N210.
>
>
>
> What would be a good way of calculating how long the retunes are taking?
> Is there a built in UHD utility to help with that?  I know the retunes are
> taking longer because in an application I use I had to increase the dwell
> time from 5,000 msec to 30,000 msec to avoid any frequencies being skipped
> in the retune.
>
>
>
> I am using UBX40 daughtercards and my X310 revision is 4.
>
>
>
> Thanks
>
>
>
> Mark
>
>
>
> *From: *Derek Kozel 
> *Date: *Tuesday, October 3, 2017 at 7:44 AM
> *To: *Mark Koenig 
> *Cc: *"usrp-users@lists.ettus.com" 
> *Subject: *Re: [USRP-users] uhd_usrp message return and Comms issues
>
>
>
> Hello Mark,
>
> It has been some time since I have looked at the probe routine in the 3.8
> version of UHD, but it sounds like the discovery packets are having routing
> problems. Do you have an N210, N200, or USRP2 anywhere on the network?
>
>
> We can probably give some assistance to discovering the root cause of
> those messages, but it sounds like your real issue is that the retunes are
> taking longer than you expect. How long are they taking? How are you
> measuring the retune time? What daughtercard are you using?
>
> We usually find that if you are running Centos and an older version of UHD
> means that updating is not possible or prohibitively difficult. It does
> bear saying that the X310 and daughtercard code bases have advanced over
> the past two years. The UHD 3.9 branch provides a nice middle ground where
> you can get access to many of these updates without large architectural
> changes.
>
> Regards,
>
> Derek
>
>
>
> On Mon, Sep 25, 2017 at 4:09 PM, Mark Koenig via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> When I run the “uhd_usrp_probe” command I receive an interesting message
> prior to getting all of the information returned.  It is listed below.  I
> am having communication issues with the USRP X310 when changing
> frequencies, as it is taking much longer to retask the X310 than I would
> assume and therefor during my scan some frequencies are being missed.  I am
> using the 10gig bit Ethernet port, with a Chelsio card on a server running
> CentOS 6.5 with UHD rev 003.008.004.
>
>
>
> Any suggestions would be much appreciated.
>
>
>
> Thanks
>
>
>
> UHD  Error:
>
> X300 Network discovery error send_to:  Network is
> unreachable
>
>
>
> UHD  Error:
>
> X300 Network discovery error send_to:  Network is
> unreachable
>
>
>
> UHD  Error:
>
> USRP2 Network discovery error send_to:  Network is
> unreachable
>
>
>
> UHD  Error:
>
> USRP2 Network discovery error send_to:  Network is
> unreachable
>
> -- X300 initiallization sequence…
>
>
>
> Then the rest of the output is the usrp and daughtercard information,
> which is all correct.
>
>
>
>
>
>
> ___
> 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] ADC + DAC Compare of N200 and B200

[Derek Kozel via USRP-users]

Hello Kevin,

No, the N200 and B200 do not change the electrical transport modes based on
the frequency or bandwidth requested by the application, there is no need.
The 12 and 14 digital bits are available at all frequencies. The actual
effective number of bits out to the host depends on the ADC performance and
the decimation in the FPGA DSP.

I have not looked in depth at the design decisions that went into selecting
the interfaces but I'm confident that the hardware designers verified the
signal integrity.

You are correct about the use of the two output DAC. For most
daughterboards they are used for I and Q. For the others such as the LFRX
and LFTX the two channels can be used either as a complex pair or two real
valued channels.

Regards,
Derek



On Fri, Oct 13, 2017 at 5:21 AM, Kevin McGuire via USRP-users <
usrp-users@lists.ettus.com> wrote:

> This is connected to me investigating power level but the question is
> specifically about the number of bits per RX and TX channel between the
> N200 and B200. However, I fell into the rabbit hole that Alice went into
> and I seem to be stuck for the moment in determining what I am missing.
>
> I looked at the datasheet for the B200 and the AD9361. The AD9361 is
> advertised as using a 12-bit ADC and DAC. However, I see that it can
> operate in a 6-bit mode using the inputs as differentials - i suspect that
> is useful at ever higher frequencies. I counted 24 data pins.
>
> Now, the N200 uses this ADS62P42 which is a dual channel ADC. When looking
> at the datasheet it has 14 output ports per channel and two channels. I
> think this chip can also run in LVDS (differential) or CMOS (single-ended)
> modes. I am guessing once again LVDS gives only 7 effective bits per
> channel and CMOS gives 14 effective bits per channel.
>
> It seems that the AD9361 has two data ports where each port uses 12 of the
> 24 pins. Each of the data port pins can be an input or output. And, from
> what I can read it seems like these data ports can be combined in various
> ways, such as:
>
> 12-bit RX channel + 12-bit TX channel [FDD]
>I = 6-bit and Q = 6-bit (single data rate)
> 24-bit RX channel + 24-bit TX channel [TDD]
>I = 12-bit and Q = 12-bit (single data rate)
> 12-bit RX1 + 12-bit RX2 + 12-bit TX1 + 12-bit TX2 [FDD]
>I = 6-bit and Q = 6-bit (double data rate)
> 12-bit RX1 + 12-bit RX2 + 12-bit TX1 + 12-bit TX2 [TDD]
>We can have only two RX or TX active at the same time. (double data
> rate)
>
> Is this correct? And, which modes are actually used?
>
> The N200 I believe I have a handle on because it appears more straight
> forward. I can see how the RX provides two independent DAC outputs and each
> are 14-bit. If I have a handle on it then one should be the in-phase and
> the other the quadrature or two separate in-phase depending on the daughter
> board.
>
> Then, I also wonder, does the FPGA/firmware switch between CMOS and LVDS
> on either the B200 or the N200 in order to improve quality at higher
> frequencies?
>
> ___
> 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] ADC + DAC Compare of N200 and B200

[Derek Kozel via USRP-users]

Hi Kevin,

It is 12 bits each for I and Q, a total of 24 bits per complex sample pair.
It is usual for SDRs to list the resolution of the ADC which is then dual
channel for the I and Q.
https://www.ettus.com/content/files/b200-b210_spec_sheet.pdf

Regards,
Derek

On Fri, Oct 13, 2017 at 12:29 PM, Kevin McGuire  wrote:

> Derek or anyone,
>
> Do you know if it's a 12-bits complex on the b200 (6-bit I + 6-bit Q) or a
> 24-bit complex? I always thought it was a 24-bit complex but from what you
> said and what I see in the schematics it is plausible things may not be as
> they seem.
>
> This is ultimately my question but I have a weirdness of going around the
> world to ask it, haha. The exact precision used of the ADC before the FPGA
> for comparison is what I am after - but was also after any details too.
>
> Derek,
>
> Your information is most helpful and id assisting me in getting closer to
> understanding. I sincerely appreciate your help/wisdom and I am most
> thankful for people like you (and others) who voluntarily take their time
> to answer questions. I would know nothing if not for the help of people.
>
> I also feel like a lazy dummy because I just realized I could have looked
> at the schematic and seen how the, what appears to be LVDS enabling pins,
> are configured/connected.
>
> On Oct 13, 2017 5:02 AM, "Derek Kozel"  wrote:
>
>> Hello Kevin,
>>
>> No, the N200 and B200 do not change the electrical transport modes based
>> on the frequency or bandwidth requested by the application, there is no
>> need. The 12 and 14 digital bits are available at all frequencies. The
>> actual effective number of bits out to the host depends on the ADC
>> performance and the decimation in the FPGA DSP.
>>
>> I have not looked in depth at the design decisions that went into
>> selecting the interfaces but I'm confident that the hardware designers
>> verified the signal integrity.
>>
>> You are correct about the use of the two output DAC. For most
>> daughterboards they are used for I and Q. For the others such as the LFRX
>> and LFTX the two channels can be used either as a complex pair or two real
>> valued channels.
>>
>> Regards,
>> Derek
>>
>>
>>
>> On Fri, Oct 13, 2017 at 5:21 AM, Kevin McGuire via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> This is connected to me investigating power level but the question is
>>> specifically about the number of bits per RX and TX channel between the
>>> N200 and B200. However, I fell into the rabbit hole that Alice went into
>>> and I seem to be stuck for the moment in determining what I am missing.
>>>
>>> I looked at the datasheet for the B200 and the AD9361. The AD9361 is
>>> advertised as using a 12-bit ADC and DAC. However, I see that it can
>>> operate in a 6-bit mode using the inputs as differentials - i suspect that
>>> is useful at ever higher frequencies. I counted 24 data pins.
>>>
>>> Now, the N200 uses this ADS62P42 which is a dual channel ADC. When
>>> looking at the datasheet it has 14 output ports per channel and two
>>> channels. I think this chip can also run in LVDS (differential) or CMOS
>>> (single-ended) modes. I am guessing once again LVDS gives only 7 effective
>>> bits per channel and CMOS gives 14 effective bits per channel.
>>>
>>> It seems that the AD9361 has two data ports where each port uses 12 of
>>> the 24 pins. Each of the data port pins can be an input or output. And,
>>> from what I can read it seems like these data ports can be combined in
>>> various ways, such as:
>>>
>>> 12-bit RX channel + 12-bit TX channel [FDD]
>>>I = 6-bit and Q = 6-bit (single data rate)
>>> 24-bit RX channel + 24-bit TX channel [TDD]
>>>I = 12-bit and Q = 12-bit (single data rate)
>>> 12-bit RX1 + 12-bit RX2 + 12-bit TX1 + 12-bit TX2 [FDD]
>>>I = 6-bit and Q = 6-bit (double data rate)
>>> 12-bit RX1 + 12-bit RX2 + 12-bit TX1 + 12-bit TX2 [TDD]
>>>We can have only two RX or TX active at the same time. (double data
>>> rate)
>>>
>>> Is this correct? And, which modes are actually used?
>>>
>>> The N200 I believe I have a handle on because it appears more straight
>>> forward. I can see how the RX provides two independent DAC outputs and each
>>> are 14-bit. If I have a handle on it then one should be the in-phase and
>>> the other the quadrature or two separate in-phase depending on the daughter
>>> board.
>>>
>>> Then, I also wonder, does the FPGA/firmware switch between CMOS and LVDS
>>> on either the B200 or the N200 in order to improve quality at higher
>>> frequencies?
>>>
>>> ___
>>> 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] 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

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] time/phase synchronization of 2 X300

[Derek Kozel via USRP-users]

Hi Luca,

Any external 10 MHz and 1PPS source will work. The 1PPS is basically a DC
signal so it is best to have a buffer amplifier to split it, but if just
going to two USRPs you may be able to get away with using the RF power
divider as well.

The required signal levels are posted in the user manual and knowledge
base, if you can meet those then the system will work.
https://kb.ettus.com/X300/X310#Ref_Clock_-_10_MHz

Regards,
Derek

On Mon, Oct 30, 2017 at 10:12 AM, Luca Pascale via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Marcus,
>
> What about to use an "external" GPS Timing receiver with PPS and 10 MHz
> output and to split them using power divider to provide pps and ref to
> the 2 X300 ?
>
> I do not want to use the octoclok for space saving reasons.
>
>
> Thanks,
>
> Luca
>
>
> > There has never been really-good support for REF OUT and 1PPS out on the
> > X3xx series.  Partially because making it "work right" with the hardware
> > that is in there is more-or-less impossible (length compensation, etc).
>
>
> ___
> 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] 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]

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] Setting LO offset and exact central frequency with RFNoC

[Derek Kozel via USRP-users]

Hello Dragoslav,

What you are seeing is expected and correct. With the multi_usrp interface
the set_tx_freq function does a series of actions for you.

1) Calculate a target RF frequency, taking into account any LO offset
requested
2) Call a function to set the RF frequency to this target and then read
back the actual frequency
3) Call a function on the DDC to account for the difference between the
user requested frequency and the actual RF frequency

The important thing to note is that the DDC frequency shift will be the
combination of the LO offset and the frequency error of the RF tuning. This
frequency error can occur for a number of reasons usually based on
limitations in the frequency synthesizer and sometimes because of decisions
built into the code to improve system performance.

When using the RFNoC workflow you'll have to replicate the above three
steps because you have manual control over the Radio and DDC blocks. Tune
the Radio block first then use the results of that to compensate using the
DDC.

Regards,
Derek

On Thu, Nov 2, 2017 at 3:17 PM, Dragoslav Stojadinovic via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I have been trying to set LO offset while using an RFNoC device, and I
> have encountered 2 separate problems with it.
>
> Specifically, I create a standard uhd::usrp::multi_usrp object, and then
> get device3::sptr from it. I set the TX graph in the following way: DUC ->
> radio_ctrl, and the RX graph is radio_ctrl->DDC->custom_block.
>
> The first problem is setting the LO offset. The only way I know of doing
> this is by calling set_tx_freq with a uhd::tune_request_t(freq, lo_offset)
> as an argument. However, this did not work in my case. It works perfectly
> when using clean UHD, but with RFNoC I don't get consistent behavior, and
> it seems most of the time I will just get no LO offset and central
> frequency set to freq + lo_ffset. Is this a known problem? Is there a way
> to set the LO offset with RFNoC? Is there a specific RFNoC block that I
> would need to use to set this?
>
> The second problem is the actual central frequency, when setting it simply
> as set_tx_freq(freq) - where freq is a double, or set_tx_frequency (a
> method of device3 instead of multi_usrp). These both work in exactly the
> same fashion, which is fine, however - with some frequencies simply not
> being set very precisely. Here, the results I get are very consistent,
> always the same, and the precision of the frequency I get depends on the
> frequency I request. For example, when I request 1 GHz, I get exactly 1
> GHz. When I request 992.5 MHz, I get ~ 992.498 which is approximately 2 kHz
> below the frequency I requested. Depending on the frequency I request, the
> actual frequency will be up to 5 kHz below (or above). This happened across
> multiple different RFNoC bitstreams, both the ones provided by Ettus and
> custom ones, and both with using integer and fractional dividers, the
> values I get were always exactly the same and it only happens with RFNoC -
> with standard UHD I consistently always get the exact frequency I requested
> (maybe up to a couple of Hz off, but that is really negligible). Is this a
> known issue, am I doing something wrong? Is there something I can do to get
> a more precise actual frequency with RFNoC?
>
> Thank you in advance!
>
> Regards,
> Dragoslav Stojadinovic
>
> ___
> 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] Sync two USRP devices to sense 100MHz of spectrum

[Derek Kozel via USRP-users]

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 of the same type? like two of USRPN200 or two
> of USRP2.
>
> Thanks
> Wahhab Albazrqaoe
>
> ___
> 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] 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 of the same type? 

Re: [USRP-users] spectrum analyzer USRP N210

[Derek Kozel via USRP-users]

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__usrp.html#a263ab7f0364c03e8a6e330c546769e4f
http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.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:
> 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")
>
> prom1 = np.fft.fft(recv_buff)
> prom1[0:5] = 0
> prom1[num_samps-5:num_samps] = 0
> prom1= np.fft.fftshift(prom1)*w
> fft1 = np.hstack((fft1,prom1))
>
> stream_cmd.time_spec = lib.types.time_spec(0)
> streamer.issue_stream_cmd(stream_cmd)
>
> dbm = np.array(10 * np.log10(np.abs(fft1))  - 60)
>
> return dbm,config.start_freq+(config.band/num_samps)*np.arange(dbm.size)
>
>
> ___
> 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 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:
> print ("ERR2")
> elif config.metadata.error_code == 
> lib.types.rx_metadata_err

Re: [USRP-users] Independent use of ethernet ports on Ettus x310?

[Derek Kozel via USRP-users]

Hi Chad,

To add to what Neel said, no matter the FPGA image or Ethernet type a USRP
cannot be accessed from two computers at the same time. The device is
claimed as the first action when a connection is made to it by a program.

Regards,
Derek

On Fri, Nov 17, 2017 at 1:08 AM, Neel Pandeya via USRP-users <
usrp-users@lists.ettus.com> 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 depending on which FPGA image is being used.
>
> http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_load_
> fpga_imgs_fpga_flavours
>
> Regarding your use-case, if you have a second daughterboard in your
> X300/X310, then you can simultaneously receive in parallel. With two
> daughterboards, the X300/X310 provides two transmit chains and two receive
> chains.
>
> What is the configuration of your system?
>
> --Neel Pandeya
>
>
>
> On 15 November 2017 at 17:34, Chad Spooner via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> All:
>>
>> I'm wondering how to use the second ethernet port on my x310. I've been
>> going through the
>> online Ettus SDR help, but can't seem to find the right pages.
>>
>> The short version of my question is: Can I use the two ethernet ports
>> independently, say
>> when each of them is connected to a separate computer? If so, how do I
>> set up the second
>> port? I'm using computers with 1 GiG Ethernet only.
>>
>> Details/Context: I have a working gnuradio companion flowgraph that
>> generates a signal indefinitely
>> and applies it to (A:0, Tx/Rx). That output port is connected by a cable
>> to (B:0, RX2).  All indications are
>> that this is working well. At irregular intervals, I want to obtain large
>> numbers of samples from
>> (B:0, RX2) by calling, say, uhd_rx_cfile or the like, outside of the
>> flowgraph, which is still
>> running. I'm prevented from doing that while the flowgraph is running.
>> Can I do it using the
>> second 1 GiG port if I set it up properly?
>>
>> Thanks for any advice you can offer.
>>
>> Chad
>>
>> --
>> Chad M. Spooner
>> NorthWest Research Associates
>> 301 Webster Street
>> Monterey, CA 93940cmspooner@nwra.com831 582 4904 <(831)%20582-4904>
>> cyclostationary.blog
>>
>>
>> ___
>> 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] 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 depending on which F

Re: [USRP-users] underrun problem in GPS record and replay system with USRP/WBX

[Derek Kozel via USRP-users]

Hello Fabrizio,

Have you tried running the benchmark_rate example included with UHD? That
can test if there is any issue sending data at that rate to the USRP.
uhd_siggen is also a good test as it uses GNU Radio so can check that the
rate continues to work from within GNU Radio.

If both of those work then more information would be needed about your GNU
Radio flowgraph. Is it only a file source into a USRP sink?

Regards,
Derek

On Mon, Nov 27, 2017 at 3:19 PM, Fabrizio Turin via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all
> for a research project I'm trying to record and replay few seconds of GPS
> signal. The recording part has been done correctly, a 40 seconds GPS
> acquisition has been tested against a GPS-SDR receiver obtaining a correct
> position fix. Now I'd like to transmit the recorded signal through RF cable
> and see if a commercial GPS receiver is able to get the position fix as
> well. The problem is that, as soon as I start the simple flow graph in GNU
> radio I get the "U" underrun warning (side note: PC became un-responding
> too) and it seems I'm not transmitting at all.
> Here's the complete description of the problem:
>
> Front-end: USRP N210 with WBX
>
> Recorded file:
>
> data type: complex float32
> centre freq: GPS L1
> sampling rate: 10 MHz
> acquisition length: 40 seconds
> recorded file size: 3.2 GB
>
> Host PC:
>
> OS: Windows 10 Pro (64bit)
> CPU: Intel Core i7-7820HQ
> RAM: 32 GB
> HD: Toshiba THNSNK512GCS8 (545 MB/s write speed)
> network adapter: gigabit capable
>
> USRP Sink configuration:
>
> sampling rate: 10 MHz
> input type: complex float32
> wire format: automatic
> centre freq: GPS L1
> Ch0:Antenna TX/RX
> (everything else as default)
>
> From the numbers I wouldn't say that the bottleneck is the HD (in any case
> I've already tried loading the recorded file from a RAMdisk with the same
> problems...) or the network speed.
> Any idea on what I'm doing wrong and how to get rid of the underrun
> warning?
> Thanks in advance
>
> Fabrizio
>
>
>
>
> 
> --
>
>
>
> The information contained in this e-mail is intended only for the
>
> individual or entity to whom it is addressed. Its contents (including
>
> any attachments) are confidential and privileged: if you are not an
>
> intended recipient you must not use, disclose, disseminate, copy or
>
> print its contents. If you have received this email by mistake please
>
> notify us by emailing the sender, and then delete and/or destroy the
>
> e-mail and any copies from your system
>
>
>
> 
> --
>
> ___
> 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]

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] 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 Telecommunications Program
>>> A.V. Williams Building
>>> University of Maryland at College Park
>>> College Park, MD 20742
>>> =

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] 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] 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] 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 Image:
> /xyz/xyz/rf

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] 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
>>> |   |   |   |   Bandw

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] 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] 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] 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&lc=eng&;
>> ckey=96887&nid=-34815.0.00&id=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 which the HP device measures and they're very
>> >> comparable. ... Except below ~ 1GHz.
>> >>
>> >> And here's the issue - I am seeing higher NF for DUTs below abou

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] 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]

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] 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] Readback data block

[Derek Kozel via USRP-users]

Hello Andy,

You can use the standard UHD streamer functions to do a burst reception in
GNU Radio with the number of samples set to 1024.

Regards,
Derek

On Thu, Mar 1, 2018 at 8:54 AM, Andrew Thommesen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
>
> Is it possible to use gnuradio to read a data block (1024 IQ samples) from
> an RFNoC block? An approach similar to register readback would be useful.
>
>
> 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] 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] 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] 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] [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] 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] 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] 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,

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  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 
>>> *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]

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  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  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 
>> 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 
>>>>> *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 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] 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] 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).
>>
>> ./tx_waveforms --rate 61

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 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] 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
>
>
>
>
> ___
> USRP-

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  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.010.003 

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  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 
> 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  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--

Re: [USRP-users] N310 schematics and phase noise

[Derek Kozel via USRP-users]

Hello Louis,

Yes, the schematics are being prepared for posting. I don't know
specifically when that will be completed. Unlike the X310 the GPSDO is
always installed with the N310.

The GPSDO is a Jackson Labs LTE Lite.
http://jackson-labs.com/index.php/products/lte_lite

The 25 MHz TCXO is a Crystek CXOHDV4-DB3Y
http://www.crystek.com/crystal/spec-sheets/tcxo/CXOHD4.pdf

I don't have more detailed phase noise information about performance of the
total reference circuit. Is there more specific information that you are
looking for?

Regards,
Derek

On Sat, Mar 24, 2018 at 10:43 PM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 03/24/2018 05:54 PM, Louis Brown via USRP-users wrote:
>
>> Will the N310 schematics be posted?  I’m specifically needing to find out
>> the phase noise of the TCXO and GPSDO.
>>
>> Thanks,
>> Lou
>>
>>
>> There is a phase-noise chart on the product datasheet:
>
> https://www.ettus.com/content/files/USRP_N310_Datasheet.pdf
>
> It doesn't indicate whether this is with the on-board TCXO, or the GPSDO.
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] UHD version for RFNoC

[Derek Kozel via USRP-users]

Hello Juan,

Right now RFNoC development requires Vivado 2015.4 and the rfnoc-devel
branch. We are in the process of updating the rfnoc-devel branch to include
the changes from the master branch, including Vivado 2017.4 support.

Regards,
Derek

On Tue, Mar 27, 2018 at 4:33 AM, Juan Francisco via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Ok is there any way to build for rfnoc-devel using Vivado 2017.4 then?
>
> On Mon, Mar 26, 2018 at 11:22 PM, Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 03/26/2018 11:15 PM, Juan Francisco via USRP-users wrote:
>>
>>> Hi,
>>>
>>> I am starting a new RFNoC design with custom RFNoC FPGA blocks, and I am
>>> a bit confused as to whether I should use UHD 3.11 or the rfnoc-devel
>>> branch.  I'd like to be able to build using Vivado 2017.4, which seems to
>>> be the default for 3.11, but the rfnoc-devel branch is still stuck on
>>> 2015.4.
>>>
>>> Is UHD 3.11 fully RFNoC compatible, or do I need to stick with
>>> rfnoc-devel to get all the necessary features?
>>>
>>> Thanks,
>>> Juan
>>>
>>>
>>> rfnoc-devel is still the branch you should use for now, although there
>> will be fixes coming to 3.11 soon I think that will make it OK for RFNOC
>> developers.
>>
>>
>>
>> ___
>> 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