Tag Archives: ROBOGUARD

ROBOGUARD PROTOCOL

#133 Decoding an ASK Alarm Protocol

A few years ago I wanted to add multiple devices to my Roboguard HQ. Unfortunately I had to make my own custom solution because the original product can only allow up to 8 zones for sensors. I created a prototype using the classic Atmega328p but since then I’ve made 3 PCB designs all with different ICs: Attiny, STM8s and STM32 versions, all working with great success

Now I would like to talk a bit about the RF side of things and since I am a licensed ham radio operator as well. I think sharing a blog post will be quite interesting.

So first of all I needed to use an SDR with the correct antenna for the correct frequency in this case it was the tried and true good ol standard (ISM 433.92mhz). Since I’m located in a rural area the air waves are relatively uncongested so for me this is great.

Now I needed to record the signal I used a few tools mainly SDRSharp (because I like writing my own private plugins in C# ) Universal Radio Hacker and Audacity. Honorable mentions go to paint.net I used it for the picture editing

So firstly I observed my device for a few days, triggering it and pressing buttons etc. all while locked on to the frequency. Each time it did something I would record the time and make a high quality .wav recording of the signal.

Once I had learnt a few of the patterns and habits of the device i was able to use this in conjunction with the recorded wave files in audacity to start putting meaning to the patterns of bits and bytes.

Though to make my life a bit easier I calibrated Universal Radio Hacker for my RTL SDR and mad some recordings using some .complex16s files.

The nice thing about URH is that it tries to figure out the patterns for you but I find there’s always a bit of manual labour needed so clankers-0 meatsacks-1 in this regards

URH helped clean up the signal a bit but I still needed to make some fine tuning adjustments and re record the signals a few times with different crystal offsets.

Eventually I got decent results and was able to easily read the bitstream.

So the basic signal is 1x preamble then 8x repeating pattern containing the id and type of signal being sent.

looks like this:

Now everything is about timing. The preambles timing is very different to the payloads timing sure you can just grab the payload and call it a day but the preamble is critical in this day and age. It helps prevent false positives and also adds a bit of time so that the listener can “wake up” and grab the signal reliably so it has and important purpose.

So I used URH since it captures the timings in μs where Audacity can’t really show you accurate timings.

And I came up with the values like in the picture.

This is a nice and simple AM signal to reverse engineer and so far I have not seen anyone else do this for this specific signal so I think I’ll add it to the RTL_433 devices list.

Now once we understand the signal we need to send that signal and receive that signal.

I have done this in bare-metal C programming for the Attiny, STM8 and STM32 microcontrollers as well as added the decoding library to the RTL_433 project on Github.

The cool thing about this was that now I got to extend my bit banging knowledge using bit arrays and shifting bits around. Plus really simplicity is genius in this case. complexity just confuses an already confusing pattern of radio waves, the simple solution is always there as humans we are mostly just to dumb to see it and require time running our biological processors thinking about it until one night suddenly there’s a solution.

The main purpose was to make a cool system for myself at the time but now the secondary objective is to get more people interested in Radio and signals, SDR making plugins etc.

Reverse engineering this signal required multiple different skills and the ability to learn new things so it’s a wonderful educational and useful thing to do with a youngster.

In my opinion it opens the door to curiosity about further complex signals in a moderate way, the individual could then take up more demanding tasks like decoding FSK and other more complex signals like digital voice DMR as an example.

DIY ROBOREMOTE REMOTE

#129 Building a DIY Robo remote

My prototype using a LAN cable breakout enclosure made it small and nifty.

A few years ago while using many wireless systems on a large remote property I had the problem of testing the signals in varies areas before installing my hardware like: Roboguards or my own custom devices that have the ability to communicate with the RoboGuard ecosystem.

Front view of the PCB. It fits perfectly into an ABS enclosure.

So I decided to create a dedicated remote that uses the ASK protocol used with these devices. This makes my life so much easier because it allows me to test multiple requirements at once.

I’m able to test:

  • Signal strength in the area
  • 433 modules I want to use
  • Antennas I want to use
  • The transmission logic I want to use
  • Different ASK protocols

All this with a wireless, rechargeable and easily customizable package. At the moment this is not a commercial product however I have many other devices that work with the Roboguard ecosystem that have commercial applications.

Back view of the PCB. This was made around the ATtiny212 MCU and the SYN1115 transmitter.

ROBOGUARD INTEGRATION

#105 Custom integration sensors with custom receiver

V1.0 breadboard prototype with DIY EEPROM module
V1.0 stripboard soldered prototype with USB and Lipo battery
Testing 2x custom sensors (1x ATTINY85 and 1x ATTINY412) with 433 RF modules

Recently I wanted to integrate the RoboGuard system with some custom sensors on my farming property.

This motivated me to study the hardware and RF protocols used by the RoboGuard

I would like to also account for multiple RoboGuard transmitters scattered over the property each RoboGuard device has 2x pir sensors and sends an alarm signal once both are triggered.

They also send a heartbeat ping every 15min.

They have a range of roughly 400m from transmitter RoboGuard to receiver HQ.

Testing EEPROM data storage.

Now the RoboGuard system uses 433.92Mhz to send signals to the HQ however the HQ can only add up to 8 paired RoboGuards.

Once you reach this limit you will need to purchase more RoboGuard units.

For example if you had 12 RoboGuards, 2 HQ units would be required but if you wanted an HQ that can store more than 8 you would be out of luck.

luckily I had made my own custom RoboGuard receiver and was able to add my own DIY sensors to the RoboGuard device ecosystem

The protocol used is 433.92 ASK and each RoboGuard has 3 signals

  • alarm
  • tamper/learn
  • heartbeat ping
Testing penetration behind galvanised shed (using CY33 module)

Now my receiver needs to store the received device learn UID and this is done via EEPROM on my board

Now my custom device receives all signals just like the RoboGuard HQ.

Next is communicating with the TAK Server.

I could swap the 328P for an ESP8266 which allows WiFi connectivity to the internet

This then allows the device to connect wirelessly.

It still receives RF data from the RoboGuards and just ports these signals over the internet

In future I will make a device with an integrated WiFi connection but In this case all I wanted was more zones and an affordable extra device to keep in my laboratory permanently with the capability to receive 433mhz signals walking around the premises. If need be

Overall my unit contains

A speaker
6 push buttons
2000mAH Lipo battery
built in charger
ability to add clients 12 RoboGuards (more depending on EEPROM size)
433 MHz superheterodyne receiver only
logic to handle all these features

Front of the 433 Transmitter
Back of the 433 Transmitter

More info + datasheets and schematics etc. on my GitHub here