# Front Panel GPIO on Ettus X310 **URL:** \ **Category:** GNU Radio\ **Created:** [June 1, 2015, 11:45pm UTC](https://www.ruby-forum.com/t/front-panel-gpio-on-ettus-x310/242169 "2015-06-01T23:45:06Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\ **Post date:** [June 1, 2015, 11:45pm UTC](https://www.ruby-forum.com/t/front-panel-gpio-on-ettus-x310/242169/1 "2015-06-01T23:45:06Z")
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](http://gnuradio.4.n7.nabble.com/Front-Panel-GPIO-on-Ettus-X310-tp53979.html) Sent from the GnuRadio mailing list archive at [Nabble.com](http://Nabble.com). ---
**Author:** ![Falessan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/73ab20/32.png) [@Falessan](https://www.ruby-forum.com/u/Falessan)\ **Post date:** [June 2, 2015, 2:11am UTC](https://www.ruby-forum.com/t/front-panel-gpio-on-ettus-x310/242169/2 "2015-06-02T02:11:08Z")
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 ---
**Author:** ![Falessan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/73ab20/32.png) [@Falessan](https://www.ruby-forum.com/u/Falessan)\ **Post date:** [June 2, 2015, 4:04pm UTC](https://www.ruby-forum.com/t/front-panel-gpio-on-ettus-x310/242169/3 "2015-06-02T16:04:13Z")
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:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] 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] > **[Discuss-gnuradio Info Page](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](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\_](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](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 ---
**Author:** ![Falessan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/73ab20/32.png) [@Falessan](https://www.ruby-forum.com/u/Falessan)\ **Post date:** [June 2, 2015, 7:26pm UTC](https://www.ruby-forum.com/t/front-panel-gpio-on-ettus-x310/242169/4 "2015-06-02T19:26:27Z")
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 ---
**Author:** ![Falessan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/73ab20/32.png) [@Falessan](https://www.ruby-forum.com/u/Falessan)\ **Post date:** [August 5, 2015, 11:56pm UTC](https://www.ruby-forum.com/t/front-panel-gpio-on-ettus-x310/242169/5 "2015-08-05T23:56:46Z")
Maurizio, On Wed, Aug 5, 2015 at 7:49 AM, Maurizio Crozzoli [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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#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#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.v#L659) [https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300\_core.v#L304](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: > **[USRP Hardware Driver and Device Manual: GPIO API](https://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](https://www.kernel.org/doc/Documentation/gpio/sysfs.txt) > **[GPIO - eLinux.org](https://elinux.org/GPIO)** 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](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) > Happy hacking, Moritz ---
**Author:** ![Falessan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/73ab20/32.png) [@Falessan](https://www.ruby-forum.com/u/Falessan)\ **Post date:** [August 5, 2015, 5:19pm UTC](https://www.ruby-forum.com/t/front-panel-gpio-on-ettus-x310/242169/6 "2015-08-05T17:19:31Z")
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](http://gnuradio.4.n7.nabble.com/Front-Panel-GPIO-on-Ettus-X310-tp53979p55274.html) Sent from the GnuRadio mailing list archive at [Nabble.com](http://Nabble.com). ---
**Author:** ![Falessan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/73ab20/32.png) [@Falessan](https://www.ruby-forum.com/u/Falessan)\ **Post date:** [August 31, 2015, 6:24pm UTC](https://www.ruby-forum.com/t/front-panel-gpio-on-ettus-x310/242169/7 "2015-08-31T18:24:56Z")
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:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Inviato: mercoledì 5 agosto 2015 23:56 A: Crozzoli Maurizio Cc: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Oggetto: Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310 Maurizio, On Wed, Aug 5, 2015 at 7:49 AM, Maurizio Crozzoli [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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#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#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.v#L659) [https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300\_core.v#L304](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: > **[USRP Hardware Driver and Device Manual: GPIO API](https://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](https://www.kernel.org/doc/Documentation/gpio/sysfs.txt) > **[GPIO - eLinux.org](https://elinux.org/GPIO)** 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. > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) 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. ---
**Author:** ![Falessan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/73ab20/32.png) [@Falessan](https://www.ruby-forum.com/u/Falessan)\ **Post date:** [August 31, 2015, 7:36pm UTC](https://www.ruby-forum.com/t/front-panel-gpio-on-ettus-x310/242169/8 "2015-08-31T19:36:13Z")
Ciao Maurizio, On Mon, Aug 31, 2015 at 9:03 AM, Crozzoli Maurizio [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > In the default FPGA image the GPIO pins are wired up to ATR pins that are > connected to the radio0. > [USRP Hardware Driver and Device Manual: GPIO API](http://files.ettus.com/manual/page_gpio_api.html) > > > 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 ---
**Author:** ![Falessan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/73ab20/32.png) [@Falessan](https://www.ruby-forum.com/u/Falessan)\ **Post date:** [September 1, 2015, 4:43pm UTC](https://www.ruby-forum.com/t/front-panel-gpio-on-ettus-x310/242169/9 "2015-09-01T16:43:55Z")
-----Messaggio originale----- Da: Moritz Fischer [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Inviato: lunedì 31 agosto 2015 19:35 A: Crozzoli Maurizio Cc: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid); 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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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. ---
**Author:** ![Falessan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/73ab20/32.png) [@Falessan](https://www.ruby-forum.com/u/Falessan)\ **Post date:** [September 1, 2015, 5:13pm UTC](https://www.ruby-forum.com/t/front-panel-gpio-on-ettus-x310/242169/10 "2015-09-01T17:13:44Z")
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