Screenshot from 2020-08-27 15-11-36.pngDescription: PNG image
|
| From: | Ivan Zahartchuk |
| Subject: | Re: [USRP-users] GPIO setup via gnuradio |
| Date: | Thu, 27 Aug 2020 15:20:10 +0300 |
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---On Tue, Jun 16, 2020 at 6:39 AM Ivan Zahartchuk <adray0001@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 <michael.dickens@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---On Mon, May 25, 2020 at 6:36 PM Ivan Zahartchuk <adray0001@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 <michael.dickens@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---On Fri, May 15, 2020 at 9:46 AM Ivan Zahartchuk <adray0001@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 change there gives me hope that this works.пт, 15 мая 2020 г. в 00:09, Michael Dickens <michael.dickens@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---On Thu, May 14, 2020 at 3:50 PM Ivan Zahartchuk <adray0001@gmail.com> 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 have not yet carried out any further experiments in connection with quarantine.чт, 14 мая 2020 г. в 22:29, Michael Dickens <michael.dickens@ettus.com>:Hi Ivan - I'm glad to hear you got the firmware / FPGA images sorted out. That's really quite something! I'll need to do some playing around with how to do GPIO in UHD C++. I'm confident there's a way ... just need the right "special sauce" if you know what I mean. Maybe you've made progress on this end? - MLD---On Mon, May 11, 2020 at 4:04 PM Ivan Zahartchuk <adray0001@gmail.com> wrote:If I understand you correctly, then I need to create another block uhdself.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]: <block uhd_rfnoc_FIFO (7)>]: 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 <michael.dickens@ettus.com>:Hi Ivan - I was out last week; here now for a few days. Please keep support@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&D 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---On Thu, May 7, 2020 at 7:38 AM Ivan Zahartchuk <adray0001@gmail.com> 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 <adray0001@gmail.com>: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 <adray0001@gmail.com>: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 <michael.dickens@ettus.com>:Hi Ivan - Let me discuss your query with the Ettus R&D guy who handles gr-uhd. Hopefully he'll be able to clarify your query. - MLD---On Mon, Apr 27, 2020 at 7:59 PM Ivan Zahartchuk <adray0001@gmail.com> 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.
Screenshot from 2020-08-27 15-11-36.png
Description: PNG image
| [Prev in Thread] | Current Thread | [Next in Thread] |