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.

 

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?

 

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.

 

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?

 

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

 

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.

 

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

 

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!

 

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

 

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

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

 

Sweet As

 

I agree with Fred ^

 

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

 

no - forget 2byte load or load 11bit4.

 

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???