Back to the bits'n'bytes

There's been an on-going battle between me and the ATMega chip recently. I wanted it to work as a rev-counter and spark timing reporter, and it didn't want to be reliable.

at first I had the idea that it was the fault of my detection process or algorithm. I had a 555 timer configured as a flip-flop triggered high by the incoming spark pulse and reset to low by the engine TDC detection. That way (I thought) I could measure the width of the pulse and the frequency of the full cycle, and calculate the RPM and spark advance. It failed quite spectacularly and very bizarrely, giving fractionally out of time results as well as full cycle multiples. I now realise that it was the way I was detecting the pulse that was causing a lot of the issues.

An ATMega processor can be set up to accept any pin as an interrupt, but unlike the 'real' interrupt lines, it can only detect a change of state on a standard pin. Consequently the programmer has to manage the state detection and pulse/cycle duration calculations. This was causing me headaches. My folly was that I believed the problem was all down to timing constraints, and tried several ways to improve the code.Nothing really worked.

Then I read some more and found timers ... with the pulseIn() function, measuring the spark pulse was a no-brainer ....

But there were still definitely timing issues with the reporting (I'm using Serial.print() to show the results on a terminal) and I found that when I upped the pulse rate to > 7000 rpm, the output routine was taking too long and the cycle was skipping a pulse. Consequently I had a rev counter running at 50% of the actual revs.

I eventually fixed that by sampling two pulses and the space between them ... A little extravagant, but now I can report up to 25000 rpm without a glitch and with accurate spark timing ... but I lose one pulse per sample.

A case of standing too close to the coal face ...

The reason for my obsession with sampling every pulse was caught up with the future need to manage every pulse when actually generating spark timing rather than reporting it. Consequently, I didn't recognise the evident fact that the timing generator would only be detecting a rotation pulse and flicking a pin about 2.5 to 48 milliseconds later ... so there would be no communication overhead in this case.

Happy bunny time ...

So now I have a working rev counter and timing reporter which can communicate the results faster than the eye can detect jitter on an instrument, and the plan is in place for the timing driver as well ....

... And finally I feel ready to start on some simple sensor interfacing and display drivers ...

It all started about a year ago

I guess the time has come to start to put out some of the things that are happening over here. I can't promise anything either riveting or even vaguely interesting, but I felt the need to document my progress on a couple of interrelated, 2 year, hobby projects that I'm currently playing with.

The first is the building of a Volkswagen Beetle-based hot rod which is intended as a present for my grandson when he's old enough to drive, and qualified (in about 10 years). For more of the history of the VolksRod with comments from others in the hobby, you can take a look at either of these two sites:
Volksrods UK
Keversite NL (mostly in Dutch)
but I'll also post the un-commented build thread in this blog as soon as I can get around to it.

The second project is the building, programming and installation of the car's electronic engine telemetry system, it's audio and entertainment computer, and in the long-term it's engine management system. For this side of things, I'll be posting here mostly, although I will probably make occasional posts on
Digital Car UK
A site which is well worth visiting if you are interested in in-car electronics.

I don't work very quickly, and I make a lot of mistakes along the way, but I'll share them, good or bad, and I do intend to finish, one way or another.

Along the way I may also post a few things I felt the need to jot down before I forget them, or maybe some random thoughts, a recipe ... I dunno ... really whatever is in my head at the time I guess ... but most of the time it will be my way of providing my grandson Joshua with a permanent record of the car build, , so if you're interested, drop in occasionally and see what's up.