[USRP-users] USRP N210: No control response

Farrukh Aziz farrukh59th at yahoo.com
Thu Jun 21 17:29:58 EDT 2012


Josh,Thanks for the reply. If it was a network configuration error then how come my other N210 is working fine on the same network.

Farrukh Aziz Bhatti
PhD Candidate
Department of Electrical & Computer Engineering
University of Auckland+64 21 02973964



--- On Thu, 21/6/12, usrp-users-request at lists.ettus.com <usrp-users-request at lists.ettus.com> wrote:

From: usrp-users-request at lists.ettus.com <usrp-users-request at lists.ettus.com>
Subject: USRP-users Digest, Vol 22, Issue 21
To: usrp-users at lists.ettus.com
Received: Thursday, 21 June, 2012, 9:00 PM

Send USRP-users mailing list submissions to
    usrp-users at lists.ettus.com

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
    usrp-users-request at lists.ettus.com

You can reach the person managing the list at
    usrp-users-owner at lists.ettus.com

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 <lmkindermann at gmail.com>
To: usrp-users at lists.ettus.com
Cc: Rafael Luiz Cancian <cancian at inf.ufsc.br>, Ant?nio Augusto
    Fr?hlich <guto at lisha.ufsc.br>,    Lucas Caldeira de Oliveira
    <lucasktr at gmail.com>,    Sabrina Perardt <sabrinaperardt at gmail.com>
Subject: [USRP-users] TVRX2 Automatic Gain Control problem
Message-ID:
    <CA+Z-nR6zt8EKoEnH-0C-5R5SyL-777eC8oCDq67WBk6_u1jCGA at 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.
lmkindermann at gmail.com
+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 <tmathews at mail.uh.edu>
To: usrp-users at lists.ettus.com
Subject: [USRP-users] Reusing a block for multiple iterations
Message-ID: <71c0f17116ee.4fe1e6e5 at mail.uh.edu>
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: tmathews at mail.uh.edu



-------------- 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 <nick at ettus.com>
To: Tinajayce Mathews <tmathews at mail.uh.edu>
Cc: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] Reusing a block for multiple iterations
Message-ID:
    <CALALHJXoex0-Y4qRQxEN=eDv3KHKK24hrGrxT2ebEurLn9QZQg at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Wed, Jun 20, 2012 at 1:06 PM, Tinajayce Mathews <tmathews at mail.uh.edu>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: tmathews at mail.uh.edu
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> 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" <mleech at ripnet.com>
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] TVRX2 Automatic Gain Control problem
Message-ID: <4FE24123.8050605 at ripnet.com>
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 <farrukh59th at yahoo.com>
To: USRP user forum <usrp-users at lists.ettus.com>
Subject: [USRP-users] USRP N210: No control response
Message-ID:
    <1340239040.34275.YahooMailClassic at web161302.mail.bf1.yahoo.com>
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 <josh at ettus.com>
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] USRP N210: No control response
Message-ID: <4FE26EDA.9010703 at ettus.com>
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
> USRP-users at lists.ettus.com
> 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 <lmkindermann at gmail.com>
To: "Marcus D. Leech" <mleech at ripnet.com>
Cc: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] TVRX2 Automatic Gain Control problem
Message-ID:
    <CA+Z-nR7Wmf2Y6hqSnj+6qLs2ZwC4jp8ZyUjS7CXK9ybUP7=EZQ at 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 <mleech at ripnet.com>

>
>> 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
> USRP-users at lists.ettus.com
> 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.
lmkindermann at gmail.com
+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" <mleech at ripnet.com>
To: Lucas Kindermann <lmkindermann at gmail.com>
Cc: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] TVRX2 Automatic Gain Control problem
Message-ID: <4FE292AC.20005 at ripnet.com>
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 <birhanea at gmail.com>
To: usrp-users at lists.ettus.com
Subject: [USRP-users] Using two USRP N200 for capturing uplink and
    downlink    signals
Message-ID:
    <CAPF4MOzcKRst0-dei75C+MG1aeQKCkaN4ZeTHui6PmqaseFqEw at 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 <nick at ettus.com>
To: Birhane Alemayoh <birhanea at gmail.com>
Cc: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] Using two USRP N200 for capturing uplink and
    downlink signals
Message-ID:
    <CALALHJV2QFHGQhsXHRu4voRtqYS=BC6fYtAed3J7RRv11f-C+w at 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 <birhanea at gmail.com>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
> USRP-users at lists.ettus.com
> 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 <cingular.alex at gmail.com>
To: usrp-users at lists.ettus.com
Subject: [USRP-users] Problem of SBX board to support full-duplex
    communications.
Message-ID:
    <CA+FEAne8Yw4q1p93Yuw=Y-9MGHTeh_8ARfJ3Ds6cgHnD8mmw1A at 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 <john.malsbury at ettus.com>
To: Huldi Michael <huldm1 at bfh.ch>
Cc: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] Transceiver IC max2829
Message-ID:
    <CAN5WegSWULjf5-wQoPgiwZR9BMDybF894+1P37JAWLTT22p10w at 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 <huldm1 at bfh.ch> wrote:

> First I will study this file. Yes I try to realize a frequency hopping.
> Thanks.****
>
> ** **
>
> *From:* John Malsbury [mailto:john.malsbury at ettus.com]
> *Sent:* Mittwoch, 20. Juni 2012 01:31
>
> *To:* Huldi Michael
> *Cc:* usrp-users at lists.ettus.com
> *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:john.malsbury at ettus.com<john.malsbury at ettus.com>]
>
> *Sent:* Dienstag, 19. Juni 2012 13:23
> *To:* Huldi Michael
> *Cc:* usrp-users at lists.ettus.com
> *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 <huldm1 at bfh.ch> 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 <josh at ettus.com>
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] Problem of SBX board to support full-duplex
    communications.
Message-ID: <4FE2D0C4.4090506 at ettus.com>
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/discuss-gnuradio@gnu.org/msg36636.html
http://www.mail-archive.com/discuss-gnuradio@gnu.org/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
> USRP-users at lists.ettus.com
> 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" <christophe.alexandre at cnam.fr>
To: <usrp-users at lists.ettus.com>
Cc: jean-pierre.wallerand at cnam.fr
Subject: [USRP-users] LO phase alignment
Message-ID: <0AB374D11FEE4B69A9594F30A0F4C3CE at 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 : christophe.alexandre at cnam.fr               
 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 <john.malsbury at ettus.com>
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] LO phase alignment
Message-ID: <4FE3309D.80209 at ettus.com>
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 : christophe.alexandre at cnam.fr 
> <mailto:christophe.alexandre at cnam.fr>
>  tel. 0140272699
>  mob. 0651087311
>  fax. 0140272994
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> 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 <cingular.alex at gmail.com>
To: josh at ettus.com
Cc: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] Problem of SBX board to support full-duplex
    communications.
Message-ID:
    <CA+FEAncDXGGad02KNiR8GXXhE3Gy+RkeoKUW8JCCO9XhSpcfww at 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 <josh at ettus.com> 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/discuss-gnuradio@gnu.org/msg36636.html
> http://www.mail-archive.com/discuss-gnuradio@gnu.org/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
> > USRP-users at lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> 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" <christophe.alexandre at cnam.fr>
To: "John Malsbury" <john.malsbury at ettus.com>,
    <usrp-users at lists.ettus.com>
Cc: jean-pierre.wallerand at cnam.fr
Subject: Re: [USRP-users] LO phase alignment
Message-ID: <37DBE971A9A24433972EB1CEB220878C at 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 : christophe.alexandre at cnam.fr               
 tel. 0140272699 
 mob. 0651087311
 fax. 0140272994    
 

  ----- Original Message ----- 
  From: John Malsbury 
  To: usrp-users at lists.ettus.com 
  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 : christophe.alexandre at cnam.fr               
     tel. 0140272699 
     mob. 0651087311
     fax. 0140272994    
     


_______________________________________________
USRP-users mailing list
USRP-users at lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




------------------------------------------------------------------------------


  _______________________________________________
  USRP-users mailing list
  USRP-users at lists.ettus.com
  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 <josh at ettus.com>
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] LO phase alignment
Message-ID: <4FE34373.2020607 at ettus.com>
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
USRP-users at lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


End of USRP-users Digest, Vol 22, Issue 21
******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120621/9a1311d4/attachment-0002.html>


More information about the USRP-users mailing list