You're using a SDS100E correct?
SDS100/SDS200: Conventional Channel DMR vs DMR One Frequency Reception
- Thread starter rgchristy
- Start date
You're using a SDS100E correct?
Ubbe
Member
They didn't change the DSP code so it wasn't a decoding error but something to do with how they used the information. I think they would like to check if it will have any negative impact on anything else before releasing an update. But it is a bit strange that it is the last digit that change, that usually indicates a small cosmetic fix that doesn't change operation of the scanner and have so far never triggered an update, only being put in new scanners without old users being allowed to upgrade to it.
Maybe they just change that last digit so it will possible to upgrade when the firmware are released with a proper 1.23.00 number.
/Ubbe
Maybe they just change that last digit so it will possible to upgrade when the firmware are released with a proper 1.23.00 number.
/Ubbe
Hi Ubbe,
How you can see that they did not change the DSP code , only on the sequel number / digit of the firmware change ??
i got the following remark after they had studied my logfiles
--quote--
As a result of investigating them , it turned out to be an unexpected sequence of data.
It is difficult to judge this system as DMR One Frequency under the current judging criteria.
I will design a new judging criteria.
--unquote--
How you can see that they did not change the DSP code , only on the sequel number / digit of the firmware change ??
i got the following remark after they had studied my logfiles
--quote--
As a result of investigating them , it turned out to be an unexpected sequence of data.
It is difficult to judge this system as DMR One Frequency under the current judging criteria.
I will design a new judging criteria.
--unquote--
Thanks for sharing your interactions with Uniden. Maybe there is hope for another firmware update in future.
I don't believe that firmware version is going to be available for the SDS100's/SDS200's in the USA?
Ubbe
Member
It's still the same old version number.
It could introduce a new can of worms if not considering all aspects in the criteria that have been thought out and refined over all these years.
They probably had something similar to:
Received data A-B-C and A=control channel flag and B=2slot voice detected
If position 1 are A then go to "Do A"
If position 2 are B then "Do B"
Do A: handle this as DMR type A
then goto End
Do B: handle this as DMR type B
goto End
.
.
End
In a situation when receiving A-B-C it never handles B as A and B are never expected to happen at the same time and it assumes it's a A type.
Of course it is much more complex and not those indicators but are not as easy as just change to If position 1 are A and position 2 are not B then go to "Do A".
It's the same kind of logic mistake if you do not program a dummy TG, that it seems that the programmed TG's are checked first and if none are found it errors out of the whole code segment as that was unexpected, as it must always be a TG to decode in a system, and it never checks if IDSearch should be used. It takes a very competent quality control to catch those errors and who also knows exactly how a system works, and I believe that Japan do not have any DMR systems so practical on-hands knowledge are also lacking.
A staff that do coding in Asia often have no knowledge of the rest of the device outside of their responsibility. In a radio receiver there will never be a 100% integrity of the decoded data due to interference and noise. If one bit are wrong that now incorrectly indicates it's a A system it runs the code to detect the control channel but there's no data there and it errors and skip that system. It needs to verify the data several times in a radio receiver to make sure it's correct and if contracting data are found it should recheck instead of continuing. It doesn't seem to happen in Unidens DMR decoding as if I avoid a TG, like 24010 in a HAM repeater, the conversation could come back as something like TG 16489, from the exact same slot, as I have IDSearch enabled. The staff that did the DMR handling have not done a high quality work.
/Ubbe
Hello Ubbe. nice story, but i think you are assuming as we do not know how they do the programming,
or do you have some inside information ?
And regarding the version number, if they change version from 1.22 to 1.23 , then you know for sure they have changed the DSP code?
And what do you concider DSP code ? The code that determines which digital signal is received or is the code that is doing the whole SDR reception , sampling etc, generating the I/Q signal , detection ?
If you do not use the right talkgroup to listen to, it will never decode, same for timeslot .
and regarding the errors caused by noise etc, therefore (i think) they have introduced a checksum like crc.
i don't know the DMR coding exact , but otherwise i think you will be missing a lot of the conversation, when the signal level is low.
And i must say it decodes reasonably , even with low signal strength.
But we will see when a new commercial version comes out, this one is working ok for me now, not missing a conversation and showing the ID and when you program the callsign and name , it shows it too (Only possible within DMR One Frequency, not in conventional if i am correct )
I have the Europan version, so i cannot say that it wil be changed for the USA version.
They also made a test firmware for the SDS200 (i received both versions) , but i don't have a SDS200, so could not test that version.
Nice to brainstorm about this matter.
or do you have some inside information ?
And regarding the version number, if they change version from 1.22 to 1.23 , then you know for sure they have changed the DSP code?
And what do you concider DSP code ? The code that determines which digital signal is received or is the code that is doing the whole SDR reception , sampling etc, generating the I/Q signal , detection ?
If you do not use the right talkgroup to listen to, it will never decode, same for timeslot .
and regarding the errors caused by noise etc, therefore (i think) they have introduced a checksum like crc.
i don't know the DMR coding exact , but otherwise i think you will be missing a lot of the conversation, when the signal level is low.
And i must say it decodes reasonably , even with low signal strength.
But we will see when a new commercial version comes out, this one is working ok for me now, not missing a conversation and showing the ID and when you program the callsign and name , it shows it too (Only possible within DMR One Frequency, not in conventional if i am correct )
I have the Europan version, so i cannot say that it wil be changed for the USA version.
They also made a test firmware for the SDS200 (i received both versions) , but i don't have a SDS200, so could not test that version.
Nice to brainstorm about this matter.
Ubbe
Member
Yes, all of that. It is the sub processor that are the DSP.
Yes, there's checksums and even FEC, forward error correction, so it's a bit surprising that decode quality can be so bad. The only explanation for it are that some Motorola systems use RAS that encrypts some data that requires a key so that only Motorola radios with the correct key can be used in the system. To be able to receive those system with a scanner they have to ignore all checksums as they cannot be calculated and there will no longer be any error detection and error correction. I believe that the firmware code handling the RAS function are faulty and sometimes are used even for normal systems. Sometimes a part of the code doesn't do error correction and another part then decides that the signal are too bad to be decoded and skips the system and other times ut decides it's a RAS system and let the errors pass as valid and presents incorrect results.
DMR worked fine in the first releases of firmware but when Uniden included RAS handling the problem started. Uniden really needs to take a closer look at this as it probably has an impact on the whole DMR functionality.
There's also logic problems in some firmware versions and scanner models when it comes to discovery mode and selecting to register only new systems, as it sometimes doesn't trigger that a system has been recorded the max amount of times or that the system already exists in the scanner and continuous to record as if it where a new unknown system.
The best way to solve bugs are to have firmware Fridays that UPMan had so that one single bug fix was released on Friday and people tested it over the weekend and then came back with feedback, and if it was a success only then continue to the next bug. If they try and solve many things in the same firmware release it will be more difficult to know what bug fix was responsible for additional bugs being created. Like now with your bug fix they rely on your feedback that it was solved but could have side effects to another users systems if they do not release a beta version for everybody to download and test. They will probably fix some other things as well and have them all in the same firmware release and call them stability improvement without specifying to what function they made a change.
/Ubbe
