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.