Author Archives: ghp_Ar7p

Preparing Raspbian Images on Headless System

Annual school preparation needs to prepare some SD card with most current software, the current tutorials and some specific setup for scratchClient software.

There is standard answer you get when asking for the best procedure doing this: clone images using linux ‘dd’ tool.

Unfortunately this does not work when there are a SD cards which differ in size. And nevertheless it is needed to have a reference setup somewhere on a (laptop)-computer which allows to copy the data at least to one of the cards. So I decided to set up the SD card images using a headless PI and no manual operations on the target device.

This article shows some details about the scripting used.

Basic Procedure

The basic procedure is

  • prepare the data (tutorials, custom config, software) in a file system on a remote computer.
  • have sd cards with off-the-shelf raspbian prepared. WinDiskImager is used to prepare these. Which is a quick procedure, as these images are typically around 3GB in size.
  • Insert sd car into pi, power and start script.
  • Write some blog about scripting SD card setup.


The automation of these tasks is performed in ‘ant’. SSH access and SCP are essential for controlling the remote raspberry.
Ant is available standalone. As I use ‘eclipse’ on a laptop for most of my programming tasks, ant is easily available.

The host computer controls a PI by ssh commands. This Pi is connected by network. The local DHCP-Server assigns fixed IP address to this Pi. One card after the other is inserted into the SD slot, Pi gets power and the script is started on laptop.

Script desription

In the script, first step is to get root access from remote. In earlier releases of raspbian < mai 2016, it was possible to create root user and have root access through ssh. In current releases, the /etc/ssh/sshd_config does not allow root user access by password. The setting ‘PermitRootLogin’ does not allow this. The workaround is to use key based authentication. The keys need to be copied to the target system first.

<antcall target='passwd.root' />
 <antcall target='key.deploy.pi' />
 <antcall target='key.deploy.root' />

Creating the root user can be performed by standard pi user. A shell file is created locally, transferred to target and executed there.

    <target name="passwd.root">
        <echo file="">
            <![CDATA[passwd root <<EOF
        <scp_l2r_pi local="" remote="/home/pi/" />
        <delete file="passwd.root" />

        <ssh_exec_pwd_pi command="sudo sh" />
        <ssh_exec_pwd_pi command="rm" />

The commands scp_l2r_pi (scp local 2 remote, user pi) and ssh_exec_pwd_pi (ssh exec, passwort authentication, user pi) are macro definitions which hide all the details .

    <macrodef name="scp_l2r_pi">
        <attribute name="local" default="NOT SET" />
        <attribute name="remote" default="NOT SET" />
            <scp remoteTofile="${pi.user}:${pi.password}@${}:@{remote}" file="@{local}" failonerror="true" verbose="${verbose}" trust="yes" />
    <macrodef name="ssh_exec_pwd_pi">
        <attribute name="command" default="NOT SET" />
        <attribute name="failonerror" default="true" />

            <sshexec command="@{command}" failonerror="@{failonerror}" host="${}" username="${pi.user}" password="${pi.password}" trust="yes" />

Similiar macros exist for key authentication, which is possible for root when ssh keys are available and root user is created.

The key distribution is done with password authentication and pi-user access only.

    <target name="key.deploy.pi">
        <ssh_exec_pwd_pi command="[ -d /home/pi/.ssh ] || mkdir /home/pi/.ssh" />
        <scp_l2r_pi remote="/home/pi/.ssh/authorized_keys" local="key/" />

    <target name="key.deploy.root">
        <scp_l2r_pi remote="/home/pi/authorized_keys" local="key/"  />
        <ssh_exec_pwd_pi command="echo '${root.password}' | sudo -S mkdir /root/.ssh" failonerror="false" />
        <ssh_exec_pwd_pi command="echo '${root.password}' | sudo -S cp /home/pi/authorized_keys /root/.ssh/authorized_keys" />

The root file deployment is done into a pi-user file first. Then with copy commands, the transfer into the target dir is performed. Here ‘sudo’ is needed.

raspi-config non interactive

The tool ‘raspi-config’ assembles all the knowledge about the config files and settings needed to tweak the system. Since some time > mai 2016, there is a command line switch allowing to use the tool from command line. There is no documentation, but the programming is straightforward. Here the code to set serial (off) and to spi (on).

    <target name='set_serial' description="disable serial">
        <echo>set Serial off</echo>
        <ssh_exec_key_root command="raspi-config nonint do_serial 1" />

    <target name='set_spi'>
        <echo>set SPI on</echo>
        <ssh_exec_key_root command="raspi-config nonint do_spi 0" />

The parameters ‘0’ and ‘1’ are opposite to their human meaning, but these values are found inside the script. So ‘do_serial 1’ switches serial line off.

    <target name='set_overclock_high'>
        <!-- High is both available on pi 2 and pi 3 -->
        <ssh_exec_key_root command="raspi-config nonint do_overclock High" />

For completeness also the scripting for the overclock setting.

Update system software

One of the basic steps is the update of the system.

            <echo>Packages aktualisieren</echo>
            <ssh_exec_key_root command="apt-get update" />
            <ssh_exec_key_root command="apt-get upgrade -y" />

Transfer of data, code, config

Finally, the transfer of the tutorials, software and all the other things is done. Compared to the overhead needed a quite short task.

                <echo>copy tutorials and other</echo>

                <scp failonerror="true" verbose="${verbose}" todir="${root.user}@${}:/home/pi" keyfile="${basedir}/key/id_rsa.root" trust="yes">
                    <fileset dir='data'>
                        <include name='**/*' />
                <ssh_exec_key_root command="chgrp -R pi /home/pi/" />
                <ssh_exec_key_root command="chown -R pi /home/pi/" />


Time measurements

The execution time of the script is dependent on the amount of packages downloaded from the web into the computer. For this setup, the raspbian distribution is from mai 2016 and the setup time was sept 2016, so quite a lot of packages needs to be updated.

target system overclock SD card time
PI 2 no 6MB/s 41 min
PI 2 fast 6MB/s 38 min
PI 3 fast 6MB/s 24 min
PI 3 fast 16MB/s 15 min


With automation by ‘ant’, SD cards are set up using a headless pi installation and no manual interaction.


Door closing speed analysis

The entry door in the house I live has an automatic door closer, which started to close the door faster and faster over time and slammed the door with an incredible sound. There is the possibility to to adjust closing speed with two screws on the door closer for the overall closing speed, and the speed for the final few degrees.

As tuning the system with the screws is quite difficult (a few degrees of turning the screws changes closing times by 10 secs), I added a speed recording device temporarily to the door and recorded the closing speed. And I wanted to use the wireless capabilities of the MKR100 to avoid having a lot of cables in a public area.

The door angle was measured with a simple potentiometer, uses the ADC in the  MKR1000 processor and sends the measurement values with a rate of 100 samples per second to a host computer.


The chart shows in blue the original closing action, in black the last two records. Horizontal axis is time. The ascending slope is decreased on the black lines, indicating lower speed. And especially the last few degrees move slower and avoid the ‘big bang’ of the door.


The measurement device is temporarily clipped to the door.


The acryl rod with the small parallel vice form the anchor point for the potentiometer.

A closeup of the device shows the details

  • the MKR100 is mounted on a prototyping board.
  • Three LED display wireless connection status ‘connect to access point’, ‘access to socket’, ‘operational’.
  • The LiPo battery is on the back.
  • The adapter is 3d-printed.


On the host computer, a python program opens a socket and receives the data. With TKinter, the data are displayed.

pi and more 9, workshop ‘raspberry, scratch, gpio’

For the ‘pi and more 9‘ in Trier on 11 june 2016, I had the chance to run a workshop on how to use scratch with gpioserver and as an alternative to use scratch with scratchClient.
Basis setup was to control three LED with a button.

The introduction is available as a pdf-document.
The tutorials are available here: tutorial (de), tutorial (en).

Working with gpioserver was found to be unstable. Quite a few  attendants had problems to get a connection to the hardware. It simply did not work, or they got popups in scratch that connection to pigpiod could not be established. It was needed to stop scratch and restart to get it running. A reboot of the computer was needed to cure the problems where scratch complained about missing pigpio.
In the scratch startup shell script, there is a check for pigpiod, and when not running this code is started. Obviously this does not work stable.

The differences between using gpioserver and scratchClient have been clearly visible in this workshop:
gpioserver does not complain about misspelled commands, and there is no monitoring capability for this tool. So when something is wrong, it is difficult to find the problem.
scratchClient needs an additional tool to be started, and multiple startups have been a problem. But the monitoring features with the web tool  localhost:8080 have been acknowledged as valuable in training environments.


scratch io response times

Scratch 1.4 on raspberry pi allows programs to work with GPIO pins. I was curious to see how fast scratch can react to input values.

To measure these times, I connected an arduino due (84MHz clock) with a raspberry pi 2B. The arduino produces a 0–>1 edge for scratch and scratch responds with a 0–>1-edge on another pin. The red arrow in the chart shows this dependency. The time between these two edges is the response time of scratch. timing

The scratch code is straightforward. Sensor values are 0, 1, so there are logical operations needed.


Response times are aggregated in a chart. X-axes shows the time intervals, y-axis shows how often execution times have been measured in the 0.5 ms intervals.


The response times range from  3ms to 46ms. The bulk of values is between 5ms and 27ms. The chart is produced from 5659 single measurements. So scratch is sufficient fast to respond in slow environments, but should not be used to control fast systems.

Here the arduino code:

// run on an arduino due

int pout = 11;
int pin = 12;

void setup() {
  while (!Serial) {
    ; // wait for serial port to connect. Needed for native USB port only
  pinMode(pin, INPUT);
  pinMode(pout, OUTPUT);
  digitalWrite(pout, LOW);
long randomnumber = 0;
long t0 = 0;
long t1 = 0;

void loop() {
  // wait for input low
  while ( HIGH == digitalRead(pin)) ;

  randomnumber = random(1, 700);
  t0 = micros();
  digitalWrite(pout, HIGH);

  while ( LOW == digitalRead(pin)) ;
  t1 = micros();

  Serial.println(t1 - t0);

  digitalWrite(pout, LOW);

There is a variable delay in the arduino code from 1 to 700ms to prevent a ‘lock in’ to scratch cycle times.

Although time measurements are in microseconds, the accuracy depends on how good the compiler is in producing fast code. As the times to be measured are in millisecond range, this approach is reasonable precise.

Similiar setup with scratchClient yields following results:


Times are centered around some 67 ms, min is 46 ms which is slower than using gpioserver.

The scratchClient-adapter used is ‘GpioButtonInput’, which already provides edge-detection. The scratch code is



Zusatzaufgabe scratch, Palindrom-Checker

Ein Palindrom ist ein Wort, das vorwärts wie rückwärts einen Sinn ergibt. Idealerweise sogar denselben Sinn, wie  “Lagerregal”.

Satzpalindrome sind  “Ein Eis esse sie nie.”. Hier werden Leerzeichen und Satzzeichen ignoriert und Groß- und Kleinschreibung wird ebenfalls ignoriert.

Die erste Aufgabe ist: Überprüfe ein Wort ob es ein Palindrom ist

Das Wort mit der Antwort-Methode einlesen und dann überprüfen. Da scratch keine Methode zur Korrektur von Groß- und Kleinschreibung hat, sollen nur Kleinbuchstaben und Zahlen eingegeben werden.

Schon eine Idee wie man das machen kann ? Einen Hinweis gibt es hier.

Das Programm soll ‘das ist ein Palindrom’ sagen. Oder eben auch ‘sorry, kein Palindrom’.


Die zweite Aufgabe ist: Überprüfe auch Satzpalindrome.


Das Programm aus Aufgabe 1 so erweitern, dass Leerzeichen und Satzzeichen wie !?.,: entfernt werden.



LEGO powerfunctions control with scratch 1.4

LEGO has a nice set of controls named ‘powerfunctions’. The main device is a IR-receiver which can control motors, LED with a variety of functions. ON,OFF, PWM are available.

To connect this to scratch I use an arduino to control the IR-LED. Arduino is connected by USB to raspberry pi.

The LED is connected to the arduino UNO on a breadboard. I had one from an earlier experiment already mounted to a small board. When arduino outputs are used, current for the LED is limited to 20mA. With an external transistor, current and thus the range can be increased. With my setup range was prox one to two meter.


The setup shown uses an arduino UNO. It is also possible to use an arduino NANO instead. Other arduino boards like mega,zero due should be possible, but not tested.

Arduino code uses a library from a library with small modifications.

The code can control up to four channels. The LEGO RC protocol used is ‘Combo PWM mode’. The timeout needed is handled by the scratch Adapter, resending commands each 0.3 sec.

With a mobile camera, it is possible to make the IR LED light visible. The sensors used in camera have a broad sensitivity area and record IR light too.


In scratch are a few variables needed like c_4_A or c_4_B for the channel 4 ‘red’ or ‘blue’ signals. Values are -7 to +7 for backward max speed to forward max speed;, as a special value ‘BREAK’ can be used.

Adjust USB connection in config file config/config_arduino_powerfunctions.xml

Start scratchClient with

cd ~/scratchClient
python src/ -c config/config_arduino_powerfunctions.xml


When variables are available, a sample script is quite easy. This script was used to record the video.

2016-03-27 updated fritzing chart: LED connection now GND to PIN12 with resistor.

raspberry pi scratch 1.4 sound recording

Scratch 1.4 can record sound. But unfortunately the setup is not simple.

The comments here are based on raspbian 2016-02-26 and scratch 2016-01-15.

Recording sound in scratch 1.4

I connected a simple USB sound card. This card is connected to a microphone and a pair of speakers. The reason to use a card like this is especially the mic-input. Raspberry pi does not have an input on board.


Doublecheck that your adapter is recognized from operating system. Open a terminal window ad enter ‘lsusb’. The output should show your sound device, here the output from my system:

pi@raspberrypi:~ $ lsusb
Bus 001 Device 009: ID 0d8c:013c C-Media Electronics, Inc. CM108 Audio Controller

On desktop, the proper audio device needs to be selected.


I had to reboot the computer to get the changes working. The ‘unable to connect…’-popup clearly indicates that there are errors.


In scratch, check the audio output first. Let the cat ‘meow’ a few times.


Start recording with ‘New sound, record’. The sound recorder popup should be displayed. The red button starts recording.


There is a nice volume indication shown in the bar.

Press stop ■ and ok. The recording is available now.

Unfortunately, the sound was played double the speed, faster and higher than recorded. Seems to be a bug in scratch. Exporting the audio file to file system and importing this back results in normal playback.

There is no possibility to control recording by program code.

Advanced commands for command line

On my system, it was possible to record sound from mic by

arecord -D plughw:1,0 test.wav

With aplay it is possible to reply these data

 aplay -D plughw:1,0 test.wav

Recording sound and playback sound with scratchClient

Recording sound is possible with scratchClient controlled by scratch runtime.
This functionality is implemented by calling linux commands ‘arecord’ and ‘aplay’.

The adapter needed is ‘adapter.linux.Linux_ARECORD_Adapter’. It stores the files in a predefined directory. It uses the linux arecord command. You need to be familiar with alsa devices; this device needs to be specified.

Sample script is


Set the file name, then start recording and stop as needed. There is a timeout specified in the adapter config.

Sample config file is config/config_linux_arecord.xml

Playback can be done by adapter adapter.linux.Linux_APLAY_Adapter. Sample script is


Replay one file in a loop needs to set the file name ‘wave’ to blank in between, as only changing names are transmitted to scratchClient.

Sample config file is config/config_linux_aplay.xml

The files recorded or available for playback are NOT included in the scratch code. So when you move your scratch application to another computer, you need to move your files too.

Use same directory for record and playback, when a scratch program needs play earlier recorded sound.


scratch broadcast event handling

scratch 1.4 is sometimes good for a surprise. In school, a program of a pupil reacted unexpected: Obviously the event driven script did not complete operation, but was stopped by a second event.

A detailed analysis lead to this test code, demonstrating the behavior of event triggered code.

One of the observations are that scratch event handling is not multithreaded, but a new event stops current processing and restarts script.

scratch_boadcast_even_handlingThe sample here uses a simple script, triggered by ‘tick’ event. On entry, a variable ‘a’ is incremented, on exit of the script the variable is decremented. When the script is executed from start to end, then the variable will have same value at the end as at the beginning.


Triggering this script with a ‘slow’ loop (use ‘s’ key), uses a loop with two sec delay. In this scenario, the variable keeps the value.

Using the ‘fast’ loop (use ‘f’-key), the script receives a new tick event when just in the middle of operation. Obviously the script gets interrupted and restarts from beginning. This is clearly visible, as the variable gets incremented.


The ‘c’ key resets the logic.



The full scratch code 1.4 code is here for download


gpioServer and scratchClient performance comparison for stepper driving signals

GPIO performance on raspberry pi is an often discussed topic.

New scratch uses a build in gpioServer, other options are scratchClient.
Especially stepper motors need quite high pulse rate, so I have set up a test harness for a small stepper with 2ms step width. The scenario are

  • a DMA pulse driven approach
  • a python program
  • scratch, using scratchClient
  • scratch, using GPIOserver

The main focus is on performance of scratch to GPIO.
For scratchClient, some bottleneck analysis is performed.

DMA created pulses

As expected, DMA pulse widths are precise. The glitch on third line is due to a limitation in my modified RPIO.PWM-library which does not yet allow impulse roll over. The interval time printed on the image is for four steps and precise 8ms.



This DMA approach is listed for reference only, as it is not easily controllable from scratch. It is either on or off, but number of pulses can’t be determined.

python created pulses

python code is also pretty good. Pulse with is exceeding the expected 8ms by 0.5ms, which could quite easily compensated by some more advanced time handling.


scratch and scratchClient

The scratchClient approach is expected to be slower. Time scale is changed for this chart and the result is 326ms for 4 steps, which is 40 times slower than python or DMA.



scratch with gpioserver

GPIOserver, build in into scratch, is finally at 101ms, three times faster than scratch with scratchClient, only 12 times slower than python. The assymmetric pulses are due to to ‘forever loop’, I suppose.


All of the measurements have been taken on a RPI2, Model B, raspbian ‘jessie’, scratch is 2015-11-11.
Python is 2.7, the DMA code is a modified RPIO.PWM, adjusted for PI2.

scratchClient bottleneck analysis

The result for scratchClient was unexpectedly bad. So I have set up some tests to find out where the bottleneck is located.


First approach was to change the variable based communication to the stepper module by an event based ‘broadcast’. This approach resulted in 101ms cycle time, a good match to the result from GPIOserver.

Second approach was to write a small python code which simulates scratch: a socket server for port 42001, sending out sensor updates like “sensor-update “br0.0” 0 “.



The delay time was 2ms, and the result from this is a cycle time of 9ms. Pretty close to the pure python approach.
From these results it is clear that the bottleneck is on scratch side. Looks as if scratch variable access and sending them out is three times slower than sending out broadcasts from scratch.
Socket communication imposes some overhead, but is not limiting performance.

See also scratch performance 2, gpioserver reaction time