Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
usrp-users-requ...@lists.ettus.com
You can reach the person managing the list at
usrp-users-ow...@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. B210 LO phase behavior (Beaudoin, Christopher J)
2. Re: B210 LO phase behavior (Marcus D. Leech)
3. SC16 incompatible complex type assignment. (Walter Maguire)
4. RFNoC Packet Size (Walter Maguire)
5. FOSDEM 2017: SDR Track CfP (Martin Braun)
6. [UHD] 3.10.1.0 Release Candidate (Martin Braun)
7. Re: [SPAM] Re: Modify the FPGA in X300 (???)
8. Fwd: SC16 incompatible complex type assignment. (Walter Maguire)
9. Re: Fwd: SC16 incompatible complex type assignment.
(Jonathon Pendlum)
10. Re: RFNoC Packet Size (Jonathon Pendlum)
11. Using overload detectors in MGC mode (Woelfel, Maximilian)
12. SFP adapter for 1 GigE for X300/X310 (Vladica Sark)
13. X310 (Vladica Sark)
14. Re: Weird behaviour with set_master_clock_rate in X300
(Pol Henarejos)
15. Re: [SPAM] Re: Modify the FPGA in X300 (Marcus M?ller)
16. Failed tests when compiling UHD on Windows 10 (Pol Henarejos)
17. Re: X310 (Marcus M?ller)
18. Re: SFP adapter for 1 GigE for X300/X310 (Marcus M?ller)
19. Re: X310 (Vladica Sark)
20. Re: SFP adapter for 1 GigE for X300/X310 (Vladica Sark)
21. Re: X310 (Marcus M?ller)
22. Re: X310 (Vladica Sark)
23. Re: X310 (Marcus M?ller)
24. Re: Modify the FPGA in X300 (Marcus M?ller)
25. rfnocmodtool not working (Jason Matusiak)
26. Re: rfnocmodtool not working (Jason Matusiak)
27. Re: rfnocmodtool not working (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Tue, 18 Oct 2016 19:38:08 +0000
From: "Beaudoin, Christopher J" <christopher_beaud...@uml.edu>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] B210 LO phase behavior
Message-ID: <168fcfe4-4ec3-4e38-95e4-bf0de34ff...@uml.edu>
Content-Type: text/plain; charset="utf-8"
Hi,
I?m developing an absolute phase detector with the B210 and establishing
a consistent phase measurement (relative to the internal sampler clock) from
acquisition-to-acquisition has proven difficult. I?m wondering if I have not
configured the radio properly or if the device does not function in exactly the
way that I am anticipating. In my setup, I have locked together the 10 MHz
reference of the B210 and my external signal generator - the generator is
providing a constant -30 dBm, 3 GHz tone. The B210 is configured to lock in the
integer-N mode, I command the frontend LO frequency to 2999950000 Hz (i.e. 50
kHz offset from my 3 GHz tone), and I do not reset the clock nor do I re-tune
any frequency/sample-rate parameters in between acquisitions. Configured in
this way, I am anticipating that the absolute phase of the IQ samples at every
integer second boundary to repeat precisely between acquisitions since there
are an integer number of signal cycles in each second but the measur
ed results indicate otherwise.
To investigate lack of phase repeatability on the second?s boundary further, I
pulse modulated the 3 GHz tone with a 1 kHz square wave derived from the same
10 MHz reference that the B210 and signal generator are locked to. What I
observed from measurements of this modulated tone is that that edges of the 1
KHz modulation appear at precisely the same sample indices relative to the
integer-second boundary from acquisition-to-acquistion, however, the absolute
phase of the 50 KHz tone relative to the edge of this 1KHz modulation varies
significantly (>> 90 degs) from one acquisition to the next. Just in case you
are wondering, I independently confirmed that the 1 kHz modulation is phase
locked to 3 GHz tone with a separate/independent setup. What this is telling me
is that the time samples are true and aligned between acquisitions and that an
embedded LO phase term appears to change between acquisitions. I?m not sure if
such a term is arising from the analog AD9361 frontend, some known
shift that results in the FPGA signal processing, or perhaps elsewhere.
Does anyone know if the behavior I?ve described here to be expected? Any
insight that you can offer would be greatly appreciated.
Best regards,
Chris
------------------------------
Message: 2
Date: Tue, 18 Oct 2016 15:44:42 -0400
From: "Marcus D. Leech" <mle...@ripnet.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] B210 LO phase behavior
Message-ID: <58067baa.8010...@ripnet.com>
Content-Type: text/plain; charset=utf-8; format=flowed
On 10/18/2016 03:38 PM, Beaudoin, Christopher J via USRP-users wrote:
> Hi,
>
> I?m developing an absolute phase detector with the B210 and
> establishing a consistent phase measurement (relative to the internal sampler
> clock) from acquisition-to-acquisition has proven difficult. I?m wondering if
> I have not configured the radio properly or if the device does not function
> in exactly the way that I am anticipating. In my setup, I have locked
> together the 10 MHz reference of the B210 and my external signal generator -
> the generator is providing a constant -30 dBm, 3 GHz tone. The B210 is
> configured to lock in the integer-N mode, I command the frontend LO frequency
> to 2999950000 Hz (i.e. 50 kHz offset from my 3 GHz tone), and I do not reset
> the clock nor do I re-tune any frequency/sample-rate parameters in between
> acquisitions. Configured in this way, I am anticipating that the absolute
> phase of the IQ samples at every integer second boundary to repeat precisely
> between acquisitions since there are an integer number of signal cycles in
> each second but the mea
sured results indicate otherwise.
>
> To investigate lack of phase repeatability on the second?s boundary further,
> I pulse modulated the 3 GHz tone with a 1 kHz square wave derived from the
> same 10 MHz reference that the B210 and signal generator are locked to. What
> I observed from measurements of this modulated tone is that that edges of the
> 1 KHz modulation appear at precisely the same sample indices relative to the
> integer-second boundary from acquisition-to-acquistion, however, the absolute
> phase of the 50 KHz tone relative to the edge of this 1KHz modulation varies
> significantly (>> 90 degs) from one acquisition to the next. Just in case
> you are wondering, I independently confirmed that the 1 kHz modulation is
> phase locked to 3 GHz tone with a separate/independent setup. What this is
> telling me is that the time samples are true and aligned between acquisitions
> and that an embedded LO phase term appears to change between acquisitions.
> I?m not sure if such a term is arising from the analog AD9361 frontend, some
> kno
wn shift that results in the FPGA signal processing, or perhaps elsewhere.
>
> Does anyone know if the behavior I?ve described here to be expected? Any
> insight that you can offer would be greatly appreciated.
>
> Best regards,
> Chris
> _______________________________________________
When you say you do "multiple acquisitions", how exactly are you doing
that? Unless you're continuously streaming, various bits and
pieces get "idled" and brought back up between runs.
------------------------------
Message: 3
Date: Wed, 19 Oct 2016 08:33:32 +1100
From: Walter Maguire <wmagu...@iinet.net.au>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] SC16 incompatible complex type assignment.
Message-ID: <f04c2a20-4c5e-84d5-ee11-08b9673f9...@iinet.net.au>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi all,
I am using XSIM and Vivado 2014.4. The following line in my
noc_block_device_tb
`RFNOC_CONNECT(noc_block_tb /* From */, noc_block_device /* To */,
SC16 /* Type */, 256 /* Samples per packet */);
is giving the error
SC16 incompatible complex type assignment.
This is strange as it does not do it for other simulations.
The only real difference I can think of is the fact that I am not using
the simple header mode and use a packet_length setup as per
tb_streamer.write_reg(sid_noc_block_capturer,
noc_block_capturer.SR_PKT_SIZE, 4); .
Regards
Walter
------------------------------
Message: 4
Date: Wed, 19 Oct 2016 08:46:34 +1100
From: Walter Maguire <wmagu...@iinet.net.au>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] RFNoC Packet Size
Message-ID: <94428212-c5de-da36-7ccb-638d3f9d9...@iinet.net.au>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi all,
Apologies to OpenBTS list, I should have posted this question on the USRP lists.
"Just to clarify, I assume the packet size and the CE input and output
block processing buffer sizes can be different? So for example lets
assume I have a 256 * 32 bit in/out buffers for a FFT. I assume the
packet size could be set to 4 (4 bytes, or one sample) and it would be
the sending of the EOB (triggered by tlast from sample 255 on packet
255) which would subsequently confirm the complete input buffer for
processing."
After studying the Verilog code in more detail it looks like the full packet
needs to be sent as the entire transaction. I think the packet length in RFNoC
is the input or output processing buffer size. Can packet transfers be
interrupted?
Regards
Walter
------------------------------
Message: 5
Date: Tue, 18 Oct 2016 15:27:58 -0700
From: Martin Braun <mar...@gnuradio.org>
To: "discuss-gnura...@gnu.org" <discuss-gnura...@gnu.org>,
"'USRP-users@lists.ettus.com'" <usrp-users@lists.ettus.com>,
fos...@lists.fosdem.org
Subject: [USRP-users] FOSDEM 2017: SDR Track CfP
Message-ID: <1e5464ed-7792-136f-8f31-ebcfeedf9...@gnuradio.org>
Content-Type: text/plain; charset=utf-8
Dear friends and fans of software defined radio,
next year's FOSDEM (the free and open source developer's meeting in
Brussels, Europe) will, once again, feature a track on Software Defined
Radio.
Therefore, we invite developers and users from the free software radio
community to join us for this track and present your talks or demos.
Software Radio has become an important tool to allow anyone access the
EM spectrum. Using free software radio libraries and applications and
cheap hardware, anyone can now start hacking on wireless
communications, remote sensing, radar or other applications. At FOSDEM,
we hope to network all these projects and improve collaboration, bring
new ideas forward and get more people involved.
The track's web site resides at:
http://gnuradio.org/redmine/projects/gnuradio/wiki/FOSDEM
Here, we will publish updates and announcements. The final schedule will
be available through Pentabarf and the official FOSDEM website.
** Submit your presentations
To suggest a talk, go to https://penta.fosdem.org/submission/FOSDEM16
and follow the instructions (you need an account, but can use your
account from last year if you have one). You need to create an 'Event';
make sure it's in the Software Defined Radio track! Lengths aren't
fixed, but give a realistic estimate and please don't exceed 30 minutes
unless you have something special planned (in that case, contact one of
us). Also, don't forget to include time for Q&A.
You aren't limited to slide presentations, of course. Be creative.
However, FOSDEM is an open source conference, therefore we ask you to
stay clear of marketing presentations. Of course, we like nitty-gritty
technical stuff.
Here's a list of topics that will most likely be included:
- SDR Frameworks + Tools
- Wireless security
- Radio hardware
- Telecommunications
- Random fun wireless hacks
We will reserve time for interactiveness, it won't all be talks.
** Important Dates
FOSDEM is February 4th and 5th, 2017.
* December 9th 2016: Submission Deadline
* January 2nd 2017: Announcement of final schedule
* February 4th 2017: SDR Track (Saturday)
These dates are not set in stone. However, the least years we were
always full to the brim with presentations, so if you want to present,
please make sure to submit your abstracts soon!
** Steering Committee
The track committee consists of:
* Phil "catvideos" Balister (OpenEmbedded / OpenSDR)
* Martin "mbr0wn" Braun (GNU Radio)
* Sylvain "tnt" Munaut (OsmoCom)
Hope to hear from you soon! And please forward this announcement.
Martin
------------------------------
Message: 6
Date: Tue, 18 Oct 2016 15:32:40 -0700
From: Martin Braun <martin.br...@ettus.com>
To: "'USRP-users@lists.ettus.com'" <usrp-users@lists.ettus.com>
Subject: [USRP-users] [UHD] 3.10.1.0 Release Candidate
Message-ID: <d5aabb81-2530-2644-2f64-e37a7dcc1...@ettus.com>
Content-Type: text/plain; charset=utf-8
Everyone,
we're getting towards another release on the 3.10 development cycle.
We're going straight to 3.10.1.0 (from 3.10.0.0) because we broke ABI to
resolve some issues, and according to our new convention of encoding ABI
versions in the actual versions string, this meant skipping any 3.10.0.1
versions.
This release updates the FPGA images for X-Series and B-Series, but not
the compat numbers. Please make sure to run uhd_images_downloader to get
all the updates!
For now, we've tagged the 3.10.1.0 release candidate, and the actual
release is slated for next Monday.
This release contains a large number of various bugfixes, some more
serious. In particular, TwinRX users should be moving to this version if
they're still on 3.10.0.0, but in general, anyone using 3.10 should
upgrade once the release is out there.
This is the tag for RC1:
https://github.com/EttusResearch/uhd/tree/003_010_001_000_rc1
Cheers,
Martin
PS: Changelog:
## 003.010.001.000
- Fixed multiple compiler warnings
- Multiple documentation fixes
- X300: RX strobe lines are always in sync on device initialization. DB
EEPROM
now properly written. ignore-cal-file no longer ignored. Fixed case
where too
large recv_frame_size settings could break things. Reduced ZPU clock speed
(helps FPGA timing). Added area constraints for AXI interconnect. Improved
halfband scaling in rx_frontend.
- B2xx: Clear sequence numbers in idle state.
- RFNoC: Nodes disconnect on destruction. Fixed setting of correct bits on
sr_error_policy. DDC does no longer clear timed commands on EOB. DUC fixed
timed CORDIC tuning. Enable Noc-Shell response FIFOs (fixes simultaneous
commands on multiple channels).
- UBX: Changed default performance parameters
- TwinRX: LEDs properly light up depending on channels. Fixed issue of
multiple
(redundant) writes.
- XCVR: Query dboard clock instead of DAC clock. Helps in X3x0s.
- GPS: Fixed message for case when no GPS is present. Fixed multiple
GPS-related
issues.
- Converters: Fixed floating point rounding error in tests.
- Utils: uhd_usrp_probe can now query vectors
- Fixed issue that prevented soft_regs working on 32-bit systems
- Tools: Merged dissectors into common directory.
- CMake: -Og is the default now for gcc-based Debug builds.
------------------------------
Message: 7
Date: Wed, 19 Oct 2016 09:56:51 +0800 (GMT+08:00)
From: ??? <2012301650...@whu.edu.cn>
To: usrp-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] [SPAM] Re: Modify the FPGA in X300
Message-ID:
<76b6583c.1dd76.157daa7c706.coremail.2012301650...@whu.edu.cn>
Content-Type: text/plain; charset=utf-8
> -----????-----
> ???: "Marcus M?ller" <marcus.muel...@ettus.com>
> ????: 2016?10?18? ???
> ???: "???" <2012301650...@whu.edu.cn>, usrp-users <usrp-users@lists.ettus.com>
> ??:
> ??: Re: [SPAM] Re: [USRP-users] Modify the FPGA in X300
>
> Hi Tan,
>
> > Dear Marcus
> > Thank you for your help.I am using the x300 to collect GPS data.When
> > I go outdoors to collect GPS data?I have to use laptop.So I can just link
> > to the pc across GE.The GE limite the transmission speed.
> ah, so the link to the PC is the bottleneck
> > To improve Sampling rate,I hope to the usrp output 2bit samples to the PC.
> Well, GPS is actually one of the rare cases where such minimal sample
> depths are possible indeed
> > Can I achieve it by modifying the fpga code?
> Yes!
> > If it is possible to ahieve it ,should I build system follow the FPGA
> > maunal in http://files.ettus.com/manual/md_usrp3_build_instructions.html?
> Yes; mostly, however, you should definitely look into getting started
> with RFNoC. Doing so will allow you to simply write an AXI4 module that
> takes in 16bit samples and spits out 2bit samples, and UHD will still
> take care of everything around.
>
> Then again: if you're already modifying the FPGA image, it might be
> worthwhile thinking about which signals and bandwidths you're interested
> in. Could you elaborate on that?
>
> Best regards,
> Marcus
Hi Marcus
Thank you for your help.I haven't modified FPGA image,regarding the
signals and bandwidths I'm interested in.I have two daughterboards,one for
GPSL1,about 1575.42MHz and 2MHz bandwidths,the another for BDB1 about 1560.98
MHz and 2MHz bandwidths.Now,I am using the GNUradio to transform the 16bit
samples to 2bit samples,and it works well.Now I am interested in GPSL2 about
1226MHz and 20MHz bandwidth.
I have tried RFNOC in GNUradio following in
https://kb.ettus.com/RFNoC_Getting_Started_Guides#Installing_UHD.2FRFNoC_Branch.But
it provides just 8 blocks ,I even can't find a block like usrp source.I am not
clear about how to write an AXI4 module that takes in 16bit samples and spits
out 2bit samples.Should I wirte the module in GNUradio or getting started with
RFNoC in another way?Can you give me some materials about RFNOC.
If the RFNOC can achieve my goal ,I am willing to use RFNOC,because I am
not familier with FPGA.
Thank you in advance.
Tan
------------------------------
Message: 8
Date: Wed, 19 Oct 2016 14:52:32 +1100
From: Walter Maguire <wmagu...@iinet.net.au>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] Fwd: SC16 incompatible complex type assignment.
Message-ID: <302fd467-007f-bb14-1837-6ea268239...@iinet.net.au>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi all
As a followup to this issue, I think the problem is in XSIM. Normally I
use Vivado running on Win 8 where the problem occurs. I retested the
simulation on Vivado running on Ubuntu and it works. So an odd one.
Regards
Walter
-------- Forwarded Message --------
Subject: SC16 incompatible complex type assignment.
Date: Wed, 19 Oct 2016 08:33:32 +1100
From: Walter Maguire <wmagu...@iinet.net.au>
To: usrp-users@lists.ettus.com
Hi all,
I am using XSIM and Vivado 2014.4. The following line in my
noc_block_device_tb
`RFNOC_CONNECT(noc_block_tb /* From */, noc_block_device /* To */,
SC16 /* Type */, 256 /* Samples per packet */);
is giving the error
SC16 incompatible complex type assignment.
This is strange as it does not do it for other simulations.
The only real difference I can think of is the fact that I am not using
the simple header mode and use a packet_length setup as per
tb_streamer.write_reg(sid_noc_block_capturer,
noc_block_capturer.SR_PKT_SIZE, 4); .
Regards
Walter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161019/81bfd495/attachment-0001.html>
------------------------------
Message: 9
Date: Wed, 19 Oct 2016 00:43:09 -0500
From: Jonathon Pendlum <jonathon.pend...@ettus.com>
To: Walter Maguire <wmagu...@iinet.net.au>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Fwd: SC16 incompatible complex type
assignment.
Message-ID:
<cagdo0us-ct3n6gdrrnny4wbhnunkz80nu0chtaasexkyz1n...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Walter,
Xilinx's XSIM simulator definitely has bugs. It is best to use 2015.4 since
that is what is currently supported on rfnoc-devel and Xilinx has fixed a
lot of issues in XSIM since 2014.4.
Jonathon
On Tue, Oct 18, 2016 at 10:52 PM, Walter Maguire via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi all
>
> As a followup to this issue, I think the problem is in XSIM. Normally I
> use Vivado running on Win 8 where the problem occurs. I retested the
> simulation on Vivado running on Ubuntu and it works. So an odd one.
>
> Regards
>
>
> Walter
>
>
> -------- Forwarded Message --------
> Subject: SC16 incompatible complex type assignment.
> Date: Wed, 19 Oct 2016 08:33:32 +1100
> From: Walter Maguire <wmagu...@iinet.net.au> <wmagu...@iinet.net.au>
> To: usrp-users@lists.ettus.com
>
> Hi all,
> I am using XSIM and Vivado 2014.4. The following line in my
> noc_block_device_tb
>
> `RFNOC_CONNECT(noc_block_tb /* From */, noc_block_device /* To */,
> SC16 /* Type */, 256 /* Samples per packet */);
>
> is giving the error
>
> SC16 incompatible complex type assignment.
>
>
> This is strange as it does not do it for other simulations.
>
> The only real difference I can think of is the fact that I am not using
> the simple header mode and use a packet_length setup as per
>
> tb_streamer.write_reg(sid_noc_block_capturer,
> noc_block_capturer.SR_PKT_SIZE, 4); .
>
> Regards
>
> Walter
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161019/bfcd4d0b/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 19 Oct 2016 00:47:20 -0500
From: Jonathon Pendlum <jonathon.pend...@ettus.com>
To: Walter Maguire <wmagu...@iinet.net.au>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] RFNoC Packet Size
Message-ID:
<cagdo0usowjky+oxqrmctcsva2clo-yafwbrnqopq9f5vttq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Walter,
Yes, you can have packets with a different SPP (samples per packet).
However, I would highly recommend you do not send packets with only one
sample. While it is possible, the header overhead would severely impact
your block's throughput. Is there some reason you can't pack the entire 256
samples into one packet?
Jonathon
On Tue, Oct 18, 2016 at 4:46 PM, Walter Maguire via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi all,
>
> Apologies to OpenBTS list, I should have posted this question on the USRP
> lists.
>
> "Just to clarify, I assume the packet size and the CE input and output
> block processing buffer sizes can be different? So for example lets
> assume I have a 256 * 32 bit in/out buffers for a FFT. I assume the
> packet size could be set to 4 (4 bytes, or one sample) and it would be
> the sending of the EOB (triggered by tlast from sample 255 on packet
> 255) which would subsequently confirm the complete input buffer for
> processing."
>
> After studying the Verilog code in more detail it looks like the full
> packet needs to be sent as the entire transaction. I think the packet
> length in RFNoC is the input or output processing buffer size. Can packet
> transfers be interrupted?
>
>
> Regards
>
>
> Walter
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161019/d0ace6ad/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 19 Oct 2016 07:40:20 +0000
From: "Woelfel, Maximilian" <maximilian.woel...@h-ab.de>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] Using overload detectors in MGC mode
Message-ID: <1bfec54a0c3043f6ad0cffbd1eac6...@rzntms02.hab.h-ab.de>
Content-Type: text/plain; charset="us-ascii"
Hello,
in order to prevent my b200 mini from strong outband interfering signals, I
want to read out the Spi-register 0x2b8 to detect a LMT or ADC overload. Is
there any way to route the Spi-command to the multi-usrp class? I'm not sure
how to use the property tree correctly.
Thanks in advance,
Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161019/e25f4c11/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 19 Oct 2016 10:18:39 +0200
From: Vladica Sark <vladicas...@gmail.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] SFP adapter for 1 GigE for X300/X310
Message-ID: <5627162d-43ab-360e-9df4-791bcc37a...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
I have a couple of 1 GigE SFP adapters:
https://www.finisar.com/sites/default/files/downloads/finisar_fclf-8520-3_fclf-8521-3_1000base-t_copper_sfp_optical_transceiver_productspecreve1.pdf
Can I use them with X300/X310?
Best regards,
Vladica
------------------------------
Message: 13
Date: Wed, 19 Oct 2016 12:01:35 +0200
From: Vladica Sark <vladicas...@gmail.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] X310
Message-ID: <e940d332-afa5-1ca2-6696-99cf9bae8...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi there,
If I want to connect the X310 using 10 GbitE interface, do I have to
connect the both cables in order to achieve 200 MSps on the both channels?
What about PCI interface? Can I achieve 200 MSps on the both channels
using this interface?
BR,
Vladica
------------------------------
Message: 14
Date: Wed, 19 Oct 2016 12:14:42 +0200
From: Pol Henarejos <pol.henare...@cttc.es>
To: Martin Braun <martin.br...@ettus.com>, usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Weird behaviour with set_master_clock_rate
in X300
Message-ID: <4eccae5f-a59e-5455-89e0-24bd78bb1...@cttc.es>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Dear Martin,
Thank you for the appreciation. I'll keep in mind in future. With
master_clock_rate=foo works perfectly.
Regards.
Pol Henarejos
Researcher, MSc
pol.henare...@cttc.es
Centre Tecnol?gic de Telecomunicacions de Catalunya (CTTC)
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 645 29 00 Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es
El 15/10/2016 a les 3:01, Martin Braun via USRP-users ha escrit:
> The behaviour is actually as expected, with a small hitch.
> `set_master_clock_rate()` is only for devices that support changing the
> clock at run time, which the X300 does not. However, we have a known
> issue that the reported clock rate may be wrong.
>
> To confirm, master_clock_rate=foo is *not* a workaround. It's the right
> way to configure this.
>
> Cheers,
> Martin
>
> On 10/14/2016 02:13 AM, Pol Henarejos via USRP-users wrote:
>> Dear Claudio,
>>
>> Thank you! Your snippet works like a charm. This is a temporary
>> workaround but I guess the behvaiour should not be the described one.
>>
>> Thank you again.
>>
>>
>> Pol Henarejos
>> Researcher, MSc
>> pol.henare...@cttc.es
>>
>> Centre Tecnol?gic de Telecomunicacions de Catalunya (CTTC)
>> Av. Carl Friedrich Gauss, 7
>> 08860 Castelldefels, Barcelona (Spain)
>> Tel: +34 93 645 29 00 Ext: 2177
>> Fax. +34 93 645 29 01
>> www.cttc.es
>>
>> El 14/10/2016 a les 10:09, Claudio Cicconetti ha escrit:
>>> Dear Pol,
>>> I experienced the same issue with X300, while the same code with
>>> set_master_clock() works fine with B210.
>>>
>>> I worked around the issue by adding "master_clock_rate=184.32e6" to the
>>> argument of multi_usrp::make(), which works with both X300 and B210.
>>>
>>> Best regards,
>>> Claudio
>>>
>>> On 10/14/2016 09:25 AM, Pol Henarejos via USRP-users wrote:
>>>> Dear all,
>>>>
>>>> I am experimenting some weird issues when I try to change the master
>>>> clock. I wish to set the TX rate of my X300 to 15.36 Msps. So,
>>>> previously I set the master clock to 184.32 MHz in order to obtain an
>>>> integer decimation (184.32/15.36 = 12) but it seems that is not set
>>>> properly. What I get from USRP X300 is the following warning:
>>>>
>>>> UHD Warning:
>>>> The requested interpolation is odd; the user should expect passband
>>>> CIC rolloff.
>>>> Select an even interpolation to ensure that a halfband filter is
>>>> enabled.
>>>> interpolation = dsp_rate/samp_rate -> 13 = (200.000000
>>>> MHz)/(15.360000 MHz)
>>>>
>>>> UHD Warning:
>>>> The hardware does not support the requested TX sample rate:
>>>> Target sample rate: 15.360000 MSps
>>>> Actual sample rate: 15.384615 MSps
>>>>
>>>> I guess that the master clock is set to the default 200 MHz and not
>>>> changed to 184.32e6.
>>>>
>>>> Any clue?
>>>>
>>>> The code is:
>>>>
>>>> usrp->set_master_clock(184.32e6);
>>>> usrp->set_tx_rate(15.36e6); //Warnings are displayed here
>>>>
>>>> I am using the UHD version Win32; Microsoft Visual C++ version 14.0;
>>>> Boost_106000; UHD_003.010.000.000-92-ON
>>>>
>>>> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3741 bytes
Desc: Signatura criptogr??fica S/MIME
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161019/b58d9a12/attachment-0001.p7s>
------------------------------
Message: 15
Date: Wed, 19 Oct 2016 12:50:42 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] [SPAM] Re: Modify the FPGA in X300
Message-ID: <b0076ccf-cf0a-19e2-88e9-1a1ef0a59...@ettus.com>
Content-Type: text/plain; charset=utf-8
Dear Tan,
> I have two daughterboards,one for GPSL1,about 1575.42MHz and 2MHz
> bandwidths,the another for BDB1 about 1560.98 MHz and 2MHz bandwidths.
2 MHz + 2 MHz = 4 MHz, and that perfectly fits through Gigabit ethernet,
as you already show:
> Now,I am using the GNUradio to transform the 16bit samples to 2bit
> samples,and it works well.Now I am interested in GPSL2 about 1226MHz and
> 20MHz bandwidth.
Would that mean that L1 would still be observed with 2 MHz bandwidth? 22
MS/s still easily fit through gigabit ethernet.
Even if you wanted L1 to be 20 MHz, too, a total of 40 MS/s would fit if
you used 8bit samples ? which would be far easier to handle for your
CPU, and also, better for SNR, and also, a bit easier to handle on the FPGA.
> .I am not clear about how to write an AXI4 module that takes in 16bit
> samples and spits out 2bit samples.Should I wirte the module in GNUradio or
> getting started with RFNoC in another way?Can you give me some materials
> about RFNOC.
FPGA development means, in this case, that you'd write Verilog code, and
use Vivado 2015.4 to generate an FPGA image that contains the converter
block, in addition to the the DDC, buffer and radio RFNoC blocks you'd
want to use. Are you sure this is the way you want to go? The learning
curve of FPGA development is somewhat steep.
> If the RFNOC can achieve my goal ,I am willing to use RFNOC,because I
> am not familier with FPGA.
RFNoC for you is only a way to make FPGA development more focussed.
You'd still be doing FPGA development.
Best regards,
Marcus
On 19.10.2016 03:56, ??? via USRP-users wrote:
>
>
>> -----????-----
>> ???: "Marcus M?ller" <marcus.muel...@ettus.com>
>> ????: 2016?10?18? ???
>> ???: "???" <2012301650...@whu.edu.cn>, usrp-users
>> <usrp-users@lists.ettus.com>
>> ??:
>> ??: Re: [SPAM] Re: [USRP-users] Modify the FPGA in X300
>>
>> Hi Tan,
>>
>>> Dear Marcus
>>> Thank you for your help.I am using the x300 to collect GPS data.When
>>> I go outdoors to collect GPS data?I have to use laptop.So I can just link
>>> to the pc across GE.The GE limite the transmission speed.
>> ah, so the link to the PC is the bottleneck
>>> To improve Sampling rate,I hope to the usrp output 2bit samples to the PC.
>> Well, GPS is actually one of the rare cases where such minimal sample
>> depths are possible indeed
>>> Can I achieve it by modifying the fpga code?
>> Yes!
>>> If it is possible to ahieve it ,should I build system follow the FPGA
>>> maunal in http://files.ettus.com/manual/md_usrp3_build_instructions.html?
>> Yes; mostly, however, you should definitely look into getting started
>> with RFNoC. Doing so will allow you to simply write an AXI4 module that
>> takes in 16bit samples and spits out 2bit samples, and UHD will still
>> take care of everything around.
>>
>> Then again: if you're already modifying the FPGA image, it might be
>> worthwhile thinking about which signals and bandwidths you're interested
>> in. Could you elaborate on that?
>>
>> Best regards,
>> Marcus
>
>
> Hi Marcus
> Thank you for your help.I haven't modified FPGA image,regarding the
> signals and bandwidths I'm interested in.I have two daughterboards,one for
> GPSL1,about 1575.42MHz and 2MHz bandwidths,the another for BDB1 about 1560.98
> MHz and 2MHz bandwidths.Now,I am using the GNUradio to transform the 16bit
> samples to 2bit samples,and it works well.Now I am interested in GPSL2 about
> 1226MHz and 20MHz bandwidth.
> I have tried RFNOC in GNUradio following in
> https://kb.ettus.com/RFNoC_Getting_Started_Guides#Installing_UHD.2FRFNoC_Branch.But
> it provides just 8 blocks ,I even can't find a block like usrp source.I am
> not clear about how to write an AXI4 module that takes in 16bit samples and
> spits out 2bit samples.Should I wirte the module in GNUradio or getting
> started with RFNoC in another way?Can you give me some materials about RFNOC.
> If the RFNOC can achieve my goal ,I am willing to use RFNOC,because I
> am not familier with FPGA.
> Thank you in advance.
> Tan
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 16
Date: Wed, 19 Oct 2016 12:51:49 +0200
From: Pol Henarejos <pol.henare...@cttc.es>
To: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] Failed tests when compiling UHD on Windows 10
Message-ID: <ec4222b5-b344-e1a8-682d-e98b59a11...@cttc.es>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Dear all,
I am compiling UHD driver on Windows 10 but when I run RUN_TESTS, some fail.
25/40 Test #25: blockdef_test ....................***Failed
27/40 Test #27: graph_search_test ................***Exception: Other
29/40 Test #29: rate_node_test ...................***Exception: Other
31/40 Test #31: tick_node_test ...................***Exception: Other
Are they meaning something wrong?
I use UHD maint branch 3.10.1.0_rc1
Regards.
--
Pol Henarejos
Researcher, MSc
pol.henare...@cttc.es
Centre Tecnol?gic de Telecomunicacions de Catalunya (CTTC)
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 645 29 00 Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3741 bytes
Desc: Signatura criptogr??fica S/MIME
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161019/7e3f650f/attachment-0001.p7s>
------------------------------
Message: 17
Date: Wed, 19 Oct 2016 13:08:39 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] X310
Message-ID: <65e45adb-44f1-df5c-1b0e-bc0eef7e0...@ettus.com>
Content-Type: text/plain; charset=windows-1252
Hi Vladica,
yes, for 2x 200 MS/s you need the dual-10GE connection (quick calcution:
2*(16 b [I] + 16 b [Q])/S * 200e6 S/s = 12.8 Gb/s ).
PCIe doesn't offer 2x200MS/s
Best regards,
Marcus
On 19.10.2016 12:01, Vladica Sark via USRP-users wrote:
> Hi there,
>
> If I want to connect the X310 using 10 GbitE interface, do I have to
> connect the both cables in order to achieve 200 MSps on the both
> channels?
>
> What about PCI interface? Can I achieve 200 MSps on the both channels
> using this interface?
>
> BR,
> Vladica
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 18
Date: Wed, 19 Oct 2016 13:10:10 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] SFP adapter for 1 GigE for X300/X310
Message-ID: <aaee7da2-d450-dac6-18d1-2dd7eb454...@ettus.com>
Content-Type: text/plain; charset=windows-1252
Hi Vladica,
if it says "SFP" and "1000Base", you can use it for Gigabit Ethernet
connectivity. If it says "SFP+" and "10GBase", you can use it for 10GE
connectivity. I've yet to encounter incompatible transceivers :)
Generally, how far's the distance you have to bridge?
Best regards,
Marcus
On 19.10.2016 10:18, Vladica Sark via USRP-users wrote:
> Hi,
>
> I have a couple of 1 GigE SFP adapters:
> https://www.finisar.com/sites/default/files/downloads/finisar_fclf-8520-3_fclf-8521-3_1000base-t_copper_sfp_optical_transceiver_productspecreve1.pdf
>
>
> Can I use them with X300/X310?
>
> Best regards,
> Vladica
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 19
Date: Wed, 19 Oct 2016 13:11:32 +0200
From: Vladica Sark <vladicas...@gmail.com>
To: Marcus M?ller <marcus.muel...@ettus.com>,
usrp-users@lists.ettus.com
Subject: Re: [USRP-users] X310
Message-ID: <7c0389fc-4a33-0df8-de99-d6eaf598c...@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Thanks for the valuable info. I didn't know that PCIe does not support
2x200MS/s
Best regards,
Vladica
On 19.10.2016 13:08, Marcus M?ller via USRP-users wrote:
> Hi Vladica,
>
> yes, for 2x 200 MS/s you need the dual-10GE connection (quick calcution:
> 2*(16 b [I] + 16 b [Q])/S * 200e6 S/s = 12.8 Gb/s ).
>
> PCIe doesn't offer 2x200MS/s
>
> Best regards,
>
> Marcus
>
> On 19.10.2016 12:01, Vladica Sark via USRP-users wrote:
>> Hi there,
>>
>> If I want to connect the X310 using 10 GbitE interface, do I have to
>> connect the both cables in order to achieve 200 MSps on the both
>> channels?
>>
>> What about PCI interface? Can I achieve 200 MSps on the both channels
>> using this interface?
>>
>> BR,
>> Vladica
>>
>> _______________________________________________
>> 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
>
------------------------------
Message: 20
Date: Wed, 19 Oct 2016 13:14:27 +0200
From: Vladica Sark <vladicas...@gmail.com>
To: Marcus M?ller <marcus.muel...@ettus.com>,
usrp-users@lists.ettus.com
Subject: Re: [USRP-users] SFP adapter for 1 GigE for X300/X310
Message-ID: <34ea267a-9074-f631-6344-fdaa59b1b...@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Markus,
I found out later that x310 comes with 1G SFP adapter, therefore I do
not need the ones I have. I just thought if I have to order them from
Ettus or use the ones I have.
The distance is not an issue anyway.
Best regards,
Vladica
On 19.10.2016 13:10, Marcus M?ller via USRP-users wrote:
> Hi Vladica,
>
> if it says "SFP" and "1000Base", you can use it for Gigabit Ethernet
> connectivity. If it says "SFP+" and "10GBase", you can use it for 10GE
> connectivity. I've yet to encounter incompatible transceivers :)
>
> Generally, how far's the distance you have to bridge?
>
> Best regards,
>
> Marcus
>
>
> On 19.10.2016 10:18, Vladica Sark via USRP-users wrote:
>> Hi,
>>
>> I have a couple of 1 GigE SFP adapters:
>> https://www.finisar.com/sites/default/files/downloads/finisar_fclf-8520-3_fclf-8521-3_1000base-t_copper_sfp_optical_transceiver_productspecreve1.pdf
>>
>>
>> Can I use them with X300/X310?
>>
>> Best regards,
>> Vladica
>>
>> _______________________________________________
>> 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
>
------------------------------
Message: 21
Date: Wed, 19 Oct 2016 13:15:09 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: Vladica Sark <vladicas...@gmail.com>, usrp-users@lists.ettus.com
Subject: Re: [USRP-users] X310
Message-ID: <e7119598-8a8d-c01a-1ee8-3492939f0...@ettus.com>
Content-Type: text/plain; charset=windows-1252
Hi Vladica,
The PCIe interface we use can't deal with the raw data rates of 2x
200MS/s [1], and you can't have two of them. So, that won't work.
Best regards,
Marcus
[1] https://kb.ettus.com/X300/X310#Choosing_a_Host_Interface
On 19.10.2016 13:11, Vladica Sark wrote:
> Thanks for the valuable info. I didn't know that PCIe does not support
> 2x200MS/s
>
> Best regards,
> Vladica
>
>
> On 19.10.2016 13:08, Marcus M?ller via USRP-users wrote:
>> Hi Vladica,
>>
>> yes, for 2x 200 MS/s you need the dual-10GE connection (quick calcution:
>> 2*(16 b [I] + 16 b [Q])/S * 200e6 S/s = 12.8 Gb/s ).
>>
>> PCIe doesn't offer 2x200MS/s
>>
>> Best regards,
>>
>> Marcus
>>
>> On 19.10.2016 12:01, Vladica Sark via USRP-users wrote:
>>> Hi there,
>>>
>>> If I want to connect the X310 using 10 GbitE interface, do I have to
>>> connect the both cables in order to achieve 200 MSps on the both
>>> channels?
>>>
>>> What about PCI interface? Can I achieve 200 MSps on the both channels
>>> using this interface?
>>>
>>> BR,
>>> Vladica
>>>
>>> _______________________________________________
>>> 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
>>
------------------------------
Message: 22
Date: Wed, 19 Oct 2016 13:18:52 +0200
From: Vladica Sark <vladicas...@gmail.com>
To: Marcus M?ller <marcus.muel...@ettus.com>,
usrp-users@lists.ettus.com
Subject: Re: [USRP-users] X310
Message-ID: <e2f33a5d-958a-2e5a-854c-7054df0c9...@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Markus,
But if I get the 2x 10G Ethernet, it has enough bandwidth for the RAW
2x200MS/s rate.
Is this supported by the radio?
Do I see them as 2 separate radios, since they would have separate IP
addresses?
Any idea about the latency when using 10G Ethernet?
Best regards,
Vladica
On 19.10.2016 13:15, Marcus M?ller wrote:
> Hi Vladica,
>
> The PCIe interface we use can't deal with the raw data rates of 2x
> 200MS/s [1], and you can't have two of them. So, that won't work.
>
> Best regards,
>
> Marcus
>
> [1] https://kb.ettus.com/X300/X310#Choosing_a_Host_Interface
>
>
> On 19.10.2016 13:11, Vladica Sark wrote:
>> Thanks for the valuable info. I didn't know that PCIe does not support
>> 2x200MS/s
>>
>> Best regards,
>> Vladica
>>
>>
>> On 19.10.2016 13:08, Marcus M?ller via USRP-users wrote:
>>> Hi Vladica,
>>>
>>> yes, for 2x 200 MS/s you need the dual-10GE connection (quick calcution:
>>> 2*(16 b [I] + 16 b [Q])/S * 200e6 S/s = 12.8 Gb/s ).
>>>
>>> PCIe doesn't offer 2x200MS/s
>>>
>>> Best regards,
>>>
>>> Marcus
>>>
>>> On 19.10.2016 12:01, Vladica Sark via USRP-users wrote:
>>>> Hi there,
>>>>
>>>> If I want to connect the X310 using 10 GbitE interface, do I have to
>>>> connect the both cables in order to achieve 200 MSps on the both
>>>> channels?
>>>>
>>>> What about PCI interface? Can I achieve 200 MSps on the both channels
>>>> using this interface?
>>>>
>>>> BR,
>>>> Vladica
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>
------------------------------
Message: 23
Date: Wed, 19 Oct 2016 13:24:21 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: Vladica Sark <vladicas...@gmail.com>, usrp-users@lists.ettus.com
Subject: Re: [USRP-users] X310
Message-ID: <4b6fd27d-f34f-425b-2b49-2a754a724...@ettus.com>
Content-Type: text/plain; charset=windows-1252
Hi Vladica,
On 19.10.2016 13:18, Vladica Sark wrote:
> Hi Markus,
>
> But if I get the 2x 10G Ethernet, it has enough bandwidth for the RAW
> 2x200MS/s rate.
> Is this supported by the radio?
Yes!
> Do I see them as 2 separate radios, since they would have separate IP
> addresses?
No; you'd just specify a second IP address; see the "Dual 10 Gigabit
Ethernet" section in the manual [1].
> Any idea about the latency when using 10G Ethernet?
Not really much higher than PCIe in most usage scenarios. Your mileage
might vary, but think of 100?s up. It really depends mostly on your host
computer and its OS, so general numbers are really impossible to give. I
haven't done any latency testing with dual 10GE, and it probably doubles
the latency.
In many applications, latency can be "hidden" by usage of *timed
commands*; are you familiar with those? what's your application?
Best regards,
Marcus
>
> Best regards,
> Vladica
[1] http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_hw_10gige
>
>
> On 19.10.2016 13:15, Marcus M?ller wrote:
>> Hi Vladica,
>>
>> The PCIe interface we use can't deal with the raw data rates of 2x
>> 200MS/s [1], and you can't have two of them. So, that won't work.
>>
>> Best regards,
>>
>> Marcus
>>
>> [1] https://kb.ettus.com/X300/X310#Choosing_a_Host_Interface
>>
>>
>> On 19.10.2016 13:11, Vladica Sark wrote:
>>> Thanks for the valuable info. I didn't know that PCIe does not support
>>> 2x200MS/s
>>>
>>> Best regards,
>>> Vladica
>>>
>>>
>>> On 19.10.2016 13:08, Marcus M?ller via USRP-users wrote:
>>>> Hi Vladica,
>>>>
>>>> yes, for 2x 200 MS/s you need the dual-10GE connection (quick
>>>> calcution:
>>>> 2*(16 b [I] + 16 b [Q])/S * 200e6 S/s = 12.8 Gb/s ).
>>>>
>>>> PCIe doesn't offer 2x200MS/s
>>>>
>>>> Best regards,
>>>>
>>>> Marcus
>>>>
>>>> On 19.10.2016 12:01, Vladica Sark via USRP-users wrote:
>>>>> Hi there,
>>>>>
>>>>> If I want to connect the X310 using 10 GbitE interface, do I have to
>>>>> connect the both cables in order to achieve 200 MSps on the both
>>>>> channels?
>>>>>
>>>>> What about PCI interface? Can I achieve 200 MSps on the both channels
>>>>> using this interface?
>>>>>
>>>>> BR,
>>>>> Vladica
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>
------------------------------
Message: 24
Date: Wed, 19 Oct 2016 15:49:04 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: ??? <2012301650...@whu.edu.cn>, usrp-users
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Modify the FPGA in X300
Message-ID: <b032a939-b34c-204e-1b86-0b4b7acd5...@ettus.com>
Content-Type: text/plain; charset=utf-8
Hi Tan,
> I hope 25MHz sampling rate for L2 and 5Mhz for L1,considering IQ
> sampling, a total of 60 MS/s would fit.But I am sorry that I am not clear
> about two things?
I'm talking about complex sampling all the time. 30MS/s (complex) fit
through Gigabit Ethernet, see calculation below.
> 1? I am now using the GNUradio to control the usrp.I am not clear about
> how to use usrp_source block to set the Output Type to 8bit,I have only
> Complex Int 16 and Float 32 to choose.Do you mean the Wire Format decides the
> output bits?
Exactly. the X3xx doesn't support any transport format other than SC16
(16bit I+16bit Q) out of the box. That is why you need to modify the
FPGA if you want 8 or 2 bit samples on the wire.
> 2?And I can just set one sampling rate,I am not clear about setting
> different sampling rate in different channels.
I think you're right, this is a current limitation of the USRP source in
GNU Radio, as far as I can tell. Let me think about this and discuss it
with the others.
> I think if I can use 8bit samples and two different sampling rate,my
> problem will be solved.Thank you in advance.
As said, 25MS/s + 5 MS/s = 30 MS/s *do* fit through to Gigabit Ethernet,
though just barely:
(25+5) MS/s * (16b [I] + 16b [Q])/S
= 30MS/s * 32 b/S
= 960 Mb/s
< 1 Gb/s
which leaves headroom for 4% overhead; with a reasonable MTU of 4kB, 4%
is about 160 Bytes ? much more than the Ethernet + IP + UDP + UHD
headers need. However, your mileage might vary ? it's not guaranteed
that your host and your Network card can keep up to nearly-saturated
Gigabit ethernet.
Best regards,
Marcus
On 19.10.2016 14:51, ??? wrote:
>
>
>> -----????-----
>> ???: "Marcus M?ller via USRP-users" <usrp-users@lists.ettus.com>
>> ????: 2016?10?19? ???
>> ???: usrp-users@lists.ettus.com
>> ??:
>> ??: Re: [USRP-users] [SPAM] Re: Modify the FPGA in X300
>>
>> Dear Tan,
>>
>>> I have two daughterboards,one for GPSL1,about 1575.42MHz and 2MHz
>>> bandwidths,the another for BDB1 about 1560.98 MHz and 2MHz bandwidths.
>> 2 MHz + 2 MHz = 4 MHz, and that perfectly fits through Gigabit ethernet,
>> as you already show:
>>
>>> Now,I am using the GNUradio to transform the 16bit samples to 2bit
>>> samples,and it works well.Now I am interested in GPSL2 about 1226MHz and
>>> 20MHz bandwidth.
>> Would that mean that L1 would still be observed with 2 MHz bandwidth? 22
>> MS/s still easily fit through gigabit ethernet.
>>
>> Even if you wanted L1 to be 20 MHz, too, a total of 40 MS/s would fit if
>> you used 8bit samples ? which would be far easier to handle for your
>> CPU, and also, better for SNR, and also, a bit easier to handle on the FPGA.
>>
>>
>>> .I am not clear about how to write an AXI4 module that takes in 16bit
>>> samples and spits out 2bit samples.Should I wirte the module in GNUradio or
>>> getting started with RFNoC in another way?Can you give me some materials
>>> about RFNOC.
>> FPGA development means, in this case, that you'd write Verilog code, and
>> use Vivado 2015.4 to generate an FPGA image that contains the converter
>> block, in addition to the the DDC, buffer and radio RFNoC blocks you'd
>> want to use. Are you sure this is the way you want to go? The learning
>> curve of FPGA development is somewhat steep.
>>
>>> If the RFNOC can achieve my goal ,I am willing to use RFNOC,because
>>> I am not familier with FPGA.
>> RFNoC for you is only a way to make FPGA development more focussed.
>> You'd still be doing FPGA development.
>>
>> Best regards,
>> Marcus
>>
> Dear Marcus
> I hope 25MHz sampling rate for L2 and 5Mhz for L1,considering IQ
> sampling, a total of 60 MS/s would fit.But I am sorry that I am not clear
> about two things?
> 1? I am now using the GNUradio to control the usrp.I am not clear about
> how to use usrp_source block to set the Output Type to 8bit,I have only
> Complex Int 16 and Float 32 to choose.Do you mean the Wire Format decides the
> output bits?
> 2?And I can just set one sampling rate,I am not clear about setting
> different sampling rate in different channels.
> I think if I can use 8bit samples and two different sampling rate,my
> problem will be solved.Thank you in advance.
>
> Best regards,
> Tan
>
>
------------------------------
Message: 25
Date: Wed, 19 Oct 2016 10:04:25 -0400
From: Jason Matusiak <ja...@gardettoengineering.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] rfnocmodtool not working
Message-ID:
<f5f464b2-082e-017d-c63a-2fd711fbf...@gardettoengineering.com>
Content-Type: text/plain; charset=utf-8; format=flowed
I have a fresh load of 14.04 and everything set itself up flawlessly. I
built a test bitfile using make.py and everything worked great. I then
went to create a new rfnoc module by running: rfnocmodtool newmod
multiaperture
and got the following feedback back:
Traceback (most recent call last):
File "/home/jmat/rfnoc/bin/rfnocmodtool", line 5, in <module>
from ettus.rfnoc_modtool import *
File
"/home/jmat/rfnoc/lib/python2.7/dist-packages/ettus/rfnoc_modtool/__init__.py",
line 6, in <module>
from modtool_base import ModTool, ModToolException, get_class_dict
File
"/home/jmat/rfnoc/lib/python2.7/dist-packages/ettus/rfnoc_modtool/modtool_base.py",
line 27, in <module>
from gnuradio import gr
File
"/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/__init__.py",
line 41, in <module>
from runtime_swig import *
File
"/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
line 28, in <module>
_runtime_swig = swig_import_helper()
File
"/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
line 24, in swig_import_helper
_mod = imp.load_module('_runtime_swig', fp, pathname, description)
ImportError: libthrift-0.9.3.so: cannot open shared object file: No such
file or directory
Did a package not get installed correctly? If I try to tab out sudo
apt-get install libthr, the only option I get is libthrift-java, which
doesn't sound right. Any suggestions?
------------------------------
Message: 26
Date: Wed, 19 Oct 2016 10:55:39 -0400
From: Jason Matusiak <ja...@gardettoengineering.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] rfnocmodtool not working
Message-ID:
<0c24b4db-208d-6445-5b5c-ae7d38e45...@gardettoengineering.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Well, I think I have it working again. I went and downloaded the
libthrift tarball
(http://www.apache.org/dyn/closer.cgi?path=/thrift/0.9.3/thrift-0.9.3.tar.gz)
and installed it by hand (followed by a sudo ldconfig). Is this maybe a
requirement that should be added to the instructions?
~Jason
On 10/19/2016 10:04 AM, Jason Matusiak wrote:
> I have a fresh load of 14.04 and everything set itself up flawlessly.
> I built a test bitfile using make.py and everything worked great. I
> then went to create a new rfnoc module by running: rfnocmodtool newmod
> multiaperture
>
> and got the following feedback back:
> Traceback (most recent call last):
> File "/home/jmat/rfnoc/bin/rfnocmodtool", line 5, in <module>
> from ettus.rfnoc_modtool import *
> File
> "/home/jmat/rfnoc/lib/python2.7/dist-packages/ettus/rfnoc_modtool/__init__.py",
>
> line 6, in <module>
> from modtool_base import ModTool, ModToolException, get_class_dict
> File
> "/home/jmat/rfnoc/lib/python2.7/dist-packages/ettus/rfnoc_modtool/modtool_base.py",
>
> line 27, in <module>
> from gnuradio import gr
> File
> "/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/__init__.py",
> line 41, in <module>
> from runtime_swig import *
> File
> "/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
> line 28, in <module>
> _runtime_swig = swig_import_helper()
> File
> "/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
> line 24, in swig_import_helper
> _mod = imp.load_module('_runtime_swig', fp, pathname, description)
> ImportError: libthrift-0.9.3.so: cannot open shared object file: No
> such file or directory
>
> Did a package not get installed correctly? If I try to tab out sudo
> apt-get install libthr, the only option I get is libthrift-java, which
> doesn't sound right. Any suggestions?
------------------------------
Message: 27
Date: Wed, 19 Oct 2016 17:08:00 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] rfnocmodtool not working
Message-ID: <50213101-74d6-129d-e91b-aaa094d78...@ettus.com>
Content-Type: text/plain; charset=windows-1252
Hi Jason,
we need to separate this: what fails here has nothing to do with
rfnocmodtool, but the loading of the GNU Radio runtime library, because
it's missing a library. That means that at compile time, there was a
libthrift-0.9.3.so, but now, at runtime, it can't be found. This is
clearly an installation problem. Are you sure you've set all the library
paths correctly?
So, no, this is not a thing we should add to the rfnocmodtool
documentation; the "you need a working GNU Radio installation" is implicit.
Best regards,
Marcus
On 19.10.2016 16:55, Jason Matusiak via USRP-users wrote:
> Well, I think I have it working again. I went and downloaded the
> libthrift tarball
> (http://www.apache.org/dyn/closer.cgi?path=/thrift/0.9.3/thrift-0.9.3.tar.gz)
> and installed it by hand (followed by a sudo ldconfig). Is this maybe
> a requirement that should be added to the instructions?
>
> ~Jason
>
> On 10/19/2016 10:04 AM, Jason Matusiak wrote:
>> I have a fresh load of 14.04 and everything set itself up
>> flawlessly. I built a test bitfile using make.py and everything
>> worked great. I then went to create a new rfnoc module by running:
>> rfnocmodtool newmod multiaperture
>>
>> and got the following feedback back:
>> Traceback (most recent call last):
>> File "/home/jmat/rfnoc/bin/rfnocmodtool", line 5, in <module>
>> from ettus.rfnoc_modtool import *
>> File
>> "/home/jmat/rfnoc/lib/python2.7/dist-packages/ettus/rfnoc_modtool/__init__.py",
>> line 6, in <module>
>> from modtool_base import ModTool, ModToolException, get_class_dict
>> File
>> "/home/jmat/rfnoc/lib/python2.7/dist-packages/ettus/rfnoc_modtool/modtool_base.py",
>> line 27, in <module>
>> from gnuradio import gr
>> File
>> "/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/__init__.py",
>> line 41, in <module>
>> from runtime_swig import *
>> File
>> "/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
>> line 28, in <module>
>> _runtime_swig = swig_import_helper()
>> File
>> "/home/jmat/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
>> line 24, in swig_import_helper
>> _mod = imp.load_module('_runtime_swig', fp, pathname, description)
>> ImportError: libthrift-0.9.3.so: cannot open shared object file: No
>> such file or directory
>>
>> Did a package not get installed correctly? If I try to tab out sudo
>> apt-get install libthr, the only option I get is libthrift-java,
>> which doesn't sound right. Any suggestions?
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 74, Issue 19
******************************************
