My 87 toyota supra hardware build

All home-built FreeEMS implementations without a forum of their own, usually TA-based.
Post Reply
via
QFP80 - Contributor
Posts: 57
Joined: Mon Dec 02, 2013 5:57 pm

My 87 toyota supra hardware build

Post by via »

Hi all.

I've got a 1987 Toyota Supra turbo that I have put way too much of my life into, so I figured why not put more.

Image

Its got the 7mgte inline 6. I've been pretty happy with 300rwhp for a while, and have fiddled with trying to make my own piggyback fuel controller using an fpga loaded with openrisc and some custom HDL on it, but decided going standalone is the right path forward. For the last few weeks I've been researching freeems and getting the basic fundamentals down.
I've got most of it planned out and have started the build, but figured before I go too much further I should run everything up here to make sure I'm not doing something really dumb.

The engine semisequential injection (3 batches of two injectors), and wasted spark (also 3 batches of two). Firing order is 1-5-3-6-2-4.
It uses a toyota CPS with three VR outputs. NE with 24 pulses per cam rotation, and G1/G2 each triggering once per rotation. I've decided that I can use NE/G1 with a 24/1 decoder (eventeeth) that already exists. The stock engine uses a KVAFM which I fully intend to replace with speed-density using a MAP sensor and an IAT after the intercooler. Exact placement of these is not yet decided. I plan to use the existing coolant temperature sensor after calibrating it. The injectors I've got installed at the moment are some Bosch 550cc low impedence injectors that are run through a giant resistor for the ecu to drive. I've toyed with the idea of using a low-z driver, but figured for the time being I'll continue using the stock resistor pack until I need replacement injectors and then I can just get some high-z ones.

I decided I would be most comfortable doing the hardware piece by piece on perfboard and soldering rather than trying to make my own pcb. I have very little experience with pcb design, and only marginal
experience with soldering. I've done some SMT, but prefer through-hole components, and even then I'd say my soldering is not particularly high quality. I purchased a TA board and a Jimstim. I started out by going through the Ravage and Jaguar schematics to choose parts, basing various subcircuits off of those designs. Injector/Ignition drivers, analog inputs, and most of the power supplies are shamelessly copied from Ravage. I assembled a list of parts from those designs, substituted through-hole components where appropriate, and then bought a lot of them:
https://pastee.org/2tur7

Before getting the hardware started, I wanted to make sure I could get all the software components working well. I was able to compile freeems-loader with zero problems on OpenBSD. Emsstudio took a bit
more effort, as that code depends on a relatively recent version of qwt. Making it work with older qwt's just involved a very simple change (the use of the graph set_samples calls), and now emsstudio works great and can talk to the board. Rather than try to get all the toolchain set up I took the easy route and set up a debian VM and installed the tools necessary to build. I will say, that part was extremely easy, thanks to anyone who made it so simple and easy to configure/build.

I started off with the power supply, using two 5V regulators just like in Ravage. One thing I'm not 100% clear on is the use of a mcu pin to turn on/off the accessory 5V supply. There seems to be some debate about if this is a good idea, perhaps I should just switch it on key, as right now it seems that there is no freeems support for always on (is this true?). Primary 5V supplies the TA board (bypassing the onboard regulator), and the other powers the analog sensors, jimstim, and anything else I come across that wants 5V. I've separated each ground, although in my pictures below they all connect to the same point for testing.

I went the simple route on the VR board and just outright bought and assembled one. It uses the LM1815 ICs, and I have not tested it with my actual CPS yet.
I just finished the ignition drivers a few days ago, and it feels pretty great to be able to adjust the jimstim tach output and watch lights blink in sequence.

The stock 7mgte uses a igniter that operates in multiplex; There is one distributor-like output and two other control wires that designate which set to fire. This could probably be made to work with FreeEMS, but in the supra community the igniter is considered problematic, so I invested in a 3 channel igniter from the later Lexus models (DH61). I imagine it'll be simple to integrate with FreeEMS. It apparently automatically controls dwell, I'll probably need some guidance on setting that up.

I've added in #ifdef'd sections into my local checkout of freeems-vanilla that I'll put up on my own github in the near future, but right now there's not much different. I set the engine sizes/injector sizing, and added a section for my event control.

#elif CONFIG == SUPRA_ID // Firing order 1-5-3-6-2-4
anglesOfTDC: {ANGLE(0), ANGLE(120), ANGLE(240), ANGLE(360), ANGLE(480), ANGLE(600), ANGLE(0), ANGLE(120), ANGLE(240), ANGLE(360), ANGLE(480), ANGLE(600)},
outputEventPinNumbers: {3,4,5,3,4,5,0,1,2,0,1,2}, // An example of wiring your engine with cylinder one on output one, harder to grok
schedulingConfigurationBits: {1,1,1,1,1,1,0,0,0,0,0,0}, // Ones represent scheduling for injection, zeros represent scheduling for ignition
decoderEngineOffset: ANGLE(0.00), // Trim fuel injection END point with this value.
numberOfConfiguredOutputEvents: 12, // 6 coil events, 6 injection events
numberOfInjectionsPerEngineCycle: 2 // Semi-sequential


I'm pretty confident I have this close to right at least for the ignition sequencing, but I'm still a little unclear on what I'm doing. I figured I'd wire up the igniter driver ports to PT0-2 and the injector drivers to PT3-5. However, while my ignition order makes sense to me ( firing order 153624, wasted spark pairs are 1-6 2-5 3-4), the fuel injector order makes very little sense and I'm not sure how
to set it up. They are wired in 1-4 2-6 3-5 pairs, and I assume they're fired in that sequence too. I'll be honest and say that the timing of these things is still something I'm starting to understand.
Nor do I fully understand how the timing of the injection batches is supposed to be done. About all I have to go on is this random picture on the internet:
Image

Current collection of pictures of the hardware: http://imgur.com/a/iJOzZ
A lot of its hacky, and I'll probably end up redoing parts of it.

I know thats all kind of a lot to post, but I did want to have a pretty good idea of what I was doing and get started before getting on here. Even then I'm certain I've missed some things.

Thank you and Merry Christmas.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: My 87 toyota supra hardware build

Post by Fred »

Great to see the amount of research you've put into doing this. I thank you from the bottom of my heart for how thorough you've been. Really! <3 :-)

Re power supplies and always-on and MCU switched stuff, ignore that. Your best bet is to use one 1Amp supply from an lm2940 or more sophisticated setup (MOV, diodes, clamps, filters, etc, but don't bother), and roll with it. Yes, no support for it right now, once there is hardware with our guessed setup, there will be some dev and testing on that hardware. Until then, especially for DIY setups, KISS (keep it simple, stupid).

If you have any trouble with the LM1815 stuff, consider upgrading to a MAX992X setup.

For your "smart" ignitor, you need to bench test it, fully understand what it does, and what it doesn't do, and how it works, and tell us. Only then can we help you set up the software and circuits to best control them. A better choice is dumb ignitors, which are easy to get, but do test yours, as it may be dumb, and the internet (largely m$ based in this field) may have lied to you.

Your scheduling config is a bit back to front. Generally it's fine, however specifically reverse the order of the first and last 6 so ignition is first and injection last. The reason for this is that if the setup is slightly wrong (code, not your config) then the fueling gets mal-scheduled, not the ignition. This is unlikely, but a bad ignition pulse can do damage under low load conditions, so should be avoided always.

With respect to understanding injection batches and timing and so forth, the main objective is to give all cylinders even timed fueling such that they all run the same, and thus the engine and overall combo is smooth. If they are wired the way you described, then you will live with it like that, and it likely won't make much difference. No stress. Their strategy is to fire the injector once per cycle, where as mine is to fire it twice per cycle. They are basing it on both dwelling in the cylinder for a while (one longer than the other), and I'm basing it on some dwelling and some fresh, always, for all cylinders. It's not critical, most of the time.

About your pictures, those heatsinks are going to break the leads of the regs, sooner or later. Mount them, somehow, firmly.

Merry xmas to you too, this is your gift at 10pm on my xmas day here in NZ.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
via
QFP80 - Contributor
Posts: 57
Joined: Mon Dec 02, 2013 5:57 pm

Re: My 87 toyota supra hardware build

Post by via »

Your best bet is to use one 1Amp supply from an lm2940
I'm not super knowledgeable about power supply design, so I just want to be clear on what you mean here. Are you suggesting the one lm2940 for both the mcu power and the accessory power, and I suppose switching it via a relay controlled by the key? I suppose that'd definitely be simpler than what I've got going now, but I do already have a bunch of lm2937's and lm2941's, can I continue to use those? I was a bit surprised by how hot the heat sink gets for the mcu...
If you have any trouble with the LM1815 stuff, consider upgrading to a MAX992X setup.
Yeah, I see most of the designs here use those. I might order some preemptively in case that VR board doesn't work, if not simply because I already don't like having the separate pcb board for that.
For your "smart" ignitor, you need to bench test it, fully understand what it does, and what it doesn't do, and how it works, and tell us.
Ok. The igniter apparently got delivered yesterday, but I'm out of town until tonight. I'll be able to play with it tomorrow. What is entailed in bench testing it? I've got an ancient oscilliscope, should I just hook it up to the igniter outputs and see what it looks like as I change rpm?
Your scheduling config is a bit back to front.
Changed. Thank you. Definitely don't want to blow the engine up just yet.
Their strategy is to fire the injector once per cycle, where as mine is to fire it twice per cycle.
Ok, cool. I've gathered that the order doesn't matter a huge lot to getting it running anyway... But on that note, does firing injectors once/twice per cycle have any bearing on that "numberOfInjectionsPerEngineCycle" config? Should I have that set to 1 in this case?
About your pictures, those heatsinks are going to break the leads of the regs, sooner or later. Mount them, somehow, firmly.
Understood. I'll either do that with my existing one, or I'm making a new power supply unit wrt above, I'll try to make it cleaner as I go.

Thanks for the quick response on Christmas day. :-)
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: My 87 toyota supra hardware build

Post by Fred »

numberOfInjectionsPerEngineCycle was correct at 2 for the config you posted above, and should still be correct if you simply reordered the parts. Repost it within code tags and we'll re review.

you can use weaker regulator(s) but:

1) if you only use one, it'll be close to maxed out, which is OK, but not ideal
2) if you do use two, you need to ensure they are accurate enough to not cause issues with the reference exceeding the supply, or vice versa (one matters, I forget which)

A nice way to mount your regs for heatsinking is with a piece of alloy bar, or angle, screwed to the top of it and it screwed to the board. This is totally reliable vibration wise.

Testing the ignitor means hooking it up to an actual coil (same as you want to use, but spare, in case you burn it, unlikely, but...) and observing dwell input, current drawn, and discharge times. Smart tends to mean "limits dwell to some maximum" which translates to "fires sparks too advanced if overdwelled". However it can mean "controls dwell by itself, and you simply control when to fire the spark. It could even have inverted input requirements, etc. You need to fully test it and understand exactly what it does in all cases. Dumb ignitors are MUCH nicer to work with. You just tell them what to do and they just comply.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
via
QFP80 - Contributor
Posts: 57
Joined: Mon Dec 02, 2013 5:57 pm

Re: My 87 toyota supra hardware build

Post by via »

Repost it within code tags and we'll re review.

Code: Select all

#elif CONFIG == SUPRA_ID // Firing order 1-5-3-6-2-4
                anglesOfTDC: {ANGLE(0), ANGLE(120), ANGLE(240), ANGLE(360), ANGLE(480), ANGLE(600), ANGLE(0), ANGLE(120), ANGLE(240), ANGLE(360), ANGLE(480), ANGLE(600)},
                outputEventPinNumbers:       {0,1,2,0,1,2,3,4,5,3,4,5}, // An example of wiring your engine with cylinder one on output one, harder to grok
                schedulingConfigurationBits: {0,0,0,0,0,0,1,1,1,1,1,1}, // Ones represent scheduling for injection, zeros represent scheduling for ignition
                decoderEngineOffset:           ANGLE(0.00), // Trim fuel injection END point with this value.
                numberOfConfiguredOutputEvents:          12, // 6 coil events, 6 injection events
                numberOfInjectionsPerEngineCycle:        2  // Semi-sequential
if you do use two, you need to ensure they are accurate enough to not cause issues with the reference exceeding the supply, or vice versa
Ok. I think especially with the lm2937 being as hot as it is I'll redo it with the two lm2941's. Currently with the resistors I got (all .1% tolerance, the ones from ravage), that is outputting 4.95 V. Is that too low for the mcu? And how far apart is too far apart for the two supplies?
A nice way to mount your regs for heatsinking is with a piece of alloy bar, or angle, screwed to the top of it and it screwed to the board.
I'll definetely do that for the new supply.
same as you want to use, but spare, in case you burn it, unlikely, but...)
Unfortunetely I only have my three coils. Plenty of people use this igniter with these coils with no problems on M$. I know that shouldn't give me that much confidence, but it gives me enough to do it.

My main problem is I only have one probe for my oscope. I can easily measure current and charge times, but its hard to measure anything in relation to the input signal. Can you think of any way to do this? Otherwise I have some really crappy software oscope that connects via usb -- I think its just a usb sound card with extra protections on the inputs, but should be good enough for this.
via
QFP80 - Contributor
Posts: 57
Joined: Mon Dec 02, 2013 5:57 pm

Re: My 87 toyota supra hardware build

Post by via »

Correction, I found a really crappy probe in my closet. I'll try to have something useful by the end of the day.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: My 87 toyota supra hardware build

Post by Fred »

I still don't remember which way around the voltages must be, but one must not exceed the other. Huff originally posted about this. TonyS is his nick and also his name.

Sched config is better now. Theoretically there is no difference, but it's possible there could have been a difference, and a bad one.

You likely won't kill your coil, so no big deal there. You could do it with one probe, measure one wave form, change nothing, move the probe, observe, move it back, change, repeat, etc.

If plenty of people use the ignitor, perhaps you can find out what the behaviour is supposed to be from their postings, and then just verify that it's true (or not).
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
via
QFP80 - Contributor
Posts: 57
Joined: Mon Dec 02, 2013 5:57 pm

Re: My 87 toyota supra hardware build

Post by via »

I got a coil and plug set up in a pretty hacky manner, but works well enough to get sparks. Its extremely noisy and causes frequent resets of the mcu, but for now I'll chalk that up to my terrible grounding for testing: http://i.imgur.com/G7SFJ4Th.jpg

Anyway, I know my pictures aren't very good, but I took some at around 1000 rpms, and some around 6000 rpms. When it works, it generates spark, and if I'm reading the scope right, it does seem that the spark always occurs when the input to the igniter returns to zero.

The full album is here: http://imgur.com/a/LAfvC
In all of the pictures the igniter->coil output is on top, the input from the line driver on the bottom. Seems to me that when the input goes high it starts charging the coil, and when it goes low it fires the coil, pretty much throughout the entire rpm range. The part that confuses me is that, especially at lower rpms, it seems like it decreases the voltage on the coil partway through the charge, but not completely, before the input goes low again. Is this the "smart" part slowing the charge rate of the coil after some time, but not enough to generate a spark?

Don't pay too much attention to the vertical scales, the impedences of the probe are definetely not what the scope is set to (10Mohm probes, scope only does 1Mohm).

I'll try to get some cleaner pictures in the next few hours. Any advice for measuring charge current? Can i just slap a high wattage resistor inline with the line to the coil and measure across it?

Edit:
Wrt other EMS and the dh61, apparently there's already an option for i in the AEM one:
To run the IS300 coils you will need to run the setup wizard for the coils to do this in AEM Pro follow these steps.
*Ignition*
*Advanced Ignition*
*Coil Dwell Setup*
*Coil Dwell Wizard*
Select "Toyota Coil (93-98 3.0L Non Turbo)
via
QFP80 - Contributor
Posts: 57
Joined: Mon Dec 02, 2013 5:57 pm

Re: My 87 toyota supra hardware build

Post by via »

Still haven't gotten current measurements down, but here are two cleaner shots:
http://imgur.com/a/JQrUD

First one is at 1000 rpm, bottom being input, top being to coil.
Second is at 6000 rpm.

I double checked, the firmware is configured to BRV based dwelll, and dwellFixedPeriod: T(3).

I'll note that I'm still having a lot of trouble getting it to not reset the mcu most of the time. I've tried running things to differerent ground points, but they all still go back to the ground on my battery, so I'm not sure thats helping much. Moving the coils further away helped some, but its about 3ft away and still pretty bad.

Edit:
Moving the coils even further away helped more, but I can't really get them much further without a bigger desk.
I took three more pics: http://imgur.com/a/XmMWO
First is at 1000, Second is 6000, Third is 3000. I'm wondering wtf is happening in those pictures. It seems like it decides to stop charging partway through, I suppose when i t determines the coil is charged, then when the input drops, it goes back to charging and fires. Looks to me like almost a millisecond after the input goes low that the output returns to 12V. Is that unacceptably long? Back of the napkin math suggests to me that at 6000 rpms, thats 20ms between ignition events in a cylinder. Thus 1ms would correspond to many degrees.

Is it also possible that the automatic dwell its performing won't actually happen correctly unless it is receiving all three channels worth of spark?

Final edit:
I connected the other three inputs, and it changed nothing.
I also tried changing to fixed dwell and decreased the dwell time enough so that it did not have time to switch to the lowered charge current (or whatever that is), and the 500uS or so delay is still there. Am I wrong in assuming that the spark isn't actually firing until that last part?
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: My 87 toyota supra hardware build

Post by Fred »

It's pretty hard to read those photos, at least for me.

What you need to do, is not change RPM, which is pretty much irrelevant, but rather change dwell and increase it gradually until it ceases to increase peak current. Once that happens the coil is saturated and you have a single point for a voltage vs dwell table for your coil-ignitor combo. you can dwell the coil any amount less than the knee point with decreasing spark energy and voltage potential as you go down. Going up from the knee point gives no benefit, only using more battery power to heat the coils and ignitors, eventually damaging them if you take it too far.

Your goal is to find the knee point of the coil while charging from at least three voltages, but even one is a good data point to have. To do this you need to watch current, not voltage. A 0.1 ohm resistor inline with the ignitor/coil combo is fine. If your ignitor is getting in the way of finding the knee point, then you likely have an ignitor that's less than ideal for the coils involved. Additionally, some ignitors will not handle the peak current of coils they were not designed to be paired with.

In short, constructing your own ignition system that works is easy. Constructing your own ignition system that works correctly isn't as easy. Constructing your own ignition system that works reliably and optimally with a strong spark isn't that easy. Try to borrow or obtain a cheap normal dumb ignitor to evaluate your coil performance.

Also be aware of the performance of your ignitors. If not properly driven, you might be dropping 6v across the ignitor, leaving only 6 for the coil. In a good setup the waste will be in the 1 to 2 volt range.

With respect CPU resets, this is not surprising. Grounding won't change much, but properly sealing your ECU in a Faraday cage might. Be careful, though, as currently there is nothing to reset that CPU should you cause a lockup rather than reset.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply