Tetra decoding

[M6UEX]

Good to know, thank you.

It's on a network I have occasional access to, unfortunately the private (individual) call function has been disabled. I'm happy to try a few things when I'm next at the site though.

 

[racingfan360]

that really depends on the order in which the signalling info arrives, and also only 3 SSIs are remembered, so if there is a group call, and more than 2 ISSIs use it, then one ssi has to be forgotten and the list gets "shifted"

btw was this on tetra equipment which you own (or control)? if so, then you can try different scenarios (group calls, individual etc). i'd also be interested in the results

I rarely get to monitor TETRA networks in the clear: on one major network I monitored last year, I know there were several Groups and Users operating. But the filenames of the recordings made by Telive didn't appear to make much sense. Is this expected behavior, or should I have expected one of the SSI names in the .ogg filename to have been the correct GSSI, or will SSI1, 2 and 3 in the filename likely to be be a mix of ISSI and GSSI?

 

[passie101]

Is it possible to add the 3 played id's ( (G)ISSI ) that are showed in the telive screen under the PLAYED message to the logfile ?
So is is easier to filter them out, for external use.

 

[bilbolodz]

Maybe it could be a good idea to implement external xrpc server driving e.x. codding program and make Telive to report current (G)ISSI to it. I've thought about implementing online (private) streaming from telive and icecast/ices2 (with dynamic stream description) but my "favorite tetra network in my city" turned encryption on so there is no need for it anymore :-(

 

[sq5bpf]

Is this expected behavior, or should I have expected one of the SSI names in the .ogg filename to have been the correct GSSI, or will SSI1, 2 and 3 in the filename likely to be be a mix of ISSI and GSSI?

they will be a mix of issi and gssi. if there are only 2 radios talking in this group, then often there is an order (usually it's: calling issi _ gssi _ responding issi), but that depends on a lot of things (and is invalid for a lot of networks).

you can still find out the gssis, just listen to a few days worth of recordings, while looking at the file names.

btw i've planned to distinguish between issis and gssis in the next major version (whenever it comes)

 

[sq5bpf]

Maybe it could be a good idea to implement external xrpc server driving e.x. codding program and make Telive to report current (G)ISSI to it. I've thought about implementing online (private) streaming from telive and icecast/ices2 (with dynamic stream description) but my "favorite tetra network in my city" turned encryption on so there is no need for it anymore :-(

i've planned to do this somewhere in this major version, for reasons unrelated to streaming.

 

[sq5bpf]

Is it possible to add the 3 played id's ( (G)ISSI ) that are showed in the telive screen under the PLAYED message to the logfile ?
So is is easier to filter them out, for external use.

yes, i can add this to the next version (if i don't forget)

 

[passie101]

Thank you !

 

[sq5bpf]

Is it possible to add the 3 played id's ( (G)ISSI ) that are showed in the telive screen under the PLAYED message to the logfile ?
So is is easier to filter them out, for external use.

i can log the SSIs after the file has been saved. logging something while the audio is playing doesn't make sense, because the values can change over time.

is this ok?

 

[sq5bpf]

i've fixed the frequency info bug in telive 1.9 beta

 

[ET-NL]

i can log the SSIs after the file has been saved. logging something while the audio is playing doesn't make sense, because the values can change over time.

is this ok?

That would be enough. With that info we can combine devices to groups, maybey even with some smart combining predict the gssi's more easy.

ET

 

[passie101]

If we had it in the log while playing it would be nicer because of the real time filtering that can be done for external display of the ISSI/GISSI that are played at the moment.
Or a separate "log" file that contain the real time played info

 

[bilbolodz]

i've fixed the frequency info bug in telive 1.9 beta

I've made "git pull" with "new 1.9 beta version" and I've got core dump when I'm trying to run telive. Unfortunately I didn't make a copy of working version....

 

[Pepijn1908]

i've fixed the frequency info bug in telive 1.9 beta

Nice!

 

[Pepijn1908]

If we had it in the log while playing it would be nicer because of the real time filtering that can be done for external display of the ISSI/GISSI that are played at the moment.
Or a separate "log" file that contain the real time played info

I think this will be solved with the implementation of an xrpc server... See this post: http://forums.radioreference.com/vo...are/302347-tetra-decoding-70.html#post2600111

 

[sq5bpf]

I think this will be solved with the implementation of an xrpc server... See this post: http://forums.radioreference.com/vo...are/302347-tetra-decoding-70.html#post2600111

so now you know why this was planned

another reason was to have a simple way to have an external program drive an LCD display. one way this could be used would be a raspberry pi with external lcd that could be used as a standalone tetra receiver/scanner.

but this is not at the top of my priority list at the moment.

 

[passie101]

Yes, I have read this. putting it in the log file will be a "quick" solution till XRPC Server is implemented.
With multiple telive's running is is nice to show in the log windows what is playing.
so you do not have to swap al the telive screens to see what is playing.

 

[point2point]

Segmentation Fault (./rxx 1.9 beta)

 

[sq5bpf]

Segmentation Fault (./rxx 1.9 beta)

yes, i've seen it, and will investigate it next week. for now you can comment out the call to clear_freqtable(frequencies) in tickf() (this is somwhere around line 1478)

 

[point2point]

works perfect now.