9500i TrueLock testing on the bench - Take II

[jimbonzzz]

I did some more bench testing of the 9500i's TrueLock feature. The first thread is here:
http://www.radardetector.net/viewtopic.php?t=25198

A thread somewhat explaining the "segments" is here:
http://www.radardetector.net/viewtopic.php?t=25185


In Test 1, The reason that the entire K-Band ended up being locked out in this test is due to the way the 9500i works, as shown in tests 4 and 5.

Tests 2 and 3 show that when you lock out a K-Band signal, it only locks one 30 MHz segment. Does the 9500i inherently lock out the entire K-Band? NO.

Tests 4 and 5 show that the 9500i "remembers" recently detected signals, and when you lock out a signal, it doesn't only lock out the signal the detector is alerting to when the button is pressed, but also locks out other recently detected signals in the same geographical area!

These tests should also show that the frequency displayed in Spec Mode IS tied to the lockout feature. If you lock out one frequency, it locks out that entire ~30 MHz segment, and that segment will no longer be displayed in Spec Mode if locked out.

Test-1
1. Demonstrate that nothing is locked out
2. Lock out X-Band frequency
3. Drive down the road 1.5 miles with 9500i, and come back
4. Result: X-Band locked out, and entire K-band locked out.

Test-1A
Unlocked X-Band, K-Band also unlocked.


Test-2
1. Demonstrate that nothing is locked out
2. Drive down the road 1.5 miles with 9500i, and come back
3. Lock out 24.110
4. Drive down the road 1.5 miles with 9500i, and come back
5. Only one 30 MHz segment locked out, the rest of the K-Band alerts


Test-3
1. Demonstrate that nothing is locked out
2. Drive down the road 1.5 miles with 9500i, and come back
3. Lock out 24.195
4. Drive down the road 1.5 miles with 9500i, and come back
5. Only one 30 MHz segment locked out, the rest of the K-Band alerts


Test-4
1. Demonstrate that nothing is locked out
2. Cycle Power etc
3. Hit detector with 24.090, but did NOT lock it out
4. Hit detector with X-band frequency, lock it out
5. Cycle power
6. Result: X-Band frequency locked out, and K-Band segment for 24.090 also locked out


Test-5
1. Demonstrate that nothing is locked out
2. Cycle Power etc
3. Hit detector with 24.090, but did NOT lock it out
4. Hit detector with 24.148, lock it out
5. Cycle power
3. Result: 24.148 segment locked out, and K-Band segment for 24.090 also locked out

[SmaartAasSaabr]

Good stuff. Have I ever told you you'd have a great future in clean room engineering? :P

edit

It appears they've set this up for a novice user, just to kill anything within a certain radius with one press instead of getting one signal at a time. Hmm....

[<<JAZZY>>]

Jimbonzzz, do you honestly think that the 9500i can be corrected with a firmware revision or is it probably never going to work?

[ahmadr]

This explains everything. What a silly design from Escort! I bet the engineer behind it had little sense of what/how a RD is used in real life and the priorities involved. Scary!

Even more silly is that someone outside Escort must discover it Great job Jim.

That said, it is most likely that incorrect lockouts would rarely occur for normal users (that don't mess around with it too much). BUT, having a logical lockout would also have few errors. And I would rather deal with locking out a false twice than getting busted!

Now we must beg Escort to remove this feature!! - or just let them deal with more returned 9500s

[SmaartAasSaabr]

It would seem simple to allow a user-configurable Windowze app running through the USB port to configure it. User-programmable guardbands and the multiple freq surpression turned on/off...

[jimbonzzz]

Jimbonzzz, do you honestly think that the 9500i can be corrected with a firmware revision or is it probably never going to work?

I think they designed it that way on purpose, so I would be surprised if they were to change it.

[bauzer71487]

I think its both genius and retarded that it locks out alerts that were relatively close to the location. But I think we all agree that the ~30mhz is needed as a spacer incase the radar drifts(which we all know it will)

I also have the feeling that if a road had 2 stores on it with K band alerts - and I assumed they were teh same one - I would think that it would be broken after I had already locked out the first one.

Its a tossup on the engineering - I'm sure that the reasons to do it outweighed the negatives. So that is why they did it - and most likely won't change it in this detector. Maybe the 9500i x50

[ES13Raven]

Jimbonzzz, do you honestly think that the 9500i can be corrected with a firmware revision or is it probably never going to work?

What do you care? You have your V1... :roll:

[ES13Raven]

This explains everything. What a silly design from Escort! I bet the engineer behind it had little sense of what/how a RD is used in real life and the priorities involved. Scary!

I agree... There are some things implemented in programming that are totally unnecessary, and some things that can be changed - which need to be. This is a "no brainer" to me, and most of the users of this forum.

Escort - please fix this!!! :!:

[thestaton]

ok, i'm trying to understand why it locked out all of the K band when you only locked out an X band?

but yet in another test did not... so if there is a single X band in the area don't lock it out unless there is also a K band present?

thanks for the testing jim just trying to figure it out.