• To anyone looking to acquire commercial radio programming software:

    Please do not make requests for copies of radio programming software which is sold (or was sold) by the manufacturer for any monetary value. All requests will be deleted and a forum infraction issued. Making a request such as this is attempting to engage in software piracy and this forum cannot be involved or associated with this activity. The same goes for any private transaction via Private Message. Even if you attempt to engage in this activity in PM's we will still enforce the forum rules. Your PM's are not private and the administration has the right to read them if there's a hint to criminal activity.

    If you are having trouble legally obtaining software please state so. We do not want any hurt feelings when your vague post is mistaken for a free request. It is YOUR responsibility to properly word your request.

    To obtain Motorola software see the Sticky in the Motorola forum.

    The various other vendors often permit their dealers to sell the software online (i.e., Kenwood). Please use Google or some other search engine to find a dealer that sells the software. Typically each series or individual radio requires its own software package. Often the Kenwood software is less than $100 so don't be a cheapskate; just purchase it.

    For M/A Com/Harris/GE, etc: there are two software packages that program all current and past radios. One package is for conventional programming and the other for trunked programming. The trunked package is in upwards of $2,500. The conventional package is more reasonable though is still several hundred dollars. The benefit is you do not need multiple versions for each radio (unlike Motorola).

    This is a large and very visible forum. We cannot jeopardize the ability to provide the RadioReference services by allowing this activity to occur. Please respect this.
  • Effective immediately we will be deleting, without notice, any negative threads or posts that deal with the use of encryption and streaming of scanner audio.

    We've noticed a huge increase in rants and negative posts that revolve around agencies going to encryption due to the broadcasting of scanner audio on the internet. It's now worn out and continues to be the same recycled rants. These rants hijack the threads and derail the conversation. They no longer have a place anywhere on this forum other than in the designated threads in the Rants forum in the Tavern.

    If you violate these guidelines your post will be deleted without notice and an infraction will be issued. We are not against discussion of this issue. You just need to do it in the right place. For example:
    https://forums.radioreference.com/rants/224104-official-thread-live-audio-feeds-scanners-wait-encryption.html

Strange Squawking Sound - G5

bob550

Member
Premium Subscriber
Joined
Apr 5, 2005
Messages
1,078
Location
Albany County, NY
We're straying a bit from the topic Unication, and are likely to get told to stop by our friendly mods
Perhaps. But you're contributing to the knowledge base of the OP who is trying to understand the nature of the issue he is experiencing. :)
 

boatbod

Member
Premium Subscriber
Joined
Mar 3, 2007
Messages
1,723
Location
Talbot Co, MD
The repeater system or the receiver are failing to recognize the end of transmission bits and try to process random noise as voice.
I just can't see that happening in the receiver as there is too much error correction passed in the P25 protocol stream for random data to be validated as voice. More likely it's noise (or something else) being encoded into AMBE codewords at the base station.
 

bob550

Member
Premium Subscriber
Joined
Apr 5, 2005
Messages
1,078
Location
Albany County, NY
Lately, I've heard a similar noise which sounds more distant, as if it's background noise being re-transmitted along with the audio on the transmission I'm monitoring at that point. It occurs infrequently, and I haven't discovered any correlation between the talkgroups this occurs on and the one's I've experienced this on.
 

RFI-EMI-GUY

Member
Joined
Dec 22, 2013
Messages
3,193
I just can't see that happening in the receiver as there is too much error correction passed in the P25 protocol stream for random data to be validated as voice. More likely it's noise (or something else) being encoded into AMBE codewords at the base station.
If you break the transmission before the receiver sees the TDU, the receiver is going to try and ride out a few random bits (assuming a faded condition) until it mutes. This could happen anywhere in the system.
 

boatbod

Member
Premium Subscriber
Joined
Mar 3, 2007
Messages
1,723
Location
Talbot Co, MD
If you break the transmission before the receiver sees the TDU, the receiver is going to try and ride out a few random bits (assuming a faded condition) until it mutes. This could happen anywhere in the system.
Not it really couldn't because a P25 frame either contains valid a LDU1/LDU2 or 2V/4V or it doesn't. Fade, random bits, and pure fantasy simply don't get passed along to the AMBE codec.
 

RFI-EMI-GUY

Member
Joined
Dec 22, 2013
Messages
3,193
Not it really couldn't because a P25 frame either contains valid a LDU1/LDU2 or 2V/4V or it doesn't. Fade, random bits, and pure fantasy simply don't get passed along to the AMBE codec.
If that were entirely true, you would never receive garbled P25, yet it happens. I guess I am going to have to try some experiments for you.
 

N6ML

Member
Premium Subscriber
Joined
Sep 26, 2008
Messages
546
Location
SF Bay / Delta, CA
If that were entirely true, you would never receive garbled P25, yet it happens. I guess I am going to have to try some experiments for you.
I think he's saying that a frame could contain some uncorrectable (sp?) errors (so you can get garble during a message), but there should never be an LDU frame after a TDU, so there shouldn't be any voice data to even try to decode at that point.

I wonder if it could be a frame belonging to a different (new) session, on the same voice channel, though? Don't know if there's any verification of each frame to ensure that it pertains to the message being received.
 

RFI-EMI-GUY

Member
Joined
Dec 22, 2013
Messages
3,193
I think he's saying that a frame could contain some uncorrectable (sp?) errors (so you can get garble during a message), but there should never be an LDU frame after a TDU, so there shouldn't be any voice data to even try to decode at that point.

I wonder if it could be a frame belonging to a different (new) session, on the same voice channel, though? Don't know if there's any verification of each frame to ensure that it pertains to the message being received.
If you go back to what I suggested, I said that

"The repeater system or the receiver are failing to recognize the end of transmission bits (aka TDU) and try to process random noise as voice." ,

meaning the TDU is being dropped by some element of the system and the receiver is trying to process random stuff. The random stuff of course is uncorrectable and the receiver is going to let some of that happen for a period of time until either it sees a TDU or some valid voice frames otherwise completely mute and start over..
 

boatbod

Member
Premium Subscriber
Joined
Mar 3, 2007
Messages
1,723
Location
Talbot Co, MD
If that were entirely true, you would never receive garbled P25, yet it happens. I guess I am going to have to try some experiments for you.
Experiment away, but I'm telling you from a protocol standpoint your hypothesis that random data can be mistaken for AMBE codewords is just not possible. Clearly you shouldn't take my word for it, but go read TIA-102 (as I have done for many hours while working on op25) and understand how the numerous layers of FEC are applied to their respective payloads, then tell me how the firmware in the receiver could even begin to think it has valid data that should be sent for playback.

Garbled playback happens very rarely on a subscriber radio because they have better demodulators and first class FEC handling. At the opposite end of the spectrum, traditional consumer scanners do a horrible job and spit out garbled audio frequently because the do the least well at demodulating the signals and spend little to no effort on FEC handling. Somewhere in the middle are the various SDR packaged (DSD+, OP25, Trunk Recorder,...) and products like the Unication G-series pagers which make an honest effort to get things decoded properly. When garbled audio does work through those devices, it is either the result of the frame having bit errors in the non-error checked portion of the codewords, or attempting to play back encrypted traffic as if it were unencrypted. It is also possible under marginal signal conditions for frames to only successfully being decoded intermittently, leaving the failed frames in between to be either muted or excessively frame-repeated using prior good data.
 
Top