False readouts on the 396T scanner

[altec]

I have never had a problem with the 396 scanner until recently. When I bought it new 2 years ago everything worked just fine except for a few minor exceptions. I've upgraded to the latest firmware V3.01.00 .For a while everything seemed to work alright till recently. For some unknown reason on a Type II Smartnet system that I have monitored for three years unknown tgid's have been coming up that I have never seen before on this system.Its off a particular group of known users but it seems its bleeding in on these new tgid's or the control channel data is reading it wrong. Once in a while in the past this has happened but not enough to really matter. They only have two tgids's on the system. I'm thinking its false read outs on the control channel but for some reason it seems to have gotten a lot worst recently" like every 30 mins of monitoring these fake tgid's pop up at least once". Just curious on what might be causing this problem. Also do any other scanner models have this problem?

 

[ranger2004]

Can you give an example of the normal and the one's that are showing up now?

Might be status bits if its 1 to 8 off.

 

[floydpink999999]

Divide the TGID number by 16 and see if the answer is a whole number.

If it is not, then status bits 1 to 16 set, depending on your result.

Example: if your TGID is 18320, divided by 16 = 1145, therefore it is not a status bit.

but if your TGID is 18322, divided by 16 = 1145.125, therefore TGID is 18320 + bit 2 set.


Status bits assignment here: http://wiki.radioreference.com/index.php/Motorola_Type_II

HTH

 

[altec]

Status bit is off

The status bit is turned off. The two tgid's are 912 and 944 are the normal ones used. These new tgid's are appearing in the 2190 - 2196 range. The highest known tgid on the system goes up to 1616. When the tgid comes up on these other tgid's only one part of the conversation is heard then resumes back to 912 or 944. This only happens once in a while but yesterday it happened like every 30 mins.

 

[hankv]

The status bit is turned off. The two tgid's are 912 and 944 are the normal ones used. These new tgid's are appearing in the 2190 - 2196 range. The highest known tgid on the system goes up to 1616. When the tgid comes up on these other tgid's only one part of the conversation is heard then resumes back to 912 or 944. This only happens once in a while but yesterday it happened like every 30 mins.

Could you tell us the exact system you are listening to?

Hank

 

[altec]

link

http://www.radioreference.com/apps/db/?sid=1802 While listening today it has not done this yet.

 

[ayaresr]

I have had a similar problem with this even before the upgrade. I will still get the audio, but the TGID will be way off on a TG that I have confirmed and know the false id not to exist on the system. This was on Salem County, NJ Smartnet system. http://www.radioreference.com/apps/db/?sid=742
Ryan

 

[altec]

Today not much

Today it only happened a few times. This time the tgid's was in the 9100 area. Most of the time I have these two specific talkgroups locked out due to their talkative issues. I wanna listen to the police mostly and when you hear bus drivers come on the air they like to chit chat a lot. It wouldn't bother me if this only happened once in a while but some days its a lot worst.

 

[slicerwizard]

This is a known bug with the Uniden DMA scanners - they get false decodes off the control channel all the time. Usually, the bogus decode points to a frequency that has no signal present, so you don't notice it.

To reduce the problem:

- don't use Control Channel Only mode

- don't use ID Search

- move the antenna away from interference sources (like your PC)

 

[altec]

This is a known bug with the Uniden DMA scanners - they get false decodes off the control channel all the time. Usually, the bogus decode points to a frequency that has no signal present, so you don't notice it.

To reduce the problem:

- don't use Control Channel Only mode

- don't use ID Search

- move the antenna away from interference sources (like your PC)

Thanks slicerwizard, I was thinking of something along those guildlines.

 

[n4yek]

This is a known bug with the Uniden DMA scanners - they get false decodes off the control channel all the time.......

This scanner has been out for at least 3 years and they haven't fixed this known issue? This is the first I have heard about this and if a person is trying to figure out new systems in search mode, you get false ID's?
I like this scanner but this is something that should have been resolved.
If not, then the next generation 396's and 996's will have the same problem.

 

[slicerwizard]

This scanner has been out for at least 3 years and they haven't fixed this known issue?

I don't recall any mention of it in any of the firmware update notes.

This is the first I have heard about this and if a person is trying to figure out new systems in search mode, you get false ID's?

That you do. More so if you're using Control Channel Only mode. The old requirement of programming every voice frequency for a Motorola 3600 bps system tended to mask the problem, as most false decodes come up with frequencies that aren't part of the system you're monitoring. With Control Channel Only mode, the scanner is free to latch on to any signal on any frequency within a system's bandplan, whether it be a voice channel from another system (trunked or not), a birdie, or even just noise from your PC.

One's best bet is to use a discriminator tapped scanner to drive decoding software.

I like this scanner but this is something that should have been resolved.
If not, then the next generation 396's and 996's will have the same problem.

I'm sure they will. Uniden's marketing leans towards new bells and whistles, not fixing subtle bugs.

 

[FlashP]

errant decodes

All digital communications suffer from some percentage of 'bit errors'. Signal quality is in fact usually measured as "Bit Error Rate" (BER). For wired systems like computer networks, the BER is a very small number, like 1 bit in 10E6 or better. On radio systems the quality's not as good - you can hear that yourself.

So there's two things to do if you want better digital comms: clean up the signal (more transmit power, quieter receiver, eliminate multipath, etc.), or code the data so bit errors can be detected and dealt with. With a scanner, about all you have control of is location and antenna; many posts here talk about the great improvements you might get with an apparently minor change. The error-handling is where Uniden comes in... the scanner is reading a 3600 bit/sec data stream that has some level of error detection available. But it's not very robust and the scanner designers then get to choose what to do with it. (Example: you could wait for ten consecutive matching channel assignments before jumping to the voice channel, but users probably wouldn't like missing the first few seconds of the comms.)

The earliest trunk trackers required you to program ALL the voice channels - that way, if the control instructions were decoded wrong, the scanner most likely would see that it was an invalid frequency and ignore it. Based on experience and some amount of customer input, we now have the option to program only the control channels and take our chances with the occasional erroneous assignment. Most of those go to dead air and immediately return to scanning - in the original problem of this thread, there are only two talkgroups and it's very obvious to the user that the errors occur.

So to say Uniden DMA scanners "have a known problem" is a bit of a stretch. All trunking radios have to deal with this issue, the 396 happens to chase a marginal signal more often than some other scanners and H/Ts that might make fewer mistakes but miss more transmissions completely. Commercial gear can afford more $$ for higher a quality front end tuned to a specific band. I suspect Uniden would respond if there was enough consumer interest in a scanner that performed, and cost, like a high-end Motorola H/T, but I'm putting my money into antennas.

Flash

 

[n4yek]

I don't recall any mention of it in any of the firmware update notes.

I never seen any mention of fixing it either, but again I was un-aware of the problem. I always ID Scan my systems.

 

[slicerwizard]

the scanner designers then get to choose what to do with it. (Example: you could wait for ten consecutive matching channel assignments before jumping to the voice channel, but users probably wouldn't like missing the first few seconds of the comms.)

Well, that's quite the nice false dichotomy you're presenting there. So we can either have complete comms with some bogus IDs or incomplete comms with no bogus IDs?

All that has to be done is wait to see the same assignment twice - that would make the problem go away. Noise doesn't generate the same bogus assignment (talkgroup plus RF channel index) during short sampling intervals (say, one to two seconds). When I'm controlling a voice scanner, I wait for grants to repeat before acting on them. I don't miss any part of voice comms - the voice repeaters take longer to key up and stabilize than my verification and tuning does. I don't get bogus talkgroups slipping through. If I can do it, so can Uniden.

Based on experience and some amount of customer input, we now have the option to program only the control channels and take our chances with the occasional erroneous assignment. Most of those go to dead air and immediately return to scanning

That is very dependent on the channel mix of a given system. I have one here that my 396 just loves to report bogus talkgroups and private calls on. I can see that a group call (that I don't want to hear - damn meter maids...) on channel 3 is frequently being decoded as random groups active on channel 7, and when channel 7 happens to be in use, I get to hear it until channel 7 drops.

in the original problem of this thread, there are only two talkgroups and it's very obvious to the user that the errors occur.

Yes, it's not that hard to catch it on a system with only 11 talkgroups. It's a different story on systems with hundreds of talkgroups - one usually isn't familiar with all of the users and with many simultaneous comms on the go, the scanner isn't going to bounce from the bogus group display back to the correct display when the next user replies.

So to say Uniden DMA scanners "have a known problem" is a bit of a stretch.

No, it's not. It's a real problem and I have to deal with it. So do others - they're right here in this thread. Uniden could fix this, but they haven't.

 

[FlashP]

slicerwiz,

No offense, I'm just pointing out it's a design trade that they've made.

"Fix" is only possible if you define the requirement precisely. "Improve" can be done if you're willing to accept the cost, which could be dollars, an impact on other performance factors, or a delay in the next product release. I'm sure Uniden would react if enough people cited this as the reason they put their scanners on eBay...

Flash