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: Phase comparator using a N200 (Marcus D. Leech)
2. Remotely power cycle a B200 (Matthias P. Braendli)
3. Re: Remotely power cycle a B200 (Marcus M?ller)
4. Re: Remotely power cycle a B200 (Marcus M?ller)
5. Re: Remotely power cycle a B200 (Matthias P. Braendli)
6. Re: Remotely power cycle a B200 (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Sat, 22 Mar 2014 13:31:29 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Phase comparator using a N200
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 03/21/2014 04:49 PM, Juha Vierinen wrote:
> Hi,
>
> For the last few weeks we've been trying to make an inexpensive phase
> comparator using a USRP N200. I thought I'd share some of our
> experiences here for the benefit of somebody else attempting this.
>
> The goal is to measure relative time delay between two sinusoidal
> signals on two channels by measuring the relative phase of the two
> channels. In our case, we are using 5 MHz.
>
> We first tried the most obvious approach, ie., using the two DDCs with
> with the standard firmware. However, we encountering systematic
> relative phase changes between two channels that were variable over
> time. We did remove the residual frequency error that was there due to
> the finite length tuning word, so that wasn't the cause of the
> problem. It was as if the two NCOs weren't in exactly the same phase
> at each time step. These phase changes are small enough that you won't
> notice them unless looking at the cross channel relative phase
> difference very carefully (~`100 picoseconds peak-to-peak and
> zero-mean). I never figured out the exact cause of this problem, but
> tuning the DDC to 0 removed the issue. I ended up removing the CIC and
> the half-band filter and just streamed decimated ADC counts on the two
> channels, avoiding nearly all fpga processing. This is a fairly easy
> modification to the UHD Verilog code (this would also be a nice to
> have standard feature for the USRP N200 fpga image).
>
> We next noticed that single precision filtering did not provide enough
> numerical accuracy. We were seeing 10 to 20 picosecond jumps, which
> went away when doing the filtering in double precision. For this
> purpose, I wrote a new gnuradio signal processing block that performed
> 25 MHz -> 10 Hz digital downconversion with double precision floating
> point.
>
> We are right now at a point where we can get relative time stability
> of approximately 4e-14 in 10 seconds and 5e-15 over 100 seconds
> between the two channels, which is good enough to resolve sub
> picosecond relative time changes between the two channels. I've
> attached a plot where we tested relative time delay between two
> channels, using a trombone to vary the length of one of the channels.
>
> juha
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
OK, some random thoughts.
The group-delay through the analog filters on the back of your
daughtercard isn't going to be uniform across the passband at picosecond
scales, and
it will tend to change with temperature.
Similarly, although this one is harder to really picture, the digital
clock lines within the FPGA aren't going to be perfectly-aligned on
picosecond time
scales, and that alignment will change with temperature as parasitic
capacitance changes internally. But it's hard to see how such
picosecond-scale
clock skews could all "accumulate" in a single direction--I'd expect
them to be randomly distributed about a mean, and for them never to
accumulate
to the point that a single-bit-time phase-error "accumulates".
That's what would be required, I think, to cause phase hits in the
digital bits. But I'm
not an FPGA guy, so I'm just speculating.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140322/24433f85/attachment-0001.html>
------------------------------
Message: 2
Date: Sat, 22 Mar 2014 19:17:35 +0100
From: "Matthias P. Braendli" <[email protected]>
To: [email protected]
Subject: [USRP-users] Remotely power cycle a B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hi all,
it's not clear to me how the two power sources of the B200 (USB bus
power + external connector) interact together.
I would like to power the B200 *only* from the external connector, so
that I can power-cycle it using an PC-controlled relay. How can I
achieve that ?
Regards,
mpb
------------------------------
Message: 3
Date: Sat, 22 Mar 2014 19:59:28 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Remotely power cycle a B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Matthias,
http://files.ettus.com/schematics/b200/b200.pdf p. 8:
Power should be continuous when external power is taken away but USB
stays; refer to the LTC4412 datasheet
(http://files.ettus.com/schematics/b200/b200.pdf). I don't think
"enforcing" exclusive external power works (without removing parts
from the PCB).
To solve your problem:
Many USB controllers have the option to actually power off ports.
https://www.kernel.org/doc/Documentation/usb/power-management.txt,
search for /sys/bus/usb/devices/.../power/ .
In many application scenarious, B2x0 series USRPs can be used purely
bus-powered; for these that would be sufficient.
For the others, you could use the USB voltage to turn on a mosfet that
sits between your external power supply and the USRP (no switchable
relais for mains necessary if you're just switching <<10V); don't
forget a pull-down resistor to turn the FET off.
Greetings,
Marcus
On 22.03.2014 19:17, Matthias P. Braendli wrote:
> Hi all,
>
> it's not clear to me how the two power sources of the B200 (USB
> bus power + external connector) interact together. I would like to
> power the B200 *only* from the external connector, so that I can
> power-cycle it using an PC-controlled relay. How can I achieve that
> ?
>
> Regards, mpb
>
> _______________________________________________ USRP-users mailing
> list [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTLd2QAAoJEBQ6EdjyzlHt/wUH/RSxldIuKrOnDsAvLO9YMkiH
Qh1M8Imb71ZIulBAGIlZglhGmO1ZNXylrjieFOeUkz2/LDcZc8/RbOYxQ90FK1yK
Iw5kNbylM57iw7KvrVjZMAFU3Ur9JcPFjq5213QcNIPlKAyPbWg3DSaFfYnDM9DA
zTJHw5e6Cn8kiHMR70RgQN5vDqM7XDovrw+GUnNEJYjZFzp1fp9D/+SUYZfvaYcx
+IEAzac9w+a5kDRuJQD4RqRMg8YKa823ZFctnmiLqma4i1e2CoNId6heVVXGQNMP
n1fDeO6ugO/VQRl9KSaLZp7L/DfBmjqdgP01WXTOjBGfKoSjF1uPhTi07evRxU8=
=vJCg
-----END PGP SIGNATURE-----
------------------------------
Message: 4
Date: Sat, 22 Mar 2014 20:01:14 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Remotely power cycle a B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sorry, wrong URL for the LTC4412:
http://www.linear.com/product/LTC4412
On 22.03.2014 19:59, Marcus M?ller wrote:
> Hi Matthias,
>
> http://files.ettus.com/schematics/b200/b200.pdf p. 8: Power should
> be continuous when external power is taken away but USB stays;
> refer to the LTC4412 datasheet
> (http://files.ettus.com/schematics/b200/b200.pdf). I don't think
> "enforcing" exclusive external power works (without removing parts
> from the PCB).
>
> To solve your problem: Many USB controllers have the option to
> actually power off ports.
> https://www.kernel.org/doc/Documentation/usb/power-management.txt,
> search for /sys/bus/usb/devices/.../power/ . In many application
> scenarious, B2x0 series USRPs can be used purely bus-powered; for
> these that would be sufficient.
>
> For the others, you could use the USB voltage to turn on a mosfet
> that sits between your external power supply and the USRP (no
> switchable relais for mains necessary if you're just switching
> <<10V); don't forget a pull-down resistor to turn the FET off.
>
> Greetings, Marcus
>
> On 22.03.2014 19:17, Matthias P. Braendli wrote:
>> Hi all,
>
>> it's not clear to me how the two power sources of the B200 (USB
>> bus power + external connector) interact together. I would like
>> to power the B200 *only* from the external connector, so that I
>> can power-cycle it using an PC-controlled relay. How can I
>> achieve that ?
>
>> Regards, mpb
>
>> _______________________________________________ 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
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTLd36AAoJEBQ6EdjyzlHtIgQH/2vxEkKoUn/UoGidUR/HdSEX
Tgqy3J7r5l1ZWgf+MJd7K+AMOJ3tm8Bj9PEi77h0RLIYJvPaAVEemVYbL4wAR25R
+aHQUZe89qZ6jKUCmi/B13sX1FLNI9k+8tGogZel5jREt4KZwFvZrhiEccOql6UL
5Bc1iP4Ho4aZywQZi+HpnVZz13C3TjAtW/R4kaQzu4Cq4g/DheiLQOm8ZptGzVCM
841PToLVXoMhgDX3olJhwV/xqd3qOsJ7DSFet4y4Gp8YRYpPluWC0TxFPoTUXXZl
Kdq3+ZTozaQQAOGJ/Opy92pNtoSt5wlnAMu0jyOjXp1C0hUjyUFS6wUCWpFszts=
=IYlW
-----END PGP SIGNATURE-----
------------------------------
Message: 5
Date: Sat, 22 Mar 2014 20:23:10 +0100
From: "Matthias P. Braendli" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Remotely power cycle a B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 22. 03. 14 19:59, Marcus M?ller wrote:
> To solve your problem:
> Many USB controllers have the option to actually power off ports.
> https://www.kernel.org/doc/Documentation/usb/power-management.txt,
> search for /sys/bus/usb/devices/.../power/ .
> In many application scenarious, B2x0 series USRPs can be used purely
> bus-powered; for these that would be sufficient.
>
> For the others, you could use the USB voltage to turn on a mosfet that
> sits between your external power supply and the USRP (no switchable
> relais for mains necessary if you're just switching <<10V); don't
> forget a pull-down resistor to turn the FET off.
Very interesting approach. I'll see if my controller has that ability to
do something like this.
However, the documentation you mention doesn't seem to talk about
powering off ports, but mostly about USB selective suspend, which
doesn't cut off power.
The other option would be to add a a FET on the USB power line in the
cable. I don't want to apply my soldering iron to the B200. But in that
case, I'd rather take a USB cable without the power, and switch my
external supply.
mpb
------------------------------
Message: 6
Date: Sat, 22 Mar 2014 21:21:05 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Remotely power cycle a B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
be careful though, different states of VBUS on USB might have
different meanings to USB controllers; I don't know how the Cypress
USB controller likes being powered (externally) with no potential on
VBUS but differential signal on the data lines.
On 22.03.2014 20:23, Matthias P. Braendli wrote:
> On 22. 03. 14 19:59, Marcus M?ller wrote:
>> To solve your problem: Many USB controllers have the option to
>> actually power off ports.
>> https://www.kernel.org/doc/Documentation/usb/power-management.txt,
>>
>>
search for /sys/bus/usb/devices/.../power/ .
>> In many application scenarious, B2x0 series USRPs can be used
>> purely bus-powered; for these that would be sufficient.
>>
>> For the others, you could use the USB voltage to turn on a mosfet
>> that sits between your external power supply and the USRP (no
>> switchable relais for mains necessary if you're just switching
>> <<10V); don't forget a pull-down resistor to turn the FET off.
>
> Very interesting approach. I'll see if my controller has that
> ability to do something like this.
>
> However, the documentation you mention doesn't seem to talk about
> powering off ports, but mostly about USB selective suspend, which
> doesn't cut off power.
>
> The other option would be to add a a FET on the USB power line in
> the cable. I don't want to apply my soldering iron to the B200. But
> in that case, I'd rather take a USB cable without the power, and
> switch my external supply.
>
> mpb
>
> _______________________________________________ USRP-users mailing
> list [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTLfCxAAoJEBQ6EdjyzlHtBIoH/R29da3fteZt9BVCLuUlOo2r
4L44iP9AzD+Bi5U6m7df2L7ggs4OqGVNG6/LLm6tjZ9gVKeNmpGMjVL/dB7M21x4
htK/AmvRDHZknhev0I6armJiJob3NC4TOCGYcKVcSKvx6r+74ks6E1JBr22xil2H
kubJXSAQsYfwcIQtmPVxkAU6UcqdPSHCMYrk0oAJQz1gOEyIIdcKYRp7a79Rsw1U
bexz98J64vjT9l3tv3pO2Dxn0MsMb/NaKALjIGjx4xGE4wDro4VZL0QooxuLI/MQ
TllaIcA43VVWrCzBs1bFROE2IXz+FIadlvdpmQPB5lNa8O5NuoFjE3pzKdOwAdo=
=inRR
-----END PGP SIGNATURE-----
------------------------------
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 43, Issue 23
******************************************
