My 7-year-old son uses the term "search up", which he learned at school. "Dad, just search up the eclipse!" It actually seems like a decent term for, um, googling.
I've had luck rescuing a digital camera which was immersed in a dirty puddle by taking off the cover, rinsing the circuit boards with distilled water, and then putting everything into the oven.
In particular, put the oven on its lowest setting - hopefully around 150 deg F - significantly below boiling. Let the oven heat up first, then put your electronics inside and let them cook for several hours, even overnight. This will evaporate the water out. Then take your electronics out of the oven and let them cool before testing.
The advice to clean with alcohol might work as well or better (I haven't tried it), but I would trust that alcohol would dissolve the contaminants that came with your dirty water. Since the contaminants dissolved out of water in the first place, you should be able to get rid of them with water.
I was quite surprised at the range of my Apple Bluetooth keyboard (the new flat version) and Mighty Mouse - they would work without problems completely across my house (not very far - maybe 40 feet) and through the floor and part of the basement wall. Unfortunately I hated the Mighty Mouse. I've searched in vain for a decent wireless trackball in the style of the Logitech Mouseman Marble, but no dice. I use Logitech's non-bluetooth wireless Mouseman Marble, but the range is less than 6 feet.
And if you check out the image attached to the article, you'll find a remarkably obfuscated and short chunk of code to generate a random Voronoi diagram image. I bet this is the precursor to the winning code submitted to the IOCCC.
The press release gives a release date of May in Europe, and price of 300 Euro. There's also the key010, which looks like the same thing without the video capability and MP3 player, for 200 Euro.
Um, no it's not. If you look at their web page, it's a 450 MHz PII:
vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes) stepping : 2 cpu MHz : 451.018 cache size : 512 KB
In fact, I'm pretty sure it's a Pentium II Xeon (the server version of the processor), since the desktop processors have only 256K of cache. My machine at home happens to have two of the same PII Xeons:
vendor_id : GenuineIntel cpu family : 6 model : 5 model name : Pentium II (Deschutes) stepping : 3 cpu MHz : 448.058 cache size : 512 KB
So, while it's not speed monster, this is not that slow of a CPU.
A while back, there was a Slashdot article about the Conquest File System, a filesystem for machines with large amounts (gigabytes) of battery-backed RAM. It seems likely, with falling RAM prices, that large quantities of persistent RAM will be a part of fast servers in the future. Do you have any plans to make ReiserFS take advantage of such systems, beyond just putting the journal in RAM?
They're using a Xilinx XCV1000, which is a very very high-end FPGA. Go to www.findchips.com and search for XCV1000, and you'll see prices from $1300-$2400. Not exactly cheap for a slow (not pipelined, single ALU, etc) 15-17 MHz processor. This thing isn't going to actually be useful for anything except its intended purpose: experimentation for a thesis.
That was the original plan for this thing - I wanted to make a VT100 terminal clone to hang on the wall. Unfortunately to get decent resolution with normal LEDs it'd have to have been about 6 feet long, and at that length, rotating at 30 Hz, the edges experience about 3000 Gs. Seemed like a bad plan at the time. In the actual ROPOD, the edges only experience 800 Gs.
Re:If you thought this was cool, check out the ROP
on
Illusionary LED clock
·
· Score: 1
I'm the creator of the ROPOD, so I ought to be qualified to answer your questions. I'm ashamed to admit that I haven't modified the ROPOD web page since Aug 20, 1997. I really should do so...
Do you use a micro controller or is the device connected to the PC while running ?
Both, really. The spinning portion of the display has a 68HC11E2 microcontroller on board. The host computer can talk to the controller over a 115kbaud serial line. Since the controller only has 64K of RAM, animations and such are sent in real time over the serial line.
How do you supply power/control to the rotating parts (the LEDs)?
It's not obvious from the picture, but most of the electronics are on the rotating portion. The board basically has the HC11, a giant AMD PAL (about twice as big as the processor), 64K of VRAM, and a bunch of MOSFETs to drive the LEDs.
Power is supplied via motor brushes on slip rings. The brushes drop a few volts, so power is supplied at 12 volts and regulated to 5.
Communication is via an infrared trasmitter/receiver pair embedded in the axle of the ROPOD. The tranmitter is stationary, and the reciever rotates with the axle. You can see me holding the tranmitter in one of the pictures on the ROPOD web page. Communication is just 115kbaud unidirectional RS-232 serial.
How do you read out the instantaneous angle of the LEDs ?
There's an infrared LED on the base at a particular location, and a sensor on the rotating disc. The sensor gets triggered once per revolution, letting the processor figure out rotation speed and orientation. In the big picture (the one where it says "ROPOD Mark I") on my web page, you can see the trigger LED as a bright spot in the lower left - the video camera I was using is sensitive to infrared.
Is the software available?
I suppose I could supply schematics and PAL code and 68HC11 code and the (Linux-based) communications environment, but all of the hardware is horribly outdated, and if I made a ROPOD now, I'd use totally different stuff. I've been meaning to make an updated version. With surface mount LEDs I should be able to get much better resolution, and with the relatively cheap blue LEDs that are available now, I could make it full color. And programmable logic devices and processors are so much bigger and faster now that I could make it much more capable. I've been meaning to, but always had too many other projects on the back burner.
15ms is 15 milliseconds (0.001 seconds).
15us is 15 microseconds (0.000001 seconds).
There's a big difference - 15ms latencies are achievable with a standard linux kernel with a few patches. 15us maximum latencies are pretty impressive for an x86.
My 7-year-old son uses the term "search up", which he learned at school. "Dad, just search up the eclipse!" It actually seems like a decent term for, um, googling.
I've had luck rescuing a digital camera which was immersed in a dirty puddle by taking off the cover, rinsing the circuit boards with distilled water, and then putting everything into the oven.
In particular, put the oven on its lowest setting - hopefully around 150 deg F - significantly below boiling. Let the oven heat up first, then put your electronics inside and let them cook for several hours, even overnight. This will evaporate the water out. Then take your electronics out of the oven and let them cool before testing.
The advice to clean with alcohol might work as well or better (I haven't tried it), but I would trust that alcohol would dissolve the contaminants that came with your dirty water. Since the contaminants dissolved out of water in the first place, you should be able to get rid of them with water.
Seth
I was quite surprised at the range of my Apple Bluetooth keyboard (the new flat version) and Mighty Mouse - they would work without problems completely across my house (not very far - maybe 40 feet) and through the floor and part of the basement wall. Unfortunately I hated the Mighty Mouse. I've searched in vain for a decent wireless trackball in the style of the Logitech Mouseman Marble, but no dice. I use Logitech's non-bluetooth wireless Mouseman Marble, but the range is less than 6 feet.
Wikipedia has a pretty good entry on Voronoi diagrams.
And if you check out the image attached to the article, you'll find a remarkably obfuscated and short chunk of code to generate a random Voronoi diagram image. I bet this is the precursor to the winning code submitted to the IOCCC.
The press release gives a release date of May in Europe, and price of 300 Euro. There's also the key010, which looks like the same thing without the video capability and MP3 player, for 200 Euro.
There are some nice pictures and such in a Philip press release at:e bit2004-568.html
http://www.press.ce.philips.com/press/2004-2-23-C
The sample exploit works just fine on IE 6 too - from the article, it looks like it should work on IE 5.5 and on.
Um, no it's not. If you look at their web page, it's a 450 MHz PII:
In fact, I'm pretty sure it's a Pentium II Xeon (the server version of the processor), since the desktop processors have only 256K of cache. My machine at home happens to have two of the same PII Xeons:
So, while it's not speed monster, this is not that slow of a CPU.
A while back, there was a Slashdot article about the Conquest File System, a filesystem for machines with large amounts (gigabytes) of battery-backed RAM. It seems likely, with falling RAM prices, that large quantities of persistent RAM will be a part of fast servers in the future. Do you have any plans to make ReiserFS take advantage of such systems, beyond just putting the journal in RAM?
They're using a Xilinx XCV1000, which is a very very high-end FPGA. Go to www.findchips.com and search for XCV1000, and you'll see prices from $1300-$2400. Not exactly cheap for a slow (not pipelined, single ALU, etc) 15-17 MHz processor. This thing isn't going to actually be useful for anything except its intended purpose: experimentation for a thesis.
That was the original plan for this thing - I wanted to make a VT100 terminal clone to hang on the wall. Unfortunately to get decent resolution with normal LEDs it'd have to have been about 6 feet long, and at that length, rotating at 30 Hz, the edges experience about 3000 Gs. Seemed like a bad plan at the time. In the actual ROPOD, the edges only experience 800 Gs.
- Do you use a micro controller or is the device connected to the PC while running ?
Both, really. The spinning portion of the display has a 68HC11E2 microcontroller on board. The host computer can talk to the controller over a 115kbaud serial line. Since the controller only has 64K of RAM, animations and such are sent in real time over the serial line.- How do you supply power/control to the rotating parts (the LEDs)?
It's not obvious from the picture, but most of the electronics are on the rotating portion. The board basically has the HC11, a giant AMD PAL (about twice as big as the processor), 64K of VRAM, and a bunch of MOSFETs to drive the LEDs. Power is supplied via motor brushes on slip rings. The brushes drop a few volts, so power is supplied at 12 volts and regulated to 5. Communication is via an infrared trasmitter/receiver pair embedded in the axle of the ROPOD. The tranmitter is stationary, and the reciever rotates with the axle. You can see me holding the tranmitter in one of the pictures on the ROPOD web page. Communication is just 115kbaud unidirectional RS-232 serial.- How do you read out the instantaneous angle of the LEDs ?
There's an infrared LED on the base at a particular location, and a sensor on the rotating disc. The sensor gets triggered once per revolution, letting the processor figure out rotation speed and orientation. In the big picture (the one where it says "ROPOD Mark I") on my web page, you can see the trigger LED as a bright spot in the lower left - the video camera I was using is sensitive to infrared.- Is the software available?
I suppose I could supply schematics and PAL code and 68HC11 code and the (Linux-based) communications environment, but all of the hardware is horribly outdated, and if I made a ROPOD now, I'd use totally different stuff. I've been meaning to make an updated version. With surface mount LEDs I should be able to get much better resolution, and with the relatively cheap blue LEDs that are available now, I could make it full color. And programmable logic devices and processors are so much bigger and faster now that I could make it much more capable. I've been meaning to, but always had too many other projects on the back burner.15ms is 15 milliseconds (0.001 seconds).
15us is 15 microseconds (0.000001 seconds).
There's a big difference - 15ms latencies are achievable with a standard linux kernel with a few patches. 15us maximum latencies are pretty impressive for an x86.