... 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.Statistics: Posted by abecedarian — Sun Jan 12, 2014 1:13 am
]]>
Getting better?
Statistics: Posted by abecedarian — Sun Jan 12, 2014 1:09 am
]]>
]]>
]]>
Statistics: Posted by abecedarian — Sat Jan 11, 2014 11:28 pm
]]>
DAC outputs similarly did a little bit of punching, as did the MOSI data trace from the header to the DAC.
Is this better?
Statistics: Posted by abecedarian — Sat Jan 11, 2014 11:22 pm
]]>
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.
That's one reason I'm using DAC's for the outputs back to the ECU, with 5v from the ECU as Vref.As it stands now, 3V at the MCU will not correlate to 3V at the sensor.
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.
Statistics: Posted by abecedarian — Fri Jan 03, 2014 8:13 pm
]]>
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.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.Two ways, actually:How do you get 5V?
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.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 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.
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.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'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.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.
Statistics: Posted by kb1gtt — Thu Jan 02, 2014 11:37 am
]]>
ECU = Engine Control Unit: CX500TC / CX650T motorcycle
Okay.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.
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:
Two ways, actually:How do you get 5V?
- 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.
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.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.
With regards to:
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.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.
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 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....
Statistics: Posted by abecedarian — Thu Jan 02, 2014 3:15 am
]]>
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.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.Since 5v0 is supplying all the devices none of them should output more than that.
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.
Statistics: Posted by kb1gtt — Wed Jan 01, 2014 2:45 pm
]]>
kb1gtt wrote:
Well, it's been a while and I've been spending a lot of time on this, probably too much actually. Don't worry about it at least not while there is good contentabecedarian wrote:
Sorry for the long-winded reply.
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....
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.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.
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.
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.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.
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.
Not sure how I'd get a >7v spike from a 5v regulated source that also supplies power to the processors within the ECU.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.
Statistics: Posted by abecedarian — Wed Jan 01, 2014 4:21 am
]]>
Sorry for the long-winded reply.
Don't worry about it at least not while there is good content 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 know you're busy so probably didn't look at CFI document I linked to earlier.
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.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.
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.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.
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=8Valid question the best answer for which I have is it seems 'safer' to me.
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.
Statistics: Posted by kb1gtt — Wed Jan 01, 2014 12:44 am
]]>
I know you're busy so probably didn't look at CFI document I linked to earlier. It explains a bunch.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.
P1 is referenced as being barometric / atmospheric pressure sensor.
It's all map / look up table based:I also don't know what your ECU is doing with that data so who knows what algo they are expecting and looking for.
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.)
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.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.
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.
Valid question the best answer for which I have is it seems 'safer' to me.For MAP in and 5V sensing, I don't see why you need the op-amps, why not just resistor divide?
Statistics: Posted by abecedarian — Tue Dec 31, 2013 7:56 pm
]]>
For MAP in and 5V sensing, I don't see why you need the op-amps, why not just resistor divide?
Statistics: Posted by kb1gtt — Tue Dec 31, 2013 10:59 am
]]>
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.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.
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.
Statistics: Posted by abecedarian — Mon Dec 30, 2013 2:28 pm
]]>