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. TVRX2 Automatic Gain Control problem (Lucas Kindermann)
2. Reusing a block for multiple iterations (Tinajayce Mathews)
3. Re: Reusing a block for multiple iterations (Nick Foster)
4. Re: TVRX2 Automatic Gain Control problem (Marcus D. Leech)
5. USRP N210: No control response (Farrukh Aziz)
6. Re: USRP N210: No control response (Josh Blum)
7. Re: TVRX2 Automatic Gain Control problem (Lucas Kindermann)
8. Re: TVRX2 Automatic Gain Control problem (Marcus D. Leech)
9. Using two USRP N200 for capturing uplink and downlink signals
(Birhane Alemayoh)
10. Re: Using two USRP N200 for capturing uplink and downlink
signals (Nick Foster)
11. Problem of SBX board to support full-duplex communications.
(Alex Zhang)
12. Re: Transceiver IC max2829 (John Malsbury)
13. Re: Problem of SBX board to support full-duplex
communications. (Josh Blum)
14. LO phase alignment (Christophe ALEXANDRE)
15. Re: LO phase alignment (John Malsbury)
16. Re: Problem of SBX board to support full-duplex
communications. (Alex Zhang)
17. Re: LO phase alignment (Christophe ALEXANDRE)
18. Re: LO phase alignment (Josh Blum)
----------------------------------------------------------------------
Message: 1
Date: Wed, 20 Jun 2012 16:46:03 -0300
From: Lucas Kindermann <[email protected]>
To: [email protected]
Cc: Rafael Luiz Cancian <[email protected]>, Ant?nio Augusto
Fr?hlich <[email protected]>, Lucas Caldeira de Oliveira
<[email protected]>, Sabrina Perardt <[email protected]>
Subject: [USRP-users] TVRX2 Automatic Gain Control problem
Message-ID:
<ca+z-nr6zt8ekoenh-0c-5r5syl-777ec8ocdq67wbk6_u1j...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Greetings,
I'm working on a project using two USRP1 Rev. 4.5 (both USRP1 works
separately) and four TVRX2 Rev. 1.1 boards for DF application.
Besides the phase alignment, this application needs the implementation of
amplitude detection on all RX channels too, and for this goal, the
Automatic Gain Control could screw up the real value of amplitude from the
received signals.
Can the AGC feature on the TVRX2 receivers be shut down or manually
adjusted across the software configurations or hardware modifications ?
Another question, i don't had success to find the full datasheet of
TDA18272 receiver on the internet, even at manufacturer's website. I only
had found a shorten version of datasheet with 10 pages that shows
superficially the IC's features. Do you have and could you send me a copy
of full datasheet or application notes of TDA18272 receiver used on TVRX2
design ?
I thanks for your attention, knowing your time is precious.
Cordially,
--
Lucas de Mello Kindermann.
UFSC/CTC/LISHA - Software/Hardware Integration Lab.
Postgraduating in Electronics Product Development at Federal Institute of
Santa Catarina.
B.Tech in Electronics Systems at Federal Institute of Santa Catarina.
[email protected]
+55 (48) 3721-9516
+55 (48) 9937-7679
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120620/e5bdd5a8/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 20 Jun 2012 15:06:13 -0500
From: Tinajayce Mathews <[email protected]>
To: [email protected]
Subject: [USRP-users] Reusing a block for multiple iterations
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi All,
I wanted to use a C++ block and run it multiple number of times. For eg: I am
using a block to run one iteration. If I needed the results from this block
again in the continuing iterations, is there a work around for it. I am using
a hierarchical block and calling it like a function. I wonder if this is
possible. Any help is appreciated.
Thanks a lot for your help.
Regards,
Tina Mathews,
Instructional Assistant
Email: [email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120620/780d2d2a/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 20 Jun 2012 13:11:21 -0700
From: Nick Foster <[email protected]>
To: Tinajayce Mathews <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Reusing a block for multiple iterations
Message-ID:
<CALALHJXoex0-Y4qRQxEN=edv3khkk24hrgrxt2ebeurln9q...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, Jun 20, 2012 at 1:06 PM, Tinajayce Mathews <[email protected]>wrote:
> Hi All,
>
> I wanted to use a C++ block and run it multiple number of times. For eg: I
> am using a block to run one iteration. If I needed the results from this
> block again in the continuing iterations, is there a work around for it. I
> am using a hierarchical block and calling it like a function. I wonder if
> this is possible. Any help is appreciated.
>
> Thanks a lot for your help.
>
Unless I'm misunderstanding your question, just store the results from last
time in a private buffer which is a member of the block class.
--n
>
> Regards,
> Tina Mathews,
> Instructional Assistant
> Email: [email protected]
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120620/765d310a/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 20 Jun 2012 17:31:15 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] TVRX2 Automatic Gain Control problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Greetings,
>
> I'm working on a project using two USRP1 Rev. 4.5 (both USRP1 works
> separately) and four TVRX2 Rev. 1.1 boards for DF application.
>
> Besides the phase alignment, this application needs the implementation
> of amplitude detection on all RX channels too, and for this goal, the
> Automatic Gain Control could screw up the real value of amplitude from
> the received signals.
>
> Can the AGC feature on the TVRX2 receivers be shut down or manually
> adjusted across the software configurations or hardware modifications ?
>
No, there is no way to turn off the AGC on the TVRX2. This has been
thoroughly investigated at Ettus, and it cannot be done.
> Another question, i don't had success to find the full datasheet of
> TDA18272 receiver on the internet, even at manufacturer's website. I
> only had found a shorten version of datasheet with 10 pages that shows
> superficially the IC's features. Do you have and could you send me a
> copy of full datasheet or application notes of TDA18272 receiver used
> on TVRX2 design ?
>
> I thanks for your attention, knowing your time is precious.
>
The full datasheet is available only under NDA with NXP.
Also, keep in mind that only a *single* TVRX2 can be used per USRP1 due
to I2C addressing limitations.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 5
Date: Wed, 20 Jun 2012 17:37:20 -0700 (PDT)
From: Farrukh Aziz <[email protected]>
To: USRP user forum <[email protected]>
Subject: [USRP-users] USRP N210: No control response
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi list, I have been working with two N210s for a while now, and they have been
working fine. However yesterday I started off again after a break, but one of
the USRP N210 showed an error.
When I run the command 'uhd_find_devices' I get this output
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
??? type: usrp2
??? addr: 130.216.24.101
??? name:
??? serial:
Device serial no is not shown.
When I run the command 'uhd_usrp_probe' I get this output
linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.001.002-5239879
-- Opening a USRP2/N-Series device...
Error: RuntimeError: no control response
I am not able to figure out whats wrong. It appears to be a basic fault, that
the device's IP address is shown, but still there is a control error. Will
appreciate any help.
Farrukh Aziz Bhatti
Department of Electrical & Computer Engineering
University of Auckland
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120620/36feed73/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 20 Jun 2012 17:46:18 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP N210: No control response
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 06/20/2012 05:37 PM, Farrukh Aziz wrote:
> Hi list, I have been working with two N210s for a while now, and they have
> been working fine. However yesterday I started off again after a break, but
> one of the USRP N210 showed an error.
>
> When I run the command 'uhd_find_devices' I get this output
> --------------------------------------------------
> -- UHD Device 0
> --------------------------------------------------
> Device Address:
> type: usrp2
> addr: 130.216.24.101
> name:
> serial:
>
> Device serial no is not shown.
>
> When I run the command 'uhd_usrp_probe' I get this output
>
> linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.001.002-5239879
>
> -- Opening a USRP2/N-Series device...
> Error: RuntimeError: no control response
>
>
> I am not able to figure out whats wrong. It appears to be a basic fault, that
> the device's IP address is shown, but still there is a control error. Will
> appreciate any help.
>
>
It smells like a network configuration error. The USRP can respond to
the broadcast packet, but the lack of name and serial seems that its not
able to communicate directly to the IP address. That would explain the
runtime error as well.
-josh
> Farrukh Aziz Bhatti
> Department of Electrical & Computer Engineering
> University of Auckland
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 7
Date: Thu, 21 Jun 2012 00:11:42 -0300
From: Lucas Kindermann <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] TVRX2 Automatic Gain Control problem
Message-ID:
<CA+Z-nR7Wmf2Y6hqSnj+6qLs2ZwC4jp8ZyUjS7CXK9ybUP7=e...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Marcus,
Firstly, i would like to thank you for the info about the AGC configuration
and the TDA datasheet. However i'm now worried with that you've said about
the use of two TVRX2.
"Also, keep in mind that only a *single* TVRX2 can be used per USRP1 due to
I2C addressing limitations."
This is weird, because in fact i'm using two TVRX2 in one USRP1 and i can
tune both boards, although the tuned frequency for both TVRX2 channels (RX1
and RX2) is mirrored for both boards on the RXA and RXB slots. This would
not be a problem for my application because i really need that all RX
channels from both boards be tuned at the same frequency.
On Gnuradio, i can see the four channels receiving radio signals on the
tuned frequency (each channel is connected in a different antenna) and
using the uhd_usrp_probe command i can obtain the ID from both boards, each
in their correspondent slots. Presume this happens because of the data
stored at the EEPROM memory in each board.
Now my doubt is: Am i getting the two TVRX2 channels tuned each time i set
the central frequency for both boards? Or one of the boards isn't
communicating and it's tuned because the central frequency is stored in
EEPROM memory and read by the TDA receivers when USRP1 and TVRX2 boards are
turned on?
Cordially,
2012/6/20 Marcus D. Leech <[email protected]>
>
>> Greetings,
>>
>> I'm working on a project using two USRP1 Rev. 4.5 (both USRP1 works
>> separately) and four TVRX2 Rev. 1.1 boards for DF application.
>>
>> Besides the phase alignment, this application needs the implementation of
>> amplitude detection on all RX channels too, and for this goal, the
>> Automatic Gain Control could screw up the real value of amplitude from the
>> received signals.
>>
>> Can the AGC feature on the TVRX2 receivers be shut down or manually
>> adjusted across the software configurations or hardware modifications ?
>>
>> No, there is no way to turn off the AGC on the TVRX2. This has been
> thoroughly investigated at Ettus, and it cannot be done.
>
>
> Another question, i don't had success to find the full datasheet of
>> TDA18272 receiver on the internet, even at manufacturer's website. I only
>> had found a shorten version of datasheet with 10 pages that shows
>> superficially the IC's features. Do you have and could you send me a copy
>> of full datasheet or application notes of TDA18272 receiver used on TVRX2
>> design ?
>>
>> I thanks for your attention, knowing your time is precious.
>>
>> The full datasheet is available only under NDA with NXP.
>
> Also, keep in mind that only a *single* TVRX2 can be used per USRP1 due to
> I2C addressing limitations.
>
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> ______________________________**_________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/**mailman/listinfo/usrp-users_**lists.ettus.com<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
--
Lucas de Mello Kindermann.
UFSC/CTC/LISHA - Software/Hardware Integration Lab.
Postgraduating in Electronics Product Development at Federal Institute of
Santa Catarina.
B.Tech in Electronics Systems at Federal Institute of Santa Catarina.
[email protected]
+55 (48) 3721-9516
+55 (48) 9937-7679
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120621/75207df6/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 20 Jun 2012 23:19:08 -0400
From: "Marcus D. Leech" <[email protected]>
To: Lucas Kindermann <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] TVRX2 Automatic Gain Control problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Hi Marcus,
>
> Firstly, i would like to thank you for the info about the AGC
> configuration and the TDA datasheet. However i'm now worried with that
> you've said about the use of two TVRX2.
>
> "Also, keep in mind that only a *single* TVRX2 can be used per USRP1
> due to I2C addressing limitations."
>
> This is weird, because in fact i'm using two TVRX2 in one USRP1 and i
> can tune both boards, although the tuned frequency for both TVRX2
> channels (RX1 and RX2) is mirrored for both boards on the RXA and RXB
> slots. This would not be a problem for my application because i really
> need that all RX channels from both boards be tuned at the same frequency.
>
> On Gnuradio, i can see the four channels receiving radio signals on
> the tuned frequency (each channel is connected in a different antenna)
> and using the uhd_usrp_probe command i can obtain the ID from both
> boards, each in their correspondent slots. Presume this happens
> because of the data stored at the EEPROM memory in each board.
>
> Now my doubt is: Am i getting the two TVRX2 channels tuned each time i
> set the central frequency for both boards? Or one of the boards isn't
> communicating and it's tuned because the central frequency is stored
> in EEPROM memory and read by the TDA receivers when USRP1 and TVRX2
> boards are turned on?
>
> Cordially,
There is no frequency or parameters information stored in the EEPROMs.
I'm rather surprised that this is working apparently-sanely.
Which may purely be by accident. There is insufficient I2C address
demuxing on the the TDA18272 chip, so you can only have two of
them on any given I2C bus, and the USRP1 only has a single I2C bus.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 9
Date: Thu, 21 Jun 2012 08:56:57 +0300
From: Birhane Alemayoh <[email protected]>
To: [email protected]
Subject: [USRP-users] Using two USRP N200 for capturing uplink and
downlink signals
Message-ID:
<capf4mozckrst0-dei75c+mg1aeqkckan4zethui6pmqasef...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi everyone,
I am planning to capture and analyze GSM signals using two USRP N200
devices; one for downlink and one for uplink.
USRP N200 can't run with external clock like 52 MHz which is suitable
for GSM systems. However, these devices have the option for external
10MHz reference clock.
I have three questions:
1)
Can I achieve my objective of capturing GSM uplink and dwonlink
signals by connecting the two USRP N200s using MIMO cable and by using
the 10MHz reference clock for one USRP N200?
Can the ClockTamer be used an external clock reference to generate 10MHz?
2)
What is the main function of this reference clock? I mean can this
clock help for synchronizing the two USRP N200s in my application?
3)
GSM standards put the following requirement "The BTS shall use a
single frequency source of absolute accuracy better than 0.05 ppm for
both RF frequency generation and clocking the timebase."
How can this be achieved while using USRP N200?
Thank you in advance!!
--
------------------------------
Message: 10
Date: Wed, 20 Jun 2012 23:17:07 -0700
From: Nick Foster <[email protected]>
To: Birhane Alemayoh <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Using two USRP N200 for capturing uplink and
downlink signals
Message-ID:
<CALALHJV2QFHGQhsXHRu4voRtqYS=bc6fytaed3j7rrv11f-...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
If you are just capturing the uplink/downlink, and not actually acting as a
base station, the GSM frequency accuracy requirement doesn't apply. The
N200 should be perfectly well suited for this without an external reference.
--n
On Wed, Jun 20, 2012 at 10:56 PM, Birhane Alemayoh <[email protected]>wrote:
> Hi everyone,
> I am planning to capture and analyze GSM signals using two USRP N200
> devices; one for downlink and one for uplink.
> USRP N200 can't run with external clock like 52 MHz which is suitable
> for GSM systems. However, these devices have the option for external
> 10MHz reference clock.
> I have three questions:
> 1)
> Can I achieve my objective of capturing GSM uplink and dwonlink
> signals by connecting the two USRP N200s using MIMO cable and by using
> the 10MHz reference clock for one USRP N200?
> Can the ClockTamer be used an external clock reference to generate 10MHz?
> 2)
> What is the main function of this reference clock? I mean can this
> clock help for synchronizing the two USRP N200s in my application?
> 3)
> GSM standards put the following requirement "The BTS shall use a
> single frequency source of absolute accuracy better than 0.05 ppm for
> both RF frequency generation and clocking the timebase."
> How can this be achieved while using USRP N200?
> Thank you in advance!!
> --
>
> _______________________________________________
> 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/20120620/dbe1b4d3/attachment-0001.html>
------------------------------
Message: 11
Date: Thu, 21 Jun 2012 01:30:09 -0500
From: Alex Zhang <[email protected]>
To: [email protected]
Subject: [USRP-users] Problem of SBX board to support full-duplex
communications.
Message-ID:
<CA+FEAne8Yw4q1p93Yuw=y-9mghteh_8arfj3ds6cghnd8mm...@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Hi,
As declared by SBX applications nodes, it supports full-duplex, which means
the transceiver can perform transmission and receiving at the same time.
However, within my application, I found the SBX is working as half-duplex,
even I set the antenna as RX2 for receiver, and TX/RX for transmitter.
In my case, I am setting up a point to point link and try the double-way
communcations, i.e, A send a request to B, and B should send a reply back
to B.
The observed behavior is: B can only send the reply by a delay to ensure
the A receive this reply correctly. I am suspecting this is due to the
half-duplex
switching time at A. My test result shows that the B should delay 9ms after
it gets request from A and then the reply can be delivered to A safely.
Otherwise,
A can not receive this reply or the received packet fails in CRC check.
In GNURadio community, many guys complains the PING test fails, due to the
ARP query failure. I add the delay to the ARP reply and this PING test
passed.
So I believe there is some problem in duplex, either caused by incorrect
setting or board issue.
Is there anything I missed, to get the SBX board supporting full-duplex?
--
Alex,
*Dreams can come true ? just believe.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120621/479f3a77/attachment-0001.html>
------------------------------
Message: 12
Date: Thu, 21 Jun 2012 00:04:13 -0700
From: John Malsbury <[email protected]>
To: Huldi Michael <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Transceiver IC max2829
Message-ID:
<can5wegswuljf5-wqopgiwzr9bmdybf894+1p37jawltt22p...@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Huldi,
I would recommend looking into the timed features that are available in the
master branch. If you search for a thread with the subject ""Timed
Commands" feature" in the mailing list archives, you may find some useful
references.
Basically, the time commands to be used to deterministically tune the PLLs,
and you can use these for frequency hopping. This might be a more straight
forward path vs. the microblaze.
-John
On Wed, Jun 20, 2012 at 11:15 PM, Huldi Michael <[email protected]> wrote:
> First I will study this file. Yes I try to realize a frequency hopping.
> Thanks.****
>
> ** **
>
> *From:* John Malsbury [mailto:[email protected]]
> *Sent:* Mittwoch, 20. Juni 2012 01:31
>
> *To:* Huldi Michael
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] Transceiver IC max2829****
>
> ** **
>
> Huldi,
>
> If you're interested in understanding how to interact with the XCVR2450,
> please look at db_xcvr2450.cpp. If you wish to reduce the ref input
> frequency you can decrease the output frequency of the AD9510(may have
> other consequences), or by increase the divide value of the AD9515 on the
> daughterboard. However, it seems that tuning works with the constraints
> currently set in db_xcvr2450.cpp, so I would start with that as a baseline
> for your application.
>
> Just out of curiosity, what are your intentions with the microblaze? Are
> you trying to produce some sort of frequency hopping capability, or are you
> trying to create a standalone radio with the microblaze? There may be an
> easier path.
>
> -John
>
>
>
>
> On 06/19/2012 04:30 AM, Huldi Michael wrote: ****
>
> Yes, with USRP N210 and daughterboard xcvr2450.****
>
> ****
>
> *From:* John Malsbury
> [mailto:[email protected]<[email protected]>]
>
> *Sent:* Dienstag, 19. Juni 2012 13:23
> *To:* Huldi Michael
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] Transceiver IC max2829****
>
> ****
>
> Are you developing this on a usrp, with an xcvr2450?
>
> John
>
>
>
> On Tuesday, June 19, 2012, Huldi Michael <[email protected]> wrote:
> > Hello,
> >
> > In the datasheet of the transceiver IC MAX2829, which is on the
> daughterboard xcvr2450, I read that the reference oscillator input on pin
> 30 need to be 20 ? 44 MHz. But I measured a clock of 50 MHz on this pin.
> Does someone have an explanation for that?
> >
> > I have to know this because I write my own driver in C for the
> transceiver IC. The transceiver IC is driven of my microblaze via SPI.
> Perhaps someone has already done similar work?!
> >
> > Huldi Michael
> >
> >
> >
> > ****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120621/f7ca9343/attachment-0001.html>
------------------------------
Message: 13
Date: Thu, 21 Jun 2012 00:44:04 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Problem of SBX board to support full-duplex
communications.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 06/20/2012 11:30 PM, Alex Zhang wrote:
> Hi,
>
> As declared by SBX applications nodes, it supports full-duplex, which means
> the transceiver can perform transmission and receiving at the same time.
> However, within my application, I found the SBX is working as half-duplex,
> even I set the antenna as RX2 for receiver, and TX/RX for transmitter.
>
> In my case, I am setting up a point to point link and try the double-way
> communcations, i.e, A send a request to B, and B should send a reply back
> to B.
> The observed behavior is: B can only send the reply by a delay to ensure
> the A receive this reply correctly. I am suspecting this is due to the
> half-duplex
> switching time at A. My test result shows that the B should delay 9ms after
> it gets request from A and then the reply can be delivered to A safely.
> Otherwise,
> A can not receive this reply or the received packet fails in CRC check.
> In GNURadio community, many guys complains the PING test fails, due to the
> ARP query failure. I add the delay to the ARP reply and this PING test
> passed.
We had a similar discussion in April. It was working, no?
http://www.mail-archive.com/[email protected]/msg36636.html
http://www.mail-archive.com/[email protected]/msg36656.html
> So I believe there is some problem in duplex, either caused by incorrect
> setting or board issue.
>
> Is there anything I missed, to get the SBX board supporting full-duplex?
>
>
Well, the tunnel.py is gnuradio's most infamous example...
You might consider debugging the setup at a lower level. A simple flow
graph in gnuradio-companion perhaps? Antennas are connected, power
levels expected, frequencies expected etc.
-josh
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 14
Date: Thu, 21 Jun 2012 16:27:33 +0200
From: "Christophe ALEXANDRE" <[email protected]>
To: <[email protected]>
Cc: [email protected]
Subject: [USRP-users] LO phase alignment
Message-ID: <0AB374D11FEE4B69A9594F30A0F4C3CE@fletan>
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
i want to use 2 x (N210 + SBX) for a laser telemetry application.
i need to synchronize clocks, align sample times and also have precise knowledge
of LO phase difference between both N210s.
At the moment, using a mimo cable, i use the following
method : i generate a 1.00005 GHz and inject it on both N210s
with a center frequency equal to 1 GHz.
I get 2 exact 50 kHz complex signals with a constant phase difference. Each time
i start a measure, i get an other phase difference, still constant.
if i change the frequency from 1 GHz to 1.1 GHz then go back
to 1 GHz, the phase difference has changed.
I can't use this for a telemetry application.
i have read this application note :
http://www.ettus.com/content/files/kb/Selecting_an_RF_Daughterboard.pdf
and find this :
Do I plan to implement beamforming or direction finding (DF) capability?
While all daughterboards can be used in a MIMO configuration, this does not
necessarily imply there is phase alignment between the RF chains of one or more
daughterboards. The BasicRx, BasicTX, LFRX and LFTX are exceptions to this,
since they do not include local oscillators that contribute to phase ambiguity
between channels.
The Ettus Research SBX daughterboard utilizes an RF PLL that includes a
resynchronization feature, which can be used to align the LOs across multiple
SBXs, and multiple USRP hardware devices. Using the
UHD (USRP Hardware DriverT), timed SPI commands can drive this
re-synchronization feature. At the time of this writing, this feature is not
supported in the mainline UHD. However, this feature is planned for release in
2012.
I can't work without phase alignment. So my question is :
when could we get this feature in UHD ?
regards.
Christophe ALEXANDRE
Conservatoire National des Arts et M?tiers (CNAM)
Laboratoire CEDRIC-LAETITIA
D?partement EASY
Acc?s 17-1-32, Case 2D2P10
292 rue Saint Martin
75141 PARIS CEDEX 03
FRANCE
email : [email protected]
tel. 0140272699
mob. 0651087311
fax. 0140272994
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120621/bab9566b/attachment-0001.html>
------------------------------
Message: 15
Date: Thu, 21 Jun 2012 07:33:01 -0700
From: John Malsbury <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] LO phase alignment
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
This feature is currently supported in the master branch. I will update
the document when it is moved to release. If you search the list
archives, you can find some information on how to use this feature.
Here's a quote from one such e-mail sent by Josh Blum:
"Use set_command_time and clear_command_time around any call you wish to
schedule.
http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#a191b78b00d051d3d51c2f719361c1fb5
Note that this will remove the tune-to-tune offset variations. But you
will probably still need to perform some level of calibration and expect
this to change a bit with temperature, etc. I'd recommend reading the
mimo and sync app note on the kb as well.
-John
On 06/21/2012 07:27 AM, Christophe ALEXANDRE wrote:
> Hi all,
> i want to use 2 x (N210 + SBX) for a laser telemetry application.
> i need to synchronize clocks, align sample times and also have precise
> knowledge
> of LO phase difference between both N210s.
> At the moment, using a mimo cable, i use the following
> method : i generate a 1.00005 GHz and inject it on both N210s
> with a center frequency equal to 1 GHz.
> I get 2 exact 50 kHz complex signals with a constant phase difference.
> Each time
> i start a measure, i get an other phase difference, still constant.
> if i change the frequency from 1 GHz to 1.1 GHz then go back
> to 1 GHz, the phase difference has changed.
> I can't use this for a telemetry application.
> i have read this application note :
> http://www.ettus.com/content/files/kb/Selecting_an_RF_Daughterboard.pdf
> and find this :
> _Do I plan to implement beamforming or direction finding (DF)
> capability? _
> While all daughterboards can be used in a MIMO configuration, this
> does not necessarily imply there is phase alignment between the RF
> chains of one or more daughterboards. The BasicRx, BasicTX, LFRX and
> LFTX are exceptions to this, since they do not include local
> oscillators that contribute to phase ambiguity between channels.
> The Ettus Research SBX daughterboard utilizes an RF PLL that includes
> a resynchronization feature, which can be used to align the LOs across
> multiple SBXs, and multiple USRP hardware devices. Using the
> UHD (USRP Hardware Driver^(TM)), timed SPI commands can drive this
> re-synchronization feature. At the time of this writing, this feature
> is not supported in the mainline UHD. However, this feature is planned
> for release in 2012.
> I can't work without phase alignment. So my question is :
> *when could we get this feature in UHD ?*
>
> regards.
>
> Christophe ALEXANDRE
> Conservatoire National des Arts et M?tiers (CNAM)
> Laboratoire CEDRIC-LAETITIA
> D?partement EASY
> Acc?s 17-1-32, Case 2D2P10
> 292 rue Saint Martin
> 75141 PARIS CEDEX 03
> FRANCE
> email : [email protected]
> <mailto:[email protected]>
> tel. 0140272699
> mob. 0651087311
> fax. 0140272994
>
>
> _______________________________________________
> 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/20120621/8ef58550/attachment-0001.html>
------------------------------
Message: 16
Date: Thu, 21 Jun 2012 10:32:27 -0500
From: Alex Zhang <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Problem of SBX board to support full-duplex
communications.
Message-ID:
<ca+feancdxggad02knir8gxxhe3gy+rkeokuw8jcco9xhspc...@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Hi Josh,
After last time of discussion, I am using different frequencies for TX/RX
and no transmitting packets are bounded back to the transmitter.
The double-way communications succeed in most the cases, except when the
reply is sent to transmitter too fast, as described in this main chain.
I add a delay for each reply and the communications works well, although
the throughput is not as expected.
This is also the other guy who complain the tunnel.py which fails in ARP
query, and I suggest him to add the delay and it works.
http://lists.gnu.org/archive/html/discuss-gnuradio/2012-06/msg00384.html
So I need to investigate where this delay comes from. Currently, I guess it
is needed by the switching from TX->RX. If so, it really confuses me as I
am using two different frequecies with different antennas.
On Thu, Jun 21, 2012 at 2:44 AM, Josh Blum <[email protected]> wrote:
>
>
> On 06/20/2012 11:30 PM, Alex Zhang wrote:
> > Hi,
> >
> > As declared by SBX applications nodes, it supports full-duplex, which
> means
> > the transceiver can perform transmission and receiving at the same time.
> > However, within my application, I found the SBX is working as
> half-duplex,
> > even I set the antenna as RX2 for receiver, and TX/RX for transmitter.
> >
> > In my case, I am setting up a point to point link and try the double-way
> > communcations, i.e, A send a request to B, and B should send a reply back
> > to B.
> > The observed behavior is: B can only send the reply by a delay to ensure
> > the A receive this reply correctly. I am suspecting this is due to the
> > half-duplex
> > switching time at A. My test result shows that the B should delay 9ms
> after
> > it gets request from A and then the reply can be delivered to A safely.
> > Otherwise,
> > A can not receive this reply or the received packet fails in CRC check.
> > In GNURadio community, many guys complains the PING test fails, due to
> the
> > ARP query failure. I add the delay to the ARP reply and this PING test
> > passed.
>
> We had a similar discussion in April. It was working, no?
> http://www.mail-archive.com/[email protected]/msg36636.html
> http://www.mail-archive.com/[email protected]/msg36656.html
>
> > So I believe there is some problem in duplex, either caused by incorrect
> > setting or board issue.
> >
> > Is there anything I missed, to get the SBX board supporting full-duplex?
> >
> >
>
> Well, the tunnel.py is gnuradio's most infamous example...
>
> You might consider debugging the setup at a lower level. A simple flow
> graph in gnuradio-companion perhaps? Antennas are connected, power
> levels expected, frequencies expected etc.
>
> -josh
>
> >
> >
> > _______________________________________________
> > 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
>
--
Alex,
*Dreams can come true ? just believe.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120621/26253347/attachment-0001.html>
------------------------------
Message: 17
Date: Thu, 21 Jun 2012 17:48:41 +0200
From: "Christophe ALEXANDRE" <[email protected]>
To: "John Malsbury" <[email protected]>,
<[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] LO phase alignment
Message-ID: <37DBE971A9A24433972EB1CEB220878C@fletan>
Content-Type: text/plain; charset="iso-8859-1"
hi John,
i have already read this app note (in fact, i have started with it).
I've only seen a star after phase on table 2 for SBX but no more info.
what is the basic principle used to solve the phase alignment problem ?
can i use this new feature using gnuradio ?
do you have any example (even C++ example) showing how to use it ?
regards.
Christophe ALEXANDRE
Conservatoire National des Arts et M?tiers (CNAM)
Laboratoire CEDRIC-LAETITIA
D?partement EASY
Acc?s 17-1-32, Case 2D2P10
292 rue Saint Martin
75141 PARIS CEDEX 03
FRANCE
email : [email protected]
tel. 0140272699
mob. 0651087311
fax. 0140272994
----- Original Message -----
From: John Malsbury
To: [email protected]
Sent: Thursday, June 21, 2012 4:33 PM
Subject: Re: [USRP-users] LO phase alignment
This feature is currently supported in the master branch. I will update the
document when it is moved to release. If you search the list archives, you can
find some information on how to use this feature. Here's a quote from one such
e-mail sent by Josh Blum:
"Use set_command_time and clear_command_time around any call you wish to
schedule.
http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#a191b78b00d051d3d51c2f719361c1fb5
Note that this will remove the tune-to-tune offset variations. But you will
probably still need to perform some level of calibration and expect this to
change a bit with temperature, etc. I'd recommend reading the mimo and sync
app note on the kb as well.
-John
On 06/21/2012 07:27 AM, Christophe ALEXANDRE wrote:
Hi all,
i want to use 2 x (N210 + SBX) for a laser telemetry application.
i need to synchronize clocks, align sample times and also have precise
knowledge
of LO phase difference between both N210s.
At the moment, using a mimo cable, i use the following
method : i generate a 1.00005 GHz and inject it on both N210s
with a center frequency equal to 1 GHz.
I get 2 exact 50 kHz complex signals with a constant phase difference. Each
time
i start a measure, i get an other phase difference, still constant.
if i change the frequency from 1 GHz to 1.1 GHz then go back
to 1 GHz, the phase difference has changed.
I can't use this for a telemetry application.
i have read this application note :
http://www.ettus.com/content/files/kb/Selecting_an_RF_Daughterboard.pdf
and find this :
Do I plan to implement beamforming or direction finding (DF) capability?
While all daughterboards can be used in a MIMO configuration, this does not
necessarily imply there is phase alignment between the RF chains of one or more
daughterboards. The BasicRx, BasicTX, LFRX and LFTX are exceptions to this,
since they do not include local oscillators that contribute to phase ambiguity
between channels.
The Ettus Research SBX daughterboard utilizes an RF PLL that includes a
resynchronization feature, which can be used to align the LOs across multiple
SBXs, and multiple USRP hardware devices. Using the
UHD (USRP Hardware DriverT), timed SPI commands can drive this
re-synchronization feature. At the time of this writing, this feature is not
supported in the mainline UHD. However, this feature is planned for release in
2012.
I can't work without phase alignment. So my question is :
when could we get this feature in UHD ?
regards.
Christophe ALEXANDRE
Conservatoire National des Arts et M?tiers (CNAM)
Laboratoire CEDRIC-LAETITIA
D?partement EASY
Acc?s 17-1-32, Case 2D2P10
292 rue Saint Martin
75141 PARIS CEDEX 03
FRANCE
email : [email protected]
tel. 0140272699
mob. 0651087311
fax. 0140272994
_______________________________________________
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/20120621/bcf258d6/attachment-0001.html>
------------------------------
Message: 18
Date: Thu, 21 Jun 2012 08:53:23 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] LO phase alignment
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 06/21/2012 08:48 AM, Christophe ALEXANDRE wrote:
> hi John,
>
> i have already read this app note (in fact, i have started with it).
> I've only seen a star after phase on table 2 for SBX but no more info.
>
> what is the basic principle used to solve the phase alignment problem ?
>
Does this example help:
http://files.ettus.com/uhd_docs/manual/html/sync.html#align-los-in-the-front-end-sbx-wbx-n-series
> can i use this new feature using gnuradio ?
>
Yes
> do you have any example (even C++ example) showing how to use it ?
>
Link above.
-josh
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 22, Issue 21
******************************************
