Especially since we lost Paul?
Does Uniden Support Read this forum?
- Thread starter zzdiesel
- Start date
- Status
doctordialtone
Member
I guess this is the one place they would visit the most.
You can also PM them or do this:
@UnidenSupport
You can also PM them or do this:
@UnidenSupport
Thank you. I sure wish they'd cure our SDS200 no audio on some DMR one-frequency channels!
I reprogrammed these two frequencies again tonight as DMR One frequency mode hoping maybe I messed up something entering them the first time. I won't know until the morning. One is a school I used to drive buses for & the other is an electric company. Maybe I wouldn't be so worried so much if they don't come in so well on my Whistler TRX-1. I have am ambulance company that I have 2 DMR MotoTRBO frequencies programmed in my SDS200 that work perfectly as Conventional DMR. I'm sorry but this is so frustrating because it's been an ongoing problem here on RR with other SDS200 owners as well. I just don't notice anything is being done about this for us.
Most of the one freq DMR systems I monitor come in fine on the Unidens.
But... I also have some single channel systems that show as Tier III systems in DSDplus that give me troubles no matter how they are programmed.
I discovered with a couple of these troubled systems that if I manually hold on any talkgroup number I'd added and then release that hold that the system then usually seems to decode very well. I don't know if that is just some kind of coincidence or something but if I don't do the TG hold and release, the system will just keep searching without ever stopping on active chatter when I'm monitoring the system with a Whistler TRX-2.
Once I do the hold and release, the Uniden will follow the TRX-2 and stop on the active chatter. Go figure.
The above does not always work but it usually does. It seems to be something to do with the conventional DMR systems that don't use a talkgroup. When I add these systems, I'll usually throw in a dummy talkgroup so I have something to hold on in order to get it decoding.
I read something here that mentioned the Uniden models expect a talkgroup and if none are used, they have the no decode problem. Not sure if that's true as I have several conventional systems that don't use TGs that decode just fine on my Uniden's. It seems to be the systems that DSD+ show as Tier III systems that have the issues.
If I enter them as a Conventional DMR; they do stop when the channel is active but they have no audio. The display will show the correct CC & Slot but the TG will be blank. I've heard of this DSDplus but I have no idea what it is.
Thanks, buddrousa, I'll do me some reading on it later.
Thank you, kruser. You helped me to get one of these two channels to work; the school. Using a dummy TG cured it, but using a dummy TG on the power channel didn't help it.
Ubbe
Member
I'm pretty sure that you will need to have at least one TG programmed. The scanner are scanning TG's in trunked systems and if none is programmed it might just skip the control channel without even checking if IDSearch are enabled. It depends of how the firmware code are written. It would also explain why a system that doesn't use a dedicated control channel, a non TierIII system, might work without any TG being programmed.
It was a similar bug with NAC codes, if it was set to ignore it wouldn't decode the system and had to be set to search until the firmware code where fixed in a later release, if I remember correctly. It's probably many more bugs in such a complex firmware code that haven't been discovered or are considered being user errors or system quirks.
/Ubbe
Last edited:
I have had ID Search enabled all along. Hopefully, Uniden is reading this.
For several of the previously undocumented DMR systems in my area, when using ID Search to try & determine usage, I seem to have better results if I add a 'dummy' talkgroup as a place-keeper.
Somewhere, in all the myriad threads that came up when the DMR upgrade was released, I think I saw a quote, possibly from UPMan (though not positive) that suggested adding the dummy TGID as wellas a Department, even though TGIDs had yet been identified.
Thank you, hiegtx
Ubbe
Member
It's defenitly a talk group bug in the firmware of SDS100. When receiving an amateur DMR frequency programmed as a One Frequency DMR system I have a fairly good signal at -100dBm and other scanners where on the same frequency and the amateur guys where using TG9. I have that programmed as well as IDSearch. The whole programming comes from my BCD536.
The SDS100 shows the correct color code, which is set to search, and the correct slot, and the correct UID are displayed but the TG are not displayed and only scans without stopping on the TG and no audio are heard. They are still chatting away in other scanners. It happens a couple of times at other frequencies.
The DMR decode quality seems also to be much worse than other scanners. For some reason using the FM setting on a standard NFM DMR channel gives less D-errors. But with a little noise in the signal it seems as it really struggles to decode the data.
My experiance from asian programmers are that they often use students that just have graduated with a degree in software programming from a university. They have no experiance of the products they code for and only gets instructions what they are supposed to do. It's a strong hierarchy in most asian countries that forbids any employee to questions a senior managements orders.
The code works if everything are exactly as expected, but with radio signals there will always be noise and interferencies that needs to be handled by using good algorithms to filter out noise. The DSDPlus program are excellent and decodes DMR when the signal are almost lost in the noise. The SDS100 needs a noise free signal to operate satisfactory.
/Ubbe
The SDS100 shows the correct color code, which is set to search, and the correct slot, and the correct UID are displayed but the TG are not displayed and only scans without stopping on the TG and no audio are heard. They are still chatting away in other scanners. It happens a couple of times at other frequencies.
The DMR decode quality seems also to be much worse than other scanners. For some reason using the FM setting on a standard NFM DMR channel gives less D-errors. But with a little noise in the signal it seems as it really struggles to decode the data.
My experiance from asian programmers are that they often use students that just have graduated with a degree in software programming from a university. They have no experiance of the products they code for and only gets instructions what they are supposed to do. It's a strong hierarchy in most asian countries that forbids any employee to questions a senior managements orders.
The code works if everything are exactly as expected, but with radio signals there will always be noise and interferencies that needs to be handled by using good algorithms to filter out noise. The DSDPlus program are excellent and decodes DMR when the signal are almost lost in the noise. The SDS100 needs a noise free signal to operate satisfactory.
/Ubbe
Good info Ubbe. I've figured out with my two problem channels that it decodes better if the dummy TG I use ends in a 0 zero. I no longer have any complaints with my SDS200 since it now receives everything I want it to.
Ubbe
Member
OK, I already have TG240 and others that ends in a zero programmed, so that didn't help me. Maybe I should test with the exact same setup as you have, only program one single dummy TG that are not used in the system and then use IDSearch to monitor all TG's.
It's been strange all evening here when I try and monitor the amateur site in a One Frequency DMR system. I can hold on the site and the d-error are just a dash and sometimes a zero pops up. Color codes and the rest are displayed but no TG. When i go to the same frequency programmed as conventional analog+digital it works fine with d-errors between 3-7. Filters and IFX are the same and all service types are on and I've tested all combination of filters but it never decodes a TG in DMR One system.
I will experiment with that dummy TG and also different firmware and subprocessor firmwares.
/Ubbe
The only purpose of the 'dummy' talkgroup and department is to jump start the ID Search process. Once you begin to find, and add, verified TGIDs, the "dummy" can be deleted. That's what I've been doing on "new" systems that I'm trying to verify.
Ubbe
Member
OK. Then it has to be a pure software bug in DMR One Frequency System in the SDS100 firmware.
I have the SDS100 and BCD536 on the same splitter and the same programming and the SDS100 are very quiet compared to the BCD536.
There's another thread with a guy I'm trying to help that seems to have similar problems but with weak signal P25 monitoring in One Frequency Systems.
/Ubbe
I have the SDS100 and BCD536 on the same splitter and the same programming and the SDS100 are very quiet compared to the BCD536.
There's another thread with a guy I'm trying to help that seems to have similar problems but with weak signal P25 monitoring in One Frequency Systems.
/Ubbe
Ubbe, it was sure was aggravating in the beginning, but it's so simple now. Whoever dreamed a dummy number would fix something so easy?
- Status