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: Data formatting questions for gnuradio complex to Q16 in
RFNOC (Martin Braun)
2. Re: How do timed commands work? (Martin Braun)
3. Question Concerning RFNOC block reuse (Walter Maguire)
4. Help with porting an old out-of-tree block (Elvis Angelaccio)
5. Re: Help with porting an old out-of-tree block (Elvis Angelaccio)
6. Re: Help with porting an old out-of-tree block (Elvis Angelaccio)
7. Re: How do timed commands work? (Dave NotTelling)
8. Re: UBX Tx-to-Rx interference, Performance and Power-Save
modes (Michael West)
9. Re: Question Concerning RFNOC block reuse (Martin Braun)
10. Re: Question Concerning RFNOC block reuse (Dave NotTelling)
11. Re: Question Concerning RFNOC block reuse (Marcus M?ller)
12. Re: Question Concerning RFNOC block reuse (Dave NotTelling)
13. Re: Question Concerning RFNOC block reuse ([email protected])
14. Re: Multiple B210s firmware update issue (Joshua Sendall)
15. Re: Multiple B210s firmware update issue (Derek Kozel)
16. Re: Separate thread for each streaming channel (Rob Kossler)
17. Re: Separate thread for each streaming channel (Michael West)
18. Clock Spur (John Shields)
19. Re: Clock Spur (Marcus D. Leech)
20. Re: Clock Spur (John Shields)
21. Re: Clock Spur (Marcus D. Leech)
22. Re: How do timed commands work? (Marcus M?ller)
23. TRANSMITTED POWER OF USRP B200mini (mohamed hamid)
24. Re: TRANSMITTED POWER OF USRP B200mini (Marcus M?ller)
25. Re: TRANSMITTED POWER OF USRP B200mini (Marcus D. Leech)
26. Re: How do timed commands work? (Dave NotTelling)
27. Re: Burst Tx and Underrun ([email protected])
28. Re: Decaying RX energy & oscillations on N210+RFX2450 Re:
Frequency synchronization problem (Marc Bauduin)
29. b205 mini and gnuradio companion (rv pellarin)
----------------------------------------------------------------------
Message: 1
Date: Thu, 19 May 2016 09:19:53 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] Data formatting questions for gnuradio
complex to Q16 in RFNOC
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
The noc-shell operates on 64-bit lines, the AXI wrapper on 32-bit lines.
If your data type is sc16, m_axis_data_tdata will have 1 sample per
clock cycle.
However, if you're using axi_wrapper, you can really ignore anything on
the other side of it. Basically, don't worry about the noc-shell data
format.
M
On 05/19/2016 01:42 AM, Swanson, Craig wrote:
> Guys,
>
> Sorry for not seeing Martin's response below on the mailing list until
> now. His explanation really helps.
>
>
> I think it is my confusion over how the axi_wrapper.v works when I run
> it in Modelsim.
>
>
> For every 64 bit data value sent to i_tdata, I see m_axis_data_tdata
> toggling twice.
>
> input [63:0] i_tdata
>
> output [31:0] m_axis_data_tdata
>
>
> How is i_tdata related to m_axis_data_tdata? I am assuming I am sending
> it a single complex value i and q, but what is m_axis_data_tdata sending
> out on the two clock edges? My guess is that they are i and q. If so,
> does it simply clock the same values out twice? That is not what I am
> seeing. I wish I could send you a snapshot waveform which would quickly
> explain my confusion.
>
>
> Craig
>
>
>
> Craig,
>
> when we send integer data to the FPGA (sc16 format), the on-the-wire
> format (in *little endian*) is 16 bits Q, 16 bits I. This is
> unintuitive, and goes back to VITA-49, but the important thing is *you
> don't need to care about it*. After the conversion, you'll either have a
> valid std::complex<int16_t> (if your software uses sc16) or a valid
> std::complex<float> (if your software uses fc32). (Note that the C++
> standard defines std::complex<> such that it looks the same in memory as
> an array, with index 0 being I, index 1 being Q).
>
> If you want to send *float* data *to the FPGA*, I recommend sending
> 32-bits I, then 32-bits Q. Remember not only your FPGA will be more
> heavily utilized, but also the I/Os will get heavier load.
>
> In your Verilog, the output of the 32-bit output bus of AXI wrapper is
> 16-bit I, 16-bit Q.
>
> Cheers,
> Martin?
>
>
> *Craig F. Swanson*
> */Research Engineer II
> /*
> */Information and Communications Laboratory/*
> */Communications, Systems, and Spectrum Division/*
> /Georgia Tech Research Institute/
> /Room 560
> 250 14th St NW
> /
> /Atlanta, GA 30318/
> /Cell: 770.298.9156/
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
------------------------------
Message: 2
Date: Thu, 19 May 2016 09:26:25 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] How do timed commands work?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 05/18/2016 07:15 PM, Marcus D. Leech via USRP-users wrote:
> On 05/18/2016 10:07 PM, Dave NotTelling via USRP-users wrote:
>> I've been poking around the UHD host library trying to figure out how
>> the timed commands actually work. I see that the tree is getting
>> updated, but I can't seem to figure out what happens after that. Is
>> there some async thread that picks up values from the tree? At what
>> point do the commands actually get sent to the radio? Is there a
>> buffer on the radio for storing up to X timed commands?
> There's a (not very deep) queue in the radio that is handled by the
> FPGA. The tree architecture allows for "publishers" and "subscribers",
> so the "top half" publishes updates to the tree, and underlying
> device-specific code "subscribes" to updates to the tree. I believe this
> is a standard boost::property_tree thingy.
Actually, the uhd::property_tree is its own thing, although they have
some similarities.
> So, the timed commands are picked from the queue in-order, and the FPGA
> uses the device time to process commands.
I think one thing that easily confuses people is the way the command
time and the command interact. The way it works is: You set a command
time (in software) and that value is cached somewhere. After that, *any*
command that is sent out to the radio control on the FPGA will have this
time stamp, until you change or reset the command time.
The next tricky part is which commands are sent to the radio control,
and which commands are sent elsewhere. As a rule of thumb, anything that
controls anything radio-related goes there, with the exception of the
AD9361 control commands.
As for the PMT-related page, you may have meant this:
http://gnuradio.org/doc/doxygen/page_uhd.html
Cheers,
Martin
>
> Off the top of my head:
>
> tuning
> gain setting
> stream start/stop
> ...probably others...
>
> The whole "timed commands" thing was originally invented to allow
> time-synchronized setting of tuning parameters for daughtercards that
> have a phase-resynch feature in them (SBX, WBX, UBX, CBX), said
> feature only works properly if all synthesizers (all daughtercards) tune
> their VFOs at precisely the same time, because the phase-reset pulse
> has to happen at precisely the same time for all synthesizers.
>
> But, once you have the goop in-place on the FPGA, you might as well
> generalize for other hardware-setting commands.
>
> B2xx doesn't support timed commands, but N2xx and X3xx do.
>
>
>>
>> Also, what things can be changed via the timed command interface? I
>> remember seeing a webpage that listed all of them, but I cannot seem
>> to find it anymore. I think it was a page that listed information
>> about the PMT interface for GNU Radio.
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [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
>
------------------------------
Message: 3
Date: Wed, 18 May 2016 17:44:00 +1000
From: Walter Maguire <[email protected]>
To: [email protected]
Subject: [USRP-users] Question Concerning RFNOC block reuse
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi all,
Just a basic question concerning the RFNOC system. If a RFNOC E310 or
other device has been built with a single CE function, say a FFT for
example, can that FFT be used multiple times in the GNU radio companion
or does each RFNOC block require a specific dedicated CE. I suppose in
theory provided there was enough time a block could send data to itself.
For example if you look at the attached png you will see that it allows
me to specify the FFT RFNOC block twice. Note it fails when I try to
run it ie give this error RuntimeError: Cannot find a block for ID:
FFT_1. Is this because there is only one FFT CE resource in the FPGA?
How are the bandwidth / resource requirements checked in the RFNOC system?
Regards
Walter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rfnoc_fft.grc.png
Type: image/png
Size: 106106 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/b85f9218/attachment-0001.png>
------------------------------
Message: 4
Date: Thu, 19 May 2016 13:50:15 +0200
From: Elvis Angelaccio <[email protected]>
To: [email protected]
Subject: [USRP-users] Help with porting an old out-of-tree block
Message-ID:
<caln1cnujy5hb-tuvyqpdwevchwm7z2gdxuznfr2ymtsodzt...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi all,
I've been working on porting an old gnuradio out-of-tree block [1] to
latest upstream gnuradio. The port is available in [2]. The block
implements a reader for RFID tags on top of an USRP v1.
The C++ code was quite easy to port, but I'm stuck with the Python
application I'm interested in [3].
In particular, it seems that the connect()s are broken and I cannot
build the flowgraph, resulting in a RuntimeError when starting the
app:
RuntimeError: gr uhd usrp sink(16): insufficient connected input ports
(2 needed, 1 connected)
Relevant code snippet (currently commented):
https://github.com/aelog/QuarkNet/blob/port/gr-usrp_reader_gen2/apps/WISP_reader.py#L165
How should I debug this issue? Is there an easy way to check what
every block I'm using expects to be connected with?
Best regards,
Elvis
[1]: https://github.com/pengyuzhang/QuarkNet/tree/master/usrp_reader_gen2
[2]: https://github.com/aelog/QuarkNet/tree/port/gr-usrp_reader_gen2
[3]:
https://github.com/pengyuzhang/QuarkNet/blob/master/usrp_reader_gen2/apps/WISP_reader.py
------------------------------
Message: 5
Date: Thu, 19 May 2016 14:43:15 +0200
From: Elvis Angelaccio <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Help with porting an old out-of-tree block
Message-ID:
<caln1cnsp1ebzn5zsz3qavgzm52nzbfu76d4988y2htqebm6...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
2016-05-19 13:50 GMT+02:00 Elvis Angelaccio <[email protected]>:
> Hi all,
> I've been working on porting an old gnuradio out-of-tree block [1] to
> latest upstream gnuradio. The port is available in [2]. The block
> implements a reader for RFID tags on top of an USRP v1.
>
> The C++ code was quite easy to port, but I'm stuck with the Python
> application I'm interested in [3].
>
> In particular, it seems that the connect()s are broken and I cannot
> build the flowgraph, resulting in a RuntimeError when starting the
> app:
>
> RuntimeError: gr uhd usrp sink(16): insufficient connected input ports
> (2 needed, 1 connected)
>
> Relevant code snippet (currently commented):
> https://github.com/aelog/QuarkNet/blob/port/gr-usrp_reader_gen2/apps/WISP_reader.py#L165
>
> How should I debug this issue? Is there an easy way to check what
> every block I'm using expects to be connected with?
Follow up: turns out the issue was the `channel` argument of uhd.stream_args.
I was using channels=range(2), while channels=range(1) makes the
RuntimeError disappear.
What's the meaning of this parameter? I have 2 daughterboards, both
attached to the TX/RX ports. Can I use both even if channels is set to
range(1) ?
>
> Best regards,
> Elvis
>
>
> [1]: https://github.com/pengyuzhang/QuarkNet/tree/master/usrp_reader_gen2
> [2]: https://github.com/aelog/QuarkNet/tree/port/gr-usrp_reader_gen2
> [3]:
> https://github.com/pengyuzhang/QuarkNet/blob/master/usrp_reader_gen2/apps/WISP_reader.py
------------------------------
Message: 6
Date: Thu, 19 May 2016 15:47:41 +0200
From: Elvis Angelaccio <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Help with porting an old out-of-tree block
Message-ID:
<caln1cnvlgpypgi5_nkkdbgnj_bvb27mzsf-hch7pwbvi7tp...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
2016-05-19 14:43 GMT+02:00 Elvis Angelaccio <[email protected]>:
> 2016-05-19 13:50 GMT+02:00 Elvis Angelaccio <[email protected]>:
>> Hi all,
>> I've been working on porting an old gnuradio out-of-tree block [1] to
>> latest upstream gnuradio. The port is available in [2]. The block
>> implements a reader for RFID tags on top of an USRP v1.
>>
>> The C++ code was quite easy to port, but I'm stuck with the Python
>> application I'm interested in [3].
>>
>> In particular, it seems that the connect()s are broken and I cannot
>> build the flowgraph, resulting in a RuntimeError when starting the
>> app:
>>
>> RuntimeError: gr uhd usrp sink(16): insufficient connected input ports
>> (2 needed, 1 connected)
>>
>> Relevant code snippet (currently commented):
>> https://github.com/aelog/QuarkNet/blob/port/gr-usrp_reader_gen2/apps/WISP_reader.py#L165
>>
>> How should I debug this issue? Is there an easy way to check what
>> every block I'm using expects to be connected with?
>
> Follow up: turns out the issue was the `channel` argument of uhd.stream_args.
> I was using channels=range(2), while channels=range(1) makes the
> RuntimeError disappear.
>
> What's the meaning of this parameter? I have 2 daughterboards, both
> attached to the TX/RX ports. Can I use both even if channels is set to
> range(1) ?
Not sure if related, but my calls uhd.tune_request(freq=915e6) always
return 0...
>
>
>
>>
>> Best regards,
>> Elvis
>>
>>
>> [1]: https://github.com/pengyuzhang/QuarkNet/tree/master/usrp_reader_gen2
>> [2]: https://github.com/aelog/QuarkNet/tree/port/gr-usrp_reader_gen2
>> [3]:
>> https://github.com/pengyuzhang/QuarkNet/blob/master/usrp_reader_gen2/apps/WISP_reader.py
------------------------------
Message: 7
Date: Thu, 19 May 2016 12:57:52 -0400
From: Dave NotTelling <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] How do timed commands work?
Message-ID:
<cak6gvuojwhralfdff1ujl6k9nxlatr9axmuz0o3+czgxhyr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Marcus and Ian! I still need to figure out exactly what commands
can be timed. Is there a group of source code files that I can look at to
get an idea of what's going on? Perhaps a file that shows the radio
accessing the tree? As mentioned earlier, I can see where the things like
sample rate are set in the tree, but I cannot figure out where/when those
values are pulled out by something else.
Martin: That was the page I was looking for!
Based on what I've read from all the responses I would expect that gain,
rate, and freq should be settable via timed commands and not be executed
until the specified time. Attached is a quick C++ program I wrote to test
the idea. What's odd to me is that the program is showing that the freq,
rate, and gain all change immediately after the timed command. I was
expecting for them to not change until the time command was supposed to
execute. Is the timed command still executing properly but the local
values for the getters comes back as the last set value?
I am aiming to be able to set the rate, freq, and gain via timed commands.
The other side of the research is how long it takes for each of the fields
to be set. Since these commands are happening on the FPGA side of things I
suppose that I cannot know exactly when the timed commands are firing and
completing right? Is the best I can hope for to benchmark how long it
takes each command to settle with just the setters in the UHD API?
Thanks!
On Thu, May 19, 2016 at 12:26 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> On 05/18/2016 07:15 PM, Marcus D. Leech via USRP-users wrote:
> > On 05/18/2016 10:07 PM, Dave NotTelling via USRP-users wrote:
> >> I've been poking around the UHD host library trying to figure out how
> >> the timed commands actually work. I see that the tree is getting
> >> updated, but I can't seem to figure out what happens after that. Is
> >> there some async thread that picks up values from the tree? At what
> >> point do the commands actually get sent to the radio? Is there a
> >> buffer on the radio for storing up to X timed commands?
> > There's a (not very deep) queue in the radio that is handled by the
> > FPGA. The tree architecture allows for "publishers" and "subscribers",
> > so the "top half" publishes updates to the tree, and underlying
> > device-specific code "subscribes" to updates to the tree. I believe this
> > is a standard boost::property_tree thingy.
>
> Actually, the uhd::property_tree is its own thing, although they have
> some similarities.
>
> > So, the timed commands are picked from the queue in-order, and the FPGA
> > uses the device time to process commands.
>
> I think one thing that easily confuses people is the way the command
> time and the command interact. The way it works is: You set a command
> time (in software) and that value is cached somewhere. After that, *any*
> command that is sent out to the radio control on the FPGA will have this
> time stamp, until you change or reset the command time.
> The next tricky part is which commands are sent to the radio control,
> and which commands are sent elsewhere. As a rule of thumb, anything that
> controls anything radio-related goes there, with the exception of the
> AD9361 control commands.
>
> As for the PMT-related page, you may have meant this:
> http://gnuradio.org/doc/doxygen/page_uhd.html
>
> Cheers,
> Martin
>
>
>
>
> >
> > Off the top of my head:
> >
> > tuning
> > gain setting
> > stream start/stop
> > ...probably others...
> >
> > The whole "timed commands" thing was originally invented to allow
> > time-synchronized setting of tuning parameters for daughtercards that
> > have a phase-resynch feature in them (SBX, WBX, UBX, CBX), said
> > feature only works properly if all synthesizers (all daughtercards) tune
> > their VFOs at precisely the same time, because the phase-reset pulse
> > has to happen at precisely the same time for all synthesizers.
> >
> > But, once you have the goop in-place on the FPGA, you might as well
> > generalize for other hardware-setting commands.
> >
> > B2xx doesn't support timed commands, but N2xx and X3xx do.
> >
> >
> >>
> >> Also, what things can be changed via the timed command interface? I
> >> remember seeing a webpage that listed all of them, but I cannot seem
> >> to find it anymore. I think it was a page that listed information
> >> about the PMT interface for GNU Radio.
> >>
> >>
> >> _______________________________________________
> >> USRP-users mailing list
> >> [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
> >
>
>
> _______________________________________________
> 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/20160519/bcdfcd29/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testing.cpp
Type: text/x-c++src
Size: 2135 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160519/bcdfcd29/attachment-0001.cpp>
------------------------------
Message: 8
Date: Thu, 19 May 2016 10:47:27 -0700
From: Michael West <[email protected]>
To: hanwen <[email protected]>
Cc: "[email protected]" <[email protected]>, Marcus
M?ller <[email protected]>
Subject: Re: [USRP-users] UBX Tx-to-Rx interference, Performance and
Power-Save modes
Message-ID:
<CAM4xKrrgBcgDZz6BrPW=SQMx_ZoHmRqd+0g4VR_xJ=WW=fo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Hanwen,
There is an issue for UBX in TDD mode of which we are aware and in the
process of fixing. In the meantime, apply the attached patch and use the
default (performance) power mode and let me know if it helps.
Regards,
Michael
On Wed, May 18, 2016 at 9:03 PM, hanwen <[email protected]> wrote:
> Dear USRP users and experts,
>
>
>
> Instructed by Michael in:
> https://www.mail-archive.com/[email protected]/msg01766.html
>
> I tried the switching between powersave and performance mode for the new
> UBX and did some further test.
>
>
>
> Basic config: 11.42MS/s, Carrier: 2.6GHz, TDMA mode with 1ms time slot and
> one device switches between Tx and Rx every 1ms; UHD and firmware are the
> fresh 3.9.4 release.
>
>
>
>
>
> *Power Save*
>
> *Performance*
>
> *Tx*
>
> The transmitted signal is very weak no matter what Tx gain is chosen
>
> The transmission is fine, but the maximum Tx power is 2~3dB lower than SBX
>
> The device is getting very hot
>
> *Rx*
>
> The noise floor not affected by Tx
>
> Noise floor rising up by c.a. 7dB by setting to higher Tx gain (>21.5),
> EVEN WHEN no transmission in Tx slot
>
>
>
> In the attachment you could see some screenshots:
>
> ? Tg_1.5~31.5.png: showing the rising Rx noise floor in the
> default Performance mode
>
> ? Cst_performance/powersave.png: showing in the Powersave mode:
> the constellation demodulated at another device is very poor due to weak
> transmit power.
>
>
>
> For both powersave and performance mode we observed unacceptable problems
> for our system, but using the older SBX-40 and SBX 120 boards we didn?t
> observe these problems.
>
>
>
> Bests, Hanwen
>
>
>
> [image: ???? 7][image: ???? 8][image: ???? 9][image: ???? 10][image: ????
> 11][image: ???? 12]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160519/b2bd5173/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg_11.5.png
Type: image/png
Size: 24955 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160519/b2bd5173/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg_21.5.png
Type: image/png
Size: 25015 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160519/b2bd5173/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cst_powersave.png
Type: image/png
Size: 31677 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160519/b2bd5173/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cst_performance.png
Type: image/png
Size: 21136 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160519/b2bd5173/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg_31.5.png
Type: image/png
Size: 25055 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160519/b2bd5173/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg_1.5.png
Type: image/png
Size: 24942 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160519/b2bd5173/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ubx_tx_noise.patch
Type: text/x-patch
Size: 684 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160519/b2bd5173/attachment-0001.patch>
------------------------------
Message: 9
Date: Thu, 19 May 2016 11:51:22 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Question Concerning RFNOC block reuse
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Walter,
good question. In any given flow graph (e.g., a GNU Radio flow graph)
you can only use the FFT once. The reason is not the FFT itself, but the
data connections: Data flowing from one block to another is flow
controlled, so we need to know where data is going, and where it's
coming from.
Now, you *could* have up to 16 inputs and outputs to that same FFT
block, and they could all use *the same FFT IP* in a time-sharing
fashion as you describe. Our block does not do that, but it could.
The total bandwidth from any block to the crossbar is given by the bus
clock (166 MHz in our current default design) and the bus width (64
bits). In terms of complex samples, that's 332-ish Msps *per block*. If
you had the FFT with 16 inputs, you'd have to share that bandwidth
between the 16 inputs.
In the example you cite, UHD is trying to find 2 separate FFT blocks,
which don't exist, hence the error.
Cheers,
Martin
On 05/18/2016 12:44 AM, Walter Maguire via USRP-users wrote:
> Hi all,
>
> Just a basic question concerning the RFNOC system. If a RFNOC E310 or
> other device has been built with a single CE function, say a FFT for
> example, can that FFT be used multiple times in the GNU radio companion
> or does each RFNOC block require a specific dedicated CE. I suppose in
> theory provided there was enough time a block could send data to itself.
>
> For example if you look at the attached png you will see that it allows
> me to specify the FFT RFNOC block twice. Note it fails when I try to
> run it ie give this error RuntimeError: Cannot find a block for ID:
> FFT_1. Is this because there is only one FFT CE resource in the FPGA?
>
> How are the bandwidth / resource requirements checked in the RFNOC system?
>
> Regards
>
>
> Walter
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 10
Date: Thu, 19 May 2016 14:58:18 -0400
From: Dave NotTelling <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Question Concerning RFNOC block reuse
Message-ID:
<cak6gvupdlcr5gdbptuov9xj5470ghttttixpnpxlj_c9syp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Martin,
Can multiple FFT blocks be added to the image? Is it as simple as a
config file or copy/paste in a Verilog file?
-Dave
On Thu, May 19, 2016 at 2:51 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> Walter,
>
> good question. In any given flow graph (e.g., a GNU Radio flow graph)
> you can only use the FFT once. The reason is not the FFT itself, but the
> data connections: Data flowing from one block to another is flow
> controlled, so we need to know where data is going, and where it's
> coming from.
>
> Now, you *could* have up to 16 inputs and outputs to that same FFT
> block, and they could all use *the same FFT IP* in a time-sharing
> fashion as you describe. Our block does not do that, but it could.
> The total bandwidth from any block to the crossbar is given by the bus
> clock (166 MHz in our current default design) and the bus width (64
> bits). In terms of complex samples, that's 332-ish Msps *per block*. If
> you had the FFT with 16 inputs, you'd have to share that bandwidth
> between the 16 inputs.
>
> In the example you cite, UHD is trying to find 2 separate FFT blocks,
> which don't exist, hence the error.
>
> Cheers,
> Martin
>
> On 05/18/2016 12:44 AM, Walter Maguire via USRP-users wrote:
> > Hi all,
> >
> > Just a basic question concerning the RFNOC system. If a RFNOC E310 or
> > other device has been built with a single CE function, say a FFT for
> > example, can that FFT be used multiple times in the GNU radio companion
> > or does each RFNOC block require a specific dedicated CE. I suppose in
> > theory provided there was enough time a block could send data to itself.
> >
> > For example if you look at the attached png you will see that it allows
> > me to specify the FFT RFNOC block twice. Note it fails when I try to
> > run it ie give this error RuntimeError: Cannot find a block for ID:
> > FFT_1. Is this because there is only one FFT CE resource in the FPGA?
> >
> > How are the bandwidth / resource requirements checked in the RFNOC
> system?
> >
> > Regards
> >
> >
> > Walter
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [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/20160519/4091ce48/attachment-0001.html>
------------------------------
Message: 11
Date: Thu, 19 May 2016 21:34:43 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Question Concerning RFNOC block reuse
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
It's as simple as editing the top-level verilog file duplicating one
module instantiation (rfnoc_ce_auto_inst_3x0.v) , and eventually
increasing one counter (NUM_CE), in fact. Haven't tried, but should
definitely work.
Best regards,
Marcus
On 19.05.2016 20:58, Dave NotTelling via USRP-users wrote:
> Martin,
>
> Can multiple FFT blocks be added to the image? Is it as simple
> as a config file or copy/paste in a Verilog file?
>
> -Dave
>
> On Thu, May 19, 2016 at 2:51 PM, Martin Braun via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Walter,
>
> good question. In any given flow graph (e.g., a GNU Radio flow graph)
> you can only use the FFT once. The reason is not the FFT itself,
> but the
> data connections: Data flowing from one block to another is flow
> controlled, so we need to know where data is going, and where it's
> coming from.
>
> Now, you *could* have up to 16 inputs and outputs to that same FFT
> block, and they could all use *the same FFT IP* in a time-sharing
> fashion as you describe. Our block does not do that, but it could.
> The total bandwidth from any block to the crossbar is given by the bus
> clock (166 MHz in our current default design) and the bus width (64
> bits). In terms of complex samples, that's 332-ish Msps *per
> block*. If
> you had the FFT with 16 inputs, you'd have to share that bandwidth
> between the 16 inputs.
>
> In the example you cite, UHD is trying to find 2 separate FFT blocks,
> which don't exist, hence the error.
>
> Cheers,
> Martin
>
> On 05/18/2016 12:44 AM, Walter Maguire via USRP-users wrote:
> > Hi all,
> >
> > Just a basic question concerning the RFNOC system. If a RFNOC
> E310 or
> > other device has been built with a single CE function, say a FFT for
> > example, can that FFT be used multiple times in the GNU radio
> companion
> > or does each RFNOC block require a specific dedicated CE. I
> suppose in
> > theory provided there was enough time a block could send data to
> itself.
> >
> > For example if you look at the attached png you will see that it
> allows
> > me to specify the FFT RFNOC block twice. Note it fails when I
> try to
> > run it ie give this error RuntimeError: Cannot find a block for ID:
> > FFT_1. Is this because there is only one FFT CE resource in the
> FPGA?
> >
> > How are the bandwidth / resource requirements checked in the
> RFNOC system?
> >
> > Regards
> >
> >
> > Walter
> >
> >
> > _______________________________________________
> > 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] <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/20160519/f57f1060/attachment-0001.html>
------------------------------
Message: 12
Date: Thu, 19 May 2016 15:40:32 -0400
From: Dave NotTelling <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Question Concerning RFNOC block reuse
Message-ID:
<CAK6GVuN9pwo1xnFbtMaqxW04S8LuHPb4+pN6bcaJ=y5oz6w...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Awesome, thanks!
On Thu, May 19, 2016 at 3:34 PM, Marcus M?ller <[email protected]>
wrote:
> It's as simple as editing the top-level verilog file duplicating one
> module instantiation (rfnoc_ce_auto_inst_3x0.v) , and eventually increasing
> one counter (NUM_CE), in fact. Haven't tried, but should definitely work.
>
> Best regards,
> Marcus
>
>
> On 19.05.2016 20:58, Dave NotTelling via USRP-users wrote:
>
> Martin,
>
> Can multiple FFT blocks be added to the image? Is it as simple as a
> config file or copy/paste in a Verilog file?
>
> -Dave
>
> On Thu, May 19, 2016 at 2:51 PM, Martin Braun via USRP-users <
> <[email protected]>[email protected]> wrote:
>
>> Walter,
>>
>> good question. In any given flow graph (e.g., a GNU Radio flow graph)
>> you can only use the FFT once. The reason is not the FFT itself, but the
>> data connections: Data flowing from one block to another is flow
>> controlled, so we need to know where data is going, and where it's
>> coming from.
>>
>> Now, you *could* have up to 16 inputs and outputs to that same FFT
>> block, and they could all use *the same FFT IP* in a time-sharing
>> fashion as you describe. Our block does not do that, but it could.
>> The total bandwidth from any block to the crossbar is given by the bus
>> clock (166 MHz in our current default design) and the bus width (64
>> bits). In terms of complex samples, that's 332-ish Msps *per block*. If
>> you had the FFT with 16 inputs, you'd have to share that bandwidth
>> between the 16 inputs.
>>
>> In the example you cite, UHD is trying to find 2 separate FFT blocks,
>> which don't exist, hence the error.
>>
>> Cheers,
>> Martin
>>
>> On 05/18/2016 12:44 AM, Walter Maguire via USRP-users wrote:
>> > Hi all,
>> >
>> > Just a basic question concerning the RFNOC system. If a RFNOC E310 or
>> > other device has been built with a single CE function, say a FFT for
>> > example, can that FFT be used multiple times in the GNU radio companion
>> > or does each RFNOC block require a specific dedicated CE. I suppose in
>> > theory provided there was enough time a block could send data to itself.
>> >
>> > For example if you look at the attached png you will see that it allows
>> > me to specify the FFT RFNOC block twice. Note it fails when I try to
>> > run it ie give this error RuntimeError: Cannot find a block for ID:
>> > FFT_1. Is this because there is only one FFT CE resource in the FPGA?
>> >
>> > How are the bandwidth / resource requirements checked in the RFNOC
>> system?
>> >
>> > Regards
>> >
>> >
>> > Walter
>> >
>> >
>> > _______________________________________________
>> > USRP-users mailing list
>> > [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
>>
>
>
>
> _______________________________________________
> 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/20160519/d090574e/attachment-0001.html>
------------------------------
Message: 13
Date: Thu, 19 May 2016 15:43:36 -0400
From: [email protected]
To: Dave NotTelling <[email protected]>
Cc: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Question Concerning RFNOC block reuse
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
I actually had someome produce a custom image for me with doubled-up FFT
and others, and which dropped the modules I didn't need. Fairly
straightforward.
On 2016-05-19 15:40, Dave NotTelling via USRP-users wrote:
> Awesome, thanks!
>
> On Thu, May 19, 2016 at 3:34 PM, Marcus M?ller <[email protected]>
> wrote:
>
> It's as simple as editing the top-level verilog file duplicating one module
> instantiation (rfnoc_ce_auto_inst_3x0.v) , and eventually increasing one
> counter (NUM_CE), in fact. Haven't tried, but should definitely work.
>
> Best regards,
> Marcus
>
> On 19.05.2016 20:58, Dave NotTelling via USRP-users wrote:
> Martin,
>
> Can multiple FFT blocks be added to the image? Is it as simple as a config
> file or copy/paste in a Verilog file?
>
> -Dave
>
> On Thu, May 19, 2016 at 2:51 PM, Martin Braun via USRP-users
> <[email protected]> wrote:
> Walter,
>
> good question. In any given flow graph (e.g., a GNU Radio flow graph)
> you can only use the FFT once. The reason is not the FFT itself, but the
> data connections: Data flowing from one block to another is flow
> controlled, so we need to know where data is going, and where it's
> coming from.
>
> Now, you *could* have up to 16 inputs and outputs to that same FFT
> block, and they could all use *the same FFT IP* in a time-sharing
> fashion as you describe. Our block does not do that, but it could.
> The total bandwidth from any block to the crossbar is given by the bus
> clock (166 MHz in our current default design) and the bus width (64
> bits). In terms of complex samples, that's 332-ish Msps *per block*. If
> you had the FFT with 16 inputs, you'd have to share that bandwidth
> between the 16 inputs.
>
> In the example you cite, UHD is trying to find 2 separate FFT blocks,
> which don't exist, hence the error.
>
> Cheers,
> Martin
>
> On 05/18/2016 12:44 AM, Walter Maguire via USRP-users wrote:
>> Hi all,
>>
>> Just a basic question concerning the RFNOC system. If a RFNOC E310 or
>> other device has been built with a single CE function, say a FFT for
>> example, can that FFT be used multiple times in the GNU radio companion
>> or does each RFNOC block require a specific dedicated CE. I suppose in
>> theory provided there was enough time a block could send data to itself.
>>
>> For example if you look at the attached png you will see that it allows
>> me to specify the FFT RFNOC block twice. Note it fails when I try to
>> run it ie give this error RuntimeError: Cannot find a block for ID:
>> FFT_1. Is this because there is only one FFT CE resource in the FPGA?
>>
>> How are the bandwidth / resource requirements checked in the RFNOC system?
>>
>> Regards
>>
>>
>> Walter
>>
>>> _______________________________________________
>> USRP-users mailing list
>> [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
>
> _______________________________________________
> USRP-users mailing list
> [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
_______________________________________________
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/20160519/a15e412f/attachment-0001.html>
------------------------------
Message: 14
Date: Thu, 19 May 2016 21:55:31 +0200
From: Joshua Sendall <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Multiple B210s firmware update issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Martin,
Thanks for replying so quickly. The issue only seems to occur on Windows.
I compiled the project on a Linux system and everything worked as expected. I
have also tried a number of Windows systems from 7-10.
Kind regards,Joshua Sendall
_________________________________________________
Joshua,
which OS is this?
-- Martin
On 05/18/2016 04:25 AM, Joshua Sendall via USRP-users wrote:
> Hi Everyone,
>
> I have found an issue upon trying to use multiple
create multiple B210s.
> The issue arises when the second multi_usrp object is
created (I have to
> use 2, because 2 B210s are not supported on a single
multi_usrp object).
> After searching for the
GPSDO a libusb error is thrown (see the
> attached screenshot). The issue arose upon updating UHD
to version
> 3.9.x, but the program continues to work with previous
versions.
>
> Has anyone else had success running multiple board
configurations with
> the newer software, or have any suggestions for a
solution?
>
> Kind regards,
> Joshua Sendall
>
>
> _______________________________________________
> 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/20160519/d9af1348/attachment-0001.html>
------------------------------
Message: 15
Date: Thu, 19 May 2016 13:05:20 -0700
From: Derek Kozel <[email protected]>
To: Joshua Sendall <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Multiple B210s firmware update issue
Message-ID:
<CAA+K=tunVU0=1+yimU-JGYkif=mke2guok0bpqx3+gmsxkf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Joshua,
Thanks for letting us know what OS you're on. I'm working on a fix for this
issue and will let you know when it is ready.
Regards,
Derek
On Thu, May 19, 2016 at 12:55 PM, Joshua Sendall via USRP-users <
[email protected]> wrote:
> Hi Martin,
>
>
> Thanks for replying so quickly. The issue only seems to occur on Windows.
>
>
> I compiled the project on a Linux system and everything worked as
> expected. I have also tried a number of Windows systems from 7-10.
>
>
> Kind regards,
>
> Joshua Sendall
>
>
> _________________________________________________
>
>
> Joshua,
>
>
>
> which OS is this?
>
>
>
> -- Martin
>
>
>
> On 05/18/2016 04:25 AM, Joshua Sendall via USRP-users wrote:
>
> > Hi Everyone,
>
> >
>
> > I have found an issue upon trying to use multiple create multiple B210s.
>
> > The issue arises when the second multi_usrp object is created (I have to
>
> > use 2, because 2 B210s are not supported on a single multi_usrp object).
>
> > After searching for the GPSDO a libusb error is thrown (see the
>
> > attached screenshot). The issue arose upon updating UHD to version
>
> > 3.9.x, but the program continues to work with previous versions.
>
> >
>
> > Has anyone else had success running multiple board configurations with
>
> > the newer software, or have any suggestions for a solution?
>
> >
>
> > Kind regards,
>
> > Joshua Sendall
>
> >
>
> >
>
> > _______________________________________________
>
> > USRP-users mailing list
>
> > [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/20160519/ff952733/attachment-0001.html>
------------------------------
Message: 16
Date: Thu, 19 May 2016 16:16:53 -0400
From: Rob Kossler <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Separate thread for each streaming channel
Message-ID:
<CAB__hTQC5fj1J2m=BEDppn3AF64kq9jYRaT+O=k1syvbdy6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Marcus, Michael,
I was able to implement the channel per streamer concept successfully and
the performance is quite a bit better. I am using a relatively recent
(last week or so) version of the master head on Ubuntu 14.04 LTS.
Here are some approximate numbers obtained by visually monitoring CPU
performance via 'htop'. My CPU is i7-4770 (3.4GHz). These were measured
with my own version of rx_samples_to_file where I was streaming to RAM
files for a 5 second capture.
- Single streamer with 4 channel
- at 50 MS/s, max CPU usage around 50% and no overruns
- at 100 MS/s, several (4-5) CPU above 95% and multiple Overruns
- Four streamers with 1 channel each
- at 100 MS/s, max CPU usage around 30% and no overruns
So, although as you say the alignment issue is more complicated in the
event of bad things, the likelihood of bad things appears to be much
reduced.
Rob
On Fri, May 13, 2016 at 4:05 PM, Marcus M?ller <[email protected]>
wrote:
> Hi Rob,
>
> Michael's point was that even if bad things?happen, the streams of a
> single streamer stay aligned.
> But yes, if you
>
> 1. use exactly one multi_usrp,
> 2. spawn multiple streamers,
> 3. start them at the same time,
> 4. pay attention not to tune the frontends at different times, and
> 5. avoid any underruns/overruns
>
> Then your streams should be aligned.
>
> Best regards,
> Marcus
>
>
>
> On 13.05.2016 21:34, Rob Kossler via USRP-users wrote:
>
> Martin,
> Just to be clear. If I have the clocks for each motherboard sync-ed AND I
> use the same start time for each of my streamers AND I verify the metadata
> of the first sample coming off the stream, then shouldn't the streams be
> aligned perfectly for MIMO operation?
>
> Rob
>
> On Fri, May 13, 2016 at 2:52 PM, Michael West via USRP-users <
> <[email protected]>[email protected]> wrote:
>
>> Hi Rob,
>>
>> There can only be one streamer for a given channel, but there can be
>> multiple streamers. I have done it several times.
>>
>> The manual should state that if a channel is included in one streamer,
>> that streamer must be destroyed before another is created that uses that
>> channel. But I think that kind of wording might make some people go
>> cross-eyed. :-)
>>
>> Regards,
>> Michael
>>
>> On Fri, May 13, 2016 at 11:23 AM, Martin Braun via USRP-users <
>> [email protected]> wrote:
>>
>>> This would definitely work; one thing I would like to point out for the
>>> records is that you won't get aligned streams this way. If you're doing
>>> MIMO processing or something similar, you only want a single streamer,
>>> with N channels.
>>>
>>> Cheers,
>>> M
>>>
>>> On 05/13/2016 11:13 AM, Michael West via USRP-users wrote:
>>> > Hi Rob,
>>> >
>>> > There can be multiple rx_streamer objects, but only a single multi_usrp
>>> > object. So, you could have a main thread that creates the multi_usrp
>>> > object and passes a reference to all the slave threads for them to use
>>> > to create their respective streamers.
>>> >
>>> > Regards,
>>> > Michael
>>> >
>>> > On Fri, May 13, 2016 at 11:03 AM, Rob Kossler <[email protected]
>>> > <mailto: <[email protected]>[email protected]>> wrote:
>>> >
>>> > Michael,
>>> > I wasn't using 3.10, but instead 3.9.2. So, I went ahead and
>>> > updated to 3.10 (which I assume has the improved threading
>>> > architecture that you mentioned). Unfortunately, I still have the
>>> > same general issue: I can run 2 program instances with each
>>> instance
>>> > handling 2 channels @ 100 MS/s successfully, but if I try 1 program
>>> > instance with 4 channels @ 100 MS/s, I get overruns and other
>>> errors
>>> > and several of the CPU's show that they are pegged (using 'htop').
>>> >
>>> > I then tried to see if I could get even better performance (i.e.,
>>> > lower CPU usage) by running multiple streamers with each streamer
>>> > having only 1 channel. It wasn't til after I implemented this (and
>>> > it failed to work) that I realized that there can only be 1
>>> > rx_streamer object at a time. So, does this mean that my idea of
>>> > running a separate thread for each channel's data is impossible?
>>> > Rob
>>> >
>>> >
>>> > On Wed, May 11, 2016 at 7:33 PM, Michael West
>>> > < <[email protected]>[email protected] <mailto:
>>> [email protected]>> wrote:
>>> >
>>> > Hi Rob,
>>> >
>>> > Having multiple channels in a single streamer guarantees time
>>> > alignment of the received data across the channels, even when
>>> > there are overruns. Individual threads for each channel
>>> results
>>> > in much better performance, but can cause more work in aligning
>>> > the data later (especially if there are overruns).
>>> >
>>> > We are working on some improvements for UHD 3.10.0 that will
>>> > definitely help. Namely, we added a thread to offload the
>>> > receive side I/O for X310 over 10 GbE. This removes a
>>> > significant load from the rx_streamer::recv() call and should
>>> > make it much easier for your application to achieve 4 channels
>>> > at 100 MS/s on one PC. If you are using the head of the master
>>> > branch, that could explain the improvement.
>>> >
>>> > Regards,
>>> > Michael
>>> >
>>> > On Wed, May 11, 2016 at 3:31 PM, Rob Kossler via USRP-users
>>> > < <[email protected]>[email protected]
>>> <mailto:[email protected]>>
>>> > wrote:
>>> >
>>> > I am trying to capture samples to RAM drive on 4 channels
>>> (2
>>> > X310 w/ UBX-160) at 100 MS/s per channel. A while ago, I
>>> > determined that my CPU couldn't keep up at this rate. So,
>>> I
>>> > modified my C++ application (loosely based on
>>> > rx_samples_to_file.cpp) so that I could run a separate
>>> > instance on each of 2 PCs with each PC linked to an X310.
>>> > This involved synchronizing X310 clocks and streaming start
>>> > times, but seems to work fine.
>>> >
>>> > I recently discovered that if I ran both instances on the
>>> > same PC (with this PC connected to both X310s), I could
>>> > successfully achieve 4 channels at 100 MS/s on one PC. This
>>> > surprised me because of my previous failure using a single
>>> > program instance. The primary difference I could think of
>>> > was that when two program instances are executing they are
>>> > naturally on different threads whereas my single instance
>>> > pulls all samples from UHD on one thread.
>>> >
>>> > With this long intro, here is my question: Given that using
>>> > 2 threads to pull the data from UHD seems to work better
>>> > than 1 thread, would I be best off taking it a step further
>>> > such that I use a separate thread for each channel? This
>>> > would mean I would have a single channel assigned to each
>>> RX
>>> > streamer. Let me know any pros/cons of implementing in
>>> this
>>> > way.
>>> >
>>> > Rob
>>> >
>>> > _______________________________________________
>>> > 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
>>> >
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [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
>>
>>
>
>
> _______________________________________________
> 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/20160519/8cac2eb2/attachment-0001.html>
------------------------------
Message: 17
Date: Thu, 19 May 2016 14:15:32 -0700
From: Michael West <[email protected]>
To: Rob Kossler <[email protected]>
Cc: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Separate thread for each streaming channel
Message-ID:
<cam4xkrp+rwdpb6czgnjhkkxxayybaykrremfz9z2txn9h7x...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Rob,
Yes, we have noticed the same things. The alignment of the channels in UHD
is causing considerable CPU overhead and severely limiting throughput. We
are looking into potential solutions for that now.
Regards,
Michael
On Thu, May 19, 2016 at 1:16 PM, Rob Kossler via USRP-users <
[email protected]> wrote:
> Thanks Marcus, Michael,
>
> I was able to implement the channel per streamer concept successfully and
> the performance is quite a bit better. I am using a relatively recent
> (last week or so) version of the master head on Ubuntu 14.04 LTS.
>
> Here are some approximate numbers obtained by visually monitoring CPU
> performance via 'htop'. My CPU is i7-4770 (3.4GHz). These were measured
> with my own version of rx_samples_to_file where I was streaming to RAM
> files for a 5 second capture.
>
> - Single streamer with 4 channel
> - at 50 MS/s, max CPU usage around 50% and no overruns
> - at 100 MS/s, several (4-5) CPU above 95% and multiple Overruns
> - Four streamers with 1 channel each
> - at 100 MS/s, max CPU usage around 30% and no overruns
>
> So, although as you say the alignment issue is more complicated in the
> event of bad things, the likelihood of bad things appears to be much
> reduced.
>
> Rob
>
>
> On Fri, May 13, 2016 at 4:05 PM, Marcus M?ller <[email protected]
> > wrote:
>
>> Hi Rob,
>>
>> Michael's point was that even if bad things?happen, the streams of a
>> single streamer stay aligned.
>> But yes, if you
>>
>> 1. use exactly one multi_usrp,
>> 2. spawn multiple streamers,
>> 3. start them at the same time,
>> 4. pay attention not to tune the frontends at different times, and
>> 5. avoid any underruns/overruns
>>
>> Then your streams should be aligned.
>>
>> Best regards,
>> Marcus
>>
>>
>>
>> On 13.05.2016 21:34, Rob Kossler via USRP-users wrote:
>>
>> Martin,
>> Just to be clear. If I have the clocks for each motherboard sync-ed AND
>> I use the same start time for each of my streamers AND I verify the
>> metadata of the first sample coming off the stream, then shouldn't the
>> streams be aligned perfectly for MIMO operation?
>>
>> Rob
>>
>> On Fri, May 13, 2016 at 2:52 PM, Michael West via USRP-users <
>> <[email protected]>[email protected]> wrote:
>>
>>> Hi Rob,
>>>
>>> There can only be one streamer for a given channel, but there can be
>>> multiple streamers. I have done it several times.
>>>
>>> The manual should state that if a channel is included in one streamer,
>>> that streamer must be destroyed before another is created that uses that
>>> channel. But I think that kind of wording might make some people go
>>> cross-eyed. :-)
>>>
>>> Regards,
>>> Michael
>>>
>>> On Fri, May 13, 2016 at 11:23 AM, Martin Braun via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> This would definitely work; one thing I would like to point out for the
>>>> records is that you won't get aligned streams this way. If you're doing
>>>> MIMO processing or something similar, you only want a single streamer,
>>>> with N channels.
>>>>
>>>> Cheers,
>>>> M
>>>>
>>>> On 05/13/2016 11:13 AM, Michael West via USRP-users wrote:
>>>> > Hi Rob,
>>>> >
>>>> > There can be multiple rx_streamer objects, but only a single
>>>> multi_usrp
>>>> > object. So, you could have a main thread that creates the multi_usrp
>>>> > object and passes a reference to all the slave threads for them to use
>>>> > to create their respective streamers.
>>>> >
>>>> > Regards,
>>>> > Michael
>>>> >
>>>> > On Fri, May 13, 2016 at 11:03 AM, Rob Kossler <[email protected]
>>>> > <mailto: <[email protected]>[email protected]>> wrote:
>>>> >
>>>> > Michael,
>>>> > I wasn't using 3.10, but instead 3.9.2. So, I went ahead and
>>>> > updated to 3.10 (which I assume has the improved threading
>>>> > architecture that you mentioned). Unfortunately, I still have the
>>>> > same general issue: I can run 2 program instances with each
>>>> instance
>>>> > handling 2 channels @ 100 MS/s successfully, but if I try 1
>>>> program
>>>> > instance with 4 channels @ 100 MS/s, I get overruns and other
>>>> errors
>>>> > and several of the CPU's show that they are pegged (using 'htop').
>>>> >
>>>> > I then tried to see if I could get even better performance (i.e.,
>>>> > lower CPU usage) by running multiple streamers with each streamer
>>>> > having only 1 channel. It wasn't til after I implemented this
>>>> (and
>>>> > it failed to work) that I realized that there can only be 1
>>>> > rx_streamer object at a time. So, does this mean that my idea of
>>>> > running a separate thread for each channel's data is impossible?
>>>> > Rob
>>>> >
>>>> >
>>>> > On Wed, May 11, 2016 at 7:33 PM, Michael West
>>>> > < <[email protected]>[email protected] <mailto:
>>>> [email protected]>> wrote:
>>>> >
>>>> > Hi Rob,
>>>> >
>>>> > Having multiple channels in a single streamer guarantees time
>>>> > alignment of the received data across the channels, even when
>>>> > there are overruns. Individual threads for each channel
>>>> results
>>>> > in much better performance, but can cause more work in
>>>> aligning
>>>> > the data later (especially if there are overruns).
>>>> >
>>>> > We are working on some improvements for UHD 3.10.0 that will
>>>> > definitely help. Namely, we added a thread to offload the
>>>> > receive side I/O for X310 over 10 GbE. This removes a
>>>> > significant load from the rx_streamer::recv() call and should
>>>> > make it much easier for your application to achieve 4 channels
>>>> > at 100 MS/s on one PC. If you are using the head of the
>>>> master
>>>> > branch, that could explain the improvement.
>>>> >
>>>> > Regards,
>>>> > Michael
>>>> >
>>>> > On Wed, May 11, 2016 at 3:31 PM, Rob Kossler via USRP-users
>>>> > < <[email protected]>[email protected]
>>>> <mailto:[email protected]>>
>>>> > wrote:
>>>> >
>>>> > I am trying to capture samples to RAM drive on 4 channels
>>>> (2
>>>> > X310 w/ UBX-160) at 100 MS/s per channel. A while ago, I
>>>> > determined that my CPU couldn't keep up at this rate.
>>>> So, I
>>>> > modified my C++ application (loosely based on
>>>> > rx_samples_to_file.cpp) so that I could run a separate
>>>> > instance on each of 2 PCs with each PC linked to an X310.
>>>> > This involved synchronizing X310 clocks and streaming
>>>> start
>>>> > times, but seems to work fine.
>>>> >
>>>> > I recently discovered that if I ran both instances on the
>>>> > same PC (with this PC connected to both X310s), I could
>>>> > successfully achieve 4 channels at 100 MS/s on one PC.
>>>> This
>>>> > surprised me because of my previous failure using a single
>>>> > program instance. The primary difference I could think of
>>>> > was that when two program instances are executing they are
>>>> > naturally on different threads whereas my single instance
>>>> > pulls all samples from UHD on one thread.
>>>> >
>>>> > With this long intro, here is my question: Given that
>>>> using
>>>> > 2 threads to pull the data from UHD seems to work better
>>>> > than 1 thread, would I be best off taking it a step
>>>> further
>>>> > such that I use a separate thread for each channel? This
>>>> > would mean I would have a single channel assigned to each
>>>> RX
>>>> > streamer. Let me know any pros/cons of implementing in
>>>> this
>>>> > way.
>>>> >
>>>> > Rob
>>>> >
>>>> > _______________________________________________
>>>> > 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
>>>> >
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [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
>>>
>>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>
> _______________________________________________
> 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/20160519/1f02a7e9/attachment-0001.html>
------------------------------
Message: 18
Date: Fri, 20 May 2016 14:18:17 +1200
From: "John Shields" <[email protected]>
To: "usrp-users" <[email protected]>
Subject: [USRP-users] Clock Spur
Message-ID: <49A6EEC42DA04EB1AB59533D47146507@JohnsHPLaptop>
Content-Type: text/plain; charset="utf-8"
Hi,
I have an N200 w/GPSDO and SBX being used for receive. When I put the SBX
into a non-GPSDO box, there is no spur in the spectrum but when I put that same
PCB into the N200 with the GSPDO, I get a large spur which shows up on the
simple_ra spectrum screen.
I was given advice that normally we could add gain to low-intensity signals
and swamp the spurs ? (@ 1.42 GHz in this case) with 1.4204058GHz being the
tuned frequency.
I have attached two spectral pics one with the RAS_LNAs ( roughly 50 dB )
and one with the addition of a mini-circuits LNA with 20 dB gain (The signal
magnitude probe shows ~ 0.25 so I am not saturating the SBX as far as I can
tell). As you can see, the signal floor has been raised by the expected amount
but the spike is still roughly 15dB above that.
Since I have now narrowed down the clock spur problem to be with
GPSDO-equipped N200 only, is there any further advice on how to take care of
this spur which, as you can imagine, distorts the spectrum?
Kind Regards,
John
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160520/0a032eff/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RAS_LNAs_only.png
Type: image/png
Size: 91460 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160520/0a032eff/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RAS_LNAs+mini-cricuits_20dB.png
Type: image/png
Size: 96437 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160520/0a032eff/attachment-0003.png>
------------------------------
Message: 19
Date: Thu, 19 May 2016 23:22:20 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Clock Spur
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 05/19/2016 10:18 PM, John Shields via USRP-users wrote:
> Hi,
> I have an N200 w/GPSDO and SBX being used for receive. When I put
> the SBX into a non-GPSDO box, there is no spur in the spectrum but
> when I put that same PCB into the N200 with the GSPDO, I get a large
> spur which shows up on the simple_ra spectrum screen.
> I was given advice that normally we could add gain to
> low-intensity signals and swamp the spurs ? (@ 1.42 GHz in this case)
> with 1.4204058GHz being the tuned frequency.
> I have attached two spectral pics one with the RAS_LNAs ( roughly
> 50 dB ) and one with the addition of a mini-circuits LNA with 20 dB
> gain (The signal magnitude probe shows ~ 0.25 so I am not saturating
> the SBX as far as I can tell). As you can see, the signal floor has
> been raised by the expected amount but the spike is still roughly 15dB
> above that.
> Since I have now narrowed down the clock spur problem to be with
> GPSDO-equipped N200 only, is there any further advice on how to take
> care of this spur which, as you can imagine, distorts the spectrum?
> Kind Regards,
> John
>
SOme things to try:
A couple of clamp-on ferrites on your RX antenna cable.
Put a terminator on the TX port
Clamp-on ferrites on the ethernet cable
Clamp-on ferrites on the power cable
My suspicion is that the 10MHz harmonics are travelling along your
cable(s) out to the antenna.
I had problems with ethernet radiation when I ran ethernet cabling out
to a dish. My cure was to use fiber-optic ethernet :(
When you consider that your "signal of interest" (the continuum and H1)
emissions are the equivalent of a black-body at about 10-15K, and
the spur is only 15dB louder than that, it's still a fairly weak
signal, which is consistent with harmonic radiation getting outside of
the enclosure
and travelling along cables to your antenna.
When you're operating, as you are, right down and the sensitivity limits
of your overall system, spurs that wouldn't even be an "annoyance"
for telecom applications are more significant. The fact that it's
still 15dB out of the noise when you increase the external gain means that
it's likely getting picked up by your antenna, by common-mode
propagation via cabling.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160519/41fd0657/attachment-0001.html>
------------------------------
Message: 20
Date: Fri, 20 May 2016 16:07:26 +1200
From: "John Shields" <[email protected]>
To: "Marcus D. Leech" <[email protected]>,
<[email protected]>
Subject: Re: [USRP-users] Clock Spur
Message-ID: <8CF7D52F35A7481CA60FF27326A41279@JohnsHPLaptop>
Content-Type: text/plain; charset="windows-1252"
Thanks Marcus,
Will try your suggestions ? all make sense to me.
Slainte,
John
From: Marcus D. Leech via USRP-users
Sent: Friday, May 20, 2016 3:22 PM
To: [email protected]
Subject: Re: [USRP-users] Clock Spur
On 05/19/2016 10:18 PM, John Shields via USRP-users wrote:
Hi,
I have an N200 w/GPSDO and SBX being used for receive. When I put the SBX
into a non-GPSDO box, there is no spur in the spectrum but when I put that same
PCB into the N200 with the GSPDO, I get a large spur which shows up on the
simple_ra spectrum screen.
I was given advice that normally we could add gain to low-intensity
signals and swamp the spurs ? (@ 1.42 GHz in this case) with 1.4204058GHz
being the tuned frequency.
I have attached two spectral pics one with the RAS_LNAs ( roughly 50 dB )
and one with the addition of a mini-circuits LNA with 20 dB gain (The signal
magnitude probe shows ~ 0.25 so I am not saturating the SBX as far as I can
tell). As you can see, the signal floor has been raised by the expected amount
but the spike is still roughly 15dB above that.
Since I have now narrowed down the clock spur problem to be with
GPSDO-equipped N200 only, is there any further advice on how to take care of
this spur which, as you can imagine, distorts the spectrum?
Kind Regards,
John
SOme things to try:
A couple of clamp-on ferrites on your RX antenna cable.
Put a terminator on the TX port
Clamp-on ferrites on the ethernet cable
Clamp-on ferrites on the power cable
My suspicion is that the 10MHz harmonics are travelling along your cable(s) out
to the antenna.
I had problems with ethernet radiation when I ran ethernet cabling out to a
dish. My cure was to use fiber-optic ethernet :(
When you consider that your "signal of interest" (the continuum and H1)
emissions are the equivalent of a black-body at about 10-15K, and
the spur is only 15dB louder than that, it's still a fairly weak signal,
which is consistent with harmonic radiation getting outside of the enclosure
and travelling along cables to your antenna.
When you're operating, as you are, right down and the sensitivity limits of
your overall system, spurs that wouldn't even be an "annoyance"
for telecom applications are more significant. The fact that it's still 15dB
out of the noise when you increase the external gain means that
it's likely getting picked up by your antenna, by common-mode propagation via
cabling.
--------------------------------------------------------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160520/c1a61c2a/attachment-0001.html>
------------------------------
Message: 21
Date: Fri, 20 May 2016 00:32:32 -0400
From: "Marcus D. Leech" <[email protected]>
To: John Shields <[email protected]>, [email protected]
Subject: Re: [USRP-users] Clock Spur
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 05/20/2016 12:07 AM, John Shields wrote:
> Thanks Marcus,
> Will try your suggestions ? all make sense to me.
> Slainte,
> John
Also, if you're not using the 10Mhz reference input, put a terminator on
it as well. It's *conceivable* that there's some small coupling to that
connector from the output of the GPSDO, even though there's a jumper
block to select between them, as I recall.
> *From:* Marcus D. Leech via USRP-users
> <mailto:[email protected]>
> *Sent:* Friday, May 20, 2016 3:22 PM
> *To:* [email protected] <mailto:[email protected]>
> *Subject:* Re: [USRP-users] Clock Spur
> On 05/19/2016 10:18 PM, John Shields via USRP-users wrote:
>> Hi,
>> I have an N200 w/GPSDO and SBX being used for receive. When I put
>> the SBX into a non-GPSDO box, there is no spur in the spectrum but
>> when I put that same PCB into the N200 with the GSPDO, I get a large
>> spur which shows up on the simple_ra spectrum screen.
>> I was given advice that normally we could add gain to
>> low-intensity signals and swamp the spurs ? (@ 1.42 GHz in this
>> case) with 1.4204058GHz being the tuned frequency.
>> I have attached two spectral pics one with the RAS_LNAs ( roughly
>> 50 dB ) and one with the addition of a mini-circuits LNA with 20 dB
>> gain (The signal magnitude probe shows ~ 0.25 so I am not saturating
>> the SBX as far as I can tell). As you can see, the signal floor has
>> been raised by the expected amount but the spike is still roughly
>> 15dB above that.
>> Since I have now narrowed down the clock spur problem to be with
>> GPSDO-equipped N200 only, is there any further advice on how to take
>> care of this spur which, as you can imagine, distorts the spectrum?
>> Kind Regards,
>> John
> SOme things to try:
>
> A couple of clamp-on ferrites on your RX antenna cable.
> Put a terminator on the TX port
> Clamp-on ferrites on the ethernet cable
> Clamp-on ferrites on the power cable
>
> My suspicion is that the 10MHz harmonics are travelling along your
> cable(s) out to the antenna.
>
> I had problems with ethernet radiation when I ran ethernet cabling out
> to a dish. My cure was to use fiber-optic ethernet :(
>
> When you consider that your "signal of interest" (the continuum and
> H1) emissions are the equivalent of a black-body at about 10-15K, and
> the spur is only 15dB louder than that, it's still a fairly weak
> signal, which is consistent with harmonic radiation getting outside of
> the enclosure
> and travelling along cables to your antenna.
>
> When you're operating, as you are, right down and the sensitivity
> limits of your overall system, spurs that wouldn't even be an "annoyance"
> for telecom applications are more significant. The fact that it's
> still 15dB out of the noise when you increase the external gain means that
> it's likely getting picked up by your antenna, by common-mode
> propagation via cabling.
>
>
> ------------------------------------------------------------------------
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
> Virus-free. www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160520/ca7e8b85/attachment-0001.html>
------------------------------
Message: 22
Date: Fri, 20 May 2016 10:50:55 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] How do timed commands work?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Dave,
On 19.05.2016 18:57, Dave NotTelling via USRP-users wrote:
> Thanks Marcus and Ian! I still need to figure out exactly what
> commands can be timed.
Depends on your device. Just ask. Since I don't know which device we're
talking about, I can only repeat what Ian said:
On all later second gen (USRP N2xx) and all third gen devices (B2xx,
E3xx, X3xx) you can start/stop streaming at a specified time, you can
set the digital tuning offset (CORDIC phase increment) at a specified
time, and quite a few things more, as long as they are inherent to the
FPGA and not part of the analog hardware.
On all of these devices that have interchangeable daughterboards (N2xx,
X3xx), together with recent daughterboards (UBX,SBX,WBX,CBX, coming new
ones), you can also tune the frontend LO at a specified time, and adjust
gain etc.
> Is there a group of source code files that I can look at to get an
> idea of what's going on? Perhaps a file that shows the radio
> accessing the tree?
Really, the property tree isn't involved in timed execution, because the
property tree is happening on your computer, whereas timed command
timing happens on the USRP. I don't really think understanding the tree
will help you understand timed commands.
> As mentioned earlier, I can see where the things like sample rate
> are set in the tree, but I cannot figure out where/when those values
> are pulled out by something else.
They're mostly not pulled out; there's a subscriber that "hooks" into
the tree that gets notified when a certain property gets set.
>
> Martin: That was the page I was looking for!
>
> Based on what I've read from all the responses I would expect that
> gain, rate, and freq should be settable via timed commands and not be
> executed until the specified time.
No, or yes, or Well, see my answer above. Gain and Freq have analog
components involved, and rate changing might have analog consequences,
again, depending on the device.
> Attached is a quick C++ program I wrote to test the idea. What's odd
> to me is that the program is showing that the freq, rate, and gain all
> change immediately after the timed command. I was expecting for them
> to not change until the time command was supposed to execute. Is the
> timed command still executing properly but the local values for the
> getters comes back as the last set value?
well, misunderstanding: the get_rx_freq calls (and similar calls) don't
actually ask the USRP for its current frequency (that's pretty much
technically impossible; not all tuners have registers that you can ask
"hey, what's your current frequency", and also, the conversion between
frequency and synthesizer register settings is often far from trivial),
but just return the last value you set via set_rx_freq, whether or not
the timed command has taken effect in the device ? really, timed
commands aren't happening on your computer, but in the device. Your
computer and your device have different understandings of time (the USRP
much more being close to "real world time"), and so the computer could
never know if a point in time has passed for the device (and vice versa).
>
> I am aiming to be able to set the rate, freq, and gain via timed
> commands. The other side of the research is how long it takes for
> each of the fields to be set. Since these commands are happening on
> the FPGA side of things I suppose that I cannot know exactly when the
> timed commands are firing and completing right?
right.
> Is the best I can hope for to benchmark how long it takes each
> command to settle with just the setters in the UHD API?
No, you can't hope for that. As mentioned, the get_* calls don't usually
tell you what's going on on the device. You need to come up with a)
values of experience or b) a signal-based method of noticing change.
Since this now *really* gets device-specific, I won't elaborate further
until you tell us your device :)
Best regards,
Marcus
------------------------------
Message: 23
Date: Fri, 20 May 2016 09:22:43 +0000
From: mohamed hamid <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] TRANSMITTED POWER OF USRP B200mini
Message-ID:
<am4pr04mb15544fa31cf5a572e496b26cc3...@am4pr04mb1554.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hello,
I have a USRP b200mini. I want to perform based on this USRP B200mini. I looked
to the datasheet, it says that the RF output power is >10dBm. Does the RF
output power mean the transmitted power of this USRP is more than 10dBm? If
that so, how can I know the maximum transmitted power for the device.
Also, is there a way to measure the amount of consumption power of the USRP
B200mini when it is in idle state (running only), and power consumption of the
USRP when it transmit or receive?
Thank you in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160520/7757f487/attachment-0001.html>
------------------------------
Message: 24
Date: Fri, 20 May 2016 11:33:33 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] TRANSMITTED POWER OF USRP B200mini
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Mohamed,
it means that the output power might, for some frequency, gain, signal
and bandwidth combination, be more than 10dBm.
The only way to know how much signal you're emitting is to use a
calibrated measurement setup for your B200mini+cable+antenna at exactly
the frequency, gain, sampling rate, bandwidth and with the signal type
of interest.
>
> Also, is there a way to measure the amount of consumption power of the
> USRP B200mini when it is in idle state (running only), and power
> consumption of the USRP when it transmit or receive?
>
Yes, quite easy: Use an external DC power supply, and measure the
current the USRP draws through that.
Best regards,
Marcus
On 20.05.2016 11:22, mohamed hamid via USRP-users wrote:
>
> Hello,
>
>
>
> I have a USRP b200mini. I want to perform based on this USRP B200mini.
> I looked to the datasheet, it says that the *_RF output power is
> >10dBm. _* Does the RF output power mean the transmitted power of this
> USRP is more than 10dBm? If that so, how can I know the maximum
> transmitted power for the device.
>
>
>
> Also, is there a way to measure the amount of consumption power of the
> USRP B200mini when it is in idle state (running only), and power
> consumption of the USRP when it transmit or receive?
>
>
>
> Thank you in advance.
>
>
>
>
>
> _______________________________________________
> 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/20160520/3429ff81/attachment-0001.html>
------------------------------
Message: 25
Date: Fri, 20 May 2016 06:47:02 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] TRANSMITTED POWER OF USRP B200mini
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 05/20/2016 05:33 AM, Marcus M?ller via USRP-users wrote:
> Hi Mohamed,
>
> it means that the output power might, for some frequency, gain, signal
> and bandwidth combination, be more than 10dBm.
> The only way to know how much signal you're emitting is to use a
> calibrated measurement setup for your B200mini+cable+antenna at
> exactly the frequency, gain, sampling rate, bandwidth and with the
> signal type of interest.
>>
>> Also, is there a way to measure the amount of consumption power of
>> the USRP B200mini when it is in idle state (running only), and power
>> consumption of the USRP when it transmit or receive?
>>
> Yes, quite easy: Use an external DC power supply, and measure the
> current the USRP draws through that.
>
> Best regards,
> Marcus
There are also in-line USB power meters--can be found on eBay for a few
dollars...
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160520/8ecf8106/attachment-0001.html>
------------------------------
Message: 26
Date: Fri, 20 May 2016 10:19:42 -0400
From: Dave NotTelling <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] How do timed commands work?
Message-ID:
<cak6gvuowb2s2u6etlbtqv_unv6fdnw9gtxq7p6nqiyg1xw9...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Marcus,
Thank you for the in depth explanation!! My apologies for not listing
the devices. I am using an X310 with the UBX-160 and an N210 with the
UBX-40.
I brought up the property tree because from what I can see in the X300
source code, the property tree is used
@ uhd/host/lib/usrp/x300/x300_impl.cpp line 998 (version 3.9.4). That
shows something subscribing to samp rate changes. The actual method that
changes the freq is located at uhd/host/lib/usrp/x300/x300_io_impl.cpp line
67. What I don't see is how timed commands are treated differently than
normal commands. Honestly it doesn't really matter that I have a full
understanding of it so long as I can be promised that for the X310 and N210
with UBX daughterboards that sample rate, gain, and freq can all be changed
via timed commands.
I would like to be able to pack as many timed commands as possible as
close in time as possible. In order to do that I need to figure out how
long the various operations take (tuning, sample rate changes, and gain
settings). Is there any way to benchmark those operations to get an idea
of how much spacing I need between timed commands?
Thank you very much!!
-Dave
On Fri, May 20, 2016 at 4:50 AM, Marcus M?ller <[email protected]>
wrote:
> Hi Dave,
>
> On 19.05.2016 18:57, Dave NotTelling via USRP-users wrote:
> > Thanks Marcus and Ian! I still need to figure out exactly what
> > commands can be timed.
> Depends on your device. Just ask. Since I don't know which device we're
> talking about, I can only repeat what Ian said:
> On all later second gen (USRP N2xx) and all third gen devices (B2xx,
> E3xx, X3xx) you can start/stop streaming at a specified time, you can
> set the digital tuning offset (CORDIC phase increment) at a specified
> time, and quite a few things more, as long as they are inherent to the
> FPGA and not part of the analog hardware.
> On all of these devices that have interchangeable daughterboards (N2xx,
> X3xx), together with recent daughterboards (UBX,SBX,WBX,CBX, coming new
> ones), you can also tune the frontend LO at a specified time, and adjust
> gain etc.
>
> > Is there a group of source code files that I can look at to get an
> > idea of what's going on? Perhaps a file that shows the radio
> > accessing the tree?
> Really, the property tree isn't involved in timed execution, because the
> property tree is happening on your computer, whereas timed command
> timing happens on the USRP. I don't really think understanding the tree
> will help you understand timed commands.
> > As mentioned earlier, I can see where the things like sample rate
> > are set in the tree, but I cannot figure out where/when those values
> > are pulled out by something else.
> They're mostly not pulled out; there's a subscriber that "hooks" into
> the tree that gets notified when a certain property gets set.
> >
> > Martin: That was the page I was looking for!
> >
> > Based on what I've read from all the responses I would expect that
> > gain, rate, and freq should be settable via timed commands and not be
> > executed until the specified time.
> No, or yes, or Well, see my answer above. Gain and Freq have analog
> components involved, and rate changing might have analog consequences,
> again, depending on the device.
> > Attached is a quick C++ program I wrote to test the idea. What's odd
> > to me is that the program is showing that the freq, rate, and gain all
> > change immediately after the timed command. I was expecting for them
> > to not change until the time command was supposed to execute. Is the
> > timed command still executing properly but the local values for the
> > getters comes back as the last set value?
> well, misunderstanding: the get_rx_freq calls (and similar calls) don't
> actually ask the USRP for its current frequency (that's pretty much
> technically impossible; not all tuners have registers that you can ask
> "hey, what's your current frequency", and also, the conversion between
> frequency and synthesizer register settings is often far from trivial),
> but just return the last value you set via set_rx_freq, whether or not
> the timed command has taken effect in the device ? really, timed
> commands aren't happening on your computer, but in the device. Your
> computer and your device have different understandings of time (the USRP
> much more being close to "real world time"), and so the computer could
> never know if a point in time has passed for the device (and vice versa).
> >
> > I am aiming to be able to set the rate, freq, and gain via timed
> > commands. The other side of the research is how long it takes for
> > each of the fields to be set. Since these commands are happening on
> > the FPGA side of things I suppose that I cannot know exactly when the
> > timed commands are firing and completing right?
> right.
> > Is the best I can hope for to benchmark how long it takes each
> > command to settle with just the setters in the UHD API?
> No, you can't hope for that. As mentioned, the get_* calls don't usually
> tell you what's going on on the device. You need to come up with a)
> values of experience or b) a signal-based method of noticing change.
> Since this now *really* gets device-specific, I won't elaborate further
> until you tell us your device :)
>
> Best regards,
> Marcus
>
> _______________________________________________
> 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/20160520/59f13951/attachment-0001.html>
------------------------------
Message: 27
Date: Fri, 20 May 2016 16:39:48 +0200
From: [email protected]
To: [email protected]
Subject: Re: [USRP-users] Burst Tx and Underrun
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Marcus,
My bad, it was a typo as it should show 1M on the sink too.
The combination of PFB and other sample_rates seems to show a better
result, thanks for the prime factor sharing rule !
However, I need to detect the new end_of_burst nor recalculate the
packet_len tag after modulation/resampling.
Should I write a custom version of TaggedStream To PDU which wait for a
change in the number of samples in the input buffer (if it's an
effective method) ?
Best regards,
-JM
On 2016-05-18 22:22, Marcus M?ller via USRP-users wrote:
> Hi JM,
>
> Two things:
> First, it seems you're resampling to 1MS/s, but you use 2MS/s in your
> sink. That doesn't lead to any Underruns, but will make everything in
> your baseband signal be interpreted at twice the sampling rate. Is
> that a typo?
>
> Secondly, generally, I recommend the rational resampler ? because
> it's very efficient at what it does. However,
>
> * you should configure it with interpolation and decimations that
> don't share any prime factors, and 1,000,000 and 655360 share one
> prime factor of five and six prime factors of 2, and
> * it's only an efficient solution if the resulting factors aren't
> very large ? 15625 and 1024 (that being the reduced
> interpolation/decimation factors) are very large, so the resulting
> resampling filter will need to be very harsh.
>
> This might really be the case where an arbitrary resampler might work
> better. As it is now, the resampling filter probably eats up all your
> CPU. Try the PFB resampler, or try something different than 1 or 2 MS
> as sampling rate for the USRP ? the B-series USRPs are very flexible
> in terms of possible rates, and the USRP2/N2xx series can take most
> integer factors of 100MS/s, and the X3xx series integer factors of
> 200, 184.32 and 120 MS/s.
>
> Best regards,
> Marcus
>
> On 18.05.2016 11:31, JM via USRP-users wrote:
>
>> Hi Everyone,
>>
>> I'm currently trying to implement a burst 2-FSK data transmitter
>> which fulfill these parameters :
>> - Bit_rate : 32768
>> - FSK_deviation : 50k
>> - Center Freq : 868MHz
>>
>> Here my simple flowgraph : http://i.imgur.com/u6LOK5m.png [1]
>>
>> The very precise baud_rate was a problem at first, because the USRP
>> sample rate was a multiple of baud_rate and was not supported (UHD
>> Warning: "expect CIC rolloff" & "The hardware does not support the
>> requested TX sample rate" ), so i inserted a Rational Resampler and
>> it solved this issue quite well.
>>
>> With this Tx chain, i can recover the data with a 60% sucess ratio.
>> For the 40% failed data, I see a "hole" in my recovered data, as if
>> the USRP stoped transmitting for a very short period of time
>> (randomly in the body of the message)
>>
>> I think the problem is linked to the "Under run" warning observed
>> at each burst (only a single one).
>> - I first tried to use the "length tag" ( but the number of samples
>> for my burst has changed after the modulation chain (and of course,
>> after the resampling) .. so i didn't find any way to recalculate it
>> precisely to modify the tag before the USRP sink.
>> - I then tried to use the couple tx_sob / tx_eob with a custom
>> block (which is quite fun after all) after the PDU to Tagged stream
>> block. Length tag is removed (to enable tx_sob/tx_eob parsing),
>> tx_sob is inserted at the first sample and tx eob is inserted at the
>> last sample. After resampling, another custom block is shifting
>> tx_eob tag to the last sample of the sample set.
>>
>> None of these tries removed the "U" warning, but i achieved to get
>> 85% receive success by sending quite a big padding before any packet
>> ... It's better but it's a dirty fix, i don't like it :)
>>
>> I'm running out of ideas and blocks coding experiments .. Anyone
>> has any ideas ?
>>
>> Thanks !
>>
>> -JM
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> [2]
>
>
>
> Links:
> ------
> [1] http://i.imgur.com/u6LOK5m.png
> [2] 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
------------------------------
Message: 28
Date: Fri, 20 May 2016 16:55:03 +0200
From: Marc Bauduin <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Decaying RX energy & oscillations on
N210+RFX2450 Re: Frequency synchronization problem
Message-ID:
<CA+ekp-b4Uwr0Rt0nk2wkKFcM2mfxG=v1_fvprq_nhlrkqos...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi everyone,
I made a simulation with the DC compensation algorithm for a carrier
frequency of 2.43 GHz and an interpolation factor of 16. In this case, the
peak at -1.43 MHz is reduced by -25 dB. Even with this algorithm, I am able
to recover the steps with this carrier frequency. I don't understand why
the DC algorithm affect a value which not in DC. Could it be due to the
CORDIC algorithm if this one is after the DC compensation? It makes sense
in this case because we would have a DC offset before the frequency
translation. This one would become a progressive phase rotation at the
output of the CORDIC algorithm. Is that right?
I also removed the I/Q balance compensation algorithm and, in this case, it
is the peak at -2.86 MHz which decreases by -25 dB. Maybe the I/Q
compensation doesn't work very well? It is strange as I made a calibration
with the UHD tools. Or maybe I misinterpret my results?
Marc
2016-05-18 14:47 GMT+02:00 Marc Bauduin <[email protected]>:
> Hi Marcus,
>
> I disabled the dc offset filter in this scenario with
> set_rx_dc_offset(false).
>
> I would not be surprise to see some oscillations at the beginning of each
> step because of the finite bandwidth of the front-end. But, in this case,
> they would decrease to finally disappear in the noise of the communication.
> But it is not the case.
>
> Just to be sure that my scenario is clear. I do a communication between
> two USRPs. The signal which is created by the Tx USRP is a step signal in
> baseband.
>
> For the synchronisation, I use a 10 MHz square wave. This one is generated
> with a clock-tamer 1.30.
>
> I sent you four figures. On the first one (stepSignal.png), you can see
> the step signal for different interpolation factor when the signal is
> transmitted around 2.43 GHz. The second one (stepSignal240.png) is also a
> step signal but with a carrier frequency of 2.4 GHz.
>
> The third figure (stepSpectre.png) is the spectrum of one step of my
> signal transmitted with an amplitude of 0.5. I used different
> interpolation/ decimation factors. As you can see the received spectrum is
> very different from the spectrum of constant signal. It can explain the
> degradation that I observe on "stepSignal.png" when I reduce the
> interpolation factor. It explain also the presence of these oscillations.
>
> Finally, the fourth figure (stepSpectreAmp16.png) is the spectrum of some
> steps with an interpolation factor of 16 and a carrier frequency of 2.43
> GHz. We can see the spectrum of three different amplitudes. It is
> interesting to see that the component around -2.85 MHz decreases in the
> same proportion as the DC component (which is the amplitude of the step).
> The amplitude of the component around -1.43 MHz does not depend on the
> amplitude of the step (this is very strange). For the peak around 2.85 MHz,
> it seems that it comes from the non-linear behavior of some components.
> This one is not a surprise because, with an amplitude of 0.9, I am very
> close to the saturation point of the power amplifier of the transmitter.
>
> I also made an experiment where I removed the antenna from my Rx USRP and
> evaluate the received spectrum. Normally, it should only be a white noise.
> But I also observe a peak around -1.43 MHz. It seems that this component is
> always present in the receiver. I tried with another USRP and I have the
> same result. The position of the peak only changes with the carrier
> frequency. It can explain why I have a so different result between these
> two carrier frequencies.
>
> Do you know the origin of this peak?
>
> I hope that these results are easy to read.
>
> Thanks in advance for your answers.
>
> Marc
>
> 2016-05-13 13:06 GMT+02:00 Marcus M?ller <[email protected]>:
>
>> Hi Marc,
>>
>> On 13.05.2016 10:55, Marc Bauduin via USRP-users wrote:
>>
>> Thanks for the information.
>>
>> I reduced decimation and interpolation factor to 4. In this case, the CIC
>> filter is bypassed and the decimation is only done with the help of two
>> half-band filters. Is that right?
>>
>> yes!
>>
>>
>> In that case, I don't observe the decay anymore but each step are
>> affected by an important oscillation. I checked the spectrum of each step
>> and I can see some important peak for some specific frequencies. I still
>> need to find their origin.
>>
>> can you give us plots or samples? What kind of oscillation, is it
>> decaying, constant in frequency?
>>
>> Like Marcus L., my first suspicion here is the rx_dc_offset filter; did
>> you disable that in this case?
>> Oscillations at a step wouldn't surprise me; after all, all linear
>> systems have what is called a step response, and so do our halfband
>> filters, and the analog baseband filters on the daughterboard.
>>
>>
>> I also changed the carrier frequency. Previously, I worked around 2.4
>> GHz. Now I tried 2.43 GHz. In this case, I still observe important
>> oscillations with an interpolation factor of 4. If I reduce the sampling
>> frequency, I am now able to recover the step signal.
>>
>> How do you synchronize your signal generator to the USRP? What's the
>> generators' bandwidth.
>> Point is that you physically can't produce a proper step function without
>> any oscillations ? that would simply have infinite bandwidth.
>>
>> My suspicion is that there might be analog non-perfections going on.
>> Again, can you give us a plot of what you're seeing?
>> How does your signal generator connect to the USRP?
>> What happens if you reduce the power of the signal and the gain of the
>> daughterboard?
>>
>> Best regards,
>> Marcus
>>
>>
>> Any idea of why the results are so different when I change the carrier
>> frequency?
>>
>> 2016-05-10 16:17 GMT+02:00 <[email protected]>:
>>
>>> It's a CIC decimator with FIR-based clean-up filters, as far as I know.
>>>
>>>
>>>
>>>
>>> On 2016-05-10 05:10, Marc Bauduin via USRP-users wrote:
>>>
>>> I increased the duration of each step to 1e4 samples. I made this
>>> simulation for several interpolation factors. Each time, I can approximate
>>> the decay with an exponential decay exp(-t/d) where d = 1.7e-4 seconds.
>>> This value is a little bit lower (1.2e-4 seconds) for an interpolation
>>> factor of 8.
>>>
>>> I am not surprised to see a peak at the beginning of each step. The
>>> problem is that the decay always go back the same value. I expected that,
>>> after some oscillation due to the decimation filter, I could observe the
>>> different steps.
>>>
>>> What kind of filter is used for the decimation?
>>>
>>> 2016-05-06 16:51 GMT+02:00 <[email protected]>:
>>>
>>>> What is the period of the decay? This may just be the decimation
>>>> filters reacting to a step change in the input, and it's just more obvious
>>>> when the devices are strictly synchronous. That's just a guess.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 2016-05-06 05:09, Marc Bauduin via USRP-users wrote:
>>>>
>>>> Maybe I answered too quickly.
>>>>
>>>> I made a new test where I send a step signal (0.1, 0.2, ..., 1). Each
>>>> value is maintained during 1e3 samples. If I look at the amplitude of the
>>>> received signal in baseband, I am able to recover this step signal if the
>>>> USRPs are not synchronized. But if I synchronize them with the 10MHz clock,
>>>> I can see quick changes in amplitude followed by a decay. As if the radio
>>>> still tried to compensate a DC offset.
>>>>
>>>> I used the function set_rx_dc_offset(false) or
>>>> set_rx_dc_offset(false)(std::complex<double>(a,b)). The only difference is
>>>> the value reached after the decay.
>>>>
>>>>
>>>> 2016-04-27 22:24 GMT+02:00 Marc Bauduin < <[email protected]>
>>>> [email protected]>:
>>>>
>>>>> Thank you for your answer. It was effectively that.I used the
>>>>> function set_rx_dc_offset(false) to remove the algorithm and I don't
>>>>> observe this effect anymore when I send a signal constant in baseband.
>>>>>
>>>>> 2016-04-27 15:39 GMT+02:00 Marcus D. Leech via USRP-users <
>>>>> <[email protected]>[email protected]>:
>>>>>
>>>>>> On 04/27/2016 08:40 AM, Herlook Search via USRP-users wrote:
>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> I use two USRP N210 with the RFX2450. I manipulate them in C++.
>>>>>>>
>>>>>>> I would like to characterize the USRPs. In that way, I send very
>>>>>>> simple signals, as a constant signal in baseband. When I send this
>>>>>>> signal,
>>>>>>> I observe a circle in baseband due to the CFO. This is what I expected.
>>>>>>>
>>>>>>> If I send the same signal when the USRPs are synchronized with the
>>>>>>> same 10 MHz clock (I use an external square wave generator), I see that
>>>>>>> the
>>>>>>> amplitude of this sequence quickly decreases through time. If I use an
>>>>>>> alternate sequence of {-1;+1}, I also observe that its amplitude
>>>>>>> decreases.
>>>>>>>
>>>>>>> But it seems that the synchronisation works because, when I do an
>>>>>>> OFDM communication or a single carrier communication with the 10 MHz
>>>>>>> clock,
>>>>>>> I can recover my QAM constellation without CFO.
>>>>>>>
>>>>>>> Can you confirm that these results are expected from such a
>>>>>>> configuration? If it is the case, can we avoid them?
>>>>>>>
>>>>>>> Thanks in advance.
>>>>>>>
>>>>>>> Marc
>>>>>>>
>>>>>>> Make sure that your baseband tone is far enough away from DC so as
>>>>>> not to get swallowed by the DC-offset compensation algorithm, which
>>>>>> takes a
>>>>>> while to converge.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> <[email protected]>[email protected]
>>>>>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>>>>> 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
>>>>
>>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>>
>> _______________________________________________
>> 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/20160520/f53127df/attachment-0001.html>
------------------------------
Message: 29
Date: Fri, 20 May 2016 10:26:35 +0200
From: rv pellarin <[email protected]>
To: [email protected]
Subject: [USRP-users] b205 mini and gnuradio companion
Message-ID:
<CAHLh5KGYPPN8omo5=yqwjpmfuro0ensahwr_a1qgobrpoxs...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
hi folks,
happy to join the community, i just received my b205 mini
i ve started to get into gnuradio companion, but i fail getting the b205mini
do you guys have one or two grc file to share that i can look into,
flowcharts that would work with the b205 mini?
would be great
thx for your time
best regards
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160520/7850f14e/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 69, Issue 20
******************************************
