Page 1 of 3 123 LastLast
Results 1 to 10 of 25

Thread: why 30MHz

  1. #1
    Good Citizen
    Join Date
    Jul 2006
    Posts
    77

    Default why 30MHz

    Ok why does the truelock work in approximately eight segments of +/- 30MHz on K? why cant it just lock out the exact MHz?

    and if your going to say "well it changes". It should lock out what it changes to too duh. So maybe its like 1-2 MHz locked out. That way the chances of it locking out a cops radar is very unlikely.

  2. #2
    Professional
    Join Date
    Jan 2008
    Location
    Nevada
    Posts
    1,183

    Default

    To cover frequency drift. If you use your detector in SpecDisplay you'll notice the signal is not always stable dead on at a given frequency, you'll also find in daily driving many false signals will drift up and down over time. Usually this drift is contained within that specified block they allocate to it.

    From my own experience with using it I would have to say they did their homework rather well in coming up with the values they did. This is also taking them just out of the range in which two seperate signals are going to walk on each other at.

    and if your going to say "well it changes". It should lock out what it changes to too duh.
    Duh, thats exactly what they are doing with the blocks.

  3. #3
    Banned
    Join Date
    Jun 2007
    Posts
    9,497

    Default

    X2 Esoterica.

    Good question Ghost917,

    If it was 2-3MHz blocks you would pass the false after locking it out and say, I just locked that the other day why is it falsing again? Then after calling Escort about 3 times and locking the same false 12 times (essentially locking a 30MHz block) you would return the unit and hate Escort.
    There is frequency drift, In/Out door falses from the same door, and the RD may also get a +-1-2MHz inconsistency.

    Let’s say there is a standard drift of 10-15MHz and there are 2 In/Out falses for every door, to cover frequency drift in both directions (up/down) a 30MHz would be safe.
    Escort did there homework, the 30MHz wasn’t out of thin air. Frequency drift from day to day would be a huge problem if they did much less than a 30MHz block or so.

    Even with the 30MHz block you will see a previously locked out false on rare occasions alert.

    Personally I think you should be allowed to program in what frequency your local LEO's use, (there radar doesn't really drift much) and the 9500I could always monitor or prevent lock out on that block/specific frequency.

  4. #4
    Old Timer
    Join Date
    Nov 2006
    Location
    Cleveland/Shaker Heights, Ohio, USA
    Posts
    7,732

    Default

    Quote Originally Posted by CJR238
    Personally I think you should be allowed to program in what frequency your local LEO's use, (there radar doesn't really drift much) and the 9500I could always monitor or prevent lock out on that block/specific frequency.
    Now *that* would be lovely!

  5. #5
    Advanced Member
    Join Date
    Dec 2004
    Location
    Michigan
    Posts
    7,509

    Default

    The blocks are 30 MHz wide in order to to compensate for frequency drift of both the radar source, and frequency drift of the detector's oscillators.

    The radar detector isn't an expensive microwave frequency counter, and itself isn't stable enough to determine the frequency of a radar source accurately down to 1 MHz. For example, see below for a test I did a while back using the RX-65.

    Quote Originally Posted by jimbonzzz
    I decided to re-do my test, only this time I used a freq counter to display the actual frequency of the generated signal to compare with what the RX-65 displays. I also went through the entire K band, in 10 Mhz increments.

    For the photos of each 10 Mhz increment, go to:
    http://www.kc8unj.com/radar/freq/







    Here are my results:

    Freq Counter / RX-65

    24.010 - No Alert
    24.020 - 24.050
    24.030 - 24.050
    24.040 - 24.066
    24.050 - 24.066
    24.060 - 24.082
    24.070 - 24.082
    24.080 - 24.100
    24.090 - 24.100
    24.100 - 24.116
    24.110 - 24.116
    24.120 - 24.132
    24.130 - 24.132
    24.140 - 24.150
    24.150 - 24.150
    24.160 - 24.150
    24.170 - 24.166
    24.180 - 24.166
    24.190 - 24.182
    24.200 - 24.182
    24.210 - 24.200
    24.220 - 24.200
    24.230 - 24.216
    24.240 - 24.216
    24.250 - 24.232
    24.260 - 24.232
    24.270 - No Alert

    As you can see, these results are consistent with the results of the little test I did back in February. I can explain what I am measuring, and I can repeat it as many times as you like, which you said is the mark of good test results.

    Worst case, it could be about 30 MHz off of the actual frequency. Average is about 14.8 MHz, which equates to about .1% in a 15 GHz LO, just like I have speculated in other posts, and just like the example they use in their patent.

    Since there IS a pattern, I can certainly understand how you might think this is some channel scheme being utilized by the source, but this test should show that what you are seeing is clearly a limitation of the detector.

    Jim

  6. #6
    Good Citizen
    Join Date
    Feb 2008
    Location
    Raleigh, NC
    Posts
    198

    Default

    Freakin' Exactly!

    Hypothetical Letter if people were wondering.

    Dear Escort,

    Here is a solution someone should have thought of already, but since I came up with the idea, I guess you can send me the check. So here it is:

    First, let me refer to the YouTube video made by RadarScandal, a member of RadarDetector.net, the link to the video being YouTube - Escort 9500i TrueLock Problems
    This is a great video that directly addresses the biggest issue with the Escort Passport 9500i, the TrueLock. I do have several criticisms about how the test was conducted. Mainly, I feel that the tester should have been more patient with changing the frequency, the 9500i was having a hard time keeping up with the changing frequency. I hope he conducts a second test where he slows down the change of frequency and also conducts the experiment in a room that inhibits radio waves from bouncing around. The reason being that the radio waves with the old frequency is still bouncing around. I did however enjoy watching the tester move slowly within the blocked out frequency. I got the following data from watching closely on the second trial run where he blocked out 24.201 GHz.

    (Because the Table could not be structured correctly in this post, this might be a bit confusing below, but I tried my best. Just note this is a 3 by 3 table with Cell 1,1 empty.)

    First number: Emitted Frequency (GHz)
    Second Number: Measured Freq. by 9500i
    Lower Band Limit: 24.197 ; 24.179
    Set LockOut: 24.201 ; 24.215
    Upper Band Limit: 24.230 ; 24.242

    What I mean by "Band Limit". When the tester dialed the emitted frequency lower than the "Lower Band Limit", the 9500i gave out an alert. The same definition applies to the "Upper Band Limit" where when the tester dialed above 24.230 GHz, the 9500i alerted.

    If you look at my table above you will notice that there are significant discrepancies between what the emitted frequency was set at and what the 9500i was measuring on its end. Personally, I have not made up my mind of which set of numbers we should all concentrate on yet, the frequency set by the "radar gun" or what your 9500i is picking up. So I will refer to both sets of numbers for now.

    First analysis is to measure how big the block-out is within the K band range. Based on the radar source, the lockout was based on 24.201 GHz with the “silent” range being 24.197 to 24.230, which is 33 MHz big. What is interesting is that this “silent” range is not evenly distributed around the lockout target of 24.201 GHz, rather it’s (-4 MHz) 24.201 GHz (+29 MHz). This is not good, we don’t want uneven block-out ranges around the target, unless of course emitting sources tend to fluctuate unevenly. But wait, that doesn’t make any sense, so we need the 9500i to apply an even block-out range over the target lockout frequency.

    Lets do this same analysis on the measured frequency. The lockout target is actually now 24.215 GHz according to the 9500i with a block-out range of 24.179 to 24.242 GHz, which is 63MHz. This is twice as big compared to the source’s output. Distribution is: (-36 MHz) 24.215 GHz (+27 MHz). That is pretty much evenly distributed across the target lockout frequency.

    So as the 9500i sees it, it’s applying a lockout range of roughly +/- 30 MHz, which is what I’ve read people say again and again on this forum. So that is a positive match. However, as for the device producing the radio waves, it saw differently. According to its output, it saw the 9500 apply a block-out range of -4 and +29 MHz, or a total of 33 MHz. Unfortunately, I can’t just say +/- 15 MHz due to the severely uneven distribution.

    But lets move on. So the people at Escort did actually program into their 9500i to apply a block-out range of +/- 30 MHz around the target frequency producing a block-out range of about 60 MHz long. The problem lies with the 9500i not accurately measuring the correct frequency being emitted. Now this is where my criticism of the video comes into play and now you see is very critical! Maybe if the tester was more patient, the 9500i would have the time to measure the emitted frequency properly, or maybe the 9500i was being confused by bouncing radio waves traveling on the old frequency. Either way, I would like to see this test redone more carefully to eliminate more unwanted variables.

    If we can trust the source device, then the 9500i was actually only (unevenly) blocking out +/- 15 MHz (again not truly so, it was really -4/+29 MHz), or a total of roughly 30 MHz.

    With all this said, I’m going to focus now on what the 9500i measured, because that is what can be changed. Addressing the issue of the 9500i measuring the correct frequency is altogether a separate issue. With what I know now, I don’t know who to blame, the 9500i unable to measure frequency correctly or the tester from radardetector.net to conduct the experiment more slowly. But again, lets put that issue of measuring frequency aside. I will only focus on what Escort can program into the TrueLock feature.

    So according to what I’ve read from several people in this forum and what I witnessed while watching the referenced YouTube video, the people at Escort are programming a block-out range of +/- 30 MHz, totaling 60 MHz. And this is where I finally relate back to this thread, Why 30 MHz? Or more precisely, why +/- 30 MHz? Or Why 60 MHz block-out range?

    I suggest to Escort that they change this programming. Let me first make note of the two radio bands in question, the X band: 10.500 – 10.550 GHz (Total of 50 MHz) and K band: 24.050 – 24.250 GHz (Total of 200 MHz). Okay, so let Escort leave the 60 MHz block-out as a default. But what they need to change is by offering two alternatives. The owner should be allowed to change this setting and ask the 9500i to apply two different block-out ranges: +/- 5 MHz totaling 10 MHz (Precision Expert) and +/- 10 MHz totaling 20 MHz (Sharp). Lets play out this scenario I have created here.

    If it was me, I would change the default/factory settings and select “Precision Expert” from the menu. Over a period of two weeks during my daily commute, I have identified a false X-band emitting a frequency of 10.520 GHz. I now ask 9500i to block it out while running on “Precision Expert” mode. I have now locked out 10.515 to 10.525 GHz at that exact location. This leaves the rest of the X band open to alerts: 10.500 – 10.515 GHz and 10.525 – 10.550 GHz. That’s leaving 80% of the X band still active, while 20% is now blocked out. If I was running the 9500i on default mode, I would have blocked out the ENTIRE X band: 10.510 +/- 30 MHz = 10.490 – 10.550 GHz. I would have blocked out more than 100% of the X band (including frequencies outside/below the X band).

    We have now opened up 80% of the X band for any potential threats from real radar guns operating on the X band. But if I was running default, cops would be free to operate their radar guns anywhere on the X band and my 9500i would just blindly block it. So by using "Precision Expert" mode, I have reduced the risk of blocking out a threat operating on the X band.

    This idea applies to the K band as well. If I identified a false alert emitting a K band frequency at 24.150 GHz, then I would only block-out a range of 10 MHz while operating under “Precision Expert”, 24.145 – 24.155 GHz. Whereas the default setting of +/- 30 MHz would have locked out a huge block of 24.120 – 24.180 GHz. “Precision Expert” produced a block-out range spanning 5% of the K band, whereas default would have spanned 30%.

    Again, I have left 95% of the K band open to alerts if a cop where to operate his/her radar gun on the K band. This is a significant reduction in risk in comparison to running default mode where only 70% of the K band is active to alerts.

    One side issue, Escort should also impose a logic code where if the strength of the source is so strong, it should override the TrueLock. I might address this issue in my second post.

    If you are still reading this, I might know what you are thinking right now. If I block out such a small frequency range, I might still get that false alert the very next day due to fluctuations produced by the door opener, alarm system, or whatever it is. I agree, the chances are quite good that one won’t be able to lock out the total fluctuation from the source. But this is why I title the mode “Precision Expert”. The user has agreed to become an expert in blocking out false sources. The user must now inspect again this new alert to see if it’s the same false source. This is not impossible as one could drive towards the source and identify it visually. Also the user can read the measured frequency and if it’s close to the block-out limit, then that’s another piece of evidence that it’s coming from the same false source in question. A third technique is to make note of the strength of the alert, if it’s a weak source day after day, then this is another piece of evidence that it’s the same false source.

    Once the user has identified that the source is producing a frequency that tends to fluctuate out of the first blocked out range, then the user can block out the source for the second time, but it will be based on a different target frequency, either above or below the first blocked out range. This will add to the initial block-out range making it larger than 10 MHz to a maximum of 20 MHz, which is still much less than the default 60 MHz.

    Now if the owner feels like this is too much effort, the owner can move up to “Sharp” mode which blocks out +/- 10 MHz or a total of 20 MHz with every LockOut. This is 67% reduction from the default setting, hence the term “Sharp” mode.

    I will stop here due to the length of this write up. I will leave this open now to discussion. I would appreciate any comments or criticism and based on what everyone says, might continue my write up on this issue. Thanks for your patience by reading my entire post.

  7. #7
    Professional
    Join Date
    Jan 2008
    Location
    Nevada
    Posts
    1,183

    Default

    I wouldn't send Escort the link to the video you are using. It's my understanding from reading in another thread here just posted by him today that he admits that video is flawed. Why its still out there though I have no idea.

    The frequency reading in the detector does not need to be 100% accurate down to .00000f for it to work, if they did make it so, the thing would be priced far beyond any practical persons reach.

    Any idea what new test equipment capable of accurate measurement runs?

    Like about $3,000 for a cheap one, upwards to $5,000 to $7,000 for a good one.

    You need function in the detector, not scientific lab grade over kill. I'm not going to pay $8,000 for a windshield mount detector just so it displays the frequency down to .000000 when it isn't even remotely required of it. That's just ridiculous to even consider or contemplate.

  8. #8
    Advanced Member
    Join Date
    Dec 2004
    Location
    Michigan
    Posts
    7,509

    Default

    Quote Originally Posted by Esoterica
    I wouldn't send Escort the link to the video you are using. It's my understanding from reading in another thread here just posted by him today that he admits that video is flawed.
    Oh believe me, Escort has already seen it. And what I have heard, they had quite a bit of discussion about it ops: But after seeing that video, I think they decided to provide users with a bit more detail on how TrueLock works :wink:


    Quote Originally Posted by Esoterica
    Why its still out there though I have no idea.
    OK, one more time:

    I DID NOT POST THE ****ING VIDEO ON YOUTUBE, SO I CAN'T TAKE IT DOWN!!!

  9. #9
    Advanced Member
    Join Date
    Dec 2004
    Location
    Michigan
    Posts
    7,509

    Default

    You make some excellent suggestions for improving TrueLock (selectable block sizes, signal strength override). I think that some of the advanced detector users don't feel they have as much control as they would like. If it had features like this, they would be much happier.

    But I don't expect Escort to do anything like this. I think they're more concerned with making the detectors easy to use for the average joe instead of worrying about advanced users.

    Just a couple of other comments:

    Quote Originally Posted by SAfricanCracker
    Maybe if the tester was more patient, the 9500i would have the time to measure the emitted frequency properly, or maybe the 9500i was being confused by bouncing radio waves traveling on the old frequency. Either way, I would like to see this test redone more carefully to eliminate more unwanted variables.
    I was the tester...
    And it would have done the same thing if I had gone slow. The frequencies displayed in TechMode are in 30 MHz blocks, the same as for TrueLock. Perhaps I should have done this slower for demo purposes, but I had done extensive testing on the bench already and knew it didn't make a difference, and I didn't want the video to be HUGE.


    Quote Originally Posted by SAfricanCracker
    Mainly, I feel that the tester should have been more patient with changing the frequency, the 9500i was having a hard time keeping up with the changing frequency. I hope he conducts a second test where he slows down the change of frequency and also conducts the experiment in a room that inhibits radio waves from bouncing around.
    Doesn't make a difference....

    Quote Originally Posted by SAfricanCracker
    The reason being that the radio waves with the old frequency is still bouncing around.
    ????????


    Quote Originally Posted by SAfricanCracker
    So according to what I’ve read from several people in this forum and what I witnessed while watching the referenced YouTube video, the people at Escort are programming a block-out range of +/- 30 MHz, totaling 60 MHz.
    No, the blocks aren't +/- 30 MHz. The blocks are 30 MHz, period:



    Image from this thread:
    http://www.radardetector.net/viewtop...r=asc&start=60

  10. #10
    Good Citizen
    Join Date
    Feb 2008
    Location
    Raleigh, NC
    Posts
    198

    Default

    Quote Originally Posted by jimbonzzz
    Quote Originally Posted by SAfricanCracker
    So according to what I’ve read from several people in this forum and what I witnessed while watching the referenced YouTube video, the people at Escort are programming a block-out range of +/- 30 MHz, totaling 60 MHz.
    No, the blocks aren't +/- 30 MHz. The blocks are 30 MHz, period:
    If that is true, then why did the Escort Passport 9500i display 24.179 GHz when you began decreasing the frequency from the target lockout and then again displayed 24.242 GHz when you increased away from the target lockout? In other words, the Escort believed that it was only going to report to the user frequencies less than 24.179 GHz or greater than 24.242 GHz creating a block-out range of 63 MHz or roughly +/- 30 MHz between the two values.

    So aha... Here's where science notation comes into play and is ignored by many. The difference between using the symbol (+/-) and not using it before an uncertainty value in association with it's constant value. I am no expert in knowing the Escort Passport 9500i, so please don't portray my posts as all-knowing. I'm just using my science background to make sense of this all. Is the block-out range +/- 30 MHz or just 30 MHz? There's a difference of 100% between the two!

    And if one were to read my post carefully, I came to both results using two different methods. If I used data from the emitting source, I came up with a block range of 33 MHz or +4/-29 MHz. But if I were to base my data on the 9500i, then I get a block range of 63 MHz or -36/+27 Mhz.

    So what does the programmer at Escort do? He told his 9500i to block out 60 MHz range... Well tried to, that particular 9500i at that instance blocked out 63 Mhz pretty evenly. If the programmer told the 9500i to block out +/- 15 MHz, the detector would be displaying frequencies accordingly. For example, just before the tester pressed the mute button three times, the detector displayed 24.215 GHz. So if it followed its programming exactly, it would have displayed on its screen a frequency 24.200 GHz when the tester was dialing down or 24.230 GHz when dialing up.

    But here lies the problem, the detector displayed 24.179 and 24.242 GHz. Please note the symmetry here! These two numbers are VERY close to being symmetric around the target lockout of 24.215 GHz leading to the existence of background programming.

    But yes, you are correct. In reality (if we were to trust the source output over the 9500i readout), the 9500i blocked out just 33 MHz. But isn't strange that is was only -4 MHz below 24.201 GHz? That's rather tight? Just 4 MHz below. But it also blocked out +29 MHz above 24.201 according to the source output. That's rather strange... If the false source in real life situation were to fluctuate -6 MHz, your 9500i would display an alert while still applying this 33 MHz block!

    Hence I make my conclusion. In order to solve the problem of TrueLock, we must first identify the problem of the 9500i measuring the emitted frequency. What's happening? Is is due to the way the test was conducted in the video I referred to in my previous post or is it due to the 9500i itself?

 

 

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •