This is all very good news! After the rocky start I was worried there would be nothing but problems.

John's results seem like proof of concept to me! I'm not sure about the errors he was getting compiling yet, but it's great to see people getting things working and posting back.

In the future, if you do NOT want something you email me posted to the website please let me know. Otherwise I think it can only help to keep posting everything there.

Gompy, I do like the idea of having the spreadsheet generate the code. At the very least it will be good to have it generate the whole user settings/curve table section. I'll work on getting that done.

I know you don't like the multispark, but I think it's worth keeping as an option. You can always turn it off and it doesn't waste any significant processor time. I think that any CDI circuit is going to be different, and some may be capable of delivering sparks very fast. The setup John sent has a partly bad coil, I had a random large spark gap (bare wires), and I still could fire it every 4ms. I think with a proper gap and a good coil it could fire a lot faster. I proper resistor spark plug might also make a difference.

I also think there's other applications for the MSD. If your spark doesn't fire the first time, maybe a spark just after TDC would at least clear the cylinder and burn the fuel.
Don't let me discourage you from discouraging us though. It's good for people to know when us young pups are trying something silly, and I don't want people to think this is some amazing feature when it might not work at all.

COM, I thought about your comment and I think you're right. The software should not just skip sparks that it can't throw on time. I didn't think much about how this would cause problems for high advances at different RPMs. I was only thinking about it being a problem at very high RPMs. I'll rework the code so that it will just throw a spark right away if it can't time it.

My plan for the future is to stick with the 683 for awhile, until I'm sure it's working as good as possible and I've maxed out it's capabilities for features. The code should directly port to the 1840 with no problems, aside from some adjustments for higher running frequency.


I have a few ideas left for the 683. Please comment on what you think of them so I don't end up wasting time on something silly...

****I need to rework the MSD delay degree idea. I think that was a bust. My idea was to space out the sparks as much as possible so they would have the best chance. I thought that the best idea would be to throw the first spark proper, then the next at half way to TDC, then the final at TDC, and/or maybe even sparks after TDC. My thought was that even a late spark would burn off the fuel, which would hopefully be cleaner and better prepare the cylinder for the next spark. It might also give a little power to keep the engine turning so it doesn't sputter out.
My understanding is that it is harder to spark as cylinder pressure goes up. So my thought was that if it didn't fire at the right spot maybe it was because the fuel was late or not vaporized enough, if it didn't fire at TDC maybe it was because the pressure was too high, but ATDC it might have a chance to fire.

I need to know what people think about how best to time the MSD sparks. Set delay between them or somehow spaced based on RPM?

****I'll get two ignition tables loaded at the same time so you can switch between them. I think there's no better way to test curves than switching back and forth and seeing how it runs. People might also want to run the same ignition on multiple engines. There's room for probably three curves, and I might try to get three loaded at some point too. Pins 2+3 aren't used and pin 4 is grounded, so the switch/jumper will probably go between 2-3 or 3-4.

****If anyone has looked at the code closely you might have noticed that I save CurrentRev to LastRev for no apparent reason. I'm thinking about adding a feature that uses the RPM from the last spark to tell if the engine is accelerating or decelerating and use that to predict the delay a little more precisely.

If anyone knows about the different speed throughout the cycle please share. I think that the 30-0 revolution speed is probably less than the speed of the whole revolution. Inertia from the flywheel should smooth things out, but how well does it work? Also what about people milling their flywheels down or running with none at all?

If the engine is accelerating I think the 30-0 speed is probably very close to the total rev speed. But if it's slowing down I think the 30-0 could be a lot slower than the total.

Can someone also set their curve to flat (all the same advance value) and see how steady the timing is? I'm curious if it's real steady or if it doesn't track well when revving or letting off the throttle.

I think it might also be possible to have the engine slow down faster by retarding the spark. Some people might like this. The way it would work is that if the processor detects that the CurrentRev is a lot less than the LastRev it will know you have let off the throttle and will retard the spark to produce less power, thus slowing the engine faster.

****Another idea I plan is to shorten the table to only what is needed for the high RPMs and start calculating the delay on the fly for the rest of the range. If I can calculate at least up to the idle and a little bit of the takeoff from idle I think that will help.

Using a table you can only have so many values. This limits how precisely I can use the timer value.
Right now I have about 128 uS resolution throughout, but I should hopefully be able to get down to a few uS resolution in the calculated range.

The other strategy for this would be to use the high bits of the timer for a table lookup as I do now, then use the low bits to determine the position between table values, then calculate how much time to add. This would take too much processing time I think.

****A RPM limiter is another thing I would like to add. Cutting off, skipping every other, or retarding the spark are the methods I can think of for this. Advice requested.

One interesting thing I noticed about the curent code is that when the RPM goes too high to time the spark it skips every other spark. It just happened to work out this way. But as COM seemed to figure out, this could also happen if your advance was set too high. That would make you run really rough.

****The only other thing I can think of for the 683 is using the sleep mode to save some power. The processor should be able to sleep through 330 degrees of engine revolution. If I can reduce the power consumption by over 90% (330/360) I think that would be worthwhile.

The GP2 interrupt should wake the processor from sleep mode, but the timers don't run in sleep without an external clock source. We would need some sort of crystal to keep the timer going and that would tie up more pins. A crystal is more stable and less temperature sensitive, so it might be something to think about for the future. Tying up two extra pins on a 8-pin processor probably isn't worth it though.


So keep the comments comming! That's what keeps me going and how I learn what I need to know for this project.


-Jake

P.S. John's tested and working version is up on the website. I might get some time to get a few things done tonight.