[help needed] rusEfi Use Scenarios for Next Hardware Iteration

Hardware inside and outside of the ECU
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 »

I am afraid to discuss this top to bottom since I am afraid that we will fall into analysis paralysis.

I would prefer to discuss this bottom to top and to try to actually achieve at least something, I also believe that slack is better than forum and phone is better than slack.

A bottom to top approach would be finding out who has how many hours to spend on doing things in the next 30, 60 and 180 days :)

My 30 day plan: gather more info on OEM cases, I am still looking for a huge 121 pin case. At the moment 121 cases I've seen are either short or shallow, I would like a square and deep OEM 121 pin case.

I've ordered some double row angle male and female pins and headers - ETA 21 days - it would be easier to just lay things in real empty cases. I plan a junk yard to expand my cases collection.

I am not sure about CPU right on the board in first iteration. While I agree that eventually CPU should be on the main board, I would like to suggest agile hardware development and start by using some brain board. Probably not discovery, maybe "Core 407V STM32F407VET6 NRF2401 Interface Development Mainboard Module Kit" board from eBay

I am not even sure if we have any people working to collaborate or are we just discussing what we would ask Jared to implement Single-handedly?

Have we agreed to use KiCad? Have we agreed to use KiCad 4 and not KiCad 5?
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 »

mck1117 wrote:
Mon Dec 31, 2018 8:18 pm
I guess it doesn't really matter either way. It will probably come down to space constraints as well a actual power supply design. If an integrated supply is used, I can't see it being particularly complicated to lay out in either location.
I guess it doesn't really matter either way. It will probably come down to space constraints as well a actual power supply design. If an integrated supply is used, I can't see it being particularly complicated to lay out in either location.
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 »

How about the generic ECU uses that 90 degree header which @ has noted, but instead of pressing into a mating connector, solder the part of the connector that hangs over the edge of the PCB. The ECU adapter PCB can likely fit between the row's. Then solder top and bottom to make a good low ohms connection. The limitations in the headers is mostly because of the mechanical connection between the pins and the socket. That connection gets much better if you solder it. Via's could be used to gain mechanical strength of the soldered pads.
PCB_header_edge_connector.png
PCB_header_edge_connector.png (7.51 KiB) Viewed 10621 times

I found the 9-146308-0 a kind of pricey gold plated connectors from TE.
https://www.te.com/commerce/DocumentDelivery/DDEController?Action=srchrtrv&DocNm=1307819_AMPMODU&DocType=DS&DocLang=EN
Page 105, tells me technical data is on page 276, which then tells me to look for
-- Technical document
108-16 ACTION PIN Contacts
108-25026 AMPMODU Mod. II Inter
-- Application specification
114-25028 ACTION PIN Contacts with TE Headers, Application
114-13011 AMPMODU .025 and .045 Square Continuous Posts
-- Instruction sheet's
408-2636 ACTION PIN Contact Rear Insertion/Extraction Tool 265871-7
408-6944 TE Uninsulated Bandolier Post Insertion Tool 91419-1
408-7977 AMPMODU Double Row, Straight Posts, End Shrouds .100 x .100 [0.64 x 0.64] Centers
408-7878 AMPMODU Header Barrier Inserts
408-9054 ACTION PIN Contact Headers Seating Tool, 91170 Series
408-9707 Tool Kit 314818-1 for Breakaway Headers

I can't seem to figure out how to get those on the interwebs, so I guess it's time to call TE and see if those are on demand documents.

The use of multiple pins in an attempt to get more amps is a sub par idea. There are many issues which happen when you attempt that approach.

About spacing the current carrying pins, alternating GND, that's OK. Basically every pin should be able to carry the full load. Spacing them out to spread the heat and help keep the connector colder is and OK thing to do.
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 »

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 »

kb1gtt wrote:
Tue Jan 01, 2019 1:56 am
solder the part of the connector that hangs over the edge of the PCB
That makes it hard to use the same common board with multiple vehicle adapters if they're permanently soldered together...
kb1gtt wrote:
Tue Jan 01, 2019 1:56 am
The use of multiple pins in an attempt to get more amps is a sub par idea. There are many issues which happen when you attempt that approach.
Then why do OEMs do it? I had a peek inside the GM ecu for my LS, and it has ~4 12V in pins, all tied together inside the case, that all go to the same fuse in the fusebox with their own 18ga wires.
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 »

mck1117 wrote:
Tue Jan 01, 2019 5:21 am
Then why do OEMs do it? I had a peek inside the GM ecu for my LS, and it has ~4 12V in pins, all tied together inside the case, that all go to the same fuse in the fusebox with their own 18ga wires.
This can depend on the design. AKA if one pin can handle the load, the extra's are for redundancy purposes. AKA MTBF calculations can some time obtain the desire results with redundancy of components. As well with 18AWG wire, it's likely that one pin could handle the load. I would need to see the connector and general circuit setup to know why they might have considered it to be OK. I do not expect such a design from major OEM's as this kind of design is costly for them, and keeping unit costs as low as possible in high production quantities is critical for them. We are considering it for low production, where pennies on the design are traded to minimize labor hours in the development cycle.

Is the goal of the connector to allow people to purchase one primary ECU and re-use it as they change to different car's? I was thinking the goal was to allow bulk building of the primary board, then allow them to purchase that board with an adapter board. I was thinking the goal was to allow easier PnP's to exist. I guess both goals could exist.

We should write down a list of goals some where.
Welcome to the friendlier side of internet crazy :)
960
contributor
contributor
Posts: 336
Joined: Mon Dec 10, 2018 1:22 am
Location: Norway

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by 960 »

kb1gtt wrote:
Tue Jan 01, 2019 12:36 pm
mck1117 wrote:
Tue Jan 01, 2019 5:21 am
Then why do OEMs do it? I had a peek inside the GM ecu for my LS, and it has ~4 12V in pins, all tied together inside the case, that all go to the same fuse in the fusebox with their own 18ga wires.
This can depend on the design. AKA if one pin can handle the load, the extra's are for redundancy purposes. AKA MTBF calculations can some time obtain the desire results with redundancy of components. As well with 18AWG wire, it's likely that one pin could handle the load. I would need to see the connector and general circuit setup to know why they might have considered it to be OK. I do not expect such a design from major OEM's as this kind of design is costly for them, and keeping unit costs as low as possible in high production quantities is critical for them. We are considering it for low production, where pennies on the design are traded to minimize labor hours in the development cycle.

Is the goal of the connector to allow people to purchase one primary ECU and re-use it as they change to different car's? I was thinking the goal was to allow bulk building of the primary board, then allow them to purchase that board with an adapter board. I was thinking the goal was to allow easier PnP's to exist. I guess both goals could exist.

We should write down a list of goals some where.
If you use the 154 Pin that most later Bosch have, the cases are more ideal.

The pcb is then 165 x 130
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 »

One more idea: backup power?

There's always constant power available on vehicle connector, let's use this for backup sram/rtc.
We could potentially store some data such as long term fuel trim.
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by stefanst »

mobyfab wrote:
Thu Jan 03, 2019 10:40 pm
One more idea: backup power?

There's always constant power available on vehicle connector, let's use this for backup sram/rtc.
We could potentially store some data such as long term fuel trim.
I think long-term fuel trim should be stored in non-volatile memory. SRAM would be for logged error codes etc.
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 »

stefanst wrote:
Fri Jan 04, 2019 3:17 am
I think long-term fuel trim should be stored in non-volatile memory. SRAM would be for logged error codes etc.
That's a lot of flash writes...

You have to either 1) save periodically, or 2) save at shutdown.

We have a full 4k of backup ram, so might as well use it. A 16x16, uint16 table is only 1k, so you could fit LTFT and only use 25% of the space.
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 »

OEM ECUs do store all of this in backup sram

Flash is a big no as it stops code execution while writing/erasing, and uses 1k sectors minimum.
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:
Fri Jan 04, 2019 10:28 am
Flash is a big no as it stops code execution while writing/erasing, and uses 1k sectors minimum.
Flash and EEPROM also have limited write cycles. You can consume those write cycles very quickly with active writes.
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 »

mobyfab wrote:
Fri Jan 04, 2019 10:28 am
Flash is a big no as it stops code execution while writing/erasing, and uses 1k sectors minimum.
external flash like all many cheap dev boards have now? but that's probably not first revision, let's move forward in phases
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
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: rusEfi Use Scenarios for Next Hardware Iteration

Post by stefanst »

So maybe keep the long-term trim in sram and have a manual option to apply it to the VE values? I guess that would have to be done in TS somehow.
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 »

stefanst wrote:
Fri Jan 04, 2019 2:47 pm
long-term trim in sram and have a manual option to apply it to the VE values
Exactly. LTFT reset with just disconnecting power is quick and easy, and saves the tons and tons of flash write cycles it would take. I don't see a reason to ever store it in flash.

If you want to take the fuel trims in to account in your persistent tune, a button in TS is the way to go.
Post Reply