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. help on exception on using the uhd.dll (iftah giladi)
2. Re: Synchronization between B210 and N210 (Linnenkamp, Nicholas)
3. Re: Could I use set_user_register function with USRP X310
(Ashish Chaudhari)
4. how to use Makefiles to construct FPGA project (Anum Sheraz)
5. Re: B210 Aliasing and Sampling Rate Precision (Ian Buckley)
----------------------------------------------------------------------
Message: 1
Date: Thu, 17 Apr 2014 19:44:45 +0300
From: "iftah giladi" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] help on exception on using the uhd.dll
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hey,
In order to start my on application code using the uhd code, I tried
creating a new blank project ,and did all
The necessary includes, and library include in the linker an compiler and so
on..
As a starter I copied the uhd_find_devices.cpp to my project lib and build
it.
It's run o.k , and then I tried to use the exe and it has this exception:
First-chance exception at 0x0f62763b in uhd_find_devices.exe: 0xC0000005:
Access violation reading location 0x02796000
The exception happens on this line:
uhd::device_addrs_t device_addrs =
uhd::device::find(vm["args"].as<std::string>());
the exception is:
First-chance exception at 0x0f62763b in uhd_find_devices.exe: 0xC0000005:
Access violation reading location 0x02796000
p.s:
maybe It will help if you'll write down the basic steps needed in order to
be able to build one of the example code on your on
Thanks,
iftah
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140417/1a2456a8/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 17 Apr 2014 17:12:46 +0000
From: "Linnenkamp, Nicholas" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Synchronization between B210 and N210
Message-ID:
<f12eb16eed10e34598b8204ce060869c0ceae...@rrc-ats-exmb2.ats.atsinnovate.com>
Content-Type: text/plain; charset="us-ascii"
Yu-Hsuan,
I think that the problem you are likely having is something that caught me
about time synchronization between devices. The following pseudocode should
help you understand the process so that you can get the procedure calls in the
right place.
On USRP1 set the clock and time source and reset the time to zero
usrp1 set_clock_source("gpsdo", 0)
usrp1 set_time_source("gpsdo", 0)
usrp1 set_time_unknown_pps(uhd.time_spec())
On USRP2 set the clock and time source and reset the time to zero
usrp2 set_clock_source("external", 0)
usrp2 set_time_source("external", 0)
usrp2 set_time_unknown_pps(uhd.time_spec())
Go to sleep for at least one second
sleep(1)
Read off the time from each device
cmd_time1 = usrp1 get_time_last_pps()
cmd_time2 = usrp2 get_time_last_pps()
Compute a time in the future
future_time1 = cmd_time1 + 1
future_time2 = cmd_time2 + 1
Set the command time on the devices to start streaming at same time
usrp1 set_command_time(future_time1)
usrp2 set_command_time(future_time2)
Set the center frequency on the devices
usrp1 set_center_freq(freq1)
usrp2 set_center_freq(freq1)
stop queuing commands on the device
usrp1 clear_command_time()
usrp2 clear_command_time()
Now all you have to do is translate that pseudo code into something that works
in the programming language you chose. The real key is to give the devices
some time to rest between setting the time on a pps signal. If you call it
too soon then it will respond with a time that is a fraction smaller than a
whole second. When I called get_time_last_pps() too early, I got something
like "2.993405928" seconds was the time it saw its last pps. After sleeping
for 1 second and making the get_time_last_pps() call again, it showed
"3.999999995" seconds as the time of the last pps. This indicates that if you
set the time and then call it immediately you can get unpredictable results.
It appears, according to your code that right at the end, you reset the time on
the devices without an appropriate wait time for them to synchronize.
Matt and Marcus are right in that because of the differences in receiver chains
you will have different delays between devices but you should at least be able
to get them very close. It shouldn't be in the millisecond range but more
microsecond/nanosecond range.
Nicholas
-----Original Message-----
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus D. Leech
Sent: Wednesday, April 16, 2014 10:39 PM
To: Yu-Hsuan Chen; [email protected]
Subject: Re: [USRP-users] Synchronization between B210 and N210
On 04/16/2014 10:29 PM, Yu-Hsuan Chen wrote:
> Hi Marcus,
>
> They share the same 10MHz refclock.
>
> I create two uhd::usrp::multi_usrp::sptr. usrp is for N210 and usrp2
> is for B210. Then, do follows.
>
> ===========================
> // setup time and clock source
> usrp->set_time_source("external");
> usrp2->set_time_source("external");
>
> usrp->set_clock_source("external");
> usrp2->set_clock_source("external");
>
> /*
> set rate and frequency
> */
>
> // synchronization
> std::cout << boost::format("Synchronizing the device time...") <<
> std::endl;
> std::cout << boost::format(" 1. catch time transition at pps
> edge") << std::endl;
> uhd::time_spec_t time_start = usrp->get_time_now();
> uhd::time_spec_t time_start_last_pps = usrp->get_time_last_pps();
> while(true){
> if (usrp->get_time_last_pps() != time_start_last_pps) break;
> if ((usrp->get_time_now() - time_start) >
> uhd::time_spec_t(1.1)){
> throw uhd::runtime_error(
> "Board 0 may not be getting a PPS signal!\n"
> "No PPS detected within the time interval.\n"
> "See the application notes for your device.\n"
> );
> }
> }
>
> std::cout << boost::format(" 2. set times next pps synchronously") <<
> std::endl;
> usrp->set_time_next_pps(uhd::time_spec_t(0.0));
> usrp2->set_time_next_pps(uhd::time_spec_t(0.0));
> ======================================
>
> After saving samples to files, I have my own code to see the time
> offset between N210 and B210.
> Basically, they share the same source of GPS signal and I check time
> synchronization by processing the signal from the same satellite.
>
> Yu-Hsuan
>
>
The internal and communicatons latencies between the two devices will be quite
different, and the exact point where sample frames are time-stamped
will be slightly different as well, although not as large as 10ms.
You'll probably find that if you actually check the timestamps in the sample
meta-data, things will be much, much, closer aligned than 10ms.
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 3
Date: Thu, 17 Apr 2014 09:46:49 -0700
From: Ashish Chaudhari <[email protected]>
To: Luong Tan Phong <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Could I use set_user_register function with
USRP X310
Message-ID:
<caozxt+dmyz7v5myjvudfokd3qubo3fwu-vdbp0ohvzxhhsr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Luong,
The USRP X310 FPGA does support user defined registers if you are planning
to modify the FPGA. There are multiple places where you can add you own
registers (to the existing set) and depending on where you do it, the
software interface will look different. A little more information about
your application will be helpful. What is your new register going to
control in the FPGA? What clock domain does it have to be in? Is it meant
for low speed or high speed control? The answers to all of these questions
will determine where your register could be placed.
Cheers,
Ashish
On Thu, Apr 17, 2014 at 12:45 AM, Luong Tan Phong <[email protected]>wrote:
> Hi list,
>
> I've bought USRP X310 and I'd like to modify FPGA source code for my
> application. I've look around the FPGA code and it seems that it don't
> support to setting user registers.
>
> Could I setting user registers on USRP X310, pls?
>
> With best regards.
>
> LTP
>
> _______________________________________________
> 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/20140417/7e1d5180/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 17 Apr 2014 07:58:31 +0100
From: Anum Sheraz <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] how to use Makefiles to construct FPGA project
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
I'm not sure whether to post this to GnuRadio or to USRP-users, so I
post it here.
We've started a project to implement a custom SDR hardware (which we
plan to open-source later) and we want to reuse as much of USRP FPGA
code as possible. But it will require a good deal of customization
aswell.I am working in the FPGA part of our GNU Radio design. I've downloaded
the USRP FPGA source code tree from the web. I was going through the
instructions in the usrp2/readme.txt , it
says:*********************************************************************************usrp2/
Description: generation 2 products
Devices: USRP2, N2XX, B100, E1XX
Tools: ISE from Xilinx, GNU make
Build Instructions:
1) ensure that xtclsh is in the $PATH
2) cd usrp2/top/<project-directory>
3) make -f Makefile.<device> bin
4) bin file in
build-<device>/*.bin*********************************************************************************
Can anyone elaborate me how do I go through these points (written under Build
instructions:) My major confusion is related to the makefiles. I've installed
Xilinx ISE 10.1 webpack, opened the windows .cmd command prompt, typed "xtclsh"
, then after that, i am totally lost !!! I've also installed GNUmake tools
"GNUWin32"(for windows), but don't know what to do with it.
Kindly help anyone ! Thanks in advance
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140417/899be49c/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 17 Apr 2014 12:31:13 -0700
From: Ian Buckley <[email protected]>
To: Sabathy Mischa <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210 Aliasing and Sampling Rate Precision
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Sabathy,
So I looked at issue #1 further. What I saw yesterday turned out to be a bug in
the new unreleased filter design specificly for the B200, the current public
B200 behaves as I expected for an interpolation ratio of 2.
When used in isolation the current 7 tap interpolation filter can only do so
much to suppress aliasing as is shown by this shot of the current 7 tap filter
overlaid on the new 47tap filter (Fs=11.52MHz for reference):
http://ianbuckley.net/hb7_vs_hb47.jpg
You'll see the new interpolation filters rolling out across B2x0 and X3x0 in
the next few weeks. Until then if the relatively poor performance of the 7tap
filter is affecting peoples applications badly, I recommend using
configurations that daisy chain the 7 tap filter with the 31 tap filter
(interpolation 4 or factorable by 4) or to interpolate by 1 (master_clock_rate
= Fs) and allow the B2x0 Radio to do all the interpolation with it's digital
filters.
-Ian
On Apr 17, 2014, at 5:30 AM, Sabathy Mischa <[email protected]> wrote:
> Hello Ian,
>
> Ok I?m glad you could reproduce it. If you need further support please let me
> know, but I have to mention that I never looked at the FPGA code.
>
> Best Regards,
> Mischa
>
> From: Ian Buckley [mailto:[email protected]]
> Sent: Donnerstag, 17. April 2014 01:02
> To: Sabathy Mischa
> Cc: [email protected]
> Subject: Re: [USRP-users] B210 Aliasing and Sampling Rate Precision
>
> Sabathy,
> I've reproduced your issue #1. I see the alias very clearly. We need to work
> out what the regression is now.
> -Ian
>
> On Apr 16, 2014, at 2:01 AM, Sabathy Mischa <[email protected]> wrote:
>
>
> Thanks for your answer Ian,
> Honestly it doesn?t look like that there is a 7 tap filter active in my
> configuration. The aliasing is not attenuated it is fully visible. The
> attenuation starts just at the end of the 30.72e6/2.
> At the moment it is simply not possible to use two channels on two different
> center frequencies using the tune_request possibility, since aliasing
> destroys everything :P
>
> Has somebody an idea about my second question?
> Thanks
>
> From: Ian Buckley [mailto:[email protected]]
> Sent: Dienstag, 15. April 2014 22:00
> To: Sabathy Mischa
> Cc: [email protected]
> Subject: Re: [USRP-users] B210 Aliasing and Sampling Rate Precision
>
> In answer to your first question, that is expected behavior, you would also
> see it if you used N210 @ 50Msps (8bit) mode. This is because there are two
> half band interpolating filters in both designs, one is 31tap, the other 7
> tap. The 7 tap design can run at 1 output sample per clock, the 31 tap at 1
> output sample for every two clocks. Thus in this configuration the only
> filter that can be used is the 7 tap, which as you might expect being so
> short is less effective at suppressing aliasing than the 31 tap. In N210 @
> 25Msps you have both of these filters cascaded with good performance.
>
> The next B2x0 UHD release will contain a new interpolation filter design that
> will greatly improve this performance. In the mean time you could reduce
> master_clock_rate to 15.36MHz so that all FPGA filters are bypassed which
> should improve your measured system performance.
>
> -Ian
>
> On Apr 15, 2014, at 7:38 AM, Sabathy Mischa <[email protected]> wrote:
>
>
>
> Dear All,
>
> I have two questions regarding the B210 performance.
>
> 1. If I use the Clock Rate 30.72e6 Hz and Sampling Rate 15.36e6 (set in GRC)
> i have aliasing effects. I think there was already a discussion about it.
> Will this be fixed soon? I pulled today the latest UHD from git and I still
> have this issue. I need to use this when I want to have two seperate channel
> on two different centre frequencies using the tune_request possibility. I
> also have aliasing issue when I only use one channel with a clock rate of
> 30.72e6 Hz and the sampling rate of 15.36e6 Hz. It seems that the lowpass
> filter is not enabled.
>
> 2. I made some tests correlating with a reference signal in the time domain.
> The B210 was set to 15.36e6 Hz clock and sampling rate. The B210 was
> configured to the centre frequency of ~1.85e9 Hz. I used a rubidium freq
> standard which is locked to a GPS 1pps as external reference (10 MHz and 1
> PPS). If I observing my interpolated correlation peak, I see a significant
> higher drift in the time domain as I am used to see when I use N210 with a
> WBX board installed (locked to the same rubidium) measuring in parallel the
> same signal. Of course the N210 was configured to 25e6 Hz sampling rate but I
> used the rational resampler in gnuradio to resample to 15.36e6 Hz.
> It seems that the sampling rate is not as precise (not 15.36e6 Hz) as in the
> N210+WBX, does anybody made a similar observations or has an idea what causes
> this error? I don't really get why this can happen on the B210 since there is
> a PLL as well :P
>
> I appreciate your comments and your help.
> Best Regards
> Mischa
> _______________________________________________
> 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/20140417/a0e64da3/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 44, Issue 18
******************************************
