Page 1 of 1
Reasons For Lambda Table Naming
Posted: Thu Oct 06, 2011 4:09 pm
by Fred
Fred wrote:My take on AFR/Lambda, and it's not a target, it's integral, is that...
BenFenner wrote:And you can call lambda integral all you want. It is still a target. You simply can't tune the VE table correctly blind. And then head to the lambda table and get your desired AFRs. You have to (by virtue of how this all works) go to the lambda table an input a target and then tune the VE table accordingly. Refusing to call it a target is just head-in-the-sand stupid.
Ben, a table serves a purpose in code. You serve a purpose tuning that table. The table is integral because if you touch it, the fuel output changes immediately. It is not targetted, hunted down, searched out, or in any other way moved towards, it is just done. This, unlike various other systems, is an open loop table. If and when we add closed loop fuel control, this table will serve a dual purpose as an integral lambda table AND a lambda target table. That is currently NOT the case, and even when it is, the target aspect will be implicit and by definition secondary anyway. I'm sorry if this terminology is new to you, and doesn't fit well with your ideals of YOU targetting a specific lambda while tuning, but that is how it is and that is how it is going to stay. Calling me "head in the sand stupid" because I disagree with you about this is fundamentally unacceptable too. If you were anyone else, your post would have got edited and locked. But you're you, so it got edited, linked and moved here. Do not post in this thread until we have spoken on the phone. PM, IM or email me your number so we can have this severely shed coloured discussion offline.
Fred.
Re: Reasons For Lambda Table Naming
Posted: Wed Dec 14, 2011 4:46 pm
by thebigmacd
FWIW the MS2extra code allows the user to select whether the AFR table is integral or just a target. I find it works way better when it is integral. Changing your AFR is a matter of changing the table entries rather than changing the entries and having to re-tune the map.
+1 on the "integral" AFR table concept.
Re: Reasons For Lambda Table Naming
Posted: Wed Dec 14, 2011 8:30 pm
by Fred
Glad you're happy about it :-)
They added that after I wrote my implementation, btw!...
As for this thread, it was all about the naming, which I think is significant, not the feature/design choice itself. Ben doesn't like the naming and thinks of it as a target, but it's not a target for the device, only for the tuner.
Fred.
Re: Reasons For Lambda Table Naming
Posted: Thu Dec 15, 2011 3:59 am
by thebigmacd
I found out today that GM calls it "command AFR"
Re: Reasons For Lambda Table Naming
Posted: Thu Dec 15, 2011 10:15 am
by Fred
Good info! What about ford? I'm up for renaming it, provided that it conveys the meaning and intent properly. Under no circumstance will it ever be called or labeled "Target Lambda" though.
Re: Reasons For Lambda Table Naming
Posted: Thu Dec 15, 2011 11:50 pm
by thebigmacd
Haven't found what Ford calls it yet, but I did stumble across these specs for the processors in their modern ECUs:
MPC565: 32 Bit Microcontroller (used in Mustang GT S197)
The MPC565 is a member of a MPC500 family of microprocessors that implements the PowerPC instruction standard architecture. The MPC565 is integrated with a Floating Point Unit, an advanced peripheral set and one megabyte of FLASH memory on a single chip. This combination is ideal for high performance automotive applications as well as other control-intensive applications.
Features:
1M byte of internal FLASH memory (divided into two blocks of 512K bytes)
36K bytes Static RAM
Three time processor units (TPU3)
A 22-timer channel modular I/O system (MIOS14)
Three TouCAN modules
Two enhanced queued analog system with analog multiplexors (AMUX) for 40 total analog channels. These modules are configured so each module can access all 40 of the analog inputs to the part.
Two queued serial multi-channel modules, each of which contains a queued serial peripheral interface (QSPI) and two serial controller interfaces (SCI/UART)
A J1850 (DLCMD2) communications module
A NEXUS debug port (class 3) – IEEE-ISTO 5001-1999
JTAG and background debug mode (BDM)
MPC561: 32 bit Microcontroller (used in GT500)
Features:
Precise exception model
Extensive system development support
On-chip watchpoints and breakpoints
Background debug mode (BDM)
IEEE-ISTO 5001-1999 NEXUS Class 3 Debug Interface
True 5-V I/O
Two time processing units (TPU3) with eight Kbytes DPTRAM
22-channel MIOS timer (MIOS14)
Two queued analog-to-digital converter modules (QADC64_A, QADC64_B) providing a total of 32 analog channels
Three TouCAN modules (TOUCAN_A, TOUCAN_B, TOUCAN_C)
One queued serial module with one queued SPI and two SCIs (QSMCM) 32-Kbyte static RAM (CALRAM)