Tried your suggestions, no good.
FYI
When I program a Conventional FL on the hotspot frequency, the scanner locks onto the transmission no problem
- Status
FYI
When I program a Conventional FL on the hotspot frequency, the scanner locks onto the transmission no problem
@JoeBearcat can you please test this issue with One Frequency DMR not locking onto a transmission.
racingfan360
Member
- Joined
- Dec 19, 2005
- Messages
- 1,184
When programming via software, the Alpha Tag (Channel Name) has to be left blank to see/decode the TGID and RID. By deafult this then sets the Channel name/alpha tag to be the frequency in MHz. Just to repeat, this is about programming as a conventional system given the - as yet to be understood - issues with missing signals via OFT. You cant program a TGID or RID into a conventional system configuration either.
If you manually add a frequency to a conventional system via the keypad it will also default the Alpha Tag/Channel Name to the frequency in MHz.
Oddly if you then make any change to this channel name, even returning back to the 'by default' frequency in MHz name, it's back to square one and no decoded TGID and RID. It is odd/very frustrating.
Last edited:
Followed your instructions, and still do not see UID. It should be right above Custom 1
Ubbe
Member
Did it stay 2 sec on that one frequency trunked system? If it did not then it's probably mistaken the data stream to have some sort of encryption or something that forces it to leave the channel before it has time to properly decode all of the data. If it did stay 2 sec then try 5 sec for the hold time and it must start to decode the conversation as it works when you make a hold on the system.
Is that hotspot a fully working two slot version, that it can send one TG in one slot and at the same time send another TG on the other slot?
/Ubbe
The Conventional stops for 3 seconds (as programmed) during the scan, but the One frequency Trunk does not hold (set to 5 seconds) when scanning. I think the hold on the trunk is after a signal was received.
It's not a true 2 timeslot hotspot, both timeslots are joined together.
This was not an issue on the BCD536 that I sold when upgraded to SDS200
It's not a true 2 timeslot hotspot, both timeslots are joined together.
This was not an issue on the BCD536 that I sold when upgraded to SDS200
Ubbe
Member
Then the scanner have problems to interpret the data stream and thinks it something wrong with it. Can the hotspot be programmed in some way so you can try different options and features in it?
That's usually the case. I see that the scanner always seem to indicate slot2 even though it should also be able to use slot1. As I recall hotspots do not mimic a basestation using two slots but a simplex radio using one slot but are transmitting the same info on both slots as hotspots transmit a constant carrier. What happens if you turn off IDSearch and program the TG's as only using slot1 and not All?
Yes, it needs to have the squelch open by a carrier to stop scan and start the hold timer. So you would need to check only when the hotspot are transmitting. If the hotspot only sends a carrier without any DMR data modulation it will stop scan briefly and after 100mS or so it will know that there's no valid DMR data to decode and will continue to scan. If you program the frequency as conventional it will stop scan even on a carrier without any DMR data.
It probably are some firmware issue in the scanner and you could start a debug log when the problem are shown and send it to Uniden to analyze. There will always be these bugs with complex scanners that needs support and bug fixing by the scanners firmware developers. As it worked in 536 they must have done a bug fix in SDS that broke another function related to simplex DMR. The firmware release notes doesn't go into detail and do not include everything they have done and the small changes they do that are not supposed to have anything to do with operational functions, the last two digits in the firmware release number, are never explained what they have actually done.
/Ubbe
@JoeBearcat where do I send my debug logs?
Last edited:
Ubbe
Member
It was just an illusion from the display being updated slowly and not in sync with what where happening. Your scanner always do a 1,45sec hold on your hotspot frequency. So it doesn't reject the data and starts to scan prematurely. But it struggles to find any voice frames in the data stream. If you had your 536 working with that hotspot and no configuration have changed in it, then it has to be an updated firmware in SDS scanners compared to what your 536 where using.
Do you see any difference if you delete all TG's in that system and only have a dummy TG programmed and set IDSearch, or have the actual TG programmed with IDScan, try to set slots to All, then to 1 and then to 2 and see if one of the settings will work more or less 100% of the time. It would help Uniden in their bug hunting.
/Ubbe
Do you see any difference if you delete all TG's in that system and only have a dummy TG programmed and set IDSearch, or have the actual TG programmed with IDScan, try to set slots to All, then to 1 and then to 2 and see if one of the settings will work more or less 100% of the time. It would help Uniden in their bug hunting.
/Ubbe
Ubbe
Member
You can try the previous firmware, as the latest has "improved" DMR OFT reception. Just dump the file in the SD cards firmware folder and politly disconnect the USB cable.
drive.google.com
/Ubbe
SDS200_V1_09_02.bin
drive.google.com
/Ubbe
- Joined
- Jun 30, 2020
- Messages
- 2,008
I will have to check to see if this is intended operation. If it sees no signal, it may just move on since this is "trunked" operation.
Ubbe
Member
For TierIII DMR, or any system using a constant transmitted data in the control channel, it would be an appropriate function to not use the hold timer if no carrier are detected. There's no point in waiting for a call if there's not even a data carrier. But for control channels that sends beacons or idle data bursts it should use hold to eventually wait for a call to start, much like analog conventional hold are used to scan the department repeatedly for the whole hold time, waiting for a conversation to start.
I think it might have been a quick fix to not let the scan slow down to a crawl when scanning sites that could not even be received. It could also be related to the scanner leaving a site when there's conversations on it, as it sense the control data not indicating a call when a user release his PTT button and the "skip site if control channel indicate no conversation" have priority over TG delay time. A properly done flow chart should indicate any unwanted behavior.
/Ubbe
- Status
Similar threads
