SparkFun Forums

[StaticDet5]

I've got one tube of thermal paste left. I was going to use it on my gloves for the winter... I'm probably going to wait on it, at least a couple of days.

I've got a couple of voltmeters that I can connect to the system, but I don't have a way of "listing" the readout like I can with the Arduino serial display. The meter reading is going to jump around faster than I can detect it.

I'll try it in the morning, and let you know what happens. I'm worried about measuring directly across the motor. Will the collapsing magnetic field of the motor kill my meter? I only ask because I'm kind rough on meters due to a lack of abundance of caution. I'm very familiar with the magic blue smoke. I'm trying to remedy that.

[Mee_n_Mac]

I've got a couple of voltmeters that I can connect to the system, but I don't have a way of "listing" the readout like I can with the Arduino serial display. The meter reading is going to jump around faster than I can detect it.

I'll try it in the morning, and let you know what happens. I'm worried about measuring directly across the motor. Will the collapsing magnetic field of the motor kill my meter? I only ask because I'm kind rough on meters due to a lack of abundance of caution. I'm very familiar with the magic blue smoke. I'm trying to remedy that.

While I'm curious to see what the meter reads when the motor is running, just measure the battery and Arduino A/D input voltages, with the Arduino on but the motor off, if you're worried. I want to see what, if any, effect the Arduino A/D input impedance is having on your voltage divider and to get some "calibration" on the readings you're seeing. Whatever your eyeballs sees is good enough for that.

Given you've got both a smoothing cap and reverse diode across the motor I wouldn't worry about it hurting the meter. If your Arduino is surviving, the meter will as well. With the motor running I'd exepct some variance in the readings depending on whether the motor is compressing the spring or not. If you can get some min and max eyeballed from the meter, that's good. Otherwise just an average will suffice. Measuring the voltage across the motor would be nice as well but not needed given the other 2 readings.

[StaticDet5]

I measured the amps with a multi-meter (two actually, but one of them just didn't hold a reading well). The values between the Arduino and the multi-meter seemed to jibe, as much as I could tell.

I'm still getting occasional "zero" reads from the analog pin. I was thinking it was a loose connection somewhere, but that would probably make the pin read like it's floating, right?

[Mee_n_Mac]

Amps ... or volts ?

I'm not sure what an open pin would read on the A/D. How occasional is this ?

So what did you read ?

[StaticDet5]

Oh shoot... I only measured volts. The voltage centered around 12.65 volts. After triggering the motor, the voltage would change (Ok, probably obvious), but the "shift" swapped. Before I triggered the motor, the Arduino measured 12.65 and the multi-meter measured 12.69. After, the Arduino measured 12.65 and the multi-meter measured 12.62. I didn't even think to measure the amps.

Is it possible that the Arduino measures with more accuracy?

[Mee_n_Mac]

Is it possible that the Arduino measures with more accuracy?

I wouldn't think so. Both are probably 2-3 % for accuracy, the Arduino perhaps a bit worse. Did you have the DVM - probe on the ground plane (or pin) of the Arduino or someplace else ? So there was minimal drop across the battery, motor on vs motor off (w/ the DVM). And apparently no voltage loss as measured by the Arduino. Previously the Arduino indicated a larger drop, a 0.5V IIRC (though I don't know how you got that from 10 counts difference out of the A/D, 637 to 627). I deduce your Arduino is a 5V flavor so 637 counts equates to ~12.44V given your voltage divider (and a high enough Arduino input resistance). 627 counts would be about 12.25V. That sounds pretty reasonable to me, It's also indicative of why I said you might find it easier to count the motor cycles, or BBs, another way. That 0.2V difference (let alone the 0.04V you just measured above) may be too small a difference to reliably detect given motor noise and decreasing battery voltage with discharge.

So all in all the only mystery to me is the "occasional" 0 count. I'm not sure what to make of those. And maybe there's no real need to.

I wouldn't bother trying to measure the amps, unless you're curious. I don't know what your meter can handle.

[StaticDet5]

I just put another order in with SFE. I've got photo-interrupters, Hall Effect Sensors, and some analog thermal sensors.
I realized that I need to have a sensor on the gearbox, in order to determine when the gearbox has completed one firing cycle. This is in addition to the sensors on the barrel (the photo-interrupters) that are actually counting shots and measuring the speed of the shot.

I'm starting to write my pseudo-code. I'm wondering if I need to include a Real-Time-Clock (RTC) in my design, in order to accurately measure the speed of the shot. How accurate are the Arduino clock cycles? I already have the RTC, so I wouldn't need to get another part. However, the more I look at the datasheet, the more it looks like the RTC only has a 1 second resolution.

I'm trying to decide if I "Unload" the shot timing function to something else. I don't know what the something else is, but I can describe the function. I need the system to detect when the first photo-interrupter is triggered, and begin a timing counter at that point. I then need it to stop and report that counter when the second interrupter is triggered.

Tomorrow I'm going to experiment with controlling the motor speed via PWM through the MOSFET. This would be a nice feature to have when it comes to tuning an AEG.

I'm now eyeballing my Arduino Nano (v3.0), and thinking about starting system integration. I put together the AEG this morning, with the test barrel in place. This way I can mount the photo-interrupters when they arrive. I'm also thinking about mounting a variable resistor (pot) to the trigger. However, it is my understanding that it takes about a tenth of a second to perform an AnalogRead. This isn't suitable for a trigger (It doesn't sound like much time, but a tenth of a second is a really long time). I'm wondering if I can set the system up with two outputs off of the trigger. I digital output, and an analog output that is only read when the trigger is pulled. In this concept, the system would start the "fire sequence", and then read the analog state of the trigger. I can't figure out the electrical layout of this kind of system (I need the system to read a definite digital signal until the signal changes, then I need it to read an analog signal).

Thanks for the help so far. This project has been a fantasy of mine since I saw the movie "Aliens" (Two decades!). I've learned more doing the is project (so far) than all of my electronics dabbling in the past (Three decades).

[Philba]

An RTC is good at ticking off seconds. You are measuring time in milli or nanoseconds. (1000 fps means 1" takes 83 microSeconds). Even with a resonator, your arduino is going to be within a couple of percent minimum, probably better than that. [edit: fixed nano to micro]

And analog read is much faster than that. I timed 1K reads using analogRead() on my mega 2560 and it came out 113 microseconds per cycle of the loop (1000 reads took 113 mS).

[StaticDet5]

Oh wow!
That's exactly the information I need. Thank you.

I'll post up the results of the changes as soon as I can.

[Mee_n_Mac]

I just put another order in with SFE. I've got photo-interrupters, Hall Effect Sensors, and some analog thermal sensors.
I realized that I need to have a sensor on the gearbox, in order to determine when the gearbox has completed one firing cycle. This is in addition to the sensors on the barrel (the photo-interrupters) that are actually counting shots and measuring the speed of the shot.

Well, it looks like you're covering all the bases ! Assuming the photo-interupters work to count BBs, what's your thinking behind counting the gearbox cycles seperately ? Is this to turn off power to stop shooting at the proper point in the cycle ? How does an AEG do this now ? I have to believe there's something like a cars windshield wiper. Once triggered it completes a cycle and then shuts off automagically.

I'm starting to write my pseudo-code. I'm wondering if I need to include a Real-Time-Clock (RTC) in my design, in order to accurately measure the speed of the shot. How accurate are the Arduino clock cycles? I already have the RTC, so I wouldn't need to get another part. However, the more I look at the datasheet, the more it looks like the RTC only has a 1 second resolution.

I think you can calibrate the Arduino "counts", the question really is how stable would this calibration be ? If you counted 1 miilion counts in 1 second, will it be the same tomorrow ? How accurate do you really need it to be ? If your Arduino's clock is set by a crystal (vs a resonator), it's probably good enough.

I'm trying to decide if I "Unload" the shot timing function to something else. I don't know what the something else is, but I can describe the function. I need the system to detect when the first photo-interrupter is triggered, and begin a timing counter at that point. I then need it to stop and report that counter when the second interrupter is triggered.

I believe the Arduino can time things with microsecond resolution, IF true, that should be sufficient. I have a pretty simplistic Excel "simulation" of a gas gun (6" barrel) and IIRC the BB takes a few msecs to go down that barrel. The "sim" is on another PC, I'll check it tomorrow. What I would recommend is using interrupts to turn on and then off a timer, which is running as fast as it can.

Tomorrow I'm going to experiment with controlling the motor speed via PWM through the MOSFET. This would be a nice feature to have when it comes to tuning an AEG.

I'm now eyeballing my Arduino Nano (v3.0), and thinking about starting system integration. I put together the AEG this morning, with the test barrel in place. This way I can mount the photo-interrupters when they arrive. I'm also thinking about mounting a variable resistor (pot) to the trigger. However, it is my understanding that it takes about a tenth of a second to perform an AnalogRead. This isn't suitable for a trigger (It doesn't sound like much time, but a tenth of a second is a really long time). I'm wondering if I can set the system up with two outputs off of the trigger. I digital output, and an analog output that is only read when the trigger is pulled. In this concept, the system would start the "fire sequence", and then read the analog state of the trigger. I can't figure out the electrical layout of this kind of system (I need the system to read a definite digital signal until the signal changes, then I need it to read an analog signal).

Thanks for the help so far. This project has been a fantasy of mine since I saw the movie "Aliens" (Two decades!). I've learned more doing the is project (so far) than all of my electronics dabbling in the past (Three decades).

Philba is correct, an analog read is about 100 usec, nothing in comparison to human perception timing. I'm not sure I'd like a "soft" trigger like a potentiometer, but if you go this way be sure to incorporate a little hysteresis in it's operation. That is, trigger "on" differs from trigger "off" by a few or more counts from the A/D. Verify each state with a couple/few consecutive counts above/below the thresholds.

[StaticDet5]

Sorry about the gap in replies. I go under the knife tomorrow to have my foot fixed, and I've been gimping around trying to get ready for that.

PWM works! I initially had a problem, but it was attributed to a loose wire. I'll be able to tune the firing rate of the gun, which will be nice.

As it stands on most AEG's, the firing cycle is an electro-mechanical cut-out for a single operation of the gearbox, or a continuous cycle with full-auto. One of the goals of the build is to have the gearbox return to a "resting/relaxed" state after operating on full-auto. As most AEG's are currently built, the spring can be left in compressed state. Having the circuit only allow "full" cycles will extend the life of the gearbox.

I did the math on the projectile timing. A BB moving at 1000fps (insane worst case scenario that I've never seen) will clear 6 inches in about a 1/2 of a millisecond. I'm comfortable listing an "Over-speed" warning at that point. A BB moving at 500fps will be at around a millisecond. I need to be able to resolve that. I'd like to be able to resolve up to 650fps, because that's the fastest I've ever seen one of those plastic pellets pushed out of a factory built airsoft gun. That clears 6 inches in 0.83 milliseconds.

Page 550 of the Arduino Cookbook (By Michael Margolis. This book has been invaluable) says that I can get down to a 62.5 nanosecond level of precision if I mess with the CPU prescalar. Yikes. I understand what that says, but I've never even implemented an interrupt, much less messed with a prescalar or even memory registers. Before I tackle that issue, I'm going to need to make sure that the hardware (circuits) work. It looks like I'm going to need to work some voodoo to pull off another feature, a system to measure how many rounds are being fired per-second in full-auto mode.

The "soft" trigger concept is for a couple of reasons. First, there are a couple of systems out there (like the Steyr Aug) that offer "progressive" triggers. Pull the trigger down halfway offers one mode of firing, pulling the trigger completely engages a full-auto state. The other idea is to allow the trigger to be "set" to fire at a specific point on the pull.
This is only a bench idea, right now. The prototype already has hardware built into it for a "two-stage" digital trigger (a snap switch is the first stage, over-pulling it presses a standard button switch). The prototype system modified the original AEG significantly, so I'm working on that design direction first (the display mount, control joystick and trigger assembly are already built in).

It's going to be a couple of days before I get back on. All of my computers are on the fritz, and I'm doing the surgery tomorrow. I'll be back on as soon as I can, hopefully my SFE parts will arrive today or tomorrow (It feels like I ordered them a month ago, but it's been less than a week).

Thanks folks!

[Mee_n_Mac]

I think you'll find that because the BBs start off at rest and have to accelerate (not instantaneously) that the time they spend in the barrel is longer than you've posted above. Somewhere between 2.8 and 3.5 msecs would be my estimate. In any case a timer running "fast" should be able to time that with good resolution. Counting the cyclic rate uses much the same hardware and techniques, so learning interrupts and counters/timers will pay off.

Good luck with the surgery.

[StaticDet5]

Surgery is done. My parts arrived from Sparkfun. I put together the breakout boards for the trigger (not going to work, in this build), and the photo-interrupters. They're a little large for the test barrel, but I think I can snug them into place with some tape (I'm a medic and chem/bio guy professionally... I have tons of different tape).

I worked on test code for the photo-interrupters and hit the same snag that I did before. I think it's a coding issue not a circuity issue (the opposite of my expectations). I think I was using variables incorrectly. I've fixed the problem, and now have sample code that correctly times interrupts.

I had a bizarre moment, and I'm hoping someone can give some insight into what I saw. I was reconnecting everything (battery, motor, board) and the gearbox cycled once, with no inputs triggering the system. Do I need to incorporate an additional MOSFET or transistor to guarantee that the MOSFET gate is not powered until "commanded"? This is a big safety issue to me, and I can't build this thing if it's going to go off unpredictably.

I'm gimping around right now. I can't put any weight on my foot yet (another week), but I'm going to try to continue to make progress on the project. I've started looking at Eagle for circuit design, because I'll eventually need to create a PCB and breakout board for this (I'm thinking about making an Arduino Nano shield for this. The Nano fits in place really well, in the prototype). So far it's been an uphill battle. I'm trying out SFE's tutorials, but they're written with a prior version in mind. Some things aren't exact (and the pain pills don't help my mental state at all).

[Mee_n_Mac]

I had a bizarre moment, and I'm hoping someone can give some insight into what I saw. I was reconnecting everything (battery, motor, board) and the gearbox cycled once, with no inputs triggering the system. Do I need to incorporate an additional MOSFET or transistor to guarantee that the MOSFET gate is not powered until "commanded"? This is a big safety issue to me, and I can't build this thing if it's going to go off unpredictably.

Do you recall the timing of the event ? Did the gearbox run as soon as the battery was connected or did it run some short time afterwards ? I wondering if you've got a hardware problem or a software problem. First off I'd put a 10K resistor between the gate of the MOSFET and ground. But if the problem is caused by the Arduino sending out a logic high before the pin gets initialized to a logic low then you'll probably need another solution as well. If the latter is the cause it should be very repeatable, so see if it happens every time after you add the resistor. There's should be an easy fix for that as well (ie - require 2 pins to be in different states to fire the MOSFET).

Also, just for my curiousity, was the gearbox still cocked or was the spring relaxed when this happened ? If it was the latter, am I correct in thinking (given your prior statement, below, and that's my understanding as well) that whenever power is re-applied, the gearbox will wind the spring to it's compressed, cocked state and so the MOSFET would have had to been still "on" after that winding time in order to fire ?

As it stands on most AEG's, the firing cycle is an electro-mechanical cut-out for a single operation of the gearbox, or a continuous cycle with full-auto. One of the goals of the build is to have the gearbox return to a "resting/relaxed" state after operating on full-auto. As most AEG's are currently built, the spring can be left in compressed state. Having the circuit only allow "full" cycles will extend the life of the gearbox.

[StaticDet5]

The gearbox is run directly by the electric motor. Currently there is no cycle interrupt, or even cycle sensing. Power is applied and withdrawn from the motor regardless of where it is in the driving cycle. This is one of the things I'm hoping to change. One of my current design projects is to determine when the gearbox is at it's lowest potential energy state (spring relaxed). I'm trying to figure out a proper sensing methodology on the gearbox. I'm actually back to my original idea of detecting motor load.

Let me break it down further:
An AEG gearbox (typically) consists of a toothed compression cylinder, backed with a heavy duty spring. This spring provides the power to launch the BB. The compression cylinder is driven by a "sector gear" . This gear is driven, in turn, by two other gears, and finally meets the motor at the pinion gear.
The motor is energized (typically by closing open switch contacts), which drives the gears. The sector gear engages gear teeth on the cylinder, compressing the spring. The sector gear only has teeth on half of the gear surface that makes contact with the compression cylinder. Once it "runs out" of teeth, the sector gear spins rapidly, and the cylinder flies forward. At this point, the activity in the motor changes dramatically (the motor has gone from being under a maximum load to almost zero load). I'm wondering if I can detect that state.
The reason goes beyond just detection of the motor cycle. If I can regularly detect the "load state" of the motor, it gives another indicator of the "health" of the gearbox. A change in load can signal a variety of issues in the gearbox.

The issue that I currently have is trying to figure out when the gearbox has cycled. I was hoping to use a small neodymium magnet and Hall effect sensor combination, but the location that I originally picked is unsuitable. The location was as distant from the electric motor as possible, and still on the gearbox. I'm wondering if I could put the same magnet (or even a larger one. My current one is an 1/8th of an inch) in the sector gear to determine the location of the gear. It won't give me any kind of measurement of the electrical load of the motor, but it will give me a definitive indicator of the gearbox state. Even if I can determine the state of the gearbox, I'd still like some insight into the electrical load of the motor.

On the inadvertent gearbox cycling:
Years ago I switched to using Dean's connectors for all of my power needs. The only disadvantage to them is that they can be difficult to disconnect or reconnect. There are times where intermittent connection is made during the connection process. I'm wondering if this intermittent contact can induce triggering phenomena through the circuit. Right now, I don't have a way to test this. I do need to consider a way to prevent this, if this is the case. When I'm walking around again, I'm going to try to replicate the circumstances, scientifically.

My current project is something I can plug away at with my leg in the air. I'm going to try to tackle the video display portion of the project.
I've got two uOLED displays from 4D systems (The uOLED 96 and the uOLED 160). Eventually I'd like to be able to use either display, but I'm going to work on the 96 first (http://www.4dsystems.com.au/prod.php?id=77).
I've tried using existing libraries, but I'm getting compile errors. I'm guessing that the libraries I'm looking at are not supported by the current generation of the Arduino compiler (1.0). Instead, I'm going to begin experimenting with my own code, and possibly start a new line of code.

Again, thanks for the interest and contributions. It's really moving this project forward.