ARDUINO PWM should drive a opto coupler, and that is controlling the MOSFET, ( and i think i see 2 resistors in the circuit )

That circuit (figure 8 in your linked page) is going to see shoot-through (both high-side and low-side switches on simultaneously) - this is very bad news, don't do that.  The problem is that when the opto-isolator switches off the two gates start to charge up through the 10k resistor (taking about 20 to 200us to do so perhaps, depending on the exact MOSFETs used)  For most of that time both high and low side devices will be conducting, shorting the power supply to ground and causing havoc.

Its important the switching for high and low side devices happens at different times that prevent any overlap of the on-time like this.

Your suggestion of using a NPN to level convert for the p-channel MOSFETs is good, just make sure you allow enough dead-time between switching one device off and the other on (you have to allow for switching time, which means estimating the gate charging/discharging time.

Using a 10k resistor to drive a MOSFET gate is just hopeless for PWM, gates are highly capacitive and need high current drive to switch fast.

For a current transformer you need to know the number of turns, and this can be roughly measured (its likely to be a nice round number fortunately).

Measurement means you need a known source of AC current at mains frequency.  You also need to place a multimeter in AC current measuring mode across the output of the clamp sensor.  Don't try to measure its voltage, you must short-circuit the output with a current meter.  The ratio of current through the clamp jaws to the measured current from the sensor is the number of turns.  Expect a value of several hundred or thousand turns (ie 10A rms through the jaws you'd expect something in the range around 10mA at the output).

Or try asking at the current-cost blog...

Can you be a bit more specific about the application and what counts as "tiny".  And its only presence, not position or number of objects?

Exactly, I'm suggesting you pass the information to the constructor, but don't do anything on the bus till calling a method Begin() - ie write a Begin() and move the code to it.  Then you get control of when things happen.

You need to drive CONVST, RD and read EOC + 8 data lines = 11 pins.  The PD and CS pins can be permanently enabled to save pins.  Note  these signals are active-low.

If you can cope with lower conversion speeds, a serial ADC like the MCP3204/3208 would only need 4 pins (and can read 4 or 8 channels at 12bit resolution).

analogRead takes about 0.1ms, so it should be fast enough assuming no/little contact-bounce.  But with a single pin there is the problem of recognising contact bounce in the first place, which I have glossed over.

Can you clarify the circuit you have there for the p-channel MOSFET?  And which MOSFETs? (are they logic level for instance).

Not so good with brushless motors though (but the Kidera scheme can't be brushless anyway).

Why not? Wouldn't it just be one extra power connection to route via a slip-ring or similar?

My point is that using slip rings means it isn't brushless!  Brushes are common to slip-rings and commutators.

The 555 is cheap as chips and easily available.  Falling edge will work as reliably as rising - for each falling edge there must be a rising edge.   The 'noise' could be due to stray inductance, capacitances or poor circuit layout or lack of decoupling - perhaps the input is too strong - try reducing the input resistor to ground somewhat and see if that alters things.  If a 'scope is available that is very useful for this kind od diagnosis.

If you are using a constant current driver to power a MOSFET gate with a pull-up, make sure the pull-up is large enough that the driver's output pulls fully down - from the curves for the TLC5940 it looks like using a set output level of 20mA and using a 4k7 pull-up would provide good pull-down.  Using a set current of 120mA won't be as good whatever the pull-up resistor.  Assuming you can trust that graph in the datasheet.

A far more direct way is to use a serial-in/parallel-out shift register to drive the MOSFET (the 74HC595 being the classic example) which will pull down to the rail properly and need no pull-ups.  You could also use Darlington arrays to power the LEDs but they have a large Vsat and won't handle very high currents.

Yes that looks right.

Crashes can be caused by power supply glitches, or electrical noise, not just software problems.  Try monitoring the power source when the outputs switch and check that the relay coil has a flyback diode fitted.

Code:

  if(curMillis - windowStartTime>windowSize)  windowStartTime += windowSize;

Adding time variables is a bad idea.

But that's adding an interval to a timestamp to get a new later timestamp, nothing wrong with that at all.

Having just seen your companion posting about the hardware I'm suspicious of the receive side electronics - is the IR receiver demodulating the 38kHz signal - if not then connecting it to the RX pin will not produce clean 2400 baud signalling as the 38kHz waveform will be superimposed - this could easily explain mis-reading of the serial input.

I have posted the code I am using for this project in the programming section. I am transmitting data between two Arduino's using an infrared transmitter and receiver. The issue is that the text string that I am sending is being received as a jumbled mess of characters. Any ideas as to what might be causing this? I'm beginning to suspect some sort of hardware issue. Just an idea of the wiring, on the transmitter I have the infrared LED cathode and the indicator LED cathode wired to digital pin 10. The ground is connected to digital pin 1 for TX communication ability. The receiver utilizes a three pin infrared receiver. The ground and v pins of the infrared receiver are wired to ground and +5v respectively. The signal leg of the receiver is wired to RX.

Keep all the relevant parts of one problem to one topic in one forum please - there are a lot of forums, choose the one that is the best match for the problem in your eyes, so long as its relevant to part of the problem that's fine.