A cloud so personal, it senselessly gathers your intimate details that it doesn’t need.
I tried this combination over the weekend: hot chocolate and chocolate flavored caffeinated marshmallows. The marshmallows had a couple of spots with a candy like flavor that they lack when eaten without hot chocolate, but otherwise the combination worked very well. I suppose marshmallows without a chocolate flavor would work, too, but these caffeinated ones don’t come it that flavor.
A while ago, I got I2C repeated starts and SMBus support to work from the Linux kernel on a Raspberry Pi. I recently built a new 3.10.25 kernel from the foundation’s kernel fork on Github and updated my own fork of their fork with just the I2C update in a new branch. In the process, I managed to misuse git so that commits now attempt to go to the Raspberry Pi Foundation’s kernel fork rather than my own. I tested the module on the copy of Raspbian that I have. It is running the 3.10.24 kernel, but is quite happy with the new kernel module (or for 3.10.37, or 3.12.24) and my MLX90614 test program. I also built the kernel module for the BMP085, but it looks like that requires more than just a kernel module file to get it working. No big deal for me; I’ll just replace the whole kernel. I just wanted to see if I could make it really easy for someone else.
To use the updated I2C module, first download it. The file will need to replace the one in /lib/modules/<kernel version>/kernel/drivers/i2c/busses. You may want to keep a copy of what is already there. After copying it, check to see if the i2c-bcm2708 module is loaded. If not, load it up and have fun! If it is, you can either reboot or unload the i2c-bcm2708 kernel module. Before unloading will work, any dependent modules must first be unloaded. It wasn’t loaded for me right after boot, so it hopefully won’t be any trouble.
Update: I finally got the code up on Github. I hope the kernel module has been working out for anyone who has tried it. Please do leave a comment about any success or failures with it. I have yet to get any feedback, so I only have my own test case to claim that it works.
It is good to have diffuse light for soft shadows. To that end, when I can’t aim the flash at a ceiling I use LumiQuest softtboxes because they aren’t super pricey (although there are cheap competitors from beyond the USA now), and they are very portable. This isn’t an advertisement for the product, though; I’m not getting paid. Instead, this is about an investigation I did into how to get the best results from the LumiQuest’s Softbox and Softbox LTp.
I got the LTp to help with some Thanksgiving dinner pictures of Lego minifigures. It is almost too large for something attached to a flash, and it did take a few tries to keep it from falling off. It was facing downward to be an overhead light, but that made falling extra easy.
I wanted the light to be as even as possible, so I used the pull-out light scattering lens of the flash. This put the flash’s zoom head into its 14mm setting, which is really just the 24mm setting with the lens applied. The lens is made of some plastic like material and absorbs some light, which was also helpful because otherwise the flash was too bright. The flash in question here is the Yongnuo YN568EX II, which is working out quite well for me, but that could be the topic of another post.
Afterwards, I wanted to investigate what works best with the LTp to make the softest shadows. It makes sense that the light will need to be uniformly bright across the light scattering surface of the softbox for the best results. I took pictures of the LTp with different flash zoom and power settings to get an idea of the uniformity. The exposure was the same for all pictures (f/16, 1/125sec, ISO 100). The resulting test is not indicative of overall brightness because most of the images have over-exposed areas. They do, however, clearly show that the 14mm flash zoom setting does provide the most uniform light over the surface provided by the LTp softbox. The 24mm setting isn’t much worse, but the 105mm setting looks like it should make the LTp perform the same as a much smaller softbox.
Next, I decided to see what effect this has on the quality of shadows. I put a cardboard tube on frosted glass so that I could photograph the shadow on the glass, and because I had the glass already setup. I later discovered that the shadow on the glass was sometimes filled in with light from the flash reflecting from other surfaces in the room which obscured what the shadow would have been with light only directly from the softbox. The test images also had a shadow cast by the tube onto itself, which turned out to be mostly immune to the problem. It made for small test images, but I think they worked out well.
For a more complete test, I also tried my old LumiQuest Softbox (the one with a notch in what otherwise would be a rectangular light scattering surface), a bare flash, and a misused Sto-Fen Omni-Bounce. I varied the flash power, but not the exposure (f/4, 1/160sec, ISO 100) or distance between the flash and tube (about 740mm, or 29 inches). In all cases, the 14mm setting required quadrupling the flash power and the modifiers required doubling it. The bare flash at 24mm used 1/32 flash power. The 105mm flash zoom setting required changing flash power, but it wasn’t so consistent.
The results show that the LTp softbox responds more to the flash zoom setting than the other LumiQuest softbox I have. The LTp improves with the 14mm setting over the 24mm, but the loss of light from the flash’s scattering lens will sometimes make 14mm too dim. Other flashes may fare better, but I think most will be similar if they don’t use a glass scattering lens. Using the LTp with the 105mm setting makes it about as good as the non-LTp softbox at 14mm or 24mm.
The LumiQuest Softbox (non-LTp) produces shadows with a negligible difference with the 14mm and 24mm zoom settings, but does get worse at 105mm. The bare flash gives the expected shadows with hard edges, but it does seem to be very slightly softer at 105mm. This suggests the zooming action changes the uniformity of the brightness across the flash head.
Finally, I tried a Sto-Fen Omni-Bounce pointed directly at the tube. The Omni-Bounce is a light scattering device that doesn’t add much surface area like a softbox does. This makes it half of a light diffuser. The other half is supposed to be the ceiling and walls of the surrounding room. The little card included with the Omni-Bounce states that it should be pointed at the ceiling and not the subject. This test shows why. I have seen some people misuse their Omni-Bounce by pointing it directly at their subject while inside a convention center with high black ceilings, but that just results in wasting flash power.
I’ve been using a stack of CD-R’s as the background for several images of Lego minifigures. The CD-R’s are lit by flashlight (a silver Hexbright). In front of the flashlight is a color filter and a light scattering filter, both really intended to be used with a flash. The position of the CD-R’s and the two Star Wars minifigs in front are unchanged from the recent photo “Don’t let this happen to you”. The examples shown here all use the same color filter, but I also used violet and red-ish ones, as well as none at all.
The background result is affected by the relative position and orientation of the flashlight, CD-R stack, and camera. This makes using a flash in place of the flashlight really difficult. Also, I usually had the Hexbright at a low brightness setting, so it really was flashing, but it bothered the camera more than me. All of these positions and orientations provide lots of variables to play with to make a number of interesting effects for colorful abstract out-of-focus backgrounds.
Some of the light going through the CD-R’s makes nice vertical columns of highlights. There are four of these columns: one on either side of the central spindle pillar thingy (I don’t know what that is called), and two further away that seem to be reflections of the first two. Getting all four in the same picture is nearly impossible, but two is pretty easy and three isn’t difficult. Some prism-like effects are visible in those highlights, and the CD-R’s colors the light a bit green. I’ve got two or three bands of CD-R’s in the stack, so the exact shade of green varies a bit. I also looked at some DVD-R’s, but they are a boring white. I think I’ve got older ones that’ll color the light a bit red, but I haven’t tried.
With this setup, horizontal bands over a limited vertical distance can be shown where the light passes between the disks. As a result, these bands are not colored by the CD-R’s. They are visible just under Iron Man’s left arm in “Looking for trouble”. The light also reflects between the surfaces of adjacent disks; this seems to create an odd pattern that can result in curved swirly lines that are more easily seen by a camera than eyes. The curvy swirlies are seen in “Mom, I can see straight” to the left of the minifig. Some placements of the camera versus the CD-R stack avoid this effect and have clear horizontal lines with beveled edges as seen near the minifig in “An explorer in a strange place”.
With the help of a light in front of the CD-R’s (I used an on-camera flash pointed at the ceiling and nearby wall), a single vertical column of reflected light can also be put in the background. The reflection highlights look distinctly different from the highlights of light passing through the CD-R’s. Instead of aperture shaped highlights, they have horizontal bands that seem to be sections of the aperture shape. Since this light comes from a different source, it is a simple matter to make it a different color. This shows up in “Looking for trouble” with Lego Iron Man (sans iron). I used a CTO filter on the flash attached to the camera to help make the helmet look more golden, and it shows up reflecting off the CD-R’s.
What I’m most fascinated by are some horizontal bands in my picture “This guy” (lower middle of frame next to the minifig; not visible in the little thumby here, best seen after taking the link and viewing the image full size). Even though the stack is well out of focus, there are a number of thin bands. I’m guessing that the banding of horizontal disks caused similar banding in the out-of-focus light which can be made into thin lines by how the light from different bands are superimposed on each other.
The top of the desk is glass, so I usually have a flash under it. The effect works a lot better than some of the scenes of the evil Kirk in “The Enemy Within”. It also helped tremendously with my “Looking for trouble” picture; one flash lit the face and the other lit the helmet.
I also made a video to show how the background can change, but it really doesn’t give a full demonstration.
There is a nice post on the Adafruit blog about the networks of stuff. It features this wonderful picture:
A very happy looking cloud is grabbing everything in sight. It seems like the artist tried to think of the most harmless thing; something that could never possibly destroy us. The post is a short summary of a way to tame the puft cloud put forth by Limor Fried. There is also a Google+ page for it. The basic notion is to keep things open so that what is collected is known and how it is used can be limited and controlled by users. Given how companies love to keep everything proprietary, we may be doomed. But, maybe after a few more incidents like the Samsung Smartly-taking-away-your-privacy-through-security-flaws TV, companies might finally get the idea when users demand security they can verify. If no one outside the originating company can verify their device’s security, it is only a short matter of time until someone outside that company verifies the device’s lack of security. Such lacking security of a device used in the presumed privacy of one’s home is a problem most people would rather not have, but a few will want to profit from.
Update: If you just want a kernel module for something close to kernel version 3.10.25, look here.
I’m working on a project that uses the Raspberry Pi and various sensors. One sensor is a MLX90614 IR thermometer; this communicates using SMBus. One of my goals is to avoid making the project specific to the target hardware, the hardware that actually runs my code. I want the code that communicates with the sensors to be Linux specific but not Raspberry Pi specific.
One of the problems a lot of people have had with the Raspberry Pi is with getting SMBus communication to work. SMBus is built on I2C, a way of managing serial communication between many devices with only two wires: clock and data. I2C is more flexible, while SMBus is made to be more reliable. As part of guaranteeing reliability, mostly in a multi-master setup, SMBus requires the use of I2C’s repeated starts for read operations. The I2C master driver for Linux on the Raspberry Pi does not support this, and I have been unable to find a patch or custom version anywhere that adds support. Most people have solved the problem by using code that directly interfaces with the Raspberry Pi’s hardware, ignoring the Linux kernel support altogether. This solution not only fails to meet my goal of avoiding code specific to the target hardware, it also won’t work well if more than one process on the same host attempts to use the I2c master hardware.
I decided to solve the problem by modifying the Linux kernel’s support for the I2C master of the Raspberry Pi. I succeeded. My implementation may not be the best or bug free (works for me is a weak guarantee), but it does allow for communication with a MLX90614 using the user-space (unprivileged code outside the kernel) SMBus interface provided by Linux. Since examples with SMBus are more difficult to find than I2C, here is my test code. I also tested with a BMP085 sensor using the support for it already in Linux. This sensor uses I2C rather than SMBus, and it also functions correctly. It doesn’t need a repeated start, but it gets one anyway.
To avoid causing extra trouble, I implemented repeated starts for a subset of conditions under which they could be valid. I focused on SMBus communication. With I2C, a slew of messages going back and forth can be requested, all with repeated starts, but this isn’t normally done or required. Also, the hardware requires that once the first message has begun transmission, the second message be setup in the registers ahead of the stop condition. To make matters worse, there is no interrupt condition for this, so polling in a busy wait is required. I stuck all this inside the bcm2708_i2c_master_xfer() function of i2c-bcm2708.c so it isn’t in the interrupt handler. After the second message is configured, the interrupt handler is used to receive the data. That avoids additional polling at the cost of not allowing additional repeated starts.
If you’d rather see the kernel change in source control, I stuck it on Github. It is a 3.6.11 kernel, but not the latest revision out there. I’m still using it for now. There is no kernel or kernel module for download here because I’m running Gentoo on my Raspberry Pi and I build my own kernels. If I gave you my kernel, you may well find that something doesn’t work anymore.
A lot of hobbyists are using Sainsmart relay boards with their projects because the boards cost less than buying the relays, or come really close. The boards include circuits to drive the relay coils so that a typical logic output can be connected directly to the board. Each driver circuit uses an optocoupler so that the driver and the coils only share a ground potential. This is a great scheme to allow the driver to work at a different voltage than the relay coils, but the board was intended for use with 5 volt supplies for both. The drivers start to work reliably from around 3.8V up to 5.5V or so. The result doesn’t work well with a 3.3V supply for the drivers operated by 3.3V logic; some relays will function, and others won’t. The solution is to give the drivers a 5V supply, but then the floating driver inputs should rise to 5V; the drivers are connected the positive supply, and are two LEDs and a resistor in series that connect to an input pin. A common solution to using 3.3V logic with the Sainsmart board is to add another driver circuit to drive the driver circuit on the board. I thought that was annoying and sounded rather silly, so I investigated further and found a simpler method.
I started by hooking up 5V supplies to the board and measuring the voltage of one of the driver inputs when left floating. This setup is in the picture; channel 1 (left) is measuring the voltage on a driver input, and channel 2 (right) is measuring the 5V supply. The first results showed a drop of about 2.2V from the driver’s supply. This occurs even when the only wire connected to the board, besides the measuring probe, is the positive power end, VCC, to the drivers. This voltage drop is made possible by the current passing through the probe; connect the probe’s reference potential to the board’s VCC instead of ground, and the voltage measured is zero.
I measured using a 1MΩ probe. With the supply voltage measured at just over 4.8V, I get 2.5V on an otherwise disconnected driver input. The current flowing through the driver is adequate for the LED to make a very dim light. By switching the probe to 10MΩ (as pictured), the voltage measured is over 0.27V, meaning the voltage on the input is 2.7V.
This indicates that a small current is all that is needed to keep the drivers below 3.3V when using a 5V supply. Connecting a 3.3V logic output directly to one of the board’s driver circuits should work just fine without adding an additional driver circuit. In many cases, though, some 3.3V processor is used and its general purpose I/O lines are initialized as inputs after a reset. Clamping diodes are often present and can probably handle the small current through the relay board’s drivers trying to pull the line to 5V. Adding a 10MΩ resistor to ground should save the clamping diodes from any work, while connecting it to the 3.3V supply should work almost as well while eating even less power. The small current draw of the input might actually take care of the problem, but I lack any measuring equipment that can confirm this without drawing the small current that will take care of the problem.
I’ve been asked to post a circuit diagram for the solution I mention above, so here it is. I threw it together in Inkscape even though I don’t really know how to use Inkscape. The circuit will work for the Sainsmart relay boards like the one I tested when the drivers on the board are given a 4V to 5V power source.
I’ve been out of a car since someone rammed mine about a month ago. On two occasions thus far, I have rented a car from a local Enterprise office so that I could get a few things done, like buy a lot of groceries or obtain a copy of the police report about the collision. The people at the Enterprise office/location have been great, and seem to handle the stress of being very busy quite well. I’m surprised just how busy it is since the place isn’t located next to an airport.
The second rental I got was a Toyota Corolla. All the keys were bound together with a steel cable along with a tag showing the replacement cost. I can understand the rental company wanting to impress upon its customers that losing keys is a bad thing, but the steel cable isn’t helping. With all the keys bound together, that means if one key is lost, all the keys are lost. This will make life more difficult for a customer who loses the keys, and will increase the replacement cost. Further, it makes giving more than one driver access to the car less convenient since two people can’t each have a key simultaneously.
Most ridiculously and silly, though, is the inclusion of the valet key next to the regular full-function keys.
This bit of absurdity really has nothing to do with the local rental office. I’m sure it’s just company policy.
I found myself recently contemplating what I would do if I found myself on the Enterprise-D from Star Trek.
First, I would find the holodeck and destroy it before it could destroy me. That thing is way too dangerous. Where was the months long, if not years long, investigation into what went wrong the first time someone was hurt in there? After it managed to take control of the ship, why weren’t these things removed immediately from the entire fleet? I’m not going to take any chances; I won’t even step inside that room. I can use one of those phaser thingys to scar the walls while standing outside after I wreck the power supply and control system.
Second, I would install fuses and circuit breakers. It seems like every time something slams into the Enterprise, nasty dangerous sparks fly out of exposed cabling. The crew members doing damage control have enough to worry about without sparks igniting something. It shows up on lots of fiction shows set in space in the future. I guess we’re supposed to think that people will forget how to make fuses or how to use circuit breakers because sparks get safer, but hat doesn’t make any sense.
For that matter, why are there so many wires that can fall down from the ceiling of the bridge? Didn’t they network together everything? They ought to be able to send plenty of data on a single cable, and I bet some things don’t even need much bandwidth. That leaves power. How much power do they need in the ceiling? Do they have 50kW stage lighting?
Oh, that’s right. It is stage lighting because it’s a stage. That makes the Enterprise-D much less exciting, but still not bad. In that case, I’d bring my camera.