Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: USRP B210 queries (Neel Pandeya)
2. Re: USRP B210 queries (Marcus D. Leech)
3. Synchronization in USRP B210 (?Shen .)
4. Re: Synchronization in USRP B210 (Mike McLernon)
5. Re: Synchronization in USRP B210 (Marcus D. Leech)
6. Random Phase Offset Between Two Rx Channels of B210 ???
(Ufuk Tamer)
7. Re: 4 Channel Synchronization with 2 X-300s (Michael West)
8. Re: Random Phase Offset Between Two Rx Channels of B210 ???
(Marcus D. Leech)
9. Re: varying TX delay on TX/RX loopback with B210
(Jeremy Hershberger)
----------------------------------------------------------------------
Message: 1
Date: Tue, 24 Mar 2015 09:40:00 -0700
From: Neel Pandeya <[email protected]>
To: mvprasad k <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] USRP B210 queries
Message-ID:
<CACaXmv_BUz2-VH1JqQwnmo3u_BGoBFr=WJ4Khc-z67=Ctcy1=q...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Let's please keep this conversation on the mailing list.
You have an Intel 7-Series/C210 USB controller, and the Intel controllers
generally work quite well. So I don't suspect a problem with your USB
controller.
What's your CPU clock speed? Could you run "sudo lshw -html >
system_specs.html", and attach the output HTML file?
Are you only getting a couple of overruns at the beginning of your capture,
or are you getting continuous overruns as "rx_samples_to_file" runs?? If
you do a 30-second capture, how many overruns do you see?
What is the system loading when you run these captures? It's strange that
it would run without overruns for 10 seconds, but then start producing
overruns after that point. Could you run "htop" while doing a 30-second
capture, and keep an eye on the CPU loading? What kind of loading do you
see?
--Neel
On 22 March 2015 at 22:25, mvprasad k <[email protected]> wrote:
> HI,
>
> I'm using mechanical disk drive.
> I?m on Ubuntu 14.10.
>
> I?m using sample rates...upto 10MSPS. with 10 MSPS its working fine for 10
> seconds duration but if we increase the time, we are getting overrun.The
> output is as follows...
>
> root@prasad-pc:/home/prasad/uhd/host/examples# ./
> ??
> rx_samples_to_file.exe --freq 80e6 --time 15 --rate 10e6
> linux; GNU C++ version 4.9.1; Boost_105500; UHD_003.008.002-80-ge28d7844
>
>
> Creating the usrp device with: ...
> -- Operating over USB 3.
> -- Initialize CODEC control...
> -- Initialize Radio control...
> -- Performing register loopback test... pass
> -- Performing register loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Asking for clock rate 32.000000 MHz...
> -- Actually got clock rate 32.000000 MHz.
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> -- Setting master clock rate selection to 'automatic'.
> Using Device: Single USRP:
> Device: B-Series Device
> Mboard 0: B210
> RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: FE-RX2
> RX Channel: 1
> RX DSP: 1
> RX Dboard: A
> RX Subdev: FE-RX1
> TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: FE-TX2
> TX Channel: 1
> TX DSP: 1
> TX Dboard: A
> TX Subdev: FE-TX1
>
> Setting RX Rate: 10.000000 Msps...
> -- Asking for clock rate 40.000000 MHz...
> -- Actually got clock rate 40.000000 MHz.
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> Actual RX Rate: 10.000000 Msps...
>
> Setting RX Freq: 80.000000 MHz...
> -- Successfully tuned to 80.000000 MHz
> --
> Actual RX Freq: 80.000000 MHz...
>
> Waiting for "lo_locked": ++++++++++ locked.
>
> Press Ctrl + C to stop streaming...
> OGot an overflow indication. Please consider the following:
> Your write medium must sustain a rate of 40.000000MB/s.
> Dropped samples will not be written to the file.
> Please modify this example for your purposes.
> This message will not appear again.
> O^C
> Done!
>
>
> The output of the command uhd_find_devices....
>
> prasad@prasad-pc:~/uhd/host/examples$ uhd_find_devices
> linux; GNU C++ version 4.9.1; Boost_105500; UHD_003.008.002-80-ge28d7844
>
> -- Loading firmware image: /usr/local/share/uhd/images/usrp_b200_fw.hex...
> done
> --------------------------------------------------
> -- UHD Device 0
> --------------------------------------------------
> Device Address:
> type: b200
> name: lab_USRP
> serial: F5D87A
> product: B210
>
> The output of the command lspci....
>
> prasad@prasad-pc:~$ lspci
> 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core
> processor DRAM Controller (rev 09)
> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd
> Gen Core processor Graphics Controller (rev 09)
> 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
> Family USB xHCI Host Controller (rev 04)
> 00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series
> Chipset Family MEI Controller #1 (rev 04)
> 00:16.3 Serial controller: Intel Corporation 7 Series/C210 Series Chipset
> Family KT Controller (rev 04)
> 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network
> Connection (rev 04)
> 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
> Family USB Enhanced Host Controller #2 (rev 04)
> 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset
> Family High Definition Audio Controller (rev 04)
> 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
> Family USB Enhanced Host Controller #1 (rev 04)
> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a4)
> 00:1f.0 ISA bridge: Intel Corporation Q77 Express Chipset LPC Controller
> (rev 04)
> 00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset
> Family 6-port SATA Controller [AHCI mode] (rev 04)
>
>
> Kindly share your ideas.
>
> wbrs,
> prasad.
>
> On Fri, Mar 20, 2015 at 5:51 PM, Neel Pandeya <[email protected]>
> wrote:
>
>> Your system, at first look, seems to be powerful enough to sustain high
>> sample rates. What type of disk are you using? A mechanical disk or an SSD
>> drive?
>>
>> Are you running Linux? Which distribution/version?
>>
>> Do you still see overruns if you run "rx_samples_to_file" as root with
>> "sudo"? If so, at what sample rates?
>>
>> Which version of UHD are you using? If you run "uhd_find_devices", the
>> first line of output will tell you.
>>
>> Which USB controller do you have in your system? Could you run "lspci",
>> and post the output?
>>
>> --Neel
>>
>>
>> On 20 March 2015 at 00:36, mvprasad k via USRP-users <
>> [email protected]> wrote:
>>
>>> Hi,
>>>
>>> I have the following queries regarding B210 board functioning.
>>>
>>> 1. Is there any memory buffer inside the B210 board?
>>> 2. Actually I?m running rx_samples_to_file.cpp with different sampling
>>> rate values ranging from 10MHz to 40MHz. Sometimes it's going to the
>>> following code loop and generating the overflow error but sometimes not.
>>> I'm giving time to receive samples also say 10 seconds.
>>> Why this unpredictable behaviour of the board?
>>>
>>> if (md.error_code == uhd::rx_metadata_t::ERROR_CODE_OVERFLOW){
>>> if (overflow_message) {
>>> overflow_message = false;
>>> std::cerr << boost::format(
>>> "Got an overflow indication. Please consider the
>>> following:\n"
>>> " Your write medium must sustain a rate of
>>> %fMB/s.\n"
>>> " Dropped samples will not be written to the
>>> file.\n"
>>> " Please modify this example for your purposes.\n"
>>> " This message will not appear again.\n"
>>> ) % (usrp->get_rx_rate()*sizeof(samp_type)/1e6);
>>> }
>>>
>>> 3.Continue from above question, Is this overflow problem depends on my
>>> PC specs.? My PC specs are HP Compaq Elite 8300 microtower, 4GB RAM, I5
>>> processor, USB 3.o port, 3.66 GHz clock speed.
>>>
>>> Kindly share your ideas.
>>>
>>> wbrs,
>>> prasad
>>>
>>>
>>> _______________________________________________
>>> 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/20150324/cf17eab8/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 24 Mar 2015 12:45:39 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B210 queries
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 03/24/2015 12:40 PM, Neel Pandeya via USRP-users wrote:
> Let's please keep this conversation on the mailing list.
>
> You have an Intel 7-Series/C210 USB controller, and the Intel
> controllers generally work quite well. So I don't suspect a problem
> with your USB controller.
>
> What's your CPU clock speed? Could you run "sudo lshw -html >
> system_specs.html", and attach the output HTML file?
>
> Are you only getting a couple of overruns at the beginning of your
> capture, or are you getting continuous overruns as
> "rx_samples_to_file" runs?? If you do a 30-second capture, how many
> overruns do you see?
>
> What is the system loading when you run these captures? It's strange
> that it would run without overruns for 10 seconds, but then start
> producing overruns after that point. Could you run "htop" while doing
> a 30-second capture, and keep an eye on the CPU loading? What kind of
> loading do you see?
>
> --Neel
>
Actually, the "no overruns in the first few tens of seconds, then
overruns" when using rx_samples_to_file is typical of disk-subsystem
insufficiency.
The kernel buffers fill up, but then the kernel has to start
back-pressuring, as writes actually get committed to disk.
Try rx_samples_to_file with /dev/null as the written-to "file" and see
if that changes things...
>
>
> On 22 March 2015 at 22:25, mvprasad k <[email protected]
> <mailto:[email protected]>> wrote:
>
> HI,
>
> I'm using mechanical disk drive.
> I'm on Ubuntu 14.10.
>
> I'm using sample rates...upto 10MSPS. with 10 MSPS its working
> fine for 10 seconds duration but if we increase the time, we are
> getting overrun.The output is as follows...
>
> root@prasad-pc:/home/prasad/uhd/host/examples# ./
> rx_samples_to_file.exe --freq 80e6 --time 15 --rate 10e6
> linux; GNU C++ version 4.9.1; Boost_105500;
> UHD_003.008.002-80-ge28d7844
>
>
> Creating the usrp device with: ...
> -- Operating over USB 3.
> -- Initialize CODEC control...
> -- Initialize Radio control...
> -- Performing register loopback test... pass
> -- Performing register loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Asking for clock rate 32.000000 MHz...
> -- Actually got clock rate 32.000000 MHz.
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> -- Setting master clock rate selection to 'automatic'.
> Using Device: Single USRP:
> Device: B-Series Device
> Mboard 0: B210
> RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: FE-RX2
> RX Channel: 1
> RX DSP: 1
> RX Dboard: A
> RX Subdev: FE-RX1
> TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: FE-TX2
> TX Channel: 1
> TX DSP: 1
> TX Dboard: A
> TX Subdev: FE-TX1
>
> Setting RX Rate: 10.000000 Msps...
> -- Asking for clock rate 40.000000 MHz...
> -- Actually got clock rate 40.000000 MHz.
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> Actual RX Rate: 10.000000 Msps...
>
> Setting RX Freq: 80.000000 MHz...
> -- Successfully tuned to 80.000000 MHz
> --
> Actual RX Freq: 80.000000 MHz...
>
> Waiting for "lo_locked": ++++++++++ locked.
>
> Press Ctrl + C to stop streaming...
> OGot an overflow indication. Please consider the following:
> Your write medium must sustain a rate of 40.000000MB/s.
> Dropped samples will not be written to the file.
> Please modify this example for your purposes.
> This message will not appear again.
> O^C
> Done!
>
>
> The output of the command uhd_find_devices....
>
> prasad@prasad-pc:~/uhd/host/examples$ uhd_find_devices
> linux; GNU C++ version 4.9.1; Boost_105500;
> UHD_003.008.002-80-ge28d7844
>
> -- Loading firmware image:
> /usr/local/share/uhd/images/usrp_b200_fw.hex... done
> --------------------------------------------------
> -- UHD Device 0
> --------------------------------------------------
> Device Address:
> type: b200
> name: lab_USRP
> serial: F5D87A
> product: B210
>
> The output of the command lspci....
>
> prasad@prasad-pc:~$ lspci
> 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen
> Core processor DRAM Controller (rev 09)
> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200
> v2/3rd Gen Core processor Graphics Controller (rev 09)
> 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series
> Chipset Family USB xHCI Host Controller (rev 04)
> 00:16.0 Communication controller: Intel Corporation 7 Series/C210
> Series Chipset Family MEI Controller #1 (rev 04)
> 00:16.3 Serial controller: Intel Corporation 7 Series/C210 Series
> Chipset Family KT Controller (rev 04)
> 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit
> Network Connection (rev 04)
> 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series
> Chipset Family USB Enhanced Host Controller #2 (rev 04)
> 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series
> Chipset Family High Definition Audio Controller (rev 04)
> 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series
> Chipset Family USB Enhanced Host Controller #1 (rev 04)
> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a4)
> 00:1f.0 ISA bridge: Intel Corporation Q77 Express Chipset LPC
> Controller (rev 04)
> 00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series
> Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
>
>
> Kindly share your ideas.
>
> wbrs,
> prasad.
>
> On Fri, Mar 20, 2015 at 5:51 PM, Neel Pandeya
> <[email protected] <mailto:[email protected]>> wrote:
>
> Your system, at first look, seems to be powerful enough to
> sustain high sample rates. What type of disk are you using? A
> mechanical disk or an SSD drive?
>
> Are you running Linux? Which distribution/version?
>
> Do you still see overruns if you run "rx_samples_to_file" as
> root with "sudo"? If so, at what sample rates?
>
> Which version of UHD are you using? If you run
> "uhd_find_devices", the first line of output will tell you.
>
> Which USB controller do you have in your system? Could you run
> "lspci", and post the output?
>
> --Neel
>
>
> On 20 March 2015 at 00:36, mvprasad k via USRP-users
> <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi,
>
> I have the following queries regarding B210 board functioning.
>
> 1. Is there any memory buffer inside the B210 board?
> 2. Actually I'm running rx_samples_to_file.cpp with
> different sampling rate values ranging from 10MHz to
> 40MHz. Sometimes it's going to the following code loop and
> generating the overflow error but sometimes not. I'm
> giving time to receive samples also say 10 seconds.
> Why this unpredictable behaviour of the board?
>
> if (md.error_code == uhd::rx_metadata_t::ERROR_CODE_OVERFLOW){
> if (overflow_message) {
> overflow_message = false;
> std::cerr << boost::format(
> "Got an overflow indication. Please
> consider the following:\n"
> " Your write medium must sustain a
> rate of %fMB/s.\n"
> " Dropped samples will not be written
> to the file.\n"
> " Please modify this example for your
> purposes.\n"
> " This message will not appear again.\n"
> ) %
> (usrp->get_rx_rate()*sizeof(samp_type)/1e6);
> }
>
> 3.Continue from above question, Is this overflow problem
> depends on my PC specs.? My PC specs are HP Compaq Elite
> 8300 microtower, 4GB RAM, I5 processor, USB 3.o port, 3.66
> GHz clock speed.
>
> Kindly share your ideas.
>
> wbrs,
> prasad
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150324/5ff03a59/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 24 Mar 2015 10:10:12 +0100
From: ?Shen . <[email protected]>
To: [email protected]
Subject: [USRP-users] Synchronization in USRP B210
Message-ID:
<cachrcjpimjpdh80pundablrdczjcfxahojord9dj29msw4r...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
I am building a OFDM project in B210 with matlab. I am confused about the
synchronization problem.
Does the board do it or I should do it totally in the software?
How the board decide where to start sampling in every frame?
Should I use cable to synchronize the clock in Tx and Rx?
All the best,
Boyu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150324/a7a6ec0e/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 24 Mar 2015 17:06:20 +0000
From: Mike McLernon <[email protected]>
To: ?Shen . <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Synchronization in USRP B210
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Boyu,
You?ll want to describe your problem a bit more completely for me to give you a
confident answer. Which synchronization problem are you referring to? If it
is the synchronization in both time and frequency of the OFDM signal itself,
then you can look at a MATLAB-based OFDM sync example at
http://www.mathworks.com/help/comm/examples/ofdm-synchronization.html. You
would do all this synchronization in software.
The radio simply pulls data out of a buffer and sends it to MATLAB. The A/D on
the radio operates at the master clock rate that you specify, and then streams
data to downstream buffers.
If you use an external clock to synchronize the tx and rx, then you effectively
remove one source of signal impairment, thus making demodulation easier.
Whether or not you should depends on if you want to implement a frequency
correction algorithm. The MATLAB example referenced above does perform the
frequency correction.
Hth,
Mike
From: USRP-users [mailto:[email protected]] On Behalf Of ?Shen
. via USRP-users
Sent: Tuesday, March 24, 2015 5:10 AM
To: [email protected]
Subject: [USRP-users] Synchronization in USRP B210
Dear all,
I am building a OFDM project in B210 with matlab. I am confused about the
synchronization problem.
Does the board do it or I should do it totally in the software?
How the board decide where to start sampling in every frame?
Should I use cable to synchronize the clock in Tx and Rx?
All the best,
Boyu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150324/9abdfa55/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 24 Mar 2015 13:10:17 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Synchronization in USRP B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 03/24/2015 01:06 PM, Mike McLernon via USRP-users wrote:
>
> Hi Boyu,
>
> You'll want to describe your problem a bit more completely for me to
> give you a confident answer. Which synchronization problem are you
> referring to? If it is the synchronization in both time and frequency
> of the OFDM signal itself, then you can look at a MATLAB-based OFDM
> sync example at
> http://www.mathworks.com/help/comm/examples/ofdm-synchronization.html.
> You would do all this synchronization in software.
>
> The radio simply pulls data out of a buffer and sends it to MATLAB.
> The A/D on the radio operates at the master clock rate that you
> specify, and then streams data to downstream buffers.
>
> If you use an external clock to synchronize the tx and rx, then you
> effectively remove one source of signal impairment, thus making
> demodulation easier. Whether or not you should depends on if you want
> to implement a frequency correction algorithm. The MATLAB example
> referenced above does perform the frequency correction.
>
> Hth,
>
> Mike
>
Further, in real-world systems, the TX and RX are rarely synchronized in
time and phase. Which is why *real* RX algorithms have provisions for
taking
care of that.
> *From:*USRP-users [mailto:[email protected]] *On
> Behalf Of *?Shen . via USRP-users
> *Sent:* Tuesday, March 24, 2015 5:10 AM
> *To:* [email protected]
> *Subject:* [USRP-users] Synchronization in USRP B210
>
> Dear all,
>
> I am building a OFDM project in B210 with matlab. I am confused about
> the synchronization problem.
>
>
> Does the board do it or I should do it totally in the software?
>
> How the board decide where to start sampling in every frame?
>
> Should I use cable to synchronize the clock in Tx and Rx?
>
> All the best,
>
> Boyu
>
>
>
> _______________________________________________
> 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/20150324/9aca2a51/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 24 Mar 2015 21:12:20 +0200
From: Ufuk Tamer <[email protected]>
To: [email protected]
Subject: [USRP-users] Random Phase Offset Between Two Rx Channels of
B210 ???
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1254"; Format="flowed"
Dear all,
I am testing the phase offset between two Rx channels of B210. For this
case, I transmit a sine signal with another USRP device and receive it
with two RX channels of B210. Then I calculate the phase offset between
channels. The problem is the phase offset changes whenever I reset the
receiver. So it gives a random phase offset on each device turn on.
Is this normal? If yes, what is the reason for this random phase offset.
Since both channels share the same LO, where this "random" phase offset
come from?
Thank you...
Anketek Signature
------------------------------------------------------------------------
/*Ufuk Tamer
*/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150324/66fbd3a9/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 24 Mar 2015 13:09:11 -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:
<cam4xkrpxzfede5q0qzed__5yd49nzft21jqqiehyqdzpcuj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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/20150324/12621046/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 24 Mar 2015 16:12:03 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Random Phase Offset Between Two Rx Channels
of B210 ???
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 03/24/2015 03:12 PM, Ufuk Tamer via USRP-users wrote:
> Dear all,
>
> I am testing the phase offset between two Rx channels of B210. For
> this case, I transmit a sine signal with another USRP device and
> receive it with two RX channels of B210. Then I calculate the phase
> offset between channels. The problem is the phase offset changes
> whenever I reset the receiver. So it gives a random phase offset on
> each device turn on.
>
> Is this normal? If yes, what is the reason for this random phase
> offset. Since both channels share the same LO, where this "random"
> phase offset come from?
>
> Thank you...
>
> Anketek Signature
> ------------------------------------------------------------------------
> /*Ufuk Tamer
> */
What version of UHD are you using?
How are you doing the two-channel receive?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150324/b713599b/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 24 Mar 2015 16:12:07 -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:
<camziklrkdta99dpcnu3spxovermkn2o6cebn-nb1imaibai...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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/20150324/d1a16da1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: run1_delay169.dat.zip
Type: application/zip
Size: 8915567 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150324/d1a16da1/attachment.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: run2_delay168.dat.zip
Type: application/zip
Size: 12800806 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150324/d1a16da1/attachment-0001.zip>
------------------------------
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 24
******************************************
