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: MIMO cable based USRP sample time alignment (Martin Braun)
2. Re: Problem of running two channels of TVRX2 (Martin Braun)
3. Re: X310 RFNOC FFT block issue (James Wagner)
4. Re: X310/UBX temperature/performance, RFNoC clock control
(Michael West)
5. Re: X310 MTU Issue in Ubuntu 14.04 (Dave NotTelling)
6. Re: X310 MTU Issue in Ubuntu 14.04 (Michael West)
7. Re: Problem of running two channels of TVRX2 ([email protected])
8. X310 Multi-daughterboard (Dave NotTelling)
9. Re: X310 Multi-daughterboard (Michael West)
10. Re: X310 Multi-daughterboard (Dave NotTelling)
11. Re: X310 Multi-daughterboard (Michael West)
12. Re: X310 Multi-daughterboard (Martin Braun)
13. Re: MIMO cable based USRP sample time alignment
(avinash kalyanaraman)
14. Re: MIMO cable based USRP sample time alignment (Martin Braun)
15. Re: Keep_one_in_n doesn't seem to work above 1:1 in RFNoC
(Jonathon Pendlum)
16. Re: Bug: Uncachable Exception thrown when stack is unwound
from destroying multi_usrp (Weaver, Tyler)
17. Announcing NEWSDR on Thr/Fri June 2/3 (Updated) (Neel Pandeya)
18. Re: Frequency synchronization problem (Marc Bauduin)
19. Re: Frequency synchronization problem ([email protected])
20. Using Two Inputs on N210 (Eric C.)
21. Re: Using Two Inputs on N210 ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Mon, 9 May 2016 10:34:39 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] MIMO cable based USRP sample time alignment
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
You also need to actually write the time to the device using
set_time_next_pps().
If you create a single streamer to both devices (e.g. in GNU Radio with
a single USRP source), it will only work if the samples are time-aligned.
M
On 05/06/2016 08:50 AM, avinash kalyanaraman via USRP-users wrote:
> Hi all,
>
> I am trying to calculate the phase difference on a received signal at
> two USRP N210s that are connected via a MIMO cable.
>
> To do this, I use GRC and set one of the USRP Sources to have Mb0: Clock
> Source and Mb0: Time Source = MIMO Cable.
>
> Is this sufficient to ensure that the sample times at the two USRPs will
> be temporally aligned (i.e. they happen at the same instance) ? Is there
> anyway for me to test real-quick, if they are both sampling at the same
> time?
>
>
> Thanks,
>
> --
> Avinash
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 2
Date: Mon, 9 May 2016 10:35:16 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Problem of running two channels of TVRX2
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
How are you setting your subdev spec? Is this in GNU Radio?
M
On 05/05/2016 11:41 PM, Tai Wooi Ling via USRP-users wrote:
> Hi.
>
> I am recently using TVRX2 and USRP1 to receive 150MHz and 400MHZ. Hence,
> i use both channels of TVRX2. However, i found that i cannot run both
> channels at the same time. But when only one channel, it works ok. So, i
> wonder have i miss some procedure before using TVRX2?
>
> Your help is appreciated.
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 3
Date: Mon, 9 May 2016 10:48:08 -0700
From: James Wagner <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 RFNOC FFT block issue
Message-ID:
<CA+USoOK24r2aHL3oK1q5Hr6b9DmTnhpG_0Pf+guRYXX7j=x...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Right, so finally tracked down the problem. apparently the maximum frame
size was violated by a spp of 512 on the X310. so the FFT was able to run
on the E310 but not on the X310. apparently the system fails rather
silently. when i set the SPP to 256 this time it worked( I tried this
earlier but this was obscured by the other issues).
This brings one interesting question to mind. Does RFNOC conflate
processing block sizes and transfer sizes?
On Fri, May 6, 2016 at 12:51 PM, James Wagner <[email protected]> wrote:
> I am trying to get code that works with the E310 to run on the X310. I
> have the E310 off the network right now and am running the code locally( I
> assume network mode still does not work with RFNOC). for the X310 I am
> running it over an Ethernet connection. I check the mailing list and found
> that the poke32 error can often be fixed by increasing the size of the
> socket buffer and after doing this that error stopped. now i just don't get
> anything out of the block. if i run my own code i get zero samples back
> when i call the recv method for the streamer. when I run a GRC flowgraph it
> gives me an error message "timeout on chan 0".
>
> just to clarify this code operates correctly on the E310, and I am able to
> get samples from the X310 (I was demodulating live FM stations to confirm).
> the issue is when I attempt to use the FFT block on the X310 I seem to be
> getting no data out.
>
>
>
> On Fri, May 6, 2016 at 9:31 AM, Martin Braun via USRP-users <
> [email protected]> wrote:
>
>> On 05/05/2016 09:14 AM, James Wagner wrote:
>> > well I partially resolved this one. in the C++ code a line got commented
>> > out that connects the Radio to the FFT block. I have not dug too deep
>> > into the issue_stream command but I am guessing it tries to issue a
>> > corresponding command to the radio and when it did not find the radio it
>> > tried to issue it to the FFT block.
>>
>> Yes, that would happen.
>>
>> >
>> > but this really only showed that the warning
>> >
>> > issue_stream_cmd() not implemented for 0/FFT_0
>> >
>> > is unrelated to the problem.
>> >
>> > it turns out that if i run this code directly on the E310 it works. I
>> > also found that there are two failure modes depending on the
>> > configuration. when pass data directly to both sides of the FPGA there
>> > is simply no output from the FPGA and the streamer delivers 0
>> > packets. however if I connect the input of the FFT to the radio two
>> > error messages are produced
>> >
>> > EnviromentError: IOError x300 fw communication failure # 3
>> > EnviroemntError: IOError x300 fw poke32 - reply timed out
>> >
>> > this is consistent across both my own code and GNURadio.
>>
>> ...those errors come from an X-series though. And you said this is on an
>> E310? Are you maybe discovering the wrong device on the network?
>>
>> M
>>
>>
>> >
>> >
>> >
>> >
>> > On Mon, May 2, 2016 at 2:01 PM, James Wagner <[email protected]
>> > <mailto:[email protected]>> wrote:
>> >
>> > something like
>> > std::string stream_arguments = "";
>> > uhd::stream_args_t stream_args(cpu_format,wire_format);
>> > stream_args.args = stream_arguments;
>> > uhd::rx_streamer::sptr rx_stream =
>> > usrp->get_rx_stream(stream_args);
>> > uhd::stream_cmd_t
>> > stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
>> > stream_cmd.num_samps = 100000;
>> > stream_cmd.stream_now = true;
>> > stream_cmd.time_spec = uhd::time_spec_t();
>> > rx_stream->issue_stream_cmd(stream_cmd);
>> >
>> > while( some tests)
>> > {
>> > num_rx_samps = rx_stream->recv(&buff.front(),
>> > buff.size()/2, md, 3.0, true);
>> > if(num_rx_samps)
>> > {
>> > std::cout << "got samples\n";
>> > num_fails = 0;
>> > }
>> >
>> >
>> >
>> > }
>> >
>> >
>> > On Mon, May 2, 2016 at 1:16 PM, Martin Braun via USRP-users
>> > <[email protected] <mailto:[email protected]>>
>> wrote:
>> >
>> > How does your C++ code look like? It looks like you're calling
>> > issue_stream_cmd() on the actual FFT block, which you shouldn't
>> > be doing
>> > -- you'd only call that on a radio, or you streamers.
>> >
>> > Cheers,
>> > m
>> >
>> > On 05/02/2016 10:23 AM, James Wagner via USRP-users wrote:
>> > > I am currently working with RFNOC on the X310 after doing some
>> > work on
>> > > the E310 and I seem to be having an issue getting the FFT
>> > block to work.
>> > > I have tried the block in both GNURadio and with C++ code
>> which
>> > > previously worked with the E310. in GNURadio Chan 0 timeouts
>> > immediately
>> > > and no data seems to pass through. when i run my C++ code i
>> get a
>> > > warning saying
>> > >
>> > > UHD warning:
>> > > issue_stream_cmd() not implemented for 0/FFT_0
>> > >
>> > > and the recv method for the streamer never returns a non-zero
>> > value.
>> > >
>> > >
>> > >
>> > > additional information
>> > > Ubuntu 14.0.4
>> > > UHD_003.010.rfnoc-300-g74d178b5
>> > >
>> > >
>> > > _______________________________________________
>> > > 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/20160509/26295d96/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 9 May 2016 10:55:10 -0700
From: Michael West <[email protected]>
To: hanwen <[email protected]>
Cc: Mark-Jan Bastian <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310/UBX temperature/performance, RFNoC
clock control
Message-ID:
<cam4xkrrh08o04i+1qy23-snr4jqemrvfr+q6zagha5-rqlu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Hanwen,
Sorry, I forgot the "/value" at the end of the path. It should be:
usrp->get_device()->get_tree()->access<std::string>("/mboards/0/dboards/A/rx_frontends/0/power_mode/value").set("powersave");
You can see the paths to all the properties in the tree by running
"uhd_usrp_probe --tree".
Regards,
Michael
On Sun, May 8, 2016 at 2:39 AM, hanwen <[email protected]> wrote:
> Hi Michael,
>
> I'm building a TDMA system with UHD and found strong leakages from Tx slot
> to Rx slot of UBX than of SBX. I try to turn on the powersave mode of UBX
> with:
>
> usrp->get_device()->get_tree()->access<std::string>("/mboards/0/dboards/A/rx_frontends/0/power_mode/").set("powersave");
> but I get runtime error: Error: RuntimeError: Cannot access! Property
> uninitialized at: /mboards/0/dboards/A/rx_frontends/0/power_mode/
>
> Would you tell the correct setting for turning on the powersave mode?
> Thank you.
>
> I'm using x310+UBX-160 with fresh 3.9.4-release UHD and image.
>
> Br, Hanwen
>
>
>
> 2016-02-01 20:38 GMT+01:00 Michael West via USRP-users <
> [email protected]>:
>
>> Hi Mark-Jan,
>>
>> I can't speak to the RFNoC question, but there are ways to reduce power
>> on the UBX board. First, the UBX has a "power_mode" setting that can
>> disable certain frontend components when not streaming. To do this, add
>> the following lines of code:
>>
>> BOOST_FOREACH(size_t mboard, usrp->get_num_mboards)
>> {
>> usrp->get_device()->get_tree().access<std::string>("/mboards" /
>> mboard / "dboards/A/rx_frontends/0/power_mode").set("powersave");
>> usrp->get_device()->get_tree().access<std::string>("/mboards" /
>> mboard / "dboards/B/rx_frontends/0/power_mode").set("powersave");
>> }
>>
>> In "powersave" mode, the UBX will only enable the frontend components
>> when streaming so settling time will be longer. The default is
>> "performance" mode, which keeps the frontend components enabled.
>>
>> Beyond that, you can modify the UHD code to shutdown the TX side LOs.
>> Just add the following code at the end of the UBX initialization (at line
>> https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/dboard/db_ubx.cpp#L465
>> ):
>>
>> _txlo1->shutdown();
>> _txlo2->shutdown();
>>
>> Regards,
>> Michael
>>
>> On Sat, Jan 30, 2016 at 6:24 AM, Mark-Jan Bastian via USRP-users <
>> [email protected]> wrote:
>>
>>> Hi,
>>>
>>> Over time, my UBX-160 modules run hot, up to concerning levels (ribbed
>>> heat plate of one or both sometimes run too hot to touch).
>>> The temperature of the FPGA heatsink does not seem to be a problem. The
>>> metal lid of the X310 is on to push the air over both modules, vents on
>>> both sides are ofcourse free.
>>>
>>> I would like to reduce the heat and perhaps powerconsumption of the X310
>>> and the daugtherboards to moderate levels, also to get the best analog
>>> phase and SNR performance, while downconverting a wideband signal around
>>> 1420.405751786 MHz (hydrogen line). For this purpose, I will not need
>>> to use the transmitter part.
>>>
>>> On the software and FPGA side, I'd figure some bias currents might be
>>> switched off or reduced, perhaps clocks and modulatators/demodulators
>>> to the unused parts of the UBX-160 could be turned off if not already
>>> turned off.
>>>
>>> 1) There are two additional 12V headers on the X310 mainboard, W3 and W4,
>>> are there additional fans available for these, how much can be drawn ?
>>>
>>> I have used both an RFNoC based bitstream and the mainbranch.
>>> I performed calibration of DC offsets, rx and tx iq balance,
>>> for both modules and the ADCs they are instaled on, independently.
>>> I terminated all RF inputs with 50 ohm.
>>> I have no GPSDO installed, instead I'm using an external 10 MHz rubidium
>>> reference or the (hardwired?) internal oscillator.
>>>
>>> 2) I'm missing configuration options when using RFNoC regarding
>>> external clocksources for both radio inputs. Is there more documentation
>>> or some other hints in sourcecode for this ?
>>>
>>> Best,
>>>
>>> Mark-Jan
>>>
>>> _______________________________________________
>>> 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/20160509/6665ab79/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 9 May 2016 14:01:22 -0400
From: Dave NotTelling <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 MTU Issue in Ubuntu 14.04
Message-ID:
<CAK6GVuN5irjbGm5MZnAagbxv4f0y=Zt+p-p=guzucts3cuh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I was able to solve the issue by mucking with the sysctl settings a bit. I
arbitrarily upped the net.core.* settings by * 10 and the MTU issue went
away. Yay blind luck! Here is my config for anyone else who has issues:
[conf]
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_sack = 0
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_rmem = 10000000 10000000 10000000
net.ipv4.tcp_wmem = 10000000 10000000 10000000
net.ipv4.tcp_mem = 10000000 10000000 10000000
net.core.rmem_max = 5242870
net.core.wmem_max = 5242870
net.core.rmem_default = 5242870
net.core.wmem_default = 5242870
net.core.optmem_max = 5242870
net.core.netdev_max_backlog = 300000
[/conf]
On Mon, May 9, 2016 at 11:06 AM, Dave NotTelling <[email protected]>
wrote:
> I am trying to set the MTU of my Intel X710 10 gigabit card to 9000 in
> Ubuntu 14.04 but when I try to run osmocom_fft I get the error below. I
> changed both the net.core.rmem_max and net.core.wmem_max sysctl values to
> what is listed on http://files.ettus.com/manual/page_usrp_x3x0_config.html.
> I've gotten it to work before, but sadly I did not write down the magic
> commands that made it work and then reformatted the machine. Oh, and the
> error pops up if I lower the sampling rate down to 25e6 as well.
>
> If I back the MTU down to 2400 things work fine. Past that I get the same
> error. I am using the X710 driver from Intel instead of the stock driver
> as that was the only way I was able to get things working before nuking the
> machine.
>
> [error]
>
> osmocom_fft -F -f 5.8e9 -s 200e6
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-202-g9e0861e1
>
> gr-osmosdr v0.1.4-72-g164a09fc (0.1.5git) gnuradio 885b5a75
> built-in source types: file fcd rtl_tcp uhd hackrf rfspace redpitaya
> -- X300 initialization sequence...
> -- Determining maximum frame size... 8000 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Initialize Radio0 control...
> -- Performing register loopback test... pass
>
> FATAL: EnvironmentError: IOError: Radio ctrl (A) packet parse error -
> AssertionError: packet_info.packet_count == (seq_to_ack & 0xfff)
> in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
> at /opt/git/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:264
>
>
> Trying to fill up 1 missing channel(s) with null source(s).
> This is being done to prevent the application from crashing
> due to gnuradio bug #528.
>
> [/error]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/7c44f4b0/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 9 May 2016 11:14:22 -0700
From: Michael West <[email protected]>
To: Dave NotTelling <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 MTU Issue in Ubuntu 14.04
Message-ID:
<CAM4xKropxkP4pPAd19MjM5K_LNyaZDt07OB=dkmpo4dz2q0...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Dave,
Yes, this is a known issue with the X710. It has to do with the driver
using the full MTU size in the socket buffer even when the packet contains
less data. The default size of the socket buffer is ~200 KB, so when 32
radio control packets are queued up and the MTU is 9000, the 32 ACKs
overflow the receive buffer (32 x 9000 = 288,000) and some of the ACKs get
dropped. The simple solution (as you have found) is to increase the
default receive socket buffer size. I usually set it to 2 MB
(net.core.rmem_default=2097152).
Regards,
Michael
On Mon, May 9, 2016 at 11:01 AM, Dave NotTelling via USRP-users <
[email protected]> wrote:
> I was able to solve the issue by mucking with the sysctl settings a bit.
> I arbitrarily upped the net.core.* settings by * 10 and the MTU issue went
> away. Yay blind luck! Here is my config for anyone else who has issues:
>
> [conf]
>
> net.ipv4.ip_local_port_range = 1024 65000
>
> net.ipv4.tcp_sack = 0
> net.ipv4.tcp_timestamps = 0
>
> net.ipv4.tcp_rmem = 10000000 10000000 10000000
> net.ipv4.tcp_wmem = 10000000 10000000 10000000
> net.ipv4.tcp_mem = 10000000 10000000 10000000
>
> net.core.rmem_max = 5242870
> net.core.wmem_max = 5242870
> net.core.rmem_default = 5242870
> net.core.wmem_default = 5242870
> net.core.optmem_max = 5242870
> net.core.netdev_max_backlog = 300000
>
> [/conf]
>
> On Mon, May 9, 2016 at 11:06 AM, Dave NotTelling <[email protected]>
> wrote:
>
>> I am trying to set the MTU of my Intel X710 10 gigabit card to 9000 in
>> Ubuntu 14.04 but when I try to run osmocom_fft I get the error below. I
>> changed both the net.core.rmem_max and net.core.wmem_max sysctl values
>> to what is listed on
>> http://files.ettus.com/manual/page_usrp_x3x0_config.html. I've gotten
>> it to work before, but sadly I did not write down the magic commands that
>> made it work and then reformatted the machine. Oh, and the error pops up
>> if I lower the sampling rate down to 25e6 as well.
>>
>> If I back the MTU down to 2400 things work fine. Past that I get the
>> same error. I am using the X710 driver from Intel instead of the stock
>> driver as that was the only way I was able to get things working before
>> nuking the machine.
>>
>> [error]
>>
>> osmocom_fft -F -f 5.8e9 -s 200e6
>> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-202-g9e0861e1
>>
>> gr-osmosdr v0.1.4-72-g164a09fc (0.1.5git) gnuradio 885b5a75
>> built-in source types: file fcd rtl_tcp uhd hackrf rfspace redpitaya
>> -- X300 initialization sequence...
>> -- Determining maximum frame size... 8000 bytes.
>> -- Setup basic communication...
>> -- Loading values from EEPROM...
>> -- Setup RF frontend clocking...
>> -- Radio 1x clock:200
>> -- Initialize Radio0 control...
>> -- Performing register loopback test... pass
>>
>> FATAL: EnvironmentError: IOError: Radio ctrl (A) packet parse error -
>> AssertionError: packet_info.packet_count == (seq_to_ack & 0xfff)
>> in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
>> at /opt/git/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:264
>>
>>
>> Trying to fill up 1 missing channel(s) with null source(s).
>> This is being done to prevent the application from crashing
>> due to gnuradio bug #528.
>>
>> [/error]
>>
>
>
> _______________________________________________
> 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/20160509/56f85892/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 09 May 2016 14:30:51 -0400
From: [email protected]
To: Martin Braun <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Problem of running two channels of TVRX2
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
You'd use subdev A:RX1 A:RX2,
also, you'll need the 4rx fpga image:
usrp1_fpga_4rx.rbf
So, use "fpga=usrp1_fpga_4rx.rbf"
In your device arguments.
On 2016-05-09 13:35, Martin Braun via USRP-users wrote:
> How are you setting your subdev spec? Is this in GNU Radio?
>
> M
>
> On 05/05/2016 11:41 PM, Tai Wooi Ling via USRP-users wrote:
>
>> Hi.
>>
>> I am recently using TVRX2 and USRP1 to receive 150MHz and 400MHZ. Hence,
>> i use both channels of TVRX2. However, i found that i cannot run both
>> channels at the same time. But when only one channel, it works ok. So, i
>> wonder have i miss some procedure before using TVRX2?
>>
>> Your help is appreciated.
>>
>> _______________________________________________
>> 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/20160509/21e00e27/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 9 May 2016 14:31:08 -0400
From: Dave NotTelling <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] X310 Multi-daughterboard
Message-ID:
<CAK6GVuOVswed0Y0UhvquMHfKt8TCaYMUUM8OMzgggf=mhmv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
If I put two UBX daughterboards in an X310 chassis with two network
connections can I use each daughterboard completely independently of the
other? I'd like to be able to have two completely separate applications
using one daugherboard each.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/61093f25/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 9 May 2016 11:44:39 -0700
From: Michael West <[email protected]>
To: Dave NotTelling <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 Multi-daughterboard
Message-ID:
<cam4xkrqn7unr9gafccc1pwd4-p4uw_ap3wytz78isse21oj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Dave,
The X310 will support only a single multi_usrp object at a time. One way
to accomplish what you want is to create a process that manages the USRP
and provides an API to the other processes.
Regards,
Michael
On Mon, May 9, 2016 at 11:31 AM, Dave NotTelling via USRP-users <
[email protected]> wrote:
> If I put two UBX daughterboards in an X310 chassis with two network
> connections can I use each daughterboard completely independently of the
> other? I'd like to be able to have two completely separate applications
> using one daugherboard each.
>
> _______________________________________________
> 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/20160509/13c5fa68/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 9 May 2016 14:51:24 -0400
From: Dave NotTelling <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 Multi-daughterboard
Message-ID:
<cak6gvumiqmdvenb3g2xmqlluhcvuw4plonmvu2-9kumqz-0...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Well poop. Thank you!
On Mon, May 9, 2016 at 2:44 PM, Michael West <[email protected]> wrote:
> Hi Dave,
>
> The X310 will support only a single multi_usrp object at a time. One way
> to accomplish what you want is to create a process that manages the USRP
> and provides an API to the other processes.
>
> Regards,
> Michael
>
> On Mon, May 9, 2016 at 11:31 AM, Dave NotTelling via USRP-users <
> [email protected]> wrote:
>
>> If I put two UBX daughterboards in an X310 chassis with two network
>> connections can I use each daughterboard completely independently of the
>> other? I'd like to be able to have two completely separate applications
>> using one daugherboard each.
>>
>> _______________________________________________
>> 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/20160509/056234ee/attachment-0001.html>
------------------------------
Message: 11
Date: Mon, 9 May 2016 11:53:02 -0700
From: Michael West <[email protected]>
To: Dave NotTelling <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 Multi-daughterboard
Message-ID:
<CAM4xKrogRw=wzrazwzmnngqobcuyjayglqst+sts8yao6_z...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
GnuRadio might be able to help. It is fairly easy to set up USRP Source
and Sink and connect them to UDP Source and Sink blocks to stream data
to/from other applications. Might be worth a look.
Regards,
Michael
On Mon, May 9, 2016 at 11:51 AM, Dave NotTelling <[email protected]>
wrote:
> Well poop. Thank you!
>
> On Mon, May 9, 2016 at 2:44 PM, Michael West <[email protected]>
> wrote:
>
>> Hi Dave,
>>
>> The X310 will support only a single multi_usrp object at a time. One way
>> to accomplish what you want is to create a process that manages the USRP
>> and provides an API to the other processes.
>>
>> Regards,
>> Michael
>>
>> On Mon, May 9, 2016 at 11:31 AM, Dave NotTelling via USRP-users <
>> [email protected]> wrote:
>>
>>> If I put two UBX daughterboards in an X310 chassis with two network
>>> connections can I use each daughterboard completely independently of the
>>> other? I'd like to be able to have two completely separate applications
>>> using one daugherboard each.
>>>
>>> _______________________________________________
>>> 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/20160509/f35486df/attachment-0001.html>
------------------------------
Message: 12
Date: Mon, 9 May 2016 14:25:14 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] X310 Multi-daughterboard
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
I was going to suggest that too; you can use ZeroMQ to mux data to two
other applications across some socket (without data loss) and also send
control data back to your main app through ZeroMQ or ControlPort. Nice
bonus: It doesn't matter if those apps are on the same machine or not.
M
On 05/09/2016 11:53 AM, Michael West via USRP-users wrote:
> GnuRadio might be able to help. It is fairly easy to set up USRP Source
> and Sink and connect them to UDP Source and Sink blocks to stream data
> to/from other applications. Might be worth a look.
>
> Regards,
> Michael
>
> On Mon, May 9, 2016 at 11:51 AM, Dave NotTelling <[email protected]
> <mailto:[email protected]>> wrote:
>
> Well poop. Thank you!
>
> On Mon, May 9, 2016 at 2:44 PM, Michael West <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi Dave,
>
> The X310 will support only a single multi_usrp object at a
> time. One way to accomplish what you want is to create a
> process that manages the USRP and provides an API to the other
> processes.
>
> Regards,
> Michael
>
> On Mon, May 9, 2016 at 11:31 AM, Dave NotTelling via USRP-users
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> If I put two UBX daughterboards in an X310 chassis with two
> network connections can I use each daughterboard completely
> independently of the other? I'd like to be able to have two
> completely separate applications using one daugherboard each.
>
> _______________________________________________
> 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
>
------------------------------
Message: 13
Date: Mon, 9 May 2016 18:15:46 -0400
From: avinash kalyanaraman <[email protected]>
To: Martin Braun <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] MIMO cable based USRP sample time alignment
Message-ID:
<cajpbu_hstq1uop9f1ac_vt81phmykkzrp_qt1ukll1rzwcd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Martin.
I write 0.0 to both devices using
"set_time_next_pps(uhd.time_spec_t(0.0))", followed by a 1second sleep (as
shown below).
Would this now suffice for samples being time-aligned ?
...
self.uhd_usrp_source_2 = uhd.usrp_source(
",".join(("addr=192.168.20.2 ", "")),
uhd.stream_args(
cpu_format="fc32",
channels=range(1),
),
)
self.uhd_usrp_source_2.set_clock_source("mimo", 0)
self.uhd_usrp_source_2.set_time_source("mimo", 0)
self.uhd_usrp_source_2.set_samp_rate(samp_rate)
self.uhd_usrp_source_2.set_center_freq(freq, 0)
self.uhd_usrp_source_2.set_gain(0, 0)
self.uhd_usrp_source_2.set_antenna("RX2", 0)
self.uhd_usrp_source_1 = uhd.usrp_source(
",".join(("addr=192.168.10.2", "")),
uhd.stream_args(
cpu_format="fc32",
channels=range(1),
),
)
self.uhd_usrp_source_1.set_samp_rate(samp_rate)
self.uhd_usrp_source_1.set_center_freq(freq, 0)
self.uhd_usrp_source_1.set_gain(0, 0)
self.uhd_usrp_source_1.set_antenna("RX2", 0)
#Write time to device here
self.uhd_usrp_source_1.set_time_next_pps(uhd.time_spec_t(0.0))
self.uhd_usrp_source_2.set_time_next_pps(uhd.time_spec_t(0.0))
time.sleep(1)
...
Thanks,
On Mon, May 9, 2016 at 1:34 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> You also need to actually write the time to the device using
> set_time_next_pps().
>
> If you create a single streamer to both devices (e.g. in GNU Radio with
> a single USRP source), it will only work if the samples are time-aligned.
>
> M
>
> On 05/06/2016 08:50 AM, avinash kalyanaraman via USRP-users wrote:
> > Hi all,
> >
> > I am trying to calculate the phase difference on a received signal at
> > two USRP N210s that are connected via a MIMO cable.
> >
> > To do this, I use GRC and set one of the USRP Sources to have Mb0: Clock
> > Source and Mb0: Time Source = MIMO Cable.
> >
> > Is this sufficient to ensure that the sample times at the two USRPs will
> > be temporally aligned (i.e. they happen at the same instance) ? Is there
> > anyway for me to test real-quick, if they are both sampling at the same
> > time?
> >
> >
> > Thanks,
> >
> > --
> > Avinash
> >
> >
> > _______________________________________________
> > 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
>
--
Avinash
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/aa59ef21/attachment-0001.html>
------------------------------
Message: 14
Date: Mon, 9 May 2016 15:44:54 -0700
From: Martin Braun <[email protected]>
To: avinash kalyanaraman <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] MIMO cable based USRP sample time alignment
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hey Avinash,
you don't actually need to set_time_next_pps(), sorry, that was me
mixing things up. You just need to make sure the time and clock sync are
set to MIMO on one device, and to something else on the other one.
The other thing was correct, though. If it works, you can set up a
multichannel USRP Source and it'll stream.
Cheers,
M
On 05/09/2016 03:15 PM, avinash kalyanaraman wrote:
> Thanks Martin.
>
> I write 0.0 to both devices using
> "set_time_next_pps(uhd.time_spec_t(0.0))", followed by a 1second sleep
> (as shown below).
>
> Would this now suffice for samples being time-aligned ?
>
>
> ...
> self.uhd_usrp_source_2 = uhd.usrp_source(
> ",".join(("addr=192.168.20.2 ", "")),
> uhd.stream_args(
> cpu_format="fc32",
> channels=range(1),
> ),
> )
> self.uhd_usrp_source_2.set_clock_source("mimo", 0)
> self.uhd_usrp_source_2.set_time_source("mimo", 0)
>
>
>
> self.uhd_usrp_source_2.set_samp_rate(samp_rate)
> self.uhd_usrp_source_2.set_center_freq(freq, 0)
> self.uhd_usrp_source_2.set_gain(0, 0)
> self.uhd_usrp_source_2.set_antenna("RX2", 0)
> self.uhd_usrp_source_1 = uhd.usrp_source(
> ",".join(("addr=192.168.10.2", "")),
> uhd.stream_args(
> cpu_format="fc32",
> channels=range(1),
> ),
> )
> self.uhd_usrp_source_1.set_samp_rate(samp_rate)
> self.uhd_usrp_source_1.set_center_freq(freq, 0)
> self.uhd_usrp_source_1.set_gain(0, 0)
> self.uhd_usrp_source_1.set_antenna("RX2", 0)
>
> #Write time to device here
> self.uhd_usrp_source_1.set_time_next_pps(uhd.time_spec_t(0.0))
> self.uhd_usrp_source_2.set_time_next_pps(uhd.time_spec_t(0.0))
> time.sleep(1)
> ...
>
> Thanks,
>
>
> On Mon, May 9, 2016 at 1:34 PM, Martin Braun via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> You also need to actually write the time to the device using
> set_time_next_pps().
>
> If you create a single streamer to both devices (e.g. in GNU Radio with
> a single USRP source), it will only work if the samples are
> time-aligned.
>
> M
>
> On 05/06/2016 08:50 AM, avinash kalyanaraman via USRP-users wrote:
> > Hi all,
> >
> > I am trying to calculate the phase difference on a received signal at
> > two USRP N210s that are connected via a MIMO cable.
> >
> > To do this, I use GRC and set one of the USRP Sources to have Mb0:
> Clock
> > Source and Mb0: Time Source = MIMO Cable.
> >
> > Is this sufficient to ensure that the sample times at the two
> USRPs will
> > be temporally aligned (i.e. they happen at the same instance) ? Is
> there
> > anyway for me to test real-quick, if they are both sampling at the
> same
> > time?
> >
> >
> > Thanks,
> >
> > --
> > Avinash
> >
> >
> > _______________________________________________
> > 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
>
>
>
>
> --
> Avinash
------------------------------
Message: 15
Date: Mon, 9 May 2016 18:06:39 -0500
From: Jonathon Pendlum <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Keep_one_in_n doesn't seem to work above 1:1
in RFNoC
Message-ID:
<CAGdo0uStXYYKnEMz=f82cbswft9jkcu-d+ob01yzngjek3e...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Craig,
We talked a bit offline about this block but for the mailing list's sake
are you still having this issue?
Jonathon
On Thu, May 5, 2016 at 3:08 PM, Swanson, Craig <
[email protected]> wrote:
> ?Jonathan,
>
> I created a noc_block which included this module and tested it on the
> E310. If I assigned any number greater than n=1, it failed. I think this
> is because the output fifo is expecting exactly the same amount of data as
> what is filling the input fifo. Is this the case?
>
>
> Craig
>
>
> *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 <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>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/0ad68764/attachment-0001.html>
------------------------------
Message: 16
Date: Mon, 9 May 2016 23:52:55 +0000
From: "Weaver, Tyler" <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Bug: Uncachable Exception thrown when stack
is unwound from destroying multi_usrp
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Yes, this is a single N210 with a UBX. I?ll try to get the latest version of
UHD to work with our code and report back.
tyler
> On May 2, 2016, at 11:25 AM, Marcus M?ller via USRP-users
> <[email protected]> wrote:
>
> Just for verifcation:
> This is a single N2x0 with a UBX, right?
>
> On 02.05.2016 18:51, Marcus M?ller wrote:
>> Hi Tyler,
>>
>> would it be possible to test this with a current UHD?
>> I can't fully remember, but I vaguely recall talking about something
>> similar. With a bit of luck, this might already be solved.
>>
>> Best regards,
>> Marcus
>>
>> On 02.05.2016 18:47, Weaver, Tyler via USRP-users wrote:
>>> We would like to support removing a UHD device asynchronously within our
>>> application. There is a problem with out uhd cleans up it's object that is
>>> preventing this feature. This was observed on both centos 7 and fedora 21.
>>> We are using UHD 3.8.5 and Boost 106000.
>>>
>>> One of our objects contains a uhd::usrp::multi_usrp::sptr as a member
>>> variable that gets initialized by the value returned by
>>> uhd::usrp::multi_usrp::make. When our object is deleted it calls the
>>> destructor for the multi_usrp which throws an exception we are not able to
>>> catch because it?s related to unrolling of the stack. Please fix this as it
>>> affects are ability to support hot plugging usrp radios while our
>>> application is running. Below is part of a stack trace to demonstrate the
>>> issue:
>>>
>>> #0??0x00007f62db07a5f7 in __GI_raise (sig=sig@entry=6) at
>>> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
>>> #1??0x00007f62db07bce8 in __GI_abort () at abort.c:90
>>> #2??0x00007f62dc1da9d5 in _gnu_cxx::_verbose_terminate_handler ()
>>> ????at ../../../../libstdc+-v3/libsupc+/vterminate.cc
>>> <http://vterminate.cc/>:93
>>> #3??0x00007f62dc1d8946 in std::terminate () at
>>> ../../../../libstdc+-v3/libsupc+/eh_terminate.cc:48
>>> #4??0x00007f62dc1d7909 in _cxxabiv1::_cxa_begin_catch
>>> (exc_obj_in=0x7f62b4089d20)
>>> ????at ../../../../libstdc+-v3/libsupc+/eh_catch.cc:44
>>> #5??0x00007f62dc1d8574 in _cxxabiv1::_cxa_call_unexpected
>>> (exc_obj_in=0x1032)
>>> ????at ../../../../libstdc+-v3/libsupc+/eh_personality.cc:731
>>> #6??0x00007f62db417c1f in _Unwind_Find_FDE (pc=0x7f62b4089d20, bases=0x0)
>>> ????at ../../../libgcc/unwind-dw2-fde-dip.c:461
>>> #7??0x00007f62db41557f in uw_frame_state_for (context=0xd8be2e00, fs=0x1b)
>>> at ../../../libgcc/unwind-dw2.c:1293
>>> #8??0x00007f62db415903 in _Unwind_RaiseException_Phase2
>>> (exc=exc@entry=0x7f62b4089d20,
>>> ????context=context@entry=0x7f62c717bd60) at ../../../libgcc/unwind.inc:62
>>> #9??0x00007f62db415e37 in _Unwind_Resume (exc=0x7f62b4089d20) at
>>> ../../../libgcc/unwind.inc:230
>>> #10 0x00007f62d885424d in max287x<max2871_regs_t>::~max287x() () from
>>> /home/user/testing/libusrp.so
>>> #11 0x00007f62d88542a3 in max2871::~max2871() () from
>>> /home/user/testing/libusrp.so
>>> #12 0x00007f62d8843f19 in boost::shared_ptr<max287x_iface>::~shared_ptr() ()
>>> ?? from /home/user/testing/libusrp.so
>>> #13 0x00007f62d8850f56 in ubx_xcvr::~ubx_xcvr() () from
>>> /home/user/testing/libusrp.so
>>> #14 0x00007f62d8850f92 in
>>> boost::detail::sp_counted_impl_p<ubx_xcvr>::dispose() ()
>>> ?? from /home/user/testing/libusrp.so
>>> #15 0x00007f62d879bd34 in std::_List_base<std::pair<std::string,
>>> boost::shared_ptr<uhd::usrp::dboard_base> >,
>>> std::allocator<std::pair<std::string,
>>> boost::shared_ptr<uhd::usrp::dboard_base> > > >::_M_clear() ()
>>> ?? from /home/user/testing/libusrp.so
>>> #16 0x00007f62d8797b42 in dboard_manager_impl::~dboard_manager_impl() ()
>>> from /home/user/testing/libusrp.so
>>> #17 0x00007f62d879d682 in
>>> boost::detail::sp_counted_impl_p<dboard_manager_impl>::dispose() ()
>>> ?? from /home/user/testing/libusrp.so
>>> #18 0x00007f62d86cae2e in boost::detail::sp_counted_base::release() () from
>>> /home/user/testing/libusrp.so
>>> #19 0x00007f62d896d50b in
>>> usrp2_impl::mb_container_type::~mb_container_type() ()
>>> ?? from /home/user/testing/libusrp.so
>>> #20 0x00007f62d896dda4 in std::_List_base<std::pair<std::string,
>>> usrp2_impl::mb_container_type>, std::allocator<std::pair<std::string,
>>> usrp2_impl::mb_container_type> > >::_M_clear() () from
>>> /home/user/testing/libusrp.so
>>> #21 0x00007f62d897e83a in usrp2_impl::~usrp2_impl() () from
>>> /home/user/testing/libusrp.so
>>> #22 0x00007f62d897f209 in usrp2_impl::~usrp2_impl() () from
>>> /home/user/testing/libusrp.so
>>> #23 0x00007f62d86cae2e in boost::detail::sp_counted_base::release() () from
>>> /home/user/testing/libusrp.so
>>> #24 0x00007f62d87ba017 in multi_usrp_impl::~multi_usrp_impl() () from
>>> /home/user/testing/libusrp.so
>>> #25 0x00007f62d87ba059 in multi_usrp_impl::~multi_usrp_impl() () from
>>> /home/user/testing/libusrp.so
>>> #26 0x00007f62d86cae2e in boost::detail::sp_counted_base::release() () from
>>> /home/user/testing/libusrp.so
>>> #27 0x00007f62d8ada468 in ~shared_ptr (this=0x7f62b4000a88,
>>> __in_chrg=<optimized out>)
>>> ????at
>>> /usr/local/upe/buildtools/include/boost-1_60/boost/smart_ptr/shared_ptr.hpp:336
>>> #28 USRPReceiver::UHD_USRP::~UHD_USRP (this=this@entry=0x7f62b4000a30,
>>> __in_chrg=<optimized out>)
>>> ????at /usr/src/debug/usrp-app-16.04/src/hardware/usrp/usrp_uhd.h:90
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected] <mailto:[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/02f153d0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/02f153d0/attachment-0001.asc>
------------------------------
Message: 17
Date: Mon, 9 May 2016 18:16:29 -0700
From: Neel Pandeya <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] Announcing NEWSDR on Thr/Fri June 2/3 (Updated)
Message-ID:
<CACaXmv9jZPqyRC3P=b+oqpdjtmohb2rotpg9fulkcvcrqe8...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
??
*********************************************************************
NEWSDR 2016
New England Workshop on Software-Defined Radio
Sixth-Annual
Workshops
Thursday June 2
6:00 PM - 9:00 PM
Symposium
Friday June 3
8:00 AM - 4:00 PM
Northeastern University (NEU)
Boston, MA, USA
http://www.sdr-boston.org/
Free Registration
Poster Submissions Accepted Until Friday May 15
*********************************************************************
INVITATION TO PARTICIPATE
You are cordially invited to the 2016 New England Workshop on
Software Defined Radio (NEWSDR 2016), which is the sixth installment
of an annual series of symposium and workshop events organized by
the Boston SDR User Group (SDR-Boston).
This year, NEWSDR will be held at Northeastern University (NEU),
and consists of a day-long symposium on Friday, as well as several
hands-on workshops the evening before on Thursday. You are welcome
to attend either or both events, which are entirely free.
Attendance is typically about 100 people, and attendees are from
both academia and industry.
*********************************************************************
WORKSHOPS
THURSDAY JUNE 2
18:00 to 21:00
Forsyth Building
?70 Forsyth Street
Room 236 and 237
AGENDA
16:00 to 18:00 Early Sessions for Workshop Setup and Prerequisites
18:00 to 21:00 Workshop Events
Two workshops are being offered:
* "SDR Challenge ? Identifying Mystery Waveform Using Simulink
and RTL-SDR" by MathWorks (more details listed below)
* "Hands-On Tutorial on FPGA Computing for SDR with RFNoC"
by Ettus Research (more details listed below)
MathWorks and Ettus Research will each run a workshop on the evening
before the main event. Workshops are technical, practical, hands-on
activities in a group setting. Specific topics and further details
about the workshops will be announced shortly. Attendance is free,
but advance registration is required. Free pizza and soda will be
provided.
*********************************************************************
SYMPOSIUM
FRIDAY JUNE 3
08:00 to 16:00
Raytheon Amphitheater
Egan Research Center
120 Forsyth Street
AGENDA
08:00 to 08:30 Coffee and Light Refreshments
08:30 to 08:40 Welcome and Introduction
08:40 to 10:00 Sponsor Flash Talks (20 minutes each)
10:00 to 11:00 Coffee, Attendee Networking, Poster Sessions,
Sponsor Exhibits and Demos
11:00 to 12:00 Invited Talk: Mr Richard Reinhart,
NASA Glenn Research Center
12:00 to 13:00 Lunch and Attendee Networking
13:00 to 14:00 Invited Talk: Dr Tommaso Melodia,
Northeastern University
14:00 to 15:00 Coffee, Attendee Networking, Poster Sessions,
Sponsor Exhibits and Demos
15:00 to 16:00 Sponsor Short Course by Analog Devices
16:00 to 16:15 Closing Remarks
Plenary Speakers:
* Mr. Richard Reinhart, NASA Glenn Research Center
* Prof. Tommaso Melodia, Northeastern University
Technical Poster Presentations:
* Covering the recent work in SDR and cognitive radio technology
* Poster presentations are now being solicited
* See link at the bottom of this email to submit your abstract
Corporate Sponsors:
* Analog Devices
* Ettus Research / National Instruments
* MathWorks
* MediaTek Wireless
The symposium features plenary speakers, technical poster
presentation sessions, hardware and software demonstrations from the
event sponsors, and workshops from the event sponsors, all focusing
on recent work in SDR and cognitive radio technology. Free breakfast,
lunch, and coffee will be provided. Attendance is free, but advance
registration is required.
The symposium provides an excellent networking opportunity and a
terrific venue to exchange thoughts and ideas with other people
working in the SDR space.
*********************************************************************
WORKSHOP DESCRIPTION
SDR Challenge ? Identifying Mystery
Waveform Using Simulink and RTL-SDR
by MathWorks
During this evening event, the audience will be tasked with
identifying a ?mystery waveform? that is being generated in their
vicinity. Using MATLAB/Simulink and the RTL-SDR platform, both of
which will be provided during this event, each team will be given
several partially completed models and some details of the mystery
waveform. The objective of this challenge is to add the remaining
functionality to the models provided and leverage the RTL-SDR in
order to classify the received signal and potentially even decode
the signal.
The learning outcomes of this event include:
* Obtaining an understanding of the MATLAB/Simulink software
environment and its capabilities.
* Gaining knowledge on how MATLAB/Simulink interfaces with the
RTL-SDR device.
* Experience hands-on real-time wireless experimentation using
MATLAB/Simulink and the RTL-SDR in a controlled wireless scenario.
Given the limited number of computer workstations and RTL-SDR
platforms available, this event has a registration limit of 30
individuals (teams of 3 individuals will be formed at this event).
Facilitators: Mike McLernon, Dr Ethem Sozer
*********************************************************************
WORKSHOP DESCRIPTION
Hands-On Tutorial on FPGA Computing for SDR with RFNoC
by Ettus Research
Ettus Research has introduced a platform called RF Network-on-Chip
(RFNoC) which makes FPGA computing for SDR more accessible and
flexible. RFNoC is a new architecture for USRP devices that use
Xilinx 7-series FPGAs (E310, X300, and X310). RFNoC is built around
a packetized network infrastructure in the FPGA that handles the
transport of control and sample data between the host CPU and the
radio. Users target their custom algorithms to the FPGA in the form
of Computation Engines (CE), which are processing blocks that attach
to this network. CEs act as independent nodes on the network that can
receive and transmit data to any other node (e.g., another CE, the
radio block, or the host CPU). This architecture permits scalable
designs that can distribute processing across many nodes. Users can
create modular, FPGA-accelerated SDR applications by chaining CEs
into a flow graph. RFNoC is supported in UHD and GNU Radio. In this
workshop, we will present an interactive tutorial on RFNoC, including
a discussion on its design and capabilities, demonstrations of
several existing examples, and a walk-through on implementing a
user-defined CE and integrating the CE into GNU Radio.
Prerequisites:
* Attendees are expected to bring their own laptops to the workshop.
The laptop should have at least 2 GB memory, have at least one
Ethernet port and one USB 3.0 port, and be able to boot into a Linux
environment from a USB 3.0 flash drive.
* Attendees must create Xilinx user accounts at least three days
before the workshop, in order to obtain Xilinx licenses for the free
WebPack Edition of Vivado version 2015.4.
USB flash drives and USRP hardware will be provided in the workshop.
Enrollment is limited to 20 people.
Facilitators: Jonathon Pendlum, Wan Liu, Neel Pandeya
*********************************************************************
REGISTRATION
* Register for the Symposium, or the Workshop, or both
* Registration is required but is completely free
* Registration takes less than 5 minutes
* Registration includes free food
* Parking available
* You must register online for food and parking
* Attendance, food, parking are all limited, so please register
online as soon as possible to secure your spot
* Registration deadline is Friday May 20
* See link at the bottom of this announcement to register online
*********************************************************************
LINKS
Attendee Registration:
https://docs.google.com/forms/d/1QCIyKIVzpZfzh4ptim7zCIbcKvi2drDLurkptokdqN4
Poster Abstract Submission:
https://docs.google.com/forms/d/17faN0FQuifOHS4xX1TZWN9ABMlY__s3g81ZUfIwdtqE
*********************************************************************
ADDITIONAL INFORMATION
More information, and the event schedule,
for this event can be found at our website:
http://www.sdr-boston.org/
*********************************************************************
EOF
*********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/2a0cb98d/attachment-0001.html>
------------------------------
Message: 18
Date: Tue, 10 May 2016 11:10:00 +0200
From: Marc Bauduin <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Frequency synchronization problem
Message-ID:
<ca+ekp-y+ypwpdx3x_f1nqrnzrtvu_yve7mjrnnkgm4z5wuw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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]>:
>
>> 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]>:
>>
>>> 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]
>>> 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/20160510/695bbbcd/attachment-0001.html>
------------------------------
Message: 19
Date: Tue, 10 May 2016 10:17:39 -0400
From: [email protected]
To: Marc Bauduin <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Frequency synchronization problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
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]>:
>
> 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]>:
>
> 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]
> 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/20160510/607dc352/attachment-0001.html>
------------------------------
Message: 20
Date: Tue, 10 May 2016 09:17:21 -0600
From: "Eric C." <[email protected]>
To: [email protected]
Subject: [USRP-users] Using Two Inputs on N210
Message-ID:
<cabf-ja5xcvbsp6omm7dlxhw8etx6qdpaehyhydbp58qzftm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I have an N210 that I've used for a few projects now. In the past I've used
it with a single input on RX2 and a bandwidth of around 16.666 MHz. Along
with that I've used frequency translating filters, frequency plots, and
file metadata save blocks. All without dropouts. This was all done with
gnuradio companion.
However now I'm trying to use two inputs, RX2 and TX/RX. I've tried
something as simple as 200 kHz sample rate on each input and saving
directly to a file. I get a ton of dropouts (the character D repeated
often). Any suggestions on what I might be doing wrong? What other
information might you need from me? Thank you.
-- Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160510/3cb794db/attachment-0001.html>
------------------------------
Message: 21
Date: Tue, 10 May 2016 11:39:05 -0400
From: [email protected]
To: "Eric C." <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Using Two Inputs on N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
There's only a single receiver on most daughtercards, which gets
switched, analog-wise, between the RX2 and TX/RX ports, depending on
configuration and transmit state.
On 2016-05-10 11:17, Eric C. via USRP-users wrote:
> I have an N210 that I've used for a few projects now. In the past I've used
> it with a single input on RX2 and a bandwidth of around 16.666 MHz. Along
> with that I've used frequency translating filters, frequency plots, and file
> metadata save blocks. All without dropouts. This was all done with gnuradio
> companion.
>
> However now I'm trying to use two inputs, RX2 and TX/RX. I've tried something
> as simple as 200 kHz sample rate on each input and saving directly to a file.
> I get a ton of dropouts (the character D repeated often). Any suggestions on
> what I might be doing wrong? What other information might you need from me?
> Thank you.
>
> -- Eric
>
> _______________________________________________
> 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/20160510/f20c31e3/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 10
******************************************
