Radio IDs for Conventional P25 Channels?

[PeterGV]

Just got a PSR-500, and have been trying to play with the much touted "radio ID" feature.

Just one problem: I'm not seeing any radio IDs displayed for conventional P25 channels.

Is the display of Radio IDs only supported for trunked systems??

Peter
K1PGV

 

[rdale]

The RID is pulled from the system's control channel, aka trunked only.

 

[PeterGV]

Thank you, rdale.

Sigh... That's unfortunate. Like the NAC, the Radio ID is just SITTING in the P25 message (on conventional channels) waiting to be picked-up and displayed.

Maybe GRE will be nice enough to add this feature some day.

Oh well... I *still* like the radio.

Thanks again,

Peter
K1PGV

 

[Eng74]

I agree that it would be great if they could add the radio id's to coventional systems even non-P25's. Kern County Fire has it. They can tell who hit the panic button be it a hand held or on a unit.

 

[N_Jay]

In the non-P25 world, there are many different ID protocols.

 

[Eng74]

I should have said non-digital, non-trunked. I always think digital and or trunked when I see P-25.

 

[scanfan03]

I should have said non-digital, non-trunked. I always think digital and or trunked when I see P-25.

Like NJay said there are too many non-digital protocols for Radio IDs. The only one that could be supported the easiest would be non-trunked P25 because it is one standard. Using your example for Kern county fire it would depend on what make radio they use for you to decode the radio ID (Kenwoods and Motorolas aren't interchangeable).

 

[DaveNF2G]

NJay is right. MDC1200 is popular for analog, but here in NY, the home of General Electric, the State agencies use G*Star instead.

I would be willing to pay a small fee for modular firmware enhancements like that. One module for MDC1200, another module for G*Star, maybe one for DTMF, etc. Then everyone could buy those protocols they need without inflating the price of the scanner for folks who don't need those features.

 

[N_Jay]

And who is going to pay for all the testing to make sure one module does not interfere with another, or worse yet cause completely unrelated bugs?

 

[WayneH]

Sigh... That's unfortunate. Like the NAC, the Radio ID is just SITTING in the P25 message (on conventional channels) waiting to be picked-up and displayed.

It sounds simple but it's more complex to add than one would think. Because of memory limitations you aren't going to see it in GRE's current line of scanners.

 

[PeterGV]

It sounds simple but it's more complex to add than one would think.

Your comment prompted me to refresh my (ever hazy) memory and look this up. And you're entirely correct: The NAC code is transmitted in the P25 CAI header data unit as well as at a fixed location in the voice code words.

The Source ID is in the voice code words super frame, but the location can change based on the format of the message.

So... You're right: Not so simple. Especially not if your already limited in terms of memory.

Thanks for providing the incentive for me to look this up,

Peter
K1PGV

 

[motoman30]

It sounds simple but it's more complex to add than one would think. Because of memory limitations you aren't going to see it in GRE's current line of scanners.

GRE has no excuse for not engineering extended/extra memory into their current and past products. With the cost of memory so cheap, why would they go the cheap route?

Example: Motorola uses an 8MB flash memory in XTS/XTL 2500/5000. I ordered the flash ROM used in the ASTRO25 line for a prototype radio (Intel GE28F640W18BD60). Even at prototype quantity (100 pcs) it cost $1.57USD per flash ROM, plus shipping and wire-transfer fees. (About $3.20USD/chip in the end.)

GRE could easily increase the prices of their scanners by a buck or two to compensate for this and their customers wouldn't complain. Costs go down when you order in larger quantity!