Re: [Discuss-gnuradio] R: Front Panel GPIO on Ettus X310

[Marcus Müller]

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

On 01.09.2015 16:43, Crozzoli Maurizio wrote:

-----Messaggio originale-----
Da: Moritz Fischer [mailto:address@hidden]
Inviato: lunedì 31 agosto 2015 19:35
A: Crozzoli Maurizio
Cc: address@hidden; 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 <address@hidden> 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.

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio