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:
Chainsaw on a Disney Princess scooter - hence the name
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.

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:

  • 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
Knowing this, we had several approaches to turning on the laser.

  1. 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.
  2. 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.
  3. 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...

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:

Really ass photo
This self-test mode would prove critical to getting the laser to turn on under our control, as you will soon see.

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:
  • 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:
  1. 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.
  2. 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.
  3. 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
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.

diode close-up
The laser also had a diode driver made by Vuemetrix and a Lytron recirculating chiller.
diode driver

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).


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.

Wednesday, September 11, 2013

Fun with USB

So I wanted to get rid of the USB-MIDI cable needed to run my Tesla coils and save 5 bucks...

Actually, I wanted to save as much as possible, and keep things through-hole. Fortunately, there exists a library called V-USB that implements a software USB stack on Atmel microcontrollers.

As usual, it starts with a board. Fortunately the actual hardware design was pretty trivial - the board consists of an ATTiny85, a micro-USB jack (mini-USB is so 2005), an output connector, and a couple of passives. The design is mostly based on this fellow's work here. I didn't want the diodes dropping the voltage down to 3.6V, so I left them out in the initial design. The boards were sent out to OSH Park since I was feeling cheap and didn't want to send out for a $100 Myro order, and a couple weeks later I had them on hand.

After putting a board together and plugging it in, I was immediately greeted with a very warm, very sad microcontroller. Hmmm...
So it turned out I had entered the micro-USB jack backwards into Eagle...sadly the fix was not as simple as making a reversed cable since D- had been connected to NC on the board, and naturally, NC was not connected in the cable.
After some fiddling around, I gave up and soldered a cable to the bottom of the board.
Next up was putting some firmware on the board. I flashed this demo using Atmel studio, upon which Windows angrily told me that the USB device had failed. Turns out those diodes were necessary.
A couple of 1N4007's later (the next revision of the board clamps D+ and D- with 3.3V zeners), I had a device which properly identified itself as a MIDI device. I felt extremely accomplished until I realized my MIDI device did absolutely nothing. So ended the first day's work.

The next day...
The next step was compiling the source provided in the demo. Sadly this was easier said than done. For starters, Atmel studio threw a bunch of syntax errors trying to compile V-USB in its stock state. Inserting 'const' into the appropriate places remedied that, and produced output that was neither the same size as the original binary, nor functional.
Next up was Eclipse, which didn't throw syntax errors, but produced similarly dysfunctional binaries.
Finally, I gave up and switched to a Makefile and Vim. This still didn't work, until I realized that V-USB depended on having an accurate value defined for F_CPU (which in this case is 16500000). At this point I was able to compile the demo file, flash it, and have the device show up as a MIDI device that did nothing.

Next: implement MIDI handling. Fortunately, USB-MIDI is not as complex as normal MIDI (for one thing, there is no running status). This document describes the packet structure nicely. A dozen lines of code and an ISR later, I had the board buzzing at 400Hz on every note.

From here it was presumably a matter of calculating 220*2^((n-57)/12) for each note received and setting some prescalers, right? Nope, including math.h to get a pow() function caused the microcontroller to run out of memory. The workaround was to precompute 2^((n-57)/12) for n=36, 37,...,47 and then use the fact that f(n+12)=2*f(n) to find the actual frequencies (so this way our LUT is only 12 entries instead of 128 entries long).

Finally I had the thing producing different tones. Unfortunately they were the wrong tones, and even more alarmingly, the interrupter would sometimes cause Windows to crash. The latter was attributed to the blocking nature of my ISR (adding ISR_NOBLOCK fixed it), but the former was trickier to track down.
After finally pulling out the scope (scopes are better test equipment than ears!) I realized all of my on-times were 600uS, which threw off the frequencies of the high notes pretty spectacularly. It turns out that _delay_us() and _delay_ms() only take constant values as arguments, so I switched to _delay_loop_2() and it worked just fine.

The last bits to implement were master volume control (control change 0x07) for power control, limiting the notes played to channel 1, and STOP messages (which are harder to implement than you'd think; there are six ways to stop a MIDI track and it's easy to forget one...). The results are still a bit too unstable to post (I need to work out some host-side issues involving driver installation) but at this point I'm pretty sure I have (what might be the first?) direct-USB interrupter. It's not really good for DRSSTC use (for one thing it's copper out, not fiber out) and is pretty limited in what it can do (no hardware knobs, only one note at a time though this might change tomorrow) but it's dirt cheap (the total cost of hardware is something like $3) and should work acceptably for a small SSTC.

Speaking of which...well, hopefully that project will come together in the next day or two.

Tuesday, August 6, 2013

So I found this camera on eBay...

A thousand FPS of goodness
A Redlake MotionXtra HG-SE, to be precise. This camera does 1280x1024 24-bit color at 500FPS, and doubles in framerate every time the vertical resolution is halved, up to 32000FPS at 1280x16. It records to 1.3GB of internal SDRAM, giving 2 seconds of record time. While this may seem low, 2 seconds of footage at 500FPS translates into nearly a minute at 24FPS, and most fast events don't take all that long to happen anyway.

I'm pretty sure (though not certain) that the camera uses a Photobit PB-MV13 as its image sensor (the same sensor is found in cameras such as the Weisscam HS-1) and was made by AOS. The camera is identical to the AOS VITCam, and in fact, Redlake Imaging Studio is a rebranded version of AOS Imaging Studio.

The first step was to find a reasonable control computer for the camera. Unfortunately, the drivers were never updated for Windows 7, which means the control machine has to be a dedicated Windows XP system. Furthermore, most ExpressCard/PCMCIA Firewire adapters don't have 12V power lines, which means the the camera needed to be tethered to an external adapter as well.
Fortunately, it turns out that Apple was obsessed with Firewire until recent years, so the first generation (2006) Macbooks have full-sized Firewire ports, complete with 12V power. Plus, they were x86 (Core/Core 2 Duo), so they run Windows XP quite nicely.

The trickiest part of using this camera is lighting. At 500FPS, the camera is constrained to shutter speeds of 1/500 or faster. Furthermore, the 2005-era CMOS sensor it uses doesn't have the greatest sensitivity, and there is no option to turn up the sensor gain.
Initial tests with room lighting proved to be a dismal failure. I switched to a 300W halogen bulb, which at least gave usable results:

Sadly, the sensor really wants high color-temperature (bluer) lighting, so there was no way to make the image look decent with a halogen.
Fortunately, the home hydroponics market has spawned a bunch of semi-legit electronic metal halide ballasts. These are functionally equivalent to what the film industry calls "HMI" lights, and are good for around 25000 lumens at a color temperature of 5000K.
In addition, the camera is natively a C-mount camera. Unfortunately, most C-mount lenses don't go above 16mm format, which means the edges of the image degrade in quality. The solution to this is to use SLR lenses and an adapter; I'm a Nikon guy, so I chose F-mount as my mount of choice. Nikon F also happens to have the most lenses out of any mount (since the mount has not changed since the early 60's!)
Because the camera uses a sensor with a diagonal of 20mm, and not a full-frame 35mm sensor, the crop factor is approximately 2. This means that a 50mm normal lens behaves like a 100mm telephoto, and a 24mm wide-angle behaves like a normal lens.
Putting the metal halide lighting, a 50mm f/1.8 Nikkor lens, and some Jello together gave the following video:

If you look closely at the video, you'll notice numerous color and motion artifacts. These are not actual camera artifacts, but rather a consequence of the shitty early-90's AVI codec Imaging Studio uses. The solution was to export the frames as uncompressed BMP's first, then use FFMPEG to convert the sequence of BMP's into a high-quality video.
At this point, I also discovered that by default, Imaging Studio does not apply gamma correction, leading to some washed-out looking images. Applying a gamma of 1.5 and turning up the contrast resulted in much prettier, contrastier videos:

This past weekend, we (oneTesla) was at MuseCon in Chicago. One of the featured shows was Masters of Lightning (Terry Blake and Jeff Larson, with a pair of 12KW DRSSTC's). The sparks from the big coils were just bright enough to show up decently on the camera.


1000FPS (quick 'n dirty export with pretty bad artifacting):

Jeff also brought his wire exploder, so we filmed that as well. Both videos at 1000FPS.

The exploding wire produces some interesting stills: