MAP sensor "adapter"

Post Reply
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

MAP sensor "adapter"

Post by abecedarian »

Some may be aware, others may not, so some "history"....

I've been toying with an idea initially intended to allow alternate MAP sensors to be used with the ECU my motorcycle uses. Replacement sensors for these bikes are mostly non-existent, or cost far too much than a used sensor should, as they were only made for two years- 1982 and 1983. This lead me to the idea of 'translating' one MAP sensor's output in order to emulate another.

The bike is an '82 Honda CX500TC and its EFI system was the first step taken in Honda's PGM-FI system. It runs alpha/N within a certain throttle position range then switches to speed/density at another range. The 500T used an external ignition controller in 82, and it's successor, the 650T integrated ignition within the ECU but was otherwise mostly the same. A group of MAP sensors, 4 in the 500T and 3 in the 650T (ignition change reduced the number of MAP sensors required), measured barometric pressure and manifold pressure both less than and above 1 bar, and adjusted fuel accordingly; the 4th sensor on the 500T adjusted ignition advance.
MAP-DEC282013-BRD.jpg
MAP-DEC282013-BRD.jpg (107.57 KiB) Viewed 23664 times
What I have is one op-amp to scaling the 5v output from the ECU and MPX4250AP MAP sensor to 2v5 to be sampled by a 12 bit ADC, a 12 bit dual DAC to output two voltages, and another op-amp sampling the DAC outputs for control / accuracy. My ECU's required accuracy is +/-0.2V and it seems I can achieve better than +/-0.02v accuracy with the DAC being used. Also, there is a provision for one of the 'cheap' BMP085 modules to be used as a barometric pressure sensor and temperature compensation (when the firmware is written and supports it). The MCU, in my case is a $12 MSP-EXP430F5529LP running at 25MHz, and the dev board itself will provide USB connectivity for programming via USB device and monitoring via USB back-channel / serial port.

I would appreciate comments, suggestions, criticisms and even assistance in coding.

Thank you.
You can lead the horticulture but you can't make them think.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: MAP sensor "adapter"

Post by kb1gtt »

Long time no speak, good to see you around.

I forget the details of your bike. I seem to recall the existing sensor was a pressure sensor, not a flappy paddle, and not the hot wire thing. So it's a MAP not MAF sensor. Is that correct? Do I also recall you had multiple sensors, not one? Where do those connect on the bike? I seem to recall you had a schematic for the bike, can you post that? I'm also not seeing the forest from the tree's, is that duel row header for a Discovery board? Do you have a KICAD project you can post to show the schematic and other such details? Have you considered using Seeedstudio's OPL library such that they can populate the boards? The board i just have them do cost $30 that was $10 for the board and components, then $20 assembly fee.
Welcome to the friendlier side of internet crazy :)
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: MAP sensor "adapter"

Post by abecedarian »

G'day Jared. ;)

You're right- it's not MAF or VAFM based air metering.
The 500T has 4 sensors, the 650T lacks the Pign for reasons mentioned earlier-
1) P1 = barometric, sourced near the air filter
2) P2 = boost sensor, sourced from the plenum / throttle body
3) Pb = vacuum sensor, sourced from the plenum / throttle body
4) Pign = vacuum / boost sensor, sourced from the plenum / throttle body

Electrically, P1 & Pb have identical outputs in relation to vacuum; P2 and Pign outputs are electrically identical as well with regards to vacuum / pressure; though the Pign sensor has a 12v source it's output is in the 0-5v range, implying it has an internal regulator. Essentially, it's "speed / density" below a pre-defined throttle opening angle and "alpha / N" with boost compensation above that angle. There's a PDF with a basic run-down of the EFI system here. *Warning- 18+ MB.

The MCU board this is intended to attach to is this one; 25MHz, 128K flash/10K SRAM, 12 bit ADC, USB, SPI, IIC/I2C, 32 bit hardware multiplier, on-board emulation / programmer with built-in USB back-channel serial device.

I haven't committed to the board design yet so haven't sought pricing.

Bike schematic:
Low-res schematic
Low-res schematic
CX500T_WiringDiagram_reduced.jpg (190.55 KiB) Viewed 23651 times
Board consists of MPX4250AP 2.5 bar pressure sensor, MCP4922 12 bit DAC, two AD8656 op-amps and supporting components and 3v3 LDO to power the MCU. DAC is rated -40 to 125C. Op-amps are AEQ100 qualified and buffer the ADC inputs and are configured to 0.5x gain since the MCU runs at 3v3. Power for the board and MCU is sourced from the ECU's internal regulator. Total system current draw (including MCU board) is anticipated to be under 200 mA; it's theorized that I can draw over 500 mA if necessary.

I'm contemplating a 3rd op-amp at unity gain to buffer / isolate the outputs from the DAC but haven't seen the proof there's a need for it.

Operationally, the unit will (hopefully) sample the 5v0 rail, the MAP sensor and if included the BMP board, and determine what voltage(s) to set the DAC to output. It will also sample the DAC outputs to verify they are correct and can alter the DAC outputs if necessary. The DAC is controlled via SPI and uses 5v0 for its supply and output voltage references. Support for near real-time monitoring of the unit with a PC is planned as is updating the tuning. I say "near" real-time because USB serial takes time so it can't keep up with the MCU.


Although this is oriented at my motorcycle, it could theoretically be used to provide a programmable, tunable MAP sensing system to many MAP equipped vehicles. With dual-outputs, it could be set up to allow a piggy-back EFI system over a stock ECU: program one output to give 0-1 bar signal to the stock ECU and full signal to a piggy-back controller for instance.

Sorry, no KiCad- I'm using Eagle.
Board schematic:
JPEG of schematic
JPEG of schematic
MAP-DEC282013-SCH.jpg (112.03 KiB) Viewed 23651 times
You can lead the horticulture but you can't make them think.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: MAP sensor "adapter"

Post by AndreyB »

First of all: OMG, I did not know there was such a thing as turbo bike!

Next question: does it have to be a digital device? If both the original Honda sensors and the ones you are looking to use are linear, why not make an analog signal conversion? I am all for digital, but it looks like here this might be simpler?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: MAP sensor "adapter"

Post by abecedarian »

russian wrote:First of all: OMG, I did not know there was such a thing as turbo bikes!
Many people don't know. They never caught on, insurance was outrageous, and non-turbo bikes' tech caught up quickly.
Odd fact: stock Honda CX650T versus stock Hayabusa... the 650T can out-run the 'busa from 60 to 120 MPh in a 'top gear throttle roll on'; the 650T runs out of gearing.

Honda (CX500TC and CX650T),
650T (500TC similar, but different colors):
Image

Suzuki (XN85),
Image

Yamaha (Seca)
Image

Kawasaki (GPz750)
(note- the intercooler seen behind the front wheel is not stock)
Image
Next question: does it have to be a digital device? If both the original Honda sensors and the ones you are looking to use are linear, why not make an analog signal conversion? I am all for digital, but it looks like here this might be simpler?
I chose digital because it seemed easier than trying to work an analog circuit to adapt a sensor to the bike.
Also, digital can be 'tuned', as I mentioned, and there are people using these bikes for land-speed racing so being able to tune it is a plus.
You can lead the horticulture but you can't make them think.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: MAP sensor "adapter"

Post by kb1gtt »

I would think an early item you need to figure out is what signals they provide over a variety of pressures. Once you know those graphs, then you can figure out if you need CPU or not. You might find the MPX series of chips are good enough as they are now. I believe you are looking to do something with P1, P2 and Pb in the schematic. With out knowing what voltage you need to make with what pressure, you're going to be guessing either in software or in hardware.
Welcome to the friendlier side of internet crazy :)
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: MAP sensor "adapter"

Post by abecedarian »

kb1gtt wrote:I would think an early item you need to figure out is what signals they provide over a variety of pressures. Once you know those graphs, then you can figure out if you need CPU or not. You might find the MPX series of chips are good enough as they are now. I believe you are looking to do something with P1, P2 and Pb in the schematic. With out knowing what voltage you need to make with what pressure, you're going to be guessing either in software or in hardware.
Mostly taken care of:
Image

For the involved sensors, the pressure to voltage transfer functions have been calculated:
P1/Pb: Vout = (0.036 * kPa) - 0.103
P2/Pign: Vout = (0.020 * kPa) - 0.830
MPX4250A: Vout = Vsupply * ((0.004 * kPa) - 0.04)
You can lead the horticulture but you can't make them think.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: MAP sensor "adapter"

Post by abecedarian »

Might be worth noting the MPX4250A function was taken from the datasheet Freescale provides and the P1/Pb and P2/Pign sensor functions were derived from the factory service manual and test points (pressure versus volts) it provides and extrapolated to be linear functions. It is possible the P1/Pb and P2/Pign sensors are non-linear hence another reason to use digital emulation as opposed to analog conversion.

Also, though the P1/Pb function plot stops just above 100 kPa, there is no reason to assume they are saturated and limit their outputs above ~100 kPa ... that's just where I decided to stop plotting the line. There's no reason to assume they do not output up to 5v0.
You can lead the horticulture but you can't make them think.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: MAP sensor "adapter"

Post by abecedarian »

Another graph showing about the same thing I did but from another CXT owner but based on the obsolete MPX4250 (not 4250A):
Link since the image gets chopped by this forum.

And a little 'breadboard' testing:
Image Image

AD = value reported by the ADC;
kPa = calculated pressure based on ADC;
MAP = calculated voltage from ADC;
P1 = calculated voltage to be output by P1 sensor;
P2 = calculated voltage to be output by P2 sensor.
Last edited by abecedarian on Mon Dec 30, 2013 3:08 am, edited 2 times in total.
You can lead the horticulture but you can't make them think.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: MAP sensor "adapter"

Post by AndreyB »

abecedarian wrote:It is possible the P1/Pb and P2/Pign sensors are non-linear hence another reason to use digital emulation as opposed to analog conversion.
From the catalog of five to ten MAP sensors in FreeEMS it looks like they are all linear. Could it be something to do with the way they all work physically?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: MAP sensor "adapter"

Post by abecedarian »

russian wrote:
abecedarian wrote:It is possible the P1/Pb and P2/Pign sensors are non-linear hence another reason to use digital emulation as opposed to analog conversion.
From the catalog of five to ten MAP sensors in FreeEMS it looks like they are all linear. Could it be something to do with the way they all work physically?
I would think the sensors would be linear, but the sensors I'm trying to replace were made by Hitachi and no longer available, and not used on any other vehicle, so I can't easily test.

And sorry for editing the post above. I wanted to add a few pics.
You can lead the horticulture but you can't make them think.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: MAP sensor "adapter"

Post by kb1gtt »

Do you know the response time of the existing sensors? The MPX series has a certain delay I think it was 1mS. Do you know the delay of the existing sensors? You may need to add some delay or filtering to get the same signals. If the MPX has a faster response time, the extra noise might cause problems. If it's just a y=mX+B scaled to another y=mx+b, that could be easily done with an op-amp or two. However if you have to make some adjustments to the dynamics, or if you expect to need to change the scale dynamically, then I can see a need for the MCU.

I think I'm missing something. I don't see the Pb in your schematic. I only see one sensor. I can see how one sensor can be used to generate P1, P2 and Pign.

Also why the op-amps on the inputs? Can't you sample directly with the ECU input? I also wonder why the need for the op-amps on the outputs. Does the MCU have a DAC? It looks like it doesn't and you are using the op-amps to get a strong enough drive.
Welcome to the friendlier side of internet crazy :)
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: MAP sensor "adapter"

Post by abecedarian »

kb1gtt wrote:Do you know the response time of the existing sensors? The MPX series has a certain delay I think it was 1mS. Do you know the delay of the existing sensors? You may need to add some delay or filtering to get the same signals. If the MPX has a faster response time, the extra noise might cause problems. If it's just a y=mX+B scaled to another y=mx+b, that could be easily done with an op-amp or two. However if you have to make some adjustments to the dynamics, or if you expect to need to change the scale dynamically, then I can see a need for the MCU.

I think I'm missing something. I don't see the Pb in your schematic. I only see one sensor. I can see how one sensor can be used to generate P1, P2 and Pign.

Also why the op-amps on the inputs? Can't you sample directly with the ECU input? I also wonder why the need for the op-amps on the outputs. Does the MCU have a DAC? It looks like it doesn't and you are using the op-amps to get a strong enough drive.
Don't know the response time of the stock sensors; MPX is 1 millisecond. DAC settling time is 4.5 µs.

As for Pb, if you're talking about the bike's schematic, it's at the bottom, next to P1 and P2; Pign is at the top. If you're talking about my board, it's not on there. My board is designed to use the MPX and provide two independent outputs and optionally support the installation of a BMP085 module like this. If the BMP085 is used, one of the DAC outputs will reflect barometric pressure since doing a 'sample and hold' of the MPX when the board powers up wouldn't be sufficient to provide ambient pressure if someone was driving for a long period or had substantial changes in elevation in one trip.

Op-amps on the inputs are, as I already explained, because the MCU is 3v3 and everything else is 5v0. So they are dividing the 5v0 signals (5v0 reference, MPX and DAC outputs) in half to be sent to the ADC of the MCU for sampling.
You can lead the horticulture but you can't make them think.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: MAP sensor "adapter"

Post by kb1gtt »

It's my understanding the baro isn't used for altitude adjustments, but is used for live data which can change as air currents around your bike change, not just long term changes as you drive up a mountain or similar. I think you need 2 pressure sensors and I expect Pb is required not optional. However I also don't know what your ECU is doing with that data so who knows what algo they are expecting and looking for. Looks like Pb would be that BMP_OP header with a SPI interface. I only see the two outputs, but I believe you need 4 signals to the bike. I don't know what you would be generating on A_sample and B_sample. One might be Pb, or P1, or Pign. I see you needing at least 3 outputs, but probably 4 outputs.

For MAP in and 5V sensing, I don't see why you need the op-amps, why not just resistor divide?
Welcome to the friendlier side of internet crazy :)
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: MAP sensor "adapter"

Post by abecedarian »

Sorry for the long-winded reply.
It's my understanding the baro isn't used for altitude adjustments, but is used for live data which can change as air currents around your bike change, not just long term changes as you drive up a mountain or similar.
I know you're busy so probably didn't look at CFI document I linked to earlier. It explains a bunch.
P1 is referenced as being barometric / atmospheric pressure sensor.
I also don't know what your ECU is doing with that data so who knows what algo they are expecting and looking for.
It's all map / look up table based:
Image
And if you can believe it, people are still trying to decipher exactly what Honda was doing with the maps.
Best anyone's come up with is with all of the maps the vertical axis is injection volume and horizontal sloping down is RPM.
Horizontal sloping up is the tricky axis but it appears, and don't quote me on this...
... and sorry for not doing these left / right - top / bottom, but it should make more sense why I didn't after reading below:
(A) 3rd axis in top right is differential pressure between P1 (baro) & Pb (manifold pressure), and this map is the base fuel map used below a certain throttle opening angle;
(B) 3rd axis in bottom left is throttle angle over some pre-programmed angle, and this map is the base fuel map used above a certain throttle opening angle;
(C) 3rd axis in top left is pressure using P2 (charge / boost pressure) sensor;
(D) 3rd axis in bottom right atmospheric pressure P1 (barometric pressure) and is used under boost.

To summarize:
- the ECU operates in two different modes depending on throttle opening angle- speed density [map (A)] and alpha-N [map (B)];
- P1 sensor is used in conjunction with both maps;
- Pb is only used in [map (A)];
- P2 is only used in [map (B)].

Other things that have been determined:
- Pb sensor saturates (full output) at ~110 kPa;
- Pb and P1 are functionally equivalent and output the same voltages at the same pressures and can be interchanged;
- if Pb sensor fails, ECU goes into alpha-N mode and uses [map (B)];
- if P1 sensor fails, ECU fixes barometric pressure at 101 kPa
- P2 upper limit is ~240 kPa;
- if P2 sensor fails, ECU fixes P2 to 101 kPa, and also if the reading is not within tolerance for a given engine speed and throttle angle the ECU enters limp mode.
(Odd fact- pre-production demo units wastegates were set to ~21 PSI / 246 kPa but production units were set to 17.1 PSI / 217.6 kPa.)
Looks like Pb would be that BMP_OP header with a SPI interface. I only see the two outputs, but I believe you need 4 signals to the bike. I don't know what you would be generating on A_sample and B_sample. One might be Pb, or P1, or Pign. I see you needing at least 3 outputs, but probably 4 outputs.
Pb is required needed- it's a manifold sensor, not barometric. That is P1 and why the BMP_OP is there- it's "OPtional", and it's IIC/I2C, not SPI.

I only have two outputs because I was aiming at comparatively low cost and was thinking maybe variations with different routings which could be stacked, like an 'expansion board' to add two more outputs to be controlled by the MCU. Maybe I'll go towards two boards, one with MPX and DAC and the second with BMP_OP and DAC, or maybe one "sensor" board and one 4 out board. That's part of why I'm posting about this.

The A & B outputs are routed to ADC channels on the MCU. Intent is to have the MCU sample them for consistency / accuracy and fail-safe: if an output drifts the MCU might be able to correct it by adjusting the DAC or completely shut the DAC channel down. I haven't committed to this. I'll likely have a few boards fabbed and DNP that op-amp and related components then do testing to see if they should be added.
For MAP in and 5V sensing, I don't see why you need the op-amps, why not just resistor divide?
Valid question the best answer for which I have is it seems 'safer' to me.
You can lead the horticulture but you can't make them think.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: MAP sensor "adapter"

Post by kb1gtt »

abecedarian wrote:Sorry for the long-winded reply.
Don't worry about it at least not while there is good content :)
I know you're busy so probably didn't look at CFI document I linked to earlier.
Yes lots of excuses and higher priorities. Kids, work, typical life stuff. You are correct I didn't read the CFI, thanks for the patience as I stumble through figuring out how to offer useful help.
I only have two outputs because I was aiming at comparatively low cost and was thinking maybe variations with different routings which could be stacked, like an 'expansion board' to add two more outputs to be controlled by the MCU. Maybe I'll go towards two boards, one with MPX and DAC and the second with BMP_OP and DAC, or maybe one "sensor" board and one 4 out board. That's part of why I'm posting about this.
I don't think I follow. If you need 4 signals, I see one board as lower cost than multiple boards. Perhaps you are think of projects other than this bike which might not require all 4 signals. Any how, I might suggest looking for 4 outputs.
The A & B outputs are routed to ADC channels on the MCU. Intent is to have the MCU sample them for consistency / accuracy and fail-safe: if an output drifts the MCU might be able to correct it by adjusting the DAC or completely shut the DAC channel down. I haven't committed to this. I'll likely have a few boards fabbed and DNP that op-amp and related components then do testing to see if they should be added.
This doesn't make sense to me. What do you mean output drift? Perhaps you mean temperature stability, or drift from electrical noise getting induced on the MCU DAC signal. I'm a fan of the feedback where you command 3V then measure it's actually at 3V.
Valid question the best answer for which I have is it seems 'safer' to me.
I'm not sure it's really safer. If you use a rail to rail op-amp, the rail to rail circuits often dump energy when you exceed the rails by like .5V to 1V. So if you get a spike that's more than say 7V, then you're still going to see the spike at the MCU pin. I've not been happy with the rail to rail diode dumping. I'm making progress on a better protection. See here for details. http://rusefi.com/forum/viewtopic.php?f=4&t=274&start=8
Basically it only dumps to GND instead while the diode approach dumps to the + rail. That circuit is intended to allow inputs that can go as high as 250V. Basically a 250V input is can be resistor divided by 50, such that 250V is 5V at the input pin. If the op-amp is set for a gain of 1, then the MCU see's 5V. However if you have a 25V signal on the 250V input, then the 10X jumper installed, the 0-5V seen by the MCU will correlate to 0-25V. However if you have a voltage spike (like on an injector or ignition driver) you are protected up to 250V with out damage to the MCU. If you exceed 250V you are still protected at the MCU as the clamping protection kicks in shunting to GND limiting the input voltage to 5.3V peak. Now I just need to get into the basement to play with it.
Welcome to the friendlier side of internet crazy :)
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: MAP sensor "adapter"

Post by abecedarian »

kb1gtt wrote:
abecedarian wrote:
Sorry for the long-winded reply.
Don't worry about it at least not while there is good content :)
Well, it's been a while and I've been spending a lot of time on this, probably too much actually. :D
Been weighing resister/dividers versus op-amps, analog signal level translation (read a bunch of Maxim, TI and Freescale app notes), and otherwise have been pondering things and popping up here and there asking questions, positing solutions and otherwise being the cautious version of Curious George. So if I sound a bit more informed than before, maybe I am? ;)

Anyhow....
I don't think I follow. If you need 4 signals, I see one board as lower cost than multiple boards. Perhaps you are think of projects other than this bike which might not require all 4 signals. Any how, I might suggest looking for 4 outputs.
Both the 500T or 650T need 3 sensors to run the EFI; the 500T needs 1 more to run ignition. As far as I know, the P1 (baro) and Pign (500T ignition) sensors have relatively low failure rates. The P2 (boost) sensors are starting to show their age. Pb are failing at increasing rates because they were not really designed to be subject to 17+ PSI boost for 30+ years... well neither was the P2 or Pign but they were designed to experience that boost level though.

So, I was 'targeting' the bike owners who might need to replace Pb and possibly P2... for two reasons: they are starting to go bad and there are no replacements off the shelf- used only, so it's a crap-shoot, and each is a $50-$200 dollar risk. If I can make one sensor for under $100 that could replace one or both, it's a win-win, no? ... AND I was thinking of people, like I mentioned, who might want to add something to their current system: piggyback controller, or who knows? I started with two MPX and 4 outputs, scaled down to 1 MPX and 4 outputs then realized that to do barometric I'd need a 2nd sensor or sample and hold the MPX at system start but that wouldn't give any real-time compensation.
This doesn't make sense to me. What do you mean output drift? Perhaps you mean temperature stability, or drift from electrical noise getting induced on the MCU DAC signal. I'm a fan of the feedback where you command 3V then measure it's actually at 3V.
Basically, you are right. Think of it like it's a 'digital' trim pot. If the output voltage is not what's it's supposed to be, an offset can be added, and plans are there for temp compensation. That is why I'm sampling the ECU 5v0 rail also, to allow for fluctuations on the sensor supplies.

Also, I'm not dropping 5v0 to 3v0- it makes no sense to me to drop the signal to within 0.3v of ADC reference; it leaves almost no headroom. Since 5v0 is supplying all the devices none of them should output more than that. 6v0 is "absolute maximum rating" into the op-amp, so I guess it would depend on which way it failed because if the 0.5x gain held, the MCU can survive up to 3.9V on an input for a short period (7.8v into the op-amp). So, it should pop the op-amp and not the MCU (my words, not the EE that told me that).

Doing math at 1/2 (0.5x) also makes using the hardware multiplier easier and avoids floats. No floats means faster code, even if I had an FPU available, which I don't.
I'm not sure it's really safer. If you use a rail to rail op-amp, the rail to rail circuits often dump energy when you exceed the rails by like .5V to 1V. So if you get a spike that's more than say 7V, then you're still going to see the spike at the MCU pin. I've not been happy with the rail to rail diode dumping. I'm making progress on a better protection.
Not sure how I'd get a >7v spike from a 5v regulated source that also supplies power to the processors within the ECU.
You can lead the horticulture but you can't make them think.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: MAP sensor "adapter"

Post by kb1gtt »

abecedarian wrote:Also, I'm not dropping 5v0 to 3v0- it makes no sense to me to drop the signal to within 0.3v of ADC reference; it leaves almost no headroom.
I'm still not seeing the need for the op-amp, you can still use a resistor divider to drop it how ever you want, doesn't have to be 5 to 3V, you can change that divider to what ever you are looking for. Then after the drop, use a clamp to protect the MCU input. This approach can sustain a much higher input voltage issue than the opamp can sustain.
Since 5v0 is supplying all the devices none of them should output more than that.
It can go higher for a variety of reasons. I'm sure you've see that these linear regulators will pull you up to 5V, but not down to 5V. I also think you've seen how these schottkey diodes will dump a transient spike to the + rail, which can cause the 5V to rise if there isn't enough of a load pulling it down to 5V. One items folks often over look is that most MCU pins are protected with nearly the same diodes that are commonly used external to the MCU. The diodes internal to the MCU are for ESD not continuous over voltage, this is why folks often use the external diodes which are much larger and can sustain the continuous operation. So if you have a spike, the MCU pin will often dump that energy to the + rail even if you don't have those extra protection diodes installed. If the 5V is sensitive to over-voltage it's often a good idea to add a clamping protection. A common approach is a crow bar circuit. Either that or a shunt to GND. Or the more common often assumed OK as it'd done by many OEM who have much stringent control on the install constraints, is to use not protection. Because this would be used by DIY'er I would not suggest the no protection approach, as you don't have control over how it's going to be installed. There are lots of creative ways to get more than 5V on the + rail, probably one that's more likely is to simply connect the +V when +V is powered. Linears are typically fairly poor about ripple rejection, and can pass more than 5V during upstream fast transients. If you connect the power after it's powered, you often get a large amount of transients caused by the arcing that happens while the connection is being made. Any how, for a DIY approach, I suggest a 5V clamp, or some kind of MCU pin protection. I don't know the failure mode of the op-amp, so I don't know if it would open or short, or other. I would assume it shorts which would mean the MCU would need to bare the load after the op-amp failed any how.

Now that I have a fairly good grasp of the 50,000 ft view. How is this connecting to the existing harness. I'm assuming you'll have some pig tails with the sensor side of the connector. How do you get 5V?

Op-amps are high gain an can ossilate easily. You may want to add pads for an optional slew limiting option. However you may not need it, but you may need it and you have the PCB space.

I don't know the inductive or capacitance properties of the ECU input, so I'm not sure if this is a problem or not, which usually means it is a problem. Check op-amp stability as noted in this brief overview of some issues that often arise. http://www.analog.com/library/analogdialogue/archives/38-06/capacitive_loading.html I suspect you are OK with those 1k resistors on the output. However....

What does the MCU sensor require for current? Basically what's the MCU's impedance and is is linear? It's not uncommon with older electronics that they needed 1mA to 5mA. If I assume 1mA and a 3V signal, the MCU impedance would be 1kohm. If it's 1kohm, then you're going to have trouble getting more than 2.5V out of the 5V rail op-amp with 1kohm drive resistor. I suspect you'll need to drop the 1kohm drive resistor to allow for higher voltages to be generated, but then you may start to experience issues as noted in the above analog devices archive.

AS for the layout itself, I'm not crazy about it. I recommend spending more time placing the components than drawing the traces. When I look at it I see lots of current loops that are larger than required, which results in a raised noise floor. This circuit should be easy enough to have nearly no punch through's to the back layer which should be GND. As a general layout technique I suggest placing the components (optimizing the current loops), then draw the traces, then draw the PCB edges. However it's very common folks start with an enclosure then try to shoe horn the components in the box. Which often leads to bad electrical design.

C6 and probably C5, wants to be much closer to the regulator. The regulator is a high gain device it can ossilate if the output cap isn't just right. Note section 11 found here title ESR and Stability. http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=snva020&fileType=pdf By placing the cap so far away, you change the ESR which may allow oscillation. Moving the caps closer to the regulator will control the ESR much better.

Of course, don't forget silk screen. That's really handy when assembling and when diagnosing later down the road. Just picture asking someone in the field to look at R5, then picture how much time might be spent trying to tell them where R5 is located. I suggest a URL, and perhaps some kind of logo. After all, these are a free bill board you should use it. http://www.eevblog.com/2010/11/15/eevblog-127-pcb-design-for-manufacture-tutorial/

Any how that's enough for now. I think I'm going to get a chance to play in the basement.
Welcome to the friendlier side of internet crazy :)
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: MAP sensor "adapter"

Post by abecedarian »

So things don't get too confused:
MCU= Micro Controller Unit: MSP-EXP430F5529LP
ECU = Engine Control Unit: CX500TC / CX650T motorcycle
I'm still not seeing the need for the op-amp, you can still use a resistor divider to drop it how ever you want, doesn't have to be 5 to 3V, you can change that divider to what ever you are looking for. Then after the drop, use a clamp to protect the MCU input. This approach can sustain a much higher input voltage issue than the opamp can sustain.
Okay.
Please stop trying to find a "need" for the op-amps: they are design requirements suggested by more than a few people with experience using the MCU family I'm using (MSP430). I'm noob at this, I admit, but when a guy that's built circuits that interface these MCU's to LCD's, motor controllers, DMX lighting, and such, and has also designed self-contained MCU experimenter boards with these MCU's, I respect that person's opinion. His opinion is that resistor dividers are great for things when "you" control the source voltage and current, and bad for interfacing to things you don't. Digital signals should go through opto-isolators; analog through op-amps.


I'll skip over most of the next paragraph and address:
How do you get 5V?
Two ways, actually:
- 5v for the MPX, DAC, op-amps and core MCU operation is coming from the ECU, as mentioned previously. Since this unit is meant to 'stand in' for other sensors, it is presumed the extant ECU itself has a very strong interest in keeping the sensor rail at 5v for its own protection. As the inclusion of this unit results in the deletion of one (or more) sensors, I don't foresee any spurious spikes in the near future. I have spoken with many people about this and their concerns have been, primarily, if the ECU can supply enough current for this to operate, what are the failure modes and can the DAC can source enough current to satisfy the ECU. If the ECU cannot source enough current, I can include a 12v connection and 5v regulator to supplement the ECU supply, in parallel, which should serve to stabilize the 5v rail both for this unit and the ECU.
- 5v for the USB peripheral of the MCU for serial / programming is coming from the computer it might be connected to. I have already tested this and is not an issue. The MCU in question has been designed to accommodate this type of situation where 5v may not be present, or if it is, not used unless the chip is connected to USB.
C6 and probably C5, wants to be much closer to the regulator. The regulator is a high gain device it can ossilate if the output cap isn't just right.
C5 and C6 are for the 3v3 circuit, obviously. Strictly speaking they are not required at all since the MCU board has decoupling capacitors installed near the MCU chip already. C6 is a carry-over from a previous design which had the MCU on the board and would be installed close to the MCU. C5 doesn't need to be installed at all, but is there to help smooth voltage fluctuations to the MCU and should be as close to the MCU as possible, which happens to be near the 3v3 pin, as shown. Again, suggested by the person referenced above.

With regards to:
AS for the layout itself, I'm not crazy about it. I recommend spending more time placing the components than drawing the traces. When I look at it I see lots of current loops that are larger than required, which results in a raised noise floor. This circuit should be easy enough to have nearly no punch through's to the back layer which should be GND. As a general layout technique I suggest placing the components (optimizing the current loops), then draw the traces, then draw the PCB edges. However it's very common folks start with an enclosure then try to shoe horn the components in the box. Which often leads to bad electrical design.
I'm open to layout suggestions, but the pin headers (J1, J2, J3, J4) must be located as they are so the MCU board can plug on, and am self-limiting the board to 5cm x 5cm. Also, top and bottom layers are GND planes; power is distributed by discrete traces to the components so I'm curious about what "current loops" you're seeing.
I don't know the inductive or capacitance properties of the ECU input, so I'm not sure if this is a problem or not, which usually means it is a problem....
... I suspect you are OK with those 1k resistors on the output. However....
Now, no one has determined whether the ECU is measuring voltage or current from the sensors so this unit may not work as it's a voltage source not a current source. That can easily be fixed in a future revision, but I have to start somewhere, hence the op-amps and those resistors. ;)
You can lead the horticulture but you can't make them think.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: MAP sensor "adapter"

Post by kb1gtt »

abecedarian wrote:Please stop trying to find a "need" for the op-amps: they are design requirements suggested by more than a few people with experience using the MCU family I'm using (MSP430).
I'm not trying to sway you one way or the other, but wanted to make one last comment. Programmable Logic Controllers (PLC) are designed for robust unknown installations, just like what this board is doing. PLC's use both digital and analog signals, and need to do it reliably as they are often connected to multi-million dollar systems. A PLC failure due to a wondering or incorrect input would be crippling to the PLC company. I've dissected several PLC's to see what makes them tick and how others do it. I've seen that they do use opto-isolation on digital inputs. However for analog signals they generally either use a resistor divider with clamp, or they use a highly specialized chip that I can't get data sheets for. You can do it how you feel, and it's probably going to work or work mostly. I just wanted to note that I see potential land mines and that this isn't the KISS approach. Note on the op-amp buffered inputs. Some isues with op-amps include offset voltage, aging offsets, and then the normal holes and poles issues. http://en.wikipedia.org/wiki/Input_offset_voltage I'm not trying to sway your design, I'm just passing along information. If nothing else, it might help you to know some items to keep an eye out for.
How do you get 5V?
Two ways, actually:
That wasn't what I was looking for. Your bike is 12V, how does that get to the 5V input? I'm assuming there is a linear regulator or switching regulator somewhere along the path. I'm looking for things like ripple rejection issues, or areas where you can get over voltage issues. I suggest that you only use one 5V source at a time, with out it you run risks of GND loops.
C6 and probably C5, wants to be much closer to the regulator. The regulator is a high gain device it can ossilate if the output cap isn't just right.
C5 and C6 are for the 3v3 circuit, obviously. Strictly speaking they are not required at all since the MCU board has decoupling capacitors installed near the MCU chip already.
The reason why they need to be near the regulator has nearly nothing to do with the load. Decoupling caps deal with issues caused by short term current spikes at the device, while these output caps deal with oscillation caused by the linear regulator. Here's a fellow that's experiencing it in a situation very similar to what you are looking to do. http://e2e.ti.com/support/power_management/linear_regulators/f/321/t/245637.aspx it all depends on what the linear spec calls for. Some have these caps installed internally, most do not.
I'm open to layout suggestions, but the pin headers (J1, J2, J3, J4) must be located as they are so the MCU board can plug on, and am self-limiting the board to 5cm x 5cm. Also, top and bottom layers are GND planes; power is distributed by discrete traces to the components so I'm curious about what "current loops" you're seeing.
Most of the best designs I know refuse to use these dev boards, as they are not cost effective for real world developments. They way they force you into headers like this almost always creates issues. However there are many DIY'ers that use them well enough and if you only ever plan for a short run low risk effort, they can do well enough. I tend to sit on the fence about how and when to use these low cost MCU dev boards. I would suggest using the header as a last resort, place the chips first, then after it's laid out, place the headers. In your case you have more than enough space, so it should be fairly easy to get the headers to work. I wish I had tome to open in paint to show you the loops. Again this isn't hard failures. it will only result in a raised noise floor, which your design can probably sustain. Your board isn't RF, however with op-amps the raising of the noise floor can create some hidden RF issues. When I say the back should be GND, I mean that should be GND with no physical barriers or breaks. Via's only is highly recommended.
Now, no one has determined whether the ECU is measuring voltage or current from the sensors so this unit may not work as it's a voltage source not a current source. That can easily be fixed in a future revision, but I have to start somewhere, hence the op-amps and those resistors. ;)
I'm not so interested in what it's measuring, but it's impedance over a variety of voltages. Ultimately it's using small current loops that are then turned into a voltage reference somewhere inside the ECU. If you measure the voltages and currents for a variety of pressures, you can calculate the impedance of the existing system. Once you know the impedance, you can predict what voltage you will need at the MCU to generate an equivalent voltage at the sensor input. As it stands now, 3V at the MCU will not correlate to 3V at the sensor.
Welcome to the friendlier side of internet crazy :)
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: MAP sensor "adapter"

Post by abecedarian »

Points made in your post will be considered.
I'm using the MCU board for prototyping purposes initially. I can change the board shape and size but the headers must remain positioned as they are relative to each other.
Also, if the MSP430 proves underpowered, I can change to a compatible ARM M4 MCU board with little modification.


What I know about the power source from the bike's ECU:
Voltage regulator is Toshiba D716. It converts 12v from the bike's battery / charging system to 5v for the ECU and sensors. Total current draw of the ECU from the bike is around 800 mA, key on / engine not running. In this state it is able to detect open / short across sensors and open / short across the fuel injectors.

Test procedures for the 3 EFI sensors with 4.75-5.25v on their supply.
Engine off:
- Pb should output 3.13-3.73v.
- P1 should output 3.13-3.73v.
- P2 should output 1.09-1.29v.

Engine running:
- Pb should output 1.6-2.0v @ -47 kPa relative; 2.9-3.5v @ -8 kPa relative.
- P1 should output 1.6-2.0v @ -47 kPa relative; 2.9-3.5v @ -8 kPa relative.
- P2 should output 0.4-0.5v @ -34 kPa relative; 2.9-3.5v @ +100 kPa relative.

As it stands now, 3V at the MCU will not correlate to 3V at the sensor.
That's one reason I'm using DAC's for the outputs back to the ECU, with 5v from the ECU as Vref.
Given 12bits, 0 (0000h)= 0v out; 2047 (1000h)= (0.5 * 5vrail) out; 4095 (ffffh)= (1 * 5vrail).
I've already done some tests on the breadboard and confirm this is correct.
You can lead the horticulture but you can't make them think.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: MAP sensor "adapter"

Post by abecedarian »

Stuck with thinking about "punch through" to the bottom "GND" layer.
layout_Jan-11-2014.jpg
layout_Jan-11-2014.jpg (136.7 KiB) Viewed 23176 times
Both op-amps, by necessity (whether my own mistake or otherwise) punch through to the bottom layer and route a bit so they can punch back up to the 5v layer.
DAC outputs similarly did a little bit of punching, as did the MOSI data trace from the header to the DAC.


Is this better?
You can lead the horticulture but you can't make them think.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: MAP sensor "adapter"

Post by abecedarian »

Great thing is this is 'compatible' with the Hercules board I'll be working with, albeit a little bit shorter... so more room for more toys.
;)
You can lead the horticulture but you can't make them think.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: MAP sensor "adapter"

Post by abecedarian »

I don't think I like that... will probably turn the 'plug' around so wires and vacuum hose exit the same side, but I like the layout... overall.
You can lead the horticulture but you can't make them think.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: MAP sensor "adapter"

Post by kb1gtt »

That's much better. You can still decrease the number of traces on the back plane, basically only punch though when you need to cross a trace. Another way to make the jump is with a 0R resistor. This avoids the need for vias, which are typically very reliable, but can fail. Some could still be shortened, some like that on the lower left, seem like they could be done all on the top layer. Hmmm, is it missing some traces, like on C1? I don't see the other trace, just the GND punch through.
Welcome to the friendlier side of internet crazy :)
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: MAP sensor "adapter"

Post by abecedarian »

Okay....
layout_Jan-11-2014x2.jpg
layout_Jan-11-2014x2.jpg (137.71 KiB) Viewed 23171 times
A few vias to the GND layer, 2 drills and short traces to get 5v to the op-amps, and two traces to bring DAC outputs to the op-amp for sampling.

Getting better?
You can lead the horticulture but you can't make them think.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: MAP sensor "adapter"

Post by abecedarian »

kb1gtt wrote:... Hmmm, is it missing some traces, like on C1? I don't see the other trace, just the GND punch through.
C1 has a short trace to a via that connects to the GND layer; the other side of C1 is connected to the upper layer / 5v... and is why the DAC traces travel across the bottom GND layer for a bit.
You can lead the horticulture but you can't make them think.
Post Reply