View unanswered posts | View active topics It is currently Wed Jun 20, 2018 7:44 pm



Reply to topic  [ 10 posts ] 
Hardware vision / general plan 
Author Message
1N4001 - Signed up
User avatar

Joined: Tue Jun 10, 2008 5:17 pm
Posts: 1607
I'd like to start talking about the game plan for the hardware. Right now we have been working on the bare minimum setup, however bare min is a requirement that changes from person to person. So I'd like to spend some time on putting together a vision or general plan for freeEMS 1.0, 2.0 and 3.0. I picture this list or plan as just that, a guide to help see the forrest from the trees. Right now we seem to be focusing on the tree.

I think we should list general features for each version, and I think we should try to allow for 1.0 to work as a base for 2.0 and 3.0. Here is how I see the list based on gut feel from what I've been able to absorb in the forums.

In 1.0, 6 CYL sequential fuel, and spark, natural aspirated, hall or VR tach input, O2, air and coolant temp, injector current sensing, 3 aux output.

In 2.0, more robust power regulation, ignition sensing, knock sense, IAC, more inputs and more aux outputs outputs.

In 3.0, boost control, ion sensing, other.

When I step back and think about it, perhaps we want to move the injector current sensing to 2.0 and move the robust power reg to 1.0. If we do, this will allow for 2.0 to be an addon to a stack of hardware. It also gives us a gut feel for what future power requirements and such might be. How does the work now effect work in the future?

Thoughts?

I also don't see why we can't blaze a trail, perhaps even generate some PCB's that don't exactly match the above list, that way we can start testing, and writing firmware for a specific platform. I don't plan on letting the above stop or slow progress, simply guide progress as it goes.


Mon Aug 25, 2008 2:26 am
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15142
Location: Home sweet home!
Well, the way I see it is that we need to create a "low end" basic system that becomes the defacto standard for most users. The users that want bread and butter installs. I think that is what we should be aiming for at this stage.

That design should use a modified TA card and do the basics for "most" people. That thread in the BB section should go a long way towards telling us what is required for this initial design. Give it a bit longer and we will look at everyones answers to the questions and the additional comments, weigh up what it means to include or exclude everything and decide on a spec for this board.

I think a stable boringish but not too light weight main board needs to exist from now into the future as a core to the project on the hardware side just as I want to see a core firmware that can be relied upon there and available too.

Beyond that I have no preference and am just very interested to see what interesting variants and creations various people come up with for it. Particularly bike guys who will go small and compact and power users who will go large and dense/complete.

I think a good level of focus on keeping this system basic but complete as a continuous stable core platform is a very good idea. Branches can be made etc and mods done and successes reintegrated into the main line of hardware much like what would be done with software.

It's also important to remember that it's dead simple to upgrade this with the headers on top of the TA card. So forcing extra stuff that shouldn't fit on when it could be on an expansion card makes no sense to me.

What I'm saying is that no board will ever be "right" for everyone, so this one, the initial one, the get off the ground one should just try to cater to the majority. That thread should clearly define what the majority do need and don't want. So once it has lingered for a while longer we can see what we need to do to satisfy the most people with it.

So far I see it being a good thing to bring out all ignition channels through buffers for use as general low power outputs for relay driving etc That will kill a lot of birds with one stone. I also see it being a good thing to put at least two FETs on PWM pins, preferably the high resolution PWM pins. I still think the 8 analog inputs should go on a different board, but perhaps a couple of digital ones bufferred would be a good thing to have too. I can lay out what we need to do and which pins to use for it when that thread matures.

Fred.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Mon Aug 25, 2008 5:11 pm
Profile WWW
1N4001 - Signed up
User avatar

Joined: Tue Jun 10, 2008 5:17 pm
Posts: 1607
Here's a quick sketch of how I see freeEMS

Image

Because of this, I think it might be best to keep freeEMS 1.0 on the outer most pins of the TA card, so 1H50 (VCC) to 1H26 (AN15) and 2H26 (AN07) to 2H50 (GND-3). Then freeEMS 2.0 and 3.0 could use the inside pins which are harder to get at. Perhaps freeEMS 2 and 3 won't need both rows, and you can cut them off on the connector that will go down the middle of the board(s). This way you could always pull it apart slightly, and connect a scope if needed.


Wed Aug 27, 2008 11:30 am
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15142
Location: Home sweet home!
Other than the versioning I see it potentially being similar to that, but possibly with small add on stuff on top of the TA as well/instead and with all pins at all levels for absolute expandability and also more physical strength and robustness. Provided the PCBs have all the pin in each case you can do as you wish as can I :-)

That reminds me, the BOM should include the same part as used on the TA board for pass through ability. Normal sockets are OK for those that don't want to expand further down though.

I thought that by 2.0 you mean a new main design, not an add on card. I think such add-ons should get their own nomenclature depending on their function. Something like 12 FET board or 8 ADC / 8 digitial Input board etc.

Fred.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Wed Aug 27, 2008 3:19 pm
Profile WWW
1N4001 - Signed up
User avatar

Joined: Tue Jun 10, 2008 5:17 pm
Posts: 1607
I like that, lets change that from "freeEMS 2.0" to "freeEMS IAC boost control", ect. That way we have freeEMS and descriptive add-ons.


Sun Aug 31, 2008 3:12 am
Profile
TO92 - Vaguely active

Joined: Fri Oct 10, 2008 8:00 pm
Posts: 2
I agree, I was thinking V1.0, 2.0, 3.0 was different revisions (I'm new, so I thought I was just stupid). I would at least call them adapter boards, but explaining their functions would be ideal. One of the problems I see occurring with this modular design is the ability to have standard cases. Maybe you've already taken that into account, but as I said, I'm new and still looking around. I'm a computer engineer myself, so I'm more than willing to help with any circuit, board design, or programming. Also, I'd be more inclined to separate the power circuitry and outputs as much as possible from the inputs to reduce noise. Maybe the power system on the first board, outputs on the second (relays and FETs) and inputs like the knocksense and ion sensing on the third.

Let me know what you think.

I was thinking a system-level diagram would be a nice thing to draw up as well.


Fri Oct 10, 2008 9:12 pm
Profile
1N4001 - Signed up
User avatar

Joined: Tue Jun 10, 2008 5:17 pm
Posts: 1607
Fred drew up a system design, showing injectors, fules pumt, ems, ect. It's in one of these threads somewhere.

We basically have several power supplies that route through devices, then ground at the EMS. So a path might be like, batt to relay to injector to EMS to gnd. Same general types of pathes for other devices like coils, and fuel pumps, ect.

Very willing to here input, right now I think soft/firm is the biggest thing. We have a board layout that will very likely work, the last major thing is connecting the circuits to the TA card's pins. That's not that hard of a task, we just need soft to develope such that we can really claim that pin X is really going to be pin X.

Check sourceforge, the KICAD file are there, as well as a PDF copy for those with out KICAD installed.

About the revisioning, I tend to think less about it. I think a shed is more important than the color.


Fri Oct 10, 2008 9:48 pm
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15142
Location: Home sweet home!
http://i260.photobucket.com/albums/ii15 ... iring5.png

Something like that?

Welcome along anyway :-)

Fred.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Fri Oct 10, 2008 10:02 pm
Profile WWW
TO92 - Vaguely active

Joined: Fri Oct 10, 2008 8:00 pm
Posts: 2
Yes, that's exactly what I meant assuming some details are going to be filled in as they become solidified. I haven't had a chance to look over the drawings yet. I plan on looking at the source code as well. I've always just felt the hardware was the most important thing. Programming can be changed easily, hardware is a lot more difficult and expensive. I'll be watching to see how the first board design works out. Hopefully it'll just be a couple bandaids required. Glad to hear everything is coming along well.


Tue Oct 14, 2008 6:13 pm
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15142
Location: Home sweet home!
If by details you mean the sensors etc, then no, they'll live in a separate diagram to keep it clear and comprehensible. I find the ms diagrams difficult to read and understand because of the clutter and I'd like to avoid that if possible.

Glad you like it :-)

Fred.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Tue Oct 14, 2008 8:33 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 10 posts ] 

Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF. ColorizeIt.