| Author | Message | ||
     Pwillikers |
I believe the difficulty will be in interpreting the information stored in the packets. "Each ECU manufacturer uses its own set of rules & codes to craft data packets on their vehicles networks. These informations and data formats are not readily available, and there are no shared rules followed by different manufacturers." Here is a good general reference on CAN bus functionality from where the above quote was taken: http://marco.guardigli.it/2010/10/hacking-your-car .html | ||
| Milt |
The nice thing about standards is that there are so many to choose from.  I notice that http://ecmspy.com lists live data 'specs' and links to other products that allow access to their binary capture files. From poking around on the site, it looks like the ECMSpy guys (and/or gals) had to figure out what all the output meant:
| ||
| Hildstrom |
I got some ECM data last night. I connected ECM->Arduino->Netbook. I started with the "Get Version" command and manually decoded the response. Then I sent the "Get Run-Time Data" command and read the response. I have not done any work to grab the different fields, but it's a start. Hopefully I can have this working enough to record three additional fields by the time air temperatures break 100: rpm, speed, and coolant temperature. I came across a great blog while searching for more information on the serial command checksum: http://arduinobuell.blogspot.com This guy's goals and Arduino setup are different, but he posted some very helpful code to refer to. I'll post an updated logger sketch and schematic once I feel it is reliable. | ||
| Hildstrom |
Also, we can estimate current using the "fan duty cycle" field. We would just need a current measurement at 0 FDC and at 100 FDC to be able to estimate current/power output. | ||
| Timebandit |
Thanks for posting the info on the ECM! It's great to see that another BadWeB'er has already blazed this trail for us! One potential downside that I see to that approach is that you're bandwidth limited by the need to perform bidirectional communication with a fixed number of bytes at 9600-8N1. As Reep' calculated in that other BadWeB thread, that limits your bandwidth to about 4-5 updates/second as a theoretical maximum, with 100% efficiency and no other processes requiring clock ticks on the Arduino. That's probably good enough for grabbing LF thermal data, but not what you'd want if you were trying to design a new external instrument cluster/tach that has to update at high frequency to look good. In that type of scenario, you'd probably be better off just passively sniffing packets off of the CAN rather than constantly bidirectionally polling the ECM via the serial port. This does sound really promising though. I wonder if the Arduino units are going to have enough bandwidth to do everything this project will require, or if we'll have to find a faster embedded device. Very cool news! Thanks for working on this! (Message edited by timebandit on April 28, 2012) | ||
| Timebandit |
"Also, we can estimate current using the "fan duty cycle" field. We would just need a current measurement at 0 FDC and at 100 FDC to be able to estimate current/power output." you're going to have to explain that. i'm not following your idea. | ||
| Hildstrom |
Consider 4 current measurements, related to fan duty cycle and rpm, with my clamp-on meter: * @ 0 FDC & idle * @ 0 FDC & 5000 rpm * @ 100 FDC & idle * @ 100 FDC & 5000 rpm Assuming linear relationships, I could estimate current at say 50 FDC @ 3000 rpm or 75 FDC @ 8000 rpm from the ECM data without installing a current sensor. It's not as good as a current sensor, but it's free and easy. This past weekend, I managed to get the Arduino to print and log rpm, speed, coolant temperature, and fan duty cycle. I still need to work on the conversion/calibration for speed and coolant temperature though. They changed as they should with wheel movement and run time, but the values did not seem to be scaled right. | ||
| Hildstrom |
I agree polling the ECM via serial is not as fast or elegant as sniffing CAN. The arduinobuell project has not been completely optimized. He was using software serial, like I am right now, which consumes a lot of CPU cycles. If Hz is your ultimate goal, use the hardware serial port on the Arduino. That other project was also for DDFI 2, with a different payload. Our DDFI 3 serial polling consists of a 9-byte request (not 8) and a 135-byte response. So, 9*8+135*8 = 1152 bits and 9600/1152 = 8.3 Hz theoretical maximum. There are many faster embedded platforms than Arduino[Mega], but they are not necessarily cheaper or easier to use. In addition to the software->hardware serial change, there are lots of other optimization s that can be done. For example, the following Arduino C++ Library functions have a lot of overhead: Serial.read, Serial.write, EEPROM.read, EEPROM.write, and analogRead. Converting key sections of an Arduino sketch to straight AVR-GCC will speed things up a lot. Calling analogRead to read a thermistor output ends up calling code to check/set timer registers, check/set GPIO registers, set read bit in corresponding register, wait for the done bit in corresponding register, and finally read the A/D result into memory. That works fine, but it is slow and subsequent measurements really only need to trigger the A/D and read the result when interrupted or polled done. That is part of the reason Arduino is so nice to prototype with. You can get started by using the high-level Arduino C++ Library and refine down to C or assembly as necessary and as you learn. If you need a lot more horsepower in a similar form factor, you may consider the BeagleBone. | ||
| Hildstrom |
I've got the ECM data logging pretty reliably now. The logger now records 4 sensors (stator thermocouple, regulator temperature, air temperature, battery voltage*255/15) and 4 ECM values (RPM*255/12000, VSS, CLT, Fan_Duty). I'm displaying everything at 1/5Hz to the USB/serial monitor and logging at 1/60Hz to the EEPROM. It checks the ECM response byte count and checksum before extracting values to avoid corrupt data. It's not currently fast enough for a gauge cluster and I'm sure it's not perfect, but it should be fine for what I am doing. I'll post some more data after my next long ride. | ||
| Dannybuell |
Great!! | ||
| Hildstrom |
Here is my first commute with ECM data being logged. I took a route home with less highway and a lot more traffic lights. Temperatures are still in a safe range, but the most interesting thing is that the fan duty cycle field exceeded 100%. My best guess is that this value is calculated based on what the ECM thinks is needed and that values above 100 indicate you are at the mercy of ambient air temperatures and ambient air flow. Here are the results from logdata03.txt:   | ||
| Dannybuell |
At 42-52 minutes, when speed is almost zero, the battery voltage really drops. | ||
| Hildstrom |
Notice rpm and fan duty cycle during that time too. Too much current (from the fans) and too low rpm (from idling) to keep the voltage up. | ||
| Yugi |
What does fan duty cycle mean? | ||
| Hildstrom |
Fan duty cycle is the duty cycle of the radiator cooling fans. The ECM probably drives them at different speeds using pulse-width modulation by varying the duty cycle. If both fans are connected to 12V 100% of the time, that is 100% duty cycle and full power for the fans. If both fans are connected to 12V for 10ms and disconnected for 10ms, power is only flowing 50% of the time, which is a 50% duty cycle and half power for the fans. | ||
| Timebandit |
serial BW just isn't fast enough, so it looks like we're going to be opening the CAN of worms. | ||
| Hildstrom |
Regarding the air cooling rotor modification: The air in the engine is more of an air/oil mist, so I think it can move more heat than pure dry air, but certainly not as much as directly sprayed oil from the EBR rotor. The holes I drilled in the rotor function as a crude impeller / centrifugal air pump for forced convection, not as vents for nautral convection. For that to be beneficial, a source of cool or ambient temperature air inside the engine is not necessary; just air cooler than an overheating stator flowing more than stock. I acknowledge that I do not know how much air it pumps, how much it reduces stator temperature, how much it weakened the rotor, or if it would be a sufficient solution with the stock shunt regulator. I felt it was likely to be an easy, safe, and beneficial DIY modification; otherwise I would not have done it. (Message edited by hildstrom on May 08, 2012) | ||
| Timebandit |
if you're at all worried about sample rate, it might be worth changing the code to use single precision floats rather than double precision floats. double precision floats take 4x longer to execute, and that's got to be slowing things down a bit. | ||
| Timebandit |
for anyone who's interested in CAN-logging I'm going to cut and paste my comments from the XB forum support thread on the ArduinoBuell project. Mesozoic had suggested using the TI/Luminary products instead of the "gutless" Arduino. I took a look at the Luminary Micro products for CAN logging. Luminary Micro is a TI product now. I wanted the LM4F232 kit, which is the latest and fastest processor. Unfortunately, choosing the best development board isn't as easy as it sounds. Right now TI is offering the board in four flavors: http://www.ti.com/tool/ek-lm4f232?DCMP=cortexm4f&H QS=ek-lm4f232 Unfortunately, there aren't any adequate on-line descriptions that accurately disclose what each of these packages offers and how they're different. Looking for documentation on how the CAN feature works? Good luck, there isn't any. It's just a port on the board. To find answers about product differentiation you have to call TI tech support and prod them with questions to get the information that your really need to know. By doing that you'll learn that all of the $150 board + bundled software packages are nothing more than crippleware demos for the software development companies; the SDKs are either: board-locked so that they only work with the development board; code-size limited so that the size of your application cannot be very large; or usage-time limited so that the application suite stops working after either 30 or 90 days. Your basic choice in buying these products is to determine in which way you're willing to be screwed. Then, once you buy a product you can use it until you hit the wall by running out of demonstration days or code space. When that happens your only option is to buy one of the retail SDKs, which have retail prices in the range of $1400+. I convinced that these packages are unsuitable for DIY consumer/enthusiast use. They are marketed toward corporate clients that won't blink at spending thousands of dollars on applications development when they get squeezed by the software vendor. That kind of marketing makes the "gutless" open source products look pretty good. | ||
| Milt |
Open source is the way to go. Don't like it? Improve it! Do we really need high sample rates at this point? Also, most of the documented run-time data seems to be nicely scaled. Using double floats seems like a case of computational precision far outstripping measurement accuracy. | ||
| Timebandit |
Do we really need high sample rates at this point?" we sure do if we want to look at the data on the CAN bus. as Greg has already shown us, accessing data through the serial port is bandwidth limiting. (Message edited by timebandit on May 12, 2012) | ||
| Timebandit |
Greg, can you tell me if any data is being transmitted via the serial port on the byte at offset 105? According to ECM Spy, two different datum are represented at offset 105, one being sidestand feedback, the other being oil temp. It'd be interesting to know which, if either, is actually assigned to this offset. (Message edited by timebandit on May 12, 2012) | ||
| Hildstrom |
I'm not worried about sample rate; I'm logging at 1/60Hz, so the serial port data is more than fast enough. The CAN-Bus Arduino Shield from Sparkfun offloads bus communication and packet filtering, so you should be able to grab data pretty fast. I read byte 105 from the serial response and it was a static 255 while the bike was running on the rear stand with the side stand up. | ||
| Timebandit |
By 1/60 Hz you mean 1 sample/minute, right? Thanks for looking at byte 105. I was afraid that it was going to be a static number, because AFAIK the USA bikes don't use a kickstand monitor, and no 1125 have an oil temp sending unit. I don't know where ECM-Spy came up with that disinformation, but they listed it in the table for DDFI-3. | ||
| Hildstrom |
Yes, I'm logging to eeprom at 1 sample/minute and displaying to serial at 1 sample every 5 seconds. I can certainly post some of the actual 135-byte hex responses if you'd like to look at them. I could grab one with the engine not running, one at cool idle, and one at 3000 rpm after it warms up. | ||
| Timebandit |
Thanks for the help. All I'm really interested in is byte 105. The value of 255 that tells me what I need to know. It's worthless. | ||
| Timebandit |
Greg, do you have a link to a data sheet for the epoxy that you used? I'm interested in learning what kind of thermal conductivity it has. The units are typically expressed in either: BTU in/hr sq.ft. *F or W/m *C thanks. | ||
| Hildstrom |
J-B Weld does not publish the thermal conductivity of its products. This book lists it as 0.0059 W/(cm*C) or 0.59 W/(m*C), which is about the same as water. Cotronics lists their thermal conductivities in Btu-in/(hr*ft^2*F) and the conversion is about 4. So, J-B Weld has thermal conductivity of about 0.59*4=2.36 Btu-in/(hr*ft^2*F), which is less than Cotronics Duralco 4460/4461. | ||
| Timebandit |
Thanks for that link. I had not had any luck finding the answer for JBWeld. FWIW, I've been using the same conversion factor. It's also located in the back of the Cotronics catalog.  The conductivity data for most of the Cotronics formulations predicts that relative to the thermal conductivity of the copper windings and the iron core, most of the epoxies act as a thermal insulator. I have been performing inductive heating tests of sample cores/coils that are coated with some of the Cotronics formulations that have thermal conductivity measurements in the range you've mentioned, and I haven't been happy with the results. These multipurpose epoxies are ~10x better at insulating the stator than the metallic colloidal suspensions. Another way to say that is that you could apply the suspensions 10x as thick and get the same thermal resistance as the conventional high temp epoxies. Not that you'd ever want to do that; in fact I expect that anyone would do exactly the opposite. Nevertheless, the difference is HUGE. It appears that embedding a thermocouple in a layer of epoxy added to an OEM stator after the time of manufacture is not going to provide me with sufficiently accurate core or coil temperature readings, as the thermal conductivity ratings for the epoxies are intermediate between metal and air. The readings are significantly different from a deeply embedded, properly formed, direct thermal junction from thermocouple to core or thermocouple to winding. As I'm sure you can imagine, creating a proper thermal junction is difficult if not impossible to accomplish on an intact stator / after the epoxy has been cast during manufacture. The kind of measurement device implantation we've been discussing would really be best conceptualized as part of the rewind process, rather than adding it on to an assembled stator after the fact. These observations tend to limit the faith I have in the numbers that will come from attempting to add thermocouples to an OEM stator. It seems that the right answer can only come from creating proper thermal junctions as an integral part of the rewinding process, and taking measurements from a stator that was designed from the beginning to have embedded temperature sensors. I just thought I'd pass this along since you're working under a similar model. | ||
| Posplayr |
Timebandit, I think you are starting to understand the "art" of engineering. You can't always measure everything you want and need to rely on other means. |
