Hi all,
Now that I have the USRP2 playing the university NPR station in my
office, it is now time to get down to serious work.
Could someone please, in a nutshell, explain one of the features of the
WBX (as one of the transceiver series) daughterboard that states:
16 digital I/O lines to control external devices like antenna switches
I would greatly appreciate just a nudge in the right direction, such as,
where are these (connector?)?
How are they accessed (Python script, FPGA re-write, etc.)?
What I need to do is cycle through a set of receiving antennas, sampling
signal from each one in a scan operation. If anyone has already done
this I would dearly love to know your process.
TIA,
Harley Myler
CONFIDENTIALITY: Any information contained in this e-mail (including
attachments) is the property of The State of Texas and unauthorized
disclosure or use is prohibited. Sending, receiving or forwarding of
confidential, proprietary and privileged information is prohibited under
Lamar Policy. If you received this e-mail in error, please notify the
sender and delete this e-mail from your system.
On 05/18/2010 06:57 PM, Harley Myler wrote:
I would greatly appreciate just a nudge in the right direction, such as,
where are these (connector?)?
How are they accessed (Python script, FPGA re-write, etc.)?
What I need to do is cycle through a set of receiving antennas, sampling
signal from each one in a scan operation. If anyone has already done
this I would dearly love to know your process.
Each daughterboard connector has 16 GPIOs. Some of them are used by the
daughterboards, but others are available for your use. On the WBX,
io_tx[14:8] are available for you to use, and they come to the connector
on the grand-daughterboard.
If you need to synchronize the action of these pins precisely, the bets
way to do this is by modifying the FPGA. If you just need to turn them
on and off from software, you can do that with the API.
Matt
On 05/21/2010 01:37 AM, Matt E. wrote:
Matt
The schematic for WBX makes it look like a couple of the io_rx are
available as well–are they not?
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On 05/20/2010 10:45 PM, Marcus D. Leech wrote:
turn them on and off from software, you can do that with the API.
Matt
The schematic for WBX makes it look like a couple of the io_rx are
available as well–are they not?
Yes, some others are available as well. You need to look at both the
wbx and grandaughterboard schematics.
Matt
I traced those from the WBX simple GDB, through the WBX and to the
USRP2. They wind-up at U1 (XC3SXX00FG456−IO7(tx)) and U1
(XC3SXX00FG456−IO2(rx)) on page 3 of 8 of the USRP2 schematic. I do not
know why they are both labelled “U1”. The date, revision and drawn-by
blocks only had tokens. I may be looking at a preliminary schematic.
So at this juncture my assumption is that the FPGA(s) given by the XC…
labels above, although I cannot find a Xylinx part number match, simply
run out to the 20 pin header connector on the daughterboard. Of the
sixteen lines, each daughterboard usurps–an ironic term here–any
number of the available 16 GPIOs for their own purposes and what is left
are available to the user.
As such, my conclusion is that the following, per the schematic, are
available:
RX Control Pins io_rx[15:14] −− Unused
TX Control Pins iotx[15:8] −− Unused
This gives 9 GPIO pins available to the user, hardly 16. The product
documentation should reflect this. Nevertheless, nine will be adequate
for my purposes.
On May 21, 2010, at 12:46 AM, Matt E. wrote:
bets way to do this is by modifying the FPGA. If you just need to
Yes, some others are available as well. You need to look at both the wbx and grandaughterboard schematics.
Matt
CONFIDENTIALITY: Any information contained in this e-mail (including
attachments) is the property of The State of Texas and unauthorized
disclosure or use is prohibited. Sending, receiving or forwarding of
confidential, proprietary and privileged information is prohibited under
Lamar Policy. If you received this e-mail in error, please notify the
sender and delete this e-mail from your system.
On 05/21/2010 09:33 AM, Harley Myler wrote:
I traced those from the WBX simple GDB, through the WBX and to the USRP2. They wind-up at U1 (XC3SXX00FG456−IO7(tx)) and U1 (XC3SXX00FG456−IO2(rx)) on page 3 of 8 of the USRP2 schematic. I do not know why they are both labelled “U1”. The date, revision and drawn-by blocks only had tokens. I may be looking at a preliminary schematic.
It’s pretty standard industry practice to “break up” many-pinned chips
on the schematic into functional
units, but they still get labelled with the same part number, because
in reality it’s all the same part.
We do that at two of the companies I work for, and I’ve seen it in lots
of other schematics as well.
So at this juncture my assumption is that the FPGA(s) given by the XC… labels above, although I cannot find a Xylinx part number match, simply run out to the 20 pin header connector on the daughterboard. Of the sixteen lines, each daughterboard usurps–an ironic term here–any number of the available 16 GPIOs for their own purposes and what is left are available to the user.
As such, my conclusion is that the following, per the schematic, are available:
RX Control Pins io_rx[15:14] −− Unused
TX Control Pins iotx[15:8] −− Unused
This gives 9 GPIO pins available to the user, hardly 16. The product documentation should reflect this. Nevertheless, nine will be adequate for my purposes.
I count ten (10).
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On 05/21/2010 06:33 AM, Harley Myler wrote:
I traced those from the WBX simple GDB, through the WBX and to the
USRP2. They wind-up at U1 (XC3SXX00FG456−IO7(tx)) and U1
(XC3SXX00FG456−IO2(rx)) on page 3 of 8 of the USRP2 schematic. I do
not know why they are both labelled “U1”. The date, revision and
drawn-by blocks only had tokens. I may be looking at a preliminary
schematic.
It’s a 456 pin part, which would be huge if it wasn’t split up. The
actual part number is XC3S2000-5FGG456. The XX in the part name in the
schematic is because the 1000, 1500, and 2000 are all pin compatible.
So at this juncture my assumption is that the FPGA(s) given by the
XC… labels above, although I cannot find a Xylinx part number
match, simply run out to the 20 pin header connector on the
daughterboard. Of the sixteen lines, each daughterboard usurps–an
ironic term here–any number of the available 16 GPIOs for their own
purposes and what is left are available to the user.
Yes.
As such, my conclusion is that the following, per the schematic, are
available:
RX Control Pins io_rx[15:14] −− Unused TX Control Pins iotx[15:8] −−
Unused
IO_RX[15] RX antenna selector pin
IO_RX[14] Available
IO_RX[13:8] RX attenuator control
IO_RX[7] RX 5V supply enable
IO_RX[6] RX 3.3V supply enable
IO_RX[5] Available
IO_RX[4] RX baseband amp enable
IO_RX[3] RX PLL Chip enable
IO_RX[2] RX PLL power down
IO_RX[1] RX PLL mux for debug
IO_RX[0] RX PLL lock detect
IO_TX[15] TX/RX switch
IO_TX[14] Available
IO_TX[13] Available
IO_TX[12] Available
IO_TX[11] Available
IO_TX[10] Available
IO_TX[9] Available
IO_TX[8] Available
IO_TX[7] TX 5V supply enable
IO_TX[6] TX 3.3V supply enable
IO_TX[5] Available
IO_TX[4] TX mixer enable
IO_TX[3] TX PLL chip enable
IO_TX[2] TX PLL power down
IO_TX[1] TX PLL mux for debug
IO_TX[0] TX PLL lock detect
This gives 9 GPIO pins available to the user, hardly 16. The product
documentation should reflect this. Nevertheless, nine will be
adequate for my purposes.
I count 10 in the above list. The WBX docs never say there are 16 pins,
as far as I can tell. It is the USRP and USRP2 documentation which
states 16 pins are available, and they are.
Matt
On 05/21/2010 10:08 AM, Harley Myler wrote:
Well of course, but then it is “industry practice” to identify the separation; i.e., U1-A, U1-B, etc.
I’ve seen it done a number of different ways, some more confusing than
others, to be sure.
Even better, but still hardly 16.
True enough, and I agree that the data sheet is somewhat misleading. It
should either say
“up to 16 I/O lines available for external devices”, or each device
description should include
the number of “uncommitted” I/O lines available (actually, the device
descriptions could use
a general re-work to include more information about them in terms of
performance, functionality,
etc, etc). I think that what you’re experiencing is a symptom of a
company whose customer
base has grown faster than anticipated, and some of the “good
housekeeping” things, like
really-detailed documentation, have suffered somewhat. My
understanding is that this will
get better over the next several months, as NI provides resources to
tackle some of the
documentation.
Now what is your explanation on the tokens?
None at all. I guess that whoever drew them opted not to (or forgot) to
fill in the “housekeeping”
fields on those schematic sheets.
Note to list: Marcus is the tech support assistant for Ettus R…
Yup, that’s true. Many on this list already know that–either because
they know me personally, or
I’ve had interactions with them as Ettus customers. I haven’t made
any attempt to keep that a
secret, but since I’m a self-employed technology freelancer, I make it
a policy not to
explicitly advertise my relationships with my clients in public
fora–either because there’s an
NDA in place, or because it’s just polite business practice.
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
First let me say kudos to Josh B. for a spectacular program, GRC. I
wasn’t quite sure what it was and now see the value of it. No Josh, I
will not tell you what version I am running, but suffice it to say that
your program created a program running in a WBX, installed in a USRP2,
tied to eth1 (secondary GigaBit ethernet) in a dual-quad core Mac Pro,
running Ubuntu under Parallels via Leopard.
Thanks
Anyway, can the GRC program access the GPIO bits of the daughtercards? I
didn’t see anything in the list of available elements. I am guessing it
just is not there, but the alternative would be to build the radio with
GRC and then just edit into the source that it builds. Any tidbits there
would be welcome.
rule of thumb: Dont edit the generated code.
Rather, make a custom block that suits your needs and add it to grc.
http://gnuradio.org/redmine/wiki/gnuradio/GNURadioCompanion#Adding-Custom-Blocks
-Josh
On Jun 16, 2010, at Wednesday|June 16, 2010|1:07 PM, Josh B. wrote:
rule of thumb: Dont edit the generated code.
Rather, make a custom block that suits your needs and add it to grc.
http://gnuradio.org/redmine/wiki/gnuradio/GNURadioCompanion#Adding-Custom-Blocks
-Josh
Is there a repository of custom blocks that others have created?
CONFIDENTIALITY: Any information contained in this e-mail (including
attachments) is the property of The State of Texas and unauthorized
disclosure or use is prohibited. Sending, receiving or forwarding of
confidential, proprietary and privileged information is prohibited under
Lamar Policy. If you received this e-mail in error, please notify the
sender and delete this e-mail from your system.
Hello all,
First let me say kudos to Josh B. for a spectacular program, GRC. I
wasn’t quite sure what it was and now see the value of it. No Josh, I
will not tell you what version I am running, but suffice it to say
that your program created a program running in a WBX, installed in a
USRP2, tied to eth1 (secondary GigaBit ethernet) in a dual-quad core
Mac Pro, running Ubuntu under Parallels via Leopard.
Anyway, can the GRC program access the GPIO bits of the daughtercards?
I didn’t see anything in the list of available elements. I am guessing
it just is not there, but the alternative would be to build the radio
with GRC and then just edit into the source that it builds. Any
tidbits there would be welcome.
Thanks,
Harley Myler
CONFIDENTIALITY: Any information contained in this e-mail (including
attachments) is the property of The State of Texas and unauthorized
disclosure or use is prohibited. Sending, receiving or forwarding of
confidential, proprietary and privileged information is prohibited under
Lamar Policy. If you received this e-mail in error, please notify the
sender and delete this e-mail from your system.
HR Myler wrote:
Is there a repository of custom blocks that others have created?
https://cgran.org/
However, the thought has crossed my mind more than once, that there
should be a grc-extras project, which could include a misc assortment of
interesting blocks that aren’t yet included in the trunk, and yet aren’t
really part of a specific project either. More advanced IO control
would be a nice start. Another example is a python thread that I
wrapped in a grc XML block that calls back into the get-functions of
another block to pull out statistics for the GUI… it has come in
handy more than once, and I’d like to contribute it, but don’t know
where it should go.
More to the point, Josh, do you have an example of using the auto-tx/rx
from GRC? If I understand it correctly, this is to be used whenever
the flow graph doesn’t have data for the USRP, and yet after looking
through the code, there doesn’t seem to be any way (at least not brought
out to GRC) which lets one assign a port / IO mask to this feature.
I’ll dido the kudos to Josh, keep up the elegant work!
Glenn
http://gnuradio.org/redmine/wiki/gnuradio/GNURadioCompanion#Adding-Custom-Blocks
-Josh
I’ll echo Josh’ sentiment here. Also, judicious use of “import” of your
own functions, and weaving them
into appropriate spots within the standard GRC framework can get you
very far as well.
But, it would be nice if there were a more general way to include “open
code” within a GRC-generated
flowgraph. No simple, elegant design immediately leaps to mind,
however.
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium