An encounter with Count Dracula at Whitby Abbey

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!

Whitby Abbey

Projector brightness: Optoma EH505 versus Optoma TX785 in 3D and 2D modes

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:

ModelResolutionHzModeLux
EH5051520x950104Presentation431
EH5051920x120060Presentation425
EH5051024x76860Presentation435
EH5051920x120060sRGB209
EH5051520x9501043D176
EH5051520x9501043D176
EH5051280x7201203D173
EH5051024x7681203D177
TX7851024x76860Presentation516
TX7851024x76860Bright703
TX7851024x768120Presentation233
TX7851024x768120Bright285

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 IGBT Driver Board is ready!

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:

PCB 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:

PCB Bottom Surface

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:

PCB Assembly

Google Code Shutdown

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…

Comparison of MR16 50W 12V Halogens with LED lights

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:

ManufacturerOsramSylvaniaPhilips
TechnologyHalogenLEDLED
Watts5085.5
Beam angle (Degrees)606060
Colour temperature (K)300030002700
Colour rendering (Ra)90-10080-8980-89
Average lifetime (h)40002500040000
Luminous flux (lm)770575370
Normalised brightness175%48%
EAN405030042879654102882634658718291697183
Price£1.38£22.64£8.84

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.

Raspberry Pi GPIO states at boot time

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