Unitrunker - needs a resizing or scroll functionality please

[FLANO]

Rick,

Please see the attached. I've been watching the Maricopa Co system and you'll notice that I'm just about out of room on the bottom of the screen to display any information.

Can you add a capability to resize the distribution of the dislayed information or possibly a scroll bar functionality that allows one to scroll through the available information, normally displayed on the bottom of the screen?

Just thinking about something to add to the updates to the software as you work on it.

Also, you'll notice that the system still does not recognize all of the bit messages for each TG. See TG 43440 and 43447. 43447 was a derivative of the 43440 TG, but is not a real TG. I experienced this with several TG's on this system.

Thanks again,

John
SE of Tucson

 

[DaveNF2G]

Have you tried PgDn?

 

[Go-24]

Wow thats a lot of frequencies in addition to screen size it would be great to be able to adjust column widths and spacing. What we need is a Windows GUI, if only I were a programer.

 

[Jay911]

Rick's going to put it into a Windows GUI eventually - making a new version of T4Win with the guts of Unitrunker within it.

Does your system really use all those frequencies on just one site? My Unitrunker operation from time to time still throws a few invalid freqs in the channel display every few days, when the signal goes bad. Left unchecked for long enough (i.e. if you don't delete the bad data), it ends up getting as bad as your display or worse.

 

[Forts]

Hmmm.... If you look at the database entry for system 521C, it looks like the most channels any of the sites use is about 15...

http://www.radioreference.com/modules.php?name=RR&action=sysid&sysid=521c

 

[SCPD]

Hi John;

I've been watching the Maricopa Co system and you'll notice that I'm just about out of room on the bottom of the screen to display any information.

What you're looking at is really a feature of Windows - not Unitrunker. Maximize the window - it should expand just enough to eliminate the scroll bar. If that doesn't work, click on the top-left corner and wade through the display options for the command window. I think the screen size is 80 columns by 48 rows.

Also, you'll notice that the system still does not recognize all of the bit messages for each TG. See TG 43440 and 43447. 43447 was a derivative of the 43440 TG, but is not a real TG. I experienced this with several TG's on this system.

Go to [V]iew -> Pr[o]ps to see what type of system the program thinks it has. There's a small window of time after signal acquisition where the program is still determining the type of system so as to apply Type I vs. Type II treatment of the group IDs. (That's actually been fixed for the next release).

About those extra channels: from the screenshot - looks like you've been monitoring other systems besides Maricopa. When you jump from one control channel to the next, it takes some time for the program to detect this. When it acquires the new control channel - it will likely add it to the system's channel list. This happens before a change in system has been detected. There may even be calls in progress on the new system that are added before the program has detected a change in system. Those channels and group ids will also get added as "junk" data to your system. The safe thing to do here is to exit the program before tuning the radio to a different control channel and then re-start the program.

This is only an issue when jumping to a control channel that is the same type (eg. EDACS to EDACS or Motorola to Motorola). Cleaning up the channels is easy - just delete the HZ file and let the program re-discover all the channels. Cleaning up the GID and RID file isn't as easy. If you know the group IDs that you've edited by hand (and the rest came from the RR DB download) - keep those and delete the rest (which can be had by requesting another RR DB download). You can do this in Notepad.

-rick