DIY LTCC or similar system for LT1s

[kur4o]

The opti finally gave up. I got a high res error. Somehow the pcm managed to run the engine once it fires. Have you managed to add some safety features on high res failure, and is it possible to get a limp home mode with only low res signal.

If you are willing to improve the code I can be the guinea pig. The map input can be used with low res signal to emulate spark table and with the crank table already there a startup with a waste spark firing can smooth things.


You have lots of experience with opti signals. I want to pinpoint the issue I have before starting to rip off parts.
The PCM opti pins have constant 5 volts. Does this 5 volts changes to 0v based on the optiwheel position[5v full slot,0v empty slot]. For example if I turn slightly the engine by hand will I get 0-5 volts transitions when the beam moves through empty slots.

[spfautsch]

Are you running the DIY-LTCC controller?

Or still running stock distributor and ICM + coil?

[kur4o]

Still stock.

I can temporary wire the controller for testing with the d580 coils I have.

[spfautsch]

So it sounds like you should be doing routine maintenance of your opti, which means pulling the water pump and replacing if it's been a while. Open up your opti and see if there's any oil or coolant contamination. Check the bearing for smoothness. Replace the oil seals in the front of the timing cover. Replace the optical sensor if there's no other evidence of a problem. I would replace it regardless because there's so much to remove to get at it. Be prepared to replace the opti sub-harness because the retainer clip on the distributor end gets brittle and tends to break easily.

Switching to this setup will make it run worse or not at all if your optical sensor is dying or there's an arc hole in the trigger wheel.

Getting around lossy / intermittent high res signal will require switching to time based dwell and spark advance, and I've already stated that's not going to happen any time soon. It's so hard to get time to work on what I'm currently trying to accomplish, that I was ready to throw in the towel yesterday.

[kur4o]

I did some more investigation and found the high res be totally dead. I hook up a led on the high res line while rotating the engine and it is constant 5volts, I hook it to the low res signal and it goes low to high while engine is rotated. I haven`t figure yet, when the line is high=5v, does the beam goes through the slots or at 0volts the beam goes through the slots on the opti wheel.

It looks like the optical sensor is done. I serviced it soon and I hope I didn`t went too much on the sealing.
Changing the optical sensor will be POA, since the wheel is dot welded. Do you have any experience sourcing reliable parts. I found some chinese crap sensors and some so called japan sensors.

that I was ready to throw in the towel yesterday.

It might be because the approach is not headed in the right direction.


All pre lt1 pcms were time based spark, which is also inferior due to spark scatter at startup and heavy throttle change. It wasn`t used until ls1 pcm which are much faster and accurate for the time based spark.

I traced some pcm code to see how it handles the loss of high res and it looks it is using some really simple conversion from degrees to ms.
We don`t need good running engine on low res. We need limp home running engine.
I have an idea how to sequence the coils if high res is bad. Measuring the off and on time through 1 low res event and comparing the off and on time to some percentage. Since the different slot widths, a pattern can be made for identifying the cyl id.
Your only hope is to utilize the system timer. I will get you some ideas from the lt1 code, which also uses 16bit timer. It is incremented each cpu clock cycle.

Do you have some info on the avr registers to look at.

[spfautsch]

I haven`t figure yet, when the line is high=5v, does the beam goes through the slots or at 0volts the beam goes through the slots on the opti wheel.

I answered these questions in Tom's thread on the F-Body ECM reverse engineering here. See posts 17 and 18.

Do you have any experience sourcing reliable parts.

I put a link to what I'm running in post #589. Mouse over the words "optical sensor". I've had zero issues with these except that they do not fit in the Delphi opti body without some modification to the body or adding washers between the sensor and the body. They fit perfectly in the OE Delco-Remy body.

Edit: It pains me to have to disagree with you, but this setup absolutely requires the hi res signal to detect sequence, period. Detecting sequence from time is going to be problematic at best because it has to be 100% every time or the PCM will flood the engine firing the injectors in batch mode because it doesn't need to know sequence immediately. Time based (sequence detection) simply wont work because it will take forever and there can potentially be a huge amount of RPM variation during cranking, especially for a cold engine with a less than healthy battery.

The PCM with a mechanical distributor can limp you home with sequence off by any number of degrees. Fueling will be out of whack because EOIT won't be right, but it will still fire and get you home. We have no such luxury with spark timing in a coil-per-cylinder setup. 90 degrees off and it won't run.

[kur4o]

Thanks for the links. I might need the earlier version of the sensor here.

The high res pin (adjacent to low res pin) conducts when the beam is not broken. Since I'm 100% positive the ecu doesn't care about the "polarity" of the high-res signal it wouldn't matter. But you learn something new every day.

So in my case the beam is broken all the time and there is no ground path applied. It looks like the light emitting part is gone, or the light receiver part can`t interpret light. Did any one tried to replace some of these inside the sensor.

Under some driving experience with the high res missing, I conclude that only spark is affected. There is built in logic for following the cylinder id and the fueling is time based and still runs sequential[It needs extra confirmation]. It is running on x8 low res signal. There is some built in sequencer in the TPU that takes long time to synchronized. Because the irq runs on each low res pulse, the eside logic just increase the cyl id by 1 each cycle.

I have to confirm also why the crank times are so long. I suspect the dwell is shut off or the fuel is shut off until the sequence is detected or code is set.
Now when I think more about the code, when cyl id is set to FF, the fuel part is skipped, so it needs to set the error which is set at 40 low res pulses without high res sensed and than the back up codes kick in and sequence the firing cyl id each cycle and allows fuel.

EOIT can also be enlighten in this kind of situation but I have to think more about it.
I will get you a commented code how spark is converted to time also.

[spfautsch]

I have to confirm also why the crank times are so long.

I would postulate that crank times are long because the ecu wants to see a steady rpm signal on the low res rising edge.

Also, if I had to guess I'd say it wants to see the same sequence (in addition to steady rpm) for two full cam revolutions (four crank revs) before it wants to consider the data good. As I've mentioned, getting a steady cranking rpm can be problematic with an engine that has cold oil, good compression, and a less than optimal battery.

Looking at the time intervals, there's not a huge difference between the indexed cylinders so just looking at it from my perspective I think they wanted to be "really sure".

#4 - 15.5% (14/90)
#6 - 26.6% (24/90)
#7 - 37.7% (34/90)
#1 - 48.8% (44/90)

Did any one tried to replace some of these inside the sensor.

I have one that I killed by beating the hub out of the distributor body without removing the pickup. I can try opening it up and see what discrete componentry might be inside.

[kur4o]

Here is the time conversion of spark. It can also be referenced as end of dwell similar to EOIT usag

RESERVED:5FD6 loc_5FD6:                               ; CODE XREF: IRQ+D74j
RESERVED:5FD6                 ldaa    byte_149        ; SPARK ADV CALC if high res fail
RESERVED:5FD6                                         ; 149= final spark advance
RESERVED:5FD9                 bpl     loc_5FDC        ; branch on advance
RESERVED:5FDB                 nega                    ; invert on retard ff-*
RESERVED:5FDC
RESERVED:5FDC loc_5FDC:                               ; CODE XREF: IRQ+D9Dj
RESERVED:5FDC                 ldab    #$B6 ; '¦'      ; some scalar
RESERVED:5FDE                 mul                     ; [advance * $b6] *2*2
RESERVED:5FDF                 lsld                    ; This converts spark to multipllier coefficient for low res time
RESERVED:5FDF                                         ; 45 degrees roughly equals 1 as a multilpier.
RESERVED:5FDF                                         ; 45*=$2d*b6*2*2 = $7ff8[first byte is the multiplier [$80 =1] [0.007813 * X]
RESERVED:5FE0                 lsld                    ; a= multipler
RESERVED:5FE1                 ldx     #$A1 ; 'á'      ; x=low res time]
RESERVED:5FE4                 psha                    ; low res * multiplier result goes 14d
RESERVED:5FE5                 ldab    1,x
RESERVED:5FE7                 mul
RESERVED:5FE8                 adca    #0
RESERVED:5FEA                 pulb
RESERVED:5FEB                 psha
RESERVED:5FEC                 ldaa    0,x
RESERVED:5FEE                 mul
RESERVED:5FEF                 tsx
RESERVED:5FF0                 addb    0,x
RESERVED:5FF2                 adca    #0
RESERVED:5FF4                 ins
RESERVED:5FF5                 std     word_14D        ; spark converted to time
RESERVED:5FF5                                         ; example 32* at 6000rpm
RESERVED:5FF5                                         ; 32=$20 ; 6000rpm=2.5ms
RESERVED:5FF5                                         ; multipllier=5b[*0.007813=0.711]
RESERVED:5FF5                                         ;
RESERVED:5FF5                                         ; 2.5ms*0.711=1.777ms
RESERVED:5FF5                                         ; 32* at 6000rpm =1.777ms before TDC or after tdc of previous cyl???
RESERVED:5FF5                                         ; might be related with dwell also. It could also be traslated as End of dwell
RESERVED:5FF5                                         ; similar to EOIT.
RESERVED:5FF8                 ldaa    word_15F2       ; some system timer needs to be figured how it is used.
RESERVED:5FFB                 nop
RESERVED:5FFC                 ldd     word_15F2       ; load some TPU system timer???
RESERVED:5FFF                 addd    word_A1         ; add low res to timer
RESERVED:6001                 tst     byte_149        ; test if retard or advance
RESERVED:6004                 bpl     loc_600B
RESERVED:6006                 addd    word_14D        ; add spark time on retard
RESERVED:6009                 bra     loc_600E
RESERVED:600B ; ---------------------------------------------------------------------------
RESERVED:600B
RESERVED:600B loc_600B:                               ; CODE XREF: IRQ+DC8j
RESERVED:600B                 subd    word_14D        ; sub spark time on advance
RESERVED:600E
RESERVED:600E loc_600E:                               ; CODE XREF: IRQ+DCDj
RESERVED:600E                 std     word_1450       ; store time spark at tpu 1450

[spfautsch]

Here's a few pics of the internals of the sensor. There's quite a bit more circuitry inside than I expected so there's more potential for failure than just a bad led or phototransistor.

[link] (16mb)

The conformal coating sucks.

The emitters (ir leds) are wired in series which is something I didn't expect. The one I pulled out has red print on the can. The print is at an angle so the top half of the first digit is clipped off. It's either a 3 or a 5 followed by GLB. I'm not 100% certain the G isn't something else, but a quick search of "5GLB" turns this up.

https://www.aliexpress.com/i/4000364428839.html

There's a part # on the low-res phototransistor. The first two characters are hard to make out but I believe it's CUR53. Unfortunately, it seems that the more I work to remove the conformal coating, the less legible the beginning characters / digits are.

I hope this helps. When I have more time I'll try to get part #s on the various components on the circuit board and possibly reverse engineer the schematic.

[spfautsch]

Here's an interim firmware diy_ltcc_0_9_20. < link

Included in the zip are the updated pcb schematic and board design. I'm planning to move the older releases off of github and onto my vanity domain in the coming week(s). At that point I'll update my .sig so all the previous and future releases are easily available without going to github.

This release is a hot mess - lots of experimental stuff is turned on without conditionals to turn it off. If you log the uart output at 115200|8|N|1 you'll see miscellaneous sequence detection data, and then the ADC [F]equency, the [C]oolant temp in raw units, the system [V]oltage and the raw [M]AP reading dumped out once a second.

Changelog:

I've added logic to control power to my wideband from output A0 (disabled by default, pointless for everyone but me).

Preliminary coolant temperature sensing is enabled - connect spare input "IN1" to PCM pin C25. A .1uf ripple capacitor is recommended at C20 - for those with kits that predate this change PM me and I'll drop you one in the mail free of charge. Note, you'll need to mirror your cranking spark advance at 0x12057 to the declaration of const uint8_t PROGMEM crankSpkTable[17][2] in the source

A bug was fixed that caused incorrect sequence detection when the engine was started from a position where the hi-res beam was not broken by the trigger wheel. This happens fairly infrequently, and so I assumed the difficult starts it caused were due to my tune.

MAP acceleration compensation is disabled pending a more complete solution.

DIY_LTCC_CHALLENGE!!!! READ!!!!

At this point in the project I've mailed about 10 kits out to various destinations all over the planet. Thus far no-one has attempted to actually run one that I'm aware of. I'd like that to change if for no other reason than I'd like to be able to claim I'm not a complete idiot for 1/1,000,000th of my lifecycle. So I'm issuing a challenge - the first person to post a video of their car running with my setup gets their choice of two free parts kits or a $50 Amazon gift card.

/DIY_LTCC_CHALLENGE!!!

Moving forward, based on this firmware build I plan to implement individual dwell vs voltage vs coolant temp tables cogent to the coil test data I gathered last month. Additional features <if possible> are RPM and MAP based dwell compensation tables. I'm also planning to clean up all the conditional compilation flags and create separate .cpp or .h files for dwell tables, individual user settings, etc. The ultimate goal is a semi user-friendly V1.0 release with accompanying documentation on how to install, build, etc.

kur4o-

I hate to call you out publicly, but I simply can't make progress while I'm concurrently being kicked in the balls by your relentless criticism of how this doesn't work like GM would have made it. So while I can't possibly express how much I appreciate all your help which has been indispensable, I have to proclaim that your recent requests have been difficult to stomach. This project has, and will always be targeted at a low-cost compromise between a stock optispark distributor system, and a full-on 24/27/54x conversion. The difference between the two are considerable. Please, for the love of doG, keep this in mind with your future requests. I am but a simple redneck with an antique oscilloscope and a 30 year old, yellowed electronics engineering diploma. I am not ashamed to tell the world I lack the mental capacity and financial (not to mention time) resources to match what GM did in 1995, much less 2000's and beyond. I'm doing the best I can here, and unlike GM have made the source code freely available. Cut a brother some slack? Please?

[kur4o]

Thanks for the pictures. If the ir leds are wired in series, if one fails both signals will be out. Easy to identify the problem. I don`t see anything here that can`t live forever.
It seems pretty simple and robust design. It must be either the opto sensors failing or some broken solder. Is there some other electronics in the opti or the 4 pin sensor output goes straight to the external connector. The earlier design seems to have some other electronics parts inside.

I have confirmed that until the high res code is set the fuel is cut. This explains the extended cranking time[10 full crank revs are needed for the code to set]. Hopefully if the code is set earlier the cranking time will be reduced.
The extended crank time I had on cold startups might be related with the failing high res signal and not with the fueling tables.

I will take on the challenge but it is too bad the opti failed at the worst possible time. And don`t take my suggestions too personal as demands, It is just ideas for improvements. I have no idea if they can be done with the limited resources and hardware you have.

For the uart output can I hook a bluetooth module there and log wireless.

By the way the dwell patch I was working on is almost done. If you want a steady fixed dwell output, that can be compared with your time based calculations to fine tune the math you are using you can give it a try.

As a side note the 10ms fixed startup dwell seems to work better. I got much fresher startups. Now I will add the 10ms instead of fix them to see if it can get even better.

[kur4o]

I hate to spam on the thread with irrelevant information, but I changed the high res error threshold to 2 and it fired right on. I even think it fired faster than usual with good high res signal on a cold startup.

[spfautsch]

Is there some other electronics in the opti

There's nothing else inside - pictures covered everything. If you have yours broken down I'd be interested in pics as well if it's a non-vented opti. I wasn't sure what year yours was.

I have confirmed that until the high res code is set the fuel is cut.

Are you meaning there's no injector fire without a high res signal even before the DTC is set?

The extended crank time I had on cold startups might be related with the failing high res signal and not with the fueling tables.

I had the same type of oddball issue happening because of this:

if (PINB & B00000001)

Evaluates false, but

if ((PINB & B00000001) == 1)

Evaluates true for the same input state. This check is determining if the low res trigger is high or low at controller power-on and after a stall which is used to identify how to detect sequence. Now that this bug is fixed I'm seeing much better consistency and near perfect starts.

For the uart output can I hook a bluetooth module there and log wireless.

That might work, but if it were me I would pull the four wires into the passenger compartment. You'll need to be able to disconnect the DTR pin during normal use because any program that opens a handle to the serial port will pull this low, causing the controller to reset, and the engine (if running) to die. You also probably won't want to have to climb around under the hood to switch wiring around in order to flash a new firmware.

Interesting find on changing the hi-res error threshold. Curious if you can confirm it's actually running in sequential mode, and not batch firing the injectors.

All things considered, this is like one of my children. So it's hard not to take criticism personally, but I'll try. Ultimately I want to have time instead of degree based dwell, and if that can be made to work a limp-home time based sequence detection can be employed. But in the mean time I don't want to let perfection be the enemy of the good.

[kur4o]

Are you meaning there's no injector fire without a high res signal even before the DTC is set?

Exactly, the bpw is set to zero. Only when the code is set the fuel is allowed. Next on the list is to confirm by hand feel, batch mode vs sequential. On eside all the calculations are sequential but it depends on the TPU how to fire injectors. I will dig more how the cylinders are synchronized within the TPU. I managed to log eside data with engine running and now it will be piece of cake finding more interesting stuff.

I found some excellent link with pictures of the gen1 optispark. Thanks goes to GaryDoug for the uploads. LINK

There are some substantial differences but internals look similar. The hardest part will be to remove and install the opti wheel since it is dot welded to the base on my unit.

So the dtr is used only for firmware updates, For normal use can I leave it disconnected. The bluetooth module will need 5v power to work. I can run the wires inside and make a quick disconnect for the bluetooth and usb module.

For sequence detection I just came up with this brilliant idea. Why not use the high voltage side to ground a pin on #1 to the avr.

Time based is freaking hard to imagine and a feat to get it done without the high end test equipment and code debugging in realtime.
I still have no clue how the pcm is doing it on a hardware level and recently discovered the use of some of the system timers and interrupts which reveal the code flow in the pcm.