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: ERROR_CODE_ALIGNMENT (Multi-channel alignment failed) for
2 channel receiving with USRP2 and BasicRx (Craig Tong)
2. Re: how to program FPGA (ETTUS B200) ([email protected])
3. Re: how to program FPGA (ETTUS B200) (Martin Braun)
4. Re: how to program FPGA (ETTUS B200) (Ian Buckley)
5. Re: USRP X300/X310 reference daisy-chain (Rob Miller)
6. UHD 3.8 in stable repo (John Farnsworth)
7. Re: UHD 3.8 in stable repo (Martin Braun)
8. Re: UHD 3.8 in stable repo (John Farnsworth)
9. Re: UHD 3.8 in stable repo (Ben Hilburn)
10. Re: CMake Error: cmake_symlink_library: System Error:
Operation not permitted (Marcus M?ller)
11. Re: Synched TX/RX on B210 NOT POSSIBLE????
(Eleftherios(Lef) Kampianakis)
12. USRP E110 firmware and FPGA update (Adriana Arteaga)
13. Re: Synched TX/RX on B210 NOT POSSIBLE???? (Marcus D. Leech)
14. Re: Direction finding using the B210 (Soumen Banerjee)
15. Still problems with the b210... (Ralph A. Schmid, dk5ras)
16. Re: ERROR_CODE_ALIGNMENT (Multi-channel alignment failed) for
2 channel receiving with USRP2 and BasicRx (Craig Tong)
17. Re: Direction finding using the B210 (Martin Braun)
18. Re: ERROR_CODE_ALIGNMENT (Multi-channel alignment failed) for
2 channel receiving with USRP2 and BasicRx (Martin Braun)
19. LabView support for USRP-X310 (Muhammad Hadi)
20. Re: Direction finding using the B210 (Nowlan, Sean)
21. Re: Still problems with the b210... (Neel Pandeya)
22. Processing time between successive uhd::rx_streamer::recv
(Nir Eden)
----------------------------------------------------------------------
Message: 1
Date: Tue, 28 Oct 2014 18:04:26 +0200
From: Craig Tong <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] ERROR_CODE_ALIGNMENT (Multi-channel
alignment failed) for 2 channel receiving with USRP2 and BasicRx
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Hi.
I'm not sure if my original email made the list I didn't see it come
back as a list message. If not please see below.
A further update on that
Investigating the rx_multi_samples is also showing some quite peculiar
behavior.
When I put a tone into RX-A on the daughterboard and terminate RX-B:
Printing the samples for following
rx_multi_samples --subdev="A:A A:B" --channels="0,1"
gives me as expected: varying large values (for an 8 dBm tone) in
channel-0 and 0s and +/-1s in channel-1
but if I swap the signal to RX-B and terminate RX-A and run the same program
I get values up to ~ +/-4 in channel-0 and values up to ~ +/-34 in channel 1
Is this correct? I would expect just swapped channels from the first output
Then if I now swap the subdev command to:
rx_multi_samples --subdev="A:B A:A" --channels="0,1"
I get as in the first scenario: varying large values (for 8 dBm tone) in
channel-0 and 0s and +/-1s in channel 1.
And swapping the RF inputs back again for this subdev gives the same as
the second and unexpected output values.
I get the feeling I am totally missing something here. Either I'm
misunderstanding how this is supposed to work or theres a problem.
I'm running UHD 3.7.2 installed out of Gentoo portage. x64 build. I
updated the USRP2's firmware also from 3.7.2 downloaded straight from
the website. And I see the same behavior in a 32 bit MSVC2010 Windows build.
Again any input would be much appreciated.
Kind regards.
Craig
On 10/27/14 11:04, Craig Tong wrote:
> Hi
>
> I'm wondering if anyone can give me some pointers.
>
> I'm trying to get 2 separate channels out of a USRP2 using the
> respective RF connectors on the BasicRx daughter board.
>
> Currently its returning ERROR_CODE_ALIGNMENT (Multi-channel alignment
> failed) and I'm not getting any data out.
>
> The relevant lines of code are:
>
> m_pUSRP->set_rx_subdev_spec(uhd::usrp::subdev_spec_t("A:A A:B"));
>
>
> uhd::stream_args_t oStreamArgs("sc16", "sc16"); //Use 16 bit complex
> shorts
>
> std::vector<size_t> vChannelsNumbers;
>
> vChannelsNumbers.push_back(0);
>
> vChannelsNumbers.push_back(1);
>
> oStreamArgs.channels = vChannelsNumbers;
>
> m_pUSRPRxStreamer = m_pUSRP->get_rx_stream(oStreamArgs);
>
>
> Then I'm also setting and checking the RTC on the USRP but I don't
> imagine this changes anything.
>
> boost::posix_time::ptime oEpoch(boost::gregorian::date(1970,1,1));
>
> boost::posix_time::time_duration oDurationSinceEpoc =
> boost::posix_time::microsec_clock::universal_time() - oEpoch;
>
> uhd::time_spec_t oTimeNow(time_t(oDurationSinceEpoc.total_seconds()),
> long(oDurationSinceEpoc.fractional_seconds()),
> double(boost::posix_time::time_duration::ticks_per_second()));
>
>
> m_pUSRP->set_time_now(oTimeNow);
>
> uhd::time_spec_t oUSRPTime = m_pUSRP->get_time_now(); //Confirm time set
>
>
> And the stream command
> uhd::stream_cmd_t
> oStreamCmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
> oStreamCmd.stream_now = true;
>
> m_pUSRPRxStreamer->issue_stream_cmd(oStreamCmd);
>
> The recv function doesn't return any data. If I change the
> vChannelNumber vector to contain only 0 or 1 then the code work but
> only the first of the 2 buffers passed to recv(...) is filled as is to
> be expected. The data rate into the PC is also half is this case so is
> seems like data is being streamed in the 2 channel case its just
> somehow misaligned (by timestamp?) according the UHD library.
>
> If anyone has any ideas I would greatly appreciate it.
>
> Kind regards
> --
> Craig Tong
> Radar Remote Sensing Group
> Department of Electrical Engineering
> University of Cape Town
--
Craig Tong
Radar Remote Sensing Group
Department of Electrical Engineering
University of Cape Town
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141028/1dad9595/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 28 Oct 2014 16:51:37 +0000
From: <[email protected]>
To: <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] how to program FPGA (ETTUS B200)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Dear Massimo,
If you've never done it, then unless you have a really good reason, don't do it
:-)
Ok, if you want to learn, go ahead. But is there an application that you
believe you would not be able to implement first on gnuradio or with the UHD
API?
Ruben
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> massimo zampetti via USRP-users
> Sent: Tuesday, October 28, 2014 3:05 PM
> To: [email protected]
> Subject: [USRP-users] how to program FPGA (ETTUS B200)
>
> Hi,
> I'd like to understand how it is possible to program the FPGA of my ETTUS
> B200.
> I read that the USRP B200 can be programmed with the free version of Xilinx
> tools.
> I've never done anything like this so I wonder if someone could help me.
> Is there documentation about it? Where can I find it?
> Is there anyone who has worked on these issues?
> regards,
>
> Massimo
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 3
Date: Tue, 28 Oct 2014 18:49:23 +0100
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] how to program FPGA (ETTUS B200)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 10/28/2014 05:51 PM, Ruben Merz via USRP-users wrote:
> Dear Massimo, If you've never done it, then unless you have a really
> good reason, don't do it :-)
There is some truth in this.
However, the short version is:
- Download and install ISE Webpack
- Set up your environment (this depends on your OS etc., check the ISE
manuals). You want the ISE toolchain in your path.
- We have a build infrastructure you can use. Head to usrp3/top/b200 and
run the Makefile there.
Enjoy,
Martin
>
> Ok, if you want to learn, go ahead. But is there an application that
> you believe you would not be able to implement first on gnuradio or
> with the UHD API?
>
> Ruben
>
>> -----Original Message----- From: USRP-users
>> [mailto:[email protected]] On Behalf Of massimo
>> zampetti via USRP-users Sent: Tuesday, October 28, 2014 3:05 PM To:
>> [email protected] Subject: [USRP-users] how to program
>> FPGA (ETTUS B200)
>>
>> Hi, I'd like to understand how it is possible to program the FPGA
>> of my ETTUS B200. I read that the USRP B200 can be programmed with
>> the free version of Xilinx tools. I've never done anything like
>> this so I wonder if someone could help me. Is there documentation
>> about it? Where can I find it? Is there anyone who has worked on
>> these issues? regards,
>>
>> Massimo
>>
>> _______________________________________________ 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: 4
Date: Tue, 28 Oct 2014 11:26:31 -0700
From: Ian Buckley <[email protected]>
To: Martin Braun <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] how to program FPGA (ETTUS B200)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Note:
B200 uses the LX75 FPGA which is supported by the free ISE Webpack tools
B210 uses the LX150 FPGA and requires the purchased full license ISE tools.
-Ian
On Oct 28, 2014, at 10:49 AM, Martin Braun via USRP-users
<[email protected]> wrote:
> On 10/28/2014 05:51 PM, Ruben Merz via USRP-users wrote:
>> Dear Massimo, If you've never done it, then unless you have a really
>> good reason, don't do it :-)
>
> There is some truth in this.
>
> However, the short version is:
> - Download and install ISE Webpack
> - Set up your environment (this depends on your OS etc., check the ISE
> manuals). You want the ISE toolchain in your path.
> - We have a build infrastructure you can use. Head to usrp3/top/b200 and
> run the Makefile there.
>
> Enjoy,
> Martin
>
>>
>> Ok, if you want to learn, go ahead. But is there an application that
>> you believe you would not be able to implement first on gnuradio or
>> with the UHD API?
>>
>> Ruben
>>
>>> -----Original Message----- From: USRP-users
>>> [mailto:[email protected]] On Behalf Of massimo
>>> zampetti via USRP-users Sent: Tuesday, October 28, 2014 3:05 PM To:
>>> [email protected] Subject: [USRP-users] how to program
>>> FPGA (ETTUS B200)
>>>
>>> Hi, I'd like to understand how it is possible to program the FPGA
>>> of my ETTUS B200. I read that the USRP B200 can be programmed with
>>> the free version of Xilinx tools. I've never done anything like
>>> this so I wonder if someone could help me. Is there documentation
>>> about it? Where can I find it? Is there anyone who has worked on
>>> these issues? regards,
>>>
>>> Massimo
>>>
>>> _______________________________________________ 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
------------------------------
Message: 5
Date: Tue, 28 Oct 2014 15:02:08 -0400
From: Rob Miller <[email protected]>
To: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP X300/X310 reference daisy-chain
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Thanks for all the great details --- they have been most helpful. I'm
currently considering just a handful of X300s, however wanted to understand the
nuances associated with expanding to using 10s of X300s --- all lab-based and
certainly not mobile :)Best,Rob
> Date: Fri, 17 Oct 2014 12:13:18 +0200
> To: [email protected]
> Subject: Re: [USRP-users] USRP X300/X310 reference daisy-chain
> From: [email protected]
>
> One thing I forgot to mention: the ref clock signal goes through a
> jitter cleaner, which should reduce errors when daisy-chaining. (it's an
> LMK04816, if you want to look up the datasheet).
>
> Marcus
>
> On 17.10.2014 11:55, Marcus M?ller wrote:
> > Hi Rob,
> >
> > Michael is right, the Ref out is buffered (it's U530, which is a FIN1002
> > LVDS->LVTTL converter/buffer), and the signal is basically just an
> > output of the internal 10MHz clock.
> > So what you get by daisy chaining is USRPs that shouldn't exhibit
> > significant frequency offset[1]. What you won't get is
> > delay-compensation, since the X300 can't know your cable length. Also,
> > you'll get accumulated error -- which might not be a big problem for the
> > overall system, because the PLLs generating the ADC clocks on the
> > motherboards and the LOs on the daughterboards don't have an infinite
> > control loop bandwidth, which will antagonize random variations of pulse
> > duration, but it surely won't increase system performance.
> >
> > Personally, I find daisy chaining to be an awesome concept when it comes
> > to synchronizing "a few" devices, because you can do that without an
> > external clock distributor, knowing that errors introduced can't be that
> > serious. When it comes to synchronizing a lot of devices, I'd say a
> > clock distributor is the easiest way to go, on the fact alone that you
> > can take out any X300 without breaking clocking.
> >
> > So, as usual, I'm curious [2], so: what setup do you have in mind?
> >
> > Greetings,
> > Marcus
> >
> > [1] let's assume, for gross simplification, that you're not moving the
> > x300s relative to each other at high speeds while having them connected
> > via coax, so we can neglect Doppler ;)
> > [2] ok. I'm a nerd. Stuff me in a room with a rack full of cool devices
> > and I'm happy for a while. That might explain the curiosity when it
> > comes to connecting numbers of X300s...
> > On 17.10.2014 02:36, Michael West via USRP-users wrote:
> >> Hi Rob,
> >>
> >> Characterization of the daisy-chaining for the X3x0s has not been
> >> completed, so it is not possible to say at this time. Officially,
> >> daisy-chaining is not yet supported.
> >>
> >> That said, I believe there is buffering on the lines so, in theory, an
> >> unlimited number of devices can be daisy-chained. Some propagation delay
> >> from device to device is expected (varies dependent on cable length), so
> >> the limitation is primarily dependent on how tightly all the devices need
> >> to be synchronized for a particular application. The bottom line is that
> >> daisy-chaining is still experimental, so you will have to try it to see if
> >> it works for you.
> >>
> >> Best regards,
> >> Michael E. West
> >>
> >> On Thu, Oct 16, 2014 at 3:30 PM, Rob Miller via USRP-users <
> >> [email protected]> wrote:
> >>
> >>> Hi -
> >>> Does anyone know a practical maximum for the number of USRP X300/310s that
> >>> can have their references (10MHz/1PPS) daisy-chained together.
> >>> Best,
> >>> Rob
> >>>
> >>>
> >>> _______________________________________________
> >>> 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/20141028/8a76a6a5/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 28 Oct 2014 14:16:05 -0500
From: John Farnsworth <[email protected]>
To: [email protected]
Subject: [USRP-users] UHD 3.8 in stable repo
Message-ID:
<can6aaorg96uztggasrgl-qgzfycwgppgvchodgvbexoy+su...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello - think I just ran into a nasty issue. I started working with an
X310 on Fedora 20 today rather than my normal N210s. I had to go to the
Ettus binary packaged UHD release to support the device, as Fedora 20 is
still on UHD 3.6 and doesn't recognize it. I've gotten into a catch 22
though, as it seems the gnuradio version in the Ettus repo does not
function with UHD 3.8. If I install them together, python will
segmentation fault as soon as it attempts to swig load/init
gnuradio/uhd/_uhd_swig.so. It doesn't look like any previous releases are
published in the repo, so I can't do a yum downgrade to a 3.7 version. Is
there a correct solution to this?
$ gnuradio-companion
Segmentation fault (core dumped)
Core was generated by `/usr/bin/python2 /usr/bin/gnuradio-companion'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000000001e346 in ?? ()
Missing separate debuginfos, use: debuginfo-install
gnuradio-3.7.2.2-1.x86_64 libicu-50.1.2-10.fc20.x86_64
uhd-003.008.000_release-1.x86_64
(gdb) bt
#0 0x000000000001e346 in ?? ()
#1 0x00007fe0a2e73ee0 in init_uhd_swig () from
/usr/lib64/python2.7/site-packages/gnuradio/uhd/_uhd_swig.so
#2 0x00007fe0c8decf09 in _PyImport_LoadDynamicModule (name=0x67c3264
"_uhd_swig", pathname=0x67e0394
"/usr/lib64/python2.7/site-packages/gnuradio/uhd/_uhd_swig.so",
fp=<optimized out>)
at /usr/src/debug/Python-2.7.5/Python/importdl.c:53
#3 0x00007fe0c8dead43 in load_module (name=<optimized out>, fp=<optimized
out>, pathname=<optimized out>, type=<optimized out>, loader=loader@entry=0x0)
at /usr/src/debug/Python-2.7.5/Python/import.c:1915
#4 0x00007fe0c8deb976 in imp_load_module (self=<optimized out>,
args=<optimized out>) at /usr/src/debug/Python-2.7.5/Python/import.c:3182
#5 0x00007fe0c8dd8bc4 in call_function (oparg=<optimized out>,
pp_stack=0x7fffcb66db20) at /usr/src/debug/Python-2.7.5/Python/ceval.c:4098
#6 PyEval_EvalFrameEx (
f=f@entry=Frame 0x6571620, for file
/usr/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py, line 24, in
swig_import_helper (dirname=<function at remote 0x7fe0c9276578>,
imp=<module at remote 0x24c2d00>, fp=<file at remote 0x6b196f0>,
pathname='/usr/lib64/python2.7/site-packages/gnuradio/uhd/_uhd_swig.so',
description=('.so', 'rb', 3)), throwflag=throwflag@entry=0) at
/usr/src/debug/Python-2.7.5/Python/ceval.c:2740
If I remove the gnuradio/uhd directory, gnuradio-companion loads fine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141028/68a312a7/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 28 Oct 2014 20:43:46 +0100
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD 3.8 in stable repo
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 10/28/2014 08:16 PM, John Farnsworth via USRP-users wrote:
> Hello - think I just ran into a nasty issue. I started working with an
> X310 on Fedora 20 today rather than my normal N210s. I had to go to the
> Ettus binary packaged UHD release to support the device, as Fedora 20 is
> still on UHD 3.6 and doesn't recognize it. I've gotten into a catch 22
> though, as it seems the gnuradio version in the Ettus repo does not
> function with UHD 3.8. If I install them together, python will
> segmentation fault as soon as it attempts to swig load/init
> gnuradio/uhd/_uhd_swig.so. It doesn't look like any previous releases
> are published in the repo, so I can't do a yum downgrade to a 3.7
> version. Is there a correct solution to this?
John,
this does look like it's related to an incompatibility between GR and
UHD. The correct solution would be to build GNU Radio yourself, if
that's an option.
An easy way to do this is by using Pybombs:
http://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart
It will do all you need with a single command (./pybombs install
gnuradio). You do need to make sure you've deinstalled all of your GNU
Radio stuff beforehand.
M
>
> $ gnuradio-companion
> Segmentation fault (core dumped)
> Core was generated by `/usr/bin/python2 /usr/bin/gnuradio-companion'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x000000000001e346 in ?? ()
> Missing separate debuginfos, use: debuginfo-install
> gnuradio-3.7.2.2-1.x86_64 libicu-50.1.2-10.fc20.x86_64
> uhd-003.008.000_release-1.x86_64
> (gdb) bt
> #0 0x000000000001e346 in ?? ()
> #1 0x00007fe0a2e73ee0 in init_uhd_swig () from
> /usr/lib64/python2.7/site-packages/gnuradio/uhd/_uhd_swig.so
> #2 0x00007fe0c8decf09 in _PyImport_LoadDynamicModule (name=0x67c3264
> "_uhd_swig", pathname=0x67e0394
> "/usr/lib64/python2.7/site-packages/gnuradio/uhd/_uhd_swig.so",
> fp=<optimized out>)
> at /usr/src/debug/Python-2.7.5/Python/importdl.c:53
> #3 0x00007fe0c8dead43 in load_module (name=<optimized out>,
> fp=<optimized out>, pathname=<optimized out>, type=<optimized out>,
> loader=loader@entry=0x0) at /usr/src/debug/Python-2.7.5/Python/import.c:1915
> #4 0x00007fe0c8deb976 in imp_load_module (self=<optimized out>,
> args=<optimized out>) at /usr/src/debug/Python-2.7.5/Python/import.c:3182
> #5 0x00007fe0c8dd8bc4 in call_function (oparg=<optimized out>,
> pp_stack=0x7fffcb66db20) at /usr/src/debug/Python-2.7.5/Python/ceval.c:4098
> #6 PyEval_EvalFrameEx (
> f=f@entry=Frame 0x6571620, for file
> /usr/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py, line 24, in
> swig_import_helper (dirname=<function at remote 0x7fe0c9276578>,
> imp=<module at remote 0x24c2d00>, fp=<file at remote 0x6b196f0>,
> pathname='/usr/lib64/python2.7/site-packages/gnuradio/uhd/_uhd_swig.so',
> description=('.so', 'rb', 3)), throwflag=throwflag@entry=0) at
> /usr/src/debug/Python-2.7.5/Python/ceval.c:2740
>
> If I remove the gnuradio/uhd directory, gnuradio-companion loads fine.
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 8
Date: Tue, 28 Oct 2014 15:02:11 -0500
From: John Farnsworth <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] UHD 3.8 in stable repo
Message-ID:
<can6aaotozpa-x1dxpbukg-+lqw8juw7x0uwscgih04qkjla...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I was able to grab the 3.7.3 UHD RPM out of the non-repo and confirm that
solves it. I'm trying to avoid building my own as I am having issues with
the X310 in general and trying to rule out anything I've done. After
switching to the stable RPMs and getting that working and flashing that
image, I'm still seeing funny behavior from the X310. Now I'm trying to
figure out if for some reason the 10G interface on the device is bad, as
I've tried several SFPs and I keep getting timeouts/intermittent
communication to/from the device.
On Tue, Oct 28, 2014 at 2:43 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> On 10/28/2014 08:16 PM, John Farnsworth via USRP-users wrote:
> > Hello - think I just ran into a nasty issue. I started working with an
> > X310 on Fedora 20 today rather than my normal N210s. I had to go to the
> > Ettus binary packaged UHD release to support the device, as Fedora 20 is
> > still on UHD 3.6 and doesn't recognize it. I've gotten into a catch 22
> > though, as it seems the gnuradio version in the Ettus repo does not
> > function with UHD 3.8. If I install them together, python will
> > segmentation fault as soon as it attempts to swig load/init
> > gnuradio/uhd/_uhd_swig.so. It doesn't look like any previous releases
> > are published in the repo, so I can't do a yum downgrade to a 3.7
> > version. Is there a correct solution to this?
>
> John,
>
> this does look like it's related to an incompatibility between GR and
> UHD. The correct solution would be to build GNU Radio yourself, if
> that's an option.
>
> An easy way to do this is by using Pybombs:
> http://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart
>
> It will do all you need with a single command (./pybombs install
> gnuradio). You do need to make sure you've deinstalled all of your GNU
> Radio stuff beforehand.
>
> M
>
>
>
>
> >
> > $ gnuradio-companion
> > Segmentation fault (core dumped)
> > Core was generated by `/usr/bin/python2 /usr/bin/gnuradio-companion'.
> > Program terminated with signal SIGSEGV, Segmentation fault.
> > #0 0x000000000001e346 in ?? ()
> > Missing separate debuginfos, use: debuginfo-install
> > gnuradio-3.7.2.2-1.x86_64 libicu-50.1.2-10.fc20.x86_64
> > uhd-003.008.000_release-1.x86_64
> > (gdb) bt
> > #0 0x000000000001e346 in ?? ()
> > #1 0x00007fe0a2e73ee0 in init_uhd_swig () from
> > /usr/lib64/python2.7/site-packages/gnuradio/uhd/_uhd_swig.so
> > #2 0x00007fe0c8decf09 in _PyImport_LoadDynamicModule (name=0x67c3264
> > "_uhd_swig", pathname=0x67e0394
> > "/usr/lib64/python2.7/site-packages/gnuradio/uhd/_uhd_swig.so",
> > fp=<optimized out>)
> > at /usr/src/debug/Python-2.7.5/Python/importdl.c:53
> > #3 0x00007fe0c8dead43 in load_module (name=<optimized out>,
> > fp=<optimized out>, pathname=<optimized out>, type=<optimized out>,
> > loader=loader@entry=0x0) at
> /usr/src/debug/Python-2.7.5/Python/import.c:1915
> > #4 0x00007fe0c8deb976 in imp_load_module (self=<optimized out>,
> > args=<optimized out>) at /usr/src/debug/Python-2.7.5/Python/import.c:3182
> > #5 0x00007fe0c8dd8bc4 in call_function (oparg=<optimized out>,
> > pp_stack=0x7fffcb66db20) at
> /usr/src/debug/Python-2.7.5/Python/ceval.c:4098
> > #6 PyEval_EvalFrameEx (
> > f=f@entry=Frame 0x6571620, for file
> > /usr/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py, line 24, in
> > swig_import_helper (dirname=<function at remote 0x7fe0c9276578>,
> > imp=<module at remote 0x24c2d00>, fp=<file at remote 0x6b196f0>,
> > pathname='/usr/lib64/python2.7/site-packages/gnuradio/uhd/_uhd_swig.so',
> > description=('.so', 'rb', 3)), throwflag=throwflag@entry=0) at
> > /usr/src/debug/Python-2.7.5/Python/ceval.c:2740
> >
> > If I remove the gnuradio/uhd directory, gnuradio-companion loads fine.
> >
> >
> > _______________________________________________
> > 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/20141028/a41e3be8/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 28 Oct 2014 13:04:40 -0700
From: Ben Hilburn <[email protected]>
To: John Farnsworth <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD 3.8 in stable repo
Message-ID:
<caoevzkl7ha7rd1ptcq2gx_hvfovosrrb39vwpadvh1tn1gq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi John -
At this point it may be best for you to contact our support team, at
[email protected]. We want to get you up and running as soon as we can.
Cheers,
Ben
On Tue, Oct 28, 2014 at 1:02 PM, John Farnsworth via USRP-users <
[email protected]> wrote:
> I was able to grab the 3.7.3 UHD RPM out of the non-repo and confirm that
> solves it. I'm trying to avoid building my own as I am having issues with
> the X310 in general and trying to rule out anything I've done. After
> switching to the stable RPMs and getting that working and flashing that
> image, I'm still seeing funny behavior from the X310. Now I'm trying to
> figure out if for some reason the 10G interface on the device is bad, as
> I've tried several SFPs and I keep getting timeouts/intermittent
> communication to/from the device.
>
> On Tue, Oct 28, 2014 at 2:43 PM, Martin Braun via USRP-users <
> [email protected]> wrote:
>
>> On 10/28/2014 08:16 PM, John Farnsworth via USRP-users wrote:
>> > Hello - think I just ran into a nasty issue. I started working with an
>> > X310 on Fedora 20 today rather than my normal N210s. I had to go to the
>> > Ettus binary packaged UHD release to support the device, as Fedora 20 is
>> > still on UHD 3.6 and doesn't recognize it. I've gotten into a catch 22
>> > though, as it seems the gnuradio version in the Ettus repo does not
>> > function with UHD 3.8. If I install them together, python will
>> > segmentation fault as soon as it attempts to swig load/init
>> > gnuradio/uhd/_uhd_swig.so. It doesn't look like any previous releases
>> > are published in the repo, so I can't do a yum downgrade to a 3.7
>> > version. Is there a correct solution to this?
>>
>> John,
>>
>> this does look like it's related to an incompatibility between GR and
>> UHD. The correct solution would be to build GNU Radio yourself, if
>> that's an option.
>>
>> An easy way to do this is by using Pybombs:
>> http://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart
>>
>> It will do all you need with a single command (./pybombs install
>> gnuradio). You do need to make sure you've deinstalled all of your GNU
>> Radio stuff beforehand.
>>
>> M
>>
>>
>>
>>
>> >
>> > $ gnuradio-companion
>> > Segmentation fault (core dumped)
>> > Core was generated by `/usr/bin/python2 /usr/bin/gnuradio-companion'.
>> > Program terminated with signal SIGSEGV, Segmentation fault.
>> > #0 0x000000000001e346 in ?? ()
>> > Missing separate debuginfos, use: debuginfo-install
>> > gnuradio-3.7.2.2-1.x86_64 libicu-50.1.2-10.fc20.x86_64
>> > uhd-003.008.000_release-1.x86_64
>> > (gdb) bt
>> > #0 0x000000000001e346 in ?? ()
>> > #1 0x00007fe0a2e73ee0 in init_uhd_swig () from
>> > /usr/lib64/python2.7/site-packages/gnuradio/uhd/_uhd_swig.so
>> > #2 0x00007fe0c8decf09 in _PyImport_LoadDynamicModule (name=0x67c3264
>> > "_uhd_swig", pathname=0x67e0394
>> > "/usr/lib64/python2.7/site-packages/gnuradio/uhd/_uhd_swig.so",
>> > fp=<optimized out>)
>> > at /usr/src/debug/Python-2.7.5/Python/importdl.c:53
>> > #3 0x00007fe0c8dead43 in load_module (name=<optimized out>,
>> > fp=<optimized out>, pathname=<optimized out>, type=<optimized out>,
>> > loader=loader@entry=0x0) at
>> /usr/src/debug/Python-2.7.5/Python/import.c:1915
>> > #4 0x00007fe0c8deb976 in imp_load_module (self=<optimized out>,
>> > args=<optimized out>) at
>> /usr/src/debug/Python-2.7.5/Python/import.c:3182
>> > #5 0x00007fe0c8dd8bc4 in call_function (oparg=<optimized out>,
>> > pp_stack=0x7fffcb66db20) at
>> /usr/src/debug/Python-2.7.5/Python/ceval.c:4098
>> > #6 PyEval_EvalFrameEx (
>> > f=f@entry=Frame 0x6571620, for file
>> > /usr/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py, line 24, in
>> > swig_import_helper (dirname=<function at remote 0x7fe0c9276578>,
>> > imp=<module at remote 0x24c2d00>, fp=<file at remote 0x6b196f0>,
>> > pathname='/usr/lib64/python2.7/site-packages/gnuradio/uhd/_uhd_swig.so',
>> > description=('.so', 'rb', 3)), throwflag=throwflag@entry=0) at
>> > /usr/src/debug/Python-2.7.5/Python/ceval.c:2740
>> >
>> > If I remove the gnuradio/uhd directory, gnuradio-companion loads fine.
>> >
>> >
>> > _______________________________________________
>> > 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/20141028/79c7cd10/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 28 Oct 2014 22:26:10 +0100
From: Marcus M?ller <[email protected]>
To: tides anugraha <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] CMake Error: cmake_symlink_library: System
Error: Operation not permitted
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Change to something like ext4. In this time and age, there should be
absolutely no requirement to use FAT anymore!
Greetings,
Marcus
On 28.10.2014 15:47, tides anugraha wrote:
> Hi Marcus,
>
> You were right, i'm building it on FAT32 partition. Should i change my
> sdcard partition type to linux partition type such as ext4 to resolve this
> problem?
>
> Or is there any methods to solve this problem?
>
> Thanks,
> Tides
> On Oct 28, 2014 9:30 PM, "Marcus M?ller" <[email protected]> wrote:
>
>> Hi Tides,
>>
>> this is but a hopeful guess:
>> I had something similar with raw "ld" quite a while back (when hard
>> drive space was sparse and so was my budget) when I tried to build some
>> C project on a FAT32 partition. The problem was, if I remember
>> correctly, that the system couldn't set the executable bit on some files.
>> Is it possible that you're building on a FAT/NTFS mount or on a network
>> drive?
>>
>> Greetings,
>> Marcus
>>
>> On 28.10.2014 15:25, tides anugraha via USRP-users wrote:
>>> cmake_symlink_library: System Error: Operation not permitted
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
------------------------------
Message: 11
Date: Tue, 28 Oct 2014 15:01:52 -0700
From: "Eleftherios(Lef) Kampianakis" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Synched TX/RX on B210 NOT POSSIBLE????
Message-ID:
<cag8c0fw85giv_rcckcmldljsxolpngwa28s1ns8sfni2red...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello and thank you for your responses.
I am sorry, sorry, I didnt realize that I wasnt clear enough.
My goal is to "load" the B210 with the maximum number of samples (in this
case 2044) for transmission. Followingly, I want to command the usrp to
start transmitting and receiving at the same time in such way that all the
transmitted samples have a known phase compared to the received samples.
That is, if the Nth sample is transmitted (i.e. on the antenna) at time
t_tx, and the Nth sample is received at time t_rx, the t_tx - t_rx is known
after every packet. I only need to do this ONCE (i.e. transmit only ONE
packet) so I am not interested in streaming. However, since as you noted
the TX and RX synthesizers on the ad9361 are not synched, I cannot proceed
with the aforementioned methodology.
My next step is to utilize a method proposed by Stefan Ereth with which I
will utilize a splitter at the transmitter with one output going to the RX1
and the other to RX2. Supposing RX1 and RX2 are phase synched (or have a
fixed phase difference) I should be able to compensate the phase difference
between TX and RX in every session. I have cited the failed code of my
effort to synch transmit and receive below, for archiving purposes. I have
also corrected the mistake that was pointed out by Michael which of course
didnt solve the problem.
#include <uhd/types/tune_request.hpp>
#include <uhd/utils/thread_priority.hpp>
#include <uhd/utils/safe_main.hpp>
#include <uhd/usrp/multi_usrp.hpp>
#include <boost/program_options.hpp>
#include <boost/format.hpp>
#include <boost/thread.hpp>
#include <iostream>
#include <fstream>
#include <complex>
#include <csignal>
//------------------MACROS------------------
#define DEB(x) std::cout << "DEB:" << x << std::endl
//------------------SETUP------------------
//Assign the namespace po from boost::program_options
//This is done to work with the terminal inputs cause boost::program_options
// Question: why use namespace instead of .hpp
namespace po = boost::program_options;
#define CPU_FORMAT "fc32"
#define WIRE_FORMAT "sc16"
#define REF_CLOCK "internal"
#define SAMP_RATE 200e3
#define CENT_FREQ 915e6
#define TX_GAIN 10 //dB
#define RX_GAIN 10 //dB
#define SAMPLES_PER_BUFFER 1000
#define ARGS ""
#define TX_FILENAME
"/Users/kampianakis/Desktop/SGCC/Demos/UHD/uhd/host/build/examples/data/sin_IQ_TX"
#define RX_FILENAME
"/Users/kampianakis/Desktop/SGCC/Demos/UHD/uhd/host/build/examples/data/sin_IQ_RX"
#define SN std::endl
#define RX_BW SAMP_RATE/2;
#define TX 1
#define RX_CONT 0
#define TOTAL_SAMPLES 1e6
#define SYNCH_DELAY 2 //Seconds
#define DEBUG 0
#define RX_TIMEOUT 3
//Stuff for tx asynch. Declare as global to avoid input in thread (chicken)
uhd::tx_streamer::sptr tx_stream;
uhd::tx_metadata_t tx_md;
//TX metadata structure for describing received IF data. Includes time
specification, and start and stop burst flags. The send routines will
convert the metadata to IF data headers.
size_t samples_per_buff = SAMPLES_PER_BUFFER;
size_t num_tx_samps = 0;
std::vector<std::complex<float> > small_tx_buff(samples_per_buff);
void thread_startTx(){
num_tx_samps = tx_stream->send(&small_tx_buff.front(),
small_tx_buff.size(), tx_md);
// num_tx_samps = tx_stream->send(&small_tx_buff.front(),
small_tx_buff.size(), tx_md);
}
typedef boost::function<uhd::sensor_value_t (const std::string&)>
get_sensor_fn_t;
bool check_locked_sensor(std::vector<std::string> sensor_names, const char*
sensor_name, get_sensor_fn_t get_sensor_fn, double setup_time){
if (std::find(sensor_names.begin(), sensor_names.end(), sensor_name) ==
sensor_names.end())
return false;
boost::system_time start = boost::get_system_time();
boost::system_time first_lock_time;
std::cout << boost::format("Waiting for \"%s\": ") % sensor_name;
std::cout.flush();
while (true){
if ((not first_lock_time.is_not_a_date_time()) and
(boost::get_system_time() > (first_lock_time +
boost::posix_time::seconds(setup_time))))
{
std::cout << " locked." << std::endl;
break;
}
if (get_sensor_fn(sensor_name).to_bool()){
if (first_lock_time.is_not_a_date_time())
first_lock_time = boost::get_system_time();
std::cout << "+";
std::cout.flush();
}
else{
first_lock_time = boost::system_time(); //reset to 'not a date
time'
if (boost::get_system_time() > (start +
boost::posix_time::seconds(setup_time))){
std::cout << std::endl;
throw std::runtime_error(str(boost::format("timed out
waiting for consecutive locks on sensor \"%s\"") % sensor_name));
}
std::cout << "_";
std::cout.flush();
}
boost::this_thread::sleep(boost::posix_time::milliseconds(100));
}
std::cout << std::endl;
return true;
}
int UHD_SAFE_MAIN(int argc, char *argv[]){
uhd::set_thread_priority_safe();
std::string args, tx_file, rx_file, type, ref, wire_format, cpu_format;
double rate, freq, tx_gain, rx_gain, rx_bw, delay,
lo_off,seconds_in_future, rx_timeout;
rx_bw = RX_BW;
rx_gain = RX_GAIN;
wire_format = WIRE_FORMAT;
cpu_format = CPU_FORMAT;
rate = SAMP_RATE;
args = ARGS;
ref = REF_CLOCK;
freq = CENT_FREQ;
tx_gain = TX_GAIN;
// samples_per_buff = SAMPLES_PER_BUFFER;
tx_file = TX_FILENAME;
rx_file = RX_FILENAME;
seconds_in_future = SYNCH_DELAY;
rx_timeout = RX_TIMEOUT;
//------------------INIT TX------------------
//Set the scheduling priority on
the current thread. Same as set_thread_priority but does not throw on
failure.
std::cout << boost::format("Creating the usrp device with: %s...") %
args << std::endl;
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
//Make the usrp by calling the constructor with param the args
usrp->set_clock_source(ref);
//Set the clock source for the usrp device. This sets the source for a 10
MHz reference clock. Typical options for source: internal, external, MIMO.
std::cout << boost::format("Setting TX Rate: %f Msps...") % (rate/1e6)
<< std::endl;
usrp->set_tx_rate(rate);
//Set the sample rate
std::cout << boost::format("Actual TX Rate: %f Msps...") %
(usrp->get_tx_rate()/1e6) << std::endl << std::endl;
std::cout << boost::format("Setting TX Freq: %f MHz...") % (freq/1e6)
<< std::endl; //Set up tuning frequency
uhd::tune_request_t tune_request;
tune_request = uhd::tune_request_t(freq);
//Generate the tune request
usrp->set_tx_freq(tune_request);
//Tune to CENT_FREQ
std::cout << boost::format("Actual TX Freq: %f MHz...") %
(usrp->get_tx_freq()/1e6) << std::endl << std::endl; //PRINT Actual
CENT_FREQ
std::cout << boost::format("Setting TX Gain: %f dB...") % tx_gain <<
std::endl;
usrp->set_tx_gain(tx_gain);
//Set the tx_gain
std::cout << boost::format("Actual TX Gain: %f dB...") %
usrp->get_tx_gain() << std::endl << std::endl;
//------------------CHECK STUFF------------------
//Check Ref and LO Lock detect
std::vector<std::string> sensor_names;
sensor_names = usrp->get_tx_sensor_names(0);
if (std::find(sensor_names.begin(), sensor_names.end(), "lo_locked") !=
sensor_names.end()) {
uhd::sensor_value_t lo_locked = usrp->get_tx_sensor("lo_locked",0);
std::cout << boost::format("Checking TX: %s ...") %
lo_locked.to_pp_string() << std::endl;
UHD_ASSERT_THROW(lo_locked.to_bool());
}
//------------------INIT RX------------------
//IS THIS NECESSARY?
//always select the subdevice first, the channel mapping affects the
other settings
//usrp->set_rx_subdev_spec(subdev);
std::cout << boost::format("Setting RX Rate: %f Msps...") % (rate/1e6)
<< std::endl;
usrp->set_rx_rate(rate);
std::cout << boost::format("Actual RX Rate: %f Msps...") %
(usrp->get_rx_rate()/1e6) << std::endl << std::endl;
//set the center frequency
std::cout << boost::format("Setting RX Freq: %f MHz...") % (freq/1e6)
<< std::endl;
usrp->set_rx_freq(tune_request);
std::cout << boost::format("Actual RX Freq: %f MHz...") %
(usrp->get_rx_freq()/1e6) << std::endl << std::endl;
std::cout << boost::format("Setting RX Gain: %f dB...") % rx_gain <<
std::endl;
usrp->set_rx_gain(rx_gain);
std::cout << boost::format("Actual RX Gain: %f dB...") %
usrp->get_rx_gain() << std::endl << std::endl;
boost::this_thread::sleep(boost::posix_time::seconds(1)); //allow 1sec
setup time
//------------------CHECK STUFF------------------
//Always check for locked sensor
check_locked_sensor(usrp->get_rx_sensor_names(0), "lo_locked",
boost::bind(&uhd::usrp::multi_usrp::get_rx_sensor, usrp, _1, 0), 1);
//------------------INIT FILES---------------
std::ofstream outfile;
outfile.open(rx_file.c_str(), std::ofstream::binary);
if(!outfile.good()){
std::cout << "OUT File error\n";
return 0;
}
std::ifstream infile(tx_file.c_str(), std::ifstream::binary);
if(!infile.good()){
std::cout << "IN File error\n";
return 0;
}
//------------------INIT STREAMS---------------
//Stream ARGS
uhd::stream_args_t stream_args(cpu_format, wire_format);
//Call the constructor of the class stream_args_t and generate the
stream_args object with inputs the cpu_format and wire_format (this is the
format per sample)
tx_stream = usrp->get_tx_stream(stream_args);
//Generate a tx_streamer object named tx_stream using the
usrp->get_tx_stream(stream_args). Remember, usrp is already initialized
uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);
//Generate a tx_streamer object named tx_stream using the
usrp->get_tx_stream(stream_args). Remember, usrp is already initialized
//Setup metadata
//Setup tx_metadata
tx_md.start_of_burst = true;
//Set start of burst to true for the first packet in the chain. ?
tx_md.end_of_burst = false;
#define SYNCHED_TXRX 1
//For TX
if(SYNCHED_TXRX){
tx_md.has_time_spec = true;
}else{
tx_md.has_time_spec = false;
}
//Setup rx_metadata
uhd::rx_metadata_t rx_md;
//Setup stream command ONLY FOR RX
uhd::stream_cmd_t
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
stream_cmd.num_samps = samples_per_buff;
//For RX
if(SYNCHED_TXRX){
stream_cmd.stream_now = false;
// tx_md.time_spec = stream_cmd.time_spec;
}else{
stream_cmd.stream_now = true;
stream_cmd.time_spec = uhd::time_spec_t();
}
if(SYNCHED_TXRX){
//Cannt get any faster than this
tx_md.time_spec = stream_cmd.time_spec =
uhd::time_spec_t(seconds_in_future)+usrp->get_time_now();
}
//Create the buffs
std::vector<std::complex<float> > small_rx_buff(samples_per_buff);
//Fill the TX buffer
for (int i = 0; i < samples_per_buff; ++i){
infile.read((char*)&small_tx_buff.at(i),
small_tx_buff.size()*sizeof(std::complex<float>));
}
infile.close();
//Close the file pointer
//Issue the stream command
rx_stream->issue_stream_cmd(stream_cmd);
//Print number of maximum buffer size
printf("MAX TX: %d\n", (int)tx_stream->get_max_num_samps());
printf("MAX RX %d\n", (int)rx_stream->get_max_num_samps());
size_t num_rx_samps = 0;
boost::thread txThread(thread_startTx);
//receivotrnsmit
txThread.join(); //Strart the thread for tx (tx
is f blocking)
num_rx_samps = rx_stream->recv(&small_rx_buff.front(),
small_rx_buff.size(), rx_md, rx_timeout, false); // Receive buffers
containing samples described by the metadata.
// num_rx_samps = rx_stream->recv(&small_rx_buff.front(),
small_rx_buff.size(), rx_md, rx_timeout, false); // Receive buffers
containing samples described by the metadata.
//Wait for everything to stop
boost::this_thread::sleep(boost::posix_time::milliseconds(2000));
//Cleanup and print what happened
usrp->issue_stream_cmd(uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS);
// Stop the stream (not really necessary here)
double rx_stamp = rx_md.time_spec.get_full_secs() +
rx_md.time_spec.get_frac_secs();
double tx_stamp = tx_md.time_spec.get_full_secs() +
tx_md.time_spec.get_frac_secs();
double t_diff = rx_stamp - tx_stamp;
printf("RX Time stamp: %.12lf\n ?X Time stamp: %.12lf\n Diff:
%.12lf\n",rx_stamp, tx_stamp, t_diff);
switch ( rx_md.error_code ) {
case uhd::rx_metadata_t::ERROR_CODE_NONE:
printf("No error:)\n");
break;
case uhd::rx_metadata_t::ERROR_CODE_TIMEOUT:
printf("MDError 2\n");
break;
case uhd::rx_metadata_t::ERROR_CODE_LATE_COMMAND:
printf("MDError 3\n");
break;
case uhd::rx_metadata_t::ERROR_CODE_BROKEN_CHAIN:
printf("MDError 4\n");
break;
case uhd::rx_metadata_t::ERROR_CODE_OVERFLOW:
printf("MDError 5\n");
break;
case uhd::rx_metadata_t::ERROR_CODE_ALIGNMENT:
printf("MDError 6\n");
break;
case uhd::rx_metadata_t::ERROR_CODE_BAD_PACKET:
printf("MDError 7\n");
break;
default:
printf("WUT\n");
break;
}
//write the samples
if (outfile.is_open()){
outfile.write((const char*)&small_rx_buff.front(),
num_rx_samps*sizeof(std::complex<float>));
}
outfile.close();
//Close the file pointer
//print
std::cout << "Transmitted samples: " << num_tx_samps << '\n';
std::cout << "Received samples: " << num_rx_samps << '\n';
return EXIT_SUCCESS;
}
On Mon, Oct 27, 2014 at 5:47 PM, Eleftherios(Lef) Kampianakis <
[email protected]> wrote:
> Hello forum,
>
> I have a project for which it is crucial to have minimal or none time
> delay between the transmitter and receiver. For my purposes I utilize a
> B210 and use only the TX/RX for transmit and RX for receive.
>
> I have developed (following the advice of Stephen Graham) the following
> code that attaches a the transmit function to a thread in order to execute
> tx and rx concurrently (tx is blocking). For now, the TX/RX and RX channels
> are connected with coax cable to avoid random phase introduction from the
> wireless channel. I transmit and receive samples concurrently and calculate
> the time difference using tx_metadata.time_spec and rx_metadata.time_spec.
> However, when I apply a shift at the samples that I receive according to
> this time delay (N_samples_to_shift = F_sampling * T_delay) the signals
> still wont align and I still get a random time delay everytime I execute
> the UHD code.
>
> Could someone inform me if what I am trying to do here is even remotely
> possible with the B210? Should I use another platform or should I implement
> some kind of workaround?
>
> Thank you in advance
>
> CODE:
> //Author Eleftherios(Lef) Kampianakis
>
> //V0: Tx Rx wokrking but not synched
> //V1: effort for synching (failed)
> //V2: used threads to start tx asynch
>
> #include <uhd/types/tune_request.hpp>
> #include <uhd/utils/thread_priority.hpp>
> #include <uhd/utils/safe_main.hpp>
> #include <uhd/usrp/multi_usrp.hpp>
> #include <boost/program_options.hpp>
> #include <boost/format.hpp>
> #include <boost/thread.hpp>
> #include <iostream>
> #include <fstream>
> #include <complex>
> #include <csignal>
>
> //------------------MACROS------------------
> #define DEB(x) std::cout << "DEB:" << x << std::endl
>
>
> //------------------SETUP------------------
>
> //Assign the namespace po from boost::program_options
> //This is done to work with the terminal inputs cause
> boost::program_options
> // Question: why use namespace instead of .hpp
> namespace po = boost::program_options;
>
>
>
> #define CPU_FORMAT "fc32"
> #define WIRE_FORMAT "sc16"
> #define REF_CLOCK "internal"
> #define SAMP_RATE 200e3
> #define CENT_FREQ 915e6
> #define TX_GAIN 10 //dB
> #define RX_GAIN 10 //dB
> #define SAMPLES_PER_BUFFER 1000
> #define ARGS ""
> #define TX_FILENAME
> "/Users/kampianakis/Desktop/SGCC/Demos/UHD/uhd/host/build/examples/data/sin_IQ_TX"
> #define RX_FILENAME
> "/Users/kampianakis/Desktop/SGCC/Demos/UHD/uhd/host/build/examples/data/sin_IQ_RX"
> #define SN std::endl
> #define RX_BW SAMP_RATE/2;
> #define TX 1
> #define RX_CONT 0
> #define TOTAL_SAMPLES 1e6
> #define SYNCH_DELAY 2 //Seconds
> #define DEBUG 0
> #define RX_TIMEOUT 3
>
> //Stuff for tx asynch. Declare as global to avoid input in thread (chicken)
> uhd::tx_streamer::sptr tx_stream;
> uhd::tx_metadata_t tx_md;
> //TX metadata structure for describing received IF data. Includes time
> specification, and start and stop burst flags. The send routines will
> convert the metadata to IF data headers.
> size_t samples_per_buff = SAMPLES_PER_BUFFER;
> size_t num_tx_samps = 0;
> std::vector<std::complex<float> > small_tx_buff(samples_per_buff);
>
>
>
> void thread_startTx(){
> num_tx_samps = tx_stream->send(&small_tx_buff.front(),
> small_tx_buff.size(), tx_md);
> }
>
>
>
>
> typedef boost::function<uhd::sensor_value_t (const std::string&)>
> get_sensor_fn_t;
> bool check_locked_sensor(std::vector<std::string> sensor_names, const
> char* sensor_name, get_sensor_fn_t get_sensor_fn, double setup_time){
> if (std::find(sensor_names.begin(), sensor_names.end(), sensor_name)
> == sensor_names.end())
> return false;
>
> boost::system_time start = boost::get_system_time();
> boost::system_time first_lock_time;
>
> std::cout << boost::format("Waiting for \"%s\": ") % sensor_name;
> std::cout.flush();
>
> while (true){
> if ((not first_lock_time.is_not_a_date_time()) and
> (boost::get_system_time() > (first_lock_time +
> boost::posix_time::seconds(setup_time))))
> {
> std::cout << " locked." << std::endl;
> break;
> }
> if (get_sensor_fn(sensor_name).to_bool()){
> if (first_lock_time.is_not_a_date_time())
> first_lock_time = boost::get_system_time();
> std::cout << "+";
> std::cout.flush();
> }
> else{
> first_lock_time = boost::system_time(); //reset to 'not a date
> time'
>
> if (boost::get_system_time() > (start +
> boost::posix_time::seconds(setup_time))){
> std::cout << std::endl;
> throw std::runtime_error(str(boost::format("timed out
> waiting for consecutive locks on sensor \"%s\"") % sensor_name));
> }
> std::cout << "_";
> std::cout.flush();
> }
> boost::this_thread::sleep(boost::posix_time::milliseconds(100));
> }
> std::cout << std::endl;
> return true;
> }
>
>
>
> int UHD_SAFE_MAIN(int argc, char *argv[]){
>
> uhd::set_thread_priority_safe();
>
> std::string args, tx_file, rx_file, type, ref, wire_format,
> cpu_format;
>
> double rate, freq, tx_gain, rx_gain, rx_bw, delay,
> lo_off,seconds_in_future, rx_timeout;
>
> rx_bw = RX_BW;
> rx_gain = RX_GAIN;
> wire_format = WIRE_FORMAT;
> cpu_format = CPU_FORMAT;
> rate = SAMP_RATE;
> args = ARGS;
> ref = REF_CLOCK;
> freq = CENT_FREQ;
> tx_gain = TX_GAIN;
> // samples_per_buff = SAMPLES_PER_BUFFER;
> tx_file = TX_FILENAME;
> rx_file = RX_FILENAME;
> seconds_in_future = SYNCH_DELAY;
> rx_timeout = RX_TIMEOUT;
>
> //------------------INIT TX------------------
> //Set the scheduling priority on
> the current thread. Same as set_thread_priority but does not throw on
> failure.
> std::cout << boost::format("Creating the usrp device with: %s...") %
> args << std::endl;
> uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
> //Make the usrp by calling the constructor with param the args
>
> usrp->set_clock_source(ref);
> //Set the clock source for the usrp device. This sets the source for a 10
> MHz reference clock. Typical options for source: internal, external, MIMO.
> std::cout << boost::format("Setting TX Rate: %f Msps...") % (rate/1e6)
> << std::endl;
> usrp->set_tx_rate(rate);
> //Set the sample rate
> std::cout << boost::format("Actual TX Rate: %f Msps...") %
> (usrp->get_tx_rate()/1e6) << std::endl << std::endl;
>
> std::cout << boost::format("Setting TX Freq: %f MHz...") % (freq/1e6)
> << std::endl; //Set up tuning frequency
> uhd::tune_request_t tune_request;
>
> tune_request = uhd::tune_request_t(freq);
> //Generate the tune request
> usrp->set_tx_freq(tune_request);
> //Tune to CENT_FREQ
> std::cout << boost::format("Actual TX Freq: %f MHz...") %
> (usrp->get_tx_freq()/1e6) << std::endl << std::endl; //PRINT Actual
> CENT_FREQ
>
> std::cout << boost::format("Setting TX Gain: %f dB...") % tx_gain <<
> std::endl;
> usrp->set_tx_gain(tx_gain);
> //Set the tx_gain
> std::cout << boost::format("Actual TX Gain: %f dB...") %
> usrp->get_tx_gain() << std::endl << std::endl;
>
> //------------------CHECK STUFF------------------
> //Check Ref and LO Lock detect
> std::vector<std::string> sensor_names;
> sensor_names = usrp->get_tx_sensor_names(0);
> if (std::find(sensor_names.begin(), sensor_names.end(), "lo_locked")
> != sensor_names.end()) {
> uhd::sensor_value_t lo_locked = usrp->get_tx_sensor("lo_locked",0);
> std::cout << boost::format("Checking TX: %s ...") %
> lo_locked.to_pp_string() << std::endl;
> UHD_ASSERT_THROW(lo_locked.to_bool());
> }
>
>
>
>
>
>
>
>
> //------------------INIT RX------------------
>
> //IS THIS NECESSARY?
> //always select the subdevice first, the channel mapping affects the
> other settings
> //usrp->set_rx_subdev_spec(subdev);
>
> std::cout << boost::format("Setting RX Rate: %f Msps...") % (rate/1e6)
> << std::endl;
> usrp->set_rx_rate(rate);
> std::cout << boost::format("Actual RX Rate: %f Msps...") %
> (usrp->get_rx_rate()/1e6) << std::endl << std::endl;
>
> //set the center frequency
>
> std::cout << boost::format("Setting RX Freq: %f MHz...") % (freq/1e6)
> << std::endl;
> usrp->set_rx_freq(tune_request);
> std::cout << boost::format("Actual RX Freq: %f MHz...") %
> (usrp->get_rx_freq()/1e6) << std::endl << std::endl;
>
>
> std::cout << boost::format("Setting RX Gain: %f dB...") % rx_gain <<
> std::endl;
> usrp->set_rx_gain(rx_gain);
> std::cout << boost::format("Actual RX Gain: %f dB...") %
> usrp->get_rx_gain() << std::endl << std::endl;
>
> boost::this_thread::sleep(boost::posix_time::seconds(1)); //allow 1sec
> setup time
> //------------------CHECK STUFF------------------
>
> //Always check for locked sensor
> check_locked_sensor(usrp->get_rx_sensor_names(0), "lo_locked",
> boost::bind(&uhd::usrp::multi_usrp::get_rx_sensor, usrp, _1, 0), 1);
>
> //------------------INIT FILES---------------
>
>
> std::ofstream outfile;
> outfile.open(rx_file.c_str(), std::ofstream::binary);
> if(!outfile.good()){
> std::cout << "OUT File error\n";
> return 0;
> }
>
> std::ifstream infile(tx_file.c_str(), std::ifstream::binary);
>
> if(!infile.good()){
> std::cout << "IN File error\n";
> return 0;
> }
>
> //------------------INIT STREAMS---------------
>
> //Stream ARGS
> uhd::stream_args_t stream_args(cpu_format, wire_format);
> //Call the constructor of the class stream_args_t and generate the
> stream_args object with inputs the cpu_format and wire_format (this is the
> format per sample)
>
> tx_stream = usrp->get_tx_stream(stream_args);
> //Generate a tx_streamer object named tx_stream using the
> usrp->get_tx_stream(stream_args). Remember, usrp is already initialized
> uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);
> //Generate a tx_streamer object named tx_stream using the
> usrp->get_tx_stream(stream_args). Remember, usrp is already initialized
>
>
>
>
> //Setup metadata
>
> //Setup tx_metadata
>
> tx_md.start_of_burst = true;
> //Set start of burst to true for the first packet in the chain. ?
> tx_md.end_of_burst = false;
>
> #define TIMED_TX 0
> #define TIMED_RX 0
>
> if(TIMED_TX){
>
> tx_md.has_time_spec = true;
> tx_md.time_spec =
> uhd::time_spec_t(seconds_in_future)+usrp->get_time_now();
>
> }else{
> tx_md.has_time_spec = false;
> }
>
> //Setup rx_metadata
> uhd::rx_metadata_t rx_md;
>
>
> //Setup stream command ONLY FOR RX
> uhd::stream_cmd_t
> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
> stream_cmd.num_samps = samples_per_buff;
>
> if(TIMED_RX){
> stream_cmd.stream_now = false;
> stream_cmd.time_spec =
> uhd::time_spec_t(seconds_in_future)+usrp->get_time_now();
>
> }else{
> stream_cmd.stream_now = true;
> stream_cmd.time_spec = uhd::time_spec_t();
> }
>
>
>
>
> //Create the buffs
>
> std::vector<std::complex<float> > small_rx_buff(samples_per_buff);
>
>
> //Fill the TX buffer
> for (int i = 0; i < samples_per_buff; ++i){
>
> infile.read((char*)&small_tx_buff.at(i),
> small_tx_buff.size()*sizeof(std::complex<float>));
>
> }
> infile.close();
> //Close the file pointer
>
> //Issue the stream command
> rx_stream->issue_stream_cmd(stream_cmd);
>
> //Print number of maximum buffer size
> printf("MAX TX: %d\n", (int)tx_stream->get_max_num_samps());
> printf("MAX RX %d\n", (int)rx_stream->get_max_num_samps());
>
>
> size_t num_rx_samps = 0;
> size_t num_tx_samps = 0;
>
>
>
> boost::thread txThread(thread_startTx);
>
> //receivotrnsmit
> num_rx_samps = rx_stream->recv(&small_rx_buff.front(),
> small_rx_buff.size(), rx_md, rx_timeout, false); // Receive buffers
> containing samples described by the metadata.
> txThread.join(); //Strart the thread for tx
> (tx is f blocking)
>
>
>
>
> double rx_stamp = rx_md.time_spec.get_full_secs() +
> rx_md.time_spec.get_frac_secs();
> double tx_stamp = tx_md.time_spec.get_full_secs() +
> tx_md.time_spec.get_frac_secs();
> double t_diff = rx_stamp - tx_stamp;
>
>
> printf("RX Time stamp: %.12lf\n ?X Time stamp: %.12lf\n Diff:
> %.12lf\n",rx_stamp, tx_stamp, t_diff);
>
>
>
>
> switch ( rx_md.error_code ) {
>
> case uhd::rx_metadata_t::ERROR_CODE_NONE:
> printf("No error:)\n");
> break;
> case uhd::rx_metadata_t::ERROR_CODE_TIMEOUT:
> printf("MDError 2\n");
> break;
> case uhd::rx_metadata_t::ERROR_CODE_LATE_COMMAND:
> printf("MDError 3\n");
> break;
> case uhd::rx_metadata_t::ERROR_CODE_BROKEN_CHAIN:
> printf("MDError 4\n");
> break;
> case uhd::rx_metadata_t::ERROR_CODE_OVERFLOW:
> printf("MDError 5\n");
> break;
> case uhd::rx_metadata_t::ERROR_CODE_ALIGNMENT:
> printf("MDError 6\n");
> break;
> case uhd::rx_metadata_t::ERROR_CODE_BAD_PACKET:
> printf("MDError 7\n");
> break;
>
> default:
> printf("WUT\n");
> break;
>
> }
>
>
>
>
>
> //write the samples
> if (outfile.is_open()){
> outfile.write((const char*)&small_rx_buff.front(),
> num_rx_samps*sizeof(std::complex<float>));
> }
>
>
>
> outfile.close();
> //Close the file pointer
>
>
>
> //print
> // std::cout << "Transmitted samples: " << num_tx_samps << '\n';
> std::cout << "Received samples: " << num_rx_samps << '\n';
>
>
>
>
>
>
> return EXIT_SUCCESS;
> }
>
>
> --
> Eleftherios(Lef) Kampianakis
> Electronics and Computer Engineer
> PHD Candidate and Researcher at Sensing Computing Communications Group
> (SGCC)
> Department of Electrical Engineering
> University of Washington
> 3927 Adams Lane, NE, Mercer Court D805B, 98105
> website: http://users.isc.tuc.gr/~ekabianakis/
> mail:[email protected]
>
--
Eleftherios(Lef) Kampianakis
Electronics and Computer Engineer
PHD Candidate and Researcher at Sensing Computing Communications Group
(SGCC)
Department of Electrical Engineering
University of Washington
3927 Adams Lane, NE, Mercer Court D805B, 98105
website: http://users.isc.tuc.gr/~ekabianakis/
mail:[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141028/14f5f91c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: synched_txrx.cpp
Type: text/x-c++src
Size: 13810 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141028/14f5f91c/attachment-0001.cpp>
------------------------------
Message: 12
Date: Tue, 28 Oct 2014 22:27:57 +0000
From: Adriana Arteaga <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] USRP E110 firmware and FPGA update
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi, I'm working with an USRP E110 and when I want to execute any script I have
this message:
"Please update thre firmware and FPGA images for your device. See the
application notes for USRP2/N-series for instructions.
Expected FPGA compatibility 10, but got 9:
The FPGA build is not compatible with the host code build.
Please run:
sudo "/usr/share/uhd/utils/uhd_images_downloaders.py"
sudo /usr/share/uhd/utils/usrp2_card_burned.py
--fpga="/usr/share/uhd/images/usrp2_fpga.bin"
--fw="/usr/share/uhd/images/usrp2_fw.bin""
But images file doesn't have an "usrp_e110_fw.bin", and usrp2_card_burned.py
doesn't work with usrp_e110_fpga.bin only.
What can I do for update the right image for fpga and fw to usrp e110?
Thanks,
Adriana
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141028/a839dbf3/attachment-0001.html>
------------------------------
Message: 13
Date: Tue, 28 Oct 2014 19:34:11 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Synched TX/RX on B210 NOT POSSIBLE????
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 10/28/2014 06:01 PM, Eleftherios(Lef) Kampianakis via USRP-users wrote:
> Hello and thank you for your responses.
>
> I am sorry, sorry, I didnt realize that I wasnt clear enough.
>
> My goal is to "load" the B210 with the maximum number of samples (in
> this case 2044) for transmission. Followingly, I want to command the
> usrp to start transmitting and receiving at the same time in such way
> that all the transmitted samples have a known phase compared to the
> received samples. That is, if the Nth sample is transmitted (i.e. on
> the antenna) at time t_tx, and the Nth sample is received at time
> t_rx, the t_tx - t_rx is known after every packet. I only need to do
> this ONCE (i.e. transmit only ONE packet) so I am not interested in
> streaming. However, since as you noted the TX and RX synthesizers on
> the ad9361 are not synched, I cannot proceed with the aforementioned
> methodology.
I just want to re-emphasize. The TX and RX synthesizers on the AD9361
will be *coherent* to within the limits of the synthesizer phase-noise,
but they
won't have a predictable *phase offset* with respect to one another
whenever you start a new session or re-tune.
Contrast this to the usual situation with a TX in one place, and an RX
in another. Unless special pains have been taken, the TX and RX will
not have
predictable phase-offset, and they won't "march together" (coherence).
An architecture in general-purpose transceivers (whether that's
SDRs/USRPs/whatever) where the RX and TX LOs are exactly the same--that is,
a single, shared, synthesizer, is not all that common, at least for
general-purpose RF transceivers. Having separate (but usually
common-clocked)
synthesizers is the norm.
>
> My next step is to utilize a method proposed by Stefan Ereth with
> which I will utilize a splitter at the transmitter with one output
> going to the RX1 and the other to RX2. Supposing RX1 and RX2 are phase
> synched (or have a fixed phase difference) I should be able to
> compensate the phase difference between TX and RX in every session. I
> have cited the failed code of my effort to synch transmit and receive
> below, for archiving purposes. I have also corrected the mistake that
> was pointed out by Michael which of course didnt solve the problem.
>
> #include <uhd/types/tune_request.hpp>
> #include <uhd/utils/thread_priority.hpp>
> #include <uhd/utils/safe_main.hpp>
> #include <uhd/usrp/multi_usrp.hpp>
> #include <boost/program_options.hpp>
> #include <boost/format.hpp>
> #include <boost/thread.hpp>
> #include <iostream>
> #include <fstream>
> #include <complex>
> #include <csignal>
>
> //------------------MACROS------------------
> #define DEB(x) std::cout << "DEB:" << x << std::endl
>
>
> //------------------SETUP------------------
>
> //Assign the namespace po from boost::program_options
> //This is done to work with the terminal inputs cause
> boost::program_options
> // Question: why use namespace instead of .hpp
> namespace po = boost::program_options;
>
>
>
> #define CPU_FORMAT "fc32"
> #define WIRE_FORMAT "sc16"
> #define REF_CLOCK "internal"
> #define SAMP_RATE 200e3
> #define CENT_FREQ 915e6
> #define TX_GAIN 10 //dB
> #define RX_GAIN 10 //dB
> #define SAMPLES_PER_BUFFER 1000
> #define ARGS ""
> #define TX_FILENAME
> "/Users/kampianakis/Desktop/SGCC/Demos/UHD/uhd/host/build/examples/data/sin_IQ_TX"
> #define RX_FILENAME
> "/Users/kampianakis/Desktop/SGCC/Demos/UHD/uhd/host/build/examples/data/sin_IQ_RX"
> #define SN std::endl
> #define RX_BW SAMP_RATE/2;
> #define TX 1
> #define RX_CONT 0
> #define TOTAL_SAMPLES 1e6
> #define SYNCH_DELAY 2 //Seconds
> #define DEBUG 0
> #define RX_TIMEOUT 3
>
> //Stuff for tx asynch. Declare as global to avoid input in thread
> (chicken)
> uhd::tx_streamer::sptr tx_stream;
> uhd::tx_metadata_t tx_md;
> //TX metadata structure for describing received IF data. Includes
> time specification, and start and stop burst flags. The send routines
> will convert the metadata to IF data headers.
> size_t samples_per_buff = SAMPLES_PER_BUFFER;
> size_t num_tx_samps = 0;
> std::vector<std::complex<float> > small_tx_buff(samples_per_buff);
>
>
>
> void thread_startTx(){
> num_tx_samps = tx_stream->send(&small_tx_buff.front(),
> small_tx_buff.size(), tx_md);
> // num_tx_samps = tx_stream->send(&small_tx_buff.front(),
> small_tx_buff.size(), tx_md);
> }
>
>
>
>
> typedef boost::function<uhd::sensor_value_t (const std::string&)>
> get_sensor_fn_t;
> bool check_locked_sensor(std::vector<std::string> sensor_names, const
> char* sensor_name, get_sensor_fn_t get_sensor_fn, double setup_time){
> if (std::find(sensor_names.begin(), sensor_names.end(),
> sensor_name) == sensor_names.end())
> return false;
>
> boost::system_time start = boost::get_system_time();
> boost::system_time first_lock_time;
>
> std::cout << boost::format("Waiting for \"%s\": ") % sensor_name;
> std::cout.flush();
>
> while (true){
> if ((not first_lock_time.is_not_a_date_time()) and
> (boost::get_system_time() > (first_lock_time +
> boost::posix_time::seconds(setup_time))))
> {
> std::cout << " locked." << std::endl;
> break;
> }
> if (get_sensor_fn(sensor_name).to_bool()){
> if (first_lock_time.is_not_a_date_time())
> first_lock_time = boost::get_system_time();
> std::cout << "+";
> std::cout.flush();
> }
> else{
> first_lock_time = boost::system_time(); //reset to 'not a
> date time'
>
> if (boost::get_system_time() > (start +
> boost::posix_time::seconds(setup_time))){
> std::cout << std::endl;
> throw std::runtime_error(str(boost::format("timed out
> waiting for consecutive locks on sensor \"%s\"") % sensor_name));
> }
> std::cout << "_";
> std::cout.flush();
> }
> boost::this_thread::sleep(boost::posix_time::milliseconds(100));
> }
> std::cout << std::endl;
> return true;
> }
>
>
>
> int UHD_SAFE_MAIN(int argc, char *argv[]){
> uhd::set_thread_priority_safe();
>
> std::string args, tx_file, rx_file, type, ref, wire_format,
> cpu_format;
> double rate, freq, tx_gain, rx_gain, rx_bw, delay,
> lo_off,seconds_in_future, rx_timeout;
>
> rx_bw = RX_BW;
> rx_gain = RX_GAIN;
> wire_format = WIRE_FORMAT;
> cpu_format = CPU_FORMAT;
> rate = SAMP_RATE;
> args = ARGS;
> ref = REF_CLOCK;
> freq = CENT_FREQ;
> tx_gain = TX_GAIN;
> // samples_per_buff = SAMPLES_PER_BUFFER;
> tx_file = TX_FILENAME;
> rx_file = RX_FILENAME;
> seconds_in_future = SYNCH_DELAY;
> rx_timeout = RX_TIMEOUT;
>
> //------------------INIT TX------------------
> //Set the scheduling priority
> on the current thread. Same as set_thread_priority but does not throw
> on failure.
> std::cout << boost::format("Creating the usrp device with: %s...")
> % args << std::endl;
> uhd::usrp::multi_usrp::sptr usrp =
> uhd::usrp::multi_usrp::make(args); //Make the usrp by calling
> the constructor with param the args
>
> usrp->set_clock_source(ref);
> //Set the clock source for the usrp device. This sets the source
> for a 10 MHz reference clock. Typical options for source: internal,
> external, MIMO.
> std::cout << boost::format("Setting TX Rate: %f Msps...") %
> (rate/1e6) << std::endl;
> usrp->set_tx_rate(rate);
> //Set the sample rate
> std::cout << boost::format("Actual TX Rate: %f Msps...") %
> (usrp->get_tx_rate()/1e6) << std::endl << std::endl;
>
> std::cout << boost::format("Setting TX Freq: %f MHz...") %
> (freq/1e6) << std::endl; //Set up tuning
> frequency
> uhd::tune_request_t tune_request;
> tune_request = uhd::tune_request_t(freq);
> //Generate the tune request
> usrp->set_tx_freq(tune_request);
> //Tune to CENT_FREQ
> std::cout << boost::format("Actual TX Freq: %f MHz...") %
> (usrp->get_tx_freq()/1e6) << std::endl << std::endl; //PRINT Actual
> CENT_FREQ
>
> std::cout << boost::format("Setting TX Gain: %f dB...") % tx_gain
> << std::endl;
> usrp->set_tx_gain(tx_gain);
> //Set the tx_gain
> std::cout << boost::format("Actual TX Gain: %f dB...") %
> usrp->get_tx_gain() << std::endl << std::endl;
> //------------------CHECK STUFF------------------
> //Check Ref and LO Lock detect
> std::vector<std::string> sensor_names;
> sensor_names = usrp->get_tx_sensor_names(0);
> if (std::find(sensor_names.begin(), sensor_names.end(),
> "lo_locked") != sensor_names.end()) {
> uhd::sensor_value_t lo_locked =
> usrp->get_tx_sensor("lo_locked",0);
> std::cout << boost::format("Checking TX: %s ...") %
> lo_locked.to_pp_string() << std::endl;
> UHD_ASSERT_THROW(lo_locked.to_bool());
> }
>
>
>
>
>
> //------------------INIT RX------------------
>
> //IS THIS NECESSARY?
> //always select the subdevice first, the channel mapping affects
> the other settings
> //usrp->set_rx_subdev_spec(subdev);
>
> std::cout << boost::format("Setting RX Rate: %f Msps...") %
> (rate/1e6) << std::endl;
> usrp->set_rx_rate(rate);
> std::cout << boost::format("Actual RX Rate: %f Msps...") %
> (usrp->get_rx_rate()/1e6) << std::endl << std::endl;
>
> //set the center frequency
> std::cout << boost::format("Setting RX Freq: %f MHz...") %
> (freq/1e6) << std::endl;
> usrp->set_rx_freq(tune_request);
> std::cout << boost::format("Actual RX Freq: %f MHz...") %
> (usrp->get_rx_freq()/1e6) << std::endl << std::endl;
> std::cout << boost::format("Setting RX Gain: %f dB...") % rx_gain
> << std::endl;
> usrp->set_rx_gain(rx_gain);
> std::cout << boost::format("Actual RX Gain: %f dB...") %
> usrp->get_rx_gain() << std::endl << std::endl;
>
> boost::this_thread::sleep(boost::posix_time::seconds(1)); //allow
> 1sec setup time
> //------------------CHECK STUFF------------------
> //Always check for locked sensor
> check_locked_sensor(usrp->get_rx_sensor_names(0), "lo_locked",
> boost::bind(&uhd::usrp::multi_usrp::get_rx_sensor, usrp, _1, 0), 1);
>
> //------------------INIT FILES---------------
>
> std::ofstream outfile;
> outfile.open(rx_file.c_str(), std::ofstream::binary);
> if(!outfile.good()){
> std::cout << "OUT File error\n";
> return 0;
> }
>
> std::ifstream infile(tx_file.c_str(), std::ifstream::binary);
>
> if(!infile.good()){
> std::cout << "IN File error\n";
> return 0;
> }
>
> //------------------INIT STREAMS---------------
>
> //Stream ARGS
> uhd::stream_args_t stream_args(cpu_format, wire_format);
> //Call the constructor of the class stream_args_t and generate
> the stream_args object with inputs the cpu_format and wire_format
> (this is the format per sample)
>
> tx_stream = usrp->get_tx_stream(stream_args);
> //Generate a tx_streamer object named tx_stream using the
> usrp->get_tx_stream(stream_args). Remember, usrp is already initialized
> uhd::rx_streamer::sptr rx_stream =
> usrp->get_rx_stream(stream_args); //Generate a tx_streamer object
> named tx_stream using the usrp->get_tx_stream(stream_args). Remember,
> usrp is already initialized
>
>
>
>
> //Setup metadata
>
> //Setup tx_metadata
>
> tx_md.start_of_burst = true;
> //Set start of burst to true for the first packet in the chain. ?
> tx_md.end_of_burst = false;
>
> #define SYNCHED_TXRX 1
> //For TX
> if(SYNCHED_TXRX){
> tx_md.has_time_spec = true;
>
> }else{
> tx_md.has_time_spec = false;
> }
>
> //Setup rx_metadata
> uhd::rx_metadata_t rx_md;
>
> //Setup stream command ONLY FOR RX
> uhd::stream_cmd_t
> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
> stream_cmd.num_samps = samples_per_buff;
>
>
>
>
> //For RX
> if(SYNCHED_TXRX){
> stream_cmd.stream_now = false;
> // tx_md.time_spec = stream_cmd.time_spec;
> }else{
> stream_cmd.stream_now = true;
> stream_cmd.time_spec = uhd::time_spec_t();
> }
>
>
> if(SYNCHED_TXRX){
> //Cannt get any faster than this
> tx_md.time_spec = stream_cmd.time_spec =
> uhd::time_spec_t(seconds_in_future)+usrp->get_time_now();
> }
>
>
> //Create the buffs
> std::vector<std::complex<float> > small_rx_buff(samples_per_buff);
>
> //Fill the TX buffer
> for (int i = 0; i < samples_per_buff; ++i){
> infile.read((char*)&small_tx_buff.at
> <http://small_tx_buff.at>(i),
> small_tx_buff.size()*sizeof(std::complex<float>));
>
> }
> infile.close();
> //Close the file pointer
>
> //Issue the stream command
> rx_stream->issue_stream_cmd(stream_cmd);
>
> //Print number of maximum buffer size
> printf("MAX TX: %d\n", (int)tx_stream->get_max_num_samps());
> printf("MAX RX %d\n", (int)rx_stream->get_max_num_samps());
>
>
> size_t num_rx_samps = 0;
>
>
> boost::thread txThread(thread_startTx);
> //receivotrnsmit
> txThread.join(); //Strart the thread for tx
> (tx is f blocking)
> num_rx_samps = rx_stream->recv(&small_rx_buff.front(),
> small_rx_buff.size(), rx_md, rx_timeout, false); // Receive buffers
> containing samples described by the metadata.
>
> // num_rx_samps = rx_stream->recv(&small_rx_buff.front(),
> small_rx_buff.size(), rx_md, rx_timeout, false); // Receive buffers
> containing samples described by the metadata.
>
>
> //Wait for everything to stop
> boost::this_thread::sleep(boost::posix_time::milliseconds(2000));
>
>
> //Cleanup and print what happened
>
> usrp->issue_stream_cmd(uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS); //
> Stop the stream (not really necessary here)
>
> double rx_stamp = rx_md.time_spec.get_full_secs() +
> rx_md.time_spec.get_frac_secs();
> double tx_stamp = tx_md.time_spec.get_full_secs() +
> tx_md.time_spec.get_frac_secs();
> double t_diff = rx_stamp - tx_stamp;
>
>
> printf("RX Time stamp: %.12lf\n ?X Time stamp: %.12lf\n Diff:
> %.12lf\n",rx_stamp, tx_stamp, t_diff);
>
>
>
> switch ( rx_md.error_code ) {
>
> case uhd::rx_metadata_t::ERROR_CODE_NONE:
> printf("No error:)\n");
> break;
> case uhd::rx_metadata_t::ERROR_CODE_TIMEOUT:
> printf("MDError 2\n");
> break;
> case uhd::rx_metadata_t::ERROR_CODE_LATE_COMMAND:
> printf("MDError 3\n");
> break;
> case uhd::rx_metadata_t::ERROR_CODE_BROKEN_CHAIN:
> printf("MDError 4\n");
> break;
> case uhd::rx_metadata_t::ERROR_CODE_OVERFLOW:
> printf("MDError 5\n");
> break;
> case uhd::rx_metadata_t::ERROR_CODE_ALIGNMENT:
> printf("MDError 6\n");
> break;
> case uhd::rx_metadata_t::ERROR_CODE_BAD_PACKET:
> printf("MDError 7\n");
> break;
>
> default:
> printf("WUT\n");
> break;
>
> }
>
> //write the samples
> if (outfile.is_open()){
> outfile.write((const char*)&small_rx_buff.front(),
> num_rx_samps*sizeof(std::complex<float>));
> }
>
>
>
> outfile.close();
> //Close the file pointer
>
>
>
> //print
> std::cout << "Transmitted samples: " << num_tx_samps << '\n';
> std::cout << "Received samples: " << num_rx_samps << '\n';
>
>
>
>
> return EXIT_SUCCESS;
> }
>
>
>
>
>
>
>
>
>
> On Mon, Oct 27, 2014 at 5:47 PM, Eleftherios(Lef) Kampianakis
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hello forum,
>
> I have a project for which it is crucial to have minimal or none
> time delay between the transmitter and receiver. For my purposes I
> utilize a B210 and use only the TX/RX for transmit and RX for receive.
>
> I have developed (following the advice of Stephen Graham) the
> following code that attaches a the transmit function to a thread
> in order to execute tx and rx concurrently (tx is blocking). For
> now, the TX/RX and RX channels are connected with coax cable to
> avoid random phase introduction from the wireless channel. I
> transmit and receive samples concurrently and calculate the time
> difference using tx_metadata.time_spec and rx_metadata.time_spec.
> However, when I apply a shift at the samples that I receive
> according to this time delay (N_samples_to_shift = F_sampling *
> T_delay) the signals still wont align and I still get a random
> time delay everytime I execute the UHD code.
>
> Could someone inform me if what I am trying to do here is even
> remotely possible with the B210? Should I use another platform or
> should I implement some kind of workaround?
>
> Thank you in advance
>
> CODE:
> //Author Eleftherios(Lef) Kampianakis
>
> //V0: Tx Rx wokrking but not synched
> //V1: effort for synching (failed)
> //V2: used threads to start tx asynch
>
> #include <uhd/types/tune_request.hpp>
> #include <uhd/utils/thread_priority.hpp>
> #include <uhd/utils/safe_main.hpp>
> #include <uhd/usrp/multi_usrp.hpp>
> #include <boost/program_options.hpp>
> #include <boost/format.hpp>
> #include <boost/thread.hpp>
> #include <iostream>
> #include <fstream>
> #include <complex>
> #include <csignal>
>
> //------------------MACROS------------------
> #define DEB(x) std::cout << "DEB:" << x << std::endl
>
>
> //------------------SETUP------------------
>
> //Assign the namespace po from boost::program_options
> //This is done to work with the terminal inputs cause
> boost::program_options
> // Question: why use namespace instead of .hpp
> namespace po = boost::program_options;
>
>
>
> #define CPU_FORMAT "fc32"
> #define WIRE_FORMAT "sc16"
> #define REF_CLOCK "internal"
> #define SAMP_RATE 200e3
> #define CENT_FREQ 915e6
> #define TX_GAIN 10 //dB
> #define RX_GAIN 10 //dB
> #define SAMPLES_PER_BUFFER 1000
> #define ARGS ""
> #define TX_FILENAME
>
> "/Users/kampianakis/Desktop/SGCC/Demos/UHD/uhd/host/build/examples/data/sin_IQ_TX"
> #define RX_FILENAME
>
> "/Users/kampianakis/Desktop/SGCC/Demos/UHD/uhd/host/build/examples/data/sin_IQ_RX"
> #define SN std::endl
> #define RX_BW SAMP_RATE/2;
> #define TX 1
> #define RX_CONT 0
> #define TOTAL_SAMPLES 1e6
> #define SYNCH_DELAY 2 //Seconds
> #define DEBUG 0
> #define RX_TIMEOUT 3
>
> //Stuff for tx asynch. Declare as global to avoid input in thread
> (chicken)
> uhd::tx_streamer::sptr tx_stream;
> uhd::tx_metadata_t tx_md;
> //TX metadata structure for describing received IF data.
> Includes time specification, and start and stop burst flags. The
> send routines will convert the metadata to IF data headers.
> size_t samples_per_buff = SAMPLES_PER_BUFFER;
> size_t num_tx_samps = 0;
> std::vector<std::complex<float> > small_tx_buff(samples_per_buff);
>
>
>
> void thread_startTx(){
> num_tx_samps = tx_stream->send(&small_tx_buff.front(),
> small_tx_buff.size(), tx_md);
> }
>
>
>
>
> typedef boost::function<uhd::sensor_value_t (const std::string&)>
> get_sensor_fn_t;
> bool check_locked_sensor(std::vector<std::string> sensor_names,
> const char* sensor_name, get_sensor_fn_t get_sensor_fn, double
> setup_time){
> if (std::find(sensor_names.begin(), sensor_names.end(),
> sensor_name) == sensor_names.end())
> return false;
>
> boost::system_time start = boost::get_system_time();
> boost::system_time first_lock_time;
>
> std::cout << boost::format("Waiting for \"%s\": ") % sensor_name;
> std::cout.flush();
>
> while (true){
> if ((not first_lock_time.is_not_a_date_time()) and
> (boost::get_system_time() > (first_lock_time +
> boost::posix_time::seconds(setup_time))))
> {
> std::cout << " locked." << std::endl;
> break;
> }
> if (get_sensor_fn(sensor_name).to_bool()){
> if (first_lock_time.is_not_a_date_time())
> first_lock_time = boost::get_system_time();
> std::cout << "+";
> std::cout.flush();
> }
> else{
> first_lock_time = boost::system_time(); //reset to
> 'not a date time'
>
> if (boost::get_system_time() > (start +
> boost::posix_time::seconds(setup_time))){
> std::cout << std::endl;
> throw std::runtime_error(str(boost::format("timed
> out waiting for consecutive locks on sensor \"%s\"") % sensor_name));
> }
> std::cout << "_";
> std::cout.flush();
> }
>
> boost::this_thread::sleep(boost::posix_time::milliseconds(100));
> }
> std::cout << std::endl;
> return true;
> }
>
>
>
> int UHD_SAFE_MAIN(int argc, char *argv[]){
> uhd::set_thread_priority_safe();
>
> std::string args, tx_file, rx_file, type, ref, wire_format,
> cpu_format;
> double rate, freq, tx_gain, rx_gain, rx_bw, delay,
> lo_off,seconds_in_future, rx_timeout;
>
> rx_bw = RX_BW;
> rx_gain = RX_GAIN;
> wire_format = WIRE_FORMAT;
> cpu_format = CPU_FORMAT;
> rate = SAMP_RATE;
> args = ARGS;
> ref = REF_CLOCK;
> freq = CENT_FREQ;
> tx_gain = TX_GAIN;
> // samples_per_buff = SAMPLES_PER_BUFFER;
> tx_file = TX_FILENAME;
> rx_file = RX_FILENAME;
> seconds_in_future = SYNCH_DELAY;
> rx_timeout = RX_TIMEOUT;
>
> //------------------INIT TX------------------
> //Set the scheduling
> priority on the current thread. Same as set_thread_priority but
> does not throw on failure.
> std::cout << boost::format("Creating the usrp device with:
> %s...") % args << std::endl;
> uhd::usrp::multi_usrp::sptr usrp =
> uhd::usrp::multi_usrp::make(args); //Make the usrp by
> calling the constructor with param the args
>
> usrp->set_clock_source(ref);
> //Set the clock source for the usrp device. This sets the
> source for a 10 MHz reference clock. Typical options for source:
> internal, external, MIMO.
> std::cout << boost::format("Setting TX Rate: %f Msps...") %
> (rate/1e6) << std::endl;
> usrp->set_tx_rate(rate);
> //Set the sample rate
> std::cout << boost::format("Actual TX Rate: %f Msps...") %
> (usrp->get_tx_rate()/1e6) << std::endl << std::endl;
>
> std::cout << boost::format("Setting TX Freq: %f MHz...") %
> (freq/1e6) << std::endl; //Set up
> tuning frequency
> uhd::tune_request_t tune_request;
> tune_request = uhd::tune_request_t(freq);
> //Generate the
> tune request
> usrp->set_tx_freq(tune_request);
> //Tune to CENT_FREQ
> std::cout << boost::format("Actual TX Freq: %f MHz...") %
> (usrp->get_tx_freq()/1e6) << std::endl << std::endl; //PRINT
> Actual CENT_FREQ
>
> std::cout << boost::format("Setting TX Gain: %f dB...") %
> tx_gain << std::endl;
> usrp->set_tx_gain(tx_gain);
> //Set the tx_gain
> std::cout << boost::format("Actual TX Gain: %f dB...") %
> usrp->get_tx_gain() << std::endl << std::endl;
> //------------------CHECK STUFF------------------
> //Check Ref and LO Lock detect
> std::vector<std::string> sensor_names;
> sensor_names = usrp->get_tx_sensor_names(0);
> if (std::find(sensor_names.begin(), sensor_names.end(),
> "lo_locked") != sensor_names.end()) {
> uhd::sensor_value_t lo_locked =
> usrp->get_tx_sensor("lo_locked",0);
> std::cout << boost::format("Checking TX: %s ...") %
> lo_locked.to_pp_string() << std::endl;
> UHD_ASSERT_THROW(lo_locked.to_bool());
> }
>
>
>
>
>
> //------------------INIT RX------------------
>
> //IS THIS NECESSARY?
> //always select the subdevice first, the channel mapping
> affects the other settings
> //usrp->set_rx_subdev_spec(subdev);
>
> std::cout << boost::format("Setting RX Rate: %f Msps...") %
> (rate/1e6) << std::endl;
> usrp->set_rx_rate(rate);
> std::cout << boost::format("Actual RX Rate: %f Msps...") %
> (usrp->get_rx_rate()/1e6) << std::endl << std::endl;
>
> //set the center frequency
> std::cout << boost::format("Setting RX Freq: %f MHz...") %
> (freq/1e6) << std::endl;
> usrp->set_rx_freq(tune_request);
> std::cout << boost::format("Actual RX Freq: %f MHz...") %
> (usrp->get_rx_freq()/1e6) << std::endl << std::endl;
> std::cout << boost::format("Setting RX Gain: %f dB...") %
> rx_gain << std::endl;
> usrp->set_rx_gain(rx_gain);
> std::cout << boost::format("Actual RX Gain: %f dB...") %
> usrp->get_rx_gain() << std::endl << std::endl;
>
> boost::this_thread::sleep(boost::posix_time::seconds(1));
> //allow 1sec setup time
> //------------------CHECK STUFF------------------
> //Always check for locked sensor
> check_locked_sensor(usrp->get_rx_sensor_names(0), "lo_locked",
> boost::bind(&uhd::usrp::multi_usrp::get_rx_sensor, usrp, _1, 0), 1);
>
> //------------------INIT FILES---------------
>
> std::ofstream outfile;
> outfile.open(rx_file.c_str(), std::ofstream::binary);
> if(!outfile.good()){
> std::cout << "OUT File error\n";
> return 0;
> }
>
> std::ifstream infile(tx_file.c_str(), std::ifstream::binary);
>
> if(!infile.good()){
> std::cout << "IN File error\n";
> return 0;
> }
>
> //------------------INIT STREAMS---------------
>
> //Stream ARGS
> uhd::stream_args_t stream_args(cpu_format, wire_format);
> //Call the constructor of the class stream_args_t and
> generate the stream_args object with inputs the cpu_format and
> wire_format (this is the format per sample)
>
> tx_stream = usrp->get_tx_stream(stream_args);
> //Generate a tx_streamer object named tx_stream using
> the usrp->get_tx_stream(stream_args). Remember, usrp is already
> initialized
> uhd::rx_streamer::sptr rx_stream =
> usrp->get_rx_stream(stream_args); //Generate a tx_streamer
> object named tx_stream using the usrp->get_tx_stream(stream_args).
> Remember, usrp is already initialized
>
>
>
>
> //Setup metadata
>
> //Setup tx_metadata
>
> tx_md.start_of_burst = true;
> //Set start of burst to true for the first packet in
> the chain. ?
> tx_md.end_of_burst = false;
>
> #define TIMED_TX 0
> #define TIMED_RX 0
> if(TIMED_TX){
>
> tx_md.has_time_spec = true;
> tx_md.time_spec =
> uhd::time_spec_t(seconds_in_future)+usrp->get_time_now();
>
> }else{
> tx_md.has_time_spec = false;
> }
>
> //Setup rx_metadata
> uhd::rx_metadata_t rx_md;
>
> //Setup stream command ONLY FOR RX
> uhd::stream_cmd_t
> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
> stream_cmd.num_samps = samples_per_buff;
>
> if(TIMED_RX){
> stream_cmd.stream_now = false;
> stream_cmd.time_spec =
> uhd::time_spec_t(seconds_in_future)+usrp->get_time_now();
> }else{
> stream_cmd.stream_now = true;
> stream_cmd.time_spec = uhd::time_spec_t();
> }
>
>
>
>
> //Create the buffs
> std::vector<std::complex<float> > small_rx_buff(samples_per_buff);
>
> //Fill the TX buffer
> for (int i = 0; i < samples_per_buff; ++i){
> infile.read((char*)&small_tx_buff.at
> <http://small_tx_buff.at>(i),
> small_tx_buff.size()*sizeof(std::complex<float>));
>
> }
> infile.close();
> //Close the file pointer
>
> //Issue the stream command
> rx_stream->issue_stream_cmd(stream_cmd);
>
> //Print number of maximum buffer size
> printf("MAX TX: %d\n", (int)tx_stream->get_max_num_samps());
> printf("MAX RX %d\n", (int)rx_stream->get_max_num_samps());
>
>
> size_t num_rx_samps = 0;
> size_t num_tx_samps = 0;
>
>
> boost::thread txThread(thread_startTx);
> //receivotrnsmit
> num_rx_samps = rx_stream->recv(&small_rx_buff.front(),
> small_rx_buff.size(), rx_md, rx_timeout, false); // Receive
> buffers containing samples described by the metadata.
> txThread.join(); //Strart the thread
> for tx (tx is f blocking)
>
> double rx_stamp = rx_md.time_spec.get_full_secs() +
> rx_md.time_spec.get_frac_secs();
> double tx_stamp = tx_md.time_spec.get_full_secs() +
> tx_md.time_spec.get_frac_secs();
> double t_diff = rx_stamp - tx_stamp;
>
>
> printf("RX Time stamp: %.12lf\n ?X Time stamp: %.12lf\n Diff:
> %.12lf\n",rx_stamp, tx_stamp, t_diff);
>
>
>
> switch ( rx_md.error_code ) {
>
> case uhd::rx_metadata_t::ERROR_CODE_NONE:
> printf("No error:)\n");
> break;
> case uhd::rx_metadata_t::ERROR_CODE_TIMEOUT:
> printf("MDError 2\n");
> break;
> case uhd::rx_metadata_t::ERROR_CODE_LATE_COMMAND:
> printf("MDError 3\n");
> break;
> case uhd::rx_metadata_t::ERROR_CODE_BROKEN_CHAIN:
> printf("MDError 4\n");
> break;
> case uhd::rx_metadata_t::ERROR_CODE_OVERFLOW:
> printf("MDError 5\n");
> break;
> case uhd::rx_metadata_t::ERROR_CODE_ALIGNMENT:
> printf("MDError 6\n");
> break;
> case uhd::rx_metadata_t::ERROR_CODE_BAD_PACKET:
> printf("MDError 7\n");
> break;
>
> default:
> printf("WUT\n");
> break;
>
> }
>
>
>
>
>
> //write the samples
> if (outfile.is_open()){
> outfile.write((const char*)&small_rx_buff.front(),
> num_rx_samps*sizeof(std::complex<float>));
> }
>
>
>
> outfile.close();
> //Close the file pointer
>
>
>
> //print
> // std::cout << "Transmitted samples: " << num_tx_samps << '\n';
> std::cout << "Received samples: " << num_rx_samps << '\n';
>
>
>
>
> return EXIT_SUCCESS;
> }
>
>
> --
> Eleftherios(Lef) Kampianakis
> Electronics and Computer Engineer
> PHD Candidate and Researcher at Sensing Computing Communications
> Group (SGCC)
> Department of Electrical Engineering
> University of Washington
> 3927 Adams Lane, NE, Mercer Court D805B, 98105
> website: http://users.isc.tuc.gr/~ekabianakis/
> <http://users.isc.tuc.gr/%7Eekabianakis/>
> mail:[email protected]
> <mailto:mail%[email protected]>
>
>
>
>
> --
> Eleftherios(Lef) Kampianakis
> Electronics and Computer Engineer
> PHD Candidate and Researcher at Sensing Computing Communications Group
> (SGCC)
> Department of Electrical Engineering
> University of Washington
> 3927 Adams Lane, NE, Mercer Court D805B, 98105
> website: http://users.isc.tuc.gr/~ekabianakis/
> <http://users.isc.tuc.gr/%7Eekabianakis/>
> mail:[email protected] <mailto:mail%[email protected]>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141028/9cdc815c/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 29 Oct 2014 11:33:42 +0530
From: Soumen Banerjee <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Direction finding using the B210
Message-ID:
<caezf6yx4knjhuq1rpfekfq5otkrhesxlv5c5jc8cqlrx99f...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Martin,
I completely understand what you are saying. Also, thanks a lot for the
links. Any specific one among them that you would recommend for a simple
explanation of complex baseband?
In fact, I just captured 1024 samples using the rx_samples_to_file example
and got a file that is 4096 bytes long. Since the type defaults to short,
Im guessing each sample is a complex number. A cursory look at the code
seems to confirm this. Is this like A+jB where the magnitude of the complex
number is the amplitude of the received signal and the phase is given by
arctan(B/A) ?
Thanks,
Soumen
On Tue, Oct 28, 2014 at 5:21 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> On 10/28/2014 12:13 PM, Soumen Banerjee wrote:
> > Hi,
> > I do have gnuradio installed. I have been working with the uhd examples
> > in C++ though. I guess Ill follow through with the rx_multi_samples
> > example you suggested.
> >
> > Im afraid I dont completely understand your comments on baseband. If I
> > understand correctly, what you are saying is that when we set the
> > receiving center frequency on the B210, it automatically downconverts to
> > baseband (removing the 5GHz carrier). Is this correct?
>
> 'Removing the 5 GHz carrier' is a bit ambiguous, but yes.
>
> Not to sound patronizing here, but it's absolutely essential that you
> understand what you're dealing with here before you start coding. The
> concept of complex baseband is well explained in many textbooks and
> websites, a list of them can be found here:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading
>
> From your comments, it seems like you're probably on the right track
> anyway, but I seriously recommend you have a look at some of those
> ressources to make sure you're speaking the same language as the rest of
> the SDR community.
>
> Have fun,
> Martin
>
> _______________________________________________
> 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/20141029/d7014bac/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 29 Oct 2014 08:01:23 +0100
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: <[email protected]>
Cc: [email protected]
Subject: [USRP-users] Still problems with the b210...
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
despite all the new uhd releases, I still have the issue with the bigger
sampling rates. Other projects became a bit more calm now, so I want to
throw some of my time onto the problem.
To recall the story, my b210 (ur uhd) freezes USB on my virtual machine when
sampling rates exceed 8 MS/s. At 32 MS/s it is a matter of seconds to very
few minutes until the system hangs. This seems to be not the issue with
disconnecting USB any more, this problem is gone, but I have no idea if they
somehow are related.
My test scenario is uhd_fft or gqrx. Everything is always on latest release,
built from source, no precompiled binaries. The OS is Kubuntu 14.04, I can
reproduce the same behavior with Kubuntu 12.04 or 14.10, no matter if using
existing VMs or freshly installed systems.
When the freeze happens, USB connectivity seems totally gone, commands like
lsusb just hang and do not come back, and even a system shutdown does not
complete, I have to switch of the VM the hard way.
Now one could think this is a machine issue - but for sure it has to do with
uhd somehow, as Nuands BladeRF runs with 30 MS/s for hours, using the same
Cypress FX3 USB controller. The tool chain for the BladeRF is similar, gqrx,
gnuradio, gr-osmosdr, the only difference is uhd. All within the same VM.
On the same machine within the Windows host system the b210 runs for hours
at 32 MS/s. So the hardware looks OK, also do USB controllers and USB
cables. Adding an USB3 hub with external power changes nothing, neither does
using the supplied 6V power supply for the b210.
This complete USB stall looks to me like some issue on a deeper layer, in
the interaction with the OS.
Now is my knowledge of all this Linux stuff very limited, and to collect
more debug information I need one who can take me by the hand and point me
to the right direction, where to look, what to collect. I am not very
familiar with log file parsing and reading, especially the powerful looking
commandline tols for this are new to me.
Thank you very much for any input - I really would love full functionality
of my 1k$ toy :)
With best regards
Ralph.
--
Ralph A. Schmid
Mondstr. 10
90762 F?rth
+49-171-3631223
[email protected]
http://www.bclog.de/
------------------------------
Message: 16
Date: Wed, 29 Oct 2014 10:16:31 +0200
From: Craig Tong <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] ERROR_CODE_ALIGNMENT (Multi-channel
alignment failed) for 2 channel receiving with USRP2 and BasicRx
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Ok so for the record the number scaling problem I had in
rx_multi_samples was because I didn't explicitly tune channel 1 only the
default of channel 0. That now behaves as expected.
Still no joy with my own implementation though. "Multi-channel alignment
failed" I'm trying to figure out what I have done that is critically
different from the example.
On 10/28/14 18:04, Craig Tong wrote:
> Hi.
>
> I'm not sure if my original email made the list I didn't see it come
> back as a list message. If not please see below.
>
> A further update on that
>
> Investigating the rx_multi_samples is also showing some quite peculiar
> behavior.
> When I put a tone into RX-A on the daughterboard and terminate RX-B:
>
> Printing the samples for following
>
> rx_multi_samples --subdev="A:A A:B" --channels="0,1"
>
> gives me as expected: varying large values (for an 8 dBm tone) in
> channel-0 and 0s and +/-1s in channel-1
>
> but if I swap the signal to RX-B and terminate RX-A and run the same
> program
>
> I get values up to ~ +/-4 in channel-0 and values up to ~ +/-34 in
> channel 1
>
> Is this correct? I would expect just swapped channels from the first
> output
>
> Then if I now swap the subdev command to:
>
> rx_multi_samples --subdev="A:B A:A" --channels="0,1"
>
> I get as in the first scenario: varying large values (for 8 dBm tone)
> in channel-0 and 0s and +/-1s in channel 1.
>
> And swapping the RF inputs back again for this subdev gives the same
> as the second and unexpected output values.
>
> I get the feeling I am totally missing something here. Either I'm
> misunderstanding how this is supposed to work or theres a problem.
>
> I'm running UHD 3.7.2 installed out of Gentoo portage. x64 build. I
> updated the USRP2's firmware also from 3.7.2 downloaded straight from
> the website. And I see the same behavior in a 32 bit MSVC2010 Windows
> build.
>
> Again any input would be much appreciated.
>
> Kind regards.
> Craig
>
> On 10/27/14 11:04, Craig Tong wrote:
>> Hi
>>
>> I'm wondering if anyone can give me some pointers.
>>
>> I'm trying to get 2 separate channels out of a USRP2 using the
>> respective RF connectors on the BasicRx daughter board.
>>
>> Currently its returning ERROR_CODE_ALIGNMENT (Multi-channel alignment
>> failed) and I'm not getting any data out.
>>
>> The relevant lines of code are:
>>
>> m_pUSRP->set_rx_subdev_spec(uhd::usrp::subdev_spec_t("A:A A:B"));
>>
>>
>> uhd::stream_args_t oStreamArgs("sc16", "sc16"); //Use 16 bit complex
>> shorts
>>
>> std::vector<size_t> vChannelsNumbers;
>>
>> vChannelsNumbers.push_back(0);
>>
>> vChannelsNumbers.push_back(1);
>>
>> oStreamArgs.channels = vChannelsNumbers;
>>
>> m_pUSRPRxStreamer = m_pUSRP->get_rx_stream(oStreamArgs);
>>
>>
>> Then I'm also setting and checking the RTC on the USRP but I don't
>> imagine this changes anything.
>>
>> boost::posix_time::ptime oEpoch(boost::gregorian::date(1970,1,1));
>>
>> boost::posix_time::time_duration oDurationSinceEpoc =
>> boost::posix_time::microsec_clock::universal_time() - oEpoch;
>>
>> uhd::time_spec_t oTimeNow(time_t(oDurationSinceEpoc.total_seconds()),
>> long(oDurationSinceEpoc.fractional_seconds()),
>> double(boost::posix_time::time_duration::ticks_per_second()));
>>
>>
>> m_pUSRP->set_time_now(oTimeNow);
>>
>> uhd::time_spec_t oUSRPTime = m_pUSRP->get_time_now(); //Confirm time set
>>
>>
>> And the stream command
>> uhd::stream_cmd_t
>> oStreamCmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
>> oStreamCmd.stream_now = true;
>>
>> m_pUSRPRxStreamer->issue_stream_cmd(oStreamCmd);
>>
>> The recv function doesn't return any data. If I change the
>> vChannelNumber vector to contain only 0 or 1 then the code work but
>> only the first of the 2 buffers passed to recv(...) is filled as is
>> to be expected. The data rate into the PC is also half is this case
>> so is seems like data is being streamed in the 2 channel case its
>> just somehow misaligned (by timestamp?) according the UHD library.
>>
>> If anyone has any ideas I would greatly appreciate it.
>>
>> Kind regards
>> --
>> Craig Tong
>> Radar Remote Sensing Group
>> Department of Electrical Engineering
>> University of Cape Town
>
> --
> Craig Tong
> Radar Remote Sensing Group
> Department of Electrical Engineering
> University of Cape Town
--
Craig Tong
Radar Remote Sensing Group
Department of Electrical Engineering
University of Cape Town
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141029/031b96a3/attachment-0001.html>
------------------------------
Message: 17
Date: Wed, 29 Oct 2014 09:26:03 +0100
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] Direction finding using the B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 10/29/2014 07:03 AM, Soumen Banerjee wrote:
> Hi Martin,
>
> I completely understand what you are saying. Also, thanks a lot for the
> links. Any specific one among them that you would recommend for a simple
> explanation of complex baseband?
>
> In fact, I just captured 1024 samples using the rx_samples_to_file
> example and got a file that is 4096 bytes long. Since the type defaults
> to short, Im guessing each sample is a complex number. A cursory look at
> the code seems to confirm this. Is this like A+jB where the magnitude of
> the complex number is the amplitude of the received signal and the phase
> is given by arctan(B/A) ?
That's correct. rx_samples_to_file --type will allow you to select other
data types (all complex).
M
>
> Thanks,
> Soumen
>
> On Tue, Oct 28, 2014 at 5:21 PM, Martin Braun via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> On 10/28/2014 12:13 PM, Soumen Banerjee wrote:
> > Hi,
> > I do have gnuradio installed. I have been working with the uhd examples
> > in C++ though. I guess Ill follow through with the rx_multi_samples
> > example you suggested.
> >
> > Im afraid I dont completely understand your comments on baseband. If I
> > understand correctly, what you are saying is that when we set the
> > receiving center frequency on the B210, it automatically downconverts to
> > baseband (removing the 5GHz carrier). Is this correct?
>
> 'Removing the 5 GHz carrier' is a bit ambiguous, but yes.
>
> Not to sound patronizing here, but it's absolutely essential that you
> understand what you're dealing with here before you start coding. The
> concept of complex baseband is well explained in many textbooks and
> websites, a list of them can be found here:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading
>
> From your comments, it seems like you're probably on the right track
> anyway, but I seriously recommend you have a look at some of those
> ressources to make sure you're speaking the same language as the rest of
> the SDR community.
>
> Have fun,
> Martin
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
------------------------------
Message: 18
Date: Wed, 29 Oct 2014 09:31:30 +0100
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] ERROR_CODE_ALIGNMENT (Multi-channel
alignment failed) for 2 channel receiving with USRP2 and BasicRx
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
So you're saying that rx_multi_samples works, but your app doesn't,
right? One crucial difference I can see is that you're streaming
immediately. For MIMO ops, you should give the device some setup time
and stream_now=false.
Cheers,
M
On 10/29/2014 09:16 AM, Craig Tong via USRP-users wrote:
> Ok so for the record the number scaling problem I had in
> rx_multi_samples was because I didn't explicitly tune channel 1 only the
> default of channel 0. That now behaves as expected.
>
> Still no joy with my own implementation though. "Multi-channel alignment
> failed" I'm trying to figure out what I have done that is critically
> different from the example.
>
> On 10/28/14 18:04, Craig Tong wrote:
>> Hi.
>>
>> I'm not sure if my original email made the list I didn't see it come
>> back as a list message. If not please see below.
>>
>> A further update on that
>>
>> Investigating the rx_multi_samples is also showing some quite peculiar
>> behavior.
>> When I put a tone into RX-A on the daughterboard and terminate RX-B:
>>
>> Printing the samples for following
>>
>> rx_multi_samples --subdev="A:A A:B" --channels="0,1"
>>
>> gives me as expected: varying large values (for an 8 dBm tone) in
>> channel-0 and 0s and +/-1s in channel-1
>>
>> but if I swap the signal to RX-B and terminate RX-A and run the same
>> program
>>
>> I get values up to ~ +/-4 in channel-0 and values up to ~ +/-34 in
>> channel 1
>>
>> Is this correct? I would expect just swapped channels from the first
>> output
>>
>> Then if I now swap the subdev command to:
>>
>> rx_multi_samples --subdev="A:B A:A" --channels="0,1"
>>
>> I get as in the first scenario: varying large values (for 8 dBm tone)
>> in channel-0 and 0s and +/-1s in channel 1.
>>
>> And swapping the RF inputs back again for this subdev gives the same
>> as the second and unexpected output values.
>>
>> I get the feeling I am totally missing something here. Either I'm
>> misunderstanding how this is supposed to work or theres a problem.
>>
>> I'm running UHD 3.7.2 installed out of Gentoo portage. x64 build. I
>> updated the USRP2's firmware also from 3.7.2 downloaded straight from
>> the website. And I see the same behavior in a 32 bit MSVC2010 Windows
>> build.
>>
>> Again any input would be much appreciated.
>>
>> Kind regards.
>> Craig
>>
>> On 10/27/14 11:04, Craig Tong wrote:
>>> Hi
>>>
>>> I'm wondering if anyone can give me some pointers.
>>>
>>> I'm trying to get 2 separate channels out of a USRP2 using the
>>> respective RF connectors on the BasicRx daughter board.
>>>
>>> Currently its returning ERROR_CODE_ALIGNMENT (Multi-channel alignment
>>> failed) and I'm not getting any data out.
>>>
>>> The relevant lines of code are:
>>>
>>> m_pUSRP->set_rx_subdev_spec(uhd::usrp::subdev_spec_t("A:A A:B"));
>>>
>>>
>>> uhd::stream_args_t oStreamArgs("sc16", "sc16"); //Use 16 bit complex
>>> shorts
>>>
>>> std::vector<size_t> vChannelsNumbers;
>>>
>>> vChannelsNumbers.push_back(0);
>>>
>>> vChannelsNumbers.push_back(1);
>>>
>>> oStreamArgs.channels = vChannelsNumbers;
>>>
>>> m_pUSRPRxStreamer = m_pUSRP->get_rx_stream(oStreamArgs);
>>>
>>>
>>> Then I'm also setting and checking the RTC on the USRP but I don't
>>> imagine this changes anything.
>>>
>>> boost::posix_time::ptime oEpoch(boost::gregorian::date(1970,1,1));
>>>
>>> boost::posix_time::time_duration oDurationSinceEpoc =
>>> boost::posix_time::microsec_clock::universal_time() - oEpoch;
>>>
>>> uhd::time_spec_t oTimeNow(time_t(oDurationSinceEpoc.total_seconds()),
>>> long(oDurationSinceEpoc.fractional_seconds()),
>>> double(boost::posix_time::time_duration::ticks_per_second()));
>>>
>>>
>>> m_pUSRP->set_time_now(oTimeNow);
>>>
>>> uhd::time_spec_t oUSRPTime = m_pUSRP->get_time_now(); //Confirm time set
>>>
>>>
>>> And the stream command
>>> uhd::stream_cmd_t
>>> oStreamCmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
>>> oStreamCmd.stream_now = true;
>>>
>>> m_pUSRPRxStreamer->issue_stream_cmd(oStreamCmd);
>>>
>>> The recv function doesn't return any data. If I change the
>>> vChannelNumber vector to contain only 0 or 1 then the code work but
>>> only the first of the 2 buffers passed to recv(...) is filled as is
>>> to be expected. The data rate into the PC is also half is this case
>>> so is seems like data is being streamed in the 2 channel case its
>>> just somehow misaligned (by timestamp?) according the UHD library.
>>>
>>> If anyone has any ideas I would greatly appreciate it.
>>>
>>> Kind regards
>>> --
>>> Craig Tong
>>> Radar Remote Sensing Group
>>> Department of Electrical Engineering
>>> University of Cape Town
>>
>> --
>> Craig Tong
>> Radar Remote Sensing Group
>> Department of Electrical Engineering
>> University of Cape Town
>
> --
> Craig Tong
> Radar Remote Sensing Group
> Department of Electrical Engineering
> University of Cape Town
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 19
Date: Wed, 29 Oct 2014 16:43:04 +0300
From: Muhammad Hadi <[email protected]>
To: [email protected]
Subject: [USRP-users] LabView support for USRP-X310
Message-ID:
<camwjmbvdo4goafj2xvwxt5pb0lgj+m_q8tmtr5uaye0rhzk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
We intend to work with USRP-X310 transceiver system using WBX-120 or
CBX-120 daughterboards.
Couple of inquiries ragarding this.
1) Is the UHD driver for X310 sopported in the LabView environment? Also
can we use LabView FPGA module to program the FPGA in USRP-X310?
2) Is there a standard method to calibrate the USRP-X310 hardware in order
to ensure the measurement accuracy as well as
minimize the IQ imbalance, DC offset etc. We do have all sorts of
measurement equipments in our lab.
Thanks
Muhammad Abdul Hadi
Lecturer
PSATRI, King Saud University
Saudi Arabia
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141029/a7930d33/attachment-0001.html>
------------------------------
Message: 20
Date: Wed, 29 Oct 2014 15:12:43 +0000
From: "Nowlan, Sean" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Direction finding using the B210
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
On 10/29/2014 07:03 AM, Soumen Banerjee wrote:
> Hi Martin,
>
> I completely understand what you are saying. Also, thanks a lot for
> the links. Any specific one among them that you would recommend for a
> simple explanation of complex baseband?
>
This is a fantastic write-up about quadrature (complex) signals by Richard
Lyons. [1]
[1] http://www.dspguru.com/sites/dspguru/files/QuadSignals.pdf
------------------------------
Message: 21
Date: Wed, 29 Oct 2014 08:28:41 -0700
From: Neel Pandeya <[email protected]>
To: "Ralph A. Schmid, dk5ras" <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Still problems with the b210...
Message-ID:
<CACaXmv-BeFyXhDT_qwMuVc_9eGTbxUyyVw=2shydiigy3h1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Ralph:
Are you running with UHD 3.8.0? There were changes made recently that
should address these issues. Please let us know which UHD release you're
using.
Is your B210 being powered from the AC wall power brick, or from the USB
bus?
Which USB controller do you have? What is the output of "lspci"?
--Neel
On Wed, Oct 29, 2014 at 12:01 AM, Ralph A. Schmid, dk5ras via USRP-users <
[email protected]> wrote:
> Hi,
>
> despite all the new uhd releases, I still have the issue with the bigger
> sampling rates. Other projects became a bit more calm now, so I want to
> throw some of my time onto the problem.
>
> To recall the story, my b210 (ur uhd) freezes USB on my virtual machine
> when
> sampling rates exceed 8 MS/s. At 32 MS/s it is a matter of seconds to very
> few minutes until the system hangs. This seems to be not the issue with
> disconnecting USB any more, this problem is gone, but I have no idea if
> they
> somehow are related.
>
> My test scenario is uhd_fft or gqrx. Everything is always on latest
> release,
> built from source, no precompiled binaries. The OS is Kubuntu 14.04, I can
> reproduce the same behavior with Kubuntu 12.04 or 14.10, no matter if using
> existing VMs or freshly installed systems.
>
> When the freeze happens, USB connectivity seems totally gone, commands like
> lsusb just hang and do not come back, and even a system shutdown does not
> complete, I have to switch of the VM the hard way.
>
> Now one could think this is a machine issue - but for sure it has to do
> with
> uhd somehow, as Nuands BladeRF runs with 30 MS/s for hours, using the same
> Cypress FX3 USB controller. The tool chain for the BladeRF is similar,
> gqrx,
> gnuradio, gr-osmosdr, the only difference is uhd. All within the same VM.
>
> On the same machine within the Windows host system the b210 runs for hours
> at 32 MS/s. So the hardware looks OK, also do USB controllers and USB
> cables. Adding an USB3 hub with external power changes nothing, neither
> does
> using the supplied 6V power supply for the b210.
>
> This complete USB stall looks to me like some issue on a deeper layer, in
> the interaction with the OS.
>
> Now is my knowledge of all this Linux stuff very limited, and to collect
> more debug information I need one who can take me by the hand and point me
> to the right direction, where to look, what to collect. I am not very
> familiar with log file parsing and reading, especially the powerful looking
> commandline tols for this are new to me.
>
> Thank you very much for any input - I really would love full functionality
> of my 1k$ toy :)
>
> With best regards
>
> Ralph.
>
>
> --
>
> Ralph A. Schmid
> Mondstr. 10
> 90762 F?rth
> +49-171-3631223
> [email protected]
> http://www.bclog.de/
>
>
>
> _______________________________________________
> 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/20141029/e1f671fd/attachment-0001.html>
------------------------------
Message: 22
Date: Wed, 29 Oct 2014 17:34:29 +0200
From: Nir Eden <[email protected]>
To: [email protected]
Subject: [USRP-users] Processing time between successive
uhd::rx_streamer::recv
Message-ID:
<CAP4_4=cvpioxu5ye7worgqzwllndqhqxv69mqxb86f0eoqk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I'm using B200.
uhd::rx_streamer::recv is blocking function. From my observations, its
return time is depended on the sample rate. Calculating the time needed for
nsamps_per_buff to be transmitted is good approximation for the blocking
time. What is the data buffering mechanism (from ADC to &buffs) and what is
the maximum delay time between two successive calls for
uhd::rx_streamer::recv?
Best regards,
Nir Eden, 4Z7DEF
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141029/9a36f7eb/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 50, Issue 29
******************************************
