Author Archives: logan

Supermoto Power Control Module

Since 2010 the Yamaha YZ450F has had electronic fuel injection (EFI). To support the new electrical loads of the bike – more powerful ECU, fuel pump, fuel injector, additional sensors – Yamaha beefed up the stator and added a capacitor to help with start-up transients (this is a battery-less system and still starts first kick!). However, after all of these loads are taken into account, the stator has roughly 50W of additional power available for accessory loads. The two largest loads on a street legal bike are the headlight and radiator fan (with the horn pulling up a close third). Even with a high-efficiency LED headlight the load can be as high as 20W, and a radiator fan (like this one) can draw 24-30W. To overcome these limitations, I decided to design a control unit to:

  • Provide HI/LO functionality for the headlight
  • Control radiator fan speed
  • Automatically dim the headlight when the radiator fan is on

This post details the design process I took to arrive at a functional control unit.

MOSFET Evaluation

While still working on specifications for the final design, I decided to take a detour on a small side project to more closely evaluate MOSFETs and associated driver circuitry. At this point, I hadn’t designed a board to drive any sort of real load, so I was curious about the behavior of the associated electronics. I designed a PCB to evaluate the MOSFET I was considering for the final design (IRFR3806), as well as a MOSFET driver (IRS44273L). I included a BNC connection for the input signal (as I expected to use a function generator to drive it), as well as removable Molex connectors for the supply voltage and drive output, and test points to check the voltages at the input, gate, and drain. I also used an 0805 resistor between the driver output and the MOFSET gate labeled “SLEW” on the silk – I didn’t end up playing with this part, but the idea was I would be able to control how quickly the driver charged the gate by swapping out this resistor for different values.

I happened to be reading the FET chapter in The Art of Electronics while working on this project, so I grabbed a scope shot of the gate voltage:

Always cool to see theory reduced to practice.

The next day I brought my board and fan into work to take advantage of the higher-end equipment I had available. As part of the design I included a current shunt resistor – the Fluke seen in the picture is measuring the voltage across it. With this setup I was able to easily perform a number of tests:

  • Carrier frequency evaluation – because the fan makes a large amount of noise, this frequency could be much lower than the one used for the headlight (I don’t have any pictures of testing that with this board).
  • Duty-cycle to current table

I’ve been spoiled by the MSO4034 at work, makes my TDS320 look a little sad.

Control Module Development

Let’s start with the good stuff, the assembled board:

Assembled! This was a fun one, first board I’ve made with 0402 components.

I ended up switching to a smaller, “lower” power capacity MOSFET for the final design (BSC340N08NS3G). I targeted a rather small enclosure from Digi-Key, in part because I didn’t want some honking enclosure in the headstock and in part because I like a good challenge (and because OSH Park charges $5/in^2, I’m always seeing just how small I can make something). The design is simple, there are two identical output channels and three identical input channels. I used an ATMega168PB, a low-power version of the classic ATMega168A.

Coming soon:

  • Schematics
  • Description of firmware
  • Photos of it working

1999 Honda Civic Head Gasket Replacement

In the winter of 2014 my wife’s 1999 Honda Civic overheated at the end of her drive home from college (about a three hour trip). After finishing up finals, I drove back home and met her at her mom’s house where the car had been moved into the garage so i could look at it. I found a lot signs of how bad the overheat was – the lid of the radiator overflow tank had melted, the label on the oil filter had shrunk to half its size, the valve cover smelled of roasted oil. One of my friends came up from St. Louis for a few days and helped me replace a large number of components and fluids: new radiator, new cooling hoses, thermostat, overflow reservoir, oil change, multiple coolant flushes, and the battery (I think it just happened to die around this time).

After all our work was complete, we fired the car up and it ran fine. However, I figured this wasn’t the last of the trouble – there was no obvious problem I had found during any of our work, nothing that seemed to be the root cause. After returning to school my suspicions were confirmed; the car was low on coolant. From there began a multi-month journey of trying every possible diagnostic method I had available to determine where the leak was. In the meantime, I kept a bottle of coolant in the back of her car and would regularly fill it up (every 3-4 weeks I’d put about half an overflow tank’s worth of coolant in). After trying leak-test dye, radiator headspace exhaust testing, radiator cap pressure testing – nothing turned up any obvious results. Everything pointed to a small leak between the cooling jacket and a cylinder, but small enough that my radiator headspace test didn’t turn up anything.

However, her car kept running, it just needed a bit of coolant every now and then. Fast-forward to December 2014. I take a job at Southwest Research Institute, we move to Michigan, and her car keeps on trucking. Finally, this summer I had to decide between selling the car or replacing the head gasket. I choose the later and below is a gallery providing an overview of the process. Before embarking on this project i had no experience in this sort of major automotive repair. I printed out roughly 40 pages of service manual information, watched numerous videos from Eric the Car Guy, and called numerous friends and family members with automotive experience.

The job in total took three weeks, a bit longer than I anticipated but twice I unexpectedly had to order parts (see the timing belt cover photo below). However, in the end, the car fired up and ran. I learned a lot in the process, and gained a decent amount of confidence in my auto tech abilities along the way.

Update (2017-07-15): The car ran without needing a drop of coolant for two years! While the car has been a good learning experience (since this post I’ve replaced roughly half the exhaust system, the power steering rack, and bled the brakes), I was definitely glad to finally sell it and upgrade to something a bit newer.

ThumperFI – Single-Cylinder Motorcycle EFI Controller

What started as a summer project morphed in to today what I like to call ThumperFI – “thumper” from the characteristic sound associated with single-cylinder dirt bikes and “FI” for Fuel Injection. I started the project with the intention of fuel injecting a lawn mower as a sort of in-depth introduction to fuel injection before I started work in the Internal Combustion Engines lab at school. However, the project quickly increased in complexity as my goals became loftier (and I maxed out the inputs to the MyDAQ) until it became a full-fledged system for controlling any single-cylinder engine.

Assembled ThumperFI v1.0 board

Assembled ThumperFI v1.0 board

The system is based around the Atmel ATMega644 8-bit microprocessor. Among it’s many features:

  • On-board serial-to-USB converter (FT232RL)
  • 16kB SPI EEPROM
  • Variable Reluctance CPS (MAX9924)
  • Flyback protected injector output

There are 6 analog inputs to the system, which uses speed-density to calculate airflow. The analog inputs are:

  • Manifold Absolute Pressure (MAP)
  • Intake Air Temperature (IAT)
  • Coolant Temperature (CLT)
  •  Throttle Position (TPS)
  •  Wideband O2 (UEGO)
  • Battery Voltage (BATT)

The firmware is written C and compiled by the AVR-GCC compiler in AVR Studio 6. User configuration and tables (warm-up table, MAP-RPM VE table, etc.) are stored on the external 16kB EEPROM.

The driving force behind this project has been my own desire to learn and grow in both my field of study (mechanical engineering) and other, related fields of study (computer, electrical engineering) as well as learn about engines and controlling them. Since starting this project I have attained experience in:

  • Use of oscilloscope for general measurement and circuit debugging (TDS 320)
  • Use of digital logic analyzer (USBee ZX)
  • Familiarity with engine control sensor use and operation
  • Circuit construction, design and debugging
  • Component selection and sizing
  • Basic engine fuel control algorithms and theory
  • Reading data sheets
  • Microcontrollers and embedded programming
  • Project management and documentation
  • Soldering, both through-hole and SMD (with Weller WES51)
  • PCB layout and assembly

Needless to say, I’ve learned quite a lot – and I’m always learning more each day. Two weeks ago I put the finishing touches on my communication scheme and implementation. Over winter break (2013) I received my PCB from the fab, spent 10 hours soldering it, tested it and only had to make two slight modifications.

Missouri S&T Engine Lab – CFR Pressure DAQ

I have worked in the Missouri S&T Combustion and Spray Dynamics Lab from spring 2013 to present. Primarily I maintain operating test stands and set up stands for use (from obtaining and installing mechanical hardware to developing the LabView interfaces used to operate and record data). My first major project in the lab was to remove an antiquated, somewhat functional in-cylinder pressure DAQ system and integrate the same functionality in to our existing cRIO control system.

This project involved quite a bit of work and research:

  • Reverse-engineering the LabView program written years prior to my arrival for a different NI DAQ system (the CFR is based on the cRIO RT/FPGA system)
  • Implementing the same functionality on the cRIO by adding a DMA FIFO to the CFR “driver” and writing a custom front-end to dequeue and process the pressure data
  • Creating a usable interface that could be easily taught to the TA running the labs
A snippet of the RT processing loop that grabs a complete cycle of data.

A snippet of the RT processing loop that grabs a complete cycle of data.

The most complex portion of the project was researching and implementing the DMA FIFO system to pass data between the FPGA and Real Time (RT) controller – I collected a data point at every crank angle and wanted to be able to display a cycle-to-cycle pressure graph along with calculating IMEP.

A P-V diagram of the system from a single cycle

A P-V diagram of the system from a single cycle

When complete, my program offered significant improvement over the previous iteration:

  • Cycle-to-cycle graphs not only possible but seamless
  • Live Pressure-CAD and Pressure-Volume graphs, as well as calculated IMEPn and work without taxing the real-time system.
  • Clean, organized, commented block diagram
  • User-selectable graph averaging

Aside from the programmatic improvements, I was able to remove an entire cabinet that housed the old computer and DAQ interface, as well as a specialized signal box that was simply inverting the crank position signal – this allowed us to officially control and log data from the CFR from a single cabinet.

The CFR cabinet controls and records data from the research engine

The CFR cabinet controls and records data from the research engine

ME 240 Final Project

In the fall of 2014 I took ME 240, Mechanical Instrumentation, a course described on the class website as:

This course is designed to provide the students with a background in a broad number of transducers and measurement systems for recording and controlling real world processes and conditions. This course will combine a combination of lecture, laboratory and additional hands on work to teach the indicated topics.

Every student purchased an NI MyDAQ and learned the basics of LabView to create simple DAQ systems. The final project for the course was open-ended and allowed the students to direct the project as long as it fit the guidelines (at least one transducer of our choice, as well as used LabView and measured some sort of signal). My project partner and I decided to instrument a simple lawn mower engine and calculate mass flow as the primary measurement; however, in total we measured six different signals:

  • Exhaust Gas Temperature (EGT)
  • Wideband O2 (UEGO)
  •  Throttle Position (TPS)
  •  Intake Air Temperature (IAT)
  • Manifold Absolute Pressure (MAP)
  • Crankshaft speed
The front panel for our final project, we tried to make the main interface as simple and readable as possible with configuration in other tabs.

The front panel for our final project, we tried to make the main interface as simple and readable as possible with configuration in other tabs.

We calculated mass flow using the speed-density algorithm, adjusted for air density. We also measured other parameters, such as EGT from cold-start and heat soak after shutdown. Live information was displayed on a front panel and the user had the option to log data, as well as the ability to configure various parameters such as sample rate, transducer configuration, etc.

The program was based on a producer-consumer model and the consumer loop was a state machine that handled processing, displaying, data logging, etc. The data logging was also a state machine that handled opening, writing to and closing a file (allowing multiple logs to occur during a single run).

The consumer loop, processing state demonstrating the number of custom VIs developed for the project. These custom VIs simplified the layout and made functionality obvious in addition to adding reusability for other projects.

The consumer loop, processing state demonstrating the number of custom VIs developed for the project. These custom VIs simplified the layout and made functionality obvious in addition to adding reusability for other projects.

We had access to some more advanced hardware through the Engines Lab and as a result were able to record data at a fairly high throughput. With this data we were able to examine the MAP signal during the intake and calculate true mass flow using the measured value and time differential between samples. If you’re interested in learning more about this project you can download our final presentation from Dropbox. We mounted the engine to a “stand” that we secured with a moving blanket to reduce vibration and to stop it from moving around on the floor. The lawn battery we were originally using for power stopped working so we used my Accord’s battery as power.

Sometimes it was too cold outside to run the engine with the garage door open so we ran the jumper cables and exhaust out the cat door.

Sometimes it was too cold outside to run the engine with the garage door open so we ran the jumper cables and exhaust out the cat door.

PCB Design

Introduction

One theme you might have noticed throughout my project blog posts is that I like to design and assemble PCBs. I’m not saying that I’m a great PCB designer by any means, I still consider myself quite the novice with a lot to learn (especially about higher-speed PCB layout and noise considerations). However, my lack of experience hasn’t stopped me from trying; all said and done I’ve designed six PCBs to date which you can see below.

The six boards I've designed to date

The six boards I’ve designed to date

I started designing boards in the fall of 2013 with ThumperFI v1.0 (far left), a prototype single-cylinder engine controller. After successfully assembling and testing I was amazed what I had built worked – I had designed and assembled a circuit board! From here out I knew that if I needed a board (or just wanted a board) I could make it, or at least try to. My next board was VRSim (center next to ThumperFI), a VR signal simulator that I’m still developing software for. I’ve also found the ability to build boards useful for breakouts, like the RJ45 breakout I detail in another post or the MAX9924 breakout (far right, middle).

Why?

Why not, really. I’ve always been fascinated by circuit boards. As early as 7 or 8 I displayed a stereotypical engineer trait – I liked taking things apart (and not always getting them back together at first…). I remember taking apart my grandparent’s VCR that had broken and just staring at all of the intricate parts inside. I had no idea how it worked but I thought it was pretty cool. I had various run-ins with electronics through my teenage years; I had a BASIC Stamp at one point and even played around with AVRs on a breadboard before school took up most of my time. It wasn’t until sophomore year of college I decided to start pursuing my interest in them again. ThumperFI was that first attempt, a friend convinced me to try to build an EFI controller as a means of learning about fuel injection before working in the engine’s lab at school. Naturally, I decided that building something this complex had to be done from scratch (haha!) and dived in to brushing up on my embedded C and basic AVR breadboard layout. Two years later ThumperFI is still a project I’m working on and has more-or-less been the driving behind the knowledge I’ve gained in hobby electronics.

Where Does Mechanical Engineering Fit In?

I have a pretty strong interest in engines, like a good number of mechanical engineers, and in today’s automotive environment the engines are controlled by embedded controllers. As a mechanical engineer I feel that my understanding of how engines operate is enhanced by my understanding of the underlying electronics, the capabilities and limitations of the control system.

Bench Setup

Like any engineer I enjoy collecting and using tools and my electronics hobby has been no different. I started with a terrible RadioShack soldering iron, a breadboard and a handful of through-hole components and have worked my way up to a bench setup that includes:

  • Weller WES51
  • Tektronix TDS 320
  • Fluke 115 Multimeter
  • TrippLite PR-7b (still looking for a good, reasonably priced variable power supply)
  • Hot-air Rework Station
  • And much more!

Collecting this equipment has taken roughly two years and plenty of research, both online and through discussions with my electrical engineering friends.

Logan's workbench

Logan’s workbench

Ethernet with LEDs Breakout

As I work on various projects I’ve often found I need a breakout for a standard part – a serial port, some SMD IC, etc. – and while such a breakout may exist the price of the part + shipping is either comparable or greater than the price that I can produce and assemble a board. This board is an example of such a case – Sparkfun sells a MagJack ethernet breakout board @ $0.95/piece which is really reasonable; however, that doesn’t include shipping or the jack. I can produce a very similar board for basically the same price shipped, purchase comparable parts from DigiKey and layout/add features to my board for no cost.

I also took this as an opportunity to continue working on standardizing my PCB design project layout and source control. You can find the project on GitHub with the latest files in the release/1.0 folder.

I recently returned to school and was able to assemble and photograph the boards:

Populated and unpopulated version of RJ45 Breakout.

Populated and unpopulated version of RJ45 breakout

The board includes two 1k resistors for the yellow and green LEDs included in the ethernet jack. There are also two solder jumpers so you can optionally connect the ethernet shield to ground. I designed the board to straddler a breadboard for easy prototyping.

RJ45 breakout on a breadboard.

RJ45 breakout on a breadboard

In addition to working on my PCB layout skills, I was able to add a few parts to my custom Eagle library that you can also find on GitHub. I’ve been working on standardizing the parts I use in my designs – text size, outline thickness, footprints, etc.

After testing the board works as expected, the LEDs light up and after connecting two together I confirmed all 8 pins functioned.

If you’re interested in getting this board or your own boards produced, I suggest OSH Park.

Kit photo of the RJ45 breakout

Kit photo of the RJ45 breakout

Eagle Library

Since I’ve been doing so much work with Eagle lately I decided it was time to standardize my library. Like all good engineers, I’ve already spent too much time thinking about how I can standardize, how to optimize the generation of parts in it, etc. Well, I’ve at least got something going. If you’re interested in utilizing it, you can fork the repo over at GitHub.

Like I said, it’s pretty early in development. I’ve got a library for resistors and capacitors and that’s it. I’m working on throwing together a guidelines document so that I can keep all of the parts standardized – font size and ratio, line sizes, grids, etc. The goal is to organize all of the parts I use on a regular basis so that my footprints are consistent and “tried-and-true”. My goal is to utilize the IPC standard in the “References” directory whenever possible for a device footprint. If not in the IPC standard, then it should be based on the manufacturers suggested footprint, possibly the combination of multiple manufactures or another reference, such as the Sparkfun Libraries. Speaking of the Sparkfun libraries, why not use those? Basically the same idea? In fact it looks like you’re organizing yours in the same way they are.

Well you’d be right – I’m using the SF libraries as a guideline for my own. However, I plan on integrating more device data for my parts so that I can take advantage of the BOM ULP in Eagle. For example, I’m also trying to standardize my the parts I use on a regular basis – mostly passives like resistors and caps – so I’ve decided to use the ERJ thin-film resistors from Panasonic. The next time I place a Digikey order I’ll just order about 250-1000 of whatever resistor it is I’m ordering and call it done. To that end, I’ve created a generic resistor for this called “10k-?-*” where ? is the “variant” (package size for the resistors) and * is the “technology” (1% or 5% for the resistors). Then, I add in the 4 common package sizes I’ll be using – 0603, 0805, 1206 and 1210. So, each time I add a resistor to the library (and this is where I’m looking in to scripting the process) I’ll look up and add the 8 parts necessary.

There’s a long ways to go before I’ve got this all put together so expect to see a lot of changes over the next month or two. I’ll be adding the devices I used for ThumperFI to the appropriate libraries.

Black Magic and FPGAs

As the title implies, this post is about black magic and FPGAs – really one and the same from my perspective at the moment. After talking to someone who knows a few things about engine controls (as well as considering some of the analysis I did before my recent ThumperFI hiatus), I established that interrupt-based timing is not the best approach. Currently I have the 16-bit timer on the ATmega644 connected to the ICP pin, which fires an interrupt at a rising edge of the trigger wheel signal. This seems like a great idea until you consider the fact that there’s a separate 8-bit timer firing at a fixed rate and that there are a number of complex calculations that need to happen during that interrupt (including a few 32-bit ones). I monitored some outputs on my logic analyzer to check timing of this interrupt, as well as the auxiliary 8-bit timer and found that the 16-bit timer was frequently pushing back the 8-bit timer interrupt which lead to incorrect timing.

What’s the solution to this? In industry, this is where the co-processor comes in. Where do FPGAs fit in to this? Well, FPGAs are at the forefront of engine control technology (there’s a great SAE paper about the application of some Drivven technology on an YZF-R6 about this very topic). FPGAs offer flexibility, high-speed, parallel processing and portability. You write your IP cores in a HDL and with little to no tweaking you can run your synthesized design on a vast array of different FPGAs. I recently procured a Mojo FPGA development board based on the Xilinix Spartan-6 family. I also have another board based on the Xilinix Spartan-3 family that has a few more useful learning features – like more buttons and LEDs. At the moment I’m just learning the basics of Verilog and how to think in parallel rather than sequential operations.

More to come on Verilog and FPGAs soon.

A Practical Overview of Variable Reluctance Sensors (and associated hardware)

That is quite a title, but I’m hoping that it will help others find this post some day when they run in to the same problem that I’ve been running in to for a while – finding a single source of information that provides enough detail about how variable reluctance (VR) sensors work, how to interpret the waveforms generated by them and how to configure and understand the output of the hardware associated with them (specifically the MAX9924).

How VR Sensors Work

Disclaimer: I am not an electrical engineer. Don’t judge me.

In a sentence: VR sensors generate a voltage proportional to the speed of the moving object and the magnetic flux in front of the VR sensor pole. A cutaway shot of one will make that make more sense.

The voltage output is proportional to the speed of the moving object (in the automotive world, a toothed trigger wheel) so the output can range from millivolts to nearly a hundred volts depending on coil configuration and RPM. The output shape is essentially a sine wave – the magnetic flux varies from a minimum when the tooth is farthest away (largest air gap) to maximum when the tooth is centered with the pole piece (smallest air gap). Here’s the theorhetical output of a VR sensor.

And here’s a sample of me waving a screwdriver in front of a VR sensor I have.

Pretty simliar, eh? The key point here is that the slope increases as the “tooth” gets closer to the center of the pole, then swings through zero in to the negative voltage region and then returns to zero – this is the pattern you will see for all VR sensors (when properly connected, if you see the opposite then you’ve probably switched the positive and negative lines of the sensor).

How to Interpret a VR Signal

The most important part of the VR sensor output signal is the zero-crossing from positive to negative voltage. This point is almost exactly (there’s a slight electrical delay resulting from the combination of the sensor and the processing circuitry we’ll talk about in a bit), and for our purposes is, the center of the tooth lining up with the center of the pole piece. Here’s a nifty graph I drew on my whiteboard to illustrate this point.

VR Sensor Signal Conditioning

So now you’ve got this sine wave coming from your VR sensor and you want to use it as an input to your microcontroller or ECU. How do you go about doing that? You go out and buy a chip that does everything for you like the LM1815 or the MAX9924. I’ve used both, they both do the job. ThumperFI has the MAX9924 because after researching the topic on the forums, people seem to like the MAX9924 more than the LM1815 – it seems that it’s better at detecting small signals among other benefits.

I’m not going to go in to the specifics of how the MAX9924 does what it does – not only because I only have a marginally decent knowledge of how it works but because you don’t really care (well, I guess I can’t know that but I’m going to assume that you want to know THAT it works, and how to configure it, rather than the technical details. If you want to know that, go read the datasheet).

The MAX9924 datasheet agrees with what I’ve told you above:

The zero-crossing signal provides true timing information
for engine-control applications. The zero-voltage
level in the VR sensor signal corresponds to the center
of the gear-tooth and is the most reliable marker for
position/angle-sensing applications.

Basically, the MAX9924 generates a square wave that your microcontroller/ECU can read. The falling edge corresponds to the VR signal crossing the adaptive peak threshold (i.e. the voltage goes above a certain voltage) and the rising edge corresponds to the zero-crossing point. Pay attention to that, the rising edge of the MAX9924 signal is the edge that you need to time off of. If you go back and look at the signal diagram I drew above you’ll see that the rising edge lines up with the zero-crossing which lines up with the center of the tooth. Here’s a scope capture of me swinging that screwdriver in front of the VR sensor again only how I have the output of the MAX9924 on ThumperFI overlaid on the VR signal.

You can better understand the adaptive threshold with this picture – notice how the trigger lines up with the signal when it’s slightly offset from zero? That’s the trigger threshold happening – it’s this magic that makes the MAX9924 so great at what it does.

Conclusions

That’s basically what I wanted to outline in this post – how a VR sensor works, what kind of signal it generates and how to process that signal to generate something useful. Any questions you have can be directed below to the comments section.