FreeEMS hardware feature wishlist (your suggestions here!)

[Fred]

Cough cough :

Rule four : Open development as well as open source. By this we mean don't wait until it's finished to show the world, show them now. This enables others to offer suggestions and help with your project, such that it turns out better in the end. As Google and SourceForge say "Release early, release often". We will be trying to do this too.

From http://www.diyefi.org/why.htm

Obviously, it is at your discression, but I for one am very keen to see what you have going on no matter how half finished it is :-)

[Una]

Will this unit have a constant power source? That's one thing I've always seen seriously lacking in MS. With a constant power source, you can retain things in RAM while the car is off, like a standard factory ECM would do. This would be hugely helpful for things like idle control, boost control, anything where the ECM might have to adapt to changing conditions, and it might be nice for the ECM to actually remember what it did the last time it was on. Yeah, it could be burned to flash (well, not with the MS's current craptastic CPU, unless you like the engine stumbling a lot), but you can only write to flash so many times, and it's a much slower process than just having some bit of ram that can be kept awake.

As for the people wanting a PC in the car that won't get stolen, and blends in like an ECM.. Ever looked at the "FitPC".. I keep meaning to order one when I have the cash handy, to replace my exceptionally worn out laptop. I already have an LCD bolted to the dash, since the one on my laptop long since stopped working (and I tore it off, to make the laptop less enticing to thieves.. hehehe).

[GartnerProspect]

LOL. I figured I'd get that.

When I mean presentable, I mean, not on a napkin.

If you'd like me to scan it in I surely can!

About all I have to show anybody right now is a list and some sketches. And I've been slowly building Schematic/PCB components in software so when it comes time to digitize the whole thing I'm not stopping every 15 min to build and define a new part.

But fear not!

As for a constant power source, that's not something I've ever thought about. It would require some additional thinking on keeping current draw to a minimum, placing parts into suspend or isolating them completely from the ignition switched source...

I'd have to be better convinced of a real world situation I think. I'd like an RDIF auto ignition and security, that'd convince me!

[Fred]

Una : In the long term, maybe! Our CPU has a proper EEPROM, so we can write things down when we sense power is on it's way out, and then self power ourselves down. We could also stay in sleep mode while the ign is off. I can see this being useful for hot starts etc and better interpreting the IAT/MAT (which are/should be different sensors). What I would like to see is a RTC on board, and to write the shutdown time/date to EEPROM on each power down. This would enable a simple temperature decay model based on ambient/IAT at the time of shutdown, the temperature at reboot, and the time difference between the two.

Of course, short term there are a lot of far more core things to be done, but yes, that is an attractive thing to have for sure, and we have the power to make that happen here.

Gartner : Fair enough, I thought perhaps you were further along than napkin phase :-) I'll look forward to it.

Admin.

[GartnerProspect]

Well, I sorta am or what. But I recently changed my whole direction so I have to wipe the slate clean and go back to scratch. I was originally counting on a particular CPU, but realized how foolish that was at this point in time and am redesigning a more flexible platform. I'll start a new thread tonight with the details so I don't clog up this thread any more.

[Una]

Can we have a true VSS input? Not like the MS's little afterthought, using a frequency to voltage converter. It'd come in like the tach input, watching for actual pulses, and in the software I could tell it that X number of pulses = 1 mile (mine is roughly 8k). This would be handy for idle control at the very least. And lockup torque converters. I admit, I only want it so that a gas mileage gauge could be default.. (This is a feature wish list thread... hehe)

[Fred]

For myself eventually I want 5 speed inputs so I can log wheel speed on a race track :-)

The trouble is that we need to have a clear set of what is standard and what is add-on and sensible defaults for when the add-on stuff isn't present.

But yes, VSS is on the list for sure. It may end up on an external chip, but with digital comms to the main chip.

[GartnerProspect]

Can I have VSS too? Please please!?

I would actually like to completely replace my dash with an LCD gauge cluster, so it'd be helpful.

Now I'm guessing that the MS freq/voltage rig is less accurate, but it saves cycles?

You can poll the adc whenever you want rather than having the VSS use up a counter?

Which brings me to a question regarding counting that doesn't even belong here. When inputting a crank signal, do you typically use an interupt so you instantly are aware of each tooth or how does that work? Maybe you need to put a forum category :Brads Dumb Programming Questions.

[Una]

Programming this new CPU - For Dummies.. I'd go for that.. I've got plenty of those kind of questions.. (Sorry for the off-topic post.)

[thebigmacd]

Can I have VSS too? Please please!?

I would actually like to completely replace my dash with an LCD gauge cluster, so it'd be helpful.

Now I'm guessing that the MS freq/voltage rig is less accurate, but it saves cycles?

You can poll the adc whenever you want rather than having the VSS use up a counter?

Which brings me to a question regarding counting that doesn't even belong here. When inputting a crank signal, do you typically use an interupt so you instantly are aware of each tooth or how does that work? Maybe you need to put a forum category :Brads Dumb Programming Questions.

(1) Yes VSS is a must. It is useful in advanced engine management strategies, and if any interfaced transmission control comes to fruition, it will be good to already have the VSS portion already layed out.

(2) Correct, freq/voltage is less accurate and prone to some drift. Plus, if the microprocessor counts cycles you have the groundwork for an odometer reading that is saved in eeprom.

(3) Yes, the ADC would be polled rather than using up an interrupt

(4) Typically tooth transition events are handled ASAP by interrupt

Finally...in OEM vehicles the main VSS signal is nearly always conditioned and analyzed by the microprocessor in the gauge cluster. It in turn provides a nice clean TTL square wave to the ECU. When tapping in to the VSS signal for standalone purposes (the LM2917 circuit), it is actually the signal coming from the gauges that should be used.

What I am getting at is in this application the VSS-related should be similarly offloaded to an expansion board of some sort and the values grabbed via datalink.

I am in the preliminary stages of building a "gauge cluster controller" for my MegaSquirted Jetta since the mk3 cluster I have doesn't fit properly in my dash. Some features include: pwm outputs to control at least four servo-driven gauges (temp, fuel, speed, tach), NTSC/PAL/VGA output to a screen, serial output to multiple lcd character displays (4 for now), variable voltage outputs for interface with MegaSquirt (VSS, fuel), and an LED matrix for idiot lights.

It would be trivial to program it to dump data to a diyefi system in whatever format required. Once I have the programming complete I could strip the firmware down for use in a simple VSS/datalogging interface.

/ramblings