thenuge26

iTrader: (2)

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.

viperormiata

iTrader: (24)

My dream ECU: Braineack in the passenger seat doing everything for me while I drive and holla at females.

Reverant

iTrader: (10)

What's the method? I also have 5 widebands if that helps.

richyvrlimited

iTrader: (1)

As I understand it EGT doesn't vary massively before or after MTBT, only when you're way WAY out timing wise.

Ergo it's not a very good way to tune spark as a primary input.

thenuge26

iTrader: (2)

Ah, that explains why someone hasn't already done that. Thanks for crushing my dreams.

Leafy

iTrader: (1)

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?

hustler

iTrader: (6)

I can dream about my perfect computer, if I can't hold it tonight.

vtjballeng

iTrader: (1)

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.

Leafy

iTrader: (1)

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.

Braineack

iTrader: (62)

females? you have the wrong ECU.

JasonC SBB

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


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.

Leafy

iTrader: (1)

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.

sixshooter

iTrader: (12)

As long as you are making a dream list, how about that it should do those things and still retail for $600 or less.

Leafy

iTrader: (1)

I think you could do everything in the required section for that price, maybe. But I'd rather open it up to sub 1500 and get more of the optional features into it.

vtjballeng

iTrader: (1)

Jason got there first but basically this isn't at all like coding for a computer. Embedded can be quite different and Automotive cares about timed events and not so much processing power. Those timed events are absolutely critical and just to take one processor, the MPC5xx or 5xxx series they offer time processing units that handle the critical events for you. Otherwise you are spending a lot of time crafting your own base operating code to ensure that you are handling your critical events when and as required. This is even harder to do in simulation or C rather than assembly. Once in the main processing system there is often custom A/D, output handling, timer compares, etc that are made for this market (sometimes industrial too).

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.

Jeff_Ciesielski

iTrader: (10)

Did somebody say McLaren?
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.

Propellers are neat and all, but they're quite unsuitable for anything serious. I know they now have GCC support and they look great on paper, but you have to bit-bang everything. Weak. You end up defeating the coolness of the hub + processing spokes architecture by burning up entire cores to interface with external ICs. By the time you've covered SPI, CAN, I2C, and USART, you're half occupied. Also, even though the hub memory window shifts predictably, I'd be hesitant to rely on a hard real time system that could potentially miss out on it's memory access.

Troof. I've streamed and decoded compressed, reasonably high quality audio (32khz) using a lower-mid range ARM. The vast majority of engine control doesn't need nearly as much processing power.

I can't stress enough how important timing and avoid concurrency issues are. Engine control (from a strictly _control_ standpoint) isn't rocket science. Interpolating between cells, extrapolating values, and calculating stuff like wall wetting based on a fixed algorithm really aren't difficult from a programming standpoint. What's harder is making all of those happen inside their own event windows and without negative consequences should they be pre-empted by an interrupt.



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.

richyvrlimited

iTrader: (1)

I haven't the first clue as to how to code, so please excuse my ignorance, but could you explain to me why/how it is bad?

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?

Reverant

iTrader: (10)

This is definitely a bug, no doubt about it.

richyvrlimited

iTrader: (1)

Presumably that's why the devs are conspicuous by their absence on my thread :(

JasonC SBB

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.