Nistune Forums

Thanks for posting this. If I was to monitor these variables externally from the application software I would have to keep a record of the count reached and then store and pass that through consult (similar to what I do for say HCR32 RB20 but using my own knock count value - which I never found for RB20)

Hmmm,

So is it possible to monitor these addresses?


Also based on what RomChip posted would you consider testing these routines and implement it (on request)
in the firmware?

Thanks to RomChip for sharing this, hopefully we get somewhat closer now to knock event monitoring.

This is my own way of tracking knock.
I removed some variables I don't care in the original Consult registers map to put these instead.
Having some logs with knock indication at TP/rpm points is the most useful.

I'm also working on auto self-correction of richness for ethanol E85 using only the narrowband O2 sensors.

It depends... if the variables we are monitoring are quickly changing then periodic polling via consult may not get the results you were hoping for

For example during instance of knock if the counter increases and then decreases in a matter of microseconds, then a consult read of those registers direct every 200ms would not capture the worst case value of that counter register. So its necessary to modify the ECU code to record that information. That is what is done currently for knock count. Each read resets the number of knock pulses read during the last period. This is then attributed against the cell where RPM/TP is traced

Matt wrote:It depends... if the variables we are monitoring are quickly changing then periodic polling via consult may not get the results you were hoping for

For example during instance of knock if the counter increases and then decreases in a matter of microseconds, then a consult read of those registers direct every 200ms would not capture the worst case value of that counter register. So its necessary to modify the ECU code to record that information. That is what is done currently for knock count. Each read resets the number of knock pulses read during the last period. This is then attributed against the cell where RPM/TP is traced

this is just not the case, the variables I mentioned evolve slowly, you are able to catch the real behavior, believe me

That is good news then. That is why I mentioned 'if' they are doing that.

The current variables I monitor on HCR32 etc move very quickly

Is it possible to monitor these with Nistune?
(RAM trace?)

I never used this, but it sounds like it watches an address or something?

Personally, I changed the Consult variables to be logged:



Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

00006A00 14 0A 14 0B 16 EE 16 F6 14 9F 14 A1 FF FF FF FF .....î.ö.Ÿ.¡ÿÿÿÿ
00006A10 14 0C 14 35 14 37 14 07 00 92 14 A7 FF FF 16 14 ...5.7...’.§ÿÿ..
00006A20 FF FF FF FF FF FF 15 3C 15 6E 15 6F 14 10 16 10 ÿÿÿÿÿÿ.<.n.o....
00006A30 FF FF FF FF 16 25 16 26 16 23 16 24 00 F0 00 F1 ÿÿÿÿ.%.&.#.$.ð.ñ
00006A40 FF FF 15 3D 15 70 15 71 FF FF FF FF 15 1F 15 20 ÿÿ.=.p.qÿÿÿÿ...

Interesting,

I did not know this was possible ..

This is quite interesting, your a clever guy Rom

Thats what we do to get TP out of the ECU. Last two registers (26 and 27) are used to get TP which is coded into the Nistune board so it works in stream mode. Unfortunately on ER34 reg 26 also contains the boost control parameter so now needs to be moved elsewhere for that one...

So this is rather a firmware patch

Matt wrote:Thats what we do to get TP out of the ECU. Last two registers (26 and 27) are used to get TP which is coded into the Nistune board so it works in stream mode. Unfortunately on ER34 reg 26 also contains the boost control parameter so now needs to be moved elsewhere for that one...

If you want these values in stream mode then yes the consult table needs patching

However in tuner mode I can read any RAM values when I want (like the knock map flags for instance) so then there is no firmware change

OK,

so that's something I could test then myself?

Matt wrote: However in tuner mode I can read any RAM values when I want (like the knock map flags for instance) so then there is no firmware change

Do you offer to the end-user the capability to trace RAM addresses he wants ? Where can this be configured !?
I'm not so sure...