History of VemsFrontier/Boards
Older Newer
2005-04-23 23:49:44 . . . . MembersPage/MarcellGal [split network hardware]
2005-04-23 23:05:11 . . . . MembersPage/MarcellGal [RS485 connection between N boards of mega88 ?]
2005-04-23 22:19:34 . . . . MembersPage/MarcellGal [sn65176b soic8 half-duplex transceiver]
2005-04-22 12:57:09 . . . . MembersPage/MarcellGal [reworked board mapping]
2004-11-18 11:10:56 . . . . MembersPage/MarcellGal [split MiracleBoard]


Changes by last author:

Added:
= ARM based projects =

The idea behind is that different ARM boards should share parts of hardware/software, (and AVR boards too) which would make development more efficient and would ease communication between boards. A common development will also allow us to share development costs.

----

VemsFrontier/NetWorkHardWare - find a good way for networking the AVR (mega88) boards

----

Manufactured as a break-off of a bigger board

* We will manufacture 30..40 boards first with short turnaround time

* Break-off only after automated assembly, of course

* 2 or 4 copper layers

With the help of newly created VemsExecutives/CaseDesign the 120x40x2.5 profile (a case that can hold 2 big boards with userfriendly assembly/disassembly) had been approved for some boards. The Round CNC-ing is also prepared.

VemsFrontier/ARM boards:

* 2005-04-24 functionality (mostly decided already)

* 2005-04-25 schematic 80%

* 2005-05-01 BOM chips and LED displays, start ordering

* 2005-05-01 PCB 70%, size finalized

* Not needed (done by boardhouse): allocation on breakoff board

* 2005-05-10 finalization of PCB

* 2005-05-20 finalization of PNP assembly stuff

High prio

* Round display: nice and as many LEDs as possible, but WBO2 exported to dongle

* Dongle: potted with WBO2 connector, talks serial and has analog IO

Maybe delayed to 2005-05 - but wouldn't hurt to roll a bunch

* VemsFrontier/ArmEfi (based on 120x40x2.5 mm case)

* board9343 (based on 120x40x2.5 mm case: so size updated to 114x34): LEDboard (with 2..3 round LEDbars and several digital or alphanumeric LED displays) Mega88 is enough

* VemsFrontier/MiracleBoard

Maybe postponed - but some proto would be nice

* ION smarts experimental design. Based on ARMefi (based on 120x40x2.5 mm case): interface is just the analog signal? What controls the multiplexer?

* ION Power experimental design (CDI supply and ignition switches, Plasma supply and switches, ION supply.) (based on 120x40x2.5 mm case). Let me note I prefer the transformator or L based supply, compared to caps charge-pump.

POSTPONED: - indefinitely

* AfreshMicro

----

Forget thruhole

I write this here because it affects several boards.

Please go with SMD as far as possible. Maybe this should go to DesignGuidelines page.

Thruhole is

* very hard to work with

* consumes lotsof space

* very expensive

* impossible to do professionally

* looks 35 years old design

* please change to SMD crystal in the next revision (almost same footprint as the thrughole, HC49... whatever..). Unfortunately we couldn't do so on v3.2 because +1mm would be needed in the long direction, but v3.x is routed densely. But we changed everything to SMD as far as possible.

* From now we should design boards with mostly 0603 components (0..330nF ?V; ?uF 25V; The 2.2uF ?V)

* min drill we design with is 12 mil (8 mil according to spec, but we better be safe)

* min clearance we design with is 7 mil (5 mil according to spec, but we better be safe)

* min tracewidth we design with is 10 mil (8 mil according to spec, but we better be safe)

* 1210 35V 10uF on 12V lines

* 1206 10V 10uF on 5V lines (and 220nF close to chips)

* BAV99 for railing to supply and GND at the same time

* SOD80 (LL4189) diode (or zener) for small load

* SMB footprint diode for upto 2A (continuous)

* mostly DPAK IGBTs and DPAK FETs. 2 IGBTs might be TO220 near the board-edge (or board that ain't really for driving stuff, some TO220 near the edge is welcome !)

* stepper chip: SN754410 (=L293 pinout compatible, but no diodes needed)

* the connector sucks as always, consumes huge space, expensive, etc... we have to live with that

* There is an unbelivable PottingCompound that helps heat transfer

----

= Copyrights =

The following discussion should be placed elsewhere.

It seems this should be discussed:

* when should the systems designed here be public?

I suggest we make software GPL-ed after 0..3 years (depending on type).

I think there is no point in making HW public (at least for 5..10 years). It would benefit only for commercial organizations to steal and sell it without donating anything to development. It wouldn't benefit to a student who wants to manufacture 3..4 boards for himself, as that's extremely high cost in low quantity; much higher than when made in 100+ quantity.

Also, there is huge amount of work from some people already put into v3.x (WBO2, firmware, HW). Swapping a processor shouldn't take away their IP.

Also, making HW open would make it hard to finance developers. If it worths to manufacture, either the developers or a commercial player would make some profit from it. I vote the developers do. For the end-users it's little difference. End-users are happy to donate 150 Euro to developers who developed a 800 Euro system that is otherwise only sold for 5000 Euro.

Also, making HW public would make manufacturing harder. Who would invest 10000 Euro into the manufacturing (2000 Euro had to be spent on the initial Econoseal stock alone !) if it's possible that someone start to sell the same board the next week, maybe for a few pennies cheaper. Waiting for the orders to gather (to be sure) would be slow. The developers would need to wait longer for their own boards, and would have to pay for it!

The big difference between software and hardware is that one student or small enterprise can possibly start to use the software (running on PC or other computers) at once, while hardware is only useful if it's manufactured, and manufacturing only makes sense in 100+ quantities (one could argue 1000+).

But we clearly need to refine CompenSation/Distribution and track efforts and results so anyone who contibutes work should take their share.

Alexei - I'm really surprised by your reaction ! How can you expect to protect the design if you give on this site schematics and software sources ??? When I've been copying these files I have not seen any license (maybe I should ? yes), or registration form. Or do you expect all Internet users are honest ?

When I buy a Motec ECU I can not copy it, it's just a yellow box and a poorly designed PC exe file.

Note that copyright has nothing to do with how easy it is to copy a design. If you didn't find a copyright, that means you are not allowed to copy (check the law, it is very clear): it is actually the case for HW, but you should look more carefully for software, eg. top of wbo2.c and GenBoard/PublicLicense

We definitely intend to get students learn from the design, and play with it, and contribute. But we want m0tec to pay to our developers if they think it is cheaper to develop from this than from scratch.

--

So we have to clearly define the license. (as it's always been).

So you suggest to not disclosure the HW ? As I said, the license

has nothing to do with the HW disclosed or not. I think it's good to have some control over HW visibility, but we definitely make it very easy for our developers, students and installers to get the schematics.

Could I have schematics of one board if I joined another project ? yes. Even if project mapping is mainly done on functional mapping level.

The next question is the usage the developers could make of the board. I would like to sell engine solutions with the EFI included inside. Could I do that ? yes, of course, why not? The reason for the design is so it is manufactured (in a controlled way), used, learnt, improved etc... It's very clearly stated even today. You just need to

* contribute back the firmware changes to original authors (this is not the same restriction as General Public License has! Note that traditional GPL also has clear restrictions, it is very unwise to publish something public domain with absolutely no restrictions: that encourages abuse like microsoft does: turning technology against people by making them depend on it while taking away all their rights). If Ferrari pays you 1000000 Euro to install 80 pieces on 2005 F1 engines, you're lucky (only very small percentage of that is profit on boards, most is profit from installing - thus yours).

* get boards from the team-organized manufacturing. Actually, core developers can make their own manufacturing if they like (they provide free samples for the group, and distribute board profit between developers - profit above manufacturing, handling, posting ..etc costs of course): they know the best that it's best to organize together

* have wbo2 licence if appropriate

Could I make my proper printed circuits with different board connectors ? yes. You can also have the profit from installing it to a large number of vehicles. But - even if you are a core developer - you are asked to contribute from the profit of the EFI sales to the other developers (it is marginal compared to the full project, a few 100 Euro per computer. Very good deal, given that you had much less chance to realize those sales without their work).

* I've seen a lot of discussions on CompenSation/Distribution, but no decisions.

Yes, there are decisions. The decision is that profit is distributed between contributors. Naturally, exact contribution factors (credit for architecture, firmware lines, testing etc..) only becomes urgent when sales are boosted. With v3.2 (besides the free HW as always) max 40 Euro per board (unfortunately even that can be delayed so the warehouses and manufacturing can prepare for the upcoming sales boost) can be distributed among developers (100*40 Euro = 4000 Euro) so that's not much difference if one has 10 or 13% in it.

However when we have the proper doc and tuningsoftware, with 5000 boards and 200 Euro distributed per board it makes more difference. But in any case, it's clearly a benefit for the developers to have some control over the HW manufacturing.

Please, make a clear distinction between disclosure and licence aspects. The fact that anyone can see the schematic does not mean that a third party is allowed to steal the design and manufacture 60000 units without any compensation to developers.

"Please, make a clear distinction between disclosure and licence aspects." I do. I just try to point out that if schematics are available, someone planning to sell 60000 units won't even read your license, he will just make a good package to prevent you from discovering it. Especially if he's able to produce 60000 units. Don't think people like Bosch could be interested by our design, they are far far away and just can not use this kind of designs for alot of reasons.

Could you replace this discussion with conclusions and a license definition, please.

----

= The CPU choice =

[The old wiki BrainStorming page] contains initial discussions about the MCU choice.

It appeared that ARM cores were often prefered. Currently only ARM7 chips are publicly available, while most of new industrial projects target ARM9/10/11 based chips. ARM cores are assumed to be backward compatible. Even if that's not always true, the big force of ARM is an homogeneous peripheral offer and the same development platform whatever is the chip maker.

VemsFrontier/ARM is the page about different ARM chips

GenBoard/VerFour : another ARM related page (should not be used as the v4 name is confusing)

----

= Currently identified projects (planned or started) =

* IonSense/HardwareDesign : ION/CDI board

:Is really two boards, one with the smarts and the sensitive electronics and onewith the CDI and HV supplies. They are always used together and are installedin the same box.

:Top page of IonSense.

* VemsFrontier/ArmEfi : ARM based engine managment

:The intention is to make an EFI board that is simpler and smaller then the V3, it's meant to do simple ignition and rely on ION/CDI to do (very) advanced ignition.

* GenBoard/EngineBoard : Engine Board project

:The intention is to make an external I/O board that hosts a number of high-end functions that does not fit on the other boards. It can also be used to collect all sensor information for the other modules and pass in on as a CAN data stream.

The above three projects is what we call the VEMS frontier project. The V3 is awesome, it's impossible to improve much on it without using a huge board. Instead we build several boards and to make it scale well we build them to work like modules. All three boards must be used to get all functionallity of the v3, but ArmEfi will be able to do most of the stuff V3 does. Engine board will have most of the 'extras' we are used with from v3. Ion will take the ignition to an other level.

----

* TractionControlArm : Traction control project

* General purpose EFI ( GenBoard/VerFour )

:Full feature EFI with injection, ignition, idle, NB/WB lambda, knock, turbo management and general purpose inputs/outputs. A simplified version could appear later (i.e. for motorbikes). Note, this is not a VEMS Frontier board!!! -Jörgen

* ArmProcessorSubsitution : Genboard v3 with an ARM in place of AtMega128. This is not a VEMS frotier board!. AVR is enough for V3.-Jörgen

* GoBox : Universal Motor Controller

:Goal is to define a solution specialized to the challenge to make Internal combustion Motors run with minimal amounts of Combustibles based on GoBox/HydroCarbons.

* PlugAndPlayEEC : Genboard v3 with a layout re-spin so that it fits inside a Ford EEC-IV case. Ford specific interfaces to ignition and sensors to be added.

* (add new projects here)

----

= New project suggestions =

* Host softwares compatible with several boards (Alexei)

----

= Useful pages =

* AfreshBoard (obsolete): WBO2, EGT, knock

* CanBus

* GenBoard/Autotune : VE autotune

* GenBoard/Firmware : firmware structure and related page pointers

* MegaTune and MegaTunix

----

Under construction ...

The contents bellow will likely move to the EFI project related pages. Please don't modify for the moment, unless you find a proper name for the new project, or the proper place in started projects

Actually, with a new MCU it makes sense to design the most complex system first. That would mean a GenBoard/VerThree -like board. At a very minimum, the processor-pin mappings need to be assigned (continue ArmProcessorSubsitution ), so the firmware development will not tangle. Remember, we don't use an operating system that hides/abstracts HW from software, so mixing/swapping the IO-pin usage between boards is possible, but not recommended.

----

Guidelines

* smart I/O chip: dropped (no dedicated uC for output timing)

* DPAK FET

* bipolar stepper driver

* PDTC ... digital NPN

* ULN2803

* DROPPED: TPIC6A259DW (only allowed on v3.x)

* DROPPED: 1-wire GPIO

* 74AHCT132PW for controlling logic level FETs

* Atmel Mega88-s will be used extensively.

* main ADC choice is still the Microchip MCP3208