tetra January 2011

tetra@lists.osmocom.org

9 participants
14 discussions

[Tetra] Finally: Viterbi Decoding now working
by Harald Welte 06 Jan '11

06 Jan '11

Hi! As it turns out, my fibonacci and galois form of the scrambler do not generate the same bit pattern. I originally tested and verified they produce identical results - but apparently they don't. We now have successful decoding of all the SYNC bursts in the sample capture, as you can see from the attachment. Whenever there's a gap in the decoded FN, this is due to a NORMAL burst being transmitted instead. The normal burst does not carry the timeslot/framenumber information and we need to count ourselves in the gaps in between. I am already computing the scrambling sequence init value from the MCC/MNC/CC that we receive in the SYNC burst, and de-scramble the BBK and BLK2 of the SYNC burst. However, the viterbi has not been adapted yet to the encoding of those bursts (it's not much). I'll update you once we can decode more... -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

[Tetra] Viterbi
by Harald Welte 05 Jan '11

05 Jan '11

Hi all, I managed to modify the viterbi code from C-CODE/SUB_DC.C in the ZIP file from the 300 395-2 spec. It implements a different mother code (i.e. the voice code which is a rate 1/3 code, whereas signalling uses a rate 1/4 mother code). So far I am not really getting much out of it. Sometimes some parts of the bursts make sense (like the 0/1/2/3/0/1/2/3/... sequence of frame numbers), but stuff like MCC/MNC gives completely bogus values. I'm too tired now to continue, will look at it again tomorrow. But I think we're close. I will commit the code as soon as something is working at all. My next attempt is to try to run this viterbi against bursts that I generate using my code. If that works, then we must be doing something wrong in the lower steps (de-interleaving, de-puncturing). Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Re: [Tetra] TETRA Demodulation
by Harald Welte 05 Jan '11

05 Jan '11

(we have a mailinglist and we should use it... and write in english for sylvain's benefit) On Tue, Jan 04, 2011 at 08:16:12PM +0000, Dieter Spaar wrote: > Kleine Korrektur: > > Das Muster im vorherigen Bild ist natuerlich drei Bursts mit > "Frequency Correction Field" und dann einer ohne, das koennte > eventuell etwas mit dem Frame bestehend aus vier Slots zu > tun haben. The tdma multiplex of TETRA is unfortunately much more complicated than in GSM. I only really understood it earlier today while reading a textbook, from the specs it is very difficult to understand. The Frequency Correction Field is only present in the sync bursts (SB), which in turn are only (required to be) sent in Frame number 18 , but not on every multiframe. Interestingly, the SB is also present in _every_ timeslot, but not in every Frame 18 of every TS. The formula for the Timeslot Number is "4-(MN+1)mod4", it is indicated in Table 9.25 in Chapter 9.5.1

1 1

[Tetra] code for the tetra MAC layer
by Harald Welte 05 Jan '11

05 Jan '11

Hi, I've started to implement the TETRA TMO MAC layer, i.e. the part that takes MAC blocks from higher layers and applies CRC, FEC, interleaving and scrambling before finally handing the bits to the DQPSK-modulator. The code can now generate a (hopefully valid) to-be-modulated bit pattern for a 'continuous downlink synchronization burst', i.e. what corresponds to the 'SCH+FCCH+BCCH' in GSM. You can find the code (including a small README) at: gitosis@git.osmocom.org:tetra-misc.git in the 'src' directory. If you don't yet have git access, feel free to mail me your sshv2 key. What's missing: * CRC16-CCITT to be computed over odd number of bits like 60 or 124 (all common implementations assume you encode integral # of bytes) [zecke] * decoding: * decoder for the RM(30,14) code [zecke] * soft-input/soft-decision viterbi for the RCPC code * synchronizer, able to detect synchro and normal training sequence [laforge] Once those tasks are completed, we can not only generate simulated burst bit patterns, but also decode them - which should be a good start for the time when Hopscotch' demodulator will spit out some real received bitstream. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tetra January 2011