Several years ago National Instruments approached me about designing a signal interface module for one of their clients. The client was developing next-generation 24V fan clutches for automotive cooling systems. The client had test teams in North Carolina and Michigan with LabVIEW-based test stands, with the data collection and control via NI Signal Conditioning Chassis (SCC) and modules.
The NI Signal Conditioning Chassis (SCC) system accepts modular signal conditioning modules that allow customers to mix and match input and output signal levels.
NI's client had two challenges. First, product development reached the point where the test software needed to provide direct PWM control of the 24V power to the clutches during testing. Second, they were already using all of the channels in their SCC system and wanted to avoid building a second data acquisition system to add this one additional feature to their test stands.
So NI asked if I could design a module that combines an existing tach input with a DC output module that could provide 24V PWM control at 2 amps and 2 kHz. The application was feasible because NI's SCC chassis provides access to multiple I/O channels per module slot. The application was interesting not only because of the need for 2 kHz PWM of the 24V, but also due to the requirements that the module maintain isolation between the test computer and the test stand while also dealing with the wide voltage range of the tach, which could vary from several volts at starting speeds to close to 90V peak at maximum engine RPM.
I prototyped the circuit using an NI Feed Through module. After I verified we could meet the specified functional requirements, I continued to the MVP below, a rapid prototype PCB that could go to the client for evaluation.
The client was very happy with the resulting modules and specified them as standard equipment for all of their product development test stands in both North Carolina and Michigan.
Jitter in the Tach Readings?!?
During one follow-up call the client casually mentioned being frustrated by occasionally erratic speed readings from the tach. I confess I freaked out just a little. I want my designs to ALWAYS work. A few quick clarifying questions revealed that the issue predated our module and it was simply that the module did not fix a problem that they had never mentioned to us. It turned out they had been trying for almost two years to resolve the erratic tachometer readings with software filters.
Just to cover all of our bases, I talked the test engineer into putting scope probes on both module input and output channels. We were able to verify the signal waveforms were identical other than scaling and voltage shifting, so my circuit design was in the clear. The client was unable to provide additional information about the jitter in the displayed speed.
After a follow-up visit to the client, our local support engineer called me and shared that the client was very pleased with the modules I designed. Always nice to hear. The client also demonstrated the tachometer speed reading glitch, showing scope traces for the tach signal input to the module and the conditioned output from the module. Our engineer shared that the waveforms matched when he watched the tach input signal trace moving up the oscilloscope screen, and our I/O module duplicated the same upward sloping waveform.
Something sounded off in his description, so I asked him, "Do you mean you saw the leading edge of the tach square wave?" His reply was, "No, it was not a square wave. We could watch the voltage rise smoothly as the voltage from the inductive pickup increased." Then bells went off in my head and I felt like we found the detail that would let us slay this dragon.
Slowly changing signals can wreak havoc on a digital or analog input, with any noise causing multiple transitions for what should be a single edge. The slower the signal, the worse the problem will be. But this type of issue is well-trodden ground with known solutions. Adding just a little positive feedback can add hysteresis to the system by creating separate thresholds for low-to-high and high-to-low transitions. Having two different thresholds can go a long way to prevent multiple transitions.
I suspected that the quickest solution would be changing to an optocoupler with a Schmitt-trigger input. A quick search through DigiKey turned up a chip that was signal-level compatible with my design, with a Schmitt-trigger input, but with a different pinout. It would not be a simple BOM change or drop-in solution, but I was excited to have a path forward. So I ordered a handful of chips from DigiKey for early AM delivery. The next day I showed up early at work and waited for the FedEx van to roll into the parking lot.
I quickly modified a module dead-bug style and verified the Schmitt-trigger input device worked with slow-moving signals on my bench. Next I called the client and told them I had an idea that might solve the speed glitch. They were very excited when I told them I could hand-modify a handful of modules for verification testing, and I should be able to get them in their hands by the end of the week.
A week later the engineer called, thrilled to tell me the signal glitches were completely gone. Not improved, just gone. For the first time in two years there were no glitches in their speed data, and for the moment, they had the only test stand in the world that worked properly for that product line. The client immediately ordered enough replacement modules to upgrade all of their test stands in North Carolina and Michigan.
One final stumbling block was that the client was reluctant to take their test stand offline to swap out the hand-built prototype modules. I did not want to leave those modules out in the wild and risk them being the source of future customer issues or support headaches. My solution was to offer to send three spare modules at no charge, but I would not ship them until I had the hand-wired prototypes in hand. The free spares were motivation enough to make the swap, and the prototypes were back on my desk by the end of the following week. Everyone wins.
Design Reuse
The Bidirectional DC I/O SCC module design actually proved quite versatile and ended up being used in several other automated test applications, providing power control, signal level translation, and my favorite being the solution to a couple of design challenges for a production test system for throttle controls for dual high power CAT diesel marine engines.
Quest for Excellence (and Learn from My Mistakes)
Engineers should embody a continuous quest for excellence and always be looking for opportunities for improvement in any process. Despite the positive outcome, in hindsight, I should have asked the client for screenshots of the input and output tach waveforms. A quick glance at the waveform shape and the scope timescale would have made it easy to compare the signal rise time to the spec for the digital input on the data acquisition card.
Dragon Slaying Hero
NI's client was a company hero for fixing the long lingering jitter issue with the tach sensor at slower speeds. I love it when something clicks from one of those early EE lectures or those hours of reading application notes and hands you exactly the tool you need to slay that dragon.