The touch controller is an ADS7846 chip that already has a device driver in . . . → Read More: Adding touch support for the MI0283QT* displays]]> In my last posts I showed how to integrate Watterott’s MI0283QT-2 and the newer -9 displays as a frame buffer device in Raspberry Pi’s Linux kernel. Now I will focus on adding support for the touch controller found on the display boards.

The touch controller is an ADS7846 chip that already has a device driver in the Linux kernel. User dronus has patched the vanilla driver to make it work with the MI0283QT displays and the Raspberry Pi.

Fine, we already have everything in place now to give it a try!

Hardware

First, we need to add two additional wires in our hardware setup to connect the touch controller (see old wiring in last post) with the RPi:

Signal     Raspi      Display   Comment
T_IRQ      GPIO25       13       Interrupt line from ADS7846
T_CS       SPI0_CE0_N   11       SPI chip select 0

Software

I assume you already have a patched Linux kernel with the tft driver patches applied. Here is quick list with the next steps:

• (Manually) apply dronus small patch to your kernel tree. This adds the necessary modifications of the ADS driver.
• Note: I had to replace the invert_x with the invert_y entry in the ADS configuration to match the display orientation we use in the frame buffer driver
• Your SPI config for the display now should look like this (for the newer *-9 display): linux/file arch/arm/mach-bcm2708/bcm2708.c

static struct ads7846_platform_data ads7846_config = {
  .x_max      = 0x0fff,
  .y_max      = 0x0fff,
  .x_plate_ohms    = 180,
  .pressure_max    = 255,
  .debounce_max    = 10,
  .debounce_tol    = 3,
  .debounce_rep    = 1,
  .gpio_pendown    = 25,
  .keep_vref_on    = 1,
  .swap_xy     = true,
  .invert_y    = true
};

static struct spi_board_info bcm2708_spi_devices[] = {
        {
                // ads7846 touchscreen on chipsel=0 device
                .modalias    = "ads7846",
                .bus_num    = 0,
                .chip_select    = 0,
                .max_speed_hz           = 500000,
                .irq      = GPIO_IRQ_START+25,
                .platform_data    = &ads7846_config,
                .mode = SPI_MODE_0
        }, {
                // display on chipsel=1 device
                .modalias = "ili9341fb",
                .max_speed_hz = 16000000,
                .bus_num = 0,
                .chip_select = 1,
                .mode = SPI_MODE_0,
                .platform_data = &(struct fbtft_platform_data) {
                        .gpios = (const struct fbtft_gpio []) {
                                { "reset", 23 },
                                { "led", 24 },
                                {},
                        },
                        .fps = 10
                }
        }
};

• I use GPIO 25 for the touch IRQ (mainly because wiring was easier this way and had to change the relevant entries. dronus used GPIO 17 instead.
• I reduced the SPI rate of the display to 16 MHz and the frame rate to 10 fps. This proved to be more stable with activated touch controller.
• The older -2 display works similarly. You only have to exchange the second block with the one of the r61505u driver. See old post for details
• Open the configuration of the kernel and select the ADS driver:

> make menuconfig
Select "Device Drivers -> Input Device Support -> [*] Touchscreens -> [*] ADS7846..."

• Make sure to include the ADS driver directly into the kernel and NOT in a module
• Ok, thats it! (Re-)compile kernel and install it on your RPi…

Test

After a reboot your system shows a new input device in /dev/input/*. If no other USB mouse or keyboard is connected then the devices found there are all created by the touch controller.

You can use the evtest utility to check the touch operation (Install with ‘apt-get install evtest’ first!):

> evtest /dev/input/event0

When you tap on the display you will see the incoming events. Note the x and y coordinates mapping if you tap on different corners of the display.

Now with the basic operation tested you can start X11 on your display (see last post) and use your fingers or a stylus to navigate the mouse cursor!

Open Topic

While touch operation with this driver is rock solid and works very precisely I have found one little nuisance: I can’t move the X11 cursor into the border regions of the display Approx 5 mm at the border of the visibile display area my touch movements are not recognized anymore and I can’t move the pointer there… I am not sure if this is a limitation of the display, of the ADS driver or the parameter set for the driver… If you find a workaround for this then please post a comment!

[Update: 21.4.2013] Pre-compiled Kernel

A pre-compiled Raspbian Wheezy Kernel 3.6.11+ with both ili9341 display and ads7846 touch driver (i.e. supporting all devices on the MI0283QT-9 board) is available for download here:

• raspi-linux-3.6.11-ili9341-ads7846.tar.gz

the pifon project: . . . → Read More: pifon: an audio baby monitor for two Raspberry Pis]]> Becoming a dad does not only completely change your life but also changes the scope of your hobby projects (If time still permits ) My first self-made project made especially for my newborn baby boy Felix is called pifon and is an audio baby monitor realized with two Raspberry Pi devices.

the pifon project: two Raspberry Pis converted into an audio baby monitor

Hardware

The hardware setup is fairly simple: one Pi, the pifon server, has a USB web cam attached. I use its internal microphone to record the voice of my little boy. The other Pi is the pifon monitor and has a set of analog speakers attached for the output. Additionaly, the mon device has an Adafruit RGB LCD Plate attached and I use the LCD on this little plate as output device and its 5 keys as user input. I did not mount the plate directly on the Pi but used a ribbon cable to detach it: This allows me to package the plate in its own housing (As it is easier to find a case for the plate alone):

pifon/mon: the listening Pi with the control panel attached

Software

To get started quickly, I tried to use as many off-the-shelve components for the software as I could: For the audio recording and streaming I opted for the Icecast audio streaming server that gets its input stream recorded from the webcam microphone with the darkice live audio streamer. This setup is proven to be stable and already documented in various projects – also on the Pi.

What’s missing is some kind on status messaging I wanted to have: The pifon server shall analyse the recorded audio stream and when something special (e.g. baby crying) happens it sends an event to the monitor client. So the client can start streaming the live audio only when something interesting is happening. Then the audio stream will stay live until the event is over and then stop streaming.

For the messaging between the server and the monitor I decided to use XMPP, the well known standard for Internet instant messaging. The pifon server and the monitor will then be two “bots” sitting in a chat room and exchanging events by “typing” messages. The advantage of this approach is that you can simply join the chat as a user and also watch for incoming events for the server – that’s also really helpful for debugging

I run my own XMPP server on the pifon server Pi and use the prosody server implementation. My code contribution in the project is the bot code and that is written in Python using the SleekXMPP for the XMPP communication. Additionally, I use Adafruit’s Python Code for accessing the LCD and reading the 5 buttons via the I2C bus.

Audio recording is done on the server with SoX‘s rec tool and using an ALSA dsnoop device that allows mutliple applications to share an input device (here the USB cam’s mic).

For audio playback on the pifon mon Pi I use the well known MPD that is controlled by my scripts with the MPC command line tool. It directly supports streaming by adding the stream server URL in the play list.

pifon's mon status and control panel

Features

The pifon project is now in daily production use and has the following list of features:

• pifon audio server
  • Stream baby’s audio via standard MP3 stream server to any streaming capable device
  • Constantly analyse the audio signal and watch out for loudness periods
  • Provides local XMPP chat server with private chat room for pifon eventing
  • Send events as XMPP chat messages whenever something happens on the audio channel
  • Listen on chat messages that allow to control the parameters of the analyse algorithm
• pifon monitor
  • Automatically joins the XMPP chat and watches out for events from the server
  • Can stream the audio to your local audio out with mpd
  • LCD displays current state of the server including
    • audio detector state: idle, attack, active, sustain, respite
    • connection: is mon connected to XMPP server?
    • server ping: does the audio server reply my pings?
    • shows peak and current RMS audio level during active phase
  • The LCD has an RGB backlight. It is used to display the server state:
    • BLUE: mon is running but server is not connected yet
    • WHITE: mon is running and server is connected. no audio event happened
    • RED: audio is active (loud) but playback is not enabled
    • GREEN: audio is active (load) and playback is enabled
    • YELLOW: blanking is disabled otherwise similar to WHITE
  • 5 Keys allow to directly toggle:
    • Listen: toggle direct streaming from server. This allows to listen into baby’s room without the audio detector triggering the playback
    • Mute: do not start audio streaming even if an audio event occurred. Use this if you want to watch out for audio events but do not start streaming the audio stream. You will then see the audio event with the LCD backlight only.
    • Chime: the mon client plays a short signal sound before starting or stopping the streaming playback. You can disable playback of these sound icons with this button.
    • Blank: if no audio event occurrs then the LCD is automatically blanked after 10s if no button is pressed. If you want to see the display permanently then toggle this button.
    • Menu: open the parameter menu. Press the button again to leave the menu. Inside the menu the four directional keys allow you to navigate through the menu items and alter the values. See the description of the detector parameters for details below.
• Both devices are more or less portable if your network technology allows this (I use PowerLAN, but WLAN works as well)
• Use your Mac/PC or mobile phone as an alternate client: Use an XMPP chat client (I use Adium) to watch for server events and an internet stream player (e.g. VLC) to listen to the audio stream. Talk with the server to alter parameters.

Audio Detector Parameters

The audio detector used in pifon’s audio server has several parameters that allow you to adjust the responsitivity of the detector.

The audio detecter is modeled as a state machine that analyses the max RMS value of the samples recorded in a given period and uses this value to decide on state traversal.

The following states are defined:

• Idle: nothing special happens on audio
• Attack: audio level peaks and it might be the begin of a loudness phase if its long enough
• Active: attack period was long enough, we enter active mode and start streaming audio
• Sustain: if audio is silent during the active phase for a longer time then the sustain phase is entered and will lead to end of playback if its long enough
• Respite: This phase enforces a quiet period right after the end of an active phase. Even if audio events occur in this phase they are ignored. This phase was introduced to avoid very frequent start/stop playback cycles.

The mon displays some additonal states in the LCD, but they are not audio related:

• Connect: initial connect to XMPP server
• Online: mon is in chat room and gets pings from audio server
• Offline: no ping and disconnected from XMPP server
• No Ping: mon is connected to XMPP server but audio server does not reply on pings

The following audio detector parameters can be adjusted:

• trace (boolean): allows to show the audio RMS value all the time. This is useful for debugging and adjusting the other parameters
• alevel (int, 0-100): level of audio signal must be higher than this value to enter attack state
• slevel (int, 0-100): level of audio signal muse be lower than this value to enter sustain state
• update (int, 1-..): update interval of audio state in 100 ms
• attack (int, 0-..): duration in [s] of peak audio values that must be audible so that active state is entered
• sustain (int, 1-..): duration in [s] of silence so that active state is left
• respite (int, 0-..): duration in [s] after an active period where no new active period is started

You can alter these parameters in the XMPP chat with the following commands:

get audio *
set audio trace False
set audio alevel 10
set audio slevel 5
set audio update 5
set audio attack 0
set audio sustain 5
set audio respite 10

The ‘*’ allows to get all values available.

Build your own pifon!

Yes you can build your own clone of the pifon if you like. Everything you need is freely available: all used tools and my code.

The source of my code contributions are found on GitHub: cnvogelg/raspi. Just clone the repository and use it.

This repository includes a detailed instruction manual on how to setup everything. If you need hints on setting up your Pi itself I have all notes I use for my Pi setup stored in install.txt.

Now hack on and build your own uber-geeky baby monitor!

With my new display driver . . . → Read More: Watterott MI0283QT-9A Display for the Rasbperry Pi]]> In my last post I attached the Watterott Display to my Raspi. The model MI0283QT-2 I have here is not available anymore and was replaced with the newer MI0283QT-9A display modul. Unfortunately, this new display uses a different graphics chip and thus the driver I wrote won’t work for these panels…

With my new display driver skills, I thought about adding this new module, too A few days ago I received this new model and on the weekend I finally found a little time to investigate the new driver code… The new chip is an ILI9341 and uses a 9 bit SPI protocol to receive its commands… Phew, sounds a bit strange but notro’s fbtft driver framework again comes to the rescue: he has already supported the Adafruit22 which also uses 9 bit transfers and he also added an 9-bit SPI patch for the Raspi Linux kernel… With this starting point I was able to support the new display in a few hours:

Watterott's new MI0283QT-9A display running the boot console

Since the display supports the Linux framebuffer interface its also possible to run X11 with Xorg’s framebuffer driver on it:

The display also runs the X11 desktop

Again I was able to drive the display with a 32 MHz SPI clock (even 48 MHz works) and got a stable and smooth 25 fps for the 320×240 pixels in 16 Bit RGB.

If you want to setup this display on your own Raspi then read on…

Setup the ILI9341 driver

I won’t repeat all the details of the last driver setup as a lot steps are very similar. Just read the previous driver setup page and then you’ll find the differences here:

• The hardware setup is unchanged! Its a HW compatible replacement module.
• The new driver is called ifi9341fb
• My GitHub repository holds the new driver source: cnvogelg/fbtft
• Clone the source. Reconfig and rebuild your kernel.
• Select the new ILI9341 driver either as a module or directly place it in the kernel
• Test run:

modprobe ili9341fb
modprobe spidevices name=ili9341fb cs=1 fps=25

Use pre-compiled Kernel

If you don’t want to recompile your own kernel then you could use the binary drop I have uploaded on my site:

• Download raspi-linux-3.6.11-ili9341.tar.gz
• Unpack the archive
• The files in boot directory need to be copied in your Raspi’s /boot directory
• The files in root directory need to be places in your Raspi’s / (root) directory
• Make sure to backup your existing files in these directories first before overwriting them!
• Also ensure to keep the files in the same hierarchy as found in my archive.
• I use an 12.11 Ubuntu System (as vmware on my Mac) to mount my Raspi SD card and perform the changes there. This is the safer approach as I don’t replace the running directly on the Raspi…
• Insert your updated sd card and enjoy booting with your display’s console…

X11 on your Display

• Setting up the X11 desktop on your Raspbian system is fairly easy:
• Install the frame buffer driver (as root):

# apt-get install xserver-xorg-video-fbdev

• Create a config file with following contents in /usr/share/X11/xorg.conf.d/99-fbdev.conf:

Section "Device"  
  Identifier "myfb"
  Driver "fbdev"
  Option "fbdev" "/dev/fb1"
EndSection

• Now you can startx as a user and the desktop will be on your display:

> startx

That’s it for today… and enjoy your tiny desktop on the Raspi

BTW: notro was so kind to include my last driver in his mainline source tree… So you could grab the source also from his repository.

A very nice and cheap TFT display is the MI0283QT-Adapter (note: I got the -2 version not the newer -9 . . . → Read More: Watterott Display on Raspberry Pi]]> I really like my Raspberry Pi, but what I am missing is a tiny display matching the size of the board that can be used as primary display, the boot console or some graphics later on.

A very nice and cheap TFT display is the MI0283QT-Adapter (note: I got the -2 version not the newer -9 version that has another display driver chip!) sold by Watterott. Its mainly focused to be an add on for the Arduinos, but it should work on every embedded system providing SPI access.

For the Linux running on the Raspberry Pi a framebuffer driver for the display would be the best solution, as it allows you to use it as a boot console and then you can run everything that runs on a framebuffer device (e.g. X11, SDL, mplayer, …).

First I thought about writing a fresh driver from scratch but some google-fu showed me that there already exists a nice solution: user notro has written fbtft, a driver framework that allows to simplify writing an own driver for those tiny TFTs.

For the R61505u display chip found on my display board, there was no driver available, but thanks to notro’s powerful framework and Watterott’s example code (Thanks to Markus for porting the code to the Raspi), I was able to derive a new driver for this chip in a few hours: See my cloned fbtft Git Hub repository for the source.

It works really nice: with 32 MHz SPI clock I can run 25 frames per second and even watch movies with smooth display:

Playing Big Bug Bunny with MPlayer's fbdev output

If you compile the driver directly in your kernel (i.e. no modules) then you can use the display directly as the boot console of your board:

Linux Boot Console running on display

If you want to build this setup yourself then read on…

Build this yourself

The following notes should guide you through the task of setting up the display yourself. Its not a step by step manual but rather a collection of hints and tips. It is assumed you are familiar with low-level stuff like building and setting up a new kernel for the Raspi, so you have been warned

Hardware

• I used Adafruit’s Raspberry Pi Proto Plate as a prototyping board for setting up the required connections between the Raspi and the display
• Its a very simple setup: only wires required
• The following connections are required:

Name       Raspi        Display Board
+5V        2+4          3+4
GND        6            1+2
CS_DISP    26 (CE1)     7
RST_DISP   16 (GPIO23)  6
LED_DISP   18 (GPIO24)  5
MOSI       19           8
MISO       21           9
SCLK       23           10

• See elinux.org’s Page for details on the Raspi pinout
• See Watterott’s schematics for details of the display board

Software

• First have a look at notro’s wiki pages: There you find details on how to clone the Linux kernel source and set up everything on your system.
• I prefer cross-compiling the kernel on a Ubuntu host system for speed reasons. Have a look at elinux.org’s Kernel Compilation Page for details.
• Remember to replace notro’s GitHub source tree with mine:

git clone https://github.com/cnvogelg/fbtft.git

• For a first test use the following commands:

# modprobe spi-bcm2708
# modprobe spidevices name=r61505ufb fps=25
# modprobe r61505ufb

• This will initialize the display and clear the garbled initial display to a black screen that is lit with the backlight. You’ll find the framebuffer device /dev/fb1 in your filesystem
• Install mplayer and get a movie file. I used Big Bug Bunny and the 320×180 IPhone version. As root you can try:

# mplayer -vo fbdev:/dev/fb1 BigBuckBunny_320x180.mp4

• Enjoy the smooth playback!

This setup works great if you want to use the display after boot up as a second screen. However for a first screen you have to compile all drivers into the kernel itself:

• Again follow notro’s guide
• For the platform specific setup I prepared a r61505ufb patch that you can apply to your source
• Build a fresh new kernel and if everything worked out ok then your Raspi will boot into your new console display…

Have fun with your new tiny but shiny Raspi display!

Today I had a really fine idea on how to better store all the SD cards I have lying around here on my desk…

With lots of retro projects using SD card as primary storage media I have lots of them here on my . . . → Read More: SD Card “disk box”]]> Its getting colder outside and its time for cool retro projects!

Today I had a really fine idea on how to better store all the SD cards I have lying around here on my desk…

With lots of retro projects using SD card as primary storage media I have lots of them here on my desk (e.g. for sd2iec, Chameleon 64, some Raspberry Pis, Arduinos …). All are usually shipped with their crystal plastic cases that also take up space…In daily use most of them are piled on the desk and the cases fly around somewhere else. So I really needed something to clean up this mess a bit.

Today, I copied some 5.25 inch diskettes for my real C64 machine and while storing the floppy disks back in the floppy disk box, I had an idea… why no build a disk box for SD cards?

After some hours of paper work the job was done:

If you want to build your own SD card disk box: Here are some hints:

• Basic housing was the packaging of a SAM 256 uController from Olimex
• I cut away the top cover and used the spare cardboard to model the separator in the middle
• Finally I completely covered the box with self-adhesive plastic foil (Here in germany its called d c fix)
• The foldaway dividers were cut out from SD card packaging (its a mixture of cardboard and plastic foil and its really durable) and stuck into a ground plate so you can move them a bit.

Now, its on to you! Prepare your scissors and start the paper hacking today

BTW: Another retro paperware project fits very well with this project: There is a thread on Forum64 that describes how to build scale replicas of 5.25 disk sleeves for your SD cards. See this thread for details and also downloadable PDFs with the sheets of construction paper…

With . . . → Read More: vamos runs on Windows now]]> User kyberias was so kind to port the native part of vamos (the m68k emulation) to Windows and send me his patches for inclusion. The port is now included in my source tree and Windows user can now enjoy using vamos on their platform, too. Have a look at the README.WIN for build instruction.

With Mac OS X and Linux/*nix support available since the beginning, vamos is now available on all major platforms.. Yay!

This was a . . . → Read More: Build an Arduino-based Temperature Logger]]> Ok, this time its no retro project, but a rather useful tool to measure your temperatue at home over a longer period of time. I had trouble with my heating devices at home and so I wanted to record and present temperature curves of various rooms to show that something is wrong…

This was a friday night project and done in a few hours (some might call it a hardware hack – but it works fairly stable for weeks now!). All you need is an Arduino 2009 Board, a Logger Shield, a push button, 2 1k resistors, and a DS18S20 temperature sensor. With these ingredients I was able to build the following compact temperature logger:

Arduino and Logger Shield: Temperature Logger

The logger samples the temperature every 10s and gives you a digital temperature value with +/-0.5 degree Celsius precision. It has a RTC (real-time-clock) on board that time stamps every measurement. Addionally, the SD card allows you to store the temperature samples in log files.

The logger has two modes of operation: Either directly read the temperature via a Mac/PC connected via the virtual serial port available on USB or write a temperature log onto the SD card. The latter mode allows you to use the device stand alone in any room without the need to directly connect your computer.

Read on for the full build and usage instructions…

1. Hardware

You need:

• an Arduino board (I use an Arduino 2009 but UNO will be fine, too)
• an Adafruit Logger Shield
• a push button (to toggle SD card recording)
• a DS18S20 digital temperature sensor
• 2 1k resistors

Use the prototyping area of the Logger Shield to attach the push button and the DS18S20. The following fritzing.org schematic shows you the required connections:

Note: the LEDs and the associated resistors are already available on the logger shield. You only have to connect them to the Arduino on DIGITAL 3 and DIGITAL 4 pins. The LED pins have connectors right beside the two DIGITAL ports. So two small wire bridges will connect them. The push button is connected to DIGITAL 2 and the temperature sensors data channel to DIGITAL 7. The temperate one-wire bus needs a 1k pull up to 5V while the push button uses a 1k pull down resistor.

Here is a summary of the connected digital ports:

• DIGITAL 2: push button input
• DIGITAL 3: LED (green) output
• DIGITAL 4: LED (red) output
• DIGITAL 7: temperature sensors DS18S20 DQ data channel

That’s it for the hardware… and don’t forget to add a battery for the RTC (real time clock).

2. Software

2.1 Firmware

The firmware is hosted on my github site:

• GitHub: ardu.git

• git clone git://github.com/cnvogelg/ardu.git

Simply clone this repository and have a look in the datalog directory:

The file datalog.ino is an Arduino IDE sketch you can directly open there.

Note: the sketch requires the RTC and SD FAT FS library that is available at Ladyada for the Logger Shield: see the Logger Shied Download page for details and install the libraries first!

Open the sketch and flash it on your device…

2.2 Configuration

Before you can use the data logger you have to configure it:

• In the Arduino IDE open the serial monitor (Tools -> Serial Monitor) with 57000 Baud and Line Ending Both NL+CR
• Insert a FAT formatted SD card and power the device
• If the green LED is enabled then everything is fine and SD and temperature sensor was detected. You can see the serial number of your sensor:

DS18S20: 10 83 B4 8D 2 8 0

• If the red LED blinks then an error has occurred:
  • Either the sensor was not detected:

FATAL: ADDR?

• • Or the SD card was not found:

FATAL: SD

• • In both cases have a look at your wiring or your card to fix this…

Now we are ready to set up the RTC (real time clock):

• You can enter commands in the Serial Monitor and send them to the device
• The following commands are supported:
  • ‘r’ – read clock (load time and date from RTC chip and print it)
  • ‘a’ – adjust clock (save the current values for year, month, day, hour, minutes, seconds to RTC chip)
  • ‘y’ <nnnn> – set year: 2012 …
  • ‘m’ <nn> – set month: 01 .. 12
  • ‘d’ <nn> – set day of month: 01 .. 31
  • ‘H’ <nn> – set hour: 00 .. 23
  • ‘M’ <nn> – set minute: 00 .. 59
  • ‘S’ <nn> – set seconds: 00 .. 59
  • ‘o’ – open log on SD card for writing
  • ‘c’ – close open log on SD card and stop writing
  • ‘D’ <nnnn> – interval of measurements in seconds. default: 10s
• So for setting up the clock to: 28.11.2012 18:34:20 you would enter:

y2012
m11
d28
H18
M34
S20
a

• Now your RTC is set up and you should see incoming measurements like this one

t: 2012.11.18 19:39:03 50A93957 +024.50 0189
t: 2012.11.18 19:39:13 50A93961 +024.50 0189
t: 2012.11.18 19:39:23 50A9396B +024.50 0188

• Each line has the following columns:
  • date and time
  • raw date and time in hex
  • temperature value in degree celsuis
  • raw temperature value in hex

3. Stand-alone operation

Start Logging:

• Detach the Arduino from your Mac/PC
• Use a USB power-supply to power the logger now
• Make sure the green LED is enabled after power on (SD card is attached and sensor is OK).
• Now press the push button to start the logging operation
• The red LED is enabled and shows you that data is written to SD card
• Each time the green LED blinks a measurement is taken and written to the log file

End Logging:

• After a while stop logging by pressing the push button again
• The red LED now is disabled and logging has stopped
• Now you can safely remove the SD card and have a look at your data
• Note: do never remove the SD card while the red LED is on this might corrupt your data on the card!
• On the SD card a data file is always named yymmdd_s.LOG with yymmdd being the current date and s a letter starting from A that is incremented with every new log

4. Plot a Temperature Graph

You can now use your favorite spread sheet application or graphing tool to convert the data log files from the SD card to pictures.

In my code repository I have written a small Python script that uses rrdtool to plot the graphs (see datalog/tools/plot_log.py):

Run it as follows:

python2.7 plot_log.py ./plot_log.py 121104_A.LOG out.png

This will create an image like this:

Now, have fun building your own device and inspecting your home’s temperature

What does this tool do?

Its a disk image file scanner that inspects Amiga disk (.adf) or hard disk (.hdf) image files for AmigaOS OFS or FFS file systems. If such a file system is found then the scanner . . . → Read More: added new amitool: xdfscan]]> I added a new tool to amitools, my set of cross platform classic Amiga tools: xdfscan!

What does this tool do?

Its a disk image file scanner that inspects Amiga disk (.adf) or hard disk (.hdf) image files for AmigaOS OFS or FFS file systems. If such a file system is found then the scanner runs a validator that does an in-depth check of the whole file system structure. If anything does not match or does not fulfill the file system specification then error or warning messages are generated. Warnings are usually not critical and the files on the image are all accessible, but error messages may hint to file corruption in the image. In the latter case it is advisable to recover the image by running a xdftool repack command or by issuing a DiskSalv running on an emulator.

This tool either scans a single disk image file or scans through a full directory tree. The latter operation allows you to quickly scan your disk image collection with a single run…

Have fun scanning your disk collections for corrupt or even broken images… (I must admit that the scanner is really picky and it found some issues on images I believed that were running Ok for years on a real machine… So don’t panic if lots of warnings or errors are reported… AmigaOS is quite robust handling these disks without reporting trouble…)

The first release includes full DHCP support and statically configured Ethernet operation, so it should work on most local networks out there. With ARP and TCP/UDP/IP bridging in place, it . . . → Read More: plipbox firmware 0.1 released]]> The wait is over: the first firmware release of the plipbox project is available. Simply head over to my plipbox page and fetch your copy…

The first release includes full DHCP support and statically configured Ethernet operation, so it should work on most local networks out there. With ARP and TCP/UDP/IP bridging in place, it has all essential features I envisioned for this project already available… And it really works well: I am already totally used to have my Amiga 500 in the network… (without thinking about starting a SLIP server first

Now I hope that it works for you, too… just drop me a comment if you found bugs or have any remarks!