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: X3X0 SBX corrupted samples? (LEMENAGER Claude)
2. uhd_cal_tx_iq_balance skips wide frequency range (Urban Hakansson)
3. Re: Loading USRP X3x0 by baseband processing functions
(Marcus M?ller)
4. Re: ATR registers (Ian Buckley)
5. Re: ATR registers (Per Zetterberg)
6. Re: TX and RX paths sharing a coherent LO (Matt Ettus)
7. Re: uhd_cal_tx_iq_balance skips wide frequency range
(Michael West)
8. Re: TX and RX paths sharing a coherent LO (Rickard Radio)
9. Re: ATR registers (Ian Buckley)
10. Re: X3X0 SBX corrupted samples? (LEMENAGER Claude)
----------------------------------------------------------------------
Message: 1
Date: Thu, 9 Oct 2014 18:10:11 +0200
From: LEMENAGER Claude <[email protected]>
To: Herv? BOEGLEN <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X3X0 SBX corrupted samples?
Message-ID:
<30709_1412871017_5436b369_30709_3470_1_440f3d4f-73d1-4b54-ba8b-026202623...@thsonea01hub02p.one.grp>
Content-Type: text/plain; charset="iso-8859-1"
Thank you very much Herv?.
Claude Lem?nager
[@@ THALES GROUP INTERNAL @@]
De : Herv? BOEGLEN [mailto:[email protected]]
Envoy? : jeudi 9 octobre 2014 16:48
? : LEMENAGER Claude
Cc : [email protected]
Objet : Re: [USRP-users] X3X0 SBX corrupted samples?
Hello Claude,
I had the same type of problem with an X310 + 2 CBX boards (see my past posts
on the list). The received signal on channel B was always worse than channel A.
Indeed, on channel B the noise floor was 40 dB higher than on channel A.
My problem was solved by upgrading to UHD 003.007.003 (+ new firmware images).
As Martin Braun mentioned, there were some bugs in the FPGA code solved by this
release (at least for my problem).
Concerning the LO locking, I have a GPSDO kit and get sometimes the lo_locked
not locked message but It happens in average once every 10 runs.
Best regards
Herv?
Le 09/10/2014 15:30, LEMENAGER Claude via USRP-users a ?crit :
Hello,
I sample at least two channels (SBX 120) from one or multiple X310 boards each
equipped with two SBX radio boards.
I uses NIUSRPRIO_PCIE==>UHD003.007.002 ==>Gnuradio 3.7.5 (built for this UHD
under UBUNTU 14.04LTS).
The input is connected to a CW generator. The channels definition is A:0 B:0,
antenna is RX2 in all cases.
The problems :
1) I receive a warning concerning lo_locked no locked after timeout for
each channel (I read a discuss where this fact was given)
2) When I connect the A:0 channel on a gnuradio scope, this seems OK (I
and Q parts). When I connect a B:0 channel (from any X310 board) I receive the
CW wave plus spurious (sort of dirac through a filter) generally starting on Q
channel but not only. This look like an erroneous sample (digitally speaking
for example just an incorrect bit in the LSBs) before DDC. The spurious looks
like periodic but the period seems to change with radio frequency (to confirm)
Did somebody encounters this problem?
If yes, is there a solution.
I plan to try to reproduce this (or to see if it's the same) with UHD directly
accessed BY a C++ application.
Regards,
Claude Lem?nager
P.S. Conclusion about preceding discussion (june) about PCIe interface: The HP
PC on which I made my firsts experiences was equipped with one of the first
generation PCIe chip. So it failed to interface with X310. I now uses a last
generation pc and then there is no problem except for what I mention above.
Thanks for support.
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[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/20141009/6599757d/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 9 Oct 2014 11:57:32 -0400 (EDT)
From: Urban Hakansson <[email protected]>
To: [email protected]
Subject: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency range
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi everybody,
I am trying to calibrate my N210 SBX daughterboard using the three calibration
scripts uhd_cal_rx_iq_balance, uhd_cal_tx_iq_balance,and uhd_cal_tx_dc_offset
using different values for freq_start, freq_stop, and freq_step.
uhd_cal_tx_iq_balance utility that is not behaving as I expected.
(uhd_cal_rx_iq_balance and uhd_cal_tx_dc_offset give me no problems).
If I run uhd_cal_tx_iq_balance with any other values besides the default values
it will skip approximately 300MHz of frequencies from 790 MHz to ~ 1100MHz.
Here are a few of my attempts.
uhd_cal_tx_iq_balance --freq_start 500000000
uhd_cal_tx_iq_balance --freq_start 600000000
uhd_cal_tx_iq_balance --freq_start 700000000
uhd_cal_tx_iq_balance --freq_start 785000000
uhd_cal_tx_iq_balance --verbose --freq_step 100000
uhd_cal_tx_iq_balance --verbose --freq_step 110000
uhd_cal_tx_iq_balance --verbose --freq_step 225000
uhd_cal_tx_iq_balance --verbose --freq_step 900000
uhd_cal_tx_iq_balance --verbose --freq_step 1000000
uhd_cal_tx_iq_balance --verbose --freq_step 1100000
uhd_cal_tx_iq_balance --verbose --freq_step 2000000
...
uhd_cal_tx_iq_balance --verbose --freq_step 7300000
uhd_cal_tx_iq_balance always stops just before 790MHz and just sits there, but
does not abort, and after a really long time continues at ~ 1100MHz and
continues all the way to 4370MHz without any further gaps.
I attach the calibration scripts I am using and the three csv files for one
example, uhd_cal_tx_iq_balance --verbose --freq_step 225000.
General background information about my environment:
Fedora 17 Linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5);
Boost_104800; UHD_003.007.001-0-unknown
N210 informationfrom uhd_usrp_probe:
| Device: USRP2 / N-Series Device
| _____________________________________________________
| /
| | Mboard: N210r4
| | hardware: 2577
| | mac-addr: 00:80:2f:0a:e6:15
| | ip-addr: 192.168.2.199
| | subnet: 255.255.255.255
| | gateway: 255.255.255.255
| | gpsdo: none
| | serial: F4A09C
| | FW Version: 12.4
| | FPGA Version: 10.1
What could the cause of this behaviour be? Are there only certain combination
of values that work? What do I need to do to make uhd_tx_iq_balance not hang
right before 790MHz?
Thanks for you consideration.
Regards,
Urban Hakansson
Senior Software Engineer
Tecore Networks
Phone: +1 410 872 6315
Fax: +1 410 872 6010
Email: [email protected]
Urban Hakansson Senior Software Engineer Tecore Networks Phone: +1 410 872 6315
Fax: +1 410 872 6010 Email: [email protected]
Urban Hakansson
Senior Software Engineer
Tecore Networks
Phone: +1 410 872 6315
Fax: +1 410 872 6010
Email: [email protected]
This
e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected]), then delete the message in its entirety. Thank you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rx_iq_cal_v0.2_F4D354.csv
Type: text/csv
Size: 857968 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141009/7b6e5ef4/attachment-0003.csv>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tx_dc_cal_v0.2_F4D354.csv
Type: text/csv
Size: 917203 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141009/7b6e5ef4/attachment-0004.csv>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tx_iq_cal_v0.2_F4D354.csv
Type: text/csv
Size: 766048 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141009/7b6e5ef4/attachment-0005.csv>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uhd_cal_rx_iq_balance
Type: application/x-executable
Size: 285024 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141009/7b6e5ef4/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uhd_cal_tx_dc_offset
Type: application/x-executable
Size: 293328 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141009/7b6e5ef4/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uhd_cal_tx_iq_balance
Type: application/x-executable
Size: 293408 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141009/7b6e5ef4/attachment-0005.bin>
------------------------------
Message: 3
Date: Thu, 09 Oct 2014 19:19:02 +0200
From: Marcus M?ller <[email protected]>
To: Birhane Alemayoh <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Loading USRP X3x0 by baseband processing
functions
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hi Birhane,
On 09.10.2014 19:04, Birhane Alemayoh wrote:
>> However, a complete GSM stack is a big thing, and I don't see much use in
>> implementing it in FPGA rather than host code, especially since working GSM
>> base stations already exist (openBTS).
>>
> My system is supposed to capture and process downlink and uplink GSM
> signals in real time from the air using this X310 device.
OpenBTS [0] does that with USRPs on a host.
> My system is
> shall work under frequency hopping environment which requires strict real
> time requirement.
Works.
> We believe that this requirement is difficult to handle
> by processing the signal in the host.
It is. But it has been done :)
> This is the reason why we prefer to
> write FPGA code.
Wow, that's dedication. I'd *definitely* spend more time making sure
things can't be done in host code than spending manyears of development
on FPGA hardware.
Since you're asking us for advice, I'd expect you / your company to be
not very experienced in the implementation of communication standards on
FPGAs -- deciding early you want to do *everything* in the FPGA this
early into your development doesn't sound very wise. Re-inventing the
wheel actually sounds bad. And not looking up the capabilities of
openBTS with USRPs instead of believing requirements are hard to meet
with software sounds like a mistake, but one that is easily corrected ;)
> So what do you comment/recommend for this?
Doing what all the industry has been doing for 20 years: Doing only the
really necessary part of processing in hardware, and moving higher level
functionality to general purpose processors. Seriously, look at the
Osmocom BB project [1]: Even the Motorola C115 [2] brick of a cheap
consumer mobile phone does its baseband processing in software.
Seriously, I think it will be easier to instantiate a general purpose
CPU in the FPGA and just run the baseband processing software on there
rather than doing everything in real FPGA hardware.
> Thank you
Hope you find the links I share helpful!
Greetings,
Marcus
[0]http://openbts.org/
[1]http://bb.osmocom.org/trac/
[2]http://www.gsmarena.com/motorola_c115-876.php
------------------------------
Message: 4
Date: Thu, 9 Oct 2014 10:50:51 -0700
From: Ian Buckley <[email protected]>
To: Per Zetterberg <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] ATR registers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Per,
A couple of quick observations.
1) The example you present below writes both the IDLE state and RX state with
the same values (atr_rx) so you would not see a transition of GPIO pins between
those states.
2) You haven't shown a configuration write ti the DDR register which is defined
as:
The CTRL reg determines whether the GPIO is driven by internal state changes in
the radio streaming control logic or if it just works like traditional
bit-banged GPIO. 0=Manual mode 1=ATR
The DDR reg (data direction register) sets port direction?where a 1 is an
output, 0 is an input
The OUT reg controls the bit values driven on output configured GPIOs.
Hope this helps
-Ian
On Oct 9, 2014, at 4:31 AM, Per Zetterberg via USRP-users
<[email protected]> wrote:
> Dear List,
>
>
> I am trying to use the ATR registers with a basic daughterboard. I do:
>
> db_iface->set_pin_ctrl(m_unit,mask_write,mask_write);
> db_iface->set_atr_reg(m_unit,
> uhd::usrp::dboard_iface::ATR_REG_IDLE,atr_rx,mask_write);
> db_iface->set_atr_reg(m_unit,
> uhd::usrp::dboard_iface::ATR_REG_TX_ONLY,atr_tx,mask_write);
> db_iface->set_atr_reg(m_unit,
> uhd::usrp::dboard_iface::ATR_REG_RX_ONLY,atr_rx,mask_write);
>
>
> Upon writing these values the settings of ATR_REG_IDLE should immediately
> take effect until we ask the USRP to send or receive samples. But this does
> not seem to be the case. Am I making a mistake?
>
> BR/
> Per
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 5
Date: Thu, 9 Oct 2014 18:29:35 +0000
From: Per Zetterberg <[email protected]>
To: Ian Buckley <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] ATR registers
Message-ID: <[email protected]>
Content-Type: text/plain; charset="Windows-1252"
Thank you for your answer Ian!
I know I had the same setting for IDLE and RX. I do have a set_pin_ctrl call.
I tried DDR also but my understanding is that it shouldn't matter for ATR but
only for GPIO.
Thanks again,
Per
________________________________________
From: Ian Buckley [[email protected]]
Sent: Thursday, October 09, 2014 7:50 PM
To: Per Zetterberg
Cc: [email protected]
Subject: Re: [USRP-users] ATR registers
Per,
A couple of quick observations.
1) The example you present below writes both the IDLE state and RX state with
the same values (atr_rx) so you would not see a transition of GPIO pins between
those states.
2) You haven't shown a configuration write ti the DDR register which is defined
as:
The CTRL reg determines whether the GPIO is driven by internal state changes in
the radio streaming control logic or if it just works like traditional
bit-banged GPIO. 0=Manual mode 1=ATR
The DDR reg (data direction register) sets port direction?where a 1 is an
output, 0 is an input
The OUT reg controls the bit values driven on output configured GPIOs.
Hope this helps
-Ian
On Oct 9, 2014, at 4:31 AM, Per Zetterberg via USRP-users
<[email protected]> wrote:
> Dear List,
>
>
> I am trying to use the ATR registers with a basic daughterboard. I do:
>
> db_iface->set_pin_ctrl(m_unit,mask_write,mask_write);
> db_iface->set_atr_reg(m_unit,
> uhd::usrp::dboard_iface::ATR_REG_IDLE,atr_rx,mask_write);
> db_iface->set_atr_reg(m_unit,
> uhd::usrp::dboard_iface::ATR_REG_TX_ONLY,atr_tx,mask_write);
> db_iface->set_atr_reg(m_unit,
> uhd::usrp::dboard_iface::ATR_REG_RX_ONLY,atr_rx,mask_write);
>
>
> Upon writing these values the settings of ATR_REG_IDLE should immediately
> take effect until we ask the USRP to send or receive samples. But this does
> not seem to be the case. Am I making a mistake?
>
> BR/
> Per
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 6
Date: Thu, 9 Oct 2014 11:30:56 -0700
From: Matt Ettus <[email protected]>
To: Rickard Radio <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] TX and RX paths sharing a coherent LO
Message-ID:
<CAN=1kn9b_kkq0yhs4jewvvtxyut7799fpbrtan4ru0ktqrm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Every LO in the system, whether for TX or for RX is generated independently
by locking to the same master reference, and so every LO will exhibit
mutual phase noise to the others. There isn't a mechanism to generate a
single LO and share it between boards.
To be clear, the frequencies will all be exactly the same, and the phase
will be constant between them. The only thing you lose is that they have
different uncorrelated phase noise between them.
Matt
On Wed, Oct 8, 2014 at 2:44 PM, Rickard Radio via USRP-users <
[email protected]> wrote:
> OK, interesting.
>
> Is it the exact same situation with two (or more) different transmitters
> like TX1-TX2 as you explained here with TX-RX, namely that each path always
> have physically different LO's but they are generated from the same 10MHz
> reference?
> Or can TX1-TX2 (or RX1-RX2) indeed use physically the same LO (i.e. with
> same phase noise)? Or is that impossible too?
>
> That is, is there any difference with synched TX-RX compared to synched
> TX1-TX2 (or RX1-RX2)?
>
> The thing is that in my experiment I preferably would like to use
> physically the same LO for all RX's and TX's (i.e., with exactly the same
> frequency and jitter etc.) but perhaps I need to resort to synched, but
> still ever so slightly different, LO's for each path.
>
> Regards,
> Rickard
>
> On Wed, Oct 8, 2014 at 7:19 PM, Marcus M?ller <[email protected]>
> wrote:
>
>> No, the LOs used for mixing are individually generated from the same
>> 10MHz reference; they thus don't drift away from each other, but they don't
>> share the same jitter etc. However, the Ettus daughterboards usually use
>> rather decent synths, and thus the LO quality should be dominated by the
>> quality of the reference clock -- which again, is quite ok, for most
>> applications, and can be further optimized by GPS-disciplining the
>> reference.
>>
>> Usually, that's how close you can get to shared LO if you want
>> independent TX and RX mixers.
>>
>> Greetings,
>> Marcus
>>
>>
>> On 08.10.2014 19:04, Rickard Radio via USRP-users wrote:
>>
>> Sounds good!
>>
>> Does this mean it really shares the same LO, i.e., also with the same and
>> uniquely occurring phase noise shared to all paths?! (I want that!)
>>
>> Regards,
>> Rickard
>>
>>
>>
>> On Wed, Oct 8, 2014 at 6:54 PM, Marcus M?ller <[email protected]>
>> <[email protected]>
>> wrote:
>>
>>
>> Hi Rickard,
>>
>> all the LOs are synthesized from the same motherboard reference, so Q1 is
>> answered with "you get that for free".
>> Q2 is "yes".
>> Q3 gets the answer "if you want to use definite times when sampling, use
>> the timed commands feature of UHD".
>> :)
>>
>> Greetings,
>> Marcus
>>
>> On 08.10.2014 18:48, Rickard Radio via USRP-users wrote:
>>
>> Dear usrp-users,
>>
>> I am interested in coherently LO-mixing different TX and RX paths for some
>> experiments.
>>
>> Q1: Which options exist to use the same(?) coherent(!) LO for different TX
>> and RX paths on the USRPs (N210 and/or B210)?
>> Q2: Related, with the N210s and the MIMO cable, can I obtain and use a
>> coherently shared LO for different TX and RX paths?
>> Q3: Follow up - do I need something else or in addition ?
>>
>> Regards,
>> Rickard
>>
>>
>>
>>
>> ______________________________
>> _________________
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141009/7afbfd4a/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 9 Oct 2014 12:03:08 -0700
From: Michael West <[email protected]>
To: Urban Hakansson <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency
range
Message-ID:
<cam4xkrodxzdhbs+xdx-gw2xq004g8stmq69vfovniznt9vw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Urban,
If I am understanding you correctly, you are saying that there is no
calibration data for those frequencies in the resulting file. That does
not mean the frequencies are being skipped by the utility. That only means
that a suppression of over 30 dB could not be achieved for those
frequencies, so no correction data was saved. You can set a lower
threshold for the minimum suppression by changing the value in the
following line in each IQ calibration utility:
if (best_suppression > 30){ //most likely valid, keep result
Best regards,
Michael
On Thu, Oct 9, 2014 at 8:57 AM, Urban Hakansson via USRP-users <
[email protected]> wrote:
> Hi everybody,
>
> I am trying to calibrate my N210 SBX daughterboard using the three
> calibration scripts uhd_cal_rx_iq_balance, uhd_cal_tx_iq_balance,and
> uhd_cal_tx_dc_offset using different values for freq_start, freq_stop, and
> freq_step.
>
> uhd_cal_tx_iq_balance utility that is not behaving as I expected.
> (uhd_cal_rx_iq_balance and uhd_cal_tx_dc_offset give me no problems).
>
> If I run uhd_cal_tx_iq_balance with any other values besides the default
> values it will skip approximately 300MHz of frequencies from 790 MHz to ~
> 1100MHz.
>
> Here are a few of my attempts.
>
> uhd_cal_tx_iq_balance --freq_start 500000000
> uhd_cal_tx_iq_balance --freq_start 600000000
> uhd_cal_tx_iq_balance --freq_start 700000000
> uhd_cal_tx_iq_balance --freq_start 785000000
> uhd_cal_tx_iq_balance --verbose --freq_step 100000
> uhd_cal_tx_iq_balance --verbose --freq_step 110000
> uhd_cal_tx_iq_balance --verbose --freq_step 225000
> uhd_cal_tx_iq_balance --verbose --freq_step 900000
> uhd_cal_tx_iq_balance --verbose --freq_step 1000000
> uhd_cal_tx_iq_balance --verbose --freq_step 1100000
> uhd_cal_tx_iq_balance --verbose --freq_step 2000000
> ...
> uhd_cal_tx_iq_balance --verbose --freq_step 7300000
>
> uhd_cal_tx_iq_balance always stops just before 790MHz and just sits there,
> but does not abort, and after a really long time continues at ~ 1100MHz and
> continues all the way to 4370MHz without any further gaps.
>
> I attach the calibration scripts I am using and the three csv files for
> one example, uhd_cal_tx_iq_balance --verbose --freq_step 225000.
>
> General background information about my environment:
> Fedora 17 Linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5);
> Boost_104800; UHD_003.007.001-0-unknown
>
> N210 informationfrom uhd_usrp_probe:
> | Device: USRP2 / N-Series Device
> | _____________________________________________________
> | /
> | | Mboard: N210r4
> | | hardware: 2577
> | | mac-addr: 00:80:2f:0a:e6:15
> | | ip-addr: 192.168.2.199
> | | subnet: 255.255.255.255
> | | gateway: 255.255.255.255
> | | gpsdo: none
> | | serial: F4A09C
> | | FW Version: 12.4
> | | FPGA Version: 10.1
>
> What could the cause of this behaviour be? Are there only certain
> combination of values that work? What do I need to do to make
> uhd_tx_iq_balance not hang right before 790MHz?
>
> Thanks for you consideration.
>
> Regards,
>
> Urban Hakansson
> Senior Software Engineer
> Tecore Networks
> Phone: +1 410 872 6315
> Fax: +1 410 872 6010
> Email: [email protected]
>
>
> Urban Hakansson Senior Software Engineer Tecore Networks Phone: +1 410
> 872 6315 Fax: +1 410 872 6010 Email: [email protected]
>
> Urban Hakansson
> Senior Software Engineer
> Tecore Networks
> Phone: +1 410 872 6315
> Fax: +1 410 872 6010
> Email: [email protected]
>
>
>
>
> This e-mail may contain privileged, confidential, copyrighted or other
> legally protected information, and is intended exclusively for the intended
> recipient. If you are not the intended recipient (even if the e-mail
> address above is yours), you may not review, store, use, copy, disclose or
> retransmit it in any form. If you are not the intended recipient or
> otherwise have received this by mistake, please immediately notify the
> sender by return e-mail (or [email protected]), then delete the message
> in its entirety. Thank you.
> _______________________________________________
> 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/20141009/1d73cb62/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 9 Oct 2014 21:42:47 +0200
From: Rickard Radio <[email protected]>
To: Matt Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] TX and RX paths sharing a coherent LO
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Thanks for all informative answers - they clarify this issue very well for me.
It will be more interesting and informative to practically experiment with
this, given this knowledge.
Rickard
> On 9 okt 2014, at 20:30, Matt Ettus <[email protected]> wrote:
>
>
> Every LO in the system, whether for TX or for RX is generated independently
> by locking to the same master reference, and so every LO will exhibit mutual
> phase noise to the others. There isn't a mechanism to generate a single LO
> and share it between boards.
>
> To be clear, the frequencies will all be exactly the same, and the phase will
> be constant between them. The only thing you lose is that they have
> different uncorrelated phase noise between them.
>
> Matt
>
>
>> On Wed, Oct 8, 2014 at 2:44 PM, Rickard Radio via USRP-users
>> <[email protected]> wrote:
>> OK, interesting.
>>
>> Is it the exact same situation with two (or more) different transmitters
>> like TX1-TX2 as you explained here with TX-RX, namely that each path always
>> have physically different LO's but they are generated from the same 10MHz
>> reference?
>> Or can TX1-TX2 (or RX1-RX2) indeed use physically the same LO (i.e. with
>> same phase noise)? Or is that impossible too?
>>
>> That is, is there any difference with synched TX-RX compared to synched
>> TX1-TX2 (or RX1-RX2)?
>>
>> The thing is that in my experiment I preferably would like to use physically
>> the same LO for all RX's and TX's (i.e., with exactly the same frequency and
>> jitter etc.) but perhaps I need to resort to synched, but still ever so
>> slightly different, LO's for each path.
>>
>> Regards,
>> Rickard
>>
>>> On Wed, Oct 8, 2014 at 7:19 PM, Marcus M?ller <[email protected]>
>>> wrote:
>>> No, the LOs used for mixing are individually generated from the same 10MHz
>>> reference; they thus don't drift away from each other, but they don't share
>>> the same jitter etc. However, the Ettus daughterboards usually use rather
>>> decent synths, and thus the LO quality should be dominated by the quality
>>> of the reference clock -- which again, is quite ok, for most applications,
>>> and can be further optimized by GPS-disciplining the reference.
>>>
>>> Usually, that's how close you can get to shared LO if you want independent
>>> TX and RX mixers.
>>>
>>> Greetings,
>>> Marcus
>>>
>>>
>>>> On 08.10.2014 19:04, Rickard Radio via USRP-users wrote:
>>>> Sounds good!
>>>>
>>>> Does this mean it really shares the same LO, i.e., also with the same and
>>>> uniquely occurring phase noise shared to all paths?! (I want that!)
>>>>
>>>> Regards,
>>>> Rickard
>>>>
>>>>
>>>>
>>>> On Wed, Oct 8, 2014 at 6:54 PM, Marcus M?ller <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Rickard,
>>>>>
>>>>> all the LOs are synthesized from the same motherboard reference, so Q1 is
>>>>> answered with "you get that for free".
>>>>> Q2 is "yes".
>>>>> Q3 gets the answer "if you want to use definite times when sampling, use
>>>>> the timed commands feature of UHD".
>>>>> :)
>>>>>
>>>>> Greetings,
>>>>> Marcus
>>>>>
>>>>> On 08.10.2014 18:48, Rickard Radio via USRP-users wrote:
>>>>>
>>>>> Dear usrp-users,
>>>>>
>>>>> I am interested in coherently LO-mixing different TX and RX paths for some
>>>>> experiments.
>>>>>
>>>>> Q1: Which options exist to use the same(?) coherent(!) LO for different TX
>>>>> and RX paths on the USRPs (N210 and/or B210)?
>>>>> Q2: Related, with the N210s and the MIMO cable, can I obtain and use a
>>>>> coherently shared LO for different TX and RX paths?
>>>>> Q3: Follow up - do I need something else or in addition ?
>>>>>
>>>>> Regards,
>>>>> Rickard
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ______________________________
>>>>> _________________
>>>>> USRP-users mailing
>>>>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>> _______________________________________________
>>> 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/20141009/2b8d8b05/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 9 Oct 2014 12:49:46 -0700
From: Ian Buckley <[email protected]>
To: Per Zetterberg <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] ATR registers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Per,
Recent versions of UHD include the example uhd/host/examples/fpgpio.cpp (for
X300) which gives an example of writing ATR code.
-Ian
On Oct 9, 2014, at 11:29 AM, Per Zetterberg <[email protected]> wrote:
> Thank you for your answer Ian!
>
> I know I had the same setting for IDLE and RX. I do have a set_pin_ctrl
> call. I tried DDR also but my understanding is that it shouldn't matter for
> ATR but only for GPIO.
>
> Thanks again,
> Per
>
> ________________________________________
> From: Ian Buckley [[email protected]]
> Sent: Thursday, October 09, 2014 7:50 PM
> To: Per Zetterberg
> Cc: [email protected]
> Subject: Re: [USRP-users] ATR registers
>
> Per,
> A couple of quick observations.
> 1) The example you present below writes both the IDLE state and RX state with
> the same values (atr_rx) so you would not see a transition of GPIO pins
> between those states.
> 2) You haven't shown a configuration write ti the DDR register which is
> defined as:
>
> The CTRL reg determines whether the GPIO is driven by internal state changes
> in the radio streaming control logic or if it just works like traditional
> bit-banged GPIO. 0=Manual mode 1=ATR
> The DDR reg (data direction register) sets port direction?where a 1 is an
> output, 0 is an input
> The OUT reg controls the bit values driven on output configured GPIOs.
>
> Hope this helps
> -Ian
>
> On Oct 9, 2014, at 4:31 AM, Per Zetterberg via USRP-users
> <[email protected]> wrote:
>
>> Dear List,
>>
>>
>> I am trying to use the ATR registers with a basic daughterboard. I do:
>>
>> db_iface->set_pin_ctrl(m_unit,mask_write,mask_write);
>> db_iface->set_atr_reg(m_unit,
>> uhd::usrp::dboard_iface::ATR_REG_IDLE,atr_rx,mask_write);
>> db_iface->set_atr_reg(m_unit,
>> uhd::usrp::dboard_iface::ATR_REG_TX_ONLY,atr_tx,mask_write);
>> db_iface->set_atr_reg(m_unit,
>> uhd::usrp::dboard_iface::ATR_REG_RX_ONLY,atr_rx,mask_write);
>>
>>
>> Upon writing these values the settings of ATR_REG_IDLE should immediately
>> take effect until we ask the USRP to send or receive samples. But this does
>> not seem to be the case. Am I making a mistake?
>>
>> BR/
>> Per
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 10
Date: Fri, 10 Oct 2014 16:46:22 +0200
From: LEMENAGER Claude <[email protected]>
To: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] X3X0 SBX corrupted samples?
Message-ID:
<30803_1412952393_5437f149_30803_2883_1_59957d668d245c4eb38e8f85c054e901077601c...@thsonea01cms09p.one.grp>
Content-Type: text/plain; charset="iso-8859-1"
Hello Marcus,
I am working at 950MHz (RF) sampling 25MHz.
One thing is curious: In grc I specify External for both Clock source and Time
but when running I obtain:
...
- References Initialized to internal sources
WARN: Sensor 'lo_locked' failed to lock within timeout on channel 0
... (other channels)
>From UHD-FFT example (QT), I obtain the same but the indicator 'lo_locked' is
>in locked state.
And more curiously, I use an Octoclock as external source, the PPS led is not
synchronized between Octoclock and X310 (even between X310 despite the fact I
set them to External References! (seems not to be aware from the settings)
With the respect of the images, I used the one of the 20 Aug 2014
(003.007.002-48) but have seen it exists one of 21 Aug-2014 (003.007.002-440)
(dates from tags in directory). I will try with this one.
Thank you,
Claude
De : Marcus M?ller [mailto:[email protected]]
Envoy? : jeudi 9 octobre 2014 15:39
? : [email protected]
Objet : Re: [USRP-users] X3X0 SBX corrupted samples?
Hello Mr. Lem?nager,
the warning that the LO is not locked is severe in principle; are you using an
external reference clock?
Could you paste the complete warning?
At which frequencies are you working?
Greetings,
Marcus
On 09.10.2014 15:30, LEMENAGER Claude via USRP-users wrote:
Hello,
I sample at least two channels (SBX 120) from one or multiple X310 boards each
equipped with two SBX radio boards.
I uses NIUSRPRIO_PCIE==>UHD003.007.002 ==>Gnuradio 3.7.5 (built for this UHD
under UBUNTU 14.04LTS).
The input is connected to a CW generator. The channels definition is A:0 B:0,
antenna is RX2 in all cases.
The problems :
1) I receive a warning concerning lo_locked no locked after timeout for each
channel (I read a discuss where this fact was given)
2) When I connect the A:0 channel on a gnuradio scope, this seems OK (I and
Q parts). When I connect a B:0 channel (from any X310 board) I receive the CW
wave plus spurious (sort of dirac through a filter) generally starting on Q
channel but not only. This look like an erroneous sample (digitally speaking
for example just an incorrect bit in the LSBs) before DDC. The spurious looks
like periodic but the period seems to change with radio frequency (to confirm)
Did somebody encounters this problem?
If yes, is there a solution.
I plan to try to reproduce this (or to see if it's the same) with UHD directly
accessed BY a C++ application.
Regards,
Claude Lem?nager
P.S. Conclusion about preceding discussion (june) about PCIe interface: The HP
PC on which I made my firsts experiences was equipped with one of the first
generation PCIe chip. So it failed to interface with X310. I now uses a last
generation pc and then there is no problem except for what I mention above.
Thanks for support.
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[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/20141010/9c4aabf4/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 50, Issue 10
******************************************
