I brought my old hard disk laser projector to work today, since it was the most interesting portable project I had to show off to some friends and new acquaintances at a geek get-together. Scott being himself, he naturally always has a fantastic camera with him. So we got some better pictures of its output:
This is another mini-project that began, like so many have, in a discussion with Scott over some beer. We wanted to build a new kind of speaker amplifier, which used mechanical closed-loop feedback to position the speaker cone exactly where the audio signal says it should be. We figured that, if done right, this could yield higher audio quality from cheaper speakers.
So, that idea is pretty crazy, but it seemed just barely plausible enough that I had been thinking about the component parts of such an amplifier. The most important seemed to be a sensor that could accurately supply feedback on the speaker cone position without loading the speaker or distorting the cone. The first method we considered was a capacitive pickup. Paint the back of the speaker cone with conductive paint, then position two copper plates behind the cone, just barely not touching when the speaker is at its maximum throw. This acts like two capacitors in series, and gives you a capacitance that varies along with the audio frequency, without any mechanical connection to the speaker cone.
We also considered magnetic feedback, using something like an LVDT, but where one coil is the voice coil itself. This would involve modulating some kind of high-frequency carrier into the speaker drive signal, then placing another fixed coil around or behind the voice coil to pick up that signal.
The next method, and I guess the simplest, is optical. This would work a lot like a fiber optic microphone or an optical guitar pickup. You can measure vibration by detecting changes in light intensity caused by changes in distance or angle of some reflective thing that’s vibrating.
Whereas the capacitive and LVDT ideas require a high-frequency modulated signal, that’s optional with the optical method. You can measure absolute intensity, or you can modulate your LED with a high-frequency carrier that can be detected on the receiving end. This modulation can help reject ambient light (including hum from fluorescent lights) but it isn’t required.
So, to see if this project has even a tiny chance of working, I thought I’d prototype the optical sensor by building an optical microphone. The end results were rather mediocre. I’m posting it here only because:
This is a really simple back-of-the-envelope sort of transimpedance amplifier, high-pass filter, and gain stage. Disclaimer: I hate doing math for analog circuits when it’s just a quick hobby project, so I did no math in designing this. Take it with a few shakes of salt. My breadboard was humming pretty badly due to incoming EMI, so I built it dead-bug style in a mini Altoids tin. If you build this, definitely use a suitable amount of shielding.
The first successful test I had of this pickup was with a rubber band. I’d like to try this with a guitar string, but I don’t play
It’s actually pretty forgiving about the positioning of the pickup relative to the rubber band, and it’s very sensitive even when the rubber band is a few inches away. This circuit can pick up very low-frequency vibrations well, so you hear very deep bass notes that you don’t normally notice in a rubber band pluck.
This is the application I originally hoped the optical microphone would work for: picking up sound off the front or back surface of a loudspeaker cone. If I could do this really well, the closed-loop amplifier might have a chance. The results certainly weren’t hi-fi, but I guess I was still surprised it worked at all.
Unlike the rubber band, this test was extremely finicky. I had to position the pickup just right, and I used some Kapton tape to make the surface of the speaker more reflective to IR light. I also had trouble getting a good reflection off the curved surface of the cone, so I stretched a flat section of tape between the center dome and the middle of the cone. This gave good signal strength, but the tape itself also acted as a mechanical filter, giving kind of an odd frequency response to the whole system.
Hopefully this will allow me to have some closure on a completely mediocre mini-project that was nonetheless interesting enough that I couldn’t just forget about it without sharing. If anyone reading is a real electrical engineer, I’d be interested in hearing about what I did wrong.
People all around the internet have been doing cool things with the Wii peripherals lately, including the Wii Fit balance board. Things like controlling robots or playing World of Warcraft.
But what if you just want one weight sensor, not four? The balance board starts to look kind of pricey, and who wants to deal with Bluetooth if you don’t have to?
I’ve had a couple ideas for problems that could be solved by a cheap interface to the weight sensor in a common digital bathroom scale. The kind you can get for $15 or so at the local big-box store. For example, I’ve pondered using a grid of bathroom scales as an input device. You could use it to emulate a DDR pad, and there might be new applications that could benefit from analog weight readouts on each square of the pad.
The other idea is really Scott’s doing. He has a kegerator, and naturally we’ve been plotting to fill it full of all manner of sensors, actuators, and RFID readers. We’d like to have a continuous measurement of the keg’s weight, both to have some advance warning that it’s getting low, and to detect when an individual glass of beer has been dispensed. It seemed like if we could use the sensor from a digital bathroom scale, the filtered output would probably be accurate enough to detect the difference in weight from just one beer.
I’ve seen other projects to hack a digital scale. For example, this SD Card Bathroom Scale project uses a microcontroller to ‘read’ the LCD by decoding the signals used to drive it. This was a great idea, and he pulled it off quite well. But it requires a lot of wiring, and you’re still limited to the resolution and functionality of the original scale. I wanted to see if there was a simpler and lower-level way to hack a typical bathroom scale. And, for my particular scale at least, there is.
Old-skool analog scales (you know, with the needle that moved) were based on some clever gears and levers that converted pressure on the scale into compression of a big spring, then the spring’s compression into rotational motion that could drive a dial. But digital scales don’t really have any moving parts. They are mechanically designed to distribute your weight evenly to a bar or collection of bars which bend very very slightly under the pressure. Those bars are bonded to an electrical element that also flexes very very slightly, changing its electrical resistance. This is a strain gauge.
Inside the scale I hacked, you can see the two load-bearing bars. Each bar has two strain gauge sensors bonded to it. Measuring the difference in strain between the two sensors can tell you how much the bar is flexing.
There are a lot of notable parts here:
And on the main PCB:
This is the only scale I’ve disassembled, so your mileage may vary. If your scale puts everything on a single IC, there may not be a way to hack it without building your own analog front-end. But if you get lucky (older scales may be more likely to use discrete parts) you may see something like this in the scale you disassemble. The separation of functionality into discrete analog and digital circuits makes this model of scale quite fun and easy to hack!
This section will explain the process I used to figure out how this scale works. You might be able to use some of the same procedures on other types of digital scales.
This documents my understanding of how the analog front-end works in this digital scale. I didn’t reverse engineer the circuit itself, so this is really just a “black box” description based on observing how the circuit behaves.
The circuit’s input is a tiny resistance from four strain gauges. They are arranged as two independent load cells, each with two sensors that act as a differential pair. The front-end amplifies these tiny differences in resistance, and sums them into a single analog signal. For example, if the strain gauges were labeled L1, L2, R1, and R2 (two sensors each for left and right load cells), the analog summation would be:
Total = L1 – L2 + R1 – R2
This total is still an analog signal, and it’s fairly noisy. There would be a lot of different ways to convert this to a digital signal: a standard successive-approximation A/D converter, a voltage to frequency converter, an RC oscillator… This scale uses an approach that’s simple, cheap, and pretty accurate for situations where you’d like to dynamically make tradeoffs between sample rate and accuracy. It uses an integrator and comparator.
In this approach, there is a capacitor which can charge or discharge depending on the state of a signal from the microcontroller. I’ve been calling this the “Reset” signal. When Reset is low, the capacitor slowly charges at a rate which depends on the analog Total above. This is an analog integrator. When Reset is high, the capacitor discharges quickly. This voltage across the capacitor is fed to a comparator, where it’s compared to a reference threshold. If it’s larger than this threshold, you get a logic “1″ out, if it’s smaller you get a logic “0″.
This starts to look a lot like a closed-loop feedback system. In fact, you can even think of it as an electronic equivalent to the old mechanical balance. Instead of balancing two physical weights on a lever, you’re balancing two electric currents which are trying to charge or discharge the integration capacitor. If the capacitor voltage is too high, you need to drain it a bit. If it’s too low, you need to let if fill up. If you keep the capacitor voltage oscillating right around the comparator threshold, it’s just like you’ve balanced a mechanical scale. Now you know how heavy the object you’re weighing is, because you know how much time you need to spend discharging the capacitor to keep it balanced.
I find this symmetry between the mechanical and electrical scale pretty elegant. It’s also practical- your accuracy is limited by electrical or mechanical noise in the circuit, and by your microcontroller’s timing resolution. But you can always integrate over longer periods of time in order to trade sample rate for accuracy. If you keep the capacitor balanced for a whole second, and add up how much time you spent discharging the capacitor over that second, you’ve just calculated the average weight with much more precision than you’d have if you measured the length of a single discharge pulse.
After figuring out the analog front-end, I really just wanted a way to use that by itself without worrying about the built-in microcontroller or LCD. This turned out to be really easy:
The wires on the left are power and ground. It’s hard to see here, but the traces corresponding to the three wires on the right were cut, between the wires and the chip-on-board assembly. From top to bottom, those wires are comparator, button, and reset. And that’s it! With that simple mod, the scale is ready to connect directly to any 3.3v microcontroller with two free I/O pins. I used a Propeller, but an AVR should work great for this too. If you’re using a 5V microcontroller, you’ll still want a 3v or 3.3v power supply for the scale. You may also want to limit the voltage on the reset output signal too, though I suspect this isn’t actually necessary.
I tested this mod using a PropRPM board and some jumper wires. All of the other stuff on the PropRPM board is unrelated to this project- no external components are necessary to talk to the scale, just two 3.3v I/O pins.
The software is pretty simple. To measure weight, you need to toggle the “Reset” output on and off in order to keep the integration capacitor balanced around a comparator threshold. Pulling Reset high will quickly drain the capacitor, pulling it low lets the capacitor charge at a rate which depends on the total weight on the scale. You can take more accurate measurements by repeating this for more cycles, or take quicker measurements by repeating it for fewer cycles. On the Propeller, I use the system clock to measure the total amount of time that I spend letting the capacitor charge. Here’s a complete program that prints scale measurements to the serial port:
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
PIN_SCALE_OUTPUT = 3 ' Pulse high to discharge
PIN_SCALE_INPUT = 4 ' Output from integrator
OBJ
term : "Parallax Serial Terminal"
PUB main
term.start(115200)
repeat
term.Str(String(term#NL))
term.Dec(measure_raw(500))
PRI measure_raw(period) : raw_weight | timeref
raw_weight := 0
repeat period
' Reset, and wait for input to go high. This is its idle state.
OUTA[PIN_SCALE_OUTPUT]~
DIRA[PIN_SCALE_OUTPUT]~~
waitpne(0, constant(|< PIN_SCALE_INPUT), INA)
' Turn off the 'reset' output. This starts integrating
' the pressure. When the analog integrator reaches a threshold,
' our input pin goes high. Time this.
timeref := cnt
OUTA[PIN_SCALE_OUTPUT]~~
waitpeq(0, constant(|< PIN_SCALE_INPUT), INA)
raw_weight += cnt - timeref
And that’s all it takes! I’m looking forward to trying this with a larger grid of scales. A powerful microcontroller like the Propeller should be able to simultaneously sample and filter measurements from several scales. This proof-of-concept looks pretty promising for the kegerator project, too. With an integration time of a second or so, it can easily measure weight accurately enough to count glasses of beer
P.S. I’m pretty sure I just spent more time writing this blog entry than I spent on the hack itself. How silly is that?
The story behind this project is a bit overcomplicated. That’s all below, if you’re interested. I made a video to explain the final product:
This all started when I bought a sewing machine for making fabric RFID tags a little over a year ago, and started using it to make cute plushy objects. Well, as much as I like making plushy objects, I haven’t actually made very many of them since buying the machine. So, my boyfriend has been guilting me into making him a few as gifts for Christmas, birthday, valentine’s day. Naturally, being the great partner I am, this gets me thinking about ways to soup up my sewing machine first
The original machine did bug me in many ways when working on fine detail work. I’m lazy and uncoordinated with a needle, so I tend to sew almost everything by machine, even when the individual stitches all have to be lined up just right. In fact, when sewing the face parts on my meat and crab plushies, I found myself sewing individual stitches by turning the flywheel by hand.
I don’t know whether more expensive sewing machines are any better, but on my cheap Singer Inspiration 4210 the stock motor is nearly unusable at slow speeds. It stalls easily, makes an awful buzzing noise, maintains an uneven speed, and delivers very little torque.
My first experiments were to instrument the sewing machine with sensors that I could use to estimate the speed and angle of the main shaft. I needed some kind of absolute angle reference, plus some way of counting how far the shaft has traveled. For the angle reference, I found a really handy place to mount a photo-interrupter sensor. This cam is part of the mechanism that advances the machine’s feed dogs. It conveniently moves this metal bar back and forth once per revolution of the shaft.
For sensing the shaft speed accurately, my preferred solution would have been a high-resolution encoder wheel attached to the motor or the main shaft. But that would, at the very least, involve making a rotary encoder disc and attaching it somehow to one of the sewing machine’s moving parts. I wanted to avoid messing with the machine’s moving parts as much as possible, so I looked for non-contact solutions. I noticed that, with a little signal conditioning, an IR reflection sensor works pretty well for counting teeth on the machine’s drive belt. After switching motors, I modified this to sense teeth on the motor’s sprocket instead, but the same signal conditioning circuit works in either case. The signal conditioner is an dual op-amp configured as an amplifier, bandpass filter, and comparator with hysteresis.
Lastly, there’s the most important sensor: the foot pedal! I wanted to keep the original foot pedal feel, but use it as a generic input device for the microcontroller. So, I removed all electronic parts other than the variable resistor itself, and connected that to a 1/8″ jack. With a little modification, the jack fit into the same hole that was originally used for the mains cord.
This is where the project got a bit out of hand and I started making wrong turns. At first, I was hoping it would be possible to implement smooth closed-loop control by using the original motor and a simple triac-based speed controller for the motor. This seemed straightforward enough. But I didn’t have all of the parts on hand to do a normal optotriac + triac based driver circuit. So I went shopping at HSC. No optotriac, but there were some solid state relays. Alas, after I got them home and looked up the data sheets, it turns out they are the zero-crossing switching variety. Useless for speed control. So, back to the drawing board. No optotriacs on hand. Well, I could move the opto-isolation, putting the microcontroller on a line-powered circuit, and opto-isolating the serial port instead. But that sounded really annoying to debug safely, especially for me without an isolation transformer or variac. But that would require a low-voltage power supply on the mains side of the optoisolator anyway, and if I had to go to that trouble I might as well just use a transistor to switch on the triac…
So I started rummaging through my junk bins again, and I found an old X10 lamp module. This must have a triac in it, I thought. It won’t have an optoisolator, since X10’s cheap circuits never bother with mains isolation. But it might have a power supply and zero-crossing circuit I could use. So I find a handy LM465 schematic online, and I start paring down the circuit into just a bare-bones triac driver, zero crossing detector, and +15V power supply. I got pretty far along on this triac-based speed controller before I switched tactics:
I was experimenting with closed-loop servo control using this triac controller, but the results were pretty uninspiring. With a triac, you can only change speeds as fast as twice your AC power frequency. And a 120 Hz control loop just isn’t tight enough to keep the sewing machine operating smoothly at low speeds. The motor’s lousy torque at these speeds certainly doesn’t help.
I also had lots of trouble with EMI in this design. With all the parts strewn about my desk and electrically isolated but not RF shielded, my microcontroller would randomly reset after the motor ran for a few seconds or so. I first saw this with my trusty Propeller. I tried switching to an AVR Butterfly, half to try and avoid the EMI, half to have its LCD and joystick as a user interface. But, no luck.
I was curious how they solve this problem in industry. Servo motors are pretty common in industrial automation, and surely you must need a fancier way to control the speed of a large motor in order to build a heavy-duty servo. Well, it seems that there are two solutions:
VFD seems quite cool, and I was really close to attempting to build a simple VFD controller using parts from a dead UPS. But then my better senses caught up with me…
So, I was about to settle for this mediocrity and finish off my triac-based controller with some buttons and mounting hardware from HSC, when I randomly happened upon the perfect DC motor. I didn’t know it was perfect at the time, but I had a hunch. As soon as I got it home and sat it next to the original motor, I knew.
I was pretty lucky. The speed range was good, the sprocket had the same pitch, and it had plenty of torque at low speeds. The only problem: It’s just barely too large to fit inside the sewing machine cabinet. So, I had to improvise the mounting a bit. I ended up slicing off the bottom panel of the sewing machine, bolting its frame to some scrap pressboard, and mounting the motor using a hacky arrangement of pressboard scraps, screws, and zip ties.
I started out building a simple MOSFET speed controller for the motor, since I’d never used a MOSFET to control an inductive load before. But after spending an hour or two trying to squash transients and convince my FETs to switch at a high enough frequency, I figured I’d had enough pain for one week. I had a spare LMD18200 chip with this project’s name on it.
The LMD18200 is an amazingly versatile and robust little chip. I used it for my laser projector project a while back. It was really overkill for that, but it’s about right for this sewing machine’s beefy new motor. I needed a pretty heavy duty motor drive capacitor too, so I ended up mounting the LMD18200, capacitor, and DC-DC converter in a small metal box for safety reasons. If the capacitor fails, I’d prefer not to have burning hot electrolyte and shrapnel all over my face.
Enough rambling for now. And I guess I should stop hacking my sewing machine, and start sewing cute things
I did leave plenty of room in this build for later expansion. I’d like to add some kind of user interface for switching sewing modes. Right now I’m using the USB port for that, but a little LCD with a rotary encoder knob would be just swell. I’ve also thought of other ways to automate the sewing machine to make common tasks easier. For example, it would be useful to have a mode that automatically lifts the presser foot between stitches in single-stitch mode. I already found a good place to mount an RC servo motor for that.
And then there’s the idea of building a CNC embroidery machine around this, using Lego Mindstorms to make the cartesian robot…
As much as I like the long, complicated projects that involve weeks of soldering, gluing, coding, tweaking, re-tweaking and debugging, it’s really refreshing to occasionally do something cool with no more than an hour or two of work.
This mini-project was my boyfriend’s idea. It’s an experiment in cooperative two-player Gitaroo Man, played using a gamepad for attack/charge and DDR pad for defense.
For those who aren’t familiar with it, Gitaroo Man is a rhythm game where you do battle using music. You play music on your gitaroo to attack or to charge your health bar. To defend against the enemy’s attacks, you dodge by pressing buttons in time with icons that fly toward the center of the screen. We thought the dodging phase of the game might map well to a DDR pad.
Videos first, tech details below. My boyfriend is on the gamepad, and one of my friends defends with the DDR pad. Theoretically you can play this with one person, but we suck too much at the moment. When we filmed this, we hadn’t played Gitaroo Man in years.. so we definitely could have done better with some more practice
This turned out to be such a quick project because it was really just some special-purpose firmware for my old Unicone2 controller emulator project. The firmware combines inputs from the gamepad and DDR pad, maps the DDR arrows to the buttons used for blocking in Gitaroo Man, and it includes a one-shot timer which converts sustained pressure on a dance pad arrow into a brief tap of the corresponding controller button. This way, standing still on the DDR pad won’t affect your ability to use the controller buttons normally during the attack phase.
Overview of all hardware and software components:
The Unicone2 hardware:
Links:
The Virtual USB Analyzer is a graphical tool for analyzing USB sniffer logs. It can do some basic protocol decoding, and it has a graphical timeline view which helps to visualize the latency and concurrency characteristics of USB traffic.
This release only adds a single feature, but it’s one that many people have probably been waiting for: support for Linux’s built-in usbmon sniffer tool.
With usbmon, tracing all USB traffic on your system is as simple as cat’ing text from a sysfs node to a file. It doesn’t have quite as many features as VMware’s low-level capture logs, but for most users (especially users debugging Linux USB drivers) this should be more than sufficient.
If you aren’t familiar with usbmon, the first thing to read is Documentation/usb/usbmon.txt from your kernel sources. That will tell you the basics, including how to capture raw data from the kernel. There are a few other simple front-ends for making this data more human-readable. If you’re using vusb-analyzer, those tools aren’t required. Just save the raw data to a file with a .mon extension, and hand that to vusb-analyzer.
This feature was a patch contributed by Christoph Zimmermann. Without his contribution, I no doubt would have procrastinated this release for many more years
I guess I don’t have a complete blog entry to write on any one thing.. but there are several unrelated things that I feel like writing down. I recently joined Twitter, but I must suck at using it because none of these things ended up there.
Tragic. Introspective. Complicated. This isn’t really a place where I would feel it appropriate to go into detail, but it would be unjust to omit given that the other things here are significantly less important.
I don’t have a huge amount of flying time on it yet, but I’ve been enjoying the Blade mSR so far. I’ve been flying it mostly in smallish spaces, so I haven’t had the guts to really see how maneuverable it is- but I’m impressed with its stability and responsiveness so far. Also, either I’m a totally awesome pilot, or (more likely) it’s actually pretty easy to fly.
I haven’t had much time to work on the DSi lately. I’ve let Bushing borrow my hardware, and he’s been working on producing a small quantity of additional RAM tracing/injecting setups. This isn’t the kind of thing we can make many of (I estimate it takes about 6 hours to solder one together) but it’d be helpful for the community if more than one of these rigs existed in the world.
What time I have spent on DSi-related stuff has been on Temporal Hex Dump. It’s actually coming along okay- I took a bit of a development detour to improve it’s Mac OS support after I bought a MacBook Pro… but the next step is to add the part of it that is actually a hex dump. So far, it has the timeline navigation widget and a correlated list of memory transactions:
So, way back in April, I posted the first screenshots of Robot Odyssey on the Nintendo DS. This was I guess what I’d call a “binary port”. It runs the original Robot Odyssey binaries, via static binary translation, and with many modifications and UI enhancements to adapt the game for the DS console.
I never got around to posting pictures, but I actually did make significantly more progress on this project before getting distracted. I ended up implementing a pretty sophisticated system for patching the game and dynamically manipulating its world state, as well as “forking” additional copies of the running game very quickly for the purposes of having those forked-off copies render additional sprites. What is this good for? Well, I could have the game proper running on the DS’s top screen, while the bottom screen shows status icons for each robot, where the icons accurately depict the state of the robot’s bumpers and thrusters, and even what item the robot is holding at the time. I also had a mostly complete game load/save UI implemented, including a live preview that shows you where you saved while picking a game to load. My next step was going to be a UI for editing circuits inside your robots using the stylus.
Anyway, I know I’m being cruel by describing all these great features and not posting a video or a ROM image. Sorry. I promise I’ll make a video one of these days when I have a bit more time. As for a ROM image, right now the best I have is the source code for a tool which will generate a ROM given the original Robot Odyssey files. You can get the source with:
svn co http://svn.navi.cx/misc/trunk/robot-odyssey-ds
To compile it, you’ll need devkitARM and Python. You’ll also need to put your original Robot Odyssey files (the DOS version, not Apple!) in the “original” directory in the source tree. You can leave them in a zip file, or strewn about the directory in random places. The translator knows what files it needs, and it will find them by SHA-1 hash.
I give no guarantees as to the current state of the source tree- I haven’t worked on it in a few months, and I think I last left it in a state where loading and saving were partially but not usably done. If you aren’t a developer, the source tree isn’t likely to be useful to you yet.
Homework assignment: If anyone in the audience wants to see this Robot Odyssey DS port turn into a real homebrew ROM image that anyone can download without compiling it themselves, we need to have redistribution approval from the game’s current copyright holders. Problem is, I have no idea who that is. I did email Warren Robinett about this project a while back, but he couldn’t tell me who currently owned the copyright. Following the trail of acquisitions, I think it might be owned by Houghton Mifflin Harcourt. Yeah, the textbook company. I did email them about the Robot Odyssey copyright multiple times, but I never got a reply. So, what now?
One approach is always to release it then look for the return address on the cease & desist letter. But, in all seriousness, I would like to be able to release a legal port of a classic game which the current copyright holder clearly has no commercial interest in. It seems like there should be some way to do this.
I was hoping to dust off my Blade CX2 this afternoon and get some flying in. It’s been many months since I’ve flown, and that’s really a shame.
So I take my two 800 mA 2S packs out of the liposack in the garage, and they’re both pretty swollen. One of them is still at nearly full charge (about 3.5 volts per cell), the other has one cell at 0V and one at 2.5V. Looks like no flying today… and best of all, now I get to figure out how to dispose of these things.
This really seems like something that should be on Wikipedia, or at least Snopes. The lazywebs give me all sorts of conflicting information: some people claim you should discharge the cells with a resistor or light bulb then throw them in the trash, some people say you absolutely must not discharge damaged cells, and to put them in salt water instead.. but then it seems that the salt water is more of an urban legend, and really just turns out to be a rather ineffective way to discharge the cells. The salt water won’t get into the cells themselves unless you puncture the casing (which seems like a really bad idea) and it just eats away the battery’s terminals, making them impossible to discharge properly.
For now I’m following the approach that makes the most sense to me: put the cells outdoors in a fire-resistant bag, and discharge them to zero with a 100 ohm resistor across each cell. Supposedly they’ll be inert at zero volts, and I can take them to the recycling center or throw them in a dumpster or something.
Is there an obvious resource on Lipo disposal that Google is just failing to find? This really seems like a great example of the internet at its least helpful- dozens of “authoritative” answers out there, all different.
Anyway, I guess my CX2 is still out of commission for a little while. I just ordered some replacement batteries, and that seemed like as good an excuse as any to also buy a Blade mSR. One of my coworkers has been raving about his, and it seems like a good second heli to learn
Back when I bought my last Mac: USB and the Playstation 2 were new, Altivec and shiny plastic were in, and fans were almost starting to line up for the first Harry Potter movie. Oh, and warrantless wiretapping was still illegal. So, Apple, I guess it’s time to put all those hardware failures behind us and see if this relationship can work.
I’ve actually had a lot of fun hacking on Mac OS at work while developing VMware Fusion. Working on such a low-level software project, you see a lot of the ugliest parts of any OS. And there’s certainly a lot inside Mac OS that scares me. But there’s also a lot of cool technology in there. And best of all, I don’t have to futz with my ALSA settings for an hour if I want to watch a YouTube video. Win!
I’d been thinking about upgrading my aging Thinkpad to a 15″ MacBook Pro when it finally kicks the bucket. But darnit, those things are too reliable. So I needed a different excuse. I think it finally boiled down to:
It arrived this morning, and indeed it is quite shiny. I really do like the new Unibody design- and the large trackpad surface with pseudo-button is actually quite a lot nicer than the standard touchpad on my Thinkpad. (I’ll see how long I can resist the urge to do some low-level poking around in the touchpad, to see how its multi-touch protocol works…)
I think I’m a bad Mac user though. Just about the first two things I did were to install the Ubuntu 9.10 RC, and Windows 7. Then I had to continue my tradition and render a new background image:
This is using Fyre’s cluster rendering support. The GUI and one rendering node are running in a 2-VCPU 64-bit virtual machine on my MacBook Pro. I have two more nodes running on a desktop Athlon64 machine running Linux natively. The total speeds here are pretty impressive- comparable to what David was able to get from running cluster nodes on every machine in one of the CS labs back in college. Isn’t Moore’s Law great? (And I’m sure the 6MB L2 cache helps )
I work on the graphics virtualization team at VMware. The company is about to release two new desktop virtualization products: Fusion 3.0 is in beta, with a release coming tomorrow. Workstation 7.0 has a public release candidate available.
There are a lot of exciting features in these releases, and my team has been working really hard on making the graphics virtualization in these releases the best we can. Our focus with these releases has been introducing a few large architectural changes in our graphics stack:
This is a complete rewrite, sharing no code with our Windows 2000/XP driver. This has been a monumental undertaking for the team, but the results have been pretty shiny. The architecture is clean and extensible, it’s much easier to understand and debug the driver’s performance, and it gives us a good platform to build on for future guest driver releases. Oh, and it can run 3D games with Aero enabled.
Yes, this release has not one but two brand new drivers in it! The new OpenGL driver is based on Gallium, and it finally brings both major graphics APIs into VMware virtual machines. Both of our new drivers really deserve a blog post all to themselves.
Whereas previous releases of VMware’s products have implemented multi-monitor support and Unity mode on top of an architecture that was fundamentally designed for a single framebuffer, Fusion’s entire graphics stack has been overhauled in order to natively handle multiple screens, windows, and framebuffers. This architecture is common to all of our products, but so far only Fusion 3.0 has had its entire stack updated. Workstation and ESX still use a blend of new and legacy components.
As an end-user, the effects of our Better Unity and Multi-mon project are relatively subtle. Unity mode now renders much more efficiently, and applications like games and media players will run just as fast in Unity mode as they will in single window or fullscreen mode. Window resizing is smoother. We also have a high-quality GPU accelerated scaler which you can see in action on your VM’s live thumbnails in the VM Library window.
Back in April, I announced the VMware SVGA Device Developer Kit. This is an Open Source (MIT-style license) project which documents the virtual hardware interface that our graphics stack uses, and provides a simple reference driver and some examples. If you’re interested in operating system development, graphics, or virtualization, it can be a handy platform to experiment with, and it’s the best starting point if you’re trying to write a VMware graphics driver for a new operating system.
I’ve been trying to maintain the DDK with an open development process. Instead of periodically dumping code, all development takes place directly in the open repository. The one exception to this policy is for code which doesn’t work on released VMware products, either due to serious bugs or unreleased features.
As part of our architectural improvements for Fusion 3 and Workstation 7, we added a pretty big new feature to the SVGA device: “Screen Object”. Without Screen Object, the device has a single framebuffer with a geometry controlled by a set of registers. Multi-monitor support was faked by using an additional set of registers to carve up a single large rectangular framebuffer into individual monitors. With Screen Object, the guest can create “screens” dynamically, and they don’t necessarily need to be backed by any specific kind of memory.
A Screen is really an opaque non-guest-addressable memory object, just like an SVGA3D surface. If a Surface is analogous to a texture or a backbuffer, a Screen is analogous to a frontbuffer. You can blit between system memory and a Screen, and you can blit from Surface to Screen.
This is a simple concept, but it’s a powerful tool that can be used to implement a variety of different memory management and asynchronous rendering strategies. Last week I checked in a pretty big update to the DDK which includes refdriver support for Screen Objects, and 10 new Screen Object-only examples.
To run the examples, you’ll need Fusion 3 or Workstation 7. You’ll also need to manually enable Screen Object. Like many new features, we haven’t enabled Screen Object by default right away. It is enabled automatically for Vista, Windows Server 2008, Windows 7, and Mac OS X guests, since our drivers on those platforms may take advantage of the new features. For improved portability, it is disabled by default on other guest OS types. You can enable it manually by adding a line to your VMX file:
svga.enableScreenObject = TRUE
As always, the DDK is provided as-is, with no official support from VMware. So please don’t bug our support folks 
But I’ll try to answer questions as time permits if you send them to micah at vmware.com. Thanks!