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.

Pick'n'place'd wrong

Well, it's been a while since last posting. I'm a bit short on ideas right now but maybe I'll think up something more interesting soon.

Now, on lighter note. Today electronics is typically assembled by large 'pick and place' machines, and they really are fascinating to watch when going at full speed. Sometimes of course accidents happen - components are dropped (although I think modern machines note this and place them again), components placed in wrong way (just slightly skewed, or rotated 90 or 180 degrees so at quick glance you won't notice anything wrong) and end result is non-working (or in worst case, burned) board.

As it happens, sometimes they get through the first inspection. This is why I test every single device I deliver myself before packaging it for delivery (volume isn't that high so it isn't too much strain). Typically defects aren't anything exciting - component missing, bad solder joint or whatnot. But sometimes they get... interesting.

Take your typical SOT23-3 package, pictured here. It has three leads and isn't even symmetrical. It should not even be possible to place it on board wrong, at least in a way that would pass visual inspection.

The device I had on hand failed one certain test, so I started checking the section of the board that might be responsible for the problem. I'll always start with visual inspection with microscope, and when passing by certain component in SOT23-3 package something seemed odd. I couldn't instantly figure out what, exactly it was so I picked the board up and started viewing it from angle. That's when I started to see it...

(No, it wasn't the board or component pictured above; picture here is simulated situation. And unfortunately not very good picture either, sorry about that)

Component was upside-down, leads pointing up from board and thus not even touching the pads. No wonder it didn't work right. I had to laugh for that (which immediately prompted dry "guess he found the problem" from next desk)

How? This specific board was flow-soldered, which means that every component is glued in place with a small dab of glue and then dipped (upside down, hence the glue - otherwise components would fall out) in molten solder which will solder all components. The problem with that technique is that sometimes some leads are left without solder which in real PITA - module passes all tests but then starts acting out several months after delivery when component shifts ever-so-slightly.

Oh, and after flipping the component over it worked perfectly, and for what I know the device is still in use somewhere.