Continuing with troubleshooting the dead flow-meter signal converter (part one here).
Let me recapitulate the "status quo":
1) My Parker flow-metering solution is composed of three things - the SCM-150 display, the axial turbine flow meter with a variable reluctance pickup (resistance of the coil 3.5 kOhm), and a signal-converter board in between that stopped working, and no replacement could be found.
2) The SCM-150 display somehow recognizes the board when it is connected, reads the incoming analog 0...3.3V signal, and displays it in liters per minute in the respective range (in this case 0...600 l/min).
The next logical step was to gut the signal converter and see if I could figure out what it's made of. It took a lot of elbow grease to remove the potted PCB from the stainless steel housing. I was lucky they used soft silicone for potting and not one of those hard resin compounds. After about half an hour of poking with a sharp screwdriver about the housing (and wondering if I hadn't ripped something important off of the PCB) and a lot of pushing and pulling, I managed to free the board from the silicone trap. The potting silicone is a nasty and resilient substance, and it took a lot of patience to clean the sticky residue, but in the end, I managed to remove most of it and ended up with a relatively clean PCB ready for inspection and back-engineering:
What a beautiful last-century electronic design! Large SMD components with visible references, wide traces on a 2 layer PCB - in short - a reverse-engineer's heaven!
After a couple of hours of probing about the PCB with my multi-meter, studying it through a magnifying glass, and looking the component references up online I had the schematic lined up.
Let us stop for a second and appreciate the marvelous tools that we have at our disposal. The KiCad EDA alone - the software suite I use for electronic design - is a phenomenal tool, that is available free of charge. Free of freaking charge! And the internet makes searching for component data-sheets so-o-o easy. Once again - for free! I remember how my dad would collect dozens of thick books with information on thru-hole (at the time) electronic components, and now I have the global electronic component database at my entire disposal simply because I have an internet connection. Truly great times to be alive! A self-taught individual can do more than an engineering department twenty years ago, and that including the design and professional PCB production!
Here's the schematic of the board (pdf version here). No values for the capacitors, but the color-coded resistors were easy to id:
Let us inspect this design.
First, there's an op-amp based analog part (27L2AI), that converts the variable reluctance coil signal into logic level square pulses. Today I would probably go for a ready-made VR sensor signal conditioner IC, but the engineers who designed this board used a clever combination of two operational amplifiers for the purpose. Since they used an 8 resistor network IC (and a huge one) I first drew the schematic with 8 10k resistors, but in case you are interested, I also drew a better representation in the middle of the diagram that shows how the op-amps are connected.
Then these pulses are fed into the AT89C2051 microcontroller, a beast of computing power that boasts 2K bytes of program memory and 128 bytes (!) of RAM. The fact that the VR sensor pulses are squared and then fed into an MCU means that the frequency to voltage conversion is done digitally. Well - I agree with this solution, that's how I'd do it. There's also a 128 byte EEPROM chip next to the MCU. Maybe it's used to store a linearization lookup table or some other parameters that didn't "fit" into the MCU? Another thing - the crystal oscillator has a frequency of 11.059 MHz. Someone was looking for standard baud rates, maybe?
Next stage - signal output. The MCU is connected to a 12-bit 2.048V (0.0005V resolution) digital to analog converter - (LTC1257), which in its turn feeds an output stage op-amp with amplification of 1.56, which neatly turns 2.048V into 3.19V - exactly the range we need.
Power management - there's a 5V voltage regulator (LP2951) with error monitoring, resetting the MCU when something's not right, and there's also another switched capacitor voltage converter (LMC7660), which is used to provide negative voltage for the output stage op-amp (most likely to ensure stable 0V and linearity).
Finally - there's a very interesting external 12.4 kOhm resistor:
This resitor is connected as a voltage divider in combination with another SMD 12.4k resistor mounted on the PCB, that is connected to the 5V rail and the divided voltage is fed into pin 5 of the 5-pin board connector - Aha! So this is how the sensor recognition is done (nothing new here, by the way - a lot of "smart" sensor recognition systems are based on this simple principle, sometimes, maybe, adding an internal resistor in the "recognizing" part of the hardware to make things a little bit more complicated for "hackers" like me).
To test my sensor recognition theory I connected a couple of potentiometers to the SCM-150 display, and sure thing - made it cycle through all types of sensors and ranges (pressure, flow, rpm) as I changed the voltage on the sensor recognition pin. Simple.
OK, I didn't id all of the passives, but the principle of operation was crystal clear - and I was certain that the malfunction was caused by an issue in the power managing or the analog part of the board.
The first commandment of troubleshooting any electronic device is, of course "Though shalt check voltages". So I verified the input voltage coming from the SC-150 - 9V, OK. Then the 5V rail - OK, the voltage regulator error pin value - OK, the negative 5V rail - OK. Hmm... The power's all good... I wonder if one of the op-amps failed?
Checking the input analog stage showed no errors as well. Just look at these beautiful shots! (Channel one is the signal coming from the VR sensor, channel 2 is the first stage of the op-amp, and channel 3 is the second):
You can clearly see how the VR sensor's typical signal shape is transformed into nice-looking square pulses. By the way - the filtering is very low frequency. the minimum frequency it can read is about 9 Hz and at about 1.6 kHz the square spikes become triangles and too low to be recognized by the digital input of the MCU. This means that I got the frequency range in the right ballpark. Also - the op-amp solution "catches" the zero-crossing of the VR sensor very precisely (no that this is important for this particular application, but still - great job whoever designed and implemented this solution).
Anyhow - since, apparently the analog part, at least at the input side was OK - I decided to check the digital and see how the MCU was communicating with the EEPROM chip and the DAC.
First I checked the crystal and did see a steady 11 MHz sine, so the clock was ticking. Then I checked the 2-wire serial data lines and discovered that the MCU only reads from the EEPROM when it powers up. It actually only reads 29 bytes, and for some reason, it does it twice in a row, with the byte at the address 01 being read 6 times. I wonder why they included this routine. For redundancy, maybe? I didn't manage to make any sense out of the 29 bytes though. Anyhow, this meant the MCU worked.
OK, now, then maybe the DAC chip died? I decided to look at its communication lines. A quick look in the datasheet revealed that the LTC1257 needs three wires (serial clock, data-load, and data-in) to communicate with the MCU and uses a simple serial protocol. So, I checked the lines and... Wa-a-ait, this can't be right... While I saw perfect 12 pulses in the serial clock line, which is exactly what is needed to communicate a 12-bit value, and then another negative pulse in the data load line in the end - I saw zero pulses in the data-in line. It was always low (with the turbine pulses, obviously, coming in):
Impossible! A single MCU port pin can't fail! Maybe there's a short in the DAC and it's pulling the data pin low? So - I removed the DAC and re-checked the data pin - and again saw zero communication. Hmm...
This was the worst-case scenario. Any analog failure of this board could be easily fixed by replacing components, pretty cheap components I might add. But to replace an MCU one needed a program as well.
Just to double-check my current theory - I removed the MCU, soldered the DAC chip back onto the board, and then blew the dust off my old Atmel development board, connected it to the DAC - and threw together a piece of code just to bit-bang the DAC protocol to see if the chip was working, and... yes, sir! The LTC1257 was perfectly operational, as well as the output op-amp stage. Hurray! Oh, wait... I am screwed now, aren't I?
Despite all the odds - the MCU failed on a single port pin, so what was it that I could do? Theoretically, I could still check if the OEM didn't program the fuses to prevent "intruders" like myself from downloading the code from the MCU, and simply copy the program, but first of all - one of the port one pins was, apparently, dead - and since this old MCU needed the complete port to read and load the program - I would most likely be throwing away a lot of time and effort, and second - where's fun in that?
My best bet would be finding a modern replacement for the outdated 2051, with an in-system programming of course, and then write a program to measure the frequency of the pulses, and then transform it (with linearization, obviously) into a 12-bit value sent to the DAC. Now, this sounds like a fun project, does it not?!
Googling for an "AT89C2051 replacement" revealed that, pin-for-pin, the ATtiny2313/4313 MCUs were exactly what I needed. The power and the crystal oscillator pins were the same, so I could simply drop the ATtiny on the PCB and it would work. The reset pin of the ATtiny was "the other way around" though, i.e. "pull low to reset", so I would need to change (or simply remove) the 5V regulator error monitoring that resets the MCU when there's an error, but that's an easy fix. In all, it seemed that I found the perfect replacement!
So, the action plan is the following:
This is exactly what I will be doing in my next post!