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. Loading Image on E310 USRP (Amber and Sarosh)
2. Phase offset drift over time for two x310 (Damiano Scanferla)
3. Re: (no subject) (Martin Braun)
4. Re: X310 over PCIe Instability (Neel Pandeya)
5. Re: 4 Channel Synchronization with 2 X-300s (Michael West)
6. Re: Loading Image on E310 USRP (Ben Lapointe)
7. Re: Phase offset drift over time for two x310 (Rob Kossler)
8. Re: Unexpected FIFO depth (Michael West)
9. Re: Unexpected FIFO depth (Ben Hilburn)
10. Re: varying TX delay on TX/RX loopback with B210
(Jeremy Hershberger)
11. Re: varying TX delay on TX/RX loopback with B210 (Ian Buckley)
12. Re: varying TX delay on TX/RX loopback with B210
(Jeremy Hershberger)
----------------------------------------------------------------------
Message: 1
Date: Fri, 27 Mar 2015 10:58:31 +0500
From: Amber and Sarosh <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] Loading Image on E310 USRP
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Aoa,
Can someone guide us about the procedure to load image on SDcard for booting
E310 USRP?
Regards,
Amber, Sarosh & Naheed
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/dda6c03f/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 27 Mar 2015 13:58:28 +0100
From: Damiano Scanferla <[email protected]>
To: [email protected]
Subject: [USRP-users] Phase offset drift over time for two x310
Message-ID:
<cabbv7kys8rjbd4g4evarvjq-kucod2che3wlhnwnhotydwv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I would like to achieve phase alignment at two receivers being 2 SBX-120
daughter-boards of either the same X310 or belonging to 2 different X310s.
I can measure the phase offset between the two receivers and compensate for
it. The problem is that the phase offset is not constant but it is drifting
over time. Of course I can do a periodic calibration of the receivers but I
read in several blogs that the phase offset should be constant so I am
wondering what I am not doing properly in my setup.
SETUP
An RF signal at 800 MHz or 2700 MHz is generated with a signal generator
(R&S SMJ100A) and fed to 2 daughter-boards via splitter and 2 cables of the
same length. At the receiving USRPs, I just measure the phase difference
between the samples received by receiver 1 and receiver 2 (phase offset).
The USRPs get the 10 MHz ref and PPS from an OctoClock (both clock_source
and time_source set to "external", and sync set to "unknown PPS").
I have attached the "grc file" and the slope of the phase offset over 3
minutes for the following configurations:
- 800 MHz, 2 SBX-120 in 1 X310
- 800 MHz, 1 SBX-120 in 2 different X310
- 2700 MHz, 2 SBX-120 in 1 X310
- 2700 MHz, 1 SBX-120 in 2 different X310
2 observations:
- the higher the frequency, the higher the phase drift (almost linear with
frequency). So, could it be due to a phase drift of the 10 MHz reference?
- the phase drift is lower when the 2 daughter-boards belong to the same
X310.
Do you know what could be the reason for this? Have you ever seen such
behaviour?
Best regards,
Damiano
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/7de8c5a9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0.8GHz_same_USRP.png
Type: image/png
Size: 31722 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/7de8c5a9/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0.8GHz_two_USRP.png
Type: image/png
Size: 32167 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/7de8c5a9/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.7GHz_same_USRP.png
Type: image/png
Size: 33649 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/7de8c5a9/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.7GHz_two_USRP.png
Type: image/png
Size: 36012 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/7de8c5a9/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_phase_offset.grc
Type: application/octet-stream
Size: 36065 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/7de8c5a9/attachment-0001.grc>
------------------------------
Message: 3
Date: Fri, 27 Mar 2015 09:23:47 -0700
From: Martin Braun <[email protected]>
To: Anil Gaddam <[email protected]>, GNURadio Discussion List
<[email protected]>, [email protected]
Subject: Re: [USRP-users] (no subject)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 27.03.2015 07:47, Anil Gaddam via USRP-users wrote:
> If you can point me to an existing OoTM of digital encryption, it would
> be nice.
> Is it possible to encrypt digitally in some way and decrypt using
> existing blocks in gnu radio companion 3.7.6
There's no encryption inside GNU Radio. If there's encryption OOTs out
there, they're not in PyBOMBS.
M
------------------------------
Message: 4
Date: Fri, 27 Mar 2015 09:32:16 -0700
From: Neel Pandeya <[email protected]>
To: tilla <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] X310 over PCIe Instability
Message-ID:
<cacaxmv8o51unj2833xjer5xupkxywuzejegssqzn4savfbb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Tilla:
Your HP Z820 system uses an Intel X79 chipset, and our Dell Precision T3600
also uses the Intel X79 chipset. We're both now using UHD 3.8.2. We have
tested under Ubuntu 14.04 (64-bit) and also under Windows 7 (64-bit) with
no issues. So I'm at a loss to easily explain the problems that you're
seeing.
The next thing I would like to suggest is to try running with our LiveUSB
SDR image [1]. It's a live Linux image that runs from memory, like Knoppix,
and doesn't touch your hard disk, and doesn't need to be installed. It runs
directly off of the DVD or USB. I mentioned it to you in my previous email.
I would like to know if you still see the same problems under Linux, and
whether problem is related to the hardware or the
settings/configuration/drivers of the operating system. Once you're running
in the LiveUSB SDR environment, you'll need to install the RIO kernel
driver [2]. Then you can re-run your tests.
[1] http://files.ettus.com/liveusb/3.0/
[2] http://code.ettus.com/redmine/ettus/projects/uhd/wiki/NI_USRP_RIO_Linux
Could you try running with this, and let me know your results?
--Neel
On 27 March 2015 at 08:20, tilla--- via USRP-users <
[email protected]> wrote:
> Hi Neel,
>
> I can not change this system to Ubuntu or do any of the things you outline.
>
> My simple test program pseudocode that illustrates the problem is
> something like this:
>
> for( int I=0 ; I < 100 ; I++ )
> {
> usrp = uhd::multi_usrp::make( "resource=RIO0" );
>
> Sleep( 5000 );
> usrp->reset();
> Sleep (5000);
> }
>
> On 3.8.1, the loop above would never get past 10 before failing. On
> 3.8.2, it was better, but still encountered errors consistently.
>
> I am trying to get a system setup on a more available platform to help
> facilitate easier debugging, but that has been quite challenging.
>
> Also, removing one of the WBX cards (so there is now only a single card)
> did not fix the issue (something I figured I would try to see if there was
> some sort of race condition initializing both boards)...
>
> Any other suggestions to help debug this would be much appreciated.
>
> I have purchased 10 devices at 8K per device makes 80K of hardware that I
> cannot make use of... :(
>
> Thanks.
>
>
> ------------------------------
> *From: *"tilla--- via USRP-users" <[email protected]>
> *To: *"usrp-users" <[email protected]>
> *Sent: *Monday, March 16, 2015 7:12:19 PM
> *Subject: *Re: [USRP-users] X310 over PCIe Instability
>
> I have verified our chipset is C600/X79...
>
> Some more info:
>
> I upgraded to 3.8.2 and it did offer some improvements.
>
> Instead of getting 1 out of 3 failures for the 4 reasons listed
> previously, I got about 2 out of 10 failures with the radio cntrl message
> timeout failure.
>
> So there is some improvement, but still some gremlins in the mix.
>
> My X310 has 2 WBX-120 daughter cards within.
>
> Is there something else that I can do help trace this down? Only
> speculation that comes to mind is some sort of race condition initializing
> the multiple cards.
>
> My system is win7, so no chance for an lshw results...
>
> Let me know if you have any further thoughts...
> ------------------------------
> *From:* USRP-users [mailto:[email protected]] *On
> Behalf Of *Neel Pandeya via USRP-users
> *Sent:* Friday, February 27, 2015 3:55 PM
> *To:* tilla
> *Cc:* usrp-users
> *Subject:* Re: [USRP-users] X310 over PCIe Instability
>
>
>
> I looked at the specs for the HP Z820 at [1], and it looks like the Intel
> C602 system chipset is being used. I'd like to confirm the PCIe chipset.
> When you get back in the office, please run "sudo lshw -html >
> system_config.html", and post the HTML file to the mailing list.
>
> [1] http://www8.hp.com/h20195/v2/GetDocument.aspx?docname=c04111177
>
>
>
> On 27 February 2015 at 12:41, tilla <[email protected]> wrote:
>
> I am out of the office for the next week, not sure of the chipset but
> these are brand new high end HP Z820 machines.
>
>
>
> I will check as soon as I get back.
>
>
>
> Sent from my Verizon Wireless 4G LTE smartphone
>
>
>
> -------- Original message --------
>
> From: Neel Pandeya
>
> Date:02/27/2015 14:15 (GMT-05:00)
>
> To: [email protected]
>
> Cc: usrp-users ,Ashish Chaudhari
>
> Subject: Re: [USRP-users] X310 over PCIe Instability
>
>
>
> Some PCI-Express chipsets do not work as well as others. Results can vary
> between chipsets. What motherboard and PCIe chipset are you using?? Could
> you run "sudo lshw -html > system_config.html", and send the HTML file as
> an attachment to the mailing list?
>
> Here in the office, we have a system that works well with X310 over PCIe,
> with the specifications below.
>
> Dell Precision T3600
> Intel Xeon CPU E5-1650 0 @ 3.20GHz
> C600/X79 series chipset PCI Express Virtual Root Port
>
>
>
> --Neel
>
>
>
> On 25 February 2015 at 11:08, tilla--- via USRP-users <
> [email protected]> wrote:
>
> Peeps,
>
>
>
> SW Platform:
>
> UHD 3.8.1 64 bit
>
> Windows 7 64 bit
>
> VS 2013
>
>
>
> Have a gaggle of N210s and X310s. All work flawlessly over Ethernet.
>
>
>
> I have assessed going to PCIe on the X310s to lower latency of sample
> rx/tx.
>
>
>
> We never have any problems over Ethernet initializing the devices.
>
>
>
> Over PCI, the devices fail about 2 times out of 10 purely in the
> initialization phase.
>
>
>
> The equivalent code is something so simple like:
>
>
>
> uhd::usrp::multi_usrp::make( "resource=RIO0" );
>
>
>
> This fails for the following list of reasons:
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/ec008025/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 27 Mar 2015 10:39:21 -0700
From: Michael West <[email protected]>
To: Joel Bratin <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
Message-ID:
<CAM4xKrrG+2nHs9-eO0gmT+rDPgznNR6VpVfb4T=fku8iaz9...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Joel,
Yes, you can use the PPS from the N210 GPSDO even if it doesn't lock. Just
be sure to use a 0 degree splitter and matched cable lengths.
The point of the PPS is simply to create an infrequent synchronous event
that can be used to synchronize the times across the devices. The accuracy
of the PPS only matters if you need to accurately set the time on the
devices to the "real" time. Most of the time, that is not a requirement
and any arbitrary time will work as long as the two devices agree on the
time.
Regards,
Michael
On Fri, Mar 27, 2015 at 7:44 AM, Joel Bratin <[email protected]> wrote:
> Hi Michael,
>
>
>
> We didn?t realize there were two different GPSDO Kits for the N210 and the
> X300 series.
>
> We were able to synchronize multiple boxes using the GPSDO Kit for the
> N210 as an external PPS.
>
> We thought we could just stick that kit into our X300 but we realize that
> it wouldn?t work.
>
>
>
> Do you think the GPSDO Kit for the USRP N210 would be reliable as an
> external PPS? Would the PPS be suitable even if we didn?t have a GPS lock?
>
>
>
> Thanks,
>
> Joel Bratin
>
>
>
> *From:* Michael West [mailto:[email protected]]
> *Sent:* Thursday, March 26, 2015 6:31 PM
>
> *To:* Joel Bratin
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
>
>
>
> Hi Joel,
>
> The only way to guarantee synchronization across multiple X300s is to
> provide a common PPS and clock reference to all of them. The PPS out is
> significantly delayed and we do not guarantee it will be within the same 10
> MHz reference clock cycle. You can try it, but we do not guarantee it will
> work. If you do want to try it, be sure to use both the PPS and clock
> references and set the clock source and time source to "internal" on the
> master and "external" on the slave.
>
> Regards,
>
> Michael
>
>
>
> On Thu, Mar 26, 2015 at 2:49 PM, Joel Bratin <[email protected]>
> wrote:
>
> Hi Michael,
>
>
>
> Thanks for clarifying that.
>
>
>
> We are still trying to find a solution to synchronize multiple boxes with
> an ?internal? PPS.
>
> We took the PPS-Out from a GPSDO (without a GPS lock) on an NI USRP-2930
> and split it to the PPS-In on both of our X300s and successfully
> synchronized them to within 1ns.
>
>
>
> We were wondering if we added a GPSDO to one of the X300s would there be
> any way to use the PPS-out from that GPSDO to synchronize the time sources
> of both X300s? This would really help us so we don?t have to include
> another piece of hardware outside the X300.
>
> Should we expect any negative impact on our synchronization if we never
> have a GPS lock on the GPSDO?
>
>
>
> Thanks,
>
> Joel Bratin
>
>
>
> *From:* Michael West [mailto:[email protected]]
> *Sent:* Wednesday, March 25, 2015 7:27 PM
>
>
> *To:* Joel Bratin
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
>
>
>
> Hi Joel,
>
> So, here is what is going on. When using multiple X300s, they need to
> have the same time set on both. If not, there will be all kinds of timing
> issues. Supplying a common external reference and PPS and using
> set_time_unknown_pps() is the best way to synchronize the times on the
> devices.
>
> The benchmark_rate example does not do this, so the default reference and
> PPS are used and the times on the X300s are different. The RX rate test
> results in a timeout when specifying channels on the second device because
> it sets the start time for the streaming based on the time retrieved from
> the first device. You can modify the example to add lines to set the clock
> and time sources to external and call set_time_unknown_pps() and it should
> work fine.
>
> Hope this helps clear things up.
>
> Regards,
>
> Michael
>
>
>
> On Tue, Mar 24, 2015 at 2:08 PM, Joel Bratin <[email protected]>
> wrote:
>
> Hi Michael,
>
>
>
> We are using UHD 3.8.2. We tried it on Windows, Mac OS and Linux (Fedora)
> and received the same problem.
>
>
> Steps to reproduce the problem:
>
> 1. X300 #1 with IP address 192.168.40.2
>
> 2. X300 #2 with IP Address 192.168.140.2
>
> 3. Connect each X300 to its own interface on our Intel X520-DA2
>
> 4. Reboot each X300
>
> 5. Run benchmark_rate.exe --args ?addr0=192.168.140.2,
> addr1=192.168.40.2? ?rx_rate 625000 ?channels ?2,3
>
>
>
> When running we receive ERROR_CODE_TIMEOUT
>
>
>
> We managed to find a workaround but we?re not entirely sure why it works.
>
> In our own application we used *set_time_source(?external?)* and
> *set_clock_source(?external?)*. We connected an external clock and PPS to
> both X300s.
>
> We called *set_time_unknown_pps(uhd::time_spec_t(0.0))*
>
>
>
> We stopped seeing the ERROR_CODE_TIMEOUT while streaming.
>
> Furthermore, when we returned back to benchmark_rate.exe we found that we
> stopped getting the ERROR_CODE_TIMEOUT. The ERROR_CODE_TIMEOUT disappeared
> until we shut off one of the X300s and turned it back on.
>
>
>
> It seems like our application kicked the X300s into a working state but
> we?re not sure why. Do you have any idea what could?ve fixed our problem?
>
>
>
> Benchmark_rate doesn?t set the *time_*source or *?clock_*source so we
> assume it automatically uses an ?internal? *clock_source* and ?internal?
> *time_source*. Should we expect to see ERROR_CODE_TIMEOUT if we?re not
> using an external clock/PPS? Is there a command that we called that might
> be missing in benchmark_rate?
>
>
>
> Thanks,
>
> Joel Bratin
>
>
>
> *From:* Michael West [mailto:[email protected]]
> *Sent:* Tuesday, March 24, 2015 4:09 PM
>
>
> *To:* Joel Bratin
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
>
>
>
> Hi Joel,
>
>
>
> It should work the way you are using it. Can you tell me what version of
> UHD you are using so I can try to reproduce it and look into it further for
> you?
>
>
>
> Thanks,
>
> Michael
>
>
>
> On Tue, Mar 24, 2015 at 7:48 AM, Joel Bratin <[email protected]>
> wrote:
>
> Hi Michael,
>
>
>
> The two network interfaces are on different subnets and both have
> 255.255.255.0 subnet masks.
>
>
>
> I am able to stream from each channel independently so I know that I can
> connect to both X300s.
>
>
>
> I don?t understand why benchmark_rate.exe --args "addr0=192.168.140.2,
> addr1=192.168.40.2" --rx_rate 625000 --channels"0,1" works perfectly but
> benchmark_rate.exe --args "addr0=192.168.40.2, addr1=192.168.140.2"
> --rx_rate 625000 --channels"2,3" gives me the ERROR_CODE_TIMEOUT error.
>
> For some reason changing the values of addr0 and addr1 causes an issue.
>
>
>
> Does something happen in uhd that it treats the devices on addr0 and addr1
> differently? Does it matter which one I declare as addr0 and which one I
> declare as addr1?
>
>
>
> Thanks,
>
> Joel Bratin
>
>
>
> *From:* Michael West [mailto:[email protected]]
> *Sent:* Monday, March 23, 2015 5:32 PM
> *To:* Joel Bratin
> *Cc:* [email protected]
>
>
> *Subject:* Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
>
>
>
> Hi Joel,
>
> This looks like it could be a network interface configuration issue.
> Check to make sure the two network interfaces on the host computer are on
> different subnets and the subnet masks are set correctly (should be
> 255.255.255.0).
>
> Regards,
>
> Michael
>
>
>
> On Mon, Mar 23, 2015 at 1:19 PM, Joel Bratin via USRP-users <
> [email protected]> wrote:
>
> Hi,
>
> My setup from last week keeps running into the same problem.
>
> When receiving from the rx_streamer I get the ERROR_CODE_TIMEOUT error.
>
> I tried debugging my setup with benchmark_rate and noticed that I get this
> error when trying to stream from channels "2" and "3" regardless of which
> X300 was designated as the addr1.
>
> For example, the following commands lead to ERROR_CODE_TIMEOUTs.
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"0,2"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"0,3"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"1,2"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"1,3"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"1,2"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"2,3"
> benchmark_rate.exe --args "addr0=192.168.40.2, addr1=192.168.140.2"
> --rx_rate 625000 --channels"2,3" <-- notice the addr0/addr1 swap doesn't
> help
>
> The following commands are successful:
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"0"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"1"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"2"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"3"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"0,1"
> benchmark_rate.exe --args "addr0=192.168.40.2, addr1=192.168.140.2"
> --rx_rate 625000 --channels"0,1" <-- addr0/addr1 swap still works
>
> I got the same error last week and it seemed to disappear on its own but
> now it's happening again.
>
> It doesn't look like a hardware issue because the following 2 commands do
> the same thing (stream both channels on 192.168.140.2) but give the
> opposite results
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"0,1" --> works
> benchmark_rate.exe --args "addr0=192.168.40.2, addr1=192.168.140.2"
> --rx_rate 625000 --channels"2,3" --> FAILS
>
> Any insight into this problem would be greatly appreciated.
>
> Thanks,
> Joel Bratin
>
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Daniele Nicolodi via USRP-users
> Sent: Friday, March 20, 2015 1:14 PM
> To: [email protected]
> Subject: Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
>
> On 20/03/15 17:57, Marcus D. Leech via USRP-users wrote:
> > On 03/20/2015 12:51 PM, Daniele Nicolodi via USRP-users wrote:
> >> A completely different matter is the PPS generation. If you need a
> >> PPS to synchronize multiple instruments you can use a PPS generated
> >> from a whatever oscillator (and much probably you don't even need
> >> this, but simply a trigger signal).
> >>
> >> If what you need is to align a local time scale to a well known time
> >> scale, well, you need to connect to that time scale somehow. How you
> >> do that, depends on what are your synchronization requirements. A GPS
> >> receiver gives you good synchronization to the GPS time, which can be
> >> related to the UTC time (or assumed equal to the UTC time, for most
> >> applications).
> >
> > Thanks, Daniele.
> >
> > I was mostly idly curious about the existence of less-expensive
> > devices based on a 10MHz OCXO that also produce a 1PPS signal. I have a
> bunch of
> > 10MHz OCXOs myself, and while *I* could easily whip up something
> > that produces a 1PPS pulse in parallel to the 10MHz output, I was
> curious about
> > commercial "off the shelf" devices that did this, and that weren't
> > necessarily GPSDOs.
>
> I still don't understand why you need a PPS. Is it to synchronize multiple
> devices to a common time scale? If that is the case, simply generating an
> unreferenced PPS (as the one you could derive from different oscillators)
> is definitely not a solution. In this case what you need is a PPS generator
> and distributor (a device with multiple phase aligned PPS outputs). Such a
> device may or may not include an oscillator (you may need to plug an
> external one). No idea of the price range for such a device, but it is
> going to depend a lot on your accuracy and stability requirements.
>
> Cheers,
> Daniele
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/e21821e2/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 27 Mar 2015 15:15:04 -0400
From: Ben Lapointe <[email protected]>
To: Amber and Sarosh <[email protected]>
Cc: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Loading Image on E310 USRP
Message-ID:
<cackxhtegoxuwjs+3feezbbwyzinyinypnsc-iyssffhbgyl...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Last time I did this I followed [1].
The images I got from [2]
[1] https://www.parallella.org/create-sdcard/
[2] http://files.ettus.com/e3xx_images/beta/dizzy-test/
On Fri, Mar 27, 2015 at 1:58 AM, Amber and Sarosh via USRP-users <
[email protected]> wrote:
>
> Aoa,
> Can someone guide us about the procedure to load image on SDcard for
> booting E310 USRP?
>
> Regards,
> Amber, Sarosh & Naheed
>
> _______________________________________________
> 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/20150327/b1f73760/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 27 Mar 2015 16:21:24 -0400
From: Rob Kossler <[email protected]>
To: Damiano Scanferla <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Phase offset drift over time for two x310
Message-ID:
<CAB__hTSNGQWvSKuFN1KGKf8zdEMcOxJpjwPMZSSWKefA==c...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Damiano,
I am presently working with Ettus on this issue (or at least something very
similar). I attached two screen shots. The first (*17_12_04.png) is with
the original UHD code (3.8.2, I think) and the second (*17_04_40.png) is
with a patched UHD version which uses a different register value related to
the 10 MHz clock circuit. These plots were made with a 4 channel
synchronous capture (external PPS & ref). Both plots show the same thing
with relative amplitude on top and relative phase on the bottom. By
relative, I mean one channel divided by another. So each plot shows
results from comparison of two channels. The left plot shows a comparison
of channels 0 and 1 (which are within the same X310) while the right plot
shows a comparison of channels 1 and 3 (which are not within the same X310).
You can see that my plots are similar to yours. My RF was 2.412 GHz. My
data processing is likely somewhat different because I processed the data
in blocks and performed an FFT on each block and then only looked at the
FFT bin where my CW signal was. So, this is essentially a filtering
operation.
Rob Kossler
On Fri, Mar 27, 2015 at 8:58 AM, Damiano Scanferla via USRP-users <
[email protected]> wrote:
> Hi,
>
> I would like to achieve phase alignment at two receivers being 2 SBX-120
> daughter-boards of either the same X310 or belonging to 2 different X310s.
>
> I can measure the phase offset between the two receivers and compensate
> for it. The problem is that the phase offset is not constant but it is
> drifting over time. Of course I can do a periodic calibration of the
> receivers but I read in several blogs that the phase offset should be
> constant so I am wondering what I am not doing properly in my setup.
>
> SETUP
> An RF signal at 800 MHz or 2700 MHz is generated with a signal generator
> (R&S SMJ100A) and fed to 2 daughter-boards via splitter and 2 cables of the
> same length. At the receiving USRPs, I just measure the phase difference
> between the samples received by receiver 1 and receiver 2 (phase offset).
> The USRPs get the 10 MHz ref and PPS from an OctoClock (both clock_source
> and time_source set to "external", and sync set to "unknown PPS").
>
> I have attached the "grc file" and the slope of the phase offset over 3
> minutes for the following configurations:
> - 800 MHz, 2 SBX-120 in 1 X310
> - 800 MHz, 1 SBX-120 in 2 different X310
> - 2700 MHz, 2 SBX-120 in 1 X310
> - 2700 MHz, 1 SBX-120 in 2 different X310
>
> 2 observations:
> - the higher the frequency, the higher the phase drift (almost linear with
> frequency). So, could it be due to a phase drift of the 10 MHz reference?
> - the phase drift is lower when the 2 daughter-boards belong to the same
> X310.
>
> Do you know what could be the reason for this? Have you ever seen such
> behaviour?
>
> Best regards,
> Damiano
>
>
> _______________________________________________
> 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/20150327/6af81053/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2015-03-04 17_12_04.png
Type: image/png
Size: 41699 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/6af81053/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2015-03-04 17_04_40.png
Type: image/png
Size: 43134 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/6af81053/attachment-0003.png>
------------------------------
Message: 8
Date: Fri, 27 Mar 2015 13:33:13 -0700
From: Michael West <[email protected]>
To: Rob Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Unexpected FIFO depth
Message-ID:
<CAM4xKrq2=r6ae9vn22z38mc14oqe6pwu3z6k0pyqqxqn5kc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Rob,
The error is indicating that it failed to synchronize the DAC, which means
samples will not be aligned. This is due to some timing issues between the
clock supplied to the DAC and the clock supplied to the FPGA. We have made
some adjustments to the timing that made it work, but we suspected it may
not hold for all temperatures. We have an open issue to investigate it
further and we have already made some improvements that are scheduled to be
available soon.
Regards,
Michael
On Fri, Mar 27, 2015 at 6:43 AM, Rob Kossler via USRP-users <
[email protected]> wrote:
> Hi,
> I have seen the following error several times over this past week. It is
> intermittent such that if I rerun the example program immediately following
> this error it will likely run fine.
>
> Error: RuntimeError: x300_dac_ctrl: front-end sync failed. unexpected FIFO
> depth [0x7]
>
> I am running Ubuntu 14.04 LTS and using the benchmark_rate example program
> along with an X310 (SBX-40 daughterboards). The full command output is
> shown below.
>
> Any ideas?
>
> Rob
>
>
> crosshair@crosshair-HP-Z440:~$ benchmark_rate --tx_rate=100e6
> --rx_rate=100e6 --channels="0,1"
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.002-131-gb850dfb5
>
>
> Creating the usrp device with: ...
> -- X300 initialization sequence...
> -- Determining maximum frame size... 8000 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Initialize Radio control...
> -- Performing register loopback test... pass
> -- Performing register loopback test... pass
> -- Initializing clock and time using internal sources... done
> Using Device: Single USRP:
> Device: X-Series Device
> Mboard 0: X310
> RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: SBX/CBX RX
> RX Channel: 1
> RX DSP: 1
> RX Dboard: B
> RX Subdev: SBX/CBX RX
> TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: SBX/CBX TX
> TX Channel: 1
> TX DSP: 1
> TX Dboard: B
> TX Subdev: SBX/CBX TX
>
> Testing receive rate 100.000000 Msps on 2 channels
>
> UHD Warning:
> x300_dac_ctrl: front-end sync failed. unexpected FIFO depth [0x7]
> Error: RuntimeError: x300_dac_ctrl: front-end sync failed. unexpected FIFO
> depth [0x7]
>
> crosshair@crosshair-HP-Z440:~$
>
>
> _______________________________________________
> 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/20150327/f748569b/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 27 Mar 2015 14:13:15 -0700
From: Ben Hilburn <[email protected]>
To: Rob Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Unexpected FIFO depth
Message-ID:
<caoevzkkkqfls-x2zubmyu2a12hw4xq-vfmhcvkrfp9moq+p...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Rob -
To be clear, you should *not* be seeing that failure.
Just to add some clarification to Michael's e-mail: the fixes that went
into improving synchronization between the DAC and FPGA worked for all
cases we tested it in. For customers building custom FPGA images, it can be
difficult to meet the timing requirements of the high-speed interfaces in
the device. We are in the process of finalizing our migration to the Vivado
toolchain, which does a much better job at this sort of thing. We expect
that once this migration is complete, it will be easier to meet timing
requirements in some tough scenarios. This is the improvement that Michael
mentioned would be available soon.
So, let's debug. Can you provide a bit more information regarding when you
see this error?
1. Do you ever see it from a fresh reboot? If you power cycle the
device, does it occur?
2. Do you see this on multiple units, or just one device?
Cheers,
Ben
On Fri, Mar 27, 2015 at 1:33 PM, Michael West via USRP-users <
[email protected]> wrote:
> Hi Rob,
>
> The error is indicating that it failed to synchronize the DAC, which means
> samples will not be aligned. This is due to some timing issues between the
> clock supplied to the DAC and the clock supplied to the FPGA. We have made
> some adjustments to the timing that made it work, but we suspected it may
> not hold for all temperatures. We have an open issue to investigate it
> further and we have already made some improvements that are scheduled to be
> available soon.
>
> Regards,
> Michael
>
> On Fri, Mar 27, 2015 at 6:43 AM, Rob Kossler via USRP-users <
> [email protected]> wrote:
>
>> Hi,
>> I have seen the following error several times over this past week. It is
>> intermittent such that if I rerun the example program immediately following
>> this error it will likely run fine.
>>
>> Error: RuntimeError: x300_dac_ctrl: front-end sync failed. unexpected
>> FIFO depth [0x7]
>>
>> I am running Ubuntu 14.04 LTS and using the benchmark_rate example
>> program along with an X310 (SBX-40 daughterboards). The full command
>> output is shown below.
>>
>> Any ideas?
>>
>> Rob
>>
>>
>> crosshair@crosshair-HP-Z440:~$ benchmark_rate --tx_rate=100e6
>> --rx_rate=100e6 --channels="0,1"
>> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.002-131-gb850dfb5
>>
>>
>> Creating the usrp device with: ...
>> -- X300 initialization sequence...
>> -- Determining maximum frame size... 8000 bytes.
>> -- Setup basic communication...
>> -- Loading values from EEPROM...
>> -- Setup RF frontend clocking...
>> -- Radio 1x clock:200
>> -- Initialize Radio control...
>> -- Performing register loopback test... pass
>> -- Performing register loopback test... pass
>> -- Initializing clock and time using internal sources... done
>> Using Device: Single USRP:
>> Device: X-Series Device
>> Mboard 0: X310
>> RX Channel: 0
>> RX DSP: 0
>> RX Dboard: A
>> RX Subdev: SBX/CBX RX
>> RX Channel: 1
>> RX DSP: 1
>> RX Dboard: B
>> RX Subdev: SBX/CBX RX
>> TX Channel: 0
>> TX DSP: 0
>> TX Dboard: A
>> TX Subdev: SBX/CBX TX
>> TX Channel: 1
>> TX DSP: 1
>> TX Dboard: B
>> TX Subdev: SBX/CBX TX
>>
>> Testing receive rate 100.000000 Msps on 2 channels
>>
>> UHD Warning:
>> x300_dac_ctrl: front-end sync failed. unexpected FIFO depth [0x7]
>> Error: RuntimeError: x300_dac_ctrl: front-end sync failed. unexpected
>> FIFO depth [0x7]
>>
>> crosshair@crosshair-HP-Z440:~$
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/68077c2c/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 27 Mar 2015 17:38:45 -0400
From: Jeremy Hershberger <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] varying TX delay on TX/RX loopback with B210
Message-ID:
<CAMZiKLohf3GA2o7VjepA5bYee4UDRmg=bkahjj1kwqiya7m...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
This oddity is truly bewildering.
I recently completed a FPGA-only TX, by nesting a small ROM in the B210
image and hacking apart the original TX state machine to accept only data
from the ROM instead of the host. To make the TX and RX work
simultaneously, I connected the TX's start signal to the RX's start signal.
Even with this "hard-wiring" of the TX to the RX, I still see the same
varying delay in the received data. The delay is usually in the low 160's
and varies over 2 to 3 samples.
I don't know too much about the transceiver chip on the B210, but shouldn't
it have a fixed start-up time once it is told to start transmitting?
Best,
-Jeremy
On Tue, Mar 24, 2015 at 4:12 PM, Jeremy Hershberger <
[email protected]> wrote:
> Greetings Marcus,
>
> Thanks for taking a look at this! I have attached two different captures,
> each one with showing a different delay (indicated by the filename).
>
> Each of these data files was captured using the same GNU radio script I
> have already provided, which uses the B210 to Tx/Rx a chirp waveform. If
> you run the matlab script I provided, you should be able to see the delay
> change in the correlation plots.
>
> Let me know if you need further info.
>
> Best,
>
> Jeremy
>
>
> On Fri, Mar 20, 2015 at 3:48 PM, Marcus M?ller <[email protected]
> > wrote:
>
>> Dear Jeremy,
>>
>> sorry I've been misisng your mail! I don't have an immediate answer; this
>> is a very interesting problem. Would you mind sharing your RX samples
>> somehow?
>>
>> Greetings,
>> Marcus
>>
>>
>> On 03/13/2015 07:08 PM, Jeremy Hershberger via USRP-users wrote:
>>
>> Using the timed commands, I zero'd the time on a PPS and set the B210's
>> transmitter and receiver to begin at a set time (1.5 seconds into the
>> future). The transmitter port is connected directly to the receive port via
>> a short cable. The transmit waveform is a linear chirp built in Matlab and
>> saved in a binary file. Upon correlating the received data with the
>> original transmitted waveform, I noticed the location of the first
>> correlation peak varies from run to run (over a range of +/- 2 samples). I
>> expected some delay from TX to RX (due to cable length and dsp), but I
>> expected that delay to be constant.
>>
>>
>> Has there been any success in using the B210 to simultaneously transmit
>> a waveform from file and receive to file with a known fixed delay between
>> TX/RX?
>>
>>
>> In case there is interest in reproducing the problem, I have included a
>> simple GNU radio python script to demonstrate the problem. I have also
>> included the original chirp waveform and a matlab script to show the
>> correlation lag.
>>
>>
>> Best,
>>
>> -Jeremy
>>
>>
>> _______________________________________________
>> 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/20150327/668783d4/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 27 Mar 2015 16:01:59 -0700
From: Ian Buckley <[email protected]>
To: Jeremy Hershberger <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] varying TX delay on TX/RX loopback with B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Jeremy,
I'm not sure I have an immediate answer for you here so asking some more
detailed questions:
You've put your linear chirp signal into a ROM that directly feeds the DSP?
Is the DSP configured for any interpolation or CORDIC rotation?
You are correlating at a similar place (immediately after the DSP) in the RX
chain?
You are measuring a round trip delay of ~160 clock cycles (+/-3 cycles) across
different runs.
The loopback is an (attenuated) cable between TX and RX SMA's?
The delay is stable over extended periods within the same run.?
-Ian
On Mar 27, 2015, at 2:38 PM, Jeremy Hershberger via USRP-users
<[email protected]> wrote:
> This oddity is truly bewildering.
>
> I recently completed a FPGA-only TX, by nesting a small ROM in the B210 image
> and hacking apart the original TX state machine to accept only data from the
> ROM instead of the host. To make the TX and RX work simultaneously, I
> connected the TX's start signal to the RX's start signal.
>
> Even with this "hard-wiring" of the TX to the RX, I still see the same
> varying delay in the received data. The delay is usually in the low 160's
> and varies over 2 to 3 samples.
>
> I don't know too much about the transceiver chip on the B210, but shouldn't
> it have a fixed start-up time once it is told to start transmitting?
>
> Best,
>
> -Jeremy
>
> On Tue, Mar 24, 2015 at 4:12 PM, Jeremy Hershberger
> <[email protected]> wrote:
> Greetings Marcus,
>
> Thanks for taking a look at this! I have attached two different captures,
> each one with showing a different delay (indicated by the filename).
>
> Each of these data files was captured using the same GNU radio script I have
> already provided, which uses the B210 to Tx/Rx a chirp waveform. If you run
> the matlab script I provided, you should be able to see the delay change in
> the correlation plots.
>
> Let me know if you need further info.
>
> Best,
>
> Jeremy
>
>
> On Fri, Mar 20, 2015 at 3:48 PM, Marcus M?ller <[email protected]>
> wrote:
> Dear Jeremy,
>
> sorry I've been misisng your mail! I don't have an immediate answer; this is
> a very interesting problem. Would you mind sharing your RX samples somehow?
>
> Greetings,
> Marcus
>
>
> On 03/13/2015 07:08 PM, Jeremy Hershberger via USRP-users wrote:
>> Using the timed commands, I zero'd the time on a PPS and set the B210's
>> transmitter and receiver to begin at a set time (1.5 seconds into the
>> future). The transmitter port is connected directly to the receive port via
>> a short cable. The transmit waveform is a linear chirp built in Matlab and
>> saved in a binary file. Upon correlating the received data with the original
>> transmitted waveform, I noticed the location of the first correlation peak
>> varies from run to run (over a range of +/- 2 samples). I expected some
>> delay from TX to RX (due to cable length and dsp), but I expected that delay
>> to be constant.
>>
>> Has there been any success in using the B210 to simultaneously transmit a
>> waveform from file and receive to file with a known fixed delay between
>> TX/RX?
>>
>> In case there is interest in reproducing the problem, I have included a
>> simple GNU radio python script to demonstrate the problem. I have also
>> included the original chirp waveform and a matlab script to show the
>> correlation lag.
>>
>> Best,
>> -Jeremy
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/ef30ac93/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 27 Mar 2015 20:26:00 -0400
From: Jeremy Hershberger <[email protected]>
To: Ian Buckley <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] varying TX delay on TX/RX loopback with B210
Message-ID:
<CAMZiKLq7rEJ+kAw=ig7yz_PWN8sD8YKSs4=ofrudmrwcoht...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Ian,
Hopefully these answers will give you some insight.
*You've put your linear chirp signal into a ROM that directly feeds the
DSP?*
Yes. However, I do want to emphasize that my modifications to the FPGA
resulted in the same behaviors as was seen with the stock FPGA image + my
GNU radio script.
*Is the DSP configured for any interpolation or CORDIC rotation?*
No interpolation is required as master_clock_rate=25e6, the same as the
desired TX/RX rate
I have tried it with and without CORDIC rotation. I have tried requesting
2412MHz, but the RF Lo will only do 2411.999998MHz, so the DSP needs to
make up 0.000002MHz. I have also tried requesting 2000MHz, which UHD
reports it can successfully tune to with the use of DSP.
*You are correlating at a similar place (immediately after the DSP) in the
RX chain?*
I believe the correlations are happening at the same point. I made no
changes to the behavior of the RX in my custom FPGA image, so the RX in the
stock image and the RX in my image should have identical delays
*You are measuring a round trip delay of ~160 clock cycles (+/-3 cycles)
across different runs.*
Correct. I do not care about the actual number, the only problem I am
worried about is that it changes from run to run.
*The loopback is an (attenuated) cable between TX and RX SMA's?*
Correct. I have tried it with and without 30dB pads.
*The delay is stable over extended periods within the same run.?*
Yes. The waveform is 250 samples long, and the correlation peaks appear
every 250 samples. My problem is the location of the first correlation
peak moves (~160 samples +/- 3 samples) from run to run.
Let me know if you need more info.
Best,
-Jeremy
On Fri, Mar 27, 2015 at 7:01 PM, Ian Buckley <[email protected]> wrote:
> Jeremy,
> I'm not sure I have an immediate answer for you here so asking some more
> detailed questions:
> You've put your linear chirp signal into a ROM that directly feeds the DSP?
> Is the DSP configured for any interpolation or CORDIC rotation?
> You are correlating at a similar place (immediately after the DSP) in the
> RX chain?
> You are measuring a round trip delay of ~160 clock cycles (+/-3 cycles)
> across different runs.
> The loopback is an (attenuated) cable between TX and RX SMA's?
> The delay is stable over extended periods within the same run.?
> -Ian
>
>
> On Mar 27, 2015, at 2:38 PM, Jeremy Hershberger via USRP-users <
> [email protected]> wrote:
>
> This oddity is truly bewildering.
>
> I recently completed a FPGA-only TX, by nesting a small ROM in the B210
> image and hacking apart the original TX state machine to accept only data
> from the ROM instead of the host. To make the TX and RX work
> simultaneously, I connected the TX's start signal to the RX's start signal.
>
> Even with this "hard-wiring" of the TX to the RX, I still see the same
> varying delay in the received data. The delay is usually in the low 160's
> and varies over 2 to 3 samples.
>
> I don't know too much about the transceiver chip on the B210, but
> shouldn't it have a fixed start-up time once it is told to start
> transmitting?
>
> Best,
>
> -Jeremy
>
> On Tue, Mar 24, 2015 at 4:12 PM, Jeremy Hershberger <
> [email protected]> wrote:
>
>> Greetings Marcus,
>>
>> Thanks for taking a look at this! I have attached two different
>> captures, each one with showing a different delay (indicated by the
>> filename).
>>
>> Each of these data files was captured using the same GNU radio script I
>> have already provided, which uses the B210 to Tx/Rx a chirp waveform. If
>> you run the matlab script I provided, you should be able to see the delay
>> change in the correlation plots.
>>
>> Let me know if you need further info.
>>
>> Best,
>>
>> Jeremy
>>
>>
>> On Fri, Mar 20, 2015 at 3:48 PM, Marcus M?ller <
>> [email protected]> wrote:
>>
>>> Dear Jeremy,
>>>
>>> sorry I've been misisng your mail! I don't have an immediate answer;
>>> this is a very interesting problem. Would you mind sharing your RX samples
>>> somehow?
>>>
>>> Greetings,
>>> Marcus
>>>
>>>
>>> On 03/13/2015 07:08 PM, Jeremy Hershberger via USRP-users wrote:
>>>
>>> Using the timed commands, I zero'd the time on a PPS and set the B210's
>>> transmitter and receiver to begin at a set time (1.5 seconds into the
>>> future). The transmitter port is connected directly to the receive port via
>>> a short cable. The transmit waveform is a linear chirp built in Matlab and
>>> saved in a binary file. Upon correlating the received data with the
>>> original transmitted waveform, I noticed the location of the first
>>> correlation peak varies from run to run (over a range of +/- 2 samples). I
>>> expected some delay from TX to RX (due to cable length and dsp), but I
>>> expected that delay to be constant.
>>>
>>>
>>> Has there been any success in using the B210 to simultaneously transmit
>>> a waveform from file and receive to file with a known fixed delay between
>>> TX/RX?
>>>
>>>
>>> In case there is interest in reproducing the problem, I have included a
>>> simple GNU radio python script to demonstrate the problem. I have also
>>> included the original chirp waveform and a matlab script to show the
>>> correlation lag.
>>>
>>>
>>> Best,
>>>
>>> -Jeremy
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing
>>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/84d83a43/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 55, Issue 28
******************************************
