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. Is the TX/RX port ac coupled? (Usrp IITM)
   2. Re: Is the TX/RX port ac coupled? (Matt Ettus)
   3. Question about archiving the E100 root file system
      (Kevin 'Deep Dive' Hicks)
   4. Re: Question about archiving the E100 root file system
      ([email protected])
   5. Re: E100 + GPSDO problem (Nowlan, Sean)
   6. Re: Question about archiving the E100 root file system
      (Kevin 'Deep Dive' Hicks)
   7. Re: Question about archiving the E100 root file system
      (Philip Balister)
   8. Re: questions about calibration examples in UHD utility (gang li)
   9. Re: questions about calibration examples in UHD utility
      ([email protected])


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

Message: 1
Date: Wed, 30 Jan 2013 22:35:13 +0530
From: Usrp IITM <[email protected]>
To: [email protected]
Subject: [USRP-users] Is the TX/RX port ac coupled?
Message-ID:
        <CAPkh=_9n3UF=uo36o2mhndgkza1xummk9qa7ozmltgtzhst...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi,

I am working on a board for self cancellation for full duplex. I noticed
that the USRP's TX/RX port is connected to cap c204 and saw filter. The cap
is not there in the board. So, can I know whether the TX/RX is ac coupled
internal to the filter?

- Sreejith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130130/a497d49d/attachment-0001.html>

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

Message: 2
Date: Wed, 30 Jan 2013 09:08:21 -0800
From: Matt Ettus <[email protected]>
To: Usrp IITM <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Is the TX/RX port ac coupled?
Message-ID:
        <CAN=1kn8bwh_6hab08caub9ry_+d45z-yfz22vqo0s1m9eja...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Which daughterboard are you using?

Matt


On Wed, Jan 30, 2013 at 9:05 AM, Usrp IITM <[email protected]> wrote:

> Hi,
>
> I am working on a board for self cancellation for full duplex. I noticed
> that the USRP's TX/RX port is connected to cap c204 and saw filter. The cap
> is not there in the board. So, can I know whether the TX/RX is ac coupled
> internal to the filter?
>
> - Sreejith
>
> _______________________________________________
> 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/20130130/6a66cb0a/attachment-0001.html>

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

Message: 3
Date: Wed, 30 Jan 2013 10:39:54 -1000
From: Kevin 'Deep Dive' Hicks <[email protected]>
To: [email protected]
Subject: [USRP-users] Question about archiving the E100 root file
        system
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hello,

I have updated and tweaked the file system on my E100's SD card. Now I 
wish to archive the file system in its current state.  I would like to 
do this by making a compressed tarball like the one in 
e1xx-003-make.tar.bz2 (called rootfs.tar.gz).

I used a card reader on my Linux machine and mounted the SD card's EXT3 
partition locally:

    su -
    mount -t ext3 /dev/sdb2 /mnt/e100

I changed to the mount directory and created the archive:

    cd /mnt/e100
    tar czvf <target_dir>rootfs.tar.gz *

where <target_dir> is where I unrolled e1xx-003-make.tar.bz2. I 
unmounted and replaceed the SD card, switched to <target_dir>, and invoked

    ./MakeEttusSDCard.legacy.sh /dev/sdb

(still as root -- incidentally, MakeEttusSDCard.sh doesn't work for me).

This set up the second SD card and seemed to work fine.  I put the 
second card in the E100 and powered up.  It booted just fine and let me 
log in.  But when I tried to run uhd_usrp_probe I got this:

linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; 
UHD_003.005.000-0-g5cb9779d

-- Loading FPGA image: 
/opt/uhd/share/uhd/images/usrp_e100_fpga_v2.bin... done = 1
-- Configuration complete.
-- Initializing FPGA clock to 64.000000MHz...
-- USRP-E100 clock control: 10
--   r_counter: 2
--   a_counter: 0
--   b_counter: 20
--   prescaler: 8
--   vco_divider: 5
--   chan_divider: 5
--   vco_rate: 1600.000000MHz
--   chan_rate: 320.000000MHz
--   out_rate: 64.000000MHz
-- 
-- Opening device node /dev/usrp_e0...
-- Performing control readback test... Error: RuntimeError: fifo ctrl 
timed out looking for acks

I suspect it's a problem with the permissions on a device file 
somewhere.  Most likely, the problem was in the way I created the 
compressed archive.  What is the correct method to make a tarball out of 
the root file system?  Can somebody provide a script?

Best wishes,

Kevin Hicks
TeraSys Technologies, Honolulu




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

Message: 4
Date: Wed, 30 Jan 2013 15:55:43 -0500
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] Question about archiving the E100 root file
        system
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"

 

On 30 Jan 2013 15:39, Kevin 'Deep Dive' Hicks wrote: 

> Hello,
> 
>
I have updated and tweaked the file system on my E100's SD card. Now I

> wish to archive the file system in its current state. I would like to

> do this by making a compressed tarball like the one in 
>
e1xx-003-make.tar.bz2 (called rootfs.tar.gz).
> 
> I used a card reader
on my Linux machine and mounted the SD card's EXT3 
> partition
locally:
> 
> su -
> mount -t ext3 /dev/sdb2 /mnt/e100
> 
> I changed to
the mount directory and created the archive:
> 
> cd /mnt/e100
> tar
czvf rootfs.tar.gz *
> 
> where is where I unrolled
e1xx-003-make.tar.bz2. I 
> unmounted and replaceed the SD card,
switched to , and invoked
> 
> ./MakeEttusSDCard.legacy.sh /dev/sdb
> 
>
(still as root -- incidentally, MakeEttusSDCard.sh doesn't work for
me).
> 
> This set up the second SD card and seemed to work fine. I put
the 
> second card in the E100 and powered up. It booted just fine and
let me 
> log in. But when I tried to run uhd_usrp_probe I got this:
>

> linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; 
>
UHD_003.005.000-0-g5cb9779d
> 
> -- Loading FPGA image: 
>
/opt/uhd/share/uhd/images/usrp_e100_fpga_v2.bin... done = 1
> --
Configuration complete.
> -- Initializing FPGA clock to
64.000000MHz...
> -- USRP-E100 clock control: 10
> -- r_counter: 2
> --
a_counter: 0
> -- b_counter: 20
> -- prescaler: 8
> -- vco_divider: 5
>
-- chan_divider: 5
> -- vco_rate: 1600.000000MHz
> -- chan_rate:
320.000000MHz
> -- out_rate: 64.000000MHz
> -- 
> -- Opening device node
/dev/usrp_e0...
> -- Performing control readback test... Error:
RuntimeError: fifo ctrl 
> timed out looking for acks
> 
> I suspect
it's a problem with the permissions on a device file 
> somewhere. Most
likely, the problem was in the way I created the 
> compressed archive.
What is the correct method to make a tarball out of 
> the root file
system? Can somebody provide a script?
> 
> Best wishes,
> 
> Kevin
Hicks
> TeraSys Technologies, Honolulu
> 
>
_______________________________________________
> USRP-users mailing
list
> [email protected]
>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

You
probably want to exclude /dev /proc and /sys from the input tar file 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130130/819122ac/attachment-0001.html>

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

Message: 5
Date: Wed, 30 Jan 2013 20:57:11 +0000
From: "Nowlan, Sean" <[email protected]>
To: Balint Seeber <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] E100 + GPSDO problem
Message-ID: <195933287DC65748BA7AE867BA8E430B62360381@apatlisdmbx02>
Content-Type: text/plain; charset="us-ascii"

Forgot to cc list

From: Nowlan, Sean
Sent: Wednesday, January 30, 2013 3:45 PM
To: 'Balint Seeber'
Subject: RE: [USRP-users] E100 + GPSDO problem

Yes, it appears this did the trick. Apparently the diameter of the center pin 
in the SMA connector was almost identically the diameter of the through-hole on 
the board, and pushing it through cut the trace between the through-hole and 
one end of C100. I soldered some wire-wrap wire from that capacitor, around the 
side of the board, and connected it to the center pin. External ref locks now.

Thanks!
Sean

From: Balint Seeber [mailto:[email protected]]
Sent: Wednesday, January 30, 2013 3:18 PM
To: Nowlan, Sean
Subject: Re: [USRP-users] E100 + GPSDO problem

Hi Sean,
I read that you tracked this down to a bad solder joint on the SMA connector - 
did this completely solve the problem?
Let me know how you went and if it's still causing any issues...
Kind regards,
Balint
On Fri, Jan 25, 2013 at 9:54 AM, Nowlan, Sean 
<[email protected]<mailto:[email protected]>> wrote:
Hi all,

I have an E100 rev 3.0 and GPSDO (Ettus-modified Firefly 1A). For some reason 
the E100 won't lock to the 10MHz reference. Several thoughts:

1) Even if GPS is not locked, the OXCO is pretty stable, so E100 should 
theoretically lock.
2) It could just be a bad GPSDO module, but I want to confirm I'm doing 
everything right before drawing that conclusion.

Jumpers J15 and J16 are configured for flexible clocking 
(http://files.ettus.com/uhd_docs/manual/html/usrp_e1xx.html#changing-the-master-clock-rate<http://files.ettus.com/uhd_docs/manual/html/usrp_e1xx.html#changing-the-master-clock-rate%29.>).

I came across the problem while setting up OpenBTS (reference lock timeout 
error) but I tried a simple Python script to test:

...
my_usrp.set_clock_source("external", 0)
sleep(1)
while not my_usrp.get_mboard_sensor("ref_locked", 0):
    print "ref not locked"
    sleep(1)
print "hooray! ref is locked!"
...

I ran it for a few minutes and never got a lock. It was my understanding that 
normally the PLL is orders of magnitude faster at locking than this. Any help 
would be appreciated! :)

Sean

_______________________________________________
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/20130130/e73a4cc7/attachment-0001.html>

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

Message: 6
Date: Wed, 30 Jan 2013 11:38:11 -1000
From: Kevin 'Deep Dive' Hicks <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Question about archiving the E100 root file
        system
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

> You probably want to exclude /dev /proc and /sys from the input tar file
>
Thanks, but I already checked to make sure they're empty.  (The root 
filesystem is not active while I do the archiving.)  I leave them in the 
tar file as mountpoints.

Kevin




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

Message: 7
Date: Wed, 30 Jan 2013 17:40:28 -0500
From: Philip Balister <[email protected]>
To: Kevin 'Deep Dive' Hicks <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Question about archiving the E100 root file
        system
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1

On 01/30/2013 03:39 PM, Kevin 'Deep Dive' Hicks wrote:
> Hello,
> 
> I have updated and tweaked the file system on my E100's SD card. Now I
> wish to archive the file system in its current state.  I would like to
> do this by making a compressed tarball like the one in
> e1xx-003-make.tar.bz2 (called rootfs.tar.gz).
> 
> I used a card reader on my Linux machine and mounted the SD card's EXT3
> partition locally:
> 
>    su -
>    mount -t ext3 /dev/sdb2 /mnt/e100
> 
> I changed to the mount directory and created the archive:
> 
>    cd /mnt/e100
>    tar czvf <target_dir>rootfs.tar.gz *
> 
> where <target_dir> is where I unrolled e1xx-003-make.tar.bz2. I
> unmounted and replaceed the SD card, switched to <target_dir>, and invoked
> 
>    ./MakeEttusSDCard.legacy.sh /dev/sdb
> 
> (still as root -- incidentally, MakeEttusSDCard.sh doesn't work for me).
> 
> This set up the second SD card and seemed to work fine.  I put the
> second card in the E100 and powered up.  It booted just fine and let me
> log in.  But when I tried to run uhd_usrp_probe I got this:
> 
> linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500;
> UHD_003.005.000-0-g5cb9779d
> 
> -- Loading FPGA image:
> /opt/uhd/share/uhd/images/usrp_e100_fpga_v2.bin... done = 1
> -- Configuration complete.
> -- Initializing FPGA clock to 64.000000MHz...
> -- USRP-E100 clock control: 10
> --   r_counter: 2
> --   a_counter: 0
> --   b_counter: 20
> --   prescaler: 8
> --   vco_divider: 5
> --   chan_divider: 5
> --   vco_rate: 1600.000000MHz
> --   chan_rate: 320.000000MHz
> --   out_rate: 64.000000MHz

Gah, why is thunderbird truncating ....

Anyway, the kernel is in the FAT partition, not in the root file system.
You need to copy the uImage file from your card to the new sd cards FAT
partition. This should solve the problem.

Philip



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

Message: 8
Date: Thu, 31 Jan 2013 10:19:08 -0500
From: gang li <[email protected]>
To: [email protected]
Cc: [email protected], gnu radio <[email protected]>
Subject: Re: [USRP-users] questions about calibration examples in UHD
        utility
Message-ID:
        <CAKro2L0pecAo_1MJ-cNf7ojcXHaWGR_Yfd_RcGkLWF+Qmy=p...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi, Mike,
Thanks very much for your reply. I also searched  online about the
usrp calibration. I found a post and some information:

"During cal, the TX is switched away from the TX antenna into the
"closed" switch port, where it leaks into the RX which is listening to
the TX/RX antenna. So termination on RX2 should have no effect as that
port is already unused in calibration."

Here is the link:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-April/004028.html.

I am a little confused. Since calibration uses full duplex, why is
there no direct connection between RX2 and TX/RX? I thought they are
connected inside the usrp during calibration.

Best,
Gang


On Mon, Jan 28, 2013 at 4:08 PM, Mike Jameson <[email protected]> wrote:
> Hi,
>
> Calibration uses full duplex and should only be done without anything
> plugged into the 'tx/rx' or 'rx2' ports. There is no direct connection, just
> measurement of the residual rf escaping.
>
> Mike
> M0MIK
>
> On 28 Jan 2013 20:17, "gang li" <[email protected]> wrote:
>>
>> Hi, guys,
>>
>> I am reading the codes for uhd_cal_rx_iq_balance.cpp.
>> When doing calibration by setting the RX and TX antenna as "CAL", is
>> the signal from TX directly switched to RX?
>> And I noticed that in the function set_optimum_defaults(), the tx_gain
>> is 0 but the rx_gain is 25! Is that too high? I heard that when
>> directly connecting TX and RX, we should use attenuators. So why does
>> it set 25 rx_gain? Thanks.
>>
>> Best,
>> Gang
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



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

Message: 9
Date: Thu, 31 Jan 2013 10:44:53 -0500
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] questions about calibration examples in UHD
        utility
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"

 

On 31 Jan 2013 10:19, gang li wrote: 

> Hi, Mike,
> Thanks very
much for your reply. I also searched online about the
> usrp
calibration. I found a post and some information:
> 
> "During cal, the
TX is switched away from the TX antenna into the
> "closed" switch port,
where it leaks into the RX which is listening to
> the TX/RX antenna. So
termination on RX2 should have no effect as that
> port is already
unused in calibration."
> 
> Here is the link:
>
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-April/004028.html.
>

> I am a little confused. Since calibration uses full duplex, why is
>
there no direct connection between RX2 and TX/RX? I thought they are
>
connected inside the usrp during calibration.
> 
> Best,
> Gang
> 
>
T

They don't need to be connected. There's enough leakage through the
switch that the RX side receives a strong enough signal. 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130131/b295ff3c/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 29, Issue 29
******************************************

Reply via email to