| Author | Message | ||
     Reepicheep |
It's a practical design for the application. Crunch through the math for the heat dissipation (watts) for a series regulator when the bike is drawing a high current load and the RPM's are very high (meaning the AC voltage is pushing 70 volts). On the up side, you would get a nice seat warmer, until the regulator melts through your tail section.  | ||
| Timebandit |
You guys are right -- this stator business isn't a new problem. Bikes with stators have had problems for a long time, some worse than others. Stator/rotor charging systems are the ultimate in low technology charging systems. IMO they belong on lawn mowers. Excessive heat production from stator based charging systems is a universal problem. It's their characteristic design weakness. It's one reason that stator/rotor charging systems aren't always the best design choice. Nonetheless, to save cost and weight, manufacturers of sportbikes put crappy stator/rotor charging systems on their products, minimizing weight because weight matters. A conscious decision has been made regarding failures, and that coincides with a master plan that involves selling replacement stators to their customers when they fail. Parts are a revenue stream. This is no accident. So if you want to protect yourself, and free yourself from the chains of buying expensive replacement parts at the dealer parts counter, then you have to make some changes. Rewinding is an option. So is changing the regulator. But the problem is that series regulators aren't quite as reliable as shunt regulators in some applications, and replacing them might just amount to moving the problem from the stator to a more readily serviceable location. Stator/rotor charging systems always run hot, because their magnetic field is fixed by a permanent magnet. System output depends on RPM and nothing else. An alternator, where the magnetic field is varied on demand, is a much more efficient system. It weighs more and it costs more, but it runs very cool and is very reliable. It's no coincidence that alternators are the system of choice in cars, where stators would never be tolerated. Sportbikes don't use them, though my BMW sport-touring bike does. It uses the same Bosch alternator you'd find on a VW Jetta. The bike runs cool for an oil cooled bike, and it's very reliable. The decision to put stators on bikes instead of alternators is one where a tradeoff decision was made. Period. Everyone needs to understand that. Everyone needs to understand that when they buy a bike that has a stator/rotor charging system, they're getting the ultimate in low technology that runs hot, and that problems will come with the purchase. We also know that the 1125 bike runs pretty hot. It's cooling system is marginally adequate. This all adds up to a poor outcome for stators in the stock configuration. Throw the shunt regulator in on top of that, which is merciless in terms of the energy that it forces the stator to dissipate, and things get a lot worse. Shunt regulators are pretty reliable though. They tend not to have the failure rates at high loads that series regs have, and not to have the failure rates at high RPM that series regs have, because they keep the burden of heat dissipation out of the regulator and in the stator. In the big scheme of things, the energy has to go somewhere in the system. There isn't a free lunch, and in some respects making changes to the charging system is like playing whack a mole -- you knock the problem out in one place only to see it pop up in another. It's important to understand this, so that when you make changes to the system, you understand what kind of outcomes to expect down the road. | ||
| Timebandit |
70 volts? the "low output" 2008 system will produce 127VAC if you can get it to 10,000 RPM. at that level the input power into the system is a bit over 4 kW. (Message edited by timebandit on April 20, 2012) | ||
| Reepicheep |
LOL. I keep outing myself as a non 1125 guy. We have a lower redline (but more reliable stators  ) | ||
| Timebandit |
you have fluid cooling with the primary chain throwing lube all over the place. | ||
| Hildstrom |
I commuted for a week with daytime highs in the upper 80s and low 90s. Here are the results from logdata02.txt:  The log data revolved and you can only see a portion of my first 80-minute test ride remaining around minute 170. My commute is usually 20-30 minutes. The lower peaks at 40, 95, 138, 205, and 248 are the end of my morning commutes. The higher peaks at 20, 65, 120, 156, and 230 are the end of my afternoon commutes. The dips in battery voltage at 10, 55, 115, and 220 correspond to sitting through 3-4 consecutive traffic lights toward the end of my evening commute. Both radiator fans draw enough current to reduce idle voltage to the low 12s. What is really interesting is the amount of time required to get the stator up to full temperature; at least with these modifications and air temperatures. My 30-minute afternoon commute with several traffic lights was not long enough to get the stator up to the same temperature recorded during my long test ride, which is a good thing. The small peak at 75 was a quick test after fixing my ignition cover gasket situation. The small peak at 98 was a quick 3-mile ride from my office to my wife's office. | ||
| Dannybuell |
This may be way out there, what determines time difference between battery drop and regulator start? | ||
| Timebandit |
This is interesting. Your data shows that you don't get the stator very hot in 20-30 minutes of riding, and that it would probably get a lot hotter if you kept going. This observation agrees with my forensic analysis of dead stators, which suggested that stators last longer on short mileage trips than on long mileage trips, all other things being equal. That makes sense, as it's the temperature-time product that is your enemy. It would really help to chart RPM and MPH for reference. It's hard to know what kind of load you're actually putting on the motor without that information. That said, the chart suggests that most of the time you don't ride long enough to determine the maximum plateau value for Tstator; we see this on the chart, where Tstator is a continuously increasing function that rarely if ever reaches a plateau before you shut the bike off. What would be really interesting would be to take your bike for a 3 hour ride, and see how hot the stator gets when you give it time to keep heating. It would be *really* interesting to compare 3 hours on the slab to 3 hours on the backroads. The other interesting thing would be to know if your data were collected at sub-5000 RPM, or high-RPM, and what kind of MPH you are running in terms of oil/air flow. Without knowing that, I can't draw any firm conclusions. | ||
| Timebandit |
Just noticed that your Tambient sensor shows data that looks like it is continuously increasing during the rides. Was the ambient temperature actually increasing like that, or do you have a problem with probe location? | ||
| Hildstrom |
Dannybuell: I'm not quite sure what you're asking. Timebandit: I agree. It was mostly under 5000 RPM, just like before, and under 70mph. The 80-minute ride data I posted before shows a plateau for those riding conditions. Note of all of the decreases in ambient air temperature during increases in stator temperature; Tambient is definitely not continuously increasing. I put the ambient air temperature sensor where I felt it would get little interference while stopped with the fans running. | ||
| Dannybuell |
IDK anything, just trying to keep up. It looks like when battery voltage (pink) drops then the regulator goes up (green). Does that mean the regulator went on in response to the drop in voltage? | ||
| Timebandit |
"Tambient is definitely not continuously increasing." This is what I was referring to. It looks like the overall trend for Tambient is to increase at the same time that the Tstator curves are climbing.  | ||
| Timebandit |
Maybe I can answer what I think Danny is asking. The regulator is "ON" whenever the motor is running. It's never completely "OFF" while the motor is running. Whenever it is "ON", it is actually being switched on and off very quickly, varying the Ton / Toff duty cycle on-demand in response to output voltage. But for practical purposes, we need to think of the regulator being "ON" and functioning whenever the bike is running. Voltage drops at idle because the stator is a mechanical device that cannot violate Faraday's law; the AC output voltage of the stator is proportional to the rate of change of magnetic flux, i.e. rotor RPM. Below a critical level there is not enough surplus AC voltage to regulate at 14.x, so voltages sag when RPM falls below a critical threshold. When the fans are on, current draw creates an additional drain on the system, and voltages sag further. I see Tvreg correlating with Tstator, which both correlate with running time. Temperature rises as an artifact of work being performed by the charging system components. (Message edited by timebandit on April 24, 2012) | ||
| Hildstrom |
Dannybuell: The drops in battery voltage correspond to idling at consecutive traffic lights. Stator voltage is low, air flow is low, and current is high from the radiator fans. That means more current and less cooling for the rectifier, so it continues to heat up. Timebandit: The times you chose were the entire morning commutes and in some cases also the first few minutes of the afternoon commutes. In the morning, the sun heats everything relatively quickly here in south Texas and the air temperature is definitely higher when I get to work than when I leave home. When I leave work, I go from shaded concrete to shaded asphalt to sun-baked asphalt surrounded by cars, which accounts for the first few minutes of rising air temperature in the afternoon. | ||
| Dannybuell |
Hildstrom ~ Thank You. Some people on this forum have relocated their regulators and/or placed CPU type cooling systems on their regulators. Does your data suggest a need for this? | ||
| Hildstrom |
Dannybuell: My CE-605 SB regulator is mounted here:  | ||
| Timebandit |
Just wanted to ask a few questions about the rewinding before I get prepared for trying to rebuild a failed stator: 1. Is the OEM stator wire 16-ga or did you change wire gauge? I seem to remember someone saying that it was an odd-numbered wire gauge, or perhaps even a fractional wire gauge, but now I can't find that old post. 2. Did you keep the identical number of turns on each pole, and in each layer on each pole? I seem to remember that being the case, but I just wanted to double check. 3. What's the meaning of the "e" suffix in the rewind pictures. I see some poles that are associated with phases 1, 2 and 3, while some of them have an "e" appended to the number. Not sure what the "e" is supposed to be telling me. Thanks! (Message edited by timebandit on April 25, 2012) | ||
| Hildstrom |
Timebandit: The answers to your first two questions are here and here. I sanded the insulation off the original wire as lightly as possible to get to bare copper, measured it with a micrometer in a couple places, and it was closest to 16 AWG. I kept the original turns/pole at 44. I counted many of the original poles I unwound and they were all identical. Each rewound pole was close to 13, 13, 13, 5 turns for 4 layers and 44 total turns. The turns/layer differed for some poles because of my imperfect manual winding, but the total turns/pole was always 44. The s and e suffixes signify the start and end of each phase; the order those poles were wound for each phase. Follow the arrows in the center of the stator rewind diagram and the numbering: 1s->1->1->1e, 2s->2->2->2e, 3s->3->3->3e. Then they are connected delta with the following pairs twisted together at the following locations: 2e&3s @ 2e/3e, 3e&1s @ 3e/1s, 1e&2s @ 1s/2s. I installed my thermocouple at the base between 1e/2e, about the 12 o'clock or 12:30 position, which was the next hottest location that did not already have delta pairs running between poles. I put enough epoxy on top of the thermocouple so the gap between poles was similar to adjacent poles where the delta wires run. | ||
| Timebandit |
"Then they are connected delta with the following pairs twisted together at the following locations: 2e&3s @ 2e/3e, 3e&1s @ 3e/1s, 1e&2s @ 1s/2s." It's hard to see the wires and trace them in the pictures. That last bit of info helps a lot. Thanks. | ||
| Timebandit |
Another question for you, this time about your logger: Does the Arduino unit allow you to use different types of thermocouples such as Type J and Type T, or is it only compatible with Type K? When I looked at the scripts, it looked like the system does not provide a feature to allow the user to define the type of thermocouple that's in use. Maybe I'm missing something? | ||
| Hildstrom |
Here is a condensed page for rewinding without the rest of my experimentation breaking up the flow. The MAX6675 chip I used only works with Type K thermocouples. There is no software option to switch types. A very similar chip, the MAX31855, is the newer replacement for the MAX6675 and it is available for all thermocouples types: MAX31855K, MAX31855J, MAX31855T, etc. The functions readCelsius and spiread in max6675.cpp would need to change slightly because of the extra spi bits output by the new chip, but it should be very similar overall. | ||
| Hildstrom |
Also, the MAX6603 chip looks like it would be helpful if you decide to use RTDs. | ||
| Timebandit |
Thanks. I've got type K, J and T on the bench right now. We've had custom/encased probes built in Type J for Toil, and custom/perforated probes built in Type J for Tamb. We're embedding some of our stator sensors using Type T. The problem is that our commercial 4-channel handheld, battery-powered meter/logging unit is friendly to all types, but not to different types at the same time. <sigh> We can select among several types of TCs for data acquisition, but we cannot mix the types concurrently. This means that we have to develop our own custom logger that will allow us to use different types of sensors on different channels, or we have to have new sensors made <argh> that will all be Type T, so that the removable sensors match the types that are being embedded irreversibly in the stators. The one-type at a time limitation is kind of disappointing, as we have had some really nice custom probes fabricated using type J thermocouples. I know you guys reading this like porn, so I'll post some pics in the other thread. | ||
| Hildstrom |
From your other post it looks like you'll want two Type J (MAX31855J) and two Type T (MAX31855T) at minimum. An Arduino/ProtoShield/MAX31855 based logger can support that without much effort. Also, this CAN-BUS Shield may be of interest to you. You could stack Arduino/CAN-BUS Shield/ProtoShield. A few things, like the joy stick and leds, could be removed from the CAN-BUS Shield to allow for more sensors. This would get you CAN data logging and up to 12 sensors (thermocouples, thermistors, voltage, current, etc). The CAN-BUS Shield also has microSD, so you could log tons of data without being limited to the 1KB EEPROM like I am. A step up to the Arduino Mega 2560 and the MegaShield could support even more sensors. Using 1/60Hz would probably not cut it when you start talking about recording speed and rpm, but 1Hz would probably be fine. Are you planning on recording/logging on a stand/dyno or while riding? What sample rate do you plan on using? | ||
| Timebandit |
Thanks for the help. Right now the plan is to have our sensors remade, so that they will all be of the same type. We don't want to get into incompatibility problems. It'll be easiest on us to reconfigure things if every sensor will work with every data port. I am aware of the CAN-bus shield. The problem is that although it will take the CAN-bus data and write it to SD, the problem remains that you end up with a pile of well logged, but indecipherable data. If you're familiar with the CAN-bus protocol, there is a universal standard regarding packet transmission, and how the payload is lofted across the net. The problem that comes along is that we could easily have the ability to log packets, but we'd still have no way to perform deep packet inspection to decipher them. THAT is the hurdle. We need a copy of the translation database that the IC uses to convert bus data into IC display data. Or we have to reverse engineer everything done by the IC. Yikes. We are already looking at recording 12-18 channels. Sampling rate may have to change depending on what parameters we are looking at; internal regulator behavior would need to be sampled at high speed, but for simple temp measurements the sampling rate can be quite low. | ||
| Hildstrom |
It seems there is plenty of information available to get the run-time ECU data via serial instead of CAN. I know it is not as fast, but you should be able to grab everything at 1Hz or better. You could use an activated version of EcmSpy to log. You could also use the published information and PalmOS source to roll your own serial data logger. If we could get the connect/request/response figured out, it would be relatively easy to grab the serial data with two free pins on an Arduino too. | ||
| Timebandit |
interesting. the serial connection is at 9600-8n1. one benefit of sniffing the CAN bus traffic is that sniffing and logging is a totally passive act. the downside to serial communication is that you have to write an application to generate inquiries and log the data. then you have to synchronize and blend separate sets of data logs that are collected by separate devices to analyze the data. i'm not sure that i want to turn this into a software applications development project. not any more than i have to... i think that it would be a lot easier to just sniff the can bus, logging relevant packets while ignoring the others. if we could find a way to do that, that is. the good news is that there are options. the bad news is that they all involve sadlling-up someone for a lot more work. (Message edited by timebandit on April 26, 2012) | ||
| Milt |
Given packets (or a byte stream) and a spec, I can build a parser. | ||
| Timebandit |
Thanks, Milt! My understanding is that the CAN-Bus operates on the specs discussed in this thread: www.badweatherbikers.com/buell/messages/290431/675912.html The CAN-bus is accessible under your left pod. It's the 2-pin deutsch connector right in front of the ECM. Parsing isn't a problem for me. The real problem is that we don't have a database to translate the data once it's been parsed.   | ||
| Milt |
I'm not clear on what you mean. Are you lacking a way of assigning meaning to the parsed fields? Or are you lacking a way to store, retrieve and analyze the data? |
