Buell ECM to Arduino

2012-07-30T22:40:00.001-04:00

Hey everyone! Thanks for all the views. I know it has been a while since I last updated my blog. I did present my project and got a great grade on it, my instructor was impressed with how much work I got done in a semester. If I get enough interest I might post a PDF of my final report.

I did speak with Professor George about how to calculate the varying flow from fuel injectors. Injectors don't instantly turn on and spit out the perfect amount of fuel. They have a non-linear "ramp up" and "ramp down" that happens every time the injector turns on, although from an engineering standpoint, it is safe to assume that the ramps are non-linear, and constant for every "squirt". So the actual fuel emitted from the injector on a Volume (or mass) vs. Time graph would look similar to that of a bandpass filter. If you know your pulsewidth (total injector time), and you know your time it takes the injector to turn on and off, then you can calculate the volume (or mass) of fuel that was injected during a single engine cycle, and with RPM you can calculate your rate of fuel consumption. Or if you want to get really advanced, you can calculate your temperatures and pressures (and forces, torques) internally, or you can go and calculate your power with the power equation if you know your A/F ratio and engine efficiencies and some additional data. After all, power is mass of fuel times the Lower Heating Value (QLHV) over time. Although, it costs a LOT of money and resources to get accurate efficiency numbers for engines (I mean millions of dollars). But there are some good methods for us working out of our garages to get rough estimates

For now, the project is on hold. I went active duty as a 2nd Lieutenant in the Air Force in June and moved out to Los Angeles. Going active duty is a LONG process (reporting in, security, training, finances, healthcare). I have had a TON going on and just don't have enough time to show my bike some TLC. The movers also my mirrors on my bike, so it will be a bit longer until I can even ride my bike again. I also bought a new Volkswagen GTI, and I can't help but dump money into it :D

I do plan on picking up where I left off, but I can't say when that will happen. But when it does, I will keep posting on here. But in the mean time, I am still around. If anyone in the Los Angeles area is interested in seeing the project (want to meet up for a cruse) just let me know! Please feel free to leave comments and ask questions, I will reply pretty quickly.

Me on The Tail of the Dragon (Deal's Gap, 2011)

2012-04-10T15:44:00.001-04:00

I got a LOT of work done this past weekend. Since I was able to get the Arduino to communicate with the ECM in real-time I was able to take a big step toward the purpose of the project, which is to calculate power, torque, and make a shift indicator.

You can see the results of this weekend's work here:

I attempted to compute acceleration from the change in speed. The problem with this method is that my ECM outputs speed in increments of 1MPH, which is a horribly low resolution. at the speed that the Arduino was computing with each increase in 1MPH, the acceleration would be an instant 4.48MPH/s. Since the resolution is so low, the speed would jump around all over the place and was causing my power equation to jump all around as well.

My solution for this is to go back to my original idea of calculating force from acceleration by using an accelerometer. I ordered one on Monday so hopefully it will get here this week and I can hook it up so I can get some good smooth power calculations.

Right now I also have a small problem with the speed that the arduino does its calculations. Right now with all of the datalogging code it records data at about 4-5Hz, which is a bit lower than I would like. Theoretically with a baud rate of 9600, my maximum recording speed would be at about 10Hz, so I will try to optimize my code to get closer to there.

The last little concern of mine is that the Arduino (or the program) hangs/freezes randomly. I suspect it is from the ECM not completely receiving the request, or the Arduino not completely receiving the response. Hopefully it is not from the Arduino hitting its memory limit, because that would be dire to the entire project.

On a separate note:
Last Saturday I contacted Erik Buell Racing and asked them about the fuel injectors from the XB series bikes, and I also asked them about why they didn't use the MAF method for their ECM. This is the response I got earlier today:

"Low pulse widths can be dominated by the dynamic flow duration; there is a dynamic and static flow rate so for short pulse widths you’ll be heavily into the dynamic flow portion of it and may not get an accurate calculation. We can probably dig up the spec, and it'll be something to get you in the neighborhood but more complicated analysis is needed to truly calculate a proper mass-fuel-injected value.

Regarding the MAF question, we actually use alpha-N (not speed density). MAF is better in some cases, but only given the intake air flow can be properly pre-conditioned such that it is laminar across the sensor and a steady even flow without reverse waves, especially needed on a V-twin. This works on a car because there is ample room for intake length and volume for chambers but usually is not feasible in a motorcycle, and definitely not on an H-D based motor.

Thank you,

Tech Support

Erik Buell Racing"

Apparently there is a lot more to calculating fuel flow rate than just multiplying the pulsewidth by the flow rate and RPM. I am actually interested in seeing the dynamics behind calculating the actual flow rate. Hopefully just getting an approximation will be accurate enough to calculate fuel economy.

It seems I was mistaken in my earlier blog post about Buell not using the MAF method for determining fuel flow. I knew that their were waves in the intake runners and manifold, but I didn't realize it made MAF sensors unusable. I also thought that the speed-density method was the same as alpha-N, but they are very different. Alpha-N is different in that it uses the TPS angle (alpha) and engine RPM (N) map to select a predetermined amount of fuel to flow into the engine.

2012-04-03T17:47:00.000-04:00

I was reading through the EcmSpy Buell Tuning Guide V2 pdf and found a couple really interesting things with my ECM.

1. The ECM has a function built into it that leans out the AF ratio under acceleration and other times for noise emissions. This creates a dead spot around the 3000RPM range. It is possible to send the ECM a command to disable this and return a little power in the mid range, and make the bike a little louder :D

2. The ECM has a function built in that uses a barometer to measure the atmospheric pressure when the key is turned on. A correction factor is then applied for the rest of the ride that compensates for the different air pressure. The XB bikes do not use this from the factory. The ECM has the capability, but the bikes do not have the pressure sensors installed. The tuning guide has instructions for how to make a working pressure sensor and how to connect it to the ECM with pictures and everything.

Details can be found in the Buell Tuning Guide V2 Appendix J:
http://www.ecmspy.com/tgv2/guide2.shtml

This is exciting because it shows that the designers understood the effects of pressure (maybe not humidity) on an engine. I don't know if they fully understood how it directly effects A/F ratio, but they were on the right track.

I would like to apply both of these fixes to my bike. This will definitely help with power and with efficiency. It strikes me as odd that the ECM has this function, but wasn't utilized. I am beginning to think that they used a cookie cutter ECM and set it up for the XB bikes, which might also explain why it uses the speed-density method.

2012-04-01T19:57:00.001-04:00

More great news!

I finally got the arduino to read all 107 bytes of data in real-time. No delays, no stops, no cutting off data, it works like a dream. Check out the video:

Now time for the real engineering. I can now start using the inputs that I have to generate the equations and code for torque, horsepower, and hopefully a shift indicator. I also need to start learning how to use the data-logging shield to save all 107 bytes of data to an excel.

2012-03-28T13:42:00.001-04:00

Well I did it, I finally am able to read all 107 bytes of information that the buell sends to the arduino. If you want to see the code I am using right now check out the Arduino Code page. If the link will work correctly you can also view the spreadsheet that I created to help determine what each byte means HERE, most of it was taken from the tables on the EcmSpy website and cleaned up and matched with the data I collected.

My next step is to figure out how to do it fast enough. My first few attempts either didn't work at all, or only read info every 20 seconds. It was brought to my attention that I also need to add functionality that verifies that all of the data was actually received and is good data. This means I will need to match the first 7 bytes of the header, since they are always the same, and I need to keep a running checksum as the data comes in to compare with the checksum at the end of the data. If those 8 bytes of data match then the information received is good and can be used to calculate in the next iteration.

I need to meet with my Adv. Engines Professor to talk about how the best way to get the air mass flow rate in my motorcycle. During a quick chat with him the other day he referenced using the narrowband O2 sensor, but I didn't get a chance to ask him to elaborate on it. I talked with a classmate of mine and he suggested using the LC-1 Lambda Wideband O2 sensor because it will feed the data I want into the Arduino while at the same time feeding a narrowband signal to the ECM. I wish it didn't cost $200 :(

2012-03-22T12:32:00.001-04:00

Things have been a bit slow, I have had a bit of trouble getting the arduino to read the entire 107 byte length of code being sent from the ECM, but I am getting ever closer. Right now it seems to only read 67 of the 107 bytes, which is no good for my project. It is mostly a matter of getting the arduino to read the incoming data just right. Hopefully I can get this finished up this weekend so that I can get crunching on the numbers and get the hard math done with all of the ECM info.

If anyone is interested in seeing the arduino programming roadblocks and solutions, check out this thread I have been using.

Buell ECM to Arduino help forum

2012-03-14T16:06:00.000-04:00

I was talking about engine design and ECM controls with my roommate yesterday and came to some interesting conclusions about my Lightning's ECM design.

Engine and ECM basic concepts

An engine, at it's core, is an air pump. The way you control the engine is by feeding it more or less air. An engine is designed to work with a certain fuel, which burns optimally at a very specific air-to-fuel ratio (A/F). This A/F for generic unleaded fuel is approximately 14.7 (14.7 parts air and 1 part fuel). Unfortunately air changes with pressure, temperature, humidity etc. which means that your engine on one day will need a different A/F than your engine needs on a different day or different location.

Luckily we have sensors that detect the humidity and pressure and temperature we can get the density of air and calculate our needed A/F ratio using a little bit of chemistry and balancing stoichiometric equations. This is all fed into and performed automatically in the engine control module (ECM).

Image of Buell 1125 Rotax engine throttle body

So, what happens when you push down on the accelerator or twist the throttle? Generally the valve (the gold circles in the image above) opens to allow the engine to suck in more air. So then how much fuel do I need? Well, we can measure the amount of air being sucked in with a mass air flow sensor (MAF). The ECM already knows the A/F ratio it needs from its sensors and math, and using that it calculates how much fuel to squirt into the engine for a good burn.

Not too complicated, right?

Unfortunately, that is not how MY engine (and all XB series Buells) works because it does not use a MAF. When I twist the throttle, the throttle body opens and the ECM looks at the throttle position sensor (TPS) and the current RPM of the engine. The ECM doesn't directly know how much air is going into the engine because there is no MAF sensor. It then looks at a map (see below table) and decides how much fuel is needed.

Front cylinder Fuel Map for my XB9

The ECM approximates the amount of air using the temperature, pressure of the air, volumetric efficiency of the engine (% of air it can jam into the cylinder), and a few other factors and calculates modifiers for the amount of fuel to be injected into the cylinder. After the burn, there is an O2 sensor that detects the actual A/F ratio from the exhaust. This is then used to adjust the fuel, again, to bring the combustion closer to the desired A/F ratio.

Now that sounds complicated...

This method is often called the ~~speed-density~~ alpha-N method. (Note: I was recently informed that my initial assumptions on this topic were incorrect. Please see my post on 4/10/2012 for a reply from EBR on why they didn't use the MAF method). This makes it necessary (and very difficult) to tune the engine when major modifications are made, because the maps and modifiers must be changed beyond the bounds that the ECM is capable of compensating for..

For example: Many people install free(er) flowing exhausts on my bike. This allows more air to flow through the engine. This causes the engine to run lean, which runs hotter, burns worse, and increases tendency for knock. To accommodate for the increase of air, the maps must be adjusted to give more fuel....how much fuel? We don't know unless we do data logging without the ECM's corrections. and see what the O2 sensor says at different RPM and different TPS. Then we make some adjustments and see how much the engine makes adjustments. The less adjustments the better the tune job. So, it becomes a big circle or recording data, making adjustments, and then checking the adjustments.

None of this would be necessary if the ECM used the mass air flow method and directly knew the exact amount of air flowing into the engine. Free flowing exhaust? no problem, MAF says this much air going in, ECM calculates how much fuel will make that air the correct A/F ratio. Only small adjustments would be needed that are particular to the engine design and are built into the ECM.

I do not know why Buell (and many other manufacturers) choose to use the speed-density method. MAF sensors generally cost around $80 and are small and can easily be placed in the intake manifold after (or sometimes before) the throttle body, and save so much work.

Please see my blog post on 10 April for EBR's reply on why they used Alpha-N method.

How does this relate to my project?

One of the goals for my project is to calculate instant torque and power. I need to know mass air flow in order to calculate torque and power. There are two ways that I know of right now that I can get mass air flow. I can measure it with a MAF sensor (not currently installed), or I can calculate the air ratio using the A/F reading from a wide-band O2 sensor (also not currently installed). A WB O2 sensor kit is about $200 and would be easy to install. A MAF sensor is $80 and difficult to install. I am very budget limited and it looks like a MAF is the way to go if I can install it properly in the intake manifold in my engine, but I don't feel confident I can do it right.

I am still researching my options to see if there is a cheaper, non-intrusive way I can get mass air flow.

2012-03-11T23:52:00.001-04:00

I am back! Great spring break at North Myrtle Beach.

So I messed with my bike a little bit today. I used the correct checksum 0xFD and got better results, but not quite what I needed. I was supposed to get a 107 byte response from the ECM, but it only sent back a 64 byte response with only the first 59 or so real-time values. On top of that, all of them were doubled what they should be. For example, battery voltage was reading 25 Volts, and Engine temperature was reading 120 degrees F with the engine off. It should have said 12.5 Volts and 60 degrees F.

At least I was able to read the data that I did get in real-time.

Hopefully the Buell forum guys can help me figure this one out. In the mean time I am going to start building an algorithm in C/C++ that will store each value read from the ECM to the correct variable name and correct unit conversions. Then I will be able to start using the values to do the hard calculations.

2012-03-05T01:28:00.002-05:00

Good news. The cause of the problem is from an incorrect checksum that I am using when I send a request to the ECM. The correct checksum I am supposed to use is 0xFD. Hopefully this works.

Msamuels0 over at BadWeB has been a great help so far and had a great explanation of how a checksum works. Here is a copypasta of what he said:

A checksum, by definition, is going to change if any of the data in the message changes...

That table on the ECMSpy website states that the checksum is an XOR of all the preceding data, but doesn't state that it only includes everything after the first byte (0x01).

So, to verify the checksum the following message from the ECMSpy table:

0x01
0x00
0x42
0x02
0xFF
0x02
0x56
0x03

Take what's after the 0x01, leaving:

0x00
0x42
0x02
0xFF
0x02
0x56
0x03

If we do the XOR operation on the first two bytes, then keep XORing the result with the next byte:

1. 0x00 ^ 0x42 = 0x42
2. 0x42 ^ 0x02 = 0x40
3. 0x40 ^ 0xFF = 0xBF
4. 0xBF ^ 0x02 = 0xBD
5. 0xBD ^ 0x56 = 0xEB
6. 0xEB ^ 0x03 = 0xE8

So, 0xE8 is the correct checksum for that specific message.

To calculate the checksum for the message which requests runtime data:

0x01
0x00
0x42
0x02
0xFF
0x02
0x43
0x03

Drop the first byte, leaving:

0x00
0x42
0x02
0xFF
0x02
0x43
0x03

Do the byte-by-byte XORing:

1. 0x00 ^ 0x42 = 0x42
2. 0x42 ^ 0x02 = 0x40
3. 0x40 ^ 0xFF = 0xBF
4. 0xBF ^ 0x02 = 0xBD
5. 0xBD ^ 0x43 = 0xFE
6. 0xFE ^ 0x03 = 0xFD

So, the checksum for this specific message is 0xFD.

The point of a checksum is to verify the integrity of the previously received data, so once the ECM receives the complete message, it calculates the checksum byte-by-byte, and if it doesn't match the checksum that was appended to the end of the data, rejects the whole thing as bad/corrupt, and apparently sends an error response.

Hope that helps explain it.

I am going on Spring Break this week and wont be working on my project during then. I will post the results of the correction next Saturday/Sunday!

2012-03-04T14:33:00.001-05:00

After getting some help from the guys at BadWeB and searching through the Arduino help and forums, I was able to get my Arduino to send a series of Hexadecimal data shown in the table below to the ECM.

Byte #	Meaning	Values (typical)	Remarks
1	SOH	0x01	Start of Header
2	Emittend	0x00	From PC
3	Recipient	0x42	To ECM
4	Data Size	0x02	2 Bytes
5	EOH	0xFF	End of Header
6	SOT	0x02	Start of Text
7	Data 1	0x56 = Get Version 0x43 = Get Runtime Data	Command Code
8	Data 2 (EOT)	0x03	End of Text
9	Checksum	0xE8	XORed Checksum

Top row: data request sent to ECM
Bottom row: response from the ECM

SUCCESS!

Or so I thought...I got the ECM to respond last night and I thought all was good and went to bed. I did some more research this morning and learned how to put the data I got back from the ECM into a 107 byte array saved in the Arduino memory. Everything byte I tried to access was nothing but FFFFFFFF
(which translating from Hex pretty much means FFFFFFUUUUUUUUU!). But the data still had a header which looked like normal. After deciphering the good data I realized that it was sending back a 10 byte response indicating an error in it, and the rest of the FFFFFFFF were just blank cells in the array I created.

This is the Hex code I get from the ECM:
01 //start of header
42 //to PC
00 //from ECM
03 //size of data
FF //end of header
02 //start of text
15 //ERROR (because it isn't 06 which would mean success)
41 //the rest of the error?
03 //end of text
EB //checksum

So my error code is 1541 in hex. I don't know what it means and it isn't mentioned on the ECMSpy website. I posted on the BadWeB forum and also emailed a few people. Hopefully they can help because my project is on hold until I can get the correct 107 byte series from the ECM.

2012-03-03T23:57:00.003-05:00

This blog will follow the progress of my Buell ECM to Arduino project.

This project is for my Advanced Engines Graduate class. The goal of the project is to use an Arduino to interface with the motorcycle's ECM to calculate and display instantaneous Horsepower, Torque, and a shift indicator, and data-log.

This will require specific run-time information from the ECM as well as pressure sensors, temperature sensors, and an accelerometer to be connected to the Arduino. Data will be recorded on an SD card and plotted in Excel.

So far I purchased and received my Arduino, 16x2 character LCD screen, and Data-Logger from Adafruit. This is my first time ever using an Arduino, or programming in C/C++. However, it is not my first time learning a new programming language. I have taught myself MatLab, HTML, and Expression 2 (which is from a game called Garry's Mod), and LabVIEW for college/gaming.

The Data-Logger came unassembled, which I was not expecting, so I picked up my own soldering iron and built the board, which actually was a lot of fun. I spent about 6-7 hours Wednesday teaching myself (with the help of many open-source tutorials for the Arduino) how to operate the microcontroller and got it to display and scroll through text on the LCD screen.

Next up: Figuring out how to communicate with the ECM...