Unitrunker 10th Public beta

[SCPD]

Download is here.

 

[SCPD]

The program internally handles fleetmaps differently. The AFS file is now obsolete and no longer needed. You can find the fleetmap stored inside the SYS file.

 

[bonus1331]

Update Log?

Rick,
I'm at work and will download tonight, but can you give an idea on what's been updated?
Any chance you had an opportunity to work on the below?

http://www.radioreference.com/forums/showthread.php?t=61169

Thanks for a great program.

 

[ScanWorcester]

I had brought this up in the 8th beta thread, but didn't receive any replies:

I'm hearing at least 3 of the trailing EDACS beeps. It tracks fine, but those beeps can get annoying.

EDIT: I see what's happening. I'll get the EDACS beeps until the next person in the transmission picks up the conversation. This is understandable, but quite annoying. Any ways around this?

Is there a way to implement a "mute" function to cap the voice channel at the end of the actual tranmission before the trailing system beeps pick up? I'm surprised this wasn't brought up before by other EDACS users, unless I'm just missing something.

 

[blah546]

I brought it up before and the short answer was no. Unitrunker doesn't hear the beaps so it doesn't know the transmission is over because really it is still active on the control channel.

However that being said watching the behavior of 3 other scanners would suggest that there is something somewhere in the control channel saying that only those beeps are occuring. For example I've seen scanners intentionally not begin receieving another talk group when that talk group is at the end of a transmission and still being shown as active in unitrunker, presemably beeping away. The scanner couldn't have heard the beep because it was on a different channel listening to a different talk group. To me that suggests somehow the scanner knows not to scan this new talk group since the transmission is over. Am I making any sense?

That being said I've certainly gotten used to the beeps to the extent that they don't bother me in the least and I kind of miss them when they're gone.... Also I'm not sure if unitrunker has any built in talk group delay but the beeps certainly provide that.

 

[FLANO]

Rick,

Here is a snapshot of the logged systems screen from 0_1_0_38 and 0_1_0_41. Perhaps I didn't clearly explain what I saw differently, so a picture is worth thousand words, as the saying goes....

Is this by design not to see the logged systems that have been previously worked?

 

[SCPD]

a picture is worth thousand words, as the saying goes....

Yikes. I have no idea why it's doing that ... I'll see what I can find.

 

[SCPD]

Is there a way to implement a "mute" function to cap the voice channel at the end of the actual tranmission before the trailing system beeps pick up?

Yes ... but the program would have to be monitoring the voice channel at the time the beeps occur to detect and mute them. That implies a single radio setup where the radio supports computer control and provides discriminator audio. That combined / integrated capability is not yet available. You would also lose true priority scan but that's the price you pay for keeping your sanity.

Someone wrote a program called "GE-Ease" some time ago that filters out the beeps - might provide some interim relief.

 

[SCPD]

Any chance you had an opportunity to work on the below?

I'm just now getting to that (testing scanner control on Windows 9X/ME) plus a few other things.

 

[SCPD]

I'm at work and will download tonight, but can you give an idea on what's been updated?

Sure. I need to scrape together a list of changes. Most significant was mentioned above - fleetmap support. If you use this feature (and I've done my job right) you won't notice a thing. Some other changes ... EDACS tweaks, fixes for controlling Icom PCR radios (like those $50 puppies on eBay). I need to run some proposed changes up the flagpole to get some priorities on what to chase next.

 

[Comint]

so a picture is worth a thousand words, as the saying goes....

I posted about the same problem with MPT1327 systems and 0.1.0.40 here.

http://www.radioreference.com/forums/showpost.php?p=459798&postcount=38

although I didn't include a second image.

 

[randyK]

Rick, great program, Thanks. I am running unitrunker on a simulcast motorola type II system which has a lot of simulcast noise between sites. On newer versions of unitrunker when the squelch closes for a split second on the voice radio during a conversation, the voice radio immediately goes back to the park frequency & will not go to the voice channel on the trs even though the talkgroup is still active. If another radio ID keys up on same talkgroup, it will go back to the voice channel. The last version that doesn't do this is version 0.1.0.34. It seems to have a second or 2 delay on the voice radio after the talkgroup activity has ended on the data channel radio. That version works flawlessly in my situation. I wonder if there is anyway to add an adjustable delay setting or something. Thanks again,
Randy

 

[NDRADIONUT]

Flagpole

" I need to run some proposed changes up the flagpole to get some priorities on what to chase next."


You know my flag says affiliation logging.................LOL

 

[ScanWorcester]

Someone wrote a program called "GE-Ease" some time ago that filters out the beeps - might provide some interim relief.

Any idea on where to find this? I see that it was brought up in the 4th beta thread, but no reference. Are you sure that this is the correct spelling/name? I searched through RR and Google and didn't find a thing! I'm very interested in trying it out.

 

[slicerwizard]

Yes ... but the program would have to be monitoring the voice channel at the time the beeps occur to detect and mute them. That implies a single radio setup where the radio supports computer control and provides discriminator audio. That combined / integrated capability is not yet available. You would also lose true priority scan but that's the price you pay for keeping your sanity.

Correct me if I'm wrong, but when those beeps start, don't the late entry announcements on the control channel stop? Couldn't you have a (possibly user-defined) timeout value that would force the voice receiver to mute/park when the late entries stop? I'm not suggesting they could be completely muted, just limited to one or two. If you're already doing this, please disregard.

 

[firemedic2150]

I have a problem with UniTrunker that is really driving me nuts, every time I shut down I do a save and then exit, but about one out of every 5 times I start UniTrunker all my info is gone, after three times of this happening and me manually retypeing info its getting real annoying.

Mark Mc.

 

[SCPD]

Here is a summary of changes.

Folks testing out their new PCR100's resulted in good feedback for the PCR series of radios.

Motorola fleet maps are handled in a different way inside the program. If you have a Type I or hybrid system - make sure your fleet map behaves as expected.

EDACS logging contains much more detail.

Obscure typo fix for MPT1327.

Volume control - for those models that support it - is slowly being added. This can be seen in the Tuner program.

Open issues ...

Multiple reports of sporadic crash and/or data loss (as mentioned above).

[V]iew -> ystems no longer displays neighbor systems (like networked MPT1327 and OmniLink) - also described above.

Folks running Windows 9X/ME report no success with scanner control (open, pending).

Numerous requests but ... the crash issue gets top billing!

-rick

 

[SCPD]

Any idea on where to find this? I see that it was brought up in the 4th beta thread, but no reference. Are you sure that this is the correct spelling/name? I searched through RR and Google and didn't find a thing! I'm very interested in trying it out.

I can't find it. Perhaps someone has a copy of this roughly 10 year old freeware program.

 

[wise871]

Rick,

Here is a snapshot of the logged systems screen from 0_1_0_38 and 0_1_0_41. Perhaps I didn't clearly explain what I saw differently, so a picture is worth thousand words, as the saying goes....

Is this by design not to see the logged systems that have been previously worked?

Was there ever a fix for this? I have the same issue and had to go back to 0_1_0_38 to see my previous systems.

 

[SCPD]

Was there ever a fix for this?

For you, FLANO, and comint ... this has been found and fixed for the next release. If you use the "Path=" feature in the CFG file, you will definitely see this problem. Next release will also fix a problem affecting a very tiny number of EDACS systems.

Correct me if I'm wrong, but when those beeps start, don't the late entry announcements on the control channel stop? Couldn't you have a (possibly user-defined) timeout value that would force the voice receiver to mute/park when the late entries stop? I'm not suggesting they could be completely muted, just limited to one or two. If you're already doing this, please disregard.

You just described the call progress timer. Giving the users an adjustable inter-message call timer - perhaps on a per protocol basis - would be ideal. So far no one has asked for this so I haven't bothered.