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
