Category: Algorithms and Processing

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.

Work with GE-Reason Brazil on Next Generation COSI-CT Architecture

The original design of what’s now the COSI-CT was developed at NxtPhase in about 1999.  When I was with NxtPhase Winnipeg from 2001-2003, I was involved in an informal internal evaluation of the system, and recommended significant changes.  It wasn’t that the design was bad, but that it could be improved to make it better suited for the power utility market.

A NxtPhase CT redesign was undertaken around 2003.  When I joined Alstom Grid in 2013 to work on the COSI-CT, it was practically identical to the 2003 redesign, but had a few extra components grafted on – an optional internal power supply, and a digital card.  The design was tired and had developed serious flaws, which we were trying to fix.

Everyone agreed that a new approach, the next generation of COSI-CT (called “Gen4”), was needed.  As part of GE-Alstom after the merger, we undertook the exciting new development of Gen4.

I travelled to Florianopolis, Brazil, and met with the team at GE-Reason.  They had developed an amazing array of networking, merging unit, and recording equipment before their acquisition by Alstom in 2015.  Together, the engineers at Reason and I, set about to architect COSI-CT Gen4.

After my return to Phoenix, we collaborated constantly, often in communication daily.  We worked in Atlassian Confluence, developing the architecture.  We consulted with other GE experts in Merging Unit design, and our own marketing team.

Unfortunately, just as the initial architecture was completed in late 2017, GE faced a cash crunch and had to lay off many staff, including me.  This was a big disappointment, as we were really excited about the potential for the next generation.

Oh well, hopefully Gen4 of the COSI-CT, whenever it emerges, and in whatever form, is wildly successful.

Update Alstom DIT COSI-CT Management Processor

I was only at Alstom Grid DIT in Phoenix a couple of months, when an question came from management, “Does anyone here know PIC assembly language?”

Well, I do!  So I took on the modification of the COSI-CT Management Processor firmware.  The code was written circa 2003, and was based on earlier efforts.  Good designers re-use working code!  Anyway, it had been maintained up until about 2010 by Dylan Stewart, but Dylan now had his hands full as Product Manager.  So, I took it on.

It started largely as a minor rework.  The processor has explicit support for each stored configuration value inside, knowing which one(s) are bytes, which words, which double words, and which are strings.  Things had changed in the configuration, but support for these changes was incomplete.  So, I addressed that.

A larger issue was that of supported development environment.  The old MPLab 8.x was obsolete, with MPLab X taking its place, but MPLab X would not automatically import MPLab 8.x files, especially complex ones.  I installed both development systems, and ensured that the outputs were byte-for-byte equivalent – which you can do with assembly language code!  It took a lot of tinkering to get the code to assemble properly under MPLab X, even more difficult to get it to assemble under both, but I managed it.

There was some discussion about the apparent corruption of data values on the backplane bus to and from the other internal cards.  There was no error checking on this bus.  I wrote a proposal to use CRC on the backplane comms.  It was carefully tweaked to fit within the protocol, and minimize overhead.  I implemented it on the Management Processor, but due to an error in the implementation on the CT card’s FPGA, there was an amiguity in the link, causing protocol failure.  I tried to get this error corrected, but it never was, so the effort was abandoned in place.  The code is still there, but it is never used.

Development of Flex-Header Controller for Honey Bee

Brian Fletcher of Honey Bee had contacted Vansco to do a small electronic assembly for them, but Vansco was too large and busy, so they referred him to Elecsys.  We happily took on the task of creating a controller for their new 42 foot combine flex header.

The challenge is that, with a flexible cutterbar out front, you cannot rely on simple bumpers to keep the cuttterbar from interfering with the reel.  It might flex in the middle, coming up and cutting the plastic tines off of the reel.  Those little plastic tines are expensive and very time consuming to replace.

Honey Bee had created six flex points along the length of the cutterbar, where we placed rugged precision pots to measure the displacement of the cutterbar in that region.  We placed another precision pot on the reel arm.  We were able to calculate interference between the reel and cutterbar, and drive the hydraulics to move the reel up and out of the way.

Life isn’t that simple, though.  We needed to have controls in the cab, to configure the system and monitor its operation.  We created an in-cab controller with small display, rotary dial and pushbuttons, which communicated to the controller on the implement using CAN.  At each end, the processor used was a Microchip PIC18F series MCU.

Over the winter, we performed extensive static testing on a flex header using a portable hydraulic pump, at PAMI in Portage la Prairie.  In the spring, we travelled to Honey Bee in Frontier SK to visit the plant and perform more tests.  Over the summer, Honey Bee did extensive testing all over, and I attended testing in southern Manitoba, North Dakota, Minnesota, and Illinois, riding on the combine, watching the system operation, and tweaking the control programming.

An unexpected challenge arose, that of the hydraulic capacity of different combines.  It turns out that some manufacturers have a huge hydraulic operative capacity, and others quite weak.  It’s difficult to accommodate different manufacturers, even with different programming.

Another issue was the retrofit of the controls to the combine.  The hydraulic controls weren’t meant to be tinkered with.  On some systems, we could just drive the solenoids directly.  On others, we had to diode isolate our controls from the existing controls.  On others, the diode isolation set off alarms indicating open circuit on the solenoids.

It was going to be a long haul to make the system compatible with all the potential combine systems.  In the end, Honey Bee could not invest the capital to make a flexible enough system, and Elecsys could not make this investment either.  A further challenge was that the market for the aftermarket flex header that Honey Bee was making, would not bear the several-hundred-dollar premium for such a controller.

Sadly, the controller project ended with only a handful of (very nice looking) prototypes made.

Development of Ankle-Brachial-Index Measurement Proof of Concept for Koven

Paul Koven, founder of Koven Technology Canada, was dying, and wanted to see his dream of an automatic machine measuring the ankle-brachial-index of patients.  With a very short time frame, Elecsys was asked to create a proof of concept.

Elecsys produced that proof of concept in about 6 weeks, using an SBC running LINUX, four modified off-the-shelf blood pressure monitors (selected for their ability to be controlled and monitored through a serial port), and a 2 line x 24 character alpha display, and a few buttons.  The result was very large, heavy and not all that pretty – but it worked!  We provided a single unit, with rudimentary build documentation (as much as you can expect with a proof of concept!) and a manual, and they took it to St. Louis, MO to show to Mr. Koven.

Paul did see it before he died, and we got the feedback that it was much appreciated.

Koven’s management wanted to build more of the units, but were dismayed when they found out that it wasn’t a finished product.  They hounded us for months, asking for more construction details, drawings and blueprints, and alternate suppliers for the components.  Time and time again, we patiently explained to them that they had commissioned a proof-of-concept, not even a prototype, and that the each subsequent one would cost the same to build as the first.  We offered to put more engineering into the product to make it more polished and manufacturable, for a cost of course, but each time they declined.  Then, a couple of months later, they would contact us again about details on how to mass-produce the proof-of-concept.

S-PRO for Dorsey-Forbes Transmission Line

The T-PRO wasn’t warmly received, but engineers within the MAPP region noticed the flexibility of the platform.  There was a particularly challenging aspect of stability of the Dorsey-Forbes Transmission Line that could not be readily solved using conventional relays.  Minnesota Power (MNP) asked Dr. Swift if a better algorithm could be developed using the APT Relay.  It could, so Dr. Zhiying Zhang (who had graduated and now worked for us at Vansco) wrote the algorithm and it was installed at Forbes Substation.

The Original T-PRO

The University of Manitoba’s Department of Engineering has a strong Power Systems group.  At the time, Dr. Glenn Swift had a student, Zhiying Zhang, working on his PhD thesis, which embodied the very cool concept that a transformer’s “standard operating life” between oil change and inspection (typically 7 years, by convention) could be extended if the internal temperature was monitored to take into account light loading.  Conversely, you could temporarily overload a transformer within reasonable limits, if you took into account the loss of life due to the extra heat generated within the transformer.  For instance, here in the north, during the wintertime, you could readily load a transformer for 115% of rating, say, with minimal effect on the life of the transformer, as long as you could model the heat and its affect on life.

As a testbed for their ideas, the university first used a NEC uPD7720 fixed-point DSP in a custom assembly, then moved to a PC-based solution which used a Spectrum Digital PC card containing a TI TMS320C30 floating-point DSP.  The university selected Vansco as their partner to build their designs.

The design was a “2 box solution”, with one chassis containing the CTs and PTs, and the other containing an actual PC motherboard and cards, with an umbilical cord between tpoint and he two chassis.

The DSP was programmed bare-metal in ‘C’ and assembler, while the PC ran MS-DOS (eek) and had its user interface on a classic PC keyboard and monitor.  The display was cool, using graphics to display operating quantities and trip levels.

It was Dr. Swift who coined the term T-PRO, and APT as short for “Alpha Power Technologies”, although we had to drop the latter after hearing from Alpha Technologies in BC – but “APT Power Technologies” was adopted and stuck.  Glenn always was a tireless advocate for a made-in-Manitoba relay.

We did try to market the APT T-PRO, taking it to MIPSYCON and showing it to various utilities in the MAPP region, but it wasn’t quite what they wanted.  They wanted a one-box solution… which, later, we decided to develop.