Strange offset in float_to_bits.c

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/.

Sylvain Munaut 246tnt at gmail.com
Sun Nov 11 11:56:11 UTC 2012


Hi,

> diff --git a/src/float_to_bits.c b/src/float_to_bits.c
> index 08fad54..4547ffe 100644
> --- a/src/float_to_bits.c
> +++ b/src/float_to_bits.c
> @@ -113,7 +113,7 @@ int main(int argc, char **argv)
>                         exit(1);
>                 } else if (rc == 0)
>                         break;
> -               rc = process_sym_fl(0.3f, fl);
> +               rc = process_sym_fl(0.0f, fl);
>                 sym_int2bits(rc, bits);
>                 //printf("%2d %1u %1u  %f\n", rc, bits[0], bits[1], fl);
>                 if (opt_verbose)

Applied.


> In other news, I have gotten my own GPU (openCL) assisted demodulator
> working, I am thinking about decoding multiple carriers concurrently
> with this code, but I think the gnu_radio demodulator has an edge with
> regards to BER, especially if the offset is set to 0.0f :-)

In my experience with OsmoGMR, the actual demod isn't all that CPU intensive.
The channelization and resampling to a multiple of symbol rate is
what's expensive.

A few things I don't like in the current demod :
 - Don't use the FCCH to properly lock to carrier
 - Only works for continuous carrier .. can't possibly use it for DMO
or even uplink I think.

If yours could lift those limitation that'd be great :p


Cheers,

    Sylvain




More information about the tetra mailing list