Tag Archives: Gordon Hollingworth

Creating and Kickstarting Slice, the Compute Module-Based Media Player

via Raspberry Pi

Back in August 2014, a startup company called FiveNinjas launched Slice, the first ever Compute Module-based media player, on Kickstarter.


FiveNinjas with five Slices. Front to back: Gordon, James, Mo, John, Paul

We are FiveNinjas: James Adams and Gordon Hollingworth from Raspberry Pi, Jonathan Williamson and Paul Beech of Pimoroni, and Mo Volans, entrepreneur and music producer. We’re here to tell you how we created a consumer product with the Raspberry Pi Compute Module in our spare time, and launched it using Kickstarter. It has been a long journey, but we’ve learned a lot and now have a growing and enthusiastic community over on our forums, a video channel, and even a user-created HOWTO Wiki. Finally, all Slice’s software (which is a modified version of the fantastic OpenELEC and Kodi) is available on GitHub. We hope this post will be interesting or inspiring to those who want to follow in our footsteps: grab a mug of tea and read on…

Gordon gives the background:

FiveNinjas began with the Mo Volans’s idea of a media centre built around the Raspberry Pi, including everything you needed to get going without requiring lots of knowledge about how media centres work. He first got in touch with Paul and Jon from Pimoroni to discuss the idea, thinking that he could create the simple software build required and Paul and Jon would be able to create a laser-cut case to contain the Raspberry Pi, a hard drive, and WiFi. They also came up with the idea of adding the LED ring to provide visual feedback. Between them, they created the first Slice video, which they showed to us at Pi Towers.

I was amazed by the idea, and believed that Slice was going to be a great product, but I also thought it could be better. Around that time, we were developing the Raspberry Pi Compute Module which would allow smaller and more custom hardware in a very small package. It was perfect for the Slice, as it would also allow us to use a standard SODIMM connector, while remaining backward-compatible with future Compute Modules, and enabling users to upgrade their boxes.

I came on board, bringing James Adams with me. James went to work on the hardware schematics and I went to work on the software. At this stage, we were still trying to start up the Kickstarter but knew we had to wait until we had the first version of the hardware because Kickstarter require you to have implemented a first prototype.

The first thing we had to do is to set a timescale for the Kickstarter, which can be tricky. The longer time you set, the more opportunity you’ll have to get people interested in the product. However, you’ll also have a longer delay before you can start ordering supplies for your project. In the end, we had to wait about six weeks to be able to order the PCBs, even though we had already finished the design. Interestingly, the optimum time for a Kickstarter is probably significantly less than you’d expect: we took five days to hit our funding target but then couldn’t start ordering parts until around four weeks later! Finally, we ordered the first set of PCBs, and I began the task of developing the test code.

One of the most important parts of the PCB manufacturing process is developing the manufacturing test system, which is the test that tells you whether the manufacturer has actually built the hardware correctly. If you find a problem at the manufacturing stage in China it is relatively quick and cheap to fix it right there. Whereas if we find the bug later when the PCBs have been transported to the UK, we’d have to either throw them away, fix them by hand, or send them back to China! The test system for Slice was built around a simple Buildroot Linux kernel, which is actually the same way the Compute Module is tested. The Buildroot kernel can be pushed into the Compute Module over USB; the software can then run through the test process.

Slice testing

This is a video of the FiveNinjas Slice product being tested. It is actually very simple to execute a linux buildroot on a compute module without having to program the Flash at all

The test schedule included the audio output, the LEDs, HDMI output, the USB connections, the internal SATA hard disk, and the infrared sensor; each test required the operator to complete various checks, whereupon it would output test results and the serial numbers for the Compute Modules.

I also wrote a similar but slightly different programming Buildroot kernel. This was used to program the Slice eMMC, copy data from a server onto the hard drive, install the licenses, install the recovery system and then boot into the Slice operating system to check everything was working. This takes about one minute, but, because the whole process is done automatically, it could be done in parallel.


Slices being programmed automatically in parallel (Raspberry Pi for scale)

The testing was a success: Slices are now programmed with the latest version of our software as they leave the warehouse (as you can see in the picture). The Slice software (which is fully open and available on www.github.com/FiveNinjas) has also been maturing thanks to lots of feedback from users, and we are continuing to improve it.

Jon says: Friends don’t let friends do cases (unless they’re made from laser cut perspex!).

Early on we decided that we wanted to make Slice something premium and special. We quickly decided that milled aluminium (aircraft grade, what else?) was the order of the day.

We had loads of experience making acrylic cases but had never embarked on something that required full 3D modelling. With a vision of simplicity that would accentuate the lighting ring, we knew exactly what we wanted. The only problem was we didn’t know where to start. Luckily an old friend works for Autodesk, and could provide some tips on how to get started which were amazingly useful. Armed with a killer CAD package, I spent a weekend producing the first design files. We had a viable model for machining! Fortunately, in those days Pimoroni was next door to a tooling company, who prepared a few prototypes for us to test with.

image (8)

The first Slice case prototype machined from aircraft grade aluminium!

Machining in the UK was impossible due to costs, but fortunately we had friends in Taiwan who visited a few machining companies and came back with quotes that would work. The only downside to production in Taiwan was that we couldn’t risk placing a single order for all the units at once. We had to quality control batches as they arrived otherwise there was a risk that we could receive a heap of junk and the whole project would have been in trouble. We settled on batches of 200-400 units at a time, which balanced risk with speed. Generally this worked pretty well but it was slower than we would have liked.

The case production process was fraught with delays due to the fact that there are three steps: machining, bead blasting, and anodising, all of which are done at different places. The end result is, however, undeniably lovely and makes Slice something quite special.


Red Slice with remote. Also available in black or grey!

Paul says: It’s hard to be Jony Ive on a budget of less than £1m.

The Slice Kickstarter was a success. This is a lot harder to achieve than it looks, but we had a stellar team with a good overlap of talents and a great, supportive community. For me, the joy was getting back to the days of hard disk players, but smaller and sleeker. Nowadays, everything and its dog has Netflix, so I was keen to see something with usable software and a simple setup for the old skool crowd.

Slice capture 5

The Slice UI

Unfortunately, 500-1500 backers is pretty much the valley of death for hardware. If you want to make 100 of something, you can do it locally, at high cost, but probably beautifully. If you want to make 10000 of something, you can do it in the Far East, quite economically and with good quality. In between, you’re in a sticky middle ground. Things like electronic components come in reels of 2000-3000, factories don’t get out of bed for less than 10,000 pieces, and you don’t have time to play with R&D of 100 units to get things right and smooth. You have the higher costs of smaller-run production but without the benefits of doing things big.

Fortunately we had a lot of advantages, or we might have struggled. There have been mid-sized crowdfunding projects that have gone horribly wrong. We haven’t been one of those, and the results have always been satisfying, even when late.

I got a real kick out of seeing the case come to life. It’s simple, beautifully finished, and without fussy details. I didn’t expect us to be able to nail the finish this well, but the results are pro-style and built to last, which is handy as we’ve made the Slice upgradeable.

James says: Circuits are fun, but there’s more to it than that…

Designing the circuitry and circuit board (PCB) for Slice turned out to be more of a challenge than expected despite having lots of experience.

The hard part of any design is the balance of features and trying to come up with low cost yet functional and well engineered circuitry. Using the Compute Module made the entire project possible, as we knew we were building on a stable platform and could concentrate on all the other parts.

We spent many hours working out how to mount the hard disk, the LEDs, and Slice’s LED diffuser. Eventually we settled on the solution we have today, which works remarkably well despite being very simple!

We created three sets of prototypes at our own expense, and did all the testing as well as compliance testing. Thankfully this all went relatively smoothly, but even for the professionals it takes a lot of work and usually several prototypes to get things right. Let’s not go into how much time was spent arguing about and testing the layout of the ports on the back of Slice and spacings between them….

Slice’s PCB including Compute Module

Mo says: I had an idea in my kitchen, gained a team in Sheffield and lost my voice in New York.

My journey with Slice has been a little different: from the initial idea to putting together the Kickstarter campaign, everything has been about concept and image for me. I’m always a little obsessed with how things appear and whether or not people will perceive something as a quality product. This moulded my interactions with Slice.

It all started in my kitchen. A Raspberry Pi, a hard drive, a few sensors and a huge bunch of wires were stuck to a TV. I was convinced the whole contraption could fit into a box and become something that people would want to use, so I got to work with my Dremel and took my first prototype on the road.

Mo's very first Slice prototype!

Mo’s very first Slice prototype! Fortunately production Slices are a little better.

I approached a few companies at this point but the best fit by far were the guys at Pimoroni in Sheffield. After a few boozy meetings, the first solid Slice unit was born.

After my wife Emma coined the name Slice, Jon added some LEDs, and Paul came up with a killer logo, it was time to get to work. Kickstarter was our chosen route but we needed a working prototype and some great footage. We made some progress but something was missing, Slice was just too big, and our efforts were a little unstructured.

It was at this point that Jon and Paul introduced me to Gordon and James at Raspberry Pi. They loved the idea of Slice and FiveNinjas was created (Emma gets credit for a second name here). We suddenly had expertise in marketing, hardware, software, logistics and design, as well as the new Compute Module.

In no time the new compact Slice, complete with custom PCB and milled aluminium case, was born. It was a great moment to see my humble concept transformed into a solid working unit.

It was time to go back to Kickstarter, where the real work began for me. The guys had done such a good job I knew I had to go all out to make the slickest proposal I could, and nothing was left to chance. The campaign itself was no less intense, with thousands of questions, some awesome press coverage and trip to New York Maker Faire (where I lost my voice talking to thousands of people and Slice won two editors’ awards). In the end we smashed our target and we’re now distributing thousands of Slices.

Slice: Raspberry Pi Media Player

Mo Volans from FiveNinjas shares Slice at World Maker Faire New York 2014. It’s a set-top media player that’s based on the brand new Raspberry Pi Compute Module. They’re in the process of crowdfunding the project, and have met their funding goal. Since it’s based on the Raspberry Pi hardware and XBMC software, the platform is totally hackable.

The journey post-Kickstarter has been bumpy: we’ve hit some serious obstacles but we’ve tackled them and come out with a bunch of happy users. Slices are now flowing freely and we are good to go. Hopefully this just the beginning for Slice.

The post Creating and Kickstarting Slice, the Compute Module-Based Media Player appeared first on Raspberry Pi.

The Eagerly Awaited Raspberry Pi Display

via Raspberry Pi

You’ve been incredibly patient: thank you. The official Raspberry Pi touch display is on sale today, priced at $60 (plus local taxes and shipping): you can buy it at the Swag Store, at RS Components/Allied Electronics and at Premier Farnell/Newark. Other sellers will be receiving stock later this week.


We gave one to Alex Eames of RasPi.TV a couple of weeks back so that he could give us one of his famously clear video introductions:

Two years ago, I began the process of looking for a simple, embeddable display for the Raspberry Pi. I honestly believed it would only take us six months from start to end, but there were a number of issues we met (and other products diverted our attention from the display – like Rev 2.1, B+, A+, and Pi 2). But we’ve finally got there, and I thought you might be interested in learning about our journey.

Display Technology

First of all, here’s an overview of the technology involved in the different types of display that the Raspberry Pi can support.

Currently the Raspberry Pi can support the following display interfaces:


HDMI is the system we all know and love, it allows us to communicate with monitors up to 4K and has a relatively low signal swing to reduce EMI. There are lots of other very useful bits of the specification such as CEC (a communication channel between the TV and the Pi that allows us to receive input from the TV), EDID (a method of automatically identifying the different formats the TV supports) and a hotplug signal allow the Pi to know when you plug in the cable. The only problem with HDMI is that the electronics required to convert from HDMI to the native panel interface can be quite expensive.


DPI (Display Parallel Interface) is a 24-bit parallel interface with a clock and various synchronisation signals totalling 28 signals, all of which switch at a rate of around 70MHz. This interface has been phased out of tablets/phones because the electromagnetic noise created and power consumed by all those wires. Although it is possible to directly talk to a DPI display through the GPIO connector on a Raspberry Pi it would leave no GPIOs left for people to connect other HATs. DPI displays are available everywhere though, and are relatively cheap!


DSI (Display serial interface) is a high-speed serial interface based on a number of (1GBits) data lanes. The total voltage swing of the data lines is only 200mV; this makes the electromagnetic noise created and power consumed very low. Unfortunately, DSI displays are only really created and sold for special purposes (i.e. when a mobile phone manufacturer wants to make a new phone), and although they can be available to buy, manufacture of the devices is subject to the lifetime of the phone!


DBI (Display Bus Interface) is an old display technology that usually has inbuilt frame storage to reduce tearing, due to the memory and hardware it makes DBI screens expensive.

So our solution to this problem was to employ both DSI (to avoid using up all the GPIOs) and DPI (easily available screens in suitable resolutions) and a bridge chip/conversion board to convert between the two.

We got in touch with many display manufacturers to try and get a display that would tick the following requirements:

  • Quality colour reproduction
  • Pixel quality (sometimes you can see the individual pixel boundaries)
  • Contrast ratio
  • Viewing angle
  • Affordable
  • Lifetime (length of time before the display is no longer going to be manufactured)

Of course lifetime is one of the most important requirements, because if a display only has a lifetime of a few months (or the manufacturer is uninterested in guaranteeing a minimum lifetime), we would have to repeat the whole development cycle once more. So we can’t just buy a display that’s used in your standard iDevice, because it is likely to be cancelled when the iCompany decides to move to another manufacturer!

When looking for a device, we needed to look for what are termed ‘Industrial’ LCD displays. These tend to have better-quality metrics and guaranteed availability.

In the end we chose an industrial-quality display from our friends at Inelco Hunter based in the UK, who were able to create something very special:

  • RGB 800×480 display @60fps
  • 24-bit colour
  • FT5406 10 point capacitive touchscreen
  • 70 degree viewing angle
  • Metal-backed display with mounting holes for the Pi

Our first PCB to do the DSI to DPI conversion was completed back in mid-2013. The board used a Toshiba bridge chip to convert the DSI signals to DPI ones. I spent quite a bit of time getting the Raspberry Pi to talk to the bridge device, and then got it working and displaying an image (yay). We then took it to our local EMC test facility to investigate how easy it would be to pass CE and FCC electromagnetic compliance.

A little word on compliance…

When electrical currents flow around a circuit board, they create electro-magnetic fields, which can be picked up by other electronic devices. Maybe you remember what used to happen to your CRT television when your mum turned on the hoover (sorry for those of you without any experience of analogue television). This was becoming a problem for television and radio receivers; when I was a kid and plugged in my Spectrum 48K, the radio wouldn’t work properly any more. So the powers that be introduced new rules about the amount of energy a device can output at various frequencies from 25MHz up to a couple of GHz. You have to make sure your electronic devices do not cause interference, and are not susceptible to electronic interference.

The best way to reduce electromagnetic interference (EMI) is to keep your high-frequency signals short and close to a nice continuous ground plane, reduce the frequency and drive of the signals (reducing the high frequency components), and reduce the maximum swing of the signals to reduce the signal power. Looking at modern communication systems, that’s exactly what they do: for example, DSI has a signal swing of only 0.2V and only has two or four actual signal lanes.

Unfortunately, DPI is 1.8V signal swing, and although much slower, it needs 28 signal wires, meaning 28x more paths with the same edges switching up and down at the same time. This gives us an output looking something like:


The green line is the class A line, and the black is class B (we need to reach Class B). You need to be below the black line if you want to sell the device to be used in the home.

Back to the drawing board

The next step was to understand why the EMI is so bad, so we tried redesigning the board so it looks like a HAT (it’s not actually a HAT because there is no EEPROM for device tree information), and added an Atmel device to control the power/reset and PWM for the backlight. We also went through three different iterations of adding chokes to improve the noise conducting down the power supply cable, and manipulating the route of the DPI signals to improve the path of the ground return.

In the end we did reach our goal of a class B EMC pass which is a great achievement considering where we started!

Building the display from scratch

The first displays are supplied as a kit which requires some initial construction. Alex Eames from RasPi.TV has helpfully provided a video showing how to do it.

Connecting the display

The display module integrates the LCD display with a conversion board that should be plugged into the Raspberry Pi through the display connector. Be aware that the connector is the same as the camera connector, but the two are not compatible, so be careful to correctly identify the display connector first.


The 15-way FPC connector should already be plugged into the display conversion board with the silvered contacts face-up. You can then plug the connector into the Raspberry Pi with the silvered connectors inboard (facing towards the USB connectors).


Powering the display

There are three options for powering the display:

1) Separate power supply

Just add a separate uUSB power supply rated for at least 500mA, and plug into the display board where it says “PWR IN”.


2) USB link

Attach an official 2A Raspberry Pi power supply to the display board “PWR IN” connector, then attach a standard uUSB connector from the “PWR OUT” connector to the Raspberry Pi.


3) GPIO jumpers

Attach two of the supplied jumpers to connect 5V and GND from the Pi.

Using the display

To use the display the user just needs to do the following:

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo reboot

The Raspberry Pi will now automatically detect the display and use it as the default display (rather than HDMI), although HDMI will still be initialised. If you’d prefer for the HDMI display to stay as default then add:


to the config.txt file.

Dual display usage

It is possible to use both display outputs at the same time, but it does require software to choose the right display. Omxplayer is one application that has been modified to enable secondary display output.

To start displaying a video onto the LCD display (assuming it is the default display) just type:

# omxplayer video.mkv

To start a second video onto the HDMI then:

# omxplayer --display=5 video.mkv

Please note, you may need to increase the amount of memory allocated to the GPU to 128MB if the videos are 1080P, adjust the gpu_mem value in config.txt for this. The Raspberry Pi headline figures are 1080P30 decode, so if you are using two 1080P clips it may not play correctly depending on the complexity of the videos.

Display numbers are:

DISPMANX_ID_FORCE_OTHER 6 /* non-default display */


The Raspberry Pi display has an integrated 10-point touchscreen (a bit of an overkill, but it does seem to work well). The driver for this touchscreen outputs both standard mouse events and full multi-touch events, and therefore can work with X as a mouse (although not brilliantly – X was never designed to work with a touchscreen!).



Kivy is a Python GUI development system for cross-platform applications. It is designed to work with touchscreen devices (phones and tablets), but also runs on the Raspberry Pi. To install Kivy onto your Pi follow the instructions at


I’m fairly sure that these are the instructions that worked for me, although I make no claims that it’s an easy task!

This short, soundless video shows off the possibilities of Kivy with multipoint touch nicely.

Raspberry Pi’s Matt Richardson has been experimenting with using Kivy to allow the touchscreen to control Raspberry Pi’s GPIO, and vice versa:

From the videos you can see how capable the interface is. I’m in the process of developing a touchscreen application for an installation at home to control a safety and heating monitoring system, so you’ll probably hear more about that at some point!

Last of all, if you’d like a stand for your display, you could do a lot worse than to take a look at the 3D-printed one that Matt Timmons-Brown has designed; we like it a lot. You’ll find his model on Thingiverse.

Have fun, and make something awesome!


The post The Eagerly Awaited Raspberry Pi Display appeared first on Raspberry Pi.