PSR-500/600 PC-IF trunked decoding

[rdale]

Incorrect... The PSR500/600 works BETTER than the Pro96 with Pro96Com because you can also hear the audio while getting info...

 

[iMONITOR]

Incorrect... The PSR500/600 works BETTER than the Pro96 with Pro96Com because you can also hear the audio while getting info...

Nice! Last I had heard from Mike, it didn't work. Something to do with the USB cable. Maybe he updated his software.

 

[rdale]

Yep, back in November I think...

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

 

[mikey60]

Nice! Last I had heard from Mike, it didn't work. Something to do with the USB cable. Maybe he updated his software.

I updated it shortly after the PSR-500 was released to work with that radio. It still only does 9600 P25 though, no 3600 Motorola or EDACS at this point.

Mike

 

[iMONITOR]

I updated it shortly after the PSR-500 was released to work with that radio. It still only does 9600 P25 though, no 3600 Motorola or EDACS at this point.

Mike

Awesome! I guess I need to get out more.

 

[MNRotrMedic]

Does the capability to analyze (a la Pro96Com) Mot 3600/LTR/EDACS exist in the PSR500/600 or was that limited to 9600 like on the Pro-96? I'l love to have a monitor for other systems buti don't have the faith in myself to tap one of my scanners. Seems like performing experimental surgery on my own kid...

 

[rdale]

All trunked can be analyzed in the 500.

 

[mtindor]

Does the capability to analyze (a la Pro96Com) Mot 3600/LTR/EDACS exist in the PSR500/600 or was that limited to 9600 like on the Pro-96? I'l love to have a monitor for other systems buti don't have the faith in myself to tap one of my scanners. Seems like performing experimental surgery on my own kid...

On the PSR-500, using the PC/IF cable instead of tapping the scanner, Unitrunker supports Mot 3600. It will support LTR/EDACS as soon as GRE issues a firmware update that includes the fix for some problems with their EDACS/LTR output. I am unsure if Unitrunker supports 9600 P25 at this time or not.

As already mentioned by others who know more about it, Pro96Com handles 9600 P25 via the PC/IF cable.

So, between the two programs you have all of the options covered (or will once GRE releases updated firmware that has the fix in it).

Mike

 

[DonS]

On the PSR-500, using the PC/IF cable instead of tapping the scanner, Unitrunker supports Mot 3600. It will support LTR/EDACS as soon as GRE issues a firmware update that includes the fix for some problems with their EDACS/LTR output.

EDACS output on the PSR-500 works just fine if you camp on a TGRP in MAN mode. It's in the "analyze" mode (or while tuned to a trunking CC in "tune" mode) that the problem exists. Rick has decided to not support EDACS data from the PSR-500 because that output isn't correct in all radio modes, though it seems to be correct in at least one mode.

I'm not aware of any LTR problems, in any radio mode.

 

[SCPD]

EDACS output on the PSR-500 works just fine if you camp on a TGRP in MAN mode. It's in the "analyze" mode (or while tuned to a trunking CC in "tune" mode) that the problem exists.

Not so, I am sorry to say. Tested - it's broken.

 

[stevolene1]

i think the GRE scanners are very nice, especially the PSR 600, ifs theres anyone on here that would like to donate one to me Id be very grateful, would even give away in return my 2051 to charity

 

[DonS]

EDACS output on the PSR-500 works just fine if you camp on a TGRP in MAN mode. It's in the "analyze" mode (or while tuned to a trunking CC in "tune" mode) that the problem exists.

Not so, I am sorry to say. Tested - it's broken.

Could you be more specific? Maybe with a MAN/TGRP capture that has errors?

To my "untrained" eye, the attached, simple capture from a TGRP in MAN mode looks ok.

I know you've said previously that you had sent some info to be forwarded to GRE, but it appears they don't have it, if such a simple thing hasn't yet been fixed. We know they read these forums, so maybe seeing details here would help them.

 

[SCPD]

I know you've said previously that you had sent some info to be forwarded to GRE, but it appears they don't have it, if such a simple thing hasn't yet been fixed. We know they read these forums, so maybe seeing details here would help them.

They have the info - both the issue at hand and my contact info. If they wish to contact me, I am happy answer questions.

Could you be more specific? Maybe with a MAN/TGRP capture that has errors?

Run the dump side-by-side with ED/Etrunker/EDumper or Unitrunker. It's pretty obvious.

 

[DonS]

They have the info - both the issue at hand and my contact info. If they wish to contact me, I am happy answer questions.

I have it on relatively good authority that they are not aware of any problems with the CC dump for EDACS systems, when camped on a TGRP in MAN mode. It would appear that they have not received whatever you sent previously.

With all due respect, would it kill you to copy/paste in an RR thread (the "PSR-500, EDACS, and UniTrunker" thread would likely be the most appropriate location) the information you sent "in painful detail to one of the GRE testers" ? Or, perhaps post it to the GRE America "Support Desk" at http://greamerica.com/support/ if you don't want to post it on RR for some reason.

Otherwise, we're at a stalemate. You say they know about it, their lack of response seems to indicate they don't. With the present situation, I doubt we can expect any "fixes" any time soon.

 

[WayneH]

I split this off the RS thread with the poll regarding keeping the Pro-96 or getting rid of it.....per request.

 

[SCPD]

I have it on relatively good authority that they are not aware of any problems with the CC dump for EDACS systems, when camped on a TGRP in MAN mode. It would appear that they have not received whatever you sent previously.

Don;
I'm being discrete on this issue because I don't want to offend anyone. The issue was originally reported on or about November 1st. When you work with someone - particularly in the field of software development - you don't flog their mistakes on a public forum. You take them aside, point out the issue, and move on. With that said, given your long standing relationship with GRE, perhaps you can more effectively communicate this issue to the engineer(s) that support this radio. I offer these details in hopes that you will pass this on ...

Here is the central flaw - the EDACS codeword / frame numbers are wrong about half the time (this is the column in the CC dump that alternates between 0 and 1). This wrecks havoc with commands (such as a call grant) that span two codewords. Imagine codewords A1, B1, G1, and G2 where A1, B1 are single codeword messages while G1 and G2 are a matched pair (again, a call grant). The control channel can place A1 and B1 in either the top or bottom half of a frame. It doesn't have this flexibilty with the G1/G2 pair. They MUST be sent with G1 in the upper half and G2 in the lower half of the frame.

Using square brackets to denote a codeword pair, suppose the control channel sent

[A1 B1] [A1 B1] [G1 G2] [G1 G2] [A1 B1]
(messages are often repeated to cope with noise)

The PSR-500 might dump the following ...

A1] [B1 A1] [B1 G1] [G2 G1] [G2 A1] [B1

First, G1 is placed in the lower half of the frame - something that never occurs on an EDACS control channel. Second, G2 now appears in the top half a frame (twice) - also something that never happens. Interpreting [G2 G1] as a call grant places bits for the LCN and radio ID in the wrong locations. Interpreting [G2 A1] as a call grant is just as bad or worse.

Here is what GRE should have done for EDACS CC dump:

Dump both codewords together on the same line of text. That's how they're sent over the control channel - together. Include two additional columns with the count of bit errors. Zero errors means a good codeword. Zero errors on both codewords means a good frame. Reporting bad as well as good codewords has the side benefit of making the % decode rate easier to calculate.

Send me an email if you need more information / clarification for presenting this to GRE.

 

[DonS]

Thanks for the confirmation. That's what I had presumed you meant previously, but I got a bit confused when you said it still did it in all modes with the newest CPU code from GRE.

(I do have a rudimentary knowledge of EDACS trunking, so I understand how incorrect "field" values would screw things up.)

I have seen that behavior in:
F1.0: TSYS Analyze mode, TUNE mode, and MAN mode on a TGRP
U1.1: TSYS Analyze mode, TUNE mode

In U1.1, however, camping on a TGRP in MAN mode doesn't "fail" like that, as far as I can see. It shows consistent 0/1 alternating fields, the decoded "text" appears to match the raw data, and it shows "CRC cail" occasionally. So, it looks like they did hear about and fix the problem in one area, but not in another.

Unless you still see it "broken" in U1.1, where parking on a TGRP in MAN mode still shows bad data?

 

[SCPD]

Thanks for the confirmation. That's what I had presumed you meant previously, but I got a bit confused when you said it still did it in all modes with the newest CPU code from GRE.

I still think that's case. To make sure I'm hitting the right mode, what is the key sequence to place the radio in a mode where it works? I have one EDACS TSYS with one non-existent talkgroup ID in scan list 1 as the only scan object.

it looks like they did hear about and fix the problem in one area, but not in another.

I hope that means there is a forthcoming U1.2 fix because, from my point of view, this isn't usable. Here's why:

This feature is most useful for mapping out newly discovered EDACS systems in Tune mode. Don't force your users to program a TSYS on a system found moments ago. Motorola, P25 and LTR work in Tune mode, why not EDACS?

 

[mtindor]

I still think that's case. To make sure I'm hitting the right mode, what is the key sequence to place the radio in a mode where it works? I have one EDACS TSYS with one non-existent talkgroup ID in scan list 1 as the only scan object.

By Don's description, I would gather:

1. Press MAN
2. Nagivate to the appropriate scanlist where the nonexistent talkgroup TGID is using <- -> arrow keys
3. Nagivate to nonexistent talkgroup TGID using the up/down arrow keys

Why a nonexistent TG? Why not use a wildcard TG. In case it doesn't show anything unless it's on an active talkgroup, you should program a group wildcard as your only TGID then so that it "responds" to all. Or maybe you are using a nonexistent TG for the purpose of making sure it stays on the CC all the time instead of switching to play the audio.

Mike

 

[SCPD]

Or maybe you are using a nonexistent TG for the purpose of making sure it stays on the CC all the time instead of switching to play the audio.

Bingo.

Just tried this ... no work. I see flipped codewords.