[help needed] rusEfi Use Scenarios for Next Hardware Iteration
- AndreyB
- Site Admin
- Posts: 14381
- 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
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?
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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: rusEfi Use Scenarios for Next Hardware Iteration
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.
Re: rusEfi Use Scenarios for Next Hardware Iteration
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.
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.
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
- AndreyB
- Site Admin
- Posts: 14381
- 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
We just had a great chat at https://rusefi.slack.com/messages/C4Y7HA6NM/details/ and we now have https://rusefi.com/forum/viewtopic.php?f=4&t=1473 and https://github.com/rusefi/hw_imolaboard
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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
-
- running engine in first post
- Posts: 1495
- Joined: Mon Jan 30, 2017 2:05 am
- Location: Seattle-ish
Re: rusEfi Use Scenarios for Next Hardware Iteration
That makes it hard to use the same common board with multiple vehicle adapters if they're permanently soldered together...
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.
Re: rusEfi Use Scenarios for Next Hardware Iteration
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
Re: rusEfi Use Scenarios for Next Hardware Iteration
If you use the 154 Pin that most later Bosch have, the cases are more ideal.kb1gtt wrote: ↑Tue Jan 01, 2019 12:36 pmThis 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.
The pcb is then 165 x 130
Re: rusEfi Use Scenarios for Next Hardware Iteration
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.
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.
Re: rusEfi Use Scenarios for Next Hardware Iteration
I think long-term fuel trim should be stored in non-volatile memory. SRAM would be for logged error codes etc.
-
- running engine in first post
- Posts: 1495
- Joined: Mon Jan 30, 2017 2:05 am
- Location: Seattle-ish
Re: rusEfi Use Scenarios for Next Hardware Iteration
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.
Re: rusEfi Use Scenarios for Next Hardware Iteration
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.
Flash is a big no as it stops code execution while writing/erasing, and uses 1k sectors minimum.
Re: rusEfi Use Scenarios for Next Hardware Iteration
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
- AndreyB
- Site Admin
- Posts: 14381
- 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
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
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: rusEfi Use Scenarios for Next Hardware Iteration
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.
-
- running engine in first post
- Posts: 1495
- Joined: Mon Jan 30, 2017 2:05 am
- Location: Seattle-ish
Re: rusEfi Use Scenarios for Next Hardware Iteration
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.