Odds are he won't take our advice regardless of what it is. Actually -- never mind. I'm now in favor of letting him struggle to find out the hard way. He might even thank us later.

 

I agree. Today's PICs might be the greatest thing since sliced bread, but I don't think you'll get sub-microsecond precision in a uC unless it has a RISC core running hand-tuned assembler code. OTOH, there's probably a PIC wizard out there that could solve this in a weekend. Personally I'd put everything in a Lattice CPLD, but we all have our favorite toys.

ak

 

there's probably a PIC wizard out there that could solve this in a weekend

Paging @joeyd999 ....

 

Let me back up a step. I'm very passionate about perfecting this, don't ask why. Maybe there's something you guys are equally passionate in, I don't know. Regardless, I am interested in seeing if I can get EVEN BETTER than 0.5us, maybe better than 0.1us.

The problem that arises is the arduino clock frequency doesn't translate into perfect timing. For instance if I use the micros() code for timing, I can tell it to flip a pin HIGH and that number is effectively divided by 4 - meaning rounded up or down. One gentleman tested this for very crucial timing with PPM signals used with R/C radios, and the 1500us pulse was randomly either 1496, 1500, 1504 - and occasionally 1492 and 1508. That's 16us, not 0.5us. That variance ALONE is over 0.8% at 2ms, meaning all my mechanical bits must have less than a 0.2% margin of error to result in my end figure of +/-0.5%. NOTE: I've bolded and underlined some very important concerns.

AnalogKid, while I appreciate your contribution, I again refer to the last sentence in post #1. All my training is that which I've given myself and I'd be able to rebuild a corvette motor faster than design a circuit with your BOM. Also, didn't I make it clear I already have the waveform generator?

I really don't like to turn away people eager to help me, but I am only seeking 1 of 2 things: arduino coding guaranteed to be accurate to 0.5us or pointers on implementing a known-accurate waveform gen with arduino/mosfet control.

I don't know from where you are getting your information.

Crystal oscillators are stable to better that 10 ppm which is better than 0.001%.

ATmega328 can operate with a clock frequency of 20MHz. That gives you 0.05μs resolution ±0.001%.
Even if you use an Arduino running at 16MHz, that will still give you 0.06μs resolution ±0.001%.

If you are using software to time your delay then of course you will have huge uncertainties.
Use the hardware timer and the solution is a piece of cake.

btw, I routinely get resolutions down to 0.005μs ±0.001% stability, that's 5ns!!! using a micro clocked at 200MHz.

 

I agree. Today's PICs might be the greatest thing since sliced bread, but I don't think you'll get sub-microsecond precision in a uC unless it has a RISC core running hand-tuned assembler code. OTOH, there's probably a PIC wizard out there that could solve this in a weekend. Personally I'd put everything in a Lattice CPLD, but we all have our favorite toys.

ak

You're getting pretty digital for an "AnalogKid" Kid. Welcome to the club.

 

You're getting pretty digital for an "AnalogKid" Kid.

Tinker toys are fun to play with.

ak

 

Tinker toys are fun to play with.

ak

So are analog chicklets

https://en.wikipedia.org/wiki/Chiclets

 

AnalogKid, I think I can see where we are "talking past each other", you're talking about overall precision and I'm talking about code not executing immediately. Slow code execution (lag?) is what I'm trying to avoid. Lag could be accounted for in the code if it was a whole number, but multiple tests I've found show it's not.

ATmega328 can operate with a clock frequency of 20MHz. That gives you 0.05μs resolution ±0.001%.
Even if you use an Arduino running at 16MHz, that will still give you 0.06μs resolution ±0.001%.

I completely understand that the ATmega328 clock has high resolution. The PROBLEM is code doesn't flip pin states with just 1 clock cycle on the Arduino, and this is why I don't want to have the Arduino controlling the solenoids. Even the most efficient code on the arduino can't flip an output pin close to 0.06us. Here is a picture of what happens when basic code sets an output high then low continuously, all without any delays added. It takes 4.15us to set the output pin LOW (which effectively gets added to the duty cycle). Isn't 4.15us much larger than 0.06us, or am I crazy?

(https://learn.sparkfun.com/blog/1687)

Here's another I found that gets it as low as 0.375us. This will probably work for me, but it certainly isn't 0.06us.
https://emayssat.wordpress.com/2012/04/10/the-fastest-way-to-change-arduino-digital-ios/

YES I know some advanced hardware would do this, but I came here for help with the "junk" that I had. Nobody has even explained why you can't have 2 mosfets in parallel. They're used for mosfet NAND gates for signals, so why can't 75A mosfets do this with a few amps?

 

Ok, I'm stumped.

I'm outta here!

 

Do you really need 60 nanosecond precision driving a solenoid valve? I would think variations in the valve's metallurgy and spring constant would introduce more timing variation than that. Or, for a snarky facetious retort: Why not 1 ns? 1 ps? OK, enough of my wit and humor.

I'm not a grand wizard, but I've done enough programming to know that you never will get that kind of repeatable precision from any code more complex than three NOPs in series. If:

I don't want to have the Arduino controlling the solenoids.

then we're back to an external clock and divider to get the FET drive waveforms. If part of the external divider is a programmable downcounter, then you can change the output pulse width through the arduino without affecting the system resolution. Is this more like what you're after?

ak

 

AnalogKid I would happily use the external clock driving the FET if someone would be so kind as to design a circuit for me, as unfortunately that's far beyond my skill level atm. My hope was to use the waveform gen to drive the FET, as it was a device I could easily obtain, then use the arduino to control additional FETs thereby actting as a convoluted CD4020.

Odds are he won't take our advice regardless of what it is.

I can assure you I'll happily listen to advice when I get help figuring out the holes in my original idea first. I'm not sure about you guys, but when someone asks me a questions such as "Why has my car's gas mileage dropped?", I tend to explain why rather than tell them to get a Prius.

Until then I will keep asking, what is the problem with 2 power mosfets in series? I'm genuinely curious, not just trying to be a brat.

 

There is no explicit problem, and that is how some AND gates are constructed internally. But it almost always is lower cost and higher reliability to have one power device and do the logical control functions at the logic level.

BTW, two power MOSTETs in series back to back (or source to source) is an excellent way to replace a power diode for much less power dissipation and voltage drop in things like reverse polarity protection and battery management.

ak

 

THANK YOU AnalogKid, that's basically what I was asking from the beginning. Teach someone to fish, as they say... I'll end up trying both direct IC control and the original idea now that I have a permanent scope to use (yay!). My older model seems to test out great with this scope, although it's hard to nail it due to the programming loop creating a variable period (every 6th pulse has a longer off-time).

My remaining questions are with direct control - will my chosen mosfet driver work with the IRF1404Z? Will I need any limiting resistor between gate & driver? The two mosfet's I'll be using will have a gate capacitance (Ciss?) of 3300-4300 pF and the driver can supply up to 5 amps.

Driver: http://www.mouser.com/ds/2/149/FAN3224C-1006782.pdf
Mosfet A: http://www.irf.com/product-info/datasheets/data/irf1404z.pdf
Mosfet B: http://www.datasheetlib.com/datasheet/847688/smp60n06-14_temic-semiconductors.html?page=2#datasheet