Category Archives: Hardware

Interfacing an FPGA with a PS/2 Keyboard: Part 1

As part of my “build a computer from scratch” project (overview blog post forthcoming) I need a keyboard. While building the USB stack from hardware up to software sounds like a fun project, I have quite a few other pieces to assemble and a PS/2 keyboard is much more expedient. So, I dropped by HSC Electronics Supply in Santa Clara and picked up the most old-school looking PS/2 keyboard the had, along with two 6-pin mini-DIN headers I could solder leads to.

Having only read about the PS/2 specification I wanted to put theory to practice and see the output during a keypress event. So, I assembled my PS/2 breakout, broke out my power supply and breadboard, and wired everything together. I set up my logic analyzer to capture the clock and data channels and was pleased to find a PS/2 analyzer option – however, I did find that lower capture rates – I went all the way down to 1 MS/s – were required to make the analyzer function properly. My guess is the analyzer isn’t applying much, if any, filtering to the data stream and glitches are corrupting the decode state machine.

I set the trigger on the falling edge of the clock signal and powered the keyboard up, expecting to see a BAT message from the keyboard.

On power-up PS/2 keyboards enter the basic assurance test (BAT) state and, if successful, send 0xAA “BAT successful” to the host.

I restarted the capture and pressed “a”. In the capture below you can see the decoded messages in the lower-right panel – both the “make” and “break” messages were captured.

After assembling my PS/2 header I wired it up on my breadboard and pressed ‘a’ – success!

With the smoke test out of the way I moved onto my second target – level shifting the clock and data signals to 3.3V to be able to interface with my miniSpartan6+ dev board. I didn’t have any level shifter ICs on hand but I did have some SOT-23 FETs. So, I put two of my IRLML2060TRPbF FETs on a SOT-23 breakout board, added a few pull-up resistors, and turned on analog capture on the logic analyzer.

The result – a nice 3.3V output on the host side, perfect for my FPGA.

My next post will detail the PS/2 link layer and keyboard controller modules for the FPGA. The goal is to emulate the register interface standard for PS/2 keyboard controllers, on top of this I will build a simple module that will translate keycodes into ASCII characters and spit them out the serial port on the miniSpartan6+.

References

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

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.

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.

Hardware Testing – Update

USB is alive again! After fiddling with the FT232RL and the USB cable some combination of factors brought it back to life. I suspect that the cable may have been the problem all along (goes to show that you should always double check what you think works). I ended up using the clips from my USBee and the AVR ISP to test the cable and it passed…after I swapped USBDP/DM (this was after I’d already cut the end off and soldered on new connections, along with heat-shrinking the more sensitive 26/28 gauge cables – I imagine if I had tested it before it would have failed).

Testing the USB cable for continuity/functionality

One thing to note – every time I tested the USB cable with my multimeter for continuity it worked (and that’s from the male plug contacts to the output pin on the wiring harness). What this tells me is a continuity test of a USB cable is not enough to verify it’s functionality (unless there was some freak event where it would have failed continuity if I’d checked at a different time). I’ll have to ask one of my EE friends or a forum about this but it’s something I’m going to keep in mind in the future when dealing with USB.

I didn’t end up connecting the RESET pin to anything, it’s just floating. Hopefully this won’t cause me any issues with enumeration but if I start having issues that’ll be where I start. In v1.1 that will be fixed so let’s hope it holds up until then.

So, this means that all of the hardware on ThumperFI v1.0 is fully functional! There were only two minor modifications  which will also be fixed in v1.1.

Hardware Testing

ThumperFI v1.0 PCB arrived two weeks ago (2013/11/26). I spent most of that week soldering it together – once I learned how to solder most of the components, that is. Before putting it together, I had soldered a 44-TQFP and 10-uMAX package (0.65mm pitch MAX9924). Now I got to experience soldering SMD resistors, caps, LEDs, etc. Overall it went well, I only bridged two pins and that was on the MAX9924 (as I expected). Here’s the final result:

Kind of poor quality photo but shows the components the best.

While I was at home two weeks ago I was only able to able to test that it powered on – all of my other equipment was at school: my AVR ISP, oscilloscope, etc. So I attached a 9V across 12V_RAW and GND and the PWR LED lit up, so that was exciting.

When I got to school pretty much the first thing I did was set my work bench back up and hook ThumperFI up to my ThinkPad (i.e. “science” computer). It passed the visual inspection, the status LED on the ISP turned green which means my layout was correct. Then I opened up AVR Studio and checked if I could read the voltage and signature of my ATmega644A – which I could!

Now, there’s a decent amount of hardware to test on this thing and I was really busy last week so I spaced out the testing – I’ve since tested functionality of all major components (I haven’t done any intense testing like over-voltage, reverse-voltage, injector flyback, etc.) so I’ll summarize the results here before going in to detail about all of them:

  • ATmega644A – functional, able to load programs, behaves as expected
  • EEPROM – functional after modification
  • FT232RL (USB) – non-functional, “device not recognized”, currently debugging
  • ADC inputs – functional, including conditioned inputs like IAT, CLT and battery
  • Injector, fuel pump and spark signal output – functional, behave as expected
  • VR input – functional, converted 200mA sine wave to square at zero-crossings perfectly
  • Kill switch input – functional, hardware debouncing works well

So other than USB, everything works! Now for the details.

EEPROM

EEPROM did not work, at all, right off the bat. So, I pulled up the schematic for the PCB and drew up a schematic for the EEPROM on my old prototype and noticed immediately that I had put a pull-down resistor on CS (Chip Select) instead of a pull-up (SPI CS is active low, so my chip was active all of the time). To fix this I cut the trace to GND and bridged the 10k resistor to the +5V cap terminal right next to it. Thinking I had fixed the problem I reloaded my test program and ran it again – no dice. I broke out my USBee DSA and carefully tapped off of the SPI lines and logged some data – everything was coming in to the chip correctly but there was no activity on the MISO line – strange. After examining and re-examining my circuits to make sure everything was the same (my test program worked on my prototype) I decided to ask my friend Mike for some help. He went through a number of checks with me based on what I gave him until he asked me what I had done with the ~HOLD pin. I told him it was just soldered to a pad connected to nothing. He said that the ~HOLD pin can tri-state if not pulled up and that can cause all sorts of issues – like the missing MISO signal I had. The SO-8 pitch is just big enough that I was able to bridge a 10k resistor across Vcc and ~HOLD and that immediately fixed the problem.

FT232RL

The second thing I tested after the ATmega644A was the USB capability. And it worked. Perfectly. So I assumed it was going to continue working and moved on to testing the EEPROM which, as described above, didn’t go so hot the first few times. Once I got the EEPROM working I wanted to see if I could output the values I had stored in the EEPROM on the screen using the USB connection. I hooked everything back up and it didn’t work. At all. I got the “device not recognized” message on Windows. I re-examined my FT232RL circuit and compared it to SparkFun’s circuit and didn’t really see anything wrong. Then I read FTDIs debugging tips and took note of the self-powered vs. VBUS powered section. I hadn’t really done either of those, more of some hybrid. And, even better, I had connected VBUS to +5V which makes no sense. So, I left VBUS disconnected and tried it again. No dice.

I ended up e-mailing FTDIs support and a very helpful guy pointed out the self-powered circuit (see Section 6.2 in this document) in the data sheet. So, I painstakingly soldered a 30 gauge wire to the FT232RL chip, made the 3.3V resistor bridge and tested it out. Still no luck. I have tried all of his suggestions as well as anything else I can think of:

  • Make sure your USB cable is good – check
  • Make sure your drivers are installed properly – check
  • Restart – check
  • Make sure all of your solder joints are good – check
  • Plug in USB first, then power on and vice versa – check

So, after exhausting all of the options I could think of I ordered a new FT232RL chip from DigiKey and am waiting patiently to test that out (in case I roasted this one somehow – though the RXLED/TXLEDs still function…). I’m going to try the self-powered circuit first then if that doesn’t work maybe try the VBUS powered. I’ll need to make that decision before I get PCB v1.1 made.

ADC Inputs

There are 6 different analog inputs to ThumperFI:

  1. Battery (BATT)
  2. Intake Air Temperature (IAT)
  3. CooLant Temperature (CLT)
  4. Manifold Air Pressure (MAP)
  5. Throttle Position Sensor (TPS)
  6. Air-Fuel Ratio (O2)

TPS, O2 and MAP are simple inputs with no special conditioning (aside from current limiting resistors, Schottky protection and 0.1uF cap). The BATT, IAT and CLT all have a voltage divider giving me a known voltage or resistance. I tested the BATT and got 9V (which is what I was powering the system with at the time, minus the diode voltage drop). I tested IAT and CLT with a 10k resistor and 2.5V which is also what I was hoping for. All good on that front.

Injector, Fuel Pump and Spark

There are three outputs from ThumperFI (listed above) and all three of them work. Of course, I chased non-existent problems with the injector output for roughly an hour (turns out it was a programming issue, though I don’t really know what caused the issue because the changes I made in the code shouldn’t have actually done anything) – the pin wasn’t set as an output so it’s voltage was kind of floating around and wouldn’t drive the MOSFET. One interesting thing to note that I didn’t expect while debugging was that I would see the transistor base-collector voltage at the 10k pull-down resistor (makes sense, considering I was measuring at a trace connected to the base…). Regardless, it all functions on a basic level – I still need to test the Fuel Pump and Injector outputs under load conditions but it at least drives an LED.

Variable Reluctance Input

The VR input is kind of the most important part of this whole deal – if it doesn’t work I don’t have engine position and speed and can’t manage spark and injections. I saved this guy for last. I knew that the circuit worked before I made the PCB, I had built it using a DIP breakout for the MAX9924 and an actual trigger wheel (attached to a drill and holding the VR sensor). However, I was still a little nervous that for some reason it wouldn’t work BUT it did work, at least it works with a sine wave generated by my MyDAQ. I have a lawn mower engine in the garage with a trigger wheel mounted to it that I’m planning on testing it with (at speed) to confirm full functionality.

100 Hz, 400mA sine wave produces expected output. The MAX9924 is an active-low device so the falling edge indicates a tooth. Photo courtesy of TDS320 over RS232.

On a related note, I also figured out that I can just generate zero-crossings with any waveform and it will work – what that means is I can use the VR signal generator I’ve been working on with my Arduino and somehow level-shift the wave down and BAM I’ve got a functional, adjustable VR generator.

Kill Switch Input

Aside from the USB hardware, the Kill Switch input was the only untested portion of the hardware on this PCB. I grabbed a debouncing circuit from this guide. Works perfectly. It’s got a little longer RC time constant than I anticipated (honestly, I didn’t do the math so it’s probably exactly what it’s supposed to be) but I mean, hopefully you’re not just clicking the kill switch quickly wanting it to stop.

I might adjust this a bit in v1.1 but I’ll have to do some testing with it.

Other Lessons

I haven’t done a lot of extreme case testing yet (over/under-voltage, transients, etc.) and honestly I don’t really want to until I have an easier way of producing this board. In theory everything will function like it should, all of my inputs have Schottky diodes for transients, my regulator has a TVS with a clamping voltage of less than what my regulator can take, as well as a diode for reverse protection (and my regulator actually has quite a few built-in protections as well). My 22uF cap is rated for up to 100V which should pretty well cover any transients. Overall I’m hoping it’s a pretty solid design and I guess testing over the next few months will either prove or disprove that.

Now for some more pictures.

After multiple hours of soldering, it was born.

I mean, come on, I had to put my name somewhere on it.