Hi there,
I just wanted to second Habibur's suggestion of applying the
patch to the transceiver code, for reasons I
briefly explained in that thread and will try to summarize below.
This patch simply moves some manual enabling of FPGA timestamp functionality to
after a bladerf_sync_config() call. This is required because timestamp support was officially introduced in libbladeRF v0.17.0 via the BLADERF_FORMAT_SC16_Q11_META format. As of libbladeRF v0.17.0, specifying the BLADERF_FORMAT_SC16_Q11 format indicates one does not want metadata so it turns it off. (So what you're seeing in those error messages is IQ data being interpreted as timestamps.) Credit goes out to
mambrus for pinpointing and reporting this.
I sincerely apologize for the confusion caused by the API changes in the unstable libbladeRF v0.x.x series, and more recently, this issue caused by the underlying differences between metadata/non-metadata format specifiers. For what it's worth, on the bladeRF side of things, the aforementioned timestamp change should be the last of the reverse-incompatible changes. The recent v1.x.x libbladeRF series (From November 2014) is intended to provide stability and maintain backwards compatibility within that v1.x.x series; increments major version shall denote reverse-incompatible API changes (which there are no remaining plans to introduce).
We bladeRF folks intend to keep our top-level
CHANGELOG updated with the latest set of compatible versions.
With that said, as paulc noted, using an older libbladeRF version (earlier than v0.17.0) with the appropriately matched FX3 firmware and FPGA should also work. Unless you want to be using bleeding edge fixes it would probably be best to stick to libbladeRF, FX3 firmware, and FPGA image versions recommended by the Yate team, considering that they would have tested and verified a certain set of versions.
Hope that helps rather than causing you further confusion,
Jon
