tephra

iTrader: (6)

Hey All,

Just thought I would post up a quick image of the next mod to be included. It's not very "cool" but should save some headaches:



So what I have done is reduced the 2byte variable and stuffed it inside a 1byte variable - why? 2 reasons:

1) Save 1byte of logging - speeding up logging is always good!
2) Stop the hi/low byte order mismatch error as seen above at the 1590.7 mark.

How:
Simply divide the real 2byte load by a factor (yes it will be customisable) and put it into 1byte which is logged like normal.

My factor is 1.2, which means we can log a load of upto 306 (255*1.2). A bigger factor equals higher load logging capability but also means less resolution.

The factor in the ROM needs to equal the factor in the EvoScan formula!

Cheers
D.

dudical26

iTrader: (17)

Thats a very "cool" idea, lol. How much accuracy is lost with this method, assuming you want the ability to log up to 340 load?

I'll just be happy to get rid of the annoying errors of 2 byte load.

Can you do this with all 2 byte data?

tephra

iTrader: (6)

Basically to find out your "factor", you get your max load and divide it by 255.

ie 340 / 255 = 1.333333, now round it upto the closest .1, so 1.4

so 255*1.4 = 357, so you can log upto 357.

A factor of 1.4 would go in steps of 1.4, ie 0, 1.4, 2.8, 4.2..... so you loose a "little" accuracy, but I think its ok

Yes we could do this with any of the 2bytes, essentially this is how RPM works already, ie 255*31.25 = 7968, so 31.25 is the factor for MUT21.

logic

iTrader: (2)

Interesting idea, it definitely beats the heck out of the two-byte problems we currently have. Wonder if you could define a "floor"; say, a load of 100, with a factor of 1 (ie. the eval would simply be "x+100")? Does anyone really care about lower load values?

tephra

iTrader: (6)

lol, original that was my plan, but MrFred convinced me otherwise.

l2r99gst

iTrader: (2)

Nice work, Dave. I remember this being mentioned a few times in the past. I think this is a great mod, especially for load, where you are losing very little resolution.

mrfred

iTrader: (50)

Lower loads are useful for tuning part throttle and cruise. I guess if tephra wants, he can include an adjustable offset as well.

tephra

iTrader: (6)

Nah - I am trying to reduce the core code now, as I am at a stage where the start of my code is too far from the end of my code - if you know what I mean

I think it's good enough, I think most people will be happy with a 1.1 or 1.2 factor!

dudical26

iTrader: (17)

I think the gains are worth the slight loss in resolution. If you are off by a few points in load I don't think that really matters. So long as it is within 5% or so I would say that is still ok

tephra

iTrader: (6)

ditto, the higher the factor the lower the accuracy...

like I said most people will find 1.1x or 1.2x is HEAPS..

dudical26

iTrader: (17)

Sweet As

Asmodeus6

iTrader: (7)

I agree with Fred ^

Jobi

So basically the new formula in EvoScan would be:
- for "load 11bit4": 1.2x
- for "load MUT 2byte mod": 1.2*0.3125*x

Am I right? Cause if I am, it would explain why I see load values which seem kinda low compared to the boost I'm running...

Thx a lot for help on this point

tephra

iTrader: (6)

no - forget 2byte load or load 11bit4.

nonschlont

iTrader: (3)

ok excuse the newbish question, but I tried to add this definition to my evoscan v2.5 and since the actuall .xml file has been done out w/, I added a new data item, added: Display="Load 1Byte" / LogReference="Load" / RequestID="41" / Eval=1.2*x / Unit="load" / ResponseBytes="1" / GaugeMin="0" / GaugeMax="300" / ChartMin="0" / ChartMax="300" / ScalingFactor="0.1" Notes="" Priority="1"

and logged next to 2byte load, and nothing... Am I missing something???