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
