Loading...
 
Skip to main content

RF-DDE trigger

About my RF trigger links.

November 2010.

The BlueIris video motion detection works quite well but we can't expect it to cope with leaves shaking in the wind and shadows moving about. All my external cameras are prone to false triggering. Fortunately it is possible to use BlueIris DDE to trigger events (and more). People have used sensors attached to computer ports to trigger cameras but I'd like to us radio links.
I have a lot of experience with some of the RFM modules but the radio links sold by sparkfun are attractive because of their low cost.

Sparkfun modules.

SF sell transmitters, receivers and transceivers. The downside is the transceivers are FM while the other a ASK/OOK. In other words they aren't compatible with each other. If it was a simple choice I'd probably go for FM but unfortunately the transceivers are 5 volt units and I'd like to run some sensors off a 3V battery.
Therefore I'm using separate transmitters and receivers.

The transmitters work fine but the 2400baub receivers have problems. Some say the 4800baub receivers are better but others say they are crap as well.

My initial tests show the 2400baub receivers do have issues but they work well enough to let me write to software while I wait for the "better" ones.

The receivers detect noise in the absence of a real signal. Most likely they have an AGC (automatic gain control) which makes them overly sensitive in the absence of a real RF signal. I also have it near a computer and USB powered - some RF filtering may help.

Most people commenting on the SF site seem to be using standard serial data from a UART to drive the link - that would be very difficult to get working.

Manchester encoding.

I use manchester encoding. If you don't know what that is google it.
Basically you invert the data for either the first or second half of each bit.
This has two advantages at the expense of data rate. The signal always changes state for every bit so the AGC doesn't have to cope with periods of silence or full signal.

This encoding also allows the decoder to resynchronise once per bit so the clocks can be less accurate.
A sensor with a low battery on a cold night may have quite an error in clock frequency if the oscillator is R/C rather than crystal or resonator.

The encoding is done using a tiny85 with a mix of "C" and assembler - it could probably be done in pure "C".
I'm currently transmitting 1000 bits/second and this can be decoded on mega328 in "C" without having to add assembler routines.

The image above is a logic capture of my packet at the receiver data pin. The high level on the second trace means the packet decoded correctly and the CRC was correct.
With the 2400 baud receiver I get about one percent bad packets across the room and maybe 10% bad from a couple of rooms away. I could live with that if I have too.
The packet is 8 bytes long including the 2 byte CRC. One could use a much shorter packet but this is a standard format I use for other things.

My transmission starts at around 82mS on the scale. There is about 5mS of RF followed by a sync byte (hex80). The actual data - which is hex "00 00 7F 00 01 80 CRC1 CRC2" starts at about the 90mS mark.

http://en.wikipedia.org/wiki/Manchester_code

Wireless PIR.

The photo above is of my wireless PIR unit. It is based on my Tiny tiny85 PCB. On the left side is a sparkfun PIR module (zilog) and on the right is one of their ISM transmitters. The yellow wire is the antenna.

This unit basically works but there are some false positives. A rapid drop in sunlight intensity seems to trip it sometimes. There have been a few false triggers without sun and I'm not sure what is causing it - it may be power glitches.

With the sensitivity pin set to 0.6V false triggering is rare.

When I first installed the unit it was tripping every few seconds. This turned out to be a power issue - with the hub un-powered the USB supply I was stealing for the PIR was down to around 4V.

I plugged power into the hub but until this in on UPS a loss of mains power would cause repeated triggering.
To get around this I modified both the DDE gateway and the embedded AVR code. The former now limits how many trigger events are passed to blueiris. The tiny85 now checkes the supply voltage and only sends an alert packet if power is over 4.5V.

The system is far from perfect but reliably detecting people outside is difficult. In a sheltered space reliable detection should be fairly easy but out in the weather even ultrasound and micro-wave could have problems when rain passes in front of the detector.

Waterproof strain gauges on my steps would probably work fine as people detectors.

It would be nice to have a perfect detector but even if some people slip past they will be picked up by one of the internal sensors.

eddie


Created by eddie. Last Modification: Wednesday 29 of May, 2024 21:03:56 AEST by admin2.

Main Index

Switch Theme

Switch Theme

Shoutbox

eddie, 18:52 AEST, Wed 11 of Sep, 2024: Most pages should be working again.
System Administrator, 08:03 AEST, Sat 10 of Aug, 2024: Lots of images are still broken. I'm working on it. Maybe 1/2 way through.
admin2, 14:05 AEST, Mon 05 of Aug, 2024: running tiki 27
admin2, 16:01 AEST, Sun 09 of Jun, 2024: Wiki running tikiwiki version 27alpha on a raspberry pi-3. About 1/2 the images are missing and most thumbnails not working. Slow manual rebuild. About %20 done.
eddie, 20:23 AEST, Sun 19 of May, 2024: Images moved from wiki_up to file galleries and wiki pages fixed.

Last-Visited Pages

Online Users

20 online users