How can you determine if a DMR system is utilizing RAS or not ?
-
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.
DMR RAS ?
- Thread starter druhe
- Start date
The system is definitely in the clear. I was attempting to program it into an SDS as a DMR One Frequency, with negative results. When its programmed as a conventional DMR it receives as it should.
With DMR one-frequency ,remember you either need to know the TG and add it or enable ID Search. Other than that, if you can hear it programmed as conventional digital but can't heard it when programmed as DMR one-freq, you've got something missing (color code, TG)
Mike
MTS2000des
5B2_BEE00 Czar
RAS should have no effect on scanners, just subscriber radios attempting to access the repeater. One of the nicest thing if you want your part 97 MotoTRBO repeater to be free of lids and kerchunkerbaters is RAS. One can listen all day long, they just can't play with your repeater! R A S=moron avoidance system.
DSD+ Fast Lane tells you when DMR is using RAS.
RAS doesn't rob audio bits. RAS just obfuscates the CRC so the receiving radio is unable to validate it, thus ignores it assuming it's a bad decode. Encryption does use bit robbing, but not in a manner that is going to affect anything. That is to say, if the signal is so poor that encryption causes it to fail, it was already too weak in the first place.
RAS affects a scanner's ability to decode properly with even modest loss in signal strength, I have also witnessed countless times where Enh Privacy makes the voice noticeably distorted (on radios), and especially in the last 25% or so of it's useful range. When we un-checked the EP, it cleared right up. P25 doesn't have this issue, but Mototrbo absolutely does
Ubbe
Member
Radios and scanners always use FEC, forward error correction, to restore databits that have been received distorted. You will always have data errors using radio signals, except when the signal are totally noise free at full signal strength. Not using the proper RAS key will need the checksums to be ignored and will then disable the FEC feature and practically reduce the quality of the received signal.
I see indications that Uniden scanners falsely thinks it detects a RAS system and disables FEC incorrectly.
For the non working OFT programming, have only one frequency and one site programmed and at Hold when testing it out. Look at the detailed display when testing as a conventional channel to see what color code are used. If you in OFT have both slots monitored and IDSearch enabled it should monitor it.
/Ubbe
I see indications that Uniden scanners falsely thinks it detects a RAS system and disables FEC incorrectly.
For the non working OFT programming, have only one frequency and one site programmed and at Hold when testing it out. Look at the detailed display when testing as a conventional channel to see what color code are used. If you in OFT have both slots monitored and IDSearch enabled it should monitor it.
/Ubbe
Also, audio frames don't get affected by RAS. That is only applied to the link control messages. RAS has zero impact on audio quality. If you're experiencing audio issues, it isn't because of RAS.
slicerwizard
Member
Well, I do. But I also like experimenting. I am wanting to see if I can get the scanner to work properly with RAS on my stuff, not only for monitoring, but also so it will hopefully work properly with others, without decode issues.
But I read into your comment, and the "💩" icons that another left, guess he felt like was funny. No worries, I -can- skip over the smartass stuff, however, I am responding to it to hopefully shut that down, or make it known I am aware, so we can move past that pettiness.
Yes, I program radios, big deal. An SDS100/200 is great for monitoring and seeing what is going on with a system, even simplex DMR, in a very convenient form factor, with many features and settings included, that a radio won't show you.
I see now that I was absolutely incorrect about RAS and the voice data bits, it's the Enh. Enc. that does that. (MOT doesn't exactly share that with you) We turned ENC off, so the voice degradation and range loss due to complications with "Enc deployed as an after-though" is not an issue anymore. But the RAS does affect the scanners (SDS and TRX series) with the FEC. Turning off TG's in the TRX series isn't a very desirable way to monitor anything. I would hope a FW would be introduced in the future where the proper (known) RAS code could be entered into a scanner to help clear this up, but I am doubtful that will happen though, as this isn't something that many would actually be able to utilize. (Even though HAM radio uses it a lot also)
And interestingly enough, it seems an older XPR series portable using an early version of 16.0 will monitor a system using RAS, without the key in it, that one with later 16.0 won't. It seems as though Mot. introduced something in a FW update back in the day when RAS was brought out, that made it sound scrambled, without the proper RAS code entered. (it doesn't "mute" it?) The audio comes through pretty decent using older 16.0., without the RAS key, and no ENC used.
Is it wrong, or frowned upon to experiment? I think not. Mototrbo made radio programming interesting again back in the "narrowbanding" times. Instead of trying to be creative with different PL types, using 2 different freqs hoping for some privacy with simplex comms between 2 radios, etc., to using variable TG's, and even Enc. Mototrbo was a breath of fresh air, in a stale room of analog.
It's possible that around FW 16 Motorola changed the way it handled "bad decodes" of link control data. I'm guessing that since RAS does nothing to affect voice frames, older firmware still unmutes if the voice data passes a CRC check, even if the link control data does not.
RAS likely affects scanners as if it detects a bad CRC on the link control data, it doesn't do anything to correct errors with the voice frames. That is just an assumption, but it would explain why you're having audio issues with a RAS system and a scanner.
It WOULD be nice if other radio manufacturers gave the ability to "ignore bad CRC decode on link control data" or something. IE, still unmute voice that passes a CRC check but ignore the rest of it.
RAS likely affects scanners as if it detects a bad CRC on the link control data, it doesn't do anything to correct errors with the voice frames. That is just an assumption, but it would explain why you're having audio issues with a RAS system and a scanner.
It WOULD be nice if other radio manufacturers gave the ability to "ignore bad CRC decode on link control data" or something. IE, still unmute voice that passes a CRC check but ignore the rest of it.
Scanners don't simply "bypass" RAS, they try to compensate for it. Downside is the signal quality suffers. If there was a way to enter the known RAS key, then the integrity of the jumbled up bits RAS creates would be mitigated.
Similar threads
