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. ERROR_CODE_ALIGNMENT (Multi-channel alignment failed) for 2
channel receiving with USRP2 and BasicRx (Craig Tong)
2. UHD utilities (Stephen Bell)
3. How to load firmware to X310? (=?utf-8?B?WS5MaXU=?=)
4. Re: USRP2 Antenna for 2.4GHz-2.5GHz (David)
5. GPIO (Daly, Michael P CIV SPAWARSYSCEN-PACIFIC, 52250)
6. Re: problem with USRP example on X310 with CBX-120 (Michael West)
7. Re: How to load firmware to X310? (Michael West)
8. Re: UHD utilities (Marcus M?ller)
9. Usrper Program (Will Lunden)
10. Re: Usrper Program (Martin Braun)
11. Re: How to load firmware to X310? (Martin Braun)
12. Re: B200 - Spurs at the frequency domain (Michael West)
13. Re: Usrper Program (Will Lunden)
14. Re: problem with USRP example on X310 with CBX-120 (Jim Hunziker)
15. Synched TX/RX on B210 NOT POSSIBLE????
(Eleftherios(Lef) Kampianakis)
16. Re: Synched TX/RX on B210 NOT POSSIBLE???? (Marcus D. Leech)
17. Re: Synched TX/RX on B210 NOT POSSIBLE???? (Michael West)
18. Re: Synched TX/RX on B210 NOT POSSIBLE???? (Marcus D. Leech)
19. Toggling GPIO's from USRP FPGA (Anum Sheraz)
20. Re: USRP2 Antenna for 2.4GHz-2.5GHz (Roland Awusie)
21. Re: Toggling GPIO's from USRP FPGA (Ian Buckley)
22. Buying antennae and RF Cable for USRP B210 (Soumen Banerjee)
23. Re: How to load firmware to X310? (Martin Braun)
24. Re: Buying antennae and RF Cable for USRP B210 (Marcus M?ller)
25. Re: Buying antennae and RF Cable for USRP B210 (Martin Braun)
26. Re: X310 MTU frame size issue (Martin Braun)
27. Re: Direction finding using the B210 (Martin Braun)
28. Re: documented memory-map and streaming interfaces (Martin Braun)
29. Re: Boost Requirements (Was: 3.8.0 build issues on centos 6)
(Martin Braun)
30. Re: Direction finding using the B210 (Soumen Banerjee)
31. Re: Buying antennae and RF Cable for USRP B210 (Soumen Banerjee)
32. Re: Direction finding using the B210 (Martin Braun)
33. Re: Buying antennae and RF Cable for USRP B210 (Martin Braun)
34. CMake Error: cmake_symlink_library: System Error: Operation
not permitted (tides anugraha)
35. [UHD 3.8.0] Release Announcement (Martin Braun)
36. Images for latest master -17 do not fit? (Ralph A. Schmid, dk5ras)
37. Re: Images for latest master -17 do not fit?
(Ralph A. Schmid, dk5ras)
38. Re: CMake Error: cmake_symlink_library: System Error:
Operation not permitted (Martin Braun)
39. Re: Images for latest master -17 do not fit? (Martin Braun)
40. how to program FPGA (ETTUS B200) (massimo zampetti)
41. Re: CMake Error: cmake_symlink_library: System Error:
Operation not permitted (tides anugraha)
42. Re: CMake Error: cmake_symlink_library: System Error:
Operation not permitted (Marcus M?ller)
43. Re: CMake Error: cmake_symlink_library: System Error:
Operation not permitted (tides anugraha)
----------------------------------------------------------------------
Message: 1
Date: Mon, 27 Oct 2014 11:04:43 +0200
From: Craig Tong <[email protected]>
To: [email protected]
Subject: [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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141027/e14071e9/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 24 Oct 2014 22:27:18 +0200
From: Stephen Bell <[email protected]>
To: <[email protected]>
Subject: [USRP-users] UHD utilities
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello
I have been mucking about with the UHD utilities,
I don't seem to be able to run any of them smoothly
the only commands that I can get to work on my computer is
uhd_find_devices & uhd_usrp_probe, and only if I type them in, cannot run
the EXE file from the UHD folder,
I would like to run some of the utilities like the benchmark test and
latency test and so on,
So if there is anyone that will guide me to what this problem may be,
because I seem to have met a dead end, it will be much appreciated
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141024/6eb0e57d/attachment-0001.html>
------------------------------
Message: 3
Date: Sun, 26 Oct 2014 23:40:14 +0800
From: "=?utf-8?B?WS5MaXU=?=" <[email protected]>
To: "=?utf-8?B?dXNycC11c2Vycw==?=" <[email protected]>
Subject: [USRP-users] How to load firmware to X310?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi, everyone.
I am a new developer for this powerful X310 kit. I start to modify the firmware
provided by Ettus and successfully compile it. But I can't find any instruction
how to burn a firmware to X310. All instructions in manual are talking about
how to burn FPGA images to X310. Could someone please tell me how to burn
firmwares to X310?
Thank you in advance.
Y.Liu
XTR Solutions
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141026/8c608458/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 27 Oct 2014 07:28:07 +0000
From: David <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP2 Antenna for 2.4GHz-2.5GHz
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 27/10/2014 04:52, Roland Awusie via USRP-users wrote:
> error in bold:
> [rawusie@localhost uhd]$ ./usrp_spectrum_sense.py --args
> "addr=192.168.10.3" 25M 230M --fft 1024 > ~/home/rawusie/Desktop/log.txt
> *bash: /home/rawusie/home/rawusie/Desktop/log.txt: No such file or directory
Notice it is trying to save to /home/rawusie/home/rawusie. You probably
meant one of the following:
[ command ] > /home/rawusie/Desktop/log.txt
[ command ] > ~/Desktop/log.txt
David
------------------------------
Message: 5
Date: Mon, 27 Oct 2014 14:12:45 +0000
From: "Daly, Michael P CIV SPAWARSYSCEN-PACIFIC, 52250"
<[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] GPIO
Message-ID:
<cd184e1021cc284fb647a604ecbb4c660f98b...@nawespscxm01v.nadsuswe.nads.navy.mil>
Content-Type: text/plain; charset="iso-8859-1"
P { MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px }
We would like to write to the GPIO pins on our WBX boards. I've seen snippets
of code from about three years ago on how this is done but are there any
complete codes available so that we can try running it ourselves? Is the
GR-GPIO extension still compatible with newer USRPs?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141027/e669585e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3287 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141027/e669585e/attachment-0001.p7s>
------------------------------
Message: 6
Date: Mon, 27 Oct 2014 10:32:50 -0700
From: Michael West <[email protected]>
To: Jim Hunziker <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] problem with USRP example on X310 with
CBX-120
Message-ID:
<CAM4xKrrzKGzjH5kRNGbUJmsR2jMBdzHveEbchn2CbtAo=mm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
The patch should work for any version of UHD from 3.7.0 forward.
Michael
On Mon, Oct 27, 2014 at 7:48 AM, Jim Hunziker <[email protected]>
wrote:
> Thanks. It looks like this patch isn't against 3.7.3. We're not running
> against the master branch right now. Is this patch intended for 3.8-rc?
>
>
> --
> Jim Hunziker
> BCI Systems and Software Engineering
> (973) 348-9299
> [email protected]
>
> On Fri, Oct 24, 2014 at 5:55 PM, Michael West <[email protected]>
> wrote:
>
>> Hi Jim,
>>
>> An experimental UHD patch was sent to your colleague to address the
>> calibration issue. Please let me know if you need the patch sent to you
>> directly and I will get it to you.
>>
>> Best regards,
>> Michael
>>
>> On Thu, Oct 23, 2014 at 10:40 AM, Jim Hunziker via USRP-users <
>> [email protected]> wrote:
>>
>>> Marcus Leech responded to me off-list that I was using gain settings
>>> that were too low. Setting them to 10 greatly improved my signal, though
>>> there's still a carrier component that's bigger than my signal and not
>>> getting removed. A colleague tells me he's working with Ettus regarding
>>> this problem.
>>>
>>>
>>> --
>>> Jim Hunziker
>>> BCI Systems and Software Engineering
>>> (973) 348-9299
>>> [email protected]
>>>
>>> On Wed, Oct 22, 2014 at 4:42 PM, Jim Hunziker <[email protected]>
>>> wrote:
>>>
>>>> It looks like some of my problem was plotting abs(sig_c) rather than
>>>> real(sig_c), but the signal still doesn't look great.
>>>>
>>>>
>>>> --
>>>> Jim Hunziker
>>>> BCI Systems and Software Engineering
>>>> (973) 348-9299
>>>> [email protected]
>>>>
>>>> On Wed, Oct 22, 2014 at 12:15 PM, Jim Hunziker <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi. I have an X310 with a CBX-120 and a GPSDO, and I'm running the
>>>>> txrx_loopback_to_file example with UHD version 3.7.3 like this:
>>>>>
>>>>> ./txrx_loopback_to_file --tx-args addr=10.10.10.90 --nsamps=250000
>>>>> --tx-rate 2500000 --rx-rate 2500000 --tx-freq 56000000
>>>>> 00 --rx-freq 5600000000 --rx-ant CAL --wave-type SINE --ref internal
>>>>> --wave-freq 1000
>>>>>
>>>>> (It makes no difference if I use the RX2 antenna and a loopback cable.)
>>>>>
>>>>> With a sampling rate of 2.5 MHz and a sine wave of 1 KHz, I expect to
>>>>> see a sinusoidal cycle every 2500 samples. I'm plotting them with GNU
>>>>> Octave and the following commands:
>>>>>
>>>>> fid = fopen("~/uhd/host/build/examples/usrp_samples.dat", "rb");
>>>>> [sig, count] = fread(fid, Inf, "int16");
>>>>> sig_c = sig(1:2:end) + j * sig(2:2:end);
>>>>> plot(abs(sig_c));
>>>>>
>>>>> The signal seems very noisy, and it's pretty much gone towards the end
>>>>> of the capture. Am I doing something wrong?
>>>>>
>>>>> --
>>>>> Jim Hunziker
>>>>> BCI Systems and Software Engineering
>>>>> [email protected]
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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/20141027/23c4645f/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 27 Oct 2014 10:34:45 -0700
From: Michael West <[email protected]>
To: "Y.Liu" <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] How to load firmware to X310?
Message-ID:
<CAM4xKrrjMw2QKbKvBgb3q+=YA3+uSAo5oqwLW9ndpiTkdK=s...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Y.Liu,
The firmware is embedded in the FPGA image for the X310, so there is no
separate firmware image to load.
Regards,
Michael E. West
On Sun, Oct 26, 2014 at 8:40 AM, Y.Liu via USRP-users <
[email protected]> wrote:
> Hi, everyone.
>
> I am a new developer for this powerful X310 kit. I start to modify the
> firmware provided by Ettus and successfully compile it. But I can't find
> any instruction how to burn a firmware to X310. All instructions in manual
> are talking about how to burn FPGA images to X310. Could someone please
> tell me how to burn firmwares to X310?
>
> Thank you in advance.
>
>
>
>
>
> Y.Liu
>
> XTR Solutions
>
>
>
> _______________________________________________
> 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/20141027/4ffcdf5d/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 27 Oct 2014 18:51:09 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD utilities
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Stephen,
what does "run them smoothly" imply?
running them by double clicking should work fine, but you won't see any
of the output, which is the functional equivalent of doesn't work.
Generally, most of the utilities are command line based, and thus you'll
need to run them from the console. As a rule of thumb, running them with
--help will give you an overview of how to use them.
For example
rx_samples_to_file --help
will give you something like
-----------------------------------------------------------------
linux; GNU C++ version 4.8.3 20140911 (Red Hat 4.8.3-7); Boost_105300;
UHD_003.008.000-9-ga41527e3
UHD RX samples to file Allowed options:
--help help message
--args arg multi uhd device address args
--file arg (=usrp_samples.dat) name of the file to write binary samples to
--type arg (=short) sample type: double, float, or short
--nsamps arg (=0) total number of samples to receive
--time arg (=0) total number of seconds to receive
--spb arg (=10000) samples per buffer
--rate arg (=1000000) rate of incoming samples
--freq arg (=0) RF center frequency in Hz
--gain arg gain for the RF chain
--ant arg daughterboard antenna selection
--subdev arg daughterboard subdevice specification
--bw arg daughterboard IF filter bandwidth in Hz
--ref arg (=internal) reference source (internal, external, mimo)
--wirefmt arg (=sc16) wire format (sc8 or sc16)
--setup arg (=1) seconds of setup time
--progress periodically display short-term bandwidth
--stats show average bandwidth on exit
--sizemap track packet size and display breakdown on
exit
--null run without writing to file
--continue don't abort on a bad packet
--skip-lo skip checking LO lock status
--int-n tune USRP with integer-N tuning
-----------------------------------------------------------------
So, assuming the USRP you are using (which USRP are you using? If it is
USRP1/B100/E100/E110/USRP2/N200/N210/X300/X310: which daughterboard?)
works in the 900MHz band:
rx_samples_to_file --rate 1e6 --freq 900e6 --gain 20 --file data.uint16
--nsamps 1e7
Will record a 1 MHz bandwidth around 900MHz (==899.5MHz-900.5MHz) to the
file data.uint16, setting the rx chain gain to 20dB, and stopping after
10s (nsamps/rate).
I hope that was helpful!
Greetings,
Marcus
On 24.10.2014 22:27, Stephen Bell via USRP-users wrote:
> Hello
>
> I have been mucking about with the UHD utilities,
>
> I don't seem to be able to run any of them smoothly
>
> the only commands that I can get to work on my computer is
>
> uhd_find_devices & uhd_usrp_probe, and only if I type them in, cannot run
> the EXE file from the UHD folder,
>
> I would like to run some of the utilities like the benchmark test and
> latency test and so on,
>
> So if there is anyone that will guide me to what this problem may be,
> because I seem to have met a dead end, it will be much appreciated
>
>
>
>
>
>
> _______________________________________________
> 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/20141027/08d9e239/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 27 Oct 2014 14:02:27 -0400
From: Will Lunden <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Usrper Program
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Dear list,
I am a newcomer to the world of USRP and gnuradio, and as a first project I
have been trying to configure a USRP1 as a digital PID controller using code
developed by a former colleague. The configuration requires running the
"usrper" command, which I have seen some mention of in various how-to's, but my
installation of uhd/gnuradio doesn't seem to include this command.
I've used the package managers in Ubuntu 14 and Fedora 20 to install
uhd/gnuradio and have successfully communicated with my usrp1 in both cases,
but neither installation included the usrper command. I've also built gnuradio
from source in Ubuntu 14, but have the same problem.
Is this command no longer included in recent versions of uhd or gnuradio? Or
perhaps I'm missing something very basic?
Thanks for your time,
Will
------------------------------
Message: 10
Date: Mon, 27 Oct 2014 20:27:10 +0100
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Usrper Program
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 10/27/2014 07:02 PM, Will Lunden via USRP-users wrote:
> Is this command no longer included in recent versions of uhd or
> gnuradio? Or perhaps I'm missing something very basic?
Will,
usrper has been deprecated a long, long time ago. I would suggest
upgrading your code.
Cheers,
Martin
------------------------------
Message: 11
Date: Mon, 27 Oct 2014 20:28:38 +0100
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] How to load firmware to X310?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
If you want to update the firmware running inside the FPGA, you init
your device using the fw= command line arguments.
M
On 10/27/2014 06:34 PM, Michael West via USRP-users wrote:
> Hi Y.Liu,
>
> The firmware is embedded in the FPGA image for the X310, so there is no
> separate firmware image to load.
>
> Regards,
> Michael E. West
>
> On Sun, Oct 26, 2014 at 8:40 AM, Y.Liu via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi, everyone.
>
> I am a new developer for this powerful X310 kit. I start to modify
> the firmware provided by Ettus and successfully compile it. But I
> can't find any instruction how to burn a firmware to X310. All
> instructions in manual are talking about how to burn FPGA images to
> X310. Could someone please tell me how to burn firmwares to X310?
>
> Thank you in advance.
>
> __
>
>
>
>
>
>
>
> Y.Liu
>
> XTR Solutions
>
> __
>
> ____
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 12
Date: Mon, 27 Oct 2014 12:54:22 -0700
From: Michael West <[email protected]>
To: Daniel Malafaia <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B200 - Spurs at the frequency domain
Message-ID:
<CAM4xKrq35e6FAAS48y5+CY-9+=wmds8zc9_ugnsyvt_qtgp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Daniel,
It could be a harmonic of the master clock. The default master clock rate
is 32 MHz and 5x32=160. Try setting the master clock rate to a different
value to see if it changes.
Regards,
Michael E. West
On Sat, Oct 25, 2014 at 2:13 PM, Daniel Malafaia via USRP-users <
[email protected]> wrote:
> Hi all,
>
> I'm analyzing the B200 and I found out that the frequency response have
> some high power spurs.
> In annex I'm sending an example. In this example the data was gather at a
> Fc=161MHz, Fa=(5+1/3)MHz with a 36.5 gain and with the B200 closed at a
> Faraday cage with no external sources of noise and with the connected
> laptop covered in aluminium.
> In this situation there's a visible spur at 160MHz, does someone knows
> what the source may be?
>
> Best Regards,
> Daniel Malafaia
>
>
> _______________________________________________
> 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/20141027/60688348/attachment-0001.html>
------------------------------
Message: 13
Date: Mon, 27 Oct 2014 15:55:56 -0400
From: Will Lunden <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Usrper Program
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Dear Martin,
Thanks for clearing that up for me. The problem is, I have inherited a variety
of python programs which all want to call usrper. Is there no currently
supported command that works in a similar way?
Will
> On Oct 27, 2014, at 3:27 PM, Martin Braun via USRP-users
> <[email protected]> wrote:
>
>> On 10/27/2014 07:02 PM, Will Lunden via USRP-users wrote:
>> Is this command no longer included in recent versions of uhd or
>> gnuradio? Or perhaps I'm missing something very basic?
>
> Will,
>
> usrper has been deprecated a long, long time ago. I would suggest
> upgrading your code.
>
> Cheers,
> Martin
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 14
Date: Mon, 27 Oct 2014 16:05:37 -0400
From: Jim Hunziker <[email protected]>
To: Michael West <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] problem with USRP example on X310 with
CBX-120
Message-ID:
<CAGH06Jtd-beGoE-z8rho0YSZTzi=OhV=irdq1mwnc2cotko...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I found the problem. I had to run dos2unix on the patch first. I'll get
back to you on how it affects our tests. Thanks!
--
Jim Hunziker
BCI Systems and Software Engineering
(973) 348-9299
[email protected]
On Mon, Oct 27, 2014 at 1:32 PM, Michael West <[email protected]>
wrote:
> The patch should work for any version of UHD from 3.7.0 forward.
>
> Michael
>
> On Mon, Oct 27, 2014 at 7:48 AM, Jim Hunziker <[email protected]>
> wrote:
>
>> Thanks. It looks like this patch isn't against 3.7.3. We're not running
>> against the master branch right now. Is this patch intended for 3.8-rc?
>>
>>
>> --
>> Jim Hunziker
>> BCI Systems and Software Engineering
>> (973) 348-9299
>> [email protected]
>>
>> On Fri, Oct 24, 2014 at 5:55 PM, Michael West <[email protected]>
>> wrote:
>>
>>> Hi Jim,
>>>
>>> An experimental UHD patch was sent to your colleague to address the
>>> calibration issue. Please let me know if you need the patch sent to you
>>> directly and I will get it to you.
>>>
>>> Best regards,
>>> Michael
>>>
>>> On Thu, Oct 23, 2014 at 10:40 AM, Jim Hunziker via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Marcus Leech responded to me off-list that I was using gain settings
>>>> that were too low. Setting them to 10 greatly improved my signal, though
>>>> there's still a carrier component that's bigger than my signal and not
>>>> getting removed. A colleague tells me he's working with Ettus regarding
>>>> this problem.
>>>>
>>>>
>>>> --
>>>> Jim Hunziker
>>>> BCI Systems and Software Engineering
>>>> (973) 348-9299
>>>> [email protected]
>>>>
>>>> On Wed, Oct 22, 2014 at 4:42 PM, Jim Hunziker <[email protected]
>>>> > wrote:
>>>>
>>>>> It looks like some of my problem was plotting abs(sig_c) rather than
>>>>> real(sig_c), but the signal still doesn't look great.
>>>>>
>>>>>
>>>>> --
>>>>> Jim Hunziker
>>>>> BCI Systems and Software Engineering
>>>>> (973) 348-9299
>>>>> [email protected]
>>>>>
>>>>> On Wed, Oct 22, 2014 at 12:15 PM, Jim Hunziker <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hi. I have an X310 with a CBX-120 and a GPSDO, and I'm running the
>>>>>> txrx_loopback_to_file example with UHD version 3.7.3 like this:
>>>>>>
>>>>>> ./txrx_loopback_to_file --tx-args addr=10.10.10.90 --nsamps=250000
>>>>>> --tx-rate 2500000 --rx-rate 2500000 --tx-freq 56000000
>>>>>> 00 --rx-freq 5600000000 --rx-ant CAL --wave-type SINE --ref internal
>>>>>> --wave-freq 1000
>>>>>>
>>>>>> (It makes no difference if I use the RX2 antenna and a loopback
>>>>>> cable.)
>>>>>>
>>>>>> With a sampling rate of 2.5 MHz and a sine wave of 1 KHz, I expect to
>>>>>> see a sinusoidal cycle every 2500 samples. I'm plotting them with GNU
>>>>>> Octave and the following commands:
>>>>>>
>>>>>> fid = fopen("~/uhd/host/build/examples/usrp_samples.dat", "rb");
>>>>>> [sig, count] = fread(fid, Inf, "int16");
>>>>>> sig_c = sig(1:2:end) + j * sig(2:2:end);
>>>>>> plot(abs(sig_c));
>>>>>>
>>>>>> The signal seems very noisy, and it's pretty much gone towards the
>>>>>> end of the capture. Am I doing something wrong?
>>>>>>
>>>>>> --
>>>>>> Jim Hunziker
>>>>>> BCI Systems and Software Engineering
>>>>>> [email protected]
>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20141027/9e6be116/attachment-0001.html>
------------------------------
Message: 15
Date: Mon, 27 Oct 2014 17:47:53 -0700
From: "Eleftherios(Lef) Kampianakis" <[email protected]>
To: [email protected]
Subject: [USRP-users] Synched TX/RX on B210 NOT POSSIBLE????
Message-ID:
<cag8c0fwayrcqxn4gkdk6zjfw3z4-xf2vigzwxy2bzmcwzgz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141027/4b1b0528/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: execution1.png
Type: image/png
Size: 106112 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141027/4b1b0528/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: execution2.png
Type: image/png
Size: 108433 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141027/4b1b0528/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: synched_txrx.cpp
Type: text/x-c++src
Size: 13242 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141027/4b1b0528/attachment-0001.cpp>
------------------------------
Message: 16
Date: Mon, 27 Oct 2014 20:54:53 -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="iso-8859-1"; Format="flowed"
On 10/27/2014 08:47 PM, Eleftherios(Lef) Kampianakis via USRP-users 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?
>
OK, so, I"m not exactly clear on what you mean by "synchronized" and "at
the same time".
Clearly, if the samples are travelling through the computer up the RX
chain, into your application, and then out the TX side, there'll be some
latency.
Said latency will be unpredictable. That is unrelated to the B210
hardware, but, rather, to the entire concept of doing SDR on a host
platform with
a garden-variety OS handling the signal processing.
While sharing the code is great, sharing a *detailed* description of
what it is you're trying to accomplish, and where the shortcomings are,
from your
perspective.
> 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]>
>
>
> _______________________________________________
> 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/20141027/e3724ad0/attachment-0001.html>
------------------------------
Message: 17
Date: Mon, 27 Oct 2014 18:04:01 -0700
From: Michael West <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Synched TX/RX on B210 NOT POSSIBLE????
Message-ID:
<cam4xkrqjs6zajhfzcfoler+cpniym5zmh6f7jidde9ha2nh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I also see that you are not setting the start times on the TX and RX
streams to the same value:
tx_md.time_spec = uhd::time_spec_t(seconds_in_future)+usrp->get_time_now();
...
stream_cmd.time_spec =
uhd::time_spec_t(seconds_in_future)+usrp->get_time_now();
You should have a single value assigned to both:
uhd::time_spec_t start_time =
uhd::time_spec_t(seconds_in_future)+usrp->get_time_now();
...
tx_md_time_spec = start_time;
...
stream_cmd.time_spec = start_time;
Regards,
Michael E. West
On Mon, Oct 27, 2014 at 5:54 PM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 10/27/2014 08:47 PM, Eleftherios(Lef) Kampianakis via USRP-users
> 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?
>
> OK, so, I"m not exactly clear on what you mean by "synchronized" and
> "at the same time".
>
> Clearly, if the samples are travelling through the computer up the RX
> chain, into your application, and then out the TX side, there'll be some
> latency.
> Said latency will be unpredictable. That is unrelated to the B210
> hardware, but, rather, to the entire concept of doing SDR on a host
> platform with
> a garden-variety OS handling the signal processing.
>
> While sharing the code is great, sharing a *detailed* description of what
> it is you're trying to accomplish, and where the shortcomings are, from
> your
> perspective.
>
>
> 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]
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141027/cc849e98/attachment-0001.html>
------------------------------
Message: 18
Date: Mon, 27 Oct 2014 21:16:02 -0400
From: "Marcus D. Leech" <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[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/27/2014 09:04 PM, Michael West wrote:
> I also see that you are not setting the start times on the TX and RX
> streams to the same value:
>
> tx_md.time_spec =
> uhd::time_spec_t(seconds_in_future)+usrp->get_time_now();
> ...
> stream_cmd.time_spec =
> uhd::time_spec_t(seconds_in_future)+usrp->get_time_now();
>
> You should have a single value assigned to both:
>
> uhd::time_spec_t start_time =
> uhd::time_spec_t(seconds_in_future)+usrp->get_time_now();
> ...
> tx_md_time_spec = start_time;
> ...
> stream_cmd.time_spec = start_time;
>
> Regards,
> Michael E. West
>
Also, I should note that the TX and RX synthesizers on the B210 are
separate, and so they'll not be in the same phase-state either with each
other, or
repeatably across different sessions, even if you get the gross
sample-timing correct, if there's a requirement that TX and RX have
either zero
relative phase offset, or some predictable, fixed, phase-offset
value, the synthesizers on the AD9361 simply aren't designed for that.
In fact, it's very rare that synthesizers, in general, have predictable
phase states after tuning. So getting any two of them to agree on
phase-state,
even when using a common reference clock, is usually not possible.
There are exceptions, for example, the SBX card, when used on the N2xx,
and I believe X3xx platforms have a special "phase-resynch" feature
that is enabled through "timed commands". But this is a very-special
hardware
feature that is unusual in general-purpose synthesizers.
>
> On Mon, Oct 27, 2014 at 5:54 PM, Marcus D. Leech via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> On 10/27/2014 08:47 PM, Eleftherios(Lef) Kampianakis via
> USRP-users 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?
>>
> OK, so, I"m not exactly clear on what you mean by "synchronized"
> and "at the same time".
>
> Clearly, if the samples are travelling through the computer up the
> RX chain, into your application, and then out the TX side,
> there'll be some latency.
> Said latency will be unpredictable. That is unrelated to the
> B210 hardware, but, rather, to the entire concept of doing SDR on
> a host platform with
> a garden-variety OS handling the signal processing.
>
> While sharing the code is great, sharing a *detailed* description
> of what it is you're trying to accomplish, and where the
> shortcomings are, from your
> perspective.
>
>
>> 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]>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141027/46972234/attachment-0001.html>
------------------------------
Message: 19
Date: Tue, 28 Oct 2014 09:47:42 +0500
From: Anum Sheraz <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Toggling GPIO's from USRP FPGA
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi there,
I have configured a new custom block inside the FPGA of USRP N210. This block
contains a simple 6 bit up Counter. and i've connected the these 6bits output
to the io_tx[15:10] line on the FPGA. instead of io_tx[15:0] going directaly to
the GPIO_atr module, now its 6 bits [15:10] are connected to the counter's
output and the remaining 10 bits are not used.
I've tested the output of these Pins
on oscilloscope, but i see a strange fix pattern of sin wave. i am
expecting to see a square pulse.
My daughter board is WBX and a Simple Granddaughterboard , GPIO pins that are
available are brought out to
J15 on the GDB for WBX. I was reading the schematic of this GDB and i found
out some conditions of using these GPIO. do i need to keep the io_rx[15]=0 ?
its all going above my head. Does anyone has any idea about this ?
Any help will be highly appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141028/98de8bc6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wbx_fe.pdf
Type: application/pdf
Size: 17561 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141028/98de8bc6/attachment-0001.pdf>
------------------------------
Message: 20
Date: Mon, 27 Oct 2014 23:11:27 -0600
From: Roland Awusie <[email protected]>
To: David <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP2 Antenna for 2.4GHz-2.5GHz
Message-ID:
<cagdf4g5p-1s8gsed_fq+6hgwp04ddeluozox_rhon1vxisx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi David,
Thanks for your input. I have tried both command line input as suggested
but with no success. The code runs OK if I have not tried to save output to
a text file as in above cases.
I knew I had used similar Linux (Fedora 20) syntax in the past but could
not recollect that exact format. Please, I would be grateful for any
direction or help on this.
Thank you,
On Mon, Oct 27, 2014 at 1:28 AM, David via USRP-users <
[email protected]> wrote:
> On 27/10/2014 04:52, Roland Awusie via USRP-users wrote:
> > error in bold:
> > [rawusie@localhost uhd]$ ./usrp_spectrum_sense.py --args
> > "addr=192.168.10.3" 25M 230M --fft 1024 > ~/home/rawusie/Desktop/log.txt
> > *bash: /home/rawusie/home/rawusie/Desktop/log.txt: No such file or
> directory
>
> Notice it is trying to save to /home/rawusie/home/rawusie. You probably
> meant one of the following:
>
> [ command ] > /home/rawusie/Desktop/log.txt
>
> [ command ] > ~/Desktop/log.txt
>
> David
>
> _______________________________________________
> 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/20141027/128ef548/attachment-0001.html>
------------------------------
Message: 21
Date: Mon, 27 Oct 2014 23:13:15 -0700
From: Ian Buckley <[email protected]>
To: Anum Sheraz <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Toggling GPIO's from USRP FPGA
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
OK first off?STOP!
You can not reuse GPIO that are already being used by a daughter board, both
io_tx[14] and io_tx[15] are used by the WBX and are not available for your free
use.
Re-purposing GPIO pins that are already in use without careful consideration
risks effects on the spectrum between: unexplained behavior, through board
destruction.
If you need a bus of 6 bits then, as shown on page 5 of the WBX schematic bits
[13:8] of io_tx are UNUSED. Leave bits of GPIO used by the daughter board
connected to the GPIO_ATR modules.
(Note also that there is an error on page4 of the current WBX schematic -
io_rx[5] is unused, io_rx[15] controls RX1/RX2 selection.)
Now if what you mean by:
> but i see a strange fix pattern of sin wave.
is that you examine a single bit of GPIO and do not see clean digital edges but
instead see large rise and fall times w.r.t the expected toggle frequency then
it's likely you are toggling that signal too fast?remember these are not signal
traces optimized for the transfer of high speed bussed data.
What clock is driving your counter? Does the MSB of your counter look better
than the LSB?
The Mictor connector on the N210 motherboard is a far better choice if you need
to add a user designed high speed data interface to N210.
-Ian
On Oct 27, 2014, at 9:47 PM, Anum Sheraz via USRP-users
<[email protected]> wrote:
> Hi there,
>
> I have configured a new custom block inside the FPGA of USRP N210. This block
> contains a simple 6 bit up Counter. and i've connected the these 6bits output
> to the io_tx[15:10] line on the FPGA. instead of io_tx[15:0] going directaly
> to the GPIO_atr module, now its 6 bits [15:10] are connected to the counter's
> output and the remaining 10 bits are not used.
>
> I've tested the output of these Pins on oscilloscope, but i see a strange fix
> pattern of sin wave. i am expecting to see a square pulse.
>
> My daughter board is WBX and a Simple Granddaughterboard , GPIO pins that are
> available are brought out to J15 on the GDB for WBX. I was reading the
> schematic of this GDB and i found out some conditions of using these GPIO. do
> i need to keep the io_rx[15]=0 ?
>
> its all going above my head. Does anyone has any idea about this ?
>
> Any help will be highly appreciated.
> <wbx_fe.pdf>_______________________________________________
> 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/20141027/f134bf70/attachment-0001.html>
------------------------------
Message: 22
Date: Tue, 28 Oct 2014 12:04:46 +0530
From: Soumen Banerjee <[email protected]>
To: [email protected]
Subject: [USRP-users] Buying antennae and RF Cable for USRP B210
Message-ID:
<caezf6yyv5w8kkfnejj26vvucnomsftresvvjb0hzkthqbz3...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I have a B210 with one VERT2450 antenna. For my application, I need to have
two antennae separated by a baseline. To achieve this, I need to buy some
more antennae and some RF cable. What parameters do I need to consider when
buying these? I plan to work in the 5.7-5.8GHz ISM band.
Regards,
Soumen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141028/c267ab16/attachment-0001.html>
------------------------------
Message: 23
Date: Tue, 28 Oct 2014 10:40:50 +0100
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] How to load firmware to X310?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
On 10/28/2014 01:46 AM, Y.Liu wrote:
> Hi, Martin
>
> Could you please tell me more how to init it? Right now I only have
> usrp_x3xx_fpga_burner, but it doesn't have fw= argument...
Please ask these questions on the mailing list.
Just to make sure there is no misunderstanding: The firmware is *not*
the FPGA image (which holds the FW image inside).
You *can* update the ZPU code of a running X-Series by appending fw= to
any device args, e.g. uhd_usrp_probe --args fw=<PATH TO FW>
This is *just* for ZPU code!
Cheers,
M
------------------------------
Message: 24
Date: Tue, 28 Oct 2014 11:03:12 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Buying antennae and RF Cable for USRP B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
As the B210 only outputs about 100mW, power is not a consideration.
Other than that, you have listet all the parameters you'll have to
consider, ie. target frequency (taking into account acceptable
attenuation in the cabling) and bandwidth. That, together with SMA
connectors on the B210 end and 50Ohm impedance completely defines your
needs in cabling. As everywhere in engineering, there's a effort/cost vs
quality consideration to be made; cabling that has low attenuation up to
6GHz is a bit more costly, and it really depends on your power needs
whether you can buy the cheaper, high-attenuation cabling.
I don't know what your application looks like, so I can't really tell
you what you're looking for in an antenna. Is it directivity? Or maybe
the opposite? What about efficiency needs? Mechanical stability?
Protection against rain, storm, hail, lightning, birds, copper thieves...
Greetings,
Marcus
On 28.10.2014 07:34, Soumen Banerjee via USRP-users wrote:
> Hi,
> I have a B210 with one VERT2450 antenna. For my application, I need to have
> two antennae separated by a baseline. To achieve this, I need to buy some
> more antennae and some RF cable. What parameters do I need to consider when
> buying these? I plan to work in the 5.7-5.8GHz ISM band.
>
> Regards,
> Soumen
>
>
>
> _______________________________________________
> 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/57bcc25f/attachment-0001.html>
------------------------------
Message: 25
Date: Tue, 28 Oct 2014 11:03:28 +0100
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Buying antennae and RF Cable for USRP B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 10/28/2014 07:34 AM, Soumen Banerjee via USRP-users wrote:
> Hi,
> I have a B210 with one VERT2450 antenna. For my application, I need to
> have two antennae separated by a baseline. To achieve this, I need to
> buy some more antennae and some RF cable. What parameters do I need to
> consider when buying these? I plan to work in the 5.7-5.8GHz ISM band.
RF cables come in different quality, mainly determined by their loss.
Your antenna should obviously match your frequency range, but also
depends on which application you are developing.
Remember that the B-Series (like all our current devices) has SMA
connectors, so make sure you buy something that matches that.
Do you have a local RF guru you can ask about these things? That might
yield better results than this list, where we don't really know what you
need.
Best results!
Martin
------------------------------
Message: 26
Date: Tue, 28 Oct 2014 11:14:49 +0100
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] X310 MTU frame size issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 10/24/2014 05:55 PM, Louis Brown via USRP-users wrote:
> Now this morning, after a reboot, it's finding the correct MTU. I did
> have the address entered into the UHD source.
Are you going through a switch?
M
------------------------------
Message: 27
Date: Tue, 28 Oct 2014 11:17:08 +0100
From: Martin Braun <[email protected]>
To: [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/24/2014 08:06 AM, Soumen Banerjee via USRP-users wrote:
> Hi,
> I have setup uhd and gnuradio on my computer running Ubuntu 12.04 using
> the instructions on this page:
>
> http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_Linux
>
> I'd like to try receiving samples from both the channels and writing
> them to a file. What is the easiest way of achieving this?
Do you have GNU Radio installed? If so, that'll be the easiest way.
Otherwise, have a look at the rx_multi_samples example. It does not have
code to write to files, but you can easily add that.
> Say I have another SDR transmitting a random bitstream modulated over
> some high frequency carrier(chosen to avoid interference), do I get the
> bitstream as the samples out of the B210 or do I get samples of the
> modulated waveform. In essence, does the B210 perform some kind of
> down-conversion on the received signals?
All devices mix to baseband, most often directly (no IF). You will
receive complex baseband samples in your software.
M
------------------------------
Message: 28
Date: Tue, 28 Oct 2014 11:44:21 +0100
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] documented memory-map and streaming
interfaces
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 10/22/2014 07:02 PM, David Watt via USRP-users wrote:
> We need to run the Ettus X310 in a mode that?s quite a bit different
> than the I&Q samples to & from software mode. Our mode can?t really be
> implemented by putting a DSP block in either the Tx or Rx streaming paths.
>
> Is there a more general way to interface between software and the FPGA
> internals? There?s a wishbone bus inside ? is there a C API that can
> read/write from this directly without all the other UHD layers? Is there
> an API for uploading a stream data packet and a documented timing
> protocol on the FPGA side for how it would ingress into the FPGA? And
> vice versa for packetizing a data stream from FPGA to software? Any
> pointers are appreciated.
Hey David,
other than what we have in UHD, there's no API that we've written to
access the device.
I'd be curious what exactly it is you want to do -- maybe it *can* be
done with our existing streaming API.
Cheers,
Martin
------------------------------
Message: 29
Date: Tue, 28 Oct 2014 11:48:23 +0100
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Boost Requirements (Was: 3.8.0 build issues
on centos 6)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 10/21/2014 04:18 PM, Ben ROBERT via USRP-users wrote:
> I am trying to build UHD 3.8.0 on Ubuntu LTS 12.04 and I am facing the same
> problem with file shared_lock_guard.hpp missing.
> I have libboost-all-dev 1.48.0.2 installed. May be a higher version of boost
> library is required.
Benoit,
that was another, separate, issue where we where accidentally using
features from a a too-current UHD. This build issue is fixed on master.
M
------------------------------
Message: 30
Date: Tue, 28 Oct 2014 16:43:05 +0530
From: Soumen Banerjee <[email protected]>
To: Martin Braun <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Direction finding using the B210
Message-ID:
<caezf6ywhsg-z63c8n9uyh-gmua-ac5a6ww8a_evtba7iek+...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
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?
Regards,
Soumen
On Tue, Oct 28, 2014 at 3:47 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> On 10/24/2014 08:06 AM, Soumen Banerjee via USRP-users wrote:
> > Hi,
> > I have setup uhd and gnuradio on my computer running Ubuntu 12.04 using
> > the instructions on this page:
> >
> > http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_Linux
> >
> > I'd like to try receiving samples from both the channels and writing
> > them to a file. What is the easiest way of achieving this?
>
> Do you have GNU Radio installed? If so, that'll be the easiest way.
>
> Otherwise, have a look at the rx_multi_samples example. It does not have
> code to write to files, but you can easily add that.
>
> > Say I have another SDR transmitting a random bitstream modulated over
> > some high frequency carrier(chosen to avoid interference), do I get the
> > bitstream as the samples out of the B210 or do I get samples of the
> > modulated waveform. In essence, does the B210 perform some kind of
> > down-conversion on the received signals?
>
> All devices mix to baseband, most often directly (no IF). You will
> receive complex baseband samples in your software.
>
> M
>
>
> _______________________________________________
> 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/b4b266c7/attachment-0001.html>
------------------------------
Message: 31
Date: Tue, 28 Oct 2014 16:54:04 +0530
From: Soumen Banerjee <[email protected]>
To: Martin Braun <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Buying antennae and RF Cable for USRP B210
Message-ID:
<caezf6yy6jyzhxvwq-zxr3aaeupuyup4hkts50cs47kqgjnd...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
So in essence, for the cable, what I am looking for is something with this :
1) 50 ohm impedance
2) SMA connectors on both ends
3) Low loss near 6GHz
Have I got it covered?
Thanks,
Soumen
On Tue, Oct 28, 2014 at 3:33 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> On 10/28/2014 07:34 AM, Soumen Banerjee via USRP-users wrote:
> > Hi,
> > I have a B210 with one VERT2450 antenna. For my application, I need to
> > have two antennae separated by a baseline. To achieve this, I need to
> > buy some more antennae and some RF cable. What parameters do I need to
> > consider when buying these? I plan to work in the 5.7-5.8GHz ISM band.
>
> RF cables come in different quality, mainly determined by their loss.
> Your antenna should obviously match your frequency range, but also
> depends on which application you are developing.
> Remember that the B-Series (like all our current devices) has SMA
> connectors, so make sure you buy something that matches that.
>
> Do you have a local RF guru you can ask about these things? That might
> yield better results than this list, where we don't really know what you
> need.
>
> Best results!
>
> 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/20141028/298c9fe0/attachment-0001.html>
------------------------------
Message: 32
Date: Tue, 28 Oct 2014 12:51:11 +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/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
------------------------------
Message: 33
Date: Tue, 28 Oct 2014 12:51:37 +0100
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] Buying antennae and RF Cable for USRP B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Sounds good!
Cheers,
M
On 10/28/2014 12:24 PM, Soumen Banerjee wrote:
> Hi,
> So in essence, for the cable, what I am looking for is something with this :
> 1) 50 ohm impedance
> 2) SMA connectors on both ends
> 3) Low loss near 6GHz
>
> Have I got it covered?
>
> Thanks,
> Soumen
>
> On Tue, Oct 28, 2014 at 3:33 PM, Martin Braun via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> On 10/28/2014 07:34 AM, Soumen Banerjee via USRP-users wrote:
> > Hi,
> > I have a B210 with one VERT2450 antenna. For my application, I need to
> > have two antennae separated by a baseline. To achieve this, I need to
> > buy some more antennae and some RF cable. What parameters do I need to
> > consider when buying these? I plan to work in the 5.7-5.8GHz ISM band.
>
> RF cables come in different quality, mainly determined by their loss.
> Your antenna should obviously match your frequency range, but also
> depends on which application you are developing.
> Remember that the B-Series (like all our current devices) has SMA
> connectors, so make sure you buy something that matches that.
>
> Do you have a local RF guru you can ask about these things? That might
> yield better results than this list, where we don't really know what you
> need.
>
> Best results!
>
> Martin
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
------------------------------
Message: 34
Date: Tue, 28 Oct 2014 18:53:15 +0700
From: tides anugraha <[email protected]>
To: Ettus USRP <[email protected]>
Subject: [USRP-users] CMake Error: cmake_symlink_library: System
Error: Operation not permitted
Message-ID:
<CA+a=GO5DJF=jutpvq8gzryammub_kkgpmdu3ylk6foav9pg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi All,
I'm trying to install UHD on my beaglebone black using my sdcard,
everything seems to run normally when i run:
cmake ../ -DENABLE_MANUAL=OFF -DENABLE_DOXYGEN=OFF -DENABLE_MAN_PAGES=OFF
-DENABLE_B200=ON -DENABLE_USB=ON
the output result:
-- ######################################################
-- # UHD enabled components
-- ######################################################
-- * LibUHD
-- * Examples
-- * Utils
-- * Tests
-- * USB
-- * USRP1
-- * USRP2
-- * B100
-- * X300
-- * B200
-- * OctoClock
--
-- ######################################################
-- # UHD disabled components
-- ######################################################
-- * Manual
-- * API/Doxygen
-- * Man Pages
-- * ORC
-- * E100
-- * E300
--
-- Building version: 003.008.000-17-gfd61f0cc
-- Using install prefix: /usr/local
-- Configuring done
-- Generating done
-- Build files have been written to: /home/debian/src/uhd/host/build
And when i try to run make command, i've got the following error message at
the end of the line:
Linking CXX shared library libuhd.so
CMake Error: cmake_symlink_library: System Error: Operation not permitted
CMake Error: cmake_symlink_library: System Error: Operation not permitted
make[2]: *** [lib/libuhd.so.003.008] Error 1
make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2
make: *** [all] Error 2
Is there any clue to resolve this error message?
Thanks for the reply,
Tides
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141028/64532c92/attachment-0001.html>
------------------------------
Message: 35
Date: Tue, 28 Oct 2014 12:58:52 +0100
From: Martin Braun <[email protected]>
To: "[email protected]" <[email protected]>,
"'[email protected]'" <[email protected]>
Subject: [USRP-users] [UHD 3.8.0] Release Announcement
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hello lists,
at this point, we are releasing our UHD version 3.8.0. There were some
minor changes since the release candidate, but mainly regarding
documentation, the Boost version and minor build fixes to make sure UHD
works on all platforms.
You can get this release by either pulling master branch, or checking
out the release's tag:
https://github.com/EttusResearch/uhd/tree/release-003_008_000
If you haven't pulled master for a while, it will be a huge diff (might
take a bit, don't worry). A couple of notes on this release:
- We have reorganized the firmware and fpga subdirectories. The former
was simply moved around, but the latter is now a git submodule. Run 'git
submodule init' and 'git submodule update' if you want to read and
change the fppga source code. As a result, the source tarballs will be
much smaller.
- B200 updates: We've fixed the issue with B200 rapidly losing
connection on some devices (this particular issue never existed on
maint, but for a while it was in master). The reason was the version of
the SDK we used to compile the firmware. Altogether, B200 initialization
is now much faster.
- E310: This release includes support for our upcoming embedded device.
News on the actual device will follow in the near future, so please be
patient.
- CMake improvements: Among some fixes, we now distribute a
UHDConfig.cmake file which you can use to more easily build applications
linking to UHD. We provide an example on how to do that in
host/examples/init_usrp/.
We will be resetting maint branch to master soon. From then on, the
development will happen as usual:
- All bug fixes go into maint. This branch can be considered 'stable'.
- New features etc. go into master. This branch should be considered
'unstable'.
Binary installers will follow this week.
More features and products are coming up!
Cheers,
Martin
## Changelog for 3.8.0
* Added E310 support
* B200/B210: Moved AD9361 controls from firmware to host
* Added several tools: ZPU dissector, improved CHDR dissector,
kitchen sink, B200/B210 USB debugging utility, latency
measurement tool.
* Reorganized firmware/ directory structure. Refactored some
firmware.
* Removed FPGA sources, is now in own repository (submoduled).
* Cleaned up command line arguments for some tools
* Added math namespace, plus a unified float comparison infrastructure
* Fixed tuning-related bugs
* Moved manual over to Doxygen, also several manual bug fixes and
amendments
* Added many missing virtual destructors (less build warnings)
* Added support for NI-RIO 14.0
* X300 fixes: Not found over PCIe with no eth interfaces
* CMake improvements: Now comes with own UHDConfig.cmake and example
to build standalone UHD apps, build fixes on Apple, interoperability
with GNU Radio
* OctoClock fixes and improvements: Ethernet initialization, external
ref detection, stability fixes, host driver (UHD can now talk to
OctoClock)
* Examples: Improved GPIO example, rx_samples_to_file
* Bumped minimum Boost version to 1.46
------------------------------
Message: 36
Date: Tue, 28 Oct 2014 12:59:33 +0100
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Images for latest master -17 do not fit?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
After loading and building the last master -17, I get this one:
Error: RuntimeError: Expected firmware compatibility number 0x7, but got
0x6.0:
The firmware build is not compatible with the host code build.
Please run:
sudo "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
Loading the last images does not change anything.
Did I miss something?
With best regards
Ralph.
--
Ralph A. Schmid
Mondstr. 10
90762 F?rth
+49-171-3631223
<mailto:[email protected]> [email protected]
<http://www.bclog.de/> http://www.bclog.de/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141028/18b55426/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141028/18b55426/attachment-0001.sig>
------------------------------
Message: 37
Date: Tue, 28 Oct 2014 13:06:17 +0100
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Ralph A. Schmid, dk5ras'" <[email protected]>,
<[email protected]>
Subject: Re: [USRP-users] Images for latest master -17 do not fit?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
OK, forget about this, I rebuilt it all over again, now it works J
Ralph.
From: USRP-users [mailto:[email protected]] On Behalf Of Ralph
A. Schmid, dk5ras via USRP-users
Sent: Tuesday, October 28, 2014 13:00
To: [email protected]
Subject: [USRP-users] Images for latest master -17 do not fit?
* PGP Signed by an unmatched address: 2014-10-28 at 12:59:43
Hi,
After loading and building the last master -17, I get this one:
Error: RuntimeError: Expected firmware compatibility number 0x7, but got 0x6.0:
The firmware build is not compatible with the host code build.
Please run:
sudo "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
Loading the last images does not change anything.
Did I miss something?
With best regards
Ralph.
--
Ralph A. Schmid
Mondstr. 10
90762 F?rth
+49-171-3631223
[email protected]
http://www.bclog.de/
* Ralph A. Schmid, dk5ras <[email protected]>
* 0xA3C839C4
* PGP Unprotected
* text/plain body
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141028/f4fb70bb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141028/f4fb70bb/attachment-0001.sig>
------------------------------
Message: 38
Date: Tue, 28 Oct 2014 13:00:14 +0100
From: Martin Braun <[email protected]>
To: [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=ISO-8859-1
On 10/28/2014 12:53 PM, tides anugraha via USRP-users wrote:
> And when i try to run make command, i've got the following error message
> at the end of the line:
> Linking CXX shared library libuhd.so
> CMake Error: cmake_symlink_library: System Error: Operation not permitted
> CMake Error: cmake_symlink_library: System Error: Operation not permitted
> make[2]: *** [lib/libuhd.so.003.008] Error 1
> make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2
> make: *** [all] Error 2
>
> Is there any clue to resolve this error message?
Are you running make with the right privileges (root, sudo...)?
M
------------------------------
Message: 39
Date: Tue, 28 Oct 2014 14:02:34 +0100
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Images for latest master -17 do not fit?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
On 10/28/2014 01:06 PM, Ralph A. Schmid, dk5ras via USRP-users wrote:
> OK, forget about this, I rebuilt it all over again, now it works J
>
> Ralph.
Heh, you gave me a small heart attack there :)
M
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141028/a851066f/attachment-0001.asc>
------------------------------
Message: 40
Date: Tue, 28 Oct 2014 15:05:01 +0100
From: massimo zampetti <[email protected]>
To: [email protected]
Subject: [USRP-users] how to program FPGA (ETTUS B200)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
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
------------------------------
Message: 41
Date: Tue, 28 Oct 2014 21:25:10 +0700
From: tides anugraha <[email protected]>
To: Martin Braun <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] CMake Error: cmake_symlink_library: System
Error: Operation not permitted
Message-ID:
<CA+a=go5l7eciv-b+-t0f7qzrsy5t+vnn0o446dymuxt1kza...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Martin,
No, i'm running it as ordinary users (non root). I've also try to run make
command as root, but it still shows the same error message.
On Oct 28, 2014 7:59 PM, "Martin Braun via USRP-users" <
[email protected]> wrote:
> On 10/28/2014 12:53 PM, tides anugraha via USRP-users wrote:
> > And when i try to run make command, i've got the following error message
> > at the end of the line:
> > Linking CXX shared library libuhd.so
> > CMake Error: cmake_symlink_library: System Error: Operation not permitted
> > CMake Error: cmake_symlink_library: System Error: Operation not permitted
> > make[2]: *** [lib/libuhd.so.003.008] Error 1
> > make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2
> > make: *** [all] Error 2
> >
> > Is there any clue to resolve this error message?
>
> Are you running make with the right privileges (root, sudo...)?
>
> M
>
>
> _______________________________________________
> 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/9bf300a1/attachment-0001.html>
------------------------------
Message: 42
Date: Tue, 28 Oct 2014 15:29:43 +0100
From: Marcus M?ller <[email protected]>
To: [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=ISO-8859-1
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
------------------------------
Message: 43
Date: Tue, 28 Oct 2014 21:47:53 +0700
From: tides anugraha <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] CMake Error: cmake_symlink_library: System
Error: Operation not permitted
Message-ID:
<CA+a=GO63DvaYC=vif7AFMq_6KsMrg9OeKDcS6widXEPM=jf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141028/11b6ca92/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 28
******************************************
