UniTrunker 16th Public Beta

[SCPD]

Fixes some loose-ends missed in the previous release.

For the PSR-500, EDACS and LTR remain a ways off.

I'll look into single radio operation (both voice and data) when time permits.

http://www.unitrunker.com/

Click on the downloads link and look for the .54 release.

 

[Einstein]

Up-Grade

If I wanted to up-grade to the newest version, do I have to delete the previous version or can I just load the new version over the old one? If I need to delete the previous version what files will be lost?

Thanks

 

[Viper43]

yeah, you do have to use Add/remove programs to remove the old file before installing the new version, it tells you that if you try and install it. You shouldn't lose data, but you can change the location it installs the new file. Or you can just move the data files before unistalling if you want.

V

 

[PiccoIntegra]

All fixed on this end, thanks Rick!

 

[IndyEmsGuy]

I am new to digital scanning and have had my PSR500 for about 3 weeks now. I would like to use Unitrunker but don't know much about it. Is there a user guide or manual somewhere that explains how to use it and what to do with it?

Thanks,

Kris

 

[Viper43]

I think the 500 allows you to use a connection on the scanner so you don't have to tap the IF discriminator to get te signal for Unitrunker. Check your manual for the 500. If so all you do is connect that to the Mic in or audio in on your computer and go from there with the program. As Unitrunker (the dude programming the software) says, run Unidcope first to make sure your getting the right levels and signals.

V

 

[SCPD]

I am new to digital scanning and have had my PSR500 for about 3 weeks now. I would like to use Unitrunker but don't know much about it. Is there a user guide or manual somewhere that explains how to use it and what to do with it?

Welcome. The primary purpose of the program is to see activity broadcast over the control channel. There's an HTML document included with the installation but it does not describe how to use the PSR-500.

For your radio ... there is an example configuration here. That link also provides the keypad sequence to turn on the CC dump feature. Connect the computer and radio using the factory supplied cable. Run the program, set the [R]eceiver options to match your radio (again, refer to the link above). You don't need to run Uniscope since you aren't using a discriminator tap. Tune the radio to an active control channel. With a decent signal, you should see the program (1) identify the system by type and system ID and begin to accumulate information like channels, talkgroups, and radio ids based on call activity. You can attach labels to the groups and radio ids.

I see you're a premium subscriber. Once you've found a system, you can download talkgroup data from the RR DB. Look under [F]ind -> ystem -> [D]ownload. Fill in your RR username and password along with the type and system ID of the system you want to download. If it happens to be the currently monitored system, you'll likely see labels for some of the more active groups appear along with the system and site names.

The program remembers this information and retains it for the next run.

Understand that the radio can only provide control channel information while tuned to the control channel. When the radio is in Scan mode, it will leave the control channel and tune to a voice channel. To Unitrunker, this appears the same as a loss of signal. That's why I suggest using the Tune mode (press [Tune] and key in the frequency). You can also use the TSYS [Analyze] option if the system is already programmed into the radio but I forget the keypad sequece to do so.

There's a lot more to tell but this should get you started.

 

[Einstein]

Thanks Viper43 for the info.

 

[APX8000]

Any word on when Unitrunker will support EDACS system decoding through the PSR-500 ?

 

[SCPD]

Any word on when Unitrunker will support EDACS system decoding through the PSR-500 ?

None yet. You'll need a discriminator tapped radio for the time being - but you can use the PSR-500 as a voice radio.

 

[gmclam]

What's up?

I am experiencing something with UniTrunker that I am not sure is correct or what. Hopefully there is a good explanation.

I am monitoring a Motorola system (3 actually but 1 at a time). Normally there is a "G" under the "T" column and the talkgroup ID gets logged onto the lower half of the screen. Today I am seeing transmissions with an "I" under the "T" column, and they do not get logged. I used a separate scanner to navigate to the voice channel and verify that these are analog conversations.

Another thing I notice is that the ID does not match exactly for the above transmissions. For example UniTrunker will display 46250 and the scanner receives 46256. In another case Unitrunker displayed 46168 and the scanner displayed 46160.

 

[SCPD]

Today I am seeing transmissions with an "I" under the "T" column, and they do not get logged. I used a separate scanner to navigate to the voice channel and verify that these are analog conversations.

That's an I-call or radio to radio call. The ID to the left of the "I" is another radio ID.

 

[gmclam]

That's an I-call or radio to radio call. The ID to the left of the "I" is another radio ID.

I find it interesting that the ID to the left of the I is in a range of "unused"/non-identified talkgroups. Is there a way for UniTrunker to log these transmissions?

 

[Jay911]

Radio IDs will be independent from talkgroup IDs. In a Motorola Type II system, radio IDs begin with a 7 and can range from 1-65534. Talkgroup IDs in the same system begin with an 8 and can range from 1-4095 (IIRC); multiply by 16 to get the values you see on Uniden scanners and the like (from 16 to 65520). So you could have a talkgroup 16400 (actually 801025), a radio 16400 (actually 716400), etc.

 

[gmclam]

I'm missing something

Radio IDs will be independent from talkgroup IDs. In a Motorola Type II system, radio IDs begin with a 7 and can range from 1-65534. Talkgroup IDs in the same system begin with an 8 and can range from 1-4095 (IIRC); multiply by 16 to get the values you see on Uniden scanners and the like (from 16 to 65520). So you could have a talkgroup 16400 (actually 801025), a radio 16400 (actually 716400), etc.

Can you supply the formula for getting these values? What I am reading here is that it seems the values transmitted are not what is displayed; and a different formula is used, depending on the field, to get to the displayed value.

There are two "ID" columns on UniTrunker - it shows (from left to right) Frequency, Priority, Group Text label, Group ID, "T", Radio ID, Radio Text Label, CT. The values I see which do not get logged are under the Group ID column, immediately to the left of the "T" column (when it displays I instead of G). I'm not talking about "radio IDs" here.

 

[Jay911]

Actually, you are talking about radio IDs here. When Unitrunker shows an "I" in the "T" column (T = Type, IIRC), the value shown under "Group ID" is a radio ID because that is a direct radio-to-radio call, not involving a talkgroup at all. (I = Individual Call.)

I only gave a little demonstration of the 8xxxxx and 7xxxxx formats to help illustrate that the same numbers can be "used over again" in both talkgroup IDs and radio IDs.

If you see an I-call with a source (Radio) ID of 12345 and a target (Group) ID of 23456, it's not going to talkgroup 23456, it's going to radio 23456. T4Win used 'source' and 'target' nomenclature, if I recall correctly; it's a bit better description, IMO, than 'radio' and 'group', especially in this case.

When a Motorola system's control channel announces a call, be it a group call or an individual call, it actually "speaks" in hexadecimal. So if radio 12345 was calling talkgroup 23456, it says something similar to "3039 G 5BA0". (That's not exactly how it goes, but it serves to illustrate the point.) If a radio asks for an individual call/private call to another radio, the G is replaced with an I. So you could theoretically see the same thing, except with an I in it - "3039 I 5BA0" ... that would mean radio 12345 was calling radio 23456 directly. Has nothing to do with talkgroup 23456 at all.

The values showing up under the "Group" heading during I-calls are logged (I'm reasonably sure they are), just not in the GID file. Since they're actually radio IDs, they belong (and are) in the RID file.

gmclam - change your display settings to have the system show you "Motorola" style IDs (under the "Options" menu) and you'll see the numbers in the 7xxxxx/8xxxxx format I described. Other than hex, that's the "natural" way Motorola radios see these values internally.

Unitrunker (Rick) - Am I on target with how Unitrunker handles this?

 

[cg]

You are talking about Radio IDs if it is an "I" in the call (T)ype column...

The two columns are each labled "ID" in the newest Unitrunker (I am not sure about older versions)
The first "ID" column is used for the Talkgroup ID when it is a Group call. It is also used for the radio ID when it is a "I" type call. This is a private call, I-call, whatever you would call a unit to unit direct conversation over the trunked system. There is no talkgroup ID involved. You should first see one ID and then the other when they reply.
As far as the values being transmitted not being what is displayed, it is transmitted in binary code. When it gets converted to decimal, it is as it is shown with the exception of the 7 being removed on the radio IDs. Since every radio ID is 7xxxxx, the 7 is not needed in the display.
The talkgroups have the 8 from 8xxxxx removed and they are multipled by 16 because that way they match the Trunktracking scanners.

chris

 

[gmclam]

Thank you

Thank you to the last two posters. I am definitely aware of the fact the codes are sent in hexadecimal, and I am a programmer, so no problems there. That's why I wanted the formula so I could understand this a bit more.

I changed the Options to Motorola as you suggested, and now understand what you are saying. Unfortunately I've set it back to Decimal so it matches the scanners and all my documentation.

None of this stuff seems to be explained anywhere among UniTrunker documentation. In the past I've also inquired about knowing the protocol (at the lowest level) for which MO (and other) trunk or control channel data is sent. In other words, the stream that is parsed by the scanner and/or programs like UniTrunker; but have had no luck. As I learn each of these elements which is new to me, it makes me wonder how much more I do not know.

Thanks again.

 

[DaveNF2G]

The next generation of trunktracking software should probably have a dynamically reconfigured display based on the exact nature of the traffic being received. Then when an I-call is received (perhaps when the user chooses to lock onto it), the column headers would automatically change to the proper designators. That might alleviate some of the confusion about this stuff.

 

[bpsmicro]

So today I decided to finally update my UniTrunker install to the latest build, and it seems the unitrunker.com site is down. What luck. :-(
Is there a mirror download link for the latest build somewhere (or word of when the site will be back up)?

Thanks;
Brad.