Micro Controller Pulse Circuit

[CLaNZeR]

Thank you again barbosi for valuable feedback.

At the moment I am going to leave the circuit just as a controller and let other people worry about harvesting the BEMF and other forms of output down to them for now, as there seems varied opinions and configurations.

The Micro Processor should be fast enough to handle all 4 Inputs from the Opto switches while still switching the Coils at the correct time, but I think your idea of having the PC calculate seperately say the RPM's is a good idea. Again I think the Processor would probably be fast enough to feed data back to the PC, but by dedicating the RTS line and keeping it seperate will make coding easier for me and also be a good play safe!
A simple Windows application that sits there counting the pulses coming in on the RTS line say once every second, should be good enough for calculating the correct RPM's.
My lathe has a variable speed control and dispalys the RPM via a Digital counter and so I plan on popping a wheel into the end of it with one of the Opto Switches attached to check the accuracy.

Back to the coding this end.

Regards

Sean.

Very creative idea about pulse counting in PC!

Now brief comments:

- I don't see any protection for CMOS agaist BEMF pulse. Of course protection can be mounted out of PCB in parallel with coil, but is a shame to waste BEMF. This is the gold mine to harvest free energy. Maybe a neon lamp in parallel with CMOS will give you a chance to harvest at least partially this pulse...?

- Related also to RPM calculation; if processing time is a concern, then it will be also for all opto signals to be processd when they arrive at the same time. You'll have multiple processes competing for calculation time in real mode. This in case you use a RTOS. Just a thought...

Anyway no body thought it will be a smooth ride, and I presume this is why you asked for feedback. A good start is a half way towards a finished job.

Regards.

[CLaNZeR]

Quick update from me, Last weekend I finished my PCB and soldered up and seems to work as I predicted!
I will update the site soon with Firmware and Software releases and of course Hi-Res PCB ArtWork for the PCB.



I have now started work on my pulse motor and had head stuck into that this weekend.
Have opted for alluminium rather than PlexiGlass this time around.



All I have left to do is Dril out some 20mm holes and fit the magnets flush in the wheel.



Then add a small wheel for the Opto Sensors, mount the Electro Magnets and see how she goes.

I will then start working on how to get the energy back!!

[CLaNZeR]

Is the 20K to adjust things or the serial port?  Not sure why you have both.  I would run it via the PC and get it all working, then move it into the PIC chip.  Or add a couple pots to the PIC to have more control there.

You should be able to do it all via the uC?  You have plenty of PIC chip there.

The FET probably has the diode, but add them if you are not sure.  They are not labeled.

What language are you writing the code in?  The serial routines might cause a little jitter.

EDIT:  Just saw the whole post, FETs are labeled earlier.  Mechanical work is nice..

Hi Mramos

The 20K pot allows manual tweaking of the Trigger delay to fine tune it and then read it back to the computer.
The PC software is just a configuration program so you can specify how you want the Pic Chip to control the Optical Sensors and the Coil triggering. It also allows each sensor and coil to be disabled etc etc.
I thought this would be an easier approach than releasing different version sof firmware for each configuration.

So the Pic is doing all the hard work as such. Here is a screenshot of the Windows application for reading the configuration and writing it back to the Pic. It has to be finished yet but should give you an idea.



Regards

Sean.

[FredWalter]

http://www.overunity.org.uk/softwarev1.jpg

You have an absolute pulse delay option, and absolute pulse width option...

Would it make sense to also have a relative pulse delay option, and a relative pulse width option, that take into account the RPM of the wheel?

Does your software allow one to configure how the RPM is calculated - for example, which opto-switch is used?

[CLaNZeR]

You have an absolute pulse delay option, and absolute pulse width option...

Would it make sense to also have a relative pulse delay option, and a relative pulse width option, that take into account the RPM of the wheel?

Does your software allow one to configure how the RPM is calculated - for example, which opto-switch is used?

The original plan was to have the option to measure the speed between any combination of the 4 opto's and allow that value to be the trigger delay for any of the Outputs, but due to controlling 4 Fet's with 1 Micro doing the extra routines is not so easy as the micro is tied up enough doing the trigger and PWM timings.

After the feedback here I might re-design the PCB and maybe have a small Pic chip for each Fet and a main chip that brings it all together. This will then give dedicated control for each output but obviously the circuit will pull more current. But then again it would be easy enough to put the Pic's in Sleep mode if they are not being used.

Ummm some more thinking needed here, so thanks for the feedback.