There’s no shortage of good Software Defined Radio (SDR) apps for RTL2382-based dongles, but wouldn’t it be nice if they could be driven remotely? WebRadio is a project I have been working on which aims to be a fully functional SDR with a user interface that runs in a browser.
The front-end is separated cleanly from the signal processing server by a (fairly) RESTful JSON API, so alternative GUIs are also an option (smartphone apps being the obvious one).
A key feature of the design is server-side decoding of data modes. Since the original impetus for WebRadio was my involvement with a local school’s high altitude balloon project, initial focus will be on making it decode RTTY, but the modular design makes it easy to add other decoders.
Currently the project builds and runs on a Linux PC, but with only basic functionality (tuning for a single receiver and selection of AM and FM). Channel filtering also needs some improvement, after which SSB will work as well – this is next on the list. The GUI is known to work properly in Chrome; for other browsers, for now, YMMV. Take a look.
The TI MSP430 Launchpad is a cheap MSP430 development board – about £3 when they first came out, although a bit more now. I think mine was a freebie from a distie. Although I quite like the MSP430 I do tend to use either AVR or some kind of ARM for most of my projects, so it hasn’t really seen much use.
The built-in emulator consists of a TUSB3410 and an MSP430F1612, pre-programmed with TI’s own MSP430 “FET” debugger. My aim here is to end up with a debugger that I can use with TI’s CC1110 chips used in the Ciseco SRF. The GoodFET project can talk to these using its Chipcon module, and this has at some point in the past been made to run on the Launchpad.
For many microcontroller projects requiring accurate temperature sensing the sensor of choice is the Maxim DS18B20. Although this has a specified absolute accuracy of +/- 0.5°C, it has several drawbacks, not least of which is its relatively high cost. For my prototype sensors I incorporated a TI TMP112, which is an I2C device with a minimum operating voltage of 1.4 V, making it particularly attractive for battery powered applications. My preferred option for cost-reduction, however, has always been to use a cheap thermistor with the microcontroller’s built-in analogue to digital converter (ADC).
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 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
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 github 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.
Over the last few weeks I have been helping out the guys over at OpenTRV with an implementation of the FHT protocol for use with HopeRF RFM22B and RFM23B modules. My as-yet unreleased sensor modules (as seen in another post) make use of an RFM23B, and I have an interest in evaluating the Conrad/ELV FHT8V valve head as part of my own central heating upgrades, so this was a job that I needed to do anyway.
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.
I’m going to start by admitting that this isn’t going to be a tirade of abuse against the oddly named 802.15.4-based wireless tech, but rather a request for comments on an open, lightweight alternative, particularly for low-cost sub-GHz applications. I know what the point of ZigBee is, and the ability to form into self-organising mesh networks is an obvious advantage for large scale industrial automation, but for domestic applications it feels like overkill.
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.
As part of my project to bring our central heating into the 21st century I have been working on a custom wireless sensor platform. My key aim here is to develop a low-cost, open solution with security designed in from the start; something that a lot of sub-GHz protocols seem to totally omit. I’m avoiding ZigBee because, as much as I want to like it, I keep coming back to the issue that its complexity just pushes up the system cost. In a domestic environment a simple sub-GHz solution can easily cover a typical property without resorting to meshing.
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.
I have an ongoing project to improve the performance and automation of the heating system in our house, given the ever-rising cost of energy. As part of this project I am planning to zone the central heating system to allow the temperature of each room to be controlled independently, and to do this I need a way of remotely controlling the radiators. Because of the level of integration I am looking for I’ve been unable to find an off-the-shelf solution that meets my needs at a price that is acceptable. Time to start hacking!
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.