SparkFun Forums

[Mee_n_Mac]

The spec on the detector output is 50 mA. This means the lowest value for the pullup should be 100 ohms. I'd not go below 200.

[StaticDet5]

You read my mind... Lunch, then I'm going to work on the wiring

[StaticDet5]

I just ran 4 runs of data with the new cable and the 50 ohm resistor.

It looks better. The hits were 24,23,26,23. The run with 26 sounded different, and I said it before I saw the results (no one was here to hear it...). Further, the other runs, initially, line right up with each other.

The new cable:
CAT5 cable (I can't find my spool of CAT5e) with four breadboard connectors (Eventually I want to have the second photo-interrupter). One wire of each pair was left unused, and unconnected. I don't know if I'm supposed to connect all four unused wires to ground or not. I can always go back and make that happen (I'll just need to cut a layer of heatshrink).

[StaticDet5]

So there is a limit to the number of files you can upload. Here's log4.

[Mee_n_Mac]

Looks like 2, 0, 4 and 0 false detections for tests 1-4 above.

Slide1.JPG

Slide2.JPG

[StaticDet5]

So every single false detection is shortly after a real detection. That means implementing the "refractory period" where the system ignores inputs for a certain period of time after a shot, should work.

[Mee_n_Mac]

So every single false detection is shortly after a real detection. That means implementing the "refractory period" where the system ignores inputs for a certain period of time after a shot, should work.

It has in every case where I've tried it. Which is all of them w/the detector. For the above AEG and no PWM, 45 msec seems to do the trick. In general I'd think you'd want some lookup table as a function of PWM and probably it'll be specific for each AEG. The latter inplies to me some way of training the controller.

[StaticDet5]

OK. I'll start code bashing over here. I also need to update some pics. I owe Dan a pic of the safety rig (newly upgraded yesterday with a big orange Home Depot bucket... I should start soliciting sponsors...), some of the side projects (The airsoft pistol with pulse laser), and the prototype area.

[Mee_n_Mac]

Refresh my neurons on how this will work in real life. Say you're in SA mode. You squeeze the trigger and hold it. A single shot occurs and no more happens until you let off the trigger and squeeze it again. OK, so how do you keep switch bounce from looking like a squeeze, release, squeeze ? Well the 1'st shot probably takes long enough that any bouncing is done before the software gets around to "looking" at the trigger state again. Going by the last 4 sets of data the trigger to shot#1 times were between 128 - 136 msec. Do you want to incorporate a little bit of "trigger off" time that must occur before a re-trigger can happen ? I dunno but if you get back to double taps in SA mode, it'll be worth a look.

In burst/select fire mode what happens ? I think, like the above, a single trigger activation (and hold) pops off X shots and no more until the trigger is off again. Switch bounce won't be an issue because any bouncing will be done before X shots can be fired. But what happens if the user let's off the trigger before X shots happen ? Should the AEG continue to run until it counts X shots or stop as soon as it can ? If the latter, does that mean immediately (no parking) or after the next shot (and park) ? This all implies that the trigger switch state is being continuously read while the burst is running. Which gets you back to knowing switch bounce vs trigger let-off.

Finally in FA mode the motor runs and runs, and the trigger must be monitored as the motor is running because the only way the AEG knows to stop is by sensing trigger let-off. So how do you prevent trigger/switch bounce from looking like trigger on = run, off = stop, on = run, etc, etc ? Perhaps impose a min burst length in FA mode, no matter what the trigger state reads as ? I dunno.

Lastly at some point in time I think you'll want a dry firing park-it mode. This is so when you run out of ammo, perhaps on purpose, the gearbox and spring are left in a good, non-stressing place (one of the original goals). Given the highly repeatable current variations vs cycle with this AEG, I'm certain some software can be written to train the gun during a dry fire so it finds a proper current threshold for parking. That software doesn't have to happen tomorrow.

[StaticDet5]

OK, here goes.

In all cases, the gearbox shouldn't stop cranking until it is in a "good spot", AND the trigger is off.
This saves us on debounce issues.
If the trigger is pressed, the gearbox fires a round and increments the round counter. The motor continues to run until the round is fired.
In SA mode we have the following flow:
If the trigger is depressed, immediately start cranking the gearbox (we don't need to debounce this)
After the shot is fired, stop cranking the gearbox.
Make sure the trigger is "Latched" (Do not progress until the trigger is released. THIS we need to debounce. We're not going to allow another initiation of the gearbox for a "debounce period")

In "Explicit Burst Mode" we have the following pseudo-code:
If the trigger is depressed, the gearbox starts cranking.
After the gearbox cycles it increments the burst-fire tracker. If the burst-fire tracker is less than the burst setting, the system continues to crank. If it equals (or exceeds) the burst setting, it stops the gearbox.
Again, we "latch" the trigger, again paying attention to debounce.

In "Command Burst Mode" the following code:
If the trigger is depressed, the gearbox starts cranking.
After the gearbox cycles it increments the burst-fire tracker. If the burst-fire tracker is less than the burst setting, AND the trigger is still depressed (no worries about debounce here), the system continues to fire. If it equals (or exceeds) the burst setting, it stops the gearbox (regardless of the trigger state).

Again, we "latch" the trigger, paying attention to debounce.

In "Full-Auto":
If the trigger is depressed, the gearbox starts cranking.
After the gearbox cycles, we check the trigger state. If it is still depressed (no worries about debounce) we continue firing. If not, we stop the gearbox.

In every case, we don't check the trigger until immediately after the round is fired. If the system is not supposed to fire again (due to trigger/burst issues), the motor stops immediately. This will stop the gearbox at with the spring as uncompressed as possible (we can't stop the motor before the spring is released). If the trigger is released AFTER this point, the motor is already starting to compress the spring, we should just fire the shot. In any case, the motor stops with the spring in the extended position.
If we "surrender" to the limitations of the system, we can almost ignore debounce completely. We only need to watch for it when the trigger is released, because a "bounce" could initiate an uncommanded discharge.

We literally don't care about the position of the trigger during the firing sequence. Once the system is commanded to fire, it's going to fire. It will continue firing until the gearbox cycles. Then it will check the conditions for a valid continuation of the firing process.

[Mee_n_Mac]

Sounds like a plan ! Let me suggest a safety feature. In those cases where a preset number of shots is supposed to happen, additionally impose a time limit. If 1 and only 1 shot is supposed to happen, time the trigger pull and should enough time for ... I dunno 3 ... shots have gone by and the BB has yet to be detected, shut 'er down. Same thing for a burst of N shots. This way if the wiring ever comes loose or ??? happens to prevent the detections, the gun doesn't run on until you pull the battery out.

Semi-related story ... A friend bought a new "Tommy Gun" (SA only version, blah) a few years ago and he decided to slick up the trigger a bit. Well he slicked it up real gud he did !! Turned out that the gun was feeding a round into the chamber (almost) and slamfiring as the bolt came forward. Full auto is fun but I'd like the gun to stop when I take my finger off the trigger ! Especially as bits of brass were spraying in my face due to them being touched off before they were fully chambered.

[StaticDet5]

I had a similar issue happen to me when I first started shooting. That one got melted down.

I'm planning on having the system do shot counts on the gearbox cycles, not on the barrel sensor. With the barrel sensor, by default, reading a "zero", there's too much room for "bad stuff" if the wiring goes bad or something.

When the gearbox is commanded to fire, it will cycle the gearbox and look to the gearbox to end the firing cycle. If you set it to three round burst, the AEG will cycle three times, even if it is dry firing. At that point, some kind of feedback will occur, saying "You're not putting rounds out".
Again, at it's most basic, I'd like to be able to just drop the controller into the gun, with minimal changes. If I can, I'd like to make the barrel sensor completely optional (but well worth it).

[Mr. E]

Hi Static!

Sorry for not replying on AM, I've been away from my project for a long time but can finally start getting back to it. I'll read through everything you've posted here and try to catch up! You are light years ahead of me. Keep up the good work!

Mr. E

[StaticDet5]

Mr. E:
Beg, borrow, and steal any ideas you see here. The goal is to have a completely open-source/open-hardware based project. I need to check in with Airsoft Mechanics again. Things got crazy, so I stopped prowling the web.

[StaticDet5]

OK, so now the hard part.

We've been able to examine graphs and figure out where the peaks are. How do I write the computer code to figure that part out, while still keeping it speedy? It looks like we should be able to reliably identify the gearbox cycles. Hell, we can eyeball it ourselves, even with the moving baseline during the initial two shots.

Did you folks already work this out? I ask, because this is stuff I haven't done before.