Your dream ECU
#21
Haha I'm pretty sure I just found your first post on the Adaptronic forum.
According to the rest of that thread, they used a simple yet unreliable way to estimate torque output with their changes, so I can see why it wasn't popular (although I would still try it if it was offered but I like automation).
And I'm guessing that nobody has ever done it with EGT, since anyone who has an EGT sensor probably isn't worried about autotuning spark.
Edit: wait I forgot Reverant has 4 EGT sensors!!! Come on Reverant you know you want to write some spark autotune code that uses the EGT input.
According to the rest of that thread, they used a simple yet unreliable way to estimate torque output with their changes, so I can see why it wasn't popular (although I would still try it if it was offered but I like automation).
And I'm guessing that nobody has ever done it with EGT, since anyone who has an EGT sensor probably isn't worried about autotuning spark.
Edit: wait I forgot Reverant has 4 EGT sensors!!! Come on Reverant you know you want to write some spark autotune code that uses the EGT input.
#23
Elite Member
iTrader: (10)
Join Date: Jun 2006
Location: Athens, Greece
Posts: 5,979
Total Cats: 356
And I'm guessing that nobody has ever done it with EGT, since anyone who has an EGT sensor probably isn't worried about autotuning spark.
Edit: wait I forgot Reverant has 4 EGT sensors!!! Come on Reverant you know you want to write some spark autotune code that uses the EGT input.
Edit: wait I forgot Reverant has 4 EGT sensors!!! Come on Reverant you know you want to write some spark autotune code that uses the EGT input.
#24
Elite Member
iTrader: (1)
Join Date: Jun 2006
Location: Warrington/Birmingham
Posts: 2,642
Total Cats: 42
Haha I'm pretty sure I just found your first post on the Adaptronic forum.
According to the rest of that thread, they used a simple yet unreliable way to estimate torque output with their changes, so I can see why it wasn't popular (although I would still try it if it was offered but I like automation).
And I'm guessing that nobody has ever done it with EGT, since anyone who has an EGT sensor probably isn't worried about autotuning spark.
Edit: wait I forgot Reverant has 4 EGT sensors!!! Come on Reverant you know you want to write some spark autotune code that uses the EGT input.
According to the rest of that thread, they used a simple yet unreliable way to estimate torque output with their changes, so I can see why it wasn't popular (although I would still try it if it was offered but I like automation).
And I'm guessing that nobody has ever done it with EGT, since anyone who has an EGT sensor probably isn't worried about autotuning spark.
Edit: wait I forgot Reverant has 4 EGT sensors!!! Come on Reverant you know you want to write some spark autotune code that uses the EGT input.
Ergo it's not a very good way to tune spark as a primary input.
#26
Elite Member
Thread Starter
iTrader: (1)
Join Date: Jun 2012
Location: NH
Posts: 9,479
Total Cats: 104
If you had that accelerometer though. You could use it to determine both acceleration in the direction of travel and road inclination. And you could use it to tune spark that way. Maybe. How accurate is a moderately priced 2 axis or 3 axis accelerometer? Within 0.1 degree if trying to sense inclination based on how much of the downward acceleration from gravity is in one of the other directions and some trig?
#28
A few things missing from this list... oh wait, here is the answer:
http://www.bosch-motorsport.de/en-US/literature/en-US/Engine_Control_Unit_MS_5.5_Datasheet_51_en_2775686 027.pdf
Multiple power supplies, all IO protected, flexible io, internal high quality logging, current feedback on outputs, programmable current parameters, vibration isolation, high quality connectors, advanced turbo control with turbo speed inputs, wide power range for when the alternator dies, on and on...
Really the biggest difference between the best ECUs and the worst are in the basic design, board layout, software and a TON of little details. On a spec sheet you could line up the best and worst 4 cylinder standalones and the spec sheet shouldn't be miles apart. I've seen bad ECUs die because of a momentary grounding of the 5v bus or a user misconnection of gnd and +12v.
Specifying the processor is odd at best. You want automotive temps and most ideal processors have a coprocessor or time processing unit that do the heavy lifting. At the customer level XXX Mhz becomes transparent and irrelevant. You can get an old series ~50Mhz MPC5xx processor with multiple TPU cores that will be much more appropriate than a 1GHz + Arm core as used in cell phones. If we were in a Mhz race, we would all be using Arm cores and nobody would be using the automotive specific processors from Freescale, ST, Atmel, Fujitsu, Infineon etc.
http://www.bosch-motorsport.de/en-US/literature/en-US/Engine_Control_Unit_MS_5.5_Datasheet_51_en_2775686 027.pdf
Multiple power supplies, all IO protected, flexible io, internal high quality logging, current feedback on outputs, programmable current parameters, vibration isolation, high quality connectors, advanced turbo control with turbo speed inputs, wide power range for when the alternator dies, on and on...
Really the biggest difference between the best ECUs and the worst are in the basic design, board layout, software and a TON of little details. On a spec sheet you could line up the best and worst 4 cylinder standalones and the spec sheet shouldn't be miles apart. I've seen bad ECUs die because of a momentary grounding of the 5v bus or a user misconnection of gnd and +12v.
Specifying the processor is odd at best. You want automotive temps and most ideal processors have a coprocessor or time processing unit that do the heavy lifting. At the customer level XXX Mhz becomes transparent and irrelevant. You can get an old series ~50Mhz MPC5xx processor with multiple TPU cores that will be much more appropriate than a 1GHz + Arm core as used in cell phones. If we were in a Mhz race, we would all be using Arm cores and nobody would be using the automotive specific processors from Freescale, ST, Atmel, Fujitsu, Infineon etc.
#29
Elite Member
Thread Starter
iTrader: (1)
Join Date: Jun 2012
Location: NH
Posts: 9,479
Total Cats: 104
A few things missing from this list... oh wait, here is the answer:
http://www.bosch-motorsport.de/en-US/literature/en-US/Engine_Control_Unit_MS_5.5_Datasheet_51_en_2775686 027.pdf
Multiple power supplies, all IO protected, flexible io, internal high quality logging, current feedback on outputs, programmable current parameters, vibration isolation, high quality connectors, advanced turbo control with turbo speed inputs, wide power range for when the alternator dies, on and on...
Really the biggest difference between the best ECUs and the worst are in the basic design, board layout, software and a TON of little details. On a spec sheet you could line up the best and worst 4 cylinder standalones and the spec sheet shouldn't be miles apart. I've seen bad ECUs die because of a momentary grounding of the 5v bus or a user misconnection of gnd and +12v.
Specifying the processor is odd at best. You want automotive temps and most ideal processors have a coprocessor or time processing unit that do the heavy lifting. At the customer level XXX Mhz becomes transparent and irrelevant. You can get an old series ~50Mhz MPC5xx processor with multiple TPU cores that will be much more appropriate than a 1GHz + Arm core as used in cell phones. If we were in a Mhz race, we would all be using Arm cores and nobody would be using the automotive specific processors from Freescale, ST, Atmel, Fujitsu, Infineon etc.
http://www.bosch-motorsport.de/en-US/literature/en-US/Engine_Control_Unit_MS_5.5_Datasheet_51_en_2775686 027.pdf
Multiple power supplies, all IO protected, flexible io, internal high quality logging, current feedback on outputs, programmable current parameters, vibration isolation, high quality connectors, advanced turbo control with turbo speed inputs, wide power range for when the alternator dies, on and on...
Really the biggest difference between the best ECUs and the worst are in the basic design, board layout, software and a TON of little details. On a spec sheet you could line up the best and worst 4 cylinder standalones and the spec sheet shouldn't be miles apart. I've seen bad ECUs die because of a momentary grounding of the 5v bus or a user misconnection of gnd and +12v.
Specifying the processor is odd at best. You want automotive temps and most ideal processors have a coprocessor or time processing unit that do the heavy lifting. At the customer level XXX Mhz becomes transparent and irrelevant. You can get an old series ~50Mhz MPC5xx processor with multiple TPU cores that will be much more appropriate than a 1GHz + Arm core as used in cell phones. If we were in a Mhz race, we would all be using Arm cores and nobody would be using the automotive specific processors from Freescale, ST, Atmel, Fujitsu, Infineon etc.
#31
Parallax Propeller - Wikipedia, the free encyclopedia
And the more power the more accurate you can do your airflow simulations and interpolation between cells in a table. And it would open up the ability to actually model transient fueling based on port wall coating rather than just stomp comp.
For the hobbyist, what's more important are the auto-tune wizards for the time-consuming stuff like boost control, idle, and transient fuel.
#32
Elite Member
Thread Starter
iTrader: (1)
Join Date: Jun 2012
Location: NH
Posts: 9,479
Total Cats: 104
The more you know I guess. Electronics are not my strong suite, especially imbedded electronics. Which is why I missed requirements like power supplies and filters and whatever else. My real gripe with most standalones is not the hardware its the software anyways. For example, the EMS4 is MORE than capable enough to do the math for VE based tuning, its not supported and they have no intention of ever supporting it even though it should be like 20-50 lines of code on the controller and some added code to the tuning software. Instead I have to make an excel to convert between real tuning and injector pulsewidth 90's tuning.
#35
All good points. On the processor, why multi-core. Its obviously very hard to program something to multi thread as shown by any single pc software company that has more programmers than the entire automotive aftermarket. And the more power the more accurate you can do your airflow simulations and interpolation between cells in a table. And it would open up the ability to actually model transient fueling based on port wall coating rather than just stomp comp. But we're getting into serious feature creep range on a lot of things. I don't picture this being a bosch/pectrel/mclaren competitor on price point.
The bottom line is that more processing power is /= better and from a customer standpoint is a largely irrelevant point. Just trying to debunk a common customer misconception.
#36
All good points. On the processor, why multi-core. Its obviously very hard to program something to multi thread as shown by any single pc software company that has more programmers than the entire automotive aftermarket. And the more power the more accurate you can do your airflow simulations and interpolation between cells in a table. And it would open up the ability to actually model transient fueling based on port wall coating rather than just stomp comp. But we're getting into serious feature creep range on a lot of things. I don't picture this being a bosch/pectrel/mclaren competitor on price point.
Multicore is an absolute non-issue as the vast majority of embedded systems don't feature any sort of pre-emption, i.e. there are no threads. At best you use protothreads to give the illusion of sequential processing, at worst, you use a bunch of ticking state machines.
You are thinking of multi-core processors designed for general purpose applications, which suck for real-time control. *This* radically different multi-core microcontroller is suited for real-time embedded control:
Parallax Propeller - Wikipedia, the free encyclopedia
Parallax Propeller - Wikipedia, the free encyclopedia
Bah, mid-range microcontrollers have more than enough power to do those.
For the hobbyist, what's more important are the auto-tune wizards for the time-consuming stuff like boost control, idle, and transient fuel.
For the hobbyist, what's more important are the auto-tune wizards for the time-consuming stuff like boost control, idle, and transient fuel.
My dream ECU is simple: MS2 featureset, with a proper power supply, on a single board, with real connectors, a better communication protocol and a codebase that isn't a huge, flaming pile of ****. I'm sorry guys, I know it works, but MS has some of the _worst_ code I've ever seen. It's so bad, we show it to developers here as an example of how to get fired.
Seriously.
#37
Elite Member
iTrader: (1)
Join Date: Jun 2006
Location: Warrington/Birmingham
Posts: 2,642
Total Cats: 42
Is it just inefficiencies/bad math, or fragments of dead code left behind or?
I'm beginning to suspect my MS3 ECU is displaying signs of a bug, but it's not apparent on most setups, I presume bad code could well be a cause of something like that?
#40
That's not an issue with the ECU, that's an issue with the tuning software. Whether it's VE based or injW based, the tuning software will send the same tables to the ECU. Put another way, one can re-write the tuning software to present VE based tuning to you, then translate it into whatever the ECU needs.