> > If that is true, then it seems to follow that there would be > > nothing in the multi_usrp API that I couldn't accomplish "manually" > > outside of that API. > > But it's not really true. For example, with two uhd::usrp::device > instances instead of a mulit_usrp with two IP addresses, you can't get > the same level of ADC phase sync on X3xx, IIRC.
Why do you compare two instances of "device" with one instance of "multi_usrp"? Can't the device object have two IP addresses? I'm not aware of a performance issue that can only be achieved using multi_usrp as opposed to working directly with device, but perhaps I'm wrong. As an alternative example, consider the multi_usrp::get_usrp_rx_info() method. This method requires <uhd/eeprom.hpp> (one of the non-installed headers I mentioned) to get the typdef eeprom_map_t. This is then used to read the daughterboard serial number and subdev id. It seems to me that I should be able to access this information without going through the multi_usrp API. In fact, if I have a non-standard FPGA image, I am not even ABLE to use the multi_usrp API because legacy_compat will not "make" without an expected set of rfnoc blocks. But, without <uhd/eeprom.hpp> include file, I don't have the needed eeprom_map_t typdef. _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
