Sorry for the double post. Been fighting with Tapatalk.
Sent from my SM-G930V using Tapatalk
Sent from my SM-G930V using Tapatalk
BCD325P2 / BCD996P2 Major Improvement Update
- Thread starter UPMan
- Start date
- Status
Well then forget my question. You just need to figure out the LCNs.
And now that the scanner is following them better, it should be a breeze to compare them to DSD+ or DMRDecode.. Just need the time to actually get it done.. hehe
Well, that's a comparison I did already in that link. So if this update doesn't fix it, then we might basically back to square 0 on this issue.
I don't truly understand a lot of these bullet points. Maybe someone could help?
What does this mean? Doesn't the scanner already have a scan delay setting? If a repeater has hang time, then what is it that the scanner is "supporting"?
Does this "private voice grant message" basically mean we can now listen and trunktrack private calls? How do we program this in the scanners and is there a wildcard?
Awesomeness.
Does this mean the scanner will no longer get hung up and stay stuck on a frequency that is only transmitting data but not a voice call? DMR frequencies have an annoying way of keying up and transmitting lots of extra junk even when there's no voice call going on.
So what does this mean? The scanner will display "RAS" on the screen and that's it?
What was the issue? And what is a "band plan"?
Sorry, don't understand this at all. What is a "receiving terminator" and what does "LNK" mean?
That would be a good thing!
What is this "modification" and what does "detection criteria" mean? If the scanner thinks a talk group is encrypted, what does the scanner actually do?
Really can't understand what this means. What are we "strengthening"? Does this mean some sort of improvement on being able to tell which slot a transmission is on? Is this for trunking or conventional?
Again, can't understand this. What does "recovery processing" and "missing of avoidance TGID" mean? Does this have something to do with locking out a talk group ID?
What "judgement criteria" are we talking about? I'm not following you here. What are we "judging" and what does the scanner actually do differently now?
Well, here's another big question. I keep getting an error and can't do the update.
"The operation has timed out."
Why would it time out? The update software has no problem detecting the scanner, so I know I've got the right COM port number. It actually starts off running and the two progress bars start running. But then about halfway through, it just stops suddenly and it gives this error:
"The operation has timed out."
Why would it time out? The update software has no problem detecting the scanner, so I know I've got the right COM port number. It actually starts off running and the two progress bars start running. But then about halfway through, it just stops suddenly and it gives this error:
Ubbe
Member
I'll give it a try.
Scanner used to instantly go back to control channel and wait for next PTT. Now it waits on the voice channel, the same as the radios in some systems does. It doesn't miss as many conversations as before as the control channel PTT might not show up during system hang time on the voice channel depending of the system setup.
It's always worked in other DMR system types, except DT3. Private calls doesn't trunktrack, they stay on one channel the whole conversation. It was probably an oversight that Uniden forgot to support this in cap+
I guess so.
RAS means that you'll need a system key to calculate the correct checksum of the data. Scanners have to ignore this and accept checksum errors which could increase bit errors resulting in bad audio and bad coverage. If the RAS detection doesn't work properly the scanner could ignore the whole data and not monitor the call as it thinks it's all bit errors and a too bad reception to be able to monitor.
The Uniden scanner skips any calls that it thinks is encrypted and continues to scan. It probably didn't detected that reliable enough in cap+ systems. (I now notice that my 536 detect both enc and dmr falsely on pure conventional channels, so they seem to have done this a bit too much)
It was problems to properly detect which slot a conversation was using and switched over to the other slot if another conversation where ongoing there and then jumped between the two slots which resulted in a monitoring mess.
Yes, it's related to the previous problem with the slot jumping. It was impossible to keep track of the avoided TGs as Uniden stores TG avoids associated with a particular slot.
Hytera systems can use their own kind of system called XPT. A standard system have one slot with data and the other slot with voice, or two voice slots with each slot dedicated to different users. XPT allows both slots for voice for all of its users. The advantage is that one user group can use two TGs at the same time when a standard system only allows one TG. I guess Uniden must properly detect a system as XPT to be able to follow a conversation if it travels between slots. This is probably related to that previous slot jumping problem.
/Ubbe
Last edited:
Not using the DMR enhancement. I noted someone had an analog search issue with this upgrade.
Is the improvement in p25 reception significant enough to go to this upgrade, as opposed to waiting on a more significant one?
It's the only thing I see for non-DMA users.
536/436/ws1095/996p2/996xt/325p2/396xt/psr800/396t/HP-1/HP-2 & others
Is the improvement in p25 reception significant enough to go to this upgrade, as opposed to waiting on a more significant one?
It's the only thing I see for non-DMA users.
536/436/ws1095/996p2/996xt/325p2/396xt/psr800/396t/HP-1/HP-2 & others
It's a shame that the scanner only shows the color code and not the talk group ID and slot #. There's enough unused pixels on the screen that it could show it. If the frequency was moved all the way over to the left and there was only 1 space between the frequency and color code, there's room to show the TGID and maybe an S1 or S2.
milcom_chaser
Member
- Joined
- Jul 4, 2010
- Messages
- 987
- Reaction score
- 61
Send in your suggestion!
Sent from my iPhone using Tapatalk
Sent from my iPhone using Tapatalk
Will that seriously even do any good?
I'm not sure one could see a improvement in "decode of digital signals" unless you have a decent signal and depends on your area and distance from the tower sites....Its questionable for me to do the upgrade as a non-DMR user as I already get very good coverage here on the site towers I monitor on IL-Starcom in the Chicago area....Sure need more input from area users.....Not much input on this upgrade as yet.....
Some of the input suggests some things working now are a problem after upgrading.
Think I will wait...
536/436/ws1095/996p2/996xt/325p2/396xt/psr800/396t/HP-1/HP-2 & others
milcom_chaser
Member
- Joined
- Jul 4, 2010
- Messages
- 987
- Reaction score
- 61
Tech1
Member
I'm having trouble installing this update. I know there's a particular sequence to doing an update and right now I can't remember it.
You run the program called BC_VUP3 and follow the directions.
chris
chris
Tech1
Member
Cancell the request for help, It's done. I did the DMR Update back in March, but I forgot where I put the file for the Uploader.
Tech1
Member
Right now everything is running correctly.
The latest release is a General release and is available via the BC_VUP3 updater.
chris
chris
- Status
