DIY LTCC or similar system for LT1s

[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.

[spfautsch]

Good info, thanks for posting.

... since it is dot welded to the base on my unit.

That's unfortunate. I hope you can get it off without destroying it. Speaking from experience it's very difficult to get whatever stainless alloy they used for these to relax once it's been wrinkled even slightly.

So the dtr is used only for firmware updates, For normal use can I leave it disconnected.

Correct - the DTR line is used to pull the AVR's reset pin low so the programming utility (avrdude) can access the bootloader to upload to the flash.

Why not use the high voltage side to ground a pin on #1 to the avr.

I'm not sure how you're going to get a clean signal from the rotor to one of the cap electrodes - isn't there an air gap between them? Or were you thinking of rigging a hall effect sensor in there?

Time based is freaking hard to imagine and a feat to get it done

I've been bouncing ideas around on how to accomplish time based dwell. I never said it was impossible. It may not even be particularly difficult, I just haven't had the proverbial light bulb come on with an elegant method to implement multiplexing one timer that handles all 8 coils, tracks spark advance (as well as ATDC spark timing), and overlap. The high res timer I'm currently using is just a simple counter timer that runs at a pre-determined divisor of the system clock - 1/64th of 16mhz at the moment. This timer uses a capture interrupt tied to the low res input for a trigger to measure engine speed between the TDC edge signals. There are also two compare registers available with interrupts that can be used with this timer, for instance to initiate dwell. But I'm trying to keep the ideas for this on the far back burner at the moment because I don't want to get too distracted.

I'm currently working on building out the dwell table logic, and I want to get this milestone figured out before moving on. I think the dwell tables will store desired time in a single byte, 0-255. A fixed scalar of 0.048828125 will convert the desired dwell from milliseconds to the raw table value. This gives a maximum of 12.5 ms dwell before MAP and RPM multipliers. I think this will be adequate for all real-world scenarios for all the coils I've tested.