Harald Welte's blog
   

RSS

Harald's Web
gnumonks.org
hmw-consulting.de
sysmocom.de

Projects
OpenBSC
OsmocomBB
OsmocomTETRA
deDECTed.org
gpl-violations.org
gpl-devices.org
OpenMoko
gnufiish
OpenEZX
OpenBeacon
OpenPCD
librfid
openmrtd
opentom.org
netfilter/iptables

Categories

Archives

Other Bloggers
David Burgess
Zecke
Dieter Spaar
Michael Lauer
Stefan Schmidt
Rusty Russell
David Miller
Martin Pool
Jeremy Kerr
Tim Pritlove (German)
fukami (German)
fefe (German)
Bradley M. Kuhn
Lawrence Lessig
Kalyan Varma

Aggregators
kernelplanet.org
planet.netfilter.org
planet.openezx.org
planet.openmoko.org
planet.foss.in

Ohloh profile for laforge
identi.ca
twitter
flattr
Linked in
Xing

Creative Commons License
Articles on this blog/journal are licensed under a Creative Commons Attribution-NoDerivs 2.5 License.


blosxom


Contact/Impressum

       
Tue, 31 May 2011
Starting to investigate old Motorola Dimetra EBTS

Together with some friends, we have managed to get our hands on some ancient (1997) Motorola Dimetra TETRA equipment. Specifically, this includes the Base Radios (BR) and the TETRA Site Controller (TSC).

We haven't yet managed to put everything up in the wiki, but you can watch our progress at the Dimetra_EBTS page on http://tetra.osmocom.org/ as well as it's sub-pages.

It's going to be a big challenge to put all that equipment to some good use. Success is probably defined in terms of running your own small TETRA network with such an EBTS but without any of the Motorola Dimetra core network infrastructure (SwMI, basically the same thing we did for GSM with OpenBSC.

The big conceptual difference to GSM here is: In GSM, the internal protocols (A-bis, A, ...) are all publicly specified. There are vendor-specific dialects, but those are relatively easy to figure out. In TETRA, the ETSI only specified the air interface, but not the interfaces between the wired components of the network. This leaves pretty much everything else proprietary :(

So if anyone has any information (installation manuals, service manuals, provisioning software, protocol specifications, ...) or experience with configuring or maintaingin this equipment, I would be very happy if you could drop me a message.

[ /tetra | permanent link ]

Sat, 22 Jan 2011
Public release of Osmocom TETRA code

Today I have publicly released the TETRA receiver code that I've started to work on earlier this year. The gnuradio-based demodulator, PHY and lower MAC code as well as some README file is available from the new http://tetra.osmocom.org/ website.

There's still a lot of work to be done, but fundamentally we are able to receive, demodulate and decode TETRA TMO downlink data. So the task of the software somewhat compares to that of gsm-tvoid or gsm-receiver (part of airprobe).

A corresponding project mailing list has also been made available. Please respect that this is a development-only discussion list right now. If you cannot make the code work and need help with it, chances are high that it doesn't do anything useful for you anyway.

There is some early code that should eventually enable us to run a base-station side transmit implementation, but it's not working yet.

[ /tetra | permanent link ]

Sat, 08 Jan 2011
Working on a Free Software TETRA implementation

Those who have been following my twitter feed over the last week will already know: I've been in deep hacking mode implementing the lower levels of TETRA, specifically the PHY and lower MAC but also parts of the upper MAC level.

The primary idea here is to produce something similar to what airprobe is for GSM: An air-interface protocol analyzer that can demodulate/decode/demultiplex information received from a TETRA base station.

I'm not working on this alone, a number of known (and unknown) names from the Osmocom projects have been involved again. Progress has been surprisingly quick. The biggest gain was Dieter discovering that we didn't have to write our own pi4/DQPSK demodulator, but that somebody had already done that as a gnuradio hierarchical block originally intended for the more advanced channel types of APCO25.

So we could concentrate on the PHY and lower MAC layers, i.e. implementing stuff like

    correlator for the various training sequences to achieve frame sync
  • de-scrambler, de-interleaver, convolutional decoder, CRC, Reed-Muller decode
  • Implementing the TDMA multiplex, reading the BSCH (like SCH in GSM)
  • Decoding the MAC-layer PDUs like ACCESS-ASSIGN, SYNC, SYSINFO, RESOURCE
  • Peeking into the higher layers like MM

Before writing the decoder I also wrote encoders/interleaver/scrambler etc. for the transmit side in order to do first testing/validation of the decoder. Using this encoder, we are able to generate continuous downlink SYNC bursts containing BSCH(MAC-SYNC PDU) + BNCH(SYSINFO PDU). As the SYNC bursts can be used for unallocated time-slots, a never-ending sequence of this single burst should provide a valid carrier that TETRA mobiles can lock to.

Working on all this has taught me much. My previous knowledge on convolutional codes, scrambling, interleaving, training sequence corellation, viterbi decoding, etc. has been mostly abstract and theoretical. Now I had the chance of implementing [almost] everything from scratch. Now I can understand what people like Tvoid or Piotr went through when they wrote gsm-tvoid/gsm-receiver (part of airprobe).

For the next couple of weeks I have to turn back to doing some higher priority work again, and in February I want to play with the GSM RF side of the MTK GSM chipsets again, so I don't know when I'll be able to continue with the TETRA related work. However, I hope other developers in the team will pick up where I left and bring the project further forward.

As soon as the code has moved beyond early prototyping, we'll be releasing the demodulator, libosmo-tetra-phy, libosmo-tetra-mac and associated command line tools.

[ /tetra | permanent link ]