Hi, I've figured out what I was doing wrong.... No set_filter() once the taps are set (I mistakenly thought that this was implicitly done -- and checking the source code of UHD confirmed that the sptr returned by get_filter() is a sptr to a **copy** of the original filter, and not the actual one!)! :S :S :S :S Now it works like a charm.... Thanks again!!! :) Rob
On 13 September 2017 at 07:11, Rob Heig <robh...@gmail.com> wrote: > Hi, > Thank you both for your help! :) > I had started myself patching UHD for the job like Sylvain did, but that > scared me a bit since I didn't want to stump on the feet of the library and > risk having some strange behaviour, therefore I preferred to ask first ;) > Have a nice day! > Rob > > On 12 September 2017 at 22:15, Julian Arnold <jul...@elitecoding.org> > wrote: > >> Hey, >> >> In case you haven't already adopted the straight forward approach >> mentioned by >> Sylvain I just dug out the tool I mentioned and moved >> it to my github account [1]. >> >> I quickly compiled and linked against a recent version of UHD (3.9.6) to >> confirm that it still works. >> >> Build as usual: >> mkdir build >> cd build >> cmake .. >> make >> >> You can then run the "main" program as follows: >> >> ./main --list >> >> to see a list of all available filters with their corresponding paths. >> Then, you can write new filter coefficients with: >> >> ./main --write_fir --path=<path from run with --list option> >> e.g.: >> ./main --write_fir --path=/mboards/0/dboards/A/rx >> _frontends/A/filters/FIR_1 >> >> this will update the coefficients of FIR_1 and then read the filter again >> to >> check if the coefficients have been updated. >> However, the tool is definitely not polished in any way and does not check >> whether or not the new coefficients actually take effect. >> If they still don't then let me know and I'll try to create a more >> complete >> example application. >> >> [1] https://github.com/jarn0ld/uhd-filter-tool >> >> Cheers, >> Julian >> >> On Tuesday, September 12, 2017 5:16:56 PM CEST Sylvain Munaut wrote: >> > Personally I'm using a patched UHD where I expose the SPI device : >> > >> > >> > diff --git a/host/lib/usrp/b200/b200_impl.cpp >> > b/host/lib/usrp/b200/b200_impl.cpp index a513e1336..01c1e3b51 100644 >> > --- a/host/lib/usrp/b200/b200_impl.cpp >> > +++ b/host/lib/usrp/b200/b200_impl.cpp >> > @@ -549,6 +549,8 @@ b200_impl::b200_impl(const uhd::device_addr_t& >> > device_addr, usb_device_handle::s >> > _adf4001_iface = boost::make_shared<b200_ref_pl >> l_ctrl>(_spi_iface); >> > } >> > >> > + _tree->create<spi_iface::sptr>(mb_path / ("spi")).set(_spi_iface); >> > + >> > //////////////////////////////////////////////////////////// >> //////// >> > // Init codec - turns on clocks >> > //////////////////////////////////////////////////////////// >> //////// >> > >> > >> > Then in my code I can get the SPI object : >> > >> > uhd::spi_iface::sptr spi = >> > usrp->get_device()->get_tree()->access<uhd::spi_iface::sptr> >> ("/mboards/0/spi >> > ").get(); >> > >> > and use read_spi / write_spi to control any register I want. >> > >> > >> > Cheers, >> > >> > Sylvain >> >> >> -- >> Julian Arnold, M.Sc. >> >> Institute for Networked Systems >> RWTH Aachen University >> Kackertstrasse 9 >> 52072 Aachen >> Germany >> > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
