You've posted that John Gilmore sponsoured SMS implementation which is the main new feature of 2.x releases. Was it he who denied to open the codes immediately? I don't believe he did this.

My strong belief is that main development branch (i.e. trunk) *must* be in free access. It's ok to develop some features in a «delayed open» manner, but they should be worked on in a separate (private) branch. Then, all bug-fixes should land trunk first and then regularly merged to feature-branch regularly. And when client is satisfied and is going to deliver his product, you merge feature-branch back to main. Even svn provides means for regular merging, not to say about DCVSs (like Mercurial/hg or awkward git). Yes, it will add some work on merging, but I do believe that long-term outcome of this openness is far more valuable.

Another reason that we allow the public distribution to lag the private one by a few months is that some of the clients who pay for this work request that it not be released publicly until after a certain time has passed. There are some specific cases of that in 2.4. (BTW, we *will* release 2.4 onto GNU Radio as soon as we have had a chance to test the merged code.) There's no real business case for telling a commercial customer, \You pay for the code so I can give it away for free, even to your competitors, before it's even finished.\ So you offer delayed public release: \You pay for the code and I promise not to give it away for free until your business plan is more mature.\

I realize that this policy annoys many potential open source developers, but this is how a lot of work got funded and how a lot of it is likely to be funded in the future. I also realize that we may need to find a better way to manage this policy now that the lawsuit is over. I am open to suggestions.

Also, anyone who is serious about becoming an active OpenBTS developer is encouraged to contact me for more recent code, or even for direct access to our SVN server. There are few such active developers at this time and I am glad to accommodate them.

Потому и спросил, что она немодифицированая была.

Open-source версия будет? После продажи опсосу, конечно ;)

Кстати, AirProbe — тоже забавная игрушка. Особенно в качестве утилиты для отладки OpenBTS :)

PicoChip — это замечательно, но они работают только с очень крупными заказчиками. Кроме того, для GSM совершенно не обязательна такая бешеная производительность, как для 4G, для которых они и создавались. Да и фемтосоты — это не «another billion», а всё тот же, что в офисах сидит и в смартфоны играет. Не думаю, что в ближайшие лет десять 4G телефоны будут дешевле старых добрых GSM.

Да, анализатор именно на базе этого скрипта... может даже продать местному опсосу получится).

А в качестве фемтосот и вообще новой концепции построения сети сотовой связи (на базе IP), захвата рынка «another billion» — мне нравятся разработки PicoChip.

Про дрифт частоты. А какой источник часов использовался — родной USRP'ный? С нашим новым источником часов обрывов связи мы не наблюдали вроде бы.

Про рыночные перспективы согласен. Но так же не могу не отметить, что все эти проблемы решаемы. А если получится довести разработку до реального применения — её эффект будет значительным. Просто в социальном плане и в плане изменения отношения к системам связи как к чему-то, что доступно только когорте избранных.

PS А что за спектроанализатор — вdvanced версия usrp_fft.py?

Я тестил OpenBTS с кучей мобилок (как американских, так и европейских). У меня работали все старые Ericsson/SE (новые плохо работали — срывали разговор — им дрифт частоты не нравился). Nokia S40 работали без проблем. S60 приходилось натравливать на ARFCN. iPhone работали без проблем. Моторола вообще ни одна не завелась.

А вообще, openbts — конечно штука интересная, но рыночные перспективы туманны (слишком много закрытых патентов, слишком много проблем). Пока не будет нормальной авторизации — её нельзя продавать... Да и есть проблема с легализацией установки...