Re: [USRP-users] New mender instructions?
Hi Rob, Per (https://files.ettus.com/manual/page_usrp_e3xx.html#e3xx_rasm_mender) I used the following on an E320: mender install /home/root/usrp_e320_fs.mender I'm pretty sure I needed to add a force flag to it as well. Jim From: USRP-users on behalf of Rob Kossler via USRP-users Sent: Thursday, October 8, 2020 3:10 PM To: usrp-users Subject: [USRP-users] New mender instructions? Hi, What is the new mender command to use on the N310 under UHD 4 file system? The -rootfs option from the following instructions is not a valid option. root@ni-n3xx-serial:~# mender -rootfs /home/root/usrp_n3xx_fs.mender ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] B210 USRP object creation
Marcus, Thanks again. I am using the GRC as a test-bed for writing gr-code as the flow-graph method promotes well defined partitioning of the signal processing functions, including of course the UHD interface. The project which I may have mentioned previously is Direct Sequence Spread Spectrum based and GRC C++ OOT blocks have been developed. These generate PRN sequences for transmission and then acquire and track the carrier and PRN code phases in a modular receiver. Much of the concept development can therefore be done using the GRC stand-alone or using the USRP in RF loopback with a simple BPSK modulator/demodulator pair. I am aware of the GRC scheduler shortcomings particularly in terms of throughput timing stability, however for now, some form of primitive access to the UHD hardware is required for external timing event signalling through the GPIO. I will have look at some of Balint Seeber’s old code and run some of the UHD test code as suggested. Finally to add to my woes, the B210 is no longer “found” after my vid and pid experiment. USB finds the device with the vid and pid as written, but it can no longer be accessed through UHD application. I have tried carefully editing the uhd-usrp.rules file to comply with the new pid value, but without success. Perhaps a cautionary warning should be added to the EEPROM on USRP devices note! Regards, David From: Marcus D. Leech via USRP-users Sent: Thursday, October 8, 2020 8:42 PM To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] B210 USRP object creation On 10/08/2020 03:33 PM, David Taylor (manx.net) via USRP-users wrote: Point taken. - I didn’t actually check the original default values of the VID and PID, but they were reset according to the table provided, so that they could be tested as arguments in the make statement below. “About the Motherboard and Daughtercard EEPROM on USRP Devices (5th August 2020)” The aim is to be able to manipulate some GPIO bits in the block work function and to align events using the 1PPS input. Regards, David GD4FMB Ok, so presumably you're using Gnu Radio, since you're talking about "block work functions". So this issue straddles the two universes--UHD/USRP and Gnu Radio. I'd encourage you to use the UHD test tools to confirm sanity of your setup and then move on to a stupid-simple flow-graph with standard blocks. Once THAT works, then one can think about grabbing the usrp source/sink "object" and being able to use it in your own processing "block". There used to be a way to do this even within GRC but I fear that it was a custom block (perhaps from the old gr-balint set of blocks) that would allow you to grab an object handle and pass it as a variable into your own functions. It's something I've wanted to do myself from time to time. Of course if you're coding in "naked" GR, without using GRC, it's easy. But GRC uses a "data flow" model, and is less "procedural", so it gives an added layer of abstraction that makes it difficult to do what you want to do. The gr-uhd module provides GPIO functions: https://www.gnuradio.org/doc/doxygen-v3.7.9.1/classgr_1_1uhd_1_1usrp__block.html#ab09502e1c8c43a546616b9a998f137f1 But they aren't exposed in any meaningful way into GRC that I know of. I'll note that in GR3.9, there is support for something called "code snippets" which would let you "dip down into the lower layers" without having to post-facto edit generated Python code. ___ 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] Operating E310 from host?
Note that on UHD 3.15, the N310 will also not let you do that over the RJ45. --M On Fri, Oct 2, 2020 at 8:01 PM Michael Dickens via USRP-users < usrp-users@lists.ettus.com> wrote: > UHD 3.15: just on the E310. No network mode. > > UHD 4.0: either. > > > On Fri, Oct 2, 2020 at 1:57 PM Rob Kossler via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi, >> Is it possible to run an Ettus example app & UHD on the host PC with an >> E310 (rather than running the app/UHD directly on the E310)? This is a >> typical mode for the N310, but I wasn't sure if the E310 supported it. I >> am interested in the answer for both 3.15 and 4.0. >> Rob >> ___ >> 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] B210 USRP object creation
David, To clarify, you used "write-vid" and "write-pid" arguments with UHD b2xx_fx3_utils [1] to convert your NI-2901 to a B210 using the VID and PID values found in the "About the Motherboard and Daughtercard EEPROM on USRP Devices" KB [2]. Correct? And after changing these values, you are no longer able to reach the device using uhd_find_devices? Does the behavior change if you feed in arguments for the unit's serial number? e.g. uhd_find_devices --args serial= If memory serves, I'd expect you to still be able to find the device with uhd_find_devices irrespective of the programmed VID and PID. However, those values are necessary for basically anything else as they're used to determine the FPGA image that is loaded onto the unit at runtime. [1] https://github.com/EttusResearch/uhd/blob/master/host/utils/b2xx_fx3_utils.cpp [2] https://kb.ettus.com/About_the_Motherboard_and_Daughtercard_EEPROM_on_USRP_Devices#USB_VID.2FPID On Fri, Oct 9, 2020 at 10:09 AM David Taylor (manx.net) via USRP-users < usrp-users@lists.ettus.com> wrote: > Marcus, > > Thanks again. > > I am using the GRC as a test-bed for writing gr-code as the flow-graph > method promotes well defined partitioning of the signal processing > functions, including of course the UHD interface. > > The project which I may have mentioned previously is Direct Sequence > Spread Spectrum based and GRC C++ OOT blocks have been developed. These > generate PRN sequences for transmission and then acquire and track the > carrier and PRN code phases in a modular receiver. > Much of the concept development can therefore be done using the GRC > stand-alone or using the USRP in RF loopback with a simple BPSK > modulator/demodulator pair. > > I am aware of the GRC scheduler shortcomings particularly in terms of > throughput timing stability, however for now, some form of primitive access > to the UHD hardware is required for external timing event signalling > through the GPIO. > > I will have look at some of Balint Seeber’s old code and run some of the > UHD test code as suggested. > > Finally to add to my woes, the B210 is no longer “found” after my vid and > pid experiment. > USB finds the device with the vid and pid as written, but it can no longer > be accessed through UHD application. I have tried carefully editing the > uhd-usrp.rules file to comply with the new pid value, but without success. > Perhaps a cautionary warning should be added to the EEPROM on USRP devices > note! > > Regards, > David > > > > *From:* Marcus D. Leech via USRP-users > *Sent:* Thursday, October 8, 2020 8:42 PM > *To:* usrp-users@lists.ettus.com > *Subject:* Re: [USRP-users] B210 USRP object creation > > On 10/08/2020 03:33 PM, David Taylor (manx.net) via USRP-users wrote: > > Point taken. - I didn’t actually check the original default values of the > VID and PID, but they were reset according to the table provided, so that > they could be tested as arguments in the make statement below. > “About the Motherboard and Daughtercard EEPROM on USRP Devices (5th August > 2020)” > > The aim is to be able to manipulate some GPIO bits in the block work > function and to align events using the 1PPS input. > > Regards, > David GD4FMB > > > Ok, so presumably you're using Gnu Radio, since you're talking about > "block work functions". > > So this issue straddles the two universes--UHD/USRP and Gnu Radio. > > I'd encourage you to use the UHD test tools to confirm sanity of your > setup and then move on to a stupid-simple flow-graph with standard > blocks. Once THAT works, then one can think about grabbing the usrp > source/sink "object" and being able to use it in your own > processing "block". There used to be a way to do this even within GRC > but I fear that it was a custom block (perhaps from the old > gr-balint set of blocks) that would allow you to grab an object handle > and pass it as a variable into your own functions. > > It's something I've wanted to do myself from time to time. Of course if > you're coding in "naked" GR, without using GRC, it's easy. > But GRC uses a "data flow" model, and is less "procedural", so it gives > an added layer of abstraction that makes it difficult to do > what you want to do. The gr-uhd module provides GPIO functions: > > > https://www.gnuradio.org/doc/doxygen-v3.7.9.1/classgr_1_1uhd_1_1usrp__block.html#ab09502e1c8c43a546616b9a998f137f1 > > But they aren't exposed in any meaningful way into GRC that I know of. > > I'll note that in GR3.9, there is support for something called "code > snippets" which would let you "dip down into the lower layers" without > having to post-facto edit generated Python code. > > > -- > ___ > 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.et
[USRP-users] UHD on Ubuntu 20.04 and USRP N310
Hi everyone, It has been a few months since I used my USRP N310 and now that I am going back to set everything back up, it seems that I have some version issues. Basically, my setup was Ubuntu 19.04 and the USRP had UHD v3.14.0, but now it seems that those versions are unsupported because I was getting a few errors that I have not seen before with my exact same setup. I figured I just needed to update everything so I basically updated my Ubuntu to version 20.04 and was still unable to get everything working. My question is, is there a supported UHD release for Ubuntu 20.04 that would work with my USRP N310? Would I have to update the version of UHD on Ubuntu and the USRP to v3.15.0? Or would I be better off reinstalling Ubuntu on a previously supported version like 18.10? I’m just not really sure what course of action to take as I do not want to have any issues going backwards if I need to. Open to any suggestions! Thank you, Austin Adam ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
