Re: [USRP-users] GPIO setup via gnuradio

[Marcus D. Leech via USRP-users]

On 08/27/2020 12:45 PM, Ivan Zahartchuk wrote:

UHD 3.15
uhd_cal_rx_iq_balance
as far as I understand your question, then the calibration program that is 
provided with the uhd driver

Have you noticed a difference in image suppression for different tuned 
frequencies?  What is your signal amplitude, and what is your gain setting?




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] GPIO setup via gnuradio

[Marcus D. Leech via USRP-users]

On 08/27/2020 08:20 AM, Ivan Zahartchuk via USRP-users wrote:
Hi there. My problem is that even after calibration I can clearly see 
the mirror channel on my USRP N 210 with SBX. Maybe someone will tell 
you how to solve this problem. This problem is observed on several 
boards and different boards.

What version of UHD?

How are you running the calibration tools?

Looks like the image suppression is only about 20dB, which I *think* is 
poorer than the algorithms can achieve (it has been a while since I looked

  at this).




вт, 16 июн. 2020 г. в 17:28, Michael Dickens 
mailto:michael.dick...@ettus.com>>:


Hi Ivan - OK; so you got the GRC <-> GR <-> UHD <-> GPIO access to
work? Well done!

As for your next question about tuning times: the E313 is the same
as an E310 in terms of the USRP part. Here's my understanding:

Tuning times if the frequencies do not require changing out a RX
filter should be around 25 ms; jumping between RX filters should
be more like 125 ms; we use a different "RX filter" for each
different frequency range. These are -very- typical tuning times
for the E31x series; actually, this is true for most of our USRPs
except the N3xy series which are intentionally designed with fast
frequency switching in mind (among other attributes).

In theory one could speed up tuning via FPGA code. I'm not an FPGA
programmer, so I don't know how to do this nor the complexity of
doing so -- just that in theory it could be done for specific user
needs.

I hope this is useful! - MLD
---
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com 
Web: https://ettus.com/


On Tue, Jun 16, 2020 at 6:39 AM Ivan Zahartchuk
mailto:adray0...@gmail.com>> wrote:

  Hello. I nevertheless got to work and equipment and
everything worked out for me. Gpio works. It turns out that in
theory, you can connect to it through dev as well as to the
gps receiver. I have one more question for you. I plan to also
use the E313 as a frequency tunable scanning receiver. But as
far as I was written before (and I was convinced of this
myself) that the frequency tuning is slow due to the
configuration of the filters on the board. Tell me how can I
get around this and speed up the scan. I want to achieve a
speed of at least 1ms at 50 MHz and the frequency tuning
itself in the E310 takes about 100 ms.

пт, 29 мая 2020 г. в 23:28, Michael Dickens
mailto:michael.dick...@ettus.com>>:

Hi Ivan - It was a crazy week for me; I still don't even
have the required software installed; putting out so many
fires I can't count them any longer! I sincerely hope next
week is less stressful, and I can make progress on getting
things installed. Have you made any progress on your end?
Cheers & happy weekend again! - MLD
---
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com 
Web: https://ettus.com/


On Mon, May 25, 2020 at 6:36 PM Ivan Zahartchuk
mailto:adray0...@gmail.com>> wrote:

  Hello. There are no changes so far. There is no way
to get to the equipment. Waiting for your feedback on
the code. Have a nice weekend

вт, 19 мая 2020 г. в 00:19, Michael Dickens
mailto:michael.dick...@ettus.com>>:

HI Ivan - Happy Monday! I hope you had a good
weekend. I took an extra part day off on both
ends, which made for a lovely elongated time. I'll
take a look at your code shortly; I'm moving
between computers, so I'll need to create the UHD
3.15.0.0 + GR 3.7.14.0 Release + gr-ettus master
installs for testing this. Always a good time
getting a new computer, but it does take time to
set it up reasonably well! Any updates on your
end? - MLD
---
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com 
Web: https://ettus.com/


On Fri, May 15, 2020 at 9:46 AM Ivan Zahartchuk
mailto:adray0...@gmail.com>>
wrote:

Thanks for your support. The archive has a
file for USRP E310 and for PC. For now, I'm
just sending a request via gnuradio using the
slider. I just have not figured out
get_gpio_attr but the fact that the values
 

Re: [USRP-users] GPIO setup via gnuradio

[Ivan Zahartchuk via USRP-users]

Hi there. My problem is that even after calibration I can clearly see the
mirror channel on my USRP N 210 with SBX. Maybe someone will tell you how
to solve this problem. This problem is observed on several boards and
different boards.

вт, 16 июн. 2020 г. в 17:28, Michael Dickens :

> Hi Ivan - OK; so you got the GRC <-> GR <-> UHD <-> GPIO access to work?
> Well done!
>
> As for your next question about tuning times: the E313 is the same as an
> E310 in terms of the USRP part. Here's my understanding:
>
> Tuning times if the frequencies do not require changing out a RX filter
> should be around 25 ms; jumping between RX filters should be more like 125
> ms; we use a different "RX filter" for each different frequency range.
> These are -very- typical tuning times for the E31x series; actually, this
> is true for most of our USRPs except the N3xy series which are
> intentionally designed with fast frequency switching in mind (among other
> attributes).
>
> In theory one could speed up tuning via FPGA code. I'm not an FPGA
> programmer, so I don't know how to do this nor the complexity of doing so
> -- just that in theory it could be done for specific user needs.
>
> I hope this is useful! - MLD
> ---
> Michael Dickens
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: https://ettus.com/
>
>
> On Tue, Jun 16, 2020 at 6:39 AM Ivan Zahartchuk 
> wrote:
>
>>   Hello. I nevertheless got to work and equipment and everything worked
>> out for me. Gpio works. It turns out that in theory, you can connect to it
>> through dev as well as to the gps receiver. I have one more question for
>> you. I plan to also use the E313 as a frequency tunable scanning receiver.
>> But as far as I was written before (and I was convinced of this myself)
>> that the frequency tuning is slow due to the configuration of the filters
>> on the board. Tell me how can I get around this and speed up the scan. I
>> want to achieve a speed of at least 1ms at 50 MHz and the frequency tuning
>> itself in the E310 takes about 100 ms.
>>
>> пт, 29 мая 2020 г. в 23:28, Michael Dickens :
>>
>>> Hi Ivan - It was a crazy week for me; I still don't even have the
>>> required software installed; putting out so many fires I can't count them
>>> any longer! I sincerely hope next week is less stressful, and I can make
>>> progress on getting things installed. Have you made any progress on your
>>> end? Cheers & happy weekend again! - MLD
>>> ---
>>> Michael Dickens
>>> Ettus Research Technical Support
>>> Email: supp...@ettus.com
>>> Web: https://ettus.com/
>>>
>>>
>>> On Mon, May 25, 2020 at 6:36 PM Ivan Zahartchuk 
>>> wrote:
>>>
   Hello. There are no changes so far. There is no way to get to the
 equipment. Waiting for your feedback on the code. Have a nice weekend

 вт, 19 мая 2020 г. в 00:19, Michael Dickens >>> >:

> HI Ivan - Happy Monday! I hope you had a good weekend. I took an extra
> part day off on both ends, which made for a lovely elongated time. I'll
> take a look at your code shortly; I'm moving between computers, so I'll
> need to create the UHD 3.15.0.0 + GR 3.7.14.0 Release + gr-ettus master
> installs for testing this. Always a good time getting a new computer, but
> it does take time to set it up reasonably well! Any updates on your end? -
> MLD
> ---
> Michael Dickens
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: https://ettus.com/
>
>
> On Fri, May 15, 2020 at 9:46 AM Ivan Zahartchuk 
> wrote:
>
>> Thanks for your support. The archive has a file for USRP E310 and for
>> PC. For now, I'm just sending a request via gnuradio using the slider. I
>> just have not figured out get_gpio_attr but the fact that the values 
>> change
>> there gives me hope that this works.
>>
>> пт, 15 мая 2020 г. в 00:09, Michael Dickens <
>> michael.dick...@ettus.com>:
>>
>>> That's some positive progress, Ivan! Do you have any code you can
>>> pass on to me to try? I have a variety of USRPs around that should be
>>> usable with GPIO; doesn't need to be an E310 specifically (that's what 
>>> my
>>> notes tell me you're using ... yes?). I also have both UHD 3.15.0.0 and 
>>> the
>>> 3.15.LTS branch available for testing. - MLD
>>> ---
>>> Michael Dickens
>>> Ettus Research Technical Support
>>> Email: supp...@ettus.com
>>> Web: https://ettus.com/
>>>
>>>
>>> On Thu, May 14, 2020 at 3:50 PM Ivan Zahartchuk 
>>> wrote:
>>>
 Hello. Yes, I have advanced in this direction. Indeed, I figured out a 
 bit with GPIO. The idea is to initialize usrp_source earlier than the 
 RFNoC block (I don’t know what this is related to), and then I avoid 
 the error and in theory I have the same access to gpio. But when 
 calling the get_gpio_banks command. “FP0” is returned to me and not 
 “INTO”; I 

Re: [USRP-users] GPIO setup via gnuradio

[Ivan Zahartchuk via USRP-users]

If I understand you correctly, then I need to create another block uhd
self.uhd_usrp_source = uhd.usrp_source ( ",". join (("", "")),
uhd.stream_args ( cpu_format = "fc32", channels =
range (1), ), )
so I created it. But I don’t understand how it works since I don’t connect
it anywhere and I get an error
 [WARNING] [RFNOC] [legacy compat] Not enough FIFO ports to connect, not
all TX sinks will be connected [WARNING] [RFNOC] [legacy_compat] No DDCs
detected. You will only be able to receive at the radio frontend rate.
[WARNING] [RFNOC] [legacy_compat] No DUCs detected. You will only be able
to transmit at the radio frontend rate. [WARNING] [RFNOC] Assuming max
packet size for 0 / Radio_0 thread [thread-per-block [0]: ]: RuntimeError: On node 0 / FIFO_0, output port 0 is
already connected.
 If somewhere there are examples of how to get to gpio correctly, I would
be very grateful if you would provide them to me. I figured out the FPGA
firmware and now the only problem is gpio.

пн, 11 мая 2020 г. в 17:58, Michael Dickens :

> Hi Ivan - I was out last week; here now for a few days. Please keep
> supp...@ettus.com on CC so that someone there can try to help you when
> I'm away.
>
> Here's a summary of the discussion with the Ettus R person I spoke with
> about accessing the GPIO via GRC: you have to create a UHD USRP Source/Sink
> object, then you use it to access the underlying C++ USRP object (via
> Python) to obtain the GPIO API. You can't access the UHD GPIO API from
> RFNoC blocks; there is no USRP object to provide access.
>
> Are you still having issues with the FPGA creation? If so, please update
> me on where you're at and I'll do what I can to help. - MLD
> ---
> Michael Dickens
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: https://ettus.com/
>
>
> On Thu, May 7, 2020 at 7:38 AM Ivan Zahartchuk 
> wrote:
>
>> Hello. Sorry to bother you so often. But I really want to understand this
>> board and firmware. I solved the problem with the fact that I did not
>> create an image for FPGA. The problem was that at startup, the
>> rfnoc_ce_auto_inst_e31x.v configuration file is created, which also tells
>> which blocks to compile for VIvado. But the next time you call
>> ./uhd_image_builder, this file is not replaced with a new one, but the
>> rfnoc_ce_auto_inst_e310.v file is created, which does not participate in
>> further work. But I also had questions about the GPIO.
>>
>> вс, 3 мая 2020 г. в 14:09, Ivan Zahartchuk :
>>
>>> Hello. Your colleagues haven’t answered anything yet? Tell me, could you
>>> generate firmware for RFNoC and drop it to me. Sorry to ask a lot, I just
>>> can not test the error with generating a bit file for FPGA differently.
>>>
>>> ср, 29 апр. 2020 г. в 08:11, Ivan Zahartchuk :
>>>
 Thanks! I found out that the problem in the firmware comes from
 applications for creating this firmware. After opening the firmware using
 Vivado, I found in it the same FIR block that I did not add there. Perhaps
 this is due to the fact that I installed the wrong version of Vivado.
 Because I also don’t generate the dts file that is needed for firmware. I
 installed Vivado 18.3 HL System Edition.

 ср, 29 апр. 2020 г. в 00:12, Michael Dickens >>> >:

> Hi Ivan - Let me discuss your query with the Ettus R guy who handles
> gr-uhd. Hopefully he'll be able to clarify your query. - MLD
> ---
> Michael Dickens
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: https://ettus.com/
>
>
> On Mon, Apr 27, 2020 at 7:59 PM Ivan Zahartchuk 
> wrote:
>
>> Unfortunately for all this time I have not come a step closer to solving 
>> my problems. I don’t know how to solve the problem with flashing fpga.
>> I even reinstalled ubuntu but it did not help. The only assumption is 
>> that the board has its own memory that is not erased after overwriting 
>> the SD card. But this is also doubtful.
>> In addition, I still didn’t get to switch to the GPIO through the RFNoC 
>> block and I am thinking about returning to version 3.14. But honestly I 
>> would like to deal with this version.
>>
>>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] GPIO setup via gnuradio

[Michael Dickens via USRP-users]

Hi Ivan - I'll work with you off-list on this topic. If we figure out
something useful, we can report back to the lists here. - MLD



On Fri, Apr 17, 2020 at 7:41 PM Ivan Zahartchuk  wrote:

>
> Honestly, I have worked very little with gnuradio and do not quite
> understand what it means to transfer a UHD USRP object. If it does not make
> it difficult for you to show how it works, I will greatly appreciate it.
>
> пт, 17 апр. 2020 г. в 21:27, Michael Dickens :
>
>> Ohh ... nice! I didn't know gr-uhd provided that interface! A quick
>> search shows it's in GR as of sometime in version 3.7 .. not sure how far
>> back, but certainly in the current release. Good to know!
>>
>> Note that this gr-uhd GPIO API is available in Python (via SWIG) as well
>> as C++ ... BUT: it is not exposed into GRC.
>>
>> Hence, to use the UHD GPIO API inside GRC, you'll still need to do what I
>> wrote previously: provide the UHD USRP object to your custom GRC block
>> (whether Python or C++), and then it can manipulate the USRP GPIO via the
>> gr-uhd Python provided API, or directly in C++ via the UHD C++ API for GPIO.
>>
>> Fun fun fun! - MLD
>>
>>
>> On Fri, Apr 17, 2020 at 1:36 PM Rob Kossler  wrote:
>>
>>> The following link (GR documentation) shows some UHD GPIO functionality.
>>> https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__block.html
>>>
>>> On Fri, Apr 17, 2020 at 10:27 AM Michael Dickens via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hi Ivan - I'm assuming you mean configure and control a USRP's GPIO via
 UHD in GNU Radio?

 In theory this should be possible, at least in C++ and of course it
 requires that the specific USRP have GPIO ...

 I'm not sure if there's a Python GPIO API as of UHD 3.15, but if there
 is then that method should work about the same as the C++ method.

 You'd have to get access to the instantiated USRP object, then you can
 use that object to issue GPIO related calls. See these pages for more info
 about GPIO in UHD:

 < https://files.ettus.com/manual/page_gpio_api.html >

 <
 https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD#Example:_Using_Timed_Commands_to_Control_GPIO
  >

 <
 https://github.com/EttusResearch/uhd/blob/master/host/examples/gpio.cpp
  >

 I can't think of a current GNU Radio block that handles UHD USRP GPIO.
 If you look around & can't find one, then you'd need to create a custom GNU
 Radio block to handle this. You would pass your new block the USRP object,
 which you'd then use for the GPIO calls ... using Python or C++ depending
 on which API is available for your specific UHD.

 Maybe there's another way that I don't know of? If so hopefully others
 will add to the discussion!

 Hope this is useful! - MLD

 On Fri, Apr 17, 2020 at 9:15 AM Ivan Zahartchuk via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Hello. Please tell me if it is possible to configure GPIO using
> gnuradio. I want to use RFNOC blocks and switch an external device using
> GPIO
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
 ___
 USRP-users mailing list
 USRP-users@lists.ettus.com
 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

>>>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] GPIO setup via gnuradio

[Ivan Zahartchuk via USRP-users]

Honestly, I have worked very little with gnuradio and do not quite
understand what it means to transfer a UHD USRP object. If it does not make
it difficult for you to show how it works, I will greatly appreciate it.

пт, 17 апр. 2020 г. в 21:27, Michael Dickens :

> Ohh ... nice! I didn't know gr-uhd provided that interface! A quick search
> shows it's in GR as of sometime in version 3.7 .. not sure how far back,
> but certainly in the current release. Good to know!
>
> Note that this gr-uhd GPIO API is available in Python (via SWIG) as well
> as C++ ... BUT: it is not exposed into GRC.
>
> Hence, to use the UHD GPIO API inside GRC, you'll still need to do what I
> wrote previously: provide the UHD USRP object to your custom GRC block
> (whether Python or C++), and then it can manipulate the USRP GPIO via the
> gr-uhd Python provided API, or directly in C++ via the UHD C++ API for GPIO.
>
> Fun fun fun! - MLD
>
>
> On Fri, Apr 17, 2020 at 1:36 PM Rob Kossler  wrote:
>
>> The following link (GR documentation) shows some UHD GPIO functionality.
>> https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__block.html
>>
>> On Fri, Apr 17, 2020 at 10:27 AM Michael Dickens via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi Ivan - I'm assuming you mean configure and control a USRP's GPIO via
>>> UHD in GNU Radio?
>>>
>>> In theory this should be possible, at least in C++ and of course it
>>> requires that the specific USRP have GPIO ...
>>>
>>> I'm not sure if there's a Python GPIO API as of UHD 3.15, but if there
>>> is then that method should work about the same as the C++ method.
>>>
>>> You'd have to get access to the instantiated USRP object, then you can
>>> use that object to issue GPIO related calls. See these pages for more info
>>> about GPIO in UHD:
>>>
>>> < https://files.ettus.com/manual/page_gpio_api.html >
>>>
>>> <
>>> https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD#Example:_Using_Timed_Commands_to_Control_GPIO
>>>  >
>>>
>>> <
>>> https://github.com/EttusResearch/uhd/blob/master/host/examples/gpio.cpp
>>>  >
>>>
>>> I can't think of a current GNU Radio block that handles UHD USRP GPIO.
>>> If you look around & can't find one, then you'd need to create a custom GNU
>>> Radio block to handle this. You would pass your new block the USRP object,
>>> which you'd then use for the GPIO calls ... using Python or C++ depending
>>> on which API is available for your specific UHD.
>>>
>>> Maybe there's another way that I don't know of? If so hopefully others
>>> will add to the discussion!
>>>
>>> Hope this is useful! - MLD
>>>
>>> On Fri, Apr 17, 2020 at 9:15 AM Ivan Zahartchuk via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hello. Please tell me if it is possible to configure GPIO using
 gnuradio. I want to use RFNOC blocks and switch an external device using
 GPIO
 ___
 USRP-users mailing list
 USRP-users@lists.ettus.com
 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] GPIO setup via gnuradio

[Michael Dickens via USRP-users]

Ohh ... nice! I didn't know gr-uhd provided that interface! A quick search
shows it's in GR as of sometime in version 3.7 .. not sure how far back,
but certainly in the current release. Good to know!

Note that this gr-uhd GPIO API is available in Python (via SWIG) as well as
C++ ... BUT: it is not exposed into GRC.

Hence, to use the UHD GPIO API inside GRC, you'll still need to do what I
wrote previously: provide the UHD USRP object to your custom GRC block
(whether Python or C++), and then it can manipulate the USRP GPIO via the
gr-uhd Python provided API, or directly in C++ via the UHD C++ API for GPIO.

Fun fun fun! - MLD


On Fri, Apr 17, 2020 at 1:36 PM Rob Kossler  wrote:

> The following link (GR documentation) shows some UHD GPIO functionality.
> https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__block.html
>
> On Fri, Apr 17, 2020 at 10:27 AM Michael Dickens via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi Ivan - I'm assuming you mean configure and control a USRP's GPIO via
>> UHD in GNU Radio?
>>
>> In theory this should be possible, at least in C++ and of course it
>> requires that the specific USRP have GPIO ...
>>
>> I'm not sure if there's a Python GPIO API as of UHD 3.15, but if there is
>> then that method should work about the same as the C++ method.
>>
>> You'd have to get access to the instantiated USRP object, then you can
>> use that object to issue GPIO related calls. See these pages for more info
>> about GPIO in UHD:
>>
>> < https://files.ettus.com/manual/page_gpio_api.html >
>>
>> <
>> https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD#Example:_Using_Timed_Commands_to_Control_GPIO
>>  >
>>
>> < https://github.com/EttusResearch/uhd/blob/master/host/examples/gpio.cpp
>>  >
>>
>> I can't think of a current GNU Radio block that handles UHD USRP GPIO. If
>> you look around & can't find one, then you'd need to create a custom GNU
>> Radio block to handle this. You would pass your new block the USRP object,
>> which you'd then use for the GPIO calls ... using Python or C++ depending
>> on which API is available for your specific UHD.
>>
>> Maybe there's another way that I don't know of? If so hopefully others
>> will add to the discussion!
>>
>> Hope this is useful! - MLD
>>
>> On Fri, Apr 17, 2020 at 9:15 AM Ivan Zahartchuk via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello. Please tell me if it is possible to configure GPIO using
>>> gnuradio. I want to use RFNOC blocks and switch an external device using
>>> GPIO
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] GPIO setup via gnuradio

[Rob Kossler via USRP-users]

The following link (GR documentation) shows some UHD GPIO functionality.
https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__block.html

On Fri, Apr 17, 2020 at 10:27 AM Michael Dickens via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Ivan - I'm assuming you mean configure and control a USRP's GPIO via
> UHD in GNU Radio?
>
> In theory this should be possible, at least in C++ and of course it
> requires that the specific USRP have GPIO ...
>
> I'm not sure if there's a Python GPIO API as of UHD 3.15, but if there is
> then that method should work about the same as the C++ method.
>
> You'd have to get access to the instantiated USRP object, then you can use
> that object to issue GPIO related calls. See these pages for more info
> about GPIO in UHD:
>
> < https://files.ettus.com/manual/page_gpio_api.html >
>
> <
> https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD#Example:_Using_Timed_Commands_to_Control_GPIO
>  >
>
> < https://github.com/EttusResearch/uhd/blob/master/host/examples/gpio.cpp
>  >
>
> I can't think of a current GNU Radio block that handles UHD USRP GPIO. If
> you look around & can't find one, then you'd need to create a custom GNU
> Radio block to handle this. You would pass your new block the USRP object,
> which you'd then use for the GPIO calls ... using Python or C++ depending
> on which API is available for your specific UHD.
>
> Maybe there's another way that I don't know of? If so hopefully others
> will add to the discussion!
>
> Hope this is useful! - MLD
>
> On Fri, Apr 17, 2020 at 9:15 AM Ivan Zahartchuk via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello. Please tell me if it is possible to configure GPIO using gnuradio.
>> I want to use RFNOC blocks and switch an external device using GPIO
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] GPIO setup via gnuradio

[Michael Dickens via USRP-users]

Hi Ivan - I'm assuming you mean configure and control a USRP's GPIO via UHD
in GNU Radio?

In theory this should be possible, at least in C++ and of course it
requires that the specific USRP have GPIO ...

I'm not sure if there's a Python GPIO API as of UHD 3.15, but if there is
then that method should work about the same as the C++ method.

You'd have to get access to the instantiated USRP object, then you can use
that object to issue GPIO related calls. See these pages for more info
about GPIO in UHD:

< https://files.ettus.com/manual/page_gpio_api.html >

<
https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD#Example:_Using_Timed_Commands_to_Control_GPIO
 >

< https://github.com/EttusResearch/uhd/blob/master/host/examples/gpio.cpp >

I can't think of a current GNU Radio block that handles UHD USRP GPIO. If
you look around & can't find one, then you'd need to create a custom GNU
Radio block to handle this. You would pass your new block the USRP object,
which you'd then use for the GPIO calls ... using Python or C++ depending
on which API is available for your specific UHD.

Maybe there's another way that I don't know of? If so hopefully others will
add to the discussion!

Hope this is useful! - MLD

On Fri, Apr 17, 2020 at 9:15 AM Ivan Zahartchuk via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello. Please tell me if it is possible to configure GPIO using gnuradio.
> I want to use RFNOC blocks and switch an external device using GPIO
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com