trunk-recorder
trunk-recorder copied to clipboard
robotastic
Using frequency number instead of "numbers by order" in conventional systems
As you know, for conventional systems, trunk-recorder assigns talkgroups id numbers by order, as they are written in the configuration. See attached data.
"systems": [
{
"shortName": "472-System",
"type": "conventionalP25",
"channels": [
472000000, 472100000, 472200000, 472300000, 472400000,
472500000, 472600000, 472700000, 472800000, 472900000
],
"modulation": "fsk4",
"squelch": -30,
"compressWav": false,
"uploadScript": "upload-call.sh 472",
"audioArchive": false,
"callLog": false
}
]
(info) [472-System] Monitoring Conventional Channel: 472.000000 MHz Talkgroup: 1
(info) [472-System] TG: 1 Freq: 472.000000 MHz
(info) [472-System] Monitoring Conventional Channel: 472.100000 MHz Talkgroup: 2
(info) [472-System] TG: 2 Freq: 472.100000 MHz
(info) [472-System] Monitoring Conventional Channel: 472.200000 MHz Talkgroup: 3
(info) [472-System] TG: 3 Freq: 472.20000 MHz
(info) [472-System] Monitoring Conventional Channel: 472.300000 MHz Talkgroup: 4
(info) [472-System] TG: 4 Freq: 472.30000 MHz
...
Using a tgid in this format is inconvenient for further use when uploading calls in rdio-scanner. I ask you to add the use_freq_as_tgid parameter to the system configuration so that the frequency is used as the talkgroup id. Or maybe add the use_freq_as_tgid_in_json parameter, so that the frequency is duplicated in the talkgroup field in the .json-file.
Just wanted to add a +1 on this. For those of us with a bunch of conventional systems this makes sense.
While it's kind of silly to care about this at all (as analog conventional systems don't have talk groups) the monitoring tools kind of expect this value to be reasonable and unique and setting it uniquely would be useful.
Instead of using the frequency as a TG ID, wouldn't it be helpful to just have something like:
"channels": [
472000000, 472100000, 472200000, 472300000, 472400000,
472500000, 472600000, 472700000, 472800000, 472900000
],
"channel_talkgroups": [
1, 3, 5, 7, 9,
10, 8, 6, 4, 2
],
to arbitrarily assign TG numbers for conventional systems?
While a freq may be reasonably unique within a local system, I can imagine a scenario where you may be coordinating multiple TR instances watching multiple repeater sites, and different frequencies carrying the same "talkgroup".
The frequency itself is also a relatively large number compared the normal range of trunked TGs. Things downstream may not display too well with a TG four digits longer than it is expecting to encounter.
Currently playing around with a solution using talkgroupsFile as a lookup table for conventional talkgroup numbers and alpha tags (groups, etc..). For example:
"systems": [{
"type": "conventionalP25",
"channels": [451650000, 453365000, 453465000],
"shortName": "test",
"talkgroupsFile": "test.csv",
test.csv:
100,451650000,D,Town FD, Town Fire Department, Fire Dispatch, Town
200,453365000,D,Town PD, Town Police Department,Law Dispatch, Town
300,451500000,A,Town DPW, Town Public Works, Public Works, Town
325,453500000,A,Dog Catcher,Town Animal Control, Animal Control,Town
210,453465000,D,Town PD TAC,Town Police Department,Law Tactical, Town
Running:
Allocating 15 zero-copy buffers
[test] 0C TG: 100 ( Town FD) Freq: 451.650000 MHz Starting P25 Recorder Num [0] TDMA: false Slot: 0 QPSK: true
[test] 1C TG: 200 ( Town PD) Freq: 453.365000 MHz Starting P25 Recorder Num [1] TDMA: false Slot: 0 QPSK: true
[test] 2C TG: 210 ( Town PD TAC) Freq: 453.465000 MHz Starting P25 Recorder Num [2] TDMA: false Slot: 0 QPSK: true
Seems to work so far. I could turn it into a PR after I'm pretty sure I haven't created any new issues.
@taclane - that is interesting. I think something like that could work. The CSV parsing code is already pretty brittle, but this could be a good excuse to work on it.
Another option could be optional providing the channels an array of objects: [{"freq": 451650000, "id": 100}] and then use this to populate the Talkgroup/Call info. Also just using a separate, optional, array for Channel IDs is easy enough.
What would people prefer?
@taclane - that is interesting. I think something like that could work. The CSV parsing code is already pretty brittle, but this could be a good excuse to work on it.
Another option could be optional providing the channels an array of objects: [{"freq": 451650000, "id": 100}] and then use this to populate the Talkgroup/Call info. Also just using a separate, optional, array for Channel IDs is easy enough.
What would people prefer?
@robotastic I have had it running the last few days using the a talkgroupFile csv without finding any problems (so far). A side benefit of it is that it also allows plugins to report off Talkgroup Tags and Groups for conventional frequencies as well.
Maybe a simple array for TG numbers would be one solution, but if you also want to include: descriptions, tags, groups... being able to read that all in from a csv has been really nice.
Just wanted to voice support for a fix for this. It took me a bit to figure out how to get Rdio-Scanner to play out conventional channels and match up the talkgroup ID since they were all 1. Putting them in as one system as an array works far better, but, this causes a problem when some channels are p25 and some are analog. You then have overlapping talkgroup numbers across systems. I also tried naming the systems identically to see if the software was smart enough to increase the counter but it did not - and I was stuck with duplicate talkgroup numbers. I'll adapt to either an array format or CSV as either are easy to implement on my end.
I also tried naming the systems identically to see if the software was smart enough to increase the counter but it did not - and I was stuck with duplicate talkgroup numbers.
@cherizon You can somewhat get around this by padding the config with dummy frequencies. It's not the ideal solution, but something like this
"systems": [{
"type": "conventionalP25",
"channels": [455750000, 455375000],
"alphatags": ["Fire", "Police" ],
"shortName": "mixedsystem",
"unitTagsFile": "mixedsystemtags.csv",
...
},{
"type": "conventional",
"channels": [0, 1, 455225000, 456225000],
"alphatags": ["nullA", "nullB", "DPW", "FireTac"],
"shortName": "mixedsystem",
...
will ultimately behave like this
mixedsystem
TG1 - p25conv Fire
TG2 - p25conv Police
TG3 - analog DPW
TG4 - analog FireTac
as far as trunk-recorder is concerned. I've been using something similar for months, but you really don't have much ability to rearrange or edit things without totally breaking talkgroup assignments.
https://github.com/robotastic/trunk-recorder/pull/630 currently works as a proposed way to handle conventional talk groups with a csv file. I'm fine if that doesn't end up being the solution that gets adopted, but it would be nice to have the conventional side as flexible as trunked with regards to TG IDs, Alpha Text, Groups, etc...
Wow, I didn't know you could put bogus information in to space it all out that way. Thank you for the pointer. It is working perfectly and fixes my specific issue.
With the addition of the talkgroup csv for conventional channels, is there anything else in this issue that isn't being addressed?
With the recent change, a conventional channel can now have any talkgroup number, as well as additional metadata like alpha text, description, service tag, and group tag.