AVI-TAR System Design Part 1

When I started this project over a year ago I knew very little about AEG (airsoft electric gun) operation. That was a blessing because it forced me to try different things in ignorance of the "system" I was working with. You learn more from your failures.

With that in mind, time for some technical stuff.

Theory of Operation

This is a toy, after all, so I didn't try to get too fancy. In order to meet my design goals (in my first post) I figured that I needed the following elements:

• A "shot sensor" to detect when a round was shot. There are a few ways to do this:
• Timer - Once gearbox timing is determined, you can time the shots if you have a fast enough timer system and fine control of the motor so that you can be sure of where the gearbox is when you stop the motor.
• dV or dI detection - The motor that drives the gearbox tends to draw more current as it pulls back the spring and then freewheels as the sector gear releases the spring for a shot.
• Hard gearbox timing - Uses some method to determine where the gearbox is. There are a few systems out there that seem to monitor the sector gear. I assume that they look at the disconnector assembly to determine when the system has run through a cycle.
• BB detection - Uses some method to detect a BB fed through the barrel.
• Other - Vibration detecion via a piezo element on the gearbox? Tried that...
• A magazine position sensor to tell when there's a mag inserted in the mag well.
• A user interface; display and user controls that would fit into the gun's design.
• Power electronics to control the motor.
• A micro controller to tie it all together.

From that comes the system diagram:

Of course, this is primarily a software-driven design since the feature set I'm aiming for is complex.

With these subsystems, the operational theory is:

• State-driven software that reacts to user inputs as well as environmental inputs,
• Environmental inputs include shot detection, battery voltage and magazine state.
• User inputs include trigger state and some sort of menu/selection switch inputs.
• Software runs in a continuous loop, checking inputs; some inputs may generate interrupts to trigger state changes mid-loop.
• Inputs result in state changes, which cause subroutines to execute, based on state.

So Many Choices:

A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible.

With that quote I profess to be more engineer than scientist. Why hurt yourself while trying to unscrew the inscrutable? I tackled components in this order:

1. Motor control. I wanted a half H-bridge design but didn't want to have to festoon my board with multiple MOSFETS and their attendant components that'd be needed to interface to logic-level I/O. Fortunately, there's a lot of need for this type of logic-driven real-world interface so you can find everything you need to control a DC motor prepackaged onto a chip for not much money. I looked at a number of high power half bridge drivers before settling on the Infineon BTN7960B, which I found can be sourced cheaply. It's an older product and Infineon has since moved on to the BTN7971 and BTN89xx family. A good discussion of how to use these neat little devices is here.
2. Processor. There are plenty of decent uCs out there and plenty of good tool chains supporting them. I didn't want to waste time in circuit design so I looked into breadboard type devices. It boiled down to PIC and AVR devices. I've used both before but the AVR-based Arduino culture seemed more adept at rapid prototyping so that's where I went. The SparkFun Pro Micro (5V) is what I settled on. I'd helped my son build a game with one for a school project and he got to learn C and state-driven programming while I got to check out the product.
3. Everything else. I knew that I didn't have a full-formed idea for the user interface, nor did I understand how to detect shots from the AEG. I figured that I'd dope those out through trial and error. And boy, was there a lot of error to experience...

The "everything else" category was where the scientist came in. Experimentation was the only way to determine how to solve the puzzles of shot detection and the little gotchas that revealed themselves during design integration (making all the parts work as expected). Research is important to the scientific process as well. For example, I found that the micro switch used in the S&T gearbox has a lot of bounce when running in full-auto mode due to the extreme vibrations caused by the gearbox. I spent hours figuring out why the gun would randomly stop firing in burst mode; this was the cause. As it turns out, someone else wrote up the phenomenon. A little time on Google would've saved me hours of hair-pulling and I ain't got much hair to begin with. Of course, you have to know what you don't know before you can research.

I figured that I'd be breadboarding the bench test, throwing support electronics around the core as needed. In reality, once I decided on the display to use and got that working on a breadboard I saw that I needed to get onto a PCB. The motor control IC I wanted to use is a surface-mount device and I needed to run it full power in the early stages of development. No way to do that on your usual white protoboard.

These days, you can do PCB design and get a batch of boards made pretty quickly. I've been using OSH Park for PCBs. They take Eagle board files and turn them into reality for not a lot of money.

I'll continue on with the PCB design and schematic in the next post. Until then, "if you can hear it, it wasn't meant for you".