Manifold Absolute Pressure Sensors – Early Mopar MPI

There are lots of stories an old Jeep can tell. Ours is no exception. Given that it lives in urban AZ today, getting it past the required IM147 smog inspection (required every 2 years) can be a challenge, despite careful upkeep. That’s certainly the case this cycle, and I’ll have more to discuss later, when I work out a few things. This post describes one sensor check.

This XJ has an OBD-I Mopar MPI setup, some call this an “H.O.” injection setup, as opposed to the Bendix-Renault setup that Jeep had as part of their AMC legacy, before Chrysler bought AMC. Not certain, but I think the HO OBD-I MPI setup ran from 1991-1995, after which it went to OBD-II. Ours is 1994.

In any case, there’s a lot less information available for troubleshooting an OBD-I system than for later OBD-II systems. Therefore, checking sensors is a common problem, without a lot of supporting information to help. That’s something I want to try to fix.

The (M)anifold (A)bsolute (P)ressure Sensor

Fuel control for electronic fuel injection requires a number of sensor inputs. A key sensor input is the MAP sensor, telling the ECU how much air pressure exists in the intake manifold (We think of this as a vacuum, and in a non-boosted engine, it is. Strictly speaking, it is a pressure, just one that is less that the external air pressure unless air is pumped in somehow). The ECU reads manifold pressure from the MAP sensor, combines this throttle position and load in order to compute a mass airflow, corrected for density with information from the IAT sensor. That allows it to compute an appropriate fuel flow, which can be fine-tuned with the oxygen sensor whenever the ECU is running closed-loop (idle, steady cruise).

If the MAP sensor misbehaves, or gets a false pressure indication (e.g. Vacuum leak), then it’s going to report an incorrect pressure, and the fuel delivery will be “off”…garbage in, garbage out. Knowing what it’s telling the ECU then becomes important.

But, there’s not a lot of data to support diagnosis. The Mopar FSM says that the MAP sensor should report 1.5-2V on the “B” pin at hot idle. Without their scan tool, it’s hard to know more.

The Delphi 1-Bar MAP Sensor

…is what I think is used here. It was once common for non-boosted engines, and I’m reasonably sure it’s what Chrysler used in this application.

Inside, it uses a small silicon diaphragm balanced against a sealed vacuum on one side. Air pressure distorts the diaphragm; this can be measured. The sensor is supplied 5V plus a ground, and the measured pressure is output as a voltage on the center pin. This voltage feeds manifold pressure to the ECU.

Information on them is scattered around the internet, but the most useful data I found came from here. Notice that he references the 2 and 3 bar sensors, but there is still useful data on the 1-Bar sensor here, reproduced in this table:

mapgraphjl2

The second and third columns are what we really care about, showing the output voltage for a given pressure. If our sensor doesn’t match this curve, then we can suspect a problem. (Also note that error band data for the 1-Bar sensor is missing, this would be useful to know). It appears to be basically linear.

So, we can just hook up a vacuum source and meter and test it, right?

Basically, yes, but there are a few things to watch for.

  1. Pressures here are given in Kilopascals. A gauge may be marked in inches of mercury, if so, you’ll have to apply a conversion factor.
  2. The sensor measures against near-vacuum. You may have difficulty pumping this low. Also, you’re not likely to have 105kPa surrounding air pressure at your test location. Unless you’re at sea level, it is likely to be less than this, and this has to be factored into your measurement.
  3. The ground connection at the sensor is “sensor ground”; it may not be exactly the same as the other grounds in the system. You may be able to ground to the engine block and get away with it, but the ground at the sensor is the correct one to measure against.
  4. A cheap gauge is likely to have some error. Just be aware of this.

With this, I collected and interspersed some data from my own sensor just to see if it was relatively close to what was published. Here’s what I came up with:

Pressure Pressure Delphi Sensor
kPa inHg Reference Under Test
105.0 31.01 5.00
100.0 29.53 4.75
97.4 28.76 4.68
96.0 28.35 4.50
91.0 26.87 4.25
88.9 26.26 4.06
86.0 25.40 4.00
81.0 23.92 3.75
80.5 23.76 3.72
77.1 22.76 3.60
77.0 22.74 3.50
73.7 21.76 3.36
72.0 21.26 3.25
70.3 20.76 3.19
67.0 19.79 3.00
66.9 19.76 3.05
63.5 18.76 2.86
62.0 18.31 2.75
60.1 17.76 2.70
58.0 17.13 2.50
56.8 16.76 2.50
53.4 15.76 2.40
53.0 15.65 2.25
50.0 14.76 2.10
48.0 14.17 2.00
46.6 13.76 1.90
43.2 12.76 1.76
43.0 12.70 1.75
39.8 11.76 1.55
39.0 11.52 1.50
36.4 10.76 1.28
34.0 10.04 1.25
33.1 9.76 1.15
29.7 8.76 1.02
29.0 8.56 1.00
26.3 7.76 0.85
24.0 7.09 0.75
22.9 6.76 0.74
20.0 5.91 0.50
19.5 5.76 0.42
16.1 4.76 0.30
15.0 4.43 0.25
12.7 3.76 0.10
10.0 2.95 0.00

Which, looks as if it lines up pretty well, really. Depicted graphically:

1-bar-map-sensor

Which looks reasonable to me. Error band information would be useful, but I don’t see any glaring exceptions here.

“Redneck Test Methodology”

Note that my data starts at 97.4 kPa, not 105. Why?

Effectively, that was the local air pressure in my shop that day. Remember, the sensor is comparing the air pressure at the sense port against an ideal internal vacuum. That translates into a voltage that’s representative of the sensed pressure. Without any applied vacuum, it’s just a voltage that corresponds to the local air pressure. 105kPa would have to be very near sea level pressure (maybe even slightly below).

Two factors will affect the local air pressure:

  1. Altitude
  2. Weather

If you know both, you can compute the correction factor for your local elevation.

First, check your local weather for a nearby barometric pressure. As published, this pressure is relative to sea level, the actual pressure will be less than this at your elevation. We need to know this to start. In the U.S., this is likely to be expressed in inches of mercury, other nations will likely use a metric measure.

Once we know this weather-specific value, we can reduce it to the local pressure by subtracting the difference for altitude. This change in pressure is a slight curve, but at low altitudes, we can use a simple linear rule-of-thumb and get away with the approximation in most cases. That rule of thumb is: 1″ of mercury reduction for each 1000′ of altitude.

At the time of my test, the pressure was reported at 30.15″. My shop is approximately 1390′ above sea level. Using this rule of thumb, the pressure decrease for my altitude is 1.39″, so 30.15 – 1.39 = 28.76″ of mercury at my location. This is the highest pressure I could read that day, and each inch of vacuum I applied to the sensor with my hand pump (which is calibrated in inches of mercury of vacuum) would reduce the pressure on the sensor by that amount.

(Keep in mind that the vacuum gauge on your pump is comparing the difference between the pumped pressure and the external air pressure, or zero if not connected to anything.)

Using the same process, you should be able to use a small hand pump yourself and confirm if your MAP sensor is telling the truth, or if it has degraded for some reason.

By the way, ours appears to idle at around 16-18″ of vacuum under these conditions, with no identified vacuum leaks. That calculated to a MP of 12.76-10.76, or right around 1.5V at the sensor. (Hooked to an oscilliscope, you can even see the intake pulses in the sensor output).

Mine looks to be reasonably close to spec, using this test method. That suggests my problem is elsewhere, and that will be the basis for another post…

mcHF Unit #1 / Update #2

So, some 50-60 hours of assembling later, we get something that looks like this:

IMG_1586
mcHF Unit #1 First Listen

The general purpose builder’s axiom:

  1. The things you expect to be hard turn out to be easy.
  2. The things that you expect to be easy turn out to be unexpectedly hard.

To that we could add a 2a: “…or they consume all of the available time”.

Being a noob with SMT, I thoroughly expected to be chasing solder faults for weeks. That didn’t occur. In fact, after quite a bit of experimentation, I haven’t found a single fault either in the receive or transmit path. I don’t know that everything is optimal yet, but all bands do seem to function.

(I did make a mistake on one of the PA transformers, but caught it and reworked it before adding the PA finals, which I only did after I knew everything else worked. Excepting the PA, I assembled the entire unit over the course of a few weeks. Many will build in stages, testing as they go. I chose not to. I can’t explain why…)

That doesn’t mean that bringup was flawless, however. What I did have issues with was tools and software. The basic bring-up is going to look like this:

Step #1: Basic power-up smoke-and-flame check. No smoke/flame/sparks? Proceed to…

Step #2: Get a bootloader into the processor’s flash.

Step #3: Using the bootloader, flash the operational firmware image.

Step #4: With functional firmware, work everything we can to check/fix faults.

Step #5: Parameterize operation for this specific unit. “Alignment”, but using data instead of an insulated screwdriver.

Then, we should be ready to radiate.

In practice, I ran into driver and connectivity issues that made the bringup a bit of a debugging exercise. Having witnessed others run into similar problems, instead of glossing over it, I’m going to write up a little more detail in some subsequent posts which I hope will be a useful resource for others. Look for those soon…

 

 

mcHF – unit #1 / update #1

When I started this project, I acquired 2 board sets; one to use as an everyday unit, and another to hack on. There is substantial potential in this design through software, and the cost per unit is reasonable, so obtaining a pair seemed wise. In these last few weeks, I’ve been assembling the first of the 2 units, the second to come later. That’s what this post is about.

Acquiring parts is the first task (unless you purchase the full kit from Chris; I elected not to). The project has origins in the UK, and the original Bill of Materials mostly references part numbers as sourced by Farnell/element-14 in Europe, with much of the remainder eBay sourced. Here in North America, most of the Farnell catalog is available through Newark/element-14. Yet, most of the BoM is fairly standard stuff available from other more familiar sources such as Mouser, where I sourced most of mine (and who I’m used to dealing with…heck, with Grant Imahara as a spokesperson, you have to be in good company…).

There are some exceptions and single source items, such as:

  • HY28B LCD displays – single source (have to come from China, required about 3.5 weeks via Singapore Post registered service). I ordered 3; one as a spare, because once these become unavailable, I’ll be well and truly stuck.
  • Si570 programmable oscillator – kind of the “heart” of this radio – this seems to only be available via DigiKey. I have not ordered just yet.
  • Mitsubishi RD16-HHF1 Power MOSFETs for the transmitter final amplifier. There are a small number of North American resellers of these, and they’re not all that cheap. Fakes appear to be very common on eBay.
  • Inductor cores – available via Amidon, Palomar, or others. Some, I already had in my possession.
  • The specific 3.5mm connectors specified for this PCB needed to come from Newark (using the Farnell numbers), no other equivalents appeared to match the footprint.

The photo above shows the state of the boards as I currently have them, with approximately 20-25 hours invested in assembly so far. Most assembly is complete with a few exceptions:

  • No display yet: I’m thinking of putting it in a socket, because of the damage that could be done if it needs to be removed. It connects using an uncommon 2mm pin pitch (instead of the typical 2.54mm/0.100″ header pitch). Sockets are available in that size, they’re just uncommon.
  • No encoders: I’d prefer to solve the display socket question first, because encoder shaft length might be tied to socket height.
  • No pushbutton switches on the UI. They’re backordered.
  • Have not wound the BPF/SWR inductors yet; I don’t have them all.
  • Do not have the finals yet, and I didn’t install the driver transistors yet; I think I’ll wait to get the receiver and UI working first.
  • No relays for the BPF.
  • I still need to get the Si570 oscillator. It will be difficult to solder correctly, so I’ve left off the nearby passives to make sure I have room to heat it well. Many builders report trouble soldering this 6-pin 5x7mm QFN part, which is not at all surprising; it was meant for wave soldering. So, I want to take some care with this.
  • No serial EEPROM on the UI yet. Early builds of the firmware didn’t use it, but newer ones do.
  • Not sure if I want to use the stock 30-pin header for the UI-RF board interconnect, or rig up something allowing more space between boards. They stack to 0.425″,which is just enough. However, I might want enough space between the boards for a metal sheet for RF quieting reasons, and that may require more space.
  • There are still some optional component value selections from recommended mods, which I need to make final decisions on.

This is my first exposure to SMT assembly at this level; I’ve done minor rework to SMT before, but never assembly on this scale.

For assembly, I’m using a simple temp-controlled soldering station with a fine-point conical tip for most assembly (using .015 67/33 flux-core solder wire), and it’s working fine for most things. It took a little practice to get good quality joints, starting with the larger pitch SO-x chips, working my way up to the 100-pin LQFP CPU. That one took about 60 minutes to pin down clean one pin at a time (I didn’t like the drag method myself). I did bridge a few pins, but they cleaned up OK.

A friend lent me an unused hot air pencil for rework; I haven’t needed to use it so far. For unit #2, I may use it for some of the assembly.

Of course, I haven’t seen the unit run yet…until I do, no claims about my quality of workmanship…

I should note, it’s certainly not a project for a first-time builder, although it could be accomplished by a first timer with a little coaching, I think. It is time consuming, and there is potential for difficult-to-detect/correct mistakes in many places. However, if you’ve built a few things before, you’re patient, and are ready for a challenge, it’s not so bad. The boards were laid out with room to spare in most places, and most of the passives are 0805 dimension; not too small for manual placement. In the future, SMT is what we’ll be doing for most everything; learning to deal with it is just going to be a requirement.

More to come after I make some decisions, and finish a few other tasks. Until then…

 

This Old Jeep – Background

Lots of folks drive used cars. I, on the other hand, have this:

img_1478
That’s a 1994 Jeep Cherokee “XJ”, built in Toledo in June of 1994. It has been a trusted member of our household since November 2005. Today, it is 236,000 miles young and counting. Most days, it’s just simple transportation. Others, it’s a recreational gateway; or a platform for escape. Somehow, despite 20 years in the “red-light-running” capital of the nation, it’s still intact. A survivor, if you will (and let’s hope it stays that way).

It is far from perfect. The paint is eroding away from 20+ years in the southwestern sun. The headliner is disintegrating and needs replaced. The driveline is noisy and clunky from wear in the transfer case and differential. There’s an engine-vibration squeak somewhere in the front end that I cannot isolate. Engine instrumentation is of questionable trust. Leakproofing the engine/transmission/driveline are never ending tasks. Oh, and the drivers seat is utterly and completely shot.

In short, if one wants a rolling collection of mostly harmless puzzles and projects with a secondary purpose of transportation, it’s perfect. And that’s why I’m writing about it.

Most old cars are just old cars. But there’s something about old Jeeps that transcend time. Sure, a brand new Wrangler is quite a refined improvement over the CJ-series. But the CJ, imperfect as it was, speaks of fun and freedom over the decades with a fold-down window, canvas top, and no doors. You’ll sunburn, freeze, bake, drown, and yet smile most everywhere you go in it. The XJ is the same, yet different; it trades the topless joy of the CJ for utility, yet it’s simple, light, and goes everywhere in the bargain, while remaining affordable, simple, and above all, fun. Despite it’s flaws, it exhibits this “let’s go” personality that’s irresistible. Like the CJ, it’s easy to fix, and parts are rarely an issue (although good quality parts can be a problems).
They used to be thick around here; now, the few that still exist are modified or pampered. Owners will wave at each other (“hey, another one lives!”). There’s little else like it that can replace it’s go-anywhere utility and practicality and personality. So I’m going to keep it awhile yet. Consider it a challenge…

mcHF – a.k.a. what I wish I’d done

90 years ago, amateur radio operators built all their own stuff. There wasn’t any other way; no one would or could do it for you, and one really had to be committed to build a station with the technology of the day, not to mention the costs involved. You had to understand how every component worked, and how to make a radio “system” work with minimal to nonexistent test equipment.

After WWII, more commercial gear became available, and useful stations could be cobbled together using surplus military gear. An operator didn’t have to build from scratch anymore, but they did still have to understand their gear in detail so as to make it work within their legal operating bands.

Kits were still an option into the 60s and 70s, as tube gear transitioned into the semiconductor age. Perhaps an operator didn’t understand how the equipment worked at the outset, but by building it, he would at the end. Kits are a difficult business model, however. If your customers have trouble putting your products together, it will cost you in terms of technical support, and in terms of reputation. Because of this, and perhaps because of attention span compression in the modern age, kits come and go.

From the 70s into the 80s, amateurs who built their own gear (and who truly understood their own gear) became increasingly rare. So many simply purchased commercial gear and became “appliance operators” as the options declined. More educated and motivated operators might fix broken gear as a way to build a station cost-effectively. Into the 90s, the transition into higher levels of silicon integration and surface-mount technology made the equipment nearly unserviceable except for the most committed folks.

In the early 21st century, though, bright spots are entering. The internet makes all sorts of information accessible to anyone that wants to look for it. Open source software (where the source code and licensing are available to anyone that wishes to work with it), and the culture that came with it, opened the door to open source hardware. EDA/design tools are now sometimes available for free, whereas they used to cost monumental amounts. In short, for those that wish to invest themselves into Making Their Own Stuff, it is now possible in ways not possible before. Still, it does require an investment of self to succeed.

Example: mcHF, started by Chris, m0nka, in the UK, and supported by a cast of others. They’ve designed a small, SDR centric HF rig that you can build if you’re willing to invest yourself a little. The design is released under non-commercial usage constraints, and PCBs are available for nominal cost. In short, it’s a reasonable way to get exposed into the current state-of-the-art in “smart” radio technology.

I’ve been watching the project for several months now, and finally decided to dive in, with 2 pairs of boards (one pair for a working radio, one to hack on), arrived yesterday:

IMG_1522
mcHF RF and UI Boards

Design-wise, this is the kind of project that, if I had the time, I’d love to have undertaken myself. On the other hand, my engineering background is more software and systems with a little RTL thrown in; even though I understand how the hardware works, I’m not sure I’m up to designing one from scratch with this technology. Troubleshooting/modifying/improving it, however, may help me learn enough to cross that design threshold. Besides, it looks like fun.

What’s compelling about mcHF is that it’s an SDR design; that is to say that the modulation/demodulation/filtering (all the “magic” radio stuff) is done in software instead of captive hardware. This does two things; it reduces the cost and complexity, while enabling changes or improvements in functionality without requiring hardware redesign.

(Ironically, I spend a lot of my professional time with software, and I dabble in this space because I want the distraction of playing with hardware, not software. Go figure…)

I suspect that the future of HF operating is really in digital modes; the really interesting and useful future things will happen in digital, and this is just the kind of open platform to make hacking in this space possible.

So, I’ll try to work on one (actually two). Watch this space…

If it’s not yet broken, it soon will be.

What is this all about? (Not that I honestly expect the question…)

I became an engineer by accident. It’s not a profession I actively chose, rather, it found me indirectly one day when I wasn’t really looking for it.

Now, that’s not entirely true, either. Since I was old enough to autonomously perambulate, I’ve been disassembling and (usually) reconstructing stuff. Sometimes changing it for the better. And, oftentimes, not. It’s not something that can be helped or amended; I’ve done it for five decades, and I will continue to. It led to what became a career, even when I didn’t expect one.

I tinker. In a word, it is just what I do.

My other blog was originated for aviators. I love being an aviator; it defines and qualifies my identity. I dearly wish I could do more of it. Yet, tinkering, indirectly so, pays my bills, and enables aviating. That won’t change. So, maybe I should write some about it.

Examples and conditions of my obsession:

  • I drive old stuff that I maintain myself. There’s an economic basis for that, but also, I enjoy the challenge of keeping it on the road.
  • I work on my own airplane as much as 14 CFR Part 43 allows me to. I trust my life to the machine, so I want to know it inside and out. (I wish I could build my own aircraft, but the spare time to do so does not exist today. Someday, that could change.)
  • I’ve held an amateur radio license for quite some time now. I don’t talk on the air much, but I love fooling with the equipment.
  • In my college years, I was a part-time musician. I miss it. I mostly taught myself to play with the help of a few friends, because I was compelled to find out how to do it myself. I find it easy and wonderful to get lost in music, whether I’m making it, or someone else is.
  • My wife and I are building a second home, as much as we are able to, by ourselves. And we’re thankful we did not physically wait much longer to begin this…
  • Oh, and I still get paid to help define the intellectual property that goes into large scale microchips.

For whatever it’s worth, writing always helps me to clarify thoughts and find a sensible path. I need to do more of it. So, when I tinker, on any of these things, perhaps I should talk about it a little more. Maybe it’ll help others solve problems. Maybe it will inspire. Maybe it’ll help me think things through. Maybe it will do none of this stuff. I don’t know.

But, for whatever reasons, this may just become my soapbox for all sorts of other non-aviation related things that I do or think about. Let’s see where that leads.