NefMoto

Hello...

I have been taking my time slowly looking over the great amount of information given here. I'm not quite ready to tune my car yet, but As I start looking over future information I found this map (provided by the site) and is the % scale wrong?? It was provided in one of the data packs in the Nefmoto section

Also the reference to BTS? I'm not sure I always know what you guys are talking about with that.

Thanks, and sorry for being such a noob.

Justin Howard Mcane

If it is a 16-bit value and has an odd (not even) address, likely it is wrong.

GG bad damos port

BTS refers to this
http://s4wiki.com/wiki/Tuning#LAMBTS

Nyet,

Thanks for your response and thanks for all your great work. I am an admirer

I read your link like 500 times. It's part of my bible..

ok it says 15bit LoHi and the start address is 1C383. I changed it to 8bit per what I would assume you were talking about. and it went from the original value of 128.xxx to 0.0 - 0.6959. I would be left to assume this is what has been referred to as the improper scale and the lower value should be set to 50 and the corresponding values should rise up to 100%

Justin Howard Mcane

No. 1C383 is odd. Try 1C382

16-bit values MUST be 16-bit (two byte) aligned ....

hopefully you can find the time to understand what that means. At some point you'll have to :)

I will be slowly working on getting a full grasp.

I changed the address as you mentioned and kicked it back to 16-bit. Now the start value is .4578 and the end value is .8973? I read (on your page) where you said this was wrong and this needed to be changed. Would it be a good start to go with .45% now = 50%

and then would I have to change DLAMFAW to tie them both in?

Thanks

Justin Howard Mcane

HMM. That isn't quite right either. Try 1C384. It should be .50-1.0, which you should change to 50-100...


No, you can leave DLAMFAW alone... I actually haven't looked into under what circumstances you might need it. Perhaps others can comment and/or suggest some wording for the wiki.

Bingo,

Thanks for being so committed to this for me, it was one of the many struggles, I have been having attempting to get a full grasp on this system. I keep reading back and forth with members about some systems and it comes to be confusing.

.5005 - 1.0011. This is percentage of throttle correct? So changing it from .5005= 50 then each data point up till the last of 1.0011= 100% would be closer to what I want.


Also a quick question that has me confused. KFLAMKR is a 6x6 table but the ID tag is the same on  Wichtungsfaktor für Anfettung bei Zündwinkelspätverstellung it translates to Weighting factor for enrichment in ignition angle retardation (per google). It reads values as 1.0001. I have read and or understand that if you change 1.001 = 0 this table will not support table Anfettung bei Zündwinkelspätverstellung, This translates into the Enrichment in ignition angle retardation, But is also a 6x6 table with the ID of KFLAMKRL The values in Anfettung bei Zündwinkelspätverstellung are adding fuel? per what the weighting factor tables say? For testing to make sure I have my fueling strategy proper. Would I be able to turn off KFLAMRK by turning the one or both tables to 0? 

sorry for asking stuff that has been talked about. I was just never able to grasp the actual end answer.

 I would give you a plus vote but I can't apparently do that yet.

Thanks again
Justin Howard Mcane

This has been discussed to death on the forum.
Look at the KFLBTS vs LAMFA thread and read it.

I am not sure your axis values are right.
Half the DAMOS files and ASAP files are also wrong.

The only way to confirm it is to find the map access in assembly.

Btw I believe you are wrong on this one...
You can still read a 16 bit axis which is not two byte aligned if you read it per-byte and then combine it.

Can you do it? Of course you can. Should you? No. In any case, you cannot do a word access on a non-byte boundary in assembly. Most c compilers are smart enough to do it for you. Some cpus (and/or programming environments) can do the right thing on unaligned word access exceptions.

I do not believe the C166 is one of those cpus.

In any case, it is far slower on most cpus to do unaligned accesses, so typically programmers try hard to keep things aligned.