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 <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 <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 <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 <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 <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 <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 >>>>>> 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 <adray0...@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.dick...@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 >>>>>>>>> --- >>>>>>>>> Michael Dickens >>>>>>>>> Ettus Research Technical Support >>>>>>>>> Email: supp...@ettus.com >>>>>>>>> Web: https://ettus.com/ >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, May 11, 2020 at 4:04 PM Ivan Zahartchuk < >>>>>>>>> adray0...@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> 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]: <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.dick...@ettus.com>: >>>>>>>>>> >>>>>>>>>>> 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&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 >>>>>>>>>>> --- >>>>>>>>>>> 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 < >>>>>>>>>>> adray0...@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 <adray0...@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 < >>>>>>>>>>>>> adray0...@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.dick...@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 >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>> adray0...@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. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
