Official bladeRF forum

I was wondering what would need to done in order to use the BladeRF with OpenBTS?
I see that it is already being worked on as the Roadmap states.

Many thanks
Ash

bnt2025 wrote:I was wondering what would need to done in order to use the BladeRF with OpenBTS?
I see that it is already being worked on as the Roadmap states.

Many thanks
Ash

Very little would need to be done, relatively speaking. The only changes that I can think of would be to integrate the drivers for the bladeRF to work with OpenBTS/OpenBSC/related projects. Otherwise, one is talking about a communications standard that is traveling over RF. How that occurs is important, but the hardware relaying such a pathway should be of little consequence.

Thats good news then!
How would I go about doing that. I have only really got experience in Java, but if you have any good start points for me to learn I am more than willing to give it a go!

Thanks

Sorry to bump this, but does anyone know anywhere I could learn how to do this?

Any help would be fantastic!

Many thanks,

bump

The current limitation is the lack of inband signaling in the FPGA. Basically OpenBTS needs a timestamp on the samples it sends out or receives. The sample stream uses these timestamps to keep a consistent timebase. Currently if there are samples which are late to show up, they will just immediately go out instead of being sent out at the correct time.

That is the biggest hurdle in getting OpenBTS on the device.

Thank you very much for your reply!
Am I right that this should be solvable within the firmware running on the FPGAs?
Are you personally working on this, and if yes, thank you for that and how long do you think does it take to make it work?
Third and last question: Is it correct that the clock within the blade is accurate enough to talk GSM without an external clk?

You are correct that it is an FPGA modification as well as some host side software to understand the packet format coming in.

I am working on it, but it's currently slightly lower on the priority list versus getting libusb running well and on Windows and OSX.

The clock on the board is an asvtx-12-a-38.400mhz-h10-t and does have a trim DAC on the tuning pin. The biggest issue with the accuracy of oscillators, from what I understand, is handoff from one BTS to another BTS. We do calibrate them to be very accurate, but they will age and will probably need re-calibration.

I am definitely no authority on the matter, but that is what I have been told.

Thank you again! I agree with you about the priorities.

As far as I understand the asvtx is very temperature stable for most needs and also very accurate over time. On the bladeRF homepage it says it’s around 0.040ppm. Can you acknowledge that number? As I learned from [1] GSM requires a very accurate clock (~0.1ppm). So this should work without an additional clock but anyway: does the external clock interface work already or when may this be expected? And which external clocks available would fit and work? These: [2] ?

Can you say for sure that the board on sale, as it is, will be capable of working with OpenBTS in the near future? Because IMHO bladeRF is the best SDR in it’s segment available for sale today (USB3, Freq. range, Bus-powered, Open, Fast, Fair price). I would love to get some, but I have to do GSM (& signal analysis) with them, soon! So if you could acknowledge that it should work I will buy some and try to make OpenBTS work with them.

[1]: http://gnuradio.org/redmine/projects/gn ... nBTSClocks
[2] http://shop.fairwaves.ru/laboratory-use ... LVDS%20GPS

Sorry to bump this,
I have been trying to figure out how to get the bladeRF working with openBSC. I found it after i created this thread, i really am struggling to find a start point.

can anyone help with this? I think this running OpenBSC would be an awesome project.
Many thanks
Ash

IS there any success visible in getting OpenBTS to work with the BladeRF? I will have to show a demonstration soon, and the USRP1 is a bit bulky when being on travel

Ralph.

The current limitation on running the software is the guarantee of timestamping of samples.

This requires an FPGA change to both read and insert the sample number with the IQ datastream and to extract that same data from the received samples.

Once this is done, I've been told that it becomes relatively simple to support OpenBTS. Unfortunately, we haven't gotten to this point yet. It's a big hope for October that we can get it up, running and have OpenBTS working right out of the box.

OK, this sounds quite good. I see that the prebuilt fpga images have not changed for a while. Is it recommended to build it from the latest sources, or does this not make any noticeable difference in normal usage? I fear installing this Quartus monster

Ralph.

It's always recommended to build from the latest sources. I understand that Quartus is a bit of a beast, but a necessary thing to install if you wish to build the source.

I am in the process of refactoring the HDL as long as I can get enough time away from the host side of things to test it all out, and get the simulation models up and running. Hopefully more HDL work can be done this weekend.

Post if you have issues or other FPGA questions. It might be better to open a new post if they are not OpenBTS specific, though.

What about getting it working with OpenBSC? Would there still be the same problem?