They load their operating code (FPGA + CYPRESS FX2) over USB
dynamically.
If you have a recent version of UHD, you should also have the images for
these devices.
What does "lsusb" show for the USRP1 and B100 when you plug them into
the USB bus (with external power--these devices won't take powe
Hi Rob,
this might be something more suited for the USRP-users mailing list [1],
which I put in CC: here.
> My question is, how do I burn a startup code to EEPROM of...
The EEPROM doesn't contain any startup code, but just the serial number,
device name and model.
You can change those with the
I have a couple of old USRP1 and B100 boards that I am trying to revive. My
question is,
how do I burn a startup code to EEPROM of:
1. USRP1
2. B100
3. RFX1800 ?
Does any of the UHD utils allow to dump all the contents of my old EEPROMS bit
by bit to a file?
Rob
Hi Steve,
first off, a small hint: the GRC explicitly has a nice "save screenshot"
button / Menu entry so that you don't even have to use the screenshot
ability of your OS. Please, really, don't take camera pictures of your
screen.
But regarding your question:
Yes, since both resamplers are math
Hi Devin,
in include/my_mod/api.h you'll find a #define like this
#define MY_MOD_API __STUFF
use MY_MOD_API in front of the classes and free-standing functions you
want to export, like
uint32_t MY_MOD_API crc32(unsigned int, void const*, unsigned long);
Best regards,
Marcus
PS: having written
Hey gwenj,
I resolved the issue though I'm not entirely sure why this worked.
Previously I installed everything in bulk sans the gr-iio recipe. Then I
attempted to make that separately and install it. Leading to the issue of
the original make not placing the pkg-config files in staging.
The fix:
Hello,
I've created my own GR module with GR mod tool. I added two files
include/my_mod/crc.h
lib/crc.cc
And I can use the functions (crc32 for example) in those files perfectly
fine within classes that wind up in libgnuradio-my_mod.so. However, I
can't use the functions in crc.h/crc.cc
> I noticed the comment about blocking, and wondered if a dedicated message
handler would be a better option than overloading "calculate_output_stream_
length".
Yes I think that would be a cleaner way that follows the GR message passing
paradigm.
> I was wondering if I should use the PDU to Tagge
You add it to this line in lib/CMakeLists.txt:
target_link_libraries(gnuradio-xxx ${Boost_LIBRARIES}
${GNURADIO_ALL_LIBRARIES})
like so:
target_link_libraries(gnuradio-xxx ${Boost_LIBRARIES}
${GNURADIO_ALL_LIBRARIES} -lgsl)
This is the quick and dirty way. The better way is to use a cmake
Dear GnuRadio experts,
I want to use some minimization functions from the Gnu Scientific Library (GSL)
in my own OOT module, e.g. a simple 1-D minimizer such as Brent's method. In my
OOT module I can compile and install my new block with GSL without any errors
(seems like compilation and linkin
10 matches
Mail list logo
