Hi laf0rge,
wireshark has more strict compile settings and found this:
#define GSMTAP_TETRA_AACH 0x02
#define GSMTAP_TETRA_AACH 0x03
I would remove the second occurrence and renumber the other members? Or should
I remove the first one and go with the value of 0x03?
z.
> [snip] ... but wondered if
> anyone had worked on the GR porting of the code. I assume, that is not the
> case.
No that I know of.
What would be the interest exactly ?
I mean GR is great for signal processing but once you got the bits,
the rest is IMHO way better handled outside gnuradio itself. All the
phy/mac levels are no trivial and will need state processing and such
... not something I really see in GR.
Using fifo on the filesystem you can pipe directly/live the flow of
info from GR outpout to the tetra-rx input.
Cheers,
Sylvain
BTW, you forgot to CC the list in your reply. (I assume it was your
intent because of the "with everyone here" comment at the end of your
mail).
Hello,
My main activity here would be lurking, but i certainly like to make a
contribution in the future. I've programmed in ASM on several platforms,
C, C++, and nowadays do all of the work in Java.
Most java implementations suffer from non-deterministic timing issues,
so i wonder, would there be any application for java as a platform in
the (osmocom) radio protocols?
I've build a hearing loss simulator in java, which is a streaming audio
pipeline, so java is not completely useless in applications with strict
timing relations. I believe the latency couldn't exceed 50mS which is
huge in TDM radio protocols, but in the upper layers with a lot of
complex data shuffling it might be usefull? Any ideas?
Gr. Sim
Hi,
after a remark by Harald about bitwise CRC calculation and seeing the
crc_simple code in lower_mac, I've thought about how to implement
"optimized"
routines using a table-based approach operating on our pbit_t/ubit_t
arrays in libosmocore/master.
People on IRC consider it more tetra-specific though, so I'm posting
this here for advice on where to put it.
The usage is to first create the table via
osmo_crc16_table_init(*table,polynomial)
and then to encode bits using
osmo_crc16() - default, operates on pbit_t[]
osmo_crc16_ubits() - operate on ubit_t[]
osmo_crc16_ubit() - one single bit, takes polynomial as first arg!
osmo_crc16_pbit() - operate on 1-7 bits in a pbit_t
It passes the crc_test ported to the new routines.
$ ./crc_test # osmo-tetra
The CRC is now: 4129/0x1021
The CRC is now: 4129/0x1021
The CRC is now: 61905/0xf1d1
The CRC is now: 65534/0xfffe
The CRC is now: 57073/0xdef1
The CRC is now: 7439/0x1d0f
Decoded successfully.
$ tests/crc/crc_test # this patch, in libosmocore
First elements of table for CRC with poly 0x1021:
0000 1021 2042 3063 4084 50a5 60c6 70e7 8108 9129 a14a b16b c18c d1ad
e1ce f1ef
The CRC is now: 4129/0x1021
The CRC is now: 4129/0x1021
The CRC is now: 61905/0xf1d1
The CRC is now: 65534/0xfffe
packed bits: 10 b0 be 00 83 07 d3 3d ef 10
The CRC is now: 57073/0xdef1
...packed: 57073/0xdef1
packed bits: 10 b0 be 00 83 07 d3 3d ef 10
The CRC is now: 7439/0x1d0f
Decoded successfully.
Chris
Hi all,
OsmocomBB and OsmocomTETRA share the same list of accounts, so if you have
an account on OsmocomBB, you can use the same credentials to write to the
new http://tetra.osmocom.org/ website.
Regards,
--
- 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)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi everybody,
I haven written (and ripped :-) a PI/4 DQPSK modulator, which should be
able to transmit TETRA bursts. For compilation have a look into the
Makefile.
It reads data from stdin and expects one byte for every symbol. The
value should be 0, 1, 2 or 3. 0xff results in silence.
The symbol rate is 250000/14 on USRP1 which is 17857 symbols/s. A more
or less simple demodulator should work without problems (perhaps with
more selfnoise), but a MLSE based RX will most probably not work.
For more "professional" uses we will need an accurate resampler, but I
will throw that one in as time comes :-)
Have fun,
Christian
- --
- ---------------------------------------------------
| maintech # Dipl. Inf (FH) Christian Daniel |
| GmbH ### Otto-Hahn-Str. 15 · D-97204 Höchberg |
- ---------------------------------------------------
| AG Würzburg, HRB 8790 Tax-ID DE242279645 |
- ---------------------------------------------------
| http://www.maintech.de cd(a)maintech.de |
- ---------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNLjLHAAoJEHkgzUIsAWriO2UH/ivlinNO6L/Y74pe8Bf3eKhF
K9bgUKAbowa/AHlKRzJlUU0AvjmAgkDRZOJ9lDqZUyBW5NnoJkxTvRjfq0Deytad
MCwb2jLkN37MLCWju/3io60672G5uMKX4J7N3zDkrLgZKnKesaVJY+NgiLLTkMY1
uh6/ZJ7Fg/snMPXfffMiNo+vG+G9pIMYmzRp3rPaqYL4sSQjyoUWpOoNruDFA+uu
wYf/R1rGo5wWbKdTKAbRCHt3FmTyn61BEtngcyrc30XOZppCjH2oboMpAYmUyU88
bI6pnptMHixoi7skGH0lfD5Fqb5PlUqYOqAaq83LUYmbcv5v7NV51BrikBfk1l0=
=7aiy
-----END PGP SIGNATURE-----
It seems somebody has already done it:
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5355672
I have contacted the authors of the paper and asked them if they have ever
released the source code or send me a copy of it. This would definitely
speed things up.
I really have no intention (or time) to write a full wireshark dissector for
the entire protocol stack. Too many other interesting projects :/
So lets hope they will release their code...
--
- 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!
I have uploaded a number of tetra data files to a password-protected rsync
repository:
you can access it using "rsync -azv tetra@osmocom.org::tetra/data ."
using the password "Xo4ried5" (please use -z option to compress the
transmission, as the files in the repo are uncompressed)
*.cfile raw complex samples recordings, need tetra_demod.py
*.float output files of demodulator, 1 float per symbol
*.bits output of float_to_bits (1 bit-per-byte format)
If you want to contribute traces, feel free to upload them, preferrably
both the cfile and the bits... there's no need for the .float files.
please create one new directory for every trace or class of traces you
upload. A small README file is appreciated in order to explain what those
traces are.
Due to the sensitive nature of the data, pleaes keep access to the repository
private. Thanks for your understanding.
btw: The entire project is not released yet. While I have made it public
that we're working on TETRA, I would not want the current code released -
last but not least since we're using a viterbi implementation that is under
unclear license terms as it is derived from the ACELP refernence codec.
Once somebody has replaced the viterbi with a new implementation and we have
cleaned up the code, I don't really see why we would not release it publicly.
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)
Hi all,
we're making great progress! Today I've added support for the SCH/F dedicated
signalling channel (where blocks 1+2 of each burst are combined). This,
plus fixing some other bugs now results in CRC=OK on all of the frames in my
captures, i.e. we can assume that the PHY and lower MAC layers are working
as expected now.
I've also added code to display MAC-ACCESS_ASSIGN, MAC-RESOURCE and some
other PDUs. We can now see that there are unencrypted MM LOCATION UPDATE
ACCEPT messages even on the BDBOS network, and in some commercial TETRA
networks we have already discovered no encryption being used.
The next step would probably be to use the ACELP reference codec and
use that for all TCH frames. Luckily, the 'Downlink usage' field of the ACCH
(ACCESS-ASSIGN) even tells us if a frame is SCH/F (assigned control)
or TCH (traffic).
However, after more than a week of intense TETRA related hacking, I really have
to get to some more serious (paid) work now, and I don't expect to find much
time again before the end of the month.
So feel free to improve the code as you see fit. I'll be watching your
progress.
Zecke is currently looking into integrating the float_to_bits conversion
as a gnuradio functional block, together with improving it, i.e.
* dynamically calculate the 'offset' that is currently hardcoded at 0.3f
* generate soft-bits as int8_t, i.e. +127 == very likely to be a 1,
-127 == very likely to be a 0
Other TODO items:
* Make sure the de-scrambling will work with the int8_t soft-bits
* Actually check if the RM30,14 code produces a correct checksum for AACH
* remove lots of superfluous memcpy's all over the place
* introduce logging levels/subsystems, use libosmocore/logging
* optimize the viterbi decoder (and its primitives)
* modify the viterbi to directly use arrays of uint8_t so we can seave
the copying from 8->16 and back from 16->8
* dump the TCH/F speech frames and try to play them back using the reference
ACELP codec (as indicated above)
If you work on something, simply let the mailing list know so we can avoid
duplicate work.
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)
Hi all,
in TETRA, the only part of the signal that is transmitted with a well-known
scrambling code is the BSCH in the SB1 (first half of the downlink SYNC block).
We can finally decode that since yesterday and get proper MCC/MNC and TDMA time
information.
The colour code + MNC + MCC is used as the scrambling sequence for all other
messages of the cell, specifically also the BNCH containing the SYSINFO
messages.
I've recently added code to indicate when a BNCH block is to follow, but the
de-scrambled type-2 bits do not look plausible at all.
So there's most likely still some problem with the de-scrambling. The
de-interleaving, de-puncturing and viterbi decoder are the same code (even
with different parameters), so I don't think that there are likely problems
caused by them.
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)
