Trying to make sense on how to read low frequency odometer signal

Projects General Guidance
1

Trying to make sense on how to read a low frequency odometer signal.

Ahh, but it is NOT a beautiful 50% duty cycle pulsed TTL signal !!!

The signal is awful PWM signal that changes frequency a few times generated from this inductive ABS wheel sensor. What my understanding is the Pulse-Width is accurate.

What I am trying to do is to read-in the pulse-width and generate 50% duty cycle output of the same pulse-width.

The head scratcher for me is at a few Miles-Per-Hour the pulse width is in the 70% to 90% of the period, so I do not have time to generate my "50% duty cycle" before the period ends, so I guess I need to wait to the next cycle to get another reading, but at higher Miles-Per-Hour's the pulse width is 5% to 10%, and I have the space(the time) to output half-dozen 50% duty cycle pulses before the next period.

The reason for generating 50% duty-cycle output is the revised updated instrument cluster is looking for nice TTL signal with 50% duty cycle, and this revised cluster is available all day used for $50-$100, yet the identical original instrument cluster is around $1000 USD for old 20 something-year-old instrument cluster. When the value of the car is two to three times that, sad condition . I'd settle to fix the old cluster, but the traces on the PCB are all painted, so no reverse engineering here....

The revised cluster uses the 50% duty cycle signal with the same pulse-width as stated in the service literature of the car, and frequency conditions are: 5mile/hr =50Hz, 50mile/hr=500Hz, 100mile/hr=1000Hz, and the cluster goes up to 160mile per hour, but I'd be happy if it can only make it to 80miles/hr or 100miles/hr

The moral of the story is never try to get "cute" with a family member that you help them/ recommend a used car, so I'm a bit of a rock and a hard spot to figure this out as the car will not be able to get it registered for road use in the "Union of Kalifornia" in the good-old-USA....

Looking for snipits of code! Maybe someone has done a low frequency counter where the width is used for a counter! I was eyeing the PulseIn command, but it has some "flea's" for my purpose or is it possible?

Can I do this with a Nano or a Uno board?

Thank you,

Martin

2

The requirement for 50% seems odd. If you have a positive edge, how do you know how far away the next positive edge is going to be? You can't predict the future.

If it doesn't work on the raw signal, I would first try inverting the signal. If it doesn't like 70% high maybe it will work with 70% low. Do the experiment rather than just reading the book.

3

Hi,

Have you googled to see if someone else has tried to do what you are doing, like automotive forums.

What make and model are the two incompatible cars?

Tom... :slight_smile:

4

@MAVA, can you make a drawing showing the type of pulse you are trying to read? How does it vary between low speed and high speed?

...R

5

What I am trying to do is to read-in the pulse-width and generate 50% duty cycle output of the same pulse-width.

So basically, you need a PWM to square wave converter. The output square wave frequency = input PWM frequency. Internally, the odometer's electronics would only need to measure the pulse width to get pulse rate (speed) and pulse count to get distance travelled.

Can I do this with a Nano or a Uno board?

I don't see why not. 16 million MCU cycles per second should be more than enough.

Can the vehicle's system tolerate if the square wave signal to the odometer has a single 1 or 2 cycle latency?

Rephrased, can the square wave appear at the odometer 1 or 2 periods late meaning there's never more than 1 or 2 count error?

I'm not talking about jitter ... just a consistent 1 or 2 count error, 1 or 2 periods of latency, dictated by the design of the converter (code).

6

Thank you all for your replies.

Morgan,

The revised cluster works beautifully with a 50% duty cycle as I have made the revised cluster work on a function-generator.

Tom,

What people have done is bought a old used cluster. Lived with no Speedo/ Odometer, and for those who live safety tests, or emissions testing have junked the car as I have read about. No one has done what I am doing as I service these cars no-one else can service. The factory dealers cannot even service them as the new mechanics are not tought these old cars. I'm glad I have a electronics knowledge, and wet to school for this as that is what it takes.

Robin,

I have scoped the signal, and got nothing at first because it is coil changing impedance. It is not a reed switch, so only until I built a bias voltage circuit with a few transistors, and I thought I could easily tie the revised cluster to my circuit, but it was a no go after my circuit. I tried to invert the signal too, and that was a no go. This is the reason why I need a 50% duty cycle signal. Sadly, I have a CRT type scope, so I cannot do a ride along to see the signal at all the speeds. What I did do is put the rear wheels on jack-stands to read-off the speed signals(and by the way the documented literature says to spin the left front wheel when the transmission has the sensor-clearly this wrong for rear wheel driven car).. My findings indicate the right rear wheel generates this signal, and on this car I can spin the wheel with the transmission being in park, so the literature is dead wrong as to where the sensor is..

Dlloyd,

Yes a PWM to TTL with 50% duty cycle. I tried putting a square wave to the revised speedo and the needle just hums in place. I guess missing a pulse or two should be okay

My wisdom to all is never buy a 90-93 R129(model) Mercedes with a speedo problem, or a Infra Red door lock problem. You will spin your wheels. I restore these cars for people-Paint-rebuild the electronic transmissions-etc... These early to mid 90's Benz cars had engine wiring problems. Those problems are so easy to fix compared to this design flaw of the speedo. The +94 cars came with this revised speedo that took in a nice TTL 50% duty frequency signal, yet the flagship model of Mercedes (S-Class-W140 model) all came with TTL 50% duty cycle instrument cluster. The R129 was the last of hand-built cars, and the latest hand built is SLR they made a handful of years ago. With any hand build item is differences.

Look at this thread of my problems, but my last post has the diagram, and the testing procedures(which is wrong).

Martin

7

MAVA:
Thank you all for your replies.

Morgan,

The revised cluster works beautifully with a 50% duty cycle as I have made the revised cluster work on a function-generator.

Great! So how far away from 50% can you get before it stops being "beautiful"?

8

MorganS:
Great! So how far away from 50% can you get before it stops being "beautiful"?

The whole PWM signal is ugly once it comes in contact with one the transistors-Spiky/Noisy. I have managed to calm the noise with some small ceramic capacitors, and by the time it passes the last transistor the PWM is relatively clean. I may need to pass it through a Schmitt-Trigger chip later, but it good enough to pass through a CPU for processing.

Martin

9

In this process, I will use a Servo PWM generator code that does not use the servo library, so I can shorten the higher frequency, and lengthen the slower pulse width. Also vary the period too.

That will be on a Arduino Nano as my source, so I'm not doing this in the car...

Play with the PulseIn command and I guess Arduino does not have a pulseOut command like Proton Basic?

Thanks, and keep it coming..

Martin

10

Hi,

MAVA:
The whole PWM signal is ugly once it comes in contact with one the transistors-Spiky/Noisy. I have managed to calm the noise with some small ceramic capacitors, and by the time it passes the last transistor the PWM is relatively clean. I may need to pass it through a Schmitt-Trigger chip later, but it good enough to pass through a CPU for processing.

Martin

Have you tried putting a clean pulse into the cluster with a different duty cycle, not your cleaned up inductive signal?
You seem to want 50%, but have you experimented with 10% or 90% duty?
Tacho circuits use pulse edge detection to measure frequency hence speed.
Thanks.. Tom.. :slight_smile:

11

MAVA:
Robin,

I have scoped the signal, and got nothing at first

I was not looking for anything as sophisticated as an image from a 'scope - just a hand-drawn estimate.

But, if you can't get a scope image maybe you don't actually know what it looks like. In that case it is a bit like shooting pheasants with your eyes closed.

Would there be any value feeding the signal to a schmidt trigger IC to tidy it up?

Or, perhaps it is a signal that is intended to be analysed as an analog signal after some (unknown?) filtering?

...R

12

I'm guessing that what you have is a variable reluctance sensor, effectively an AC current generator. Not sure why you wouldn't see a signal across the wires with the scope, but maybe it needs a load resistor across the leads. If so the output voltage might look like anything from alternating positive and negative spikes to a sine wave depending upon the speed. In any case, I would think the parameter you want to recover is frequency as "TomGeorge" suggests above. A sketch or a photo of the waveform you're looking at would be helpful.

13

TomGeorge:
Hi,Have you tried putting a clean pulse into the cluster with a different duty cycle, not your cleaned up inductive signal?
You seem to want 50%, but have you experimented with 10% or 90% duty?
Tacho circuits use pulse edge detection to measure frequency hence speed.
Thanks.. Tom.. :slight_smile:

I tried the revised cluster after my little transistor circuit at 5v and at 12v the needle just just sits there humming away no mater the speed, yet I tried this cluster on the generator with 50% TTL signal after that test(to see if I did not blow it up), and it works great with generator, so that is the reason why! I too figured it would be edge triggered.

Martin

14

Robin2:
I was not looking for anything as sophisticated as an image from a 'scope - just a hand-drawn estimate.

But, if you can't get a scope image maybe you don't actually know what it looks like. In that case it is a bit like shooting pheasants with your eyes closed.

Would there be any value feeding the signal to a schmidt trigger IC to tidy it up?

Or, perhaps it is a signal that is intended to be analysed as an analog signal after some (unknown?) filtering?

...R

Robin,

I get nothing on the scope if I connect the leads to this isolated signal, so I need to provide a bias of some kind to turn this pulsing mechanical signal into something...

Yes, the signal is processed through the the dead old instrument cluster, but I have gone that route to try to measure some voltage, and get zero volts/ nothing...

Now, Mark may have a point, and that I have not tried to place some resistance across this sensor/switch, and to scope it...

I will have to get the car on the lift, and take some screen shots, and post it on the Mercedes site, so you see the pulses if available with the resistor only, or after my two-transistor circuit.

Thanks,

Martin

15

if you time the leading edge of two signals, then create a square wave that is half of that, you should be in the ballpark.
latency of a few millisecond on a gauge is often acceptable. take the last two if you like. as a note, nothing in a car will change state faster than your sensor can watch and control.

16

Couldn't find any examples of a PWM to square wave converter, and I see you have been working at this for quite a while, so I thought I would create a sample sketch to try.

This does not use interrupts (polling method).
Debounces both edges of the PWM input (pin 2).
Creates square wave output on pin 13 with frequency = PWM frequency.

To use the built-in PWM generator, connect pin 10 to pin 2.

PWM input width is 3.9% (duty=10, 8-bit)

PWM input width 96.1% (duty=246, 8-bit)

const byte pwmInputPin = 2;
const byte squareWavePin = 13;

byte recordingInterval = 10; // for testing 70µs stability in recordedState
unsigned long recordingTime, pwmPeriod, timeNow, prevPwmTime, pwmCount = 0;
byte recordedState = 0xAA, inputFlag = 0xAA, prevInputFlag = 0xAA;

void setup() {
  pwmBegin(246); // 61.04Hz PWM, range for duty is 1-254
  pinMode (squareWavePin, OUTPUT); // pin 13, square wave output
  pinMode(pwmInputPin, INPUT_PULLUP);
}

void loop() {
  timeNow = micros();
  if ( timeNow - recordingTime > recordingInterval) {
    recordedState = (recordedState << 1) | digitalRead(pwmInputPin);
    if (recordedState == 0xFE) inputFlag = 0;
    if (recordedState == 0x01) inputFlag = 1;

    if (inputFlag != prevInputFlag) {
      if (recordedState == 0xFE) { // input just went low
        // code here if needed
      }
      if (recordedState == 0x01) { // input just went high
        pwmCount++;
        pwmPeriod = timeNow - prevPwmTime;
        digitalWrite(squareWavePin, HIGH);
        prevPwmTime = timeNow;
        Serial.println(pwmPeriod);
      }
    }
    prevInputFlag = inputFlag;
    recordingTime = timeNow;
  }
  if ((timeNow - prevPwmTime) >= (pwmPeriod / 2)) {
    digitalWrite(squareWavePin, LOW);
  }
}

void pwmBegin(unsigned int duty) {  // for self-test, connect pin 10 to pin 2
  TCCR1A = 0;  // TC2 Control Register A
  TCCR1B = 0;  // TC2 Control Register B
  TIMSK1 = 0;  // TC2 Interrupt Mask Register
  TIFR1 = 0;   // TC2 Interrupt Flag Register
  TCCR1A |= (1 << COM1B1) | (1 << WGM10); // OC1B (pin 10) toggles on compare match
  TCCR1B |= (1 << WGM12) | (1 << CS12) | (1 << CS10); // 1024 clock prescaler
  OCR1B = duty;
  pinMode(10, OUTPUT);
}
17

For the odometer function, here is one workaround:

18

Thank you all for your replies. I'm spending way too much time on this, and i found someone can fix this cluster for a few hundred dollars...

Martin