small patch for float_to_bits and tetra-rx

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/tetra@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Wed Aug 17 06:41:58 UTC 2011


On Tue, Aug 16, 2011 at 01:11:15PM +0200, ciaby wrote:
> On Tue, 2011-08-16 at 08:52 +0200, Holger Hans Peter Freyther wrote:
> > any numbers for that?
> I don't have any hard numbers for that, but consider that before
> float_to_bits was using 100% cpu on a atom core and was decoding 2-3
> times slower than real-time. Now, it doesn't even pop up in top (less
> than 1%) :-D
> 
> > yes, I think that is still the plan. I once started trying to do this in
> > python but the GNU Radio bindings only allow to control modules, not really do
> > processing in python.
> Sorry, i didn't explain myself properly... I was planning to write it as
> a C module. Have a look at the gr_float_to_uchar module, but instead of
> returning a single uchar, it should return uchar[2], where each item of
> the array contains 00 or 01. Alternatively, we can pack the two bits
> into a single uchar and change how tetra-rx reads it. The second
> approach looks cleaner, but it's a bit more invasive.. (it breaks
> compatibility with all the previously made dumps).

You will definitely neeed one uint8_t per bit.  The reason for that is
simple: Our viterbi is soft-input.  So a correct implementation would
convert the float values to signed 8bit values with the range -127 ...  127

This is clearly indicated in the source code.

> I have one last question for Harald: which parts of the TETRA protocol
> hasn't been implemented yet? I would really to contribute the remaining
> bits, and maybe finish the rx part. Low-cost open-source TETRA handset
> anyone? :-)

So far, we only have _interpretation_ of some of the protocol levels,
mostly the lower ones (physical, lower mac, upper mac).  There is no
code for any protocol logic (state machines, etc.) and no code for
generating anything beyond very simple physical layer frames.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)




More information about the tetra mailing list