The Raspberry Pi is a great little board, and it still amazes me the huge range of things you can do with it. However, it's not without its limitations. One of these limitations is that it has no "real-time" clock. Sure, it has internal counters and the like, and when running under Linux it will keep pretty good track of time, and update its internal clock using NTP (Network Time Protocol) whenever it is connected to the internet. However, if it's not connected to the internet it has no idea what the time is.
I have some uses in mind for a Linux Pi on a local network, and this lack of time could be a problem, so I ordered a Real Time Clock (RTC) from CJE Micros. It arrived today, so I rushed to unpack and install it. As always, it was not quite a simple as it claimed...
The fitting instructions came on a double-sided black-and-white A5 sheet with a few grainy photos. The same instructions, and colour versions of the photos, are also available on the RTC fitting instructions page of the CJE website. The physical fitting was actually very easy - remove the supplied tiny battery from its packaging, plug it in to the RTC (making sure it is the correct way round) and the module is ready. Then it was just a matter of plugging it onto the first six pins of the GPIO header.
Next the instructions moved on to configuring Linux to use the RTC module rather than its own "soft" clock. The RTC page on the website claims:
Raspbian "wheezy" now supports the Real Time Clock (see fitting instructions above for how to enable this).
I stuck my Linux SD card into the Pi and botted it, then added the following lines to /etc/rc.local as instructed:
1modprobe i2c-bcm2708
2echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-0/new_device
3modprobe rtc-ds1307
4hwclock -s
I was doing this using vim (its not my favourite editor, but it is there when you need it) so there were a few hiccups and re-tries until I got it right. When I ran it, however, no result. Adding "-v" to various parts of the script gave a bit more output, but still no clock.
When I looked again at the instructions, I noticed that you apparently need a version of Raspbian "Wheezy" 2012-10-28 or later. Not being entirely sure of the version I have, I thought I might as well grab the latest so that I can have a clean OS for this project, without all the other junk I put on the original one. A quick hop to The Raspberry Pi download page and I had a torrent running to download it. The torrent transfer was actually very quick - it ended up taking longer to "burn" the image to an SD card than it did to complete the torrent download. I copied the archive, extracted the image and gave it to WinDiskImager to put on the card. I left the torrent running, as I always like to help out with worthwhile free products.
I put the new card into the Pi, and this is where it got tricky. As I have mentioned before, I run my Raspberry Pi "headless", so I plugged in the ethernet cable and started up my usual ssh session to log in. It was rejected with:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
Well, of course the ssh certificates have changed - it's a whole new operating system!
I tried again, and again using different ssh clients, but still with no luck. A bit more searching turned up that I could do ssh-keygen -R 192.168.0.205 to remove the existing entry for the Pi's IP address, and then ssh should allow me to accept the new certificate. When I tried it, it didn't work, it seemed to say there was a problem with the path to the known_hosts file. I'm not surprised, this is a Windows XP box, and my home directory has spaces in the names. However, it had pointed me at the correct file.
I backed up the existing file: cp ~/.ssh/known_hosts known_hosts.old then opened it in an editor to delete the offending line. When I tried ssh again it asked for confirmation, then accepted the certificates. Finally I was able to log in to the new installation. When I logged in it complained (as Raspberry Pi's do) about first time installation, so I went through that process, and was eventually ready to try setting up the clock again.
It failed again, with Cannot access the hardware clock via any known method. After a lot more head scratching, I finally spotted one sentence at the bottom of the back of the slip of paper:
It's important to note that if you are using a Rev2 Raspberry Pi then you need to replace i2c-0 with i2c-1
Of course, I happened to be running this on my revision 2 Raspberry Pi (the revision 1 board still has a LEDBorg plugged in to it). I made the change ans suddenly the error messages stopped and the clock was working. Unfortunately, though, it had now lost the date from NTP, and instead, claimed that it was "Sat Jan 1 01:23:28 UTC 2000". I'm guessing that this means I had spent and hour and 23 minutes messing around since I connected the battery trying to get it working. The solution was straightforward: date -s "Wed Jan 23 20:39:00 UTC 2013".
Having eventually spotted the problem, I was intrigued to see if I had needed to get a new Linux after all. I shut down the ssh connection and the raspberry Pi, edited ~/.ssh/known_hosts and added back the line from the backup file, so that there were now two lines for the same IP address. Starting up the Pi with the old card worked and let me log in, so I applied the corrections to the script and the clock was working on that one too.
In short, a lot of extra work, but I did end up with a working clock and a second clean Linux SD card to work with for future projects.