Ok, maybe not stupid, but I did miss something pretty fundamental and I missed it early enough to waste a couple of days of development time. Also, there was a side quest through the quicksand that is Windows USB drivers.

As mentioned earlier, ESP-NOW is expected to fulfill a number of needs for my project. To recap, I have built a reliable target activating system applicable to several shooting sports I am involved in. It is reliable because it is electrically pretty simple, with some switches and relay providing the limited logic needed, a control box with said relays and switches and a battery and finally the connectors and cabling to hook it all up.

Removing those cables can be done with a wireless system that essentially doubles the built cost for the system. It would also be plenty reliable, but the cost is prohibitive, especially as I do intend to sell this system and I can’t make the price attractive and make a little money on it if I have to spend that much on the wireless technology.

The hardware for ESP-NOW is built in to microcontrollers that already support WiFi and are incredibly cheap. Furthermore, adding a microcontroller will let me replace a couple of other expensive parts while added even more features.

Of course, ya gotta get it working first.

I had easily set up two devices where one could messages to the other. I found an easy to follow YouTube tutorial for two way communication between two devices and chose that one to implement for the next step. The tutorial had a lot of symetry to it. Two ESP32 devices, each with an environmental sensor (temperature, humidity and pressure) and a tiny OLED display. The environmental data from each device was displayed on the other. The sketches are identical on both devices other than the manual entry of each devices peer MAC address, the device it is sending data to. While some of the ESP-NOW tutorials included facilities to scan for peers and automatically record their MAC addresses, this one assumes you know the MAC address for each of your devices and even includes a super simple sketch to extract the mac of the board it runs on. I ran this sketch and recorded these MAC addresses in a notepad text file for later reference. The sketch requires the MAC address to be stored in an array variable and in the declarations area of the sketch, this array variable was created in this form…

… where you would substitute the MAC address octets of the peer device for 0xFF in each position. If you leave it all FF’s, it will work by broadcasting the data to all devices on the network and the ESP-NOW devices will actually listen. However, the receiving devices do not acknowledge receipt of the message, where as unicasting to a specific MAC address does. There are situations where broadcast is appropriate, but for my purposes, I’d rather have the acknowledgement.

In my notepad, I created this string of hex notation digits so that I could just copy and paste the MAC into any script I was working on.

I modified the sketch, simplified it, removing all the code to support the display and environmental sensor because I didn’t have those to connect to it. My sketch sent two bytes to each other. Eventually, my messages between units will also be just two bytes, on as a unit identifier, the other as a command or status. I could probably make that two nybbles and just send a single byte.

The trouble is that my devices would only send one way. I had intended one to be the Activator and one to be the Control Box. Under normal circumstances, the Control Box will send a command to the Activator to instruct it to trip immediately. The Activator will either periodically send a status or it will respond to a poll for status from the Control Box. In my case, however, communication was also only one direction. The sending unit did not have an acknowledgement and the receiving unit never received any messages. I did a few minor troubleshooting steps to ensure that my sketches were indeed identical other than the peer MAC addresses.

The next step was to swap out equipment. I was using one ESP32 for the Control Box, assuming I would want to add more features to that one eventually and they have more I/O pins. The Activator was a very inexpensive ESP8266 board and there was always a chance one might have a bad transmitter. When I started swapping boards and sketches around, the laptop would occasionally not drop the virtual comm port when a board was unplugged. It would sometimes take a reboot to clear this issue. I had two instances of the Arduino IDE running. Juggling two IDEs and two of about four available cards when sometimes the USB subsystem would basically stop responding and require a reboot to fix quickly grew tedious as hell. I reached a stopping point on the first day and had to drop it at least overnight.

The next day, I decided that, since I was fighting some weird issues, I would work with some ESP32 boards instead of the 8266’s. The libraries for ESP-NOW and WiFi are different between the two MCUs. It was just a variable wanted to eliminate. The situation was largely unchanged, including the USB virtual comm port issues. I had a new sympton there. Now sometimes, I could get two of the same virtual comm port number. A bit of research revealed that sometimes, the USB to serial chips on these boards will have the same serial number, at least as far as Windows Device Manager can tell, so it give them the same comm port. I could manually edit one of them to an unused port number and make them work, but the more I unplugged boards, the more often the entire subsystem would lock up. Reboots would take several minutes, then time out with an error “DRIVER POWER STATE FAILURE” and it would then reboot itself from the reboot process. It happened several times and took 5-10 minutes EACH TIME to complete a reboot. That was the clue I finally latched onto and worked on replacing the driver for the USB to serial chip on these boards, the Silicon Labs C210X series.

That is an easy download, but of course by now, things weren’t going to go easy. Eventually, I discovered that there were three separate sets of Silicon Labs drivers installed on my laptop. I presume there was some subtle difference between some of the ESP boards I have plugged into this laptop and each installed it’s own ‘most recent’ drivers. I deleted them all and installed the fresh download from Silicon Labs, dated in 2023. This seemed to settle down the USB traumas.

Of course, they would still only communicate in one direction.

Now that I felt like I could trust the USB stuff, I added some code to print the device’s MAC address and peer MAC address during the setup() function. It never printed. I added other tag prints to show where in setup execution was. Those never printed. It was like it was skipping the setup() function. Google again.

Eventually, I found some references to the serial port/driver being slow to come up at boot timer or after an upload. One solution was to use a while loop to wait until the serial system was active. That didn’t help, either. Finally, one suggestion was to literally wait for 5 seconds before executing the Serial.begin() function and that finally worked! It was kludgy and needed only for sanity checking while developing, but it worked. The two MAC addresses printed out.

Since I copied and pasted the information into my notepad file, I have no idea how one of those MAC addresses was wrong and more importantly, how a C got changed to a D. They are adjacent keys, but good grief.

It can easily be argued that fixing the USB driver thing definitely needed to be done, but because of that distraction and the slow start on the USB serial port connected to it, troubleshooting a friggin’ TYPO took two days.

In my last post, I went over some mile high view details of ESP-NOW and my plan to replace the largely analog control scheme for my target activator system with some microcontroller boards running ESP32 and ESP8266 chips. That these systems can provide wireless communications for far less than the cheapest alternative that I had found thus far. However, in making that jump, there are many other advantages, some of which feed from one another, but all rooting in using the MCU boards to control the system.

The control box primarily becomes just more control-y, able to leverage MCU features in the activator and trigger devices. The control box will have user friendly lights to indicate whether the activator has been reset and the trigger is ready. With an arming feature, it will be able to ignore trigger inputs during stage reset. With wireless triggers, there is no need to choose an input polarity. Once a later version is configured with a display, more sophisticated features, such as sequencing multiple activators from one trigger or battery charge level from remote devices.

The activator benefits in several ways, where using an MCU introduces cascading improvements. Immediately, I realized that a big problem will be that the activator will now need an internal battery. Since the MCU can take over the timer relay’s one function, that relay can come out, leaving more room for the MCU and a battery. I don’t need a connector for the wire, but I will need a power switch and the external antenna.

I was watching a YouTube video about multitasking MCUs. One of my favorite videos on the subject involved adding more things that were happening at the same time, first a blinking LED, then an LED that fades in, then a button that lights and LED and finally a servo that sweeps, with all of these running simultaneously. BTW, all of that revolves around programming the various delays needed without using the built in delay() function because the MCU can do nothing else while that particular delay is running.

Wait a second, ‘servo’? Epiphany! I can replace the 12 volt lock motor with a suitably strong servo; I don’t need to protect the lock motor if there is no lock motor to protect. Oh, and any servo will be a LOT smaller than the lock motor, so now I have more room for the battery. Oh, and the lock motor was the only reason I was going to need a 12 volt battery, so now I can use a smaller battery, like a 7.4 volt RC car battery, which are made to be easy to swap out and charge.

Hardly mentioned thus far is that the trigger devices can be remote and wireless. There is a good argument for keeping the hardwired connector for certain triggers that don’t really need to be automated. On the other hand, a wireless trigger appliance that hardwired triggers can plug into makes all triggers look alike to the controller software.

The short version (I know, I’m not good at telling the short version of anything) of implementing ESP-NOW is that there are quite a few serviceable example sketches showing how to set it up and get it working between almost any number of devices. The examples tend to show unidirectional commuications, with one or more transmitting devices paired with one or more receiving devices. At minimum in my application, I need for the control box to receive from a trigger device and send to an activator device. The control box really needs to be able to communicate in either direction. Taken a bit farther, an activator needs to be able to send it’s status and a trigger might need to be able to receive a command, so from the ground, I need to deploy them as bidirectional.

At this point, however, I am pretty happy to have unidirectional communications that is responsive. In the little video below, the window on the left is the ESP32-S3-Box set up a the sender. I have a button push set up to trigger it sending it’s data, in this case the number ’25’. On the right is the D1 Mini Pro set up to print any data it receives as soon as it receives it.

This video is not particularly easy to see the details, but I think you can tell that there is only a tiny delay between when the S3-Box senses the button and when the D1 Mini displays the received data.

Interestingly, the button press needs work. No matter how debounced the button is, it somehow sends the data twice per button closure and once upon button release. None of the logic in place *should* do that, but it does. I suspect it will be because the example code scans for all slave devices and puts them in an array. The button press triggers a loop which counts through the list of slaves and sends the data to each. I am guessing that something in that loop is to blame for the multiple sends. I don’t want to completely eliminate the loop because a near future version needs to e able to sequence through several activtors. Plus, my button press might not be perfectly well executed. Maybe it isn’t as debounced as it should be.

My first implementation of the wireless setup will actually have the units hard coded to eliminate such issues until I am ready to tackle them. I don’t need to be fighting on multiple fronts.

The activator software really doesn’t need to do much for a successful version 1.0. Receive the activate command, operate the servo as required to release the physical device, then sense whether the physical device has been reset or not.

Once I had really decided to go with the MCU route, the primary trigger device that I have been thinking about is a ESP-NOW equipped photobeam sensor. Like the activator, version 1.0 of the trigger doesn’t need to do just a gob of stuff, just send a signal to the controller when triggered. Everything after that is gravy.

There is one potential problem. The photobeam I *have* requires 12 volts and all the alternatives that work in the same basic way, with the emitter and detector in one device that points to a retroreflector on the other side of the detection area, also all start at 12 volts. This means that the trigger device will either have to have a different battery than the control box and activator, or I need to get 12 volts from somewhere.

There are boost voltage converters that use switching power supply technology to boost voltage. Of course, there is no free lunch, so a boost converter draws the same amount of power it converts. To supply 12V at 1A would take 1.6A from a 7.4V battery, plus a little to account for efficiency loss. Happily, the photobeam draws 40mA or less and, at this point, I’m not sure how much the D1 Mini Pro pulls, but I’d bet I can probably use one and a 7.4V battery and be just fine. I guess we will find out.

Longer term the the data protocol I develop should include the activator and trigger devices sending a periodical status packet. This will be used as a general keep alive communication, but the structure of status message will include a device ID that the user assigns, a bit or two to identify that type of device it is and other status information, like battery condition and whether the activator needs to be reset. I have 250 bytes to play with, but one or two bytes should suffice.

Ok, *they* call it ESP-Now… or ESPNOW… or maybe it’s ESP-now…

Point is….

Espressif makes some chips now and then. Maybe a bunch of them. Chances are pretty good that if you have something in your house that does WiFi, especially if it is an IoT thing, it likely has an Espressif chip at the heart of it.

My gateway into ESP was the ESPHome platform in Home Assistant. I have a couple of ESP8266 based boards gathering and reporting information back to my Home Assistant. One is a pretty simple temperature sensor that reports the outside temperature, or at least the temperature *just* outside of the garage door. The other has two active inputs, a temperature sensor that tells the approximate ambient temperature around my water system, which consists of a a bunch of overcomplicated plumbing in my garage, and the water flow rate and total consumption for the house, based on what a flow sensor equipped water meter is willing to share. This unit also has two inputs that I have not yet connected that are detailed in the other blog post.

To the point, I am at least somewhat familiar with the ESP8266 based Wemos D1 Mini board. This is a 1 x 1.5 inch board with the surprisingly powerful ESP8266 microcontroller on board. ESPHome hides a lot of the ugly details from you, but the ESP8266 is a general purpose microcontroller with built in WiFi support and a handful of general purpose IO pins. It is essentially a single core version of the ESP32 with a little less I/O and a (only) 80MHz clock.

Remember ESP-NOW? This is a post about ESP-NOW….

ESP-NOW is, to paraphrase the documentation somewhat, a hijack of the typical WiFi TCP/IP stack. ESP-NOW uses the hardware of the MCU’s WiFi facilities, but at a not the whole stack. It lives and communicates at layer 2 of the OSI model. It is a peer to peer protocol, with no need of a WiFi router, DHCP or any of that sort of thing.

This protocol leverages the ‘action frames’ element of the 802.11 standard. This subprotocol is generic, but often networking gear of any given brand uses this protocol to communicate between themselves. For example, action frames are how access points in the same SSID pass your roaming device between different access points, with vendor specific data passed as action frames.

This protocol comes with some limitations, such as a limit of 250 bytes per packet. For most such purposes, 250 bytes is way more than needed most of the time. I need to pass only one or two bytes as my payload.

If you want to skip a bunch of background and exposition, you can scroll down to the big Espressif logo.

I was killing the usual time on YouTube when, based I’m certain on browsing habits that include ESP8266 stuff, they presented a couple of ESP-NOW basic configuration guides. My application has been begging for a wireless connectivity method and here it is, dropped in my lap and almost perfect for my needs.

Without getting too detailed, I am building a system which needs a controller that can see an initiating action and trigger the activation of some hardware. Specifically, I am a competitive pistol shooter. The main sport I am involved with includes scenarios wherein you may have to address targets that are moving or may have non-threat targets moving in front of them. Historically, these moving targets have been triggered by simple mechanical means, such as stepping on something that will trigger a spring loaded device to yank a cord/cable in order to activate the moving target. At this point, I have a working and reliable system that operates electrically. It has been used at several matches for a little over 300 activations, with no mechanical or electrical failures. So long as it is reset between stages, it just works.

I have build a version 2.0 of the same device, with almost identical mechanics, but with a four conductor connectors and cabling for reasons detailed below.

This unit has only been to one match, but except for the occasional failure of the humans to reset it, it performed perfectly.

The issue is, of course, everyone wants just a little more out of it, including me. I mentioned “So long as it is reset between stages…” and that is a fairly common issue. Failure of stage equipment to activate results in a mandatory reshoot for that competitor, which costs everybody time.

For example, a given competitor decides to be the one who resets the device. When that competitor is coming up in the rotation, generally for at least two competitors before him, he is not actively resetting the stage. If nobody notices at first, the activator doesn’t get reset.

When the next competitor goes, whatever is supposed to trigger the activator doesn’t seem to do anything, so that competitor is commanded to stop and reload to make a new attempt. Once this kind of thing is happening, it tends to snowball into two or three competitors in a row having some kind of problem and the root cause is that people didn’t notice that the activator was not reset.

Another, though lesser, issue is when resetting the stage and someone *has* reset the activator, but someone accidentally walks through the triggering area and prematurely sets off the moving target.

Let’s list our grievances…

1. Nobody notices that the activator has not been reset.
2. It is clumsy or impossible to guard certain kinds of triggers from activating while the stage is being scored and reset.
3. I haven’t mentioned yet that everyone wants this to be wireless, too
4. Ultimately, it would be great if the activator could reset itself.

I added the extra wiring to the activator with the intent to have a switch inside the unit that is closed whenever the unit has been tripped and thus turn on a big red light at the controller whenever it needs to be reset. While I haven’t actually figured out the best switch arrangement yet, the idea is otherwise fairly trivial to accomplish.

Triggering the activator wirelessly is something I have experimented with. The best analog solution I found for that is a wireless system intended to operate a gate from a remote button. The receiver is relatively small and can be powered by 12V. The remote is a typical handheld door opener button, but would be pretty easy to modify to attach to the control box as it currently operates. The bad news is that this wireless set is about the same cost as my build cost for an entire system, essentially doubling what I would need to charge for it in a finished product.

However, and I’m sure the reader is tired of all this exposition by this point, I do have a solution.

For reliability reasons, I did not first pursue microcontroller automation of this system. The more that can go wrong, the more you have to work to prevent it. I wanted the physical hardware to be solid, but I have always known that it could be more feature rich under MCU control. I have seen a couple of activators controlled by a Raspberry Pi. I love my RPi for all the things it is good at. In my opinion, they are extreme mass overkill for controlling small things, primarily because they are general purpose computers, running an operating system that is really designed for human interaction. In the match where a device was operated by a Pi, the stage it was on was almost thrown out due to reliability issues. The comparitive simplicity of an MCU board removes a lot of potential issues arrising from a more complicated controller.

On the other hand, I have seen quite a few stages, particularly at the national level, with activators controlled by actual industrial control hardware. They are designed specifically for control of industrial equipment where tolerance for failure is minimal. They are priced accordingly. When I started looking at making my device, a suitable industrial controller started at about $300, which is about how much I’d like my entire device to sell for.

My analog system is very reliable; it’s just switches and relays, with almost nothing to break, but adding or changing features requires literally rewiring it. An industrial controller would also be reliable and much more flexible, but is notoriously expensive. The MCU occupies the space between them.

I can replace a lot of relatively inflexible hardwired relays and switches with an MCU and thanks to Espressif’s ESP-NOW protocol, they can communicate wirelessly. It took several days of working through some details, but the decision had enabled several other decisions and almost all of them result in savings of time and cost.

For example, the activator itself is fairly simple mechcanically. There is a car door lock motor that, when powered up by the current control box, it simply pulls on a metal sear, releasing a spring loaded rod that supplies the yank required to activate almost every imaginable moving target. This lock motor has one troublesome characteristic, namely that leaving power applied to it will eventually damage the little motor inside of it. To mitigate this, I use a timer relay. The timer relay is powered by the same activation power from the control box, however it is set to throw it’s contacts after about a half second and those contacts are wired to remove power from the lock motor to protect it. When power is removed, the relay resets. Ironically, this timer relay is the single most expensive part of the activator, including the steel box and frame, and for the MCU board I will be using, I could buy four of them for the cost of one timer relay.

The current control box is quite literally two relays, a switch and a battery. One relay is just to buffer the input trigger so that the full power going to the acivator doesn’t have to flow through the triggering device, also most of the triggers in current use could probably handle it.

The other relay is to invert the trigger input. For example, the ‘dead man switch’ trigger is a hand held switch that the competitor holds and presses to ‘arm’ the system. When they release the button, it triggers the activator. In the sport rules, you are limited in what you can *require* a competitor to do once the timer has been started, but before the timer, you can require them to hold something, for example.

The switch is a three position switch to select whether the input is inverted or not, with the center position used to disable the system.

The battery powers it all. I chose a 12 volt lithium ion battery pack that has a power switch and a barrel connector. In my original testing of the lock mechanism, I used a second timer relay configured in pulse generator mode, set to trip once every 30 seconds and wired at a trigger to the system. Once that was running, I left it on the workbench overnight. The next morning, about 6 hours later, it was still running. In 6 hours, the relay (both relays, technically) and lock motor had cycled about 720 times. The battery was between 40% and 60% charged. This is far and away long enough for a long day at a major match. During the entire time of this protoyping project, I have recharged that battery about 5 times and never was it completely flat when I started charging it.

The latest update to the control box just upgraded the connectors to 4 pin connectors and added power to the trigger input so that the control box could also power the photobeam trigger.

By changing these switches and relays out to a couple of MCUs, I will risk added complexity, particular as I need to write the software for them, but there is a LOT to be gained. The big ones are wireless communications, easier to add sophisicated features and overall lower build cost.

There are GOBS of companies making MCU boards and many of them are clones of each other. The specific controller I have chosen for the activator is commonly called the D1 Mini Pro. I have used the D1 Mini clone in my home automation pursuits. The primary difference between the standard and Pro variant is that the Pro offers an external antenna connector, a requirement for a device that needs to communicate wirelessly but still be enclosed in a steel box. For the immediate upgrad needs, the control box could also use this same board, but for the long term, the control box will probably have something with a display for eventual features I hope to add. I’m starting off with an Esperrif ESP32-S3-Box because it has a display and a couple of buttons on the front of it and I already had it, purchased for some home automation pursuits.

This post is already too long, so I am going to cover my development, implementation and more detailed design philosophy in the next one.