1986 Ford Mustang 5.0 EFI swap

Your chance to introduce yourself and your vehicle
wstefan20
Posts: 111
Joined: Thu Dec 10, 2020 4:00 pm
Github Username: wstefan20

Re: 1986 Ford Mustang 5.0 EFI swap

Post by wstefan20 »

Well turns out most of those hall effect sensors still run at 5V so I should be good to run it at 5V instead of 12V and not worry about voltage dividers etc.

As far as the voltage conversion for the 12V signals. I'm assuming I can get away with a voltage divider circuit with some TVS diodes and maybe a filter capacitor?

As long as the high output will work as PWM (I'm sure it should be quick enough) then that problem is solved.

I found out the neutral safety switch pin actually supplies 5V and the switch connects it to ground so I should be able to use a regular pin for this just fine. For the automatic cars this is a start pin and I can use a voltage divider to an input pin and just use a manual jumper to select the function of that pin.

I'll update the planned pinout and make a schematic of the wiring and post it, then I can finally start mapping out the 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: 1986 Ford Mustang 5.0 EFI swap

Post by mck1117 »

wstefan20 wrote:
Fri Jan 01, 2021 5:56 am
As far as the voltage conversion for the 12V signals. I'm assuming I can get away with a voltage divider circuit with some TVS diodes and maybe a filter capacitor?
you mean for 12v input signals? The digital and analog inputs on Proteus are already tolerant of at least +-24v indefinitely without damage.
wstefan20
Posts: 111
Joined: Thu Dec 10, 2020 4:00 pm
Github Username: wstefan20

Re: 1986 Ford Mustang 5.0 EFI swap

Post by wstefan20 »

mck1117 wrote:
Fri Jan 01, 2021 10:03 am
you mean for 12v input signals? The digital and analog inputs on Proteus are already tolerant of at least +-24v indefinitely without damage.
Wow! Well that shows my familiarity with this system! :lol: I saw the 5V supply to the op amp circuit and assumed it was 5V limited. Guess I didn't look hard enough at the circuit. Geesh! Guess I need more coffee! Well that's perfect! Thank you!

Is the rise time quick enough on the high side outputs to produce a 12V PIP square wave signal? I'm assuming so but figured I'd ask.
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: 1986 Ford Mustang 5.0 EFI swap

Post by AndreyB »

mk e wrote:
Thu Dec 31, 2020 10:30 pm
My strong and last advice get an old ECU to steal the connector off, wire it to a a proteus and get the car running. Actually see what everything is and does, what you like, what you feel you're missing, then, and only then, pick up your p&p project again.
+5

60 pin breakout is open source https://github.com/rusefi/rusefi/tree/master/hardware/Breakout_60pin_EEC-IV-Connector also available on eBay

David has just sent https://github.com/rusefi/rusefi/tree/master/hardware/Breakout_104pin_EEC-V-Connector to bad that one not yet on eBay

Please remember that you have to be careful with stm32 pinout, ideally use 100% Proteus pinout.

I have limited time to support https://github.com/rusefi/rusefi/wiki/Hardware#q-this-is-all-very-cool-but-you-guys-do-not-have-a-plugplay-for-my-trabant-i-think-i-will-go-and-make-a-new-rusefi-board-just-for-my-trabant

Matt is the good cop in this show but he is probably a human as well and his energy has some boundaries somewhere.

Tl,DR: please modify Proteus schematics for you PnP application if you have a PCB itch.
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
wstefan20
Posts: 111
Joined: Thu Dec 10, 2020 4:00 pm
Github Username: wstefan20

Re: 1986 Ford Mustang 5.0 EFI swap

Post by wstefan20 »

AndreyB wrote:
Fri Jan 01, 2021 4:22 pm
60 pin breakout is open source https://github.com/rusefi/rusefi/tree/master/hardware/Breakout_60pin_EEC-IV-Connector also available on eBay

David has just sent https://github.com/rusefi/rusefi/tree/master/hardware/Breakout_104pin_EEC-V-Connector to bad that one not yet on eBay

Please remember that you have to be careful with stm32 pinout, ideally use 100% Proteus pinout.

I have limited time to support https://github.com/rusefi/rusefi/wiki/Hardware#q-this-is-all-very-cool-but-you-guys-do-not-have-a-plugplay-for-my-trabant-i-think-i-will-go-and-make-a-new-rusefi-board-just-for-my-trabant

Matt is the good cop in this show but he is probably a human as well and his energy has some boundaries somewhere.

Tl,DR: please modify Proteus schematics for you PnP application if you have a PCB itch.
AndreyB thanks for all the help. I manage another project like this but for open source system control boards so I completely get where you're coming from, and yes, I did read the harware sticky forum.

The reason I'm wanting to design a plug and play is because of a need in the mustang community. Simply put, when doing a top swap, you've only got a handful of options. They no-longer produce the stock EEC for manual foxbody cars and used they sell for $300+ and what little "tuning" available for them is pretty much garbage. I don't know about most but I wouldn't pay $300 for a 30 year old circuit with no expansion ability. There is an aftermarket plug-and-play controller for the foxbody, but it retails for $840 which is out of the price range for most diyers. My goal here is to provide something affordable, stock, and has features that rival other available controllers.

Personally, I do not even consider a breakout board an option. The time and attention needed to hand-solder 60 jumpers crossing like spaghetti is way beyond most diyers, and is in my opinion, harder than just making a custom harness. Sure, a custom harness would address the complexity concerns to the diyer, but again would drive the price way up and I used to do custom swap harnesses and in my experience is a headache unless you make them from scratch brand new which is even more expensive.

My other reasoning is that I DO have quite a lot of experience with electronics and I know I can help on the dev side once I get up to speed. I am not the greatest, but I am comfortable coding in C and C++ for microcontrollers.

If I haven't made this clear before, I FULLY intend on using Proteus as is. That is to say, I will be removing the circuitry not needed for my application and re-routing everything, but physically the schematic of how the pins are assigned and connected will be IDENTICAL.

I have a re-flow oven and have hand assembled dozens of PCBs just as complex if not more than this one so I am not concerned about my abilities to tackle this project.

If I have seemed uninformed and hesitant, it is simply because I make sure I understand everything 100% and plan accordingly before I proceed on any project. I've learned the hard way that making assumptions is a great way to start a doomed project.

Again, none of this is to brag on my own abilities because I can see I have much to learn, and I appreciate everyone's advice and help. This is simply to assuage any doubts in my abilities, commitment, or general sanity. :lol:
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: 1986 Ford Mustang 5.0 EFI swap

Post by AndreyB »

it is my blunt opinion that you are not in the position to design a manageable, supportable and fabricateable board. if you want to collaborate for a nice mustang board you shall join slack and maybe call me other the phone.
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
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: 1986 Ford Mustang 5.0 EFI swap

Post by mk e »

wstefan20 wrote:
Fri Jan 01, 2021 5:41 pm


Personally, I do not even consider a breakout board an option. The time and attention needed to hand-solder 60 jumpers crossing like spaghetti is way beyond most diyers, and is in my opinion, harder than just making a custom harness.
It's not for anyone but you....it is a development tool. It lets you easily change configurations and play with options until you are happy. At the same time it allows you to become family with the entire system, the entire WORKING system on a WORKING car. It also lets you show off what the product would be on a running car to get feedback from the potential market place with very little investment in time or money. Its about starting at the beginning rather than trying to jump to the end. Worst that happen on this path is you're buddy's car is up and running as quickly and cheaply as possible and you realize the target market doesn't exist. Best case is you're buddy's car is up and running as quickly and cheaply as possible and serves as a marketing and development tool as you can just plug you're new board in, load the tune and know it should work and you can always resell the working proteus once you're done testing with it.

There is no down side. It is both project risk management 101 and project acceleration methods 101. It is hands down the best path, its just not what you WANT hear....but it is the right thing to do.
wstefan20
Posts: 111
Joined: Thu Dec 10, 2020 4:00 pm
Github Username: wstefan20

Re: 1986 Ford Mustang 5.0 EFI swap

Post by wstefan20 »

mck1117 wrote:
Fri Jan 01, 2021 10:03 am
you mean for 12v input signals? The digital and analog inputs on Proteus are already tolerant of at least +-24v indefinitely without damage.
Sorry for re-visiting this. I think I might be overlooking something simple so my apologies if this is my stupidity. In the below circuit it appears this connects directly from the connector all the way to the STM microcontroller.

Image

There's a few pull-down resistors (470k), current limiting resistors (10k), filtering capacitors (100nF), some TVS diodes, then a voltage follower (buffer if you will) and then a voltage divider. The MCP6004 chip is clearly only rated for 5V and this makes sense because the voltage divider takes a 5V signal and steps it to around 3.2V which is the limit on the microcontroller pins.

From this it appears that all the analog pins are 5V not 12V inputs unless there's another part of the schematic I'm not seeing.

As for the digital circuit shown below, it appears this is from direct input to controller.

Image

There's a pullup resistor (2.2k), current limiting resistor (3.3k), filtering capacitors (1nF) and then through a buffer and straight into the controller which doesn't make sense because it's 5V (above the range of that pin for the controller).

I must be missing something here....
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: 1986 Ford Mustang 5.0 EFI swap

Post by AndreyB »

mk e wrote:
Fri Jan 01, 2021 6:44 pm
It's not for anyone but you....it is a development tool...
Mark, those two paragraphs should be engraved in gold with a few other quotes of yours. That's now part of https://github.com/rusefi/rusefi/wiki/HOWTO-Make-a-PnP-board
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
wstefan20
Posts: 111
Joined: Thu Dec 10, 2020 4:00 pm
Github Username: wstefan20

Re: 1986 Ford Mustang 5.0 EFI swap

Post by wstefan20 »

mk e wrote:
Fri Jan 01, 2021 6:44 pm
It's not for anyone but you....it is a development tool. It lets you easily change configurations and play with options until you are happy. At the same time it allows you to become family with the entire system, the entire WORKING system on a WORKING car. It also lets you show off what the product would be on a running car to get feedback from the potential market place with very little investment in time or money. Its about starting at the beginning rather than trying to jump to the end. Worst that happen on this path is you're buddy's car is up and running as quickly and cheaply as possible and you realize the target market doesn't exist. Best case is you're buddy's car is up and running as quickly and cheaply as possible and serves as a marketing and development tool as you can just plug you're new board in, load the tune and know it should work and you can always resell the working proteus once you're done testing with it.

There is no down side. It is both project risk management 101 and project acceleration methods 101. It is hands down the best path, its just not what you WANT hear....but it is the right thing to do.
Ok. I think we had a miscommunication. when I said I don't consider a breakout board an option, I was referring to production. As a dev tool, you are completely correct, it is definitely a completely viable way to do things so we agree here.

I guess the difference in my mind is that I am not really trying to make a whole new system or even improve upon Proteus. If that were the case, I 100% agree, the dev board method would make infinitely more sense.

Since all I will really be doing is re-arranging traces on a PCB I see no need to do a dev board as long as I know what my traces will be connecting to.

Also, I never intended this to be a product I would sell. This is because my re-work is a far cry from being a "new-product" and that's not fair to the maker of Proteus. If he wanted to sell these, I'd be fine with that, and if he was ok with it, I wouldn't mind working a deal out for small batches and having me assemble or something, but that's way way off in the future.

Also, the available pins are pretty limited so if I were to make a dev board it would be squabbling about maybe 4 pins so unless I mess up planning the pins royally it shouldn't matter.

All my difference of opinion is is that the benefits of a dev board (in this specific case) are outweighed in my opinion. Again, this would be different if this was anything more than re-wiring.
wstefan20
Posts: 111
Joined: Thu Dec 10, 2020 4:00 pm
Github Username: wstefan20

Re: 1986 Ford Mustang 5.0 EFI swap

Post by wstefan20 »

AndreyB wrote:
Fri Jan 01, 2021 7:00 pm
Mark, those two paragraphs should be engraved in gold with a few other quotes of yours. That's now part of https://github.com/rusefi/rusefi/wiki/HOWTO-Make-a-PnP-board
Ok.... I get it. Please see my prior post before burning me at the stake. I believe my reasons are valid. Whether you agree with them or not is up to you. As a dev on other platforms, if I had a penny for the number of people who didn't listen to advice like this and failed, I'd be rich. I know that nothing I say will change your mind that I am not one of these so I simply and humbly ask you for the chance to fail and a little help and support is all I ask for.

If I am wrong, I am humble enough to eat my words. Until then, can we please agree to disagree and instead of telling me why this won't work and how to do it differently, maybe we can move forward on this?
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: 1986 Ford Mustang 5.0 EFI swap

Post by AndreyB »

I have no resources or motivation to burn anyone. You have my full moral and limited technical support.

If you are interested to give back to the community please consider following as many of the best practices as you personally find reasonable.

Please consider documenting the pinout in a reusable modifiable text form, not a read-only image form. Similar to any of the https://github.com/rusefi/rusefi/wiki/Vault-of-Pnp-Vehicle-Pages pages.

Please consider using https://github.com/rusefi/rusefi/wiki/Vehicle-Page-Template as a template
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
wstefan20
Posts: 111
Joined: Thu Dec 10, 2020 4:00 pm
Github Username: wstefan20

Re: 1986 Ford Mustang 5.0 EFI swap

Post by wstefan20 »

AndreyB wrote:
Fri Jan 01, 2021 7:54 pm
I have no resources or motivation to burn anyone. You have my full moral and limited technical support.

If you are interested to give back to the community please consider following as many of the best practices as you personally find reasonable.

Please consider documenting the pinout in a reusable modifiable text form, not a read-only image form. Similar to any of the https://github.com/rusefi/rusefi/wiki/Vault-of-Pnp-Vehicle-Pages pages.

Please consider using https://github.com/rusefi/rusefi/wiki/Vehicle-Page-Template as a template
Thanks! I didn't see this in the wiki before. I'll go ahead and add what I have! And thanks for all the help Andrey! I know you guys are just trying to keep people on the right track. Hopefully I don't make y'all's life any harder than necessary! :lol:
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: 1986 Ford Mustang 5.0 EFI swap

Post by AndreyB »

wstefan20 wrote:
Fri Jan 01, 2021 8:05 pm
Thanks! I didn't see this in the wiki before. I'll go ahead and add what I have! And thanks for all the help Andrey! I know you guys are just trying to keep people on the right track. Hopefully I don't make y'all's life any harder than necessary! :lol:
That's a gap and we maybe have to something better somehow. While we have a shit ton of amazing, not all of it is as integrated as it should be.

That reminds me of https://github.com/rusefi/web_backend/issues/57 and we have to find a way to better integrated wiki, forum and rusEFI online.
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
wstefan20
Posts: 111
Joined: Thu Dec 10, 2020 4:00 pm
Github Username: wstefan20

Re: 1986 Ford Mustang 5.0 EFI swap

Post by wstefan20 »

AndreyB wrote:
Fri Jan 01, 2021 8:25 pm
That's a gap and we maybe have to something better somehow. While we have a shit ton of amazing, not all of it is as integrated as it should be.

That reminds me of https://github.com/rusefi/web_backend/issues/57 and we have to find a way to better integrated wiki, forum and rusEFI online.
Yeah. I'm using github's wiki on one of my projects and it has issues for sure.

I do not have push access so I'm not able to upload the image for the connector. Any other way around this?
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: 1986 Ford Mustang 5.0 EFI swap

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
wstefan20
Posts: 111
Joined: Thu Dec 10, 2020 4:00 pm
Github Username: wstefan20

Re: 1986 Ford Mustang 5.0 EFI swap

Post by wstefan20 »

Aaand that makes waaay more sense... give me a bit and send a pull request!
wstefan20
Posts: 111
Joined: Thu Dec 10, 2020 4:00 pm
Github Username: wstefan20

Re: 1986 Ford Mustang 5.0 EFI swap

Post by wstefan20 »

Pull request sent! I'll post the link to this forum once it is approved.
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: 1986 Ford Mustang 5.0 EFI swap

Post by AndreyB »

I am not 100% sure but it looks like it would not have worked without https://github.com/rusefi/rusefi_documentation/commit/d6226c71f914cfe24a1453b35e879fd945fd3353

Is there any overlap between https://github.com/rusefi/rusefi/wiki/Ford-Fox-Body-(88-Ford-Mustang-302-V8) and https://github.com/rusefi/rusefi/wiki/Mustang-Ford-92-5.0 ?

Please add a reference to either or both into https://github.com/rusefi/rusefi/wiki/Vault-of-Pnp-Vehicle-Pages - that could be done with a simple online page edit no PR needed.
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: 1986 Ford Mustang 5.0 EFI swap

Post by mck1117 »

wstefan20 wrote:
Fri Jan 01, 2021 6:45 pm
Sorry for re-visiting this. I think I might be overlooking something simple so my apologies if this is my stupidity. In the below circuit it appears this connects directly from the connector all the way to the STM microcontroller.

Image

There's a few pull-down resistors (470k), current limiting resistors (10k), filtering capacitors (100nF), some TVS diodes, then a voltage follower (buffer if you will) and then a voltage divider. The MCP6004 chip is clearly only rated for 5V and this makes sense because the voltage divider takes a 5V signal and steps it to around 3.2V which is the limit on the microcontroller pins.

From this it appears that all the analog pins are 5V not 12V inputs unless there's another part of the schematic I'm not seeing.

As for the digital circuit shown below, it appears this is from direct input to controller.

Image

There's a pullup resistor (2.2k), current limiting resistor (3.3k), filtering capacitors (1nF) and then through a buffer and straight into the controller which doesn't make sense because it's 5V (above the range of that pin for the controller).

I must be missing something here....
Neither is a direct input in to the controller - they're buffered by the opamp and 74HC2G17 respectively. The 2G17 has clamping diodes from the inputs to the power rails, and allows the input voltage to leave the power rails by one diode drop's worth (aka the requirement is actually that you don't overcurrent the clamp diodes).

The analog inputs only do something useful from 0-5 volts, but won't be damaged by +-24v. Below 0v will indicate 0v, and above 5v will indicate 5v.

Likewise on the digital inputs, they can only tell whether the voltage on the input pin is greater/less than whatever the threshold on the 2G17 is (something like 2.8 volts going high, and 1.8 volts going low). That could be 0 to 5v, or -10v and +10v. All it does is compare whether it's above or below threshold.
dbh97
contributor
contributor
Posts: 84
Joined: Sat Jul 19, 2014 10:43 pm
Location: 67867
Github Username: chuckwagoncomputing
Slack: dbh97

Re: 1986 Ford Mustang 5.0 EFI swap

Post by dbh97 »

Yep, the 88 and 92 wiki pages you linked use the same EEC-IV connector that wstefan20 has.
It's the same connector I sent you a while back, not the same as I'm working with, the EEC-V.
wstefan20
Posts: 111
Joined: Thu Dec 10, 2020 4:00 pm
Github Username: wstefan20

Re: 1986 Ford Mustang 5.0 EFI swap

Post by wstefan20 »

AndreyB wrote:
Fri Jan 01, 2021 10:06 pm
I am not 100% sure but it looks like it would not have worked without https://github.com/rusefi/rusefi_documentation/commit/d6226c71f914cfe24a1453b35e879fd945fd3353

Is there any overlap between https://github.com/rusefi/rusefi/wiki/Ford-Fox-Body-(88-Ford-Mustang-302-V8) and https://github.com/rusefi/rusefi/wiki/Mustang-Ford-92-5.0 ?

Please add a reference to either or both into https://github.com/rusefi/rusefi/wiki/Vault-of-Pnp-Vehicle-Pages - that could be done with a simple online page edit no PR needed.
Actually the 92 Mustang 5.0 is my post! The 88 is a custom project that actually lead me to rusEFI. They used the microrusefi with I think a batch injection if I remember correctly. Their diagram is correct but the pinout is specific to their project, not the actual vehicle. Should I be doing that?

And I will edit the page!
wstefan20
Posts: 111
Joined: Thu Dec 10, 2020 4:00 pm
Github Username: wstefan20

Re: 1986 Ford Mustang 5.0 EFI swap

Post by wstefan20 »

mck1117 wrote:
Fri Jan 01, 2021 10:29 pm
Neither is a direct input in to the controller - they're buffered by the opamp and 74HC2G17 respectively. The 2G17 has clamping diodes from the inputs to the power rails, and allows the input voltage to leave the power rails by one diode drop's worth (aka the requirement is actually that you don't overcurrent the clamp diodes).

The analog inputs only do something useful from 0-5 volts, but won't be damaged by +-24v. Below 0v will indicate 0v, and above 5v will indicate 5v.

Likewise on the digital inputs, they can only tell whether the voltage on the input pin is greater/less than whatever the threshold on the 2G17 is (something like 2.8 volts going high, and 1.8 volts going low). That could be 0 to 5v, or -10v and +10v. All it does is compare whether it's above or below threshold.
I was always warned against using clamping diodes in this manor rather than voltage dividers, but I've seen your thermal testing so it's obviously not a concern. Is there a specific advantage to using clamping diodes vs a voltage divider? They both would put off heat for sure. Just curious why you chose this approach is all.
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: 1986 Ford Mustang 5.0 EFI swap

Post by mck1117 »

wstefan20 wrote:
Fri Jan 01, 2021 10:39 pm
mck1117 wrote:
Fri Jan 01, 2021 10:29 pm
Neither is a direct input in to the controller - they're buffered by the opamp and 74HC2G17 respectively. The 2G17 has clamping diodes from the inputs to the power rails, and allows the input voltage to leave the power rails by one diode drop's worth (aka the requirement is actually that you don't overcurrent the clamp diodes).

The analog inputs only do something useful from 0-5 volts, but won't be damaged by +-24v. Below 0v will indicate 0v, and above 5v will indicate 5v.

Likewise on the digital inputs, they can only tell whether the voltage on the input pin is greater/less than whatever the threshold on the 2G17 is (something like 2.8 volts going high, and 1.8 volts going low). That could be 0 to 5v, or -10v and +10v. All it does is compare whether it's above or below threshold.
I was always warned against using clamping diodes in this manor rather than voltage dividers, but I've seen your thermal testing so it's obviously not a concern. Is there a specific advantage to using clamping diodes vs a voltage divider? They both would put off heat for sure. Just curious why you chose this approach is all.
The energy is the same. 24v -> 5v is a 19v drop, across a 3.3k resistor is 5.7mA. The CPU alone draws over 100mA from the 5v rail (really from the 3.3v rail, but it's a linear reg, so current is the same at 5v).

If divided such that the analog inputs could sense -24v to +24v, that's 10x wider range that 0-5v, which means you lose 3.2 bits of effective resolution. That's a lot! The STM32's 12-bit ADC is already sort of crappy, offering like 10 bits of usable data. Knocking another 3.2 off of that would provide only ~111 codes between 0 and 5 volts, almost 50mV per count, which is not enough resolution for thermistors to be accurate.

If you wanted digital inputs to tolerate 12v but also work at 5v, the threshold would have to be extremely low, making them susceptible to noise.
wstefan20
Posts: 111
Joined: Thu Dec 10, 2020 4:00 pm
Github Username: wstefan20

Re: 1986 Ford Mustang 5.0 EFI swap

Post by wstefan20 »

mck1117 wrote:
Fri Jan 01, 2021 10:54 pm
The energy is the same. 24v -> 5v is a 19v drop, across a 3.3k resistor is 5.7mA. The CPU alone draws over 100mA from the 5v rail (really from the 3.3v rail, but it's a linear reg, so current is the same at 5v).

If divided such that the analog inputs could sense -24v to +24v, that's 10x wider range that 0-5v, which means you lose 3.2 bits of effective resolution. That's a lot! The STM32's 12-bit ADC is already sort of crappy, offering like 10 bits of usable data. Knocking another 3.2 off of that would provide only ~111 codes between 0 and 5 volts, almost 50mV per count, which is not enough resolution for thermistors to be accurate.

If you wanted digital inputs to tolerate 12v but also work at 5v, the threshold would have to be extremely low, making them susceptible to noise.
That makes a lot of sense! I guess that "rule" I was taught was just so there was no clipping. I never even thought about reducing resolution.

On a side tangent, have we ever thought about adding a standalone ADC? I know it would be a bit of coding but if resolution is an issue, it could help.

So I'm going to go out on a limb and say the clipping of the analog signals for something like tach isn't an issue since it's not about the amplitude but the frequency which can still be determined.

Either way, thanks for the info. I find both school and the workplace tend to teach "rules" without actually stating why they exist. I'm grateful for forums like this with people like you where I can actually get practical knowledge.
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: 1986 Ford Mustang 5.0 EFI swap

Post by mck1117 »

wstefan20 wrote:
Sat Jan 02, 2021 12:05 am
That makes a lot of sense! I guess that "rule" I was taught was just so there was no clipping. I never even thought about reducing resolution.

....

Either way, thanks for the info. I find both school and the workplace tend to teach "rules" without actually stating why they exist. I'm grateful for forums like this with people like you where I can actually get practical knowledge.
That rule only makes sense if you actually care about the signal getting clipped. 99% of analog sensors are either actually 0-5v, or ratiometric to their supply voltage, which is 5v in our case. So there's no reason to try and do anything useful with anything outside the 0-5v range. Outside that range is an error condition, so the only things we care about are 1) detect the error (software) and 2) don't blow up the ECU (hardware).
wstefan20 wrote:
Sat Jan 02, 2021 12:05 am
So I'm going to go out on a limb and say the clipping of the analog signals for something like tach isn't an issue since it's not about the amplitude but the frequency which can still be determined.
Trigger/vss/whatever signals aren't even analog. They're digital, just on or off. So you want as few bits as possible. That's why the HC2G17 is there - it's a schmitt trigger to sharpen up incoming edges so they really are exactly one bit of information. If it clips, who cares, that's the point.
wstefan20 wrote:
Sat Jan 02, 2021 12:05 am
On a side tangent, have we ever thought about adding a standalone ADC? I know it would be a bit of coding but if resolution is an issue, it could help.
The best reasoning for an external ADC is actually additional channels, not better resolution. The STM32's ADC is plenty accurate for what we're doing, but you are limited to 16-ish channels on most STM32 parts.

You start adding redundant position sensors on two throttles, a wastegate, multiple temperature and pressure sensors, and it adds up quick and you find yourself without many channels left.
wstefan20
Posts: 111
Joined: Thu Dec 10, 2020 4:00 pm
Github Username: wstefan20

Re: 1986 Ford Mustang 5.0 EFI swap

Post by wstefan20 »

mck1117 wrote:
Sat Jan 02, 2021 2:33 am
That rule only makes sense if you actually care about the signal getting clipped. 99% of analog sensors are either actually 0-5v, or ratiometric to their supply voltage, which is 5v in our case. So there's no reason to try and do anything useful with anything outside the 0-5v range. Outside that range is an error condition, so the only things we care about are 1) detect the error (software) and 2) don't blow up the ECU (hardware).
Makes sense. My research involves very high voltage pulses where frequency content is important, so analyzing the entire waveform is also important. The "rule" is definitely different depending on the application.
mck1117 wrote:
Sat Jan 02, 2021 2:33 am
Trigger/vss/whatever signals aren't even analog. They're digital, just on or off. So you want as few bits as possible. That's why the HC2G17 is there - it's a schmitt trigger to sharpen up incoming edges so they really are exactly one bit of information. If it clips, who cares, that's the point.
Good to know! I have been using oscilloscopes to diagnose these waveforms so long that sometimes it's hard to just see them as a trigger. The more I dive into this the more I realize you really have to "think like the computer".
mck1117 wrote:
Sat Jan 02, 2021 2:33 am
The best reasoning for an external ADC is actually additional channels, not better resolution. The STM32's ADC is plenty accurate for what we're doing, but you are limited to 16-ish channels on most STM32 parts.

You start adding redundant position sensors on two throttles, a wastegate, multiple temperature and pressure sensors, and it adds up quick and you find yourself without many channels left.
Yeah. I saw that looking through your diagrams. Once I get more comfortable with the software side of things I could help look into that. I've coded plenty of libraries for DACs and ADCs before, and although most of those are precision versions, the cheaper ones needed for our application wouldn't be any different to program.
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: 1986 Ford Mustang 5.0 EFI swap

Post by mck1117 »

wstefan20 wrote:
Sat Jan 02, 2021 3:32 am
Makes sense. My research involves very high voltage pulses where frequency content is important, so analyzing the entire waveform is also important. The "rule" is definitely different depending on the application.
Yes - if you want to do any frequency analysis, anything in the class of clipping/averaging/whatever will hurt your ability to do so, especially if your analog front end has distortion near the rails or requires a significant period of time to recover from saturation.

When you only care about in the time domain like we do, and everything is extremely slow compared to the bandwidth of the opamp (even the MAP sensor doesn't have more than a few hundred hz of bandwidth, and the analog filter has Fc at ~150hz), you can clip all you want without making too much of a mess.
wstefan20 wrote:
Sat Jan 02, 2021 3:32 am
Yeah. I saw that looking through your diagrams. Once I get more comfortable with the software side of things I could help look into that. I've coded plenty of libraries for DACs and ADCs before, and although most of those are precision versions, the cheaper ones needed for our application wouldn't be any different to program.
RIght, I think it'd be pretty easy to do, but we just haven't had the need yet.
wstefan20
Posts: 111
Joined: Thu Dec 10, 2020 4:00 pm
Github Username: wstefan20

Re: 1986 Ford Mustang 5.0 EFI swap

Post by wstefan20 »

mck1117 wrote:
Sat Jan 02, 2021 3:39 am
Yes - if you want to do any frequency analysis, anything in the class of clipping/averaging/whatever will hurt your ability to do so, especially if your analog front end has distortion near the rails or requires a significant period of time to recover from saturation.

When you only care about in the time domain like we do, and everything is extremely slow compared to the bandwidth of the opamp (even the MAP sensor doesn't have more than a few hundred hz of bandwidth, and the analog filter has Fc at ~150hz), you can clip all you want without making too much of a mess.
All wise words! Thank you. Once I get the simulator running finally I'll start working on the schematics. I'm torn because I really like Fusion360's interface, and I've never used KiCad before, so I'm tempted to design it and port it over afterwards, but I also know that I won't have access to Fusion forever since I graduate with my Masters next semester and don't plan on going for my Doctorate so I might as well bite the bullet and learn KiCad. I'm sure they can't be THAT different after all, and it would save me a load of time since I could pretty much just slightly modify your schematic and then just place the board components.
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: 1986 Ford Mustang 5.0 EFI swap

Post by mk e »

wstefan20 wrote:
Fri Jan 01, 2021 7:27 pm

Ok. I think we had a miscommunication. when I said I don't consider a breakout board an option, I was referring to production. As a dev tool, you are completely correct, it is definitely a completely viable way to do things so we agree here.

I guess the difference in my mind is that I am not really trying to make a whole new system or even improve upon Proteus. If that were the case, I 100% agree, the dev board method would make infinitely more sense.

Since all I will really be doing is re-arranging traces on a PCB I see no need to do a dev board as long as I know what my traces will be connecting to.

Also, I never intended this to be a product I would sell. This is because my re-work is a far cry from being a "new-product" and that's not fair to the maker of Proteus. If he wanted to sell these, I'd be fine with that, and if he was ok with it, I wouldn't mind working a deal out for small batches and having me assemble or something, but that's way way off in the future.

Also, the available pins are pretty limited so if I were to make a dev board it would be squabbling about maybe 4 pins so unless I mess up planning the pins royally it shouldn't matter.

All my difference of opinion is is that the benefits of a dev board (in this specific case) are outweighed in my opinion. Again, this would be different if this was anything more than re-wiring.
So you've convinced me you don't need a break-out board as what you're doing is really a 1 off install so you've made an incredibly strong case to buy a proteus and wire it in and stop worrying about which features you'll need to delete to use the OEM connector, just cut it of and be done with the problem for good. Hell, you would have had it running and tuned by now just using the time you and I have sent discussing PnP :D

Use the new found free time to grind all but 1 tooth off the distributor trigger and add a proper crank position setup so it will rev crisply.

Spec what's right for the project not what you might be able to get away with.....I have never ever hear any one complain about having too many ECU features available, but literally 100's about too few.

Also old cars just don't have everything new ones do so you always endup adding a bit of wiring....and the sooner you just get on with it the easier you're life becomes. My project car started life fuel injected but an early 80's implementation so its got...100? 120? new wires. It just is what it is.

On the pin count front, I'm using ..36? just for analog inputs. They go fast and as I said, I've never hear anyone complain about having too many. When I do car for other this is always one of the first questions, are we leaving room for future improvements or is it finished? If its for me the answer is I'm leaving room for future improvement because nothing is ever DONE done.....I sent a CAN line and 1/2 dozen other unused wire to the front, and use 2 plus I extended another 4 OEM wires back to the ECU before I ever "finished" the 1st round of wiring. Project cars are toys...toys are for playing with, plan accordingly and stop trying to remove pins you'll miss later. I don't have a proteus because I'd need 2 or 3 to get enough pins to be happy :lol:
Attachments
2015-12-05 002.JPG
2015-12-05 002.JPG (339.65 KiB) Viewed 14339 times
2016_02_15 002.JPG
2016_02_15 002.JPG (350.11 KiB) Viewed 14339 times
Post Reply