P1225 DPL Freqs?

[Thomascattus]

Redid the freqs in a P1225 using RSS S/W but couldn't get it to take the DPL code (122) for the existing system. Does this radio only accept certain codes or is there a trick to get this code in? Thanks T.C.

[Will]

The RSS will only accept DPC codes from the drop down list. Sound as if 122 is not a /\/\ DPL code.

[Thomascattus]

Correct, i'm trying to integrate this into a Vertex fleet. Any way of doing this? Thanks

[HLA]

see if it will let you enter 225 dpl and check the invert box and that will make 122 work also

[laramiecountyCERT]

If the DPL is not in the drop down list it wont let you enter it. I have a few that I tried to do this with and it didn't work.

[Thomascattus]

Nope, it didn't work. But thanks for the info. T.C.

[jackhackett]

122 inverted is 225
equivalent code for 122 is 535
equivalent code for 225 is 536

so 122, 225inv, 535, and 536inv would all be the same... looks like you're out of luck, the 1225 doesn't do any of those :/

[k2hz]

The 83 standard DPL codes that Motorola and everyone supports are not arbitrary. They are based on unique bit patterns that have 8 or 12 NRZ transitions. The additional codes used by some other manufacturers have 16 NRZ transitions and the P1225 was not designed to support these codes.

The codes 122/225 are a 16 NRZ format so not supported. The codes 535/536 are simply non-standard duplicates of 122/225.

The bottom line is that if you need interoperability or don't want to be limited to certain brand and model radios you need to use universally supported PL or DPL codes.

[RKG]

Just to amplify a bit: the limit to the 83 EIA-approved DPL values is not entirely arbitrary, but rather exists for good reason. From Midian: "DCS employs a fxed octal digit 4 as the 18th digit, followed by three octal digits shown in the table above. Code words are 23 bit-long strings: 12 bits of octal code, followed by 11 bits of CRC. Each bit is 7.5 ms, adding up to 172.5 ms per word. While it might appear that 512 codes are possible, only 83 exist, because a code word that is misaligned when serially shifted into the decoder can match a different code word."

[Wowbagger]

I had to do an internal presentation on this subject, so let me add a few things.

First, there is the requirement that to be a valid code word, after adding the Golay error correcting codes, any bit shift of the resulting 23 bit code which has an octal 4 (binary 100) in the middle 3 bits of the word MUST also pass error correction checks - that allows a radio to jump into the middle of a transmission and not lock onto a false code and get spurious errors.

Second, the bit inverse of an error corrected code word, when shifted such that the middle 3 bits are an octal 4, must also pass error correction. This is to allow radios with an inversion in either the TX or RX path to correctly see the codes (remember that in the old days DCS encoders were an add-on board, and depending upon the design of the radio a positive voltage on the input might yield a negative frequency shift of the carrier OR a positive shift of the carrier, and likewise a positive shift of the carrier might yield either a negative voltage on the RX our OR a positive voltage).

Third, codewords that led to long strings of either 1 or 0 bits were avoided - some receivers and some transmitters were not DC coupled, and such a long string of bits would cause the signal to "droop" back towards zero carrier offset, potentially corrupting the signal. (These codewords are no problem for a modern design where the signal paths are all DC coupled, such that a constant voltage on the input will cause a constant carrier offset, and likewise a constant carrier offset causes a constant voltage on the RX path.)

Fourth, codewords with too many transitions between levels were avoided, as they had high frequency components that would be harder to filter out of the audio presented to the user. Again, this isn't as much of a problem with a modern design, where oft-times the filtering could be done digitally with a very sharp filter.