work in progress stimulator board

[AndreyB]

stimulator_gerber.zip schematics
SVN repository

MCP42010-I/SL-ND
2N7002KCT-ND

In order to catch stock behavior of different stock ECUs one of the approaches should be to stimulate the ECU with fake signals and record the ECU reaction while everything is on the bench.

So far I am doing this with a couple of transistors and a couple of digital potentiometers, but if someone can spend time on that and get a proper board what would be amazing.

1) I suggest a simple board works together with Frankenstein. Frankenstein is under the Discovery, so stimulator would have to go above the discovery - we would need tall headers to clear the buttons & audio jack. Maybe even a hole in the stimulator board so that we can hit 'reset' button?

2) at least two MCP42010-I/SL-ND. All 'A' pins should be connected to GND via a 0805 resistor (0R if we just need GND), all 'B' pins should be connected to +5 via a 0805 resistor (we can either not mount it or mount a 0R if we need a voltage divider). All 'w' pins should have two output pins so that we can have one wire running to stock ECU and another wire running to a multimeter or smth like that.

3) at least x2 10x2 pin headers (black on the sketch) - this would sit above the discovery, so 2nd header would be needed at least for support

4) 5.08 screw-in terminals (red on the sketch)? 0.1" terminals? not sure.

6) the board should expose dual pins for a couple of discovery pins. For instance PD1 & PD2 should be exposed both with two pins - one for stock ECU another for logic analyzer or something.

6) Discovery input capture needs a 0v/5v signal. Common ECU output is floating/GND, we would need at least two decoders like
(and a capacitor to GND)

On the sketch board outline is orange.

[roflcopter]

I had an Arduino Uno sitting in my room and I was using it to test my board(although I crashed my laptop about 4 times running two serial monitors at once). I just whipped up a quick sketch to output the crank pulse, TP voltage, and read the output from a single injector channel.

Are you looking for a standalone board especially for this, or just something cheap and simple to use? Also, what all inputs are necessary in this application? I assume you are using your logic analyzer to actually look at the board outputs and won't need to use the board to interpret those as well.

[kb1gtt]

For some time I've wanted a device I dubbed a play recorder. As my name implies it would record, then play. For automotive applications, I would find it really handy for sniffing a real ECU, saving the signals to a file. The file can be sent to a developer or tuner who can then write software or create a tune that causes the development ECU to reproduce the same signals as the original ECU. I see this device as real handy for more than just ECU sniffing, and I've been tempted to make such a device as a product. Another way to think of it, is as a mixed signal scope, with play back capabilities.

So I'm curious, if such a device existed, who would be interested in such a device? I picture it as a 6 channels in and 6 channels out, accepting something like a .001V to 600V input and generating signals up to like 18V. I'm kind of tempted to make it battery powered and wireless to prevent ground loops issues, but I'm sure people are going to be very concerned with costs, so perhaps it can use USB. I also like the wireless idea s it could potentially be used with a phone app.

So who's interested?

[AndreyB]

A recording/playback would be close, but not exactly the same. For me the benefit of a simulator is that it can produce all kinds of signals, including the ones which would be hard or impossible to record - like say you have a stock ECU but do not have the vehicle.

[kb1gtt]

Use a jim stim or your sound card for that kind of thing. Those already exist. However they have limitations as well, so be-ware the stimulators. I'm looking to capture real world signals to get real world errors to program against.

[AndreyB]

Use a jim stim

I should double-check how many analog signals jim stim has. But my point is being able to control the simulation from a PC, so that I can say gradually change the CLT temperature and see how the ECU would react.

No one say 'potentiometer'!

[kb1gtt]

I seem to recall that remote control over the JimStim has been done. I forget where though. Ah, here we go. I seem to recall Fred is not impressed with jimstim as it caused him some development issues as it was generating an incorrect wheel pattern. So I don't think he ever took it further than that video.

[Sudo]

I thought about this project for a while already. I wanted to develop a simulator board that can drive OEM ECU. I wanted to automate the process of gathering OEM maps. I think a Cypress PSoC 5 is perfect for this application. The PSoC 5 have very versatile digital/analog IOs.

One of my challenges was to simulate a VR signal. I am still trying to figure out a way to do this. Perhaps using a 3D printer to create wheel pattern?

Instead of digital potentiometers, one can also use DACs that are already available on MCUs, since most sensor inputs are only looking for a varying voltage between the operating range.

[AndreyB]

I am also curious how to simulate a VR signal. I wonder what would be the chance that the OEM VR input could be fooled with just a 3.3 square wave signal?

I am sure that a real physical wheel could be avoided one way or another. The stimulator board was a bit abandoned while we were focused on other stuff, now that we have the Frankenstein we can actually take another look at this board.

For a 1st revision, we would need three MCP42010 digital potentiometers in SOIC package - MCP42010-I/SL-ND and a couple of transistors to emulate hall sensors and a couple of very simple circuits to capture injector/ignition ECU output.

See also http://rusefi.com/articles/stimulator/

[kb1gtt]

I tend to think what we really want is the ability to play fairly fast analog voltages with the ability to drive around .5A. Such that if you want to simulate a hall, you drive an analog output signal from your MCU connected to an op-amp that can drive rail to rail from 0V to 5V. If you configure your output to be a GPIO, the op-amp won't be the wiser. So the op-amp would drive hard like a digital signal. However if you want to simulate a VR, you can simply send an analog signal. I like this concept combined with an analog input that can safely capture large voltage input signals.

This chip can do 2 channels of 1.5A with up to 17MHz for about $4 per channel. http://octopart.com/opa564aidwp-texas+instruments-12190440

Of course most all signals are typically under 20mA of drive, you we could probably do it with normal op-amps. However why not go big if we go this route.

Hmmm, we have 12 analog input channels. Do we have 12 PWM channels? If so we can make 12 ADC's fairly easily. The PWM/ADC can drive the op-amp. Then it can be connected to the high voltage input. Such that we can drive it and verify it drove to the correct voltage. I also think that if we do not enable the op-amp, the output will be high impedance. If that's true. we can selectively turn off the output. then record an engine. Then we can play back the exact signals that were recorded.

Does this make sense to anyone other than myself? Basically record signals, then play them back.

[AndreyB]

No, it does not make sense to me: how are we going to simulate a CLT sensor with a DAC/PWM instead of a digital potentiometer?

Also while record/playback is one valid use-case, a different but also valid use-case is generating signals without a record.

[kb1gtt]

A resistor is a voltage / current correct? So an op-amp that's dumping 1mA at 1V is the same as 1kohm resistor. If you measure an existing signal, then generate those voltages, you'll simulate the resistances of the original sensor.

[AndreyB]

Jared, what you are suggesting should be illegal

I kinda-maybe-barely understand what you mean, but that's too an EE of an approach for me. And no, we do not exactly have 12 PWMs. I mean yes, we do, but I'd rather not use them - the hardware PWM pins are all over the boards, and working with the hardware PWM is not a joy for me. And our software PWM is not ready yet. And a potentiometer and transistors approach just seems simpler to me simply because CLT is a fair resistor, not something pretending to be a resistor.

[kb1gtt]

Might as well continue my illegal suggestion with a pencil schematic By drawing it out, I see we would be limited to 6 channels, as it requires 2X ADC's. One for current sensing, one for voltage sensing.

The HV AN input is the 500V rated input that I'm developing and allows a wide range of input voltage selection. The LPF is a Low Pass Filter. I think the rest would make at leas some kind of sense. The ACS710 was supposed to be an ACS712, it's a hall current sensing chip.

[kb1gtt]

Some features of the simulator would also be handy for checking builds. This video notes some interesting DFM notes http://www.eevblog.com/2013/11/29/eevblog-552-dfm-automated-pcb-panel-testing/

[AndreyB]

http://www.ardio.ru/ultrascan.php is a scan tool with signal generation feature, but it costs above $3k. I wonder if there are cheap devices which already do the same?

[Art_ELectro]

http://www.ardio.ru/ultrascan.php is a scan tool with signal generation feature, but it costs above $3k. I wonder if there are cheap devices which already do the same?

Or http://www.dhgate.com/store/product/kd-3055b-auto-signal-generator-of-ecu-diagnostic/121346686.html
Wholesale - KD-3055B Auto Signal Generator of ECU diagnostic scanner
US $199.02 - 240.22 / Piece

or...

[kb1gtt]

Could simply write some software for the DSOQuad https://www.sparkfun.com/products/12066

[AndreyB]

Is DSOQuad capable of PRODUCING signals? Because these scanners are PRODUCING signals, and we need to both produce and capture signals for the task of OEM ECU stimulation.

[kb1gtt]

It has at least one analog generation channel, there may be other channels, but I they are typically inputs not outputs, so I don't know for sure if they can be made into an output or not.

[abecedarian]

Here's something I was working on:

ENGSIM.png

... for use on a TI MSP-EXP430F5529LP board
.
I don't have 5v on the crank or cam outs, it's 3v3, but do have LED's. Actually, it could be easily modified to switch at 5v with a pair of transistors.

The firmware isn't written yet either but it was going to report sensed voltages from each of the pots and allow inputting RPM into a terminal window and setting crank and cam signals accordingly; USB is built in to the boards so no need to have a separate interface. And obviously, the screw terminals would allow you to route things to other inputs if necessary for other tests. Pins 1-6 on SV2 can output PWM signals if you needed, too, though again at 3v3; there are two IIC/SPI interfaces available, unused as well.

5v external can be applied to pin 11 SV1 if the 5v jumper on the LP header that connects it to the ICDI interface is removed. That basically makes the resistors around the pots into 1/2 dividers and uses your source for 5v. A future revision would have had jumpers to disconnect the pots and allow connection of live sensors.

[AndreyB]

Here's something I was working on:

ENGSIM.png

Yep, more or less what I am looking for - just that I want a programmable potentiometers so that I can capture data in some range of values automatically.

[abecedarian]

An option might be Maxim MPC4922 12 bit, two-channel, 0-5.5v, rail-rail DAC's. You can supply an external reference for each output channel and they can source ~20-25mA per output. Additional output might be achievable using op-amps. They're controlled via SPI and are 3v3 logic level compatible on the SPI bus. Sample the outputs back into the MCU and monitor the voltage out- F5529LP has 8 ADC channels capable of being grouped into 3 batches for automatic sampling.

A few months ago I requested 'samples' from Maxim and had two PDIP-8 chips within a week. Individually, they're under $3 each @ Mouser.

[Sudo]

kb1gtt, your idea is simular to what I have in mind. And it seems to be the simplest/cheapest/most versatile method for low-medium speed signals.

As far as VR simulation, the only problem I see with the VR simulation is that the signal bandwidth needs to be MaxRPM*Teeths*Resolution, which is most likely in the MHz range. I highly doubt the DSO can do this. I am not sure if its worth trying to simulate a VR signal using circuitry only. A parallel DAC may work, but the GPIO have to be fast enough to drive a 2 times the speed of the signal. Anyone know how fast the STM32 can go with the GPIO? It seems we would be pushing the limit of a MCU. An FPGA driving a parallel DAC can certainly achieve this without a problem, but it is more costly. At the end, it really seems a dc motor with a wheel seems to be much simpler and more a realistic stimulus. Maybe we can hack junk hard drives to do this.

However, I do have one minor concern with using DACs now that I thought about it more. Most likely the ECU have their ADC reference set to the rail. That means, it is possible that if the ECU rail fluctuates, we can induce noises and/or offsets into the input relative to the ECU rail. I am not sure if this is critical or even an issue, but basically we are betting on the fact that ECU rails is rock solid, which may or may not be the case. But then again, this is just the stimulator board. Accuracy doesn't seem critical for this application. But it is just a thought to keep in mind.

[abecedarian]

As far as VR simulation, the only problem I see with the VR simulation is that the signal bandwidth needs to be MaxRPM*Teeths*Resolution, which is most likely in the MHz range. I highly doubt the DSO can do this. I am not sure if its worth trying to simulate a VR signal using circuitry only. A parallel DAC may work, but the GPIO have to be fast enough to drive a 2 times the speed of the signal. Anyone know how fast the STM32 can go with the GPIO? It seems we would be pushing the limit of a MCU. An FPGA driving a parallel DAC can certainly achieve this without a problem, but it is more costly. At the end, it really seems a dc motor with a wheel seems to be much simpler and more a realistic stimulus. Maybe we can hack junk hard drives to do this.

Assume a 36 tooth wheel at 10000 RPM: 360000 teeth per minute / 60 seconds = 6000 teeth per second = 6KHz signal / 12KHz if you're counting rising and falling edges. MSP430G2553 @ 16MHz core clock (little brother to the F5529 in the LP I mentioned) can toggle pins well in excess of 50KHz; I suspect STMF32 can do at least that. So, toggling a couple pins isn't such the issue it seems. I mean, consider that these processors have instructions that are single-cycle, meaning it takes one clock cycle to do the job. At 16MHz, that's 16 million cycles per second; STM32 @ 80+ MHz? See what I mean?

And if you're not comfortable with the F5529LP, there's always the TM4C123GXL running an 80MHz Cortex-M4 similar to the STM32F4, which is pin-compatible with the stimulator board I posted. Both are $12.99 USD.

Anyhow, the biggest problems I see with generating the actual VR signal are: many VR's are dual-ended meaning it has a negative voltage component (some have one wire tied to ground so are single-ended); the voltages increase with frequency. When you're stuck with a 0-3v or 0-5v signal, getting a signal that can be +20/-20 or even more isn't so easy. LM1918 can handle this somewhat but MAX9926 and related are most often used with 0v crossing so if the voltage never goes below 0v, it never crosses- there are options for that too but it's a different circuit.

However, I do have one minor concern with using DACs now that I thought about it more. Most likely the ECU have their ADC reference set to the rail. That means, it is possible that if the ECU rail fluctuates, we can induce noises and/or offsets into the input relative to the ECU rail. I am not sure if this is critical or even an issue, but basically we are betting on the fact that ECU rails is rock solid, which may or may not be the case. But then again, this is just the stimulator board. Accuracy doesn't seem critical for this application. But it is just a thought to keep in mind.

A workaround to an MCU with hard-wired ADCREF is possible. Divide your sensors' 5v rail and sensor inputs with resistor dividers or op-amps so that they are below the maximum voltage the ADC can sample, then sample the 5v rail along with the sensors. If you have a 12 bit ADC with 3v reference, you have potential resolution of better than 0.01v (3v / 4096 steps = 0.00732v per step) though you'll be limited to around 3400 steps since the voltage being sampled will not get near 3v unless you have a serious problem; a 2.5v internal reference is possible but if the 5v rail or any sensor goes above 5v you'll saturate the ADC.

It's hard to see but that's what I've planned on the board I posted. Each pot has a pair of 100K resistors arranged to divide the voltage in half. The top plane is ground, bottom is 5v. Header SV1/Pin11 is connected to the 5v plane along with all the pots and has a pair of 100K resistors arranged as dividers and SV1/Pin13 is ADC0 on the MCU. SV1/Pin14-17 are also ADC (ADC1-ADC4 actually) as well. What I haven't done is permit a way to disconnect the pots from the circuits so external sensors can be connected for logging instead of stimulating, but that's a trivial modification to the board, nor have I worked out a similar thing for cam / crank signal logging. It is in the plan to do so though, probably a DIP slider or something to choose stimulator or logger with the firmware responding appropriately.

Pins 1 & 2 on the CAM_CRANK_OUT terminals are connected to the 5v plane and GND plane, respectively. Pins 3 & 4 care CAM and CRANK signal outputs with LED's and current limiting resistors.

The F5529LP board itself provides 5v for USB ICDI and other related operations and normally has that connected between the debug interface and MCU but it can be disconnected which permits having two different 5v rails- one for USB connectivity when needed and one external 5v source. The only caveat is that the GND between the two sections of the LP are connected so if the GND potentials are different between the external and USB side there can be problems, but in the situation where the engine is in the vehicle and there are no other connections such as through a battery charger or such, the "floating" ground of the vehicle will equal the ground on the board so no problem there.

[abecedarian]

To add, my idea for using DACs was not to generate the CAM / CRANK signals but to generate voltages to simulate sensors without relying on potentiometers.

Considering they are roughly 'linear', if the reference voltage fluctuates, their output would fluctuate in kind. I.e. if the 5v rail is at 5v0 and the DAC is set to output 0x0800 (1/2 scale) it would output 2v5 and if the rail glitched to 5v2, the DAC output would be 2v6- exactly what would happen with normal resistive sensors... the MAP sensor might be the exception but that still falls within its output error range.

[kb1gtt]

The MAX992X chips are differential inputs, they don't care much about 0V. That is a very important feature and why they have better CMR than other chips that rely on GND as one of the signals. They have a mild pull to mid voltage, which is how they can be used for hall, as you let one input float to mid scale, and the hall goes from rail to rail.

One can also get op-amps with a differential output, which might help if we desire to make a floating output, but I don't see how that really helps. The differential input of the MAX chip doesn't really care where the voltage is, well doesn't care as long as you don't wonder like 1kV from GND.

If you have a 60 tooth wheel, you'll end up with around 24k transitions at high RPM. I wonder how many harmonics does one need to accurately re-produce that signal. I seem to recall any signal can be made from the sum of sine waves. I forget how many you need to get good accuracy. I'd bet you are fairly good with like 4 to 8 harmonics. So I would put a max desired frequency of around 192kHz.

[abecedarian]

You're kidding, right?

[Sudo]

Assume a 36 tooth wheel at 10000 RPM: 360000 teeth per minute / 60 seconds = 6000 teeth per second = 6KHz signal / 12KHz if you're counting rising and falling edges. MSP430G2553 @ 16MHz core clock (little brother to the F5529 in the LP I mentioned) can toggle pins well in excess of 50KHz; I suspect STMF32 can do at least that. So, toggling a couple pins isn't such the issue it seems. I mean, consider that these processors have instructions that are single-cycle, meaning it takes one clock cycle to do the job. At 16MHz, that's 16 million cycles per second; STM32 @ 80+ MHz? See what I mean?

Opps, I think I used RPS instead of RPM. Lol, so my math was a bit off. But nonetheless, my concern still stands for the slower MCUs. My initial thought was that I want to be able to generate an arbitrary waveform we can either defined or recorded. Assuming we are using a parallel DAC and trying to simulate a sawtooth at 12kHz (which is somewhat similar to VR waveform) the DAC would need to be 12kHz*Steps. The number of output steps will determine the smoothness of the waveform. So 32 steps per cycle(tooth) quickly brings you up to 384k steps per second, which means your GPIO needs to be at least 768kHz to be able to latch in each steps to the DAC, not even including the cpu cycles to load each step from RAM. But I guess with the 80 MHZ MCU, we shouldn't have a problem based on my corrected math. So nevermind! Perhaps this is overkill and unnecessary since we only need to generate a zero crossing event for the VR IC?

If my ideas are wild, please bare with me. I am still learning this stuff as I go.

[abecedarian]

Again, no need for a DAC to simulate VR outputs. But if you want to go there, AD9858 (can probably sample it for free, otherwise around $5 USD on ebay) is probably a good choice- it's a function generator. I might sample a few and work something out.