The jamming algorithm?

[fr0st]

Hey all,
I'm kind of new to the world of jamming. I've been trolling for info in the past couple of days on the more technical aspects of jamming and need a bit of help.

I'm a (bored) engineering student from Australia with a fair bit of microcontroller and analog circuits knowledge. I'm fairly confident I can make the required circuitry to recieve and transmit IR effective enough to produce a working jammer. I figured I'd use LED's as they're cheap and they work for blinder so why not?

What I'm stuck with is the way the 'smart jam' works.
In a perfect world, the IR pulse would come in exact intervals so you could predict exactly when the next pulse is due and produce your own pulse to fool the gun into reading a false distance (and hence speed).

Theres a few things that stop this from working...
1. If you moving towards the gun, the timing changes since your closing distance on the gun. This is about a nanosecond every pulse so not a huge concern.

2. A 20MHz Pic microcontroller using its capture module can sample a waveform 5MHz, a 200ns resolution. This completely rules out precision timing.

3. Stealth mode

To address the first I came up with the following -
Use the microcontroller to measure the time between pulses as best you can. Since you can't predict anything with the first two pulses you don't bother jamming them. For the pulses following you spam the interval that you think the pulse will come based on the time between the last two pulses.

Say the pulse timer has a value of 1000, this means the next pulse must come between 1000 and 1001. Since we're limited by the resolution of the timer, you have to start jamming when the timer reachs 1000 and stop when you recieve the real pulse from the gun (to reduce error codes).

Someone posted a picture of the blinder board which showed its little atmel microcontroller. Since there not exactly loaded with insane amounts of processing power, I assume blinder is using a similar algorithm for jamming.

Just a note, the microcontroller wouldn't be generating the timing for the LED's, only when to turn on jamming. The pulse duration would be too short for the uC to do in software so it'd be easier to have an external oscilator to drive the LED.

This still leaves the stealth mode, which will no dout render this type of algorthm useless. I havn't been able to find much info on it but I assume it sends a few pulses and delays a random amount of time and then sends pulses again.

The only way I can see of getting around this is if stealth mode uses a fixed delay's between pulses and a fixed large delay between groups of pulses. Theres alot of processing time between pulses that could be put to use looking for patterns in the pulse timing. Or perhaps if we could get the data, calculating the PPS and loading a profile based on each gun on how best to jam it to reduce error codes.

Can anyone shed some light on this?
Sorry if its a bit confusing, I tried to explain as clear as I can :?

[andi]

There are a lot of interesting Threads:

http://www.radardetector.net/viewtop...er=asc&start=0

http://www.radardetector.net/Laser-J...rams-8799t.php

[ronsc1985]

I think you are making this more complicated than it needs to be.

a. With respect to pulse timing all you need to do is figure out what the PPS of the gun is. This is easy as the gun pulse rates are very slow, in the 100-300 pps range. If the processor you choose is too slow for the required resolution just use the processor crystal frequency and an external counter and read in the results. Using your 20 mhz processor this would get you 50 ns resolution which should be good enough. What you need to do is provide a skewed pulse in the time range from when you will receive the next pulse and the round trip flight time you wish to operate in. At 50 ns you would be O.K. until the car got within 25 feet of the gun. If you want better get a faster oscillator and divide down for the processor clock input. Either that or use a faster processor to begin with.

b. With respect to the stealth mode as I understand it they just send two pulses keyed by the operator. If he gets a reading with these two you are screwed, however if he repeats you already know the pulse spacing and you can screw with the second pulse he sends such that he gets a quick return and therefore a really high computed speed. This is actually no different than the other case except that case you probably want to provide jitter in the pulses you send back so the gun cannot get any reading, fast or otherwise.

Hope this helps. BTW if you are a EE student and are bored with your classes, take harder classes. I can personally guarantee that at higher levels you won't be bored, maybe confused, but definitely not bored.

[jimbonzzz]

I'll throw in my 2 cents:

Theres a few things that stop this from working...
1. If you moving towards the gun, the timing changes since your closing distance on the gun. This is about a nanosecond every pulse so not a huge concern.

Yep, not a huge concern. Jammers generally continue to evaluate incoming pulses as you approach the gun, and send the jamming pulses accordingly so they always make it into the time window where the gun is expecting a pulse.

To address the first I came up with the following -
Use the microcontroller to measure the time between pulses as best you can. Since you can't predict anything with the first two pulses you don't bother jamming them. For the pulses following you spam the interval that you think the pulse will come based on the time between the last two pulses.

Sounds like the right idea to me. In fact, I believe that Blinder calculates the timing based on averaging the first four pulses received. It doesn't jam all pulses, just enough to prevent a speed reading. It will "sync" using the first four or so pulses, and will then send a series if jamming pulses, after which it "syncs" again.

Someone posted a picture of the blinder board which showed its little atmel microcontroller. Since there not exactly loaded with insane amounts of processing power, I assume blinder is using a similar algorithm for jamming.

That was probably me. And yes, it uses something similar...

2. A 20MHz Pic microcontroller using its capture module can sample a waveform 5MHz, a 200ns resolution. This completely rules out precision timing.

I pretty much agree with ron here, maybe you're overcomplicating things a bit...
Maybe that PIC isn't the way to go, nor is sampling the waveform. For example, one might use the received pulses to trigger interrupts directly...

3. Stealth mode


This still leaves the stealth mode, which will no dout render this type of algorthm useless. I havn't been able to find much info on it but I assume it sends a few pulses and delays a random amount of time and then sends pulses again.

The only way I can see of getting around this is if stealth mode uses a fixed delay's between pulses and a fixed large delay between groups of pulses. Theres alot of processing time between pulses that could be put to use looking for patterns in the pulse timing. Or perhaps if we could get the data, calculating the PPS and loading a profile based on each gun on how best to jam it to reduce error codes.

It does use fixed delays...
As far as I know, there's NO randomness to stealth mode at all, the pulses are periodic and just as predictable as the other guns/modes. The only difference is that it pulses twice, then delays long enough to "fool" the detection algorithms in the detectors and jammers, then pulses twice again etc etc. Generally, to prevent false alerts, the detection algorithms in most of these units required that there be three (or more) pulses received before and alert/jam was triggered. Stealth mode takes advantage of this to prevent detection and jamming.

Just a note, the microcontroller wouldn't be generating the timing for the LED's, only when to turn on jamming. The pulse duration would be too short for the uC to do in software so it'd be easier to have an external oscilator to drive the LED.

Jamming pulse duration doesn't matter, only leading edge is used by the gun, which is why LED jammers like Blinder and ZR3 can still do pretty well...

Jim

[kpatz]

Stealth mode sends out 2 pulses, then pauses, then 2 more pulses, then pauses, etc. 2 pulses by themselves can measure distance, but not speed, unless the individual pulses are spaced far enough apart for the target to get measurably closer/further away. And then the gun has to receive the pulses in order to take a measurement. Due to aiming, reflections etc. not all pulses are received by the gun. This is why stealth mode takes longer to lock in a speed.

Jimbonzzz measured the pulse rate of a LA gun in stealth mode and measured 68 PPS, so that's probably the time between pairs of pulses.

Since there's fewer pulses in stealth mode, it's actually easier to jam, once you have the algorithm down.

[fr0st]

If the processor you choose is too slow for the required resolution just use the processor crystal frequency and an external counter and read in the results. Using your 20 mhz processor this would get you 50 ns resolution which should be good enough. What you need to do is provide a skewed pulse in the time range from when you will receive the next pulse and the round trip flight time you wish to operate in. At 50 ns you would be O.K. until the car got within 25 feet of the gun. If you want better get a faster oscillator and divide down for the processor clock input. Either that or use a faster processor to begin with

I pretty much agree with ron here, maybe you're overcomplicating things a bit...
Maybe that PIC isn't the way to go, nor is sampling the waveform. For example, one might use the received pulses to trigger interrupts directly...

The capture module itself is an interupt. The PIC (and most other uC's) have an internal timer. The capture module copies the value of the timer (16 bit's) to its own register and then resets the timer ready for the next event whenever an interupt is detected. A 20MHz pic has a instruction clock of 5MHz, which is what the timer runs from. So the resolution is limited to 200ns. Using software interrupts needs multiple instructions to be executed so its resolution would be atleast 5 times worse.

With respect to the stealth mode as I understand it they just send two pulses keyed by the operator. If he gets a reading with these two you are screwed, however if he repeats you already know the pulse spacing and you can screw with the second pulse he sends such that he gets a quick return and therefore a really high computed speed.

As far as I know, there's NO randomness to stealth mode at all, the pulses are periodic and just as predictable as the other guns/modes.

Thanks for the info
So its just short delay and then a long delay. I was expecting it to be alot more complicated than that. You could change the algorithm to measure the time between 3 pulses so you capture the short and long delay. Then is just a matter of syncing to the pattern of the gun... not that hard at all :wink:

Jamming pulse duration doesn't matter, only leading edge is used by the gun, which is why LED jammers like Blinder and ZR3 can still do pretty well...

The problem would be getting the jammer to send the edge in the time window that will jam the gun. If I'm limited by the 200ns resolution I can only achieve about 60 meters before the jammer becomes ineffective. If I can send 5 pulses in 200ns instead of 1 there a greater chance I get one in the window and jam the gun.

So the purpose of the pic here would be when to start and finish the jamming. If I drove the leds using a 10MHz clock I could jam effectively up to about 30 meters. The pic would turn the clock on when it thinks the jamming window is so it gets out as many pulses as possible without being limited by the .
It would probably generate error codes this way but since you don't know your distance from the gun I don't think theres a better option unless you sacrifice jamming distance for the sake of error codes.

[ronsc1985]

The capture module itself is an interupt. The PIC (and most other uC's) have an internal timer. The capture module copies the value of the timer (16 bit's) to its own register and then resets the timer ready for the next event whenever an interupt is detected. A 20MHz pic has a instruction clock of 5MHz, which is what the timer runs from. So the resolution is limited to 200ns. Using software interrupts needs multiple instructions to be executed so its resolution would be atleast 5 times worse.

I think you're missing the point here. The idea is to use external timing circuits, designed and constructed by you, to achieved the desired resolution. Similar methods have been used forever when the resolution of the processor couldn't do the job and a processor was desired for other reasons.

A better solution would be to use a fast enough processor. Many are available in the 100-300 MHZ and faster range from all sorts of suppliers such as Digi-Key. That said it is probably more fun and certainly a better learning experience build your own circuitry using SSI and MSI circuits rather than spend most of your time writing code.