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)
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)
(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
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)
