Taking the temperature

We want to be able to record the temperature of the outside air for our weather station.

We can do this using a Thermistor.  This is a resistor that changes resistance relative to its temperature.  Unfortunately we are unable to measure resistance directly, we can however measure a voltage.

Consider the circuit below:

____ Vcc
|
#
#   R1
#
|
+—– Vadc
|
#
#   R2 (Thermistor)
#
|
__|__ 0V

(Action replace with png just as soon as I can fix word press config)
If R2 is our thermistor then we do not know what it’s current resistance is, but if we apply a known voltage at Vcc, and have a fixed resistor (R1) then when we measure Vadc then we have all the parameters required to work out the resistance of the thermistor (which we can then use to determine the temperature)

Ohms law tells us that R = V / I so if we know Vadc (the voltage across R2) and we know I then we can derive the value of R2.

Right now we do not know the value of I, but given that R2 is in series with R1, we know that the current through R2 will be the same as that through R1.  ok so we don’t know what the value for I in R1 is either, but we can derive that!

I = VR1 / R1

Where VR1 = Vcc – Vadc

So I = (Vcc – Vadc) / R1

which in turn enables us to derive R2:

R2 = Vadc / I

R2 = Vadc / [ (Vcc – Vadc) / I ]

 

Given a little scaling work to ensure that the ADC input voltage is within safe ranges, we can now determine the resistance of our thermistor and from that (and the data-sheet for the thermistor) derive the current temperature…

Unfortunately by this stage Alys’ eyes had glased over and she had lost all interest in determining how we might measure Temperature.

Time for a different approach…

What if we were to use a device that has done all that tedious maths for us already, and not only that has converted into Si units (in this case the offset unit degree centigrade)?  Enter the Dallas / Maxim 1-Wire DS18B20.

This is a simple three pin device that measures Temperatures from -55°C to +125°C (with ±0.5°C Accuracy from -10°C to +85°C).   Better yet there is already Arduino Library support meaning that we needed only to download the libraries and knock up a very quick and simple sketch to get the first part of our project working.

Hardware:

We are using an Arduino Uno with a breadboard cape for the development.  We simply connected the DS18B20 as shown below:

(Stolen image – replace with our own schematic ASAP)

Finally we connected a FTDI USB/TTL-Serial adapter to the Arduino (Pin 0 and Pin 1) so that we can send the temperature data to a serial console for now (minicom running on my laptop)

(Insert photo here)

Software setup

  • Arduino IDE and programming environment
    apt-get install arduino
  • Ensure user is in the dialout group for permissions to talk to /dev/ttyAM0 which is what the Arduino presents it self as (at least on our hardware)

Libraries:

Application:

Our Arduino sketch is simplicity itself

/********************************************************************/
// First we include the libraries
#include <OneWire.h> 
#include <DallasTemperature.h>
/********************************************************************/
// Data wire is plugged into pin 2 on the Arduino 
#define ONE_WIRE_BUS 2 
/********************************************************************/
// Setup a oneWire instance to communicate with any OneWire devices  
// (not just Maxim/Dallas temperature ICs) 
OneWire oneWire(ONE_WIRE_BUS); 
/********************************************************************/
// Pass our oneWire reference to Dallas Temperature. 
DallasTemperature sensors(&oneWire);
/********************************************************************/ 
void setup(void) 
{ 
 // start serial port 
 Serial.begin(9600); 
 Serial.println("Dallas Temperature IC Control Library Demo"); 
 // Start up the library 
 sensors.begin(); 
} 
void loop(void) 
{ 
 Serial.print("Requesting temperatures..."); 
 sensors.requestTemperatures(); // Send the command to get temperature readings (from all 1-wire temperature devices)
 Serial.println("DONE"); 

 Serial.print("      Temperature is: "); 
 Serial.println(sensors.getTempCByIndex(0)); // Why "byIndex"?  
   // You can have more than one DS18B20 on the same bus.  
   // 0 refers to the first IC on the wire 
   delay(1000); 
} 

 

Output:

Requesting temperatures...DONE
            Temperature is: 29.50 
Requesting temperatures...DONE
            Temperature is: 29.50

It is somewhat warm here!  We validated the sensor using a bag of iced water, and also by heating the sensor.  Everything looked good.  We should perhaps ensure calibration using known temperatures and a known thermometer – but for now this is enough…

 

Summer Project – Weather Station

This summer’s project we (Isy Simpkins, Alys George, Andy Simpkins) intend to build a weather station. The project can be split into various sections and today we decided the scope of the project.

Initially we decided what we want to measure:

  • Temperature
  • Humidity
  • Precipitation
  • Wind speed and direction
  • Light
  • Air pressure

We’ve also decided that we shall have multiple sensors connected together reporting back to a central server. Sensors will be based around the Arduino ecosystem and the central server will be either a Raspberry Pi or a Beagle Bone Black. So we can get up and running quickly we will build our sensors and server using jump-wires and breadboard initially, then when we have a working prototype, we will make printed circuit boards and enclosures. Along the way, we will need to learn how to take measurements in a form that can be controlled and interpreted by the Arduinos (simple electronics), how to program the Arduinos (sketches in ‘C’), printed circuit board design (kicad), electronic assembly and test (soldering and fault-finding), mechanical design (CAD package to be decided), mechanical production (assembly into enclosures and 3D printing certain parts such as anemometer sails, optical encoder discs and wind vain). Finally, we will cover getting data from all our sensors into our central server (CAN bus or RS485?) storing the data (database?) and presenting historic and current weather information (active website with pretty graphs and charts). Obviously this is a lot of work so we will do it in small steps.

 

When ‘Bad thing™’ happens….

As part of a wider project I have been looking at how to reuse the keyboards found on Thinkpad laptops.  The connector for these is no longer available (at least not in small quantities), however the Molex SlimStack range appears to be a compatible fit.  I was unable to find a simple breakout board for this series of connectors I decided to produce one of my own.

Now, I am used to producing very fine pitch PCBs as part of $dayjob, so I had to move away from my normal design rule set to something that can be built by the fabs used by the PCB bureaux that cater for the hobbiest (lets face it this is a simple connector breakout board – so it shouldn’t tax any fab plant; going to the hobby bureaux provides access to cheaper fabs that can easily cope with these simple boards, but may not be suitable for the stuff I run through with $dayjob, likewise those more advanced fabs I use for $dayjob would simply be too expensive for this kind of work).

My ‘goto’ guy for this is Mitch at Hackvana, having been recommended to me by a friend, Colin (G8TMV), who has also used Hackvana for several projects, his boards are a little bit smaller than the behemoth that is OpenTAC – actually quite a complex, if only 4 layer board, that Mitch produced for me (photo).

Anyway, back to this story…

I dutifully followed the design rules posted on the Hackvana website (indeed I still owe them a set of Altium Templates but that will be another post), and emailed Mitch version 1.00 CAM files.

I got a response very quickly pointing out that I hadn’t quite complied with the design rules (some of my overlay lines were too thin – turns out I didn’t care if they came out or not).  More importantly though, Mitch suggested that if I shrank my board ever so slightly that the cost would be massively reduced!

Lets just take a moment to think about this.  Here am I with a farily good expectation of the price I am going to pay, I have submitted files to be made, and my supplier has come back and said:

[That will be] USD30.  They'd be USD19 if you can get them to fit within 5x5cm.

Now $30 is a low price for 10 boards no matter how small.  $19 is a fantastic price, and it was all of a matter of a few minutes work to fit inside the smaller size constraint…

PCB Layout
PCB Layout

Great, I made the changes, sent through the updated CAM files and awaited my lovely boards…

Well yesterday came and I got a message form my wife telling me that the boards had arrived.  I got home and inspected them.

PCBs have arrived
PCBs have arrived

Something looks wrong, can you spot the problem?

Faulty board
Faulty board

 

If you haven’t spotted the problem; there is a plated, arc / partial hole, on the top left of the board (all boards) that is joining the ground plane to pins 5 and 6 of the connector.

I double checked that I hadn’t screwed up by opening the CAM files (into a different package than I created them in) then sent an email containing the above photo to Mitch at Hackvana detailing my problem (and prodded in IRC).  Within 3 minutes I got a response:

That's really not on!

Can you please send me another photo that shows the extent of the problem?
Ie, does it apply to just one board, or does it apply to some (percentage
affected?) or all?

I will get replacements made and shipped to you ASAP.

A short exchange of emails later, including the first photo showing the problem on all of the boards and me explaining that I don’t need the replacement PCBs back in any hurry (I am off to Debconf so will be unable to do anything with these boards even if they arrived tomorrow)

Now that is customer service!  OK it is unrealistic to expect a responce of 3 minutes, but a fast response, acknowledging the problem, and offering to do something about is what I expect, and all to rarely receive.

Customers have a right to expect what they order to arrive on time and defect free.  This should be the norm and so nothing of note here.  However things do, occasionally, go wrong.  In this case I suspect that the board adjacent to mine had a stray pad that for whatever reason got missed (at the prices I am paying it would be unrealistic to expect the fab plant to notice this – hoped for but not expected) and this encroached into the panel space that had been allocated to my board.

Occasionally though, things do go wrong, and ‘Bad thing™’ happens….

Just how a company reacts in these situations is what separates a good company from the bad.   Had this been one of the faceless automated PCB bureaus out there, I suspect that I would still be trying to contact customer support, with Hackvana, however I am now awaiting my replacement boards happy in the knowledge that they have seen the problem and are putting it right.

Of cause what separates a good company from a truly excellent one is that they put measures in place to stop this from happening again…  Only time will tell on that front, but for now, even though I still don’t have my boards, I’m still a happy customer.

OpenTAC sprint, Cambridge

Last weekend saw a small group get togeather in Cambridge to hack on the OpenTAC.  OpenTAC is an OpenHardware OpenSoftware test platform, designed specificly to aid automated testing and continious intergration.

Aimed at small / mobile / embedded targets OpenTAC v1 provides all of the  support infrastructure to drive up to 8 DUTs (Device Under Test) to your test or CI system.
Each of the 8 EUT ports provides:

  • A serial port (either RS232 levels on an DB9 socket, or 3V3 TTL on a molex kk plug)
  • USB Power (up-to 2A with a software defined fuse, and alarm limits)
  • USB data interconnect
  • Ethernet

All ports on the EUT interface are relay issolated, this means that cables to your EUT can be ‘unplugged’ under software control (we are aware of several SoC development boards that latch up if there is a serial port connected before power is applied).

Additionly there are 8 GPIO lines that can be used as switch controls to any EUT (perhaps to put a specific EUT into a programming mode, reboot it or even start it)

 

Anyway, back to the hacking weekend. ..

 

Joining Steve McIntyre and myself were Mark Brown, and Michael Grzeschik  (sorry Michael, I couldn’t find a homepage).  Mark traveled down from Scotland whilst Michael flew in from Germany for the weekend.  Gents we greatly apprecate you taking the time and expence to join us this weekend.  I should also thank my employer Toby Churchill Ltd. for allowing us to use the office to host the event.

A lot of work got done, and I beleive we have now fully tested and debugged the hardware.  We have also made great progress with the device tree and dvice drivers for the platform.  Mark got the EUT power system working as proof of concept, and has taken an OpenTAC board back with him to turn this into suitable drivers and hopfully push them up stream.  Meanwhile Michael spent his time working on the system portion of the device tree; OpenTAC’s internal power sequancing, thermal managment subsystem, and USB hub control.  Steve  got to grips with the USB serial converters (including how to read and program their internal non-volatile settings).  Finally I was able to explain hardware sequancing to everyone, and to modify boards to overcome some of my design mistakes (the biggest was by far the missing sence resistors for the EUT power managment)