gsmtap_sendmsg() may return an error, and we need to free the msg.
Likewise, if we don't even call gsmtap_sendmsg, the msgb must be free'd.
Change-Id: I9b018165982996cafb2fd17e89646177462002c6
Depends: libosmocore I106b09f2a49bf24ce0e8d11fd4d4ee93e9cafdf5
Related: OS#5329
Finding synchronization sequence eats several times more CPU time than the
actual decoding. This is especially pronounced on channels with lots of errors
(where synchronization is lost frequently) and channels that are most of the
time empty (such as uplink channels, support for which is coming in following
patches).
Profiling shows that all the time is spent in memcmp calls.
A complicated and efficient algorithm, e.g. Aho-Corasick, turned out to be
not necessary. Compilers can optimize even a simple bit filter into fast code.
This provides only a modest (~25 %) performance gain, more fixes are coming.
Fixes: OS#1897
Change-Id: I3b90cc70c2ec67253a0fd2f00c6957a80971c38b
When a bad frame is received, the scrambling should not be updated,
because setting scrambling to wrong values will completely break further
decoding (until another SYNC frame is received).
Change-Id: I5e88b52fcbb98532d7ab6ca85e4f956589a595ab
Running tetra-rx on a capture with lots of bit errors is not
deterministic. Investigation with Valgrind shows various errors about
uninitialised values in libosmocore's viterbi decoder.
The cause appears to lie in @lower_mac/viterbi.c@. The only function
there allocates space for 864 symbols and then fills it with the symbols
received. However, sym_count is sometimes less than 864, leaving the
rest of the array uninitialized.
Initializing it with @int8_t vit_inp[864*4] = {0};@ fixes the problem.
Change-Id: Ib745c387e21fb81afef69efcf7e46d5d49331c8f
Fixes: OS#3410
Since the gerrit build jobs no longer contain git clean workspace config (for
good reasons), it is important to use osmo-clean-workspace.sh. To make it work
best, this jenkins.sh should follow the same structure as most others do.
Change-Id: I3eca957c52b2c018e4c784b29330a0d06c4e3595
keeps some of the device specific scripts in addition to the (supposedly
generic) osmosdr-tetra_demod_fft.py
Also, update the README file to corresponding changes.
Change-Id: Icae93bb9a6a7219e14931fb6e04a4c6fffa0779d
osmosdr-tetra_demod_fft.py: Commandline switch -F for frequency offset
osmosdr-tetra_demod_fft.py: More verbose fine-tuning messages
Conflicts:
src/demod/python/osmosdr-tetra_demod_fft.py
This is a symptom of frequency offset and it's the demodulator job to
correct this ...
Thanks to Frank A. Stevenson for noticing this legacy hack
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Call it with
src$ ./demod/python/rtlsdr-tetra_demod_fft.py -s 1.8e6 -f 394.6e6 -g -1 -o /dev/stdout | ./float_to_bits /dev/stdin /dev/stdout | ./tetra-rx /dev/stdin
- Adjust the center frequency (-f) and gain (-g) according to your needs.
- Use left click in Full Spectrum window to roughly select a TETRA carrier.
- Use left click to fine tune the carrier by clicking on the left or right side of the spectrum.
It's more stable ... here we just need a flexible length, which we
can 'fake' by creating a local copy of the 'code' definition on the
stack.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Harald Welte
Martin Hauke
Jan Hrach
Dieter Spaar
Dimitri Stolnikov
Sylvain Munaut
Steve Markgraf
Alexander Huemer