i hope that being a linux noob doesn't mean that you also can't read the documentation? there is a section the the faq titled: "The receiver doesn't work, no matter what frequency I tune it to. Gnuradio complains about PLL unock".
Tetra decoding
- Thread starter sq5bpf
- Start date
-
- Tags
- tetra decode
- Status
i hope that being a linux noob doesn't mean that you also can't read the documentation? there is a section the the faq titled: "The receiver doesn't work, no matter what frequency I tune it to. Gnuradio complains about PLL unock".
Is there someone here who had tried to install GNU Radio 3.6 on a raspberry Pi 2 ?
If i use the script from sbrac.org it fails on the RaspPi 2 with no specified error.
I had modified the sbrac.org scrip to get it work with the latest Debian release for the RaspPi 2.
If i use the script from sbrac.org it fails on the RaspPi 2 with no specified error.
I had modified the sbrac.org scrip to get it work with the latest Debian release for the RaspPi 2.
see if you get any SDS messages in telive.log with "Location" in the description. if you get any, then send them to me, including the previous line (the one with lots of 101010101)
you mean for the voice files? are they broken up or something?
I can also confirm that the recording sometimes gets interrupted in the middle of the conversation. This happens on some types of calls when there are no new SSI's comming in which pushes the usage timer. I haven't looked much further in the code to figure out why, but I just increased the REC_TIMEOUT in tlive.c to reduce the risk that this happens. When doing this you also need to increase SSI_TIMEOUT, else no SSI's will be shown in the filename.
I would also like to use the Call Identifier (instead of usage index) to create the recordings, at least on the 5 different systems I've checked the Call Identifier works just fine.Using the Call Identifier would make it easy to create one file for the entire call, no matter how many times the index changes during the call. When looking at the Call Identifier together with other commands, like D-RELEASE, it also becomes easier to follow the various commands during the call, like when the call is terminated and the recording can be stopped (instead of using timers as it's currently implemented)
is this a problem with the new telive, or all versions? if it is a problem with new telive, then disable kml export (comment out the setting of KML-related variables in rxx).
btw these timeouts should probably be configurable.
this was the reason i added the call identifier to osmo-tetra in the first place. but unfortunately didn't get around to use it so far.
btw the development roadmap for v1.x is as follows:
- finish the location stuff (at least the LIP long location report and simple location system rtcm sc-104)
- show data about neighbour cells (frequency etc)
- iron out some bugs (mostly segfaults etc)
- don't require the codecs to be compiled in a 32-bit environment. a patch for this has alredy been contributed! (didn't test it, but looks good)
- have the option to use gnuradio 3.7. a patch for this has alredy been contributed! (didn't test it, but looks good). this is a reolutional change, so there will be no support
----- and this will be the end of v1.x development, i don't want to make any revolutional changes to the code, just keep it stable ------
this is my wishlist for the next version:
- make a better communication protocol between osmo-tetra-sq5bpf and telive (any hints? and no, xml is not a good idea, rpc is not a good idea (although it's fast enough))
- implement sds transfer (for now i just skip 2 bytes)
- use gnuradio 3.7 (or 3.8). a patch for this has already been contributed!
- use call identifiers instead of usage index.
- keep more state about the calls. (any hints on what in-memory database to use?)
- maybe put kml writing into another process so that it doesn't block
- scanning support (actually i've already implemented a proof of concept, but it is a very ugly hack, and didn't release it)
- make the interface smaller, so that it fits in an 80x24 xterm (or something smaller than
- maybe have some means of remote control of telive via another process, and to make it run headless. SM0VEC already runs the software on an Intel NUC. so put a small lcd display and a few buttons on it, and you can make a nice tetra receiver for your car
- scanning support (actually i've already implemented a proof of concept, but it is ugly as hell, and i wont release it in this state)
- have some way to send events from telive to other processes. for example one user parses the logs for statistics which SSIs talk together.
..and before someone asks - no, there will be no windows version
The interruption of one minute, it is in a live voice broadcast and his record file, just when it lasts more than a minute is cut and the rest of the transmission is lost. This is new , in previous versions telive the transmission is not cut .
In the telive.log file any description does not appear location , probe first with the basic log option and then with verbose option and no location data in this system at least. Will try on the other tetra system available
In the telive.log file any description does not appear location , probe first with the basic log option and then with verbose option and no location data in this system at least. Will try on the other tetra system available
could you revert to a previous version and see if the calls are uncut? this part of the code has not been touched.
I believe this problems have always been present. I can especially see this on systems with only one site and frequency. Below is an example from the log where a group call is established on one Index, but since Telive doesn't push the timers on TX GRANTED (since that's not associated to an Index), the audio and recording stops long before the call actually is finished.
20150303 14:25:26 FUNC: D-CALL PROCEEDING SSI:00015733 IDX:000 IDT:1 ENCR:0 RX:1 CI:5135
20150303 14:25:26 FUNC: D-ALERT SSI:00015733 IDX:000 IDT:1 ENCR:0 RX:1 CI:5135
20150303 14:25:36 FUNC: DSETUPDEC IDX:0 SSI:15733 RX:1 CI:5136
20150303 14:25:36 FUNC: D-SETUP SSI:00010002 IDX:000 IDT:1 ENCR:0 RX:1 CI:5136
20150303 14:25:43 FUNC: D-CONNECT SSI:00015733 IDX:053 IDT:6 ENCR:0 RX:1 CI:5135
20150303 14:25:43 FUNC: D-CONNECT SSI:00015733 IDX:053 IDT:6 ENCR:0 RX:1 CI:5135
20150303 14:25:44 FUNC: D-TX CEASED SSI:00010002 IDX:000 IDT:1 ENCR:0 RX:1 CI:5136
20150303 14:25:45 FUNC: D-TX GRANTED SSI:00015733 IDX:000 IDT:1 ENCR:0 RX:1 CI:5135
20150303 14:26:10 FUNC: D-TX CEASED SSI:00015733 IDX:000 IDT:1 ENCR:0 RX:1 CI:5135
20150303 14:26:11 FUNC: D-TX GRANTED SSI:00010002 IDX:000 IDT:1 ENCR:0 RX:1 CI:5136
...
20150303 14:27:50 FUNC: D-TX GRANTED SSI:00010002 IDX:000 IDT:1 ENCR:0 RX:1 CI:5136
20150303 14:27:51 FUNC: D-TX CEASED SSI:00015733 IDX:000 IDT:1 ENCR:0 RX:1 CI:5135
20150303 14:27:53 FUNC: D-RELEASE SSI:00015733 IDX:000 IDT:1 ENCR:0 RX:1 CI:5135
This log is from a system with only one frequency and no other sites.
It's also interesting to see that different Call Identifier is assigned to each caller, even though they share the same Usage Index (I've added the printing of CI as the call identifier in this example if someone wonder where that came from).
The caller on Identifier 5136 must have been assigned the Usage Index by another message that's not yet fully decoded. I'm trying to figure out in which command this information is sent but I haven't yet found it.
i think so too. btw i was begining to worry that i have somehow introduced a bug somewhere
there are numerous ones that change ids and usage index. for example d-call restore can change the call identifier to a new one, d-connect can assign a new usage index to a call identifier etc. i've implemented decoders for some of these functions, but not all. the rest will be implemented for v2 but first i need to polish up v1 to a finished state. v2 will have totally different logic for call tracking anyway.
maybe I'm wrong with this 1 minute condition with previus telive version, this happen or I notice it with duplex calls (only can monitor one side).
I can´t reverse to previus versions, still fighting with linux.
sq5bpf, please check inbox with some SDS founded
I can´t reverse to previus versions, still fighting with linux.
sq5bpf, please check inbox with some SDS founded
more LIP parsing has been added to osmo-tetra-sq5bpf, please update
this one will parse LIP long messages. i'd like to thank everybody who have sent samples
if anybody sees interesting looking messages in telive log, especially ones which don't decode, or decode incorrectly, then please send them to me. i really like toget telive.log from various parts of the world
this one will parse LIP long messages. i'd like to thank everybody who have sent samples
if anybody sees interesting looking messages in telive log, especially ones which don't decode, or decode incorrectly, then please send them to me. i really like toget telive.log from various parts of the world
ET-NL
Member
I'm following this forum for a while now but never opend an account.
Since last month I'm using an RTL-SDR with osmo-tetra to listen to the Tetra networks in the neighbourhood (commersial network with lots of different users, airport, ..). Many thanks for this great software, I love it.
With the latest update's I see LIP data being decoded.
This morning I updated osmo-tetra to the latest version, after this update Telive is crashing on location data, I think its location data I'm not a programmer just a listener ;-)
In Telive I get a segment fault (Core dumpt)
Since last month I'm using an RTL-SDR with osmo-tetra to listen to the Tetra networks in the neighbourhood (commersial network with lots of different users, airport, ..). Many thanks for this great software, I love it.
With the latest update's I see LIP data being decoded.
This morning I updated osmo-tetra to the latest version, after this update Telive is crashing on location data, I think its location data I'm not a programmer just a listener ;-)
In Telive I get a segment fault (Core dumpt)
i've had reports of this, but i can't reproduce it (and i don't see where this could happen in the code, it's just 2 simple functions).
for now try to comment out the following lines in rxx (put a # in front of the line) :
#export TETRA_KML_FILE=/tetra/log/tetra1.kml
#export TETRA_KML_INTERVAL=3
this disables KML export, and should "fix" the problem.
unfortunately this error is hard to reproduce. i've tried to play back logs into telive from people who get crashes, and everything is ok on my systems.
to everyone who gets crashes: please send me what linux distribution you're using including the bit length (like "debian 7.8 32-bit"), and the result of free. preferably send it via private message
to everyone who gets crashes: please send me what linux distribution you're using including the bit length (like "debian 7.8 32-bit"), and the result of free. preferably send it via private message
hansheesbeen
Member
Had this problem in one of the first releases of Telive, Also monitoring commercial networks in the Netherlands.
Maybe some network settings who made an conflict?
Reinstall Telive gave the solution, after that I had never crashes anymore...
ET-NL
Member
It looks like after restarting my machine (Unbuntu 32 Bits VM) I did not see the problem again.
At the moment of the crash Telive log's where running, can you use them for troubleshooting ?
Elmar
(my post have some delay, there I'm a new user and still under moderation)
At the moment of the crash Telive log's where running, can you use them for troubleshooting ?
Elmar
(my post have some delay, there I'm a new user and still under moderation)
a restart shouldn't change anything
not really. i already got a few logs from people, also with telive versions patched for better debugging. it seems that there is some heap corruption, but i don't know why. and i can't reproduce it.
i am begining to suspect that this is a problem with running the software under a virtual machine - is there anyone who has crashes under linux running on normal hardware (not a vm)?
- Status