I'd think the ignition module more or less has the base of the coil driving transistor connected to that pin.
If you know the resistor in the PCM then it's easy to add an external resistor to create the required voltage divider which lets the pin go to say 4V.
Didn't mean to offend by leaving the ignition module connected, but I always picture myself on the side of the road without help in the ozarks. I usually leave myself a backdoor to reverting these things back so I can make it home in case of emergency....such as keeping the original plug wires and coil in the trunk.
The resistor trick is commonly used to null out offset voltage in oscilloscopes and such. Ancient chinese secret. heh.
We may have to get you an oscilloscope for your birthday. You are far too skilled to be working without one. Keeps the frustration and guesswork down, for sure.
I was mostly being sarcastic - no offense taken. I know all too well what you mean about being stranded on the side of the road in south central Missouri. If this is going on your daily driver you'd be best served by not even removing any of that "legacy" hardware for a few years until we know how this will handle real world conditions. I don't know how much room there is on a b-body but on the y-body I'd rather pull the engine out than to try routing plug wires without removing the left wheel, inner fender and most of the belt driven accessories. And forget about attempting it the side of the road.
It should have occurred to me to try a trim pot Sunday when I was working on the comparator because the project I borrowed the potentiometer from was itself a voltage sense / comparator circuit. Was too busy looking for an "easy" solution and not thinking systematically. I probably spent the better part of an hour digging through parts totes looking for my original (failed) ignition module to hack open in hopes of finding something useful.
I initially thought that myself but there's definitely more to it than that because the module only switches on / sources current through the coil when the EST line is turned off and allowed to float. So minimally there's an inverting input stage there.Originally Posted by lionelhutz
Fingers crossed I hope to finalize the initial circuit design tonight. Once I'm happy that it's doing more or less what it should be doing I'll try to finish the schematic. After that I probably won't be very active on the project until I get the engine out / back in.
If the module is charging the coil while the line is floating then it could be a NPN transistor? It gets turned on when the PCM pull-up resistor is connected to it?
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.
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.
In the interest of keeping the do-it-yourself ethos, I have no interest in using the Atmel toolchain.
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.
That's why as I stated I'm using them very sparsely.
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.
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.
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.
That's why I put pretty much those exact words in the comment header of that function. Examples are welcome.
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.
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.
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.
Last edited by spfautsch; 01-17-2018 at 07:36 PM.
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.
Last edited by spfautsch; 01-17-2018 at 10:58 PM.
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.
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...
Note that spark advance plus dwell is around 122 degrees so that's 32 degrees where two coils would be dwelling simultaneously.Code: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
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.
Last edited by spfautsch; 01-17-2018 at 10:45 PM.
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.
Last edited by kur4o; 01-17-2018 at 11:50 PM.
Posting Permissions
Reply With Quote
Bookmarks