Discussion of New UI 2025

[boatbod]

New UI pull request has been merged into "dev" branch and is currently working for P25 only. This thread is for ongoing developer discussions pertaining to the new code.

[boatbod]

Todo:

• Fix the typo "Synbol" in op25/gr-op25_repeater/www/www-static/index.html (done)
• Need to add support for showing active "patches" that was in the legacy ui. (verified working)
• Need to make work with tk_smartnet.
• Need to make back-end app use the legacy gui when running under rx.py

Discussion

• Call History window is interesting to watch, but scrolls quickly on a busy system. Can we add a configuration option to restrict it only to traffic that op25 tunes a voice channel to? Rough equivalent would be running with log level -v 1 and seeing the "voice update:" lines in stderr.2

• Is there a way to make the boxes draggable/reorderable, or perhaps switch some off? e.g. Adjacent Sites

• Figure out how to migrate the contents of config.js to op25's config.json file and have it passed over the messaging interface from the app to the terminal (in progress)

[triptolemus510]

Patches is already there. See screenshot below. The div that contains it is display=none when patches=0

Under Settings, Adjacent Sites can be hidden, Call History and the plot images sizes can be resized. I can add option to show/hide the frequency table. Draggable / renderable seems like a heavy lift for not much value.

I'm can work on a user option to select from where the Call History table is populated.

[triptolemus510]

@boatbod - can you bring over srcaddr and srctag in frequency_data? If so, we can display the Call History data consistently in both Frequency and Voice selections.

Also, c_tdma in channel_update - can you explain its purpose/function? It doesn't seem to show up consistently.

See Call History Source selection and implantation on the right.

[boatbod]

You should find that srcaddr and srctag are already in the response from the receiver object (voice channel) which comes over in the channel_update["rx_rcvr"] portion of the message. See tk_p25.py methods rx_ctl::get_chan_status() and p25_receiver::get_status(). Did you need them elsewhere too? Be aware that srcaddr=0 can be a frequent occurrence depending on timing of receiving a voice grant or update. You really can't rely on it for much.

ETA: The "frequency_data" information presently contains a list of tgids with either None, one, or two entries, and tags is similar. Are you thinking to just do the same with srcaddr & srctag? Perhaps I just need more insight into how you plan on using them, but presently I'm having a hard time figuring out how to handle when a srcaddr and/or tag missing.

Similarly, c_tdma (in main.js) comes from the channel_update["rx_rcvr"]["tdma"] parameter, which is the currently active slot in that voice receiver. It will be either null, 0, or 1. An active receiver with c_tdma=null means P25 phase 1 traffic (for P25 protocol).

[triptolemus510]

Yes. I would like to have srcaddr and srctag in frequency_data. This would provide a consistent display of Call History when it is populated from voice grant or frequency data.

I recall having the same problems with srcaddr=0 on max branch. c_tdma appears to exhibit similar behavior in that it often shows up null when it should have a slot (?). I don't think c_tdma is very important to show in call history, so I've replaced it with the frequency, which is present consistently in both data sets.

I'm going to push an update to my repo. Changes:

• In Settings, add option to show/hide call history
• In Settings, add option to choose source of call history data (voice grant or frequency data)
• Deleted TDMA/FDMA from Call History, replaced with Frequency
• Log to Call History only when source ID is present

Looking for:

Source ID and Source Tag in json trunk_update under frequency_data (see screenshot)
Name of the running Python module somewhere so the js can invoke the legacy ui automatically

Noted issues:
It looks like there might be something wrong with exiting a HOLD talkgroup. Need to look further.
Error display in frequency_data

[boatbod]

I have added "srcaddrs" array and "srctags" array to the frequency_data[freq] message.
Valid entries are None (null), or a decimal source address (rid), or a text source tag.

            tags = []
            srcaddrs = []
            srctags = []
            for tgid in tgids:
                try:
                    tgid_int = int(tgid)
                    tag = self.talkgroups.get(tgid_int, {}).get('tag', None)
                    srcaddr = self.talkgroups[tgid_int]['srcaddr']
                    srctag = self.get_rid_tag(self.talkgroups[tgid_int]['srcaddr'])
                except (ValueError, TypeError) as e:
                    if self.debug >= 10:
                        sys.stderr.write(f"Error converting TGID '{tgid}' to int: {e}\n")
                    tag = None
                    srcaddr = None
                    srctag = None
                tags.append(tag)
                srcaddrs.append(srcaddr)
                srctags.append(srctag)

In addition, I added "satag" and "gatag" to the patch_data message so that you can display tags (if they exist) in the patches window.

[triptolemus510]

Excellent. I will incorporate those changes and push an update tomorrow (hopefully).

[boatbod]

I thinking we need still need a better methodology for figuring out call history. There was a medical consult that just took place which lasted 3 minutes (with some back and forth) that generated 28 entries in the UI call history, vs 5 entries in the stderr.2 log.

Are you deriving Call History from "frequency_data" or "channel_update" messages? I'm assuming the former, because the latter looks like there's only going to be an entry if a call is being actively received. Potentially you could look at the list of tgids in frequency_data and see which ones also exist in channel_update. Those that do have been tuned by a channel.

[triptolemus510]

The source of the call history data is user choice under Settings. One is frequency_data and the other is channel_update. Frequency Data is obviously more chatty as you pointed out earlier.

The decision to append the Call History table is made in appendCallHistory() and isDuplicate(). This function checks the call history table to determine if a call with the same Talkgroup ID (tgid) and Source ID (sourceId), and same sysid has already been logged within the recent past (defined by MAX_HISTORY_SECONDS) within the MAX_HISTORY_ROWS.

		function isDuplicate(tgid, sourceId) {
			const recentRows = tableBody.querySelectorAll("tr");
		
			for (let i = 0; i < Math.min(MAX_HISTORY_ROWS, recentRows.length); i++) {
				const cells = recentRows[i].querySelectorAll("td");
				if (cells.length < 6) continue;
		
				const rowTime   = cells[0].textContent.trim();
				const rowSys    = cells[1].textContent.trim();
				const rowTgid   = cells[3].textContent.trim();
				const rowSrcId  = cells[5].textContent.trim(); // <-- updated to index 5
		
				if (rowSys === sysHex && rowTgid === String(tgid) && rowSrcId === String(sourceId)) {
					const rowDate = new Date();
					const [hours, minutes, seconds] = rowTime.split(':').map(Number);
					rowDate.setHours(hours, minutes, seconds, 0);
		
					const rowEpochSec = Math.floor(rowDate.getTime() / 1000);
					const nowSec = Math.floor(epoch / 1000);
					const delta = Math.abs(nowSec - rowEpochSec);
		
					if (delta <= MAX_HISTORY_SECONDS) {
						return true;
					}
				}
			}
		
			return false;
		}

I will give it some further thought...

[boatbod]

Another Call History observation:- when set to Voice Grant source, the call history only appears to update from the currently displayed channel. i.e. if I have a system with 3 channels, only calls for the one that is presently showing in the top window get added to the history log.

[boatbod]

If it makes things easier, I could create a new response message "call_log" populated at the server end and include as part of the response to an update request, similar to channel_update, trunk_update and frequency_data. I imagine it would look similar to the 'voice update:' stderr.2 log messages, but json encoded

[triptolemus510]

call_log sounds intriguing and probably exactly what's needed. How difficult would that be for you to implement? And to confirm, it would send over data intended to be appended to the Call History table, based on voice grants?

And you're right, it's populating from just what's displayed.

[triptolemus510]

gatag and sgtag are coming up null. I see there's a space in the related ga and sg fields. Perhaps that's screwing up the lookup?

[boatbod]

I tweaked it; should be working now.
patch_data: {12001: {12003: {'sg': 12001, 'sgtag': 'CarolineFireDisp', 'ga': 12003, 'gatag': 'CarolineFireTac3'}}}

[triptolemus510]

Looks good. I'll post up a www-static update shortly.