Not really. Only the 255 part is. At that I will let Bruce complain that information is not being shared. What you really need to concentrate your efforts on is resolution and then I wonder if you'd run into issues from having too much with the 'programmed in' sluggish reaction time of the system itself. Too much 'accurate' data and you might find pulse widths jumping up and down like a kid on a pogo stick. I cant say thats necessarily a good thing coming from an airflow meter in the front of the air tract to 8 cylinders on a dynamic component.

As for the Granatelli, I have not read much in the way of good reviews on the front of reliability. However it can play into your hand if you feel like training the ECM to understand something past the 255 g/sec limit as coded from GM.

It is refreshing to see, however, that some actual useful information is being exchanged rather than saying you are limited to X hp or X ET's or X driveability.

Sorry for resurrecting the dead but I stumbled across this and had to add my 3 cents.

 

You could certainly change whats represented by the 255. No problems there. The stock code will have serious resolution problems, though, as at higher airflows itll be the limiting factor for resolution. From what Ive seen, this will cause the AFRs to ratchet from one value to the next rather then vary smoothly, which will cause issues with the engine. With coding, though, teh limiting factor will then be the A/D converter. Another thing you can do is assign BLM cells to ranges of airflows to help correct for the lack of resolution. IOW, each blm cell will cover a short span of airflow. This can really help at p/t.

The other thing that Ive been keen on trying is pulse accumulation for the freq. based MAF signal. Basically each time an edge is detected on an input line, an interrupt is generated. Once this happens, you increment a pulse counter and take a snapshot of the internal free running CPU timer. This has the advantage of being able to let you gather data over a longer span of time. The resolution can be improved by many orders of magnitude to only several 10ths of a percent of error on the computers side. The real disadvantage is that there can be upwards of 12,000 interrupts a second, so this will add overhead in the ecm, and there has to be an input that can generate interrupts. Other then that, it beats all other methods of capturing the maf signal hands down. If im not mistaken, this is the method used by GM now.

 

Carefully reread the claim, that's not what they actually say.

 

Nope, in general I could pretty much care less what goes on around here.
Folks have pretty much shown themselves for what/who they really are.

It seems over the years, that few want to share much. Thou, it was great seeing the ALDL programming being shared. But, as far as any community goals, and trying to forge things ahead, and make any serious differences, that's DOA.

I hope that clears things up for you.

 

This is a very good read for Maf and SD