Well, I think this might be the one. But, I'm open to comments or suggestions.
I decided to keep the QS board for now. Still have to set mount holes so there may be some slight re-routing but most everything's there, except ISO9141 / OBD stuff, but that's only a couple discrete components, connector, connection to header and code.
Supported external devices:
2 high impedance injectors; low impedance with external drivers.
2 logic level ignition triggers; inductive coils with external drivers, including current sense / fault detection if drivers support it.
1 O2 heater (HEGO) control with current sense / fault detection. Can be disabled in software and used as other type driver.
2 Relays. I.e. one for 12v out to injectors / ignition, one for fuel pump.
1 Tachometer output.
1 Indicator lamp. This is driven by MCU so can be used for anything including driving another relay or such.
3 VR sensors. One for crankshaft position; 2 for camshaft position. I'm using 2 camshaft sensors because my bike has two, therefore I can track each cylinder position independently.
1 Key switch position. Since the unit is permanently connected to the battery, this allows the unit to execute a power-off routine prior to full shut-down.
1 Protected 5v0 out for external sensors: short to ground, short to battery.
7+1 ADC channels: manifold pressure, throttle position, air temp, coolant temp, O2 sensor and two 'extra' channels plus 12v system voltage.
Pin assignments / type / description:
P1 / P3: I2C, SCL & SDA for ADC
P10: Supervisory, Propeller control to enable logic / voltage level translation on the following-
P16-P17: Output, Relay 1 & 2 control (on / off)
P18: Output, O2 sensor heater control (on / off)
P19-P20: Output, Ignition 1 & 2 control (on / off)
P21-P22: Output, Injector 1 & 2 control (on / off)
P23: Input, Key switch position indicator (on / off)
(Conveniently, the above correspond with the LED's on the QS board so there is visual indication things are working. )
P27: Supervisory, Propeller control to enable logic / voltage level translation on the following-
P12-P13: Input, VR sensors 2 & 3 (cam shaft position for two cylinders)
P14: SPI, chip select for MC33814
P15: Input, VR sensor 1 (crankshaft position sensor)
P24: SPI, SCLK for MC33814
P25: SPI, MOSI for MC33814
P26: SPI, MISO for MC33814
RIN: Supervisory, RESET (inverted) from MC33814 to Propeller
Did you ever get the algorithm for interpolation engine position working?
I've been busy batting my head against the wall on the hardware side and pmrobert has been doing the coding so far: MAP and other sensor look-ups and the tuning / GUI interface.
When I'm happy with the board, I'll have to make another board to simulate the sensors so I can start hitting my head against the code.
I think, really sometimes I do , I'm getting close.
Some thoughts. I'd bring any unused propeller pins out to a through hole header with ground and power nearby. This makes quick fixes/additions much easier. Second, just build one! As my grandpa says, "once you build a prototype, the janitor can tell you how to make it better"
Not sure what it means, but I have 4 unused Prop pins.
Programming / tuning / debug is already handled over FT233RL USB interface.
The breakdown is:
SPI 'channel' for MC33814
I2C 'channel' for 64-128KB EEPROM
Control over 2 external relays for power distribution and fuel pump via toggling 33814 pins
Tachometer output from 33814 pin
Status / MIL lamp from 33814 pin (controlled by Prop)
Secondary SPI channel (controlled by Prop):
8 buffered ADC channels; 6 with 0-5v support, 2 with 0-12v (through voltage divider / Zener clamp):
0-5v: MAP, TPS, IAT, CLT (intake air and coolant temp), O2, one user defined
0-12v: battery voltage, one user defined
2 high impedance injector outputs (controlled by Prop toggling pins on the 33814 chip)
(low Z injector supported with external peak-and-hold drivers, fault monitoring can be supported with appropriate code
2 logic level ignition drivers (controlled by Prop toggling pins on the 33814 chip)
LS1/LS2/D514A or similar supported
inductive coils supported with external IGBT drivers
fault monitoring for IGBT can be supported with appropriate codeO2 heater control
HEGO / narrow band O2 / Lambda sensor support (heater controlled by Prop via SPI and toggling pins on the 33814 chip)
ADC channel for O2 feedback support
WBO2 / wide band possible with appropriate hardware and feedback through the ADC
ISO9141 / K-Line (serial data / protocol to be handled by Prop, but not implemented)
Brought out to the harness
Requires external hardware driver
pmrobert has already started doing the code, so if you want to contribute he's the one to ask.
He's already done a lot of the coding for the system AND coding the GUI for tuning, which I'm told can run on Windows, Linux and Android,
I guess I need to put a Bluetooth interface on the board?
Also, the feature set and capabilities are subject to change.
One thing I'd like to implement is 'soft-start' where the user turns the key "on" and presses the "start" button, and the ECU handles starting the engine.
This means I would need to sense the "start" button, control a relay, AND sense the "neutral" safety switch. More pins, more pins, more pins.
Not sure what it means, but I have 4 unused Prop pins.
Programming / tuning / debug is already handled over FT233RL USB interface.
The breakdown is:
SPI 'channel' for MC33814
I2C 'channel' for 64-128KB EEPROM
Control over 2 external relays for power distribution and fuel pump via toggling 33814 pins
Tachometer output from 33814 pin
Status / MIL lamp from 33814 pin (controlled by Prop)
Secondary SPI channel (controlled by Prop):
8 buffered ADC channels; 6 with 0-5v support, 2 with 0-12v (through voltage divider / Zener clamp):
0-5v: MAP, TPS, IAT, CLT (intake air and coolant temp), O2, one user defined
0-12v: battery voltage, one user defined
2 high impedance injector outputs (controlled by Prop toggling pins on the 33814 chip)
(low Z injector supported with external peak-and-hold drivers, fault monitoring can be supported with appropriate code
2 logic level ignition drivers (controlled by Prop toggling pins on the 33814 chip)
LS1/LS2/D514A or similar supported
inductive coils supported with external IGBT drivers
fault monitoring for IGBT can be supported with appropriate codeO2 heater control
HEGO / narrow band O2 / Lambda sensor support (heater controlled by Prop via SPI and toggling pins on the 33814 chip)
ADC channel for O2 feedback support
WBO2 / wide band possible with appropriate hardware and feedback through the ADC
ISO9141 / K-Line (serial data / protocol to be handled by Prop, but not implemented)
Brought out to the harness
Requires external
One thing you may want to consider is a voltage input to see actual system voltage. Primarily to calculate injector opening and closing time. Should normally be lower than 16 volts, but a faulty voltage regulator in the alternator can produce a lot higher.
[/INDENT]One thing you may want to consider is a voltage input to see actual system voltage. Primarily to calculate injector opening and closing time. Should normally be lower than 16 volts, but a faulty voltage regulator in the alternator can produce a lot higher.
Already on it.
What I mean is there is support for 2 'battery voltage' level analog inputs, one of which is already dedicated to sensing the battery voltage. They're basically ran through 10K/4.7K voltage dividers (which should result in 15V = 4.8V out) and clamped (for safety) to 5v by Zener's.
I'm nearing the end (I hope) of my TBI conversion with a GM system. So I'm generally interested in fuel injection and particularly in homebrew. I feel like there must be a better way to do EFI than using oem gear with these antiquated 680x controllers. I'm also planning on doing some automotive electronics in the next few weeks. A speed sensor buffer for the TBI some audio stuff, etc. I'm interested in what you're doing around power conditioning.
If I knew what you wanted, I, or others, might be able to help.
Perhaps I miscommunicated the conversational intent of my post. It's not that I want anything in particular. I was just sharing enthusiasm about your project. For example, I meant to say that I like the idea of an EFI system based on a modern MCU. The OEM EFI system I've been dealing with uses a rather ancient Motorola 6800 variant.
I mentioned power conditioning. I was referring to the harsh environment of automotive electrical systems. I'm guessing motorcycles do not suffer from the same magnitude of electrical noise as an automobile. Is there an equivalent to ISO 7637 / ISO 10605 tests for motorcycles? Not sure if you've gotten to a point of thinking about that yet.
To be honest, I hadn't thought much about ESD and noise.
Battery charging on my bike is done with a permanent magnet 3-phase AC generator which passes voltage through the regulator / rectifier module. The RR is comprised of SCR's and associated electronics that rectify the AC to DC and shunt unused current to ground in contrast with automotive alternators with variable output which modulate the voltage through rotating field windings to affect the voltage / current output. Ignition was thyristor controlled switching of typical inductive coils, with a ballast resistor in series with the two coils' grounds, and resistor type spark plug leads.
I don't recall ever encountering any substantial 'noise' such as alternator 'whine' or ignition noise.
Motorcycles, however, have somewhat differently routed electrical systems than cars, with many wires trunked / routed in parallel and in close proximity to each other, with wires branching out only as necessary to reach ancillaries unlike cars / trucks which can have multiple somewhat independent harnesses for chassis / body electrical and engine functions.
I'm using a slightly modified version of FreeScale's evaluation board for the MC33814 chip to derive power and other related circuitry, incorporating reverse voltage protection, and have relegated ignition to 5v logic level signals instead of incorporating IGBT drivers for coils, though that is supported as external modules. And, instead of using the MC33814's 5v output to power the processor and other externals, I'm using that to provide power to the 5v side of logic level / voltage translators and power to sensors, with a 5v0 LDO and a 3v3 LDO providing power to the processor and EEPROM and things not dependent on the MC33814. USB / FT232RL is bus powered and only using its internal 3v3 to interface with the processor, not sourcing any significant power for anything other than communication and a few status LED's, though I'm looking at galvanic isolation to help keep ground loop / voltage potentials from interfering with USB-to-processor operation- and that's unnecessary if the motorcycle is self-powered and not using a battery charger when connected to USB.
This is one of my first real projects and as such I am open to suggestions. Were I not, I'd probably not have started this thread / topic.:)
Battery charging on my bike is done with a permanent magnet 3-phase AC generator which passes voltage through the regulator / rectifier module.
I confess I know basically nothing at all about motorcycles. They sound like a bit of a different ballgame for this and the other reasons you mention. Not that some things don't carry over. So, if the regulator / rectifier fail, on a car at least, you'd be looking at 18V output (source: personal experience and http://www.industrologic.com/autotransients.pdf). But that's a car...
The RR is comprised of SCR's and associated electronics that rectify the AC to DC and shunt unused current to ground in contrast with automotive alternators with variable output which modulate the voltage through rotating field windings to affect the voltage / current output.
I wonder, then, what the failure mode might be for such a generator. Hm.
Ignition was thyristor controlled switching of typical inductive coils, with a ballast resistor in series with the two coils' grounds, and resistor type spark plug leads.
I wonder how much of a spike would be coming off the coils, then? If I read the table in the URL above correctly, not much? I guess the best way is to throw an oscilloscope on the main power and see what it looks like. At least you don't have to worry about spikes coming off door locks and window motors and a winch.
I'm using a slightly modified version of FreeScale's evaluation board for the MC33814 chip to derive power and other related circuitry, incorporating reverse voltage protection,
And up to 36V input. Nice. Throw a suitable capacitor on the power input and that probably takes care of it.
with a 5v0 LDO and a 3v3 LDO providing power to the processor and EEPROM and things not dependent on the MC33814.
I'm a new fan of the Ti LM2940 5V LDO which is designed for automotive use with lots of protection features and a neat dual mode where it draws less current when outside the LDO input range. I feel dumb having to ask but are motorcycles still 6V or are they 12V these days?
Edit: Looks like you have a TVS and reverse protection in there. Seems like that'd do the trick?
The rest sounds good. Your point about isolation gives me an idea for an issue I'm having with my FT232RL capturing ALDL data out of my ECM. Anyhoo... if I think of other things I'll post up...
Nearly all street ridden motorcycles over the past few decades are 12v systems. Some off-road / dirt bikes may be different.
Many motorcycles use permanent magnet generators- a set of magnets in the flywheel spinning around stationary charging coils (stator), so the charging system is running at full bore all the time hence why they shunt current to ground; they cannot change the magnetic field strength like an automotive type alternator can. This also means the typical failures are open windings which reduces the voltage / current output, or failed SCR's in the regulator which typically fail 'open' and reduce the output to the system.
Not sure about voltage spike and noise coming from the coils since I won't be using them and instead will be putting in D514A coils which are replacements for GM LS1/LS2 coils and are triggered by 5v logic level signals.
That regulator you mention looks interesting and seems to be pin-compatible with the LDO's I've chosen, and has an automotive friendly rating, but they don't have a 3v3 version. Not that I should worry about that though since I don't see an AEQ100 P8X32A either.
Note to pmrobert-
- don't abandon things yet.
I wish I could get pmrobert out here commenting on the hardware- he seems to prefer emailing me and that's probably because I email him such things instead of posting here- but I think I keep him in stitches over every hardware choice I make... then subsequently retract for whatever reason / whim / feather I'm sitting on. I feel 'off' since I'm doing this for myself, primarily, but other people are interested in this so I'm one person trying to fill a niche for what could amount to 1000's of people if this is done right. My goal is something similar to Microsquirt but at a lower cost and with more options. This makes me think that maybe I'm thinking too much and need to re-evaluate what I'm doing even if I have to go backwards, starting over... again.
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.
Cool! I think I can offer some information that you might be able to use. Condition: Use a propeller as a unit to control an engine. application: Develop Prop, sensors, and software necessary to make the total system.
First, develop an overall diagnostic to develop the system and offer feedback to engauge
in progression. (will have mistakes)
Second, develop math model to simulate how you expect it to perform.
Third, build the system.
This is what I had to do when I made my Hydrogen engine. I built the engine,
then the expected sensors. I made a crude sketch of how it should perform.
Then I used and Excel spreadsheet as a combustion phase monitor. The spreadsheet
was fed info from my sensors.(angles, exhaust, combusion, heat, etc) , and I had a real
time combustion phase monitor. All was going along well, until my injector did not do
like I told it to! Back to square one.
This setback angered me, as I discovered some other loose ends. That is when I
came up with my BeaglePeller project(tricorder/hpcalc).
The spreadsheet helps you greatly, because you can calculate power/second, fuel/sec
moles/sec, BTU/sec. You can store this information, to use later on, to find problems.
If you make an ideal engine on the spreadsheet, and compare it to the engine actually
running, you can find the efficency of the motor. May be able to tweek it out. Good Luck!
Nearly all street ridden motorcycles over the past few decades are 12v systems. Some off-road / dirt bikes may be different.
Many motorcycles use permanent magnet generators- a set of magnets in the flywheel spinning around stationary charging coils (stator), so the charging system is running at full bore all the time hence why they shunt current to ground; they cannot change the magnetic field strength like an automotive type alternator can. This also means the typical failures are open windings which reduces the voltage / current output, or failed SCR's in the regulator which typically fail 'open' and reduce the output to the system.
Not sure about voltage spike and noise coming from the coils since I won't be using them and instead will be putting in D514A coils which are replacements for GM LS1/LS2 coils and are triggered by 5v logic level signals.
That regulator you mention looks interesting and seems to be pin-compatible with the LDO's I've chosen, and has an automotive friendly rating, but they don't have a 3v3 version. Not that I should worry about that though since I don't see an AEQ100 P8X32A either.
Note to pmrobert-
- don't abandon things yet.
I wish I could get pmrobert out here commenting on the hardware- he seems to prefer emailing me and that's probably because I email him such things instead of posting here- but I think I keep him in stitches over every hardware choice I make... then subsequently retract for whatever reason / whim / feather I'm sitting on. I feel 'off' since I'm doing this for myself, primarily, but other people are interested in this so I'm one person trying to fill a niche for what could amount to 1000's of people if this is done right. My goal is something similar to Microsquirt but at a lower cost and with more options. This makes me think that maybe I'm thinking too much and need to re-evaluate what I'm doing even if I have to go backwards, starting over... again.
I'm here brother! I've been busy dealing with an incongruity in the GCC force field - look in the GCC forum here for details. The ongoing hardware decisions don't bother me in the least - the code is being written in a modular manner and can easily be modified to change ADCs or do PWM instead of the letting the 33814 do the injector current management, etc. I do know that the coil/stator setup on most bikes and outboards generally is in the mid teens at idle and does jump to 70+ at redline. That's why the RR modules in them run so hot. mklrobo's nicely organized build advice is excellent. The math model stuff is well known and the code uses simplified versions of those models to generate the outputs with inputs from real world conditions such as EGO, etc.
I'm here brother! I've been busy dealing with an incongruity in the GCC force field - look in the GCC forum here for details. That's why the RR modules in them run so hot. mklrobo's nicely organized build advice is excellent. The math model stuff is well known and the code uses simplified versions of those models to generate the outputs with inputs from real world conditions such as EGO, etc.
:cool: Thanks for the compliment, I appreciate that.:cool:
It sounded like he has alot of computing power revolving around items on the engine. He will definetely need a diagnostic system
to help him narrow down any problems that may arise. A question may arise, "Is it software or mechanical, or a combo?".
Diagnostics will help make life easier.
The past few days have had me frustrated about multiple things trying to concentrate on any one thing has been nearly impossible.
Points being made and things said aren't falling on deaf ears here though.
Bikes like mine- the CX and GL 500/650's Honda made are pretty robust, mechanically speaking, with people losing coolant and getting 15 miles down the road and not having any damage. The worst part about them is the charging system and they known for issues there but manly the stator giving up because it sits in the back of the engine and shares space with the cam chain so it's in a hot oil bath all the time.
So in all fairness I am reinventing the wheel with this but with good intent. I'm working with reference designs whenever possible; Freescale and TI are both known for having robust designs so I'm comfortable with that. A fair portion of my issues though are voltage level related- 5v control chip / system and 3.3v processor and getting an ADC that will live with that, finding automotive qualified parts and fighting against a 2 layer board and harness connector that doesn't give much room around its pins.
But it's annoying when I sit back, take a long look, then wonder what I was thinking.
:cool: Thanks for the compliment, I appreciate that.:cool:
It sounded like he has alot of computing power revolving around items on the engine. He will definetely need a diagnostic system
to help him narrow down any problems that may arise. A question may arise, "Is it software or mechanical, or a combo?".
Diagnostics will help make life easier.
Yes, I agree - you can't fix a problem if you can't characterize it. Up to this point, most of my effort has been to create a software framework in the embedded code and the PC GUI to facilitate comprehensive and dynamic monitoring, editing and reporting of real time variables (as appropriate) via a serial link running at 350Kbps with hooks that will allow configurable internal trip points to be set that will dump a snapshot to either EEPROM and/or SD card. The SD card will be optionally able to record a log of configurable parameters for post processing.
Kirk, an idea popped into my head as I was looking at other ECUs that I have lying around - the case that you specified can carry 2 boards in it. This would make things a little more complex for your layout task but would give you the real estate you're currently tight on. That was the sound of my Train of Thought derailing...
I don't think so. Taking advantage of the processor means a full suite of inputs and clean, reliable power. That's going to take a few parts.
Yeah, I'm feeling a bit overwhelmed.
I considering piggy-backed boards but I'm still limited by access to some of the Ampseal pins so have to re-evaluate where things lie such as things sinking an Amp or two- injector outputs have to be easy to get to as do the relays and the O2 heater; ignition too if I go back to IGBT's on board; camshaft VR's are about -5/+18v at redline, crankshaft I'm not sure yet but I expect substantially higher voltage so can probably be hit easily; other sensors are all limited to approximately 0.2-4.8v, TPS is one I think may go a little beyond that but I haven't checked it recently so memory is fuzzy, but either way I don't want them parallel to other traces on top or bottom layers and admit I may be overacting.
Maybe I can pull analogs off the two ends of the connector then pass them up to another board for processing, leaving the higher current stuff on the bottom board?
*Edit- Was going over some things and found a few discrepancies between the schematic and some of the components on the board so I ripped it all up for a clean slate.
:nerd: Just had an idea that might help you; I will use it for my Hydrogen engine project:nerd:
Your project and mine are very similar, in the fact that control with diagnostics is needed.
I have decided to use my beaglebone black for the platform to control my BS2 and propeller
to control/monitor my engine. Bill Henning has a RaspPeller combo that could be used
for your application! All the power of a platform, programming and all, with the real time
speed of the propeller! you could keep your COG libraries on the Raspberry PI, along with
the diagnostic program, and it could fit on your bike! (Dodge Chargers use 3 boards similar
to the Pi's on their vehicle. Well, looks like it anyway)
Interesting concept, being able to develop on the bike. Throw a display and simple keyboard on there and hand held programmer.
The 33814 does have some diagnostics / fault data that the Prop can pull over SPI, and many of the outputs are open / short and under / overcurrent protected. Have to re-check things but I'm aiming at allowing the Prop to halt and/or reset the 33814 if something happens.
For operation, what I imagined was one cog running in a supervisory context where it would be responsible for spawning other cogs which had to intermittently signal their status. My thought was that the supervisor would raise a flag (set a bit in a variable) for each cog or process and the representative cogs would clear the bit / flag, or vice-versa. It would also maintain data logging and serial output if connected to USB for debugging. No response from a cog halted the unit and maybe performed a full reset.
Among the spawned cogs' duties could be-
- one to communicate with the MC33814 for initialization, setup and fault checking, maybe also doing data logging to an SD card and handling USB when connected.
- one to poll the sensors, do table lookups and calculations for fuel duration and ignition timing and set global variables for other cogs to use;
- one to control fuel injection- with two timers one cog should be able to handle two injectors;
- one to control ignition timing- again with two timers, one timer could be used to determine when to fire and the other timer used to count down the 4-5ms dwell duration.
pmrobert would have to elaborate more since he's been working the code.
Other things / thoughts were:
Fuel injection would be synchronized with the cam sensor signals since there is one sensor for each signal and they correspond with TDC compression / ignition cycles.
RPM and crank position would be determined by timers- one a master timer resetting every full engine cycle / 720 degrees, one resetting between adjacent crank tooth detections. When a known position is detected from a cam signal, the timers would start. Knowing that there are 32 teeth on the trigger wheel, RPM can be deduced from the first timer, and knowing there are 11.25 degrees between tooth centers, (360/32=11.25), the interval between teeth can be used to infer crank position (timer ticks between teeth). Information from both timers can be used to confirm RPM. Also, resetting the timers with cam signals should zero out and accumulated drift over time.
Further expanding on RPM and timing, if the second timer was used to generate a fixed number of ticks between teeth, crank position can be inferred more accurately since you wouldn't be measuring time between teeth but instead would be measuring distance: if 92 ticks could be made (11.25 * 4), positional accuracy should be ~0.25 degrees between teeth and if for some reason ticks didn't come up correctly, for instance 88 or 100 were detected, the second timer tick interval would increase or reduce accordingly to try to accommodate the missing or extra ticks within the next tooth providing a sort of self-compensating system. If you further increase the ticks, positional accuracy increases and drift over time reduces.
I finally figured out what I was trying to say.
In addition to the above information, check out the new thread in general discussion;
Propeller and Raspberry Pi/beaglebone powerhouse. Some other members helped me
define the practicality of the idea.
Comments
Well, I think this might be the one. But, I'm open to comments or suggestions.
I decided to keep the QS board for now. Still have to set mount holes so there may be some slight re-routing but most everything's there, except ISO9141 / OBD stuff, but that's only a couple discrete components, connector, connection to header and code.
Supported external devices:
2 high impedance injectors; low impedance with external drivers.
2 logic level ignition triggers; inductive coils with external drivers, including current sense / fault detection if drivers support it.
1 O2 heater (HEGO) control with current sense / fault detection. Can be disabled in software and used as other type driver.
2 Relays. I.e. one for 12v out to injectors / ignition, one for fuel pump.
1 Tachometer output.
1 Indicator lamp. This is driven by MCU so can be used for anything including driving another relay or such.
3 VR sensors. One for crankshaft position; 2 for camshaft position. I'm using 2 camshaft sensors because my bike has two, therefore I can track each cylinder position independently.
1 Key switch position. Since the unit is permanently connected to the battery, this allows the unit to execute a power-off routine prior to full shut-down.
1 Protected 5v0 out for external sensors: short to ground, short to battery.
7+1 ADC channels: manifold pressure, throttle position, air temp, coolant temp, O2 sensor and two 'extra' channels plus 12v system voltage.
Pin assignments / type / description:
P1 / P3: I2C, SCL & SDA for ADC
P10: Supervisory, Propeller control to enable logic / voltage level translation on the following-
P16-P17: Output, Relay 1 & 2 control (on / off)
P18: Output, O2 sensor heater control (on / off)
P19-P20: Output, Ignition 1 & 2 control (on / off)
P21-P22: Output, Injector 1 & 2 control (on / off)
P23: Input, Key switch position indicator (on / off)
(Conveniently, the above correspond with the LED's on the QS board so there is visual indication things are working.
P27: Supervisory, Propeller control to enable logic / voltage level translation on the following-
P12-P13: Input, VR sensors 2 & 3 (cam shaft position for two cylinders)
P14: SPI, chip select for MC33814
P15: Input, VR sensor 1 (crankshaft position sensor)
P24: SPI, SCLK for MC33814
P25: SPI, MOSI for MC33814
P26: SPI, MISO for MC33814
RIN: Supervisory, RESET (inverted) from MC33814 to Propeller
Whelp, back to the drawing board.
When I'm happy with the board, I'll have to make another board to simulate the sensors so I can start hitting my head against the code.
I've fantasized about creating an EMS before. Not sure how much help I would be, but, I would be happy to give you hand.
Some thoughts. I'd bring any unused propeller pins out to a through hole header with ground and power nearby. This makes quick fixes/additions much easier. Second, just build one! As my grandpa says, "once you build a prototype, the janitor can tell you how to make it better"
Looking forward to the results,
Marty
Programming / tuning / debug is already handled over FT233RL USB interface.
The breakdown is:
SPI 'channel' for MC33814
I2C 'channel' for 64-128KB EEPROM
Control over 2 external relays for power distribution and fuel pump via toggling 33814 pins
Tachometer output from 33814 pin
Status / MIL lamp from 33814 pin (controlled by Prop)
Secondary SPI channel (controlled by Prop):
WBO2 / wide band possible with appropriate hardware and feedback through the ADC
Requires external hardware driver
pmrobert has already started doing the code, so if you want to contribute he's the one to ask.
He's already done a lot of the coding for the system AND coding the GUI for tuning, which I'm told can run on Windows, Linux and Android,
I guess I need to put a Bluetooth interface on the board?
Also, the feature set and capabilities are subject to change.
One thing I'd like to implement is 'soft-start' where the user turns the key "on" and presses the "start" button, and the ECU handles starting the engine.
This means I would need to sense the "start" button, control a relay, AND sense the "neutral" safety switch. More pins, more pins, more pins.
One thing you may want to consider is a voltage input to see actual system voltage. Primarily to calculate injector opening and closing time. Should normally be lower than 16 volts, but a faulty voltage regulator in the alternator can produce a lot higher.
What I mean is there is support for 2 'battery voltage' level analog inputs, one of which is already dedicated to sensing the battery voltage. They're basically ran through 10K/4.7K voltage dividers (which should result in 15V = 4.8V out) and clamped (for safety) to 5v by Zener's.
I'm nearing the end (I hope) of my TBI conversion with a GM system. So I'm generally interested in fuel injection and particularly in homebrew. I feel like there must be a better way to do EFI than using oem gear with these antiquated 680x controllers. I'm also planning on doing some automotive electronics in the next few weeks. A speed sensor buffer for the TBI some audio stuff, etc. I'm interested in what you're doing around power conditioning.
Perhaps I miscommunicated the conversational intent of my post. It's not that I want anything in particular. I was just sharing enthusiasm about your project. For example, I meant to say that I like the idea of an EFI system based on a modern MCU. The OEM EFI system I've been dealing with uses a rather ancient Motorola 6800 variant.
I mentioned power conditioning. I was referring to the harsh environment of automotive electrical systems. I'm guessing motorcycles do not suffer from the same magnitude of electrical noise as an automobile. Is there an equivalent to ISO 7637 / ISO 10605 tests for motorcycles? Not sure if you've gotten to a point of thinking about that yet.
Battery charging on my bike is done with a permanent magnet 3-phase AC generator which passes voltage through the regulator / rectifier module. The RR is comprised of SCR's and associated electronics that rectify the AC to DC and shunt unused current to ground in contrast with automotive alternators with variable output which modulate the voltage through rotating field windings to affect the voltage / current output. Ignition was thyristor controlled switching of typical inductive coils, with a ballast resistor in series with the two coils' grounds, and resistor type spark plug leads.
I don't recall ever encountering any substantial 'noise' such as alternator 'whine' or ignition noise.
Motorcycles, however, have somewhat differently routed electrical systems than cars, with many wires trunked / routed in parallel and in close proximity to each other, with wires branching out only as necessary to reach ancillaries unlike cars / trucks which can have multiple somewhat independent harnesses for chassis / body electrical and engine functions.
I'm using a slightly modified version of FreeScale's evaluation board for the MC33814 chip to derive power and other related circuitry, incorporating reverse voltage protection, and have relegated ignition to 5v logic level signals instead of incorporating IGBT drivers for coils, though that is supported as external modules. And, instead of using the MC33814's 5v output to power the processor and other externals, I'm using that to provide power to the 5v side of logic level / voltage translators and power to sensors, with a 5v0 LDO and a 3v3 LDO providing power to the processor and EEPROM and things not dependent on the MC33814. USB / FT232RL is bus powered and only using its internal 3v3 to interface with the processor, not sourcing any significant power for anything other than communication and a few status LED's, though I'm looking at galvanic isolation to help keep ground loop / voltage potentials from interfering with USB-to-processor operation- and that's unnecessary if the motorcycle is self-powered and not using a battery charger when connected to USB.
This is one of my first real projects and as such I am open to suggestions. Were I not, I'd probably not have started this thread / topic.:)
Surprised I've managed to get what I have on one sheet, two layers and 4.125 x 3.125 inch board.
Now, only need to get RTC, barometer, SD card slot and ADC on there too.
I confess I know basically nothing at all about motorcycles. They sound like a bit of a different ballgame for this and the other reasons you mention. Not that some things don't carry over. So, if the regulator / rectifier fail, on a car at least, you'd be looking at 18V output (source: personal experience
I wonder, then, what the failure mode might be for such a generator. Hm.
I wonder how much of a spike would be coming off the coils, then? If I read the table in the URL above correctly, not much? I guess the best way is to throw an oscilloscope on the main power and see what it looks like. At least you don't have to worry about spikes coming off door locks and window motors and a winch.
And up to 36V input. Nice. Throw a suitable capacitor on the power input and that probably takes care of it.
I'm a new fan of the Ti LM2940 5V LDO which is designed for automotive use with lots of protection features and a neat dual mode where it draws less current when outside the LDO input range. I feel dumb having to ask but are motorcycles still 6V or are they 12V these days?
Edit: Looks like you have a TVS and reverse protection in there. Seems like that'd do the trick?
The rest sounds good. Your point about isolation gives me an idea for an issue I'm having with my FT232RL capturing ALDL data out of my ECM. Anyhoo... if I think of other things I'll post up...
Michael
Many motorcycles use permanent magnet generators- a set of magnets in the flywheel spinning around stationary charging coils (stator), so the charging system is running at full bore all the time hence why they shunt current to ground; they cannot change the magnetic field strength like an automotive type alternator can. This also means the typical failures are open windings which reduces the voltage / current output, or failed SCR's in the regulator which typically fail 'open' and reduce the output to the system.
Not sure about voltage spike and noise coming from the coils since I won't be using them and instead will be putting in D514A coils which are replacements for GM LS1/LS2 coils and are triggered by 5v logic level signals.
That regulator you mention looks interesting and seems to be pin-compatible with the LDO's I've chosen, and has an automotive friendly rating, but they don't have a 3v3 version. Not that I should worry about that though since I don't see an AEQ100 P8X32A either.
Note to pmrobert-
- don't abandon things yet.
I wish I could get pmrobert out here commenting on the hardware- he seems to prefer emailing me and that's probably because I email him such things instead of posting here- but I think I keep him in stitches over every hardware choice I make... then subsequently retract for whatever reason / whim / feather I'm sitting on. I feel 'off' since I'm doing this for myself, primarily, but other people are interested in this so I'm one person trying to fill a niche for what could amount to 1000's of people if this is done right. My goal is something similar to Microsquirt but at a lower cost and with more options. This makes me think that maybe I'm thinking too much and need to re-evaluate what I'm doing even if I have to go backwards, starting over... again.
Cool! I think I can offer some information that you might be able to use.
Condition: Use a propeller as a unit to control an engine.
application: Develop Prop, sensors, and software necessary to make the total system.
First, develop an overall diagnostic to develop the system and offer feedback to engauge
in progression. (will have mistakes)
Second, develop math model to simulate how you expect it to perform.
Third, build the system.
This is what I had to do when I made my Hydrogen engine. I built the engine,
then the expected sensors. I made a crude sketch of how it should perform.
Then I used and Excel spreadsheet as a combustion phase monitor. The spreadsheet
was fed info from my sensors.(angles, exhaust, combusion, heat, etc) , and I had a real
time combustion phase monitor. All was going along well, until my injector did not do
like I told it to! Back to square one.
This setback angered me, as I discovered some other loose ends. That is when I
came up with my BeaglePeller project(tricorder/hpcalc).
The spreadsheet helps you greatly, because you can calculate power/second, fuel/sec
moles/sec, BTU/sec. You can store this information, to use later on, to find problems.
If you make an ideal engine on the spreadsheet, and compare it to the engine actually
running, you can find the efficency of the motor. May be able to tweek it out. Good Luck!
It sounded like he has alot of computing power revolving around items on the engine. He will definetely need a diagnostic system
to help him narrow down any problems that may arise. A question may arise, "Is it software or mechanical, or a combo?".
Diagnostics will help make life easier.
Points being made and things said aren't falling on deaf ears here though.
Bikes like mine- the CX and GL 500/650's Honda made are pretty robust, mechanically speaking, with people losing coolant and getting 15 miles down the road and not having any damage. The worst part about them is the charging system and they known for issues there but manly the stator giving up because it sits in the back of the engine and shares space with the cam chain so it's in a hot oil bath all the time.
So in all fairness I am reinventing the wheel with this but with good intent. I'm working with reference designs whenever possible; Freescale and TI are both known for having robust designs so I'm comfortable with that. A fair portion of my issues though are voltage level related- 5v control chip / system and 3.3v processor and getting an ADC that will live with that, finding automotive qualified parts and fighting against a 2 layer board and harness connector that doesn't give much room around its pins.
But it's annoying when I sit back, take a long look, then wonder what I was thinking.
-Mike
I considering piggy-backed boards but I'm still limited by access to some of the Ampseal pins so have to re-evaluate where things lie such as things sinking an Amp or two- injector outputs have to be easy to get to as do the relays and the O2 heater; ignition too if I go back to IGBT's on board; camshaft VR's are about -5/+18v at redline, crankshaft I'm not sure yet but I expect substantially higher voltage so can probably be hit easily; other sensors are all limited to approximately 0.2-4.8v, TPS is one I think may go a little beyond that but I haven't checked it recently so memory is fuzzy, but either way I don't want them parallel to other traces on top or bottom layers and admit I may be overacting.
Maybe I can pull analogs off the two ends of the connector then pass them up to another board for processing, leaving the higher current stuff on the bottom board?
*Edit- Was going over some things and found a few discrepancies between the schematic and some of the components on the board so I ripped it all up for a clean slate.
Your project and mine are very similar, in the fact that control with diagnostics is needed.
I have decided to use my beaglebone black for the platform to control my BS2 and propeller
to control/monitor my engine. Bill Henning has a RaspPeller combo that could be used
for your application! All the power of a platform, programming and all, with the real time
speed of the propeller! you could keep your COG libraries on the Raspberry PI, along with
the diagnostic program, and it could fit on your bike! (Dodge Chargers use 3 boards similar
to the Pi's on their vehicle. Well, looks like it anyway)
The 33814 does have some diagnostics / fault data that the Prop can pull over SPI, and many of the outputs are open / short and under / overcurrent protected. Have to re-check things but I'm aiming at allowing the Prop to halt and/or reset the 33814 if something happens.
For operation, what I imagined was one cog running in a supervisory context where it would be responsible for spawning other cogs which had to intermittently signal their status. My thought was that the supervisor would raise a flag (set a bit in a variable) for each cog or process and the representative cogs would clear the bit / flag, or vice-versa. It would also maintain data logging and serial output if connected to USB for debugging. No response from a cog halted the unit and maybe performed a full reset.
Among the spawned cogs' duties could be-
- one to communicate with the MC33814 for initialization, setup and fault checking, maybe also doing data logging to an SD card and handling USB when connected.
- one to poll the sensors, do table lookups and calculations for fuel duration and ignition timing and set global variables for other cogs to use;
- one to control fuel injection- with two timers one cog should be able to handle two injectors;
- one to control ignition timing- again with two timers, one timer could be used to determine when to fire and the other timer used to count down the 4-5ms dwell duration.
pmrobert would have to elaborate more since he's been working the code.
Other things / thoughts were:
Fuel injection would be synchronized with the cam sensor signals since there is one sensor for each signal and they correspond with TDC compression / ignition cycles.
RPM and crank position would be determined by timers- one a master timer resetting every full engine cycle / 720 degrees, one resetting between adjacent crank tooth detections. When a known position is detected from a cam signal, the timers would start. Knowing that there are 32 teeth on the trigger wheel, RPM can be deduced from the first timer, and knowing there are 11.25 degrees between tooth centers, (360/32=11.25), the interval between teeth can be used to infer crank position (timer ticks between teeth). Information from both timers can be used to confirm RPM. Also, resetting the timers with cam signals should zero out and accumulated drift over time.
Further expanding on RPM and timing, if the second timer was used to generate a fixed number of ticks between teeth, crank position can be inferred more accurately since you wouldn't be measuring time between teeth but instead would be measuring distance: if 92 ticks could be made (11.25 * 4), positional accuracy should be ~0.25 degrees between teeth and if for some reason ticks didn't come up correctly, for instance 88 or 100 were detected, the second timer tick interval would increase or reduce accordingly to try to accommodate the missing or extra ticks within the next tooth providing a sort of self-compensating system. If you further increase the ticks, positional accuracy increases and drift over time reduces.
In addition to the above information, check out the new thread in general discussion;
Propeller and Raspberry Pi/beaglebone powerhouse. Some other members helped me
define the practicality of the idea.