[USRP-users] GPIO with X310
ianb at ionconcepts.com
Thu Dec 4 16:39:02 EST 2014
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.
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.
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:
>>>> 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
>> 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
> /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.)
>>>> 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
>>>> 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.
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com
> USRP-users mailing list
> USRP-users at lists.ettus.com
More information about the USRP-users