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.

Work on GPS, Heads-Up Displays, Vision-Based Vehicle Speed Measurement

After years of very long hours and hard work, I was relieved when Vansco offered me the position of Chief Research Officer. Vansco built me a lab in a quiet area of the plant, gave me resources and ideas, and asked me to play.

This only lasted a short time, as both my personal priorities and Vansco’s priorities changed, and within a year I was back in APT – although, no longer as General Manager, which was fine with me.

Global Positioning System

At our CEO Dave Sokol’s suggestion, I dove into GPS positioning, real-time kinematics (RTK corrections), and their potential use in agriculture. I obtained some early GPS receivers and experimented with them. At that time, they were very expensive! I was amazed at their accuracy and reliability, even then.

Heads-Up Displays

I also toyed with heads-up displays. We anticipated that this would be in demand in agricultural equipment soon. I examined the existing state-of-the-art, and projected where we might take the technology.

Implement Velocity Measurement

One of the challenges in agriculture is the accurate measurement of ground speed. This is required to accurately control seed and material application rates, and measure harvest efficiency. Unlike road vehicles, you cannot just measure wheel rotation, because considerable slippage is seen all the time. The state-of-the-art at that time was to use a RADAR sensor aimed at the ground at an angle, measuring the Doppler shift in the returned signal. Taking into account the trigonometry of the angle, you can accurately measure velocity with respect to the ground. However, on smooth surfaces, such as puddles and some roads, this system will experience almost-total reflection away, and no Doppler shift can be measured.

Our solution was to use a colour camera, watching the terrain below the vehicle. By correlating the images in real-time, the 2-D displacement between the images can be estimated, and velocity can be accurately calculated. I obtained a patent on this innovation.

Worked on an IRIG-B Decoder

Manitoba Hydro wanted an IRIG-B decoder unit. It would listen to modulated IRIG-B, decode the time, and provide details of the time on a serial port. Filipe Fernandes and I did the system architecture. Filipe designed the board, based on a Motorola MC68HC11 development kit, and did the programming in assembly language.

The project was a success, but he was moved off to another project just as it was finishing, so I completed the programming. The design was a success.

This was my first exposure to IRIG-B, and I was fascinated.

Developed Transformer Winding Controller model 114000

This was the last in the series of transformer winding controllers developed for Micro Tool and Machine. It was an amazing work of their craftsmen!

The main mandrel was driven by a large stepper motor, giving fine pitched accuracy on the winding. There was a second, smaller stepper motor driving a traverse that payed out the wire onto the mandrel, moving left to right on a lead screw.

The mandrel and traverse stepper motors made characteristic sounds as they indexed, accelerated and decelerated, giving the machine a unique personality.

There was a tap forming head above the mandrel which moved with the traverse head, through which the wire passed. At a given point, the mandrel would stop, clamps would come down onto the wire on either side of the tap former, a clamp wrapped the wire in the middle, then twisted 2 complete turns as it pulled up – while the clamps on either side, operated with pneumatics, would slide in. This formed a perfect wire tap, where a long bolt could be passed through to the top of the transformer.

The placement of the wire tap was critical, otherwise the tap bolt would not line up with the insulator and hole in the casing. I took very careful measurements of all aspects of the machine, then worked the math so that I could determine exactly how far ahead to stop the mandrel to make the tap, and then have it wind down to the correct spot. As the rotation speed of the mandrel was well known (and set by the controller using a stepper motor), a payout encoder on the wire at the tap former gave constant information for the circumference of the winding. From this, and knowing the geometry of the machine, the exact point that the mandrel had to decelerate and stop, could be calculated. The amazing thing was – it worked!

The last cool feature of this machine was duct tap insertion – a compartment of insulating rods was kept on the side, and could be pneumatically pushed up into one-way catch slots on the ends of the winding mandrel. This provided spacing between layers, or between windings.

All of this made for a fantastic sight. Almost autonomous transformer winding! Although the operator was still required to baby-sit the machine, in case anything went wrong. Of course, they had to change wires for LV and HV (LV wire was more like a wide copper foil), weld to the ends (propane welding of copper!) and tie off things when appropriate.

I was so enthused about it, that I borrowed Lorne’s camera and made a video of it in operation. I’ll have to dig up that tape, digitize it and post it sometime!

The machine had multiple processors on multiple boards, coordinating all this activity. The traverse controller was implemented with a Motorola MC68701, programmed by Lorne and by me; the tap forming controller was implemented with a Motorola MC68705U5, programmed by Mike Stasenski, and I did the programming on the MC6800 on the main controller, coordinating all their activities. I designed the “piggyback board” which contained the very-cool PCL-240K stepper motor controller for the mandrel, the “traverse board” and the “connector board” where all the different boards wired to for the interchange of communications.

This machine went to Delta Transformers in St. Jean-sur-Richelieu, Quebec. In 1988, I visited the plant and saw my machine in action. The engineer responsible for the machine, Guy Desormeaux, told me that the company had recently been acquired, and that this transformer winding machine was fiercely sought after!

Linearizing the YSI 44030 NTC thermistor for the CMP3000 Analog Input Board

Some things just stick in your memory – like the part number of a thermistor, for instance… well, maybe not for you, but for me. Yikes.

In second year, the development of the CMP3000 control system was in full swing. Mike Stasenski was working on the CMP3521 Analog Input Board. It was based on the then-relatively-new MC68705U3 single-chip MCU. It was pretty limited in capability, but of course Mike was (and is) a very capable programmer, able to wring every last cycle out of an MCU.

One challenge was the linearization of the NTC thermistor that was to be used to measure temperature. It was a standard NTC curve – a cubic of the inverse of the natural logarithm of the temperature in degrees K, as I recall. It gets a little more complex when you measure the output voltage when it’s paired with a pull-up resistor. The idea is to pull up through a known, stable, fixed resistor to a known reference voltage, and use that same reference voltage for the analog-to-digital conversion. This would yield a true ratiometric measurement, which should eliminate supply variations.

So, I was asked to figure out what the best pull-up resistance value would be, to optimize for room temperature of about 20C.

Hmm, that was a challenge, but I felt like I was up to it. Well, I symbolically calculated the formula for the output voltage, given a pull-up resistance and supply, then differentiate it so as to figure out the slope and the maxima. I went to my first-year calculus professor, Dr. D. W. Trim, to get his advice on solving the problem. It ended up being something like a 4×4 matrix in the powers of the inverse of the natural log – which I had to figure out the determinant of, to get the zero point.

In the meantime, I used the BASIC interpreter on the Motorola Exorciser to run calculations of the output values, checking the curve fitting, and the output voltage for various pull-up resistors. Since the Exorciser was in use constantly by the CMP3000 team, I had to code my programs on paper, then hastily type them in during their coffee break, saving it to run during lunch. And run it did, often taking the full hour and then some to complete.

Once I had the solution equation, I had to process it in BASIC to calculate the correct value, then check to ensure that it was correct. I printed yards and yards of form-feed printed paper of charts, graphs, and numbers. I’m sure that I tested the patience of everyone who wanted to get back to work at the end of lunch!

The output of my exhaustive calculations were multiple look-up tables, each optimized for an area of operation, and a careful calculation of the worst case error at each point. We incorporated the concept of “degrees Vansco” into the code, where a simple linear relationship would bring it over to Celsius.

Finally, after much calculations and work, I came up with the exact value that would optimize the voltage: 3741 Ω. Yup, cross checked, checked on both sides, that was the value. Ed Van Humbeck (company president) ordered some low tempco resistors with this value… and as he did, he remarked, “it would be funny if that was just the value at 20C”. My jaw dropped. I went off and checked the charts. Sure enough, the value of the YSI 44030 at 20C was 3748 Ω, close enough that it was just cumulative BASIC calculation error. Ha ha, the joke was on me!

By the way, for the life of the CMP3000, and beyond, the thermistor used to measure temperature on that product was the YSI 44030… and the pull up used was exactly 3741 Ω. We never bothered to change it.

Developed Transformer Winding Controller model 109000

This was one of a series of transformer winding controllers developed for Micro Tool and Machine. It used an variable speed eddy current clutch with induction machine drive. As part of a three-person development team, my responsibility was for the electronics, and for the main controller software development. Like the CMP3000 and other Micro Tool systems, the main controller of the model 109000 was a Motorola MC6800.

Developed Fully Mitre Transformer Core Shear Controller

One of a number of controllers that Vansco developed for Micro Tool and Machine, my thesis partner Danny Lew and I took on the development of the Fully Mitre Core Shear Controller as our undergraduate thesis. We built upon the existing software and main controller board, but had to modify the programming to accommodate left/right/angle stops on the head rotation, distance measurement on the material progression, and control of the material movement, shear rotation and closure, and punch activation.

I did a PCB layout (double sided tape on mylar – that was some time ago!) for the I/O board – incorporating multiple options, including some that we weren’t able to use – several of the boards were manufactured. I kept one as a momento.

We were just wrapping up the project when the blizzard of final exams hit, so the my manager Lorne Repas did a chunk of the finishing work. Overall, I was very proud of the result!

Like many Micro Tool and Machine controllers, we hoped that there would be repeat orders, but to my knowledge, we only built the one. I’m pretty sure Micro Tool would have liked repeat orders too, but it just seemed that we were always doing one-offs. That’s life.

Wrote Temperature and Humidity Control Algorithms for Conviron CMP3000

After completing the floating point math package, I dove into writing custom PID control algorithms for the Conviron CMP3000 controller. We were able to attain temperature control to about +/- 0.1 deg C and humidity control to about +/- 2% RH, in chambers with interior size ranging from about that of a refrigerator to the huge PGR-16, about the size of a double garage. Of course, the control system was only part of the story – the rest was the smart engineering of the chambers themselves, with the well-distributed airflow.

These chambers were installed worldwide, including China, Hungary, and all over North America. They were most often used for growing plants in reproducible conditions, generally to test the efficacy of specific nutrients, herbicides, or growing conditions.

By the time I was taking 3rd year controls, I had already coded this commercial control system, shipped hundreds, stomped my own bugs, and had to drive repeatedly across town to deliver EPROMs to fix my mistakes! That gave me a really good perspective on product development.

Still working on the Motorola Exorciser, most of the control algorithms were implemented in Motorola MPL, only having a few small portions in assembly language for speed.

As it turned out, the MPL compiler had a few bugs – one which turned out to be quite problematic, was in the reference to absolute address values (generally hardware registers) which were called “the ASCT”. I guess other development shops would not access ASCT registers from MPL, but thunk down to assembly for that. But, for us, it was convenient to access our EEPROM using ASCT, but MPL would erroneously spit out assembly code putting ASCT registers in PSCT, the program segment. What to do? Well, Lorne Repas realized that the MPL compiler was using a simple table lookup internally, found the table, and hacked it so that it would recognize the keyword ANY, emitting the legitimate (but previously not used by MPL) keyword ANY in the assembly output. Problem solved! So we didn’t program in MPL, we programmed in MPL2, unknown to anyone except Vansco.