1970 Datsun pickup L16 TBI conversion

[mattf]

Hi!

Here is the candidate, my 1970 datsun 521, with stock L16 and 4spd manual. Currently it is stock carb and points based ignition. I'm starting with a TBI conversion for simplicity.


I modified a distributor from an early 90's toyota pickup to fit, also adding a second VR pickup to give me 4+1 signal from the cam.


Here is what the signal looks like:


I ordered a Frankenstein PCB kit, and have populated it enough to drive a single injector and single coil. Using the Mazda D 1+4 decoder I was able to get the position to sync, however I believe it is not quite correct (see question 1 below).

Now for the questions,
1)Based on the datasheet, the MAX9926 will transition low at the rising edge of the VR signal. This is also what I observed:

Unlike a hall or optical sensor, the pulse width is not a constant angle. Based on this information, I think the rusEFI position decoder should only use the falling edge of the VR signals. I found the setting to tell rusEFI to only use the rising edge, however I can't find a setting to either tell it to only use the falling edge, or alternately tell it to invert the trigger signal before processing.

2)I have not been able to find a way to configure rusEFI to only use a single injector. I'm sure it is obvious, but I can't see it.


Thanks for the help,

-Matt

[AndreyB]

A1: would it be an option to flip the sensor wires which go into MAX9926?
If flipping the wires is not an option I would change the firmware and flip the callbacks in trigger_input.cpp
The price of conditional jumps is pretty depressing, I would love not to add another condition into the trigger code flow.

A2: IM_SIMULTANEOUS and not assign output pins to injectors #2, #3 and #4?

[kb1gtt]

A bit more to russian'ss A1 and russian will need to comment as I could be wrong, but I believe the software goal is to keep it feature rich while keeping it as simple as reasonably possible. This means getting everyone to flip the polarity physically such that everyone's screen captures and such have the same polarity. It adds a certain level of consistency and repeat-ability. I believe that not having software edge selection was partly intentional. Or perhaps it was a resource issue, every option added to software adds lots of error checking and validation to ensure it's not causing problems. I'm not quite certain why it's not there. It might have been bumped lower priority against developing other features.

Looks like there is a slightly different angle from the 4 tooth pulse and the 1 tooth pulse. Do you know that angle?

Are you expecting highZ or low Z injector? I suspect you can get by with a single HighZ injector, but I don't know your flow rates, pump pressures, etc.

[mattf]

Thanks for the prompt replies.

A1: would it be an option to flip the sensor wires which go into MAX9926?
If flipping the wires is not an option I would change the firmware and flip the callbacks in trigger_input.cpp
The price of conditional jumps is pretty depressing, I would love not to add another condition into the trigger code flow.

A bit more to russian'ss A1 and russian will need to comment as I could be wrong, but I believe the software goal is to keep it feature rich while keeping it as simple as reasonably possible. This means getting everyone to flip the polarity physically such that everyone's screen captures and such have the same polarity.

Yeah I can totally understand wanting to keep the code clean. Unfortunately the behaviour of the MAX9926, along with the nature of the VR sensors means the circuit doesn't behave well when the signal from the VR sensor is reversed (I was quite surprised by this). I think this is a result of the variable threshold function of the MAX9926 causing false triggers from the flat part of the sensor signal. I'm doing a terrible job of explaining this, but fundamentally the MAX9926 wants to trigger off the sharp transition of the VR signal, not the slowly rising ramp.

I'll consider my options, and maybe try changing the callbacks as you suggest, though I don't love the idea of making custom changes to the code. Also, it seems to me that this is something that will affect anybody using VR sensors with rusEFI?

A2: IM_SIMULTANEOUS and not assign output pins to injectors #2, #3 and #4?

With this setting the console engine sniffer is still showing 4 injector channels, however they are all firing together. Is this correct, or should it just show a single channel?

Looks like there is a slightly different angle from the 4 tooth pulse and the 1 tooth pulse. Do you know that angle?

Are you expecting highZ or low Z injector? I suspect you can get by with a single HighZ injector, but I don't know your flow rates, pump pressures, etc.

I don't know the angle difference, I assume it probably marked TDC in the original application, but when I added the 2nd sensor I had no way to know the correct position. If necessary my plan was to calculate the angle based on the output of the 2 sensors using the scope or a logic analyser. Is it necessary to know the angle?

I am using a 90's 4cyl TBI throttle body from the auto wrecker. I don't know the flow rate of the injector yet, but It looks like it is a low Z (~2ohm) so I guess I'll probably try running it with a series resistor. I'm sure this isn't the best method, however it is also not exactly a high performance application and only has to perform better than the stock 45 year old hitachi carb

-Matt

[kb1gtt]

Frankenso and Frankenstein were designed for HighZ. The PCB traces are probably a bit small for LowZ and the thermal design is probably going to make them heat up more than desired. I would recommend keeping an eye on the injector driver temperatures. They have thermal shutdown, so you'll know it if it gets to hot How many cyc's / displacement are you working with? AKA how much fuel do you need? Do you have a fuel pump if so what pressure does it make? I suspect this is not high rev or high HP, so HighZ would likely flow enough fuel.

About LowZ, I guess you could help the heat issue by having the hold with a resistor on one channel, then use a different channel for the push transition. However the software to back this does not exist. At a minimum, that would spread the heat to two drivers and would double the copper used for the high current conditions. A good sized heat sink would also help with getting the BTU's out.

Also might as well start with ignition, then add fuel. You could probably do the spark now, and change the TB later on. Does the engine currently start and run? Perhaps you can put a HighZ in the LowZ's place.

Are you planning for fuel or spark first? I'm guessing the spark doesn't currently work, or perhaps you haven't added that modified distributor yet. What is your plan for spark? Do you have an ignitor planned? You might find this hand sketch interesting. See the J701 which was used at least once on a Neon.

http://rusefi.com/wiki/index.php?title=Manual:Hardware#J701_NEON_engine_schematics

[mattf]

I'm just getting started, nothing is installed in the truck yet. I'll probably start with spark and add fuel later. I have a 40+ psi in tank fuel pump from a honda to retrofit before I can do fuel. The TBI runs at a lower pressure, however it includes a fuel regulator so based on my research it should work ok. Both the fuel pump and throttle body are from engines with higher power than the datsun (which is a 1.6L 4cyl, and probably less than 100hp new) so i'm not too concerned about running out of fuel, If anything I am worried about the low end/smooth idle.

For spark I have the igniter and coil from the toyota that donated the distributor. It seems to function as expected as a dumb igniter.

The engine runs now, and I am hoping to reduce the downtime as much as possible from the conversion.

Regarding the injectors, my plan was to simply use a current limiting resistor (5-10ohm) in series with the injector. I think this has been done before. I suspect it will affect the dead time and early opening time of the injector, but I'm hoping that I can work around that.

Thanks for your input, feel free to tell me I'm wrong.

-Matt

[kb1gtt]

I'm a bit ignorant about typical LowZ pressures and such, but I generally expect the fuel pump to generated around 50 to 70 psi then the regulator generally drops the rail down to around 40 psi. The regulator usually has the vacuum line to the manifold. That vacuum line will adjust the rail pressure to keep a constant 40 psi drop across the injector from the fuel pressure to what ever pressure is in the manifold. So lets say at WOT you have a really low air resistance plenum, and lets pretend you get nearly 0 psi drop from ambient. Lets say the regulator is set to 40 psi, your fuel rail will be 40 psig (54 psia). The "g" being gauge, which would be around 14 psia with the "a" being absolute. Any how, lets then say you snap the throttle shut, the manifold pressure might drop to something like -10 psig (4 psia) and the regulator will change from 40 psig to 26 psig, such that the difference across the injector is still 40 psi. That's the ball park expectations for HighZ, but I believe holds true for LowZ, but I could be wrong. I know it's a kind of basic overview of the fuel system, but I figured I'd post it just to make sure we are all on the same page. The goal of the regulator is to keep your flow rates the same for the same pulse widths being sent to the injector. With out it you would have to vary the injector PWM's to deliver the correct grams of fuel.

I believe for LowZ you need the non resistor for the push part of push and hold or your dead times will vary greatly and you'll have lots of trouble with idle or low flow delivery. Basically you'll aim to deliver say 1mg of fuel, but you'll actually deliver 3mg which could be a flooding condition.

Any how, could you connect the distributor to a hand drill or something to spin it at about the speeds you need? If so, you could connect some spark plugs and make the entire spark system work with out any changes to the engine. You could vary the RPM and validate you are reading the proper RPM, and decoding the wheel correctly.

Also to help minimize the engine down time, you can create a flow bench out of your new tank and new injector. Then you can do a bunch of validation of the flow rates into a graduated cylinder.

[mattf]

Any how, could you connect the distributor to a hand drill or something to spin it at about the speeds you need? If so, you could connect some spark plugs and make the entire spark system work with out any changes to the engine. You could vary the RPM and validate you are reading the proper RPM, and decoding the wheel correctly.

Also to help minimize the engine down time, you can create a flow bench out of your new tank and new injector. Then you can do a bunch of validation of the flow rates into a graduated cylinder.

This is basically exactly what I'm working on right now. The traces I posted above were from the distributor being spun by drill. I'm planning on setting up a bench fuel system to verify the injector circuit and test their flow rate.

I'm totally on board regarding your description of the fuel system/fuel pressure regulator. I'm pretty sure the old GM TBI systems (like what i'm using) ran at a lower pressure (google seems to think somewhere around 12psig). I guess I'll know once I get the bench test setup.

-Matt

[kb1gtt]

I seem to recall that 12 psig is around the high end of what the carb fuel pumps provided. So it wouldn't surprise me if an early injector system used that same pressure.

About the max 9926 chip, I see what you are saying. In the below on page 3 it notes the "Watchdog Timeout for Adaptive" is typically 85mS but could be as much as 125mS or as little as 45mS. In the picture you posted, I'm assuming that's your single tooth wheel, running at 480RPM, which is pulsing about 125mS. Pulses which happens that slow will cause the adaptive window to reset, and it will reset to 33% from the peak to peak voltage in that window, with a minimum around 5 to 10 mV. This is causing a small amount of noise to cause a false trigger. If you were to rotate the engine faster, it would catch a pulse in the window and you'd be all set. As well I expect the 4 tooth wheel would be pulsing once every 31.25mS, so the 4 tooth wheel would be OK, but the CAM is causing some noise issues as lower cranking RPMs.

http://datasheets.maximintegrated.com/en/ds/MAX9924-MAX9927.pdf

I expect you'll have that same issue with the polarity flipped or not. It looks like you are using your scope with GND strap to measure a differential signal, as well I don't expect a 2.5Vp-p signal for such a low RPM. I fear your VR may be a hot one, or your scope might be reading incorrectly. Perhaps the 10X vs 1X scale was not correct. I see it was on the 10X setting for channel 2. Can I get a verification the channel 1 was really measuring 2.5Vp-p? If it is, can you crank you drill up to your max RPM and see what kind of voltages you get then? You may need to install a loading resistor. I expect you currently do not have R111 or R112 installed. You may need that if your VR is supper hot. Also did you use the 5k's noted for R102, 107, etc? Where are you measuring your VR signal, I'm assuming you're measuring the VR directly. If so remember the max9926 will be seeing that signal after the resistors, so the max chip is likely seeing a much lower voltage than what is on the screen. As well you were probably only looking at one side of the VR, not the differential signal that the max chip is seeing.

Also about that 2.5V DC offset, this tells me you have the GND strap connected to the MCU negative or chassis GND. Be careful doing this, as your scope GND strap is connected to your wall outlet GND wire. You can easily get GND loop issues that often cause problems. You'll likely be best off taking that measurement with ch1 on one side and ch2 on the other side with the GND straps connected together. This makes your scope a differential sensor instead of single ended, and prevents GND loop issues. Then if you connect ch1 to one side of R111 an ch2 to the other side of R111 to ch2, then you'll see what the max chip is seeing. But beware do not connect your GND wire to either side of the max chip directly, it will short your 2.5V bias to GND which may break something.

Russian, how hard is it to make the CAM signal less sensitive, such that it only cares about a CAM pulse +/- 45 degrees from the 4 tooth wheel? If that can be done in software, it would allow him to accurately detect the low RPM cranking situations. If not then it will likely be a much harder item to resolve in hardware. Is there any chance the CAM is already less sensitive like that? Would this extra pulse on the CAM at low RPM cause a problem with the wheel decoder?

[mattf]

good points,

About the max 9926 chip, I see what you are saying. In the below on page 3 it notes the "Watchdog Timeout for Adaptive" is typically 85mS but could be as much as 125mS or as little as 45mS. In the picture you posted, I'm assuming that's your single tooth wheel, running at 480RPM, which is pulsing about 125mS. Pulses which happens that slow will cause the adaptive window to reset, and it will reset to 33% from the peak to peak voltage in that window, with a minimum around 5 to 10 mV. This is causing a small amount of noise to cause a false trigger. If you were to rotate the engine faster, it would catch a pulse in the window and you'd be all set. As well I expect the 4 tooth wheel would be pulsing once every 31.25mS, so the 4 tooth wheel would be OK, but the CAM is causing some noise issues as lower cranking RPMs.

http://datasheets.maximintegrated.com/en/ds/MAX9924-MAX9927.pdf

I expect you'll have that same issue with the polarity flipped or not.

I arrived at the same conclusion regarding the source of the false triggers, however I wasn't able to reproduce the false triggers with the polarity flipped. My conclusion was that it was because the MAX9926 is detecting the signal going above a positive threshold. With the polarity flipped the signal ramps negative before flipping positive, so no false triggers are produced.

It looks like you are using your scope with GND strap to measure a differential signal, as well I don't expect a 2.5Vp-p signal for such a low RPM. I fear your VR may be a hot one, or your scope might be reading incorrectly. Perhaps the 10X vs 1X scale was not correct. I see it was on the 10X setting for channel 2. Can I get a verification the channel 1 was really measuring 2.5Vp-p? If it is, can you crank you drill up to your max RPM and see what kind of voltages you get then? You may need to install a loading resistor. I expect you currently do not have R111 or R112 installed. You may need that if your VR is supper hot. Also did you use the 5k's noted for R102, 107, etc? Where are you measuring your VR signal, I'm assuming you're measuring the VR directly. If so remember the max9926 will be seeing that signal after the resistors, so the max chip is likely seeing a much lower voltage than what is on the screen. As well you were probably only looking at one side of the VR, not the differential signal that the max chip is seeing.

Also about that 2.5V DC offset, this tells me you have the GND strap connected to the MCU negative or chassis GND. Be careful doing this, as your scope GND strap is connected to your wall outlet GND wire. You can easily get GND loop issues that often cause problems. You'll likely be best off taking that measurement with ch1 on one side and ch2 on the other side with the GND straps connected together. This makes your scope a differential sensor instead of single ended, and prevents GND loop issues. Then if you connect ch1 to one side of R111 an ch2 to the other side of R111 to ch2, then you'll see what the max chip is seeing. But beware do not connect your GND wire to either side of the max chip directly, it will short your 2.5V bias to GND which may break something.

Good point regarding ground loops from the scope probe ground leads. In this case the rusEFI was floating (USB powered from my laptop which doesn't have a ground lead on it's power adapter). I think the scope scales are correct, based on the 2.5V bias from grounding the probe to uC ground. You are correct I am not producing a proper differential measurement of the VR sensor, however it seems that the MAX9926 holds the -ve VR signal at the bias voltage (2.5V), so the signal shown is correct with the exception of the 2.5V offset.

I agree the amplitude of the VR signal looks high for that RPM. I did not populate R111,112, and R102-110 are all 5k each. What is the max signal allowable by the max 9926? I was measuring with the probe ground lead connected to the uC ground, and the probe connected directly to the VR sensor. Directly connecting the scope probe to the positive input side of R111 would give a more accurate result since it would show the effect of the input low pass filter.

After a quick google search (the image above is from the original application of my sensor setup), it looks like most VR sensor signals show the signal ramping positive before flipping negative (opposite to what I have been proposing). This suggests I have been wrong, and that this is an issue with my system, and I need to fix my setup. I think I can do a couple things to reduce the amplitude of the signal between pulses so it stays below the default threshold level:
1) add R111 and R112 to reduce the amplitude of the signal. I think this is the real solution. Since the signal response is so large, I can reduce it significantly and keep it below the threshold, without compromising the ability of the circuit to detect the tooth at low RPM.

2) I can increase the gap between the sensor and the tooth.... on second thought I don't think this is a good idea. It will decrease the signal peak amplitude, but won't decrease the between-tooth signal amplitude, which is what is currently causing the problem.

Russian, how hard is it to make the CAM signal less sensitive, such that it only cares about a CAM pulse +/- 45 degrees from the 4 tooth wheel? If that can be done in software, it would allow him to accurately detect the low RPM cranking situations. If not then it will likely be a much harder item to resolve in hardware. Is there any chance the CAM is already less sensitive like that? Would this extra pulse on the CAM at low RPM cause a problem with the wheel decoder?

Personally I don't think this is a good idea. I think at this point you are probably best to require solid hardware, at least while the firmware is still being developed/proven.

-Matt

[kb1gtt]

I designed the VR input to allow up to 300V, that's partly why I used 2X of the 5k 0805's, each with a working voltage of about 150V, while an equiv in 1206 would only have a working voltage of 200V-ish. As well the 0805's can dissipate significant heat, so using 2X helps spread the heat out. Also also, the 1206 has about a 50% chance of thermal expansion issues. All avoided by using 2X 0805's. The MAX chip doesn't exactly have a max voltage. What happens is you will probably go above the rail voltage at higher RPM, and under normal operations. When this happens the input's rail clamping / ESD diodes will start to conduct, clamping the input to a couple mV above your rail. So in this case something like 5.3V-ish. The more current the diodes have to conduct the higher that voltage will be. Of course if you dump to much current you'll break the diodes then the voltage will go above the chips input ratings and other things beyond the rail clamping diodes would break. As well we have to keep in mind that the energy is being dumped into the 5V rail, and if we don't have something pulling the 5V rail down, your 5V can creep above 5V. Any how I designed with 10k and (300V-5.3V = 294.7V), for a max of 30mA that can be dumped into the rails. I expect typically you'll be 50V or less, but have heard some claims of a hot VR being as much as 300V. At 50V you can be dumping 5mA to the rails.

I suspect if you scope the other trace, then do the flipped thing you are proposing, you'll find errors on that pin as well. I suspect your scope probe is what is causing the erroneous pulses to go away. I think your laptop is adding a bit of capacitance to that lead which is dampening the noise pulses, or perhaps adding the noise pulses. Either way it's on the hairy arse edge of working properly. The best would be to figure out they voltage being seen at the VR input at high RPM, then add a R111 that will drop the voltage at the chip to something not to much over 5V. Then you'll find your low RPM signals are much smaller and your auto adjusting thresholds should start to work properly.

Out of curiosity, do you get those erroneous pulses if you scope the digital signal only, with nothing or than the VR attached to the analog signals.

[mattf]

Good to know regarding the MAX9926 input limits/clamping.

I actually first noticed the false triggers in rusEFI console engine sniffer with no scope attached. The scope testing was a result of chasing the source of the double trigger. It behaves the same either way.

I'll let you know the result, but I suspect you are correct, attenuating the signal will probably fix my problem.

Thanks for the help.

-Matt

[mattf]

Update: I populated R111 with a 22kohm resistor and the false triggers are gone. The circuit still works properly down around 100rpm, so I'm satisfied.

-Matt

[kb1gtt]

Any chance you can measure the voltage at higher RPM? I'm mostly curious about the hot VR, I haven't gotten any good data points for hot VR's. Knowing yours exists makes me eager to ask for some data points. Can you take this reading as you have it now with the R111 installed. If I'm really lucky I might get you to take a scope capture showing the peak at the smallest time rate you can, as well as channel 1 on the VR and channel 2 on the top side of R111. I'm mostly curious about how high the peak goes and how long it's at the peak. Once you are past the sharp transition, and into the lazy decay, you have stopped generating energy and are simply decaying and making heat some where as the field collapses. With the voltage, time and resistance, I can predict how much energy the sensor is creating. Also if you do this test, use the 10X scale. The scope input is typically limited to about 40V to 80V, the 10X typically allows you to sniff 400V to 800V. You really only ever need 1X if you are looking at very small signals, and 10X will be safer for higher voltages. Sorry for being a bit pushy about taking these readings, I've been keeping an eye out for that kind of data for some years now.

Also good to hear you are getting good signals now. Does the mean your next nibble will be sparking something? I seem to recall that OEM's can often get down to around 30 to 50 RPM. With a bit more tuning we could probably get it lower, but meh, your probably cranking at nearly 300 RPM, so might as well do the next step. Do you have a pencil schematic or some kind of basic plan perhaps sketched on a pizza box, beer stained napkin or similar.

[mattf]

I'll try to get the data points you want. My drill only goes up to about 2100rpm and at that rate the sensor was only producing maybe 10-15V peak to peak with R111 un-populated.

The next step will probably be adding spark on the bench. I think I will also test the injectors on the bench because it will make it easier to troubleshoot.

The wiring diagram exists only roughly in my head right now; Fused power to rusEFI, another fuse for fuel pump, another for coil igniter. Relay for fuel pump. For sensors I'm using GM temp sensors(intake air and coolant), TPS and MAP (not sure if the MAP is frequency or analog yet), I also have a 14point7 wb02 to integrate at least for tuning. For outputs I'm using 1 injector with a series resistor of approx 10ohm (yet to be verified), and 1 logic level igniter for ignition. The throttle body also includes a 4-wire idle valve,which suggests it is a stepper. Maybe I'll scrounge up a stepper driver to control it.

-Matt

[kb1gtt]

I'm not sure how crazy you want to get with the schematic, I once did this thing with Dia which was kind of nice but also kind of a pain to get drawn up. I posted about it at the below link. It might be one option if you decide to do something better than a pizza box sketch.

http://rusefi.com/forum/viewtopic.php?f=3&t=360&start=162

[mattf]

I have added sensors for air temp, coolant temp, MAP and TPS to my bench test setup. Everything is sane except for TPS. The calibration using tuner studio doesn't seem to work right. My closed ADC value is 74, and my open is 716, however if I use these values in tuner studio, it causes the TPS position to 100% at closed throttle, and shows the throttle position closing as the ADC value goes up, until I reach about 30% throttle, then the throttle position stays at 0. Is this supposed to work?

[kb1gtt]

What's the multimeter claim for a voltage referenced to GND? As well what's the Frankenstein input, as well what MCU input? Some things I'm thinking need to be checked, is this the op-amp producing a bad voltage, is the TPS pot producing a bad voltage, or is the MCU simply looking at a different input than what you are connected to.

[AndreyB]

part of this is https://sourceforge.net/p/rusefi/tickets/199/
the other part - about the jumo from 30 to 0 - I cannot explain. there are some commands like tpsinfo and analoginfo which would show some info on how the math is done. See http://rusefi.com/wiki/index.php?title=Manual:Software:dev_console_commands

[RasPL]

Take a look that tps mcu pin is assigned only for tps

[AndreyB]

Take a look that tps mcu pin is assigned only for tps

there is actually some protection against this I believe, at least it was intended to detect this kind of error

[mattf]

Thanks for the suggestions. The TPS ADC values were completely sane (smoothly varied between 74 and 716 while opening the throttle). This makes me fairly certain the issue is in the calibration code.

Russian, I tried reversing the calibration values in tuner studio, but it almost seemed like it wasn't correctly using the throttle closed value (74 in my case). It would not respond to throttle input until the ADC value exceeded approx. 200.

Is there a way to do the calibration manually? I found tpsinfo, but I couldn't find a command to manually intput the values.

[AndreyB]

tpsinfo shows the min and max values and these should be the values you input via TS. As long as these values match you can be sure that the values are there.

As for changing values without TS, you can find the offsets of these variables in rusefi.ini and use the get_short/set_short commands - I've just documented those at the commands page.

The calibration code is the same interpolate method we use everywhere, I am pretty sure it is fine.

[mattf]

looks good, I'll give it a try tonight.

[mattf]

Russian,
I think have discovered what is happening regarding tpsmin/max. I'm not sure how, but it appears that the memory offset for tpsmin/max in firmware is no longer the same as in tunerstudio rusefi.ini. The min/max values aren't reversed in tuner studio, rather memory offset in the firmware is shifted by 2 bytes relative to what tuner studio is expecting. In the following example, tpsMin should be 74, and tpsMax should be 716.

Code: Select all

2015-11-12 21_32: EngineState: tps min 193/max 716 v=0.42 @PA3
2015-11-12 21_37: BinaryProtocol: Sending [get_short 84]
2015-11-12 21_37: PortHolder: confirmation_get_short 84
2015-11-12 21_37: CommandQueue: got valid conf! get_short 84, still pending: 0
2015-11-12 21_37: EngineState: confirmation_get_short 84:12
2015-11-12 21_37: EngineState: short @84 is 716
2015-11-12 21_37: CommandQueue: got valid conf! get_short 84:12, still pending: 0
2015-11-12 21_37: BinaryProtocol: Sending [get_short 86]
2015-11-12 21_37: PortHolder: confirmation_get_short 86
2015-11-12 21_37: CommandQueue: got valid conf! get_short 86, still pending: 0
2015-11-12 21_37: EngineState: confirmation_get_short 86:12
2015-11-12 21_37: EngineState: short @86 is 74
2015-11-12 21_37: CommandQueue: got valid conf! get_short 86:12, still pending: 0
2015-11-12 21_38: BinaryProtocol: Sending [get_short 82]
2015-11-12 21_38: PortHolder: confirmation_get_short 82
2015-11-12 21_38: CommandQueue: got valid conf! get_short 82, still pending: 0
2015-11-12 21_38: EngineState: confirmation_get_short 82:12
2015-11-12 21_38: EngineState: short @82 is 193

rusefi.ini shows tpsmin at offset 84, and tpsmax at address 86, but it looks like they are actually located at 82 and 84 in the firmware.

I updated rusefi.ini and now the tuner studio tps calibration is working correctly.

-matt

[AndreyB]

Offsets change sometimes, that's why rusefi.ini has a version in it and there is an indicator below the gauges which is either green if compatible or red if not compatible.

I am glad the issue is resolved

[kb1gtt]

I posted some more about VR sensors at the below link. One item of interest is that with the Honeywell 3030 VR sensor, at 10kRPM with a 60 tooth 3.1in diameter wheel, the VR sensor would generate 300V into a 10k load. However the 3010 will generate the more expected 60V. So that shows what I mean when I say there are "hot" VR sensors out there. I designed to allow those hot sensors to potentially work as well as the normal sensors.

http://rusefi.com/wiki/index.php?title=Manual:Hardware_Trigger#VR_lower_level_details.2C_formulas.2C_app_notes.2C_etc

You might be able to enter you specif information and see what voltages it predicts. This might help you tune that 20k ohm.