Live Fire Training Targets: How we Built a LoRa System to Survive the Shooting Range 

While running live fire training for law enforcement or military teams, you really only care about two things: making scenarios feel real and not wasting time on gear issues. We at Embedded Engineering Solutions were approached by a client with a simple pitch to help address these issues. They wanted us to build live fire training targets that could stick to the back of a steel plate, detect bullet impacts, use a bright LED on the front to indicate hits, and then send the hit data all the way across a full training bay to a mobile device with the  corresponding app installed. 

While it may sound simple, transforming that elevator pitch into a real-world product that functioned as intended was much more difficult than it first appeared. 

Context and constraints for live fire training targets 

The end users were law enforcement and other tactical shooters using these live fire training targets during real courses. Because of this, we needed to work within a few hard constraints. 

• Live fire environment. The electronics live on the back of a steel plate that is getting hit with real rounds. Impact shock is high enough that the unit could sometimes be knocked off the plate even though it was held on with strong neodymium magnets. 
• Long distance. Some targets might be placed up to roughly a mile from the primary location. This made BLE and standard Wi-Fi setups unrealistic for our application.  
• Multiple targets per scenario. Since a typical session might use up to a dozen targets on a single course, and all that data needed to be aggregated in one place, we had to factor in the data volume we’d be dealing with. 
• Gamified training. We also wanted to support color drills, shoot/no-shoot scenarios, long range routes, and other training scenarios, both gamified and otherwise. 
• Repeatable setup. Instructors do not want to reconfigure everything before each session, but the system still has to handle multiple courses and even multiple systems running side by side. 

Given the distance requirement, the wireless design centered on point to point LoRa between the range hub and the targets, with a single LoRa to BLE bridge at the firing line talking to the phone. 

EES handled the electronics, firmware, and app. The inventor handled the enclosure and mounting. 

The challenges we faced 

While on paper this project looks like “sensor, radio, app, done,” in practice there were quite a few non-trivial problems we needed to deal with. 

Properly detecting hits, not bumps and background noise 

We used flexible vibration sensors in each unit attached to a target to detect bullet impacts. However, the raw sensor can’t tell what caused the impact, only that it happened. 

This meant the sensor would pick up everything if it was not adjusted properly. It could pick up a bullet strike, but it might also pick up someone adjusting the stand, a gust of wind, or another target ringing nearby. Early testing showed that large caliber hits on an adjacent plate could ring the whole rack and cause false triggers on targets that were not actually hit. 

We needed hit detection that was: 

• Sensitive enough not to miss marginal hits
• Robust enough that vibrations from the frame or neighboring plates and general handling did not register as hits and spam the app with notifications

To solve these problems, we designed a filtering system in the firmware and created an adjustable threshold in each target. These design features allowed the instructors to fine tune the sensitivity of the sensors on each target to adjust for specific range setups or ammo mixes. 

Surviving repeated shock on steel 

The key issues here were: 

• The shock forces from bullet impacts put serious stress on the solder joints, connectors, and the vibration sensor itself
• Magnetic mounting is strong, but even strong magnets can reach the limit when a plate is hit repeatedly
• When our units do get knocked off, we wanted to make sure that replacing them was quick and easy, to prevent long interruptions in training exercises

It is the same class of problem we see in other harsh environment embedded hardware design: the electronics are fine on the bench but the real world is not the bench. 

Responsive long range links 

While LoRa is a great choice for long range, the low data rate and long packet times associated with it forced us to be careful with what we were sending. 

The system needed to move: 

• Hit events from each target
• LED control commands for each scenario
• Basic status data like whether a target is alive

We had to keep messages compact and protocol rules simple so that, from the user’s point of view, hits and LED changes looked close to real time. 

Multiple systems on the same range 

Another practical challenge was keeping each course isolated from the systems on other courses. In theory there could be two or more sets of live fire training targets running in the same general area. You cannot have one instructor’s app accidentally driving someone else’s targets. 

That meant every target needed to be paired to a specific hub and stay loyal to that hub. We needed to design our product with support for: 

• A one-time pairing step to link each target to the right hub 
• Unique identifiers so two systems could operate next to each other without cross talk
• Automatic reconnection after a power cycle, without forcing the user to repeat pairing

Designing an easy to use App UI, for instructors, not tech wizards 

The mobile app had to do a few jobs cleanly: 

• Discover the LoRa to BLE bridge and connect to it
• Show which targets are online and paired to that hub
• Allow the instructor to group targets together and configure training modes
• Display hits and timing in a sensible and readable way at the end of each practice session

When something about an app is confusing, the users blame the whole product, not just the small issues, so we needed to design something coherent and easy to use. 

Our approach 

The overall architecture broke into three pieces.

Target unit

Each target module included: 

• A flexible vibration sensor for hit detection
• A high intensity LED on the target face to indicate state
• A LoRa radio to talk back to the hub
• A magnetic mounting apparatus that would easily attach to the commonly used steel plate targets 
• Non volatile storage for its ID, sensitivity setting, and hub pairing

The firmware had a simple focus: 

• Sample the vibration sensor and look for impulsive events
• Apply filtering and thresholds to the configured sensitivity setting
• Enforce a minimum gap between valid hits so a single round does not get counted twice
• Package a compact hit event with target ID and local timing and send it over LoRa

Using an adjustable threshold solved the issues we had with different courses interfering with each others data. By allowing the instructors to adjust each target for ammo types and spacing, each range knew what kind of impacts to look for in the data. 

LoRa to BLE bridge

The bridge lived near the firing line and played two roles: 

• Central LoRa hub for all targets in that session. 
• BLE peripheral for the mobile app. 

The BLE bridge also acted as the anchor for the target devices to pair to. Each target knew which hub it belonged to, so it could confidently ignore packets from all the others. That kept multiple systems from interfering with each other when they were set up near the same bay. 

From a firmware point of view, the bridge primarily routed packets: 

• Hit events from targets up to the app. 
• LED and configuration commands from the app down to specific targets or groups. 

We decided to keep the bridge logic small and focused to make it easier to evolve training modes later without having to rewrite that layer. This same idea shows up often in our embedded firmware development work.

Mobile app and training modes

The mobile app displayed everything the instructors needed: 

• Pairing with the bridge over BLE. 
• Discovery and listing of active, paired targets. 
• Grouping targets into teams and/or roles. 
• Selecting a training mode and starting a session. 
• Displaying hit counts and timing during and after the run. 

The core mechanic in most modes used the LEDs: 

• Some modes split targets into red and green groups, with shooters told to engage only one color. 
• Others defined shoot or no shoot targets where hits on the wrong color count as penalties. 
• On long target routes, the app made sure to track timing across positions and tied those hits back to specific targets. 

Because commands to targets were just LED state and simple configuration messages, it was easy to support several modes without changing the underlying radio protocol. 

Results 

Upon delivery, our system included: 

• A mobile app for configuration and results. 
• One LoRa to BLE bridge device at the main firing location. 
• Up to a dozen target units paired to that bridge during a session. 

During use, instructors could light up the LEDS on specific targets, run drills using those targets, and then review trainee performance based on the hit counts and timing sent back to the app, eliminating the need for handwritten notes. Our client took the system into the field to support law enforcement and other tactical live fire training without needing us to publish client specific performance numbers. 

Lessons learned 

A few takeaways that generalize to other products. 

1. Long range plus phone usually means a bridge. If you need devices hundreds of meters or more from the user, expect to pair a long range radio like LoRa with a phone friendly hop like BLE or WiFi at the edge. 
2. Impact sensing is about false positives. It is easy to wire a sensor and count edges. The real work is getting thresholds and timing rules right so that instructors trust the counts, especially when heavy calibers and adjacent plates are involved. 
3. Treat “mounted on moving metal” as a harsh environment. Steel targets are just one example. Anything mounted to vibrating or moving structures deserves early attention to mounting, connectors, and strain paths. 
4. UX and pairing rules are part of system reliability. Clear pairing to a specific hub, obvious status in the app, and simple recovery after a knock off event all reduce the number of “mystery failures” people blame on the hardware. 

If you are building something similar 

If you are working on a long range training system, sensor network, or other embedded product that has to survive abuse in the field, we can help with the architecture, hardware, firmware, and app side as a single package. 

You can read more about our embedded firmware development services and wireless and IoT design work, or just schedule a call and we can talk through your constraints and next steps.