Announcing the BCD396XT and BC346XT Scanners

[DonS]

Correct it wasnt a true P25 system just a moto UHF system with digital talkgroups (Fleetnet local Ontario Police)

That's the easy one, since "encrypted" vs. "not encrypted" is indicated on the CC. For a P25 system, you have to get such information from the voice channel, which means you either a) get a brief bit of noise at the beginning of each transmission before the scanner can determine that it's encrypted or b) add a (possibly noticable) delay before decoding audio while the scanner waits for the encrypted/not-encrypted info.

 

[WhyWhyZed_4]

Good Day,

In the press release, they say "...at prices comparable to the models being replaced." Therefore, we're looking at a MSRP ~ $550 USD? Or was the 396T originally selling for more, and that being the 396XT's new price?

Thanks

 

[bonus1331]

BCD396XTEnd of March latest info we have - $519.95 : The Hamstation!, Your one stop on-line source for amateur radio fun.

Hamstation has been pre-ordering for about 2 weeks at $519...
#6 on the list and waiting...

 

[satin]

will the 346xlt be better than the 330t

 

[rdale]

sat - yes.

 

[JonHanson]

Quick system for Close Call hits

I know the new 396 has the capability of storing the last 10 Close Call hits in their own temporary system. Does it also store the DCS and PL tones found in the Close Call hits?

 

[bonus1331]

Anyone hear any "rumors" of a beta UASD 396XT being tested yet?
With the radio only a couple of weeks away, would hope that the software is nearing completion.

 

[KE4ZNR]

Anyone hear any "rumors" of a beta UASD 396XT being tested yet?
With the radio only a couple of weeks away, would hope that the software is nearing completion.

Rumors say that many different software options should be available considering the command protocol has been available on the Uniden Wiki for awhile
And the wait is a little longer than a couple of weeks...but will be worth it
Marshall KE4ZNR

 

[rdale]

Might be safer with Freescan if you want to be ready to go on day 1.

 

[KE4ZNR]

Might be safer with Freescan if you want to be ready to go on day 1.

Rumor has it that Freescan will indeed play nice with the 346xt/396xt on Day 1.
Marshall KE4ZNR

 

[bonus1331]

Rumors say that many different software options should be available considering the command protocol has been available on the Uniden Wiki for awhile
And the wait is a little longer than a couple of weeks...but will be worth it
Marshall KE4ZNR

Your right, should have said a "few" weeks.
Thanks

 

[firenutts]

I have a question for the new xt.... Will I be able to to use tone squelch (pl) on digital mixed conventional channels. We have a couple of local PDs that run both analog and digital.

 

[UPMan]

You'll need to program the channel twice...once analog w/PL, once Digital (w/NAC if you know it).

 

[SOFA_KING]

Too Bad

You'll need to program the channel twice...once analog w/PL, once Digital (w/NAC if you know it).

Another missed opportunity, Paul. One frequency entry with multi-mode/multi-code entry, each with their own alpha tags, would have been the way to go with radio systems like this. Many conventional systems use the same frequencies with different squelch codes (and now mixed analog/P25 codes), so it would save much scan time and match the actual operation of these systems better. Maybe in the "next line of scanners"? :roll:

Doesn't anyone who designs these things actually KNOW how radio systems are constructed and used? It might help!

Phil

 

[UPMan]

The solution you profer would make the required firmware another order of magnitude more complex as well as more complex for the end user when programming conventional channels. Taking another 3 mS to scan the additional channel seems an acceptable trade-off.

 

[SOFA_KING]

The solution you profer would make the required firmware another order of magnitude more complex as well as more complex for the end user when programming conventional channels. Taking another 3 mS to scan the additional channel seems an acceptable trade-off.

I don't buy that at all. Programming one more squelch code on a channel as opposed to another channel AND another squelch code is HALF the work. All you have to do is make the menu system easy to use. Simple!

3 mS delay? More like 30 mS! And it DOES delay opening up to what you want to here if the second (or third...) channel has the matching squelch code.

Just stop farting around and make a scanner that works well for all the different types of communications systems that exist (excluding Provoice or other proprietary technologies). No more lame excuses! Just do it already!!!

Phil

 

[DonS]

I don't buy that at all. Programming one more squelch code on a channel as opposed to another channel AND another squelch code is HALF the work. All you have to do is make the menu system easy to use. Simple!

3 mS delay? More like 30 mS! And it DOES delay opening up to what you want to here if the second (or third...) channel has the matching squelch code.

And you would see the same delay if there was some "multi-mode / multi-squelch" setting for a single conventional channel. The root problem is this: unless you want to start paying more for your scanners, it's likely the device doesn't really have the processing power to look for "digital with NAC" and "analog with CTCSS" at the same time.

Instead, what you'd have is:
1. presume you have a channel programmed as "P25 with NAC 123 OR analog with CTCSS 179.9"
2. scanner tunes to channel
3. RF squelch opens on an analog transmission with CTCSS 179.9
4. scanner sees your multi-mode settings
5. scanner first looks for "digital", with some timeout
6. transmission is analog, so the scanner times out looking for digital
7. scanner falls back to analog, and starts looking for CTCSS 179.9
8. scanner gets the CTCSS tone and unmutes audio

The example above uses "scanner looks for digital first / transmission is analog". The same problem occurs if "scanner looks for analog first / transmission is digital".

(The above isn't based on any knowledge of Uniden scanners, of course. It's meant as a general description of "the problem".)

 

[UPMan]

3 mS delay? More like 30 mS!

I was speaking of the time it would take to scan past the extra channel when the channel is idle. 30 mS would just give you about 33 ch/sec. Since the new channel would be on the same RF baseband frequency as the first channel (assuming the channels are scanned sequentially) there would be no RF switching/settle time, so the new channel would be skipped past very quickly (maybe even faster than my 3 mS guesstimate).

If there is a transmission, then the delay while the scanner checks for valid/matching mode and code would be about the same using your method or a two-channel method (as DonS explained very well). Meanwhile, you'd have a completely new layer of programming you need to do for every conventional channel.

 

[Forts]

I don't buy that at all. Programming one more squelch code on a channel as opposed to another channel AND another squelch code is HALF the work. All you have to do is make the menu system easy to use. Simple!

3 mS delay? More like 30 mS! And it DOES delay opening up to what you want to here if the second (or third...) channel has the matching squelch code.

Just stop farting around and make a scanner that works well for all the different types of communications systems that exist (excluding Provoice or other proprietary technologies). No more lame excuses! Just do it already!!!

Phil

Wow, with such a polite request like this I'm sure they will put it at the top of their priority list. If UPMan says it can't easily be done, I don't think he's saying that just to hear himself talk (or in this case, see himself type!).

If you don't like the feature set in the radio, don't buy it! Look for an alternative of some sort.

 

[hotdjdave]

Since the new channel would be on the same RF baseband frequency as the first channel (assuming the channels are scanned sequentially) there would be no RF switching/settle time, so the new channel would be skipped past very quickly (maybe even faster than my 3 mS guesstimate).

So if you program the channels in sequential order based on the freuqency, the scan speed will be increased (as opposed to, say, putting them in by alphabetical order based on the alpha tag)?

Example:

153.200 Channel C
154.300 Channel B
155.400 Channel A
156.500 Channel E
157.600 Channel D

will scan faster than...

155.400 Channel A
154.300 Channel B
153.200 Channel C
157.600 Channel D
156.500 Channel E
​

I did not know this.