Harald Welte's blog

Update on what I've been doing

For the better part of a year, this blog has failed to provide you with a lot of updates what I've been doing. This is somewhat relate to a shift from doing freelance work on mainline / FOSS projects like the Linux kernel.

In April 2011, Holger and I started a new company here in Berlin (sysmocom - systems for mobile communications GmbH). This company, among other things, attempts to provide products and services surrounding the various mobile communications related FOSS projects, particularly OpenBSC, OsmoSGSN, OpenGGSN, but also OsmocomBB, and now also OsmoBTS + OsmoPCU, two integral components of our own BTS product called sysmoBTS.

Aside from the usual software development, this entails a variety of other tasks, technical and non-technical. First of all, I did more electrical engineering than I did in the years since Openmoko. And even there, I was only leading the hardware architecture, and didn't actually have to capture schematics or route PCBs myself. So now there are some general-purpose and some customer-specific circuits that had to be done. I really enjoy that work, sometimes even more than software development. Particularly the early/initial design phase can be quite exciting. Selecting components, figuring out how to interconnect them, whether you can fit all of them together in the given amount of GPIOs and other resource of your main CPU, etc. But then even the hand-soldering the first couple of boards is fun, too.

Of all the things I so far had least exposure to is casing and mechanical issues. Luckily we have a contractor working on that for us, but still there are all kinds of issues that can go wrong, where unpopulated PCB footprints can suddenly make contact with a case, or all kinds of issues related to manufacturing tolerances. Another topic is packaging. After all, you want the products to end up in the hands of the customer in a neat, proper and form-fitting package.

On the other hand, there is a lot of administrative work. Sourcing components can sometimes be a PITA, particularly if even distributors like Digikey conspire against you and don't even carry those low quantities of a component that we need for our 100-board low quantity runs. EMC and other measurements for CE approval are a fun topic, too. I've never been involved personally in those, and it has been an interesting venture. Luckily, at least for sysmoBTS, things are looking quite promising now. Customs paperwork, Import/Export related buerocracy (both in Germany as well as other countries) always have new surprises, despite me having experience in dealing with customs for more than 10 years now.

Also significant amount of time is spent on evaluating suppliers and their products, e.g. items like SIM/USIM cards, cavity duplexers, antennas, cables, adapters, power amplifiers and other RF related accessories for our products.

The thing that really caught me off-guard are the German laws on inventory accounting. Basically there is no threshold for low-quantity goods, so as a company on capital (GmbH/AG) you have to account for each and every fscking SMD resistor or capacitor. And then you don't only have to count all those parts, but also put a value at them. Depending on the type of item, you have to use either the purchasing price, or the current market price if you were to buy it again, or the price you expect to sell the item for. Furthermore, the trade law requirements on inventory accounting are different than the tax laws, not often with contradictory aims ;)

In the end it seems the best possible strategy is to put a lot of the low-value inventory into the garbage bin before the end of the financial year, as the value of the product (e.g. 130 SMD resistors in 0402 worth fractions of cents) is so much lower than the cost of counting it. Now that's of course an environmental sin, especially if you consider lots and lots of small and medium-sized companies ending up at that conclusion :(

So all in all, this should give you somewhat of an explanation why there might have been less activity on this blog about exciting technical things. On the one hand, they might relate to customer related projects which are of confidential nature. On the other hand, they might simply be boring things like dealing with transport damage of cavity duplexers from china, or with FedEx billing customs/import fees to the wrong address...

Overall I still have the feeling that I was writing a decent amount of code in 2012 - although there can never be enough :) Most of it was probably either related to OsmoBTS, OpenBSC/OsmoNITB or the various Erlang SS7/TCAP/MAP related projects. The list of more community-oriented projects with long TODO lists is growing, though. I'd like to work on SIMtrace MITM / card emulation support, the CC32RS512 based smartcard OS, libosmosim (there's a first branch in libosmocore.git). Let's hope I can find a bit more time for that kind of stuff this year. You should never give up hope, they say ;)

Back from FOSDEM 2013

As (almost) every year, I attended the annual incarnation of FOSDEM. It is undoubtedly (one of?) the most remarkable events about Free Software in existence. No registration, no fees, 24 tracks in parallel, an estimated 5000 number of attendees. I also like that it brings together people from so many different communities, not _just_ the Linux or Gnome or KDE or Telephony or Legal people, but a good mixture of everything.

I have to congratulate the organizers, who manage to pull this off, year after year again. And as opposed to many other events, they do so quietly and without much recognition, I feel. I'd also like to thank the many volunteers working tirelessly before, at and after the event. Last, but not least, I'd like to thank the local university (ULB Solbosch) hosting the event.

What made me truly sad though, is the amount of littering that surprisingly many of the attendees did. This was particularly visible in the Cafeteria. Imagine an event run by volunteers, who put in a lot of time and effort. Imagine an event where food and drinks are sold by volunteers at such low prices that there can barely be any profit at all. And then imagine people eating there and leaving all their rubbish around, as if they were in some kind of restaurant where they are being served and where somebody is cleaning up after them. It really makes me feel very bitter to see this. Don't people realize that those very volunteers who are creating the event will then have to put in _their_ spare time just because those who just enjoyed their coffee or lunch didn't have the extra 30 seconds of bringing their trash to the trashcan? I feel ashamed for members of our community who behave this way. Please think next time before acting and show your respect to the people behind FOSDEM.

Talk Idea: How to write code to make later enforcement easy

During FOSDEM 2013, I spoke with some fellow Free Software developers about how my knowledge on copyright and specifically legal aspects of software copyright has influenced the way how I write code, and particularly how I design architecture of programs.

This made me realize that this would probably make a quite interesting talk at Free Software conferences: How to architect and write code in order to make later [GPL] enforcement easy.

Of course there are all the general and mostly well-known rules like keeping track of who owns which part of the copyright, having proper copyright claims and license headers, etc.

But I'm more thinking in the sense of: How do I write code in a way to make sure people extending it in some way with their own code will be forced to create a derivative work. If that is the case, they will have absolutely no choice but to also license that under GPL.

This is particularly important in the case of GPL licensed libraries. The common understanding in the community is that writing an executable program against a GPL licensed library will constitute a derivative work and thus the main program must be licensed under the GPL, if it is ever distributed.

However, in reality there is of course no precedent, and in some particular cases, the legal framework, depending on the jurisdiction, might come to different conclusions if it ever ended up in court. The claim of a 'derivative work' would be particularly weak if the main program is only using a set of standard function calls whose function declarations are the same in many versions of the GPL licensed library you link against. So let's assume there was a GPL licensed standard C library for stuff like open(), close(), printf() and the like. I think it would be very difficult to argue in court that a program written against those functions and linked against such a library would constitute a derivative work of the library. As in fact, there are many other implementations providing the exact same interface, under different licenses, and the API was not even drafted by the author of the GPL licensed implementation.

So I think there are some things that an author of an (intentionally) GPL licensed library can do while writing the code, which will later help him to establish that an executable program is a derived work.

The same is true to some extent for executable programs, too. I very intentionally did not introduce a plug-in interface for BTS drivers in OpenBSC, even though while technically it would have been possible. I _want_ somebody who adds code for a different BTS to touch the main code of the program instead of just writing an external plugin. The mere fact that he has to edit the main program in order to add a new BTS driver indicates that he is creating a derivative work.

So I'll probably try to submit a talk on this topic to some upcoming conference[s]. If you think this is an interesting topic and want me to talk about it at a FOSS related event, please feel free to send me an e-mail.

Why I hate phone calls so much

The fact that I have more than 20 missed phone calls on my land line telephone after only half a day has passed triggers me to write this blog post.

It is simply impossible to get any productive work done if there are synchronous interruptions. If I'm doing any even remotely complex task such as analyzing code, designing electronics or whatever else, then the interruption of the flow of thoughts, and the context switch to whatever the phone call might be about is costing me an insurmountable amount of my productive efficiency. I doubt that I am the only one having that feeling / experience.

So why on earth does everybody think they are entitled to interrupt my work at any given point in time they desire? Why do they think whatever issue they have rectifies an immediate interruption in what I am doing? To me, an unscheduled phone call almost always feels like an insult. It is a severe intrusion into my work-flow, and has a very high cost to me in terms of loss of productivity.

Sure, there are exceptional absolute emergencies (like, a medical emergency of a family member). But just about anything else can be put in an e-mail, which I can respond to at a time of my choosing, i.e. at a time I am not deeply buried into some other task that requires expensive context switching and the associated loss of productivity. And yes, a response might be the same day, some days later, or even a week or more later. There are literally hundreds of mails of dozens of people that need to be responded to. I can never even remotely answer all of them in a timely manner, even if I'm working 12-14 hours a day up to 7 days a week.

Right now I'm doing the only reasonable thing that is left: Switch off all phones. And to anyone out there intending to contact me: Please think twice before calling me on the phone. Almost anything can be put in an e-mail. And if you really want to have a phone call, please request a scheduled phone call in an e-mail containing a very detailed agenda and explanation of the topic.

Strain of bad luck

From roughly September to December 2012 I seem to have had a quite unusual strain of bad luck and set-backs. I don't want to go into the details here, as most of the issues are of quite private nature.

This has kept me quite distracted from a lot of my other activity. Projects like the various Osmocom sub-projects, gpl-violations.org are in desperate need of attention, and I have severely neglected my responsibilities in the Chaos Computer Club Berlin e.V. :(

I don't even want to talk about actual paid work, where customers also had to put up with repeated schedule slips and lack of availability.

I let down friends and colleagues at a number of occasions, as I was unable to keep up with anything that remotely resembles my typical work schedule.

Last but not least, I regrettably have also not felt much of an urge to write many blog posts here.

My sincere hope and expectation is that things are going to improve quickly in 2013. At least most of issues from the last half year have been resolved. Now I need to work through a considerable back-log of work and find more time for my volunteer projects in the FOSS and hacker worlds. However, this will need some time and I would like to ask for some patience. I do intend to be up to speed with things just like before.

In this spirit, I am looking forward to a productive and exciting 2013. Happy hacking und Viel Spass am Gerät

29C3. The end of an era?

When I first heard that the annual CCC congress was moved to Hamburg, my immediate reaction was: Fine, but I wouldn't want to be involved in it. For the last 15 years I've been attending the CCC congress every year, in most years as a speaker, and in many years in some (small) contributing role, first in the team doing the video recordings, and in the last couple of years setting up a GSM network. Contributing to an event is easy if your home/lab is within 20minutes, so if you need another strange cable/adapter/tool/whatever, you can just go and grab it. Doing that at an event that's multiple hours of driving away, in a new/unknown venue is an entirely different story. I have more than enough stress already with (paid) work and the various FOSS projects that I'm leading or involved in.

I have no interest in "just" attending the event. That never was a primary reason for me. In all those years, I've probably attended an average of one talk each year. The event for me was about being able to contribute something actively.

Now, months after those thoughts and my decision not to attend, there is a schedule for the 29C3 available. And to say the least, I am shocked. The entire event seems to have turned into a SIGINT, rather than an xxC3. Lots of talks on politics and society, and lots of German talks.

The debate on implications of technology on society, culture, politics, etc. is an important debate, there is no doubt. And so far I always had the feeling that the xxC3 had a pretty good balance between hard-core technical talks and those non-technical talks. But if I look at the schedule this year, it really looks like an incarnation of the SIGINT conference. With too many German talks you are scaring off the international community. And with focussing on non technical topics, you scare away the die-hard technical hackers. So why move to a larger venue, if you at the same time seem to limit the scope of the event?

Meanwhile I have heard of a number of friends and colleagues who seem to share this view. A number of people who have attended in previous years are not interested in attending this year due to the issues mentioned above.

It's sad to see, but I somehow have the feeling that 29C3 might be the end of an era. The end of a highly successful series of events with exceptionally strong technical talks. To me, xxC3 has always been unique and special. No other event would ever compare to it. Who will fill the gap for the die-hard technical topics? I am feeling quite sad, up to the point that I want to start mourning about "the good old times".

I'm not writing this to put blame on anyone. It just reflects my personal and highly subjective view. Let's see what people will say after 29C3 has actually happened. Let's see how successful it is in terms of number of attendees, and in terms of feedback from participants. I'd like to explicitly thank the many organizers and volunteers (a lot of whom I know in person) for putting up their time and energy to make 29C3 happen.

Inside a cavity duplexer

In many cellular systems (GSM or otherwise) there is a frequency duplex between the uplink and downlink frequency band. If you use a single antenna to serve a BTS, then somehow you need to split the frequency band between the Rx and Tx side by means of a Duplexer.

The most common technology for this is the so-called Cavity Duplexer. I've used those devices (and seen them in use) for a long time, but never really opened one so far. The problem is that they are finely tuned, and each mechanical change can severely impact performance. As I had to repair a broken SMA socket on one of them recently, I took the chance to take a picture

In the first picture you can see the bottom side. This consists of a milled aluminum block, with a series of circular cavities. The Tx output of the BTS is connected to the SMA socket on the bottom right, the antenna to the SMA socket on the top side, and the Rx port to the SMA socket on the bottom left of the picture:

The small cylindrical objects in the center of the cavities are not milled from the same part, but they are separate pieces mounted by screws from the bottom of the unit.

The second picture shows the top section of the duplexer:

You can see a ~ 4mm aluminum plate with lots of (now empty) holes which are for the ~ 117 screws with which the top plate is screwed against the bottom part shown in the first picture.

The important part, however, are the screws that you can see sticking out of the top part. Those are used for tuning and present "obstacles" in the path of the waves as they pass through the cavities.

The big miracle for me is not that there are some resonances which build up a filter, but that you can actually transfer as much as 100W of RF power from the Tx input through to the antenna output.

Short report on the first Osmocom User Group meeting in Bavaria

It's already one week in the past, but I'm only now finding some time to report on the first Osmocom User Group meeting in Bavaria.

All-in-all, there were 6 people attending, some people already known in the community, but also two completely new faces, which is great.

Dieter gave us a tour of his large BTS equipment, including a Nokia Ultrasite and an Ericsson RBS 2206. We had an introduction round where the participants could get to know each other a bit. Finally, we spoke about a variety of topics, from OsmocomBB to SIMtrace, SIM/SAT/STK security, the CC32RS512 and of course OpenBSC and the sysmoBTS.

On the day after the meeting I also had the pleasure of attempting to get the RBS2206 working with OpenBSC. Unfortunately there was no success, but still a number of bugs in the OM2000 / RBS2000 code in OpenBSC that had been found and fixed.

I'd like to thank Dieter Spaar for organizing and hosting the event, taking care of the Bavarian sausage + cheese platter for lunch.

I did not create rtl-sdr / librtlsdr

In recent weeks, the number of private e-mails I receive about rtl-sdr has increased significantly. This is odd for at least two reasons:

First, I didn't create rtl-sdr and was not involved in its creation with the tiny exception of writing an e4k tuner driver for osmo-sdr, which was then used in a variety of rtl-sdr software.

Second, you should never contact the (presumed) software author in a private e-mail, but use the respective project mailing list. There is a community of developers, contributors and users out there, and it is a waste of everyone's time if you communicate by 1:1 private e-mail rather than enlightening the mailing list.

We're now working on a UMA/GAN controller

We've pondered it a couple of times in the past whether we should implement an UMA/GAN controller (UNC/GANC). GAN (formerly called UMA) is a method by which you can tunnel GSM/3GPP Layer3 signalling (Mobility Management, SMS, Call Control) over an IP based bearer such as 802.11 (WiFi).

The idea was that mobile phones that support both a GSM/3G radio as well as WiFi could then simply use WiFi to connect to their mobile operator. This has been deployed around 2007/2008 by some operators such as T-Mobile USA as well as Orange UK. Today it seems that not many operators have caught up and UMA/GAN is mostly a legacy technology, last but not least due to very few phones actually implementing it.

Nonetheless, there are some markets and applications where UMA/GAN is useful. We (Dieter and I) now have managed to secure a contract for an Osmocom implementation based on OpenBSC (and libosmogsm, libosmo-sccp, ...). The beauty is that from L3 up, it is just regular GSM, no change needed at all. Only the transport layer is different: IPsec with TCP + GAN is the bearer, instead of LAPDm/RSL in classic GSM networks.

Another good part unrelated to UMA/GAN is: This will finally force us to clean up the separation between the MSC and BSC part in OsmoNITB (in order to replace the BSC part with the GANC).

Progress has been good so far, the SEGW (IPsec with EAP-SIM) has been configured, and a simplistic start of a GAN protocol implementation gets us through DISCOVERY, REGISTRATION and up to the point where the MS is sending the LOCATION UPDATE message. If you are curious how the protocol actually looks like, I've attached a sample pcap file to the WRTU54G-TM page in the OpenBSC wiki. The source code can be found in the laforge/ganc branch of openbsc.git.

First month of running the openmoko.org USB Product ID registry

One month ago, I had announced the availability of USB Product IDs under the Openmoko USB Vendor ID. By now, there have been 37 registrations, and the List of assigned USB Product IDs in the openmoko.org wiki is turning into something like a directory of really cool projects with Open Hardware or at least Free Software device firmware.

So actually, I enjoy a lot seeing so much activity in this field, and being able to contribute a tiny bit by enabling people to get a unique USB Product ID that they can use.

Back from a 3-day motorbike ride to the central Taiwan mountains

I've wanted to do this for many years, but somehow never managed to do this even back while I was spending a lot of time in Taiwan: A motorbike ride crossing the mountainous center of the island using the Central Cross-Island Highway. This highway is probably not what most people imagine a highway would be like: A narrow road consisting almost entirely only of serpentines with a speed limit of typically 40 km/h. In other words, a motorbiking paradise.

You can enter that highway from the east by starting from Taroko Gorge. In order to get there by motorbike, you take the famous Provincial Highway No. 9 from XinDian via Pinglin to Yilan, which is frequented a lot by Taipei motorbike riders on weekends. The No. 9 further leads along the cliffs of the coast to Xincheng, from where No. 8 starts.

The trip from Taipei to Xincheng is only about 200km, but still you need at least something like 5.30 hours if you want to ride safely. This is once again due to the mountain roads. You can barely see 100m at any given time to the next turn in the road all the way between XinDian and Yilan.

So I stayed one night at the entrance of Taroko Gorge.

Upon arrival I was greeted by the hotel owner with the news that No. 8 had been closed temporarily due to rock fall at km 150.9. That was pretty devastating to my plan, as this road is the only connection in the northern two thirds of the entire island. There is no alternative, except for No. 20, which would have been probably three times the amount of distance (and thus time). However, as it later turned out, the road would be opened for 30 minutes between 6am and 6.30am. So I had to leave at 5.00am in order to safely ride the first 30 km up to the road block. This turned out to be the best thing that could have happened:

There was absolutely zero traffic in either direction (the first 25km to Tienshang that are normally full of tourist busses).
I was able to witness the sunrise at about 5.40am in the mountains
very clear sight, which at other times is not clear at all

So I reached the road block even ahead of schedule and was able to pass as intended.

I continued along the road, and due to the fact that the road was closed again after 30mins, there was close to zero traffic all day on the entire road.

At Dayuling, you can either continue the 8 towards Lishan (but not much further due to repeated subsequent earthquake and typhoon damage), or you an continue along No. 14 A towards Hehuanshan (Mt. Hehuan). I first went to Lishan (a major tea planting region) and back, as due to my early morning start I had lots of time left for detours, to continue towards Mount Hehuan , where the road reaches an altitude of more than 3100m.

I spent the second night in Renai, where I arrived just in time: The first rain drops of a heavy afternoon thunderstorm were falling. In the morning, I was greeted by the following view from my hotel room:

I left again in the early morning, drove through Puli and headed for the Sun Moon Lake. It really is beautiful, as you can see in the following picture. However, it is also over-developed to care for tourists of all sorts, including lots of concrete directly at the lake, and bus-loads full of tourists, Starbucks coffee shops and everything that comes with it.

After two days in remote mountains with little buildings and almost no people, the experience was so shocking that I decided not to circle the whole lake but instead continue down south along No. 16 until it meets No. 3, which I then drove more or less all the way back to Taipei.

The first sixty-or-so kilometers are painful, as they lead through heavily populated areas around Nantou and Taichung. This means that there's lots of traffic, and very frequent traffic lights that make you stop. Later on, the road leads through less populated mountainous regions, and driving is more relaxed again.

Having managed this trip without any problems (nor getting lost even once), I'm hoping to find some time in the future to ride No. 7 from Yilan to Lishan, and particularly Provincial Highway No. 20, crossing the mountains much more south.

And if there's one part for me to remember: Always avoid the densely populated regions in the west of the island. If I wanted to ride stop-and-go all day long, I don't have to leave Taipei or New Taipei City in the first place ;)

Getting woken up by an earthquake...

...is a good adrenaline rush to start your day. Happened to me this morning at 5am in Taipei, caused by a Magnitude 6.5 earthquake 70 km off Yilan on Taiwans east coast. If it happened two days earlier, it would have caught me on the motorbike ride, possibly causing even some more road blocks due to rubble coming down from mountains.

Kevin Redon starts collaborative Osmocom project to collect terminal profile

As Kevin Redon writes in his blog, he has created some tools and a project for collaboratively gathering a database on the TERMINAL PROFILE capabilities of mobile phones.

The terminal profile describes which particular features regarding proactive sim or sim application toolkit a given phone supports.

This is not only important for SIM application / SIM toolkit developers, but it is also an important factor when trying to analyze the potential threat that can originate from a malicious SIM card attack.

I personally see no reason why my phone should ever report its GPS position to the SIM card, or why the SIM card should be able to re-write the nubers I'm dialling. Yes, there are cases where such features are useful, but then they should be explicitly enabled by the user, and the default should be that they are all switched off.

Who knows, after all, with some attention to this problem we might still see a SIM firewall / proxy, that you can put between the SIM and the phone to prevent any of those features from being (mis)used.

So all you need to do to contribute to the database is some way how you can read out the terminal profile from your mobile phone(s), and use Kevin's tool to upload it to the public website. And hwo do you read out the terminal profile? For example by using Osmocom SIMtrace to sniff the communication between SIM card and phone.

Openmoko USB Product ID and IEEE OUI (Ethernet MAC Address) range available to the community

As it has been quite some time since Openmoko, Inc. (the company) has released any hardware, I have obtained the permission to "donate" the Openmoko-assigned USB Product ID and IEEE OUI (MAC Address) allocations to the community.

As the actual allocations cannot be transferred unless the registrant (Openmoko. Inc.) is sold, the official registration will remain with Openmoko Inc. while the various Free / Open Source Software and hardware communities can make use of the range.

Registering a USB Vendor ID is expensive (USD 2000), and even if it wasn't for the money, many companies (let even aside community projects) will never require the 65535 product IDs allocated within that one USB Vendor ID.

As for Ethernet/Wifi/Bluetooth MAC addresses, they are allocated from the IEE OUI number ranges, which are also quite expensive (USD 1600) - but at least you get 16.7 million (24bit) and not just 16bit like USB ;)

So if you are running a small homebrew or community built project that implements a USB device or Ethernet ports, and either the software or the hardware of it is available under a free software / open source license, you can follow the instructions given at the pages in the Openmoko wiki that I linked above and request an allocation.

I'd like to thank Openmoko Inc. and especially Sean Moss-Pultz for making this donation.

osmo-lea6t-gps timing module DIY kits available

Due to lots of other work, it took quite some time between my initial blog post about the omso-lea6t-gps board and the point where we are able to offically sell kits in the sysmocom webshop. The primary reason is: The people for whom we primarily built the board (i.e. the Osmocom developers) all have one and are happy with it ;)

But repeated inquiries by e-mail and otherwise have shown there is more interest. However, for a hand ful of boards we cannot make an automated production run in a SMT assembly line. So for the time being, we are only selling DYI kits, consisting of a digikey-packaged component kit including all components, plus the PCB, as well as the LEA-6T module.

Anyone who is interested in such a timing module DIY kit can now order from the sysmocom webshop.

More information on the project, including design materials like schematics can be found at the Osmocom wiki.

Announcing the low-power, light-weight sysmoBTS

It hasn't been a secret that when I co-started a company called sysmocom more than a year ago, it was not about opening a webshop that sells cheap phones and DYI electronics kits to the larger community. Rather, it was to develop and sell exciting products surrounding Free Software and mobile communications.

There are of course the more or less obvious things to do, like system integration of OpenBSC and the related software on embedded systems, selling them as appliances including training, support and maintenance service.

However, we of course also want to more than that. Today it is my pleasure to say that the availability of our first BTS product called sysmoBTS has been officially announced.

See the news item, the product page and the data sheet for more information.

To make it very clear in the beginning: sysmoBTS is not an open hardware project. The schematics and layout files are proprietary and not disclosed publicly. Such is the FPGA bitstream and the layer1 inside the DSP.

However, any code running on the integrated ARM processor is available as free software. This includes a yocto/poky-built Embedded Linux distribution featuring u-boot, the Linux kernel (including all kernel modules!), the osmo-bts and OpenBSC software as well as many other Free Software packages.

We think this is a reasonable compromise between espanding a bit from our previous "BSC and above in Free Software" down to a "BTS Layer2 and above" divide. After all, if you use OpenBSC with a BTS from Siemens, Ericsson, Nokia or ip.access, you don't have access to the source code of anything running inside the BTS at all.

sysmoBTS offers some great new capabilities, such as integrating the BSC or even the entire osmo-nitb onto the ARM/Linux processor inside the BTS hardware itself, creating a less than 500gram, 10W power consuming autonomous GSM network.

I'm going to stop marketing here, but I thought it is one of the major milestones for sysmoocm and thus for what I've spent way too much time on in recent months - and thus deserves to be mentioned here on this personal blog.

OsmoSDR boards available for interested developers

I've posted about this on the OsmoSDR blog, so there's no point in copy+pasting it here.

There are still boards available, so feel free to order if you are interested in yet another exciting Osmocom embedded hardware/firmware/driver/software project!

Some follow-up on the Osmocom Berlin meetings

We've now had the first two incarnations of the Osmocom Berlin User Group Meeting. The start was great, and we had probably something around 10 attendees. Some were the usual suspects like the various Osmocom developers living in Berlin. But we also had a number of new people attending each of both of the meetings, which is good.

To my big surprise people are even flying in from other parts of Europe in order to be able to attend. Last time from Sweden, and for the next meeting some folks from the Netherlands have announced themselves.

To an even bigger surprise, the attendee from Sweden announced that he is working for an Ericsson research lab, and apparently they are using OsmocomBB quite a bit inside that lab. They think it's a great tool, and apparently nothing else with the same flexibility (i.e. full source code) is at their hands that can compete.

On the one hand it is surprising to see such a large traditional Telco supplier to start to use such amateur tools like OsmocomBB, which definitely have not had even a fraction of the testing (particularly with various operators in various countries) like the commercial protocol stacks.

On the other hand, if you think more about it, Ericsson is entirely a network equipment supplier today. They have spun off their baseband processor business to become part of ST-Ericsson, they have pulled out of Sony-Ericsson, sold their TEMS product line to Ascom and other bits and pieces to Tieto. So right now, if they need a MS-side protocol stack or engineering phones, they probably have to obtain what is available on the market. And that's unfortunately not all that great, as the products are either

Measurement devices aimed at mostly L1 testing / QA (Racal, Agilent, Rohde-Schwarz)
Trace mobiles primarily aimed at field testing (TEMS, Sagem OT) and while they provide traces they don't permit you to send arbitrary data or behave spec-incompliant
Mobile Phone development platforms (Qualcomm, MTK, Infinenon, ...) which don't necessarily give you the full source code to the stack, and are only available if you actually intend to build a handset

So all in all, the more I think about it, it is actually not too surprising that they ended up with OsmocomBB. It's free (as in free beer) and they get the full source code with it. You need a lot of skills and time to get it running and find your way around how to use it, but I guess if you're working in cellular protocols and embedded systems, it's not that hard.

Prototype smart card chips in DIL-40 case have arrived

Finally, the first samples of the smart card chip (for the Osmocom CardOS project) have arrived. As opposed to the final smart cards, this one has been packaged in a DIL case instead of the usual thin credit-card sized plastic. The reason for this is quite simple: This way lots of I/O pins for debugging as well as JTAG can be accessible during COS development.

Here you can see the first incarnation of a veroboard connected to an adapter pcb inside an Omnikey smart card reader:

After confirming it worked, I soldered the wires directly to the adapter PCB, as can be seen here:

There is already a real PCB design that is currently manufactured, i.e. in a week or so there will be a picture of a clean, professionally-produced/etched PCB with all of the prototype pins exported.

In terms of the COS, I haven't done much more work than compared to the last posting, mainly due to a large number of other projects. But we will get there...

Name that UART: April 2012

It's sort of a cheap knock-off idea stolen from the Name that Ware on bunnies blog: I'm going to post one picture every month about a UART that I found on embedded hardware. Unfortunately I don't have much to offer in terms of a reward for whoever finds the true solution ;)

In any case, every month there are devices that I'm looking into either out of my own interest, or because the work at gpl-violations.org requires it. In most of them, you can find a UART to get to the u-boot / Linux serial console.

So here is the device that I just took apart earlier today:

The location of the UART pads was obvious, after looking at the PCB for a very short time. The entire unpopulated U1 footprint appeared suspiciously like a UART level shifter for true RS232 voltage levels:

You can see two signals going directly to a small unpopualted3-pin header
There are two other signals coming from somewhere under the main SoC
There are capacitors (C440, C441) directly connected to the U1 for the charge pump

h-online article covering OpenBTS and OpenBSC

You can find a 3-page article about OpenBTS, OpenBSC and related projects available from the h-online web site.

OsmoDevCon 2012 is over...

We just finished the 4th and final day of the OsmoDevCon 2012. It contained four days of in-depth presentations and discussions related to Free Software communications systems, most notably OsmocomBB, OpenBSC, OpenBTS, OsmoNITB, SIMtrace, OsmoGMR, OsmoSDR, rtl-sdr and many more.

I think it was a great chance to make sure the key developers involved with those projects are up-to-date with what everyone else is hacking on. I was especially happy with the presentations of Holger's smalltalk implementation of certain GSM protocols/interfaces, and it seems my small informal Erlang intro has raised some interest.

If anything, the 4-day conference has shown that there is a massive amount of work going on in the various different projects, and that it has clearly grown beyond anything that a single person could still be involved in all the sub-projects.

Personally, I'm happy to see what has grown out of this "we have a BS-11, let's see what we can do with it" that Dieter and I started in 2008. Now we're no longer talking about BTS/A-bis/BSC, but about SS7, MSC, TCAP/MAP, SCCP, HLR, Erlang, smalltalk, DECT, SIM/USIM, COS, SDR, GMR/Thuraya, TETRA and more recently also femtocells as well as NodeBs.

In the spirit of that 2008 presentation Running your own GSM network using the BS-11, Dieter Spaar has now demonstrated his talk on Running your own UMTS network, using NSN or Ericsson NodeBs. I'm really excited to see where that will take us - despite the fact that due to the 5 MHz wide channels, it's pretty close to impossible to get the experimental spectrum licenses that most of us have been able to get in recent years for our work.

As an outlook, over the remaining year 2012, I see progress in the following areas:

osmo-nitb will get a VLR/HLR split (async database access)
we will build a stand-alone osmo-msc with A interface
the signerl TCAP/MAP implementations will be used in production
OsmoSDR firmware will be completed, the hardware will start shipping
a new card operating system (OsmoCOS) will emerge
a UMA gateway will be implemented
a Free Software GPRS/EDGE PCU and RLC/MAC implementation will appear
last but not least, sysmoBTS will start commercial shipment really soon now

I'd like to thank our host c-base for having us block their conference room for 4 days, as well as all attendees who have travelled from all parts of Europe, but even the United States and Russia to participate. There definitely will be another OsmoDevCon, though we don't know yet at which point in time.

Using a cheap (USD 20) DVB-T USB stick as SDR receiver for (not only) gnuradio

Fellow Osmocom hacker Steve Markgraf has been working on what now seems to be the cheapest way to receive real-world radio signals for PC-based SDR like gnuradio: rtl-sdr. RTL refers to the RTL2832U chipset frequently used in such devices. It can be used to obtain 2.8 Ms/s of 8-bit I+Q samples.

Below is a picture (courtesy of Steve) how the hardware looks like:

Osmocom GPS timing source with u-blox LEA6-T

Recently we have been looking for an inexpensive way to generate a high-accuracy clock source for E1 lines, as it is required by a number of classic BTSs that don't have a sufficiently accurate OCXO built-in.

Luckily, the Digium E1 cards like TE-410P have a timing connector, to which an 8.192 MHz signal can be injected. Unfortunately, there don't seem to be any OCXOs around for that frequency. That's where the u-blox LEA-6T comes into play: It has a configurable TIMEPULSE2 output that can generate any frequency up to 10 MHz. We use this in our board to generate 8.192 Mhz and want to feed that into the Digium card.

So all we had to do is build a small board that contains the module and connector for antenna input, clock output and the obligatory 2.5mm stereo jack for the OsmocomBB-style UART:

Thanks to Sylvain for doing the schematics/PCB design, and thanks to Pablo for writing the code to configurea and activate the 8.192MHz output.

Once the design is verified, the schematics + gerber will be available, as well as board from the sysmocom webshop.

Alcatel MTK phone UART pinout

The Alcatel OT-890D is a MT6573 based smartphone. It seems one of the UARTs is available on test pads as seen in this picture:

The voltage level is still 3.3V, so no fancy 1.8V gear is required.

During boot, the UART is first used at 19200 bps, where it prints the strings "MW01" and "MW02". I then switches to 115200 bps where it prints "READY", and finally switches to 921600 bps, where it seems to output some mixed binary/text messages containing AT commands and responses between AP and BP, as well as some debug information:

�Ue� � � T+CREG=2
�Ue�!�!�!T+CSQSQ=1
�Ue�!�!�!AT+CREG=2
�Uew�"w�"w�"SQSQ=1
'Ue"""      AT+EFUN=1
      SML: Load!_Ue""""""
                         SML: Load!hU("("("

I haven't yet investigated if the binary between the text is some standard HDLC framing or a TS 07.10 multiplex.

If anyone knows more about the boot process (MW01/MW02/READY) or the binary protocol, please let me know.

The next project on the horizon: A Free Software CardOS

Now that we have a 100% free software GSM protocol stack and baseband firmware for the network and mobile phone side, the only remaining proprietary part is the SIM card. And what is a SIM card? It's a small embedded computer / SoC with integrated flash + RAM.

Once again, like in many other areas of the telecommunications industry, development of Free Software has been hampered by lack of available register-level hardware documentation. Without such information, how should you be able to program? Hardware without such documentation is an insult to every software developer.

The next problem is that typically, the Card Operating System (COS) is written into mask ROM of the smartcard SoC. Making such a mask is quite expensive, and it means that for every software version, different silicon will have to be produced. So unless you are going to have millions of units in quantity, it is unlikely that it would make economic sense.

However, in recent years, purely flash based smartcard chips have been available and getting less and less expensive. However, none of them (like the Atmel AT90SC7272 or similar devices) have freely available documentation. Furthermore, availability on the open market is somewhat of a problem, mainly because they have been used extensively by people cracking encrypted satellite TV channels. In recent years, the smartcard industry is trying hard to cut any kind of supply to that group of users.

However, luckily, we now see small/independent chip design houses in China picking up and producing their own smartcard chips. They are not only cheaper, but they simply hand out the documentation to anyone who asks them. No questions asked, no NDA required. Welcome to the promised land! That's what Free Software developers like:

Free access to documentation without any confidentiality agreements
development samples available at the same price as quantity pricing later on
inexpensive development hardware with JTAG access
reference source code provided without NDA
they are happy that somebody wants to develop for their hardware

As you can see, I am quite enthusiastic about this. I like this no-bullshit approach. No stupid marketing and sales droids who charge ridiculous fees for proprietary development tools that are inflexible and force developers to use one particular OS/IDE/toolchain.

I'm not sure how much time there will be, given the multitude of other projects that are all asking for attention. However, I think this is a chance that the Free Software community doesn't get every day. Let's hope some other people like bare iron programming in small embedded systems can get excited and we can create a FOSS COS. It doesn't have to be something serious. Something quite simple would be sufficient for the beginning. I'm not thinking of EAL4+ certification, multiple channels and public key crypto. SIM/USIM cards are simple, they just require a bit of filesystem read/write operations plus authentication. And luckily, SIM toolkit development doesn't have to be done in Java this way, either ;)

OsmoSDR status update

It has been two months since I first was able to play with the OsmoSDR hardware prototypes. Back at that time, there was no FPGA code yet, and some hardware bugs still had to be resolved. Nonetheless, the e4k tuner driver could already be implemented and tuning was confirmed by looking at the analog i/q spectrum.

Meanwhile, the hardware has been re-worked by SR-Systems and FPGA VHDL code written by maintech.de. Ever since that, they dropped the ball again with me as I had been careless enough to volunteer for writing the firmware.

And that's what I did or at least tried to do for quite some time during the last two weeks. The main problem was that I didn't have much time. The second problem was that I never was able to get the SSC (synchronous serial controller) receive DMA working.

This was a really odd experience, as I've worked a lot with that very same SSC peripheral before, while writing firmware for the OpenPICC some 6 years ago. However, this was in an at91sam7s, where the SSC is interfaced with the PDC (Peripheral DMA Controller). In the at91sam3u of OsmoSDR, it interfaces with a more modern DMAC/HDMA controller, capable of scatter-gather DMA and other fancy stuff.

Atmel has provided reference code that uses the SSC DMA in transmit mode (for a USB audio device playing back music via the Wolfson codec on the SAM3U-EK board). After thoroughly studying the DMAC/HDMA documentation I set out to write code for DMA-based SSC receiver. And it never worked.

I actually wrote two independent implementations, one from scratch and the other based on Atmel reference code. Neither of them worked. It seemed to be a problem with the hardware hand-shaking between SSC and DMAC. The SSC was successfully receiving data, and that data could be read out from the CPU using a polling or IRQ based driver. But if you're running at something like 32 Mbps and don't have a FIFO, you desperately want to use DMA. When the DMA handshaking was turned off, the DMA code worked, but of course it read the same received word several thousand times before the next data arrived on the SSC.

In the end, I was actually convinced it must be a silicon bug. Until I thought well, maybe they just connected the flow controller to a different ID in Rx and Tx direction. Since there are only 16 such identifiers, it was relatively easy to brute-force all of them and see if it worked. And voila - using the identifier 4, it worked!

So what had happened? The Atmel-provided reference code contained a

 #define BOARD_SSC_DMA_HW_SRC_REQ_ID      AT91C_HDMA_SRC_PER_3

and that was wrong. 3 is valid for SSC TX but not for SSC RX. Unfortunately I never found any of those magic numbers in the SAM3U manual either. They are not documented in the chapter of the SSC, and they are not documented in the chapter about HDMA/DMAC either. And they are not identical with the Peripheral Identifiers that are used all over the chip for the built-in peripherals.

In case anyone else is interested, a patch can be found at my at91lib git repository.

I filed a ticket with Atmel support, and they pointed out in fact there was a table with those identifiers somewhere in the early introductory chapters where you can see a brief summary of the features of each integrated peripheral. Unfortunately they use slightly different naming in that chapter and in the DMAC, so a full-text search also didn't find them. Neither is that table visible in the PDF index.

So about four man-days later it was finally working. Another day was spent on integrating it with the USB DMA for sending high-speed isochronous transfers over the bus into the PC. And ever since I'm happily receiving something like 500,000 or 1,000,000 samples / second from an alsa device, using snd-usb-audio. Luckily, unlike MacOS or Windows, the Linux audio drivers don't make arbitrary restrictions in the sample rate. According to the USB Audio spec, the sample rate can be any 24bit number. So audio devices with 16.7 Ms/s are very much within the spec. I hope some of the other OS driver writers would take that to their heart.

One of the first captures can be found at this link, containing a bzip2ed wave file in S16LE format Stereo (I/Q). It contains a FM audio signal transmitted using a small pocket-sized FM transmitter.

There is no I/Q DC offset calibration yet, but once that is done we're probably able to finally put the design into production.

More research into the Motorola Horizon macro and Mo-bis

Once upon a time there was an Americans company called Motorola, and they decided to implement GSM. Unfortunately they decided to deviate significantly from the specification and implement their own proprietary back-haul protocol between BTS and BSC, called Mo-bis. It replaces the standardized A-bis interface.

Today, There are plenty of phased-out Motorola Horizon / Horizon II macro BTSs that have been phased out. Basically you can get them for scrap value, which makes them an ideal target for GSM enthusiasts willing to run a single-cell network with little investment. So while there are actually people who are interested in operating a power-consuming device roughly the size of a washing machine in their home/office - they are normally not interested in running a 19" rack sized Motorola BSC with it. Also, the BSCs are much less frequently to be found compared to the BTS.

So it would be great to support Mo-bis from within OpenBSC. A couple of brave young men have set out to try the seemingly impossible. There's absolutely zero documentation available on that protocol, and no wireshark support either. However, the University of Brno (Czech) has a functional Motorola BTS + BSC setup, and I was able to obtain protocol traces from them and actually experiment with the equipment in their lab.

The entire Motorola GSM architecture seems to be over-engineered without end. Basically you are looking at a distributed computer from the early 1990ies. Lots of processor cards (m68k, ppc) interconnected by HDLC links on top of synchronous 2Mbps links with 64k timeslots. Those links are available e.g. on the backplane of the BTS as a TDM highway. So basically even inside the BTS, the individual processors talk over E1 to each other. In the BSC, there is a token ring based LAN between some of the cards instead. And the MCUF in the BTS even supports to transport those proprietary inter-cpu links via fiber optic (!).

Each processor has a 16bit identifier by which it can be addressed in form of physical addresses. Individual processes on the processors have fixed process identifiers, and they allocate a variety of mailboxes in which they can receive messages from remote processors. There are routing functions at intermediate notes.

So any process on any processor card can send messages to any mailbox of any other process on any other processor, independent of its physical location (locally at the BTS, or at the remote BSC, or even at remote BTSs).

Besides physical addresses, there are also functional addresses. Thos addresses are used particularly to support fail-over. Every board in a BTS and BSC can be fully redundant, and if you use physical addresses, you would address one of the two redundant boards. Using functional addresses, you address the function they both can perform, and some routing magic will make sure it ends up at the current active node in the pair.

There are multiple processors in every TRX, and a couple of processors for each BTS, processors in the E1 line cards, etc. Now speaking of the actual Mo-bis interface: It seems to be a weird mixture between 08.58 (RSL) and 08.08 (BSSAP/BSSMAP). However, after staring at the messages sufficiently long, I have been able to write a more or less complete wireshark dissector for them. Radio Channel Activation (RACH/IMM.ASS) are for example handled directly inside the BTS, they don't exist as transactions on the Mo-bis like they do in A-bis.

So implementing the actual location update / MO+MT voice call and SMS related transactions is actually not all that hard. What makes things really difficult is the way the BTS is initialized at startup. Basically what resembles the OML part of standardized A-bis.

There is a lot of low-level management and bring-up of the individual processes and boards, and the download of a large 500 kByte-sized BLOB simply called database. This binary database contains literally hundreds of configuration parameters for the BTS and its neighbors. It also contains sophisticated configuration of the message routers, the switching/multiplexing of 64k timeslots on the various links, information on redundant paths within the back-haul network, etc.

Interestingly, using the password combination 3beatles and 4stooges on any of the serial consoles of the BTS or BSC, you can enter into a "god-mode" which permits you to enter the executive monitor (EMON). The executive is the operating system they run on both m68k and ppc processors. It provides access to something like a syslog of messages from the various processes, and you can manually generate messages that are to be sent to mailboxes of processes. You can inspect the object table (application programs an databases), read/write to PCMCIA flash cards, read and write to logical and physical memory, inspect CPU and I/O usage and much more. In fact, the integrated Code Object Manager (COM) even allows the processors to synchronize their code versions and remotely boot other CPUS via HDLC channels.

For a communications system geek like myself, it's extremely fascinating to see such a sophisticated and versatile system. I only wonder why on earth somebody would come up with something as complex, only to connect a couple of BTSs to a BSC. Thus, the only logical explanation is that Motorola has developed this distributed proprietary computing system way before they went into GSM, and they probably just recycled it as it already existed.

If anyone knows more about the history of this, I would be excited to hear about it. It literally feels like being an archaeologist. Analyzing ancient technology from our forefathers. But then, it only is 20 odd years old. The only time I had a similar feeling was when I briefly came in touch with IBM mainframes in 2001 and looking at IBMs SNA protocol stack.

Some comments on the heated debate on SFC / Busybox / Linux GPL enforcement

During the past week[s], there has been a heated debate on the alleged methods of GPL enforcement as it is performed by the Software Freedom Conservancy on behalf of the Busybox copyright holders.

The extent of license enforcement on Busybox has apparently triggered the proposal to create a non-GPL replacement for it, which in turn has received quite harsh responses e.g. from Matthew Garrett.

It's been relatively difficult for me to figure out what is really going on here. It is well-known that the Free Software Conservancy has been actively enforcing the GPL on Busybox. But then, at the same time gpl-violations.org has been (and still is!) similarly active in enforcing the GPL on the Linux kernel. Still, I haven't yet seen calls to write a non-GPL Linux kernel replacement. Of course, the complexity is on an entirely different scale, so this point is moot.

However, for quite some time there have been rumors about the intensity (some would say aggressiveness) of the enforcement. I don't want to accuse anybody of anything, so I'm going to write speculatively about it.

This post is to summarize my thoughts on all of this:

It is well within the right of each author / copyright holder to decide on the enforcement strategy and license interpretation. As such, I respect the decision of the authors. It is their work, they should decide what to do.
In any kind of GPL enforcement, you of course not only want the complete corresponding source code to one program, but to all of the GPL/LGPL/AGPL or otherwise copyleft licensed programs contained in the product. We at gpl-violations.org have always been requesting the complete corresponding source code to all GPL licensed software during our communication with the infringing companies. This request was typically honored by everyone, without the need to apply any pressure onto it. After all, releasing only one bit of code causes the risk to get sued by somebody else who owns the other not-yet-compliant part of the code.
Now there have been rumors that SFC was not only requesting non-Busybox source code, but also making it a condition for the explicit re-instatement of the license on Busybox. Whether or not there was such a hard condition is subject to debate and there are different opinions on it. For those in the field of FOSS licensing, it has always known that there are different lines of thought with regard to the requirement to explicit reinstatement. We in Germany generally think that it is not required at all, and the existing preliminary injunctions at least implicitly acknowledge that as they enjoin companies from distributing a product as long as it is not in compliance with the license. In other (particularly the U.S.), it is generally assumed that explicit reinstatement is required. In such a case, it may very well be legally possible to use it as a lever to obtain source code for other programs like the Linux kernel. However, I am personally not sure if that really is the right strategy. Not everything that is possible legally is ethically the right thing to do. But then, ethics and legal customs differ widely in the FOSS communities, as they do in society in general. Some countries and communities believe in the death penalty, others don't. Some countries allow abortion, others don't. Some allow prostitution, others don't. So when judging about whether that "reinstatement lever" is acceptable or not, we have to accept that there may be different lines of thought. I for my part definitely think that the far superior method is, beyond doubt, to have a rights holder on those other program in order to make any demand for source code (as opposed to a mere request without implicit or explicit legal threat).
There also have been rumors about a requirement on submitting future source code releases to a compliance audit by the Conservancy. According to SFC sources, there never was any such demand, and the rumors are likely spawned by some incorrect claims of a defendant in a court case, which ended up in the public record. If there was such a requirement, I wouldn't think it is just - at least not for a first-time non-intentional infringement case. If there was repeated infringement and a clear sign that it would happen again and again, such a requirement for future audits may be justified, depending on the case.
People who claim that GPL enforcement is scaring away companies from using Linux and/or other Free Software also have to be careful in what they say. If a commercial entity enters a new market (let's say Android Tablets), then there is a certain due diligence required before entering that market. So if you don't understand Free Software and particularly GPL licensing, then you shouldn't place a Linux-based device on the market. Just think about an analogy: If you have a recycling company and enter a new market (disposal of hazardous chemicals), then you cannot simply treat those chemicals as regular waste, wait until you run into legal trouble and expect to get away with it.
I think there are still far too many GPL violations out there, and we need to see more enforcement in order to get all the major players in their respective lines of business into compliance. But come on, dealing with embedded devices in 2012 and still getting compliance outright wrong really means that there has not been the least bit of attention on this subject. And without enforcement, it is never going to change. People who want no enforcement should simply use MIT-style licenses.
Last, but not least, I also think GPL compliance is a matter of fair competition. There are some companies who really do a good job in ensuring compliance with the various Free Software licenses. If their competition doesn't invest the funds into the respective skills, procedures and business processes, they are getting an unfair competitive advantage against those who are doing it right. If there was no enforcement, the motivation would be to reduce efforts in compliance, not increase it.

Let me conclude with a clear statement to anyone who thinks that by replacing Busybox with a non-GPL licensed project they can evade GPL enforcement: It will not work. There are others out there enforcing the GPL. Last but not least gpl-violations.org. Despite the notoriously outdated webpage, we are still alive and kicking, churning down on the violation reports that we receive. Armijn Hemel, Joachim Steiger, Tim Engelhardt, Julia Gebert and Till Jaeger deserve much of the credit for all that work, while I'm mostly spending each awake minute hacking Free Software for mobile communications. Yes, we should publish more about our activities, and I hope to find the time to do so. There should at least be an annual report with the number of cases...

New OsmocomBB RSSI monitor firmware

Jolly has been hacking up a nice new RSSI monitoring firmware application for OsmocomBB.

I let the pictures speak for themselves:

I really hope this trend continues and we'll get some actual user interface in OsmocomBB at some point this year..

OP25 project joins hosting on osmocom.org

Some days ago, I noticed that the famous OP25 project (a Free Software implementation of the APCO25 system, a digital trunked radio system) was no longer reachable on-line. It seems they were running this on a desktop PC in a university. As nobody in the project still seems to be at that university, a change in the network configuration had accidentally rendered the website unreachable.

After some quick e-mails, I offered to host them within the osmocom.org family of Free Software Projects for mobile communications. This is when op25.osmocom.org was created, and a full-site backup uploaded + installed.

I'm really happy that we were able to do a small part to help to make sure this valuable project remains accessible to interested parties in the signal processing and mobile communications field.

First osmo-nvs-gps evaluation boards soldered

At the osmocom project, we recently discovered the most interesting NVS NV08C-CSM module. It not only is a superb GPS receiver, but it includes GALILEO and GLONASS receivers, too. However, it's only available as an industry module, or as an expensive (700 EUR or so) evaluation kit.

Given the cheap PCB prototyping service at seeedstudio, I thought I'd spend an afternoon creating the schematics and PCB layout for an evaluation board. It exports the two 3.3V UARTs on OsmocomBB-style 2.5mm jacks, so they can be used with the T191 cables. I have the feeling this 2.5mm jack is becoming a new standard for low-voltage RS232 links ;)

Furthermore, it exports the SPI, I/O and I2C on a 20pin 2.54mm pitch header, connects to an external antenna via a MCX socket and has an optional footprint for a CR2032 battery on the bottom side.

So far, the board seems to be working fine. If there is interest in the bare PCB itself (without components!), please send me an e-mail. Depending on the amount of interest we might add it to the sysmocom webshop.

Schematics and Gerber files will be available at http://openbsc.osmocom.org/trac/wiki/osmo-nvs-gps soon.

Having Fun with DHL Express!

This is what I got when tracking one of my inbound shipments:

It seems DHL is having fun bouncing the package back and forward between Hong Kong and Leipzig(Germany). So far, it started in HK, then arrived in Leipzig on January 8, went back to HK, back to Leipzig, back to HK, back to Leipzig and is currently allegedly again in Hong Kong _after_ succesfully passing German customs clearance on January 15.

For the TCP/IP nerds among the readers: I wonder when the TTL expires.

First assembled prototypes of osmo-e1-xcvr

I mentioned it briefly before: I've designed a small E1/T1/J1 transceiver board, which is going to be used for experimentally interfacing such a TDM line with microcontroller and/or FPGA. The name of this board is osmo-e1-xcvr.

The first prototype PCBs have arrived yesterday, and despite lots of other more important work I couldn't resist but to actually solder some of the units. The result can be seen here:

I don't have time to do anything beyond very basic testing right now, but so far the boards seem to be doing fine. Now we need a driver for the transceiver chip, and connect its control interface over SPI to some microcontroller (likely sam7s/sam3s/sam3u in my case). The actual serial bitstream will end up at the SSC peripheral of the controller.

OsmoSDR status update

It's already two weeks since my last post mentioning OsmoSDR only very briefly. By now, OsmoSDR is fully public and you can read all about it on the http://sdr.osmocom.org/ website.

Specifically, the website includes Schematics, and one of my colorful block diagrams. I am a text guy and really hate to work with graphics, but the block diagram of the Calypso has helped a lot in the context of making people understand OsmocomBB, so I tried again for OsmoSDR:

So as you can see, it is a very simple, straight-forward design with a chip tuner, direct I/Q down-conversion, ADC for differential I and Q signals as well as a small FPGA for basic filtering and serial format conversion, followed by a Atmel SAM3U microcontroller (Cortex-M3, high speed USB).

And yes, it's receive only. However, it has a stacking connector for later addition of a transmit daughter-board which may eventually follow later in 2012.

So what is this OsmoSDR going to be used for? Well, for receiving any kind of signals between 64 MHz and 1700 MHz (possibly up to 1800 MHz, untested). We don't build it for a specific application, but we simply thought that for many applications a member of the USRP family is expensive overkill, and the FCDP has this arbitrary restriction at 96 kHz sampling frequency.

Please note that while I may be the only OsmoSDR developer that blogs about this project, it is very much a team effort and I'm only a minor part of that team. Apart from selecting the SAM3U, writing firmware and drivers for it as well as some discussions early on in the project, I didn't have any involvement in the Hardware design. Those credits go to Christian Daniel and Stefan Reimann.

So where do we stand? There are 5 prototypes of the first generation, they look like this:

There are some smaller hardware issues that were easy to work around, but one bigger problem related to the fact that the Si570 programmable oscillator output levels didn't match quite with what the FPGA clock input requires.

There will be a second generation board fixing this and other problems, and hopefully we'll see some progress in the weeks to come.

Firmware-wise, the code is currently scattered over a couple of different repositories, but I'm going to consolidate that soon. If you've worked with OpenPCD or SIMtrace, you will find some similarities: We split the flash of the controller into two partitions: One for the DFU bootloader, and one for the application code. You can then use the USB DFU (Device Firmware Upgrade) standard to quickly update the actual firmware of the device, without having to resort to jumpers or un-plugging and re-plugging of the hardware.

This also meant that I had to re-implement the old sam7dfu code for the SAM3U, which has considerable differences in the USB peripheral, cpu core, board startup code, etc. So it's really a reimplementation than a port. The good news is that I tried to make it as general as possible and integrate it with at91lib, Atmels reference code. So it should be easier to use it with other Atmel SoCs like the sam3s which I want to use e.g. in SIMtrace v2.

HTCs delays in releasing Linux source code are unacceptable

The Taiwanese smart phone maker HTC is widely known to be delaying its Linux kernel source code releases of their Android products. Initially, this has been described to to the requirement for source code review, and making sure that no proprietary portions are ending up in the release.

While the point is sort-of moot from the beginning (there should be no proprietary portions inside the Linux kernel for a product that wants to avoid entering any legal grey zone in the first place), I was willing to accept/tolerate it for some time.

At one point more than one year ago, gpl-violations.org actually had the opportunity to speak in person to senior HTC staff about this. I made it very clear that this delay is not acceptable, and that they should quickly fix their processes in order to make sure they reduce that delay, eventually down to zero.

Recently, I received news that the opposite is happening. HTC still has the same delays, and they are now actually claiming that even a 120 days delay is in compliance with the license.

I do think neither the paying HTC customers, nor tha Free Software community as a whole have to tolerate those delays. It is true that the GPLv2 doesn't list a deadline until when the source code has to be provided, but it is at the same also very clear what the license wants: To enable people to study the program source code. Especially in todays rapid smart phone product cycles, 120 days is a very long time.

So I hereby declare my patience has ended here. I am determined to bring those outrageous delays to an end. This will be one of my new year resolutions for 2012: Use whatever means possible to make HTC understand that this is not how you can treat Free Software, the community, its customers, the GPL and in the end, copyright itself.

More "bare iron" development: OsmoSDR, osmo-e1-xcvr and SIM bank

I'm currently quite excited to be doing more bare iron programming as well as actual electrical engineering work again.

There's actually not just one project I'm working on, but a variety of them:

OsmoSDR - an upcoming small form-factor, inexpensive USB SDR. Not big and expensive like USRP or real "professional" solutions, but also not as weak as the ultra-narrow-band funcube dongle. I wasn't involved in the hardware design, but have volunteered to take care of the firmware development for the Atmel SAM3U micro-controller inside.
osmo-e1-xcvr - a relatively simple circuit board containing the magnetics, LIU, clock generation and transceiver for E1/T1/J1 lines. The idea here is to have a solution for the analog part, as well as HDB3/B8ZS/AMI encoding, which can then be attached to any FPGA, CPLD or micro-controller development board. It exposes SPI for controlling the transceiver, and a synchronous serial bit-stream for Rx and Tx.
unnamed sim-bank project - here the goal is to find a cheap solution to attach a large number of SIM cards to either a PC or directly to Ethernet. This can be very useful for testing, where you host your sim cards in a centralized location and can borrow them to remote users/devices over TCP/IP. There are commercial devices available for this, but they are quite expensive (like 1700 USD for 32 card device) and intended to be used with some proprietary windows software (who wants that?!?).

In the latter two projects I'm also doing the component selection, schematics design and PCB layout. One project with KiCAD, the other in EAGLE, as I really want to get first-hand experience of the usability of Free vs. proprietary EDA tools. I'd love to also evaluate Altium Designer, but they are still windows-only, and that would just make life way too difficult for me.

The projects will be duly announced soon, and they are all intended to be Open Hardware designs with Free Software. We'll probably also make all of them available at shop.sysmocom.de, too.