Monsoon

In the desert it almost never rains. I know, you know. When I lived in upstate New York, in my foolish youth, I bought a motorcycle in the beginning of April. I was anxious to learn to ride. Too bad, because it rained every day for an entire month. Now I live in New Mexico. Two years ago we had not one drop between the end of December and July.

Where you live the weather turns with a unique step. Here, the summer breaks in July when the monsoon comes. Moist air from the Gulf of California and the Gulf of Mexico flow north over the state and give rise to afternoon thunderstorms. It is the most beautiful weather of the year here. The clouds rise miles—literally—into the sky and continuously billow in fractal glory.

Last week I configured my Raspberry Pi computer with its PiCam to take time-lapse video out my back window. The view is to the east over the Sandia Mountains. I took pictures about every six seconds from 10:30 am until dark, around 8:30 pm. The whole day compressed into four and a half minutes. The best video was from July 14, others are below.

It is hard to understand the desert if you have never lived in one. In the picture below you can see what it would be like if Leeds were in Albuquerque. A nation that ruled the world for a few hundred years fits comfortably in the desert southwest.

The rest of the videos I created are here, with the most interesting at the top.

July 11

July 13

July 8

July 7

July 10

July 16

July 15

Candle Flame Flicker

For a project I wanted to make an LED flicker like a candle. I searched for the signal statistics of candle flicker, and I found no data. One student web site suggests that candle flame flicker is a 1/f-type random signal with roll-off of 20 dB per decade increase in frequency. Similar processes are typical for turbulence, so this student’s plan seemed reasonable. However, the student did not discuss whether the signal is Gaussian or not, and did not describe the low-frequency characteristics of the signal. 1/f noises may have a spectrum that follows the 1/f curve to very low frequencies, but because they would require infinite power at f=0 they always have some lower frequency change. I had no data.

Candles aren’t hard to get, and I already had a silicon photodiode for an absorptive smoke density measurement system I’m working on. I also had an analog-to-digital converter (ADC) in an ADS1015 on a breakout board from Adafruit. I made the very simple circuit shown below and attached it to a Raspberry Pi to sample the data. There are a lot more details, but those are later.

The voltage measured by the ADC is directly proportional to the current through the resistor. The current through the reverse-biased diode is directly proportional to the incident optical power. Very simple. I recorded a minute of data at a low 250 Hz sample rate, and subjected the data to analysis. The setup was a nominally dark room with the sensor a few inches from the flame. I flapped my hand at the candle to get it to flicker while recording.

The first graph below is a histogram of sample values.

The histogram is about normally distributed, but the right-hand tail is not Gaussian; it is too fat. In other words the candle is occasionally much brighter than normal. The time series (below) shows the same properties. There are clearly visible large excursions.

For human eyes the candle’s flicker will be well represented if the frequency spectrum of the flicker and the distribution of the flicker approximately match a natural source. The spectrum below can be thought of as an average brightness (the peak at the left), a flat spectral region out to about 4 Hz, and then a 1/f-style roll off at 44 dB per decade.

Numerically, we have the recipe for a flickering candle:

• Samples should be normally distributed with a standard deviation equal to 0.25 of the mean.
• The power spectral density of the signal should roll off at about 40 dB per decade with a 3 dB cutoff frequency around six cycles per second.

To make this work on the Arduino using the pulse-width modulated outputs, we can further constrain the problem:

• The maximum value cannot exceed 255 counts—or make the limit that the mean plus two standard deviations is 255.
• From this, we can derive that 2s+m = 255, use the fact that 0.25m=s to find that the mean m=170 and the standard deviation is about 42.
• A sample rate of between 30 and 120 Hz should be more than adequate to satisfy the Nyquist criterion for human vision (see Wikipedia).
• Values may not go below zero or above 255
• A second-order infinite impulse response (IIR) filter has a roll-off of 40 dB per decade

If we can find a numerically efficient way to generate a time-series of Gaussian random variables inside the Arduino, filter them with a 2nd-order fixed-point IIR, scale them (if needed) then we should be able to make a flickering candle.

Unfortunately, I have failed repeatedly to get a stable fixed point IIR filter. The cookbook solution specification above should be easy to implement, but I have not found it so. A better solution will have to wait for another post.

Raspberry Pi Character LCD Degree Symbol

It is inevitable that you will want to write the degree symbol to your 16×2 character LCD once you have it wired to the Pi. My son wired it up, and then wanted to display the degree symbol. In the past I have solved that problem for the Arduino using the Adafruit character LCD Arduino library createChar() function. Relatively painless for the Arduino. Unfortunately, the Adafruit LCD library for GPIO not using i2c does not have an equivalent of the createChar() function. Sad.

The solution turns out to be easy. You rely on the fact that the LCD already has a degree symbol built in, and then use the write4bits() function to display it. There are other characters available, I found mine here. Here is our code.

# This is the process of importing the Adafruit library

os.system('modprobe w1-gpio')
os.system('modprobe w1-therm')

temp_c = 23.1
temp_f = 32. + temp_c*9./5.

lcd.clear()
lcd.message(&quot;temp C&quot;)
lcd.write4bits( 0xDF, True)
lcd.message(&quot;: %.1fn&quot;%temp_c)

lcd.message(&quot;temp F&quot;)
lcd.write4bits( 0xDF, True)
lcd.message(&quot;: %.1f&quot;%temp_f)



Revised Raspberry Pi TrueCrypt Benchmark

Revised March 31, 2013 with updated benchmarking approach that uses actual access to the mounted volume. New results show no appreciable sensitivity to hash, which is as expected. The numbers are for encryption only (write). I have not pursued read.

 Hash Algorithm Encryption Algorithm Rate (MB/s) SHA-512 Twofish 2.8 Whirlpool Twofish 2.8 RIPEMD-160 Twofish 2.8 SHA-512 Serpent 2.6 Whirlpool Serpent 2.6 RIPEMD-160 Serpent 2.6 Whirlpool AES 2.1 RIPEMD-160 AES 2.1 SHA-512 AES 2.1 SHA-512 Twofish-Serpent 2.0 Whirlpool Twofish-Serpent 2.0 RIPEMD-160 Twofish-Serpent 1.9 SHA-512 AES-Twofish 1.6 RIPEMD-160 AES-Twofish 1.6 Whirlpool AES-Twofish 1.6 Whirlpool Serpent-AES 1.6 SHA-512 Serpent-AES 1.6 RIPEMD-160 Serpent-AES 1.6 Whirlpool AES-Twofish-Serpent 1.3 Whirlpool Serpent-Twofish-AES 1.3 SHA-512 Serpent-Twofish-AES 1.3 SHA-512 AES-Twofish-Serpent 1.3 RIPEMD-160 Serpent-Twofish-AES 1.3 RIPEMD-160 AES-Twofish-Serpent 1.3

Shell Script for Timing


#!/bin/bash

# Create a file of random elements, needs to be at least 300 bytes
dd if=/dev/random of=random bs=512 count=1

# Iterate over the hash hash funnctions
for HASH in RIPEMD-160 SHA-512 Whirlpool
do
# Iterate over the available encryption algorithms
for ENCALG in AES Serpent Twofish AES-Twofish AES-Twofish-Serpent Serpent-AES Serpent-Twofish-AES Twofish-Serpent
do
# Write the algorithms to the log
echo &quot;Algorithms: $HASH$ENCALG&quot; &gt;&gt; log
# TrueCrypt will report the performance in the output
truecrypt -c /home/pi/test.tc --filesystem=fat --size=10485760
--encryption=$ENCALG -p ppp --random-source=random --hash=$HASH --volume-type=normal --non-interactive
# Mount the partition
truecrypt --non-interactive -p ppp -m nokernelcrypto test.tc /home/pi/tcvol
(time  ./timeit) 2&gt;&gt; log
truecrypt -d /home/pi/tcvol
# Erase the created file
rm test.tc
done
done



Timed Routine


dd if=/dev/zero of=tcvol/test bs=5242880 count=1 &amp;&gt; /dev/null

sync



Python Reprocessor


import sys
fid = open( sys.argv[1], 'r')
fid.close()

tsecs = None
while len( lines) &gt; 0:
line = lines.pop(0)
lls = line.strip()

if lls.startswith( 'Algo'):
# If we already have a tsecs, then print
# the last elements
toks = lls.split()
if tsecs == None: # first record
algo = &quot;,&quot;.join( toks[1:3])
else:
print algo,&quot;,&quot;,tsecs
algo = &quot;,&quot;.join( toks[1:3])
elif lls.startswith( 'real'):
toks = lls.split()
toks = toks[-1].split('m')
tsecs = float( toks[0])*60 + float( toks[1].replace('s', ''))

print algo,&quot;,&quot;,tsecs



Raspberry Pi TrueCrypt Benchmark

Note: The results in this post have been improved with more accurate values at Revised Raspberry Pi TrueCrypt Benchmark.

I recently acquired a Raspberry Pi model B 512 MB from the excellent people at Adafruit. I am interested in it as a small computer for basic text processing, and am curious about its performance in consumer crypto. One part of the security of the Pi, or any modern computer, is disk encryption.

My disk encryption of choice is TrueCrypt, mainly because it is cross-platform. That it is also free and open source is a nice benefit, though the TrueCrypt3 license may not rise to Stallman’s standard. I found several posts from persons who compiled TrueCrypt on the RasPi, and it is relatively trouble free. At the bottom of the post are my notes on how I did the install and a script that performs the benchmarking.

While I don’t understand the relationship between the hashing function and the encryption function, I expected that speed would be unrelated to the hash algorithm. This was not what I experienced, as shown in the data below.

Performance, in MB seconds, as TrueCrypt reports for initializing a 10,000,000 byte file.

 Hash Encryption Speed (MB/s) RIPEMD-160 Twofish 3.4 RIPEMD-160 Serpent 3 RIPEMD-160 AES 2.5 SHA-512 Twofish 2.5 RIPEMD-160 Twofish-Serpent 2.3 SHA-512 Serpent 2.2 SHA-512 AES 2 RIPEMD-160 AES-Twofish 2 RIPEMD-160 Serpent-AES 1.9 SHA-512 Twofish-Serpent 1.8 SHA-512 AES-Twofish 1.6 Whirlpool Twofish 1.6 RIPEMD-160 AES-Twofish-Serpent 1.5 Whirlpool Serpent 1.5 SHA-512 Serpent-AES 1.5 RIPEMD-160 Serpent-Twofish-AES 1.5 Whirlpool AES 1.4 SHA-512 AES-Twofish-Serpent 1.3 SHA-512 Serpent-Twofish-AES 1.3 Whirlpool Twofish-Serpent 1.3 Whirlpool AES-Twofish 1.2 Whirlpool Serpent-AES 1.2 Whirlpool Serpent-Twofish-AES 1 Whirlpool AES-Twofish-Serpent 0.934

The upshot is that all of these are pretty slow, and all of them would be essentially unnoticeable for basic text file (or RTF) work. I wouldn’t want to do image or audio processing with this encryption, but then I wouldn’t want to do that on a Pi anyway.

Method of Speed Assessment

I wanted a non-interactive way to perform the test, so I wrote this script. I am relying on the data reported by the TrueCrypt volume creation process. Because TrueCrypt writes a status to the terminal it produces output that is dreadful to process, so I wrote the little python script to produce a CSV from the log.

The test was performed with an ARMv6 compatible processor rev 7 (v61) at 464.48 BogoMIPS. The OS is Debian GNU/Linux 7.0 (Wheezy), which was installed as the 2013-02-09-wheezy-raspbian image. I built TrueCrypt from source for 7.1a along with wxWidgets 2.8.12 (also built from source) and pkcs version 11.2.

Shell Script

#!/bin/bash

# Create a file of random elements, needs to be at least 300 bytes
dd if=/dev/random of=random bs=512 count=1

# Iterate over the hash hash funnctions
for HASH in RIPEMD-160 SHA-512 Whirlpool
do
# Iterate over the available encryption algorithms
for ENCALG in AES Serpent Twofish AES-Twofish AES-Twofish-Serpent Serpent-AES Serpent-Twofish-AES Twofish-Serpent
do
# Write the algorithms to the log
echo “Algorithms: $HASH$ENCALG” >> log
# TrueCrypt will report the performance in the output
truecrypt -c /home/pi/test.tc –filesystem=fat –size=10485760
–encryption=$ENCALG -p ppp –random-source=random –hash=$HASH –volume-type=normal –non-interactive >> log
# Erase the created file
rm test.tc
done
done

Python Reprocessor

import sys
fid = open( sys.argv[1], ‘r’)
fid.close()

speed = None
while len( lines) > 0:
line = lines.pop(0)
lls = line.strip()

if lls.startswith( ‘Algo’):
# If we already have a speed, then print
# the last elements
toks = lls.split()
if speed == None: # first record
algo = “,”.join( toks[1:3])
else:
print algo,”,”,speed
algo = “,”.join( toks[1:3])
elif lls.startswith( ‘Done’):
toks = lls.split()
speed = “,”.join(toks[-5:-3])
print algo,”,”,speed