AutoThority MAF
#16
Addict
Rennlist Member
Rennlist
Small Business Partner
Rennlist Member
Rennlist
Small Business Partner
![Default](https://rennlist.com/forums/images/icons/icon1.gif)
#17
![Default](https://rennlist.com/forums/images/icons/icon1.gif)
Ok totally honest, possibly naive question here. Having written some engine control software in a past life for the Ford Powerstroke, I have a basic understanding of sensor outputs and how the software works to use them.
As I understand it (pretty sure I've "got" this but correct me if I am wrong, as I feel like I'm missing something big here) the AFM and MAF both measure airflow. One does it by moving a door (more airflow = moves the door further), one does it by wire temperature change (more airflow = more heat loss in the MAF wire.)
Aside from a transfer function (the math function written to convert sensor voltage to airflow) - how is "true MAF code" different from AFM code updated with the MAF transfer function?
Or is that all that's really changed for a "true MAF" chip - the transfer function? In which case... why is this so hard to change and so elusive for so many people? The MAF manufacturer should be able to provide the transfer function to the developer of the chipset.
As I understand it (pretty sure I've "got" this but correct me if I am wrong, as I feel like I'm missing something big here) the AFM and MAF both measure airflow. One does it by moving a door (more airflow = moves the door further), one does it by wire temperature change (more airflow = more heat loss in the MAF wire.)
Aside from a transfer function (the math function written to convert sensor voltage to airflow) - how is "true MAF code" different from AFM code updated with the MAF transfer function?
Or is that all that's really changed for a "true MAF" chip - the transfer function? In which case... why is this so hard to change and so elusive for so many people? The MAF manufacturer should be able to provide the transfer function to the developer of the chipset.
#18
Instructor
Join Date: Nov 2009
Location: Stouffville, Canada
Posts: 197
Likes: 0
Received 0 Likes
on
0 Posts
![Default](https://rennlist.com/forums/images/icons/icon1.gif)
![Cheers](https://rennlist.com/forums/images/smilies/beerchug.gif)
#19
Addict
Rennlist Member
Rennlist
Small Business Partner
Rennlist Member
Rennlist
Small Business Partner
![Default](https://rennlist.com/forums/images/icons/icon1.gif)
Well first, the AFM measures air volume while a MAF measures air mass. So DME takes air volume, baro, and IAT to then derive air mass.
Second, the transfer function curve of the AFM is calculated via three tables in an odd fashion (most likely done this way to minimize table size). Because of the way the DME uses these three tables, it is impossible to match the transfer function to an aftermarket sensor without re-writing the code.
Third, the DME software is completely done in assembly, and to keep the processing requirements down, Bosch did quite a bit of the flow calculations beforehand. So what we have is a 24bit representation of flow, but no real way to make it mean anything. Similar can be said about fuel injector size as well.
Fourth, there are acceleration responses that are counting on the physical movement of the AFM vane. These responses need to be addressed as well.
Ect.
Writing software is much easier than reverse engineering it...
Second, the transfer function curve of the AFM is calculated via three tables in an odd fashion (most likely done this way to minimize table size). Because of the way the DME uses these three tables, it is impossible to match the transfer function to an aftermarket sensor without re-writing the code.
Third, the DME software is completely done in assembly, and to keep the processing requirements down, Bosch did quite a bit of the flow calculations beforehand. So what we have is a 24bit representation of flow, but no real way to make it mean anything. Similar can be said about fuel injector size as well.
Fourth, there are acceleration responses that are counting on the physical movement of the AFM vane. These responses need to be addressed as well.
Ect.
Writing software is much easier than reverse engineering it...
#20
![Default](https://rennlist.com/forums/images/icons/icon1.gif)
Well first, the AFM measures air volume while a MAF measures air mass. So DME takes air volume, baro, and IAT to then derive air mass.
Second, the transfer function curve of the AFM is calculated via three tables in an odd fashion (most likely done this way to minimize table size). Because of the way the DME uses these three tables, it is impossible to match the transfer function to an aftermarket sensor without re-writing the code.
Third, the DME software is completely done in assembly, and to keep the processing requirements down, Bosch did quite a bit of the flow calculations beforehand. So what we have is a 24bit representation of flow, but no real way to make it mean anything. Similar can be said about fuel injector size as well.
Fourth, there are acceleration responses that are counting on the physical movement of the AFM vane. These responses need to be addressed as well.
Ect.
Writing software is much easier than reverse engineering it...
Second, the transfer function curve of the AFM is calculated via three tables in an odd fashion (most likely done this way to minimize table size). Because of the way the DME uses these three tables, it is impossible to match the transfer function to an aftermarket sensor without re-writing the code.
Third, the DME software is completely done in assembly, and to keep the processing requirements down, Bosch did quite a bit of the flow calculations beforehand. So what we have is a 24bit representation of flow, but no real way to make it mean anything. Similar can be said about fuel injector size as well.
Fourth, there are acceleration responses that are counting on the physical movement of the AFM vane. These responses need to be addressed as well.
Ect.
Writing software is much easier than reverse engineering it...
![Smilie](https://rennlist.com/forums/images/smilies/smile.gif)
In the early 80s I was still writing stupid games in BASIC on an old Tandy 1000A. By the time I got into control systems we were well beyond the capabilities and limitations of the early 8k chips
![Smilie](https://rennlist.com/forums/images/smilies/smile.gif)
#21
Addict
Rennlist Member
Rennlist
Small Business Partner
Rennlist Member
Rennlist
Small Business Partner
![Default](https://rennlist.com/forums/images/icons/icon1.gif)
"Entertaining"... lol thats a good word to use ![Smilie](https://rennlist.com/forums/images/smilies/smile.gif)
Some of the things I've gone through in the code are truly "WTF were they thinking" moments.
I would much rather do an EMS in C. But the hardware simply isn't fast enough, so everything must be done in assembly. And considering this is one of the first electronic fuel injection systems, they didn't always to things the easy way (or performance way either).
![Smilie](https://rennlist.com/forums/images/smilies/smile.gif)
Some of the things I've gone through in the code are truly "WTF were they thinking" moments.
I would much rather do an EMS in C. But the hardware simply isn't fast enough, so everything must be done in assembly. And considering this is one of the first electronic fuel injection systems, they didn't always to things the easy way (or performance way either).