[help needed] rusEfi Use Scenarios for Next Hardware Iteration

Hardware inside and outside of the ECU
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

rusEfi Use Scenarios for Next Hardware Iteration

Post by mck1117 »

Hi all, there was a lot of overlap and confusion between the "22mm Manhattan" and "lets choose an enclosure" threads, so I'm creating this one to have a single discussion about what the next version of rusEfi's hardware looks like (whether that's one board, a modular set of boards, or something else).

In both threads, we were mixing what scenarios we wanted to enable for the end user, and how to enable those scenarios. Let's decouple those two discussions, and start with the scenarios we want to enable. Once we've decided on scenarios, we can use those to drive direction we take for implementation.

Here's a summary of scenarios I see from the other threads (to be updated from this thread):
  • Some amount of support for both ways to install rusEfi in your car:
    1. Plug-n-Play: I can connect some rusEfi solution to the factory wiring harness in my car, mostly unmodified, put the key in, and start the car.
    2. "Racer" or non-Plug-n-Play: rusEfi uses a connector not necessarily sharing pinout with any particular vehicle (though it may, if that means connector/case availability is good), with the intention of either re-pinning an existing harness, or constructing one from scratch.
  • Support for the diverse existing hardware present on vehicles. Examples could include:
    1. Hall effect vs VR
    2. Analog vs frequency MAF
    3. Stepper vs. PWM (2 and 3 pin) idle control
    4. Direct coil drive (igbt) vs logic-level coil drive
    5. Whatever weird high-power high-side driver the Dodge Neon needs?
    6. Direct injection
    7. Diesel
  • Avoid integrated components. Any component used should be minimal, not powered by magic, and guaranteed to be available in quantity for a long period of time. Generic parts good, specialized parts bad.
  • Development: We must be able to develop new hardware and software features for rusEfi. This means hardware prototyping, and connectivity for hardware and software debugging.
This list is incomplete, and probably wrong. Let's discuss! What do you want out of rusEfi for your vehicles?
User avatar
mobyfab
Posts: 139
Joined: Tue Oct 29, 2013 10:09 am
Location: Versailles, France

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by mobyfab »

it's pretty much in line with my suggestions for the last couple years :)

It might help to use ASICs in the beginning, but their specialised aspect make them expensive and hard to source for individuals. I'm thinking about HIP9011 that can be done in software. (I've done it)
"Smart" VR interfaces (MAX9927) can be replaced with discrete components (peak detectors, comparators...) and timers + software.

We need to talk about the modular (base + I/O) approach. I think it's a mandatory step for PnP and faster iteration.
For racer ECUs, if the modular approach is not possible due to space constraints, we could make a single board that fits into a sealed enclosure such as Cinch ModICE.

Once we get PnP for a few ubiquitous cars, the rate of adoption will increase significantly.
It needs to be easy to install. Tuning is another story.

The way I would go for PnP:
  • Find a proper enclosure that can hold boards large enough, and where OEM connectors fit.
  • Create a base board that contains all the mandatory devices and interfaces, plus a few very common (80%+) circuits.
  • Create multiple I/O boards for each vehicle I want to support
When checking what companies do, I noticed that their base boards contain some extra circuitry, such as low power switches.
I guess they try to put as many devices on the base board as possible to reduce the overall cost, since they are going to produce many more base boards than I/O boards. Maybe only their base boards are assembled on machines. I don't think this approach would benefit us for now since most boards are hand soldered and low volume anyway.
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by mck1117 »

Agree with the above-let's try to stick to just answering these parts:
mobyfab wrote:
Sat Dec 29, 2018 1:21 am
a few very common (80%+) circuits
Let's nail down what these circuits are.
mobyfab wrote:
Sat Dec 29, 2018 1:21 am
each vehicle I want to support
Let's nail down exactly what this requires. What hardware requirements are rare, and which are common.

Figuring out the answer to these questions will determine whether the "a few very common" circuits means 25%, 50%, 80%, or 95%. That answer may change how we design the modularity of the system.
ZHoob2004
contributor
contributor
Posts: 153
Joined: Sun Apr 03, 2016 7:11 pm
Location: Tucson, AZ

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by ZHoob2004 »

In PnP applications, what sorts of OEM features are we planning to support? Do we want to support factory O2 sensors? What about EGR valve? EVAP purge?

I guess what I'm trying to say is, how far do we go? What about features only on some models of a much broader range?
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by AndreyB »

ZHoob2004 wrote:
Sat Dec 29, 2018 4:43 am
Do we want to support factory O2 sensors? What about EGR valve? EVAP purge?
these are bad examples - I believe these features have nothing to do with hardware. factory narrow band 02 sensor is just a universal analog input and EGR and EVAP is probably just a generic low side.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by mck1117 »

Ooh, that's a good question, that's brings up another good one that's sort of the inverse.

Practically zero cars targeted for rusEfi use have factory widebands. And besides, those are the easy case, as they already have wiring for a wideband to the ECU. But for the cars that don't have a wideband in the stock harness, how do we expect a user to add one for tuning? Add another connector for "extra non-pnp" stuff? Put extra hardware on separate boards, connected via (possibly existing) CAN interface?
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by mck1117 »

russian wrote:
Sat Dec 29, 2018 4:57 am
EGR and EVAP is probably just a generic low side.
But not necessarily! And for those cars, do we even care, or leave those disconnected?

If we take the probably acceptable hard stance that we don't support emissions equipment, then it's fine to leave them floating.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by AndreyB »

We already have a "racer" and "mega-board" solution - to the best of my knowledge Frankenso is pretty amazing for custom harness. i believe at the moment the biggest void is PnP boards, finding a way to make 4 more PnP boards which would cover a lot more vehicles is my primary interest at the moment.

I guess the big question is which 4 vehicles to cover :) 121 pin connector is used really widely, is it like the most popular connector at the moment? Between "german" an "asian" keying it covers _a lot_ of cars VAG Mini Kia Lada - https://rusefi.com/wiki/index.php?title=Hardware:OEM_121_pin_connectors

Maybe the most important action item is to do the analysis of how universal are pinouts on as many 121 connector vehicles as possible? Maybe these is a similarity between many of them? Not sure to what extend they were all related or driven by Bosch. And by the way 121 pin is available new pretty cheap.

Anyway, let's assume we need multiple boards, not just one magic 121 pin board. How do we simplify development of multiple PnP boards in parallel? Would the 22mm Manhattan units help?
mck1117 wrote:
Fri Dec 28, 2018 8:49 pm
[*] Avoid integrated components. Any component used should be minimal, not powered by magic, and guaranteed to be available in quantity for a long period of time. Generic parts good, specialized parts bad.
mobyfab wrote:
Sat Dec 29, 2018 1:21 am
It might help to use ASICs in the beginning, but their specialised aspect make them expensive and hard to source for individuals.
I am not sure that I agree. TLE6440 which gives us multiple low-side channels or automotive power supply chip is definitely a better deal comparing with current Frankenso. Yes, there is a risk of loosing availability, but there are two solutions:
1) stock pile on these components :)
2) make it easier to switch from one hard to get component to another hard to get component - i.e. little module boards :)
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
ZHoob2004
contributor
contributor
Posts: 153
Joined: Sun Apr 03, 2016 7:11 pm
Location: Tucson, AZ

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by ZHoob2004 »

russian wrote:
Sat Dec 29, 2018 4:57 am
these are bad examples - I believe these features have nothing to do with hardware. factory narrow band 02 sensor is just a universal analog input and EGR and EVAP is probably just a generic low side.
I don't really mean these examples in particular, the same could be asked about AC control, MIL, or others. I'm trying more to think about how featured do we want a PnP board to be. Should there be enough low side outputs to handle all these, or should only core components be supported, or somewhere in between?

The exact hardware required doesn't really matter so much as whether or not it should be provided in the first place.
mck1117 wrote:
Sat Dec 29, 2018 4:59 am
russian wrote:
Sat Dec 29, 2018 4:57 am
EGR and EVAP is probably just a generic low side.
But not necessarily! And for those cars, do we even care, or leave those disconnected?

If we take the probably acceptable hard stance that we don't support emissions equipment, then it's fine to leave them floating.
The reasonable stance is to leave all emissions pins floating and put a big "for off road use only" sticker on everything, but I'm sure a lot of folks would like to tinker with that, or would like certain emissions systems to function despite driving a modified vehicle (myself included).

Of course, we want to avoid becoming an emissions cheating device, so this may be dangerous ground.

russian wrote:
Sat Dec 29, 2018 5:11 am
I guess the big question is which 4 vehicles to cover :)
Miata is always the answer :)

I'm always an advocate of 90s Hondas, but the community seems to be satisfied with their hondata mod chips so IDK if that's really worth the effort. Same connector as Miata, but different pinout so I believe that would still require a different PnP board or a jumper section like on frankenso.
russian wrote:
Sat Dec 29, 2018 5:11 am
I am not sure that I agree. TLE6440 which gives us multiple low-side channels or automotive power supply chip is definitely a better deal comparing with current Frankenso. Yes, there is a risk of loosing availability, but there are two solutions:
1) stock pile on these components :)
2) make it easier to switch from one hard to get component to another hard to get component - i.e. little module boards :)
I don't think integrated components are such a bad thing, especially if they save time in development/assembly and money in component cost. Downsides are discontinuation and incompatibility with some cases.

Modular construction provides a good solution to these, but likely does so with an increase in cost and time.

What about doing some/all these modules like the integrated stm on frankenso? Design for a compact, integrated solution, but break out all relevant pins so a new module can replace it if desired.
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by mck1117 »

I think if that VAG ECU case/connector are truly widely available, it could be a great option as the "racer" ECU solution. So that might hit two birds with one stone, but it still leaves everybody else out.

I'm a fan of the AEM Series 2 style layout. A common board has the processor, power supply, and some amount of common hardware that we decide that "everyone" or at least "most" people need. Using a 0.1" header (or similar), that plugs in to a board that could do as little as carry the connector to the car, or could do as much as add any vehicle-specific hardware required for that particular engine. If you have a basic car with not much interesting hardware and not many cylinders (think my Volvo 240, BMW e30, NA Miata, etc), the bottom board might be just wires. If you wanted to drive a quad-vvt, etb, sequential fire V8, it might be pretty busy. One or all of the adapter boards could have a prototyping area, with unused harness pins and interconnect pins available for development and custom extra hardware.
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by mck1117 »

ZHoob2004 wrote:
Sat Dec 29, 2018 8:25 am

The exact hardware required doesn't really matter so much as whether or not it should be provided in the first place.
Yes--this point is exactly why I started the thread. If we want to do anything at all in the realm of PnP hardware, we need a philosophy about what kinds of things we support, and what kinds of things we do not. Exactly what those are for some car doesn't matter, unless we use that as data to drive the top-down philosophy.
ZHoob2004 wrote:
Sat Dec 29, 2018 8:25 am

I don't really mean these examples in particular, the same could be asked about AC control, MIL, or others. I'm trying more to think about how featured do we want a PnP board to be. Should there be enough low side outputs to handle all these, or should only core components be supported, or somewhere in between?
Where I was starting to head in my previous post is this architecture:
  • A "common hardware board" with processor, power supply, analog inputs, CAN, and a "sensible" base set of outputs. Maybe 8 low side drivers, 8 hi-low 5v gate driver outputs.
  • That plugs in to a "vehicle application board" which has everything else. ETB, special driver hardware for whatever stuff your car has, idle control, wideband o2 if necessary, prototyping area, IGBT coil drivers, etc. This board also has the car's factory connector, and fits in the factory case.
User avatar
kneelo
Posts: 39
Joined: Sun Jun 10, 2018 6:36 am
Location: Western Australia

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by kneelo »

I think the PnP solution using the factory connector is too hard to achieve for a broad range of cars and would detract from effort that could be used improving or upgrading the base hardware. To my mind having a universal ecu with flexibility in term of features that can be populated and using an using an adapter harness is a simpler approach. Its also a lot easier to support than a large number of vehicle specific configs.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by kb1gtt »

I think cost is a critical consideration which has not been mentioned yet.

For PnP, I think support for all OEM features is desirable, and additional features could be put over CAN or perhaps some kind of RJ45 Ethernet. AKA if your adding wires to you PnP, why would it need to go into the existing harness connector(s)? Also if you add wires, why not use OEM connectors which are likely to have a long life like RJ45 or the industrial M12? They are robust, low cost, weather resistant, etc.

I understand the desire to make a modular PnP board, but I also see negative trades for trying to keep it flexible. The point of PnP is to trade flexibility to get simpler easier to install hardware. It's all about instant gratification. As well a goal of flexible is to keep development costs low. If you can re-spin just one section, you don't have to purchase an entire PCB. That's handy to keep the costs lower as you find bugs. However you're adding labor to every build when you do that. The PnP crowd doesn't want this labor. They are willing to pay an extra couple bucks to avoid this labor.

I agree with Knock in software. I once had a circuit on the o5e board. Hmmm, I think the o5e has fallen victim to bit rot. I couldn't find it in my 1 minute search. If someone created an excel spread sheet which showed the DSP algorithm to @, I'd bet he'd make such an option in software. Right now I think the key reason it has not happened is because @ needs to know how it would work at a very detailed level. I think a spread sheet would be a great way to show exactly how that would work.

I also agree VR with an op-amp instead of the MAX chip is a good goal. The Max chip is expensive and proprietary. We could make something and remove the magic. My concern is that PCB real estate will increase if we roll our own. As well we have a solution, so this is kind of re-inventing the wheel on a project that is already a re-invention of the wheel. While I find it interesting and I desire to learn the low levels, the end users don't really care. They don't really care if they toss an extra $5 and use the MAX chip. However I want to know exactly what is happening under the hood.

I think the modular design in PnP shouldn't be to allow people to solder in different modules, but to allow for a modular PCB designs. Similar to what we tried in Frankenstein. We did a layout where we could change sections. I think PnP should be an assembled by an assembly house, then validated by someone with some kind of test fixture. Then a user snaps it in. Decreasing the assembly house labor is critical in keeping the costs low. If a chip goes obsolete, then you will need to do a re-design of the board. Hopefully you can simply re-do that one section of the board. The goal of modular PCB is to keep labor down. There is upfront NRE in spinning a board, as well as repetitive labor costs. I think there are benefits of moving the modular level to the one time development costs and avoid that kind of labor to the every build level.

ASIC's can be lower cost than one might think. I understand it's common for Universities to do a batch run of ASIC's, similar to how PCB's are batched at OSHPark. If you can find a group which is running a custom batch of ASIC's that can reduce the ASIC costs allot. I understand many foundries also provide generic libraries for things like MOSFET's, and other similar interfacing circuits. It would be cool to run our own ASIC. I'd enjoy doing such a effort.

About what the next rusEFI hardware will look like, that really depends on the PCB developers motivation. With free labor, it's what ever the developer feels like doing. Also it helps when a developer has the hardware. I've developed Frankenso, and I don't have a Miata, or any thing close. Some day I dream of fixing up an old motorcycle. So some day I might get motivated to make a motorcycle ECU. As well my daily driver(s) are FSI 2.0 VW engines. So I might get motivated to do that, if I desired that making it to work is a lower priority goal :)

About a PnP effort, I might suggest using the priority chips for things like fuel injectors, and power supplies. That would make the PCB modules get really small. Then once you have the core modules small, then put it on a PCB edge which matches an existing enclosure, and matches an existing ECU connector. If you change to another ECU, then change the PCB edge cuts and change the ECU connector, but keep the core modules.
Welcome to the friendlier side of internet crazy :)
puff
contributor
contributor
Posts: 2961
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by puff »

From what I've got from other diy-ecu-related forums, using opamps instead of specific chips (MAX or LM) is associated with some difficulties, and it seems there was just one or two persons who succeeded and were happy with their discrete solutions. The rest ended up with choosing one of the dedicated chips.
On the other hand, the reason for this could be the lack of skills and knowledge. This is also proved by my own experience with audio amplifier boards - I made two equal boards (just a few components), and one was working just fine, but the oher one was oscilating, and I never learned why... :D

Never thought that rj45 connectors were designed for automotive use.

Jared, is that you who will be designing the new stacked board? Do you really see the need for the next spin? I'd say that even the first iterations of frankenstein cover the majority of needs. Then, there are several other designs in addiion to Frankenso (andreika, Dron_Gus, some other non-russian-speaking guys).

ASICs is a really interesting domain. But it all boils down to the costs issues (development and manufacturing). I hardly imagine that this batch would be bigger than 100 pieces. Besides, it requires some sort of packaging, which translates into additional costs? What could be the cost of mafacturing for such a batch? $10 per chip? or rather to say $100?

I was against ASICs in a fully-diy project because they are usually hard to obtain, but if rusefi takes all the manufacturing headaches (sourcing parts, envisioning all sorts of circuit protections) then why not - they woud probably help achieve much better density?
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by kb1gtt »

RJ45 weather resistant like the below can be obtained for around $20
http://www.l-com.com/ethernet-category-5e-ip67-rated-dual-use-waterproof-cable-assemblies

Some low cost M12 options are listed below.
5 conductor straight end, pigtail found here for less than $10 https://www.automationdirect.com/adc/shopping/catalog/cables/sensors_-z-_switches/micro_(m12)_normal_duty_q-z-d_cables/5-pole_micro_(m12)_cables/7000-12361-2150300
5 conductor 90 degree end, pigtail found here for less than $10 https://www.automationdirect.com/adc/shopping/catalog/cables/sensors_-z-_switches/micro_(m12)_normal_duty_q-z-d_cables/5-pole_micro_(m12)_cables/7000-12241-2150300
3 conductor straight end, pigtail, 50V 4A found here for $6.25 https://www.automationdirect.com/adc/shopping/catalog/cables/sensors_-z-_switches/micro_(m12)_normal_duty_q-z-d_cables/3-pole_micro_(m12)_cables/7000-12181-2130500

PCB side of M12 5 pin connector found here for $15.32.
https://octopart.com/fk4.5-pcb-turck-1609965?r=sp&s=00nTNlJcRhKw4pGemagmOA

For M12, if you pay more than just the cheapest standard pricing, you can obtain different "coded" cables, which means different keying. As well you can get different pin counts, like this 12 conductor for $35.
https://www.automationdirect.com/adc/shopping/catalog/cables/sensors_-z-_switches/micro_(m12)_normal_duty_q-z-d_cables/12-pole_micro_(m12)_cables/7000-19041-7050300

The more I think about it, the more I think the M12 would be the way to go for purchasable pig tails that you can get 30 years from now. I like purchased cables, with field wire-able options. My primary concern with M12's is keying and cost. They are good quality which makes them cost a bit more than preferred. You can get other coded options, but those are typically not stocked and cost even more. Non-standard keying options are likely to have a 2+ week lead time.

I'm not sure if I'll do the next full board or not. At the moment I'm overloaded, so larger efforts are harder than normal for me. Perhaps in Jan or Feb I'll have some more time. I can do smaller efforts, but a large effort is less likely for the next couple weeks.

I have no idea about the ASIC pricing. However it would be cool, and I've studied is slightly. There are several open sourced / free design tools which can be used to make a design. I've been tempted to encourage my work to do some ASIC's, but I do not know of any low cost foundries in the USA, so it would be a hard effort.
Welcome to the friendlier side of internet crazy :)
User avatar
mobyfab
Posts: 139
Joined: Tue Oct 29, 2013 10:09 am
Location: Versailles, France

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by mobyfab »

kneelo wrote:
Sat Dec 29, 2018 10:42 am
I think the PnP solution using the factory connector is too hard to achieve for a broad range of cars and would detract from effort that could be used improving or upgrading the base hardware. To my mind having a universal ecu with flexibility in term of features that can be populated and using an using an adapter harness is a simpler approach. Its also a lot easier to support than a large number of vehicle specific configs.
I think it's the complete opposite, PnP is the best solution for the majority of users. It's really not that hard to implement.
Most users want to use the ECU, not build it.
puff wrote:
Sat Dec 29, 2018 2:12 pm
Never thought that rj45 connectors were designed for automotive use.
They are not.

For external interfaces, we better stick with standard buses such as CAN and far away from fancy stuff like RJ45 or fiber optic. It's for cars, not planes.
mck1117 wrote:
Sat Dec 29, 2018 8:44 am
Where I was starting to head in my previous post is this architecture:
  • A "common hardware board" with processor, power supply, analog inputs, CAN, and a "sensible" base set of outputs. Maybe 8 low side drivers, 8 hi-low 5v gate driver outputs.
  • That plugs in to a "vehicle application board" which has everything else. ETB, special driver hardware for whatever stuff your car has, idle control, wideband o2 if necessary, prototyping area, IGBT coil drivers, etc. This board also has the car's factory connector, and fits in the factory case.
Fully agreed

Let's keep it as simple as possible for now, we can iterate and improve later on.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by AndreyB »

mobyfab wrote:
Sun Dec 30, 2018 1:58 pm
mck1117 wrote:
Sat Dec 29, 2018 8:44 am
Where I was starting to head in my previous post is this architecture:
  • A "common hardware board" with processor, power supply, analog inputs, CAN, and a "sensible" base set of outputs. Maybe 8 low side drivers, 8 hi-low 5v gate driver outputs.
  • That plugs in to a "vehicle application board" which has everything else. ETB, special driver hardware for whatever stuff your car has, idle control, wideband o2 if necessary, prototyping area, IGBT coil drivers, etc. This board also has the car's factory connector, and fits in the factory case.
Fully agreed

Let's keep it as simple as possible for now, we can iterate and improve later on.
Q1: is it going to use the shown kind of connector?
Q2: what is this kind of connector called and how many amps does it handle?

I guess it helps to know that at least some aftermarket units are using this approach.

I think we have three or four people generally agreeing on this approach.

Q3: what do we call "common hardware board"?

Q4: is anyone available and interested to do actual work? :) What is going to be our process for this actual work?
Attachments
image.png
image.png (134.34 KiB) Viewed 27171 times
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by kb1gtt »

russian wrote:
Sun Dec 30, 2018 2:59 pm
Q2: what is this kind of connector called and how many amps does it handle?
I think that is referencing SuperSeal mentioned in this other thread. I posted a cost break down at this link.
https://rusefi.com/forum/viewtopic.php?f=4&t=464&start=73

Above I suggest M12's, which are more costly, but widely used in many markets for many applications. So there are many sources of these pre-made cables out there. AKA no crimp tools, and easy to get replacement cables. In OEM high production applications, M12's are not OK as they simply cost to much.

Super Seal is around $0.80 to $1.00 usd per connection. You need to get a crimp tool, as pre-made cables are hard to find.
M12 is around $2 to $5 usd per connection. You can likely find pig tails, and there are many pre-made wiring options. No crimp tool required.
Welcome to the friendlier side of internet crazy :)
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by AndreyB »

russian wrote:
Sun Dec 30, 2018 2:59 pm
Q2: what is this kind of connector called and how many amps does it handle?
Image
what is this kind of connector called and how many amps does it handle?

for the purposes of "common hardware board" project which needs a name we do not care for external connector. I wonder how much you agree with the angle double row header interconnect like pictured here.

Shall we call this Frankcommon? Frankcom? Frankbase? Frankboard?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by AndreyB »

Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
mobyfab
Posts: 139
Joined: Tue Oct 29, 2013 10:09 am
Location: Versailles, France

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by mobyfab »

russian wrote:
Sun Dec 30, 2018 4:04 pm
russian wrote:
Sun Dec 30, 2018 2:59 pm
Q2: what is this kind of connector called and how many amps does it handle?
Image
what is this kind of connector called and how many amps does it handle?
That's a standard right angle 0.1" pin header. It can handle 3 amp per pin continuously.
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by mck1117 »

kb1gtt wrote:
Sun Dec 30, 2018 3:35 pm
I think that is referencing SuperSeal mentioned in this other thread. I posted a cost break down at this link.
No, I was talking about a connector between the "common" and "plug-n-play" halves of the solution, inside the ECU case.
mobyfab wrote:
Sun Dec 30, 2018 7:07 pm
That's a standard right angle 0.1" pin header. It can handle 3 amp per pin continuously.
And as evidenced by other ECU solutions, I think they have plenty of capacity for anything up to and including injector channels.

We should decide whether we use right angle pins, or straight pins. If we stack boards on top of each other, we save space in-plane, but make the stack ~3/4" thick. If we put the boards next to each other, it lets the package be around half the thickness, but might require more area.

Thinking about it, we could actually design it pretty easily to support both. If we put a dual-row 0.1" header at the edge of the common board, it could have either form factor pins installed.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by AndreyB »

mck1117 wrote:
Sun Dec 30, 2018 8:09 pm
Thinking about it, we could actually design it pretty easily to support both. If we put a dual-row 0.1" header at the edge of the common board, it could have either form factor pins installed.
I believe angle pins would work great but yes, we can kind of support both.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by mck1117 »

russian wrote:
Sun Dec 30, 2018 11:50 pm
I believe angle pins would work great but yes, we can kind of support both.
Agreed-most OEM ECU cases are large and flat, not short and thick.
User avatar
mobyfab
Posts: 139
Joined: Tue Oct 29, 2013 10:09 am
Location: Versailles, France

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by mobyfab »

AEM (and some others) use straight pin headers on the edge of the boards, using both layers.
With the average width of an ECU, this gives use many, many pins (100+) to play with.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by kb1gtt »

mobyfab wrote:
Sun Dec 30, 2018 7:07 pm
That's a standard right angle 0.1" pin header. It can handle 3 amp per pin continuously.
I don't think there is a clear answer. A connector rating depends on many factors. Gold plated vs tin plated, inductive loads vs restive loads, the pin spacing. Do all pins carry full amps, or do just some pins carry full amps, the ambient temperatures, number of insertions, and resistance to long term encroaching corrosion. These things all play a roll in how well a connector preforms. I recall TE has some datasheet which show environmental testing. They do vibration, salt spray, all sorts of testing. I'm seeing if I can find that datasheet again. From memory, I recall 0.5A was generally good for most situations, then 1A is likely for resistor loads, and under some very specific conditions you could get higher.

This 3M socket connector notes some data. I recall one from TE which was much more detailed. This one with gold plated contacts, it's rated for about 3 to 4 amps with only one pin powered. However with 6 pins powered your down to a max of about 1.5A at 85C ambient. With more powered pins, your closer to 1A maximum. That's a thermal limit. If you have done multiple insertions, used TIN coated instead of gold coated, or had some small corrosion, the contact resistance goes up, that rating decreases from this point. This amps rating is based on temperature rise, if your connection makes more ohms than when you first made the connection, it will generate more heat. I genreally aim for 10C rise on PCB traces, this datasheet was 30C rise.
http://multimedia.3m.com/mws/media/787866O/3mtm-idc-ribbon-cable-socket-891-series.pdf

Also when dealing with inductive loads, a connection of 0.1 ohms to 0.01 ohms commonly makes a tank circuit, which causes high voltage spikes in the inductor. With inductive loads you need to pay close attention to the contact resistance.
Welcome to the friendlier side of internet crazy :)
User avatar
mobyfab
Posts: 139
Joined: Tue Oct 29, 2013 10:09 am
Location: Versailles, France

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by mobyfab »

Very useful info :)

I guess we'd just have to put some space between the pins that will carry > 1A.
Most pins will only be for signal anyway.

For inductive loads we can simply use more than one pin if needed (but I doubt that would make any difference for most things)
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by mck1117 »

So that probably means that signal pins get a single pin, 12v power input gets a pair, 5v power output gets a pair (at least), injector drivers get 1 or 2, and the remainder grounds.

Something like:
GND - signal - GND - injector - GND - signal - GND - injector - etc
Would probably let you get away with a full amp on the injector pin. Also gets the noisy inductive channels far away from potentially noise-sensitive signals.

I guess we need to figure out what belongs on the to-be-named brain board, and what belongs on the vehicle adapters.

Here's a rough start:
  • Stuff that should be on the common board:
    • CPU
    • 12v->5v power supply, 5v->3.3v power supply
    • Debug/tuning interfaces
    • Analog inputs
    • A few low-side drivers (4? 6? how many?)
    • A few 5v high/low drivers (4? 6? 8?). Used to drive external coil drivers, IGBTs on vehicle adapter board, or other misc hardware.
    • Knock sense (this could mean hip9011, use the main CPU, or an stm32f3 second cpu)
  • Stuff that explicitly should NOT be on the common board:
    • Crank/cam inputs. There's a lot of diversity here (ahem Subaru) about what works, in addition to differing needs about how many inputs are necessary. 1-5 is the possible number you could need, with varying mixes of VR and hall.
    • IGBT coil drivers
    • Other high-power hardware: ETB, O2 sensors, alternator control, idle control (stepper or otherwise)
Aside: we should try to keep the common board under 10x10cm, as that's the upper limit for the cheapest tier of most pcb proto services :D At Elecrow if both dimensions are <=100mm, it's $4.49 per board, and at 101mm it jumps to $6.85 at MOQ of 10.
ZHoob2004
contributor
contributor
Posts: 153
Joined: Sun Apr 03, 2016 7:11 pm
Location: Tucson, AZ

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by ZHoob2004 »

mck1117 wrote:
Mon Dec 31, 2018 7:55 pm
  • Stuff that should be on the common board:
    • 12v->5v power supply
Should the 12v power supply really be on the common board? Is there anything that needs 12v on that board?
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by mck1117 »

ZHoob2004 wrote:
Mon Dec 31, 2018 8:14 pm
mck1117 wrote:
Mon Dec 31, 2018 7:55 pm
  • Stuff that should be on the common board:
    • 12v->5v power supply
Should the 12v power supply really be on the common board? Is there anything that needs 12v on that board?
Other than battery voltage sensing, no. However, it seems silly to re-layout the power supply for every vehicle adapter. The 12v->5v has the same requirements in every vehicle out there, and doesn't require too much area.
Post Reply