Wifi success, for a change!

I’m actually having success in connecting the super-cheap WI07C wifi module to my home network, so that an arduino can send data anywhere.

WI07C module featuring esp8266 chipset

WI07C module featuring esp8266 chipset

I can now reliably establish a TCP connection and send data back and forth. It works rather well, with some limitations. It helps that I came across some slightly better documentation, sourced from this esp8266.com forum post which lists a few more AT commands and some more illuminating explanations.

AT+CIPMODE

AT+CIPMODE=1 or 0 (1 is default) sets the data receiving mode of the socket. If it’s 0, received data is simply sent to the serial port. If it’s 1, data gets “+IPD,c,n,” prepended to it, where c is the channel number and n is the number of bytes received. c is omitted if you are in single-channel mode. If you have multiple connections going in, this mode is logical. If you have only one, it may be simpler to use the transparent mode (AT+CIPMODE=0). But see AT+CIPSEND below, because this is affected by AT+CIPMODE!

AT+CIPSEND

The usual documentation about this is a bit pants. Here’s how it works. When you issue an AT+CIPSEND command, you normally tell it the channel you want to send it over (the chip can keep four IP connections going at once) and the number of bytes you want to send (call it n). The module then responds with a “>” character. It will then take the next n bytes you give it and send them over the TCP link. Then it responds with “SEND OK” and returns to normal, waiting for your next command. There are three variants of the AT+CIPSEND command, however:

AT+CIPSEND=channel,length is used if you have multiple connections open (AT+CIPMUX=1)
AT+CIPSEND=length is used for a single channel (if you have previously issued AT+CIPMUX=0 to tell it that you will only use one connection at a time)
AT+CIPSEND can be used without any parameters if you are using a single channel and transparent data mode (AT+CIPMODE=0). Note that there is no channel or length specified in this variant. After you issue the command, it will simply send every byte you throw at it directly to the receiving socket. This includes AT+ commands. Note that I have as yet found no way of exiting this mode other than resetting the module.

Also note that if you are in transparent data mode (AT+CIPMODE=0) and you try to use the variant of AT+CIPSEND which uses a length value, it won’t just fail or ignore it, it will actually reboot the module.

Lesser known AT commands not in other documentation

AT+GMR

AT+GMR retrieves the firmware ID of the module. There are at least two versions in the wild.

AT+CIPSTO

AT+CIPSTO=60 Sets the socket timeout period to 60 seconds
AT+CIPSTO? gets the current timeout value
You might want to change this value because if the server closes the socket, and your timeout value is too high, there appears to be nothing you can do from the client end other than do a hardware reset. I’m thinking it’s probably going to be necessary to tie the CH_PD line of the module to an output from the arduino, as I’m bound to want to reset from software at some point.

It’s good to make some progress. I’m going to look at the using the module as a server next.

WiFi for less than a fiver

Last week, the excellent hackaday ran a story about a new WiFi module (the Wi07c) based on the ESP8266 chip. It is eminently suitable for attaching to an arduino or similar, but it only costs $5. As I’ve been whining for some time about the high cost of WiFi shields for arduino, this piqued my interest. I bought a couple from the electrodragon store and have now had a bit of time to play with them. It seems that for once I’m a little ahead of the game – other people seem to be waiting a long time to receive theirs. The documentation is a little sparse, but enough to be going on with. There are three main sources, mostly community-supported: electrodragon, a hackaday.io project and nurdspace. The device is serial-driven, using a limited set of AT commands which will feel familiar to anyone who has worked with GPRS modems.

I’ve connected one of the modules to an arduino, and done some testing. I’ve also driven it directly from a serial terminal on my PC. These are my findings so far:

  1. The module runs at 3.3V, not 5V. The 3.3V available from an arduino can’t provide enough current to power it (though it may seem to). The WiFi module won’t even respond to commands without a separate power supply. Powering it from one of these works fine.
  2. In the version of the module I have, you must connect the CH_PD pin to +3.3V. Don’t be put off by the suggestion in the diagrams on Nurdspace.com that the four pins in the middle of the connector are not connected to anything. CH_PD is the pin next to the TXD pin.
  3. The AT commands mostly work. AT+CWLAP briskly returns a list of visible access points. AT+CWJAP connects to my home router (or claims to). Beyond that, things get flaky. Actually setting up a TCP connection to a running server does not seem to work. Nor does sending UDP. both allow me to get to the point of sending data, but then simply respond ‘busy’ to any further command or data until the device is rebooted (by unplugging it from the power supply). I’m not convinced that the device is ever genuinely connected to my router: the router doesn’t show it in the list of active clients.

I’ll keep experimenting with it, but I’m frustrated. It seems so close to being functional, but isn’t quite there yet. It feels like the firmware is missing some useful commands and diagnostic information. Or maybe it’s the documentation. Perhaps if my Chinese was better…

It’s not my fault!

It’s probably not my fault, at least.

If you’ve been following my blog (and why wouldn’t you?), you’ll know that I have had some issues with my 3D printer printing things skewed. It got particularly annoying a day or two ago when a five-hour print ended up unusable. It’s about time I got this problem sorted out. Annoyingly, it seems that every time I do a test print, the problem goes away. Indeed, a test print after the last failure was absolutely fine. Perhaps it is time to apply logic, and isolate the causal factor. My test prints tend to be small (so that they are quick and cheap), but I notice (or perhaps only care about) the problem on large objects which take a long time to print. This morning, I printed a set of test objects of increasing size, to see if the problem was size related. The objects I used as test pieces were simple hollow square-section blocks, connected by a thin strip. The model looked like this:

test_pieces

I printed each of the pieces individually, smallest first. The results were very interesting:

size-based distortion 2

size-based distortion 1

As you can see, the first three parts printed fine (I’m not worried about the finish quality, just the geometrical straightness). Only the largest one had any skew at all. The really weird thing is that the skew was pretty constant over the entire width. To me, this strongly suggests a printer firmware issue. If the hardware were misaligned, or a drive were slipping, I would expect to see this on all the prints. A structural problem would surely show up gradually as the parts grew bigger, or possibly show up more the further from the centre the print head moved. In fact, the skew at the centre is the same as the skew at the ends of the part, and there is no skew at all on the second-largest component.

So if the problem is not the hardware (that’s why it’s not my fault :-) ), what is it? It could be the slicer, but this seems unlikely because I have used both Slic3r and Cura. Printing gcode files from either can have the problem. This seems to leave only one culprit: the printer firmware. I’m thinking that there is some rounding error, or some motor step-counter in the firmware which is overrunning or accumulating a consistent error on long print head movements. As the print head moves back and forth along the x-axis, this error fails to get reset between z-slices. Each layer is slightly offset from the one before. With smaller parts, this error simply does not occur. This is speculation at the moment.

I’m currently using Marlin firmware. My install is at least a year old, so my first step will probably be to upgrade to the latest version. This might be a bit of a pain, because I made a few customisations when I installed the last version, to suit my printer. If that doesn’t sort the issue out, I’ll have to delve into the source code. At least Marlin is open source, so I can fiddle with it.

Disappointment is…

… finding your five-hour print is faulty

Hmmm. Yesterday I replaced the heater in the printer’s hot end, vastly improving printing. Today I replaced a faulty power switch, reducing the chance of the printer cutting out mid-print. There seemed to be no reason not to make a start printing some of the bigger components I’ve been working on. Here’s the first one:

large thing 01

Don’t worry what it is. All will be revealed eventually. it’s a substantial bit of plastic, and demonstrates why I wanted to build a 3D printer in the first place. How else could I make components like that without a proper machine shop? I still want a proper machine shop, by the way, but I love the fact that I can make lightweight, stiff components straight from CAD models. I mean, just look at it.

large thing 02

So, you might think all is well. This component took five hours to print, and the printer didn’t miss a beat. What it did do, however, is print the whole thing skewed. It’s not immediately obvious, but look at this:

disappointment 01

and this:

disappointment 02

Makes you want to cry, doesn’t it? Both of those sides should be vertical, in case you didn’t realise. In fact the whole thing has been printed with a slant on it. I’ve had this problem before, but I thought I’d cured it by increasing the tension in the drive strings (the fault being that one or more was slipping). Clearly I hadn’t. Back to the drawing board I go.

Always remember: that which does not kill us makes us really annoyed.

Things are hotting up

I haven’t posted much about the 3D printer recently (or indeed about anything else). This is partly because I have been trying to work out what was the cause of poor print quality. I’ve finally worked out what the cause of the problem was. I’d been finding it increasingly difficult to print larger objects, particularly those which involved long continuous print movements. The symptom seemed to be a lack of material being extruded. I’d tried turning up the filament feed rate, but this only led to the extruder slipping as it tried to drive more filament through the print head. I turned up the temperature setting, to make it easier to extrude, and this worked over shorter movements, or at lower speeds. I could only get half-decent results by printing very slowly, with a feed rate of 120%.

The cause of the problem turned out to be very simple. The resistor used to heat the hot end simply could not provide enough heat to melt filament at the required rate. At low speeds, no problem. At higher speeds, insufficient power meant taht the hot end simply could not maintain the required temperature. Short distances were OK, because the hot end had time to heat up between extrudes.

The solution was to replace the resistor in the hot end with a cartridge heater. The J-head kit I bought came supplied with both options, and for some reason I can’t remember, I originally went for the resistor (there’s a picture in this previous post). Ten minutes of disassembly, rewiring and reassembly is all it took to fit the new heater. The hot end now reaches operating temperature much more quickly, and stays there very accurately, even if I turn the feed rate up and use a cooling fan. Goodness knows why I didn’t try it before.

Hot Pi

In my last post, I explained how to set up the Pi with the drivers needed to allow it to read temperatures from DS120B sensors. In this post, I’ll show you the code and setup required to make it start taking readings automatically at bootup, and store the information in a Mysql database for future use. I’ll also add a couple of LEDs to the circuit, so that the system can provide some feedback and also to pave the way for controlling a relay or two.

Here’s the updated circuit schematic (click on it for a bigger version).

heating_2_bb

There are a few things to note about this slightly more complex schematic:

  1. I’ve added another temperature sensor. Its pins are simply connected directly to the pins of the first one (and any subsequent ones). The one-wire protocol and the fact that each sensor has a unique ID means that they can share a common bus.
  2. I’ve added two LEDs, just so that the system can indicate some state to me. One will be replaced with a relay in future.
  3. I’ve added an Adafruit level converter (the blue pcb). This is there to protect the Pi: its GPIOs run at 3.3V, and are not designed to carry much current. overloading them will cause damage to the Pi. The cheap level shifter allows the 3.3V Pi pins to be connected to 5V input or output from other devices, and protects the Pi from accidental over-voltage. It’s not strictly necessary just to drive LEDs, but the relays I want to use later need 5V.

I’m going to use Python as the main language for running the system. The reason for this is that I don’t know it very well, and there’s no better way to learn than to dive in and try and do something with it. Of course, this also means that my Python code may well be what is technically-termed ‘Not Very Good’. Use it at your peril. To make it work, you’ll have o install a couple of other things. One is MySql, the database into which the program will write the recorded temperature values (you’ll also need the associated Python library). The other is pigpiod which is, of course, a Pi GPIO library, though the name always looks like pig-pio to me. Pigpio (also available in its useful daemon form pigpiod) is a C library which exposes all the GPIO to C programs. Not useful for Python, I hear you say. True enough, but it also exposes the same functionality through a TCP socket interface, and it’s dead easy to use this from Python without installing any special python libraries at all. We’ll deal with that in my next post.

Installing MySql

In Linux, it down’t get much easier than this:

sudo apt-get update
sudo apt-get install mysql-server

At some point, the installer will ask you for a password for the root MySql user. In any serious situation, this should be a good, secure, password. I just used the same one as I’m using for everything else on this device. It’s only a toy, after all. Once MySql is installed, you can use the command line client to create a new user and to make the ;temperatures’ database and the ‘data’ table in which the readings will be stored. NB: when you are using the MySql command line client, don’t forget the semicolon at the end of a SQL command line. Multi-line commands (such as the CREATE TABLE command below) are fine in SQL, and they don’t get executed until the parser sees a semicolon. It catches me out all the time.

mysql --user=root --password=My5ecurePa$5word

mysql> create user 'pi'@'localhost' identified by 'raspberry';
mysql> grant all privileges on *.* to 'pi'@'localhost';
mysql> create database temperatures;
mysql> use temperatures;
mysql> CREATE TABLE 'data' ('id' int(11) NOT NULL AUTO_INCREMENT, 
'timestamp' datetime NOT NULL, 'sensor_id' int(11) NOT NULL, 
'temperature' float NOT NULL,  PRIMARY KEY ('id'));
mysql> quit;

When that’s done, you will have a database with an empty table in it, and a user ‘pi’ which you can use to connect to it from python. For that’ we’ll need the python-mysqldb module. This can be installed thus:

sudo apt-get install python-mysqldb

We can check that this works with a small python script:

#!/usr/bin/python
import MySQLdb as mdb
import sys

try:
    con = mdb.connect('localhost', 'pi', 'raspberry', 'temperatures');
    cur = con.cursor()
    cur.execute("SELECT VERSION()")
    ver = cur.fetchone()
    print ("Database version : %s " % ver)
except mdb.Error, e:
    print ("Error %d: %s" % (e.args[0],e.args[1]))
    sys.exit(1)
finally:    
    if con:    
        con.close()

Run this, and if all is well you will see something like

Database version 5.5.37-0+wheezy1

Or possibly an error. With unbridled optimism, I’m going to assume that you are not seeing an error. It’s now time to create the code which will actually read the temperature sensors and write the data to the database. Here it is:

#!/usr/bin/env python
import datetime, time, sys
import MySQLdb as mdb

def getTemp(chipid):
   tfile=open("/sys/bus/w1/devices/"+chipid+"/w1_slave")
   text=tfile.read()
   tfile.close()
   secondline=text.split("\n")[1]
   tempdata=secondline.split(" ")[9]
   temperature=float(tempdata[2:])
   temperature=temperature/1000
   return temperature

try:
   con = mdb.connect('localhost','pi','raspberry','temperatures')
   with con:
      cur = con.cursor()
      while(True):
          timestamp = datetime.datetime.fromtimestamp(time.time()).strftime('%Y-%m-%d %H:%M:%S')
          t1 = getTemp("28-000001a9b68a")
          t2 = getTemp("28-0000009bba2b")
          query = "INSERT INTO data(timestamp,sensor_id,temperature) VALUES ('%s',%s,%s)"%(timestamp,'1',str(t1))
          result = cur.execute(query)
          query = "INSERT INTO data(timestamp,sensor_id,temperature) VALUES ('%s',%s,%s)"%(timestamp,'2',str(t2))
          result = cur.execute(query)
          con.commit()
          print ("%s %s %s"%(timestamp, str(t1), str(t2))
          time.sleep(60) 
finally:
   print ("Goodbye")

s.close()

There are two main parts to this code. The function getTemp(chipid) reads the virtual file created by the 1-wire driver discussed in my last post for a specific temperature sensor, and extracts the temperature data from it. There’s nothing clever about it, just python string processing. You’ll need to modify the code further down to use the chip ids of your own sensors, of course. The main body of the program establishes a connection to the database, then enters an unending loop inside which it gets the temperature from each sensor and writes it to the database with a timestamp using a simple SQL INSERT query. Adding a time.sleep(10) means that this process happens every 10 seconds. Assuming you run this without errors, you’ll find that your database will gradually be populated with temperature readings. You can check this using the mysql command line client again:

mysql --user=pi --password=raspberry

mysql> use temperatures;
mysql> select * from data limit 10;

+----+---------------------+-----------+-------------+
| id | timestamp           | sensor_id | temperature |
+----+---------------------+-----------+-------------+
|  9 | 2014-05-17 17:17:17 |         1 |        20.3 |
| 10 | 2014-05-17 16:45:10 |         1 |      22.187 |
| 11 | 2014-05-17 16:45:10 |         2 |      23.875 |
| 12 | 2014-05-17 16:45:21 |         1 |       23.75 |
| 13 | 2014-05-17 16:45:21 |         2 |      23.875 |
| 14 | 2014-05-17 16:45:33 |         1 |       23.75 |
| 15 | 2014-05-17 16:45:33 |         2 |      23.875 |
| 16 | 2014-05-17 16:45:45 |         1 |      23.812 |
| 17 | 2014-05-17 16:45:45 |         2 |      23.875 |
| 18 | 2014-05-17 16:45:56 |         1 |      23.812 |
+----+---------------------+-----------+-------------+
10 rows in set (0.00 sec)

If you have got that far, and are seeing data in the database, that’s excellent. In my next post, I’ll show you how to install pigpio and use it to flash an LED to give confidence that the process is working without having to check the database all the time. The next step is then to create a webserver which will show the data without having to log on to the Pi. Keep watching this space.

Warming to the Pi and Python

I’ve had a Raspberry Pi since Christmas, but haven’t done much with it up till now.  That’s all changed since I moved house.  Getting to grips with a new central heating system, I find that (for reasons too dull to list here) I need to monitor and control it rather more flexibly than I can do with the standard timer.  I also don’t want to pay lots of money for a Nest controller, however beautiful it may expect itself to be considered.  My first thought was to use an Arduino – the problem I’m addressing does not need a lot of processing power, and I don’t want to spend a lot – but I came up against a problem which seems to me to be the Arduino’s biggest failing at the moment.  I want to be able to control the system over WiFi.  There are WiFi shields for Arduino, of course, but they start at £30, twice the price of the Arduino.  I could invest in a Yun which has WiFi on board, but that’s £70.  There simply seems to be no cheap way of getting WiFi onto an Arduino – a device which is crying out to be connected to the internet..  Rob suggested I could use a bluetooth adapter and control the system from a phone; that has attractions and is very cheap, but means I have to be quite close to use it (no controlling the heating system from work, for example).  This made me turn to the Pi.  At first sight it seems ludicrous to use a full Linux computer for this trivial task, but consider: the Pi costs £23 (or less, for a model A), and the tiny USB WiFi dongle was only £9.  That’s £32 for the whole thing.  Much cheaper than an Arduino and WiFi combination. 

The hardware requirements of the system I want to build are quite simple.  It must monitor two or more temperature sensors, and it must be able to control two or three relays capable of switching mains voltage.  Having a couple of controllable status LEDs would be good, too.  I don’t require any other user interface input or display in hardware, because I want to use a web interface.  The Pi is more than capable of handling all this, but it turns out that there is quite a bit of software installation and configuration to do.  All of it can be done over a ssh connection (I use PUTTY for this), which is fortunate because I don’t actually have a monitor with an HDMI input that I can use as a display for the Pi.

The temperature sensors I am using are DS120B types.  Rather than being dumb devices like thermistors (whose resistance varies with temperature) they have logic inside which allows them to communicate with a host over a three wire digital serial connection.  The manufacturer calls this ‘1-wire’, because the actual communication only needs one, but you also need power and ground, so really there are three).  This has several benefits: it means that many devices can share the same wire (as each has its own address), it reduces the likelihood of inaccurate readings caused by long wires, and it means that the host does not need an analogue to digital converter to read them.  It also means that the host must implement the 3-wire protocol in order to read the sensors.  Fortunately, cleverer people than I have already done the hard work, and there are Linux drivers for these and other three-wire devices.  The relevant ones are already present in the raspbian distro, and simply need enabling.  Simply?  Did I say simply?  This is Linux – nothing is simple until you know the magic incantations.  I need Linux to load the appropriate 1-wire driver modules when it boots up, so it’s necessary to edit the /etc/modules file, which contains the list of drivers to be loaded.  It’s necessary to have root privileges to edit this file:

sudo nano /etc/modules

blog_pi.1

The lines w1-gpio and w1-therm tell the system to load the one-wire driver for the pi’s GPIO port (GPIO4 is used for this) and also the drier for the DS18B20 chip.  You can also load them manually from the command line if you wish:

modprobe wire
modprobe w1_gpio
modprobe w1_therm

Once these modules are loaded, the system will probe in the background to see if there are any sensors it recognises on the wire.  It will then create a new folder for each one under /sys/bus/w1/devices, and pop the data it retrieves from each in a file in there.  Reading the temperatures is a simple as reading the values in these files.  For example, as I write I have two sensors.on my Pi.  If I look in the devices folder, this is what I get:

blog_pi.2

The long number ‘28-0000009bba2b’ is the unique id of the sensor (hard-coded into the sensor itself).  The 1-wire driver identifies these and creates links to each.  By browsing to the folder and looking at the ‘w1_slave’ file within, the temperature is revealed.  it’s the bit saying ‘t=21250’, which is 1000 times the temperature in degrees Celsius (21.25 degrees).  If you want the temperature in Fahrenheit, I suggest you go back to the eighteenth century.  If you are actually executing the commands, you may notice a short delay between the ‘cat’ and the output.  That’s because when you read the file, the system actually contacts the sensor and takes a reading.  This is perhaps slower than you might expect, but it’s fast enough for my purposes.  For completion, here’s a quick wiring diagram of how to connect up the senor to the pi. the only other component needed is a 4k7 resistor, to tie the communication wire to the 5V line.

blog_pi.3

The next step is to use python to read these temperatures and store them in a database, then get a web-based interface up to control the relays.  I’ll also need to make sure that everything runs automatically, with no user intervention.  Watch this space.  Unless you have better things to do, which I fervently hope is the case.