Front Panel GPIO on Ettus X310

GNU Radio
1

Hi,

I would like to command the Front Panel GPIO pins for use as a trigger
signal to another piece of equipment under gnuradio and python (I’m not
a
C++ programmer). I’ve been trying unsuccessfully to use the UHD
multi_usrp
“get_gpio_banks” and the “set_gpio_attr” commands to control the I/O
pins. I
receive an "Attribute error: ‘usrp_sink_sptr’ Object has no attribute ".

My questions are:
1)Has the UHD multi_source class been incorporated into the GNU Radio
API ?
2) Is it currently possible to interface to the GPIO pins without under
Gnuradio without going the C++ route ?

Best Regards,
Frank Alessandro

–
View this message in context:
http://gnuradio.4.n7.nabble.com/Front-Panel-GPIO-on-Ettus-X310-tp53979.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

Hey Frank,

multi_usrp is exactly what the GNU Radio blocks use under the hood.
However, multi_usrp is not SWIGged – which means you can’t access
multi_usrp from Python. I believe that’s what’s triggering your error
message. get_device() can only be called on your USRP blocks using C++.

Now, if you were to use C++, I’d recommend having a look at the ‘gpio’
example in UHD. It shows how to map ATRs to GPIOs, which sounds like
what you’re trying to do.

I can see how these GPIO functions would be useful in a swigged fashion,
though, and maybe even available by command tag. We should get them onto
master.

M

3

Hi Martin,

Thanks for the response. It looks like we’ll have to go the C++ route
then.
Thanks for your assistance.

Best Regards,

Frank

From: Martin B.-2 [via GnuRadio]
[mailto:[email protected]]
Sent: Monday, June 01, 2015 7:50 PM
To: Falessan
Subject: Re: Front Panel GPIO on Ettus X310

Hey Frank,

multi_usrp is exactly what the GNU Radio blocks use under the hood.
However, multi_usrp is not SWIGged – which means you can’t access
multi_usrp from Python. I believe that’s what’s triggering your error
message. get_device() can only be called on your USRP blocks using C++.

Now, if you were to use C++, I’d recommend having a look at the ‘gpio’
example in UHD. It shows how to map ATRs to GPIOs, which sounds like
what you’re trying to do.

I can see how these GPIO functions would be useful in a swigged fashion,
though, and maybe even available by command tag. We should get them onto
master.

M

On 01.06.2015 14:23, Falessan wrote:

Hi,

I would like to command the Front Panel GPIO pins for use as a trigger
signal to another piece of equipment under gnuradio and python (I’m not a
C++ programmer). I’ve been trying unsuccessfully to use the UHD multi_usrp

“get_gpio_banks” and the “set_gpio_attr” commands to control the I/O pins.
I
receive an "Attribute error: ‘usrp_sink_sptr’ Object has no attribute ".

My questions are:
1)Has the UHD multi_source class been incorporated into the GNU Radio API
?
2) Is it currently possible to interface to the GPIO pins without under
Gnuradio without going the C++ route ?

Best Regards,
Frank Alessandro

Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

If you reply to this email, your message will be added to the discussion
below:

http://gnuradio.4.n7.nabble.com/Front-Panel-GPIO-on-Ettus-X310-tp53979p53983
.html

To unsubscribe from Front Panel GPIO on Ettus X310, click here
<http://gnuradio.4.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_
by_code&node=53979&code=ZnJhbmsuYWxlc3NhbmRyb0Bjb21jYXN0Lm5ldHw1Mzk3OXwtMTY1
OTUzNjIwMQ==> .

<http://gnuradio.4.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer
&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicName
space-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.Node
Namespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_email
s%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> NAML

4

On 02.06.2015 06:42, Falessan wrote:

Hi Martin,

Thanks for the response. It looks like well have to go the C++ route
then. Thanks for your assistance.

Happy to help,

if you run into more issues, just ask. As I mentioned, I recommend
reading the gpio example in UHD for more help.

Cheers,
Martin

5

Maurizio,

On Wed, Aug 5, 2015 at 7:49 AM, Maurizio Crozzoli
[email protected] wrote:

Hi Martin or others who can support me,
I have a problem which is similar as Frank’s: I have an E310 and I want to
receive a and external trigger on a pin which starts an acquisition process
of a burst of samples from the radio source.

In the default FPGA image the GPIO pins are wired up to ATR pins that
are connected
to the radio0.

https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L112
https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L375
https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L659
https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300_core.v#L304

would be your places to start.

If you want to use our GPIO API take a look at:

http://files.ettus.com/manual/page_gpio_api.html

from the radio source is started and, once it has been completed, the flow
goes back to the GPIO port monitoring.

You could either fork of a thread to monitor the ports through the UHD
API,
or rewire stuff in the FPGA (as pointed out above) to use the Zynq’s
GPIO_I signals in the FPGA.
You could then use the default kernel sysfs GPIO API to use GPIO
interrupts.

places to start investigating are:

https://www.kernel.org/doc/Documentation/gpio/sysfs.txt
http://elinux.org/GPIO#GPIO_interrupts_from_user_space

maybe there are python bindings available?

Is there any example code I be inspired from? OF course I have to study what
can be found in the manual page “The E3x0/X3x0 Front Panel GPIO”, but,
together with the suggested gpio.cpp example under UHD, it looks like there
is more emphasis on the ATR mechanism, which - I think - has nothing to do
with the problem I have to solve.

That is true, see the above links. Depending on latency requirements,
and your input signal,
the ATR API might not be what you need.

the acquisition process of a burst of samples from the radio source, you
might well understand how much I need your help, and not just for this
post…

Just for the GPIO part no requirement of using RFNOC.

Discuss-gnuradio Info Page
Happy hacking,

Moritz

6

Hi Martin or others who can support me,
I have a problem which is similar as Frank’s: I have an E310 and I want
to
receive a and external trigger on a pin which starts an acquisition
process
of a burst of samples from the radio source.

Stated that I have to remove the box around the E310 to have access to
the
GPIO ports (not a problem!), according to what I have read so far in
this
thread, no way to reach my goal but using C++ (no GRC!). Not an easy
task
for me but I do hope I can do it.

What I need you support about is related to the right approach I should
follow. I would think that I should write a “while” loop which runs in
ARM
processors where one on the available GPIO port is constantly monitored:
when the trigger is detected the acquisition process of a burst of
samples
from the radio source is started and, once it has been completed, the
flow
goes back to the GPIO port monitoring.

Is there any example code I be inspired from? OF course I have to study
what
can be found in the manual page “The E3x0/X3x0 Front Panel GPIO”, but,
together with the suggested gpio.cpp example under UHD, it looks like
there
is more emphasis on the ATR mechanism, which - I think - has nothing to
do
with the problem I have to solve.

Martin or others, could you please comment on my problem?

TIA!

BR,
Maurizio.

PS If you think that, according to what I have understood so far, I will
need to use RFNoC in order to cope with the sampling speed constraints
of
the acquisition process of a burst of samples from the radio source, you
might well understand how much I need your help, and not just for this
post…

–
View this message in context:
http://gnuradio.4.n7.nabble.com/Front-Panel-GPIO-on-Ettus-X310-tp53979p55274.html
Sent from the GnuRadio mailing list archive at Nabble.com.

7

Moritz,
if you wanted to scare me, you succeeded!

What you propose goes far beyond my current skills and it also looks
excessively complicated compared to my needs: really no easier way to
detect an external trigger?

Furthermore I cannot understand the meaning of the example in “The
E3x0/X3x0 Front Panel GPIO” manual:

“We are also using GPIO4, which we want to control manually, as an
output.
[…]
// set up our values for ATR control: 1 for ATR, 0 for manual
[…]
After the above code is run, the ATR in the FPGA will automatically
control GPIO6, as we have described, based on the radio state, and we
have direct manual control over GPIO4.”

So, what does it mean “After the above code is run, […] we have direct
manual control over GPIO4.”? It thought it could be the solution to my
need (a GPIO port to read an external trigger - except for the GPIO
direction, a detail) but according to what you write (which is coherent
with the introduction of the cited manual page: “These GPIO pins are
controlled directly by the FPGA, where they are controlled by an ATR
(Automatic Transmit / Receive).”) it looks it is not: could you please
explain the point?

TIA!

BR,
Maurizio.

-----Messaggio originale-----
Da: Moritz Fischer [mailto:[email protected]]
Inviato: mercoledì 5 agosto 2015 23:56
A: Crozzoli Maurizio
Cc: [email protected]
Oggetto: Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310

Maurizio,

On Wed, Aug 5, 2015 at 7:49 AM, Maurizio Crozzoli
[email protected] wrote:

Hi Martin or others who can support me, I have a problem which is
similar as Frank’s: I have an E310 and I want to receive a and
external trigger on a pin which starts an acquisition process of a
burst of samples from the radio source.

In the default FPGA image the GPIO pins are wired up to ATR pins that
are connected to the radio0.

https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L112
https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L375
https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L659
https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300_core.v#L304

would be your places to start.

If you want to use our GPIO API take a look at:

http://files.ettus.com/manual/page_gpio_api.html

samples from the radio source is started and, once it has been
completed, the flow goes back to the GPIO port monitoring.

You could either fork of a thread to monitor the ports through the UHD
API, or rewire stuff in the FPGA (as pointed out above) to use the
Zynq’s GPIO_I signals in the FPGA.
You could then use the default kernel sysfs GPIO API to use GPIO
interrupts.

places to start investigating are:

https://www.kernel.org/doc/Documentation/gpio/sysfs.txt
http://elinux.org/GPIO#GPIO_interrupts_from_user_space

maybe there are python bindings available?

Is there any example code I be inspired from? OF course I have to
study what can be found in the manual page “The E3x0/X3x0 Front Panel
GPIO”, but, together with the suggested gpio.cpp example under UHD, it
looks like there is more emphasis on the ATR mechanism, which - I
think - has nothing to do with the problem I have to solve.

That is true, see the above links. Depending on latency requirements,
and your input signal, the ATR API might not be what you need.

constraints of the acquisition process of a burst of samples from the
radio source, you might well understand how much I need your help, and
not just for this post…

Just for the GPIO part no requirement of using RFNOC.

[email protected]
Discuss-gnuradio Info Page

Happy hacking,

Moritz

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione
derivante dalla conoscenza di queste informazioni sono rigorosamente
vietate. Qualora abbiate ricevuto questo documento per errore siete
cortesemente pregati di darne immediata comunicazione al mittente e di
provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain
privileged information intended for the addressee(s) only.
Dissemination, copying, printing or use by anybody else is unauthorised.
If you are not the intended recipient, please delete this message and
any attachments and advise the sender by return e-mail, Thanks.

8

Ciao Maurizio,

On Mon, Aug 31, 2015 at 9:03 AM, Crozzoli Maurizio
[email protected] wrote:

Moritz,
if you wanted to scare me, you succeeded!

That wasn’t my intend, sorry. I merely tried to elaborate on different
factors that might play into the choice of solution that will work
best for your solution.

What you propose goes far beyond my current skills and it also looks excessively
complicated compared to my needs: really no easier way to detect an external
trigger?

I’m still not clear on how tight your latency requirements for that
trigger detection are. If you are ok to just poll with a ‘slow’
software loop then using the get_gpio_attr() function will probably be
fast enough.

Furthermore I cannot understand the meaning of the example in “The E3x0/X3x0
Front Panel GPIO” manual:

“We are also using GPIO4, which we want to control manually, as an output.
[…]
// set up our values for ATR control: 1 for ATR, 0 for manual
[…]
After the above code is run, the ATR in the FPGA will automatically control
GPIO6, as we have described, based on the radio state, and we have direct manual
control over GPIO4.”

What this means is that the GPIO6 will be controlled by the ATR’s
logic, while the GPIO4 is user controlled via the set_gpio_attr()
functions, i.e. the state of GPIO6 is controlled by the radio state
{tx,rx,xx} while GPIO4 is controlled by API calls.

So, what does it mean “After the above code is run, […] we have direct manual
control over GPIO4.”? It thought it could be the solution to my need (a GPIO port
to read an external trigger - except for the GPIO direction, a detail) but
according to what you write (which is coherent with the introduction of the cited
manual page: “These GPIO pins are controlled directly by the FPGA, where they are
controlled by an ATR (Automatic Transmit / Receive).”) it looks it is not: could
you please explain the point?

See above. As you correctly observed you just want to set the mode to
manual control (so the FPGA’s state machine will not interfere), and
control the GPIOs using {get,set}_gpio_attr, possibly in a separate
thread.

Cc: [email protected]
In the default FPGA image the GPIO pins are wired up to ATR pins that are
connected to the radio0.
USRP Hardware Driver and USRP Manual: GPIO API

when the trigger is detected the acquisition process of a burst of

radio source, you might well understand how much I need your help, and

This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying, printing
or use by anybody else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender by return
e-mail, Thanks.

I hope I could clarify this a bit

  • Moritz
9

-----Messaggio originale-----
Da: Moritz Fischer [mailto:[email protected]]
Inviato: lunedì 31 agosto 2015 19:35
A: Crozzoli Maurizio
Cc: [email protected]; Disco Daniele
Oggetto: Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310

Ciao Maurizio,

On Mon, Aug 31, 2015 at 9:03 AM, Crozzoli Maurizio
[email protected] wrote:

Moritz,
if you wanted to scare me, you succeeded!

That wasn’t my intend, sorry. I merely tried to elaborate on different
factors that might play into the choice of solution that will work best
for your solution.

What you propose goes far beyond my current skills and it also looks excessively
complicated compared to my needs: really no easier way to detect an external
trigger?

I’m still not clear on how tight your latency requirements for that
trigger detection are. If you are ok to just poll with a ‘slow’
software loop then using the get_gpio_attr() function will probably be
fast enough.

To be honest, currently I do not really know anything about the latency
requirement. I would say that in this proof-of-concept stage of the
design, the “best-we-can-do” approach could be acceptable. Of course it
would be very helpful for us in view of an estimate of the effect of the
latency if you could suggest a reasonable estimate of the latency
measured in a condition where we assume to operate with an E310 and just
test every run for the state of a pin of the GPIO port with an
instruction like ‘usrp_e300->get_gpio_attr(“INT0”,“READBACK”)’. That
change of state should happen every tens to few hundreds of milliseconds
and when it happens an acquisition of I&Q data through RFNo (if we are
able to implement it…) should be performed.

Furthermore I cannot understand the meaning of the example in “The E3x0/X3x0
Front Panel GPIO” manual:

“We are also using GPIO4, which we want to control manually, as an output.
[…]
// set up our values for ATR control: 1 for ATR, 0 for manual […]
After the above code is run, the ATR in the FPGA will automatically control
GPIO6, as we have described, based on the radio state, and we have direct manual
control over GPIO4.”

What this means is that the GPIO6 will be controlled by the ATR’s logic,
while the GPIO4 is user controlled via the set_gpio_attr() functions,
i.e. the state of GPIO6 is controlled by the radio state {tx,rx,xx}
while GPIO4 is controlled by API calls.

So, what does it mean “After the above code is run, […] we have direct manual
control over GPIO4.”? It thought it could be the solution to my need (a GPIO port
to read an external trigger - except for the GPIO direction, a detail) but
according to what you write (which is coherent with the introduction of the cited
manual page: “These GPIO pins are controlled directly by the FPGA, where they are
controlled by an ATR (Automatic Transmit / Receive).”) it looks it is not: could
you please explain the point?

See above. As you correctly observed you just want to set the mode to
manual control (so the FPGA’s state machine will not interfere), and
control the GPIOs using {get,set}_gpio_attr, possibly in a separate
thread.

So let’s say that may be what manual says in the introduction of the
section devoted to GPIO is too strong: " The E3x0/X3x0 are the first
USRP devices to offer an auxiliary GPIO connection on the motherboard
itself (independent of the daughterboards). These GPIO pins are
controlled directly by the FPGA, where they are controlled by an ATR
(Automatic Transmit / Receive). This allows them to be toggled
simultaneously with other radio-level changes (e.g., enabling or
disabling a TX or RX mixer)."

In fact, according to it, one would guess that the ATR functionality is
the ONLY one implemented and available. On the contrary, as a matter
fact, also the “classical” manual approach where things are controlled
by sw {get,set}_gpio_attr functions is feasible. Interesting to know
for… newbies like me.

Maurizio.

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione
derivante dalla conoscenza di queste informazioni sono rigorosamente
vietate. Qualora abbiate ricevuto questo documento per errore siete
cortesemente pregati di darne immediata comunicazione al mittente e di
provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain
privileged information intended for the addressee(s) only.
Dissemination, copying, printing or use by anybody else is unauthorised.
If you are not the intended recipient, please delete this message and
any attachments and advise the sender by return e-mail, Thanks.

10

Hi Maurizio,

To be honest, currently I do not really know anything about the latency
requirement. I would say that in this proof-of-concept stage of the design, the
“best-we-can-do” approach could be acceptable.
well, in that case, I’d say: just go ahead and try with the polling
method. It should work fine, but it’s “inaccurate” when one relates the
amount of polling you can do in a second (a few 1000/s) with sampling
rates (Millions of samples per second), and it eats up valuable CPU
time, if you just poll as fast as possible (i.e. in a loop without any
sleep(10ms) or so in between). The bad thing about software polling is
that there is no hard guarantee on how often it happens, because it’s up
to your OS (linux) to determine how often the poll thread gets CPU time
– with increased CPU load due to growing complexity of signal
processing, at a later point a polling mechanism that works now might
fail.

So: you’ll really have to define a maximum time that a GPIO toggle may
stay undetected. This shouldn’t be hard – I mean, in the end, there’s
some application’s needs that you’ll want to satisfy.

I must admit I do have one hackish trick up my sleeve, and I’ve never
tried it on E31x, so: your mileage might vary, and this has side
effects:

If you can live without proper time stamps on your samples, you can
trigger sampling in the FPGA by causing an edge on the PPS input:

  • usrp->set_time_now(0); which will reset the device-internal timing to
    zero
  • construct a uhd::stream_cmd_t with stream_now = false; and a time_spec
    of uhd::time_spec_t(1e6); which will theoretically start the streaming
    process in about 11.574 days.
  • usrp->issue_stream_cmd(above command);
  • usrp->set_time_next_pps(uhd::time_spec_t(1e6)); which will set the
    time to ca. 11.574 days from now, as soon as you pull up the PPS input
  • pull up the PPS input

Please be a bit careful with the PPS input. 2V difference of potential
will be plenty.
However, I don’t recommend this method, simply because it counteracts
what you actually want to do with your USRP: doing a measurement over
time. Using timestamps with the accuracy of the clock that feeds the
sampling would probably be a good idea – but you couldn’t, because
you’d be abusing the device timekeeping for your triggering purposes.

Best regards,
Marcus