I have a few haltech issues that I am hoping someone here has the possible solution for.

Issue #1:

When watching the engine idle speed on the engine monitor page, the idle changes in increments of about 60 or 80 RPM. Its not linear.

Issue #2: When timing lock is taken out, the car just falls on its face. And I am using the Hitman stock 13BT map.

Any ideas?

Any help is greatly appreciated!

Rat

 

try taking 5% out of the whole fuel map. When I used the hitmans map I was too rich to even keep it runing, I removed 5% and it ran enough for me to fine tune the idle.

 

the rpm change is normal, delta being > 1 does not mean it's nonlinear. The e6k uses a 8 bit value to represent rpm, so 0-255 scaled to 0-16000, add in rounding and you have 60rpm resolution.

So the smallest step it will take from one rpm to another is 60rpm, on the engine data page at least.

As for the other problem, has the timing been zero'd properly?

 

I timed it this way:

I locked the timing at -5, and while running, I made sure the -5 timimg mark lined up with the timing pin. All is good, car idling great.

Unlock timing, car goes poopy...

I checked the map, and it seems that the map was set to advance the car to 9 deg at idle? I need to check this a bit more..

*edit*

So at idle, and your on your engine monitor screen, your values jump by 60?

 

What is the ignition timing map set at at 0, 500, and 1000???
It should all be set to "0" (or something like that).
Is your cranking ignition map have weird values in it?

Don't worry about the idle RPM resolution - they all do that.
pengarufoo gave a really detailed explanation on why this is so!



-Ted

 

Regarding the ignition, it sounds like you need to tune your ignition maps, try 0 degrees @ idle to get it smoothed out, the rest of the map may need adjusting too. Some people intentionally offset the timing @ the zero phase so they can get negative timing values when the map says 0, for retarded timing @ idle on the 13b. I juse use 0 BTDC @ idle and it is pretty smooth.


As for the RPM, if you are referring to my software, I don't currently interpolate between samples in the simulated analog gaugse so yeah the tach steps ~60 rpm.

It's not like your stock analog tach can accurately tell you 1000 RPM vs 1010 RPM, if you were to invest in a high precision expensive stepper motor driven tachometer, you will find it too has a step size well over 1 RPM, but when your engine revs from 2000 to 12000 rpm in a fraction of a second the issue becomes can the needle represent where the accelerating engine is without significant latency, not is it able to distinguish 2050 RPM vs 2000 RPM. If it can tell you the difference between 2000 RPM and 2100 RPM as fast as if not faster than the engine can change from 2000 to 2100 rpm it's good enough. When your car is fast this actually starts to become a serious problem, you will be hitting the rev limiter on accident when accelerating because your gauge is lagging behind the engine.

Another concern is needle bounce, stock gauges bounce around and generally are not very accurate, the smooth movement can make it appear to be extremely precise but it's not really the case, they respond relatively slowly and are not positively located with regard to the scale you reference the needle to.

In the precision tachometer aftermarket it's common to find tachs with 100RPM incremements, this will also be the the resolution of the scale at the periphery of the gauge. So every step of the motor will step along one hatch, just like a mechanical clocks seconds hand steps along every hatch. But if your engine just accelerated from 2000 to 8000 RPM accelerating through 1st in under a second, the gauge will not be lagging behind any more than the resolution would permit (the engine could be at 2040 RPM when the gauge says 2000RPM, but the moment it's closer to 2100RPM the needle will be at 2100RPM, immediately)

The ECU obviously 'knows' the trigger events with greater precision to time injection and ignition events, it just doesnt communicate it to the tuning software for the engine data page to display.

If I were to actually implement interpolation to allow the gauge rendering code to generate the values in between acquired e6k data samples it would actually add more latency to the needle, so it's not something I'm likely to do.

However, something I will be doing is adding blurring code so when the needle moves from 1000 to 8000 rpm in a few frames it will blur the region the needle covered between the frames with the color of the needle so it is alot more pleasing to the eyes. This is something that happens naturally in a real analog gauge when moving ridiculously fast (generally requires a stepper motor driven one to move this fast), but not in a simulated analog gauge on a computer screen unless you simulate the blurring in the code (A good example of this are the motion blurred photos in gran turismo 4 photo mode when the cars are moving fast, their rendering engine had to go out of its way to simulate that realistically)

Anyways, enough talk, for an example of what I'm talking about with precise fast responding stepper driven gauges, I refer you to the TopGear video of the McLaren F1, theres a part where you get to see the tachometer while he's cruising not too far into the movie, the needle moves up and down one step a few times, it looks jumpy and odd if you don't know what the deal is:
http://pengaru.com/~swivel/Top_Gear-McLaren_F1.asf

hopefully that cleared some things up.

 

It cleared many things up.

Again, thank you so much for taking the time to answer my questions!

 

that is normal man... all the haltechs I've put in and setup with the Hitman map and CAS setting. When you toggle the lock it makes the car run a little worse because your ignition maps aren't active, thus meaning "locked", this way you can get your hardware and software references matched.