Linux Kernel Module to Control 434Mhz RC Outlets – Pi Version

Added a setup-script to cross-compile the Linux kenel module for the RC outlets for the Raspbarry Pi. To be able to cross-compile the module, in brief the following needs to be done:

Install ARM cross-gcc

On Ubuntu:

sudo apt-get install gcc-arm-linux-gnueabi make ncurses-dev

Get RasPi Kernel

E.g. use Kernel from GIT:

git clone https://github.com/raspberrypi/linux.git linux-raspberrypi

Compile the Kernel (needs to be done once before building the rcswitch-kmod)

To be able to compile out-of-tree Kernel modules, you need to cross-compile the targets Kernel at least once. This is done like so:

cd linux-raspberrypi
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- bcmrpi_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-

Depending on your machine, this may take some time …

Build rcswitch-kmod

Get the module from git:

git clone https://github.com/wendlers/rcswitch-kmod.git rcswitch-kmod
cd rcswitch-kmod

Edit setenv_raspi.sh, make sure LINUX_DIR points to the directory of your previously build kernel:

export LINUX_DIR=$PWD/../linux-raspberrypi

Next, build the module:

source ./setenv_raspi.sh
make all

Now copy the Kernel module to your PI. E.g. by using ssh:

 
scp module/src/rcswitch.ko pi@:/home/pi/.

Wiring the RF Transmitter to the PI (to use Kernel module defaults)

To use the modules build in default, connect the RF-Transmitter as shown in the picture below:

Connect transmitter to PI

Connect transmitter to PI

Loading the Module, Testing Module

On the Pi, the module could be loaded like this:

sudo su
insmod /home/pi/rcswitch.ko

Verify the module was loaded properly:

dmesg

Should output something like this:

[ 3392.757506] rcswitch: init
[ 3392.757540] rcswitch: using tx_repeat of 10
[ 3392.757609] rcswitch: registered command interface under: /sys/kernel/rcswitch/command
[ 3392.757623] rcswitch: registered power   interface under: /sys/kernel/rcswitch/power
[ 3392.757641] rcswitch: using gpio #17 for TX
[ 3392.757650] rcswitch: EN disabled

And the following sysfs entries should have bean created:

ls -al /sys/kernel/rcswitch
--w--w--w- 1 root root 4096 Jul 25 23:15 command
-rw-rw-rw- 1 root root 4096 Jul 25 23:46 power

If all of the above is in place, you should be able to operate your switches. E. g. turn on switch at address 11111, channel A:

echo 11111A1 > /sys/kernel/rcswitch/command

And to turn the same switch off:

echo 11111A0 > /sys/kernel/rcswitch/command

Note: there is also a python example which could be used on the Pi here.

Tri-State Protocol of the Pollin (and other) 434MHz RC Switches

Made a overview of how the over-air protocol looks for the Pollin RC Switches (see previous article for more details). The length of the pulses is a multible of 350us. The wave-forms where captured with an OpenBench logic sniffer.

RCSwitch Tri-State-Protocol

RCSwitch Tri-State-Protocol

Linux Kernel Module to Control 434Mhz RC Outlets

Some time ago, I wrote about using an EDIMAX Smart Plug with Python. The EDIMAX has build in Wifi and runs its own web server. While this is convenient, it also makes the EDIMAX quiet expensive. Lately I got notice (thanks Eric), about very cheap 434MHz based plugs sold by Pollin for less then 10 EURO per 3 pieces (including a remote control I will not need anyway). Also there are libraries for using them with a cheap 434MHz transmitter as well as some remote control software for the RaspbarryPi.

What I didn’t like about the existing solutions was the fact, that the driver ran in user spacing using wiringPi to access the GPIOs. To my opinion there is absolutely no need to wrap all this low-level stuff in user-space. The Linux kernel itself provides a very good abstraction layer to access GPIOs in a machine independent way. Also exposing functionality could be done easily through sysfs.

Thus, I decided to somehow rewrite the above code (rcswitch-pi) to live in a Kernel module being accessible through sysfs. The complete results could be found here.

Operating the outlets now becomes very simple and could be done from almost any programming language. Even from bash.

E.g. to turn the power on for address ’11111′ and channel ‘A’ one could use:

echo "11111A1" > /sys/kernel/rcswitch/command

Or to turn the power off for the same device:

echo "11111A0" > /sys/kernel/rcswitch/command

I also included optional power-management, allowing the transmitter to be turned on/off (if VCC of the transmitter is connected to an GPIO):

Power on the transmitter:

echo "1" > /sys/kernel/rcswitch/power

Power off the transmitter:

echo "0" > /sys/kernel/rcswitch/power

Get current power state of the transmitter:

cat /sys/kernel/rcswitch/power

This far, I only tested the module on my 8Devices Carambola board (running kernel 3.3.8). But it should work without modifications for any other Linux board.

For more instructions, please see the projects README.

More links regarding RC outlets:

And some pictures of mine:

433MHz transmitter

434MHz transmitter

RC outlets

Pollin RC outlets

Poor Mans 3D Goggles (OpenDive)

At Google I/O this year, Cardboard was presented. Cardboard are DIY 3D goggles made of cardboard, using a smart phone as screen and sensor device. Cardboard seams to be based on OpenDive from Stefan Welker who also published the STL files for 3D printing his goggles on ThingiVerse. And printing them was exactly what I did lately.

Obviously not all parts could be printed. One needs fitting lenses and some rubber band to “mount” the goggles on the head. Stefan Welker used to offer a kit on amazon, including lenses and rubber band. Unfortunately it looks like Google bought all the Kits for Cardboard. Thus, I replaced the lenses with the 30mm 5x ones included in this set. They do not fit in the original lens holders, but they do fit with this holders available at ThingiVerse.

The rubber band is a 40mm rubber band easily available. I used this one from amazon.

The results one gets with the OpenDrive are amazingly good! Especially playing Quake 2 is real fun! The only down side is, that there are not many (real) games available yet.

Some more links regarding OpenDive:

And some pictures of my OpenDive:

OpenDive printing phone clips

OpenDive printing phone clips

OpenDive lense holders

OpenDive lense holders

OpenDive lense holders and lenses

OpenDive lense holders and lenses

OpenDive printing  frame

OpenDive printing frame

OpenDive assembled (back)

OpenDive assembled (back)

OpenDive with lenses in place (top)

OpenDive with lenses in place (top)

OpenDive with lenses in place (bottom)

OpenDive with lenses in place (bottom)

OpenDive assembled (front)

OpenDive assembled (front)

OpenDive assembled

OpenDive assembled

OpenDive assembled

OpenDive assembled

OpenDive assembled

OpenDive assembled

Bric(k)-o-lage – Big Button

I created a first passive component for my brick-o-lage project: a big button with feedback LED. The button is mode from a big “pilz” switch which presses a smaller switch inside the case. Very simple but dangerous looking :-). The 3D files could be found on my github account. I tried to make the case stable enough so it could be hit hard too.

Big Button - Inside

Big Button – Inside

Big Button - Top

Big Button – Top

Big Button - LED

Big Button – LED

Since the bricks do have whole which are LEGO Technics compatible, they could be plugged together:

Plug Together (1)

Plug Together (1)

Plug Together  (2)

Plug Together (2)

Plug Together  (3)

Plug Together (3)

Big Button Brick Specifications

  • One Pliz-Switch (40mm)
  • One small switch
  • Some wire, plug

Big Button Brick Case

Big Button

Big Button

Big Button - Exploded

Big Button – Exploded

EDIMAX Smart Plug Switch SP-1101W from Python

I wrote a simple Python class to access the “EDIMAX Smart Plug Switch SP-1101W“. The whole code could be found here.

EDIMAX SP-W1101W

EDIMAX SP-W1101W

For more information on how the communication with the Smart Plug works, see this post on ELV (available in German only).

The code could be used as library or as command line utility:

Using as library

p = SmartPlug("http://172.16.100.75:10000/smartplug.cgi", ('admin', '1234'))

# turn plug off
p.state = "OFF"

# turn plug on
p.state = "ON"

# get plug state
print(p.state)

Using as command line utility

turn plug on:

python smartplug.py -u http://172.16.100.75:10000 -l admin -p 1234 -s ON

turn plug off:

python smartplug.py -u http://172.16.100.75:10000 -l admin -p 1234 -s OFF

get plug state:

python smartplug.py -u http://172.16.100.75:10000 -l admin -p 1234 -g

Case for STM32F4-Discovery Board

I finished a case for the STM32F4-Discovery board. It consists of two parts: the case body and the case cover. The cover is hold in place by two snap-ins. The cover has spaces for all the header, jumpers and buttons. Also I made the cover very thin at the places where the LEDs of the board are located. This makes the LEDs nicely shine through the cover. All the CAD data could be found on thingiverse.

The short video below shows how well it works using thin material to make LEDs shine through:

Here are some more pictures:

STM32F4-Discovery Case Model Closed

STM32F4-Discovery Case Model Closed

STM32F4-Discovery Case Model Exploded

STM32F4-Discovery Case Model Exploded

STM32F4-DIscovery Case Parts

STM32F4-DIscovery Case Parts

STM32F4-DIscovery Case Parts

STM32F4-DIscovery Case Parts

STM32F4-DIscovery Case Parts

STM32F4-DIscovery Case Parts

STM32F4-DIscovery Case

STM32F4-DIscovery Case

STM32F4-DIscovery Case Top

STM32F4-DIscovery Case Top

STM32F4-DIscovery Case closed

STM32F4-DIscovery Case Closed

 

Micro Python on STM32F4-Discovery

The Micro Python project is an effort to make the Python3 language fast and lean enough to run on micro controllers and if was successfully founded by this KickStarter campaign. It is intended to run on it’s own hardware, the pyboard. Unfortunately, this board is not widely availabel, and everyone who missed the KickStarter will not be able to get such a board until now. Luckily the firmware also offers support for more ARM-Coretex M4 based micros, like the widely available STM32F4-Discovery. Since I like the idea running Python on a micro, and due to the fact my STM32F4-Discovery arrived today, I decided to immediately give Micro Python a try. In the following article I will describe in short what needs to be done to make Micro Python running on the discovery by using Ubuntu.

STM32F4 Discovery

STM32F4 Discovery

Hardware needed

STM32F4-Discovery, that’s all you need since it includes already a stlink based debugger interface one could use for flashing.

Software needed on the host (Ubuntu)

To compile Micro Python, the arm-none-eabi cross-compiler is needed. On newer Ubuntu versions this could be easily installed through apt:

sudo apt-get install gcc-arm-none-eabi

Also you will need the stlink utility from texane. For more details on how to install stlink, please consult texane’s README.

To download the ELF firmware, you will also need the GDB for arm-none-eabi. In theory this could be done by the following apt statement:

sudo apt-get install gdb-arm-none-eabi

But unfortunately if you have installed any other gdb already (which is likely), this command will fail due a conflicting manpage! Thus, the following work-around is needed:

sudo apt-get install -d gdb-arm-none-eabi
sudo dpkg -i --force-overwrite /var/cache/apt/archives/gdb-arm-none-eabi_7.6.50.20131218-0ubuntu1+1_amd64.deb

Building Micro Python for the Discovery

Clone the Micro Python git repository:

git clone https://github.com/micropython/micropython.git

Now change into the micropython directory an build for the STM32F4-Discovery:

cd stmhal
make BOARD=STM32F4DISC

This should create the firmware.elf in stmhal/build-STM32F4DISC.

Flash the Micro Python firmware to the Discovery

Connect the Discovery through USB (the one on with the Mini-B connector, don’t connect the USB-OTG), then start (in a separate terminal) the stlinkt utilit:

st-util

The st-util now waits for a connection from GDB. This is done like so (assuming you are still in the micropython/stmhal directory):

arm-none-eabi-gdb build-STM32F4DISC/firmware.elf

Within GDB connect to st-util by:

target extended localhost:4242

And flash the firmware with:

load

The multi-color COM-LED should blink while loading. After downloading finised, terminate GDB.

Now disconnect the USB Mini-B cable to power the board completely off.  Connect a USB-OTG on the opposite side, and reconnect the USB Mini-B cable for power. After a few seconds, the STM should be mounted as a storage device showing the files “boot.py” and “main.py”. It is also possible to open a Python shell on the serial device /dev/ttyACM0:

screen /dev/ttyACM0

You now could follow the tutorial on the Micro Python web page (accelerometer is not supported on the STM).

Note: in theory it should be also possible to download the firmware through DFU as described in the Micro Python README. But to my understanding you need to enable DFU mode on the STM by removing some resistors to change boot-configuration. 

Conclusions

Micro Python looks very well done and promising. I think I should give it a try in some of my next projects.

 

Bric(k)-o-lage – Blockly

Here are some screen-shots of the Blockly based visual programming editor for Brick-O-Lage. Roughly it works like this:

  • On the Master Brick, the bolsrv is running.
  • bolsrv uses libbol to access the bricks connected to the master via I2C
  • bolsrv also includes a mongoose based web server doing two things: serving the HTML+JavaScript based visual editor and offering a REST interface to some of the functions from libbol.
  • For Blockly I wrote blocks repesenting the Bric(k)-o-lage bricks (DIO, DCM)
  • Also fro Blockly I wrote generators creating Python code for BOL-script
  • The BOL-script is sent to bolsrv and from there to the libbol scripting engine
  • The scripting engine is embedded Python with bindings to libbol functionality

The following picture shows the available BOL blocks (DIO and DCM):

BOL blocks

BOL blocks

A simple blinky script might then look like this:

Simple Blinky Script

Simple Blinky Script

And a slightly more complex script taking input events from a DIO input and driving a DC motor through DCM brick as a response:

More Complex Script using Events

More Complex Script using Events

Here is a very early (very poor quality) video which a made when I reached the first cut-trough:

Bric(k)-o-lage – DCM Brick

Recently I finished a first version of the DCM Brick (DC Motor Control).  As for the DIO brick and the Master Brick, I designed schematic and PCB using fritzing . Also I ordered the PCBs from fritzing FAB. For the firmware I used my own libemb as a basis.

The DCM brick allows driving two DC motors independently.  Each motors direction (clockwise and counter-clockwise) is controlled by a PWM to allow adjustment of the speed. For driving the motors, I used the SN754410 quadruple half-H driver from TI. It turned out, that this choice was not the best since the SN754410 if specified to need at least 4.5 to operate while the MSP430G2553 operates from 2.8-3.6V. It turned out that the H  bridge works (most of the time) relay-able if driven with 3.6V but I think I need to switch to something like the TI DRV8835.

For the case I tried to design some kind of snap-in-lock (as one could see in the pictures below). The cover uses to standoffs which snap into the bottom half of the case. The result is fairly OK, and I expect it to become better when printing the case in higher quality (did only quick prints so far).

DCM with Connected DC Motor

DCM with Connected DC Motor

DCM Brick Specifications

  • Uses a MSP430G2553 from TI
  • Runs custom firmware
  • Connects to master brick through I2C
  • Control 2 DC motors in direction and speed using the SN754410
    QUADRUPLE HALF-H DRIVER
  • 2 status LEDs
  • Serial RX/TX for debugging

DCM Brick Schematic / PCB

The full files could found here.

DCM Brick Schematic

DCM Brick Schematic

DCM Brick PCB Top

DCM Brick PCB Top

DCM Brick PCB Bottom

DCM Brick PCB Bottom

Some pictures of the PCB (with and without parts):

DCM PCB Bottom/Top

DCM PCB Bottom/Top

DCM PCB Top/Bottom

DCM PCB Top/Bottom

DCM PCB

DCM PCB

 

DCM Brick Case

Find the OpenSCAD and STL sources here.

DCM Case Exploded

DCM Case Exploded

DCM Case

DCM Case

The following pictures show a first print out (done in “poor but fast” printing quality):

DCM Case Closed

DCM Case Closed

DCM Case Open

DCM Case Open

DCM Case Inner/Outer View

DCM Case Inner/Outer View

DCM Case Outer/Inner View

DCM Case Outer/Inner View

DCM Brick Firmware

The whole firmware sources are located here.