Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - jynik

Pages: [1]
1
YateBTS / Re: YateBTS with bladeRF x40 : no visible network
« on: January 10, 2015, 02:54:05 PM »
Hi Habibur,

Yes, you're correct.  No patch is required when following paulc's instructions because the libbladeRF version he linked to is v0.14.0.  The introduction of timestamp support into the libbladeRF API was added in v0.17.0 (which does so in a manner that necessitates that patch). In short, the patch is only needed when using YateBTS with libbladeRF v0.17.0 or newer.

If you ever run into what you believe is a bug in libbladeRF when using that older version, please be sure to check for any thing already addressed by fixes added after that v0.14.0 release.

Cheers,
Jon

2
YateBTS / Re: YateBTS with bladeRF x40 : no visible network
« on: January 10, 2015, 07:34:33 AM »
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

Pages: [1]