Actually, I think you just need to configure and reload your udev rules as noted in this KB under “configuring USB”:
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux#Configuring_USB -Sam On Sat, Oct 10, 2020 at 3:20 AM David Taylor (manx.net) <drtay...@manx.net> wrote: > > > > > > > > > Sam, > > > > > > Thanks for your input. > > > In my rather foolhardy attempt at obtaining a UHD device handle in my GRC > > code, I used UHD b2xx_fx3_utils to alter the USB pid value on my B210. > > > The App note [2] (page 10/14) is slightly conflicting in the specification > > of the B2xx pid values, giving two value options. Having a genuine NI > part, I > > tried 0x7814.! > > > > > > uhd_find_devices fails with “No UHD Devices > > Found” > > > > > > however > > > ./b2xx_fx3_utils –init-device –write-vid 0x2500 > > –write-pid 0x7814 > > > responds with > > > Device opened (VID=0x2500, PID=0x7814) > > > B2xx detected...Failed to communicate with the device! > > > ... > > > and UHD 3.15.0 response > > > [ERROR [USB] USB open failed: insufficient permissions. > > > See the application notes for your device. > > > > > > Perhaps a very cautious patch to the programmer code might help as a > > workaround? > > > I will take a look. > > > > > > Best regards, > > > David Taylor > > > > > > > > > > > > > > > > > > *From:* Sam > > Reiter > > > *Sent:* Friday, October 9, 2020 10:01 PM > > > *To:* David Taylor (manx.net) > > > *Cc:* Marcus D. Leech ; usrp-users (usrp-users@lists.ettus.com) > > > > *Subject:* 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=<xxxxx> > > > > > > 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.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
