Announcing the BCD396XT and BC346XT Scanners

[jonny290]

The one single complaint I have about my 396 is this. There are two 'lockout' parameters for each system. One is the actual system lockout function, the other is selected by entering the system number to toggle it in the scan rotation. Is there any plan to change this functionality to be combined into a single lockout function in the next generation, and if not, could you maybe explain why the scanners behave as such?

 

[mancow]

It would no longer be a fully DMA setup if the lockout status of every system was dependent on it being assigned to a quick key. What would you do if you wanted to keep a list of systems in the memory but you don't have a current need to assign them? For example; I have a Mil Satcom system in mine. I don't want to scan that 99% of the time because it requires a certain antenna setup. I also do not want to tie it to a quick key because it doesn't fit with any of the other PS style systems already assigned and I don't want to waste a quick key on it. So, it remains in the background, locked out. When I need it I pull it up, assign it a quick key and I'm done.

 

[jonny290]

That is a fair explanation and a good idea. Makes sense now.

 

[kd7ckq]

Quote:
Originally Posted by UPMan
CC Data output is something like:

For those of us that understand this stuff, do us a favor and don't comment the OSW's. It's a wasted effort and it looks terrible as-is.

Interesting?! Why can't we talk about OSW's? How about ISW's? UPMan CC data output looked good for what it was. At least it was understandable.

Add me to the list for this idea. Most people don't understand how it works so you may as well start with calling it what it truly is. (No bass-ackward ideas/attempts at coming up with new uber cool names like calling Private Calls "I-Calls" and the "Uniden TG format").

I have always held Moderators in very high regard. I figured that they have Earned there positions by showing that they can be impartial, fair, and composed.
wayne_h, with your comments above. You have two terrible posts. You sound ..... Belittling of those who are 'not in the know.' UPMan for a lack of a better description, put it out there for comments and suggestions. RR members answered! Who is to say we have to accept /\/\oto's name for a feature. Just maybe, RR members for once can come up with something better. Something that they, as end-users of scanners, not two-way commercial gear can understand.

 

[kd7ckq]

Now for those who don't know what OSW's and ISW's are and would like to know. Here is a good article of how a Motorola trunking system handles calls. Not to technical either.
http://www.textfiles.com/phreak/motorola.txt
It is good reading, and brief.

 

[MattSR]

For those of us that understand this stuff, do us a favor and don't comment the OSW's. It's a wasted effort and it looks terrible as-is.

Yep, and makes it harder to parse too

 

[slicerwizard]

That text file is so out of date that I wouldn't recommend it to anyone without a gaggle of disclaimers. There are many differences between that file and today's Type II systems.

 

[slicerwizard]

Yep, and makes it harder to parse too

Looks simple enough: "MOT" comma command comma group comma ID comma ignore the rest...

That's one line of C code here. The fixed width of the data fields makes it even easier to verify and decode.

It would be nice if these output streams included a simple (but not too simple) checksum on each line. The same would've been nice to have on all of the serial protocol commands - the STS command returns over 100 characters with no protection; combine that with the scanner's tendancy to screw up the reply (e.g. drop characters) every now and then and the results ain't pretty.

 

[PiccoIntegra]

If you really want to learn about Motorola datastreams, you should use Xlat-OSW:

For the most part, I already understand the Motorola data stream. It is the others I'm not too familiar with. That's ok for the time being, as the only system I monitor is a Motorola system. But they are now in the early stages of rebanding and will be moving to a P25 system sometime in the future.

I was being generic in my response for those that want to learn the command structures of trunked radio in general, not just Motorola. As far as I'm concerned, all new scanners should have this feature, and have it provide as much detailed info as possible. I don't give a crap what the "veterans" think about about adding more info into the data dumps. Taking away additional info because someone thinks it's "wasted effort and it looks terrible as-is", or everyone should learn the hard way, is an utterly stupid thing to suggest. I'd rather take advantage of the available technology, then freaking reinvent it.

Go with SlicerWizard's advice. Or don't cheat and learn from scratch like the veterans have, you'll be better off than letting Uniden teach you.

Don't worry about how better off I'll be, I'm the one that gets to make that call. Trust me when I say, I will sleep just as good at night not having to learn signal processing and bit crunching/error correcting these data streams. If that makes me less of a human being, so be it. My interest simply lies with logging, tagging and recording unidentified groups/users. The easiest route I can take to achieve that goal will make my scanning experience that much more enjoyable for ME. I've come across many posts here, and on old news group posts of the "veterans" asking others for their source code so they can further their own knowledge. That's just as much of a cheat as these structured data dumps from the scanner itself. As slicerwizard alluded to above, much of the available resources are outdated. It would be nice to have updated source code to learn from, but we no longer have that luxury. So these detailed data dumps are the next best thing! I just hope those at Uniden aren't as stubborn (or bitter?) as you are.

Yep, and makes it harder to parse too

It's a delimited string structure, what is so hard about parsing that? The most basic of coding languages can parse that with one line of code. :roll:

 

[rdale]

Two questions from me.. Will there ever be a firmware update for the BCD396T to decode 2 tones like these 2 new scanners will be able to do?

Addressed before in this thread - wrong place to post. And if it does happen, don't you think Paul will announce it when he can?

My second question is how much are we looking at paying for these 2 new BCs

Already addressed very early in this thread. Can't say yet.

 

[bwilborn]

I thought of another question regarding the discriminator output last night:

If the raw data is being streamed over the serial link, will we be able to also listen to the audio stream as trunking data is being decoded? I don't own one, but as I understand, with the GRE5/600 and Pro-96, you can only do one or the other and have to have a second radio around to listen to the audio. I'm assuming this is because the PC/IF port on those radios essentially act as a shunt for the raw audio (which then is fed into your PC's sound card).

-- B

 

[rdale]

The PSR line lets you hear audio while reading the tap output, this will too...

 

[SCPD]

Yep, and makes it harder to parse too

I must the only one that caught Matt's sarcasm.

As far as I'm concerned, all new scanners should have this feature, and have it provide as much detailed info as possible.

I agree with the first part. The scanner manufacturers are in competition with each other. They'd rather hide things they consider a competitive advantage. If a fully annotated data dump is going to reveal something they consider a "secret", they likely won't include it.

I don't give a crap what the "veterans" think about adding more info into the data dumps.

Fair enough. For everyone else - I'm about to tell you what I really think.

The data dump feature is artificially limited. It tries to do too much - and in so doing - limits what you can do with the radio. I'd go further to say not only is the "annotation" unnecessary - the de-interleave and FEC are also unnecessary. Existing decoding applications already know how to do this. Just give me the raw bits off the air! While it scores high in "plug and play" - it will never be as flexible as discriminator audio (and some radios provide this out-of-the-box).

Here's my gripe: don't limit me to three or four trunking protocols. Let's take LTR as a prime example. The code for recovering the bits for LTR and Passport is the same (that's bits, not frames). The radio does so now for LTR. But because the radio is specialized to LTR only - it won't give me the bits for Passport (which I could then re-assemble into Passport packets). The radio presumes that - because it does not know Passport - I shouldn't either.

This is an artificial limitation.

Want another example? P25 link control. If the CC dump feature only passes TSBKs (control channel messages), it isn't going to give me the link control data found on voice channels - which can be useful on it's own. The least common denominator is the bits. Provide the bits and you've covered both.

This is (again) an artificial limitation.

Here's another example: EDACS working channel messages; these are the equivalent of P25 link control messages (and comparable to the low speed data over a Motorola analog voice channel). The code to recover the bits (not the packets, just the bits) from an EDACS control channel will also serve to get these messages. Image a program that can scan the EDACS control channel and EDACS voice channels and spit out the correct LCN order for you. Wouldn't that make submitting new EDACS systems to the RR database easier?

This is an artificial limitation. Do I sound like a broken record yet?

I hope these examples will explain my discord with the CC dump feature. A simple A/D channel over the serial or USB cable would have done the trick - and provided the possibility for decoding modes that the radios themselves don't understand.

This is - so far - a missed opportunity.

Maybe - in a year or two - someone with "get it" and do this feature right. While this is an improvement over where we were two years ago; I would like to remind everyone that this feature has been around for a while. Remember the old OPTOComs with the "bitbanger" option. I think it did LTR and Motorola. That was ... something like ... 10 years ago. Now we have EDACS and P25 covered. This is an improvement ... but it could have been done much better.

 

[WayneH]

For the most part, I already understand the Motorola data stream. It is the others I'm not too familiar with.

Then what's the point in arguing someone else's opinion? I stated it as it will be, the data output will no doubt be inaccurate or lacking in data; the example given was already proof.

As far as I'm concerned, all new scanners should have this feature, and have it provide as much detailed info as possible.

Yeah, well, welcome to reality, which you don't seem to be living in. There's many of us who have been working with this data for a long time. Ever think why we've yet to write detailed documentation?

I don't give a crap what the "veterans" think about about adding more info into the data dumps.

Really now? It's us veteran's of the Motorola protocol, and various others, that have made it possible for today's scanners to do what they do. It's not Uniden development or GRE, it's private individuals taking their personal time to learn this stuff. It's also exactly why we don't share it, because of unappreciative people like you.

My interest simply lies with logging, tagging and recording unidentified groups/users.

So why are you participating in an argument that deals with raw protocol data, 75% of which has nothing to do with groups and users.

The easiest route I can take to achieve that goal will make my scanning experience that much more enjoyable for ME.

Nice, so you want to go about that by reading raw protocol code. That makes a lot of sense.

I just hope those at Uniden aren't as stubborn (or bitter?) as you are.

I think Uniden should make a quality product. If they're going to do something they should do it right (as GRE has done a great job at doing). That's all my argument is about. I have the experience to speak on what's right or wrong here.

The Uniden fanatics are out in full effect in this thread! If someone wants to argue this further do it privately. We don't need any more hurt feelings because someone is afraid of facts. Also, a moderator can have an opinion like everyone else; please stop being so sensitive.

 

[jkahn]

New radio Beta testing

running beta tests on the 396XT currently and starting beta tests on the 346XT later this week (slate is filled, but thanks for your offer to help).


When you are ready for the field, I'll be happy to help Beta test. He, He, He!

 

[stlouisx50]

I would like to ask some questions everyone else has seemed to overlook...

Will the new Uniden allow changeable/adjustable steps as the competition does not?

How does the speaker sound db wise vs. the competition?

How many birdie issues are there with the GPS on? I know with a regular gps unit, it causes a lot of interference with scanners.

Can the GPS be turned off?

Why hasn't anyone came out with a scanner that is able to monitor DIGITAL FM Radio? (THAT WOULD BE NICE) Digital TV would only be limited to the audio of the TV which personally I find boring!

On fire tone out could you add Tagging per the tone out & Frequency?



~Stlouisx50~

 

[CanadaDude]

Wildcards on iCall

I would like to see wildcards for iCalls added.

I only want to hear police icalls in my town, all on i02xxx
NOT the friggin busses (i08xxx, i07xxx) Too many to lockout using conventional means.

 

[UPMan]

Steps: Yes

Audio: Better

GPS: I am not sure what you are talking about. GPS can't cause birdies, since birdies are internally generated signals and whatever GPS you choose to use will be an external device. I've not heard reports of interference issues from external GPS's on the other models.

GPS Power: I do not know of any GPS units that do not have the ability to be turned off.

Digital FM: $ to implement at this time.

Tone Out Tagging: Assuming you mean alpha tagging of each slot, it has that, now.

 

[stlouisx50]

Steps: Yes

Audio: Better

GPS: I am not sure what you are talking about. GPS can't cause birdies, since birdies are internally generated signals and whatever GPS you choose to use will be an external device. I've not heard reports of interference issues from external GPS's on the other models.

GPS Power: I do not know of any GPS units that do not have the ability to be turned off.

Digital FM: $ to implement at this time.

Tone Out Tagging: Assuming you mean alpha tagging of each slot, it has that, now.

As far as steps that sounds great.

I was thinking the Scanner had some type of GPS built into it... such as that of the Radar Detector Escort 9500CI

I never knew that you could label/tag a Tone out tone. Very cool

 

[scannersnstuff]

will the 346 look like the 246 or the 330 ?.