FreeEMS hardware feature wishlist (your suggestions here!)

[jbelanger]

You could use a diode to prevent the current flow issue, I guess. As for USB specs, the port is limited to 500ma.

Jean

[Fred]

http://en.wikipedia.org/wiki/USB#Power

However you have to be at or less than 100mA when you plug in, so that effectively rules out FreeEMS with its 350mA draw... (If you want it to be compliant)

Fred.

[jbelanger]

I don't think it would be a problem for most computers but you're right that it wouldn't be compliant (with all the potential consequences).

Jean

[AbeFM]

You can put in a resistor/cap that turns the whole thing on? So, make it wait 1 second, then draw 350

[jbelanger]

To be compliant, it's not just a question of time but there has to be a request/grant exchange.

[jharvey]

I wanted to toss out the idea of a modular design. See below picture.



I'm picturing a couple of busses separating the head unit from the slave like devices. This will likely require changing the design from one monster powered processor to several smaller ones, or perhaps not I haven't done a detailed guess yet.

Some key benefits include moving the A/D's closer to the sensors reducing coupled noise, and the ability to add your own module at a later date. Allowing for bite size pieces now.

For example, you could make a chip that reads the coolant temp, tps, ect, then via 1wire buss relay that data back to the ECU. Also note the use of ing2, you could add multiple cyls simply by connecting several modules to the same buss.

It's late, can't eloberate now, but at least I got it out there for thought.

[thebigmacd]

I wanted to toss out the idea of a modular design. See below picture.



I'm picturing a couple of busses separating the head unit from the slave like devices. This will likely require changing the design from one monster powered processor to several smaller ones, or perhaps not I haven't done a detailed guess yet.

Some key benefits include moving the A/D's closer to the sensors reducing coupled noise, and the ability to add your own module at a later date. Allowing for bite size pieces now.

For example, you could make a chip that reads the coolant temp, tps, ect, then via 1wire buss relay that data back to the ECU. Also note the use of ing2, you could add multiple cyls simply by connecting several modules to the same buss.

It's late, can't eloberate now, but at least I got it out there for thought.

I had this idea too, but it's not going to be implemented within the scope of this particular project.

I have partially designed (in my head) a standardized chip-chip crank speed/position signal for event synchronization for this very purpose. I have also thought a lot about the concept of a free-running crank position estimator/predictor that would allow easy event queuing based on crank position. Not a lot (none actually) of concrete documentation/implementation though.

[Fred]

Guys, although FreeEMS as such is going to be what it is going to be (to some extent) there is nothing stopping you from starting a thread in the section above this one for the purposes of discussing a distributed approach. You could start one from a firmware point of view, and another from a hardware point of view. Alex (ababkin) is on your team too and will be pleased to be involved.

I like the idea, but I like the idea of a single chip simple effective solution quite a bit better from a practical point of view. There is no doubt that a distributed approach can work, but the hardware infrastructure could become a pain, esp in open source land I would imagine.

If you are shy I can start a pair of threads for you, or there may already be some (it just occurred to me that there might).

Fred.

[Fred]

Here you go, it was Shameem that started it, but he started it in FreeEMS Hardware, so I moved it to General EMS http://www.diyefi.org/forum/viewtopic.php?f=9&t=249

It seems to be software and hardware, so I thought that was the best place. Enjoy :-)

Fred.

[jharvey]

Glad to hear others think it's a good idea, oddly enough I'm also glad to hear that it's not making the cut for this round. It's not a bad thing to draw a line in the sand and take a bite with what you have on hand. There are always things to learn, and if you don't choose what's feasible and focus on that for a while, you won't ever get a project finished.

Any how, I'm sure there are going to be a pile of features out there not included in round 1, but if we toss them out here, then we can start compiling a list of additional features for round 2.