Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I5050285e75cf120407a1d883e99b3c4bcae8ffd7
When switching the l2 structures passes to test_pdtch() to be constant,
it was noted that output of the test changes. This happens because same
array is tested several times with different length, incrementing each
time. Since the test was modifying the input array directly, it means
each new run of test_pdtch() the array was further modified.
Upon constifying the structures, we copy the array and hence only modify
the required bits each time.
Change-Id: Iffd0ca3669eb8d0d2e80d754fc8acbf72f1bebe8
According to 3GPP TS 44.004, figure 7.4a.b, the format of 11-bit
RACH uplink / Uplink access burst block is as defined follows:
<---------------------------------------------------
8 7 6 5 4 3 2 1
+--------------------------------------------------+
| 11 bit RACH uplink / Uplink access burst block | OCT1
+--------------------------------------------------+
| | OCT2
+-------------------+
As was (correctly) assumed in [1], the bit ordering in 11-bit RACH
coding functions is wrong. The problem is that neither of generic
functions from bit16gen.h can be used to load / store the RA11
value (regardless of the endianness), because they assume that
the payload is 16 bit long.
With this patch applied, RA11 values from [1] look correct:
< EGPRS Packet channel request message content > ::=
< Signalling : 110011 < RandomBits : 00111 > > |
< Signalling : 110011 < RandomBits : 00110 > > |
< Signalling : 110011 < RandomBits : 01111 > > |
< Signalling : 110011 < RandomBits : 01100 > > |
< Signalling : 110011 < RandomBits : 00111 > > |
< Signalling : 110011 < RandomBits : 10110 > > ;
[1] Id80e471d252b9416217b56f4c8c0a8f5f1289fee
Change-Id: I43d30611dd69f77f2b3b46f4b56056a8891d3c24
Related: OS#1548
This change adds several soft-bit (-127 .. 127) sequences containing
EGPRS Packet Channel Request message (11-bit, payload only) sent by
an EGPRS capable phone, and captured on the BTS/PCU side using a
tool from the TRX Toolkit - trx_sniff.py.
As can be seen from the test output, none of decoded RA11 values
looks like a valid EGPRS Packet Channel Request message (see
table 11.2.5a.2 of 3GPP TS 44.060). All test sequences contain
the same message with several random bits:
< EGPRS Packet channel request message content > ::=
< Signalling : 110011 < RandomBits : bit (5) > >;
since the phone was trying to perform Attach Request. It seems
the bit order of decoded messages is somehow wrong.
Change-Id: Id80e471d252b9416217b56f4c8c0a8f5f1289fee
Related: OS#1548
We don't really need additional 1.4M of debug output, given that
we test every possible 8-bit and 11-bit RA value. It's enough
to print error message if the resulting value does not match.
Otherwise it's hard to read the expected output without commenting
the related log statements out. Note that it's still possible to
re-enable verbose debug output by defining DEBUG.
Change-Id: I0d5ed90cb0a2b3007d665520a73b0fa0b86a4099
Check return value of RACH encode/decode functions and fail test on
unexpected results.
Change-Id: I41bfa808e3c064a11152e7ce8ee77a01d38a0744
Related: OS#1854
For all other decode operations we report the BER, but not for the
RACH. This results in osmo-bts-trx not being able to report BER
to the higher layers, which is possible on other BTS backends.
Let's close this gap by introducing gsm0503_rach_ext_decode_ber()
and gsm0503_rach_decode_ber() with the usual n_errors / n_bits_total
arguments.
Change-Id: I2b1926a37bde860dcfeb0d613eb55a71271928c5
inline keyword is a hint for the compiler to inline the function, but
it's not mandatory. If no static or extern is specified, the definition
is only visible in the current unit but the identifier still has
external linkage.
When running with -O0 it seems the compiler (gcc 7.2.1) decides to use
the external linkage but at the same time it seems it's not generating
the function symbol. Fix it by explicitly stating that we want to use
static linking for this function.
coding/coding_test.o: In function `test_xcch':
libosmocore/tests/coding/coding_test.c:86: undefined reference to `dump_ubits'
libosmocore/tests/coding/coding_test.c:87: undefined reference to `dump_sbits'
Change-Id: I18018adec05ce1c2ddbca38653311d74c7454ce8
* remove duplicate code: use function from libosmocore
* use utility function to dump ubits
* reformat for easier reading
* link against libosmocore
Change-Id: I8c31b0954176a2c53305936a025c92a793b6d9b6
There are some projects, such as GR-GSM and OsmocomBB, which would
benefit from using one shared implementation of GSM 05.03 code. So,
this commit introduces a new sub-library called libosmocoding, which
(for now) provides GSM, GPRS and EDGE transcoding routines, migrated
from OsmoBTS.
The original GSM 05.03 code from OsmoBTS was relicensed under
GPLv2-or-later with permission of copyright holders (Andreas Eversberg,
Alexander Chemeris and Tom Tsou).
The following data types are currently supported:
- xCCH
- PDTCH (CS 1-4 and MCS 1-9)
- TCH/FR
- TCH/HR
- TCH/AFS
- RCH/AHS
- RACH
- SCH
Change-Id: I0c3256b87686d878e4e716d12393cad5924fdfa1