What would happen to a banana if all the radioactive potassium it contained were to decay simultaneously?
Mass of average banana: 118 grams
Potassium in average banana: 422 milligrams
- 0.0117% of which is radioactive potassium-40: 49.374 micrograms
Potassium-40 has an atomic mass of 6.64*10-23 grams: 7.43584337 * 1017 atoms of potassium-40
Each atom of potassium-40 can decay into either:
- Argon-40 10.72% of the time, releasing 1.5 mega electron volts
- Calcium-40 89.28% of the time, releasing 1.311 mega electron volts
So, 7.97122409 * 1016 atoms will decay into argon-40, releasing a total of 1.19568361 * 1017 mega electron volts (19156.96 joules)
And 6.63872096 * 1017 atoms will decay into calcium-40, releasing a total of 8.70336318 * 1017 mega electron volts (139443.24 joules)
Totaling to 158.6 kilo joules
We will assume a banana is mostly water (actually 74%, close enough)
Specific heat of water: 4.186 joules per gram
Room temperature is 25 celsius
The specific heat calculation tells us how much an object will heat up when exposed to energy: T = Q/(c * M)
158.6 kilo joules / (4.186 joules per gram * 118 grams) + 25 celsius = 346 celsius
If all the potassium-40 in a single banana were to decay simultaneously, it would reach over 300 degrees celsius and explode with the force of 38 grams of TNT.
@shot_dragon pointed out that I had forgotten to take the heat of vaporization into consideration.
Heat of vaporization of water: 2.257 kilo joules per gram
Mass of vaporized banana: 70.27 grams
This is unfortunately not enough energy to vaporize the entire banana, only 59% percent or so, which would still lead to a sticky awful (burning) mess.
You can see my example working installation here: https://deaddrop.goopypanther.org/
The following text is from the readme file on this project's github page.
This webapp allows anonymous users to send messages to your inbox, which arrive signed and encrypted using PGP to ensure message integrity and privacy. Only SSL connections are permitted, which ensures encrypted communication between client and server. What SSL doesn't do is give you any idea of who the server is, be it legitimate or an attacker posing as the server. The internet tires to do this identity verification using CA certs but its a mess and full of vulnerabilities. Ultimately it is no better than self-signing, as CA certs only provide the illusion of identify verification.
The method we must use is called TOFU (Trust On First Use), you may be familiar with this if you use SSH. The client accepts the self-signed certificate and warns you if it unexpectedly changes. There are some firefox extensions such as Certificate Patrol that make this process easier for the end user. The only way to verify the identity of the server is by comparing the key fingerprint on a trusted channel of communication, such as in person or using a shared secret key. For numerous reasons this is beyond the scope of this project.
When a message is typed into the secure text box and submitted, it is securely transmitted to the server, encrypted using the recipient's public key, signed using the server's private key and delivered to a preprogrammed email account. More security conscious users may opt to have this email account be local to the server itself, but it can be delivered to any email account provided the server is capable of sending it.
A word on PGP: Like SSL, PGP is good at encrypting things, but poor at verifying identity. There is a system in place called the web-of-trust where users can verify each other's public key in person and build a network of key-identity connections. Other users can trust key-identity pairings based on how trusted the pairings are by others. The flaw in this system is that it publicly exposes networks of trust between individuals, which at best is detrimental to privacy and at worst is outright dangerous to political activists and dissidents. Again, the method we must use is TOFU. Accept the public key displayed on the site, verify it with a remote key or offline backups and be highly suspicious if it unexpectedly changes.
Because the end user may not yet trust the server's self-signed SSL certificate, they may wish to encrypt and sign their message with the displayed public key before pasting it into the secure message box. This will result in the message being encrypted twice, which is annoying but not much of a problem.
Help, my desk's been taken over by ROV parts. I've got a pcb made up and parts waiting to assemble. My current problem is that the waterproof pumps I bought only run in one direction regardless of polarity. I'll either run the ROV with much limited (although still functional) mobility or chop off the pump section and attach a propeller to the motor shaft.
Most of the core information is available in my github's readme file:
The ROV will be connected to the surface by cat5 ethernet cable, carrying data and PoE at 12-48 volts depending on what power supply I find.
The underwater component will contain a motherboard, power converter and ip camera.
The motherboard contains a passive ethernet hub, connections to the power converter, microcontroller and motor drivers. The system can be programmed by usb connection.
When the motorboard's ip address is visited in a web browser, it responds with a simple html page showing instructions and a live updating camera feed. Pressing the WASD, QE and up/down arrow keys will send GET requests to the onboard webserver that will control the motor drivers. There is also a checkbox that will control an led array for increased lighting. ROV Design
The ROV will have four motors, one each for movement in the X, Y and Z axises and one for rotation of the robot.
All electronics will be encased in a waterproofed pvc pipe that will form the body of the ROV with a window endcap on one side and 5 waterproofed electrical connections on the other. Bits of foam will be used to achieve neutral density.
Motors will be standard brushed dc, placed inside pill bottles filled with paraffin and marine jelly for waterproofing. Propellers will be whatever I can get my hands on.
Code for the embedded server is based off examples from jcw's ethercard project.
I've been a bit busy lately, working on an underwater remotely operated vehicle as part of my university's entrance into the MATE rover competition. The goal of the particular competition this year was to install mock-up research equipment at the bottom of a 17 foot deep pool.
My own contribution focused on the electrical systems, which I designed as a single module to fit inside a waterproof enclosure welded together by one of my classmates.
The propulsion system was made from six waterproof bilge pump motors fitted with propellers; two for depth control and four arranged to give vectored thrust for increased mobility. We also had control over several waterproofed servo motors to operate a robotic claw which we never ended up actually using during the event. Electrical connections through the drybox were made with specialized waterproof marine connectors we got at great discount from SeaCon. The larger one carries all motor connections as well as power to our camera, and the smaller connects to our tether, carrying command data and 48 volt electrical power.
Our internal computer was made from a slightly modified Stellaris Launchpad (several 0-ohm resistors were removed to reroute output ports) connected to a daughterboard with a power regulator, breakout headers for servo and motor control (with current protection) and a TTL to RS232 converter to communicate through a 50 foot long tether back to a laptop on the surface.
Controller boards sat between the microcontroller and the motors, which I designed based around an L6203 H-bridge chip. A small amount of logic circuitry allowed us direct control over motor polarity and duty cycle. Each module was removable and replaceable in the event of failure.
Our microcontroller acted as a gateway between these motor drivers and the surface computer, which did all the heavy calculation for our vectored thrust system. The actual drive interface was an X-box controller communicating with a C# application.
The other board inside the drybox is a switching regulator, bringing the 48 volt power supply from our tether down to 12 volts that ran all the internal systems. Finally a waterproof camera was mounted to the side of the main body with a coaxial cable running up the side of the tether.
Most of the construction of the ROV took place in the week before the competition with about seven of us working 14-hour days amongst our classes.
Unfortunately we did not pass from regional to the international level competition due to buoyancy control issues. The foam you can see attached to the wings in the first image worked well in our local pool (6 feet), but below 9 feet the pressure crushed it. We replaced this with used gatorade bottles while at the competition, which in turn crushed at 17 feet. We eventually were able to use bits of a cut apart fishing float designed to work at depths of up to several hundred feet, but without time to properly calibrate float placement we weren't able to balance the ROV in the water, or successfully reach neutral buoyancy. Our underpowered thrusters were unable to cope with either our positive or negative buoyancy and ultimately we were only able to scoot around at the bottom.
The two other teams in our bracket at the regional competition did not fair much better; the other university present was unable to complete their ROV in time and the local 4-H club (which qualified for the international level) only completed half of the mission objectives (despite operating with a budget 16x larger than ours). If other regional competitions end up having a similar level of success, I think we can expect a relaxation of mission objectives next year.
Our plan for next year's competition is to lighten our frame and replace our motors with a more powerful variety. We'll also be able to do extensive buoyancy testing in both our university's pool and our local lake.
Personally, I am interested in independently constructing a smaller ROV as part of my senior electrical engineering project before graduation.
A few changes had to be made to my board since I last posted, I had forgotten an important capacitor on the reset line. TTL serial programming on AVR chips requires a capacitor between the DTR line and the reset pin on the microcontroller in order to properly form a reset pulse during programming.
I also discovered that I lined up my SPI header backwards; all the pins are in the right order, but the PCB currently has to be turned backwards to fit it in-line with the LED strip. All these changes have been made and commited to the git repository.
Also just as an afterthought I connected the unused CTS line to an I/O pin. In the future someone may want to interface this board with another project, and this way the FTDI header can be used as 3 I/O lines, two of which are connected to the UART system.
Programming of the bootloader was done with a USBtinyISP by inserting the programming pins into the SPI header and the reset line on the FTDI header. The MISO line was connected to the exposed pogo-pin pad on the board and held there during programming by hand. The fuses I selected can be read from the table on the right. Once the bootloader hand been flashed the FTDI header could be used to program the board in the standard arduino environment (the board was flashed and programmed as a Diecimila/Duemilanove w/ 168).
The program I uploaded as a test was a simple rainbow pattern taken from adafruit's demo code. Due to my omission of the DTR capacitor I had to add one between the FTDI header and the actual FTDI cable I was using. New versions of the board will have this included.
Below is a video of the system working with the test program. Partway through I bump the ground line by accident and it briefly disconnects. The LED strip dims but does not go out during this period. My explanation for this is that current is being returned through the data and clock lines and smoothed by the capacitors built into the strip. Its nice to know that the microcontroller can actually sink enough current to keep the strip running without destroying itself, but I certainly wouldn't suggest trying to operate it this way.
|Images from Adafruit.|
After seeing this youtube video of a project called Sound Puddle, I was interested in creating a similar lighting system.
Around the same time Hackerbot Labs purchased a bulk order of addressable RGB LED strip, which seems to be the same model as this one carried by Adafruit. These strips use something like a LPD8806 chip to drive PWM to two LEDs at a time. The strip is marked with white lines every couple inches, where it can be cut to size using a pair of scissors.
Controlling these strips is kind of quirky. LPD8806 chips are actually FILO memory devices, each LED has an associated 3 bytes of memory but the MSB is reserved for chip reset, each channel has 7-bit PWM and data is latched asynchronously. You can get an idea of what's going on if you read the comments at the top of the arduino library file. Due to the chip's FILO nature, all the data to be sent onto the string must be held in memory and can't be generated on the fly and pushed down the line.
The board I designed (available on github) has an Atmega168 with a small microphone and a breakout to the SPI lines. It comes to just under 1.5x4cm which is the same width as the led strip. I'm planning on eventually wrapping the entire thing in heatshrink (the LED strip itself is waterproofed in plastic) and installing it in my shower. Alternatively, the board could be wired up to multiple strips and used in the same way as in the Sound Puddle demo. I'll post some pictures and video of it working once I program it.
Continued from my last post, the serial interface for the antenna rotator is now up on github.
The RX line on the serial header passes through a simple inverting level-shifter using an NPN transistor and a handful of resistors. This line also has a TVS diode tied to ground to protect it from electrostatic discharge or whatever might befall it during use.
The heart of the interface is an Attiny13 microcontroller which handles receiving and transmitting commands. The microcontroller's tiny and cheap and doesn't actually have a hardware UART interface, but its possible to use the USI system (Atmel's name for SPI) for half-duplex UART communication. According to Atmel's appnote on the subject the USI system should first be inactive and a pin interrupt should be used to detect the start bit condition. The interrupt service routine should then enable the USI system and switch its clocksource from the normal slave-clk pin to an internal timer calibrated to run at the same speed as the as the serial data being sent from the computer. Once all 8 bits and the stop condition have been received the USI system switches back off.
From there its just a simple process of matching up the received ASCII character to a table of commands. One pin on the microcontroller is connected to the control box's IR RX line (the actual IR receiver must be removed to prevent shorting) and data is sent across to the microcontroller inside the control box.
It should be noted that IR transmissions are usually sent on a modulated carrier (frequently 28kHz) and the overall waveform looks like a square wave made up of smaller square waves. The IR receiver is tuned to this specific carrier frequency, which prevents natural infrared radiation from interfering with the control signals. The signal that emerges from the IR receiver is stripped of this carrier frequency and looks like a normal square wave containing the binary data being sent to the receiver (usually a few address bits and a few data bits). By bypassing the IR receiver, my microcontroller will be able to send data without having to generate and modulate a carrier frequency.
The actual code that I'll be flashing to the Attiny hasn't been fully written yet. Until I know exactly what data is being transmitted by the remote control it won't make sense to try designing the program. In my next instalment I'll be probing the IR transmissions coming from the remote and coding the firmware to send commands to the control box.
I'm doing work with one of my professors on an automated antenna test platform. We imagine our setup will work as such:
- WiFi router with antenna will be mounted to a general purpose antenna rotator.
- Computer with wifi card will run labview program/etc, map signal strength while rotating antenna.
Unfortunately the antenna rotator we got our hands on has a design out of the 1940's, the rotor base with antenna attachment and the control box have identical motors inside them. Moving the dial on the control box causes both motors to run until a relay is tripped in the control box. The assumption is that identical models of motors will run at the same speed, so dial position on the control box will accurately reflect the positioning of the rotor base. This is of course not how it works in practice, the error between the two builds up quickly and the control box has a feature to resync them (by rotating full left, followed by full right, not a smart device, just mechanical relays).
It turns out that all antenna rotators work like this, in order to remain backwards compatible. Even the newer control box we got our hands on (a Channel Master 9537A Antenna Rotor with an IR remote) was still just an open-loop DC motor driver. It'll have to do.
My current plan is to replace the control box's IR interface with a serial one. The first step is to reverse-engineer the remote control's protocol. This of course started with a google search to see if anyone had already done it. Success! I think. Here's what I found courtesy of Daniel Tonks. They have some sort of fancy universal remote that learned the IR codes of the device and the settings were uploaded to the internet. Here's what I extracted using the software Philips provided:
Each command was prefixed with an identical header: 900A 006D 0000 0001 AC53
Something about this just doesn't sit right with me; its partially that I don't know exactly what these numbers represent (I assume binary data being transmitted) and its also that I've never heard of any IR protocol that would use anywhere near 12 bytes of data per command. I'll have to attach the remote's IR LED to a logic probe and check this for sanity.
In the meantime I'll have to work on the interface circuitry, as it will be the same regardless of what the commands will look like. I'm planning on building a tiny board with a serial header and a microcontroller. I'll remove the IR receiver on the controller and replace it with a signal coming from my board. As long as I sent the right code at the right speed it should perfectly emulate an IR signal.
I was recently pointed to something called LumiLor from Darkside Scientific, which seems to be offering some kind of flexible contoured electroluminescent paint, basically flexible EL-wire that can cling to any surface or be any shape. (See this youtube video for a demonstration.)
EL-wire is made up of phosphors stuck inside a small capacitor which glows in the presence of an altering electric field (Jerie Ellsworth gives a good explanation here, in a youtube video explaining how to create your own wire at home.)
It turns out my theory on how LuminLor works is probably correct, as this other video from Ellsworth shows. The "stack up" as she refers to it, is a five layer silkscreen process, but in the case of LuminLor I believe it is a spray or paint application.
|Image from astounde/Darkside Scientific|
- You start with a base coat of a conductive material which acts as one plate of a capacitor. It can be either transparent or opaque; they seem to use a transparent layer because it allows you to also see a non-luminescent paintjob under whatever they're painting.
- Next a transparent insulating layer is laid down, probably a clear varnish.
- On top of that goes the phosphor layer, probably one of the inks available from Dupont. They might also be using a hydrographic process to put patterns of phosphor onto objects.
- A transparent conductive layer is laid down either after or along with the phosphor layer, completing the capacitor.
- Finally another layer of transparent varnish is laid down to insulate the whole thing and prevent shorts and shocks to the end user.
During the process, flexible electrodes are attached to the conductive layers, which are later hooked up to an EL power supply. (~120V AC @ 60-200kHz or so.)
The current mystery is how to get ahold of the phosphor ink, Dupont seems to have a website mentioning it but does not actively sell it. They do have a nifty pdf document describing some of the process used. They have several different recommendations for the build sequence, with the phosphor layer either inside the capacitor or on top of it.
Ellsworth provided a link to some students selling small amounts of the ink, but they're currently out of stock.
This blog is powered by ikiwiki.