Hmmm, ok, these uneven pulse rates on the CAS seem to be an effort to compensate for slow micro-controllers...
If I take the hardware side of this further, I would have to replace the CAS with something more useful, also the injector wiring would have to be replaced to get sequential injection... while I'm at it, I might as well replace the MAS with a MAP... This is far more than I wanted to do... I'm a software guy really :) Ok, I guess what I want now is a diagram showing the piston no.1 position vs the CAS pulses for the NA (pre '93)... that way I can adjust my model to get it's timing from the original CAS. Note: I discovered how noisy a car's electrical system is during my investigation regarding the throttle servo project I mentioned earlier. I decided to use a standard HItech HS422 servo (not ideal for the hot, dirty environment of a car engine bay, but can be easily protected, is very powerful and is very cheap). And I had to resort to shielded cabling and a simple low pass filter algorithm on my sampling code (the AVR328 is a powerful beast) to reduce the electrical noise on the analog lines to an acceptable amount... |
It is de rigeur in system design to bandlimit signals using analog lopass filters, to only the bandwidth you need. Translation: put an RC lopass filter for the signals that come from the outside world, at the entrances of your board. Spec the time constants so the rise times are only a bit faster than what you need, e.g. 15 uS for crank signals, because that's half a crank degree at 7500 RPM.
Even output signals should be bandlimited. For example, my Arduino board generates signals for my factory ECU crank input. The Arduino will put out pulses with rise times of only a few uS. Because the wire that carries this signal runs in parallel to the input from my crank sensor, a fast rise time on this wire will couple noise into my crank input. So I bandlimited it to ~20 us with an RC lopass. |
Originally Posted by neogenesis2004
(Post 633542)
I agree with Joe on the lack of interrupts. To me it sounds like they are saying, "since you have 8 cores, there is no need for interrupts because you have so much more resources to waste polling inputs!"
To wit: the problem with multiple interrupts is: - it's hard to determine how many clock cycles are used up getting in and out of the interrupt routine - while in the interrupt, what if another interrupt occurs? This is another layer of complication It is far easier to architect the system where you have a core dedicated for each time critical operation. It is also more predictable. For example, ignition timing needs 10 us accuracy. That's not a lot of clock cycles for a midrange uC. You guys are used to, and wedded to, the idea of interrupts. I am now re-entering the world of uC's, so I have less bias than seasoned uC programmers, one may say. |
Originally Posted by JasonC SBB
(Post 633963)
It is de rigeur in system design to bandlimit signals using analog lopass filters, to only the bandwidth you need. Translation: put an RC lopass filter for the signals that come from the outside world, at the entrances of your board. Spec the time constants so the rise times are only a bit faster than what you need, e.g. 15 uS for crank signals, because that's half a crank degree at 7500 RPM.
Even output signals should be bandlimited. For example, my Arduino board generates signals for my factory ECU crank input. The Arduino will put out pulses with rise times of only a few uS. Because the wire that carries this signal runs in parallel to the input from my crank sensor, a fast rise time on this wire will couple noise into my crank input. So I bandlimited it to ~20 us with an RC lopass. |
Originally Posted by bloodline
(Post 633920)
Hmmm, ok, these uneven pulse rates on the CAS seem to be an effort to compensate for slow micro-controllers...
Without the two CMPs, you'd have to wait up to a maximum of two full crank rotations before a CMP pulse came around in order to start firing the ignition. The speed of the CPU has no bearing at all on any of this. A quad-core i7 would still have to wait up to two full crank rotations before it could begin operating the ignition if there were only one CMP pulse per cam rotation. If I take the hardware side of this further, I would have to replace the CAS with something more useful, also the injector wiring would have to be replaced to get sequential injection. Now, I do recommend replacing the CAS with a crank-triggered pickup, but only because the flex of the timing belt causes a lot of spark scatter. Nothing at all to do with batch vs. sequential. Ok, I guess what I want now is a diagram showing the piston no.1 position vs the CAS pulses for the NA (pre '93)... that way I can adjust my model to get it's timing from the original CAS. |
Originally Posted by Joe Perez
(Post 633971)
I don't see why you think this. The uneven-pulse design allows you to have fully sequential injection while reducing the time it takes for the ECU to sync up while starting. You fire the injectors in full-batch mode while cranking (every injector on every CKP pulse) and then you only have to wait a maximum of one crank rotation to get a CMP reference so you can start firing the ignition.
Without the two CMPs, you'd have to wait up to a maximum of two full crank rotations before a CMP pulse came around in order to start firing the ignition. The speed of the CPU has no bearing at all on any of this. A quad-core i7 would still have to wait up to two full crank rotations before it could begin operating the ignition if there were only one CMP pulse per cam rotation. for 0 degrees rotation, Signal A and Signal B would be HIGH. For 90 degrees, Signal A would be LOW and Signal B would be HIGH. For 180 degrees, Signal A would be HIGH and Signal B would be LOW. for 240 degrees, Signal A would be LOW and Signal B would be HIGH. This way you would only need a single interrupt on Signal A (testing the B signal in the interrupt service routine, if B is HIGH then we are at 0, if it is LOW we are at 180), to establish where you are in the cycle, i.e. only one crank rotation. Wouldn't this work? Nope. '94 to '97 MX5s have full sequential injection and they use this same CAS. Read what I wrote in my last post more carefully. Also, I'm stuck with my '91 engine... so unless I replace the injector control hardware/relay board I'm stuck with batch injection. Now, I do recommend replacing the CAS with a crank-triggered pickup, but only because the flex of the timing belt causes a lot of spark scatter. Nothing at all to do with batch vs. sequential. http://i264.photobucket.com/albums/i...ild/timing.jpg |
Originally Posted by bloodline
(Post 633975)
I would, instinctively, do it slightly differently...
My perspective on what you've described relative to the 4G63 design: 1: Assuming you are speaking of degrees at the camshaft, your design treats both the rising and falling edges of "Signal A" as triggers. Bear in mind that many (if not most) microprocessors can only see one side of a transition on their IRQ input- IOW, they can only see a falling edge or a rising edge, but not both. 2: If you were speaking of degrees at the crank, then your solution doesn't allow fully sequential injection. 3: It is desirable to have both a rising and a falling edge on the primary trigger for every ignition event. In the 4G63 design, the rising edge occurs at 75° BTDC, and the falling edge at 5° BTDC. The 75° BTDC edge is the primary trigger during normal operation, giving the timer plenty of room to achieve full ignition advance plus dwell. The 5° BTDC edge is used as an absolute reference for the spark event while cranking over on the starter, when RPM is too low and crankshaft angular velocity too unstable to accurately compute an ignition angle from 75° away. (Note that in #3, I am speaking of degrees at the crankshaft.) Also, I'm stuck with my '91 engine... so unless I replace the injector control hardware/relay board I'm stuck with batch injection. |
1 Attachment(s)
See my Arduino interface schematic.
Opamp circuit is a lopass filter to convert PWM output into a DC voltage for the AFM input of the factory ECU. The Schmitt inverter circuit is the input filter for the incoming 12-1 CKP signal. The RCRC circuit is the input filter for the MAP sensor signal. The 330 ohm / 33 nF filter is to filter the Arduino output which goes to the CKP input of the factory ECU. |
Originally Posted by JasonC SBB
(Post 633968)
To wit: the problem with multiple interrupts is:
- it's hard to determine how many clock cycles are used up getting in and out of the interrupt routine If you mean how long it takes to actually run the interrupt routine, that's important regardless of architecture. Let's look at how a Prop might be configured to do the job of an MS. We dedicate one cog to be the interrupt handler. Whatever time-critical activity the interrupt routine is doing must be executed on the same cog that's detecting the interrupt. There's no way for one cog to "interrupt" another, so you have to perform the whole interrupt routine on the interrupt cog, which, as you said, means you have to be certain that the whole interrupt routine "fits" into the window between interrupts, including the time it takes for the interrupt cog to write data into main memory so that the other cogs can read it. (Even the non-time-critical cogs need to know what the engine RPM is and what phase the crank is in.) - while in the interrupt, what if another interrupt occurs? This is another layer of complication Unless, of course, you are referring to a system with multiple interrupts, like a general-purpose PC. In that case, you handle the high-priority interrupt first, then service the lower-priority ones. But for an ECU, one IRQ is all you need. (Assuming your engine only has one crankshaft, which I think is a fair assumption.) You guys are used to, and wedded to, the idea of interrupts. |
No, you dedicate one cog to do crank angle prediction / ignition. It continually polls the CKP and CMP, calculates crank position, and outputs the coil signals. It reads the desired timing from a shared mem location, which is updated by another cog. This way this cog does one task, and does not need to be interrupted by any, more important tasks.
Another cog does the same for injection. And so on. No interrupts necessary with this architecture. |
Originally Posted by Joe Perez
(Post 617443)
Just wish they'd fucking let us see the fucking schematics for the fucking MS3 and the fucking MS3X that they've been keeping so fucking secretive on fear that some fucker will clone the fucking thing, with no regard for all the fucking people out there who don't give a fuck about copycats and just want to be able to properly optimize their fucking I/O circuits.
Fuckers... Ken |
Originally Posted by neogenesis2004
(Post 617645)
The MS3 is 32bit so the comparable Atmel chip would be from the AVR32 family.
For those who care, its the MC9S12XEP100, has 1M of program flash, 32k of data flash, and 64K of RAM. We use the data flash for all our tuning data currently. Ken |
Originally Posted by muythaibxr
(Post 634014)
Regardless of F-bombs, B&G seemed open to NDA for those who really need to see the schems. It's not really up to James and I though.
Just needed to get a few things off my chest. I'm sure that when the time comes for my next ECU, the MS3 I/O circuits won't be terribly difficult to reverse-engineer. I just hate having to spend the time to do it. |
The 32bit thing was just a shot in the dark guess. I didn't actually Google it back when I posted that.
|
After studying the Timing diagrams provided by Joe, I found it quite easy to rewrite my synchroniser code and timing interrupt to work using the output of the standard CAS.
I was then able to run a simulation, using the following Ignition timing table: RPM BTDC 500 10 1000 10 1500 12 2000 17 2500 22 3000 24 3500 28 4000 28 4500 31 5000 34 5500 36 6000 36 6500 36 7000 36 Which I believe is the stock timings... Are these any good? I would appreciate better ones. Anyway during my simulation, I hit a big snag with the Arduino. The analog acquisition time is 100microseconds per analog pin (using the standard library), which at 8000rpm is about 5 degrees of crank rotation. There simply isn't enough "dead time" in the cycle, in order to acquire the TPS and the Air flow. I think I will have to write my own analog code that will read asynchronously, any better ideas? -Edit- Actually, after playing around with it a bit, I think blinding the code for 10 degrees once per 2 crank revolutions isn't too bad, and that only happens at the VERY top of the engine's running speed... I don't think I've ever taken mine over 6000RPM... maybe once... -Edit 2- Here is the output of my current simulation; In this simulation the ignition fires at 10d BTDC and the injector open time is 90d of crank. I currently only check the cam position signal once, during startup to determine which CKP pulse is next, after that, all timings are derived from the CKP via an interrupt... http://www.cutiemish.com/OneCycle.jpg Changes made to this model mean that that the crank angle now determines the position in the cycle, the units on the x axis are 10ths of a degree. At 1000RPM, there are 170 microseconds per degree of crank rotation. |
I like where this thread is going, gonna keep an eye on it
|
Ok, to solve the Analog acquisition time problem, I decided to start the acquisition just after TDC of cylinder one then waiting to continue execution until the Cam signal goes low, that gives me at least 490micro seconds (at 8000RPM) to acquire my analog readings (plenty of time) :) and also I know that the crank angle is 49deg at that point so I remain synchronized.
I know that overlaps with my injector timing, but frankly they are just junk at the moment until I get more info on how injectors work. Note, I'm only timing from the falling edge of the CKP... I might time from both the rising edge and falling edge if I need more accuracy :) |
Originally Posted by bloodline
(Post 634154)
The analog acquisition time is 100microseconds per analog pin
A few things to consider... What are you planning to use TPS for? In a forced-induction application, MAP (or airflow) are considered be some to be a more useful predictor of load for the purposes of accel enrichment. So if you're only going to sample it for things live overrun or idle threshold, it's not necessary to sample it every single cycle. You could probably do a round-robin scheme with the analog inputs, one per cycle, such as: 1: Airflow 2: TPS 3: Airlow 4: CLT 5: Airflow 6: IAT 7: Airflow 8: O2 9: Airflow 10: TPS 11: (...)
Originally Posted by bloodline
(Post 634175)
I know that overlaps with my injector timing, but frankly they are just junk at the moment until I get more info on how injectors work.
If you're going for full sequential, the injectors should be timed such that the end of the fuel spray always occurs at the same point in the cycle, some distance before BDC on the intake cycle for a given cylinder. Note, I'm only timing from the falling edge of the CKP... |
Originally Posted by Joe Perez
(Post 634203)
Does this mean that the processor is essentially stalled for that entire time?
A few things to consider... What are you planning to use TPS for? In a forced-induction application, MAP (or airflow) are considered be some to be a more useful predictor of load for the purposes of accel enrichment. So if you're only going to sample it for things live overrun or idle threshold, it's not necessary to sample it every single cycle. You could probably do a round-robin scheme with the analog inputs, one per cycle, such as: 1: Airflow 2: TPS 3: Airlow 4: CLT 5: Airflow 6: IAT 7: Airflow 8: O2 9: Airflow 10: TPS 11: (...) If I still want a throttle servo, I'll need to serve it at least every 40milliseconds :) They contain a coil of wire which forms an electromagnet. You pass current through them, and some period of time later they start flowing fuel. You remove the current, and some period of time later they stop flowing fuel. If you're going for full sequential, the injectors should be timed such that the end of the fuel spray always occurs at the same point in the cycle, some distance before BDC on the intake cycle for a given cylinder. For spark prediction? This means that, on average, you will have nearly half a full crank revolution elapse while the timer is running. |
Originally Posted by Joe Perez
(Post 634203)
Does this mean that the processor is essentially stalled for that entire time?
|
All times are GMT -4. The time now is 04:30 AM. |
© 2024 MH Sub I, LLC dba Internet Brands