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.
-
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.
Strange Squawking Sound - G5
- Thread starter bob550
- Start date
- Status
We're straying a bit from the topic Unication, and are likely to get told to stop by our friendly mods
Friendly mods...I just spit my tea on my keyboard.
N6ML
Member
- Joined
- Sep 26, 2008
- Messages
- 1,275
AzTac
Member
Are you sure it's not your wife?? When I bought my first G5 I heard several brief loud squawks, but it turned out they were from her...
boatbod
Member
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.
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
- 6,868
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
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
- 6,868
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
- Joined
- Sep 26, 2008
- Messages
- 1,275
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
- 6,868
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
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.
- Status
Similar threads
