Category: Analog Electronics

Design Improvements on Versatile Turn Signal Flasher

We had turn signal flashers that that would misbehave from time to time, varying wildly, even though the math said it should work properly.  I investigated.

It turned out that the supply to the main timing IC, a bipolar 555 timer, was reliant on the drop across the turn signal flasher… which itself varied as the turn signal flasher turned “on” and “off”!  It was shorting out its own supply, essentially!  Oh boy.

I developed a circuit that would allow the 555 timer to still drive the monster output transistor, the TO-3 cased 2N5301, but hold the IC’s supply during the “on” time.  There were two problems with this – the circuit consumed too much current to be reasonably held up during the “on” time, and the output turned out to be referred to the wrong rail, in order to drive the output transistor using the same mechanism as before.

I addressed the current consumption by switching from the bipolar 555 timer to the then-relatively-new Intersil CMOS ICM7555.  What a joy that it ran on almost no current!

Then, I developed a 2-transistor output drive to replace the 1-transistor stage.  It worked well, until we ran it over temperature.  It was then that I learned one of the fundamental lessons that I’ve taken through my entire career: do not rely on one transistor to “short out” second transistor’s base drive over temperature!  It turned out that the Vce(sat) of the first transistor could exceed the Vbe(th) of the second transistor, sometimes, at low temperatures.

I found that you can short out the second transistor’s base drive, but then you need to put a resistor to the second transistor’s base, just to make it that much harder for the second transistor to turn on with leakage.

Well, that was a lesson learned, but then I just redesigned the stages to avoid that problem altogether.  Once bitten, twice shy!

I did do some preliminary work on using a MOSFET output on the flasher, but I couldn’t make the short-circuit protection work, and decided to stick with the bipolar output.  Later, a colleague, James White, took up that effort and successfully developed the “FET flasher”, which was another step forward turn signal flasher design.

Implement Statistical Process Control for Versatile Turn Signal Flasher

Inspired by early instruction on statistical process control, I noted that we had ongoing continuous problems with the turn signal flasher flash rate and duty cycle.  The flasher does two rates – turn, and hazard.  To meet the SAE J590, there rates each have minimum and maximum rate limits, but also a minimum and maximum ratio between the two rates.  We had constant ongoing high fallout rate on the production line, something like 30-50%, and were having to change component values continuously.

First, we did a process study.  We took 33 units off of one batch and carefully measured their characteristics.  When we analyzed them, to our surprise, we found that, although the spread of the rates was too wide to meet our requirements, it wasn’t that wide of a variation – it was primarily the process mean that was far off.  The resulting Cpk did not perfectly meet our requirements, but it was close enough that we could improve our results considerably!

I undertook a careful analysis of the results of the study.  I determined that changing the timing capacitor and resistor values, and using higher precision parts, should bring the results into J590 acceptable limits.

We ran another batch, and to our delight, almost every unit passed.

After that, I was still called upon periodically to address characteristics going outside the limits, but it was far less often.  We found that often, this was as a result of batch-to-batch variations in the ICs or capacitors.

Developed 36V Signal Flasher for Can-Car Rail

James White redesigned the “standard” 12 Volt turn signal flasher to use a MOSFET output, then he modified the design to successfully run on 24 Volts for bus & truck applications.

At about the same time that James was doing this, Can-Car Rail approached us to develop a 36 Volt flasher for their rail coaches.  I thought it would be easy!  Whoops, not so fast…

Well, oh my Lord, 36 Volts DC is nasty.  My first attempt to just use my modified 12 Volt design was a complete disaster.  The three lead-acid car batteries that we used for development just provided so much power that the 2N5301 output transistor overheated and failed on the first flash into a short.  The 12V and 24V designs could flash into a short indefinitely (Ed Van Humbeck drove around with a flasher wired directly across his car battery for about 6 months in 1980/1981 to prove that it could easily handle it).

The FET Flasher didn’t perform any better.

Instead, I had to develop a completely different design, right from scratch.  I used some of the same concepts, although I had to change components – the 2N5301, for instance, is only rated for Vceo to 40V, so it had to be changed.  The supply to the 555 timer had to be modified to handle the high voltage.  The drive stages had to be changed to handle the voltage translation and the drive requirements of the new output transistor.

The biggest change was that the 36V flasher got a “ground return connection”, which allowed it to be constantly powered, instead of having to scavenge the operating current from the bulb current.

We had to change the mechanicals as well – the original 12V and 24V flashers were simply placed into a plastic cap along with a heatsink/mount made of a piece of bent & punched aluminum, then the cap was filled with epoxy.  The But, like all challenging designs, it was 36V flasher needed much better heat dissipation for several devices, so it was designed as a flange mount device, a circuit board mounted on top of the “W” shaped metal mount, then covered with a lid.

The design was a challenge, the result was a success, but we didn’t make many units – perhaps a few hundred.  But, that’s the difficulty – you can’t tell ahead of time, what will be a winner, and what will be a loser.  You just have to do your best, and take on the ones that look reasonable.

Developed Fuse Panel and Turn Signal Modules for Ford New Holland “P53”

Ford New Holland had purchased Versatile Farm Equipment, brought some new products to the plant, and Vansco was providing much of the electronics that went into all of its tractors.

A new tractor was being made, which at the time was called “P53”.   It needed a power distribution panel / fuse panel and turn signal flasher.  I suggested that it could be a monster printed circuit board, and was asked to make it happen.

To accommodate differing standards worldwide, the turn signal flasher was a separate, small circuit board that plugged into a connector in the middle of the board.

Meanwhile, the main board was developed to fit inside one of the vertical window pillars.  It was physically large surface area, and had a large metal bus bar down the middle to distribute power to the fuses.   Of course, it had monster copper on it, 2 oz, and wide tracks, to ensure long life.

Implement IRIG-B Decoder in LINUX and on EFM8UB2 Universal Bee

I’ve been advised that one of the biggest challenges in the installation of power utility relays & recorders can be the setup and configuration of the IRIG-B time code distribution.

If there was a small, inexpensive hand-held device that could read the IRIG-B signal, and tell us all its characteristics – modulated/unmodulated, true/inverted, IEEE-1344 extensions active, time zone, offset, and other information – then it would be easier to diagnose the problem and tell the customer what they have to do to get the time sync to work.

I did a search and could not find anything… so after playing with decoding IRIG on my LINUX computer, I bought my own EFM8UB2 Development Kit and proceeded to write a decoder for it, per my blog entry.

The challenge now is to do a user interface for it.  I can easily do a LINUX UI (and did!), but what would be really cool is to (say) have an Android app that could connect to the EFM8UB2 using USB OTG – and display the data there.

I actually go the full Google Android SDK and emulator up & running, and was clicking along, learning the development of Android apps, but then along came Eye on the Ice – which took all of my spare non-work hours time.  One hobby at a time!  I’d like to return to it, and finish, some day soon.

LoRa Proof of Concept for Eye on the Ice In-Ice Sensors

After the disappointment of the Z-Wave implementation of an in-ice sensor for the Eye on the Ice system, Filipe and I did a survey of other RF communications technologies, and settled on LoRa, per this blog entry.  After evaluating several modules and then obtaining a few more, we settled on the AcSip S76S system-on-a-chip, which contains an STMicro STM32L073RZ Arm-Cortex M0+ MCU and a Semtech SX1276 LoRa Transceiver.

If used in the more-popular LoRaWAN mode, it is similar to Z-Wave, but has much longer range.  However, there is also the less-sophisticated LoRa mode, where there is no inherent mesh networking and a much simpler simplex protocol, which is what we are using for our second proof-of-concept.

We’ve increased the battery size to a CR2450, giving us 600 mA-hr, much more than the approximately 230 mA-hr of the CR2032.  However, in order to maintain decent RF antenna operation, we’ve had to split the device into two interconnected boards, complicating the design.  We’re currently evaluating the performance and reviewing further options.

In any case, it sure seems like we can get much more consistent operation at up to 250 ft, with the correct dimensional parameters, even in 32 mm diameter size.

Z-Wave Proof of Concept for Eye on the Ice In-Ice Sensors

As outlined in my blog post about Modern RF Communications Modules, around 2008, my team at Norscan developed the Eye on the Ice system for Hans Wuthrich, Master Ice Maker.  It is a great system, and still works well.  Unfortunately, the Linx FHSS modules have gone obsolete.   For the moment, inventory is available to support the relatively small runs of production.  But, over the long haul, things will have to change.

In the meantime, Hans wants a small, low cost, perhaps disposable, in-ice sensor that could be used to accurately monitor ice temperature from several points of the rink.  He had an engineer doing some experimentation in this area, but since the frequency is 433 MHz, the FHSS module and it antenna are quite large, it was difficult to get it down much smaller than, say, 50 mm x 50 mm with a 150 mm antenna sticking out in one direction or another.

With a former colleague and friend, Filipe Fernandes – analog, RF and EMC developer extraordinaire –  we developed a proof of concept that met the requirements.  Battery operated from a single CR2032 cell, and only being about 32 mm diameter x 10 mm thick before enclosure, it used Z-Wave to send the temperature to a Raspberry Pi that had both a Z-Wave controller and an FHSS module attached.  The Raspberry Pi operated as a gateway, relaying incoming temperature reports into the Eye on the Ice network.

Although the system worked, we had issues with repeatability in manufacture, causing trouble with range.  One sensor was able to report from over 80 feet away, another from only 20 feet away.  We addressed this issue, but then had trouble with battery life.  It seems that the automatic operation of the Z-Wave protocol causes a sensor to continuously retry if it doesn’t get an acknowledgement from the controller.  We were sure that there was a way to deal with this, but the lower levels of the protocol and operation of a mostly-sleeping sensor were opaque and difficult to figure out.  It would have been time-consuming (and therefore expensive) to resolve these issues, so we abandoned the Z-Wave system and sought an alternative.

Per this blog entry, we found the solution in the form of a LoRa system.

Preliminary Proof of Concept Work on ERLPhase Fault Location Algorithm

The very cool thing about sigma-delta conversion is that there are trade-offs that can be made with the data after it is captured – sampling rate versus inherent filtering versus resolution versus noise floor. These are all inter-related.

ERLPhase wanted to investigate travelling wave fault location. Technicians captured mock fault data in the lab, which I modelled in Python, performing analysis on the frequency content, and various processing techniques. I developed a proprietary front-end amplifier in LTspice, then implemented the circuit on a proof-of concept PCB. I wrote Python scripts to import the fault data into an Arbitrary Waveform Generator (often called “an ARB”), and played them into the new board, captured the data on the sigma-delta modulator evaluation board, post-processing the captured data in Python (including wavelet analysis), and displayed the results graphically in 2-D, 3-D and colour plots.

I wrote a report on the effort, providing details and outlining the path of product development.

Develop ERLPhase 2nd Generation DC Analog Isolation Module

The original DC isolation module, developed under my direction around 1999, used an unconventional custom off-line power supply and four Analog Devices AD204 isolation amplifiers, to provide isolated voltage and current input from DC to about 1 kHz.  This opened up a new market for recording sensors and telemetry signals on the TESLA, as well as some unique DC-level-sensitive AC applications, such as internal levels in static VAR compensators (SVCs) and DC converters.

Modern applications are much more stringent, however, needing better performance than the AD204 can provide (accuracy, noise level, and isolation), and the power supply couldn’t meet today’s restrictive EMC requirements.
So, I was asked to develop a newer high-performance DC Isolation Module. The basic concepts had been established by Steve Peddle, but he was quite busy on other projects.

The original concept was to perform “intelligent” ADC conversion on isolated “islands”, encoding the data in a protocol, and transferring the multiple streams of this protocol using digital isolation devices back to a central location, where it would be converted back by multiple DAC conversion on a circuit not isolated from the TESLA recoreder (as is required by the TESLA analog front-end).

I came across a potential alternative in the form of isolated sigma-delta modulator converters like the Analog Devices AD7401, which could give a highly accurate, flexible solution. Using an evaluation board, I captured data and performed extensive data analysis in Python.  I implemented the sinc3 filter in Python, demonstrated the trade-offs, and explored the possibilities of various configurations.

I evaluated the technologies against each other and wrote a report. After discussions with Steve and ERLPhase management, we decided to proceed with the sigma-delta modulator approach.

We obtained the evaluation kit for the Silicon Labs Universal Bee MCU EFM8UB20, and wrote the initial code as proof-of-concept and to bring up the system, handing it over to the firmware development team to implement the core functions.

I developed and documented the isolation plan, which included double 300V isolation gaps. After a design review, I created the schematic, and had two interconnected PCBs developed. I wrote a verification & validation document with guideline for the firmware implementation.