Saturday, 17 January 2015

Work (re)starts on the 3D printer

Attending:- Mike, Joe, Tony, Les, Michael(2), Richard, Arthur, Elizabeth, Susan, Phyllis, Kieran

We were donated a 3D printer in need of some TLC last year. 
Details of the printer here, :-

Donald started the ball rolling in October by refitted the filament drive motor and also re-aligned the the other drive belt. Description of the work is here:-

Various other small adjustment have been made since, including relocating and aligning the two vertical drive motors.

Today, Tony and Les decided that they wanted to experience building the 3D printer from scratch, this entailed dismantling the printer back down to it's component parts. Here they are discussing if they have enough boxes to put all the bits in before they start.

This is what our 3D printer looks like now.

Meanwhile, Mike continues work on his electric motor project

Arthur and Joe discuss RethinkDB

Elizabeth and Susan still trying to discover why the missing Pinterest button appears  and disappears . There is a long discussion on the mailing list about this.

Gaming talk

This event was powered by coffee and Jaffa cakes.

Saturday, 10 January 2015

2015 #1 - A Chromebook a smartwatch and a windows tablet

Attending This week: Mike, Jack, Chris, Joe, Les. Keiran, Ricky, Arthur, tony, Mark and Mike(2)

A very windy day in Blackpool today. 
Elizabeth and Susan decided not to risk the journey in the little smartcar.

Jack takes a break, Mike looks at the possibility of rewinding an electric motor for a very specific role.

Multiple and diverse discussions around the table.
 There was a lot to talk about following the Christmas / New Year break.

Chris showed off his new Chromebook, and explained how to get Ubuntu on it.

Then Chris demonstrated a smartwatch 

Arthur 'upgraded'  his windows laptop to dual boot with Linux Mint, with the help of Tony.

Les showed off a 7" windows 8 tablet obtained for the bargain price of £60
Attempts to get Linux on it are ongoing.

Sunday, 4 January 2015

Temperature monitoring display using old Android tablet

My home temperature monitoring project moved on another step with the addition of this  old Android 2.3 tablet used to display the current temperatures around the house. Two downloads from the app store were needed,  Stay awake , and Web reloader .  One keeps the screen permanently on, and the other one  is needed to refresh the page regularly to update the temperatures. 

I started this project several years ago, and this post shows the original stripboard arduino/shrimp and 433 tranceivers 

Later, I switched to using separate transmitters and receiver like these:-

And these are the Dallas DS18B20 1-Wire Digital Thermometer temperature sensors:-

This is a later version of the temperature transmitter which is battery powered by 4 rechargeable AA batteries. The circuit board is sitting on top of the battery holder.

An overview of the project so far.

There is one standard arduino uno fitted with an ethernet shield and a 433 receiver, this is the gateway.  The Gateway receives the temperatures from the transmitters, and forwards the temperatures to Xively (used to be called cosm, then pachube) . The android tablet is displaying the xively web page. Next up,  add a raspberry pi to do data logging and a web server to replace xively.

So far, all I have is monitoring, and the next major step forward will be control.
Recently, I have been experimenting with turning electrical appliances on and off using the pi with the 433 transmitter mentioned above, and these radio controlled power sockets:-

The on/off signals produced by the remote control have been decoded, and can be reproduced by the pi, and sent via the 433 transmitter. A basic web page with buttons that mimic the layout of the remote control is used to turn the switch on and off. This will be the subject of another post.

Happy new year to all.

Saturday, 3 January 2015

i2c working and noisy sensors

i2c working!

I had tried many things to get basic i2c working on my RasPi B+ and despite lots of help, failed miserably.  I bought an A+ for another project and got i2c working straight away.  There are lots of tutorials on i2c on the Pi and a really good script that I mentioned in my last post so I won't be going into setting up i2c.

The test that shows whether you've been successful is running sudo i2cdetect -y 1 and having i2c components you have connected to the RasPi appear:

i2cdetect discovering my compass and gyro/accelerometer devices. (The device at UU is related to the Pi)
In the screenshot you can see that I am using the latest Raspbian image that was released last month.

I updated my RasPi B+ to the latest image and on a whim tried i2c on it and it worked!  I had thought I'd fried the i2c hardware, but I guess now that I had somehow broken something in the image, can't think how or what, but anyway refreshing the Raspbian image fixed it.

Cheap i2c devices from eBay

So the two i2c devices I have connected to my Raspi are a Compass and Gyro/Accelerometer.  Both are really cheap units.  I got the Gyro from a UK supplier because I didn't want to wait for it to come from China.

This text is what to search for if you wish to buy these and link to the actual items I bought on eBay

Both units can be bought for about a quid from China, which is amazing value for such interesting modules.

My new Raspi A+ hooked up to i2c Compass and Gyro/Accelerometer
The image above shows the units connected up, in both cases you simply need to connect v3.3, Ground, i2c Clock and i2c Data.  Nothing else to do, it couldn't be easier. Both of these units work at v3.3.

There are wires and buttons at the back of the breadboard where I was playing with the internal pull up and pull down resistors on the RasPi GPIO.

Python and Tkinter interface

As a learning exercise I put together a Python and Tkinter interface to display the output from the sensors.  I found that to get the Tkinter to work well on the Pi I was better off using Python 2.7 which was really disappointing.  

I originally wrote my own Python class to encapsulate the compass module but the results seemed iffy so I found a class that is better than my effort here: as it turns out, the problem is that the area of my desk where I am testing the compass is awash with magnetic interference, which I proved with my trusted Silva compass I use for hiking.  In fact the output from the compass sensor is just as iffy with the better code.

Looking at the interface, I have created a canvas in Tkinter and draw a yellow line for the compass heading and move red and green circles around for the gyro and accelerometer.

I only take notice of 2 out of the 3 data axis that the sensors give, this leads to inaccuracies in the compass if it is not kept horizontal, these inaccuracies can be fixed in code by doing the math in 3 dimensions.

The video shows just how noisy the data is.  To the point that it's difficult to interpret if the Gyro is working properly at all.

My balancing robot has 3 accelerometers on it and I have been working on the Python code (the robot has a micro Python board in it) to get a very smooth and fast accelerometer reading of tilt (by measuring the acceleration due to earths gravity) and I need to work out how to clean that up when the robot is falling and there are accelerations due to actual movement.  I have moved the accelerometers as close as possible to the wheel axis to minimise the unwanted effects of movement but there are a few challenges.  The video shows nicely what we are up against using cheaper sensors for our small scale robotics.

Monday, 29 December 2014

Triggering PWM with a push button on an Arduino

I was asked how to control PWM with a push button on an Arduino.  I thought I'd blog it and then I can link them to this post.

Heres my setup:
Under the skull printed paper circle is a brushed DC motor that used to operate the tray on a CD-ROM drive.

Heres the fritzing drawing of it
Note that usually you'd use something like the Arduino motor shield to control a load like a motor with an Arduino, here we are ok because we are just spinning the motor with no load on it.  The danger is that a motor could draw more current through the Arduino than it can handle.

This is my code. 

int pinButton = 13;        // Pin 13 is handy as it has an LED on the Arduino board attached to it
int pinPWM = 11;           // Pin I am using as PWM output to power the motor directly
int iPWMValue = 53;        // This constant value controls the speed
boolean bReleased = true;  // Used to ensure the user must release the button fully before pressing again

void setup() {
  // Nothing to setup


void loop() {
  if ((digitalRead(pinButton) == HIGH) && (bReleased == true)) {
    bReleased = false;              // Set the bReleased flag
    analogWrite(pinPWM, iPWMValue);  // Start PWM output to turn the motor 
    delay(55);                       // How long the PWM signal will be sent to the motor       
    analogWrite(pinPWM, 0);          // Stop the PWM /motor from turning
  if (digitalRead(pinButton) == LOW) {
    bReleased = true;                // Reset the bReleased flag now the user isn't pressing the button


(( mmmmm.... white space however I want it and braces.... :p ))
(Apologies to Mike Hewitt who I know doesn't particularly like comments at the ends of lines of code!)

The code uses the boolean variable bReleased to ensure that once the button has been pressed it has to be released before being pressed again.  The motor just turns a set amount each time the button is pressed and holding the button down doesn't make the motor continuously rotate.

The amount the motor rotates is set by the delay(55) in between the code that starts and finishes the analogWrite (which is what starts and stops the PWM output). So as this delay is between the PWM output starting and stopping it controls how long the PWM output is actually on for.   I found the number 55 by trial and error, trying different values until I got the effect I wanted.

The iPWMValue (53) is defined at the top of the code and used like a constant. A constant is just like a variable except whereas you can expect the value of a variable to change, the value of a constant stays, well, constant.  The reasons you would code like this are for readability and also if you were using the iPWMValue in several places and wanted to change the value you only need to change the value once in one place for that new value to be used everywhere.  Whereas if I had used the value 53 everywhere its harder to follow what the 53 means and if I needed to alter the value I need to find every place I'd used 53 and change it manually.  

The iPWMValue is passed into the analogWrite command to set what part of the PWM cycle is on.  The larger the value the more power is output and the faster the motor will turn. Please take a look at the Arduino PWM tutorial for a better explanation of PWM.    

I got to the value of iPWMValue by trial and error in combination with the delay(55) value to get the effect I wanted on video.  In practice you'd probably use a motor with a gearbox on it, here the motor is driving the disc directly. What I found was that the motor didn't like being driven too slowly. If there was a gearbox it would be possible to have the motor spinning much faster whilst the actual disc would rotate at the desired slower speed.

Here is a video of the the project doing what it does:

Sunday, 28 December 2014

Saleae Logic Analyser (£20 Chinese Clone)

Chinese clone of a Saleae logic analyser. (Personally I think it's taking the michael actually labelling the thing with 'Saleae'!)

I've been having trouble with I2C on the RasPi and asking around I was advised to try a logic analyser.  I was a bit cynical about this as at first sight it seemed to be a rather expensive way to see digital activity on the I2C bus. I've looked at the I2C protocol and I'm not excited/interested in the nuts and bolts, protocols and timings of I2C, I just want it to work. Another guy recommended I slow the I2C bus down and use a normal logic probe to see activity, I have a very old logic probe a friend gave me many years ago and this was the path I started down trying to work out why I2C wasn't working for me on my RasPi.

An aside - I think I've broken my RasPi...

In fact, the I2C of my RasPi appears dead. I spent hours researching and making sure I'd set it up right and on Les' recommendation used Heeed's I2C setup script (I also recommend it, it can be found here:  

When I run i2cdetect on the Pi I'd expect to see activity as the Pi queries the various bus addresses for a response.  On my Pi the I2C pins never show any activity.  I did try my I2C compass module at 5v on there, fully aware the Pi dislikes 5v but with an optimistic 'I'll probably get away with it', maybe I didn't get away with it...  

I'm going to get a Pi A+ at some point soon and I'll try again with that (being more careful with my voltages).

Back to logic analysers...

My friend advocating the Logic Analyser sent me a link to the one he was recommending:  I hadn't realised the thing was just £20!  

This is obviously a Chinese clone of the Saleae analyser with all of the risks that means.  The one review I saw was negative, saying his was DOA and he had to get his soldering iron out to get it to work.

Another worry was the software to run it, the highlight of this unit is that it is compatible with the excellent software Saleae supply for their pukka analysers. More information here:  I read some reports that the software had been updated earlier this year and no longer works with the clone analysers, but on further investigation there are clones that are even cheaper than this one and it's them that have problems.

I decided to go for it and went with the one through Amazon.

It does what it says on the tin and at the right price

It took about a fortnight to arrive from China.  It came packaged OK but with no manual and very cheap cabling.  

The cheapness of the cables was soon forgot when the thing just worked flawlessly with the latest (beta) Saleae software (it also worked with the current stable version of the Saleae software, but the latest beta has many improvements and seems stable).

The excellent Saleae software in operation showing a trace of changing PWM coming from an Arduino

To test it I decided to play with PWM on the Arduino (and Micro Python - I hope to do a post on micro python another day).

Arduino doing analogWrite (PWM) to pin 9 to fade an LED - Analyser is setup to monitor the PWM
To generate a trace for the analyser to analyse I fired up the sketch associated with this tutorial: and got the trace above.
 All in all £24 (inc postage) well spent, and I bet you could find this unit even cheaper on aliexpress (but be careful you don't buy one that doesn't work with the latest software: ).

Saturday, 20 December 2014

Blackpool LUG and Makerspace Christmas party 2014

Attending our final meeting of 2014:

Michael, Tony, Les, Olly,Joe, Elizabeth, Kieran, Mike (2), Richard, Arran, Arthur, Jack, Surly Dev and James

I would like to thank everyone for their help and support over the years.

 We now have 10 years 'under our belt' as a Linux user Group, and 3 years as a combined LUG and Makerspace.

Happy new year to all.

Elizabeth sums up the morning as follows: "Dear Mike and All

Thank You so much for a lovely Christmas Party this morning.  Just brilliant & quite as memorable as last year's party.

Thanks to Santa Les for bringing in all the Pressies - and thanks also to all who brought nibbles, especially Tony for baking the mince pies too, they were delicious!

Thanks to Michael and Tony for helping with the stubborn HP half laptop also.

Just a lovely morning!

Best Wishes for a really Happy Christmas and a wonderful New Year.

Thanks again all, see you in 2015!