Send USRP-users mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: low frequency ADC flicker noise (Ettus x310) (Attila Kinali)
2. Re: low frequency ADC flicker noise (Ettus x310)
(Leandro Echevarr?a)
3. Defeating AGC on TVRX2 (Eric C.)
4. Re: Defeating AGC on TVRX2 (Marcus M?ller)
5. Re: Error with multiple block output ports (Barker, Douglas W.)
6. Re: Error with multiple block output ports (Jason Matusiak)
7. why will my direct copy of DDC RFNoC block not work????
(Jason Matusiak)
8. Fw:Re:Re: x310 FPGA code (Lihua Ren)
9. x310 (Lihua Ren)
10. Combining N210 and X310 in single multi_usrp (Vladica Sark)
11. Re: Combining N210 and X310 in single multi_usrp (Nicolas Cuervo)
12. Re: Gnuradio wideband processing speed (?????? ????)
13. USB 3.0 connection problems (USRP 205mini + ODROID XU4)
(Rom?n Rodr?guez P?rez)
----------------------------------------------------------------------
Message: 1
Date: Wed, 31 May 2017 18:21:13 +0200
From: Attila Kinali <[email protected]>
To: [email protected]
Cc: "Hofer, Russell Dwayne" <[email protected]>, [email protected]
Subject: Re: [USRP-users] low frequency ADC flicker noise (Ettus x310)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII
Moin
On Wed, 31 May 2017 11:50:51 -0400
"Marcus D. Leech via USRP-users" <[email protected]> wrote:
> On 2017-05-31 10:53, Hofer, Russell Dwayne via USRP-users wrote:
>
> > We have developed a system that utilizes Ettus X310 radios in order to
> > perform low frequency data collection (0 - 2 MHz). The system is
> > ruggedized for outdoor use, and utilizes an x310 along with some of our own
> >
> > custom hardware. We have used these systems several times in multi-day
> > continuous collection intervals.
> >
> > There is one glaring concern that I found when doing noise comparisons
> > between the new Ettus based system and a legacy data collection system.
> > The low frequency 1/f flicker noise from the X310's ADC is significantly
> > impacting our performance, to the point where noise levels become
> > dramatically worse than our legacy system below 25 kHz (we decimate to 4
> > MSPS using the standard FPGA image, and then perform an FFT to observe the
> > ambient noise). 25 kHz is the cross-over point, and the noise level
> > continues to increase at a rate of 1/f - i.e. very strong noise levels
> > exist at lower frequencies. Not only that, there is a significant level of
> >
> > flicker noise across the entire bandwidth; my testing shows that the ADC's
> > 1/f flicker noise doesn't level out until 10-20 MHz - so it appears that we
> >
Yes, the flicker noise of high speed ADCs is quite high. Though a corner
frequency of >10MHz seems a bit too high. The measurements I have seen
(from Enrico Rubiola one or two years ago) suggest that the corner frequency
is usually in the order of 100kHz to 1MHz. Maybe there is power supply noise
or reference noise coupling into to the ADC.
> > 1) I know that mixing the low frequency signal to a higher frequency
> > may be an option, but I would rather not do so in order to avoid dealing
> > with the non-ideal characteristics of a mixer, specifically the
> > distortion. Or, is this the only practical way to fix it?
It is definitly one way. There are quite good mixers that can achieve
a low distortion, low noise upmixing.
> > 2) Has anyone explored the idea of chopping the input by using a
> > synchronized RF/sampling switch ? The idea is to multiply the low
> > frequency input signal by a square wave, and then after it is digitized,
> > multiply it by a square wave in the digital domain. The end result is that
> >
> > the 1/f noise would still exist, but would be shifted higher in frequency
> > since it is only multiplied by the square wave one time in the digital
> > domain.
This is another possibiltiy, but the noise from the switches will dominate
anything else. Beside, finding switches that can handle a switching rate
of 4MHz are kind of rare. And I wouldn't trust them to be low noise either.
The mixer approach is way better and easier to do.
> > 3) Is there a different replacement ADC that may perform better (i.e.
> > have a chopper mode) ?
This is the easiest approach IMHO. The lower speed the ADC the lower
its 1/f noise corner frequency is. As you only need 4Msps you can use
one of the fasts SAR ADCs from Analog. I have not seen any 1/f corner
frequency of those, but I would be surprised if it's that high.
> High-speed, CMOS ADCs suffer from higher 1/F noise corners than there
> older bipolar counterparts.
>
> This article offers some insight:
>
> http://www.highfrequencyelectronics.com/index.php?option=com_content&view=article&id=1160:eliminate-high-speed-adc-flicker-noise-with-chopper-upgrade&catid=123&Itemid=189
>
>
> Installing a different ADC would be a *significant* amount of work,
> involving hardware surgery, significant FPGA changes, and significant
> changes in the UHD drivers. That would not be a trivial change.
Using a different ADC is by far easier than to get the right mixer
architecture to achieve low noise and low distortion.
That said: How about trying a different board?
We recently built a ADC/SDR board specifally with low noise applications
in mind. I haven't had time to really measure the 1/f corner yet, but
it is low enough (much smaller than 1MHz, probably 100kHz'ish)
that it didn't really show up in our measurements.
You can find the documentation and production files at [1].
I am currently writing a paper describing the design and how to use
it (which should be published at EFTF/IFCS next month).
Which way to go and what ADC/circuit architecture to use depends highly
on what your projects parameters are. You have told us only the bandwidth
sofar. We don't know anything about the noise level you want to achieve
or what impedance your signal has.
Attila Kinali
[1] http://www.ohwr.org/projects/r19-tdc-del-a/wiki
--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson
------------------------------
Message: 2
Date: Wed, 31 May 2017 16:41:36 +0000
From: Leandro Echevarr?a <[email protected]>
To: Attila Kinali <[email protected]>, [email protected]
Cc: "Hofer, Russell Dwayne" <[email protected]>
Subject: Re: [USRP-users] low frequency ADC flicker noise (Ettus x310)
Message-ID:
<caleoa2jqea9u6drarlvhexw6fx5quusjyyutg8salj20ttk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Russell,
Could you not use a different frequency in the local oscillators in the
receiving path so as to convert to a slightly off-DC frequency and sample
two repeating images of the spectrum of your signal of interest? Of course,
this is assuming your signal is not already in baseband (which I assume
given most daughterboards for the x310 are for passband signals) and that
you can perform some sort of channel filtering around those 2 MHz of
bandwidth you're interested in before digitalizing (otherwise you'd get
aliasing).
Regards,
Leo.
On Wed, May 31, 2017 at 1:22 PM Attila Kinali via USRP-users <
[email protected]> wrote:
> Moin
>
> On Wed, 31 May 2017 11:50:51 -0400
> "Marcus D. Leech via USRP-users" <[email protected]> wrote:
>
>
> > On 2017-05-31 10:53, Hofer, Russell Dwayne via USRP-users wrote:
> >
> > > We have developed a system that utilizes Ettus X310 radios in order to
> > > perform low frequency data collection (0 - 2 MHz). The system is
> > > ruggedized for outdoor use, and utilizes an x310 along with some of
> our own
> > > custom hardware. We have used these systems several times in multi-day
> > > continuous collection intervals.
> > >
> > > There is one glaring concern that I found when doing noise comparisons
> > > between the new Ettus based system and a legacy data collection system.
> > > The low frequency 1/f flicker noise from the X310's ADC is
> significantly
> > > impacting our performance, to the point where noise levels become
> > > dramatically worse than our legacy system below 25 kHz (we decimate to
> 4
> > > MSPS using the standard FPGA image, and then perform an FFT to observe
> the
> > > ambient noise). 25 kHz is the cross-over point, and the noise level
> > > continues to increase at a rate of 1/f - i.e. very strong noise levels
> > > exist at lower frequencies. Not only that, there is a significant
> level of
> > > flicker noise across the entire bandwidth; my testing shows that the
> ADC's
> > > 1/f flicker noise doesn't level out until 10-20 MHz - so it appears
> that we
>
> Yes, the flicker noise of high speed ADCs is quite high. Though a corner
> frequency of >10MHz seems a bit too high. The measurements I have seen
> (from Enrico Rubiola one or two years ago) suggest that the corner
> frequency
> is usually in the order of 100kHz to 1MHz. Maybe there is power supply
> noise
> or reference noise coupling into to the ADC.
>
>
> > > 1) I know that mixing the low frequency signal to a higher
> frequency
> > > may be an option, but I would rather not do so in order to avoid
> dealing
> > > with the non-ideal characteristics of a mixer, specifically the
> > > distortion. Or, is this the only practical way to fix it?
>
> It is definitly one way. There are quite good mixers that can achieve
> a low distortion, low noise upmixing.
>
>
> > > 2) Has anyone explored the idea of chopping the input by using a
> > > synchronized RF/sampling switch ? The idea is to multiply the low
> > > frequency input signal by a square wave, and then after it is
> digitized,
> > > multiply it by a square wave in the digital domain. The end result is
> that
> > > the 1/f noise would still exist, but would be shifted higher in
> frequency
> > > since it is only multiplied by the square wave one time in the digital
> > > domain.
>
> This is another possibiltiy, but the noise from the switches will dominate
> anything else. Beside, finding switches that can handle a switching rate
> of 4MHz are kind of rare. And I wouldn't trust them to be low noise either.
> The mixer approach is way better and easier to do.
>
>
> > > 3) Is there a different replacement ADC that may perform better
> (i.e.
> > > have a chopper mode) ?
>
> This is the easiest approach IMHO. The lower speed the ADC the lower
> its 1/f noise corner frequency is. As you only need 4Msps you can use
> one of the fasts SAR ADCs from Analog. I have not seen any 1/f corner
> frequency of those, but I would be surprised if it's that high.
>
> > High-speed, CMOS ADCs suffer from higher 1/F noise corners than there
> > older bipolar counterparts.
> >
> > This article offers some insight:
> >
> >
> http://www.highfrequencyelectronics.com/index.php?option=com_content&view=article&id=1160:eliminate-high-speed-adc-flicker-noise-with-chopper-upgrade&catid=123&Itemid=189
> >
> >
> > Installing a different ADC would be a *significant* amount of work,
> > involving hardware surgery, significant FPGA changes, and significant
> > changes in the UHD drivers. That would not be a trivial change.
>
> Using a different ADC is by far easier than to get the right mixer
> architecture to achieve low noise and low distortion.
>
> That said: How about trying a different board?
> We recently built a ADC/SDR board specifally with low noise applications
> in mind. I haven't had time to really measure the 1/f corner yet, but
> it is low enough (much smaller than 1MHz, probably 100kHz'ish)
> that it didn't really show up in our measurements.
> You can find the documentation and production files at [1].
> I am currently writing a paper describing the design and how to use
> it (which should be published at EFTF/IFCS next month).
>
> Which way to go and what ADC/circuit architecture to use depends highly
> on what your projects parameters are. You have told us only the bandwidth
> sofar. We don't know anything about the noise level you want to achieve
> or what impedance your signal has.
>
>
> Attila Kinali
>
>
> [1] http://www.ohwr.org/projects/r19-tdc-del-a/wiki
> --
> It is upon moral qualities that a society is ultimately founded. All
> the prosperity and technological sophistication in the world is of no
> use without that foundation.
> -- Miss Matheson, The Diamond Age, Neil Stephenson
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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/20170531/5d707fc0/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 31 May 2017 11:16:32 -0600
From: "Eric C." <[email protected]>
To: [email protected]
Subject: [USRP-users] Defeating AGC on TVRX2
Message-ID:
<cabf-ja4qsqqywed6uy+1pqon7exs1ecsbjtx1hg50i03ntn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
We have a TVRX2 card and it works well for us as we need the separate input
tuners and no xmit capability. I know there is a lot of discussion saying
the AGC can't be bypassed. I imagine that means it's in hardware somewhere
in the front end? If so, my co-worker had an idea on how to defeat it.
We're interested in a signal that is occasionally on, it comes in bursts.
What if we sub-band tuned about the frequency of interest to our signal,
but left an always on tone somewhere else within the bandwidth of the front
end (USRP N210 - so 100 MHz?) at a significantly higher power than our
signal. Assuming the AGC operates before our software sub-band tuning
wouldn't it lock to that signal and then the transition band and amplitude
effects on our signal of interest would be preserved? I guess the big
question is if the AGC operates in hardware on the full input bandwidth?
Thanks.
-- Eric C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170531/9a17ef3e/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 31 May 2017 19:50:53 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Defeating AGC on TVRX2
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Eric,
you're right, the AGC is tightly integrated into the RFIC (TDA18272) of
the TVRX2 [1].
Well, deafening the AGC by having a strong signal would probably work, but:
you're also not getting a good dynamic range that way, so I'm not sure
we can actually *solve* a problem here!
But I think it would be worth trying, so to answer:
> I guess the big question is if the AGC operates in hardware on the
> full input bandwidth? Thanks.
>
There's 5 stages of AGC in the IC, see the attached data sheet. Some
work on the unfiltered RF, some on bandpass, some on IF :( As
documentation for what you can adjust, I'd recommend looking into our
driver [2]. I sadly don't have a register map for the TDA18272 at hand.
Best regards,
Marcus
[1] https://files.ettus.com/schematics
On 31.05.2017 19:16, Eric C. via USRP-users wrote:
> We have a TVRX2 card and it works well for us as we need the separate
> input tuners and no xmit capability. I know there is a lot of
> discussion saying the AGC can't be bypassed. I imagine that means it's
> in hardware somewhere in the front end? If so, my co-worker had an
> idea on how to defeat it.
>
> We're interested in a signal that is occasionally on, it comes in
> bursts. What if we sub-band tuned about the frequency of interest to
> our signal, but left an always on tone somewhere else within the
> bandwidth of the front end (USRP N210 - so 100 MHz?) at a
> significantly higher power than our signal. Assuming the AGC operates
> before our software sub-band tuning wouldn't it lock to that signal
> and then the transition band and amplitude effects on our signal of
> interest would be preserved? I guess the big question is if the AGC
> operates in hardware on the full input bandwidth? Thanks.
>
> -- Eric C.
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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/20170531/9683a3e9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TDA18272.pdf
Type: application/pdf
Size: 211397 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170531/9683a3e9/attachment-0001.pdf>
------------------------------
Message: 5
Date: Wed, 31 May 2017 17:52:23 +0000
From: "Barker, Douglas W." <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>, "Yim,
Kaun J." <[email protected]>, "Brassard, Sean M."
<[email protected]>
Subject: Re: [USRP-users] Error with multiple block output ports
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Jonathon,
I corrected the mistake in ?noc_block_split_stream.v?.
In the ?uhd_rfnoc_split_stream.xml? file I changed ?channels=(0,1)? to
?channels=(0,1,2)? and it produces the same error as before. I also tried
many combinations of ?channels=xxx? and it either error?s out on a python
interpreter error or the same error as before. Is there a way to specify 3
channels that I?m not aware of?
Thanks
Doug
From: Jonathon Pendlum [mailto:[email protected]]
Sent: Monday, May 29, 2017 2:16 AM
To: Barker, Douglas W.
Cc: [email protected]
Subject: Re: [USRP-users] Error with multiple block output ports
Try fixing these issues, especially the first one, and see if that helps:
- In uhd_rfnoc_split_stream.xml, the RX stream args defines 2 channels instead
of 3.
- In noc_block_split_stream.v, the ACTIVE_MASK on split_stream_fifo is set to
have only two active outputs.
On Fri, May 26, 2017 at 8:03 AM, Barker, Douglas W.
<[email protected]<mailto:[email protected]>> wrote:
Jonathon,
I?ve attached the XML files that I was using.
Thanks!
Doug
From: Jonathon Pendlum
[mailto:[email protected]<mailto:[email protected]>]
Sent: Thursday, May 25, 2017 3:46 PM
To: Barker, Douglas W.
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] Error with multiple block output ports
Hi Doug,
Can you share your Noc Script XML file?
Jonathon
On Fri, May 19, 2017 at 2:17 PM, Barker, Douglas W. via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hello,
I?m starting a new thread for this problem. I get an error when trying to use
more than 2 output ports on a RFNoC block. I?ve designed a CE that has 9
output ports and when starting the gnuradio flowgraph it errors out. When I
reduce the ports to 2 it works. If I increase the ports to 3 it errors out.
I then made a simple modification to the ?noc_block_split_stream? block that is
provided to have three output ports (also modified the associated XML files).
It error out as well, in the same way. This test has
Radio->DDC-SplitStream->host. Below are the messages produced by gnuradio when
starting. Can the folks at Ettus please take a look as it appears to be a bug
in UHD. I?ve attached the modified ?noc_block_split_stream.v? file so you can
easily reproduce the error.
Thanks
Doug
Generating: '/home/dm/Documents/doug_rfnoc/top_block.py'
Executing: /usr/bin/python2 -u /home/dm/Documents/doug_rfnoc/top_block.py
[32;1m[INFO] [UHD] [39;0mlinux; GNU C++ version 5.4.0 20160609; Boost_106300;
UHD_4.0.0.rfnoc-devel-316-g24b98579
[32;1m[INFO] [X300] [39;0mX300 initialization sequence...
[32;1m[INFO] [X300] [39;0mDetermining maximum frame size...
[32;1m[INFO] [X300] [39;0mMaximum frame size: 1472 bytes.
[32;1m[INFO] [X300] [39;0mSetup basic communication...
[32;1m[INFO] [X300] [39;0mLoading values from EEPROM...
[32;1m[INFO] [X300] [39;0mSetup RF frontend clocking...
[32;1m[INFO] [X300] [39;0mRadio 1x clock:200
[32;1m[INFO] [RFNOC] [39;0m[DMA FIFO] Running BIST for FIFO 0...
[32;1m[INFO] [RFNOC] [39;0mpass (Throughput: 1305.2MB/s)
[32;1m[INFO] [RFNOC] [39;0m[DMA FIFO] Running BIST for FIFO 1...
[32;1m[INFO] [RFNOC] [39;0mpass (Throughput: 1302.5MB/s)
[32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
[32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
[32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
[32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
[33;1m[WARNING] [RFNOC] [39;0m[0/SplitStream_0] defines 3 input buffer sizes,
but 1 input ports
[32;1m[INFO] [CORES] [39;0mPerforming timer loopback test...
[32;1m[INFO] [CORES] [39;0mTimer loopback test passed
[32;1m[INFO] [CORES] [39;0mPerforming timer loopback test...
[32;1m[INFO] [CORES] [39;0mTimer loopback test passed
DEBUG: output item size: 8
[33;1m[WARNING] [X300 RADIO] [39;0mset_rx_gain: could not apply gain for this
daughterboard.
INFO: Setting args on 0/DDC_0
(input_rate=200000000,output_rate=1000000,fullscale=1.0,freq=1000000.0)
DEBUG: output item size: 8
INFO: Setting args on 0/SplitStream_0 (gr_vlen=1)
DEBUG: output item size: 8
[32;1m[INFO] [RFNOC] [39;0mAssuming max packet size for 0/DDC_0
[32;1m[INFO] [RFNOC] [39;0mAssuming max packet size for 0/Radio_0
DEBUG: check_topology()
DEBUG: RFNoC blocks with streaming ports: 1
DEBUG: start(): ninputs == 0 noutputs == 3
DEBUG: creating rx streamer with:
gr_vlen=1,block_id=0/SplitStream_0,block_port0=0,block_port1=1,block_port=0
DEBUG: creating rx streamer with:
gr_vlen=1,block_id=0/SplitStream_0,block_port0=0,block_port1=1,block_port=1
DEBUG: creating rx streamer with:
gr_vlen=1,block_id=0/SplitStream_0,block_port0=0,block_port1=1,block_port=2
thread[thread-per-block[0]: <block uhd_rfnoc_SplitStream (3)>]: LookupError:
KeyError: [0/Radio_0] sr_write(): No such port: 2
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
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/20170531/310d07e4/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 31 May 2017 13:58:43 -0400
From: Jason Matusiak <[email protected]>
To: "Barker, Douglas W." <[email protected]>, Jonathon Pendlum
<[email protected]>
Cc: "Yim, Kaun J." <[email protected]>, "[email protected]"
<[email protected]>, "Brassard, Sean M."
<[email protected]>
Subject: Re: [USRP-users] Error with multiple block output ports
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
I'll be interested in the fallout from all of this as well!
Thanks!
On 05/31/2017 01:52 PM, Barker, Douglas W. via USRP-users wrote:
>
> Hi Jonathon,
>
> I corrected the mistake in ?noc_block_split_stream.v?.
>
> In the ?uhd_rfnoc_split_stream.xml? file I changed ?channels=(0,1)? to
> ?channels=(0,1,2)? and it produces the same error as before. I also
> tried many combinations of ?channels=xxx? and it either error?s out on
> a python interpreter error or the same error as before. Is there a
> way to specify 3 channels that I?m not aware of?
>
> Thanks
>
> Doug
>
> *From:*Jonathon Pendlum [mailto:[email protected]]
> *Sent:* Monday, May 29, 2017 2:16 AM
> *To:* Barker, Douglas W.
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] Error with multiple block output ports
>
> Try fixing these issues, especially the first one, and see if that helps:
>
> - In uhd_rfnoc_split_stream.xml, the RX stream args defines 2 channels
> instead of 3.
>
> - In noc_block_split_stream.v, the ACTIVE_MASK on split_stream_fifo is
> set to have only two active outputs.
>
> On Fri, May 26, 2017 at 8:03 AM, Barker, Douglas W.
> <[email protected] <mailto:[email protected]>> wrote:
>
> Jonathon,
>
> I?ve attached the XML files that I was using.
>
> Thanks!
>
> Doug
>
> *From:*Jonathon Pendlum [mailto:[email protected]
> <mailto:[email protected]>]
> *Sent:* Thursday, May 25, 2017 3:46 PM
> *To:* Barker, Douglas W.
> *Cc:* [email protected] <mailto:[email protected]>
> *Subject:* Re: [USRP-users] Error with multiple block output ports
>
> Hi Doug,
>
> Can you share your Noc Script XML file?
>
> Jonathon
>
> On Fri, May 19, 2017 at 2:17 PM, Barker, Douglas W. via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hello,
>
> I?m starting a new thread for this problem. I get an error when
> trying to use more than 2 output ports on a RFNoC block. I?ve
> designed a CE that has 9 output ports and when starting the gnuradio
> flowgraph it errors out. When I reduce the ports to 2 it works. If I
> increase the ports to 3 it errors out.
>
> I then made a simple modification to the ?noc_block_split_stream?
> block that is provided to have three output ports (also modified the
> associated XML files). It error out as well, in the same way. This
> test has Radio->DDC-SplitStream->host. Below are the messages
> produced by gnuradio when starting. Can the folks at Ettus please
> take a look as it appears to be a bug in UHD. I?ve attached the
> modified ?noc_block_split_stream.v? file so you can easily reproduce
> the error.
>
> Thanks
>
> Doug
>
> Generating: '/home/dm/Documents/doug_rfnoc/top_block.py'
>
> Executing: /usr/bin/python2 -u /home/dm/Documents/doug_rfnoc/top_block.py
>
> [32;1m[INFO] [UHD] [39;0mlinux; GNU C++ version 5.4.0 20160609;
> Boost_106300; UHD_4.0.0.rfnoc-devel-316-g24b98579
>
> [32;1m[INFO] [X300] [39;0mX300 initialization sequence...
>
> [32;1m[INFO] [X300] [39;0mDetermining maximum frame size...
>
> [32;1m[INFO] [X300] [39;0mMaximum frame size: 1472 bytes.
>
> [32;1m[INFO] [X300] [39;0mSetup basic communication...
>
> [32;1m[INFO] [X300] [39;0mLoading values from EEPROM...
>
> [32;1m[INFO] [X300] [39;0mSetup RF frontend clocking...
>
> [32;1m[INFO] [X300] [39;0mRadio 1x clock:200
>
> [32;1m[INFO] [RFNOC] [39;0m[DMA FIFO] Running BIST for FIFO 0...
>
> [32;1m[INFO] [RFNOC] [39;0mpass (Throughput: 1305.2MB/s)
>
> [32;1m[INFO] [RFNOC] [39;0m[DMA FIFO] Running BIST for FIFO 1...
>
> [32;1m[INFO] [RFNOC] [39;0mpass (Throughput: 1302.5MB/s)
>
> [32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
>
> [32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
>
> [32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
>
> [32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
>
> [33;1m[WARNING] [RFNOC] [39;0m[0/SplitStream_0] defines 3 input buffer
> sizes, but 1 input ports
>
> [32;1m[INFO] [CORES] [39;0mPerforming timer loopback test...
>
> [32;1m[INFO] [CORES] [39;0mTimer loopback test passed
>
> [32;1m[INFO] [CORES] [39;0mPerforming timer loopback test...
>
> [32;1m[INFO] [CORES] [39;0mTimer loopback test passed
>
> DEBUG: output item size: 8
>
> [33;1m[WARNING] [X300 RADIO] [39;0mset_rx_gain: could not apply gain
> for this daughterboard.
>
> INFO: Setting args on 0/DDC_0
> (input_rate=200000000,output_rate=1000000,fullscale=1.0,freq=1000000.0)
>
> DEBUG: output item size: 8
>
> INFO: Setting args on 0/SplitStream_0 (gr_vlen=1)
>
> DEBUG: output item size: 8
>
> [32;1m[INFO] [RFNOC] [39;0mAssuming max packet size for 0/DDC_0
>
> [32;1m[INFO] [RFNOC] [39;0mAssuming max packet size for 0/Radio_0
>
> DEBUG: check_topology()
>
> DEBUG: RFNoC blocks with streaming ports: 1
>
> DEBUG: start(): ninputs == 0 noutputs == 3
>
> DEBUG: creating rx streamer with:
> gr_vlen=1,block_id=0/SplitStream_0,block_port0=0,block_port1=1,block_port=0
>
> DEBUG: creating rx streamer with:
> gr_vlen=1,block_id=0/SplitStream_0,block_port0=0,block_port1=1,block_port=1
>
> DEBUG: creating rx streamer with:
> gr_vlen=1,block_id=0/SplitStream_0,block_port0=0,block_port1=1,block_port=2
>
> thread[thread-per-block[0]: <block uhd_rfnoc_SplitStream (3)>]:
> LookupError: KeyError: [0/Radio_0] sr_write(): No such port: 2
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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/20170531/1603a662/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 31 May 2017 15:22:32 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] why will my direct copy of DDC RFNoC block not
work????
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Trying to debug something, I made a direct copy of the DDC block code to
my OOT RFNoC block with the only changes being changing the names
internal from ddc to ddc2, and changing the NOC ID from
64'hDDC0_0000_0000_0000 to 64'h0000_0000_0000_246B.
I made a bitfile with my block and the DDC block. When I use the DDC
block with a in/out of samp_rate and a CORDIC freq of 0, I get data
passing through fine. If I replace it with my block, I get no data out
(zeroes come out).
Here are the diffs of the various files:
from ~/rfnoc/src/uhd-fpga/usrp3/lib/rfnoc:
diff ddc.v ~/rfnoc-multiaperture/rfnoc/fpga-src/freqShift.v:
7c7
< module ddc #(
---
> module ddc2 #(
528c528
< endmodule // ddc_chain
---
> endmodule // ddc2_chain
from ~/rfnoc/src/uhd-fpga/usrp3/lib/rfnoc:
diff ./noc_block_ddc.v
~/rfnoc-multiaperture/rfnoc/fpga-src/noc_block_freqShift.v
5,6c5,6
< module noc_block_ddc #(
< parameter NOC_ID = 64'hDDC0_0000_0000_0000,
---
> module noc_block_ddc2 #(
> parameter NOC_ID = 64'h0000_0000_0000_246B,
232c232
< ddc #(
---
> ddc2 #(
238c238
< ddc (
---
> ddc2 (
from ~/rfnoc/share/gnuradio/grc/blocks:
diff multiaperture_freqShift.xml uhd_rfnoc_ddc.xml
3,4c3,4
< <name>RFNoC: DDC2</name>
< <key>uhd_rfnoc_streamer_ddc2</key>
---
> <name>RFNoC: DDC</name>
> <key>uhd_rfnoc_streamer_ddc</key>
20c20
< "DDC2", $block_index, $device_index,
---
> "DDC", $block_index, $device_index,
97c97
< <value>noc_block_ddc2</value>
---
> <value>noc_block_ddc</value>
from ~/rfnoc/share/uhd/rfnoc/blocks
diff freqShift.xml ddc.xml
3,5c3,5
< <name>Rx DSP (DDC2/CORDIC)</name>
< <blockname>DDC2</blockname>
< <key>DDC2</key>
---
> <name>Rx DSP (DDC/CORDIC)</name>
> <blockname>DDC</blockname>
> <key>DDC</key>
8c8
< <id revision="0">000000000000246B</id>
---
> <id revision="0">DDC0000000000000</id>
So what am I missing? How can it build fine, run, but be putting out zeros?
------------------------------
Message: 8
Date: Thu, 1 Jun 2017 09:54:45 +0800 (CST)
From: "Lihua Ren" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Fw:Re:Re: x310 FPGA code
Message-ID: <[email protected]>
Content-Type: text/plain; charset="gbk"
-------- Forwarding messages --------
From: "Lihua Ren" <[email protected]>
Date: 2017-06-01 09:31:21
To: "Jonathon Pendlum" <[email protected]>
Subject: Re:Re: [USRP-users] x310 FPGA code
hi,Jonathon
Does x310 support secondary development, and the underlying FPGA code master
clock can be generated randomly.I understand it right? for example,
noc_block_fft ,Its processing clock is 200MHZ, which is fixed or can be
generated arbitrarily,etc.
I hope to receive a reply as soon as possible.Thanks.
At 2017-05-19 02:03:19, "Jonathon Pendlum" <[email protected]> wrote:
HI Lihua,
Generating a 114.688 MHz clock is going to be very difficult. For instance, the
closest you'll achieve with a MMCM using bus_clk is 115.385 MHz. Can you
explain exactly why you need a 114.688 MHz clock and what you are trying to
achieve? That way, we might be able to come up with an easier approach.
Jonathon
On Tue, May 16, 2017 at 9:02 PM, Lihua Ren via USRP-users
<[email protected]> wrote:
hi?all
I met the clock problem, hope to get your help.for instance ?in
noc_block_xx.v?"ce_clk" signal through the DCM(digital clock manager) ip core
output 114.688MHz, but there are timing error.
114.688 MHz is determined by the baseband processing algorithm in my RFnoc
block,and 114.688 MHz is main clock in my FPGA code.( 114.688 MHz is not a
sampling rate)
Importantly?in X310 FPGA code ?all the modules' the main clock is 200MHz, but
my block need is 114.688MHz, which can be achieved?
_______________________________________________
USRP-users mailing list
[email protected]
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/20170601/d0b9c8b2/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 1 Jun 2017 14:01:03 +0800 (CST)
From: "Lihua Ren" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] x310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="gbk"
hi ,all
My purpose is to achieve it?The received data rate is 1.6384MHz, and the
processing clock of the demodulation algorithm is 114.688Mhz.
The demodulation code is all for the Verilog language . Can this be
implemented at USRP x310? The most important thing is to ensure that the timing
of the case, 114.688Mhz how to generate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170601/f6363422/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 1 Jun 2017 14:38:35 +0200
From: Vladica Sark <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Combining N210 and X310 in single multi_usrp
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
I am trying to combine 2x N210 and 1x X310 in a single multi_usrp.
Nevetheless, I get the following error.
When I try only the 2x N210 it works ok. Also for the single X310.
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_003.010.001.HEAD-0-gc705922a
Creating the usrp device with:
addr0=192.168.10.2,addr1=192.168.10.3,addr2=192.168.50.2...
UHD Error:
Device discovery error: ValueError: Could not resolve device hint
"addr=192.168.50.2" to a single device.
UHD Error:
Device discovery error: ValueError: Could not resolve device hint
"addr=192.168.10.2" to a single device.Could not resolve device hint
"addr=192.168.10.3" to a single device.
Error: LookupError: KeyError: No devices found for ----->
Device Address:
addr0: 192.168.10.2
addr1: 192.168.10.3
addr2: 192.168.50.2
BR,
Vladica
------------------------------
Message: 11
Date: Thu, 1 Jun 2017 14:50:05 +0200
From: Nicolas Cuervo <[email protected]>
To: Vladica Sark <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Combining N210 and X310 in single multi_usrp
Message-ID:
<CAOuPCvjNerV=mj5z_yv-ucllogyh1yktu+857anz9o6bth2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Vladica,
Quoting the manual [1]:
"Currently, the following devices support this capability:
USRP2 / N2x0 Series
X3x0 Series
*Note that only USRPs of the same type can be combined."*
This would explain what you are getting.
Regards,
- Nicolas
[1] https://files.ettus.com/manual/page_multiple.html
On Thu, Jun 1, 2017 at 2:38 PM, Vladica Sark via USRP-users <
[email protected]> wrote:
> Hi,
>
> I am trying to combine 2x N210 and 1x X310 in a single multi_usrp.
> Nevetheless, I get the following error.
>
> When I try only the 2x N210 it works ok. Also for the single X310.
>
>
> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_003.010.001.HEAD-0-gc705922a
>
>
> Creating the usrp device with: addr0=192.168.10.2,addr1=192.1
> 68.10.3,addr2=192.168.50.2...
>
> UHD Error:
> Device discovery error: ValueError: Could not resolve device hint
> "addr=192.168.50.2" to a single device.
>
> UHD Error:
> Device discovery error: ValueError: Could not resolve device hint
> "addr=192.168.10.2" to a single device.Could not resolve device hint
> "addr=192.168.10.3" to a single device.
> Error: LookupError: KeyError: No devices found for ----->
> Device Address:
> addr0: 192.168.10.2
> addr1: 192.168.10.3
> addr2: 192.168.50.2
>
>
> BR,
> Vladica
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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/20170601/c566d924/attachment-0001.html>
------------------------------
Message: 12
Date: Thu, 1 Jun 2017 16:35:26 +0300
From: ?????? ???? <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Gnuradio wideband processing speed
Message-ID:
<cabh6qsqa4dcmd8afnw6kaag7prjwr01h1t4t+mdfbqhfohb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi, thank you for your answer and links, this helped me to better
understand the insides of the gnuradio.
I got some performance gain with the setting up "performance" instead of
"energy-saving" in "indicator-cpufreq".
I attached a flow-graph with a demonstration of what is happening now. Can
I optimize all this? The first thing that comes to mind: consistently split
into channels, ie first 40e6 per 4 channels of 10e6, then each of them
divided by 4 through 2500e3, etc., until I "focus" on the desired channels. As
a result, the total volume of data for processing is reduced. Rave?)
2017-05-31 1:25 GMT+03:00 Marcus M?ller via USRP-users <
[email protected]>:
> Hi Anik,
>
> **Never** use a throttle block inside a hardware rate-limited flow graph.
> You incur the two-clock problem [1], which is why I added the explicit
> warning to GRC not to combine throttle and hardware. Throttle is a tool for
> simulation/offline analysis only.
>
> Your PC is the bottleneck if the USRP Source overflows, *not* GNU Radio
> or the USRP Source ? it does exactly the same what you do in your direct
> interface: It gets samples from UHD and directly writes them into a buffer
> in RAM [2]. You can resize that buffer using the `max_output_buffer` option
> in the advanced options of your USRP Source blcok.
>
> You didn't include a flow graph, so it's hard to guess, but:
>
> You don't want the polyphase arbitrary resampler for a resampling ration
> of > 10. Use a rational resampler, or simply a decimating FIR.
>
> Best regards,
>
> Marcus
> [1] https://wiki.gnuradio.org/index.php/FAQ#When_do_I_use_a_
> throttle_block.3F
> [2] https://www.gnuradio.org/blog/buffers/
>
> On 30.05.2017 17:15, ?????? ???? via USRP-users wrote:
>
> Ahh, sorry, forgot about throttle block. It reduces the number of
> overflows, but does not get rid of them.
> As additional info:
> i used samples_per_buffer = 10000,
> wire_format = sc12,
> in /etc/security/limits.conf i added this line: @usrp - rtprio 99
>
> 2017-05-30 17:54 GMT+03:00 ?????? ???? <[email protected]>:
>
>> Hi,
>>
>> My goal is to cut out several channels (10-30, 100e3 each) from a wide
>> band with a width of 40e6 and write them into files at real-time / or
>> pass they immediately into another flowgraph.
>> The gnuradio's USRPSurce already at a sample in ~10e6 gave out buffer
>> overflow ("OOOOO..."), therefore its use has been immediately rejected. Next,
>> I wrote the code that interacts directly with uhd and writes the results
>> directly into the RAM (tmpfs) - I got rid of the overflow, but now faced
>> the task of how to transfer data to gnuradio for further processing. Now
>> I'm using FIFO and, on the side of the gnuradio i have an ordinary "file
>> source" for reading from fifo. As a result, I again get overflows - gnuradio
>> simply can not cope with the processing of so much data. Some cores are
>> completely overloaded, realtime scheduling in flowgraph is turned ON.
>> I get overflow even on this scheme: file_source->controlled_rotato
>> r->polyphase_arbitrary_resampler->fosphor_sink
>> The only one flow-graph in which I managed to avoid overflows:
>> file_source->null_sink =)
>>
>> Probably the main issue is my sincere surprise that the 40-th core
>> processor can not cope with such a task.
>>
>> 1 Is there a way to "optimize" the gnuradio?)
>> 2 Or does it make sense to write my own "implementation" of the all
>> functionality I need from the gnuradio for optimization purposes?
>> 3 Is it rare to work with 40e6 or more?
>>
>> Thank you in advance,
>>
>> Anik
>>
>
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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/20170601/0518fde7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sample.grc
Type: application/octet-stream
Size: 91887 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170601/0518fde7/attachment-0001.grc>
------------------------------
Message: 13
Date: Thu, 1 Jun 2017 12:25:00 +0000
From: Rom?n Rodr?guez P?rez <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] USB 3.0 connection problems (USRP 205mini +
ODROID XU4)
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
We are having connectivity problems through USB 3.0 with an USRP 205 mini. We
have successfully tested it in a laptop, and it is our intention to control the
USRP with a Raspberry-like mini computer. We have chosen ODROID XU4 because it
has USB3.0 ports available, and runs Ubuntu 16.04.
The problem is that uhd_find_devices command does not find the USRP when
connected to an USB3.0 port. It does find it when connected to a USB2.0 port
and works correctly (but obviously with limited velocity).
I found out in ODROID forums that many XU4 devices came with an excess of flux
in the USB 3.0 signal pads
(https://forum.odroid.com/viewtopic.php?f=95&t=15302) but nothing changed after
cleaning with alcohol.
When I run ldusb and ldusb -t commands, I get the following output:
roman@odroid:~$ lsusb
Bus 006 Device 002: ID 0bda:8153 Realtek Semiconductor Corp.
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
roman@odroid:~$ lsusb -t
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M
roman@odroid:~$ uhd_find_devices
linux; GNU C++ version 5.3.1 20151219; Boost_105800; UHD_003.009.002-0-unknown
No UHD Devices Found
On the other hand, I found this stackoverflow thread where Marcus M?ller
answered
(https://stackoverflow.com/questions/33304828/when-trying-to-use-my-usrp-in-gnu-radio-i-get-a-no-devices-found-for),
which states that "Some USB3 host controllers don't behave
standards-conforming, and connectivity cannot be achieved. If your USRP is
detected when plugged into a USB2 port (anyone that isn't blue, usually), you
should be fine."
I also found this thread from this very same mailing list
(http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-June/014598.html)
which states that "there are USB-3.0 controllers that simply won't work with
any FX3-based device, like the B210". ODROID user manual suggests that the USB
3.0 controller is a Genesys GL3521 , which I don't know it it is compatible
with USRP 205mini.
Finally, following the instructions of the USRP manual
(http://files.ettus.com/manual/page_transport.html#transport_usb) , I looked
for uhd-usrp.rules file in /etc/udev/rules.d/, but did not find it. I tried
copying the one at my Ubuntu laptop were I tested the USRP, which contains the
following information:
#USRP1
SUBSYSTEMS=="usb", ATTRS{idVendor}=="fffe", ATTRS{idProduct}=="0002",
MODE:="0666"
#B100
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0002",
MODE:="0666"
#B200
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0020",
MODE:="0666"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0021",
MODE:="0666"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0022",
MODE:="0666"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="3923", ATTRS{idProduct}=="7813",
MODE:="0666"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="3923", ATTRS{idProduct}=="7814",
MODE:="0666"
Nevermind, it did not work either.
Any suggestion of how to proceed?
Best regards
P Please consider the environment before printing this e-mail.
______________________
This message including any attachments may contain confidential
information, according to our Information Security Management System,
and intended solely for a specific individual to whom they are addressed.
Any unauthorised copy, disclosure or distribution of this message
is strictly forbidden. If you have received this transmission in error,
please notify the sender immediately and delete it.
______________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
puede contener informacion clasificada por su emisor como confidencial
en el marco de su Sistema de Gestion de Seguridad de la
Informacion siendo para uso exclusivo del destinatario, quedando
prohibida su divulgacion copia o distribucion a terceros sin la
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje
erroneamente, se ruega lo notifique al remitente y proceda a su borrado.
Gracias por su colaboracion.
______________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170601/2ac3c0c1/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 82, Issue 1
*****************************************
