Remote monitoring Raspberry Pi 2 CPUs

I wanted to visualise of all those CPU cores on my new Raspberry Pi 2, so I decided to build a remote CPU monitoring webserver. The idea is to serve a webpage showing the percentage use of the CPU cores in a nice scrolling graph. Another idea I wanted to try was to keep all the HTML and JavaScript files embedded in the executable. So you only need the single binary program file. It means you just run the program without having to worry about putting supporting files in a particular place.

I'm hopeful that because it's lightweight and written in C the program itself won't consume many of the Raspberry Pi's resources. If you wanted, you could probably run the program as a service when the machine starts and not notice any difference. The CPU data is sent from a minimal Web API, which is built into the webserver. It sends out the CPU percentages as an array in JSON format. This means that most of the work is done by the browser (all the plotting and scrolling) and on the server side we just need to send an array of numbers every second or so. And whilst I was at it, I also included the ability to monitor the core temperature (if it is running on a Raspberry Pi).

I have put the resulting project on GitHub, so if anybody wants to have the ability to monitor their CPU cores over their network they can try it. I expect it will work on other Linux machines too, it's not restricted to the Raspberry Pi. The number of graphs is dynamically updated, depending on the number of cores you have.

This is how it looks (in this case showing the graphs on a simulated iPhone 4s):

If you want to, you can try it out like this:

git clone
cd rCPU/rCPU
sudo ./rcpu 80

...which will only work if you're not running an existing webserver on the machine, otherwise substitute the 80 on the last line for a different port. When the server is running, simply point a browser at your machines IP address (and port if its different than 80) and enjoy.

I did notice that the graphs don't plot very nicely on the default browser included with Raspbian (although if you install an alternative like Chromium it should be OK). But since the purpose is to monitor the CPUs remotely this should not really be an issue.

Recovering a slightly broken Vocore

OK, I managed to mess up the network settings on my Vocore. Oh well, it happens. It's not too bad... the device was still booting up and running... but was not accessible by Wi-Fi or by plugging in a network cable. So it's back to a good old serial connection. This is what I have done:

I've used a USB to Serial 3.3v TTL cable that I already had, and then just poked some jumper wires into the right places. Surprisingly it seems good enough. Anyway, in case I need to do this again, I thought that it would be worth taking a photo. I'm using PuTTY on a Windows box as the terminal. The settings I'm using are:

  • Speed: 57600
  • Data bits: 8
  • Stop bits: 1
  • Parity: None
  • Flow control: XON/XOFF

I connected the USB-to-serial cable first, then opened the connection using PuTTY. You then have a blank terminal screen. Then I connect the power to the Vocore, and you get to see all the logging information as the device boots. After a couple of minutes I press enter in the terminal and end up with the usual OpenWrt startup screen. After that you can use the console like normal. Anyway, it's handy to have that written down somewhere, because I'll probably break it again at some point. But I can report that I was able to fix the network config and things are back to normal now. Phew.

New Raspberry Pi 2

So, I ordered a new Raspberry Pi 2 as soon as they were launched last week. When it arrived, I couldn't resist documenting the occasion:

Last weekend I booted it up and started having a play. It seems quite an impressive little computer.

But since I had never bothered to order a B+ model I've only been using the 'original' Raspberry Pi until now, and I had forgotten that I need a microSD card these days. But I did have one lying around, so that was OK. I used a cheap HDMI to VGA adapter to use an older monitor.

The other thing I noticed was that I needed a better power supply. In the past I was using a kindle charger... but I needed to borrow the charger from my hudl tablet to get 5v at 2A. Otherwise, there was a little rainbow square showing at the top right of the screen to indicate that the device wasn't getting enough power. So watch out for that.

By the time I had finished messing around, my workbench looked like this:

1980s Synth Music

I recently watched a BBC programme called “Synth Britannia” … after which I ended up adding a bunch of extra stuff to my Spotify collection. When I was going through the OMD back catalogue on Spotify, I noticed the album cover artwork for their “Dazzle Ships” LP from 1983. And I was pretty sure that I had actually bought that album back in the 1980s. So I had a dig around the house and actually found it. So rather than put it back into storage, I’ve put it on my wall for a bit:

Apparently, I bought the 1987 reissue, which makes sense because I would have been too young in 1983. It’s also interesting, because people say that nobody bought the album when it originally came out anyway. There’s also a wikipedia article, if you’re interested.

A couple of little Chromecast tricks

A neat trick I've been using with a Chromecast is to wirelessly play movies from my iTunes library from my MacBook onto my big TV. All you need to do is enter the following URL into google Chome: file:///users/[username]/Music/iTunes/iTunes%20Media/ (obviously substituting your username where indicated). You'll then be able to browse your iTunes stuff and play what you want inside Chrome ... which makes it easy to watch it on the Chromecast using the normal Chrome plugin.

If you've seen a Chromecast, you've probably noticed that there are some nice background photos to look at. But I've also discovered that you don't *need* a Chromecast to see them. Try pointing your browser to: and you'll be able to see them on any device...

Vocore: mounting USB drives

So my next piece of work on the Vocore was to mount the filesystem from a USB stick. I found some instructions here. So I started adding all the necessary kernel modules, hoping that it would be as simple as getting the USB soundcard to work. It wasn’t quite that easy. I thought that I had done everything, but just got strange messages when I tried to mount the disk. Then I found this helpful link.

It described exactly what I was seeing. In short, you can’t rely on the error messages being returned by mount on OpenWrt. So to diagnose the problem, the most important thing was using the logread command to get some ideas why the USB drive was not mounting. In my case (I was mounting a vfat formatted thumbdrive) I needed to add support for Codepage 437 and ISO 8859–1 into the kernel. So when building OpenWrt, I needed to go into Kernel Modules -> Native Language Support, like this:

But both those character set problems were quite clear from the log entries, so working out what I needed to do wasn’t that difficult … once I knew that I should not trust the error messages being returned by mount.

And I did find some more detailed information about filesystems and character set problems here … albeit for a different type of device, but I think the principle is the same.

Anyway, as soon as I added the extra modules for the correct character sets then everything came to life and I could mount the USB disk. Happy days. So now I can play audio files from USB storage, which works great.

This is a journey into sound...

So I decided to try and get some sound out of my Vocore tiny linux box. It doesn’t come with any audio support, so I decided to add a USB sound card. I bought one of these, which I knew worked on the Raspberry Pi, so I knew had Linux support. They’re also pretty small:

I simply followed these instructions describing how to add USB Audio support to OpenWrt. At first, I chose to install sox as the player (I originally intended to use Madplay, but I don’t think it is supported on current versions of OpenWrt anymore).

I did not have much success playing mp3 files straight away, I kept getting sox WARN alsa: under-run messages when I tried to use the following command:

sox myfile.mp3 -d

Although sound was coming out … in chunks, so it was a partial success. But when I added a “-G” parameter to use temporary files (supposed to guard against clipping) like this:

sox myfile.mp3 -d -G

…then it worked fine for some lower quality mp3 files, but with a considerable delay before playing anything out the speaker. If I tried to play some better quality mp3 files then it was still stuttery. So then I started to experiment with reducing the sound quality, which sox can do easily. So I tried this:

sox myfile.mp3 -r 8000 -e unsigned -b 8 -c 1 test.raw

…which results in a raw file that can be played with the aplay command that comes with the ALSA soundcard drivers (specifically, the command above gives mono unsigned 8 bit with a rate of 8000 Hz). Whilst this results in a poor quality file, I found that the Vocore would happily play these raw files. In some ways it was kinda cool to hear my original mp3 file playing with a hiss in the background. But then I decided to see what happens if I create a file in “CD” quality, so I tried this:

sox myfile.mp3 -r 44100 -e signed -b 16 -c 2 test.raw trim 0 00:30

Note, that to save space on the Vocore I used the trim parameter to just convert the first 30 seconds. Playing that “CD” quality file on the Vocore also worked perfectly, with this command:

aplay test.raw -f cd

Passing the parameter -f cd means 16 bit little endian, 44100 Hz, stereo and is the same as passing -f S16_LE -c2 -r44100. Here’s a screenshot of a CD quality raw file playing on the Vocore with the aplay command.

So… what I’m doing now is using sox on another Linux box to convert the mp3 files and then just using aplay on the Vocore to play them. It should mean that sox is not actually required on my Vocore. It also means that playback is immediate and the quality is good. I will need to find a means to store the files, because they’re much bigger than mp3, but that’s a problem for another day… I’ll probably see if I can mount a USB stick or something.

Another lightweight webserver for the Vocore

Qin Wei, the inventor of the Vocore has written his own lightweight web server. But I haven’t tried it out personally, because I have been messing about with my own minimal webserver as well.

Actually, one of the reasons why I have been working on my own web server is so that I could run it on minimal hardware - the Vocore being a good candidate. So it goes without saying that I have been itching to try that out.

I already did a trial run some months ago, where I got it running on OpenWrt for some different hardware. So the procedure for the Vocore is pretty much the same. I’ve made it slightly easier, because the makefile now has a target called ‘openwrt’ which will do the cross-compilation. I guess it should work for whatever device your OpenWrt build environment has been configured for, but I’ve only tried it for the Vocore.

Anyway, I’ve just got to the point where I have had time to try it out. I still needed to install the POSIX thread library, by using these commands on the Vocore:

opkg update
opkg install libpthread

And after that I was able to run dweb without any problems, like this:

Even the ajax calls back to the Vocore were working, which means that I could build something to control the GPIOs through javascript in the browser, if I wanted. But in the meantime, I decided trying to serve up some of the system statistics, so I did this:

cd /dweb
ln -s /proc/stat stat.txt

Which makes the contents of /proc/stat available to the webserver, and meant that I could browse to /stat.txt and view the contents of /proc/stat in my browser. I thought that was an interesting little experiment.

LED blink program for Vocore + Dock

Having gotten one of the Vocore’s LEDs to blink from the command line, I decided that a simple C program to do the same thing would be useful, just to make sure that the cross-compiler has been set up correctly and that everything is working properly.

Having a program that just blinks an LED is pretty useful, just to verify that you can successfully run your code. If you’ve managed to cross-compile a test program like this, then copy it to the target hardware and see it working - then you can start building whatever you like with a degree of confidence.

So I’ve put the code for the Vocore blink program on GitHub just in case… NOTE: it’s designed to work without any additional electronics if you have the dock attached.

The project includes a simple Makefile which (hopefully) should work in most cases. As long as you have an OpenWrt build environment set up for the Vocore you should just be able to type make and you will then have the program cross-compiled and ready to be copied onto the device. Doing something like: scp ./blink root@ should copy the program over to your Vocore. Once you’ve done that, you just need to ssh into the Vocore and run it.

Oh, you’ll probably need to make sure that the program has been marked executable with chmod, otherwise you’ll probably get a Permission denied message. I used chmod +x blink to do that.

Vocore has arrived

My tiny Vocore Linux machine has arrived from China. Cool! So far all I have not done much more than boot it up and check that I can log in and stuff. Oh, and I tried the web-based interface too. It seems to be working fine. A Linux box about the size of a postage stamp, what’s not to like?

Mine has the dock attached to it, so I’m just using a USB cable to power the device. I tried to power it off a USB socket on my MacBook … but there wasn’t enough current to allow the wifi to start. Some lights flashed on the Vocore initially, but then it went off a few seconds later. I think that this means that there is not enough current to allow the wifi to start operating… But when I ran it of a dedicated USB power supply it was fine.

Because I have the dock, I used an ethernet cable to connect to the Vocore, which means my laptop can remain connected to my home wifi and I can still use the Vocore with its default settings.

But when sitting in front of the command prompt I got as far as making some LEDs go on and off with commands like these:

echo 255 > /sys/devices/gpio-leds.5/leds/vocore:green:status/brightness
echo 0 > /sys/devices/gpio-leds.5/leds/vocore:green:status/brightness

The advantage of doing that is that they use an LED which has already been connected up on the dock … so I didn’t need to wire anything up. I’m going to try the same thing in a little C program next. Blinking an LED is an ideal little test program

The next thing that I’ll do is try my own minimal webserver, which might be useful if I start running out of space. So that’s next on my agenda.

Apart from that, I’m not really sure what I’m going to use it for. I’m sure I’ll think of something...