<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="../../assets/xml/rss.xsl" media="all"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>LaForge's home page (Terrestrial Trunked Radio)</title><link>https://laforge.gnumonks.org/</link><description>Terrestrial Trunked Radio</description><atom:link href="https://laforge.gnumonks.org/blog/categories/tetra.xml" rel="self" type="application/rss+xml"></atom:link><language>en</language><lastBuildDate>Thu, 24 Oct 2024 20:08:50 GMT</lastBuildDate><generator>Nikola (getnikola.com)</generator><docs>http://blogs.law.harvard.edu/tech/rss</docs><item><title>Starting to investigate old Motorola Dimetra EBTS</title><link>https://laforge.gnumonks.org/blog/20110531-starting_to_play_with_motorola_dimetra/</link><dc:creator>Harald Welte</dc:creator><description>&lt;p&gt;
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).
&lt;/p&gt;
&lt;p&gt;
We haven't yet managed to put everything up in the wiki, but you can
watch our progress at the &lt;a href="http://tetra.osmocom.org/trac/wiki/Dimetra_EBTS"&gt;Dimetra_EBTS page
on http://tetra.osmocom.org/&lt;/a&gt; as well as it's sub-pages.
&lt;/p&gt;
&lt;p&gt;
It's going to be a big challenge to put all that equipment to some good
use.  Success is probably defined in terms of &lt;i&gt;running your own small
TETRA network with such an EBTS but without any of the Motorola Dimetra
core network infrastructure (SwMI&lt;/i&gt;, basically the same thing we did
for GSM with OpenBSC.
&lt;/p&gt;
&lt;p&gt;
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 :(
&lt;/p&gt;
&lt;p&gt;
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.
&lt;/p&gt;</description><category>tetra</category><guid>https://laforge.gnumonks.org/blog/20110531-starting_to_play_with_motorola_dimetra/</guid><pubDate>Mon, 30 May 2011 19:00:00 GMT</pubDate></item><item><title>Public release of Osmocom TETRA code</title><link>https://laforge.gnumonks.org/blog/20110122-osmocom_tetra_public/</link><dc:creator>Harald Welte</dc:creator><description>&lt;p&gt;
Today I have publicly released the TETRA receiver code that I've &lt;a href="http://laforge.gnumonks.org/weblog/2011/01/08/#20110108-osmocom_tetra"&gt;started
to work on earlier this year&lt;/a&gt;.  The gnuradio-based demodulator, PHY and
lower MAC code as well as some README file is available from the new &lt;a href="http://tetra.osmocom.org/"&gt;http://tetra.osmocom.org/&lt;/a&gt; website.
&lt;/p&gt;
&lt;p&gt;
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).
&lt;/p&gt;
&lt;p&gt;
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.
&lt;/p&gt;&lt;p&gt;
There is some early code that should eventually enable us to run a base-station
side transmit implementation, but it's not working yet. 
&lt;/p&gt;</description><category>tetra</category><guid>https://laforge.gnumonks.org/blog/20110122-osmocom_tetra_public/</guid><pubDate>Fri, 21 Jan 2011 19:00:00 GMT</pubDate></item><item><title>Working on a Free Software TETRA implementation</title><link>https://laforge.gnumonks.org/blog/20110108-osmocom_tetra/</link><dc:creator>Harald Welte</dc:creator><description>&lt;p&gt;
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 &lt;a href="http://en.wikipedia.org/wiki/TETRA"&gt;TETRA&lt;/a&gt;, specifically the PHY and
lower MAC but also parts of the upper MAC level.
&lt;/p&gt;
&lt;p&gt;
The primary idea here is to produce something similar to what &lt;a href="http://airprobe.org/"&gt;airprobe&lt;/a&gt; is for GSM: An air-interface protocol
analyzer that can demodulate/decode/demultiplex information received from a
TETRA base station.
&lt;/p&gt;
&lt;p&gt;
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.
&lt;/p&gt;
&lt;p&gt;
So we could concentrate on the PHY and lower MAC layers, i.e. implementing stuff
like
&lt;/p&gt;&lt;ul&gt;correlator for the various training sequences to achieve frame sync
&lt;li&gt;de-scrambler, de-interleaver, convolutional decoder, CRC, Reed-Muller decode&lt;/li&gt;
&lt;li&gt;Implementing the TDMA multiplex, reading the BSCH (like SCH in GSM)&lt;/li&gt;
&lt;li&gt;Decoding the MAC-layer PDUs like ACCESS-ASSIGN, SYNC, SYSINFO, RESOURCE&lt;/li&gt;
&lt;li&gt;Peeking into the higher layers like MM&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;
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.
&lt;/p&gt;
&lt;p&gt;
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).
&lt;/p&gt;
&lt;p&gt;
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.
&lt;/p&gt;
&lt;p&gt;
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.
&lt;/p&gt;</description><category>tetra</category><guid>https://laforge.gnumonks.org/blog/20110108-osmocom_tetra/</guid><pubDate>Fri, 07 Jan 2011 19:00:00 GMT</pubDate></item></channel></rss>