Tetra decoding

[ET-NL]

Telive 1.8 works fine, only the Call Identifiers are not beeing cleared at the end of the conversation.
(See screenshot)

ET

 

[sm0vec]

thanks for the bug report. i added a small change which will hopefully fix the crash. please tell me if it solves the problem

i didn't get the crash on my system, but the fixed code is obviously bad.

Thanks, yes this solved the crash.

The call identifier implementations doesn't seems to work so well, only a few calls get this in Telive and they seems to stay on the screen. I'll run a test for some hours on a busy system.

I'll especially look the decode of D-CONNECT and the SSI2.

This often contains quite good info about the GSSI (in some systems it's needed to decode this to even get the GSSI, but normally the GSSI appears in other messages too). Looking at the raw bits it's always easy to spot the GSSI, but what's received doesn't match the protocol as described in EN300392-2. For example, what should be the o_bit is almost always 0 for me, while data continues after (which it shouldn't according to the protocol). I've wondered if this was some error occurring quite early in the parsing, but I've not been able to find it.

But by pure bit pattern comparison (not longer caring about what the protocol say), I've been able to make a pretty good decoding of the GSSI in D-Connect, but it still get it wrong in some cases so it would be good to once for all make a proper implementation.

 

[sq5bpf]

Telive 1.8 works fine,

thanks for the report!

do you get more SSI info for calls in the new version?

only the Call Identifiers are not beeing cleared at the end of the conversation.

i will release a fix either soon, or in the next version. fortunately this is only a minor annoyance

 

[ET-NL]

I don't think I see a lot more ISSI's.
With the previous version of Telive I already saw one GSSI and one or two ISSI for every conversation.

There's only one 'strange' user in this network. Sometimes I get only one ISSI (no GSSI or other ISSI) and I only here one site of the conversation. The ISSI I see is an office ISSI no mobile user. This lonely ISSI sometimes appears on identifier 0:.

In the meantime my screen is filled with abandoned Call Identifiers ;-)
The highst number now is 7013 do they rollover to 0 when they reach 9999 or do the keep counting ?


ET

 

[sq5bpf]

There's only one 'strange' user in this network. Sometimes I get only one ISSI (no GSSI or other ISSI) and I only here one site of the conversation. The ISSI I see is an office ISSI no mobile user. This lonely ISSI sometimes appears on identifier 0:.

this is a duplex call

In the meantime my screen is filled with abandoned Call Identifiers ;-)
The highst number now is 7013 do they rollover to 0 when they reach 9999 or do the keep counting ?

they can go higher. the identifier is a 14 bit value, so the range is 0-16383

i've pushed a fix for the abandoned callid problem. btw you won't get call ids for all calls

and the receiver number shown is the one for the control channel. this value is mostly for mu debugging right now

 

[ET-NL]

Thanks for the answer.

With a duplex call you mean a private call between the office and the mobile user?
I will update Telive and test.

ET

 

[ET-NL]

Updated Telive.
Screen is cleared as before, but it looks like i see less CID's now. The network is less crowded at the moment (evening overhere) maybe thats the reason ? Will have a look again at daytime.

ET

 

[sq5bpf]

Screen is cleared as before, but it looks like i see less CID's now. The network is less crowded at the moment (evening overhere) maybe thats the reason ? Will have a look again at daytime.

these CIDs can be lost sometimes (for example when a usage identifier doesn't have traffic for some time).

the CID support is just an experiment resulting from thinking about the next major version, and i thought it might be interesting also in this version.

 

[drmaligno]

Hello I recently had to reinstall my team and I have put debian 8 Jessie and the latest version of osmocore - telive , now I have micro outages in decoding tetra . They are not important but annoying . It's like you need a more powerful computer now ,.
How I can get install an older version of the software?

 

[sq5bpf]

Hello I recently had to reinstall my team and I have put debian 8 Jessie and the latest version of osmocore - telive , now I have micro outages in decoding tetra . They are not important but annoying . It's like you need a more powerful computer now ,.

what distribution did you use bedore, what gnuradio version, what version of telive and osmo-tetra-sq5bpf?

are you sure you have too much cpu load? (what does top say?)

How I can get install an older version of the software?

all of the software is on github, so you can check out whatever version you need. try to use osmo-tetra-sq5bpf from around the same time as telive

 

[drmaligno]

Hello,
thank for your quickly answer,

i install all from the new script 15 days before, gnuradio 3.7. debian jessie


I have another pc with older instalation and work fine, the same frec and the same antenna.

Before it was more fluid, now it's like there are some signs that the receiver1 1 detected as an error and gives it annoying jumps.
.
I try to show you a video in the nex day.

 

[sq5bpf]

I have another pc with older instalation and work fine, the same frec and the same antenna.

ok, the new installation is debian 8 (32 or 64 bit?) newest telive and osmo-tetra-sq5bpf and gnuradio 3.7 from the debian packages, all installed via the install_telive.sh script. what hardware is this (memory, cpu, is this a virtual machine?)

for the older installation, which was working fine, please give the operating system, which version of telive and osmo-tetra-sq5bpf (it is enough to give me the date the files were downloaded), which gnuradio version and how was it installed (from distribution packages? or maybe from some other packages? or maybe compiled via the build-gnuradio sript, or some other), what hardware is this (memory, cpu, is this a virtual machine?)

Before it was more fluid, now it's like there are some signs that the receiver1 1 detected as an error and gives it annoying jumps.

please send all error messages from telive, receiver1 and also from gnuradio-companion (especially if you see OOOO...)

 

[drmaligno]

Ok, I think the difference is the AFC , AFC when the message shows is cut the voice.

### AFC: -0.332740

PC1 - New installation (with AFC)
Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz
4GB RAM
i686
Debian 8

PC2 - Old installation (without AFC)
Intel Core 2 T5500 @ 1.66Ghz
2GB RAM
i686
Debian 7


Can i turn off AFC ???

 

[sq5bpf]

Ok, I think the difference is the AFC , AFC when the message shows is cut the voice.
Can i turn off AFC ???

sure, AFC is turned on by the -a switch to tetra-rx (this is documented in the receiver1 script comments)

just edit the receiver1 script, and remove -a on the last line

but i doubt that it is afc.

could you please answer my question, and tell me what versions of software you had on the old computer? especially the gnuradio version, the telive version and osmo-tetra-sq5bpf version

i think this maybe related to gnuradio (the flowgraphs for 3.6 may be better than the ones for 3.7)

 

[drmaligno]

Oh sorry,

old instalation have gnuradio 3.6
osmo-tetra-sq5bpf is feb2015
telive is 1.5

I do not now how to get the version of osmo-tetra-sq5bpf

I probe gnuradio 3.6 with new install and i have the same problem.

 

[sq5bpf]

I probe gnuradio 3.6 with new install and i have the same problem.

you can see the commits here:

https://github.com/sq5bpf/osmo-tetra-sq5bpf/commits/master

for example commit 9126159 is from february 28 2015, to get it and compile, in the osmo-tetra-sq5bpf/src directory do this:

git checkout 9126159
make clean
make


but before you do this, see if the internal float_to_bits implementation is causing the problem. in receiver1 uncomment the line using float_to_bits, and comment the next one, so the end of the script should read:

demod/${GR_DIR}/simdemod2.py -o /dev/stdout -i $FIFO | ./float_to_bits /dev/stdin /dev/stdout | ./tetra-rx /dev/stdin

#tetra-rx args: -a turns on pseudo-afc , -i uses an internal float_t_bits
#if you have problems with the receiver, then try to remove -a
#demod/${GR_DIR}/simdemod2.py -o /dev/stdout -i $FIFO | ./tetra-rx -a -i /dev/stdin



btw do other people see this problem?

 

[drmaligno]

but before you do this, see if the internal float_to_bits implementation is causing the problem. in receiver1 uncomment the line using float_to_bits, and comment the next one, so the end of the script should read:

demod/${GR_DIR}/simdemod2.py -o /dev/stdout -i $FIFO | ./float_to_bits /dev/stdin /dev/stdout | ./tetra-rx /dev/stdin

#tetra-rx args: -a turns on pseudo-afc , -i uses an internal float_t_bits
#if you have problems with the receiver, then try to remove -a
#demod/${GR_DIR}/simdemod2.py -o /dev/stdout -i $FIFO | ./tetra-rx -a -i /dev/stdin

Yes more better with this mod, now in both PC is similar,

thank you very much.

 

[sq5bpf]

Yes more better with this mod, now in both PC is similar,

thank you very much.

ok, thanks for the comparison.

could you also try these versions and compare the results (comment out all other lines with tetra-rx):


#version with AFC in float to bits
demod/${GR_DIR}/simdemod2.py -o /dev/stdout -i $FIFO | ./float_to_bits -a /dev/stdin /dev/stdout | ./tetra-rx /dev/stdin


#version with AFC disabled in tetra-rx and internal float-to-bits (i think you may have already tried this)
demod/${GR_DIR}/simdemod2.py -o /dev/stdout -i $FIFO | ./tetra-rx -i /dev/stdin

 

[grosminet]

test with UDP

I tried last version with UDP .

First using GQRX V2.3.2 configuring UDP mode with port 7320 or 42000

Then using this line :

socat UDP-RECV:7320 STDOUT | /home/gnuradio37/tetra/osmo-tetra-sq5bpf/src/demod/python/simdemod2.py -o /dev/stdout -i /dev/stdin | ./osmo-tetra-sq5bpf/src/tetra-rx -a -i /dev/stdin

With GQRX not started , I have no message . As soon as I start GQRX , I have this message :

thread[thread-per-block[4]: <block mpsk_receiver_cc (6)>]: mmse_fir_interpolator_cc: imu out of bounds.

That means I have connection between GQRX and telive

I m working on the same goal : using a simple SDR interface eg GQRX or cubic sdr instead of grc . That should allow to plug rtl sdr, funcube, airspy or sdrplay ....

 

[sq5bpf]

That means I have connection between GQRX and telive

this means that you've sent data which is in the wrong format. look up my post earlier, it will have to look like c-file data from gnuradio

I m working on the same goal : using a simple SDR interface eg GQRX or cubic sdr instead of grc . That should allow to plug rtl sdr, funcube, airspy or sdrplay ....

but the current gnuradio flowgraphs already allow you to plug in these SDRs, and anyway this would be only a 1-channel receiver (which is crap, you really need to monitor all channels in a LA if you don't want to miss signalling data and voice).

of course it is always good to have other options. btw if you want something more productive, then try to do it with rtl_fm (it can do other modes, not only fm) or rtl_sdr. that would make sense because it would probably take way less CPU

btw i'm working on a third option (which is a leftover from the scanning stuff i've been promising to merge for a long time)