We had family visiting at the weekend and decided to take a day trip to Whitby to see the open air Dracula Play at Whitby Abbey. We had been before and, remembering how entertaining it was, knew they would enjoy it too! The play is performed in the grounds of the abbey by three very talented actors who really know how to entertain a crowd. The audience follow the actors around the grounds between scenes, and there’s a lot of audience participation. It’s played for laughs, and I won’t spoil the jokes here… but it’s great fun and I highly recommend it if you ever get the opportunity to see it!
Whenever in Helmsley, we like to visit the Walled Garden, which is always impressive – a real labour of love. Photographs never do it justice, but here we go:
That’s the remains of Helmsley Castle in the background, an English Heritage property, also well worth a visit. I even managed to find a decent Espresso in The Sugared Butterfly there.
This post compares the light output of two single-chip DLP projectors, running in 2D and 3D mode. These tests were prompted by a perceived reduction in brightness with the EH505 operating in 3D mode.
The projectors were set up in front-projection with 2.5m image width, and room lighting was turned off. The source was HDMI, displaying pure white full frame. For each light measurement, a central area of 200×200 pixels was scanned with an LX1330B lux meter in peak hold mode.
The EH505 projector offers 1920×1200 native resolution in 2D mode, and was tested here at the native resolution, at a custom 3D resolution, and at lower resolution for direct comparison with TX785 (an older model with 1024×768 native resolution). According to the manufacturer, both models are 5000 lumens.
For the EH505, the lamp brightness mode was BRIGHT, the lamp was at about 12 hours life, and firmware version was M01. The 3D mode used for the EH505 was VESA 3D and manually set to Frame Sequential. For the TX785, the 3D mode was set to IR Mode (i.e. DLP-Link mode disabled). Great care was taken to select appropriate settings for all parameters to permit meaningful comparison (there are too many to list here).
For the purposes of the 3D tests, the Full 3D HD 24Hz modes of the EH505 were not used, in preference for true frame sequential active stereo at over 100Hz native input frequency.
Here’s a summary of the results:
Calculating relative Lumens from Lux and screen area, it appears that the EH505 is about 37% dimmer than the TX785 in 3D mode and about 31% dimmer in 2D mode (these figures are based on a 3.91m² screen area for EH505 and 4.69m² for TX785). In mitigation, the EH505 is of course considerably higher resolution than the TX785. It’s also worth noting that these measurements were only carried out on a single projector.
The completed PCB arrived from Ragworm on Saturday, and I’m quite pleased with the end result. The board arrived vacuum packed into bubble-wrap, with a couple of free LEDs thrown in (and some orange paper hearts!) Here’s a view of the top surface:
I think this looks pretty good for a first version. The silk-screen looks very slightly offset (see JP2, JP3) but nothing to worry about. Here’s the underside of the board:
Today I made a start on assembling the board. I was relieved to find that all the components fitted fine, with no obvious layout errors. Unfortunately, I was missing one component (5mm pitch screw terminals for the mains input), so it’s time to place another order! Here’s the partially assembled board:
Google are shutting down Google Code. Nooooooooooooo…. why oh why oh why.
Now I have to migrate everything to Github. And learn Git. Great. Perhaps I could use Sourceforge, with its charming advertising banners. Marvellous.
But wait… they have an export tool! How thoughtful. Let’s try that.
The Google Code Exporter is experiencing extremely high traffic. The export queue is full. Please come back later.
Oh well. Perhaps I’ll try again later…
We have some low voltage Halogen spots (50W, wide angle 60°) in some portable demo kit and, aside from the Halogens being ineffecient and running very hot, they have a tendency to break if knocked. I wondered if these could be replaced with LED lights and did a quick comparison:
|Beam angle (Degrees)||60||60||60|
|Colour temperature (K)||3000||3000||2700|
|Colour rendering (Ra)||90-100||80-89||80-89|
|Average lifetime (h)||4000||25000||40000|
|Luminous flux (lm)||770||575||370|
I could only find one real candidate for replacement (8W Sylvania). It’s not as bright as the original Halogen, so not a true 50W equivalent, and expensive at £22.64 versus £1.38 for the Halogen. However, the LED should last 6.25× longer, and uses 16% of the power.
The Snowdrops at Burton Agnes Hall, looking very good this year:
When external hardware is connected to the Raspberry Pi, it can be important to know the initial state of the GPIO pins at boot time. For example, if we have a motor connected to a GPIO pin, it could be a problem if the motor starts running as the system boots up. Ideally, we would want all the pins defined as inputs at start up, but that doesn’t seem to be the case with some of the Pi GPIO pins.
Fortunately, there’s now a solution in the form of the device tree pin configuration. This involves creating a pin configuration source file, and compiling that to a binary “blob” which is loaded by the OS at start up. This source file can configure pins as inputs, outputs or in special function modes (UART serial port for example). It can also configure whether a pin has pull-up or pull-down enabled.
This proved very useful for my Espiresso project, when I needed a pin to enable the pump at start up. Having run out of general GPIO pins, I was forced to use GPIO15 (RXD) which is configured as a pull-up UART pin by default. This would have resulted in the pump running as the system booted. However, by editing the device tree configuration, it was possible to set this pin as an input with pull-down mode, which prevents the external hardware being switched on during boot. The GPIO pin can then be reconfigured as an output by the application, after the Pi has booted.
As an update to this, there have been a couple of important developments with device-tree since I wrote this, which I’ll summarise briefly here:
- You can now create device tree overlays, to configure specific GPIO pins at boot. However, with NOOBS these do not take effect immediately (in which case the dt-blob.bin will still be needed).
- With NOOBS, the dt-blob.bin file needs to be placed on the recovery partition. Even then, I found the only way to ensure the pins stay in the desired state through the entire boot process is to have the dt-blob.bin on both recovery and /boot partitions.
- In conclusion: avoid NOOBS for this application, and go with a vanilla Raspbian install
I’ve just found this fantastic tool for doing colour coded, side-by-side diffs from the console. It even supports Subversion/Git: