Search

Putting a raspberry pi into an old radio from the 60s had been on my project list for quite a while. Having a dedicated internet radio player inside a beautiful old case and with all the original controls connected would have been so awesome. I was hence very excited when I finally got around to buy a used 60s radio, settling for a “Löwe Opta Magnet 4725W“. Unfortunately, it turned out that the old radio I bought from a nice lady nearby still works, despite having been advertised as “broken”. Buggers, as I can’t really bring myself to destroy something that is still functioning perfectly fine.

The Löwe Opta Magnet 4725W – High Tech from the 60s.

However, there are alternatives to breaking it, especially as it features a line-in connector on the backside, which was originally used to connect record players or tape recorders. After some reading on the web and buying the right cable I tested connecting the radio to the audio jack of a Raspberry Pi 1, which worked well enough for me to stop investigating any further.

Next question was: how to control the radio? Some earlier experiments with potentiometers for controlling volume and selecting channels had already convinced me that this was the direction to take, but also showed that rotary encoders would probably the better choice due to their comparably greater range, and also have the advantage of (kind of) working out of the box with a Raspberry Pi (i.e. without involving any further chips that convert the analogue readings of the potentiometers to a digital signal).

An earlier prototype with potentiometers. Note the DAC chip to read the analogue signals on the RPi.

As rotary encoders come in different flavours and are often not well documented (at least for laypersons), I tried to find a model that reportedly worked and ended up getting some KY-040s that already had most of the circuitry on board. Apart of GND and power, only two pins need to be connected to the Raspberry Pi’s GPIO as inputs: one Clock pin, and one Data pin.

The read the rotary encoder from software, you basically need to do two things: 1) listen to the input of the Clock-Pin, and when you detect that it is getting from HIGH to LOW, 2) read the Data-Pin to figure out if the knob was turned clockwise (HIGH) or counter-clockwise (LOW). Here is a simple example on how this works in Python. You can read up further on KY-040s and how to connect them to a computer here (the example is about an Arduino).

For playing web radio streams, I used the popular Music Player Demon (MPD) which is easy to install (as in “apt-get install mpd”) and quite versatile with regard to its use. I then wrote some Python code that uses a library to control the MPD based on a playlist containing all the radio channels I like to listen to. After figuring out how to control the MPD from Python and combining that with the code for reading the rotary encoder, I can now use a knob to switch between channels on my radio; for volume, I can just use the controls of the original radio.

You can find the code for the radio here, in case you are interested: https://bitbucket.org/snippets/boden/ppRAdG. The principle of reading the rotary encoder is similar to the example above, with some small tweaks. The rest is just code for controlling the MPD (including making sure the button works even when another MPD client is used in parallel), and for cleaning up the GPIOs when the Raspberry Pi is shut down. The music playlist itself needs to be configured in MPD, for which several clients are available on a variety of platforms (so as a nice side-effect, the radio can also be controlled easily from the smartphone or any other computer on the network).

The control knob for switching the channels – already covering dust like the radio it controls.

So far, the rotary encoder is sitting in a plain paper box next to the Raspberry Pi. Next steps would be to get a nicer case for it or potentially putting everything right into the radio itself. We will see.

I got a Raspberry Pi 2 for my birthday and, as a small evening project, ported my Arduino Weatherstation project to this new platform.

The setup is relatively simple: I used the Adafruit Python DHT Sensor Library to read the sensor values from the GPIO, logging the resulting values with a timestamp to a CSV file. Another python script then reads this files and creates a graph using the Matplotlib library (which can be installed easily on the RPi with sudo apt-get install python-matplotlib).

Both scripts are called every five minutes by crontab, and the resulting image is displayed on a webserver (I used nginx, which is also quite easy to install).

Next steps would be to log to a database instead of a file, and implement different visualizations over different time intervals.

Just a snipped of code that I have found for creating a candlelight-like light with a yellow LED attached to a PWM port of an Arduino (called here ledPin). You could probably add another red LED to optimize the effect, but for a first try it does not look too bad.

I have created a holder that can be used to attach my Arduino-based camera remote to the hotshoe of the camera. The file was created in the CAD software Rhinoceros and printed on a MakerBot Replicator 1 owned by the University I work at. Its a rough first try, but the device works.

This is a binary clock that was built into a 3d-printed case created in Minecraft. It shows the current time in a binary coded decimal format. The code and idea are based on a tutorial by Daniel Andrade.

The model was exported with the free tool Mineways and printed on a Zprinter 650 3d-printer, with a block size of 125mm^3 (so every block has an edge length of 5mm).

17:07 (i.e. 5:07 PM)

After printing, LEDs were glued into the case after filing the openings a bit wider. Then, the LEDs were soldered to form a 4×4 LED matrix, and the matrix was connected to an Arduino board. Two pushbuttons were added for setting the clock (hours and minutes).

The circuit of the binary clock (not very accurate, I know, but you get the idea…).

I have updated both the hardware setup of my camera remote as well as the software that is used to control the Arduino.

With regard to the hardware, I have soldered the optoisolator and capacitors to a small board. I also bought a remote cable for the Nikon D200 and connected it to my optoisolator, so that the setup can now be connected more easily to the camera.

The revised hardware part (the pins can be connected to the Arduino ports 13 and GND). Note that the setup can also be used for different brands of cameras by using a different adapter.

Here is a description of the circuit:

The simple circuit (note that the type of optoisolator given there is different to the one I used; could not change that in the software somehow).

With regard to the software, I updated my app with further modes for interval shooting and bulb (apart of the existing self timer mode). The new version of the app depends on Android 4.0 (ICS) in order to work properly, as I used the advanced number pickers that are not available in the older versions of Android.

The start screen of the App.

The interval shooting mode. You can pick the pause between the shots, as well as how many pictures you want to have taken (as the Arduino keeps track of time etc., the App can be closed after triggering the interval shooting).

Recently I have been experimenting with interfacing my Ardunio Uno with my Nikon D200 DSLR. The D200 has a connector for a remote control cable that consists of 10 pins. After some research on the web I was able to find some information on how the pin layout works: http://www.doc-diy.net/photo/remote_pinout/#nikon. Basically, you have to connect the two pins for activating the autofocus and the shutter to the ground pin in order to take a picture.

The pin layout of the remote connector

As I do not own a remote for this camera or a cable that fits into the remote connector, I used breadboard cables which fit perfectly into the pins of the connector. With these cables and an optoisolator, it was easy to connect the camera to my Arduino board.

The remote connector of the D200

Some experiments showed that activating the optoisolator for 1000 milliseconds was a good value to activate the camera for one shot (this can also be done by simply bypassing the three cables. This opens up many possibilities for triggering the camera for example with a lightbarrier (for example using an IR diode and a photodiode), or by sound sensors or other means of activation (such as a photo resistor for detecting ambient light and automatically shooting sunsets if you are too lazy to get up early).

The Arduino board (with Bluetooth Shield), connected to the optoisolator

However, as I was recently experimenting with the Amariono toolkit (http://amarino-toolkit.net/) that enables the interfacing of Arduino boards with Android devices over Bluetooth, I decided to build a remote control App that would be able to trigger my camera wirelessly: a Bluetooth Camera Remote.

The Bluetooth Camera Remote Prototype

The BTCamRemote consists of several components:

An Arduino Uno board with an optoisolator connected to the right remote trigger pins at the DSLR.

A Bluetooth Shield (I use the one from iteadstudio.com).

An Arduino program that depends on the Amarino Library and listens to commands that are recieved over the Amarino framework (basically consisting of a certain flag and an Integer value that sets the duration for activating the optoisolator and thus the camera).

An Android cellphone (I use an HTC Legend with Android 2.2) running the Amarino App (where the connection to the Arduino has to be set-up, coupling the Bluetooth devices).

An Android App that uses the Amarino Framework to send commands to the Ardunio board when a button is pushed (the user can also set a delay before the command is sent, so you can hide the cellphone when you want to take self portraits).

This setup is not really simple (because of the many software components), but it works and can be easily extended with further functions (for example activating other pins with further optoisolators etc.). It is also possible to use the Arduino for long term exposures, for instance when taking night shots (as far as I know, the camera can do exposures up to 30 seconds without using the manual “bulb” mode; the Arduino could control exposure times that are much longer, and it could be easily made accessible with a nice user interface on the Android phone.

The Android App “BTCamRemote”

The next steps will be to solder the circuit to a (smaller) circuit board and exchange the breadboard cables with the right camera cable. I will also try to attach the Arduino board to the hot shoe of the camera, and power the Ardunio with a battery in order to make the setup more mobile and easier to carry around. It would also be nice to learn more about how the other pins on the connector work, in order to access more camera functions with my remote.

You can download the source code as well as a signed APK of the application here (note that it depends on the Amarino App that has to be installed separately): https://bitbucket.org/boden/btcamremote/