Well it’s time for the next project in my homebuilt home-security system with the Lora SX1278 radios, as as there are several people on here with a interest in electronics, PCB design, etc. I figured I’d start a devlog of sorts here for a magnetic driveway alarm. Hopefully it will be an informative (or at least entertaining) look at my design process for the circuits, the PCB, and the code. Suggestions and comments for any part of which are always welcome.
Inspiration
I used to have a ‘mighty mule’ magnetic driveway alarm, and it worked great for years. I still wanted to build my own sensor that would interface with the rest of my homebuilt security and control devices, but now that day has come early because the Mighty Mule receiver has died, and I can’t figure out what’s wrong with it.
The Mighty Mule, like most residential and commercial in-ground vehicle detectors, is some version of a low-Q Coliptts oscillator, with it’s inductor being a wire loop buried in the ground. The low-Q, aka ‘quality factor’, of the oscillator means it’s somewhat unstable at holding a steady frequency, and while the oscillation should never collapse, it will vary plus or minus some degree when a metal object passes by and changes the oscillator’s inductance. That sine wave is usually converted to a squarewave and sent to some kind of pulse/freqency counter. If the frequency has changed, there must be a vehicle overhead the buried coil, so open the gate/sound the alarm/change the stoplight…
I have found a couple designs online for such a circuit, but then I got an idea for something that might be much simpler. Why not use one of the magnetometer sensors to take the place of the entire coil and oscillator? I think it’s pretty doable, though likely the trickiest part will be getting an I2C sensor running reliably over 10-20ft of cable.
Quick background
If your wondering what I’m talking about with the homebuilt security devices, well just ask. Also, check out this post about my gate controller design, which I’ll also be tapping into as the transmitter for this project, at least for early testing:
Access control, from the circuit board up
Another design of my point-to-point Lora radio network is this remote light-controller:
Controlling power outlets at long range
Some early tests
I’ve actually tried this project before, and got distracted after struggling to debug what turned out to be a knock-off of the Honeywell HMC5883 magnetometer. Turned out to be a QMC5883, which is so jittery as to be unusable, even with a circular buffer trying to average out the bad reads. What I’ll be using now is the GY-3110 magnetometer, though I think using one of the combo units would work just as well, like the MPU-9050.
Initial tests were just an Arduino and sensor on a breadboard, with a serial output to read the sensor data. With the sensor on the ground about 4ft away from the side of a car driving by causes a variation in readings of not less than about 30 microGauss. It varies a bit on it’s own but rarely more than +/-5uG.
So I’m satisfied the idea is a sound one, now to make something a bit more permanent to test with a buried sensor and long-wires.
Signal specs
I2C at the default slow speed of 100khz specifies no more than 400pf of capacitance on the signal leads for reliable operation. I’ve got some nice direct-bury telephone cable here, so I’m going to start with that. My capacitance meter says 12ft of the stuff is 120pf, so that should be well within spec. It’s not shielded, so the other part of testing will be to see if it picks up any outside noise and causes a problem.
Oh, and never use the builtin ~20k pullup resistors in the Arduino for reliable I2C. I’ve turned those off and soldered some 3.3k resistors in.
So here’s another test setup. This is an attiny85 in the form of the Adafruit ‘Trinket’ boards. It’s got a USB bootloader and is Arduino compatible, so a hack like me can still play with it.
I’d like to make this project into a complete standalone system eventually, but for longer-term testing I’m just going to add a polling loop to my gate-controller linked to earlier, and basically use it’s radio and power supply. So with this little perf-board, when a deviation greater than 15 is detected, the LED blinks, and Pin 4 goes high for several seconds.
Finally, some code
Here’s the initial code for the Trinket board:
trinket_mag3110.ino
This big block of averaging math might be completely unnecessary:
void getgauss(){ // averaging of 8 magnetometer readings may be unnecessary for the 3110 sensor. Was absolutly necessary for the earlier, very jittery, QMC5883 sensor.
xaverage = 0;
yaverage = 0;
zaverage = 0;
int tempxaverage = 0; // temporary storage for the maths
int tempyaverage = 0;
int tempzaverage = 0;
for (int i; i<=bufferLen; i++)
{
if(mag.dataReady())
{
mag.readMag(&x, &y, &z);
}
xbuffer[i] = x; // add new readings to buffer
ybuffer[i] = y;
zbuffer[i] = z;
delay(30); //lets try 8 reads every 1/2 second
}
for (int t; t<=bufferLen; t++) //average everything into a single number for x, y, z
{
xaverage = xbuffer[t] + xaverage;
yaverage = ybuffer[t] + yaverage;
zaverage = zbuffer[t] + zaverage;
}
tempxaverage = xaverage/bufferLen;
tempyaverage = yaverage/bufferLen;
tempzaverage = zaverage/bufferLen;
xaverage = abs(tempxaverage); //absolute value taken to measure difference from last reading, positive or negative is not important for our use
yaverage = abs(tempyaverage);
zaverage = abs(tempzaverage);
//just printing the numbers to watch for changes while testing with magnet near sensor
//Serial.print("Averages: "); Serial.print(xaverage); Serial.print(" "); Serial.print(yaverage); Serial.print(" "); Serial.println(zaverage);
}
But it was an attempt to average out the noise from the old sensor. The math works well so I just left it in.
further results pending…
Soon I should be able to run the sensor out and test with a car driving by. So far it seems fine reading the sensor with the cable piled up on my desk, and waving a welding magnet over it. No issue with noise on the lines.
I’ve started the schematic for the receiver circuit in Kicad as well. I should have updates to one or both of those things tomorrow. Until then, questions and ideas welcome.