15 Aug
2011
15 Aug
'11
7:43 p.m.
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? ;-)
16 Aug
16 Aug
2:50 a.m.
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
7:04 a.m.
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
2:52 a.m.
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.
7:11 a.m.
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
17 Aug
17 Aug
2:41 a.m.
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:
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.
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? :-)
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
5085
days inactive
5087
days old
5 comments
4 participants
participants (4)
-
ciaby -
Fabio Pietrosanti (naif) -
Harald Welte -
Holger Hans Peter Freyther