Dodgy SD card: more testing

Having used the cheapo “Class 10” microSD card for a bit with the Raspberry Pi 2, I decided to flash the card with another image, using “Disks”, and got the following screenshot:


Firstly, 17GB is a bit of a dodgy number for a 16GB card, so something definitely isn’t right there. Also, for a “Class 10” card, 6MB/s makes me think it’s actually Class 6.

Strange, I will have to investigate further!


Strange SD card!

I got a new 16GB “Class 10” microSD card from Amazon to try with the Raspberry Pi 2. I ran a speed benchmark and got this:


Weird! The card seems to be split somehow. Maybe I have a cheap knockoff card? We will find out!


Rasperry Pi: Disable screen blanking

If you have a Raspberry Pi connected to a screen using HDMI or Composite, you may notice that the screen will go blank after a while of inactivity:

Screenshot - 190315 - 18:05:11

Fortunately, there is a simple command that will disable this:

setterm -blank 0 -powerdown off

This will stop the raspberry pi from turning the screen off:

Screenshot - 190315 - 18:06:36

This is useful if you want to monitor the output of a long process, and I am currently compiling RetroPie from source in the screenshot above, so stay tuned for some RetroPie action on the Raspberry Pi 2! You can make this a permanent change by adding the command above into /etc/rc.local .

Be aware, though, that if you leave the same text on the screen for a long time, it can get burned into the screen:

So be careful!


Experimenting with OpenBroadcaster!

I have a (rather rubbish) USB capture card that I can use to record footage on the Raspberry Pi, and I have used it in the past to record games such as Descent (d1x-rebirth and d2x-rebirth). I had issues with directly recording footage from the card – the sound was recorded in Audacity from the Line-In jack and this meant that the video and audio never kept in sync properly. I needed a program that could interface with the USB card and record audio from the Line-In jack at the same time with perfect alignment. I found the best way to record was to use mplayer to directly view the card on the screen and then use SimpleScreenRecorder to record the screen – not ideal.

Step forward: OpenBroadcaster:

Screenshot - 170315 - 10:57:11It was able to detect the card with no issues and it was easy to add my logo and Line-In jack, as well as set up various “scences” that can be switched between quickly. I also experimented with Twitch streaming, which worked flawlessly. I could set up the proper resolution for recording very easily:

Screenshot - 170315 - 11:09:41

Also, a recent update fixed all the sound issues I was having before with d2x-rebirth:

Sounds very good, no skipping and jumping (running rpi-update to update the kernel fixed all that), and more importantly, the audio is in sync with the video!

I’ll definitely be using OpenBroadcaster more in the future, watch this space!


Directly connecting two Raspberry Pi’s with serial UART problems

I decided to try directly connecting two Raspberry Pi’s to each other to test out controlling one Pi with the other using simple bash commands that can be sent over UART.


The RX line of RPi 1 (the older Pi with the yellow jack) is connected to the TX line of RPi 2 (the new one with way more GPIO pins) using the black wire, and the opposite is done with the white wire to allow the other direction to talk. My logic analyser is connected using some small wires to the lines so I can monitor the communication. I could see bootup messages on RPi 2 coming from RPi 1, and eventually I got a login prompt. I am using screen /dev/ttyAMA0 to connect to the serial port:

Screenshot - 130315 - 17:38:46

However, there is a really weird problem that I am experiencing. RPi 2 will only send 16 characters before the whole screen session locks up with no way of regaining control. Here is what the logic analyser shows:

Screenshot - 130315 - 17:42:06

Screenshot - 130315 - 17:41:37

The terminal shows the 16 characters that were sent by RPi 2 to RPi 1 in the bottom chart, and the responses from RPi 1 are in the top chart. The decoded protocols at the side also show the 16 numbers I sent. No amount of button mashing gets more characters to display!

It is clearly a problem with the newer RPi 2 – htop running shows loads of data coming back over the UART receive line and also htop is present in the screen session:

Screenshot - 130315 - 17:57:41

Maybe I should try a lower baud rate? It is currently running at 115200, but this doesn’t seem to be a baud rate problem since all the data is getting across just fine, its just that the data stops after 16 characters.

I will try a lower baud rate, watch this space!


Raspberry Pi vs Raspberry Pi 2: Sysbench

My new Raspberry Pi 2 arrived today! I decided to get the Minibian version of Raspbian since I heard it was very quick and lightweight on resources (more on this later).
Left: original Model B. Right: Model B 2.

First things first, lets see how much of a performance improvement there is going from the Raspberry Pi 1 Model B. I will be running the following commands on both Pi’s:

sysbench --test=cpu --cpu-max-prime=20000 run
sysbench --test=cpu --cpu-max-prime=20000 --num-threads=4 run


  • Raspberry Pi: 1309.3046s (single thread), 1312.3089s (multi thread)
  • Raspberry Pi 2: 1170.6629s (single thread), 293.6215s (multi thread)

So, from these results it can be seen that there is a 11% improvement in performance in single threaded applications and throwing four cores into the mix improves performance by 4.4x in this case.

Stay tuned, more benchmarks and details coming soon!


Coming soon: Extensive testing of the Raspberry Pi 2!

I have the sequel to the Raspberry Pi on its way to this site – so follow on Google+/RSS/WordPress!



Raspberry Pi: Increase UART speed

The Raspberry Pi has an on-board UART port attached to the GPIO pins. This is useful if you want to send serial data out through a UART to another device (such as a PC etc). The Pi comes shipped with the UART set to 115200 baud (or 14.4 kB/s), which is “fast”, but we can go faster!

I will be using a logic analyser to determine the maximum possible baud rate that the Pi can reliably output. I’ll be sending out a capital “U”, which corresponds to 85 in ASCII, which then sends 1010101 to the output, looking like a square wave:

echo -n U > /dev/ttyAMA0

Screenshot - 250115 - 23:31:16

The frequency recorded for this square wave was 57.62 kHz. The UART speed was also reported as 115200 by the logic analyser software. The letter U was also decoded properly. In the following captures, measurements are taken and displayed just above the waveform. “W” means how long the character took to send, “f” means the number of characters per second that can be sent, and “<f>” represents the averaged frequency of the square wave.

Screenshot - 250115 - 23:33:50

You can use the following command to change the UART speed on the fly:

sudo stty -F /dev/ttyAMA0 115200

For example, if we set it to 110 baud (13.75 bytes/second):

Screenshot - 250115 - 23:39:01

The average frequency now becomes 54.99 Hz, more than a thousand times slower. This means only 12.2 characters would be sent every second, as opposed to 12.8 thousand per second with 115200 baud. It would take over 20 hours to send a 1MB (1,000,000 bytes) text file over this link (at 13.75 bytes/sec). But we don’t want to go slower, we want to go faster!

So lets punch in the next baud rate level over 115200 into the Pi:

sudo stty -F /dev/ttyAMA0 230400

But we get:

stty: /dev/ttyAMA0: unable to perform all requested operations

We need to edit the /boot/config.txt file to enable higher speeds! Add the following line to the bottom of the file:


Reboot the Pi and try setting the baud to 230400 (28.8 kB/s) again. It should work straight away, and here is what the logic analyser has to say:

Screenshot - 250115 - 23:53:05

Great! The average frequency is now 115.4 kHz, double what we had as the default baud rate. We can now send 25.6 thousand characters per second. That 1 MB file we mentioned would take 34.7 seconds to transfer (still very slow by today’s standards). But can we go even faster?

The standard baud rates double in speed, from 115200 to 230400, then 460800, then 921600. After that, it follows subdivisions of 3,000,000, so the next would be 1,000,000, then 1,500,000, 2,000,000, etc.

Here are the scope shots of each baud rate as I increase it:

460800 (57.6 kB/s):

Screenshot - 260115 - 00:09:27

Average frequency 229.7 kHz, 1 MB would take 17 seconds.

921600 (115.2 kB/s):

Screenshot - 260115 - 00:13:22

Average frequency 459.3 kHz, 1 MB would take 8.6 seconds.

1,000,000 (125 kB/s):

Screenshot - 260115 - 00:15:40

Average frequency 500 kHz, 1 MB would take 8.0 seconds.

1,500,000 (187.5 kB/s):

Screenshot - 260115 - 00:21:10

Average frequency 750 kHz, 1 MB would take 5.3 seconds.

2,000,000 (250 kB/s):

Screenshot - 260115 - 00:23:40

Average frequency 1 MHz, 1 MB would take 4 seconds. Getting faster with 222.2 thousand characters sent per second!

2,500,000 (312.5 kB/s):

Screenshot - 260115 - 00:33:09

Average frequency 1.263 MHz, 1 MB would take 3.2 seconds. Nearly 300k characters per second!

3,000,000 (375 kB/s):

Screenshot - 260115 - 00:36:25

Flippin heck, average frequency 1.5 MHz, 1MB would take 2.6 seconds.

3,500,000 (437.5 kB/s):

Screenshot - 260115 - 00:41:58

Jeeeeez, average frequency 1.745 MHz, 1MB would take 2.3 seconds. Just shy of 400k characters per second!

4,000,000 (500 kB/s):

Screenshot - 260115 - 00:41:58


Okay, 2 MHz average frequency, 1MB would take 2 seconds, and over 444k characters per second!

However, there’s a snag at these speeds:

Screenshot - 260115 - 00:51:16

As you can see, the UART stutters and causes gaps to appear. This may be an issue if you have equipment sensitive to this effect. This was the highest I was able to set the UART speed to, anything higher refused to work.

Looking back, I found that 2,000,000 baud was quite stable, but I could trigger off gaps above 1 microsecond once every so often, so it still exhibits some instability. 1,500,000 proved to be *almost* rock-solid, taking a really long time until a gap 100 nanoseconds longer than the waveform period. 1,000,000 was perfect though, with no gaps seen at all!

So for pure data transfer, crank it all the way up to 4,000,000. If you need stability though, don’t go above 1,000,000!


Enable SPI and/or I2C on Raspberry Pi

So you want to enable SPI and/or I2C on the Raspberry Pi, if you want to work with other electronics through the GPIO.

To enable these services, you need to edit the following file:

sudo nano /etc/modprobe.d/raspi-blacklist.conf

Comment out either/both of the lines as shown below to enable which services you want:

Screenshot - 160115 - 03:03:18

Use ctrl-O to save the file, and then reboot!


As you can see, there is now activity on the I2C and SPI pins on the Pi!




Descent 2 on the Raspberry Pi

I just finished installing DX2-Rebirth on the Pi, but whilst the game ran smoothly graphics-wise, the sound had serious issues:

Please let me know if there are any fixes for this!