This patch just convert read/write into fread/write, which are buffered and a bit faster... (actually, quite a lot faster) :-) It works, have been tested at the CCC, and allow osmo-tetra to run in real-time on a crappy Atom CPU. Btw, if you like to run the entire decoding chain in real-time, just do this (assuming that you use the funcube dongle): cd src/demod/python mkfifo out.float mkfifo out.bit ./fcdp-tetra_demod.py -D hw:1,0 -c <offset> -o out.float //(normally the fcdp runs on the second alsa port, change it to the appriopriate one). ../../float-to-bits out.float out.bit ../../tetra-rx out.bit I'm still not 100% sure about the speech decoder, but i don't have any good sniffer dump with speech traffic to test it, i will let you know in a week or so... Happy hacking! :-)
Ciaby
P.S. I have a plan to convert the float-to-bits code into a proper GNU Radio module, shouldn't be too difficult, is there any interest into continuing this project? As I understood Harald is quite busy with other stuff (and rightfully so), but I think that we should move forward. Volunteers? ;-)
On 8/16/11 1:43 AM, ciaby wrote:
I'm still not 100% sure about the speech decoder, but i don't have any good sniffer dump with speech traffic to test it, i will let you know in a week or so... Happy hacking! :-)
I have an USRP1 with RFX900, and i'm going to buy the daughterboard card to receive TETRA frequencies. Does the same approach could work also for USRP1 based receiver?
I'd like to do on-field-testing for realtime-voice-decoding, it provide nice demonstration apps!
-naif
On Tue, 2011-08-16 at 08:50 +0200, Fabio Pietrosanti (naif) wrote:
I have an USRP1 with RFX900, and i'm going to buy the daughterboard card to receive TETRA frequencies. Does the same approach could work also for USRP1 based receiver?
Yes, it should work also for the USRP1. You need to change the .py script used, of course ;)
I'd like to do on-field-testing for realtime-voice-decoding, it provide nice demonstration apps!
Indeed :D
Ciaby
On 08/16/2011 01:43 AM, ciaby wrote:
Hi,
This patch just convert read/write into fread/write, which are buffered and a bit faster... (actually, quite a lot faster) :-)
any numbers for that?
P.S. I have a plan to convert the float-to-bits code into a proper GNU Radio module, shouldn't be too difficult, is there any interest into continuing this project?
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.
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). 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? :-) Cheers!
Ciaby
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.
-
ciaby -
Fabio Pietrosanti (naif) -
Harald Welte -
Holger Hans Peter Freyther