Sunday, June 21, 2015

Solar Monitor V1

The goal: Understand how much power a solar panel actually makes.

The most straightforward way to measure DC power is to give your source a resistive load and measure voltage across it. Power = Voltage^2 / Resistance.

Challenges we face: The problem with solar panels is that they can't be approximated as constant-voltage or constant-current. So just one resistor isn't enough. Further, I don't want to have to run power or networking outside. So whatever device does this measuring it needs to itself run off of the solar power and either save that information or convey it wirelessly.

Solution: First, let's use an 'Arduino Yun'. This is an arduino printed on the same PC board as a linux machine with the serial connection and software already made between them. So the linux machine can do the networking side of it while the arduino can do the more typical microcontroller functions; turning the resistors on and off and measuring their voltage.

For power, we can use voltage regulators 7812 and 7805 to bring the 38V of the solar panel down to 12V where a battery will store it and then down to 5V where the arduino will consume it. With a large battery, it should have no problem lasting the night even in the low-light winter.

We also want monitoring, manual control, and safeguards.

Monitoring: For monitoring, I'll put an LED on the power coming in from the solar panel, and then one on each of the resistor networks to see if they get pulled low.

Manual control: For manual control, let's add three light switches (because they're cheap) to turn on overall power from the solar panel, power from the battery to the microcontroller, and then turning on or off the monitoring LEDs. Having LED control lets me turn them off when they'd otherwise be sapping power. Having two levels of power control let me boot the microcontroller only if I want to debug, or boot it first to get around uncertainty in startup, or not boot if the battery is dead, etc.

Safeguards: The resistors could take as much as 260W at peak but I don't want to buy and don't need a 300W resistor because I'll only be pulsing that power on for a moment to take a reading. Then it will have plenty of time to cool down. Unless something breaks... if power does stay on while the resistor is turned on, it could heat up, burn, and short out other parts. So I'll put in fuses in a few key parts to make sure if it does go melty it doesn't stay melty. I could also have a secondary system montor heat, but the complexity of the machine increases dramatically if I do that.

Results

It had two problems: First, it doesn't have enough grainularity of load. At full sunlight with 2ohms it did 16V and about 124W. But then at 8ohms it did 28V and about 100W. It should have been doing at least 200W and perhaps it would have been had it been at the ideal voltage of 24V. Perhaps solar cells have a much tighter wattage curve than I knew.

Second, it melted itself. Something bad happened and the 2ohm resistor must have stayed on. It was on until it melted the acrylic holding it in place, charred part of it's outer surface and eventually internally ruptured it's connection thus ending the short.

So the data was not good enough and the device was damaged. Need a new plan. :)

Sunday, March 1, 2015

The Inconvenient Message Detection (IMD) prototype is done

Github URL, how to use it is in the ReadMe: https://github.com/DickingAround/InconvenientMessageDetection

The problem:

Who talks to who and who uses encryption is obvious to a mass-observer (e.g. the NSA). Large encryption keys and encrypted data are hard to hide. This leaves the meta-data of communication open for observation. It also leaves people using encryption vulnerable to coercion; an individual in power could demand they decrypt their communications.

The goals:

  • Obscure who talks to who without requiring broad adoption of a new technology.
  • Increase the cost of mass-observation.

Two communicating parties have to transmit something. The smallest message that can be transmitted is a single bit; 'there is a secret'. If it is reasonable to transmit this datum through insinuation, pre-determination, or other meat-space methods, then the meta-data of the communication is hidden.

The solution we've made:

Steganography that requires computing effort. Steganography is the idea of hiding data in the unimportant bits of an image. This is an old idea. The new twist is that with 'Inconvenient Message Detection' (IMD) that data can only be found if the decoder does an amount of computational work that's decided by the encoder.

Let's look at how this solved our problem: If some people use IMD, it makes every image suspect. When a mass-observer wants to see what communication is going on, they must use compute power to check every image. Furthermore, because the compute effort needed to find an image is set by the encoder, it is uncertain to the mass-observer; they never knows for certain if they've worked hard enough. By contrast, the intended recipient of a message presumably got the single datum that a message exists in some public image and will put in as much compute effort as is needed to find the data in that single image. Having every image on the internet be a potential carrier of secrets makes the mass observation of communication meta-data expensive and uncertain.

Furthermore, even a individual under direct observation can increase their protection with IMD. An individual may own thousands of images of which only one contains an secret. Until the secret is found by an observer, the individual has plausible denyability of the secret's existence. The observer may even give up before spending the necessary compute effort to find it. This increases their resistance to coercion.

The current program is only a prototype. I am a competent engineer, but not professional in security, encryption, or steganography. I am more than open to advice and help. (And here's thanks to all those who have already helped craft and refine this idea and implementation so far.)

How does it work, at a high level:

Obfuscation:

  1. The image is hashed to create a number. That number is used to encrypt the file to be obfuscated. This encryption is only done to assure the bits of the file are evenly distributes between 0 and 1, it provides no other protection.
  2. The image is hashed to create another number. That number is hashed a certain number of times as specified by the user. The result is used to seed a pseudo-random number generator.
  3. The pseudo-random number generator is then used to decide where to put the 1s and 0s of the file into the image.
  4. For each bit, there is a check to see if the pixel being changed will give away that the file exists (e.g. a '1' in a field of '0' saturated color). This check also makes sure we haven't changed the results of previous checks or written to this pixel twice.

De-obfuscation:

  1. Same as encryption step 1.
  2. Similar to step 2 except that after each hash, the image is checked to see if there is a file in it. This is continued until it finds a file or a the user stops it.
  3. Same as encryption step 2.

FAQ:

Q: Can anyone read a message hidden with IMD?

A: Yes. IMD only obscures the existence of the message. Feel free to also use encryption to make sure only the intended recipient can read the message if it is discovered.

Q: How are you making it difficult to detect changes in the image?

A: I have a basic algorithm to avoid changes that would be blatant giveaways. This algorithm also serves to show where/how a better algorithm would be implemented (it's tricky to check a pixel and than conditionally change it). The basic algorithm checks for pixels which already are or are near saturated so as to avoid them. Also, pixels that are near others with the same value are not used. I assume there are better algorithms here, but I have not had time to research it.

Q: What about image meta-data? Often images have meta-data about the camera that took them. Is this disturbed? Does it give away the existence of a message?

A: No idea. This is the #1 feature on the list for a V2 of this program.

Q: What about lossy image formats like JPEG? Isn't that the most common image on the internet?

A: Yes, but it's harder to work with. In talking to a steganography expert, I gather it should be possible to store this data in the way JPEGs or other lossy formats are encoded since they are not deterministic. But it's harder so I haven't done it yet. That work would be very valuable. If you would be willing to to that work, please don't hesitate to contact me.

Q: Why are you using python's 'random' library? It's well known that this should not be used for encryption.

A: Most encryption wants/needs a random number generator, not a pseudo-random number generator. For example, os.urandom is a source of as random as possible. We don't want real random. We want a pseudo-random number generator; a random number generator that can be seeded.

In practice the 'random' library in python is an MT19937 with a period of 2^19937 which is to say it is highly impractical/impossible to parallel-test every one of those 2^19937 possible starting positions. Thus, the library works fine for how IMD uses it.

That said, feel free to swap it out for another for your own use.

Q: Why use AES to encrypt the message before encoding it?

A: I picked a symmetric encryption algorithm at random. It's only real job is to even the distribution of bits in the secret file such that there's no pattern of more '1's or '0's in the image.

Feel free to swap it out for another for your own use.

Github URL, how to use it is in the ReadMe: https://github.com/DickingAround/InconvenientMessageDetection

Ladder to the roof is done

The roof providers 1000 more sq feet of space on our house. It was designed to hold people, plants, a hottub, etc. But there's no way to get to it.

So I built a ladder. It's welded out of 304 stainless steel using 316 stainless wire in the welds. So there's no need to paint or prevent rusting. Though it is 17' tall (tall ceilings) we estimate it only weighs about 70lbs. We actually hoisted it by hand to the second level, using people roped in to the railings and lifting. My friends are good sports. :)

Saturday, July 5, 2014

Hydro electric power for a house

Question: I have a hill in a rainy part of the world, can I build my own mini-hydro-electric plant?

We get about 40 inches per year and I have a roof about 40' by 20' that will be about 50' in the air. That works out to 2,667 cubic feet of water ever year.

Potential energy is E = M * H * 9.8 N/kg. We have 75.5 cubic meters of water at 15.24 meters of height. That works out to 11.3E6 joules. That's 3,130 watt hours. Even at a 100% efficiency I'd only get 3kWhrs per year.

Which is really unfortunate because it would have been fun to runs some pipes and I could have easily 3D printed a little hyro engine.

Monday, June 16, 2014

My house has too many fucking railings

My house is essentially done now. Little thanks to me. But I did have to build the railings. Or at least I chose to. Because I'm both a cheap skate and dumb ass. Here are some random pictures of that.

But what are random pictures without random stats?

  • 7.8 ft of 1/4" holes drilled
  • 116 square inches (0.81 square feet) of steel cuts on the saw
  • 65 ft of welding
  • 13 1/4" drill bits destroyed
  • 6 band saw blades destroyed
  • ~70 cubic feet of argon lost
  • 2,394 individual acts of machining (not including installation)

Sunday, May 11, 2014

Experiment: How much light penetrates a welding helmet?

Summary

Problem: How much light does a welding helmet block? They come in shades like '9' or '12' but the only documentation I can find defines what jobs to use what shade on. It never seems to say what the shades mean.

Conclusion: A basic 'shade 10' welding glass will block all but one part in 20,000 of low-frequency light.

A given shade number seems to allow 1/3 the light of one shade below it. So, for example, a shade 10 will allow 1/3 the light of a shade 9. Also, a shade 8 will allow 3x the light of a shade 9. A 'shade 1' appears to be equivalent to 'no shade'.

This appears to hold true only for light of wavelength green or longer. When viewing blue laser light we anecdotally saw the light appeared much dimmer than viewing green laser light of the same non-shaded intensity.

The experiment

Big thanks to Woody and Erin for helping design and do this experiment.


Original data:

Setup: We measured the shades of a Hobart welding helmet with a variable shade and a regular no-brand set-shade welding helmet. We used a LX1010B light meter inside the helmet, with cloth packed around it to shield light. Without any of the lights on, the sensor read '0' on it's most sensitive setting.

For each measurement, we took one of two flashlights and shone them through the helmet and centered on the light meter sensor. We also shone them directly on the sensor to get a no-shade measurement. For the variable-shade welding helmet we also needed to use an extra flashlight to activate the shade (normally it stays low-shade in order to allow the welder to see before they start welding and then changes it's shade when welding begins; it uses a light sensor on a different part of the face of the helmet to do this.)

We were only able to take a few measurements but they're a highly linear pattern, consistent from one light to the next, and the measurements from the variable-shade helmet closely matched the static-shade-of-10 helmet.


Results

The relationship between lux and shade looks very linear when the lux is plotted on the log scale. At a glance, it's about 1/3 the lux for every additional 1 of shade.


What's most interesting is if we assume this 1/3rd relationship going back down the shade levels, we predict that we'll see about the same as the 'unshaded' lux measurement when we reach shade level 1. This makes sense and reinforces that we've done the measurement at least approximately correctly since I can imagine an engineer/scientist choosing the shade level 0 or level 1 to be the unshaded level.

Sunday, April 20, 2014

AIWorld6: The Tree Of Life

The Mechanics

I almost want to get immediately sentimental. But let's for a moment talk about how this tree of life was created and thus how to read it.

To explain how this is build, let's talk about what happens with a single creature. This creature will have a number that represents their species. When the creature replicates, their offspring will have a number that's either +1 or -1 from their parent's number. Using this simple scheme, over many generations different species will have numbers that drift away from each other.

By chance there will also be a lot of cross over of the numbers as species' numbers wander. To fix this I bias the probability of picking -1 or +1 based on where the other creatures are. So for example if there are 1000 creatures with the number 40 and this creature has the number 41, their offspring will likely get a +1 and be 42. This has the effect of spreading out the numbers.

Next I want to use these species numbers to see which creatures are which on the map. So I assign that number to a color. On a 0 to 255, RGB color scale I get to have 1530 different full-brightness colors; so I'll just mod the number of the species with 1530 and plot it on the color scale.

Now I have colors that represent species. How to build the tree? Every X turns I can take a census of what species there are and plot a single line where the intensity is proportional to the percentage of the population with that color. Stacking those slices on each other for tens of millions of turns gives us the full and complete tree of life.

The meaning

Now for the fun part. More accurately, now for the amazing part.

At a high level, it's the first time I've ever seen every single species ever in the tree of life. No stumpy branch or leaf in this tree is left un-turned. We don't have to rely on some spotty fossil record that we piece together by comparing physical structures. We don't even have to parse the DNA. We have a tree of life based on real heritage data. And crazier yet, this is a tree of life playing out just like all our evidence said ours did. Right in front of our eyes in a repeatable way.

Look at the long stretch of yellow and orange. Notice how the yellow is longer lived (ave age ~5000 turns vs less than 1000 turns for orange) and branching less often because replication rates are slower. If we look at the real-time video of the world we can actually see yellow being killed off by the more aggressive pink who are themselves overtaken by the more stable red species.

Look at the times when a branch fans out and then suddenly tightens. That's a small set of individuals or even a single individual which turned out to be more fit than the others and out-competed them. That property alone is what keeps the lines of the species from drifting farther from each other.

I built this system with the intention of building true causational (not correlational) studies of life. The first step of that is getting life. This looks a lot like life to me. Maybe not life just like ours. Maybe without temperature-based homeostasis and carbon. But are we so sure that's the right definition of 'life'? :)