November 2012 – Richard Mudhar

Bad by design SMJ RFC2SC remote controlled mains sockets – fix

Maplin flog these SMJ remote controlled mains sockets.

SMJ Electrical remote and socket

The first thing you need to know about remote controlled mains sockets is make sure you get one which has separate on/off buttons. These things are ratty by nature, and some are a toggle – press the button to switch on, press again to switch off. That’s fine in a light switch, where you get to see if the light is on or off, but dire in a remote switch. The whole point of a remote controlled switch is you can’t necessatily see the remote item. A toggle is worse that useless in that case 😉 That’s why this is my second purchase of this sort of thing, these are made by SMJ electrical. I was using this to switch on the coffee machine in the kitchen in the morning. As the expensice 12V battery ran down the reliability of this got worse and worse.

I measured the battery and it was down to 10V. Putting the remote on a bench power supply showed it drew 5mA on transmit, and getting a scanner onto the job showed the frequency was 433.855 MHz.

This was a little bit off the advertised frequency of 433.92 MHz on the SMJ RFC2SC label, but a 65kHz discrepancy isn’t too bad. This falls within the 433.050-434.790 MHz ISM band

SMJ RFC2SC label says 433.92 MHz

So the first thing is to pop the lid of the remote and see what gives

Internal view showing PCB

The RF sub-board is a separate assembly, presumably to deal with various different regions’ RF allocations. It’s a pretty nasty piece of work compared to the rest of the remote, hand-soldered by the looks of it.

SMJ Electrical remote RF board showing really shoddy workmanship

Of note was that the hot side of the antenna is at the top. I had allocated button 1 to the coffee machine socket, and to press this you tend to put your hand round the top of the remote. I determined that this detuned the signal – it was easy enough to hear on the scanner that putting a hand round the back to press button 1 shifted the tone of the signal, and this was confirmed with a scope that the waveform was distorted. So a good tip for using these is to use the 4 buttons rather than the 1 buttons!

The next step was to test the range with the socket, which was poor initially. It wasn’t particularly sensitive to supply voltage, but it wasn’t particularly sensitive full stop. The claimed range of 50m was ridiculous, I fitted a lamp to the socket and moved to the room next door, and communication was lost. I adjusted the trimmer capacitor of the remote (on the other side of the board) and range improved dramatically.

This now measured 433.845 MHz, which is still acceptably in the ISM band. It’s now 75kHz off. In an ideal world I’d have moved both the socket and the remote closer to the original frequency, but this will do and it’s still in band. It’s still on the original battery – the transmitter frequency isn’t particularly sensitive to voltage down to about 8V, but it was so marginal originally that the lower power must have pushed it over the edge. And I get coffee in the morning 😉

How to use the OpenKontrolGateway for Data Logging

The obvious place to look is this post, OpenKontrol Gateway as Data Logger from openmicros.org, which has some sample code, which didn’t work for me. It created the log file but didn’t write any data to it.

I hacked this to make it write the data

unixtime,day/month/year hour:minutes:seconds, LLAPmessage
1352219944,6/11/2012,16:39:4,ECTMPA7.866
1352219992,6/11/2012,16:39:52,EATMPA21.59
1352220052,6/11/2012,16:40:52,EBTMPA20.82

It’s also a bit more tricky to use, compared to a regular data logger. This is because the RF network is unsynchronised – the temperature nodes fire themselves up every 5 minutes, transmit a temperature reading and then go to sleep. This isn’t a polled system, and there may be other transactions on the network. The data logger simply logs all of these transactions, be they temperature readings, status readings or setting up devices – anything starting with an a is logged.

This is why I added the unix timestamp, so that it would be possible to plot these unsynchronised elements onto the same xy plot, with the timestamp along the x axis. Some data might want to be sampled more frequently than every 5 minutes, and some might be reactive, like a PIR sensor.

The receiving application has to pull all this stuff apart, first splitting the streams into the devices, using LEFT(LLAPmessage,3). This will always be aXY with XY being the deviceID

Modified program shown below

Continue reading “How to use the OpenKontrolGateway for Data Logging”

Setting the Real Time clock Arduino based OpenKontrolGateway

The OpenKontrolGateway a board like an Arduino Uno, but with a SD card interface, three RF board interfaces, an Ethernet board module slot and a DS1307 Real Time Clock with battery backup. It’s a nice collection of all the stuff you need to make a datalogger. If you want to retrofit a DS1307 RTC to an Arduino project Seedstudio’s Grove RTC board features the SMD version of of the chip and saves you the tiresome surface mount wrangling.

The OKG bundle at £25 gives you everything needed to box it up but I added the RTC kit and SRAM which added £12 to the cost, since a data logger without an RTC is always going to be a pain, where you have to connect up a PC to set it. That’s OK at home but no fun at the farm.

The RTC gave me a hard time right off the bat. There are a few gotchas.

You have to set the damn thing,
you need to do that to even see it started, since it can need initialisation from the SPI bus before the oscillator will start
You need a 2032 coin cell present for it to be able to work too, so no testing that without and thinking you’ll fit that later 😉

So if you ‘scope the crystal and think ‘ah, that’s why it isn’t working’ then not so fast, you may need to initialise and set it before you see any action there. I found all of this out the hard way. This is what I used to set it, which I largely pinched from LadyAda’s tutorial. One of the nice things about that is it lets you set the clock to the time the sketch was compiled, which save a whole load of faff. What you must not do then is to press reset, or switch off and on again, else it will do that all over again, setting the RTC back to the time it was compiled. You must comment out the line

    // RTC.adjust(DateTime(__DATE__, __TIME__));

and re-upload it. This listing has that line commented out, so you must uncomment it to set the clock, then recomment it.

Continue reading “Setting the Real Time clock Arduino based OpenKontrolGateway”

Project Overview – what I’m trying to do with the sensors

I have two applications for sensor networks. One is at home, where I’ve focused on temperature monitoring. I am trying to reduce gas costs by using a 6kW wood burner in the living room to heat the house, and it’s interesting to see how the heat propagates to the various rooms. Insulation is good and I achived this last year. It’s a fairly standard application of the IoT idea, so probably not of much wider interest.

The second is for gathering data over a 12 acre smallholding, the Oak Tree Low Carbon Farm. This is more challenegin as it is an island site without mains power or data communications. Remote sensing has a lot to offer a smallholding – temperature and light logging are interesting. Monitoring the state of the various 12V batteries used on site could make life easier, and control applications for managing the irrigation pumps may be feasible.

Initially I am using a Ciseco OpenKontrol Gateway to log the data. I’m not particularly using it as a gateway, more a generic Arduino kit connected to the sensors that happens to have a SD card interface and RTC on it. Eventually that could be used as its name indicates, to groom more significant status changes and alarm via SMS if necessary, for instance low battery or low water for the chickens.

At the moment I am using it as a straight datalogger for temperatures at home, to gain familiarity with the sensor and Arduino stuff. I will probably move to an EVE device for that, and move the OKG to the farm.

The first thing to do is get the OKG datalogging working right for a sensor network, in particular writing the data in a format that is usable for me. When I loaded the original version of the datalogger it didn’t work as I’d expected, specifically it didn’t log data. Some hacking was required.

How to change a LLAP device ID using Teraterm script

Note: after doing this I found you should be able to change the Device ID directly via the serial connection to the device using the AT command ATMY, so I guess that would be ATMYEB here.

You have to send an ack from the control node (usually your PC) within 1/10s of the a–STARTED– message showing up to config a LLAP node. That’s way too fast for me to type. I used Teraterm (the BSD licensed V4.75), which is a SSH and serial terminal program. It also supports scripting, and I used a previous version years and years ago in the old Win95 days.

Here’s a teraterm script to switch ORIGID to DEVID. Start Teraterm connected to your FTDI USB port

Start Teraterm in serial mode on your FTDI cable USB port

Power up a XRF on an XBBO board and connect to it via serial. Once it’s running and in range, ie you see the

a--STARTED--

message repeated five times when you power up your remote device, power off the device you want to configure. Start the macro,

Here’s the macro

; start of macro
DEVID="EB"
ORIGID="--"
dispstr #$1B"[2J"
wait "a"ORIGID"STARTED"
dispstr 10 13 "a"ORIGID"ACK------"
send "a"ORIGID"ACK------"
pause 2
dispstr  10 13 "a"ORIGID"CHDEVID"DEVID
send "a"ORIGID"CHDEVID"DEVID
wait "a"ORIGID"CHDEVID"DEVID
dispstr  10 13 "a"ORIGID"REBOOT---"
send "a"ORIGID"REBOOT---"
wait "a"DEVID"STARTED--"
dispstr  10 13 "a"DEVID"STARTED--"
; end of macro

Your device should be set to the new DEVID

Remote sensing and the Internet of Things

Wires. That’s the problem with remote sensing, at least it has been until recently. You needed wire to get the signal back to where you wanted to view it, and often to power your sensor too. That’s a grand PITA. The last time I looked at this, about a decade ago, you could get little RF modules running at around 433MHz but these presented the raw demodulated FM signal. Great for voice but you then needed a modem to wrap around the project. And some sort of protocol stack, possibly.

That exchanged the signal wiring problem for a sensor powering issue, and these radio modules were send or receive so everything would end up fire and forget.

I was chuffed to find there’s been a lot of movement in this field. A lot of it seems Arduino based and I selected PICs when getting into micros, so it is a new learning curve. In researching this I came across JeeLabs and Ciseco. The latter had some £12 bidirectional RF to serial cards, the XRF, which I expected to attach a PIC. However, they seeme ot also have used the microcontroller on the RF board to do some signal conditioning for a few sensors, including temperature via the Dallas 18B20 or a thermistor. Since temperature and battery voltage/contact status are some of the things I want to remote sense that saves me a load of programming grunt-work.

They have also documented a simple serial sensor protocol, LLAP, which fitted my needs. The Internet of Things is all very well but if you need a TCP/IP stack for each battery powered node you need a lot of processing power and electrical power, which is back to wiring again.

So I ordered four XRF boards, a couple of thermistor boards and a XBBO carrier board to interface to an FTDI cable to USB. Assembling the thermistor boards and the XBBO were easy enough, now it was time to test it all out and getting some readings. To do that you have to set your LLAP sensor device to some particular address. and this is where is started getting hard. You have to program them over the air, and you have 100ms to respond to the started command.

That’s great for security, but I don’t type that fast 🙂 Which is why I use this script to do that job.