DIYEFI.org Forum

Following on from the recent LC-1 support thread, I thought I'd post this up.

Docs are here: http://www.14point7.com/Support/Softwar ... tation.zip

Initial support will be purely logging, and even that will need special support added to OLV: http://issues.freeems.org/view.php?id=300

Perhaps I can convince Alan to provide an alternative non floating point data format. Or perhaps it's easier than I originally thought.

Analysis of lambda output var requirements:

Lambda in range: 0 - 2.0 (0.68 - 1.36 (10:1 - 20:1 AFR for gasoline) are its analogue output levels and reasonable defaults, but that's only 8 bit).
Quoted accuracy: 0.01 when the sensor is in good condition, without free air calibration.

2.0/0.01 = 200 steps, so an 8 bit unsigned with fixed scaling would work fine.

I'd suggest that it should be output as 16 bit fixed point numbers with specific scales for each variable as that seems excessive and is simple to parse, and fast to transmit/receive.

Even if you expand to 4.0 and 0.001 accuracy you only end up with a range of 4000 steps. Following that logic you could go to 0.0001 accuracy with 0 - 6.5 lambda range, or 0.001 accuracy with 0 - 65 lambda range, or any other reasonable combination.

The first step will be logging support.

Lambda: Range is 0.68 to 207 Lambda
32bit IEEE 754 formatted floating point number.
[Byte3 ][Byte2][Byte1][Byte0]=[Bit31 Bit30 … Bit24][Bit23 Bit22 … Bit16] [Bit15 Bit14 … Bit8][Bit7 Bit6 … Bit0]
*Byte3 is the first byte received
Sign Bit = Bit31
Exponent = Bit30 … Bit23
Significand = Bit22…Bit0

From the docs.

Format info: http://en.wikipedia.org/wiki/Binary32

Calculator: http://www.h-schmidt.net/FloatApplet/IEEE754.html

Easy in Java: http://download.oracle.com/javase/6/doc ... t%28int%29

Fred.

Hi Fred,

I did not really appreciate the value of not having floating point for lambda until I seriously started interfacing the modules with a PIC. I thought people had an aversion to floating point because they did not want to burden the uC with floating point arithmetic, since the unit spit out lambda without the need for additional processing I did not see the value of using smaller datatypes. However, now I see it is probably more about code space and avoiding the use of floating point libraries.

I will add 16 bit and 8 bit representation for lambda.

Also about the 8 bit output, the output is 0-5v representing 10-20 AFR or 0.68 to 1.36 lambda. So the resolution; 0.68 [Lambda]/255 = 0.002666 lambda. The lambda sensor is rated for 0.01 lambda accuracy, so the resolution @ 8 bit is ~4 times the resolution needed to show the 0.01 lambda accuracy of the sensor.

Re the 8 bit DAC being more than good enough, I realised that later and should have updated my post. Sorry about that. You're 100% right, as always, it seems :-)

I'm not bothered with 8 bit, but 16 bit would be great, especially if it matched my internal unsigned 0.0 - 1.99996948 lambda scale with 32768 being stoich (div by 32768). Then it would simply be a matter of reading the stream and plucking the value directly, which would be very very very VERY nice!

My concern wasn't so much with code space, though that IS a big one, more with code time (100x slower or so) and complexity in avoiding using such fat libs. I think due to the narrow range of values I could probably do a heavily simplified conversion back to an integer value with some custom code, though. However not having to think about that would be a huge bonus! :-)

Thanks for being so responsive! :-)

BTW, I put up such threads for my own notes and for commentary from others. I was intending to have a crack at it and approach you if I had trouble, hence not linking you yet. I'm glad that you spotted it, though.

Fred.

BTW, Alan, I've forgotten what I read in your document, but if it's request response, have you considered allowing different packets?

For example, it might be pretty nice to grab the Lambda exactly as often as it makes sense to, and not have to spend time processing the rest of the data, even if it's just RX time and discard. And, on top of that, poll the other variables from time to time, much less frequently, and pass them through and out the other side to a logger.

I admit, my understanding of the I2C protocol and your layer on top of that is thin at best, but there must be some overhead in receiving a bunch of data all the time when you only really want a small fraction of it. Just a thought, let me know what you think! :-)

Fred.

With I2C you can read specific memory addresses as you please.

Ahh, OK, that sounds perfect, then! :-) Awesome news, excuse my ignorance.

Free Air is ~207 Lambda, the sensor is rated for 0.01 lambda accuracy, so if an integer value of 1 = 0.005 lambda I could fit 0 to 327.675 lambda in a 16 bit datatype.

This is true, however from a practical point of view, which is often a good one to take, you simply can not have combustion below a certain level of fuel, and railing the output at something around that limit or sufficiently over that limit to make sure that you either see "full lean" OR a meaningful value seems like a good approach. That's why I chose 2 as the limit in FreeEMS, because outside of that is not a range where an engine can function, even if gasses can exist there.

On gasoline, I have friends that push the 20:1 region cruising, but I don't know anyone that claims to go close to 30:1. A quick search found a cummins article talking about special technology to go as lean as 1.7 lambda on diesels. What is LPG like? CNG? Alcohol? How lean can you go on any of these before the mix is not combustible?

This is also what you've already done in your analogue output, but with a justifiably narrower range. Why not here too?

If you want to cover the extremes you're better off to use a divisor of 256 (a shift of 8) and have a step size of 0.00390625 and a maximum value of 256 - 0.00390625 = 255.996094, however I see no value in covering those extremes.

That's my 2c :-)

Fred.

I know its doubtful anyone would do it with freeEMS right now but the bosch automotive handbook does mention with direct injection engines running as lean as lambda = 4

I have this product in hand now and will experiment as soon as some other priorities are dealt with and I've bought a soldering iron to assemble it with. First comment, it looks very professional!