Monthly Archives: May 2013

Kickstarting: You’re doing it wrong

Posted on by

Anyone who follows me on Twitter may have seen my various rantings last night about the OUYA console that I backed on Kickstarter in early July last year.

I know for a fact I’m not alone in my frustration – a recent Ask Me Anything thread on Reddit is filled with comments from irritated backers about the lack of communication from the OUYA team about shipping dates, and the absence of any transparency over what’s going on within the company right now. Even more concerning is their promise to release the OUYA for general sale through the likes of Amazon on the 4th of June. That’s a month away, and in that time they have to ship to 50% of their Kickstarter backers (according to their latest update – you will need to be a backer in order to view), and to the thousands that have pre-ordered after the Kickstarter campaign ended. In this update, they also said that…

“We successfully eclipsed 50 percent of units shipped and remain ahead of schedule to complete all shipments by the end of May”

Well… duh. Not a great achievement. If not everyone has received their pre-ordered consoles by the time retail units ship, something has gone very wrong with their production process. What is the point in supporting a project, if you get little (if any) advantage over general market customers? In my opinion, this is an extremely poor way to treat your early investors. It’s fantastic that the OUYA console will be reaching even more people through general release – but this should have been a secondary concern to fulfilling the existing delivery promises to backers, rather than compromising your delivery schedule. Delaying general release would also give more time for bug-fixing in the software/hardware – as it stands, they’ve lost the ability to use early backers as a beta-test, as there’s little to no distinction between the two tranches of consoles. Development and shipping logistics are difficult, and the majority of Kickstarter projects are run by individuals rather than businesses – take the time to get it right, rather than diving in head-first.

To me, all of this is a perfect demonstration of how Kickstarter should not be used. When you post a project, people are pledging money to support you, often paying over-the-odds to help an idea they think deserves to be brought to market. Kickstarter provides a less risky way for your average consumer to provide angel investments, and gives potential upstarts a platform to reach a massive audience of potential investors – a win/win scenario. By putting a project on Kickstarter, you are not offering it for sale, you are asking for people to come on board and be involved in the process of bringing your project to life – personally I find this very exciting! When I back a successful project, I expect regular updates on how things are progressing, as well as access to things like burn-down charts, details of early prototypes, voting on project direction and suchlike. While I realise this isn’t what everyone is after when backing a project, I think it’s a matter of courtesy to your backers to make this information available – treat these people as your investors, not future customers. You already have their money, so let them enjoy the ride with you, rather than keeping them in the dark. In the case of the OUYA, I’m almost insulted by the way I’ve been treated as a backer.

Sadly, the OUYA team are not alone in handling public relations in this way – almost every hardware project I’ve backed seems to be plagued by a lack of updates. Even something simple like the Twyst Winder (a project created by a group of high-school students near where I used to live in London) has only posted a single update since the project was successfully funded, and that was nearly a month ago. The Pebble Watch also seemed to become “too popular”, leading to (understandable) shipping delays, but the entire process was kept shielded from backers by a lack of communication.

However, the few software projects I’ve backed don’t seem to have this problem. Project Godus, for example, have video-streamed several of their internal meetings, published regular updates on how the game is progressing (including early gameplay videos), and shown off concept artwork and the like. While I’ll admit to not diligently following everything they do, I love having that kind of access to the project I’ve supported – I think this nicely captures exactly what Kickstarter should be, but sadly is not.

Using 20×4 RGB LCD over i2c with a Raspberry Pi

Posted on by

Now there’s a specialist blog post title if ever there were one…

Recently, I’ve been dabbling with electronics to fill the void of spare time I’ve found myself with while I’m between jobs. I’m currently working on a half-baked idea to create some sort of digital assistant who will take instructions in some form, and then read stuff back to me in a Siri-esque manner. Nothing sounds more awesome than having twitter @replies read out to you, right?! To kick off this project, and get me motivated to actually do something, I ordered a boatload of parts from Adafruit, and set about learning how to use them. First challenge – connecting up their 20×4 RGB backlight negative LCD screen to my Raspberry Pi.

In order to assist with this, I also bought the i2c / SPI character LCD backpack in order to save some GPIO pins for other uses. Due to my lack of attention while ordering, I failed to notice that the LCD backpack only has 16 pins, whereas the LCD screen I ordered has 18 (2 more for the extra background LEDs). Rather than giving up and being limited to only a single channel of control for the backlights, I decided to connect pins 14 to 18 direct into the Pi, and mash two separate libraries together to give myself full control. This is what I ended up with (click for big):

2013-05-02 21.36.11

Now, that looks like an absolute mess. That’s because it is. In an attempt to make that a bit more readable, here’s a Fritzing diagram of how it’s wired (again, click for big).

lcd_test_bb

Now, that’s even more confusing as I couldn’t find a Fritzing library with the right parts – so I’ve fudged a few things. Imagine there are ports 17 and 18 on the LCD, and that the LCD itself is 20×4 rather than 16×2. Secondly, imagine the chip in the middle is actually the i2c backpack mentioned above, so everything on the bottom is connected straight to ports 1 to 16 on the LCD, and the VCC/GND/CLK/DAT are connected to the Pi. So, in terms of wiring we get:

  • LCD #1 to #14 -> i2c backpack #1 to #14
  • LCD #15 -> 5V0
  • LCD #16 -> Raspberry Pi GPIO 17
  • LCD #17 -> Raspberry Pi GPIO 27
  • LCD #18 -> Raspberry Pi GPIO 22
  • i2c backpack GND -> GND
  • i2c backpack VCC -> 5V0
  • i2c backpack CLK -> Raspberry Pi SCL
  • i2c backpack DAT -> Raspberry Pi SDA

Now that’s all set up, you can use the standard AdafruitLcd Python library (nice adaptation that I used can be found here) to control the text shown on screen, but we need something bespoke for our background lighting. For future projects, I wanted the ability to control each colour individually, so I can set arbitrary RGB values on the screen, and also brighten/dim appropriately. The latest version of RPi.GPIO will let you do software Pulse Width Modulation, which will achieve this quite nicely for us. To install the latest version (0.5.2a at the time of writing), you’ll need to run the following on your Pi (as root):

$ wget https://pypi.python.org/packages/source/R/RPi.GPIO/RPi.GPIO-0.5.2a.tar.gz
$ tar xf RPi.GPIO-0.5.2a.tar.gz
$ cd RPi.GPIO-0.5.2a
$ python setup.py install

So, combining some standard example code for PWM on the Pi with the AdafruitLcd library, I developed my own little library for controlling a LCD wired up in this manner. To get up and running with the code I wrote, you will need (again, as root):

$ mkdir lcdtest
$ cd lcdtest
$ svn co http://projects.mattdyson.org/projects/LCDControl@889 .
$ git clone https://github.com/PDKK/RpiLcdBackpack.git
$ touch RpiLcdBackpack/__init__.py
$ python testLCD.py

Note: If you see IOError: [Errno 5] Input/output error when running testLCD.py, you may need to edit RpiLcdBackpack/RpiLcdBackpack.py and change the line self.__bus=smbus.SMBus(0) to self.__bus=smbus.SMBus(1). This should only happen on newer versions of the Pi, where the i2c bus number changed to 1 from 0.

Note 2 (added 15/10/14): The version of my LCDControl library that you’re checking out with the above command is now out-dated, I’ve updated the library to use pigpio instead of RPi.GPIO, as the latter was causing me flickering problems when the Pi was under load. To get the latest version, remove the @889 from the svn co command, you will need to have pigpio installed and running for this to work.

Once you run testLCD.py, you should see the screen flash a series of colours, followed by some messages appearing on the screen. Yaaay – it works!

The LCDControl class I’ve written is pretty basic (I’m still learning Python… slowly!) but allows you to set RGB or individual colour values for the backlights, and also pass in any message without worrying about formatting. Currently (version 1.0 at the time of writing), the LCDControl.setMessage method will split by the newline character (\n) and do the logic regarding line numbers for you (as the third display line on the LCD is actually carried over from the first line passed to the controller, and the fourth with the second) – future iterations of this code will allow you to do things such as full text wrapping, and scrolling text.

So there we have it – a 20×4 RGB LCD screen talking to a Raspberry Pi over i2c, retaining individual control over the background LEDs. As always, please leave a comment if you spot anything wrong with what I’ve written here, or have any feedback/suggestions/requests!