Introduction: Dodge Viper Fuel Relay Controller
Some early Dodge Viper automobiles are difficult to start after lack of operation for more than a few hours. The problem is due to a fuel pump defect which allows an undesired slow bleed-off of fuel pressure.
For various reasons, this is difficult to fix properly. A common workaround is to slowly cycle the ignition key 7 times before cranking in order to extend the fuel pre-pressurization period beyond the usual 1 or 2 seconds.
Here we present an OEM-style plug-and-play fuel pump relay replacement which performs the extension automatically.
This project was done between February and July of 2019 by Ben (hardware and software design), Johan (mechanical design and enclosure), and Shelly (car owner and testing). Thanks to Don W. for providing the idea.
Step 1: The Problem
The first 2 model years (Generation 1, Generation 1.5, and Generation 2) of the Dodge Viper sports car (wikipedia/Dodge_Viper) have a minor but annoying problem in the tank-mounted fuel pump. The fuel pressure slowly decreases, bleeding fuel back into the tank, over several hours when the engine, and thus fuel pump, is off. The defect is said to be in a pressure regulator valve integral to the pump assembly.
The end result is that the car is hard to start after it has been off for more than about 6 hours (e.g. overnight) because there is no substantial fuel pressure throughout the fuel lines and thus fuel rail near the injectors at the engine.
Of course, the engine control unit (ECU) energizes the fuel pump during the initial 2 seconds of the engine being in run mode, whether or not it is actually (yet) running, and when in crank mode. Less formally: fuel is pumped while cranking and it gets a little head start if the driver is slow to turn the key past its detents.
This is not enough to compensate for the lost pressure, unless, perhaps, a very long cranking period is performed. The crank duration that might be involved would be much more than 7 seconds and thus is unacceptable. In addition to starter motor damage, many Vipers sit for a long time between drives and so the battery depletes rapidly even with modest crank periods. The engine is very big, so cranking is power-hungry.
Fortunately, the fuel pump relay in the Generation 1 and Generation 1.5 Dodge Vipers is located in an easily reachable, if somewhat strange, place: In-line, in the middle of a wiring harness that crosses the top inside of the trunk.
Step 2: Issues With the Obvious & Proper Fix
Of course the real fix for this is to replace the fuel pump assembly. But few owners want to do that due to expense and possible compromise. This car is quite a collector's item and significantly appreciates in value over time. Therefore, owners like to keep it pristine and unmodified, or at least be easily reversible without damage. Owners talk about keeping the car in "Concourse" condition for car show judges, after a somewhat notorious car show in Monterey, California.
Since the car is out of production (the entire line was discontinued in 2017; Generation 2 copies were discontinued in 2002), a replacement fuel pump is hard to obtain.
A proper replacement fuel pump relay also seems nearly impossible to obtain. The replacement fuel pump relays (AC Delco 15-50961 19189419), which are confidently recommended online for this application, do not work: They click, but the coil doesn't fully energize. I think the Engine Control Unit (ECU) in these Vipers do not drive the relay coil hard enough.
Access to the fuel pump involves removing the fuel tank, which is not only a major operation but also is said to involve having to cut and then repair fiberglass body panels. The out-of-production body panels were manufactured via resin transfer molding (RTM) and are hard to find on the used market.
Step 3: Issues With Common Workarounds
I have heard that some owners "fix" this problem by installing a jumper so that the fuel pump runs continuously whenever the car is in RUN mode. This is dangerous because if the car stalls or crashes, the fuel pump keeps running and could be spraying fuel onto the scene of the accident. As a safety feature, the ECU is designed to shut down the fuel pump if the engine is not in CRANK (start) mode and the drive shaft is not rotating -- in other words, stalled. In fact, in the stalled situation, the ECU sends a secondary disable signal to other electrical powertrain components as well. The ECU's ability to shut down the fuel pump should not be defeated.
Some owners apparently purchase a standard timer module (such as the UCTRONICS B07BT32T1M) and wire-OR that to let the pump run a few seconds more. I've never seen this myself, but hearing about this was the inspiration for this project. This seems reasonable, but the problem I have with this is that it seems inelegant. I guess it could be done properly: You could make connectors to avoid cutting wires in the Viper, etc. But I just wanted to make a more OEM-like plug-and-play fix.
The most common "solution" for most owners is to cycle the ignition key between the OFF and RUN mode (but not CRANK yet) about 6 times, letting it sit in the RUN position for 2 seconds while the pump runs (after 2 seconds the ECU will shut the pump off). By doing this, the pressure in the fuel lines is built up. On the 7th time, the engine is cranked and will hopefully start up.
The problem with the repeated key dance above is that the ECU can go into the diagnostic mode if you do 9 cycles. Apparently, to get out of the diagnostic mode you have to wait quite a while, or disconnect the battery. But if you disconnect the battery, there will be another nuisance: These early Viper ECUs do not have non-volatile memory (NVRAM) to store their long-term engine trim parameters. So the ECU will forget. The Idle Learn and other procedures will have to be done -- this can happen while driving normally, but can take several days of driving before the car would pass a SMOG (California emissions) test.
Step 4: Our Solution
We present here a solution we call the "Pressure Principle". We replace the relay with a "smart" one that does the equivalent of the ignition key cycling automatically.
This idea has apparently been in existence for some time. I have heard of people doing this using off-the-shelf timer boards, and that is fine.
Our way is simply an attempt to make it look more OEM-like, to make it not require cutting any wires that are part of the car proper, to perhaps add some purpose-built features, and above all, to not compromise the safety of the car's original design.
It indeed runs the pump for a few seconds more, but is intelligent to cut it off after a few seconds and then to forevermore until next power cycle to listen to the car computer's command to cut it off e.g. when the car stalls or crashes.
In addition, it has a little 300ms "hiccup" in the extra timing run that cues the driver when to turn the key to the START position. The interruption in the fuel pump running is easily heard.
Our solution also works around another problem: The out-of-production replacement relays. A modern commonly-available AC Delco relay is used as part of this circuit.
The driver has the choice of not waiting at all (turning the key all the way to CRANK (Start) immediately) or waiting the full time (11 seconds) until the hiccup and then CRANKing, or doing nothing (fuel pump cuts off 3 seconds later), or anything in between. A panic crank while stalled in traffic will always work.
We term the 11 second period the "Boost" phase, the following 300 millisecond period the "Hiccup" phase, the following 3 second period the "Back Porch phase, and all time thereafter the "Steady State" phase.
Because an electrical ground is not available at the relay connector (C-314), a separate wire feeds ground. We tried hard to work around this problem electrically and tried even harder to get a reliable, easy-to-install, and visually pleasing ground source. It was not easy; this car does not have a lot of metal interior surfaces, nor standard connectors. We settled on (and found) a suitable bolt that has reliable ground; a spade lug prevents having to fully back out the bolt in question.
Step 5: Choosing a Microcontroller
The first thing I did was to choose a microcontroller. This is a choice you have to make not only regarding what features you need but also how easy/painful the development tools are and whether it is available in "hobby" quantities or not.
Since for this project, any simple microcontroller will do, and cost is not really an issue either, a easy/"common" part with an easy development story would be best. A system-on-chip board such as a Raspberry Pi or Arduino seemed overkill. I settled on the Atmel/Microchip PIC16F18855 because of low power consumption, small size, and ready availability.
The pleasant surprise was an online web-based IDE. I was really dreading having to install and fight a clunky development system, or plug-ins, to e.g. Macintosh XCode or Microsoft Visual Studio, or such. But Microchip/Atmel actually has a web site that looks just like an IDE -- editor window, compiler window, debug window, files window, a menu bar ... crazy. You set up an account, edit your code, and save it with a filename (somewhere -- of course I manually make a local put/paste backup rather than trust it to their cloud). You then hit the compile button, and it sends you your binary as web download. Next to the IDE is also a Java applet available for download that is required for the IDE to talk to the in-circuit programmer; the applet is somewhat flaky and also requires that your Java protections be switch off. This is the only complaint I have.
The web-based IDE goes together with a $20 development board that looks like a USB thumb drive for programming. You drop your binary into the mounted USB "volume", which then causes the device on the evaluation board to be programmed. When I was ready to build some hardware, I purchased a $150 USB-based programmer that also connects via USB and works approximately the same way.
Clearly, such a solution is not something you would use for a bigger/more serious project (what if the web IDE becomes unavailable/slow? what about intellectual property security?), but for this it's perfect.
Step 6: Designing the Hardware
See the hardware description in this Instructable for the final result. To get to this point, I went in stages:
First I purchased the Microchip development board and used their online IDE to write some demo software, which quickly became refined to be the near-final software.
I then purchased the Microchip in-circuit programmer and a couple of full-size (28-pin DIP) microcontrollers. Using full-size parts and a bench power supply and tools, I got a minimal "circuit" running with my software. I then built some of the basic relay driver components around it using some other parts, some full-size and some surface mount -- I wanted to get the actual surface mount parts that I was planning to use, to prove to myself that they would work as intended, since the stakes were high for getting it wrong: I was going to make a PC board with contract manufacturing.
Once I got the hardware and software design finalized, I built a prototype in a big red plastic box, using the actual parts. This was a hodgepodge of surface mount parts taped down on a piece of paper, hand-soldered together with wire-wrap wires. It included an actual relay, with a long cable going to the relay+connector combination, so that it could actually be plugged into the car. This setup was then tested in the car. Minor changes in the hardware and software were finalized.
Step 7: Pressure Principle Hardware Description
The circuit design revolves around a Atmel/Microchip PIC 16F18855 microcontroller. We use only the most basic of its features. We use the internal oscillator mode that needs no external crystal; it has an excellent power-up-reset and brownout protection mode that we use by default -- I have never seen it glitch (not come out of reset or software hung) despite all the low voltage and rapid on/off I've thrown at it. We use the 3.3V version. R1 is per the application notes. The J5 pin pads on the circuit board are only used during/for programming.
D1 protects againsts reverse polarity and works with D2 to prevent a short and possible unnecessary fuse blow for no protective reason if D2 were to go into protective clamp mode. It is an SAE/AEC (Society of Automotive Engineers / Automotive Electronics Council) requirement that car electronics be able to survive reverse polarity, 24V jump starts, disconnection of the baterry with the engine running ("load dump"), and other such tortures. D2 is a SM6T27AY clamping surge protector zener diode intended to protect applications like this.
The diodes used for D3..D6 can all handle 1A of forward current. This was chosen over a wimpier spec because we want much more than twice the relay coil freewheel protection at D3, plus D4 is a first line of defense to the outside world, as is technically D6. We could have used the same part for D1, but I chose an extra-low-voltage-drop part for this.
We supply 3.3V to the microcontroller U2 and circuitry from the regulator U1, which can supply up to 100mA. The C1 and C2 capacitors are recommendations from its data sheet.
One of the port outputs drives transistor Q1 that drives the relay. The microcontroller otherwise could not drive the required current, plus also it is at 3.3V while the relay is at 12V. The diode D3 is the obligatory coil freewheel protection for Q1 but note how it needs to connect to the the true place where the top of the relay coil is connected, namely, J1. To connect that to the +12V post-D1 would be a mistake. The relay also has LED3 connected there as an actual "relay coil is energized" indicator.
LED1 and LED2 are driven by outputs from the microcontroller so that the software can tell the user what it is thinking: Confirmation of ECU "pump on" command input level sense, and showing when we are in boost phase.
In addition, LED1 and LED2 are connected via R7 and R8 to our +12V and +3.3V supplies, respectively, so that they glow dimly as a "background" to the microcontroller's brighter pulses. In this way, the user can confirm that we are getting +12V power from the Viper, and that the 3.3V regulator is working.
The trickiest part of this circuit is the ECU "pump on" command input, involving J3, D4, D5, R9, R2, and C3.
A simple design involving a diode pointing away from the microcontroller (e.g. cathode on the J3 side) toward the ECU's "switch closure to ground" (open collector) pad at J3, with an external or internal pull-up to +3.3V close to the micro (e.g. on the anode/RA5 side), would work. In fact, that's what I did at first.
But there's a big electrical robustness problem with that. Consider what happens if the ground supply at J2 fails (gets disconnected). When I tried that, to my horror, the circuit kept working! I traced it to a pathological ground path where the entire circuit's current would go through backwards INTO the micro's grounds (VSS1 and VSS2) and out of the micro via RA5, through my protective diode, to J3, out of J3, thru the ECU, to the car's ground. While nothing got damaged (!), and while stuff "worked", that was not a failure/"operational" mode I was going to tolerate. I would rather have the circuit stop working (relay go off) than allow such shenanigans. If the ground path is going to fail, whether at J2, or out of the Pressure Principle enclosure, or at the car, the problem should be dealt with there.
So instead, we want to prevent both current sneaking backward up/into J3 as well as a false ground path down/out of J3.
D4 prevents "current coming into the circuit via J3" (at-car wiring fault) craziness -- the only way is out. D5 prevents the "current leaving the circuit via RA5" (false ground path if J2 or car-ground failure) pathological state described above. R9 provides a pull-up: some current to travel into the ECU as well as into the PIC micro.
If the ECU is commanding "pump off", then it will not be driving J3 to ground, and so there will be voltage at the input (anode) of D5 and this at the input to the PIC micro's RA5 input; the micro will see a logic HIGH.
If the ECU is commanding "pump on", then it WILL be driving J3 to grounnd, and so there will be NO (or very little) voltage at D5 and thus RA5 and thus the micro would see a logic LOW -- almost. Consider that because there is no voltage going into D5, there is nothing coming out; OK. But it is also true that D5 is pointed in such a way that there is no forward ground drain path out of RA5 through it to ground. So that means in this ("pump on" command) state, we are floating at the output (cathode) side of D5 and therefore RA5. For that reason, the final piece of this puzzle is the pull-down resistor R2.
R9 and R2 have been carefully chosen to be complimentary and I've tried simulating a variety of resistances of J3-closure-to-GND. I needed to avoid consuming too many milliamps from the +3.3V supply but also needed to ensure noise immunity and robustness in the face of the ECU presenting some resistance (e.g. more than 1 ohm or so) in its closure-to-GND. With these values (510 and 2200 ohm), Pressure Priniciple will think the ECU is commanding "pump on" even if it presents up to about 75 ohm -- something that would never make the OEM relay click, so I can rest assured about this.
C3 is there to prevent (shunt to GND) any "detection" of any undesired RF input (like a radio station). It also functions as a bit of a "debouncer". If you want to seriously debounce, I noticed during experimentation that a 4.7uF capacitor in this place will work very nicely to de-glitch (e.g. low-pass so that only on-off commands slower than 100ms come through). I didn't think that much de-glitching was necessary here.
Or I could have just used an opto-isolator.
Regarding power budgets: The PIC microcontroller uses about 5mA at 3.3V. The 3.3V regulator can supply up to 100mA. The AC Delco relay coil uses about 120mA at 13.8V, and gets very hot. We operate the LEDs sparingly at about half power: about 10mA each. We send about 6mA at 3.3V into the Viper ECU's open-collector "pump on" output (logical output, electrical input).
When taking measurements, do not forget the 680ohm resistor that the AC Delco relay has across its coil pins, which for our purposes essentially means between +12V (J1) and the ECU input (J3). This can lead to confusing results if you forget this. Because of D4 it doesn't affect our circuit at all. I don't know why it is there in the OEM and all aftermarket relays -- is that some ploy for diagnostics so that the ECU can tell the difference between a failed relay coil vs. a wiring fault (an open) in the car's harnesses?
Step 8: Pressure Principle Software Description
The software is a simple timer loop that does not use any of the timer features nor interrupts (nor A/D, D/A, serial ports, waveform generators, etc, etc, etc).
A 16-bit timebase ("timeSincePowerOnReset_10ms") is incremented every 10 milliseonds. Starting from 0, there are defined milestones at which things happen. There are no independent state variables: All state is derived from the current time-since-power-up-reset.
Using the timebase, the variable "prepMode" is computed. It is designed to be 1 whenever we want to "artificially" turn the fuel pump on (we call this "Boost Mode" as well). It is 0 during normal steady-state operation. It is 1 during the initial 11 seconds from power-up, then turns to 0 during the hiccup, then turns back to 1 during the back porch, and then turns to 0 forevermore.
A safeguard resets the timebase back to the 26 second-from-power-up mark. In this way, after the 30 second mark, the last 4 seconds are replayed forever. This will ensure that timebase overflow will never be an issue, while keeping the loop operational as it must be to track the ECU pump command and blinking the LEDs.
Timebase overflow would otherwise occur just before the 11 minute mark: 10 ms_per_quantum * 65536 max_uint16 / 1000 ms_per_s / 60 s_per_m ~= 10.9 m.
The safeguard above also disables any possibility of returning to the boost phase after 30 seconds have elapsed from power-up. This is not strictly necessary in the program logic, but is a redundant anti-bug safety feature. This is to ensure that if the car is stalled and the ECU has disabled the fuel pump, that we don't accidentally spray fuel periodically, even if there were somehow a bug in the "prepMode" calculation above.
The "viperECMFuelCommand" variable is obtained by reading Port A, considering bit 5, and inverting. It is an active-low signal. See more discussion about that in the hardware description.
Finally, the variable "portAWrite" is starting to be prepared. We initialize it to a value of 0 (all eight zeros) and will, over the next few sections, OR in bits as appropriate. We do it this way so that we can write to Port A in one operation, not a whole bunch of different writes separated by microseconds.
The three things computed and stored to "portAWrite" are (1) the relay coil energize signal which is the OR of what the Viper is telling us and whether we are in boost mode; (2) blinking the green LED if we are in boost mode; and (3) blinking the yellow LED if the Viper wants the fuel pump to be on.
The LED blinking is simply done by "connecting the LED to" one of the ever-changing (counting) timebase bits (lower bits will change quicker = faster blinking). Note that the LEDs are steady-state on "in the background" as well but this is not done by software; see the hardware description.
Regarding I/O Port hardware analog configuration, the TRISA (Tristate Port A (1=Don't drive)) is set up so that we are using bit 0, bit 1, and bit 2 as outputs (driven). We use bit 5 as an input (not driven; we're listening). No latching needed (Latch Port A; LATA) and no analog input mode (A/D) being used (Analog Select Port A; ANSELA). We are doing our own pull-ups and pull-downs in our circuit hardware (Weak Pull Up Port A; WPUA). We do not need Schmitt-trigger (hysteresis) handling on our input (Input Level Port A; INLVLA); the ECU commands are pretty clean.
Step 9: Making a PC Board
Enclosed on this page are the CAD files that you can use with EagleCAD to create a Pressure Principle PC Board. Note the word "Disabled" in the titles -- you will have to find and customize two small places to enable functionality so as to make it that you are the actual engineer.
Also included are PDFs of the layers broken down as separate images. The scale of the enclosing dimensional rectangle is 900 mil wide by 1350 mil tall. One mil = 1/1000 inch. Equivalently, that's 22.86 mm wide by 34.54 mm tall; 41.42 mm diagonal.
I've done various little and big electronics projects off-and-on for quite a while. But I had never, myself, used surface mount components, nor laid out a PC board, nor used contract manufacturing (PCB and component stuffing). So I decided to do all 3 since they're pretty related when you're dealing with components smaller than rice grains.
Preferring to use a Macintosh, I was pleasantly surprised that the Mac no longer seems to be such a 2nd-class citizen in this arena anymore. You can download Autodesk EagleCad for free but I paid the license fee because, geez, look at the immense utility that you're getting. It takes a while to get used to the somewhat SketchUp-like user interface, but it's not too bad, and has its own kind of nice logic.
With the final design "captured", I then entered my handwritten schematic into the CAD program so that I could have a nice neat schematic to print and also to form a basis for making a PC board. I then used the CAD program to create a PC board layout, being careful to make the dimensions of my proposed board be such that it would fit in my planned enclosure. I planned the width of the board to be equal to that of the replacement relay, minus 0.15 inch of margin on both sides, so that we could make a "make the relay taller only" enclosure. It's fun to do manual routing, and the software helps you quite a bit.
The final PC board CAD design was then run through the CAD program's own Electrical Check tests and Design For Manufacturing (DFM) check tests. This resolves issues such as traces running too close together, unrouted wires, etc.
At this point I also start widening those traces that will carry a bit more current. You can use your judgement plus there are trace width calculators online.
I then chose a local PC board manufacturing house. I ran the "export Gerber files in a ZIP bundle" function in the CAD program, and sent that bundle to the manufacturer. The house that I used has their own DFM preview web site where you can upload your bundle and it will automatically send back a report of errata or success. You then make changes to your design (usually very minor) and try again.
When I was confident that the house would be happy, I printed out the PC board layout art and manually followed the traces, hand-re-creating my schematic. I did this to be as sure as possible that there were no mistakes.
You can have your house do PC boards only, or have them stuff them as well (for a substantial extra cost). Because of surface mount and because I wanted to go though the exercise, I chose to have them do the stuffing.
The other thing the PC board house then wanted was a detailed Bill of Materials (BOM), listing, for each part, the name (e.g. "C3", which they correlate with the CAD file bundle), quantity, precise manufacturer name (e.g. "Kemet") and precise part number (e.g. "T491A334K035ATCAPT3216N-L"). The CAD program can automatically produce a BOM as simply-formatted text, but they wanted it in a Microsoft Excel file anyway.
The final thing the PC board house wants is money :-) .
About a week later, I had finished (and stuffed) PC boards.
Step 10: Pressure Principle Mechanical Description
We created a Plexiglass acrylic enclosure that essentially takes a replacement relay and makes it taller by sitting "on top of" the replacement relay. We use the replacement relay's connector and replacement relay's, well, relay. The relay contact-to-connector-blade connections are left unaltered. Only the coil (solenoid) wires are "intercepted" and sent to/from the PC board.
We created a jig to help assemble the Plexiglass enclosure, so that we could make several if needed, but also to ease construction.
We used smoked high-temperature Plexiglass so that we can see the LEDs. It's important to use the proper adhesive for it. We constructed a rectangular enclosure that extends the "height" of the AC Delco relay and has the PC board mounted "above" it. The existing male connector pins on the "bottom" of the relay continues to be used (to plug into the Viper female connector) and a black 6'9" 16AWG cable to a ground lug pigtail wire to supply GND (GND is not available at the relay connector, and we do not want to require the user to cut any cables).
It is important, when assembling, to make sure any of "your" wires do not interfere in the mechanical operation of the relay, e.g. getting jammed in the contacts or moving parts.
It should be able to withstand bumps, shocks, and continuous vibration.
It should be able to withstand temperatures of up to 85 degrees C. The AC Delco relay coil generates 50 degrees C all by itself. On a medium-hot day -- even though the trunk seems fairly cool at the start of a drive -- the Viper's legendary heat generation, the hot-running relay, and the sealed enclosure, all combine to cause temperatures inside the enclosure to easily reach 65 degrees C. Do not use adhesives that can't stand the heat. Do not use hot glue. It should also be able to handle temperature cycling e.g. as if the car were parked outside in freezing conditions.
Step 11: Using the CAD Files in This Instructable
A few things have been left for you to customize in the CAD files. You need to be aware that technically you are modifying your powertrain, and so you should have decent engineering acumen. Do not proceed unless you know what you are doing and have a solid history of having built reliable, deployed projects. It is necessary to put you in the loop as an active engineer, and making these changes will do that.
Look for "See Text" comments and annotations in the software, schematic, and board silkscreen.
You will notice that the software has two places where you can adjust the functionality of the timebase, one of which is marked with "See Text", the other one is not marked. Also check how the port is written to. Adjust these places.
On the schematic and on corresponding areas of the PC board, you will notice two places in the circuit for customization. See notes in the schematic and matching silkscreen annotations on the PC board. You may want to alter those two places.
Step 12: Das Blinkenlights
What would a project like this be without blinking lights? Boring!
The LEDs are designed to give decently-rich debugging info. You can use this during bringup on the bench but also to see what is happening in-car above the noise.
The orange indicator, LED3, labeled "P" for "Pump", always shows what the relay coil is doing and confirms that the relay coil is actually getting power. We have an LED here because you can't hear relay clicking in a noisy car or shop environment. The chosen color is orange to connotate "Fire" or "Charging". Red was not chosen because that would suggest "error" or "fault" or "danger".
The yellow indicator, LED1, labeled "V" for "Viper", shows (1) that actual +12V power is coming in from the car (steady) and (2) that the software thinks that the car is giving us a "pump on" command (rapid blinking). The blinking is deliberately a "talk-back" CPU output as a confirmation of how the CPU is interpreting the input (levels), and that code is running. The steady is deliberately a "dumb" power indication. The chosen color is yellow to suggest "Imperatives from the Viper -- Viper Power On, and/or Viper Fuel Command On"; yellow is kind of a "fire" color but not as "fiery" as orange, and in my mind seemed somewhat of a "command" color.
The green indicator, LED2, labeled "B" for "Boost", shows (1) that actual +3.3V power is coming from the regulator (steady) and (2) that the software has decided to be in its "boost" mode (slower blinking). The chosen color is green to suggest "Local Power On, and/or Go".
Step 13: Bringup
When I get the PC boards from the manufacturer, the first thing I do is a careful visual inspection with a loupe or one of those inspection microscopes you can get online. They cost about $200 and are essentially a camera and screen on a stand. I look over all the parts and the solder joints. I try to follow most traces and components and know their places in the schematic. I especially check that no components have been installed backwards.
Then I use a voltmeter in the Diode/Continuity mode and check that the LEDs have been placed correctly -- not backwards. Some LEDs with some voltmeters will dimly glow when forward-bias tested this way, which is a great confidence builder at this stage.
Next, it's time to apply 12V from a bench power supply. Connect +12V to J1 and GND to J2. Current drain should be about 30mA without a relay. This is the "smoke test" moment of truth. We don't want it to smoke!
The yellow and green LEDs should turn on, steady, medium-dim-ish. If they don't, power off immediately. The yellow LED indicates 12V is flowing to where it should and that there are no shorts; the green LED indicates that the 3.3V regulator is working and that there are no shorts. Since there's no software yet, nothing else will happen.
Next, it's time to program. I connect all 5 pins of J5 to circuit clips (or you can temporarily solder wires to it, like thin wire wrap wires); the other side goes to a 5-pin header which is plugged into a Microchip, inc. "PicKit" in-circuit programmer. The other end of the programmer is USB that connects to your computer. You then run Atmel/Microchip's online web-based IDE and Java software to program the device. Sometimes the PicKit firmware is first updated; a boot loader then (apparently) written to the PIC16F18855 on the PressurePrinciple board; and finally your software itself. The Pressure Principle program takes about 2% of the code space even with the boot loader overhead. By the way, you do not notice any initialization delay when coming out of reset; I say boot loader, but there doesn't appear to be anything clunky going on.
Code will not start running until you disconnect the PicKit from the PressurePrinciple board.
When code starts running (on reset or power-up), the green LED should blink for 11 seconds, hiccup, and then blink for another 3 seconds, and stop blinking and go back to dim steady-state.
The next step is to do a full-up test. Power down. Connect the relay (coil) between +12V and J4. Arrange for a momentary test switch/contact between J3 and GND.
Make sure J3 is not connected to GND. Power up.
The relay should click on, the amber LED should turn on, the green LED should blink, and the yellow LED should be steady. This should stay like this for 11 seconds.
Then, the relay and amber LED should turn off for a hiccup (300ms) and immediately turn back on. This will stay for another 3 seconds.
Finally, the relay should click off, the amber LED should turn off, and the green LED should stop blinking. Things should stay this way.
Now connect J3 to GND. The relay should click on and the amber LED shoud turn on. And vice versa. In fact, from this point forward, the relay and amber light should track whatever J3 does. Whenever J3 is "on" (connected to GND), the yellow LED should blink rapidly.
If J3 is "on" (connected to GND) during the "boost phase" green LED blinking, that should have no effect. And the 300ms hiccup should not happen if J3 is "on".
In short, whenever J3 is "on", the relay should always be "on", bar none, "boost" phase or not.
And whenever J3 is "off", the relay should be "off", with the ONLY exception being during the green-blinking 11+3 second "boost" phase.
After the boost phase is over, the relay state should always faithfully track the J3 input.
There should never be anything weird happening, such as the 300ms hiccup or software event restart, at the time when a 16-bit counter would otherwise roll over, which is after about 11 minutes as described above.
Step 14: Assembly
Using the jig as described in the Mechanical Description, an enclosure is constructed.
The AC Delco replacement relay is opened up. A wire is connected to siphon off (connect in parallel) the +12V (plus) side of the relay coil, which goes to J1 of the PC board.
On the minus side of the relay coil, the coil is disconnected and a wire is connected to it so that that side of the coil is exclusively routed to J4 of the PC board.
The blade pin that was formerly connected to the minus side is now routed via a wire to J3 of the PC board.
The incoming ground 16AWG pigtail wire entering the acrylic enclosure is routed to J2 of the PC board.
The PC board is mounted portrait-wise "above" the relay. It is vitally important that the wires do not interfere with the mechanical operation of the relay, even when subjected to shock and being mounted in any orientation with respect to gravity. To this end, we actually replace the "roof" of the relay, with a small hole drilled in it where the 3 wires exit, so that wires will not bunch and press on the relay contacts.
Step 15: Testing & Installation & More Testing
Test, test, test. I cannot emphasize this enough. One of the 3 boards I got back from my first run at the (local, in Silicon Valley!) PC board turnkey manufacturer had a subtle defect: Under elevated temperature, a pin on one of the ICs came loose, causing a failure during our first test drive.
I did not want to do my own surface mount soldering, so I opted for full assembly: both PC board fabrication and component stuffing. That's great, but I should have known that vendors of critical applications carefully test items that other vendors supply, themselves, before integration, and I should have done the same before testing it on the road.
So you have to test -- under elevated temperature, after putting it in the freezer overnight, at all kinds of voltages, and under shock e.g. by whacking it with a screwdriver handle.
My testing protocol has been as follows:
1. Do the bringup and assembly as described above.
2. Do a full functional test at 12V. Test it for a full run of 15 minutes looking for functionality and timer overrun. Then run it at 8V and all should still work (with weak relay click). Then run it very briefly at 16V. Do a "power supply glitch" test. Make sure it comes out of reset/brown-out each and every time. Finally, leave it running at 14V.
3. Let it run at 14V for a long time like 1-2 days.
4. Put it in the freezer overnight.
5. Get it hot by putting it in a box and blowing on it with a hair dryer. I had a small hole in the enclosure and put a temperarture probe in it and get it up to 60-65 degrees C for a while. Interrupt a few times with tests of functionality.
6. While still hot, do a "smack test" by hitting it with the handle end of a screwdriver at a rate of several times per second. Rotate it 90 degrees and repeat. This simulates car vibration.
6. Put it in the freezer overnight again.
7. Test it one final time on the bench again.
8. Install it in the car. The connector name is C-314 and use the left back composite assembly attach bolt for ground; see photos.
9. Do a "driveway" test where you turn on the ignition to engine mode but don't crank it. Let it go thru the boost & off cycle. Turn the car off.
10. Do a normal car start, and go for a test drive around the block in residential streets.
11. Go a longer hour-long trip on surface streets (no freeways). Stop a few times in parking lots and re-start. Hopefully almost stall the car a few times to test against glitching. Park the car overnight.
12. Go for an all-day drive, preferably a bumpy affair in stifling heat.
Step 16: References
Relay (use for female connectors for testing only; you cannot really use these relays because they are hard to disassemble): Search for: B01N66W2XF
Search for: Koolertron-Wireless-Microscope-Adjustable-Recorder
Relay (for replacement/use):
Search for: AC Delco 15-50961 19189419
Software development tool for microcontroller:
Evaluation board for microcontroller:
In-circuit programmers for microcontroller:
CAD for creating schematics and PC boards:
(I recommend you get Eagle Standard and pay the modest license fee)