SparkFun Forums 

Where electronics enthusiasts find answers.

Have questions about a SparkFun product or board? This is the place to be.
By Mee_n_Mac
#139306
StaticDet5 wrote: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.
I'm glad I asked, thx for the info ! That's different from what I had believed, though in restrospec it makes sense. If the cyclic rate is high enough the time delay between triggering and firing wouldn't be that noticable and it's less $$s to make it that way.
StaticDet5 wrote: 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.
A lot will depend on the motor chosen. If it's overspec'ed the motor may be relatively loafing along even when compressing the spring thus making it hard, in practice, to disintinguish between the 2 states. But a strong motor would cost more $$s than picking a just adequate motor so perhaps the difference btw loaded and unloaded states can be distinguished ... amongst the noise caused by the commutation. I do think you'd have better luck measuring current vs measuring voltage (battery or motor) though. If you attempt the latter you will need some adaptive thresholds as I'd bet that the difference in battery voltage, loaded vs unloaded will be less than that of battery charged vs discharged. Best thing I can think of to recommend is to come up with some test program(s) for Arduino and use it as a low budget O-scope. Collect as many samples as you can, of battery voltage and perhaps motor current, with charged and discharged batts and see if you can devise an algorithm to determine the cycle changes.
StaticDet5 wrote: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.
Barring success in using voltage or current to do cycle detection (or the time it'll take to figure it out), I'm sure a good way can be found to do it with a "switch" of some sort. The best way to do this detection depends a lot on the space available though my gut feel is to use some optical method.
StaticDet5 wrote: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.
FETs, due to their high gate impedance, can be prone to false triggering when the voltage across them changes rapidly. Adding the resistor mentioned is good practice ... just in case. I'd only do more than this if testing showed there was good reason to do more. And afterall this is Arisoft and not a real firearm (or real steel as the AS community calls it). An AD is less likely to cause injury, provided one follows the normal safety rules.
StaticDet5 wrote: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 definitely want to see pics when you're all done ! Damn man, you'll have me digging into boxes to drag out my project pistol vs getting packed to move. :shock:
By StaticDet5
#139452
Good news!
First, I'm walking (limited as it is).
Second, I've been staring at a gearbox cycle indicator for more than a year. I feel like a freakin' idiot. There's a small armature coming from the gearbox. I tore down the gearbox today, removed the main spring, and reassembled it. I was then able to cycle the gearbox by hand. This arm moves at the end of the cycle. Literally at the end of the cycle. I'd kick myself, but it's hard with one functional leg... :oops:
Engineering the cycle detector is now going to be easier, but still a pain. I'm leaning towards a Hall Effect sensor, as a mechanical switch is just going to wear out and be subjected to a massive amount of vibration. However, the SFE Hall Effect sensors are a "latched" type. I either need to devote two pins to the sensor (There's a brilliant write up in the user notes about this solution), or find another sensor.

I'm going to devote another pin to a safety transistor for the drive MOSFET. I can't have this thing firing randomly. There's just too much of a safety issue with that.

Attempting to get the uOLED display working has literally been 4-5 days of pure frustration. There's an incredible library out there for interfacing an Arduino and 4D System's uOLED displays (The 96, 120 and 160). These displays are very attractive for a number of reasons. One of the biggest is that they potentially all have the same pin-outs.
However, the library is only supported up to Arduino version 23 (Not the new 1.0 version), and I can't even get that one to work. One of the dependent libraries appears to not be working, and I can't get folks to help out with the "Code Hodge-Podge".
Instead, I'm looking at the programming language of the display itself. I believe I can write code for the display, and have it take serial output from the Arduino. This has some really nice benefits, and I think will allow me to easily code for a system without a display.

I'll get some pics of the prototype up soon.
By StaticDet5
#139509
Image
OK, first, the "meat" of the matter. This is the overall project glance. Going clockwise from the voltage divider.
The voltage divider is set up to drop 20v of current down to a 5v current (Two resistors, R1 equaling 30k ohms, R2 at 10k ohms. If you look really closely you'll see that there are 4 resistors at 10k each. It's what I had on hand). I'm using a top end of 20v because that's the top end of what -I- would crank through one of these motors. The voltage divider is wired to the battery (+), the ground, and one of the Arduino analog read pins. This system allows me to see the actual voltage of the battery (across 1024 increments ranging from 20v to 0v). I may increase the voltage divider to drop 30v down to 5v. This will increase the protection on the Arduino analog input, and allow for a wider range of batteries to be used, without really sacrificing resolution.

The black breadboard is a simple low voltage trigger setup. This is actually the part that got this build started. Conventional AEGs use a high voltage, metal plate switch to turn the motor on and off. Watching these switches in action is a great demonstration of electricity, as the contacts frequently arc as the motor is turned off and on. This contributes to oxidation on the contacts, reducing circuit efficiency, which slows the motor down. On this system, those metallic contacts and "high" voltages have been transferred to a MOSFET breakout board. The MOSFET acts as a switch, but has no moving parts, and no arcing. Which the push button on the breadboard still has metallic contacts (teeny tiny little ones, compared to the mechanical switch of the old AEG), it's handling only 5v at just several dozen milliamps.

To the right of that is the fuse box. Inside is a 20amp, 12v automotive fuse. I'm taking a fair amount of pride that I haven't blown this fuse yet. Airsofters who mess with their guns blow-out fuses so often that many remove the fuse and short the terminals.

Next to that is the AEG gearbox. The air nozzle is on the far right (black). The blue tube to the left of it is the compression cylinder. To the left of the compression cylinder is where the cylinder travel space is. The actual spring is about 90% of the space from the start of the compression cylinder to the back of the gearbox. Different springs are available. This is actually a pretty weak spring (compared to those you find on AEG's built for range), as I use the AEG inside, or when I'm working in close proximity with people. The last time I checked the FPS it was around 220 Feet Per Second, which is pretty anemic. Still, it's a pain in the butt to get this spring back into the gearbox, so I prefer to not do it if I don't have to.
Below the cylinder and spring is the actual gear system. Three gears between the toothed cylinder and the pinion gear on the motor. The gear that interfaces with the cylinder is the sector gear. It only has teeth across half (approximately) of the gear. The sector gear also has two separate timing features on it. The first is a simple post on the gear that moves the air nozzle, to allow the next BB to fall in place. The second is a cam that moves an arm (the piece of metal sticking out of the gearbox under the cylinder, approximately an inch above the word "box" in "AEG Gearbox"). On a conventional AEG this arm breaks the trigger contacts after a single cycle of the gearbox, allowing the gearbox to fire strict single shots.

Below the AEG are two 4D Systems uOLED screens (the 96 and the 160). These screens have similar pinouts (The 160 has 2x5 pins, while the 96 has 1x5 and a 1x2 arrangement), and are very bright and colorful. They also sport their own embedded processors and uSD card slots. Both boards have an IO pin that can be used as a digital pin, a joystick (using a resistor arrangement), a speaker, or an 8 or 10 bit analog sensor. The 160 has an additional IO pin as well.

Above that is the MOSFET Breakout board from Sparkfun (http://www.sparkfun.com/products/10256). I replaced that MOSFET with a higher rated MOSFET I had purchased in bulk (IRT 3205). Again, airsofters that mess with their guns tend to do horrible things to them. I used a breakout board because I'm an electrical amateur. I had tried wiring the MOSFET up myself, without a board, and it just wasn't working. To the right of the board you may be able to make out a capacitor and diode arrangement. This is something that I'll need an actual electrical guy to look at and make sure it is spec'd correctly. I have no idea what the diode is, but it has HUGE leads. The capacitor has the markings 561 and 1kv. I'm guessing it's rated at a kilovolt. Again, it's what I had on the bench at the time.

Above that is the Arduino board, powered through a barrel jack which is run to the batter side of the MOSFET. I'm hoping that the MOSFET and diode/capacitor arrangement will protect the voltage input from the crazy electrical spikes generated by the motor in the gearbox. I'm using my oldest Arduino, a Diecimila (http://arduino.cc/en/Main/Boards). Honestly, I can't believe this little board has survived all the abuse I've heaped on it.
To the left and below (at the 7 o'clock position) is the Arduino Nano board that will eventually be the brains of the gearbox. These things are tiny, but still pack all the features (and more) of the full size Arduino. I'm hoping to design a MOSFET breakout board that will sit on top of the Nano like a backpack (or Shield, which is the Arduino terminology).

Below the Nano is the Lithium Polymer battery. I love these batteries, but they have several special handling requirements. A big thing with airsofters is to hold down the trigger until the battery runs out (OK, maybe that's overstating it). Doing this to a LiPo damages it. One of my goals is to incorporate a battery safety system that will warn the user when the battery is running out, and eventually disable the motor when the battery is below a certain threshold.

OK, a big huge post. I apologize if "TLDR" applies here. I'm going to snack real quick, and post the pictures you really want.
By StaticDet5
#139510
Image
Here's the eventual housing.
The gearbox and battery slide into the back of the stock. The Arduino Nano is at the bottom (you can see the first stage trigger wires coming out from above), and easily fits into a roomy recess in the bottom.
The left-most hole in the stock is the trigger location. Interior right, you can see a modified lever switch (similar to: http://www.sparkfun.com/products/9414), and a slide joystick (http://www.sparkfun.com/products/9426). The joystick just screamed to be mounted there. Even if the ergonomics don't work out, it's probably going to stay there on the prototype.
I'm contemplating an additional safety to be mounted in the recess at the 10:30 position on the left-most hole.

On the top of the AEG, you can see the sight rail has been slightly modified to accept the uOLED 160. This location doesn't interfere with the magazine system or obstruct the mounted sights.

Things to do:
Figure out the best way to drive the uOLED. I'm almost certainly going to make use of the onboard processor to handle drawing and updating the screen. That means I'm going to have to figure out a communications protocol between the display and the Arduino. This is going to be accomplished over the existing serial datalines. I already know that I have enough room in the AEG for cabling runs to run the required 10 pins to the display (not all of the pins are used, but this will give me some expansion options for future tech integration).

Figure out Eagle to layout the new MOSFET Backpack/shield for the Nano. My computers are rather gimpy right now, so this is a big headache.

Figure out the best way to incorporate the TMP36 thermal sensor into the MOSFET/Heatsink assembly. I just think this is a good idea.

Incorporate the additional transistor/MOSFET into the drive MOSFET system, so that I can definitively power down the MOSFET in "no-fire" situations.

Determine the best method for observing the movement of the gearbox cycle arm. I think Hall Effect sensor and a small magnet mounted to the arm are the best way to achieve this. I just need to engineer the mounting of the Hall Effect sensor.... Oh yeah, I also need to find a good Hall Effect sensor. The other issue is going to be: Can I track the gearbox AND the movement of the BB down the barrel at the same time. Measuring the speed of the BB is going to require an interrupt. The gearbox is going to complete its cycle right around the time that the BB starts moving down the barrel. Tricky....

I need to figure out how safe it is going to be to keep my USB system hooked up to this thing when I'm using it. I'd love to have some on screen diagnostics, or even download from the uSD card on the display (Eventually I could log system snapshots to the uSD card). I know the prototype Arduino board I'm using has protection system build into it to prevent spikes being transmitted on the USB lines. I don't know about the Arduino Nano.
By StaticDet5
#139572
OK, I tinkered this morning, and I think I found the solution to reading the end of the gearbox cycle.

Originally, the electrical contacts for the trigger switch were housed in a plastic box connected to the gearbox just below the cylinder. I'm going to chop that box a bit, and mount a Hall Effect sensor there. I'm going to do some experiments with the Hall Effect sensor that I do have, and figure out if I can use that.
For a single round, I'll have to read the trigger pull, energize the motor MOSFET, wait for the Hall Effect sensor to be driven high, de-energize the motor MOSFET, look for the round to pass the first photo-interrupt, count the ticks until the round passes the second interrupt, burst the info to the display.

Visualizing things, I think that's the progression for single shot.

I may change the title of this thread to something representing the project, instead of the problem.
By Mee_n_Mac
#139615
I wasn't sure what the following meant exactly ...
This arm moves at the end of the cycle.
The end of 1 cycle is the start of the next. I look at it akin to how I'd look at a 2 cycle engine, there's a compression phase and an expansion phase. I'll (arbitrarily) choose to consider it from the springs POV and say when the sector gear is engaged and compressing the spring, that's the compression phase. When the sector gear disengages and the piston flys forward, that's the expansion phase (even though that's when the air driving the BB gets compressed ... argghhhh :shifty:). So I can see your concern about how a sensor that trips just at the transistion from compression to expansion might conflict with measuring the BB speed but in reality there will be some time between the piston coming forward and when the BB trips the 1'st photo-interrupter. It may be small to me and you but to electronics 100 usecs would be a long time. I'll also mention that PICs have the ability to have an external digital input pin trigger a counter/timer to be captured. I don't know if the ATmega has this same capability. If so then the signal from the 1'st photo-interrupter could be sent to this pin, no software needed to do anything (wrt timing/chronograph) at that point in time ... perhaps. You might look to see if an ATmega has a similar "capture" capability though as I said it might not even be needed given the 'slight' time delay btw the 2 sensors tripping.

Still it would be nice to know when the transistion between expansion and compression starts (when the sector gear just starts to engage) as this is where you'd want the motor to stop, to save wear and tear on the spring by leaving it uncompressed*. Since I can't visualize the mechanical arrangement of the aforementioned 'arm' I don't think I can be of much help in this. Somehow getting the Hall effect (or other) sensor to trip at this point would eliminate your concern and simplfy how to "rest" the gun when off.

Your prior post also had me thinking about how I'd 'architect' the software. My 1'st thought is to have the main loop reading the trigger pot and perhaps doing the display updates (and this part perhaps conditionally, see below). When the fire threshold was reached the motor is turned on. Interrupt service routines then time and count the BBs. If the cycle detect could be made as I'd hope for earlier, then at that point, it's ISR would make the decision to shut the motor off or leave it on ... by reading the trigger pot again. A pot reading less than the turn_off threshold (< fire threshold) turns the motor off. Higher readings either;
- decrement a burst counter and leave the motor on (unless burst count = 0) or
- just leave the motor on (full auto mode)
... thus giving you the progessively staged trigger I think you were looking for. When the motor state eventually goes back to off, perhaps that's the time to calculate the timings and shot count and update the display. Would you be looking at the display while firing ? I think not. :lol:

*OTOH - I can see how stopping the motor with the spring compressed and just about to come forward would increase the responsiveness of the gun. The delay between the trigger reaching the fire threshold and the BB getting launched would be minimized this way. But since the present mechanism doesn't do this perhaps this isn't needed or desired.
By StaticDet5
#139686
There used to be an AEG that was specifically designed to stop the gearbox at the top of the spring compression cycle (I'll be specific when I talk about compression/expansion, as you're right, we're talking about two opposing systems that are not necessarily in temporal sync). The gearbox had issues, and chewed up motors (The gearbox relied on the motor compressing the spring one last gear-tooth-worth). If I ever get to that point, I'd consider an additional programmable fire mode to let you stop the motor at the top of the spring compression cycle.

First, I gotta get that thing to fly.

I talked to a friend of mine on Friday. We sat down with his credit card and placed a decent order with Jameco. I'm going to build him some ATTiny fireflies (LED marking strobes), and he paid for $50 worth of supplies, including several different Hall Sensors. I'm going to play with a ratiometric sensor, and a couple of different threshold non-latching Hall Effect sensors to see if I can get this part working.

He saw the price of the ATMega's versus a Nano and wants me to build the system around that. I'd rather spend the extra $10 and have the easy working environment, at least for now. I guess a "pro" version could be made, but I still don't see it being much smaller than a backpacked Nano.

I really think you're right about the timing of the cycles. I'll have enough time to get things done. If not, I pulled a couple of extra ATTiny's to mess around with. I can achieve a dedicated chrony timer with one or two of them.

If you take a look at the second picture I posted, you can see a metal "projection" sticking out of the gearbox, on the right side, just below the blue cylinder (literally take the "AEG Gearbox" label, and look directly above the word "box"). That's the "cycle arm" that I'm talking about, that moves when the gearbox has reached the spring expansion portion of the cycle (the start of the spring compression cycle).
By StaticDet5
#139777
Big break this morning on the display issue.
I got the uOLED display talking to my computer over the serial connection, using the 4D Systems 4DGL programming language.
Nothing complex, I basically sent out a test character (T) and looked for it on the Terminal (4D's Terminal program is actually pretty decent). Then I manually typed in a "Y" to reply to the display. I had the display wait for two seconds for the "Y" to call the comms test successful, and then displayed the results of the comm test on the display.

It took some tweaking, but it worked. I missed that the serial communications needed to take place in hex. Once I figured that out, everything fell in to place.

I'm going to work on a one or two letter serial communication between the display and the Arduino. Essentially, every communication will be of the format Alpha-Alpha-Number. I need the Arduino Nano to pass to the display (shot FPS, shot increment, fire mode, temperature, voltage, etc). I think I'm going to take advantage of the display's IO pin(s) to act as inputs. This will take some of the UI overhead and management functions off of the Nano.
Can more than two devices utilize a serial communication? I can't see a reason why not, but I've never tried it.

I did change the name of the project to accurately reflect what I'm working on. Also, I may just pull the trigger and get a 20-30A current sensor from Pololu to solve the issue of measuring electric load.
By StaticDet5
#139920
The Mouser parts arrived.
A quick note about forum/site trolls is worthy right now. I used to help run an airsoft board, and I hated trolls.
Same thing applies here.
This project incorporates parts from Sparkfun, Jameco, Mouser, Home Depot, AirsoftCQB, Pololu and others.

This project wouldn't be happening without Sparkfun. Period.

I'm a medic. Not an electrical engineer, not a computer programmer, not an embedded microprocessor guru. I literally entered this project with no real successful electronics experience (lots of flailing, but that's it).
Yes, I can get cheaper parts from Mouser, but I get precisely zero interactive support in making them work. No project ideas, no forums, no tech support.
Hell, this project was stalled until I got a MOSFET breakout board because I couldn't wire the basic MOSFET/Resistor combo correctly without it.

/end of rant

So the parts arrived from Mouser. I grabbed a variety of Honeywell Hall Effect Sensors (Ratiometric SS49E-L, Unipolar SS441A, and Omnipolar SS451A), and some other parts.
I spent yesterday fussing with the old latched sensor. I found out this morning that the time was wasted. Apparently neodymium magnets don't like soldering irons. The magic magnetic stuff runs away from the high heat or the solder, I'm not sure which one (Ok, in reality, I do. I just didn't think that heating the metal for that period of time at that temperature would change the magnetics. Believe me, it does). Today we're switching to hot glue (which works).

I tried the ratiometric sensor first, and got bizarre outputs. This sensor requires an analog pin, so I was using the serial monitor to keep an eye on it. My goal was to find a threshold for "at rest", and trigger when a significant spike occurred. While there were significant spikes, I kept getting aberrant reads in between (zeros when it should have been high, and 200+ readings when the sensor should have been low). I tried a couple of different wiring ideas, but nothing worked (throw some resistors in there, etc.). In the end, I just said "Screw it", because I really wasn't interested in a ratiometric sensor in this role (I'd much rather work with a digital output).

I went to the ominpolar sensor (SS451A). I had some initial trouble because I couldn't figure out the correct wiring for it. I was using a 10k resistor to ground the digital input pin, No, don't do that. It doesn't appear to have harmed the sensor, but you need to try a different approach. I checked the bildr tutorial that is attached to the Sparkfun Hall Effect Sensor product page http://bildr.org/2011/04/various-hall-effect-sensors/. I followed example 1 (The OPTEK), but with a 1K resistor (again, it's what I have).

It worked! Not just on the bench, but also on the gearbox mount that I made.

I'm taking a quick lunch break right now, but I think I'm going to try to program in a single shot code today, and see if it correctly interrupts the gearbox cycle.
By StaticDet5
#139922
Sadness.... I have released the magic smoke.

I think I blew out the MOSFET.

It also looks like that the gearbox arm that moves at the end of the gearbox cycle does not move throughout the full range of available travel. It's not moving the arm high enough to get the magnet in front of the sensor.

Wow, this place reeks of crushed geek dreams right now :)

I've got more MOSFET's. I'll look at wiring one up on Monday. I think I'm busy until then... which is gonna drive me crazy.
By Mee_n_Mac
#139930
StaticDet5 wrote:I went to the ominpolar sensor (SS451A). I had some initial trouble because I couldn't figure out the correct wiring for it. I was using a 10k resistor to ground the digital input pin, No, don't do that. It doesn't appear to have harmed the sensor, but you need to try a different approach. I checked the bildr tutorial that is attached to the Sparkfun Hall Effect Sensor product page http://bildr.org/2011/04/various-hall-effect-sensors/. I followed example 1 (The OPTEK), but with a 1K resistor (again, it's what I have).

It worked! Not just on the bench, but also on the gearbox mount that I made.

I'm taking a quick lunch break right now, but I think I'm going to try to program in a single shot code today, and see if it correctly interrupts the gearbox cycle.
That's the sensor to use for what you intend to do. It's inputs are the +V supply votlage and ground (and the magnet). It has an open collector output, meaning internal to the sensor is a transistor whose collector is the output pin. It can sink current but not source it, so you need a pull-up resistor to get the output up to your 5 (or whatever) volts when the output logic level is supposed to be a high. Your 1K resistor is fine, perhaps even a little too large in value as it means that with a 5V supply and a logic low output from the sensor, you're sinking 5 mA in the sensor. It would work for you just as well with 1 mA or even less. That is the 1K can be a 5K to save the battery juice. It might work just as well with the sensor tied to the Arduino digital input and that input's internal "soft" pull-up enabled (no external pull-up resistor needed). The open collector is similar to how you're using the FET as a switch. Both provide a low resistance path to ground when switched "on" and a high resistance path when "off".

I don't know what to say re: the gearbox arm. I got the (uninformed) impression that it moved with the sector gear and had served some similar "interrupter" function (in some way) with the unmodified gearbox. I pictured it moving forward and backward (inline with the piston travel) driven by the sector gear (like a connecting rod off the crankshaft in an engine). I guess the question would be if the range of motion was far enough to allow the magnetic field to decrease enough to allow the sensor to switch. If not perhaps a weaker magnet is the answer ? Or more distance between the sensor and magnet so that whatever motion there is gets across the tripping threshold(s) ??

What, if anything, was different with the FET ? I'm surprised it blew and not the fuse or motor given it had been working. Did it go upon starting the motor or during a run with a long on time or as the motor was turned off ? Knowing this might help pin down the cause. Did you have any protection diodes in place, like shown below ? The diode D1 is often, but not always, built right into the FET. The flyback (snubber, etc) diode across the motor is always your chore.
Image
http://www.electronics-tutorials.ws/tra ... ran_7.html
By StaticDet5
#139938
The motor went out when I tried to start the motor. I think the magnet fell off the arm (hot glue isn't going to do it), and stopped the motor at a critical point (trying to fully compress the spring).

On the MOSFET, can I use a breadboard to test out MOSFET wiring (I wanted to make changes anyway), or am I going to start melting boards? Ideally, I'd like to be able to swap out the MOSFET as needed (or as damaged).

The motor issue may really be down to an undercharged battery and a bad stop in the cycle. Looks like I'll have some time this weekend to peck at it.

Thanks folks!
By Mee_n_Mac
#139940
I think your motor is going to draw more than the 1-2 A most solderless breadboards can handle so I'd make up a separate test jig to route the high current path through (drain and source pins). A barrier strip where you can screw down the FET legs would be my choice. Screw the FET down on one side and the connecting wires on the other. You can get them at RS ... still ... I think. :shifty:
http://www.radioshack.com/product/index ... Id=2103228

Image

Because the spacing of the terminals is wider than the legs of your FET, I'd get 2 of the above and put them side by side with the FET in the middle of them. The middle leg goes to one strip and the outer 2 legs to the other ("L bends" in all legs). Voila, a high current test jig where the FET can be swapped relatively easily (no soldering). Don't forget the gate-to-source pull-down resistor that came with your FET BoB.
By StaticDet5
#140015
Well, I figured out why the MOSFET blew...

The gearbox hosted a malfunction I haven't seen before. The guide rod that guides the spring broke. This particular guide rod is a "Low torque" guide rod, with a bearing base. It broke at the base, in such a way to scatter the little bearings everywhere. I don't think any got to the gears, but I'm not sure. I'll be spending the afternoon doing a detailed tear down (good news, more pics will be coming, along with some diagrams to further show the insides of these things). I need to source a guide rod...
  • 1
  • 2
  • 3
  • 4
  • 5
  • 32