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

[Maurizio Crozzoli]

Maurizio Crozzoli wrote
> 
> Marcus Müller-3 wrote
>> 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.
> Is it a way to suggest me to use a sleep instruction during the poll loop?
> 
> Another question is: why when I set a pin as input the READBACK attribute
> says that the level of such pin is high (i.e. 1)? And it is, definitely,
> as I can verify with a multimeter!
> 
> Maurizio

Solved.

For future reference, it was just a problem related to voltage threshold due
to a pin not enough pulled-down.




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

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

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

[Maurizio Crozzoli]

Marcus Müller-3 wrote
> 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.

Is it a way to suggest me to use a sleep instruction during the poll loop?

Another question is: why when I set a pin as input the READBACK attribute
says that the level of such pin is high (i.e. 1)? And it is, definitely, as
I can verify with a multimeter!

Maurizio



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

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

[Discuss-gnuradio] R: On the "right" approach for developing applications to be run on an E310

[Maurizio Crozzoli]

Da: Marcus Müller-3 [via GnuRadio] [mailto:ml-node+s4n55906...@n7.nabble.com]
Inviato: mercoledì 9 settembre 2015 11:38
A: Crozzoli Maurizio
Oggetto: Re: On the "right" approach for developing applications to be run on 
an E310

GRC is a flowgraph design tool. You wouldn't run it on the E310 (especially as 
it is a graphical tool).
It can generate headless flow graphs set up by python programs that you can 
copy over to the E310 -- that's the usage of GRC I'd recommend in this case.

Your answer is clear.
Just one detail: what is exactly a "headless flow graph"?
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.

[rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non è 
necessario.



logo Ambiente_foglia2.jpg (928 bytes) 





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/R-On-the-right-approach-for-developing-applications-to-be-run-on-an-E310-tp55907.html
Sent from the GnuRadio mailing list archive at Nabble.com.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] On the "right" approach for developing applications to be run on an E310

[Maurizio Crozzoli]

And what about the new RFNoC and GRC to be run on an E310?

>From Ettus site we are told that "RFNoC has been integrated into UHD for our
third generation USRP SDRs (X300-series, E300-series, and future devices)".
Furthermore Ettus site shows some examples where RFNoC blocks are used under
GRC, which is a GUI environment (but they are run on an X series HW...).

So the new question is: what is the right methodology to make designs under
GRC to be run under an E310? What about initial testing steps (especially if
you want to use RFNoc)?

About RFNoC I could imagine a step-wise approache where I prepare the Python
with GRC (where the RFNoC OOT modules are installed) and then I run it on
the E310 (where the RFNoC non-default FPGA configuration is installed). But
what about testing such design? "If your flow graph doesn't use graphical
sinks" how can you test your design? The only way out I can think of is to
rely on data saved to file to be analysed in a post-processing step.

Needless to say that comments are welcome...

TIA!

BR,
Maurizio.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/On-the-right-approach-for-developing-applications-to-be-run-on-an-E310-tp55779p55905.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

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

[Maurizio Crozzoli]

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.

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