work in progress stimulator board

Hardware inside and outside of the ECU
puff
contributor
contributor
Posts: 2961
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: stimulator board

Post by puff »

vr output differs not only in frequency, but in amplitude as well :D , but that doesn't matter. once you tested vr circuitry at the desired frequency range, for other purposes you could use simple 555 circuit to generate a saw on the vr-input pin of your discovery board…or use debugging feature in java console.
guys, how do you plan to synchronize all these signals? is it really that necessary? may be plain excel spreadsheets would be enough for all calculations within acceptable value range?
it might be an option to build sort of a converter, which would have some input parameters, and the output as a pwm driver for motor with trigger wheel?
i.e. pwm=f(fuel,ignition,map)
though, experimenting with live engines is the best and most reliable (although expensive) way (imho)
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: stimulator board

Post by abecedarian »

I agree, puff, to a point.

The point of the stimulator is to be able to tweak things externally and see how the controller responds.

For instance-
- high vacuum, low throttle, high RPM;
- high vacuum, high intake temp, open throttle, low RPM and cold coolant;
... what would the controller do? Does it respond as expected?
Without a live engine you're willing to sacrifice, you won't be able to tell.

It's more of a sanity check before hitting the real world than anything else.
And the unit I'm working on would both stimulate the ECU and be able to log sensor data, I hope.
You can lead the horticulture but you can't make them think.
puff
contributor
contributor
Posts: 2961
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: stimulator board

Post by puff »

the thing is static values are virtually of no use. you need feed back from the motor, and with stimulator you won't have any, or will you?
for instance, the temperature during cold start changes pretty quick.
or, the engine's response to changes in fueling can also be very quick, and it's more important to see how quickly the ECU accommodates to these new conditions.
Once again, with fixed values of vacuum, throttle and RPM, I guess you could easily calculate ECU's behavior in excel.

Besides, some other threads in this forum suggest that, say, vacuum readings are not flat, but have some fluctuation frequency which is directly related to engine's RPM. And if the ECU is capable of reading these fluctuations, they should be synchronized with the teeth of the trigger wheel…

From my point of view, the really useful s(t?)imulator should first log (with pretty high bitrate) the readings of some set of sensors on the live engine with stock ECU (at least the most common situations: cold start, hot start, light load/low rpm, high load/low rpm, etc.) and then feed these readings to the ECU.
So, imho, the first problem is to decide, which frequency response rates we are dealing with when using certain sensors.

It might be so that instead of feeding real signals from electronic circuits it could be easier/more effective to feed values from sorta mathlab? In this case all you need is read these values from the real-life sensors of the real-life car, and then check if the real-life behavior of the stock ECU corresponds to that of rusEFI?
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: stimulator board

Post by abecedarian »

Very good information, puff.

So, maybe I should have my stimulator able to tap in and sample sensors during warm up and other situations, and log those, then be able to replay those?

... waiting for Jared to chime in... ;)

Logging was part of what I was trying to do; just didn't have the total simulation of outputs, i.e. playback, considered.
You can lead the horticulture but you can't make them think.
puff
contributor
contributor
Posts: 2961
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: stimulator board

Post by puff »

as for playback
http://datasheet.octopart.com/AD5171BRJZ10-R2-Analog-Devices-datasheet-8546.pdf
i2c, 5µs setting time, though just 6-bit resolution (i.e. 64 positions…)
or this one:
http://datasheet.octopart.com/AD5206BRU10-Analog-Devices-datasheet-8405.pdf
256 position, 6 channels, setting time 2 to 18 µs depending on resistance…
Sudo
Posts: 92
Joined: Mon Mar 17, 2014 12:53 am

Re: stimulator board

Post by Sudo »

I agree that logging is ultimately what's useful. The ability to log without having an engine is where I find the value of the stimulator. I think what we all want as the end result is to have an engine emulator. We can have feedback from the ECU for injection and ignition. We can create test profiles to emulate different scenarios.

Edit:
I just thought about this again. There seems to be no need for feedback at all. If our stimulator can sweep all possibility of the sensors outputs and we have the ability to record all of the results, we have all the data needed from the stock ECU to generate all maps.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: stimulator board

Post by abecedarian »

Sudo wrote:There seems to be no need for feedback at all. If our stimulator can sweep all possibility of the sensors outputs and we have the ability to record all of the results, we have all the data needed from the stock ECU to generate all maps.
Except without the ability to log the engine in operation, you're stuck with theoreticals.
You can lead the horticulture but you can't make them think.
Sudo
Posts: 92
Joined: Mon Mar 17, 2014 12:53 am

Re: stimulator board

Post by Sudo »

But it's not theoreticals if its from a stock ECU. Those are proven outputs. The ECU doesn't care of its a real engine or not, it will still output the same result. I am not saying we shouldn't log the actual engine running. This is just a safer way to verify a design without possibly destroying motors And also it will dual purpose as a stock ECU cloning tool.
Sudo
Posts: 92
Joined: Mon Mar 17, 2014 12:53 am

Re: stimulator board

Post by Sudo »

abecedarian wrote: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.
Image
I just reminded myself why regular signal generator won't work. You won't be able simulate missing tooth with the AD9858. This is the reason why I wanted to use a DAC to generate VR signal. We would have full control of how we want to define each wheel profile.
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: stimulator board

Post by abecedarian »

Sudo wrote:
abecedarian wrote: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.
Image
I just reminded myself why regular signal generator won't work. You won't be able simulate missing tooth with the AD9858. This is the reason why I wanted to use a DAC to generate VR signal. We would have full control of how we want to define each wheel profile.
Actually, you could. You only have to turn it off for the missing tooth.
You can lead the horticulture but you can't make them think.
Sudo
Posts: 92
Joined: Mon Mar 17, 2014 12:53 am

Re: stimulator board

Post by Sudo »

:shock: That just doesn't sound right and should be illegal. Lol :D But seriously. You would have to synchronize the MCU and AD9858. Also any glitch you produce from turning it off can falsely trigger a zero crossing event. It sounds more effort than generating your own signal. Unless you have something else in mind that I am not aware of, I can't see that as a reliable method. :?
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: stimulator board

Post by kb1gtt »

The device I see a need for is a device I've once upon a time called a play recorder. It would be a device that can measure both voltage and current of a signal creating a kind of recorded file. Then it can play back those same signals by playing the recorded file.

This would be handy, as someone with a running engine could record the engine before they even start a project. Then they could send the recording off to a remote developer and or tuning gooroo. The remote person could make tuning tables, or if required could even develop new features as required. The remote person could play those signals back to something like a rusEFI system and they could develop until they can produce the same signals. Then when that happens, the original person who did the recording can start a project of converting an engine with a high level of confidence that the system will work.

I don't see any reasons why a java script or what ever can't make the recorded file based off of specifications. For example, you could tell a program your displacement, your VE table, type of sensor, ect, then the java script would predict what a map, VR, TPS ect are doing and simply have a program generate the recorded file. That file could then be played to the development board and used to check things like tolerances of incoming signals, common long term wear and fatigue issues, or any number of design validation steps during the development cycle.

Longer term the such a device and recorded file could be used to validate equipment that's suspected to be broken or damaged. Basically if you have some kind of failure, you could play back a file to it, and verify if the output signals are correct or not.

Of course a play recorder could be useful to more than just engine control and play back.
Welcome to the friendlier side of internet crazy :)
puff
contributor
contributor
Posts: 2961
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: stimulator board

Post by puff »

with js you can simulate just few basic signals that could be far away from the real engune signals: displacement is not that necessary, sensors do tend to degrade with time, you have to count for cams configurations, lobes condition, intake and exhaust pressures, condition o plugs, fuel quality... so you can't make simulations wih formulas only.
i'd be controlling initial ignition with a stroboscope, and I'd prefer to have a programmable limits for advance. probably the rest (if not caused by he bugs) is not that dangerous.
however, the idea of 'remote administration' is not that bad :D
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: stimulator board

Post by abecedarian »

The code below (Arduino / Energia friendly) samples a pseudo MAP sensor, in real time, and does the transfer functions abstracted for the sensors used on my motorcycle, and displays those values on a 24x6 IIC/I2C LCD display... if it weren't for the slow IIC/I2C speed display, it would update the values at around 100,000 times per second.

Probably worth noting that the bike uses 4 MAP sensors: one for Alpha/N functionality at certain TPS angles, one for Speed/Density at lesser TPS angles, one for Barometric and one for ignition advance. The code below only does P1 (speed/density- should be labeled Pb) and P2 (alpha/n) equivalences, meaning Pb saturates at ~101kPa, P2 is ignored below 80kPa. So, Pb is the 'speed/density' one and P2 is the 'alpha/n' one... and is a compensation value like air temp is since it's running alpha/n under boost.
P1 is a 'barometric' sensor, and Pign is used for ignition advance which the ECU has no control over.
Don't make me explain it more than that, please. ;)

And the algorithm exhibits around 00.02 volt variance / error, well within the error of most sensors.

Code: Select all

#include <Wire.h> 
#include <LiquidCrystal_I2C.h>

LiquidCrystal_I2C lcd(0x20,20,4);  // set the LCD address to 0x20 with 20 x 4

void setup()
{
  lcd.init();             // initialize the lcd 
  lcd.backlight();        // turn the backlight on
  analogReference(INTERNAL2V5); // use internal 2.5v reference

// external sensors are divided with 100K resistor divider network
//ADC inputs are sourced from the connections between resistors

}

int sensorPin = A0;    // select the input pin for the potentiometer
int sensorValue = 0;   // variable to store the value coming from the sensor
float kPa = 0;

void loop() {
  sensorValue = analogRead(sensorPin);
  kPa = (sensorValue*2.5)/1024*100;
  
  lcd.setCursor(0,0);
  lcd.print("AD=");
  lcd.print(sensorValue);
  lcd.print("   ");
  lcd.setCursor(10,0);
  lcd.print("kPa=");
  lcd.print(kPa);
  
  lcd.setCursor(0,1);
  lcd.print("MAP:");
  lcd.print(5 * ((0.00369 * kPa) + 0.04));

  lcd.setCursor(0,2);
  lcd.print("Pb:");
  lcd.print(constrain((0.036 * kPa) - 0.103, 0.00,5.00));

  lcd.setCursor(0,3);
  lcd.print("P2:");
  lcd.print(constrain((0.020 * kPa) - 0.830,0.00,5.00));

  delay(100); // 100ms delay for updates since LCD is slow

}
P2_200kPa.jpg
P2_200kPa.jpg (11.66 KiB) Viewed 19584 times
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: stimulator board

Post by abecedarian »

Might be worth noting that the value "AD" is an 8 bit value the 10 bit ADC on the MSP430G2553 returned, after some smoothing.

So, not hard to do the transfer function:
kPa = (sensorValue*2.5)/1024*100;

As mentioned, most sensors will output 0.2v to 4.8v, so anything above (4.8/2=2.4) is generally going to be invalid. No matter what, though, no sensor can output anything above the rail, so it's possible to clamp values in software such as "if MAP > 5VRAIL then MAP = 5VRAIL"; the same is true of all sensors if / when they use a common 5v rail... might even be worthwhile to check if a sensor is near, at or above the rail and toss a trouble code.
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: stimulator board

Post by abecedarian »

Below is another example using external reference sample and limiting (note- code is Energia on MSP430G2553 with 20x4 LCD & IIC). ADC jitter / error causes ~0.02v fluctuations; there is simple add and divide smoothing that takes a few cycles to become effective.

Circuit and code below. Not shown are filter capacitors across the outputs to ground and hard diode clamping, and do note that the pot won't reach full rail-rail outputs due to the weak pull-up and pull down effects the resistor dividers will exhibit.

Code: Select all

GND-->100K<--+-->100K<--5v0
             |
A0-----------+

GND------------->potentiometer<------------------5v0
                        |
GND-->100K<--+-->100K<--^
             |
A1-----------+

Code: Select all

#include <Wire.h> 
#include <LiquidCrystal_I2C.h>

LiquidCrystal_I2C lcd(0x20,20,4);  // set the LCD address to 0x20 with 20 x 4

int refPin = A0;       // select the input pin for the reference
int sensorPin = A1;    // select the input pin for the potentiometer
int refValue = 0;      // variable to store the sampled reference voltage
int sensorValue = 0;   // variable to store the value coming from the sensor
float a1volts = 0;          // variable to accumulate ADC reference readings
float a2volts = 0;          // variable to accumulate ADC sensor readings

void setup()
{
  lcd.init();             // initialize the lcd 
  lcd.backlight();        // turn the backlight on
  analogReference(INTERNAL2V5); // use MSP430 internal 2.5v reference

  // external sensors are divided with 100K resistor divider network
  //ADC inputs are sourced from the connections between resistors

}

void loop() {
  refValue = (analogRead(refPin) + refValue) >> 1;
  // simple sample and average smoothing
  sensorValue = (analogRead(sensorPin) + sensorValue) >> 1;
  // simple sample and average smoothing

  //if (sensorValue > refValue) sensorValue = refValue;
  // limit sensor value to rail

  a1volts = (refValue * 2.5) / 1024 * 2;
  // calculate A0 / reference voltage
  // *2 because of the voltage divider
  a2volts = (sensorValue * 2.5) / 1024 * 2;
  // calculate A1 / sensor voltage
  // *2 because of the voltage divider
  
  // Below writes values to the LCD display
  // also writes blank spaces to 'clear' 
  // characters that may be left-overs.
  lcd.setCursor(0,0);
  lcd.print("AD1=");
  lcd.print(refValue);
  lcd.print("  ");
  lcd.setCursor(10,0);
  lcd.print("V=");
  lcd.print(a1volts);
  lcd.print("  ");
  lcd.setCursor(0,2);
  lcd.print("AD2=");
  lcd.print(sensorValue);
  lcd.print("  ");
  lcd.setCursor(10,2);
  lcd.print("V=");
  lcd.print(a2volts);
  lcd.print("  ");

  delay(250);
  // delay since LCD updates are slow
}
You can lead the horticulture but you can't make them think.
blundar
contributor
contributor
Posts: 141
Joined: Tue Jan 07, 2014 4:38 am
Location: Cincinnati, Ohio
Github Username: blundar
Slack: Dave B.
Contact:

Re: stimulator board

Post by blundar »

I've had to tackle the issue of VR sensor simulation for a commercial product that I helped design.

Before you get too brainiac about this, it pays to examine what the "detector" circuitry is inside the ECU. In almost all cases, VR sensor interfaces boil down to zero-crossing detectors that trigger on either the rising or falling edge of the zero crossing. (This is why polarity DOES matter with VR sensors! Their signal waveform is inverted when the wires are reversed, which almost always skews the expected zero crossing point.) ((I'm sure Jared or one of the "real" EEs can chime in and fill in some blanks here))

So... With that said. What do you need to generate to please a VR sensor interface?
1. Positive voltage swing with reference to gnd
2. SHARP downswing
3. Zero crossing
4. Negative voltage swing with respect to gnd
5. return to resting (gnd) state
6. (HARD) Varying amplitude with respect to RPM - more RPM, greater amplitude of signal

In practice, if you can achieve #1-#5, you can typically fool almost all VR detectors. Only relatively new ECUs are going to be smart enough to even try to monitor the peak voltages with respect to RPM.

In practice, RS232 transceivers are perfect for a cheap solution. RS232 uses either +3 to +15v or -3 to -15v for 0s and 1s. Many transceivers have a "silence" option (or you can use a small FET) They're dirt cheap and you can get them in a package with 2-4 on board and most of them easily do 100K baud (i.e. bits/sec - speed of wheel) which is far in excess of what you need for auto purposes.

Super ghetto: use MAX232, hook outputs together (with current limiting resistor), hook inputs to 2x GPIO pins (possibly attached to a hardware timer?), run signals inverted ( 0 1 ) to produce opposite outputs i.e. "gnd" or resting state, drive both pins 0 or 1 to produce high/low swings. I've tested this approach to 12,000 RPM with a 24 tooth wheel pattern and it produces reliable enough signals to fool a Honda and Toyota ECU.

Less ghetto: create a -voltage supply, use 3 GPIO pins. One FET to control +V, one FET to control -V, one FET to control pull to GND.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: stimulator board

Post by kb1gtt »

I kind of agree with the 0 crossing comment. It seems there is a perceptions that GND has something to do with it though. There are chips that use GND as one side of the input, but chips like the MAX9926 use a differential input. The diff input doesn't really care that much about where GND is. It cares that input + is above or below input -. The max chip will identify the max + difference, and the max - difference. It will generate an internal 0 crossing reference by taking the min and max and picking half scale of the two, which may be close to GND, but often is not close to GND. Then when ever the signal crosses that virtual 0 crossing reference, the output changes.

So if you generate a +/-5V square wave centered around GND, yeah you'll get a signal that the max chip can decode, and the virtual 0 crossing reference will be at GND potential. However you can also also generate a 0-5V or 0-3.3V square pulse and that will work just as fine. The MAX chip will generate the 0 crossing reference at either 2.5V or 1.65V.
Welcome to the friendlier side of internet crazy :)
User avatar
AndreyB
Site Admin
Posts: 14327
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: stimulator board

Post by AndreyB »

Exactly, we do not need to make the same signal as a real VR sensor - all we need is a signal which a typical VR decoder would INTERPRET as VR output.

Can someone please take a napkin and draw the schematic? With a BOM?

Should we maybe even make a super-tuny KiCad PCB for just VR stimulator?

Is it time to split 'VR stimulator' into a separate thread to make matters simpler?

I have three or four relatively modern ECUs in my closet, let me make a little inventory and I would be glad to try fooling one of them.
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
Sudo
Posts: 92
Joined: Mon Mar 17, 2014 12:53 am

Re: stimulator board

Post by Sudo »

As far as the physical driver, using RS232 driver is a very good idea. RS485 driver seems even better since it is differential. I think I will use that. Thanks for the idea! :D
User avatar
AndreyB
Site Admin
Posts: 14327
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: stimulator board

Post by AndreyB »

@ would you be available to draw some KiCad schematic? A tiny KiCad PCB?
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
Sudo
Posts: 92
Joined: Mon Mar 17, 2014 12:53 am

Re: stimulator board

Post by Sudo »

I can draw the schematic. I was planning to do one of my own anyway. I just need to figure out what else needs to be on the board.

Based on what's been discussed, if you just need the VR driver, RS485 breakout board are dirt cheap. http://www.ebay.com/itm/MAX485-module-RS-485-TTL-to-RS485-MAX485CSA-Converter-Module-For-Arduino-/170934217208?pt=LH_DefaultDomain_0&hash=item27cc7929f8
puff
contributor
contributor
Posts: 2961
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: stimulator board

Post by puff »

(This is why polarity DOES matter with VR sensors! Their signal waveform is inverted when the wires are reversed, which almost always skews the expected zero crossing point.) ((I'm sure Jared or one of the "real" EEs can chime in and fill in some blanks here))
from my understanding, reversing the wires just causes a slight shift in timing for the whole wave, and nothing more? or it has something to do with the Maxwell's rule, Lorentz force, etc? I mean if we have just a vr sensor and scope, will we be able to see any difference in signal when the wires are reversed?
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: stimulator board

Post by kb1gtt »

For a 36-1 wheel, it will shift by about 5 degrees, as there is a rising and falling edge about every 5 degrees. Also the skipped tooth would be the flipped, so 0V instead of 5V or vice versa.
Welcome to the friendlier side of internet crazy :)
User avatar
AndreyB
Site Admin
Posts: 14327
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: stimulator board

Post by AndreyB »

Can someone please explain how I am going to use MAX485 module RS-485 exactly?

So there are A and B inputs... And DI DE RE RO outputs. How is this related to VR? I am just a software developer you know...
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
Sudo
Posts: 92
Joined: Mon Mar 17, 2014 12:53 am

Re: stimulator board

Post by Sudo »

RS485 is a bidirectional differential pair. So you only need to use to transmitter part of it, which is the driver.

DI - Driver input, send your 1 and 0s here with your MCU.
DE - Driver enable, set 1 for on, 0 for off.
/RE - Recevier enable, set 0 for off, 1 for on. Normally this is tied together with DE so direction is controlled with 1 pin. So not needed, keep it high to disable it.
RO - Receiver output, you don't need this since you only want to transmit.

Connect A and B to your stock ECU VR inputs. A and B is your differential output that will mimics the VR signal.
A - Non inverting output
B - Inverting output
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: stimulator board

Post by kb1gtt »

I can see what sodu is saying. It's a low cost differential driver, which can be connected to a serial device of the STM32. Then you send a series of pulses out the 0-5V and you'll get a differential output on the 485. I guess I'm not seeing why we really care if it's differential or not. Perhaps it could be handy for VR signals that use the GND wire as one of the signal wires.

This max chip is differential, but it's also limited to 0-5V. When you command a + level signal, it will try to drive something like 40mA in the + direction. I see the datahseet notes 2V with a 50 ohm termination resistance, so about 40mA of current is passing at that point. If you have a higher impedance, the 485 lines will saturate at 5V and current passing through the buss current will drop below that 40mA. If you have an impedance of more like 60ohms for the end of line termination resistor, then you'll see 2V generated that can technically be pulled up from from GND to something like 2 or 3V. Note I chose 60ohms, as that's what you would get if you had the traditional pair of 120 ohm termination resistors at each end of the bus. In our case we don't need the termination resistor that's closer to the so one 60 ohm at the far side would suffice. Any how, note I said that can technically be pulled up from GND. It can not be pulled below GND. So I don't see how this would help a VR sensor chip that uses the GND signal as one of it's wires. Remember an op-amp is just some transistor connected either to V+ or V-, those transistors can only pull to the rails. In this case, they can only drive around 40mA as well. Also the 485 chip induces a variety of signal delays. Think of phase shift of LRC circuit, the signal delay will vary some as you increase RPM. I would think that the delay is minimal though.

Hmmmm, I guess I can see the 485 as helpful if you have a long noisy signal wire, but with the simulation I kind of doubt that will be the case. I would suggest we get the 0-5V TTL style working first, with the typical high impedance, then if we need to decrease the noise floor caused by spark plugs and such, then we can switch to the 485 thing. However I don't see this working for the GND referenced VR input sensors.
Welcome to the friendlier side of internet crazy :)
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: stimulator board

Post by kb1gtt »

To work properly with GND referenced VR, you would really need something like a isolated differential amplifier. Then you would also need to generate a -V for the op-amp's output, such that it can pull below GND. http://www.ti.com/lit/ds/symlink/amc1200.pdf‎
Welcome to the friendlier side of internet crazy :)
Sudo
Posts: 92
Joined: Mon Mar 17, 2014 12:53 am

Re: stimulator board

Post by Sudo »

@kb1gtt

Yes, I only suggested RS485 because RS232 was used with success. And because it was cheap and readily available. I really should verify the details first before making suggestions :( I do have a bad habit of jumping to conclusion really quickly. But thanks for pointing the details out to me.

I agree with your points. But before I go further, I need to clear up what I think a VR signal should be. Is it true that the VR signal can go pass 5v at high RPM? Unless there is circuitry in the sensor itself, I don't see how voltage is limited in real world scenario since amplitude varies with RPM. The voltage is actually a function of the ECU inputs depending on how much energy is generated by the VR. If we don't have anything connected to the VR sensor, the voltage would ideally go to infinity. We only see a certain voltage with a scope because of the input impedance of the meter and whatever it is connected to, which is why it is varying with RPM or energy generated. It is current thats being generated. I understand the current limit of the Maxim IC since VR can only generate so much energy, so the current probably will never go beyond 40mA. And even though the Maxim chip says 5V 40mA limit on its inputs, I don't see anything in the functional diagram taking up to 40mA other than their clamping diodes once it go beyond 5V. So it seems we only need to limit the current of our ouputs since the Maxim VR chip is designed to clamp voltage to the rails up to 40mA. :?: But this is assuming an ECU uses the Maxim chip. We really don't know what stock ECU uses as their VR inputs.

For the Maxim IC, it seems we can still use the RS485 since its output is typically under +/-10mA. Also, if we want to be on the safe side and avoid going beyond 5V all together, we can just use LVDS drivers instead of going through all the trouble of generating a negative rail. Something like this: http://www.mouser.com/ds/2/149/FIN1531-81456.pdf And we can apply current limiting resistor if needed. But if we choose a driver with under 40mA, which most are, we should be ok. Hmm, i'll give this more thought. But I think this is ok so far.

I think to model the VR sensor, we really need to figure out what is the maximum energy that is typically generated by the VR sensors in milliwatts. Then, we can apply limiting resistors to any differential output to match same maximum power output, no matter if it is RS485 or LDVS or logic outputs or OpAmp. So for the stimulator board, the VR output should have series resistors to make it possible to fine tune the power output, if needed. But I am confident that if we can get a ball park of what kind of power it typically generates, we will never need to change it. It doesn't seem like it needs to be that precise. If we limit the current, I think it is perfectly safe to apply it to any input that expects a VR sensor signal.

I further agree that VR signal doesn't have to be differential. It just needs to generate opposite current on the transitions. Differential driver just seems to match the VR model easily and cheaply, with only 1 component needed. Another method we can think about is to add a high pass filter with a transformer or common mode choke to the differential output. A differential output with a high pass filter will model the varying amplitude with frequency. Then driving that to the transformer models the current generation nature of the VR sensor. But maybe we are going way beyond what it's needed. :ugeek:

I like the simple differential driver more. ;)
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: stimulator board

Post by kb1gtt »

RS232 is +/- 12V, and generally can only provide like 1mA. We might be best off with at MAX232 instead of the 485 for shifting from TTL serial to long hall serial, also 232 generate a + and - voltage.

VR's vary in what signals they will produce. I once heard a claim that a really hot and really fast reving engine could get up to 300V. However I think 50V is a bit more reasonably for OEM setups, and are commonly well below that. I understand they are commonly above 5V. I wish I had better data, or some kind of scope screen captures to reference. The best I can offer is a vague set of ball park numbers.

I seem to recall the MAX9926 generally has a 5k or 10k input impedance, so 1mA of drive will drive the +/-12V from 232.
Welcome to the friendlier side of internet crazy :)
Post Reply