RoadTest: Raspberry Pi 2: We're Giving Away 50 Units!!!
Author: jdmcs
Creation date:
Evaluation Type: Independent Products
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: BeagleBone Black, Raspberry Pi Model B, Raspberry Pi Model B+, RIoTBoard
What were the biggest problems encountered?: Software I had planned to use for prototyping purposes that is not available for the ARM platform. One example is Chrome.
Detailed Review:
Note: I'm posting this review in sections.
Disclaimer: The Raspberry Pi 2 was provided by element14 at no cost, in exchange for this review, as part of their RoadTest program.
Introduction
The Initial Problem:
I live in a town house with an attached garage that has no windows. Unfortunately, if I don’t happen to hear the current or forecast temperatures on the radio, I can get into my car and be halfway to work before realizing that I needed a coat.
The Solution:
If I had a personal “dashboard” located near the door to the garage, I could have it show me the weather before I get into my car. It wouldn’t have to be limited to just showing the weather, but that will be the starting point for the project.
The Proposal:
As part of this RoadTest, I proposed to use the Raspberry Pi 2 to prototype my personal dashboard.
So without further ado…
Justin’s Personal Dashboard Project
If I started this review at the point of time when I received the Raspberry Pi 2, then the review would be incomplete. So please pardon a brief history lesson here, since I had yet to document any of this elsewhere. RoadTests make a great excuse to start documenting projects... 
The Monitor
I have been working on my personal dashboard off and on since January 2014 — before the announcement of even the Raspberry Pi B+. That is when I made the first decision that would dictate certain system requirements: the purchase of a touch screen monitor pulled from a piece of exercise equipment.
From the seller’s description, I knew that this was a 1920x1080 monitor with DVI-D and VGA video inputs, a 3.5mm audio input, and USB connection for the touch interface. What I didn’t know was its compatibility* with Linux or of any particular traits due to being manufactured for a piece of exercise equipment**. First trait I confirmed upon receipt: no power button. (Or any buttons for that matter.)
* If it says anything, one of my co-workers thought I'd never get the touch interface woking with Raspbian...
** As such, the monitor has no documentation available.
Much to my relief, I discovered that the touch interface was plug and play in Raspbian… but only usable if the display was running at 1920x1080. If the display is running at a lower resolution, the touch interface and the display don’t line up because the monitor centers the image instead of scaling it to fill the panel. And here lies a lovely quirk: the Raspberry Pi can’t read the EDID of this monitor when it is not powered. In fact, it seems as if the Raspberry Pi thinks this monitor is unplugged until it is powered. If the Raspberry Pi powers up without the EDID, then it defaults to a resolution lower than 1920x1080.
Luckily, the Raspberry Pi has the ability to read and save the EDID from a display, and then use that EDID file at boot time instead of the monitor’s EDID file. Now I don’t have to worry about the power up sequence. Need to perform this on your Pi? Here's the process I followed (thanks to this help):
hdmi_edid_file=1
hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=82
Some of the config.txt settings will vary depending on your monitor. hdmi_edid_file instructs the Raspberry Pi to use the /boot/edid.dat file instead of trying to read the monitor's EDID. hdmi_force_hotplug instructs the Pi to act as if the monitor is always plugged in (necessary in case my monitor is plugged in after the Pi). hdmi_group tells the Pi which format hdmi_mode is using, and hdmi_mode set the resolution and refresh rate that the Pi should use.
I this example, which works for my monitor, hdmi_group=2 specifies that hdmi_mode is in DMT format (since my monitor is DVI) and hdmi_mode=82 is 1080P at 60Hz. Unless you happen to be trying to use the same monitor, you'll need to select settings that work for your monitor. This page has more details on the config.txt settings for video modes, as well as a list of all the hdmi_group and hdmi_mode settings available.
Initial Platform Selection
I initially started prototyping the the dashboard using this very Raspberry Pi Model B (the blue board at the top right is a DS1307-based real-time clock breakout board):
I did consider the BeagleBone Black (which I had previously purchased) and the RIoTBoard (which was provided by element14 for a previous RoadTest review), but decided against using them for the following reasons:
BeagleBone Black: Only supports 1920x1080 at 24Hz, which the monitor I have does not. Also, the single USB port would require the use of a USB Hub to use the touch interface and a keyboard at the same time.
RIoTBoard: While performing that previous RoadTest, I was only able to get the RIoTBoard working in 720p at 57Hz, so I never tried it with the touch monitor.
When the Raspberry Pi Foundation announced the Model B+, I knew it would be a better match for this project due to the increased number of USB ports. This would allow me to plug in the monitor’s touch interface and a wireless keyboard/touchpad for development, and have spare USB ports for anything else I might cook up.
And while I did order a Model B+ for this project, I ended up using it for something else.
One Teensy Solution
Touch screen monitors are expensive, even if I did buy a used one. In the interest of not burning static images into the display, I decided to leave screen blanking turned on. However, I also wanted the dashboard to display information when I needed it instead of having to touch the monitor to wake the screen.
I had considered tying a PIR sensor into the RPi’s GPIO, and then somehow converting detected motion into an action that would wake the display if it were asleep. But around this same time, I found the “Awesome Button” project in Make Magazine and discovered the Teensy. And an awesome idea, at least for prototyping, was born. For lack of a better name, I call it the “WakeUp Sensor”.
The WakeUp Sensor converts detected motion into subtle mouse movements. When new motion is detected after a reasonable amount of time (I’m currently using two minutes), the Teensy sends a one-unit mouse move to the connected computer. This is enough to keep the screen awake while you're present and to wake the RPi from screen blanking, but shouldn’t be enough to cause harm if you happened to be doing something when the mouse move is sent.
And with the four USB ports on the Model B+, I can leave the wireless keyboard/mouse dongle attached.
The Moment You’ve Been Waiting For
It was also the day I was waiting for: the arrival of my new Raspberry Pi Model 2. And the RPi2 even came with a kind note:
As much as I wanted to start using my newest toy, the Raspberry Pi 2 (like its siblings) does not include a memory card in the box. I could have downloaded a fresh copy of NOOBS or Raspbian from the Raspberry Pi Foundation and written it to one of many spare MicroSD cards, but my Raspberry Pi Model B was currently working just the way I wanted it to work. Besides, software compiled for the BCM2835 SoC found on the older Raspberry Pi Models is supposed to run on the BCM2836 found on the Raspberry Pi 2, so let's put that to the test.
Migrating the Model B's SD Card to a MicroSD Card for the Pi 2
You can't just "jam" (no pun intended) an SD card from an older Raspberry Pi Model into the Pi 2. First of all, the firmware and software needs to be updated to a version that supports the Pi 2, a step that needs to be completed on your older Pi. And secondly, unless you happened to use a MicroSD card in an Adaptor (I didn't), or are moving from a Model A+ or B+ (where you've already had to use a MicroSD card), you need to clone your SD card onto a MicroSD card.
Here's how you would do this update if you are a Mac user and are running Raspbian on your RPi.
Updating Raspbian and Firmware
This step must be completed on your older RPi, and requires that RPi to be connected to the Internet.
From the Terminal, issue the following commands:
sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo apt-get install raspberrypi-ui-mods
Depending on how it has been since you last updated Raspbian, the middle commands (upgrade and dist-upgrade) may take some time to complete. Strictly speaking, the installation of raspberry-ui-mods is probably optional*, but I did notice that the menu bar did not look quite right on the Pi 2 when I failed to install raspberry-ui-mods.
* This package will move the menu bar from the bottom of the screen to the top, so I could see why you might not want to install it.
Also, if you have I2C (and possibly SPI) devices that don't work after running these commands, run sudo raspi-config from a Terminal (this launches the same program that ran on your fresh Raspbian install). Look on the Advanced Options page for the options to re-enable I2C and SPI.
Updating NOOBS
These steps supposedly must be completed on your PC or Mac.
Since I started with a plain Raspbian image, I didn't have to update NOOBS. Luckily I found this article to help you out if you did start with a NOOBS image. You'll basically download the latest NOOBS Lite ZIP from the Raspberry Pi Foundation, mount your SD/MicroSD card on your PC or Mac, and copy everything except the "recovery.cmdline" file from the extracted NOOBS Lite ZIP. Follow the link to the article for the complete instruction for this step.
Cloning Your SD Card
These steps must be completed on your PC or Mac. Since I am a Mac user, I'll provide the procedure I use, which should also work under most (if not all) Linux and UNIX distributions. [Sorry Windows users, but I don't want to provide directions that I have not tried many times in the past.] And I am assuming that your Mac OS X user account already has sudo privileges.
Disclaimer: If you don't carefully follow these directions, you could cause irreparable damage to one of the drives connected to your Mac. Trust me, I speak from prior experience (when I didn't follow my own procedure, wrote a Raspbian image to the first several gigabytes of my backup hard drive instead of an SD card, and lost data as a result).
Start with all SD/microSD cards removed. Open the Terminal (located in Applications > Utilities) and issue the following command: diskutil list
This will result in a list of all of the currently mounted volumes. Plug in your source SD/microSD card (using a card reader if your Mac does not have one built in), and repeat the same command.
You'll notice that one new disk, /dev/disk3, appeared in the list after I inserted my SD card reader into a USB port on my Mac Pro. You'll need to unmount (NOT eject) this disk; the easiest method, since you have the Terminal open, is to issue the command diskutil unmountDisk <path to disk> (in my example, "<path to disk>" would be replaced with "/dev/disk3").
Once you have successfully unmounted your SD/microSD card, you can use the dd command to read the SD/microSD card image and write it to a file.
WARNING! The dd command can be your best friend and your worst enemy. It will read from the source specified by the if= parameter and write to the destination specified by the of= parameter, and it does not care if you accidentally specify your backup hard drive instead of your SD card. (Trust me, I'm speaking from personal experience as I did once accidentally use the wrong disk number in the of= parameter and very quickly overwrote the first 4GB of my backup hard drive instead of my SD card. dd didn't care.) Carefully check your command before hitting return!
[Review will continue here.]
