Yet another attempt at EFI with P8X32A.
abecedarian
Posts: 312
Good day all!
Background-
I've looked at other MCU's and think I want to try Propeller because it seems more feasible. And yes, I've read most of the other related / similar posts and see few have come to public fruition. I think this one could be different because it's not aiming at 8 or 12 cylinders, but rather two... could probably do 4 if batch fire injection / ignition is used.
Engine (some people have probably come across my posts elsewhere):
- 80 degree, 2 cylinder, 4 stroke motorcycle with turbocharger- CX500TC. Bike has separate injection and ignition controllers and I want a unified system that can be tuned.
Planned sensors / components:
- use a 5v / 5a supply based around TPS54560
- MPX4250A MAP sensor & possibly barometric sensor;
- stock intake air and coolant temperature sensors;
- stock throttle position sensor;
- stock single tooth cam trigger wheel and variable reluctance sensor;
- 32 tooth crankshaft trigger wheel and variable reluctance sensor from the bike's GL/CX cousin;
- external ADC to sample sensors (no chip selected yet);
- cam and crank sensors sensed by MAX9926 and processed by separate COGs;
- 2 LM1949 peak and hold injector drive controllers;
- 2 low-side drivers to switch Delphi D514A ignition coils: require logic level 5ms pulse to fire.
- maybe add wide-band O2 at some point.
My thoughts are:
- one COG detect the VR sensors and work out RPM and crank position;
- one COG sample the ADC, maybe do some math;
- one COG trigger ignition / injection;
- one COG to run a display / dashboard.
It looks like the I/O pin usage will be:
- 2 for VR sensors;
- 2 each for ignition and injection;
- 3/4/5 for ADC depending on the chip and configuration.
- 15 pins, max, including display sounds right?
Treating the engine as 720 degrees, due to single cam signal and no missing crank teeth, there would be two injection and two ignition events over the entire process. Keeping a tooth counter going and using a timer to interpolate teeth between real teeth, it seems timer matches could initiate / end events.
I'm open for any suggestions, good or bad.
For what it's worth, I have no experience with Parallax products so be kind.
Background-
I've looked at other MCU's and think I want to try Propeller because it seems more feasible. And yes, I've read most of the other related / similar posts and see few have come to public fruition. I think this one could be different because it's not aiming at 8 or 12 cylinders, but rather two... could probably do 4 if batch fire injection / ignition is used.
Engine (some people have probably come across my posts elsewhere):
- 80 degree, 2 cylinder, 4 stroke motorcycle with turbocharger- CX500TC. Bike has separate injection and ignition controllers and I want a unified system that can be tuned.
Planned sensors / components:
- use a 5v / 5a supply based around TPS54560
- MPX4250A MAP sensor & possibly barometric sensor;
- stock intake air and coolant temperature sensors;
- stock throttle position sensor;
- stock single tooth cam trigger wheel and variable reluctance sensor;
- 32 tooth crankshaft trigger wheel and variable reluctance sensor from the bike's GL/CX cousin;
- external ADC to sample sensors (no chip selected yet);
- cam and crank sensors sensed by MAX9926 and processed by separate COGs;
- 2 LM1949 peak and hold injector drive controllers;
- 2 low-side drivers to switch Delphi D514A ignition coils: require logic level 5ms pulse to fire.
- maybe add wide-band O2 at some point.
My thoughts are:
- one COG detect the VR sensors and work out RPM and crank position;
- one COG sample the ADC, maybe do some math;
- one COG trigger ignition / injection;
- one COG to run a display / dashboard.
It looks like the I/O pin usage will be:
- 2 for VR sensors;
- 2 each for ignition and injection;
- 3/4/5 for ADC depending on the chip and configuration.
- 15 pins, max, including display sounds right?
Treating the engine as 720 degrees, due to single cam signal and no missing crank teeth, there would be two injection and two ignition events over the entire process. Keeping a tooth counter going and using a timer to interpolate teeth between real teeth, it seems timer matches could initiate / end events.
I'm open for any suggestions, good or bad.
For what it's worth, I have no experience with Parallax products so be kind.
Comments
Amphenol Ampseal connector and QuickStart board mounted underneath.
5v/5a power supply with TPS54560 regulator shown.
U1 is 8 channel, 12 bit, I2C ADC; U2 is MAX9926 VR detector.
Also shown is the trigger wheel and pickups going on the crankshaft.
Just noticed JP2 is off a bit, should be lower on the board. Will correct next revision.
I'll try to relate some general (not directly Prop processor related) issues to be aware of. Especially for a first version, it would be advisable to place the injector and ignition drivers on a separate board and trigger them with fast optoisolators. The EMI from the power parts is difficult to decouple from the logic parts. Meticulous attention to providing good, clean power and good, clean sensor data acquisition by avoiding ground loops, dedicated sensor ground on the logic board, etc. The regulator you speced looks nice. I like the LM1949s a lot - I own and operate a gas fuel injector flow testing and cleaning company and use them for hours on end for all kinds of injectors - 1.0 ohm PWC injectors on up the usual HiZ run of the mill products. I use an injector drive PCB module from jbperf.com - LM1949 drives TIP120 with active flyback management. A Prop Project Board running PropGCC code runs the whole deal interfacing with a laptop app that commands the period, pulsewidth, etc. then stores the results in an SQL database.
Prop related issues to consider are what language are you intending on writing in? I ended up using PASM for the wheel decoding, injector and ignition pulse driving and Spin for the rest. Were I to do it again I would use PropGCC. There is an enormous amount of MIT, GPL and open source C code available for lots of little algorithms that are either difficult or too large for PASM or too slow in Spin - bilinear interpolation for table lookup, etc. You may want to consider the Project Board instead of the QuickStart - lots of room on the prototype area and several options for accessing the pins - ribbon, solder in your choice of connector, etc. You may want to look at MCP3208 for an ADC - it's not the latest or greatest but meets your needs. 8 channels may be more than you think you need but on a turbo application it can be nice to log pre and post compressor and/or turbine temps, perhaps look into chemical intercoooling, etc. Please excuse my train of thought writing here - I'm battling autocorrect on an iPhone to write this... :-)
Treating the engine as a 760? It's still 720 for a full four stroke cycle. I'm guessing you're doing this to compensate the 80 deg twin aspect? That's not typically how it's done but i'd like very much to see you expand on your algorithm.
I am revising the board as I add components, you know the deal, and am isolating the grounds as much as possible so that there will be analog, digital and power sections, likely tied together at the Ampseal connector.
I have thought of doing the injectors on a separate board but not ignition since the coils I'm going to use are the LS2 type so only logic level signals are transmitted. I've seen the jbperf module but since I only need two injectors I'm re-inventing the machine. Heck, I might even make the injection section a separate, external module.
Don't worry about the thought train. I understood it.
I haven't thought much about the language; been more interested in getting the hardware settled so I know what I'm dealing with.
I'm leaning towards the MAX11614 for ADC. I like the pin arrangement. It's a little slower than what you propose and it's I2C. Also I'm wiring the four additional / unused inputs to the connector so they're there if I want them.
Thanks for pointing out my 760 error; corrected in OP.
Algorithmically, I haven't settled on anything quite yet but the thought was to use a timer to measure tooth intervals and implementing a tooth counter that would reset with the cam signal- the cam signal is at TDC compression for #1 cylinder. I would end up with 64 teeth over 720 degrees giving 11.25 degrees between tooth centers. A second timer would run and reset on each tooth event and I should be able to interpolate position between teeth with that using the last tooth interval to predict the next tooth interval. With a fast-enough timer, resolving better than 1 degree should be possible. I could then generate an arbitrary number of virtual teeth that could be used to trigger ignition. For instance, assume base timing is 23 BTDC. That would be the same as on the 2nd tooth before 0. So once I have cam sync, cylinder 1 would fire on real tooth count 62. I know, approximately, the stock advance curve and how it relates to things so I'd do the degree-to-tooth conversion on the computer and store that in the unit.
Injectors, not sure, but I think it could work similarly, opening on 'one' tooth and closing on 'another'.
*side-note: the stock ignition system didn't have any concept of RPM integrated into it, i.e. no mechanical advance per se. Advance was determined by manifold pressure. So if manifold was at 0, timing is base timing and advanced under vacuum and retarded under boost; 1 degree retard for each 1 PSI boost.
Still to do: place and route the ignition components; complete VR sensor routing to the header; maybe put on a BMP180 for barometric pressure sensing; work out how to get signals to the dashboard for tach and such- probably just serial out data to another controller for the VFD's I'll be using. Then it's off to code land.
This is more of a one-off thing I've been forced into because the fuel injectors on my bike are not salvageable and they are NLA- 330 cc/min low-impedance type, not manufactured since 1982 and re-flashing the chip is not an option. The stock ECU doesn't control ignition either so I want to get that under my control too. There is one, maybe two people interested in something for their CX turbo bikes, they race a Bonneville, and a few others interested for CX N/A bike conversions, but beyond that not much interest. That's not to say though that if something works it won't gather interest but at this point it's for me alone.
Why do you ask?
I can get a powercommander v with boost control to retard ignition timming. Even that's 500 dollars
With proper programming I don't see why this wouldn't work on a Harley if the triggers and stuff can be worked out. And I've sourced many of the parts like the regulator & LM1949 (got 3 each), and MAX9926 (got 6) from the manufacturers as samples so no cost.
If you're interested in collaboration, I'm up for it. And I'm not in a hurry to get this complete- the bike is being gone through at my leisure.
Which reminds me that I need to add battery voltage compensation.
-Mike
I was fairly confident that was a decent way to do the teeth. That's basically how the eTPU in some of FreeScale's processors work, except they speed up and slow down the timer to compensate, i.e. if a tooth comes before the expected timer match, the timer is sped up during the next tooth interval, and likewise slows if the tooth comes later than expected. You probably know that.
For fuel, I was planning a 2d table MAP vs RPM, with 1d coolant temp and recently added battery voltage compensation; I'm not convinced I need barometric. In the future I might add WBO2 but not sure how I want to do that.
For ignition, I haven't quite decided but it would make sense to have it referenced to MAP and RPM- that would give me more control than the stock system gave, which was zero.
It's hard to see on the board I posted but there's a 33v/5w Zener near the edge of the board 'under' the TIP leads. I couldn't find a part in the lib that had the TIP vertical so I improvised.
Thanks for the cleaning offer but I don't have injectors at the moment. My old injectors were 330 cc/min 2 ohm but sat for a while (10 years) and only cleaned up to 240 cc/min, and good used injectors come up about once every-other-third blue moon- they were only used on the CX500TC and CX650T cycles and there's no known cross-over part. Some people have tried to convince me I can get away with high-impedance injectors but I'm not confident in the idea. The closest RC sells are 310 and 370 saturated, and the bike idles at 34 PSI fuel pressure and at full boost (20 PSI) FP rises to 65 so I've little room to compensate there. I'd have to double check but I seem to remember that at idle the injector pulse width was just under 2ms with the low-z injectors. If you have any suggestions, I'm all ears.
-Kirk
-Mike
Compensations:
- coolant temperature compensation table (1d), spanning from -7C to 120C in 4 degree increments- using an array containing 32 signed values. 0.5KB
- battery voltage compensation table (1d), spanning from 7V to 15 in 0.25 volt increments- using an array containing 32 signed values. 0.5KB
* - these will be values added or subtracted from the fuel duration.
Ignition mapping:
- RPM based advance from 200-6600 RPM in 50 RPM increments, using an array containing 128 unsigned values. 1KB
- MAP based advance compensation from 20-250 kPa in 2 kPa increments, using an array containing 128 signed values. 1KB
* - these basically emulate traditional centrifugal and vacuum advance functions
Fuel mapping:
- What I want is RPM x MAP table (2d) with RPM ranging from 400-10000 in 75 RPM increments and MAP ranging from 20-250 kPa in 2 kPa increments, using an array of 128 x 128 unsigned values, but that's 32K right there. If MAP changes to 4 kPa increments, that halves the array to 16K, which seems more manageable.
So, it seems I'd be at ~ 19KB so far- leaves a fair chunk for working variables and such. I'm happy with this, I think.
Regarding sample rates of sensors:
- TPS changes quickly so should probably be sampled as often as possible.
- MAP will change most frequently but the sensor itself as a maximum 1ms settling time so should be sampled at nearly the same rate, though under boost will likely not need sampled so frequently.
- IAT should probably be sampled at least 4 times per crankshaft revolution.
- CLT should probably be sampled at least once per 2 crankshaft revolutions.
- Battery voltage should probably be sampled at least once per 2 crankshaft revolutions as well.
Comments welcomed.
Also added a jumper select for on-board or external MAP sensor.
Yes, it's not complete, yet, but it's mostly done save for routing a few traces.
Thoughts?
Now, am I correct in assuming there is a short wait period when the unit powers up where it checks for connectivity to the built-in FTDI / USB interface lasting around 4 seconds, and there is basically no way around this?
If so, I'll need to add some more things such as a start switch disable or maybe an automatic start that is also tied to the clutch / neutral safety switch, such that pressing the "START" button immediately after powering up doesn't crank the engine until 'booting' is complete and either the clutch is pulled or the engine is in neutral. It would be a waste to use analog inputs to sense a switch so maybe I should re-purpose the digital outputs somehow... or maybe a change in the connector from Ampseal 35 to something else, with more terminals.
On the other hand, using a vertical Ampseal instead of the right-angle connector could let me move some things around and get better access to the 3rd row of pins.
Anyhow, still doing tweaks and things to the board so I'll post Eagle files for the board and schematics when I'm somewhat happy with it.
And thanks to pmrobert for sending the code snippet he had available. Looking it over has, and still is actually, helping me get a good idea of how to store data in the eeprom. I don't know if he's shared it so I'll reserve posting what little tweaks I did, probably done incorrectly though, pending his comments.
I've mocked it up on some perfboard and it's nearly dead nuts 4 inch by 3 inch, with the Prop QS stacked above this board, in the lower left, obviously.
The enclosure I'm looking at is this one, which is 1.69 (H) x 3.15 (W) and 4.33 (L)... nearly perfect... or at least close enough I can fudge the board's size.
*edit-
Forgot to mention that there is nothing under 3 of the 4 holes the QS would use to secure it to the lower board. One of the transistor chips is close enough to one hole to interfere but it can be moved without issue, and I plan to do that.
Default I2C SCL (P30), SDA (P32) lines for ADC, reading MAP, IAT, TPS, CLT, two user-defined analogs and 12v system and 5v system voltages.
- might need to be moved since some data will be on the onboard EEPROM and things may result in access contention.
P24 - cam position sensor trigger.
P26 - crankshaft position sensor trigger.
P1 - injector 1 output.
P3 - injector 2 output.
P16 - ignition 1 output / LED on QS board
P18 - ignition 2 output / LED on QS board
P20 - user defined output 1 / LED on QS board
P22 - user defined output 2 / LED on QS board
Planning to open up the lower left of the board for prototyping use. Thoughts?
PEFI_R0.4b.sch | PEFI_R0.4b.brd
P16 = Injector 1 = LED P16 (Injector 1 trigger out)
P17 = Injector 2 = LED P17 (Injector 2 trigger out)
P18 = Ignition 1 = LED P18 (low current 5v out)
P19 = Ignition 2 = LED P19 (low current 5v out)
P20 = User 1 = LED P20 (low current 5v out)
P21 = User 2 = LED P21 (low current 5v out)
P22 = CAM signal = LED P22
P23 = CRANK signal = LED P23
Attached the Eagle files this time so someone can comment on values and such, considering that no one has really said anything regarding the circuitry.
Still working on the algorithms and interpolations.
Please comment.
Thanks,
Kirk
I have a Buell with fuel injection and there is some interesting reading at ECMspy.com regarding what compensations are made to the basic map. Things like cold start enrichment, acceleration enrichment, battery voltage, engine temp etc... It sounds like you have a good handle on what you need, but there may be something there that you find useful.
Unlike your system, the Buell ECM is TPS based. I think it is commonly referred to as alpha-n control. I think the Buell system is pretty well mapped on my bike. The only exception being just off-idle - there is a bit of surging at times.
Anyway, good luck with your project - I'll be reading along.
-Russ
I have an approximately 3.125" x 4.0" board to work with, based on the interior dimensions of the enclosure I previously mentioned.
Now... DIP or LQFP? Seems LQFP only adds 2 VDD / 2 VSS connections, correct?
So, about that single board design... any suggestions for memory and other things? USB for monitoring and configuration is a given but should I also include USB for firmware updates or use Prop-plug?
I'd thought about wireless / Bluetooth for monitoring but it's an aluminum enclosure so wouldn't be too RF friendly without an external antenna.
And should I have the ADC on a different IIC port / cog than the eeprom? That seems like a good idea, to me at least, so ADC reads don't block memory reads.
I wonder....
Live tuning implies immediate commits to RAM and when finished, a commit to the EEPROM, correct? So a supervisory type system that can update HUB ram, and then commit to EEPROM seems a necessity?
I'm only asking; don't shoot me.