23 Jan
2019
23 Jan
'19
5:11 p.m.
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.
23 Jan
23 Jan
6:15 p.m.
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(a)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.
25 Feb
25 Feb
4:16 p.m.
Quoting Graham Norbury <gnorbury(a)bondcar.com>om>:
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.....
4:27 p.m.
Quoting Graham Norbury <gnorbury(a)bondcar.com>om>:
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.....
4:34 p.m.
Quoting Graham Norbury <gnorbury(a)bondcar.com>om>:
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.....
4:35 p.m.
Quoting Graham Norbury <gnorbury(a)bondcar.com>om>:
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.....
26 Feb
26 Feb
2:08 a.m.
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(a)zellners.com> wrote:
Quoting Graham Norbury <gnorbury(a)bondcar.com>om>:
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.....
1893
days inactive
1927
days old
6 comments
2 participants
participants (2)
-
Graham Norbury -
op25＠zellners.com