- Status
I am seeing the same thing. However, a friend of mine says he never sees a NXDN alias on his 436 with the 1.16 FW. We both monitor the same system. I don't know what his issue could be.
If your friend has the RID#s programmed in the system, then I believe it will show the programmed RID info and not the Alias, also are the RIDs turn on?
This may be it, because I'm intermittently seeing the Alias, but always seeing the UID. At first I thought it might be the length of the Alias, but I'm not totally sure.
Maybe that will be resolved with a future update, but overall I'm very happy with this revision.
Maybe that will be resolved with a future update, but overall I'm very happy with this revision.
On my DSD+ setup, OTA aliases take about 3/4 to 1 second after the transmission begins before they show up, and sometimes they show up in pieces, i.e. if SMITH is the ID, I might see -MI-H, then a second later -MITH, then SMITH, as the data is delivered.
My setup is about 30 miles from the tower, so it's possible that the signal needs to be stronger in order for aliases to be reliably delivered. I wouldn't be surprised if the scanner has the same issue.
My setup is about 30 miles from the tower, so it's possible that the signal needs to be stronger in order for aliases to be reliably delivered. I wouldn't be surprised if the scanner has the same issue.
Yeah, I've seen DSD do that as well. Also, DSD saves the alias in the DSDPlus.Radios file, so when the UID is present again, it auto shows the alias. This is some of the reasons DSD seems to show alias better.
It is great having the Alias info. Building a RID file with Alpha tags based on the Alias info will still be great even if the issue cannot be resolved.
Are you sure there's an option to turn RID's on and off?
jasonhouk
Member
Okay; I was looking under "Edit System". 
Another log file:
https://1drv.ms/u/s!ApJIS-l4xqPtgvEtfqduv4ZYVJFyDg
The only traffic in this log is from the jail system (color code 8). The scanner picked up some traffic, but usually only when there were several transmissions in a row. Typically the first transmission or two was missed, and the third or fourth in the conversation were the first picked up. But once it locked on the conversation, the scanner would usually play the rest of the transmissions.
I was only monitoring the school and jail systems (4 frequencies total), so in the absence of traffic, each frequency was being checked several times per second. So the scanner should have had no trouble at all consistently catching the first transmission in a conversation. But it only did maybe 10-20% of the time.
https://1drv.ms/u/s!ApJIS-l4xqPtgvEtfqduv4ZYVJFyDg
The only traffic in this log is from the jail system (color code 8). The scanner picked up some traffic, but usually only when there were several transmissions in a row. Typically the first transmission or two was missed, and the third or fourth in the conversation were the first picked up. But once it locked on the conversation, the scanner would usually play the rest of the transmissions.
I was only monitoring the school and jail systems (4 frequencies total), so in the absence of traffic, each frequency was being checked several times per second. So the scanner should have had no trouble at all consistently catching the first transmission in a conversation. But it only did maybe 10-20% of the time.
This would be a handy feature in the future if possible. The option to disable it and just see the UID's might benefit us at times too. Firmware update went through without a hitch for 2-536's and 1-436. Been using the 436 frequent enough to concur that the squelch gremlin has been eradicated. All other systems have been tested and can report no degradation occurred as a result of the firmware upgrade for me.
You are required to use Sentinel to update firmware on the x36 line of scanners, and to update the database.
Why do you not want to use it?
Because I always gotten it from the yahoo groups but for some reason it has not been posted up there as well I have tried to post a couple of times and my post are not getting posted so not sure whats going on
Listening to the 536 remotely I am getting a weird digital hum after a digital transmission which seems to last for a good 20 seconds (on and off). I thought it was proscan, but I connected directly with VLC and I still get it. I don't hear it when I am listening normally through the speaker. I have 2 536's and both are doing it on this firmware.
I attached a quick recording of what it sounds like (at the 8 second mark). I will hear it often after the transmission ends and while the radio is scanning.
I attached a quick recording of what it sounds like (at the 8 second mark). I will hear it often after the transmission ends and while the radio is scanning.
Last edited:
I take it you are using the Wi-Fi. Sound should be total quiet when no transmission is present. My guess is the computer speakers enhancements are on. Turn off the enhancements if on.
If still not resolved, perhaps revert to firmware 1.15.00 just to be sure.
{edit} Does it happen only with digital. Is that P25, DMR, or NXDN only? Does it do it with a conventional channel. Try weather and go into the menu to stop the weather receiving and see if it still happens.
Last edited:
This started after the firmware update, it doesn't it on 1.14. I didn't make any other changes except for the firmware update.
I would double check and triple check. I hear that all the time with regards to no other changes made then later I hear, that an option was inadvertently turned on I forgot about.
I am getting it on the android app also
- Status
Similar threads
BCD436HP/BCD536HP:
Uniden BCD436HP/BCD536HP Version 1.28.15 Released 06/12/24
