"Search with Scan" and BCD396XT

[BenJJ]

I have a question concerning how Search with Scan works on the BCD396XT.

The BCD396XT has been programmed with several conventional systems and three Custom Search ranges. I then have started a scan, and the BCD396XT will start scanning through the enabled systems.

Finally after scanning through all the enabled systems/groups, it starts searching through the three Custom Search ranges. Now according to the "BCD396XT Complete Reference" pages 111-113, on "Scanning Order", after completion of the the last custom search range, it should return to scanning the first enabled conventional system.

However my BCD396XT returns to the beginning of the 3rd and last custom search range and starts going through the range until it hits the upper frequency limit, then it returns to the lower limit frequency and searches through this last custom range again. It does this over and over.

Every once in awhile it will return to start scanning the first enabled conventional system and work its way through the hierarchy of the scanning order, but not often.

How come my BCD396XT doesn't return every time to the first enabled system, instead doing an infinite loop through the last custom range?

Anyone have a clue what I'm doing wrong?

[UPMan]

If the systems are conventional, the scanner could be scanning them so quickly that itusually doesn't have time to actually display the system info. To confirm for yourself that it is, indeed, scanning the system try adding a known constant signal (like a NOAA station) into System 1. When it stops on the xmission, press scan...it should go through all the other conventionals, then the custom searches, then stop on the NOAA station in System 1 again.

[BenJJ]

Originally Posted by UPMan

If the systems are conventional, the scanner could be scanning them so quickly that itusually doesn't have time to actually display the system info. To confirm for yourself that it is, indeed, scanning the system try adding a known constant signal (like a NOAA station) into System 1. When it stops on the xmission, press scan...it should go through all the other conventionals, then the custom searches, then stop on the NOAA station in System 1 again.

Thanks Upman (I'd hope you'd respond to my question)!

I'll give what you mentioned a try, and let you know.

As additional background info to my problem, I forgot to mention in my first post that I setup Startup key "0" to startup the conventional system (start up one system out of about 16), plus the three custom search ranges. I mention that as perhaps it might affect this problem

[BenJJ]

Upman:

I added the NOAA frequencies as you suggested to my enabled conventional system, and have some puzzling results to report; perhaps you will be able to figure out what is going on.

Before I give you my test results, I'll give you some more background info on what I'm trying to do. My conventional system (SQK = "0") covers all aeronautical frequencies, both commercial and military. These frequencies are divided into 8 groups. The frequencies range from about 118 Mhz to about 350 Mhz.

For the Search with Scan, I have edited the first three Custom Searches as follows:
Commercial Air Search: 120.000-137.000 Mhz
Mil Air 1 Search: 137.000-144.000 Mhz
Mil Air 2 Search: 225.000-400.000 Mhz

I have set the SQKs for these three custom search ranges to "16". Further I have set the Startup Key for the conventional aeronautical system, and all three custom searches to "0".

Now back to my puzzling results from the test. Upon startup from off (no Start Up key used), the 396XT goes through the conventional aeronautical system, normally, stopping at hits on VHF and UHF, including the inserted NOAA frequencies that I have placed in the Group folder "Found Frequencies".

From there it goes to the 1st custom search, Commercial Air Search: 120.000-137.000 Mhz , and starts stepping sequentially through the frequencies to 137.000 Mhz. (Now the puzzling behavior starts.) Instead of going to Mil Air 1 Search: 137.000-144.000 Mhz, it instead RETURNS to the beginning of Commercial Air Search and steps sequentially as far as 122.000 Mhz.

Then it jumps directly from 122.000 to Mil Air 1 Search: 137.000-144.000 Mhz, but not at 137.000 Mhz, it starts at 142.000 Mhz, then steps sequentially to 143.000 Mhz. Instead of continuing on to 144.000 Mhz, it RETURNS BACK to the beginning of Mil Air 1 Search: 137.000-144.000 Mhz where it searches normally through this range.

When it gets to the 144.000 Mhz of Mil Air 1 Search, as expected, it goes to searching Mil Air 2 Search: 225.000-400.000 Mhz, where it runs all the way to 400 Mhz, then returns to the beginning to scan the conventional aeronautical system and start the whole sequence over again.

What can you make of those results...puzzling, right?

I let the 396XT do this Search with Scan about ten times, and it did the the same thing each time, except for one time (about the 5th time through the Search with Scan), when it behaved like it should do per the Complete Reference.

Note that the behavior I've just described is DIFFERENT from my first post. Before I added the NOAA frequencies to the conventional aeronautical system, the 396XT was stuck in an (almost) infinite DO loop in the 3rd Custom Search range, Mil Air 2 Search: 225.000-400.000 Mhz. I say "almost" infinite because every once in awhile it would return back to the beginning to start scanning the conventional aeronautical system.

UPDATE to above:
In the 20 minutes or so it took me to type the above, I had the 396XT off. When I turned it back on, guess what...it behaved as it should scanning through the conventional system, stepping through Commercial Air Search:120.000-137.000 Mhz, and when it reached the end, it transitioned normally to Mil Air 1 Search, then to Mil Air 2 Search, then back to conventional aeronautical system, to start over again.

It did this flawlessly three times scanning through the conventional system and searching the three custom ranges...until I decided to push the envelope. On the fourth time through the Search with Scan it stopped on a birdie (I guess that's what it is, a frequency that just has static) in the Mil Air 2 Search: 225.000-400.000 Mhz.

Instead of turning the scroll control knob to get it "unstuck" from that frequency (like I did with the first three times), I hit the button "L/O". Guess what... it started doing the original problem of doing an infinite DO loop in the last search range Mil Air 2 Search: 225.000-400.000 Mhz.

Arghhh! I think I'm going mad!!

[BenJJ]

After doing additional testing, I think using "TEMP L/O" to lock unwanted frequencies is causing the problem during Search with Scan, causing it to do infinite DO loops.

The work-around is to not use "TEMP/LO" during Search and Scan; unfortunately not using "TEMP L/O" really cripples the flexibility of this $500 scanner.

[DaveeCom]

BenJJ, do you have hold set to something greater than zero for all the scanned items? If the last custom search is repeating before returning to the other systems, I would check and make sure HOLD is zero for every system you want sequentially scanned. Otherwise the item with non-zero hold time will repeat until the hold interval elapses.

[BenJJ]

Originally Posted by DaveeCom

BenJJ, do you have hold set to something greater than zero for all the scanned items? If the last custom search is repeating before returning to the other systems, I would check and make sure HOLD is zero for every system you want sequentially scanned. Otherwise the item with non-zero hold time will repeat until the hold interval elapses.

I just started up Freescan to check the HOLD time for these custom searches, and I confirmed that they have been set to "0" all this time.

Also I had set for these three custom searches that the "ENABLED" boxes are all checked, and the "LOCKOUT" boxes are all unchecked.

Thanks for the information, but unfortunately it probably isn't the cause of this infinite DO loop. (I wish it was because then we could blame "user error" and that would be the end of the story, instead of the situation where there might be a fundamental problem with the BCD396XT scanner.)

[DaveeCom]

Other than a user issue, it seems like this would be easy to verify if it's a firmware problem or a bug. If it's a firmware problem then your checksum would be different then everyone else's. My checksum is: 11E and the firmware version is 1.04.04.

If you've found a new bug then it should be reproducible on all the other radios. If you want to find out then you would need to upload your settings to someone else and see what their radio does with your settings in their radio.

[BenJJ]

Originally Posted by DaveeCom

Other than a user issue, it seems like this would be easy to verify if it's a firmware problem or a bug. If it's a firmware problem then your checksum would be different then everyone else's. My checksum is: 11E and the firmware version is 1.04.04.

If you've found a new bug then it should be reproducible on all the other radios. If you want to find out then you would need to upload your settings to someone else and see what their radio does with your settings in their radio.

Okay, I've just checked my 396XT scanner info and here's what I found:
Firmware Version: 1.04.04
Sum = 143

I have no idea what a checksum is, and how it affects my scanner. I saw it mentioned on one of the Uniden online registration webpages, but I didn't know what it meant.

None of my previous scanners had anything called a "checksum" (non-DMA scanners).

Can someone clue me in as to what I need to do now.

Thanks.

[DaveeCom]

The checksum is a number that is the result of adding all the firmware memory contents. It's used to make it easy to tell if the system code (the firmware of the radio) is different than another radio.

I expected your radio to have the same checksum as mine since we both have the same version. I didn't expect it to be different. Although it's hard to believe - it tells me that our two radios have something different in their two memory images. Why, I have no idea.

I think I'm getting in over my head now. Maybe there's someone who could look into this to see if this means anything significant.

[UPMan]

The checksum displayed is only a checksum for the units ESN. It has nothing to do with the firmware and cannot be used to validate the firmware. It is used to ensure that a valid ESN is entered when applying major firmware updates. Only 1 in FFFh scanners will share the same checksum.

BenJJ: Email (not PM) me directly at popitz@uniden.com. I'd like to get a clone of your setup (I'll provide the clone tool and a web page to save the dump to).

[DrAncell]

I progammed my new 396xt with MPSCS and Oakland Cty Conventional systems. The MPSCS takes about 60 seconds to cycle to the Oakland System. I tested it by deleting all the groups from MPSCS and had the same problem. My hold is on Zero. I also ran the 396xt against 396t and is obvious that I was missing a large number of Oakland Cty transmissions.

What is going on. Can anyone help.

[rvictor]

Originally Posted by DrAncell

I progammed my new 396xt with MPSCS and Oakland Cty Conventional systems. The MPSCS takes about 60 seconds to cycle to the Oakland System. I tested it by deleting all the groups from MPSCS and had the same problem. My hold is on Zero. I also ran the 396xt against 396t and is obvious that I was missing a large number of Oakland Cty transmissions.

What is going on. Can anyone help.

You'll generally get quicker responses if you start a new thread rather than putting your question in someone else's thread.

Dick

[BenJJ]

Originally Posted by UPMan

The checksum displayed is only a checksum for the units ESN. It has nothing to do with the firmware and cannot be used to validate the firmware. It is used to ensure that a valid ESN is entered when applying major firmware updates. Only 1 in FFFh scanners will share the same checksum.

BenJJ: Email (not PM) me directly at popitz@uniden.com. I'd like to get a clone of your setup (I'll provide the clone tool and a web page to save the dump to).

Roger that, I sent you an email last night; I await for your reply.

[UPMan]

I have received no email.

[FlashP]

A similar 'feature' is present in the 996. For some reason, the scanners insist on going through a complete clean cycle of the entire search range prior to moving to the next: if the search pauses (even without breaking squelch), it resets its starting point and loops through everything in that system again, wrapping around as necessary. Really irksome, since it can repeat indefinitely - my XT just spent 5 minutes on a 22-step search range when I was confirming this.

I would expect the scanner to operate as such when hold time equals zero:
exit system A (whatever)
go to system B (our search band)
begin at one programmed limit (hi or low, depending on up-arrow or down-arrow)
check each step once, pausing as necessary based on squelch, user HOLD, etc.
reach the opposite limit
go to system C

The 'history' of stopping during the search should have no effect whatsoever on choosing the next channel; with 25,0000 channels and ten possibly huge search bands, I want the scanner to finish in a determinant time.

Flash

[BenJJ]

Originally Posted by UPMan

I have received no email.

Upman:

That's strange you didn't get my email...I sent it from my yahoo.com account.

I will try sending it again.

[BenJJ]

Originally Posted by UPMan

I have received no email.

Upman:

I just forwarded my original email to your address at popitz@uniden.com.

If you didn't receive it again, try sending an email directly to me at benjamesjohnson@yahoo.com.


Thanks.