Fakin' it (part 2)

This is part 2 of previous text, Fakin' it I wrote earlier. Previous text was mostly theoretical ideas, now after some more thought it's time for more in-depth look in signal analysis.

When doing theoretical work the detailed signal analysis always looks very tempting. Analyze incoming signal, detect some parameters (levels, period, duty cycle and whatnot) and if something is off you signal upper level that tampering is detected, stop everything!

Unfortunately, it seems that in many many vehicles the duty cycle of the signal isn't 50%, and it also depends on the speed of vehicle:

I remember some older MB, possibly C or E series, back when they weren't using exclusively CAN. Its signal wasn't your typical pulse train, but it was kinda sawtooth-ish; it rose at roughly logarithmic rate  (x millivolts per y milliseconds at low voltages where the threshold usually is) and was then pulled down (almost) instantly. As you can guess the duty cycle will vary wildly depending on the speed, as well as the average level of signal.

Another case; Some time ago I was doing diagnostic on an MB van as the pulse was completely gone (exact car model escapes me and is really not that important). Like so often, when I removed the panels so I could probe the incoming signal the problem went away so it must have been bad contact somewhere, but here the signal itself turned out to be more interesting.

As standard diagnostic I attached portable oscilloscope to the signal and drove a bit around (well, the car's owner drove, I monitored the signal). At the moment I didn't pay attention to specifics as I was still in full troubleshooting mode, but later I started thinking the details and realized its importance relating to this issue.

Firstly, the active period of signal was fairly constant, approx 5ms, regardless of the speed driven (granted, we didn't drive very fast - 50 km/h or so tops). This of course means that inactive period was changing. Additionally at slow speeds the inactive period was low and active period high; but when speed crossed certain threshold (I didn't pay enough attention to take note of exact speed but it was around 20-30km/h) that reversed; inactive high, active low. So this pretty much throws out duty cycle based tampering monitoring.

Now, although both examples I listed here were made by MB those are not only ones where these issues rise.

So, what we are left with? Pretty much all we have left is signal period (unless you want to implement some kind of manual configuration or auto-detection on signal features you wish to monitor; that is certainly possible, but I foresee so many problems there so I'd prefer to stay away from that particular can of worms. Just trust me on this.)
 
Next time; practical software example.