Glad to see people are working on the spreadsheet. I probably never should have made it so complicated. It seems like minor changes tend to break something or other and it's been a big PITA.

I hope everyone is checking things over and not just blindly relying on the buttons and macros. Those are only to make certain tasks easier, you should always check to make sure you're putting reasonable values into the code.

As for the timing issues... in the pics Gompy posted in the other thread look like there's several errors in different places. There certainly can be problems with different Excel versions. I use Excel 2007. There's really no way for me to test things on every version and then fix all of Micro$ofts bugs. For the next version I'll try to make a more basic spreadsheet without all the troublesome macros.

I don't know what's going on with the timing problems Rob is having. It's probably do to the problems he's having with the spreadsheet.

I have run v1.0 on a real engine. The video is here...
http://www.youtube.com/watch?feature...&v=_xVTrjYXT10

The only timing problem I've had is that there seems to be a little bit of retarding as the RPMs increase. The calculations are correct, so there is either some delay in the hall signal or in the output circuitry, or in both.

I haven't had a RPM readout and a timing light running at the same time to take any real-world measurements, so maybe somebody can help with that. To me it looks like around .5-1 deg, per 1-2K RPM. When we get some measurements we can calculate it out in the spreadsheet.

There is a maximum RPM limit due to the nature of the system. I usually simulate things and make sure it can handle 15k or better. In my simulations it seems it should do around 16k, but the real-world limit may be lower if there is delay in the hall sensor. There must be some sort of delay which becomes more important as RPMs increase.

I test on a Homelite 25cc 2-stroke engine. It can't do that high of RPMs so I'm kind of limited in how high I can test things. For now, it looks from Gompy's tests that there may be a limit around 12k RPM, so I highly suggest not exceeding this until we can figure things out better. I never thought people would be spinning props over 10k, so I haven't put much work into testing these high RPMs.

I'm working on switching over to on-the-fly calculations instead of the table lookup scheme, and I think there are some performance gains that can be had this way. It will certainly simplify the spreadsheet.

I don't see any reason to have pull-ups disabled, but if you want to turn off the hall sensor pullup it is easy enough to do. I just suggest that you do with the WPU (or WPUA) register rather than turning them off globally.

I don't like the idea of using the MCLR pin as a reset pin. It simply wastes that pin and you risk EMI or power supply problems resetting the processor. Reset pins are just a bad idea all around. If you want to reset the processor I suggest just interrupting the power supply. You can even put a switch in to do it. The code isn't written to be reset, there should never be a reason to reset the processor. If you are having to reset the processor then there is probably a problem with your hardware. There's no software problems that should require a reset and there are no changes the software makes that would be cleared by resetting it.

I've got some time off for X-mas, so I'll hopefully get another major version finished during that time. I've now got a prop ready for my engine and I'm also planning to try and make some sort of fan-boat and play around with that in the snow and water. That should give me some real-world data to work off of.


-Jake

Have fun.

Wow, 14,000 rpm. Wish I could afford the boat it fits into!
Sounds like a screamer of an engine. You need a powerful ignition to keep up with that thing for sure!

John

Have fun.

Trying some of the old versions before version 1 is giving better results in regards to the timing issues. Some of the changes made after version 9.8 are where the problems started. Ran one of my engines up to 14,000 rpms with it and didn't notice the timing shift after 12,000 like in version 1.0 software. Doing a line by line comparison shows where the routines are different.
It's got to be the rpm tracking cause when it exceeds the limits set, that's when it starts dropping the pre sets in the curves.

John

Some of the lines in the source code are being skipped over when being run in simulation mode . I'm not a programmer but to me, you would think at least once in the main program loop it would access every line at some point to check the statements if they apply or not . Timing changes to extreme ends do not affect the scanning of these lines . I believe this is why there are problems after 12,000 rpm' s .

John

Hi
I have been building an experimental electronic ignition system to use on my Sunbeam S7 motorcycle.
I chose the TCI version of Gompy's circuit with the 16F628A PIC.
At the moment I am driving it with a 555 variable timer circuit as I have not sorted out the sensor side of things yet. All seems to work as far as the PIC is concerned but when I connect a coil I get a few sparks then a spike on the 5V which upsets the PIC and it stops sparking. I am using a Fairchild ISL9V5036 IGBT. If I bypass the PIC and drive the IGBT with the 555 direct I get a really good spark. I have used Veroboard as I don't have psb facilities and mounted the IGBT on the same board as the PIC.
Any advice on how to proceed would be most welcome.
Don m5aky.
Bristol UK

This was the problem with that ignition system. I build a few versions of the CDI systems trying to trace the problem. Dug the whole lot out again a few months ago for another attempt but ended just the same as before. The software was written by someone who would not release the source code and therefore no one else could attempt to fix the software which many said was root of the problem. I read many things about the 16F628A which said they were a rather sensitive micro so for me and many others it still remains a mystery. This was initially the main reason to switch to another system, and John developed a simple CDI unit with others using a 12F683 chip. This system works absolutely flawlessly, however, when one wants to change the ignition curve, it is a bit involved.
This was when Jake became involved to try to write software firstly, for the 12F683.This works but there are small problems to do with high revs apparently.The whole objective is to transfer the code into a 12F1840 chip which has more resources for future developement such as telemetry.

If you go here you will see the end of the era so-to-speak on the 16F628A
http://www.rcuniverse.com/forum/m_98...23/key_/tm.htm

And in this area from pages 1 to about page 5 I think, you will find details on John's original 12F683 version
http://www.rcuniverse.com/forum/m_10..._1/key_/tm.htm

This expands to it's present 43 pages to include the new system from Jake.

A lot of reading but many have been working on this for many years. A lot of improvements and versions, and few mistakes.

You can plug either the 683 or 1840 into the hardware design. They're pin compatible. Right now the code is exactly the same for both, with the exception of the porting changes required because of some naming convention changes.

They're about the same price, so I'd definitely order only 1840s. I'm not sure yet if the next version will support both chips or just the 1840.

AFAIK the current version works great. Simulation shows that it should have a max RPM around 16K. Some people have reported difficulties around 12k+ or 14k, so I would consider that as the practical maximum for the moment.

In the current scheme the table lookup takes most of the processing time. I haven't been able to do much more with the current version because I don't have anything that runs that fast for testing and I'm not sure that there's really anything that can be done in any case.

Hopefully the on-the-fly calculation I'm working on for the next version will be significantly faster since it will use a smaller 8-bit table.

In any case, I've had good results with the current version and current hardware. I am continuing development and I'm sure that 16k+ will be achieved before long.

Jake,
Currently have a bit of spare time so thought i'd do some testing. Started by downloading the Mplab and xc8 compiler and this is when trouble started.

Wondered if anyone has had problems installing as well.

Currently using it on WinXP SP3 on a 2.8 gig machine with 1 gig ram.

Mplab installs ok but towards the end of the compiler install it comes up with "problem running post install step" and goes on to quote the directory (too long to include). Also saying that Mplab may not work properly.
mmm....that's all one needs when one gets some spare time and the *** won't work to begin with.

I've dropped a line at microchip forum so hope some answer comes back from there.

Otherwise it will have to be back to re-installing the Mplab version8 (whatever one i can muster up)

I think it had a hi-tech compiler included.????

What version are you using? They probably kicked out another buggy version to fix problems in the last one.

The whole thing is kind of a mess with java, netbeans, and XML config files strewn all over. All I can suggest is uninstalling MPLAB, java, and netbeans and thoroughly cleaning up all the files they leave behind, then trying again.

I use WinXP SP3, on a far weaker computer, also. I had a couple problems with one upgrade and had to uninstall and clean out everything myself. The uninstall is not very good about cleaning everything up and you can run into problems with java and netbeans if you have the wrong version installed.

The Microchip forums might also be able to help you. There's quite a few users there that are pretty helpful and will get back to you faster than Microchip support.

Have fun.

Mplab is version 1.41 and the xc8 is version 1.10 although I have tried the latest xc8 version 1.12 and it gives the same result.

You could be correct about "cleaning out" but where to start. Were you thinking the registry?

Will check back to microchip forum also, but doubt they have an answer yet.

Uninstalled everything, after that,went into the "programs" folder and deleted complete "microchip" folder.

Tried to delete the "microchip" folder in registry but it would not allow it.

Went to the archives ...
http://www.microchip.com/stellent/id...cName=en023073

Downloaded and installed MplabX v1.10 and xc8 v1.00.

All installed ok without any errors so maybe ok now.

Thanks Jake.......

> You could be correct about "cleaning out" but where to start.

That's the problem. There are files left behind in "application data". .netbeans and .mplabcomm are there. Probably other places too, but just do the best you can.