Unitrunker Release 22

[GroundLoop]

$200 is not so cheap. I'm getting these MaxTrac 800 Privacy Plus radios for $10 or less.

I didn't realize flashcodes played such an important role in determining P25 digital audio compatibility. I'm going to need to draw a map and figure out which models to look for. most people don't list firmware versions and such, so it's a bit of a crap-shoot.

Also -- does the Astro need to hear the CC in order to decode P25? (Are there any codes/keys/colors it needs other than the voice channel?) I ask because this hack basically castrates the microcontroller in the radio and just directly tunes the RF section. The radio won't be able to get to the CCh at all.

What does "CAI" stand for?

Anyway, if anyone wants to sell such a radio (800 MHz, P25 digital audio, obsolete), send a PM, eh!

 

[scottbailey]

$200 is not so cheap. I'm getting these MaxTrac 800 Privacy Plus radios for $10 or less.

I didn't realize flashcodes played such an important role in determining P25 digital audio compatibility. I'm going to need to draw a map and figure out which models to look for. most people don't list firmware versions and such, so it's a bit of a crap-shoot.

Also -- does the Astro need to hear the CC in order to decode P25? (Are there any codes/keys/colors it needs other than the voice channel?) I ask because this hack basically castrates the microcontroller in the radio and just directly tunes the RF section. The radio won't be able to get to the CCh at all.

What does "CAI" stand for?

Anyway, if anyone wants to sell such a radio (800 MHz, P25 digital audio, obsolete), send a PM, eh!

Out of respect for Rick - and since I hate reading 20+ page 'Unitrunker release xx' threads full of off-topic discussions - I started a new thread to continue this discussion: http://forums.radioreference.com/tr...nnel-steering-unitrunker-voice-reception.html

 

[GroundLoop]

Thanks Scott.

More relevant to the UniTrunker Release 22 topic..

If I were to tap the 5v digital "HS Data" discriminator feed in the radio, what's the best way to pump that into UniTrunker? Could I hook it up to Audio In like any other discriminator tap? I would guess so.

But what if we wanted to make the UniTrunker processing load lighter.. and free up the audio in for voice recording?

Could I pack it into a stream of bytes and send it down a COM port to UniTrunker? Is this similar to the CC stream on Unidens/GRE, or is there more processing done first?

Is there any mode for UniTrunker to receive a 57600bps (51200 sample bits per second) serial stream as discriminator feed?

I like the idea of freeing up the analog audio input and related processing.

 

[GroundLoop]

At the risk of monopolizing the UniTrunker release thread to continue my crash course in low-speed digital.. I see there are devices for sale called "bit slicers" that take 2 or 4-level FSK and convert it into serial bitstreams:
RS-232 Interface
This sounds very much like the idea of taking the HS Data bit going into MaxTrac's CPU and feeding it to UniTrunker. Is there already support for this, or does UniTrunker want the raw audio only?

It would be easy to take an Arduino, oversample this digital line, pack it into bytes and send it via USB to a COM port on the PC. No Audio involved, digital only. Beneficial or pointless?

 

[wa8pyr]

it might be easier to compile just having the text in bold when its active and not bold when stopped, then fade out

Actually, I'm still looking for the immediate drop as soon as the channel grant vanishes, or at least a way to choose between "instant" and "fade-out." The fadeout just makes the screen too busy and confusing, especially when looking at the display with a sideways glance to check an active talkgroup.

 

[elitedata]

Agreed.
However, id like to see a choice of both features.
The one you mentioned and bold when its active and not bold when its inactive then fade, so i can see the last frequency, TGID and ARID of the last transmission in case i happen to miss viewing it by a few seconds.

 

[Bote]

Isn't one of the "alert" features to blink the talkgroup or unit id bold? Other choices include various sounds. Would this conflict with that?

 

[scottbailey]

Agreed.
However, id like to see a choice of both features.
The one you mentioned and bold when its active and not bold when its inactive then fade, so i can see the last frequency, TGID and ARID of the last transmission in case i happen to miss viewing it by a few seconds.

This is an important point. If you make the grant disappear immidiately, you won't be able to see what you were listening too during a brief transmission. I think what maybe you are both looking for is more of a single scanner-style display as to what you're hearing.

In fact, is the entire list of channels on the system really necessary? On my local system, with 20-something channels on one site - and the erroneous extra channels UT sometimes picks up - my history is always scrunched to the bottom. Maybe put the entire LCN list on a separate tab and just make a scanner-style display (or two+ if you have more than one voice receiver) at the top - or even optionally as a standalone window, a miniature version of the channel list only showing active channel grants, and then of course the history as-is but now with more real estate.

Or at least, simply put, an option to only show channel assignments and not the whole list of channels, many of which are sparsely used except during peak times/major events.

 

[Bote]

In fact, is the entire list of channels on the system really necessary?

I find it useful and since it is already there I vote to leave it in. If it moves to a stand-alone window, fine, but don't remove the feature. Some system managers actually rely on it to gauge system loading at a glance, and there can be other not-so-obvious benefits to it as well.

Providing choices increases program complexity, but satisfies a wider user base so I vote for switches that can be configured by the user for different display modes.

 

[scottbailey]

I find it useful and since it is already there I vote to leave it in. If it moves to a stand-alone window, fine, but don't remove the feature. Some system managers actually rely on it to gauge system loading at a glance, and there can be other not-so-obvious benefits to it as well.

Providing choices increases program complexity, but satisfies a wider user base so I vote for switches that can be configured by the user for different display modes.

If you look below that quote, I was advocating to keep it - but on a standalone tab. I agree that it is useful information that should not be removed, however I don't believe that the entire list is particularly useful on the main monitoring display - which is where it is now.

For most it is probably not an issue, however on large systems, it really minimizes the real estate available for the history - which can scroll pretty fast on said large systems, even with affilliations turned off.

 

[GroundLoop]

I'd love to see the Channel display in general include the "Listening" pane from the Receiver.

These are all the Calls going on right now, in the list of channels.
and HERE is the one your receiver is currently tuned to. And the TGID/UID priorities that made it so.
(And maybe you can click on any call to listen to switch to that TGID instead?)

From a display perspective, what if the calls vanished from the active channel list immediately (no fade), but they DIDN'T appear in the Call History until the END of the Call.

So you'd see a call appear in the channel list first, and when it ends (changes Radio ID) it would move to the Call History. So, if you blinked-and-missed-it, you'd see it appear in the list with a timestamp, and possibly a duration (which is now known since the call is finished). Hm.

 

[elitedata]

If you look below that quote, I was advocating to keep it - but on a standalone tab. I agree that it is useful information that should not be removed, however I don't believe that the entire list is particularly useful on the main monitoring display - which is where it is now.

For most it is probably not an issue, however on large systems, it really minimizes the real estate available for the history - which can scroll pretty fast on said large systems, even with affilliations turned off.

i concur.
yes, i would like to see the option to have two windows for each instead of it being combined into one window, totally agree about the screen real estate being limited with this.

 

[Jay911]

I watch the channel list more often than I do the history - IMO it needs to stay where it is.

There are times when I want to see channel activity and history at the same time, so the current setup works well. Splitting it up would not work well for me.

Perhaps for those who only want to see history, a separate history tab could be an option.

Or, another option would be to make it more like ZoneWatch. Each channel in a site is a multi-line (I'm thinking 2 lines) box, with RID and GID each on separate lines. An entire site takes up a strip only 2 lines high, but the entire window wide, on the screen. Even if Rick went to 4 lines (L1: LCN & freq, L2: Ctrl/service type (i.e. "Emg", "Ptch", etc), L3: Source, L4: Call Type (I or G) and Target), that would still cut down on the amount of real estate used.

 

[GroundLoop]

One thing I do to monitor multiple systems is "slim" the window down by removing many of the columns, then make it narrow so I can fit them side-by-side in limited space. It would be neat if UniTrunker could remember which columns were deselected for the next startup. It always defaults to all-columns-enabled.

 

[Jay911]

Here's a visual depiction of what I was thinking about for the "top half" of the activity screen.

Maybe if channels > 10, you add a second (third if >20, etc) row.

Hm, that's shrunk down a bit, but if you squint, I think you get the idea.

 

[scottbailey]

I watch the channel list more often than I do the history - IMO it needs to stay where it is.

There are times when I want to see channel activity and history at the same time, so the current setup works well. Splitting it up would not work well for me.

Are you really watching the empty LCNs? Unless you're the system admin, do you really care, for casual monitoring, which LCN/freuquency the channel assignment is on? Or do you really just need to see the entire list of channel grants (I'm not advocating removing the LCN and frequency, just pointing out that the empty ones without traffic aren't particularly interesting during casual monitoring).

Perhaps I wasn't clear on what I was suggesting:

Maybe put the entire LCN list on a separate tab and just make a scanner-style display (or two+ if you have more than one voice receiver) at the top - or even optionally as a standalone window, a miniature version of the channel list only showing active channel grants, and then of course the history as-is but now with more real estate.

Or at least, simply put, an option to only show channel assignments and not the whole list of channels, many of which are sparsely used except during peak times/major events.

[Scanner Style Display (could be a separate small window)]

[List of active channel grants - essentially the current channel/lcn/frequency list but with inactive lines omitted]
[History as it is now]

On my local system, there are 20+ channels listed, but usually only 3-5 active at a time. I can resize that portion of the window, but then I don't see the activity on the lower channels, which on my local system, the frequencies most used are at the bottom of the list.

 

[Jay911]

Are you really watching the empty LCNs?

No, of course not. However...

Unless you're the system admin, do you really care, for casual monitoring, which LCN/freuquency the channel assignment is on?

You bet I do. If I'm trying to figure out the LCNs for an EDACS system, I will watch what LCN is active on Unitrunker while I scan conventionally with another scanner.

Also, some of us who use Unitrunker are system admins. Just because you don't use a feature doesn't mean everyone else doesn't.

On my local system, there are 20+ channels listed, but usually only 3-5 active at a time.

Sounds like you have way more frequencies allotted than you should have received from the FCC, then. The system(s) I monitor go through all 8 to 16 channels in less than a half-minute.

EDIT: Just thought of another benefit to having all the "empty" LCNs on the screen. Without them, you don't know how many LCNs a system has. To some of us, that's an important feature. When a channel grant occurs, if Unitrunker doesn't have that channel in its site info, it will add (display) it. I definitely don't want it to remove (not display) it once the call on that frequency is over.

Furthermore, if I want to edit a talkgroup or radio ID, on the system activity screen, I just have to double-click on it; on the history log below, I can double-click on it, but more often than not, I have to chase it because other radios' affiliations, grants, and deaffiliations are pushing it further down the log file.

Ultimately the situation is - your monitoring environment is not the same as my monitoring environment, and it does no good to either of us if the other gets his way (and things get deleted from the screen). So Rick should leave it as it is.

 

[scottbailey]

You bet I do. If I'm trying to figure out the LCNs for an EDACS system, I will watch what LCN is active on Unitrunker while I scan conventionally with another scanner.

That, I would argue, is not "casual monitoring", as my presumption was predicated on - that, and you (or the reader) not being the system admin - both of which I specifically mentioned. But it does bring up a good point - my suggestion that the full LCN list be moved to a separate tab assumed that it would be informational rather than live, and you may have raised a use case where that doesn't work. It sounds like, for my suggestion to work at all for you, the separate tab would have to show "live" data, as opposed to what I assume is at least somewhat static reporting data when you look at users/groups in the tabs in a System object).

Also, some of us who use Unitrunker are system admins. Just because you don't use a feature doesn't mean everyone else doesn't.

Just because some of those who use Unitrunker are system admins doesn't mean everyone else needs to see the same information in the same way :wink: I say that half in jest because you did raise some valid points, but I still think I did as well.

Sounds like you have way more frequencies allotted than you should have received from the FCC, then. The system(s) I monitor go through all 8 to 16 channels in less than a half-minute.

I'm no expert in the formula that is used by APCO/FCC to determine how many frequencies to grant municipalities, but I would guess that peak usage would be a more important factor than an average or anecdotal snapshot like I gave. This site is on an urban system with over 15,000 users primarily in emergency services, and, as we've unfortunately seen in at least a few documented cases, bonks can cost lives. During peak times or major events, the system is quite active.

EDIT: Just thought of another benefit to having all the "empty" LCNs on the screen. Without them, you don't know how many LCNs a system has. To some of us, that's an important feature. When a channel grant occurs, if Unitrunker doesn't have that channel in its site info, it will add (display) it. I definitely don't want it to remove (not display) it once the call on that frequency is over.

I've tried to make it clear several times that I never advocated getting rid of this valuable info - only moving it to it's own tab to increase real estate for the history. You could make the same argument for talkgroups and RIDs - after all they are off the screen as soon as the history scrolls by and gone entirely after two hours - except that you can bring up the system and look at the group and user tabs.

Furthermore, if I want to edit a talkgroup or radio ID, on the system activity screen, I just have to double-click on it; on the history log below, I can double-click on it, but more often than not, I have to chase it because other radios' affiliations, grants, and deaffiliations are pushing it further down the log file.

I can completely relate to this!:lol: It's almost comical sometimes chasing the id up the list!

Ultimately the situation is - your monitoring environment is not the same as my monitoring environment, and it does no good to either of us if the other gets his way (and things get deleted from the screen). So Rick should leave it as it is.

I'm glad it's not my job to figure out how to please all Unitrunker users, which of course is never possible, so it will be up to Rick whether he finds a way to make improvements in this area that satisfy both distinct and valid use cases, or to ignore the rants, raves, and requests entirely.

 

[SCPD]

Jay/Scott - if the history tab is scrolling out from under your mouse pointer, uncheck the auto-scroll.

Initially the call activity and call history panels were on separate tabs. Users complained of frequent toggling between the two tabs. That's how we got to where we are now.

I do need to finish the work I started on persisting window layout information - including grid columns and window size and placement.

 

[scottbailey]

Jay/Scott - if the history tab is scrolling out from under your mouse pointer, uncheck the auto-scroll.

Initially the call activity and call history panels were on separate tabs. Users complained of frequent toggling between the two tabs. That's how we got to where we are now.

I do need to finish the work I started on persisting window layout information - including grid columns and window size and placement.

I do...but usually think of that after chasing the talkgroup up the history. The feature works as it should, it's just kind of comical sometimes.

The screen layout works OK for me as is, but it sure would be nice if it was a) more immidiately apparent which talkgroup you are listening to, and b) if the history could gain some real estate without getting rid of the LCN list. And I'll leave it at that