I would like some way to know about the new RID mappings, introduced by the fix for issue #157 .
What I did
I patched terminal.py to log to a text file. The log includes the new RID mapping and other information. I did not modify the curses interface to display the new RID mapping.
This issue and pull request probably doesn't depend on issue #157 and pull request #158 , but it makes sense to use them together.
This adds a dependency on the Python logging module to terminal.py. I have attempted to make it optional - if the import logging fails, terminal.pyshouldn't attempt to do any logging - but I am not sure if this works.
If the Python logging module is available, terminal.py now attempts to open a file called op25-scanner.log in the directory it is running from. Yes, the name is hard-coded, and yes, that is terrible practice. :)
If op25-scanner.log already exists, it will be appended to. If it does not exist, it is created.
When terminal.py opens op25-scanner.log, it first writes a header line, explaining what each field is. This happens every time op25 starts, so there may be more than one instance of the header line in the log file.
If logging is working, then for each transmission that comes in, terminal.py logs the date and time, frequency, manual frequency offset, talkgroup ID, talkgroup name (if available), RID, and RID name (if available). The log lines look something like this:
2022-07-09,01:23:45,851.234500(100),56789,"Metropolis Fire Dispatch",1234,"Metropolis Fire Engine 3"
This breaks down as:
2022-07-09,01:23:45 Date and time (from the PC's system clock)
851.234500 Frequency used, in MHz
(100) Manual tuning offset used, in Hz
56789 Talkgroup ID
Metropolis Fire Dispatch Talkgroup name, from TGID tags file
1234 Radio ID
Metropolis Fire Engine 3 Radio name, from RID tags file
The logging occasionally attempts to produce two identical log lines. This is detected and suppressed. Any change in the log line - including the seconds field of the timestamp - is enough to allow a new line to be logged.
Known problems
The log file name and location is hard coded.
The log file lines could stand a little more "debouncing". Sometimes I will get a line with the RID only, and then a line with the RID name only. I assume this is due to the relative order of when the messages arrive from rx.py to terminal.py, but I'm not sure that this is the case.
How I use it
I run OP25 on Linux with Xwindows. I have a small script that basically does this:
This gives me two windows - one with the OP25 curses interface, and another that follows the last several lines of the log file. That way, I can issue commands to OP25 in one window (like holding on a talkgroup of interest, or toggling the plots), and see the history of the last few transmissions on the system in the other window.
What I would like to have
I would like some way to know about the new RID mappings, introduced by the fix for issue #157 .
What I did
I patched
terminal.pyto log to a text file. The log includes the new RID mapping and other information. I did not modify the curses interface to display the new RID mapping.This issue and pull request probably doesn't depend on issue #157 and pull request #158 , but it makes sense to use them together.
This adds a dependency on the Python
loggingmodule toterminal.py. I have attempted to make it optional - if theimport loggingfails,terminal.pyshouldn't attempt to do any logging - but I am not sure if this works.If the Python logging module is available,
terminal.pynow attempts to open a file calledop25-scanner.login the directory it is running from. Yes, the name is hard-coded, and yes, that is terrible practice. :)If
op25-scanner.logalready exists, it will be appended to. If it does not exist, it is created.When
terminal.pyopensop25-scanner.log, it first writes a header line, explaining what each field is. This happens every time op25 starts, so there may be more than one instance of the header line in the log file.If logging is working, then for each transmission that comes in,
terminal.pylogs the date and time, frequency, manual frequency offset, talkgroup ID, talkgroup name (if available), RID, and RID name (if available). The log lines look something like this:This breaks down as:
The logging occasionally attempts to produce two identical log lines. This is detected and suppressed. Any change in the log line - including the seconds field of the timestamp - is enough to allow a new line to be logged.
Known problems
The log file name and location is hard coded.
The log file lines could stand a little more "debouncing". Sometimes I will get a line with the RID only, and then a line with the RID name only. I assume this is due to the relative order of when the messages arrive from
rx.pytoterminal.py, but I'm not sure that this is the case.How I use it
I run OP25 on Linux with Xwindows. I have a small script that basically does this:
This gives me two windows - one with the OP25 curses interface, and another that follows the last several lines of the log file. That way, I can issue commands to OP25 in one window (like holding on a talkgroup of interest, or toggling the plots), and see the history of the last few transmissions on the system in the other window.