This post discusses the evaluation of a thermistor-based technique for small embedded systems capable of achieving uncalibrated temperature accuracy to rival expensive digital sensors.  An experimental comparison of various sensors over temperature is then introduced.

There are a few challenges in using a thermistor well.  Firstly, care must be taken to measure its resistance accurately, and secondly some characteristics of the thermistor need to be obtained, either from the datasheet or experimentally, and applied to a model in order to derive the actual temperature.  The formula that is usually used for this calculation is the Steinhart-Hart equation, which is not well suited for calculation on an 8-bit micro.

To solve the first problem the thermistor is used in a potential divider configuration as one might expect, but with the ADC configured to use the supply rail as its reference.  This makes the ADC count dependent only on the relative resistances in the divider, and eliminates any dependency on the accuracy of the ADC’s voltage reference.  Since the value of the fixed resistor remains important a 10k 0.1% tolerance part was used here. Even such tight tolerance resistors still only cost pence, so the cost advantage of the thermistor is not lost.  The divider is powered from a GPIO to eliminate current sinking through it while the sensor is asleep.

The second part of the problem helps drive thermistor selection, because choosing a part with reliable manufacturer-supplied Steinhart-Hart coefficients eliminates the need for calibration.  A Vishay NTCS0603E3103FMT was chosen and a spreadsheet devised which calculates the thermistor resistance (Rt) and the ratio Rt/R25 value for every 16 ADC counts across the full 10-bit range.  Maximum, nominal and minimum values are calculated in each case, based on quoted component tolerances.  For each row the maximum, nominal and minimum temperature is then calculated using Steinhart-Hart with the coefficients provided by the manufacturer.  Alternative thermistors can be evaluated by entering the R25 value and Steinhart-Hart coefficients on the “Graphs” sheet.

The predicted temperature spread due to component tolerance is plotted on the “Graphs” sheet and can be seen below for the Vishay thermistor and a 0.1% 10k reference.  At room temperature an error of +/- 0.3°C is predicted, which is well within the desired range.

To enable the microcontroller to measure temperature directly, the spreadsheet was used to derive a 64-slot lookup table mapping ADC values directly to nominal temperature.  Linear interpolation is used at runtime to calculate intermediate values, but all remaining maths, including the resistance calculation, is mopped up in the lookup table .  When generating the table the output values can be pre-scaled according to the requirements of the application.  Here, a 16-bit fixed-point representation with 8 fractional bits was used, but it would be equally straightforward to calculate the table for direct output of 100ths of °C, or any other scale factor.  The following code fragment demonstrates the resulting steps required to convert an ADC value to temperature on the microcontroller (lookup table truncated for clarity):

/* Lookup table for thermistor ADC values / 16 (64 points for full scale).
 * The result is °C with 8 fractional bits. Values include the
 * resistance calculation for a divider with a 10 k reference, and are
 * calculated using the full Steinhart-Hart formula with constants
 * given on the thermistor datasheet.
 */
static int16_t thermistor_table[] = {
  32767, /* saturate */
  32767, /* saturate */
  32767, /* saturate */
  31350,
  28197,

  ...
  -11247,
  -14041,
};

#define STEP 16

/*! Convert thermistor ADC value to temperature by interpolating
 * the above lookup table */
static int16_t adc_to_temp(uint16_t val)
{
  uint16_t idx = val / STEP; /* FIXME: Limits */
  uint16_t offset = val - idx * STEP;
  int16_t y0 = thermistor_table[idx];
  int16_t y1 = thermistor_table[idx + 1];
  return y0 + (y1 - y0) * (int16_t)offset / STEP;
}

All of the above is of course purely theoretical, so a sensor board was modified to place the thermistor directly adjacent to the TMP112, and an additional TMP102 sensor was added as shown in the photograph at the top of this article.  The firmware was altered to transmit temperature measurements from each of the three sensors at 10 second intervals, then these values were logged while the board was temperature cycled in the oven and the freezer.

The measured values can be seen in this second spreadsheet.  For each data point the mean temperature is calculated as well as the difference from mean for each sensor, which is used as a figure of merit.  The following graphs show the average temperature over the duration of the test, and the corresponding variation from the mean for each of the three sensors:

It can be seen that the offset from mean is fairly constant for a given sensor, with the total spread being under 1 degree at steady-state.  Interestingly the TMP112 was almost as far from the mean value as the thermistor, but still within its +/- 0.5°C specification.  The large swing seen during periods of high rate-of-change is thought to be due to the difference in response time between the thermistor and the diode sensors used in the TMP1x2s.  For the thermistor, the average difference from mean measured temperature is about 0.4°C; slightly worse than the predicted value.  This is not unexpected since the prediction takes into account only the spread of component values, and not errors in the Steinhart-Hart coefficients, details of which were not available.

The table below summarises the vital statistics for the sensors used in the experiment, with the DS18B20 included for reference. Pricing was obtained from Farnell UK on 28/4/13 and is ex-VAT.

The results indicate that, using the described lookup table method, a low-cost, uncalibrated thermistor can yield an absolute accuracy similar to that of the much more expensive digital sensors.  At the same time, there are no supply voltage restrictions beyond those of the microcontroller, and by using a GPIO to power the divider standby current consumption is limited to leakage and should be negligible.

There is a degree of uncertainty at the moment regarding the future availability of HopeRF’s RFM22B and RFM23B modules.  Having been in touch with a number of HopeRF’s European distributors the message appears to be that while they are indeed “not recommended for new designs”, there has been no end-of-life notification for either of these products.  Both modules will continue to be available for the foreseeable future, although they may be subject to minimum order quantities once distributor stocks run dry.

Recommended replacements are the RFM69W and RFM69HW.  These new modules appear to be based on Semtech SX1231H, which means they are not an ideal equivalent because of a 2.4 V minimum Vcc (the RFM23B can work down to 1.8 V).  Fingers crossed that HopeRF has actually used the 1.8 V capable non-H version of the chip on the lower power RFM69W.

Several EU distributors have indicated that they will be carrying the new modules within a month or so.  Pricing looks like it will be slightly cheaper than that of the older modules, so that plus the addition of hardware AES should make these a welcome upgrade.

PCB antenna with test port attached

I finally found the time to make some measurements on the printed antenna used on my sensor board, which I didn’t think was performing very well.  Turns out I was right.

For this first part of the test various antenna configurations were tested by mounting them on unpopulated sensor boards connected to an Anritsu Sitemaster RF fault analyser via some added SMA connectors.  This instrument is capable of making return loss measurements, which were taken over a range of 800 MHz to 1 GHz.

Return loss is a measure of the proportion of power reflected back into the transmitter (or back out of the antenna) due to a mismatch.  It is given in decibels as incident minus reflected dB, and is related to VSWR.  A high positive return loss value indicates a good match.

Measurements were made on the following antennas:

• A reference dipole tuned for resonance while mounted on the instrument
• The printed antenna cut to the recommended length for 868 MHz as given in the TI application note
• Wire monopoles of length 85 mm, 86 mm and 87 mm

For the purpose of these tests a target VSWR of 1.5:1 was selected as an acceptable match, and corresponds with 96% of the incident power doing useful work.  The corresponding 14 dB return loss figure is marked in red on the graphs.  Note that the instrument shows the return loss as a negative value, but the magnitude may be read directly.  Marked in blue are the ISM band edges at 863 MHz and 870 MHz, and also the common 868.35 MHz spot frequency.

Each antenna was tested with and without a battery pack attached to the board.  This is important because the PCB ground plane capacitively couples to the battery quite effectively and the performance of the antenna is drastically altered in most cases.  The battery consisted of a pair of (old) AA cells in a common side-by-side holder and was attached with double-sided tape.

Reference dipole under test

Reference Dipole

First up was a reference dipole made by attaching short lengths of wire directly to an SMA connector.  The overall length was initially set to half a wavelength at 868 MHz (173 mm).  During the test the antenna was aligned perpendicular to the plane of the analyser to minimise coupling.  As expected, it was necessary to reduce the length of the antenna slightly to achieve resonance at the desired frequency.  The overall length of the tuned antenna ended up being 160 mm, which is reasonably consistent with the theory, which results in a half-wave dipole being slightly shorter than a half wavelength.

The antenna exhibits a sharp resonance at the tuned frequency and has enough bandwidth to provide an excellent match across the entire 863 MHz to 870 MHz band.

Measured return loss for the reference dipole

PCB Antenna

The original PCB antenna was taken from the design in this (PDF) application note.  The dimensions of the rest of the board are fairly similar, but likely too small to provide an adequate counterpoise.  Without the battery there is a poor but measurable match in the band of interest.  The actual resonance appears slightly high meaning the antenna needs lengthening slightly.  The other dip seen below the 868 MHz band is present in most measurements and appears to be related to some other feature of the board, as its frequency remains fairly constant.

Measured return loss for the PCB antenna with no battery attached

With the battery attached, a more realistic scenario, the antenna presents a pretty bad match (VSWR about 3:1 or worse):

PCB antenna return loss measured with battery attached

Wire Monopole

Sensor board modified for a quarter-wave wire

A second unpopulated sensor board was modified with an SMA test port added and the printed antenna removed.  Simple quarter-wave wires were connected to the test port, using the sensor PCB as counterpoise.  Measurements were again taken with and without the battery affixed to the PCB.

The expected quarter wavelength at 868 MHz is 86.5 mm, so wires with lengths 85 mm, 86 mm and 87 mm were tested.  The measured results were similar for each with the optimum length for the band of interest being 87 mm.  Note that the absence of the battery caused the resonant frequency to increase significantly as shown in the following plot.  Although it might be tempting to compensate for this by lengthening the wire, it is likely that the resulting antenna would be easily detuned.

Return loss measured with an 87 mm long wire and no battery

By attaching the battery the antenna behaves much closer to the theory, which is encouraging:

Return loss for an 87 mm wire with battery attached to PCB

And by bending the antenna down so that it is in the plane of the board the tuning is retained within the ISM band but with further improvement to the matching.

Return loss for an 87 mm wire in the plane of the PCB, with battery attached to PCB

Again, note the sharp match at the frequency below the band of interest, which is presumably due to the same feature that caused the double-dip seen for the PCB antenna.  Its frequency is not altered significantly by changing the length of the wire as shown in the final plot, for an 85 mm long wire.  This measurement offers an indication of how accurately the antenna needs to be cut for best match.

Return loss for an 85 mm wire with battery attached to PCB

Conclusion

The results suggest that a simple quarter wave wire can yield an excellent match even on a small board such as this, but that enlarging the ground plane is beneficial, even if this is only done parasitically such as by mounting in close proximity to the battery.

Once the rain and snow stops I am going to go out to the Open Air Test Site garden to do some actual radiated performance tests which will be reported in due course, but I expect the results to back this up.

If this does turn out to be the case then I will be dropping the printed antenna in favour of 87 mm of wire for a second revision of the sensor!

As part of my interest in IoT and Home Automation I spent some time looking for a non-destructive alternative to rrdtool for long-term storage and aggregation of sensor data.  The search did turn up a few alternatives, particularly OpenTSDB, but I was not especially impressed with its performance nor its complexity.  During the search I came across Flot, which is a JavaScript library for plotting graphs client-side in a browser, and the idea for a “Web2.0″ time-series database was hatched.

Timestore, which is the result, is written in C and accessed via an HTTP API that can feed data series directly to Javascript via AJAX calls.  It is designed to be lightweight, fast, and to retain all data.  Like most equivalent tools it can decimate on inserts, so queries for aggregate data take constant time regardless of the time-scales involved.

The design has optimisations for sensor applications, where a single device may report multiple data items at each time point.  These can be submitted in one go, but queried as separate series for display.  The modular architecture will enable alternative access methods to be added; MQTT being an obvious one which I intend to look into for data submission.

Code and documentation can be found on the project’s dedicated page.  There are some hosted examples to play with, including the graph embedded above, which is real temperature data and can be zoomed by dragging a box around a range.  Double-click to zoom back out.  The software is released under GNU AGPLv3.

The FHT protocol is similar to FS20, but the receivers are battery powered and so use a timeslot technique to avoid the need for a permanently powered receiver.  This necessitates a synchronisation procedure between the controller and its valve.  Once completed, the controller will send a packet approximately every two minutes, keeping the valve in sync.  This means that it can take up to two minutes for a change to take effect, but it does mean that the receiver remains un-powered for most of the time.

This example implements the protocol using the module’s FIFO mode, requiring minimal intervention from the host MCU.  Source is available for ATMEGA328, so it should work on an Arduino, although I have not tested it yet.

The protocol is modulated using on-off-keying (OOK) with a zero represented as 400 us on then 400 us off, and a one as 600 us on, then same off.  To generate this using the RFM2x a bitrate of 5000 bps was chosen.  This gives a bit period of 200 us, which is the lowest common denominator for the required timings.  A pre-processed bitstream can then be produced which results in the correct modulation for the message being sent.

The code also includes a proof-of-concept receiver, again using FIFO mode.  To support this some additional preamble is sent outside of the normal FHT encoding.  This does not affect the ability of a genuine FHT device to receive the packet, but makes it much easier for an RFM2x based receiver to participate in the network.  At present the receiver implementation cannot receive packets from a real FHT transmitter, but there are a couple of approaches that I have in mind which could solve this limitation.

The firmware, for AVR ATMEGA328, has been tested on one of my sensor boards, but should run on an Arduino with minimal changes.  The radio module is connected to the SPI bus, and a serial converter is required on the UART pins to access the embedded command line interface.  Connection details can be found in board.h and comms parameters for the UART are 19200,8,n,1.

Before any command can be sent the sync process must first be completed.  This defines the target house code.  The command “fht sync <hc1> <hc2>” can be used to achieve this, where the house codes are given in decimal.  This takes two minutes to complete.  Afterwards, issue “fht set <setting 0-255>” to adjust the valve position.  The receiver can only be invoked independently using the command “fhtrx”, so two devices running this code would be required to try this out.

The industry is apparently thinking along the same lines, because the vast majority of DIY Home Automation (HA) stuff on the market in the UK at least is using proprietary sub-GHz like LightwaveRF.  The driver here is probably cost, but it is my view that the lack of interoperability that this leads to is holding back the mass-market acceptance of HA, and is unnecessary.

What I am looking for is a simple, open (as in freely available, properly documented, royalty free) standard for sub-GHz RF that could be implemented on the cheapest of radios in minimal code space.  I am aware of MQTT-S, although even that looks too complicated for simple sensor/actuator applications, and it doesn’t define the lower layers, instead running on top of something like ZigBee or 6LoWPAN.

Some outline requirements:

• Both master/slave and peer-to-peer networks should be supported.  Meshing need not be ruled out, but is not a key design aim.
• Security should be a primary design criterion – most proprietary protocols seem to be wide open.
• The use of IP on the air interface should not be considered – bridging to IP networks is a job for  a central controller/bridge rather than pushing this complexity (read cost) out to every single node.
• Battery powered nodes must be supported, e.g. discontinuous receive/timeslot techniques.
• Unidirectional nodes must be supported for extreme cost-sensitive applications.
• Obscure modulation schemes must be avoided to maximise the range of available radios.

An initial implementation would aim to support SiLabs EzRadio and EzRadioPro, which covers HopeRF RFM12/22/23 modules which are all in common use.

I am keen to hear from anyone with an interest in this area, particularly if there is something filling this need that I have missed.  I am also particularly interested in others’ views on the complexity of existing solutions – perhaps I am being over-sensitive!

The design I have gone for combines temperature and light sensing with a pulse input for connection to the gas and electricity meters.  The microcontroller is an ATMEGA328 and the radio is a Hope RF RFM23B, which is based on a SiLabs Si4431.  This is a synthesised transceiver so the potential for congestion can be avoided through the use of listen-before-talk and frequency hopping, the latter also offering a way around the duty cycle restrictions in the 868 MHz band.

The printed antenna needs to be tuned by trimming it to length, which will no doubt be the subject of a future post.  Once the optimal dimensions have been determined this can be applied to any future spin of the boards in advance.  No prizes for spotting the deliberate mistake with the microstrip track passing under the RF module – I am hopeful it won’t have too great an effect!

The boards in the photograph just came back from iTeadStudio in about a fortnight.  The quality is absolutely excellent considering the <£10 price tag for the 10 circuits.  I have loaded a couple and firmware development is in progress.

The Conrad FHT8V wireless thermostatic radiator valves (TRVs) are available for around £30, which is the sort of price I’m prepared to pay to get this project up and running.  I would ideally like to talk directly to these valves from my own controller, so I bought one of the £60 starter kits which includes the remote thermostat and took a look at the on-air protocol using Gnuradio.

To receive the signal a cheap RTL SDR dongle was used.  This has the Elonics E4000 tuner, which has almost continuous coverage from about 65 MHz to nearly 2 GHz.  The TRVs operate in an ISM band on 868.35 MHz.  Helpfully, the protocol has already been reverse engineered, making building a receiver a simple task.  The modulation is on-off keying with the symbols encoded as mark and space times of two different lengths, so a custom block was needed in order to decode and frame the messages.  This was written in C++ and integrated with the rest of the receiver in Python.

The code can be found here, and should serve as a simple introduction into writing custom Gnuradio blocks.

The flow graph is coded in Python without using Gnuradio Companion because I felt it was easier to get the separate decoding thread working in this way, and is simply:

Source -> 50 kHz channel filter -> Demod (Magnitude squared) -> Decimate -> Custom Decoder

Modtool was then used to generate the boilerplate code for the custom block:

$ gr_modtool.py create fs20
$ cd gr-fs20
$ gr_modtool.py add framer_sink -t sink
Operating in directory .
GNU Radio module name identified: fs20
Code is of type: sink
Block/code identifier: framer_sink
Full block/code identifier is: fs20_framer_sink
Enter valid argument list, including default arguments: 
Add Python QA code? [Y/n] n                                                                                           
Add C++ QA code? [Y/n] n

The decoder block performs symbol decoding, rejecting pulses of unacceptable length, passing the resulting binary values to a state machine for packet synchronisation and parity checking.  Once enough bits have been received the packet is pushed onto a queue for asynchronous processing from Python.

To build, ensuring Gnuradio is in your path and that you have CMake:

$ cd gr-fs20
$ mkdir build && cd build
$ cmake ..
$ make
# make install

The decoder can then be run in-situ with:

$ ./fs20rx.py

The asynchronous part of the decoder runs in a separate thread within the Python script.  Packets are popped off the message queue as they arrive and are checksummed using the FHT algorithm, which is subtly different to the FS20 one.  If the packet is valid then the length of the message is inspected to determine whether it came from the thermostat or a window sensor.  Messages are then pretty-printed on stdout as they are received (which is about every 2 minutes).

Output of the Gnuradio FS20/FHT decoder

•  Download the Python and C++ source code

Emulating bus contention and improving the cycle accuracy of the T80 core is definitely on the cards, but for now the ability to finally load emulator images from SD makes the machine extremely usable.  An explanation of how to get this up and running is a job for another post (hint: format the card as IDEDOS and bootstrap ResiDOS into the extra RAM), but for the time being here is a detailed write-up and the full VHDL source.

And let’s not forgot the obligatory eye candy…

Planning to revisit the Spectrum design next for some bug fixes, as it is clear there is still quite a bit of interest in that.