In reviewing the various setups of trunking_file.tsv, id_file.tsv etc... and looking over various documentation, I am not seeing a means to do RID(LID) or Radio ID aliasing...
I am I missing this some place???
The systems can be setup to alias out $47E136 as "Helo1" etc... The systems have places to do this from the start and update from consoles etc...
Any way to do that in OP25???????? ie:
rid.tsv
47e136 Helo1 47e137 Helo2 etc...
Turning RID into an alias would be a plus to ID units... ie: Ladder1, Ladder1_Portable, FF152521, etc.. Many of these are pretty static.. now some depending on you agency(s) may not be... in on a particular group would need some updates each year, as they change based on a progression system.
CC Data is there some sort of aggregate that determines the quality of the CC data coming out???? That can accessed programmatically???
Or maybe that question is better referenced as is the there something that documents the API to OP25 that the various python scripts are using to possible do what I want... The plots are not useful as I desire text data to use in another place....
So I guess something that documents interacting with the underlying mechnations of OP25 would probably help to do what I am after with the CC.
Thanks.
Sorry, RID alias is not there yet. Biggest issue on curses terminal (i.e. non-http) is the lack of space for the RID String.
Graham
On 1/23/19 11:11 AM, op25@zellners.com wrote:
In reviewing the various setups of trunking_file.tsv, id_file.tsv etc... and looking over various documentation, I am not seeing a means to do RID(LID) or Radio ID aliasing...
I am I missing this some place???
The systems can be setup to alias out $47E136 as "Helo1" etc... The systems have places to do this from the start and update from consoles etc...
Any way to do that in OP25???????? ie:
rid.tsv
47e136 Helo1 47e137 Helo2 etc...
Turning RID into an alias would be a plus to ID units... ie: Ladder1, Ladder1_Portable, FF152521, etc.. Many of these are pretty static.. now some depending on you agency(s) may not be... in on a particular group would need some updates each year, as they change based on a progression system.
CC Data is there some sort of aggregate that determines the quality of the CC data coming out???? That can accessed programmatically???
Or maybe that question is better referenced as is the there something that documents the API to OP25 that the various python scripts are using to possible do what I want... The plots are not useful as I desire text data to use in another place....
So I guess something that documents interacting with the underlying mechnations of OP25 would probably help to do what I am after with the CC.
Thanks.
Quoting Graham Norbury gnorbury@bondcar.com:
Sorry, RID alias is not there yet. Biggest issue on curses terminal (i.e. non-http) is the lack of space for the RID String.
Just as FYI and comment on this... while it would be nice, great etc. if the various interfaces displayed the RID data ie: ncurses and/or the http....
If its possible to ADD that to the metatag process thats where I am more interested in it.. the display be it http/ncurses is really not used 99.999999999999999% of the time... its dumped to a screen session, dettached, and hopefully forgotten about... right now for testing/setup that may not be the case, but thats the goal... same with the http... that might change if there was more data in either ala sdtrunk showing the events...even at -v 10 the log which I keep in a tail screen doesn't log the various events that others do.. now that may be where the wireshark interface was meant to deal with that and not op25 itself... I am talking about IDEN UP, RSSI info (http does grab this), affiliations, failed registrations etc... All that seems to just be ignored from that CC stream in -v10...again that may be the intention and again it was expected to pass this to wireshark, that seems to be a dead end now????...
So tl;dr, if you can get RID's to the tag data and even if it doesn't show on the interface that would be great... that wouldn't need an y space on the interfaces be it http or ncurses.... Add it to the tag interface shouldn't be wasted effort.. and when space, time what not it can be added to the interfaces when time, space etc. permit.
ie:
TGID ..... RID: MayberryPD1
etc....
Which gets me back to the another part of this...
Is there something that outlines the various ways that the threads are started, interaction with that CC data... again I have personal use cases I'd like to explore, but don't have a reference starting point to go from where all this interaction is... rx.py seems to call various things as threads to deal with things... ie: tags.....
Quoting Graham Norbury gnorbury@bondcar.com:
Sorry, RID alias is not there yet. Biggest issue on curses terminal (i.e. non-http) is the lack of space for the RID String.
Just as FYI and comment on this... while it would be nice, great etc. if the various interfaces displayed the RID data ie: ncurses and/or the http....
If its possible to ADD that to the metatag process thats where I am more interested in it.. the display be it http/ncurses is really not used 99.999999999999999% of the time... its dumped to a screen session, dettached, and hopefully forgotten about... right now for testing/setup that may not be the case, but thats the goal... same with the http... that might change if there was more data in either ala sdtrunk showing the events...even at -v 10 the log which I keep in a tail screen doesn't log the various events that others do.. now that may be where the wireshark interface was meant to deal with that and not op25 itself... I am talking about IDEN UP, RSSI info (http does grab this), affiliations, failed registrations etc... All that seems to just be ignored from that CC stream in -v10...again that may be the intention and again it was expected to pass this to wireshark, that seems to be a dead end now????...
So tl;dr, if you can get RID's to the tag data and even if it doesn't show on the interface that would be great... that wouldn't need an y space on the interfaces be it http or ncurses.... Add it to the tag interface shouldn't be wasted effort.. and when space, time what not it can be added to the interfaces when time, space etc. permit.
ie:
TGID ..... RID: MayberryPD1
etc....
Which gets me back to the another part of this...
Is there something that outlines the various ways that the threads are started, interaction with that CC data... again I have personal use cases I'd like to explore, but don't have a reference starting point to go from where all this interaction is... rx.py seems to call various things as threads to deal with things... ie: tags.....
Quoting Graham Norbury gnorbury@bondcar.com:
Sorry, RID alias is not there yet. Biggest issue on curses terminal (i.e. non-http) is the lack of space for the RID String.
Just as FYI and comment on this... while it would be nice, great etc. if the various interfaces displayed the RID data ie: ncurses and/or the http....
If its possible to ADD that to the metatag process thats where I am more interested in it.. the display be it http/ncurses is really not used 99.999999999999999% of the time... its dumped to a screen session, dettached, and hopefully forgotten about... right now for testing/setup that may not be the case, but thats the goal... same with the http... that might change if there was more data in either ala sdtrunk showing the events...even at -v 10 the log which I keep in a tail screen doesn't log the various events that others do.. now that may be where the wireshark interface was meant to deal with that and not op25 itself... I am talking about IDEN UP, RSSI info (http does grab this), affiliations, failed registrations etc... All that seems to just be ignored from that CC stream in -v10...again that may be the intention and again it was expected to pass this to wireshark, that seems to be a dead end now????...
So tl;dr, if you can get RID's to the tag data and even if it doesn't show on the interface that would be great... that wouldn't need an y space on the interfaces be it http or ncurses.... Add it to the tag interface shouldn't be wasted effort.. and when space, time what not it can be added to the interfaces when time, space etc. permit.
ie:
TGID ..... RID: MayberryPD1
etc....
Which gets me back to the another part of this...
Is there something that outlines the various ways that the threads are started, interaction with that CC data... again I have personal use cases I'd like to explore, but don't have a reference starting point to go from where all this interaction is... rx.py seems to call various things as threads to deal with things... ie: tags.....
Quoting Graham Norbury gnorbury@bondcar.com:
Sorry, RID alias is not there yet. Biggest issue on curses terminal (i.e. non-http) is the lack of space for the RID String.
Just as FYI and comment on this... while it would be nice, great etc. if the various interfaces displayed the RID data ie: ncurses and/or the http....
If its possible to ADD that to the metatag process thats where I am more interested in it.. the display be it http/ncurses is really not used 99.999999999999999% of the time... its dumped to a screen session, dettached, and hopefully forgotten about... right now for testing/setup that may not be the case, but thats the goal... same with the http... that might change if there was more data in either ala sdtrunk showing the events...even at -v 10 the log which I keep in a tail screen doesn't log the various events that others do.. now that may be where the wireshark interface was meant to deal with that and not op25 itself... I am talking about IDEN UP, RSSI info (http does grab this), affiliations, failed registrations etc... All that seems to just be ignored from that CC stream in -v10...again that may be the intention and again it was expected to pass this to wireshark, that seems to be a dead end now????...
So tl;dr, if you can get RID's to the tag data and even if it doesn't show on the interface that would be great... that wouldn't need an y space on the interfaces be it http or ncurses.... Add it to the tag interface shouldn't be wasted effort.. and when space, time what not it can be added to the interfaces when time, space etc. permit.
ie:
TGID ..... RID: MayberryPD1
etc....
Which gets me back to the another part of this...
Is there something that outlines the various ways that the threads are started, interaction with that CC data... again I have personal use cases I'd like to explore, but don't have a reference starting point to go from where all this interaction is... rx.py seems to call various things as threads to deal with things... ie: tags.....
I'm chuckling at the last comment... sorry there's no written documentation on how it all fits together other than the code itself. In essence, rx.py creates the receiver, demodulator, decoder, trunking module and terminal then uses gnuradio to connect them all together. Spending time looking through the code is the best way to figure it out.
Graham
On Mon, Feb 25, 2019, 9:38 AM op25@zellners.com wrote:
Quoting Graham Norbury gnorbury@bondcar.com:
Sorry, RID alias is not there yet. Biggest issue on curses terminal (i.e. non-http) is the lack of space for the RID String.
Just as FYI and comment on this... while it would be nice, great etc. if the various interfaces displayed the RID data ie: ncurses and/or the http....
If its possible to ADD that to the metatag process thats where I am more interested in it.. the display be it http/ncurses is really not used 99.999999999999999% of the time... its dumped to a screen session, dettached, and hopefully forgotten about... right now for testing/setup that may not be the case, but thats the goal... same with the http... that might change if there was more data in either ala sdtrunk showing the events...even at -v 10 the log which I keep in a tail screen doesn't log the various events that others do.. now that may be where the wireshark interface was meant to deal with that and not op25 itself... I am talking about IDEN UP, RSSI info (http does grab this), affiliations, failed registrations etc... All that seems to just be ignored from that CC stream in -v10...again that may be the intention and again it was expected to pass this to wireshark, that seems to be a dead end now????...
So tl;dr, if you can get RID's to the tag data and even if it doesn't show on the interface that would be great... that wouldn't need an y space on the interfaces be it http or ncurses.... Add it to the tag interface shouldn't be wasted effort.. and when space, time what not it can be added to the interfaces when time, space etc. permit.
ie:
TGID ..... RID: MayberryPD1
etc....
Which gets me back to the another part of this...
Is there something that outlines the various ways that the threads are started, interaction with that CC data... again I have personal use cases I'd like to explore, but don't have a reference starting point to go from where all this interaction is... rx.py seems to call various things as threads to deal with things... ie: tags.....
-
Graham Norbury -
op25＠zellners.com