Category: Bad Ideas
I am working on a portable projector to take to an arts festival in Toronto. I was planning to power it from a 12V lead/acid battery, which would be stepped up to 110VAC by an inverter, which would then be stepped back down to 36VDC at 3A (regulated) to drive an 8000 lumen LED. Tonight, I hooked up the LED, inverter, and battery. It almost works, but the inverter is too wimpy to drive the LED. Instead what happens is there is a brilliant flash as the LED lights, the inverter output voltage drops, the LED driver resets, and then there is another flash and the cycle repeats.
Obviously, this will never do. The inverter is supposed to be good for 140 Watts, and so driving a 100 Watt LED sounds like it should be a piece of cake, but at 110V, the extra 40 watts is really only 360mA (W=VI, so I = W/V (Sort of. For non-resistive loads, there’s power factor correction)). If there’s any extra draw in the LED driver as it starts up, it could eat that right up. It’s also possible that the power rating on the inverter was simply a lie.
Switching to a 200 watt inverter didn’t fix the problem, nor did adding a 17,200uF capacitor in parallel with the battery. However, I did check the battery voltage immediately after running the system, and it was around 11.3V. That’s mighty low for a 12V SLA, so I’m going to borrow the 12V battery charger from work and try it on my batteries. It may be that I just didn’t have a sufficient charge. If that is the problem, it may mean I need to switch to a halogen spotlight, as the 12V batteries may discharge too quickly.
When I added the ICSP header to my ToyBrain boards, I mirrored the footprint so that some of the routing would be easier. I did not, however, correct the actual wiring, so now the ICSP header comes off the wrong side of the board.
This is going to be easy to fix in the next revision, but for now I’m going to roll up a little adapter to get the boards programmed.
More later, when it’s closer to noon than midnight.
I was reading up on HTTP status codes, and I got a bad idea. There are a small number of official status codes, like the ubiquitous 404 (file not found), an even smaller number of less-official status codes, like 418 (I am a teapot), and a lot of undefined status codes.
So what happens if a browser gets an undefined status code? What if it gets a malformed code? Writing a simple test for this would be easy. It would just be a web app framework that returns whatever you pass it on the URL as the error code, so www.example.com/errorCodes/200 would get you HTTP OK, while www.example.com/errorCodes/499 would get you the undefined code 499.
I would hope that the browser runs the code past its short list of defined codes, doesn’t recognize it, and shows an error page to the user saying something like “The server returned an invalid error message. It may be misconfigured. Please try back later.”
However, some browsers may mishandle the message, and hand anything that starts off with, say, 2xx to the page renderer, whereupon things might go horribly awry. I hope modern browsers are immune to this sort of shenanigans, but it may be no one has beaten on them in that particular way.
The Seizuredome light is an icosahedron made out of aluminum. Each face is 5.5 inches on a side, so the whole thing ends up being about the size of a soccer ball. Each face has three 1″ aluminum spikes sticking out of it, so that when it is not hanging, it does not rest on any of the LEDs.
The light started life as a sheet of aluminum, 24″ on a side. I plotted the net of the icosahedron by constructing a bunch of equilateral triangles with a compass and straightedge. Geometry class is only useless if you’re not planning to make anything interesting in your life.
After that was all plotted out, I cut it out with tin snips and cut arcs out of the corners with a nibbler. The arcs will make the finished shape have a hole at each vertex. Those holes are where I will run the wires for the LEDs, but they also let me more or less ignore the thickness of the material, which would otherwise possibly make the corners look bad.
Then I drilled holes in all the pieces. The holes in the faces are for LED and spike mounting. The ones in the tabs are for rivets that hold the shapes together.
I bent the flat shapes in an improvised metal brake to get them 3-D, and then riveted them together to hold the shape.
The finished shape seems to fit together pretty well.
I added more holes for sheet metal screws. I also added a flat plastic platform inside, so that the electronics have something to rest on, and screwed the spikes to the outside. The spikes are intended to be ornaments for punk clothing, but they mount with screws, so you can stick them on anything you can drill a hole in.
The electronics are also mostly together. I just have to finish up the code, and then mount the control circuit inside, the LEDs outside, and add a power switch.
I started this blog to keep a sort of running list of what projects I have going on and my progress on each of them. Instead of doing that, I’ve been working on the projects and ignoring the blog.
My main project right now is the Seizuredome. The “dome” part is an icosahedron made out of electrical conduit. Five of the faces of the icosahedron are left off, and it rests on the ground on that side, forming a sort of dome. I used the construction techniques from Desert Domes to build the frame, but the process is essentially flattening the ends of the pieces of pipe and drilling holes in them so they can be held together with bolts. There is a picture of the completed dome frame in a previous post. That frame will be covered with mylar “space blankets” to provide a reflective surface.
The “seizure” part of the dome is a little more complicated. If you close your eyes and look at a bright light, you can still sort-of see the light, as a red glow through your eyelids. If that light pulses in the 5-20Hz range, you would expect to see the blinking through your eyelids. Instead, most people end up seeing colorful patterns, like swirling fractals, tye-die designs, spiderwebs, and such. What happens is that the blinking signal is close enough to the patterns of electrical activity in the brain that it can drive the dominant frequencies of neural activity to synchronize with it, resulting in hallucinations and mildly altered states of consciousness. You can buy goggles with blinking lights in them, or make your own devices, which will allow one person to do this. I’m building a photic driver for multiple users.
The Seizuredome will have a bright red strobing light in its center. This light is made of 20 1-watt red LEDs mounted on the surface of an aluminum icosahedron. Each LED is driven by a constant-current driver, which is controlled by a TLC5940 LED driver chip. The TLC5940 chips are controlled by an Arduino. Power for the whole thing is supplied by a LM7805 supply with a beefy pass transistor. That light will be hung inside the reflective dome, illuminating the inside. Since the light is suspended inside a reflective dome, there will probably be no place inside the dome that isn’t strobing red, so users inside the dome will be able to see the psychedelic show by entering the dome and closing their eyes.
That still doesn’t really answer why I called it the Seizuredome, though. I turns out that some people are photosensitive epileptics, but don’t know it. Strobing lights of the frequencies most likely to cause seizures by interfering with neural electrical activity are rare, and don’t usually last long enough to trigger seizures. As a result, it’s possible for someone to grow up without ever seeing a blinking light that is intense enough for a long enough time to cause a seizure.
This is the framework for a geodesic dome. It will be wrapped in mylar blankets to make the interior reflective and lit with a very powerful red LED strobe. Anyone inside it will be able to get brain-machine-like effects by sitting and looking at the strobe.
Of course, it could also cause seizures in previously undiagnosed photosensitive epileptics, so there will have to be warning signs.
Now available at my GitHub repo. Note that using these scripts is probably a horrible violation of Wizards of the Coast’s ToS for their website, and can probably get you banned.
Captchas are those distorted snippets of text that some web sites use to try to prevent spammers and bots from automatically registering accounts. The idea is that a human can read the words, but a computer cannot, and so only a human can fill out the text box correctly.
However, it’s probably possible to get humans to crack the captcha for fun. Imagine a “missile defense” typing tutor and game, where each incoming missile is a captcha text. If you type the text, it goes away. Since the game can’t tell what the texts are to begin, it would send the same word to multiple players and only block the “incoming missile” when multiple players typed in the same thing. From that, it could build a massive database of images and corresponding text, which could then be used to register accounts. Alternatively, someone who wants to crack a captcha could submit it to a server, which would then include that captcha in all the currently-running games and reply with the text when several people typed the same thing.