Detecting electronic article surveillance jammers

In 2007 I had the opportunity to work as a freelance hardware designer. I designed and built a jammer detector for EAS systems. You might want to read my page on EAS first.

Detecting jammers

Jamming circuits are extremely simple, and it is no surprise that thieves have started using them. As traversing the EAS portals with a jammer is at least as incriminating as traversing them with an active tag, there is not much need for rendering the portals immune to jamming. Detecting an active tag or a jammer is sufficient grounds for sounding the alarm. When there is a jammer, there is no need to know if there is an active tag or not.

If you are an EAS designer, adding jammer detection functionality to your portal is relatively easy: Since all but obsolete portals use digital signal processing, it is just a relatively simple matter of devising a detection criteria not too prone to false alarms and adding it to the signal processing algorithm.

However, if you have an already-installed EAS portal and wish to add jammer detection capability to it, you will need to use an extra device that will be able to tell apart a few things :

Rejecting the ordinary signal of the EAS portals is non-trivial, since good portals use irregular or randomized interrogation pulses to improve interference rejection from other systems (see the spectogram above).

Of course a jamming detection system could be tuned to a specific system on a specific site, but such tuning would likely be beyond the abilities of an average technician, and thus costly.

A digital system with an intelligent firmware using machine learning techniques can solve the problem. This is exactly the work I have done as a private consultant for a client selling EAS portals.

Developing the detector

My client sent me an acousto-magnetic portal and I studied its signal and the way it reacted to a jammer using scopes and a NI PCI-6221 DAQ card. I prefer spending bucks on hardware, so I used Octave, Tela and hand-written software to capture and analyze the signals. After I had a good idea of a discrimination algorithm, I researched how I could implement it at little cost. Digital signal processing was mandatory not only for good discrimination but also for upgrading the firmware should the thieves use harder-to-detect jammers.

Unfortunately, sampling the 58 kHz signal at baseband would have required a fast ADC and a fast DSP chip. DSP development kits by themselves being expensive, I looked for another solution.

The EAS signal is at 58 kHz but is a very narrow bandwidth one (a few kHz). So I figured that if I translated the signal to the 0-8kHz range, I could process it with a small CPU or maybe even a microcontroller.

After searching I found that there exist RF mixers ICs that can work almost all the way down to DC. So I used a MC1496 double balanced mixer to translate the signal from 58kHz to the 0-8kHz range and checked that it was possible to discriminate a jammer signal from the EAS signal.

Having grown up writing tight 68000, 680EC20 assembly code on the Amiga, I knew how to squeeze every last bit of computational power from even the tiniest CPU. I also have a taste for clean instruction set architectures and hardware with open specifications and open tools.

So I decided to do the signal processing and all the fancy keypad, LCD, SD card stuff using a 58 MHz ARM LPC2138, for which Olimex makes cheap kits. The LPC 2138 has only 32 kB of SRAM and lacks specific DSP facilities, but has a multiplier, on-board ADCs, can be RS232 programmed and runs quite fast. I used the GNU compiler suite and wrote /software/lpcsprg to program the ARM from the serial port.

MarieRTOS, my purpose-built kernel


Boot screen from marieRTOS, with debugging output enabled.


Snippet of adc.c. This piece of code runs in software IRQ mode. Its purpose is to bridge the FIQ (fast interrupt) routine (not shown here) that fills the sample buffer with the tasks that might need the ADC data, by answering requests arriving in a port, the general, zero-copy intertask communication mechanism in MarieRTOS (inspired from Amiga ports). The ARM FIQ mode has a restricted bank of registers that don't need to be saved. This is handy since the ARM doesn't have any DMA facilities. This greatly improves the efficiency and reduces the latency of data-copying routines. (The function adc_get_sample is only used for debugging.)

As this was a commercial project I did not want to be encumbered by any GPL clauses while minimizing the money I spend on non-essential gear. I needed to figure out exactly how the LPC 2138 handles interrupts (and especially the "fast" interrupts) anyway, so I decided to write my own little preemptive kernel. I decided to call it MarieRTOS, since Marie is a common woman's name in France. MarieRTOS has preemptive scheduling between tasks of the same priority level, inter-task communication and synchronization primitives and IO facilities (serial port, real-time clock, SD/MMC disk). It is inspired of the Amiga kernel. I also wrote a small C library, with a more rational API than the Unix one (for instance, passing the string length as an argument instead of using null-terminated strings is much more intelligent, IMHO.)

Jamcatch 3000, prototype 1

I built a first prototype and sent it to my client. I used a small LPC2138 development module but had to painstakingly wire all the rest of the circuit on perfboards. I love a good hour of soldering, but this one took me three days.

/resources/eas/jamcatch-prototype-2.jpeg.thumb.png An external view of the first prototype. "Therodox" was the name I chose for my little venture, and "JamCatch" the name for that particular product. I was hoping to continue in the business. /resources/eas/jamcatch-1.jpeg.thumb.png This prototype was tested in an actual retail store. /resources/eas/jamcatch-prototype-analog.jpeg.thumb.png I'm not kidding when I say that I wired it all on perfboards. It's not pretty, but can you do better?

Jamcatch 3000, prototype 2

For the second version of the prototype, I got tired of perfboards, so I ordered an actual copy of Eagle. One of the very few times where I willingly bought software, but it's worth it and it works perfectly on Linux. (Unwillingly, I buy software such as Microsoft Windows when I buy a laptop or a pre-assembled PC.) I still had to solder the whole circuitry, so I used through-hole parts as for the first prototype, routed the different subcircuits on double-sided PCBs and had them made by Olimex in Bulgaria.

Differences with the first version include:

/resources/eas/jamcatch-overall.jpeg.thumb.png Overall view of the second prototype, with the cover removed. This time I ordered PCBs so soldering was quick and easy. /resources/eas/jamcatch-front.jpeg.thumb.png The backlit front pannel, displaying the date, the time, and the count of detection events. /resources/eas/jamcatch-prototype-2-analog.jpeg.thumb.png An unsoldered PCB for the analog front-end board. I took the liberty of writing an Eagle script to remove all the component values before having them etched in Bulgaria. Oh, and PCBs have bugs too!