Elecsys starts with a… Last Call?!?
Elecsys started out with what could have been a “bang”, but ended up being a “whimper”. My “whimpering” from lack of sleep!
Two businessmen from the Riding Mountain area, Terry Ledoux and Rene Roncin, contacted Vansco about development of an remote controlled duck decoy animation system. Vansco was too busy, so they referred them to Elecsys.
Terry Ledoux was a taxidermist based in McCreary MB, who sold his taxidermy business and went full time into being an outfitter and hunting guide. He wanted his new product to be called Last Call, a trade name which he owned.
They had started the development, even had nice rotary moulded enclosures made, but they didn’t know how to do the electronics, so Elecsys took them on.
Elecsys was actually operating out of the attic of Jason’s house. We brought in all our contacts on the job – mechanical development, PCB layout, PIC programming – and ran our credit to the limit to cover all the costs of parts, etc.
The last 48 hours were an absolute nightmare. We worked non-stop, had all kinds of issues – not the least of which was destroying multiple radio modules – they were not only quite expensive, but we also only had so many to work with. I so much needed sleep that I went downstairs to lay down on the couch, while one of my colleagues was going to try to commission another unit with our last radio module… when I had a flash of insight! I had to rush back upstairs and stop them from powering it up! The radios had been destroyed by inductive kickback from the motor drive circuit, which operated from the same supply. We hastily reworked the circuit, and with another 14 hours of work, we delivered two functional prototypes to the customer for a business trip to demonstrate them to Cabela’s in the US.
In the meantime, we were all strapped for cash – the customer, Elecsys, Jason and I ourselves… and had to settle for only a portion of the planned amount. We did cover our costs, but not much more. Needless to say, the customer didn’t proceed with the next stage of the development, which would have cost a lot more money. That was unfortunate, because it was a cool product with a cute name, and I think it would have been a winner.
Some time later, we sat around with Ed Van Humbeck and discussed our experience. He shared with us that something similar happened to him in the early days of Vansco, and counselled us to always get as much as possible up front – to at least cover the bare costs of the project, should the final payment not be forthcoming. We still had much to learn!
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.
Development Support for TESLA 3000 MPB
The TESLA 3000 MPB was developed for NxtPhase by Fidus in Ottawa. It went fairly well, until the prototype board would just not recognize the Ethernet NIC, at all. Michael Miller asked Elecsys to investigate.
I insisted that we boot LINUX on the board. Fidus advised that it was not feasible to do so. I persisted, and after about a week’s work (customizing the boot parameters and hacking the kernel a bit), I had it booting to LINUX with a small laptop hard drive. Sure enough, the Ethernet NIC would not come up, even though it was fully supported by the installed LINUX driver.
By instrumenting the driver with printk() and observing the result of loading and unloading the driver in the system log, I determined that it was a short between two lines on the PCI bus to the NIC. When Fidus took a close look at the Gerber files, they discovered that the design rules were too tight on the PCI bus on a deep inside layer of the PCB. The PCB was corrected and remade, and the NIC worked.
Later, there was an issue with the operation speed of the MPB core. Fidus was doing the FPGA development in VHDL on Synopsys, but did not have the resources to continue. I took over the development under Synopsys, having to establish VPN to Fidus to obtain the license for it to run. I suspected that the Synopsys tools, as good as they were, could be responsible for my inability to get appropriate performance from the FPGA. I ported the VHDL out from Synopsys back to Xilinx ISE, a byproduct of which was that we could do full development stand-alone in Winnipeg, which was nice.
With a few tweaks, I was able to get the MPB FPGA to simulate out at better-than-required full speed operation, which was proved out in actual operation. I mapped a path to higher speed operation, anticipated as a requirement for future product development.
Production Support and Test of TESLA 3000 AIB using GPIB
After performing the design and full verification of the TESLA 3000 AIB, Elecsys was asked to support the manufacture of the boards at Trilogy-Net in Calgary. There were challenges in getting the boards to work, mostly because of the silly little LM358BP, which is in a tiny 8 microbump package. We had process issues on getting it to solder properly.
In the end, the fault was the layout that I had supervised. Unfortunately, in our desire to pack everything onto one side of the board, I had moved down to the absolute smallest package of the LM358 dual op-amp. Well, in the end the board layout person went to double sided assembly but didn’t tell me until the last minute, meaning that the tiny op-amp stayed. There were larger parts around the op-amp that drew the heat out of the oven, so the op-amp wouldn’t solder consistently. This was a headache until a couple of years ago, when that op-amp was finally replaced by the larger SOIC version. Sigh.
Anyway, we wanted to do a 100% test of the AIBs to ensure proper function before TESLA assembly.
I acquired a number of surplus IEEE-488 / GPIB test equipment and a PC GPIB card, and wrote scripts in PERL to control the test equipment. We were able to drive precise voltages into each channel, to test offset and gain, then certain frequency signals to test filter response. Data was logged, analyzed, then the aggregate data was reviewed continually to calculate statistical process control.
Developed TESLA 3000 Analog Input Board (AIB)
The TESLA 3000 was designed to put the analog-to-digital conversion as close as possible to the rear panel, so the AIB had 6 x TI ADS8364 6 channel 16 bit SAR ADCs on it, with the associated front end and conditioning circuitry. A Xilinx Spartan 3 FPGA directed the acquisition timing, collected the ADC data, and communicated with the TESLA 3000 MPB using a bidirectional high speed LVDS synchronous serial link.
I did the architecture and design of the TESLA 3000 AIB, and oversaw the PCB layout by an external contractor. I specified the operation of the FPGA, how it interfaced to the MPB, and how it was programmed for operation.
The FPGA firmware was developed in Verilog on Xilinx ISE by a contractor at Fidus in Ottawa. When that FPGA developer was unable to complete the job, I took over and finished the project.
Design Time Sync System and Write TimeServ for TESLA
As the developer of the MPB, programmer for the IRIG-B decoder, and designer of the synchronization logic in the FPGA, I had originally documented the way that the time synchronization was to work. It was implemented by our DSP programmer, Bob Jackson, and the X86 programmer, Michael Miller.
Later, during the shift from QNX 2 to QNX 4 (now POSIX-compliant), Michael Miller, now my manager, asked me to revisit the time sync design, update the documentation, and implement a “time tag” system for maintaining accurate representation of time in the buffers and on disk, in the presence of time changes, discontinuities, and disagreements between processors.
I documented the plan, identifying the method of arbitration of time, then wrote TimeServ in its entirety. It’s still in use.