PERISCOPE Perimeter Security

A perimeter security system employing multiple sensors to detect area intrusions and AWS for alarm notification, logging and visualization.

Similar projects worth following
Change the Planet with PSoC® IoT Design

PERISCOPE is a perimeter security system employing one or more solar powered OUTPOST units, each having a PSoC 62 MCU managing motion, vibration, and radio sniffing sensors to detect intrusions into sensitive areas. Each OUTPOST reports intrusion events (alarms) to a single BASE gateway using long range nRF24L01+ 2.4GHz ISM band transceivers.

BASE uses a PSoC 62 MCU to drive a small display and audible annunciator for stand-alone real time alarm notification. BASE also acts as a gateway to forward alarm events using a WiFi connection to Amazon Web Services (AWS) for logging and historical review, and for pushing notifications to designated endpoints such as smartphones and tablets. AWS QuickSight dashboards provide visualization and reporting of logged alarm events.

OUTPOST is powered by a rechargeable lithium polymer (LiPo) battery sized to last several days on a full charge. A small solar panel and charge controller provide energy for continuous recharging during available sunlight.

Motion Sensor
Each OUTPOST has a low-power PIR (passive infrared) sensor to detect intrusions within a zone area. PIR sensors work by monitoring changes in temperature from the surroundings to detect movement. The PIR sensors have a wide angle of view with a detection range up to 12 meters.

Radio Sniffing Sensor
Modern smartphones and peripherals include radio transceivers for WiFi and Bluetooth support. These signals are transmitted with less power than a mobile network signal and can normally be received only within a relatively short range. The MAC address assigned to these devices can be observed in wireless signals even if the device is not actively connected to a particular wireless network, or even if it is not actively transmitting data. 

When WiFi or Bluetooth is turned on in a typical smartphone or peripheral, the device will transmit periodic signals that include the MAC address. These signals can be picked up by nearby receivers ("sniffed") through discovery to recognize that the device is present. This has been used for commercial tracking applications, for example to let shopkeepers obtain statistics about how often particular customers visit and how long they spend in the shop. 

A similar technique is implemented in each OUTPOST to detect the presence of intruders that may have a smart device on their person. The range of detection can be controlled to some extent by factoring in received signal strength levels, such as RX power or RSSI, and to determine the proximity of the intrusion to the OUTPOST. These signals can be detected at greater ranges than the  PIR motion sensors, providing a layer of "early detection" capability to augment alerts from the motion sensors, helping to confirm human presence rather than wildlife or other potential false indications. Known "friendly" MAC addresses can be identified in advance and filtered to minimize false alarms.

More recently, some smart device manufacturers have added features to address privacy concerns raised as a result of commercial tracking practices, one technique being MAC address randomization. However, this should not limit OUTPOST's capability as we're interested only in the detection of any nearby MAC address, not a specific MAC address.

Vibration Sensor
Each OUTPOST includes an accelerometer for sensing movement and vibration. This can be useful for detecting movements of gates and fences that may not be in the field of view of the PIR motion sensor. It can also be used to detect and report possible tampering of the OUTPOST units themselves.

Each OUTPOST uses a long range nRF24L01+ 2.4GHz ISM band transceiver through an SMA antenna to communicate heartbeat, status and intrusion alarm events to BASE. Line-of-sight comm range is up to 1000 meters. Small radio packets are sent in short bursts periodically or on event basis only to reduce power requirements, maximizing battery life. OUTPOST can also receive settings data from BASE to configure channel assignments, detection ranges, MAC address filtering and scan parameters.


OUTPOST Primary Components
Panasonic EKMB1103112 PIR Sensor
NXP MMA8452QR1 3-Axis Accelerometer
nRF24L01+ 2.4GHz ISM band transceiver / SMA Antenna
18650 3.7V 2800mAH LiPo Battery
TI TP4056 LiPo Charge Controller
PowerFilm MP4.8-150 Solar Panel
Weatherproof Enclosure

BASE handles all communications with one or more OUTPOST units using an nRF24L01+ 2.4GHz ISM band transceiver through an SMA antenna. BASE uses a PSoC 62 MCU to drive a small display and audible annunciator for centralized stand-alone, real time alarm notification. It collects all intrusion alarm events and displays these to announce the type and location of the involved...

Read more »

Portable Network Graphics (PNG) - 473.83 kB - 08/24/2020 at 15:02


Portable Network Graphics (PNG) - 486.77 kB - 08/24/2020 at 15:02


Portable Network Graphics (PNG) - 145.92 kB - 06/01/2020 at 02:59


JPEG Image - 1.21 MB - 06/01/2020 at 02:59


JPEG Image - 989.34 kB - 06/01/2020 at 02:58


  • 2 × PSoC 62 MCU OUTPOST / BASE
  • 2 × Murata LBEE5KL1DX WiFi/BT OUTPOST / BASE
  • 1 × 2.4" TFT Display BASE
  • 1 × CapSense Touch Interface BASE
  • 1 × Audio Annunciator BASE

View all 14 components

  • Hardware Block Diagrams

    kschulz08/25/2020 at 01:03 0 comments

  • BASE Display

    kschulz08/25/2020 at 01:02 0 comments

    Started BASE with implementation of the TFT display. At this point the goal is to create a rudimentary display page showing the status of remote OUTPOSTs. The status is communicated via the nRF24L01 transceivers and includes PIR motion events and accelerometer data; WiFi sniffer results will be added later. 

    Apparently the SPI interface for the BASE nRF24L01 transceiver is not playing well with the Segger emWin library driving the display.  With the transceiver in place, the emWin dies at GUI_Init( ). I tried relocating the SPI pins thinking there might be a conflict with the display IO, but no joy. Will have to track this down.

    Here the BASE test page can be seen on the display. The LED is flashing red, indicating an error with the comm due to not having the nRF24L01  because of  the SPI conflict. Also shown is the KTTY virtual terminal I use for debug output.

  • PIR Motion Sensor

    kschulz08/17/2020 at 03:47 0 comments

    Added a PIR motion sensor. Here the PSoC 62 (OUTPOST) is sending data packets to BASE (Arduino-based display). For now, data includes a 32-bit timestamp and a 32-bit value identifying the sending OUTPOST. The LED flashes GREEN each time it sends a packet, RED if error. Received packet count is shown on the display.

  • nRF24l01+

    kschulz08/13/2020 at 18:14 0 comments

    A little late posting a log update; here are some notes from a couple of weeks ago.

    Getting started with the dev kit hasn't been difficult, just time consuming. I have a fair amount of hands-on with PSoC Creator and PSoC 4 devices, however with PSoC 6 / WiFi / BT devices we have a several development environments to choose from; PSoC Creator, WICED, and ModusToolbox. These must be understood to know the best dev path to take. I've gone through the WICED WiFi 101 tutorial series by Alan Hawse, which are excellent. I have yet to look at ModusToolbox, but having a better understanding of WICED Studio, I believe WICED can do what I need for this  project. I'll probably come back to  ModusToolbox when I have the time.

    The nRF24l01 radio transceiver is a fundamental part of my project so I decided to start with this first and build out from there. I started by implementing a couple SPI example projects to get a feel for interfacing with the PSoC 62 MCU. I was able to find an nRF24 library created by Carlos Diaz on GitHub in the form of a custom component compatible with PSoC Creator 4.x. Ran into a few problems getting the lib to work with the PSoC 62 MCU, particularly with interrupt handling and packet sizing, but I now have it working. I felt it would easiest to use the Arduino-compatible connectors of the Pioneer Kit to interface these components with the dev board. I typically wire prototypes together using 30ga. Kynar insulated wire.

    My understanding is that I'll need to use WICED Studio to implement the WiFi, as these aren't supported in PSoC Creator (yet?). It seems I'll eventually need to somehow migrate the nRF24l01 and PIR sensor code from PSoC Creator into the WICED Studio environment in order to tie everything together. Not exactly sure how that's going to happen but expect it will be a rather time-consuming process. Sure would be nice to have support for the WiFi / BT components already in PSoC Creator as I like it *much* better than Eclipse-based IDEs. Yeah, not a big fan of Eclipse.

    Multiple nRF24l01 transceivers will be communicating with each other in this project. It's a bit of a challenge to proto this with only one dev kit. I ended up adapting an ATMega328P-based display I had from another project and added an nRF24 transceiver to the SPI interface. For now this will act as a Periscope BASE unit until I finish enough of the OUTPOST implementation to free up the PSoC 62 dev kit for BASE development.

    Here the PSoC 62 is transmitting a 32-bit timestamp and alternating data value to the ATMega328P display unit at a 1/2 second rate. The LED is flashed GREEN each transmission, RED if error. The display unit counts received packets and toggles a comm whirlygig indicator. Debug output is being sent to USB serial port terminal emulators for both.

    Moving on now to implement the PIR motion sensor and WiFi / BT radio sniffer.

  • PSoC 6 WiFi-BT Pioneer Kit Received

    kschulz06/16/2020 at 23:19 0 comments

View all 5 project logs

Enjoy this project?



Dan Maloney wrote 05/29/2020 at 16:33 point

Hey, I really like the basic architecture here and this seems like it would be really great for a couple of use cases I have! I do have a couple of suggestions, FWIW.

1) Have you thought about adding a microphone to the sensor suite? Seems like sound could be valuable intel about an intruder.

2) I like the idea of integrating RF sniffing, but I wouldn't limit it to WiFi and Bluetooth. Intruders into wild areas often use FRS/GMRS radios in the UHF bands to coordinate activities. Monitoring those bands might be more fruitful.

3) Have you given any thought to including cameras with Edge AI? You probably won't have the bandwidth to transmit video back from each outpost, but if the outpost could take stills or short video clips when triggered, do a little AI to discern between, say, and elk and a human, or a deer and an ATV, and transmit a signal back to the base to tell whats going on in the field, that could be really valuable. The outpost could perhaps even cache the video on an SD card for later retrieval.

  Are you sure? yes | no

kschulz wrote 05/29/2020 at 17:43 point

Thanks Dan, great suggestions. I did look at adding a mic sensor and camera, but decided against them for now to keep down scope creep. But... a mic may still happen once I get into the dev and have the time. 

I love the idea of monitoring FRS/GMRS activity along with WiFi/BT and honestly that hadn't occurred to me. I'll definitely look into that further; maybe some minimal SDR could be helpful for that. I see  radio sniffing as the really unique feature for this project. Thanks again for the suggestions!

  Are you sure? yes | no

Dan Maloney wrote 05/29/2020 at 19:52 point

I agree, the RF sniffing really pulls the sensor suite together. What would also be great is some intelligence on the back end to integrate the sensor data into a single "bad guy/good guy/false alarm" report. A deer rubbing on a tree to mark territory could always be safely ignored (unless you're sizing up hunting spots, of course) while a guy lurking with a rifle and a radio bears investigation.

I know, easier for me to add requirements than for you to implement them, lol. Still, I really like the idea, and wish you the best of luck with it. Keep us posted on progress.

  Are you sure? yes | no

srainsdon wrote 07/31/2020 at 03:19 point

@Dan Maloney Along those lines if two or more outposts can "hear" the rf signal you could do rough triangulation. 

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates