DIY LTCC or similar system for LT1s

[spfautsch]

Doubtful it's a bjt transistor because the PCM isn't sinking any current when the EST line is high. Certainly not enough to drive a bjt into saturation. Maybe an n-channel fet, but my guess is it's a little more complex. If I can find my old one I'll hack it open just for fun.

Whatever the case, it's not an issue. vilefly you're a genius for your impedance matching comment. I was able to do away with the external Schmitt trigger. I had no idea what voltage to shoot for so I took a WAG and adjusted the potentiometer until I was reading 4.29 volts (219 raw) on the adc channel. If anyone has a chance sometime soon I'd like to see what yours reads at idle. See kur4o's post on page 17 for how to measure.

I was able to add ignition supply voltage sensing for the dwell compensation and tested successfully. I still need to look over the controller log for any anomalies, but no DTCs were set and everything seemed to work as expected.

It may be my imagination or the ridiculously cold weather, but it seems like it takes another 90 degrees of rotation before the engine fires. I don't normally run this thing when I can't wear shorts but it seems to be just noticeably longer cranking with the exception of hot restarts. I'll have to test more on this but it does start every time and I haven't noticed any odd behavior.

Current firmware source 0.9.2 now on github https://github.com/spfautsch/diy-ltcc/tree/master

I will concentrate on finishing the schematic, but if anyone wants to start working on a test board before that materializes PM me any questions. The code should be relatively well commented as far as what pins are what, but it's not like a "blink" arduino sketch. Very little of the arduino core libraries were utilized due to the time sensitive nature of the main function blocks.

[dzidaV8]

I've looked through your code, and I have a few suggestions.

First of all, consider loosing Arduino IDE in favor of raw C code in Atmel Studio. I know that INO is easier at first, but has many flaws that make it virtually useless for any real-time, professional use.
To make the project up to industry standards, C code should be used along with MISRA rule checking.
Arduino libraries are great for testing, as they are very universal, but as anything that is universal, they are slow and too complicated for this use. Especially USART functions, which are blocking, and port control functions which are slow.

I can help with porting the code to C and creating a project in Atmel Studio. This would have other benefits than smaller and more optimal code - you could use smaller ATtiny microprocessor.

The Interrupt service routines can be optimized as well, and that's where the timing is critical at high RPM.

Second, all the "populate" functions are unnecessary - all that work should be done by precompiler resulting with ready table in code, without unnecessary initialization routines. Also, such tables should be in program memory, to save RAM.

Third, I'm considered with the table lookup method. The switch-case lookup is far from optimal, but that's not the real issue. Right now, the integer conversion on voltage causes looked up dwell to be the same for 13V and 13.99V. Optimally there should be a interpolation function for lookup. Unfortunately AVRs don't have TBLU instructions, which are so great on Motorolas, but that's not a big problem.

Anyway, I don't want to criticise you in any way, quite the opposite in fact, as this project is growing very fast and looks very promising! If I'll find some time in the evening, I will upload some modifications to the code for you to consider.

[spfautsch]

First of all, consider loosing Arduino IDE in favor of raw C code in Atmel Studio. I know that INO is easier at first,

In the interest of keeping the do-it-yourself ethos, I have no interest in using the Atmel toolchain.

but has many flaws that make it virtually useless for any real-time, professional use.

My opinion may be under-developed here but I think that's an unfairly generalizing statement. Sure, there's a wealth of poorly written example code out there that results in some very sloppy projects, but that doesn't mean all Arduino projects are poorly executed. I'm certainly not innocent in this regard - I have some real stinkers in my code library. I don't feel this one is quite so flawed.

Arduino libraries are great for testing, as they are very universal, but as anything that is universal, they are slow and too complicated for this use.

That's why as I stated I'm using them very sparsely.

Especially USART functions, which are blocking, and port control functions which are slow.

The current serial.print function as of 1.0 and up is non-blocking. And unless something slipped past me, I'm not using any of the Arduino port control functions except in non-time critical areas such as setup(). And those I'm really only using for illustrative purposes.

I can help with porting the code to C and creating a project in Atmel Studio. This would have other benefits than smaller and more optimal code - you could use smaller ATtiny microprocessor.

It's not already C?

I'm not interested in debating which IDE or compiler is used. I'm not a huge fan of either IDE, but the Arduino platform exposes this to much broader audience. My personal opinion is as long as it remains a DIY project I believe it should stay with Arduino / gnu make / avrgcc toolchain. But you're welcome to create your own fork for a different toolchain.

The Interrupt service routines can be optimized as well, and that's where the timing is critical at high RPM.

Second, all the "populate" functions are unnecessary - all that work should be done by precompiler resulting with ready table in code, without unnecessary initialization routines. Also, such tables should be in program memory, to save RAM.

Fantastic suggestions - I would love to know how to do that with the tables. As I've stated previously in this thread I have other projects I want to work on, so discussion and debate isn't nearly as helpful as examples.

Third, I'm considered with the table lookup method. The switch-case lookup is far from optimal,

That's why I put pretty much those exact words in the comment header of that function. Examples are welcome.

Right now, the integer conversion on voltage causes looked up dwell to be the same for 13V and 13.99V.

The integer conversion / rounding happens in the main loop. So 13.49 volts and lower should round to 13 and 13.50 and higher to 14.

Optimally there should be a interpolation function for lookup. Unfortunately AVRs don't have TBLU instructions, which are so great on Motorolas, but that's not a big problem.

Some type of smoothing is one of the things on my list to consider. I really don't know if the benefit is worth bogging down the mcu with the extra math. But I'm open to any ideas you have.

Anyway, I don't want to criticise you in any way, quite the opposite in fact, as this project is growing very fast and looks very promising! If I'll find some time in the evening, I will upload some modifications to the code for you to consider.

Thanks, no offense taken. I'm a self-taught jack of all trades but master of none. This is by far my most ambitious mcu project, and I had to learn quite a lot in the process. I'm in no way ashamed of this one.

I look forward to seeing what you come up with.

[spfautsch]

In addition to the switch case code, one other area I would love to see better ideas on is the main loop. I'd like to have a scheduler mechanism here that prioritizes the dwell routine but have no idea how to implement such a beast. Edit: an idea just crossed my mind for a simple state machine scheduler. Hopefully the thought will evolve. But still open to suggestions.

Also, I fixed a couple bugs I found in the log after uploading 0.9.2 last night. I want to test the changes tonight before I update the repository with it.

[lionelhutz]

What you've got is pretty impressive.

Could the extra starting time be it synchronizing?

What rpm have you taken it to in the car?

Thinking about it more, there is likely a current limiting circuit in the module and the pin is an input to a logic circuit of some sort. But, if the PCM is just a pull-up resistor then finding the right external load resistor to keep the voltage under the fault level is all that is required as you have found out.

[spfautsch]

The extra time could be imagined. I should also add that I haven't started it in ambient temps this cold since swapping to the 42 lb injectors. It's supposed to get into the 50s this weekend so I'll try to make a better video then before I start dismantling.

I seem to recall hitting 3400 a time or two, but honestly I don't really have time to make something to parse the logs.

Edit: oh grep, you're the best regular expression cli utility...

start-run-01-13-5.log:R3400:S31:D91:C6:E0:L0
start-run-01-13-5.log:R3400:S32:D91:C6:E0:L0
start-run-01-13-5.log:R3400:S31:D91:C6:E0:L0

Note that spark advance plus dwell is around 122 degrees so that's 32 degrees where two coils would be dwelling simultaneously.

Steveo, if you're listening there's a hint at an easy feature request for eehack - peak rpm statistic on one of the analyzer tabs would be freaking awesome. Also, if possible it would be great if you could push the latest code out to github so us two or three linux users can compile the current build - isn't it at 4.9 now?

I would really like to get it off the wheel casters and run it, but I don't really have a week to spare to finish building a prototype board. As much as I want to, there's no way I'm going to go out and flog it with that ball of yarn that's hanging out of the breadboards.

[kur4o]

Steveo, if you're listening there's a hint at an easy feature request for eehack - peak rpm statistic on one of the analyzer tabs would be freaking awesome. Also, if possible it would be great if you could push the latest code out to github so us two or three linux users can compile the current build - isn't it at 4.9 now?

The last stable version is 4.7. I am working on some version labeled 4.9 but is far from ready. Anyway my improvement will be only on added mode 4 controls and some clean up of the patches.

[dzidaV8]

I see your point with the DIY-friendly side of Arduino, and probably can agree. You are also right not to make this topic a discussion about pros and cons of different IDEs, so I won't. I just couldn't have helped myself to make that point. :)
I'll work on your code to move more work on precompiler and clean up the lookups when I'll find some spare time.

[spfautsch]

Just so I'm understanding, you're saying you can build precompiler directives that will perform the function of the populate routines so users can edit the following macro definitions / constants and end up with a custom dwell table?

#define DWELL_TGT 4.5       // dwell target in milliseconds - edit to your liking (using 4.5ms for standard ls2 coils)
#define CRANK_DWELL_TGT 3.2 // dwell target for cranking / startup

#define VOLT_COMP_8 2.4     // adds / subtracts from dwell target at given input voltage
#define VOLT_COMP_9 1.5
#define VOLT_COMP_10 0.9
#define VOLT_COMP_11 0.4
#define VOLT_COMP_13 -0.2
#define VOLT_COMP_14 -0.4
#define VOLT_COMP_15 -0.7
#define VOLT_COMP_16 -0.9
#define VOLT_COMP_17 -1.0

Or are you talking about making the tables statically initialized variables like the RPM table?

int rpmReference[RPM_DIVS] = { 25, 50, 75, 100, 125, 150, 175, 200, // the rpm reference
  400, 600, 800, 1000, 1200, 1400, 1600, 1800, 2000, 2200, 2400, 2600, 2800, 
  3000, 3200, 3400, 3600, 3800, 4000, 4400, 4800, 5200, 5600, 6000, 6400, 6800 };

Also, I'm always a proponent of optimizing code but flash and memory resources aren't in short supply at this point.

Sketch uses 9816 bytes (31%) of program storage space. Maximum is 30720 bytes.
Global variables use 1013 bytes (49%) of dynamic memory, leaving 1035 bytes for local variables. Maximum is 2048 bytes.

Lastly, I don't see a point in trying to run this on a lesser mcu. This isn't a project focused on profitability, so saving a dollar or two on the mcu only to limit what can be added in the future seems counter productive. One of the reasons I developed a fondness for the adafruit clones is because they developed a bootloader mod that allows no-wait program startup while maintaining the ability to flash the chip over uart hands-off. This is important - I want the user to be able to update the firmware easily in the same way they can tune flash based PCMs. I also want it to be easily customizable, even if that means something as trivial as the end user printing their name or VIN # to uart on startup.

Latest changes tested and uploaded. Link to github repo is in my signature.

[spfautsch]

Partial schematic interfacing to an Arduino compatible device. Sorry for the bunching on the input side, I'm still learning how to use this drawing soft.

Wire colors on the input side are only confirmed on the Y chassis code. Others may use different colors.

EDIT: schematic removed - will upload to github - see link in sig

The LED + limiting resistor on pin 13 are usually present on all Arduino-like devices so I didn't number them. My ultimate goal is to develop a complete schematic and turn that into a single plane PCB with the Atmega (28 pin dip) directly onboard instead of using the Arduino device as a "daughter board". If that works out maybe we can arrange a group buy for a large quantity.

I'm hoping it's obvious, but just to be safe the the ancillary output circuitry on pin 4 (coil #1) needs to be duplicated for the other 7 cylinders.

Edit: R3 and R4 (the famous impedance matching network) is an approximation of potentiometer measurements from this post that produced ~4.29 volts on the EST line's diagnostic ADC channel. Testing and possible fine-tuning may be required (I can't find a 5.6k resistor in my substantial collection of "stuff").

[spfautsch]

I'll work on your code to move more work on precompiler...

Relative to my question in post #272, if the dwell tables can't be dynamically generated by precompiler directives - the idea crossed my mind of creating another conditional mode of operation to generate the initializers could be a better solution. That way the user could set the compiler directive and customize their dwell targets. Then when the mcu boots in this config mode the populate functions would spit out their customized tables to the uart as static initializers to be pasted directly into the source. That would eliminate the populate functions from being run at bootup in normal mode, shortening start time by 10ms or so, as well as alleviating the need to create yet another external spreadsheet tool to generate the tables.

If I don't hear from you I'm going to code toward that goal as it's a very simple change.

[vilefly]

This is the coil trigger signal from a 2010 5.3L silverado, no open circuits. So technically, we only know that it pulls down to exactly 4V, not sure what open circuit voltage is, due to a lack of time at the end of a friday....so I didn't think to do so...damnit. This engine uses the barrel shaped coils like spfautsch used in his videos.

2010 silerado ign trigger.jpg

So there is no feedback on that signal line to worry about when it comes to this type of coil.
I will venture a guess that a 5V signal suffers a 1v-.8v semiconductor based voltage drop on one leg of a transistor tied to ground.

[spfautsch]

The last stable version is 4.7. I am working on some version labeled 4.9 but is far from ready. Anyway my improvement will be only on added mode 4 controls and some clean up of the patches.

Thanks for the explanation. I'd seen mention of 4.9 in your patches thread and wasn't sure what was going on.

Quick question for you or anyone that might know - I'm relatively sure there aren't any calibrations that call for it, but is it possible for the PCM to command negative (atdc) spark timing? I'm thinking about how to implement some self-diagnostics, and wondered if atdc timing was a possibility for the EST signal.

Lastly wanted to update that I started it four times today, the first round the ECT was at 10c / 50f and it fired right off as did the three subsequent times. I think my longer cranking times were mostly a side effect of my battery getting ready to roll over dead on me. I did have a particularly long crank last night that I'm sure wasn't imagined, but I probably caused that when I yanked the injector fuses to simulate a stall. Ambient was also easily 6c / 10f colder.

[vilefly]

Quick question for you or anyone that might know - I'm relatively sure there aren't any calibrations that call for it, but is it possible for the PCM to command negative (atdc) spark timing? I'm thinking about how to implement some self-diagnostics, and wondered if atdc timing was a possibility for the EST signal.

I think when the ABS is triggered, the ignition timing could be retarded that far, but I have no proof. Would have to scope/datalog during an ABS stop. If it were a chrysler, it would happen between shifts, but not in the case of a 90s chevy.
Interesting question. Did you have some kind of misfire detection based on a second spark strike attempt by the ecm in mind?

I do know that most misfire detection is based on degrees of crankshaft acceleration after spark. (deg/second,etc)
I might have an opportunity tomorrow to scope a 2010 chevy truck ignition "fire" signal to a coil. What I am looking for is feedback or no feedback on the line. Some coil drivers provide feedback on the "fire" line, with a magnitude of 5v max, which allows the "burn time" from the secondary side to be measured and compared to the rest off the cylinders.

[spfautsch]

I think when the ABS is triggered

Good thinking - I didn't realize ABS used torque limiting but that got me thinking about ASR. I took a look at the traction control table and I think it's possible to have a condition where negative spark advance could be commanded.

Can anyone confirm the correct scalar for the 0x123A1 table? I have some xdfs with (0.062500 * X) and some with (0.250000 * X). If 0.0625 is correct there are only a few essentially "unreal" load ranges where negative timing might be commanded such as at 400 rpm and 100 map. If the other one's right there's a significant range.

Did you have some kind of misfire detection based on a second spark strike attempt by the ecm in mind?

Sorry, nothing quite that ambitious. In it's current state I would characterize the maturity of the code as "nearly mastered crawling". I merely want to add some minimal failsafe logic so if the controller doesn't see a signal on the EST line in x amount of degrees it considers it a system fault and shuts everything down. That way if the EST circuit does happen to get broken it doesn't dwell more coils than the IGN circuit fuse can tolerate. Additionally, I didn't account for the possibility of negative spark advance so it could cause unexpected behavior if the PCM were to command it.