PaPiRus ePaPer HAT hardware preview

Aaron of Pi Supply has very kindly posted me a PaPiRus ePaper HAT preview unit. This is a work in progress and Aaron was open that the software side of things still needs work. Fair enough, I’m happy with that: after all in a pre-production unit one does not expect perfection. I have previously covered the Kickstarter and the advantages of using an ePaper display. Today we will be looking at the hardware.

papirus_preview1

The unit was supplied pretty much ready to go with the three sizes of display (1.44”, 2.0” and 2.7”) along with a coin battery and v1.4 of the HAT itself. The first thing to note, and I owe Aaron and team a beer for this design decision, is that the ribbon connector between display and board uses a click up, insert, click down affair, as opposed to pull, slot in, push that is used on the Raspberry Pi Camera module. This makes inserting the ribbon cable easier and the connection notably more secure when clicked back into place.

The rest of the HAT is similarly well thought out (there is even a slot in place to allow the camera ribbon cable to pass through). As with all HATs this will be equally in place on a B+, B v2 or A+ Pi. The combination of Raspberry Pi A+, PaPiRus and 2.7” screen all in a tasty case mounted on a wall displaying data of one kind or another is very appealing as this will be a very compact, very energy efficient solution for a multitude of projects. I can even see this combination being used as an in-car display screen connected to a car’s OBD port for the same reasons.

The upper side of PaPiRUS is mostly empty, giving you a flat platform to rest your chosen screen upon. Along the top are four tactile buttons which will make interacting with the Raspberry Pi and PaPiRus straightforward.

papirus_preview3

On the reverse we find lots of little components, all pre-soldered with precision. This isn’t some DIY rough-and-ready solution, but a professional product. It re-confirms what I’ve known about Pi Supply for a while: this is a professional outfit producing products that us consumers can rely upon.

papirus_preview2

For those who like technical details I got my magnifying glass out and noted the following (obviously this is all subject to change, this being a pre-production board):

IC1 (directly above the edge-mounted ribbon connector) is flash memory from Winbond, part number W25Q32FV. This gives me a clue that the firmware could be updated in the future as needed.
IC2 (up-left from the battery) is a NXP 8523T which the datasheet tells me is a real-time clock and calendar
IC3 (above IC2) is a NXP LM75BD which is a digital temperature sensor and thermal watchdog
To the left of IC4 (below the battery) we have a B6MY which Google tells me may be a folding pocket knife. I think my Google Ninja skills failed me at this point.

The hole for the reset pin is present on v1.4 of the board (below-left from the battery) and with less than £3k to go at the time of writing we’re sure to unlock this stretch goal.

UPDATED: Most intriguing of all on the v1.4 design is the inclusion of a second ribbon cable connector at CN4 (above battery). Aaron pointed out what I had completely failed to notice: that this is a GPIO breakout (see the last photo on the Kickstarter page).

The board is rock-solid, with no loose chippery to be found anywhere. PaPiRus is on Kickstarter for 5 more days and looks set to be an excellent way to add an ePaper display to your Raspberry Pi.

Comments

Robotics 2: Using the Sharp GP2Y0A41SK0F IR distance sensor with Explorer HAT Pro

The HC-SR04 is a clever component. By measuring the time delay between signals from the included board one can easily calculate the distance to objects. Well, that’s the theory. Unfortunately it turns out that it does not play that well with Explorer HAT Pro board that it is connected to when using the provided explorerhat library. I’ve observed that ranges to perpendicular objects (to give the best result) are miscalculated by up to a metre (plus or minus). This seems to be a timing issue as the HC-SR04 does not return the distance to an object, but instead it sends a connected pin high for the same time as it took for a pulse of ultrasound to bounce back.

Instead, Zumo George has received an upgrade in the form of the Sharp GP2Y0A41SK0F infrared distance sensor. This has the added benefit of making him look more Goliath* and less WALL-E. This is an analog device that runs at 5V which matches perfectly with the Explorer HAT’s analog inputs. It measures distances accurately from 4cm to 30cm which, for the purpose of “don’t crash into an object” is perfect.
ZumGeorge_with_IR
Wiring is straightforward with GND and Vcc to their respective 5V pins and the third cable to one of the analog pins (I use pin four). I bought the sensor on eBay for a few quid and the cable it came with did not have 0.1” pins attached at the breadboard end of things. A quick bit of soldering and heat shrinking later and we’re ready to go.

Next I needed to add to my library of tests for Zumo George to ensure that when he boots up all is A-OK. Let’s write a scenario:

@ir
Scenario: Verify infrared range finder is responding
  Given the distance to an object is greater than 10 cm
  When I read the infrared range finder
  Then I should see a distance greater than 10 cm


Now we execute this with Lettuce. Note though that I have added a tag with the @ symbol to enable me to run just this scenario while we get it working. Hence we:

sudo lettuce -t ir

We need sudo because Pimoroni’s Explorer HAT Pro requires this, and we use the -t parameter to specify the tag to execute.

Immediately we see that our three steps have not been defined, and Lettuce helpfully returns suggested step definitions that assert False. Copying these into place and re-executing moves us from not implemented to not coded, with the three steps each going red.

At this point we need to implement some code to make everything work as it should. To do this I have decided to create a new Python module, zumo.py which will contain specific functions required by Zumo George. We are going to need a way of determining distance by using the GP2Y0A41SK0F sensor, hence in zumo.py I enter the following to create a read_distance() function that we can call from a step definition:

import explorerhat
import time

def read_distance():
  # with help from: http://www.yoctopuce.com/EN/article/an-usb-optical-telemeter
  # and an idea from http://jeremyblythe.blogspot.co.uk/2012/09/raspberry-pi-distance-measuring-sensor.html
  v_readings = []
  # read the voltage 10 times so that we can get a decent average
  for i in range (0,10):
    v_readings.append(explorerhat.analog.four.read())

  av_voltage = sum(v_readings)/10.0
  if av_voltage <= 0:
    av_voltage = 0.001
  distance_cm = 13 / av_voltage
  return distance_cm


The GP2Y0A41SK0F works on the principle that distance to an object is inversely proportional to the voltage that can be read from the connection on analog pin four. In other words the higher the voltage the lower the distance, and our equation takes this into account. The number 13 was determined by looking at the datasheet on the Pololu product page. In the graph we can determine for a reading of 1V we should be 13cm away from our object, i.e.: 13/1 = 13cm. I got the idea to do things this way from Yoctopuce who used another Sharp IR sensor. Their magic number was 60 for the GP2Y0A02YK0F which they obtained in the same way.

Into steps.py I then add the following three step definitions as well as the import zumo command. The Given sets up the expected result, the When is the event (i.e.: read the distance) and the Then is the comparison. I will be honest and say that in Python I don’t know if using global variables in this way is a good thing or not (note to self: must research this), but it works, so at this stage I am not too concerned:

@step(u'the distance to an object is greater than (.*?) cm')
def the_distance_to_an_object_is_greater_than(step, distance):
    global minimum_expected_distance
    minimum_expected_distance = distance

@step(u'I read the infrared range finder')
def i_read_the_infrared_range_finder(step):
    global actual_distance
    actual_distance = zumo.read_distance()

@step(u'I should see a distance greater than (.*?) cm')
def i_should_see_a_distance_greater_than(step, expected_distance):
    assert float(actual_distance) > float(minimum_expected_distance), "Distance returned = %d" % actual_distance


Running Lettuce a third time now shows everything is green, meaning our scenario is passing and our code to generate distances is working. Well, sort of. We have to remember that we are now mixing a controlled software environment with real-world robotics and as the adage goes, “anything can happen in the next half hour.” Clearly this scenario will only pass if the distance from Zumo George to an object is greater than 10cm. For me this is perfect as George always starts his working day facing away from obstacles. We could of course change our code to simulate the response from the GP2Y0A41SK0F (not the easiest of components to pronounce, or spell) but then we are not demonstrating the desired real-world behaviour: that when Zumo George is not facing a nearby object he shall be a happy robot ready to drive.

ir_test

You may note that something strange has happened though. We are clearly only running one scenario against a single feature by specifying the tag ir yet Lettuce is reporting that 2 features have passed (which you would think implies a minimum of two scenarios executed). I think of it this way: we have told Lettuce that only a single feature shall be run by telling it absolutely (in this case) that only a single tag containing a single scenario is within scope, therefore we have told Lettuce that the other feature passes and it counts it as such. This is on the basis that BDD should be all-or-nothing, i.e.: to demonstrate that software is fit for purpose all of our scenarios must pass and we are stating we are taking responsibility for this decision in this other case. Another way to think of it is that as the other feature contains no scenarios that we execute there is nothing that can fail, i.e.: it passes by default. It is something to be aware of though as it can make your numbers look a little strange if you are not used to seeing this outcome.

Next time: The Ryanteck 3 Line Follow sensor

* The evil truck from Knight Rider.
Comments

Pi PoE HAT Kickstarter

pi_poe
Like all computers the Raspberry Pi can quickly become a spaghetti junction of cables, cables and more cables. And cables have a mind of their own and are evil, entwining themselves into knots the moment your back is turned. It is into this plethora of power, USB, ethernet and HDMI connections that Pi Supply comes to the rescue with a rather clever Power Over Ethernet (PoE) offering.

PoE is one of those it-does-exactly-what-it-says-on-the-tin offerings: providing power to the computer via an ethernet connection and hence meaning you can wave goodbye to a cable. It is quite a clever idea really: ethernet requires power, your computer requires power, why not combine the two? The Pi PoE HAT gives you just this, throwing in a handy programmable button as well. Plus, the GPIO pins remain available for further connections. Note though that you do need a PoE compatible switch or injector to provide the power though.

Last night when I was previewing the Kickstarter a thought occurred: why not combine PoE with PowerLine? Now THAT is a tasty idea: use ethernet for power and your house’s power circuit for ethernet. Googling shows me there are various options for this and I’ll definitely have to investigate this some more.

There are many valid cases for PoE and the Kickstarter gives some ideas about how this can be used.
Comments

PaPiRus ePaper HAT Kickstarter

Chatting with Aaron of Pi Supply recently I became aware that he was about to put something live on Kickstarter that is really exciting. I promised to keep quiet until launch day despite constantly wanting to shout “This is AWESOME!” from the roof tops.

Papirus2
Pi Supply are seeking funding for a superb ePaper / eInk HAT on Kickstarter called PaPiRus. It’s an absolutely genius design with four buttons mounted along one edge and up to a 2.7” ePaper display. Why is this “AWESOME” you may ask? Well, ePaper displays only require power when the image is updated. It is this fantastic property that gives the Amazon Kindle such excellent battery life in the “weeks” not “hours” category. Combined with the low power Raspberry Pi and you have something that’s cheap as chips to run. This is even more so with the Raspberry Pi A+. Alex Eames of Raspi.tv did an excellent write-up of the respective Pi’s power usage.

Now, ePaper is not going to be for everyone. If you require colour, or fast screen updates in the ms range then a traditional LED/LCD screen will be more to your taste. But for status displays, Twitter feeds and the like, and especially if you need to run off batteries (this HAT will work stacked with Pi Supply’s Pi Juice) you just can’t beat ePaper. Tim Cox once repurposed a Nook eReader as an ePaper display for his Pi, but obviously this requires a fair bit of effort to get working. The beauty of the Raspberry Pi HATs is that they are pretty much plug and play, hence PaPiRus gets a massive thumbs up.

What’s more, PaPiRus is being made by Pi Supply who have a history of creating superb add-ons for the Raspberry Pi (and PiJuice of course) that are delivered as promised. I’ve no qualms at all about entrusting my money to Pi Supply for one of their projects. Pi Supply just hit the £5k fully funded mark with 30 days to go. This is clearly a project you can have confidence in.

Head on over to Kickstarter to back PaPiRus.

papirus
Comments