Well, I'm a software engineer (java, c#) with basic elektronics skills.
I'm from Holland and driving CRX for more the 6 years now.
Software is my profession/occupation, elektronics is just a hobby.
Let me explain my path so far....
I wanted to have the S2000 cluster in my car and I wanted to do it al by myself. Just buying a converter was TO simple and not challanging. So I started investigating signal specs. And found out that the VSS signal was about 36 times faster than the 'traditional' vss signal. So I started thinking about how to multiply the signal.
There were some different possibilities.
1) f/v -> v/f converter with some pot-meter to set the 'multiplier'
2) PLL and
divide the feedback by 36 (using some counter IC)
3) MicroControler
Because I wanted to learn how to use a microcontroller, I decided to choose that track.
PicBasic was a very easy language to start with and to get a first understanding.
So I started with PicBasic and a simulator just to get a first impression. Started with some blink LEDs (the "hello world" for MicroControlers) but when time passes, I went further and further. Playing with interrupts, LCD and the on-board 10bit ADC.
I started with the philosophy of 1 pulse in, 36 pulses out. I recognized that there were two ways to do this. In 7k5 Hz (so Vmax is 300km/h) bursts or with some sort of pulse-width calculation. First I created the one working in bursts.
When a rising-edge is detected on RB0 (INT) this will cause an interrupt and going into the ISR.
During the ISR I add 36 to variable 'pp' (pending pulses)
When not in the ISR I loop through some 'led blinking code'
Code:
WHILE 1=1 ; stay in the program. Don't make it stop (it's not a one shot solution)
WHILE pp > 0
PORTB.1 = 1
DELAYUS 67 ; (1 / 7500 = 133us) and we wait just half a pulse width as we do the same waiting twice.
PORTB.1 = 0
DELAYUS 67
pp = pp - 1 ; done a pulse, so one pending pulse less.
WEND
WEND
After that I dicided to play around with the timer to measure the incoming pulse width and store it to variable 'ipw' (input pulse width).
I used this to determine how much time I have to generate the 36 outgoing pulses. I also realised that this measurment needs room because when accelerating the time left is shorter then measured!!
To prevent getting behind to much, was pretty easy. Because I was using the pp variable I was always aware of how many pulses were pending. I was also more or less aware of the pulse width to be expected. I introduced a simple calculation for this. opw = ipw / pp (opw = ouput pulse width)
In the simulator this turned out to be a very nice solution. There was a chance to get behind 36 pulses at most.
So I build a first version of my elektronics on a breadboard (with 2 LED's to check input and output signal), programmed the microcontroller with the software which takes the pulse width in consideration and did a first test on the bench. First thing that surprised me was that (for the human eye) the input and output led were flashing at the same speed. I checked the reading on the S2000 gauge. FINE?!?! WTF?!?!?!? That the reading on the S2000 gauge was fine, was to be expected as per my theory of 1 pulse in, 36 pulses out, but the output led should be constantly on (as per the human eye)
(As you can see in my YouTube account a did this first bench test on january 15th, 2008 )
But why were the input and output leds were blinking the same way, and how come the s2000 gauge still did what I expected it to do?
Well... what I didn't realised up to this point, and which is a beginners mistake, the 16 bit timer of a microcontroler roles over every 65,535 clock ticks. Because I'm working with a 4MHz X, this turns out to be every 16ms. And because of this, the opw is more or less random from 0 to 440us (16ms / 36 pulses). So the PIC is pulsing in bursts with some random pulse width. But... because the S2000 readings were fine, this proves that pulse bursts arn't an issue for the gauge.
I took everything (with the pw calculating software version) into the car and went for a spin. Readings where fine... up to about 70km/h. At that point ipw = 20ms so the timer is still rolling over, causing burst output behaviour. So this can't be the issue.
Then at some point I desided to speed up the car to 130km/h and turn the engine off while letting the car roll in neutral. Damn.... readings on the gauge were perfect again (see spy movie) so the software also proved itself on higher speeds. 130km/h is 80 MPH.
This is the point where I am now. There most be noise of some sort on the input or the output of the PIC.
The past few days I did a lot of thinking about the way I wrote my software. (not that it is causing trouble though) I realised I have concentrated to much on the 1 pulse in X pulse out theory. I did some playing around with pulse witdh, which turned out not to work as intended. So at the end... nothing was done with pulse widths. I didn't concentrate on straight forward pulse width calculations and forget about numbers of pulses. I was too much focused on losing or adding pulses to the output, being scared the ODO / trip counters would not do what I want. Now I know better. This is what is called... Tunnel vision. And also probably a beginners mistake?
Ok.. in the next software version I want to do it that way. But because my timer roles over every 16ms I need to slow it down or need to write additional code to extend the timer from 16bits to say 32 bits. At least it should be able to measure 1.4 seconds as that is the input pulse width when driving 1km/h (less then 1MPH)
But it shouldn't be slowed down to much, because that potentially can cause problems when driving faster. *does some calculations*
Ok... I want at least one tick every 5ms (So that I'm able to measure 180MPH) and a rollover time of atleast 1400ms.
When slowing down the timer 128 times, it will be within this limits. It will rollover every 2.1 seconds and will tick 256 times in 5ms.
I also need to think about freeing up some processor time, as the DELAYUS function just freezes the programe for that amount of time, while I also want to do an ADC measurment for the ECT
Let me think about that one too....
My CRX has a reed switch type VSS which connects to ground. So the input (RB0 used as INT) is connected to the VSS with a pull-up resistor to +5V. So for me there was no need to use an opto-coupler. Although it would be way more elegant!
The output to the S2000 gauge is straight to RB1. On the bench this works fine up to 300km/h (180MPH).
In the car it also works fine, as long as the ECU is turned off. But no ECU means no power. GRrrrrr
It's for sure that there is noise of some sort at the input or output. (input most likely I think)
Possible suspects... Alternator, distibutor/coil, ECU
Past few days I did some playing around to find the cause of the noise.
When driving 130 turned the engine off while in neutral. Result: readings were fine!
When driving 130 turned the engine off while in 5th gear(keeping the engine and thus the alternator rotating) Result: readings were fine!
Conclusion so far... Alternator isn't the problem. ECU and distributor/coil remain suspect.
I planned to do some scope measurments tonight on the input as well as on the ouput. Hopefully I'm able to find something.
But about the ECT stuff.
I had my function generator setup to produce a 50% squarewave from 0 to 5V. Started with 60Hz. Noting. After 1 minute (gauge refreshes every 30 seconds) I went to 100Hz. Nothing. 500Hz... nothing... and so on (500Hz steps). Up to 4000Hz. Then suddenly I got a full scale reading. But nothing in between.
I have to admit that I don't have put to much effort in the ECT thing yet. I want to solve the VSS converter first.
So this is my story so far.
