I just got a priority project dumped on me. I'm trying to figure out if I can build a better stage edge light.
The client goal was to break the existing price point and deliver something cheaper. Unfortunately, that price point is $11 and I'm not sure I can get significantly cheaper.
The one thing I can do is provide a lot better performance at that price point.
The existing commercial product is dead-simple; a 9v battery clip modified to hold a naked 4ma LED. Very simple, small, easy to maintain...but that's the best of it. Undirected and extremely lossy, as 9v "transistor" batteries are much more expensive than AA cells, and since LED forward voltage is under 3v, most of that extra voltage is being wasted as heat in the regulator.
So it is obvious to design around AA/AAA, especially as those already exist in profusion in the theater world, and are better-established in the rechargeable options as well (why I opted for 3xAAA as the standard for my DuckLight).
The LED is a little more of a question. 20ma is easily available in that size, but what is the actual desired intensity? After trying several different estimation models, including illumination, visual astronomy, and f-stop estimation, I've zeroed in to assuming the LED will be behind a diffusor that in turn is tucked into a hood (or otherwise is blocked from direct audience view.
Using a whole bunch of loose assumptions, such as calling typical lux at the front edge of the stage 400-600, calling the albedo of dance marly .1 and ignoring the anisotropic shading model (which will come back to bite me, I know) I end up with a desired lux of around 100 before the self-illuminated surface can be clearly discerned from the background illumination.
So the smaller the surface, the better, right? Well, now we switch to the angular resolution of the human eye, which works out to about half a centimeter from the back of the stage. Except that resolution is actually all over the map when comparing relative magnitudes -- we can see stars, after all, and we don't have the optical power to resolve those.
Still, the numbers are converging around a 1cm^2 diffusor driven by 5-20ma as being "probably" visible from on stage. Omitting glare, of course. Plus the actor or dancer is facing right at sources (the face light) that are several magnitudes greater, and the instantaneous magnitude range of the human eye is only 3-4 f-stops.
This is going to have to be calculated when I work on making a light that can be seen against the glare of the shin-busters to allow a dancer to run off stage. (Well, since they normally navigate by the shin-busters, the real calculation is how much their eye will dark-adapt during the brief moments of a black-out as they race towards a red blinking safety light in the wings).
Unfortunately the battery numbers are not coming out where I'd like them. The competition boasts 125 hours (my calculation confirms this is possible for their setup) and that won't last the week. Running full-out with 20ma, even with the much greater capacity of "penlight" cells I can't stretch to the length of a run.
So the optimal design appears to be 2xAA, which has a slightly larger profile than 2xAAA but will last for ten days. That means the user places fresh cells in during prep for the weekend's performances, and leaves them on over the weekend. That is the best option for mechanical simplicity, cost, and limiting the failure modes (both mechanical and human error).
(I may still go for AAA, which gives a theoretical life at max output of four days. The 4x battery performance I'm getting out of penlight batteries is balanced by the 4x output power I'm aiming for in the design).
For simplicity, the diffusion may be simple cavity reflection; the "hood" is also the diffusor. Which does bring to question, however, if I want to design a tilting head so the same unit could be used for side lights. Actually, though...there's no reason it has to be designed with the light output axial with the batteries. It could be orthogonal to their long axis. This isn't a flashlight, after all!
My best guess at this point is a laser-cut acrylic "housing." The quotes are there because I don't need to close off the battery compartment. I just need to keep the batteries in place. So an open framework with a flat bottom makes the most sense (the flat bottom designed for double-stick tape, screws, or magnets to fasten it in place...provide pockets for supermagnets in the design.)
To get a true picture of the cost, then, I have to upload files to Ponoko. Even if I do intend to laser them myself at TechShop, I am entering into this on a non-profit, open-hardware basis.
Now what I really need is a name (so I can refer to it in project notes and folder names more efficiently). "mouseLight" works for me. Especially since I am working out the details for this over a production of "Nutcracker."
Wednesday, December 17, 2014
Monday, December 15, 2014
Flash! Aaaaah....!
Between shifts over the run of Nutcracker I've been getting a lot of work done on my RGB light. Finally tracked down a constant-current driver that seems nearly perfect; the AMC7135.
Back up a hair. LEDs are current devices. Once forward voltage is achieved, current flow will increase near-logarithmically over only small increases in voltage; a runaway process leading to overheating and breakdown. Thus current limiters are needed.
The most basic is a series resistor. Basically, the resistor is chosen so that the current across it (calculated assuming the voltage drop across the LED is constant), is the same as that desired for the LED. Pick the right resistor, the loop current remains under the limit. The problems are two; all the voltage above the necessary forward voltage of the LED is transformed to heat in the resistor, and, the resistor is only of the correct value when the voltage is stable.
The better regulation is essentially a transistor that uses the current flow in a feedback loop, thus holding the current at a desired point. With the right components, these circuits will compensate for a range of voltages and, as well, react thermally in the correct direction to compensate for the changing behavior of LED and circuit as it warms up.
However, the typical packages I was finding were a couple bucks each and required up to a dozen external discrete components; capacitors, resistors, signal diodes, zener diodes, even inductors. Which was a lot of parts to be adding to a small board especially when I wanted to control three channels or more of LED.
But the AMC7135 is the ticket. Unlike many current limiters, it is preset internally to 350ma. It requires essentially no external components. And it may be a usage that's out of spec, but it can be successfully PWM'd. There are in fact high-end flashlights that use this exact circuit.
Again to step back; LEDs require a minimum voltage, and when this voltage is achieved will consume as much current as you let them. This makes them poor candidates for resistance dimming. The best way to control their intensity is to turn them on and off quite rapidly. By varying the ratio of time on to time off, you achieve a nice control of intensity.
Do this to red, green, and blue LEDs and you can achieve a decent range of colors as well.
Which is what I've been trying to do for over a year; to create an extremely cheap, small, high-power colored light that can be used inside props, on costumes, and in other theatrical applications. There are a lot of commercial packages that are similar, but few offer two of the things I find important for this application; tight control, and battery power.
Control turns out to be the sticky issue. What I really don't want is all those cheap LED toys; things you have to hold down a button and scroll through different colors to get to the one you want. This is non-optimal for theatrical use. It should be able to be set so when the actor (or the light board operator) hits a switch it lights up the right way the first time.
Proof-of-concept; ATtiny controlling two channels of a 3W LED via darlington transistors, on a 4xAAA battery pack. When you hold down the button it does a candle flicker.
There are also commercial products that allow you to dial up a preset -- from infrared controllers to full DMX-512 wireless solutions to the pretty-durn-close BlinkM. Where all but the BlinkM fail for me is that they are fiddly (or expensive). We don't want a lighting controller gaff-taped to a nearby wall with sticky tape pointing at the right preset. That's just another kind of over-complicated work around. Again, we want a user-programmed preset. After the light is set, it just plain turns on.
The only real failings of the BlinkM for me is lack of power for theatrical use, and some lack of flexibility in the existing controller software. Which might just be a conflicting paradigm thing (they went with a drum machine model for animations, I went for a flexible event-based system for mine).
The BlinkM from ThinkM.
So...I've had the high-power, hard-programmed RGB working. I had it on a costume in a show, and over the show it did exactly as required. The problem is, setting the desired look was a programming task. It was done with the skills, the knowledge of the circuit's behavior, and the programming tools I own.
The "Wiz" jacket, switching between free-running light animations when commanded remotely from the simple GUI shown on the laptop beside it.
What I want is for anyone to be able to purchase a kit or make the open-hardware light, set it to a theatrically useful look (oil lamp, say), and be done with it. But I am having no luck making the power I desire accessible to the end-user I envision.
Also, on the hardware side, if I make each individual light capable of simple stand-alone programming, it increases the unit cost. It makes too much sense to offload as much as the hardware as possible even if that does mean the end-user needs a minimum of two things to get started instead of one.
Hardware USB is the most transparent option. To put it on each individual light, though, increases their cost excessively. Plus the varied solutions are non-optimal in different ways. USB is a complex protocol, and there are no all-platform open definitions for producing a virtual COM port from it -- which is what is needed to allow one to write a nice user-friendly front-end (or even to surf in to the device via Terminal and program it on a command-line basis).
The older Arduinos used a translator chip from FTDI to handle interface to the user's USB port -- which also required a driver to be installed to show up on some platforms. There are AVR chips that are USB-native, but like the FTDI they are surface-mount devices and add considerably to the cost and effort of putting together each light.
HID is actually a lot easier; you can get a class-compliant HID with out-of-spec modeling of proper USB behavior, and it will still be recognized by most computers as a keyboard. There is even a clever hack that translates extra characters on this virtual keyboard into a fake serial port. But it requires multiple pieces of helper software and probably doesn't work on Mac yet.
Clever Arduino compatibles like the Trinket get by because the programming port used by avrdude is not per se a serial port. Basically, you can program an AVR using another non-USB compliant AVR (or even program itself with a clever enough bootloader) but it can't be made to show up as a serial port.
So, unless I want to write a wrapper for avrdude that presents a simplified GUI to the end-user but invokes the avrgcc toolchain behind the screen (too many pitfalls there I'm afraid), the best option is to move the expense of this USB-to-serial translation off the light and into a second board.
The BlinkM does it quite cleverly. It is programmed via a I2C connection, which is done using the soft serial code on an Arduino. Simply put, you plug the header of the BlinkM into matching pins on an Arduino header, run the provided Arduino sketch to turn the Arduino into a I2C to USB translator, then run the BlinkM programming software.
Somewhat similarly, you can once you have the complete Arduino software up and running, use an Arduino (with or without invoking soft serial -- in the old days it was done just by prying the ATmega itself out of the socket) to patch you though to the AVR you want to program. You could even use the Arduino IDE to write and upload the program.
And that's what I'm going to do. Only with an additional wrinkle. The power user can and should write their own software into the light. But for someone who just needs to specify the exact color it boots up into, or how long it takes to fade out when turned off, I am going to provide a space for user presets in non-volatile memory. So the end-user will use either FTDI cable (which are widely available in Arduino circles), or an Arduino with the appropriate software, to plug into the light node. They will try out different looks and then commit the look of their choice to one of the slots of user memory.
If and when I get that far, I can wrap this in a proper GUI. But before then, this behavior of going direct to looks or presets and setting the boot preset is also exactly what I want for inter-node communication.
Because the other thing I want to put on these lights that doesn't exist in any cheap, easy-to-use, prop-and-theater-friendly option is remote control.
The proof-of-concept for a accelerometer-based effect; this combined accelerometer, XBee module, and AAA battery pack to detect a throwing gesture and play a sound effect from a remote receiver.
At the base of it is a protocol to let each node communicate bidirectionally. I'm doing it this way, instead of using existing buses like I2C, for transparency as I program. The BAUD rate I envision may be low, but I can still afford to send ASCII nouns rather than cryptic hexadecimal sequences.
I envision a complex prop that might have several lighting nodes each playing canned animations in free-running mode, and a single controller just telling them when to switch on and off. This is also how we will interact wirelessly; you won't control a candle flicker in real time, you will command it to light, then blow out.
A sticking point at the moment is the RF option itself. I'd like to provision each lighting node with the basic circuitry, omitting only the expensive transceiver. But between level shifting and LDO and of course a couple status lights, it may add too much to the individual cost and complexity.
This is worse when considering the transceiver options. Now, there are a lot of cheap, off-the-shelf 434 kHz, Bluetooth, etc. options. But all of them are inadequate for theater. They offer fifty feet of transmission in line-of-sight. Theater requires shooting two hundred and fifty feet through set walls and a fifty-member dance ensemble.
The leading options I have now are the Hope RF chips -- particularly the RFM69W and HW chips -- and the XBee series.
Trouble is, the Hope chips appear to require four digital pins to communicate with them properly, and the code to navigate their communications protocol eats up a full 8K of program memory. Which makes them pretty much impossible to run from an ATtiny, and pushes them up into "requires a late-model Arduino to operate" territory.
The XBees are simple and transparent and I've been using them in actual theater situations. Their major drawbacks are frequency and price. They are 2.5 GHz devices, and shorter wavelength radio has poor penetration of obstacles. The "Pro" models, which have the necessary power to punch from light booth to backstage, are upwards of forty bucks each.
So down the road, I hope to get the Hope chips working for me, but for now I'm going to have to hope that only a few of the more expensive transceivers are needed by the typical end-user.
And as for interfacing with the worlds of DMX-512 and MIDI; I'm holding off there. I see this as happening via software (aka a laptop with a DMX-512 dongle) even though it would be a lot more turn-key if it was a single stand-alone DMX-512 module. But getting one of those up to spec and robust, it would end up costing pretty close to the commercial models that are already available. So not really something I need to explore at the moment.
But, at last, I'm nailing down the specs on the basic light module. I should be able to get the first order out to the fab house for printed-circuit boards this week. Maybe even assemble one in time for my coming lighting design.
Here's the major parts. Power supply 3.7V to 5v; aka lithium poly, 5v wall wart, or 3x "penlight" batteries (AA or AAA). The latter is my preferred choice for theater due to the ease of swapping in freshly-charged cells (rechargeable or otherwise).
I have a bunch of 3W RGB's to start with, but I've found RGBW's available for about twice the price and those will provide a much nicer mix for typical theater applications (candles, lanterns, headlights...) Unfortunately RBGA or RGB+ "Warm" White (4,000 K) are harder to come by at budget prices.
The buck driver on the right there is there to illustrate mostly the SOT-89 surface-mount footprint of the AMC7135's, of which I'll be provisioning four of. A nice additional quality of these things; you can run them in parallel to drive higher wattage LEDs.
The controller chip looks at this point to be an ATtiny 20-pin, probably the attiny861A because of its 8K of program memory. I do love the 25/45/85, but there just aren't enough pins. Even the ATtiny84 is pushing it for sufficient pins -- and doesn't have the nice UART of the larger, more expensive chip. The various chips to the lower left are standing in for that footprint. I'm going through-hole and socket for ease in assembly and replacement.
I haven't decided on the header; whether to go with the 2x3 ICSP type or the 6-inline format shared by the FTDI cable and other similar devices. And I'm still pondering whether the XBee will be on the main board or have a daughterboard (for which the Adafruit board at the top right is standing in). The trade-off, as always, is between a compact footprint and lots of out-of-the-box functionality, versus price per item. Because I have to anticipate situations in which you'd want a dozen of these things scattered around as part of a more complicated lighting effect, and that would be a lot easier if I could keep them under $10 each.
Back up a hair. LEDs are current devices. Once forward voltage is achieved, current flow will increase near-logarithmically over only small increases in voltage; a runaway process leading to overheating and breakdown. Thus current limiters are needed.
The better regulation is essentially a transistor that uses the current flow in a feedback loop, thus holding the current at a desired point. With the right components, these circuits will compensate for a range of voltages and, as well, react thermally in the correct direction to compensate for the changing behavior of LED and circuit as it warms up.
However, the typical packages I was finding were a couple bucks each and required up to a dozen external discrete components; capacitors, resistors, signal diodes, zener diodes, even inductors. Which was a lot of parts to be adding to a small board especially when I wanted to control three channels or more of LED.
But the AMC7135 is the ticket. Unlike many current limiters, it is preset internally to 350ma. It requires essentially no external components. And it may be a usage that's out of spec, but it can be successfully PWM'd. There are in fact high-end flashlights that use this exact circuit.
Again to step back; LEDs require a minimum voltage, and when this voltage is achieved will consume as much current as you let them. This makes them poor candidates for resistance dimming. The best way to control their intensity is to turn them on and off quite rapidly. By varying the ratio of time on to time off, you achieve a nice control of intensity.
Do this to red, green, and blue LEDs and you can achieve a decent range of colors as well.
Which is what I've been trying to do for over a year; to create an extremely cheap, small, high-power colored light that can be used inside props, on costumes, and in other theatrical applications. There are a lot of commercial packages that are similar, but few offer two of the things I find important for this application; tight control, and battery power.
Proof-of-concept; ATtiny controlling two channels of a 3W LED via darlington transistors, on a 4xAAA battery pack. When you hold down the button it does a candle flicker.
There are also commercial products that allow you to dial up a preset -- from infrared controllers to full DMX-512 wireless solutions to the pretty-durn-close BlinkM. Where all but the BlinkM fail for me is that they are fiddly (or expensive). We don't want a lighting controller gaff-taped to a nearby wall with sticky tape pointing at the right preset. That's just another kind of over-complicated work around. Again, we want a user-programmed preset. After the light is set, it just plain turns on.
The BlinkM from ThinkM.
So...I've had the high-power, hard-programmed RGB working. I had it on a costume in a show, and over the show it did exactly as required. The problem is, setting the desired look was a programming task. It was done with the skills, the knowledge of the circuit's behavior, and the programming tools I own.
What I want is for anyone to be able to purchase a kit or make the open-hardware light, set it to a theatrically useful look (oil lamp, say), and be done with it. But I am having no luck making the power I desire accessible to the end-user I envision.
Also, on the hardware side, if I make each individual light capable of simple stand-alone programming, it increases the unit cost. It makes too much sense to offload as much as the hardware as possible even if that does mean the end-user needs a minimum of two things to get started instead of one.
Hardware USB is the most transparent option. To put it on each individual light, though, increases their cost excessively. Plus the varied solutions are non-optimal in different ways. USB is a complex protocol, and there are no all-platform open definitions for producing a virtual COM port from it -- which is what is needed to allow one to write a nice user-friendly front-end (or even to surf in to the device via Terminal and program it on a command-line basis).
The older Arduinos used a translator chip from FTDI to handle interface to the user's USB port -- which also required a driver to be installed to show up on some platforms. There are AVR chips that are USB-native, but like the FTDI they are surface-mount devices and add considerably to the cost and effort of putting together each light.
HID is actually a lot easier; you can get a class-compliant HID with out-of-spec modeling of proper USB behavior, and it will still be recognized by most computers as a keyboard. There is even a clever hack that translates extra characters on this virtual keyboard into a fake serial port. But it requires multiple pieces of helper software and probably doesn't work on Mac yet.
Clever Arduino compatibles like the Trinket get by because the programming port used by avrdude is not per se a serial port. Basically, you can program an AVR using another non-USB compliant AVR (or even program itself with a clever enough bootloader) but it can't be made to show up as a serial port.
So, unless I want to write a wrapper for avrdude that presents a simplified GUI to the end-user but invokes the avrgcc toolchain behind the screen (too many pitfalls there I'm afraid), the best option is to move the expense of this USB-to-serial translation off the light and into a second board.
The BlinkM does it quite cleverly. It is programmed via a I2C connection, which is done using the soft serial code on an Arduino. Simply put, you plug the header of the BlinkM into matching pins on an Arduino header, run the provided Arduino sketch to turn the Arduino into a I2C to USB translator, then run the BlinkM programming software.
Somewhat similarly, you can once you have the complete Arduino software up and running, use an Arduino (with or without invoking soft serial -- in the old days it was done just by prying the ATmega itself out of the socket) to patch you though to the AVR you want to program. You could even use the Arduino IDE to write and upload the program.
And that's what I'm going to do. Only with an additional wrinkle. The power user can and should write their own software into the light. But for someone who just needs to specify the exact color it boots up into, or how long it takes to fade out when turned off, I am going to provide a space for user presets in non-volatile memory. So the end-user will use either FTDI cable (which are widely available in Arduino circles), or an Arduino with the appropriate software, to plug into the light node. They will try out different looks and then commit the look of their choice to one of the slots of user memory.
If and when I get that far, I can wrap this in a proper GUI. But before then, this behavior of going direct to looks or presets and setting the boot preset is also exactly what I want for inter-node communication.
The proof-of-concept for a accelerometer-based effect; this combined accelerometer, XBee module, and AAA battery pack to detect a throwing gesture and play a sound effect from a remote receiver.
At the base of it is a protocol to let each node communicate bidirectionally. I'm doing it this way, instead of using existing buses like I2C, for transparency as I program. The BAUD rate I envision may be low, but I can still afford to send ASCII nouns rather than cryptic hexadecimal sequences.
I envision a complex prop that might have several lighting nodes each playing canned animations in free-running mode, and a single controller just telling them when to switch on and off. This is also how we will interact wirelessly; you won't control a candle flicker in real time, you will command it to light, then blow out.
A sticking point at the moment is the RF option itself. I'd like to provision each lighting node with the basic circuitry, omitting only the expensive transceiver. But between level shifting and LDO and of course a couple status lights, it may add too much to the individual cost and complexity.
This is worse when considering the transceiver options. Now, there are a lot of cheap, off-the-shelf 434 kHz, Bluetooth, etc. options. But all of them are inadequate for theater. They offer fifty feet of transmission in line-of-sight. Theater requires shooting two hundred and fifty feet through set walls and a fifty-member dance ensemble.
The leading options I have now are the Hope RF chips -- particularly the RFM69W and HW chips -- and the XBee series.
Trouble is, the Hope chips appear to require four digital pins to communicate with them properly, and the code to navigate their communications protocol eats up a full 8K of program memory. Which makes them pretty much impossible to run from an ATtiny, and pushes them up into "requires a late-model Arduino to operate" territory.
The XBees are simple and transparent and I've been using them in actual theater situations. Their major drawbacks are frequency and price. They are 2.5 GHz devices, and shorter wavelength radio has poor penetration of obstacles. The "Pro" models, which have the necessary power to punch from light booth to backstage, are upwards of forty bucks each.
So down the road, I hope to get the Hope chips working for me, but for now I'm going to have to hope that only a few of the more expensive transceivers are needed by the typical end-user.
And as for interfacing with the worlds of DMX-512 and MIDI; I'm holding off there. I see this as happening via software (aka a laptop with a DMX-512 dongle) even though it would be a lot more turn-key if it was a single stand-alone DMX-512 module. But getting one of those up to spec and robust, it would end up costing pretty close to the commercial models that are already available. So not really something I need to explore at the moment.
But, at last, I'm nailing down the specs on the basic light module. I should be able to get the first order out to the fab house for printed-circuit boards this week. Maybe even assemble one in time for my coming lighting design.Here's the major parts. Power supply 3.7V to 5v; aka lithium poly, 5v wall wart, or 3x "penlight" batteries (AA or AAA). The latter is my preferred choice for theater due to the ease of swapping in freshly-charged cells (rechargeable or otherwise).
I have a bunch of 3W RGB's to start with, but I've found RGBW's available for about twice the price and those will provide a much nicer mix for typical theater applications (candles, lanterns, headlights...) Unfortunately RBGA or RGB+ "Warm" White (4,000 K) are harder to come by at budget prices.
The buck driver on the right there is there to illustrate mostly the SOT-89 surface-mount footprint of the AMC7135's, of which I'll be provisioning four of. A nice additional quality of these things; you can run them in parallel to drive higher wattage LEDs.
The controller chip looks at this point to be an ATtiny 20-pin, probably the attiny861A because of its 8K of program memory. I do love the 25/45/85, but there just aren't enough pins. Even the ATtiny84 is pushing it for sufficient pins -- and doesn't have the nice UART of the larger, more expensive chip. The various chips to the lower left are standing in for that footprint. I'm going through-hole and socket for ease in assembly and replacement.
I haven't decided on the header; whether to go with the 2x3 ICSP type or the 6-inline format shared by the FTDI cable and other similar devices. And I'm still pondering whether the XBee will be on the main board or have a daughterboard (for which the Adafruit board at the top right is standing in). The trade-off, as always, is between a compact footprint and lots of out-of-the-box functionality, versus price per item. Because I have to anticipate situations in which you'd want a dozen of these things scattered around as part of a more complicated lighting effect, and that would be a lot easier if I could keep them under $10 each.
Thursday, December 11, 2014
It Ain't the Heat, it's the Humidity
Actually, it is both.
A very simple bit of physics. The speed of sound changes due to the density of the air. Which means altitude, temperature, and humidity.
The absorption of sound by air (that is, the way acoustic energy falls off with distance in addition to the geometry of inverse-square dispersion), also changes with humidity, and this is frequency-dependent.
But let's take the first. Assume you EQ'd your house until the speaker response was nice and flat. Well, when the audience walks in, you've got a problem.
What is room EQ? Two things, primarily. There's the response curve of the speakers and amps. And there's the response of the room. This latter is due largely to multipath reflection. Sound comes from a speaker. It travels across the audience, hits the back wall, reflects back over that same audience. Where the two paths meet, parts of the waveform will be in phase and combine, others will be out of phase and destructively interfere. Thus, peaks and valleys in the response -- the most prominent of which can be related directly back to the dimensions of the room itself.
So what happens if the speed of sound changes? The two paths increase or decrease in time. But they do so as a proportion, as a percentage, of their previous time. Which means the phase relationship changes. Which means the peaks and valleys are not in the same place.
Which means that 2 kHz peak you notched out of the mains is no longer there, and you are taking a 2 kHz cut in the middle of the sound. And there's a new, uncorrected peak at 2.5 kHz. Or maybe 1.5 kHz -- depending on how the speed of sound changes, and how it relates mathematically to the critical dimensions of the room.
Oh, yes. And the temperature and humidity does change. Not only does each human body in the audience pump 100 watts of heat into the air, each gives off water vapor, raising the humidity. And that's not the worst of it. The graph changes radically between 10% and 30% humidity. Which means starting with a dry room and introducing warm sweaty bodies will have a much greater effect on the speed of sound in your venue than you might expect.
And that's before we even get to considering the frequency-dependent attenuation that also takes place over that critical humidity curve. Which -- just to put icing on the cake -- is most prominent at 12.5 kHz; right in the middle of our frequencies of interest.
A very simple bit of physics. The speed of sound changes due to the density of the air. Which means altitude, temperature, and humidity.
The absorption of sound by air (that is, the way acoustic energy falls off with distance in addition to the geometry of inverse-square dispersion), also changes with humidity, and this is frequency-dependent.
But let's take the first. Assume you EQ'd your house until the speaker response was nice and flat. Well, when the audience walks in, you've got a problem.
What is room EQ? Two things, primarily. There's the response curve of the speakers and amps. And there's the response of the room. This latter is due largely to multipath reflection. Sound comes from a speaker. It travels across the audience, hits the back wall, reflects back over that same audience. Where the two paths meet, parts of the waveform will be in phase and combine, others will be out of phase and destructively interfere. Thus, peaks and valleys in the response -- the most prominent of which can be related directly back to the dimensions of the room itself.
So what happens if the speed of sound changes? The two paths increase or decrease in time. But they do so as a proportion, as a percentage, of their previous time. Which means the phase relationship changes. Which means the peaks and valleys are not in the same place.
Which means that 2 kHz peak you notched out of the mains is no longer there, and you are taking a 2 kHz cut in the middle of the sound. And there's a new, uncorrected peak at 2.5 kHz. Or maybe 1.5 kHz -- depending on how the speed of sound changes, and how it relates mathematically to the critical dimensions of the room.
Oh, yes. And the temperature and humidity does change. Not only does each human body in the audience pump 100 watts of heat into the air, each gives off water vapor, raising the humidity. And that's not the worst of it. The graph changes radically between 10% and 30% humidity. Which means starting with a dry room and introducing warm sweaty bodies will have a much greater effect on the speed of sound in your venue than you might expect.
And that's before we even get to considering the frequency-dependent attenuation that also takes place over that critical humidity curve. Which -- just to put icing on the cake -- is most prominent at 12.5 kHz; right in the middle of our frequencies of interest.
A Perfect Storm
There's a renter that comes into my usual theater space every December. We typically have 3-5 technicians on our overhire list, so we split up the shifts to cover the gig. This year, there's just me, and I've got the entire thing. My hours from Sunday were 14, 13, 12...and then a mere 6 (plus two hours in a meeting across town on another show).
Over the same period that protests have been marching through town tying up traffic, breaking windows, setting fires, and attracting news helicopters that sit over our apartment loudly clattering away until the wee hours of the morning.
The protests finally stopped...as a record-breaking storm moved in, rattling windows all night, knocking down power lines, and flooding half the streets.
That's a twelve-hour shift of climbing ladders, by the by, with maybe fifteen minutes to grab a bite (no lunch or dinner break). And then little sleep due to riots and weather. And little food due to being almost broke.
And you know what? I feel great.
Over the same period that protests have been marching through town tying up traffic, breaking windows, setting fires, and attracting news helicopters that sit over our apartment loudly clattering away until the wee hours of the morning.
The protests finally stopped...as a record-breaking storm moved in, rattling windows all night, knocking down power lines, and flooding half the streets.
That's a twelve-hour shift of climbing ladders, by the by, with maybe fifteen minutes to grab a bite (no lunch or dinner break). And then little sleep due to riots and weather. And little food due to being almost broke.
And you know what? I feel great.
Pan With a Real Handle
...which was a mildly clever pitch I heard some years ago from a pan-handler in The Haight, near the "pan handle" of Golden Gate Park.
Anyhow, I'm getting into a lighting design now. Nice little space, about twenty dimmers to play with (but some LED pars that should take up some of the slack).
And once again, I learn more about the goals for a circuit I'm designing when an actual application comes along. There's an old-style radio in the show and the dialog makes a point of that nice tube glow.
Seems like a good application for the Duck Light; dial up a good "glowing tube" red-amber, rig it to a button....wait. The current version is color-programmed off-line. There's no provision for real-time adjustment of the color.
Right. So I really do need to set up a software chain that, at the least, allows real-time dialing of a color selection and pushing that into permanent flash memory.
And in the nature of this play, I'd really want the effect to be both remotely controlled, and DMX controlled. I had envisioned running complex effects off a laptop, but for this show, it would be nice to have a modular, turn-key, DMX-512 solution instead.
So this is once again something the BlinkM already does, and one better; it has a primitive sequencer built in, and uploads fresh code via its own custom GUI-based IDE. It makes it nearly trivial for the end-user to select color and simple animations the will operate in free-running mode.
I'm still caught on how to offer programming flexibility without the overhead of FTDI or other USB toolchain -- since I'm not really up for adapting any of the open-source serial-over-USB code bases myself!
Anyhow, I'm getting into a lighting design now. Nice little space, about twenty dimmers to play with (but some LED pars that should take up some of the slack).
And once again, I learn more about the goals for a circuit I'm designing when an actual application comes along. There's an old-style radio in the show and the dialog makes a point of that nice tube glow.
Seems like a good application for the Duck Light; dial up a good "glowing tube" red-amber, rig it to a button....wait. The current version is color-programmed off-line. There's no provision for real-time adjustment of the color.
Right. So I really do need to set up a software chain that, at the least, allows real-time dialing of a color selection and pushing that into permanent flash memory.
And in the nature of this play, I'd really want the effect to be both remotely controlled, and DMX controlled. I had envisioned running complex effects off a laptop, but for this show, it would be nice to have a modular, turn-key, DMX-512 solution instead.
So this is once again something the BlinkM already does, and one better; it has a primitive sequencer built in, and uploads fresh code via its own custom GUI-based IDE. It makes it nearly trivial for the end-user to select color and simple animations the will operate in free-running mode.
I'm still caught on how to offer programming flexibility without the overhead of FTDI or other USB toolchain -- since I'm not really up for adapting any of the open-source serial-over-USB code bases myself!
Thursday, December 4, 2014
KP Duty
Spent a full day at TechShop milling, grinding, and most especially filing. It looks like all the parts from the parts kit will more-or-less fit:
The shroud retaining lever fits, but the shaft was sheered near where the nut would be. Right now it is a tight friction fit but if I want to be really nice, I need to cut off the shaft, press-fit a new one, and thread that for a new retaining nut.
The magazine catch release appears to fit in the existing slot, with the pin being press-fit. At the very least I have to re-drill the holes, as one got slagged over.
The charging handle appears to be assembled through the gun, with the bolt catcher also pinned on. Sounds very fiddly to do! (I don't even know how you can press the -- missing -- pin in once the side rails are welded on).
I just figured it out. There's a hole in the side plates that is drilled slightly larger than the retaining pin. Trouble is, this requires moving the bolt back slightly from out of battery -- something no longer possible since I welded it in. But I should be able to just mill the slot a bit further and make it work.
The sight was wrenched off but even straightened, the remains of the rivets do not appear to be located properly. So I'll need to grind those off, possibly re-mill the slot a little to achieve a proper fit, then drill new holes. Which I might want to tap, or use soft brass on, so the next person along doesn't have to lever the sight assembly off.
The trigger assembly is held at the front by a block with a notch in it; only the stub of this block remains as the rest was in the direct path of the cut. So I have a few hours yet -- among other things, cleaning off the cosmoleum or whatever it is on the remaining original parts so they fit and move properly.
On the receiver itself: it is never going to look pristine, and I spent all morning with diamond bit and small hand files just re-shaping the barrel lugs after my last attempt to fill some of the remaining voids. But at the same time, it is starting to look decent and it might just be worth trying to fill the two worst gaps; the remaining slot in the side plates, and the small gaps to either side of the end cap. The latter are visible when the weapon is assembled.
To do the latter, I'll want to lathe up a new backing plug from the last of my 1-1/4" aluminium rod. Although since the bolt is now a permanent part of the rebuilt receiver, there's no good reason to keep any more of the rear clear than is needed for the rod that is part of the end cap. The big downside is I'm sure to damage the threads again, and have to grind and file those some more.
The side plates are a bit more troublesome. I had a long and difficult time trimming weld metal that made it past the end of my last set of backing plates, so I'm leery of welding near the tube. But pretty much, would be milling a chunk of aluminium plate to stand in for the trigger group. And probably milling into the existing side plates to provide a slot for fresh pieces of steel. The MIG will fill a lot, but even with a backing plate, where I fill is where I'm going to have to go back with mill and grinding bits to clean out the slot again.
I'm reading up on prep for gun bluing now. I have both brown and blue and should be able to get a nice aged patina out of them. I suspect very strongly I'm going to have to spend 10-20 hours continuing to file things smoother and smoother, then graduate to finer and finer emery papers, then finally to steel wool and wire brushes. So there's a bit of labor involved, still!
The shroud retaining lever fits, but the shaft was sheered near where the nut would be. Right now it is a tight friction fit but if I want to be really nice, I need to cut off the shaft, press-fit a new one, and thread that for a new retaining nut.
The magazine catch release appears to fit in the existing slot, with the pin being press-fit. At the very least I have to re-drill the holes, as one got slagged over.
The charging handle appears to be assembled through the gun, with the bolt catcher also pinned on. Sounds very fiddly to do! (I don't even know how you can press the -- missing -- pin in once the side rails are welded on).
I just figured it out. There's a hole in the side plates that is drilled slightly larger than the retaining pin. Trouble is, this requires moving the bolt back slightly from out of battery -- something no longer possible since I welded it in. But I should be able to just mill the slot a bit further and make it work.
The sight was wrenched off but even straightened, the remains of the rivets do not appear to be located properly. So I'll need to grind those off, possibly re-mill the slot a little to achieve a proper fit, then drill new holes. Which I might want to tap, or use soft brass on, so the next person along doesn't have to lever the sight assembly off.
The trigger assembly is held at the front by a block with a notch in it; only the stub of this block remains as the rest was in the direct path of the cut. So I have a few hours yet -- among other things, cleaning off the cosmoleum or whatever it is on the remaining original parts so they fit and move properly.
On the receiver itself: it is never going to look pristine, and I spent all morning with diamond bit and small hand files just re-shaping the barrel lugs after my last attempt to fill some of the remaining voids. But at the same time, it is starting to look decent and it might just be worth trying to fill the two worst gaps; the remaining slot in the side plates, and the small gaps to either side of the end cap. The latter are visible when the weapon is assembled.
To do the latter, I'll want to lathe up a new backing plug from the last of my 1-1/4" aluminium rod. Although since the bolt is now a permanent part of the rebuilt receiver, there's no good reason to keep any more of the rear clear than is needed for the rod that is part of the end cap. The big downside is I'm sure to damage the threads again, and have to grind and file those some more.
The side plates are a bit more troublesome. I had a long and difficult time trimming weld metal that made it past the end of my last set of backing plates, so I'm leery of welding near the tube. But pretty much, would be milling a chunk of aluminium plate to stand in for the trigger group. And probably milling into the existing side plates to provide a slot for fresh pieces of steel. The MIG will fill a lot, but even with a backing plate, where I fill is where I'm going to have to go back with mill and grinding bits to clean out the slot again.
I'm reading up on prep for gun bluing now. I have both brown and blue and should be able to get a nice aged patina out of them. I suspect very strongly I'm going to have to spend 10-20 hours continuing to file things smoother and smoother, then graduate to finer and finer emery papers, then finally to steel wool and wire brushes. So there's a bit of labor involved, still!
Tuesday, December 2, 2014
One-Piece
I welded today.
Took the SBU (Safety and Basic Use class) for the MIG welder last week. Went in today and pulled a bunch of scrap (mostly battered welding chits from previous classes) from the bin and tried to remember what I'd learned in class. I'd had a lot of trouble in class for some reason. I think because previous experience in stick welding had me used to eyeballing the arc, and the bulk of the MIG electrode holder means you really can't do it that way. So fifteen years of muscle memory was in my way.
I messed with the dial settings and made lots of nasty spots and sputters for about an hour, then it started to click. The "bacon" sound came almost immediately upon achieving a good spark coil sound (the two sounds are superimposed; you can hear when you are getting a good weld). And once I found that groove, I could pretty arbitrarily change the electrode distance and travel speed, pretty much adjusting one to the other.
It is a whole dance when you are doing it right; maintaining the arc, building and pushing the puddle, achieving the right blend of penetration and fill, controlling the heat build-up. All through constant movement whilst maintaining the correct distance and travel.
Put rougher scrap on the table and started at welding into corners and filling voids. And it was going well enough I jumped right up to working on the Suomi again.
It is nice to finally have the receiver in one piece. There's a lot of grinding and filing before I can be sure I got the measurements right, though. And I haven't decided on the best way to tackle that hole behind the magazine well. I could mill a backing plate out of aluminium plate and fill the remaining void with weld metal. Or I could cut a slot and put in new steel. Or perhaps I can mill down the stubs of the side rails enough to where I can slot in new chunks of plate steel -- probably again with a backing plate of aluminium.
I also think I have to lathe another "fake bolt" to use as a backing plate to put a little more metal at the end of the tube; the cap screws down only so far and the gaps I have would be visible in the assembled weapon. The original fake bolt I machined is of course welded permanently inside the tube at this point, and I intend to take further steps to ensure it remains so.
There's still several smaller gaps. I tried flowing solder into some of the smallest holes but my iron hasn't got the power to push heat into five pounds of steel. There's also an epoxy-based filler designed for this, but it doesn't take bluing well. I have a small brazing kit, too, but unless I get in on the TIG class some time real soon I'm looking at basically throwing big blobs of metal from the oversized wire we have and then grinding them back down again. And it may take multiple passes before I'm satisfied with it.
In any case, TechShop was very much the way to go. Sturdy steel tables, lots of clamping options, a full-sized MIG of course, and lots of bandsaws and grinders and whatnot right there to create filler with. Much more comfortable than the plywood propped up on sawhorses out in a parking lot that I started with!
It is nice to finally have the receiver in one piece. There's a lot of grinding and filing before I can be sure I got the measurements right, though. And I haven't decided on the best way to tackle that hole behind the magazine well. I could mill a backing plate out of aluminium plate and fill the remaining void with weld metal. Or I could cut a slot and put in new steel. Or perhaps I can mill down the stubs of the side rails enough to where I can slot in new chunks of plate steel -- probably again with a backing plate of aluminium.
I also think I have to lathe another "fake bolt" to use as a backing plate to put a little more metal at the end of the tube; the cap screws down only so far and the gaps I have would be visible in the assembled weapon. The original fake bolt I machined is of course welded permanently inside the tube at this point, and I intend to take further steps to ensure it remains so.
There's still several smaller gaps. I tried flowing solder into some of the smallest holes but my iron hasn't got the power to push heat into five pounds of steel. There's also an epoxy-based filler designed for this, but it doesn't take bluing well. I have a small brazing kit, too, but unless I get in on the TIG class some time real soon I'm looking at basically throwing big blobs of metal from the oversized wire we have and then grinding them back down again. And it may take multiple passes before I'm satisfied with it.
In any case, TechShop was very much the way to go. Sturdy steel tables, lots of clamping options, a full-sized MIG of course, and lots of bandsaws and grinders and whatnot right there to create filler with. Much more comfortable than the plywood propped up on sawhorses out in a parking lot that I started with!
Came home, and my laptop was showing that it was on battery. With the charger plugged in. Oops. Looked at the charger, and there was a nasty charred spot in the cord where somehow it had cracked or been caught (or nibbled?) and tore the outer wrap-around conductor. Which apparently is not a ground/shield; there's power running through it. Hrm. Anyhow, was able to work a length of desoldering braid into the frayed ends and restore continuity. Good thing, too, since closing weekend is almost on us and all my sound cues and keyboard patches and house music are on this machine!
To finish up the day, plugged the UMX-610 into a Reaper file I keep for that purpose and did a little piano practice. But what did I say about muscle memory? Maybe welding all day tuned my hands to the wrong expectations. I was fumbling a lot of notes. But oh well. I do far too many things to even hope to do all of them well.
Subscribe to:
Posts (Atom)