I call it DEWS: driveway early warning system [a devlog]

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.


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:
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++)
      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.

How is the sensor typically installed? Are you going to go cut grooves in concrete or what?

Well my driveway is sand and gravel, so no issue for me. For what it’s worth the buried magnetometer would mean just cutting a small channel in the concrete/asphalt, unlike the coil designs which (at least the commercial ones) are often ~6ft wide.

I’ll get a picture of the sensor enclosure tonight. It’s small enough that it’s also possible to dig a trench underneath with something like this:
and then shove the sensor underneath with a stick

I tested this from the side of the car too, and could get about 4 feet away before detection became unreliable. If I could figure out something to make it a bit more sensitive, it’s possible it could detect cars passing beside it instead of over it, at least if the road/gate is narrow enough.

Starting on receiver designs

Alright, didn’t get any further testing done yesterday, spent the time playing with the receiver on Kicad instead. This will be a fairly simple, mostly THT (through hole) board. Also I think I’ll try to etch this one myself, as I can get it done this weekend.

Fight the feature creep!

As I was dropping parts into the schematic, this thing started evolving into something of a home control panel. Which is cool, but one lesson I’ve been learning the hard way recently is that it’s a lot easier to wire a bunch of boards and parts together, and rather another to write good code that makes it all work together. More than that even, some larger projects might be very doable, but for me I just know it will take unendingly long to get it all written and debugged. So in the interest of something that will be useful sooner rather than later, I’ve had to scale it back. Still, if I think ahead a bit in my design, I should be able to re-use a bunch of code developed for this version in a future, more featured-filled version. I already have several transmit/receive functions from the other projects that can be dropped into this one with minimal fuss.

So here’s what I’ve got so far


So for keeping it simple, I’ve got an Arduino pro mini running at 8mhz/3.3v, so I don’t need any level shifting with the radio. There’s three status leds, some control buttons, and your basic regulator with a barrel jack. I might swap that for a USB connector, I’ll just be using an old wall-wart or phone charger to power it.

Arduino libraries for making tones with a beeper have some annoying things going on with timing and how it blocks other things from running, so I’m just going to avoid that altogether. There’s a 12v buzzer that just needs DC power to make a tone, low side switched with an NPN transistor.

Primarily this thing’s job is to receive the driveway sensor and sound an alarm, but the buttons make it easy enough to add some control for my previously mentioned gate and light projects.

The radio is SPI with an IRQ pin attached to Interrupt 0. I’ve used both interrups and polling loops with this radio. Both are fine, interrupts are nice for battery projects where the ATMEGA can be put to sleep and not be woken until the radio recieves a packet. If your MCU has a lot going on packets can get dropped if not polled frequenly enough, but for a simpler wall-powered project like this it should be fine.

Oh, one thing I just realized I forgot. I’ve started putting pin-headers attached to all un-used pins for an MCU project like this. It makes it possible to have an idea later about a certain board, and be able to either dead-bug in another part (say, another button or external indicator) or even another circuit on a board. Doesn’t happen with every project, but expose your unused pins, it’s helpful for later.

Workflow and some thoughs about symbols

Couple things I should mention about Kicad. First, it’s important to remember (especially people coming from an EagleCAD background) that schematic symbols and PCB footprints are two very seperate things. Symbols are what you see in an electrical schematic, footprints are then manually assigned to symbols, and they are the physical dimensions and layout of a part as it would appear on a circuit board.

This is also to say that the schematic capture portion of Kicad, when components are dropped into it, does not know or care what the physical layout or dimension of your part is. It knows there are 3 LEDs in this schematic, not if they’re SMD 0805 LEDs, or a big 8mm through hole LED, or really if it’s truly a package with only 2 pins attached.

Once your schematic is done, there is a window for ‘Assign PCB footprints to schematic symbols’


And here is where you tell Kicad what footprint all these parts get. I’m using an edge-launch SMA connector for the antenna, and there’s even a little preview window you can open to see the part. You can take measurements on that screen too, which is very helpful in making sure you’ve got the right one. Mixing 2mm and 2.54mm pin-header spacings for connectors sucks, ask me how I know.

You can almost think of Eeschema and PCBnew as two seperate programs, connected by a file known as a netlist. The netlist is a textfile that lists every component, it’s assigned footprint, and each pin’s connection to everything else. PCBnew then reads that file, and knows before you layout any traces and LED1 attaches to Resistor R4, and so on.

Labels and wires

The green lines are connections, as you’d expect. The yellow text by some pins are called labels, and they also connect pins. Electrically, anything labeled ‘gateopen’ is connected to any other pin with the same label attached. Power symbols are their own thing, but work the same. Anything with an up-arrow labeled ‘+3.3v’ is connected to everything else with that same label.


I’m a bit torn on how and when I use labels like this. As you can see in this design it’s more labels than wires running from pin to pin. As designs get more complicated this does make things cleaner than a page of crisscrossing wires. On the other hand, trying to find how many labels there are and where they connect to on a large schematic becomes an annoying wordsearch game, instead of ‘put finger on wire, trace from A to B’.

Custom symbols, the conventional way, and my way

There are two custom symbols in this project. The U2 ‘ArduinoProMini_a’ and U3 ‘Sx1278_LORA_EE’. There’s a general convention that IC parts and modules get their pins sorted by type (input on left, output on right, power on top, etc.) or at least by register in the case of MCUs. The way I do it here, is the physical arrangement of pins on an Arduino Mini. This isn’t proper, but as the board designer I find it very helpful. On another MCU, perhaps you hookup LED 1, 2, and 3 to port pins PB6, PB7, and PC0. These LED labels might now be laid out together in your schematic, but that’s not the footprint. Now you’ve got traces and vias going everywhich way on a board to connect those LED’s to output pins.

Unlike the way I’ve laid out these footprints, where both in the schematic and on the board, the three LEDs will be laid out in the same line on the PCB. Three parallel traces from each LED to pins 5, 6, and 7. Neat and tidy.

Footprints assigned, netlist generated

So that’s my current thoughts on basic schematic layout. I’ve got my footprints selected and the netlist generated, so I can start on the fun part next: the PCB design.

I’ve got a bit of a more ridgid workflow for that aspect, and I’ll try to produce a good rightup of it. It helps to get a sensible layout of traces, and avoid mistakes. Even when I’m having board made and not home-etched, layers and layers of crisscrossing vias are not only ugly to look at, it’s ugly to debug. So that’s what I’ll work on for next time, along with an enclosure for the underground sensor.

Still working on the PCB layout and a good writeup, but I got the sensor enclosure done.
IMG_20201012_125130 IMG_20201012_125221
2 PVC caps and a barbed hose fitting. When I’m happy everything is working right the PVC will get glued together, and the direct-bury telephone wire covered in silicone and pulled through the 3/8" hose barb. Can’t think of a simpler way to make a waterproof cable gland than that!

Put at least some sort of vent/drain hole in - otherwise you may overpressure in the summer sun!

Hmm, good thought, but buried underground that might be tough to keep waterproof. I might get away with the small drain hole if I throw some pea gravel in the driveway trench so it drains well.

Or just make sure you design for the overpressure. Properly sealed PVC with a properly sealed fitting should handle a few PSI plus or minus. Don’t just toss it in assuming the inside will remain at 0 gauge PSI, though.

I’ve got the PCB to a point that I’m happy with it. Now I want to go back and get some better screenshots for my writeup. I should have that finished up over the weekend.


I did get the sensor strung out and some more testing done. It’s running on AAs, blink the LED as I drive by. Driving by with the tractor it detects it within about 3 feet away. With the much smaller ATV it needs to be within about 1 foot for reliable detection.

Not quite as sensitive as I’d hoped, but buried in the middle of the driveway it should still give reliable detection to most vehicles. Cars and tractors, not problem. We’ll see with the ATV. The gate opening is about 16 feet wide, but it’s not like I’m aiming to just scrape by the post when I’m driving in.

Most interesting will be to see what happens the first time a UPS truck comes by, since they’re mostly aluminum.

I’ll turn down the trigger threshold some more and see if that helps, though I suspect I’m pretty close to the range where sensor jitter might start causing random triggers.

Now that the netlist is generated, it’s time to read it into PCBnew and start making our actual board layout.

Something I should have mentioned last time


Kicad is a very keyboard based program. There are icons for nearly every function (and there didn’t used to be), but Kicad is a lot faster if you’ll learn the hotkeys. ctrl-f1 brings up the list of hotkeys, should you need it. Placing symbols, placing/dragging/deleting wires and traces, it all goes much faster with one hand on the keyboard and the cursor never leaves the board. It’s really worth it.

What not to worry about

Something I’d like to mention about the criticality of board layout: it’s probably less of a big deal than you think. At least for a hobbiest like me, my circuits arn’t high frequency RF, digital signals of such high number or speed that crosstalk is an issue, oscillators so sensitive they desense when you get a hand too close, etc. I always do my best to follow best practice, and so far, that seems to be good enough. I’ve had a lot of projects that have been failures, I’ve yet to have one that could be traced to the actual layout of the board itself.

The best thing to keep in mind about that is this: A horrible PCB is still better than any breadboard. The inter-element capacitance of those strips of metal in a breadboard, the crossed jumble of jumpers and wires running over the surface. Just putting parts closer together with short traces and a ground plane cleans up most noise problems right there.

How I start my layouts

After the netlist is read, I start my layout by organizing parts in two ways. First, I start making clusters of parts that go together in the same area. Regulators and their filter caps, opamps and their surrounding components, etc.

As read by netlist:

Next I start moving those clusters around according to whatever kind of function or form factor I want on the board. Typically a display front and center. Buttons underneath, likely antennas up top and power connectors down below. Then I move some of those components around each other in such cases where the layout has certain spacing requirements.

Sorting into groups:


MCU’s are usually somewhat centered, equidistant from everything it’s supposed to connect to.

Radios and RF parts are usually close as possible to each other or their antenna jacks. Microstripline and other tricks for controlling impededance arn’t usually done with 2 layer boards, usually 4 layer and sometimes with more exotic substrates than the standard FR4 that most PCBs are made with. Thus far, I’ve gotten away with keeping RF traces wide, short, and keep a ground plane underneath it with no other signals around. Then via-stitch all around it and hope it’s good enough (has been so far!).

Oh, and don’t forget mounting holes! I’ve done that a lot. Best way to add those is actually to add them in your schematic design, and assign the proper size footprint there. I’m usually going with M3 standoffs and spacers for mounting boards.

I’m sure you’ve heard the phrase: “Premature optimization is the root of all evil.”?

Well for PCB design I’d like to submit “Premature miniaturization is the root of all evil.” I like making my boards compact and I like working with SMD. Not to a crazy degree of course. I’m not trying to make a smartwatch to compete with apple. It’s easy though to lose track of the scale of things on a computer screen. The 3d viewer in Kicad helps a bit, but I’d caution designers from getting things too close together, and giving yourself a real headache later when it comes time for rework on debugging. Like I said earlier, component spacing and layout is not as critical as some think, so give yourself a little room on the boards.

This is why a lot of my analog designs are THT boards, even if I’d like a final version in a compact, portable surface mount version. It makes it so easy to clip a test probe to a lead, add another parallel cap or resistor to alter function, or even dead-bug in extra circuits if that’s what it takes to test ideas or troubleshoot problems.

Another side note: I actually find SMD saves space in ways other than part size. By those pesky laws of physics, the physical size of a 100uF 16V Aluminum Electrolytic capacitor is no different whether it’s SMD or THT. Just by choosing the SMD parts, you just opened up all that space underneath it for traces! I find that often brings in more space-savings than trying to use smaller component sizes for much, much less effort.

How I handle boards with parts on both sides

It is possible to place SMD parts on both sides of a board. However I have no interest in messing with the heat-activated adhesive that’s supposed to keep parts on the bottom of the board in place, and the other complications with trying to bake boards in an oven with parts on the bottom.

So the simple answer to this problem is don’t, whenever possible. When it isn’t, I put the bulk of SMD parts on one side, reflow that on my hot plate, and do my layout of the othersize keeping in mind that I will hand solder those.

Kinda like this:


And the front, with THT and just 3 SMD indicator LEDs on the front:


[BTW this board has been made, and the first one is soldered! Then I got very overwhelmed with trying to keep track of how to make several systems run together properly in the code, and debug the circuit at the same time. It’s been on the shelf a while. Perhaps I should make that a future devlog and get some help with the programming…]

So anyway, now it’s a repetative affair of moving parts, laying traces, deleting whole chunks and starting over again.

Does anybody here like sudoku?

Well I don’t. I’ve never been one for puzzles, my brain switches off if it thinks there’s no point or payout to it. Yet, I imagine the same satisfaction someone gets from finishing a Sudoku puzzle is the same one I get about this point. After some fits and starts and reworks, traces start to click into place. Suddenly the traces just kinda find paths for themselves, and you finish up with a design that feels clean and compact.

So, here’s my finished driveway sensor alarm, with a few buttons for turning on lights and opening the gate:


Final checklist

This is the personal checklist I’ve been building as I learn the finer points of PCB design. It changes often, usually after I make a dumb mistake and want to make sure I don’t do it again. Not everything applies to every board of course, but it’s helped me avoid a few regrets when the purchased boards show up.

  • EMI and signal integrity
    • Check analog and digital signals cross at right angles
    • If applicable, separate digital and analog ground planes: join only at one point
    • Check decoupling caps are close to chip Vcc pins
    • Via stitch around ground points, such as RF connectors
    • Discrete pullup/down resistors added as needed
    • Keepout areas for traces and planes around RF connectors, oscillators, crystals, etc.
  • Make sure THT pins connected to copper pours set to ‘thermal relief’
  • Add needed test points (untented vias make pretty good defacto test points, BTW)
  • Add needed hardware pullup/pulldown resistors
  • Add keepout areas under trimmer pots/caps, crystals, ICSP, and other sensative areas.
  • Check ICSP headers for spacing smd/tht, keepout, etc.
  • Clearance and space for large components, connectors, heatsinks, etc.
  • Check clearance and keepouts for separating AC and high voltage traces.
  • All polarized components point same way
  • Add mounting holes, check electrical isolation
  • Check solder mask and vias on high temp/heatsinked areas [however much heat sinking you think you need, isn’t enough…]
  • Ground planes not near any pcb mount antennas or capacitive sensors
  • RF traces have proper grounding, with even gnd plane widths on either side
  • Mating connectors and pinheaders checked for proper orientation.
  • Added outside rfi, power surge, and reverse polarity protection
  • Final DRC
  • Add or remove soldermask for test lines and heatsinking
  • Check silkscreen, both sides, add logos, revision numbers, model numbers, etc.
  • Modules and ICs have pin1 designator
  • Set via’s tented/untented

Ready for printing!

This is kind of a rough ‘just get it done’ kinda project at this point, so instead of sending it off and waiting two weeks I’m just going to etch this one myself. It’s certainly not a solution I’d recommend for everyone, but it’s darn handy when I want a prototype or test board the same day.

I’ll have this etched and drilled in a couple days, then I’ll be back with talk of soldering and programming.

Auuugh!! It took me over an hour to figure out why everything seemed to work, except the radio which would hang in strange ways whenever I tried to send a packet.

Turns out I missed soldering in a jumper that tied two ground planes together, so the output filter cap on the regulator was ungrounded and doing nothing. Everything else worked just fine, except the lora module would hang forever when a packet was sent.

Clearly that capacitor is important. I added an extra 0.01uF cap right next to the radio as well.


So I’m now convinced my circuit works as designed and as soldered. Two boards are made. I’ll have some things to say about that process in a day or so; in the meantime I’ll get some actual code done.


You can’t tease printing your own boards and then not show the results! Flip it over!

1 Like

Tch, well, it wasn’t the nicest looking board I’ve done. The toner transfer just didn’t stick as clean as usual. I did let the page sit on my desk for a few days before I got around to making the board; maybe letting it sit too long causes a problem. Or I didn’t get my temperature quite right, or the etchant is getting old, or I left in in too long. Well anyway:

Toner transfer onto copper


Etching in Cupric Chloride. The air pump keeps things stirred and evens the etch a bit.

Cupric Chloride: Hydrochloric acid + hydrogen peroxide + the copper itself. Do not ingest.


Ok then, clean off the toner with acetone and drill with my super helpful ‘sensitive drill chuck’.

Photo of some older (and better looking) boards with the drill chuck


Bottom of the receiver boards. One assembled, one still needs the Lora module installed

Not a pretty looking ground plane, and a couple broken traces that needed repair. Still, it will be functional, and it’s still faster (or at least less frustrating) for me to assemble and debug than trying to keep track of a jumble of jumpers on perf/stripboard or just straight up dead-bugging it.

Just for fun here’s some other examples of boards I’ve etched. Now that I look back on them I seem to get some inconsistant results on the ground plane. Sometimes certain toner brands or printers dispense less toner over wide areas to save a bit of material, but I’m not sure why that would yield such varied results.


Some of these worked, a few didn’t. Some are installed and doing their task nicely, some were just for the purpose of testing a circuit or component. The very lower left for example is a test board for a nifty 0.1 watt 500mhz solid-state RF switch. This board made it easy to test the switching and see how much signal isolation it provided.

Post solder testing

For homemade boards, or pro-made boards but with a new circuit design, I always do some careful probing around with the continuity checker before first power up. First thing is just to check continuity between power input and ground. Several times I’ve had a solder-blob or backwards component or something shorting to ground. Might have been bad if I’d powered that up without checking.

Then I check smaller components for shorts. The lora modules, TQFP chips and so on, sometimes pins might get bridged together by accident. Once I had an SPI device’s MISO pin shorted to ground. Took some probing with the oscilloscope to discover the MCU was talking to the sensor, but sensor couldn’t talk back, being pulled to ground.

A couple times I just didn’t check the footprint well enough in Kicad, and ended up with a transistor who’s collector, base and emitter were not in the order I thought they were once soldered.

It doesn’t catch all the problems but it’s caught a few.

Well with all that done and a simple test program uploaded, it seems the circuit is running fine. For stuff like this I usually write a basic test program first that just confirms everything was assembled correctly on each board. Blink LEDs, send a packet, beep on button presses.

That’s all working good. Next I’ll start on the code and be able to test some transmit/receive functions between the two boards, and after that make some updates to the gate-controller for the added magnetic sensor (mostly just a polling loop for checking the output of the separate ATTINY85 that reads the magnetometer).

Getting really close to installation and final field testing.


Wait, you actually have a computer hardware and software that won’t reject these bitbanged low-speed devices in 2020? Amazing!

The last computer I had that would work with the attiny85 “usb” bootloader was a six year old chromebook and the only flashing software that ever worked was the long since defunct cloud IDE (i think it was the original iteration of codebender.cc?) that used a chrome extension to speak the necessary fake USB HID device hack of a protocol to flash it.

Every system and modern OS I’ve tried since rejects the device usually at enumeration time or if it manages to enumerate as intended, shortly into flashing or always during flash verification, likely due to bitbanged 1.5mbps usb timing issues vs modern usb hardware leading to corrupted data left and right. Supposed tricks like inserting usb1.1 or usb2 hubs and such in the middle never worked for me.

I wasted waay too much time trying to make that work again. I finally gave up and just wire the attiny85 board’s pins up to an in system programmer sketch running on just about any larger than an attiny microcontroller (preferred: atmega32u4 or the more modern atsamd arm m0 or m4 ones).

Well whatever Adafruit is using works alright. Their bootloader and trinket boards installed with the Arduino IDE works fine, just have to hit upload within 10 seconds of board power up/reset. Although I am running Linux and I had to follow their directions for updating the udev rules, so it’s possible Linux’s usb drivers are playing nicer with things than Windows does (that might be a first…).

Adafruit also has directions to reupload said bootloader via an Arduino Uno board in case the original one gets bricked. I don’t see why the same bootloader couldn’t be installed on any attiny85.

I have a usbtinyISP board now and have used it with a few ATMEGA328 designs, but for quick tests or experiments it’s really nice to be able to just plug in a USB cable and go.

Agreed. I’m primarily Linux (with a Mac as an alternate) as well. Adafruit’s new “qtpy” is the modern trinket replacement (usb-c connector, and dirt cheap!) but I do enjoy the old 8-bit things. The 328 based boards like the pro trinket 5V (16mhz) continue to work for me; I think it’s just the attiny85 and its crystal-less idea of 8mhz having timing issues banging out USB on my end.

Lucky that yours works, it makes life easy! :slight_smile:

Ok, code is mostly complete. Needs a bit of cleaning up but testing between the two receiver boards is working well. I found a couple little things that needed fixing. I forgot to set the Lora module back to RX mode, so the board would receive and alarm on incoming transmissions, then stop listening after transmitting a button press.

12v beeper is pretty loud. Should be very audible from a few rooms away.


Also made a few tweaks for the human factors aspect. I had separate buttons for gate open and gate close, and one ‘toggle’ button for the outdoor lights. I can see the gate from the window I plan on putting this next to, but not the lights. Since the light-toggle button changed which on/off state it sent on it’s end, this resulted in a sort of ‘miswired 3-way switch’ situation where pressing ‘lights’ on one board would send the light off command. Then pressing ‘lights’ on the second board would also send the off command. Now I’ve told the lights to go off twice when I wanted them on, and I’m unable to see that until I go outside.

So that got changed to have dedicated buttons for lights on and off, and one toggle button for the gate. It’s blowing and raining here right now, but when that lets up a bit I’ll get the sensor installed at the gate and update the controller code to poll the driveway sensor and also accept a ‘toggle’ command on top of the usual on/off command.

In the meantime I got an idea I wanted to try for dressing up some project enclosures.

Step 1, design a template in inkscape and glue to some aluminum sheet.

It was easy to get the dimensions right, since I can export Kicad PCBs as .svg files, and overlay that in inkscape to know where all my holes go for standoffs, leds, and buttons go.

This was designed before I changed the gate to toggle and lights to on/off. Had to scrape it off and do it again.

I could have gone with panel-mount LEDs, but decided I’ll try a little bit of frosted acrylic for the window. Seen here is drilling over the paper template, and milling the window for LEDs.

The quickly hacked-together sheet metal fixture for the milling machine has proven much more useful than I though it would be.


Then I printed a mirror version of the graphic on the same paper I do my toner-transfer PCBs on and tried it on the aluminum. It’s… tricky. I think the temperature has to be better controlled than the copper-on-fr4 substrates that I make the PCBs on, but after a couple tries the best one turned out pretty good.


A couple bits got misaligned so I just cleaned that off. Laser toner isn’t very durable to this got sprayed over with a clear acrylic to protect it. Then I made 4 button extenders out of some 1/4" aluminum. I daresay it looks really really good,


Just gotta make the little frosted window next. Oh yeah, and actually install everything so it works and I can start on other cool projects.

Very nice work! I really like the cover plate!

… what’s “Dinner bell” for, again?

Since I made two of them, it’s just a pager button for one receiver to beep the other. There’s a ‘dinner bell’ of sorts between between the house and shop already, in the form of a cheap wireless doorbell. Now this will take over that job too.