[USRP-users] GPIO with X310

Robert Kossler Robert.D.Kossler.3 at nd.edu
Thu Dec 4 19:36:15 EST 2014


I implemented the following code in my C++ app and it seemed to work as
expected.  However, I noticed strange behavior on the LEDs.

Below is the code I added so that I would get a "1" on GPIO bit 2 while
transmitting (ignoring tx/rx case).  Rather than showing red Tx/Rx LEDs for
both channels as is the case if I comment out this code, I see an orange
LED for channel 0 Tx/Rx and the channel 0 Rx2 is green.  Channel 1 behaves
the same with code in place or removed (Red Tx/Rx LED while transmitting
and Rx2 LED is off).  Then, even after I quit the app, the channel 0 (RF-A)
LEDs remain orange for Tx/Rx and green for Rx2.  Is this expected behavior?

    //set GPIO config
    //set to output 1 on GPIO 2 when transmitting
    boost::uint32_t mask = 1 << 2;
    boost::uint32_t reg_val = mask;
    std::string fpgpio = "FP0";
    usrp->set_gpio_attr(fpgpio, std::string("DDR"), reg_val, mask);
    usrp->set_gpio_attr(fpgpio, std::string("ATR_TX"), reg_val, mask);
    usrp->set_gpio_attr(fpgpio, std::string("CTRL"), reg_val, mask);

On Thu, Dec 4, 2014 at 5:17 PM, Andy Walls via USRP-users <
usrp-users at lists.ettus.com> wrote:

> On Thu, 2014-12-04 at 13:39 -0800, Ian Buckley wrote:
> > If you want to think of ATR mode in an easier way imagine it as a lookup
> table.
> > There are 4 rows in the table, one for each possible state (IDLE, RX
> only, TX only, RX+TX).
> > There is a column for every GPIO pin.
> > You pre-populate the table before operation using UHD so that each pin
> > produces a waveform dependent on the radio state.
>
> Kind of like the attached PNG. :)
>
> Column 0 is an ATR "active low transmitter key".
> Column 1 is a manual GPIO.
> Columns 2 through 5 are just individual monitors of the various ATR
> indicators.
>
> > Alternatively each pin can also be configured as a conventional S/W
> > controllable GPIO if you prefer, remembering also that UHD gives you
> > the ability to attach a time spec to register write operations so you
> > can schedule GPIO pin toggles fairly tightly.
>
>
>
>
> > State changes in the radio happen as packets are packed/unpacked and
> > thus you have the group delay of the DSP filters to take into account
> > which is interpolation rate dependent, and on the order of 10's to
> > 100's of sample clock cycles. At 5nS a cycle on X310 you are likely to
> > be seeing a GPIO toggle within 1uS of the RF signal data hitting the
> > SMA I'd say.
>
> Ah, thank you.  Good to know.
>
> Regards,
> Andy
>
> > -Ian
> >
> > On Dec 4, 2014, at 1:24 PM, Andy Walls via USRP-users <
> usrp-users at lists.ettus.com> wrote:
> >
> > > On Thu, 2014-12-04 at 16:04 -0500, Marcus D. Leech via USRP-users
> wrote:
> > >> On 12/04/2014 04:01 PM, Andy Walls via USRP-users wrote:
> > >>> On Thu, 2014-12-04 at 15:37 -0500, Robert Kossler via USRP-users
> wrote:
> > >>>> Hi,
> > >>>> I would like to trigger some external instrumentation when my X310
> > >>>> begins transmitting.  I have reviewed the GPIO documentation and it
> > >>>> seems that the ATR functionality with the GPIO pins would work well
> > >>>> for me.  However, I have a few questions:
> > >>>> 1) I see that I can set a particular GPIO pin to output a "1" during
> > >>>> transmit, but what does "transmit" mean?
> > >>> There are 4 ATR indicators that can be mapped to a GPIO:  Idle, Rx,
> Tx,
> > >>> and Tx+Rx.  In my testing, they all appear to be mutually exclusive.
> > >>> So, if you want a "1" value when the transmit is ongoing, regardless
> of
> > >>> receive, you need both the Tx and Tx+Rx indicator mapped to that GPIO
> > >>> pin.
> > >>>
> > >>>
> > >> One could (please don't shoot me) use an old-school solution to this
> > >> class of problem and insert a COR-type device to turn your bits on and
> > >> off...
> > >
> > > /me holsters gun
> > > (I don't know what "COR" means.)
> > >
> > > The UHD API does let one map any set of the 4 ATR indicators to the
> GPIO
> > > pin, so it's not a big problem, just a "gotcha".  The logic gets fun
> > > when you need an active low transmit GPIO output regardless of receive.
> > > (Left as an exercise for the reader.)
> > >
> > > Regards,
> > > Andy
> > >
> > >>
> > >>>>   Since there are two channels, does it mean transmit on either
> > >>>> channel?  I don't see a way to specify this behavior as a function
> of
> > >>>> the transmit channel.
> > >>> Good question.   Looking at the FPGA source code, it looks like the
> > >>> Front Panel GPIO is propagated up from radio 0 (the first daughter
> card)
> > >>> and not at all from radio 1 (the second daughter card).
> > >>>
> > >>> Obviously a quick test with a DVM or oscilloscope can be used to
> verify
> > >>> that.
> > >>>
> > >>>
> > >>>> 2) I am not looking for really precise accuracy (really, about 1
> msec
> > >>>> is good enough), but I would like for this transmit bit rising edge
> to
> > >>>> occur at the same time as the RF signal appears at the SMA
> connector.
> > >>>> Does this seem possible?  If not, perhaps there would at least be a
> > >>>> "fixed" delay between the onset of the transmit bit and the RF?
> > >>> Another good question.  I can't help here.
> > >>>
> > >>>
> > >>>> 3) I see how this is called from C++ using set_gpio_attr.  However,
> I
> > >>>> would like to do this from GNU radio.  Is this possible?  Are there
> > >>>> any examples?
> > >>> There is no existing GNURadio block.  I had to write my own block for
> > >>> GNURadio and GRC.  It is possible.
> > >>>
> > >>> Regards,
> > >>> Andy
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> USRP-users mailing list
> > >>> USRP-users at lists.ettus.com
> > >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> > >>>
> > >>
> > >>
> > >
> > >
> > >
> > > _______________________________________________
> > > USRP-users mailing list
> > > USRP-users at lists.ettus.com
> > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141204/e3a97527/attachment-0002.html>


More information about the USRP-users mailing list