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
