- The entire controller gets extremely hot at 50A with the stock transistors, probably too hot for continuous duty without a fan. However, the limit is probably purely thermal - I did most of my initial testing with a 50A max current setpoint with the motor coupled to a second chainsaw motor driving a dead short, and both the current loop and short-term behavior of the controller seemed reasonable.
- Likewise, the motor is not good for 50A under stall or near-stall conditions; everything gets rather hot. However, at reasonable RPM it is probably actually a 2KW motor thanks to the integrated fan.
- Without some further connection on the blue "COMM" wire coming out of the battery, the integrated BMS shuts off at 25A. Charles has gotten 65A out of the battery, so presumably reconnecting this wire will enable high current operation; given the lack of thermal protection on both controller and motor some adaptive current limiting will probably be necessary to keep temperatures down.
- If you want to upgrade the MOSFETs, go for the lowest Rds,on FETs you can afford - gate charge doesn't really matter given the 10nF parallel capacitor on the gate. Furthermore, only 1/6 of the FETs are switching at any one time, and only at 8KHz, so switching losses are negligible. In fact, switching too fast will result in nasty transients and FET failures (don't use logic level FETs!).
- The 40V voltage limit is pretty hard with the board in its stock state; the high-side gate drive BJTs see 55V and are rated to 65V. Likewise, the LVPS assembly is not going to appreciate any sort of significant overdrive. Replacing the BJTs with 100V parts might allow it to operate at a 48V nominal pack voltage.
- Post-PRS Detroit update: confirmed that the time to failure of the stock chainsaw without fan is 15 minutes with a 40A current limit under vehicular load, so a fan is definitely needed for continuous operation at high power. The sensors on the motor are also phased so that reverse performance is extremely poor.
Monday, October 27, 2014
RY40511: a few notes
Stuff to note for other tinkerers out there:
Frozen Chainsaw Massacre Part 2: New firmware
So previously I had briefly mentioned a scooter built out of a brushless chainsaw; remarkably enough, it worked well enough so that we (Peter and I) decided to write new firmware for the chainsaw to make it behave more like a vehicle and less like a power tool.
The first step was to trace out the schematic for the board. After a couple hours of rooting around the board we came up with this:
The PNP transistors are BC856B'; the NPN transistors are BC846's. The MOSFETS are Alpha Omega AOT470's - pretty generic 100V 10mOhm FETs with 130nC of gate charge; not high performance by any means but they work.
Next we needed to set up the PWMs and interrupts to get the motor turning. The following snippet of code initializes the timers to do block commutation with high-side PWM:
This configures the high side PWM's to be enabled, and leaves the low side pins free for GPIO use.
The actual commutation is done by the following function, which is called every time the hall sensors change:
htable[] and ltable[] are lookup tables for the states of the high and low side FETs in each phase.
This was enough to get the motor turning; the next step was to read the current shunt and add some overcurrent detection. Unfortunately, the current surge during motor startup in open-loop mode was enough to trip even a 300A current limit.
We added a current loop, which ran in a main() to avoid conflicting with commutation:
After dealing with a bunch of minor-but-deadly bugs with the current loop (and in the process killing a couple dozen transistors), the motor seemed to more or less turn smoothly.
Next we added stall protection - the firmware would compute the speed of the motor and limit the duty cycle to 10% if the speed was too low. This inevitably resulted in a few more dead transistors due to integral windup, but worked pretty effectively after the bugs were fixed, giving just enough startup torque to move the scooter without pushing dangerous amounts of phase current.
At this point we were a couple weekends and ~50 dead MOSFETs (and about a hundred little BJT's) into the project and it was getting to be pretty late. We figured that before we plugged it into the battery we should investigate the startup transient of the micrcontroller. This resulted in the removal of a bug that caused a brief shoot-through event on startup (the timer duty cycles and complementary modes were not being initialized before the PWM channels were enabled) and the loss of another bridge.
We couldn't figure out what was up with the damaged bridge - no amount of replacing shorted MOSFETs could restore it to functionality. Eventually we replaced all of the transistors, and it worked again. Lesson learned: zombie-FETs are a thing.
Get the code here. To flash it, solder a 4-pin header to the "P0" pads on the board and connect a STM8 programmer, notch side in, to the header. You'll also need to configure the option bytes to set the correct alternate functions for the timer pins, which is pretty trivial in ST Visual Programmer. Code tested to work in IAR studio, definitely will not compile in other environments without some tweaking.
The default settings (constants.h) set the max current limit to ~25A (controller gets real hot above that) and UVLO to 20V (gate drives brown out below that).
The first step was to trace out the schematic for the board. After a couple hours of rooting around the board we came up with this:
The PNP transistors are BC856B'; the NPN transistors are BC846's. The MOSFETS are Alpha Omega AOT470's - pretty generic 100V 10mOhm FETs with 130nC of gate charge; not high performance by any means but they work.
Next we needed to set up the PWMs and interrupts to get the motor turning. The following snippet of code initializes the timers to do block commutation with high-side PWM:
This configures the high side PWM's to be enabled, and leaves the low side pins free for GPIO use.
The actual commutation is done by the following function, which is called every time the hall sensors change:
htable[] and ltable[] are lookup tables for the states of the high and low side FETs in each phase.
This was enough to get the motor turning; the next step was to read the current shunt and add some overcurrent detection. Unfortunately, the current surge during motor startup in open-loop mode was enough to trip even a 300A current limit.
We added a current loop, which ran in a main() to avoid conflicting with commutation:
After dealing with a bunch of minor-but-deadly bugs with the current loop (and in the process killing a couple dozen transistors), the motor seemed to more or less turn smoothly.
Next we added stall protection - the firmware would compute the speed of the motor and limit the duty cycle to 10% if the speed was too low. This inevitably resulted in a few more dead transistors due to integral windup, but worked pretty effectively after the bugs were fixed, giving just enough startup torque to move the scooter without pushing dangerous amounts of phase current.
At this point we were a couple weekends and ~50 dead MOSFETs (and about a hundred little BJT's) into the project and it was getting to be pretty late. We figured that before we plugged it into the battery we should investigate the startup transient of the micrcontroller. This resulted in the removal of a bug that caused a brief shoot-through event on startup (the timer duty cycles and complementary modes were not being initialized before the PWM channels were enabled) and the loss of another bridge.
We couldn't figure out what was up with the damaged bridge - no amount of replacing shorted MOSFETs could restore it to functionality. Eventually we replaced all of the transistors, and it worked again. Lesson learned: zombie-FETs are a thing.
Get the code here. To flash it, solder a 4-pin header to the "P0" pads on the board and connect a STM8 programmer, notch side in, to the header. You'll also need to configure the option bytes to set the correct alternate functions for the timer pins, which is pretty trivial in ST Visual Programmer. Code tested to work in IAR studio, definitely will not compile in other environments without some tweaking.
The default settings (constants.h) set the max current limit to ~25A (controller gets real hot above that) and UVLO to 20V (gate drives brown out below that).
Monday, October 6, 2014
Frozen Chainsaw Massacre: Ryobi RY40511 Cordless 40V Chainsaw on a scooter
Following up on Charles' blog post here I decided to snag one of these chainsaws for myself and see how it faired in vehicle duty.
The end result:
The scooter turned out remarkably rideable, except for the extremely annoying motor controller cut-in behavior, which gave the motor the start-up behavior of a gas engine- if throttle was applied from a standstill too quickly, the motor would cut out, requiring a controller reset. The motor had to be ramped up to speed over the course of several seconds to work properly.
The only way to fix this was to reflash the controller with new firmware. Conveniently enough, there was an unpopulated programming/debug header on the board. We rooted around the board for a while and came up with this schematic:
Next up: port my sinewave controller firmware to the STM8S micro that the board uses.
The end result:
 |
| Chainsaw on a Disney Princess scooter - hence the name |
The only way to fix this was to reflash the controller with new firmware. Conveniently enough, there was an unpopulated programming/debug header on the board. We rooted around the board for a while and came up with this schematic:
Next up: port my sinewave controller firmware to the STM8S micro that the board uses.
Sunday, October 5, 2014
Greenlight HPS Part 3: Planning an Attack
(Warning, wall of text!)
So we had this laser which probably not only had more interlocks than a nuclear reactor, but also actively prevented us from defeating those interlocks. What we wanted in the end was to be able to dial in a diode current, and have the diode driver run the diodes at that current. We also needed the crystal temperatures, water temperatures, and Q-switch settings to automatically adjust themselves according to the user current setting.
From the service information AMS had leaked on their website (the AMS Technical Services site is riddled with holes), we knew the following:
Knowing this, we had several approaches to turning on the laser.
So we had this laser which probably not only had more interlocks than a nuclear reactor, but also actively prevented us from defeating those interlocks. What we wanted in the end was to be able to dial in a diode current, and have the diode driver run the diodes at that current. We also needed the crystal temperatures, water temperatures, and Q-switch settings to automatically adjust themselves according to the user current setting.
From the service information AMS had leaked on their website (the AMS Technical Services site is riddled with holes), we knew the following:
- The service fix [Check CAN bus cables between LCB and LPS] to problem 130 in the HPS Problem Codes indicated that the subassemblies communicated via CAN (an automotive bus).
- The description of problem 209, [A voltage supply is out of spec. on the Laser Power Supply/Vuemetrix board] indicated that the diode driver was manufactured by Vuemetrix. The output power suggested that it was a variant of the VueHV stack driver.
- The following screenshot from an instructional document shows the current vs. power for a typical laser:
 |
| XPS but you get the idea |
- Disassemble the laser into constituent subcomponents, turn on those subcomponents, and reassemble into a laser. This meant figuring out how to turn on the chiller, diode driver, and Q-switch driver. We knew the Vuemetrix driver could probably be persuaded to connect to the VueHV software, and the Q-switch driver was a stock NEOS part.
- Spoof a surgical smartcard. We were able to get a smartcard off of eBay. The card had "Atmel" written on it, which meant it used an Atmel Cryptomemory secure IC. The cryptomemory had several known exploits, including a brute-force approach which would have taken ~70 days on my fastest machine, and a power analysis approach which was more involved, but would have only taken a few minutes.
- Exploit the unencrypted nature of the CAN bus to figure out what messages did what, and build a new controller that played the appropriate messages over the bus.
(1) had the advantage of being guaranteed to work; however, it meant we would lose the self-protection that the stock Laserscope controller provided, and we figured that having things like underflow and overtemp were good. (2) was also known to work, and was pretty much a standard power analysis attack; unfortunately, neither of us had much experience in such techniques. (2) would have also given us a completely turn-key way to turn on the laser, one that did not involve any extra hardware.
We decided to go with #3 because we had access to a borrowed CAN transceiver, and we figured it was a good middle ground between keeping enough of the internal firmware to protect the laser, while allowing us to hopefully build a custom user interface that did not look like a medical interface (as cute as the touchscreen was, being able to monitor critical laser parameters and set power in something other than 10W increments would have been real useful!)
Greenlight HPS Part 2: First Light
So we had this beautiful laser, and no clue how to turn it on...
This self-test mode would prove critical to getting the laser to turn on under our control, as you will soon see.
The first step was to plug it in and see what happened. We knew it had a chiller error, and indeed, after a few minutes warming up, it threw an "error 611", which was a flow error.
After some fiddling with the internal valves we were able to clear the flow error - it turned out that one of the flow restrictors was set improperly, which resulted in the diodes receiving too little flow. At this point, the laser booted, and, as expected, we could do nothing without a fiber and a smart card.
However, at some point during the weekend, one of us decided to pull the lid off of the resonator before booting the laser, at which point we saw this:
It turned out that part of the boot process was to check actual power against the internal open-loop P/I (power/current) table, and that involved turning on the laser.
Unfortunately, somewhere during the process the laser threw an error 210, "Diode Stack Overvoltage". This sounded ominous, and indeed, after we disassembled the head it turned out one of the diodes had shat itself and failed open circuit. Undaunted, we replaced the open diode with a blob of solder paste and reassembled the stack, and the laser kept going. Little did we know...
With the diode stack fixed, it was simple to put a turning mirror in the resonator and get a beam out of the head:
However, at some point during the weekend, one of us decided to pull the lid off of the resonator before booting the laser, at which point we saw this:
 |
| Green?! |
Unfortunately, somewhere during the process the laser threw an error 210, "Diode Stack Overvoltage". This sounded ominous, and indeed, after we disassembled the head it turned out one of the diodes had shat itself and failed open circuit. Undaunted, we replaced the open diode with a blob of solder paste and reassembled the stack, and the laser kept going. Little did we know...
With the diode stack fixed, it was simple to put a turning mirror in the resonator and get a beam out of the head:
 |
| Really ass photo |
Greenlight HPS Part 1: Getting to Know You
This particular story starts a year ago, on a cold night in February 2013. I had recently acquired a classic Laserscope KTP/YAG system off of eBay, and I think we (my friend Peter and I) had just gotten the thing to turn on after disassembling it entirely for transport. We were browsing all the overpriced Laserscopes on eBay (the going price of a surplus KTP/YAG was sub-$1000 at the time, and there were a whole bunch of fancy new-model ones that were between $2-6K) when we noticed a couple things:
Instead, we found this:
Evidently, Laserscope had chosen to use modern high-density microchannel modules and some sort of end-pumping scheme, the latter of which we didn't know was possible (uneven absorption down the length of the rod in high-power applications leads to thermal failures, and short rods neither have enough thermal dissipation nor gain to produce the necessary power). We later found a patent which documents the entire scheme.
The diode stack had micro-lenses on each bar, and a train of collimating optics consisting of some lenses and what appeared to be a lens duct focused the stack's output onto the end of the ~10mm YAG rod.
The laser also had a diode driver made by Vuemetrix and a Lytron recirculating chiller.
And last but not least, a cavity shot (note we had not gotten any power out at this point; this photo is merely illustrative since it shows the beam path nicely).
- The new Laserscopes were marketed as "Greenlight HPS" and were manufactured by a company named AMS. Presumably AMS had bought out Laserscope sometime in '07.
- The "Greenlight HPS"was a 120W system, significantly more than the 40W the KTP/YAG was rated for.
The latter was not too exciting; the Greenlight PV (which was known to the hobbyist community) was an 80W lamp-pumped system that pulled 50A@220V. Then we noticed the line requirement sticker on the back of the laser in one of the eBay listings:
 |
| something fishy is going on... |
See that? 120W of green out of a 20A 220V single phase outlet - 50% more power than the PV at under half the power draw. We had a hunch that this might be a DPSS laser, and fortunately, AMS's website quickly confirmed that.
We were lucky - there was a unit on eBay for $1800 that was throwing error 611. The very sparse operator's manual (intended for doctors and other end-users) indicated that error class 600 was a chiller error, so we figured that the chances that the laser was repairable was high. We also learned a few other things:
- The HPS has encrypted smart cards which encode the usage of each fiber. This presumably allows AMS to sell more fibers; each fiber will only operate for 120 min or 250kJ (whichever comes first) before needing to be replaced.
- Unlike the KTP/YAG, which had interlocks that were simply digital lines, the HPS has a fairly complex system of computers inside which manage security and interlocks.
- At least two other people in the community owned one of these lasers, but neither had been able to defeat the interlocks and turn on the laser.
We figured that it was worth a shot nevertheless, after all, the most important part was the laser head, and interlocks or not a 120W head for $1800 was not bad. Also, how strong could the security be, anyway?
One week later...
The laser finally showed up, and the first thing to do, of course, was to pull off the covers and take a look at the innards. Peter and I had been both expecting gain modules side-pumped by a few hundred watts of diodes in the form of a couple dozen bars, such as in the Coherent Avia:
 |
| mmm donuts |
 |
| wut? |
The diode stack had micro-lenses on each bar, and a train of collimating optics consisting of some lenses and what appeared to be a lens duct focused the stack's output onto the end of the ~10mm YAG rod.
 |
| diode close-up |
 |
| diode driver |
 |
| chiller |
 |
| green! |
Sinusoidal Arduino BLDC controller
Will write better documentation later, mostly uploaded for reference now. Get the source here.
It interfaces with three half-bridge drivers with inverting inputs (it was written to drive the Prius IPM, which behaves as such). No throttle support yet (I was more interested in getting sinusoidal PWM working) but that should be real easy to add.
Connect your phases to digital pins 5, 6, and 11 and your Hall sensors to pins A0, A1, and A2.
It interfaces with three half-bridge drivers with inverting inputs (it was written to drive the Prius IPM, which behaves as such). No throttle support yet (I was more interested in getting sinusoidal PWM working) but that should be real easy to add.
Connect your phases to digital pins 5, 6, and 11 and your Hall sensors to pins A0, A1, and A2.
Subscribe to:
Posts (Atom)