I’m a fan of Ciseco’s OpenKontrol Gateway. It doesn’t get anywhere near enough love on their site compared to the flighty Eve. Where it scores is that it’s a cheap way of making stuff happen and I like that.
It makes a dandy data logger, basically get the RTC kit and the SD card socket, slam one of their XRF radios in the left hand socket plus a LLAP thermistor device within 50 yards and you’re all set 🙂 You can add more thermistor devices while the datalogger is running and they get logged too without bumping it. And all for less than about £80 total system cost, what’s not to like? Okay in an ideal world the power consumption could come down a little bit as the OKG is in receive only mode, but it’s livable with – using 8 NiMH AAs gave me a couple of days runtime.
This saved our tail with finding out what the soil temperature was like in and outside a polytunnel earlier this year
What you can also see in the OKG picture is a Wiznet 5200 Ethernet card. What I didn’t realise is that this damn thing has a microcontroller inside. And it’s reset at the same time as the Arduino, so you get some sort of evil who-dares-wins race to get out of the starting blocks when that reset line goes High. The horse you want to win is the Arduino, so as the Wiznet’s ready to get initialised by the Arduino, but it doesn’t seem to happen that way.
Looks like with some configs the wiznet wins the race, and presumably gets confused when it sees data and stuff. I never got it to work reliably with the SD card datalogging. I the got another OKG, this time without the SD card and RTC option, just for posting LLAP devices from the XRF to Cosm. And this damn thing was about 50% reliable, it gave me a world of hurt until I discovered this natty fix for this sucker over at Open EnergyMonitor. I am so grateful to them. Basically you dis the reset on the Wiznet and ground the sonofabitch once the Arduino powers up, so you know where it starts from rather than whatever it got to see on the data lines as everything Arduino and SD card and XRF and what have you fired up. Sounds good to me, and it works. I had considered chucking a monostable at this to ground the line for a sec so the Arduino can sort itself out, but caught the Wiznet getting its knickers in a twist after a while having started okay. So the option to deck it if it returns more than five -ve values for etherclient post is necessary. I went off pin 3 of the RH socket which is arduino pin 6 ISTR, but I need to see if there is a genuinely spare pin because one day I might want to use the OKG as an RF to RF gateway which would mean getting both slots into service. I’m open to pinching the red status LED if necessary 😉
The Wiznet seems actually reliable now, and if it does get itself stuffed in an IoT application returning a negative value for a post five times in a row I simply reset it and reinit the device. It’s not the end of the world if five temperature readings get lost, as long as recovery is possible 😉
I have used two Dallas DS18B20 sensors to log the soil temperature inside and outside a polytunnel, as well as a free-standing RF thermistor probe for the air temperature.
reading of soil and air temp inside and outside polytunnel
The air temperature reading clearly has issues in the day, but the soil temperature readings show the value of a polytunnel. The blue trace, inside, shows the soil temperature to always remain above 5C, which is apparently important for seed germination. The temperature excursions to be smaller, ranging over about 8C rather than 12 for the outside soil temperature, and the outdie soil temperature falls to 0 at one point.
The air temperature suffers in the day from the problem of the greenhouse effect, which is of course the whole point of a polytunnel, but the sensor additionally suffers from not being in thermal balance in the day.
Measuring temperature in a room is easy, and the one-box LLAP sensors do that fine. However, setting them up where the sun shines on them means the sensor gets heated by the sun and no longer accurately reflects the ambient air temperature, because the black case is heated up faster than it radiates / convects heat away, so it’s no longer in thermal equilibrium.
The way to address this is to use an aspirated thermomenter, which has a thermal screen from above to stop solar radiation heating the sensor and a fan to waft air across the sensor – it doesn’t need a high fan speed but it needs some.
However, at night solar radiation isn’t a problem, so the air temperature reading is useful in the night, where it shows the air temperature falling below zero inside the polytunnel from about 9pm to 6am.
The soil sensors are about 5cm below the surface, which is typically where seeds would be planted.
One of the things it would be good to track at the farm is light level over the year. It’s part of a tri-sensor I want to develop to read light level, temperature and humidity, which will then radio-report to an OpenKontrol Gateway to log the values centrally.
The correct tool for this job is apparently a pyranometer which uses a thermopile to sense the heat incoming to a black surface. Presumably the thermopile, being a differential device by design, tracks variations in ambient temperature. About 40% of incoming solar energy is visible light, and a similar amount is infrared.
The obvious cheapest tool for the job is a silicon photocell, which doesn’t respond across the whole spectrum, but mainly to visible light and IR. Unfortunately the IR peak coincides with a water vapour absorption peak that makes it sensitive to water vapour too because the spectral response peak is in the IR. David Brooks’ website summarises the issues there. In his other website, he describes the fact that there’s a case to be made for measuring just the visible spectrum for photosynthetically active radiation. I’m going to start with a regular Si photocell and fight that issue later 😉
So there’s a lot wrong with the approach, but as Brooks notes –
Despite their shortcomings, solar-cell based pyranometers are widely used for meteorological, environmental, and agricultural monitoring, and their performance relative to thermopile-based pyranometers has been studied extensively. Although they are not suitable for producing stable and highly reliable research-quality data required for detecting small long-term changes in insolation, data from simple solar cell pyranometers are still very interesting. They can be used to characterize the potential of sites to produce solar power and to demonstrate seasonal effects on available solar energy. Pyranometer data recorded at intervals of a minute or so provide a record of cloud cover during the day and it has been shown in peer-reviewed scientific literature [Duchon and O’Malley, 1999] that it is possible to use pyranometer data to classify cloud amounts and types even when individual measurements of insolation are not highly accurate. It follows that such data can also be used to track long-term changes in cloud amount and type – an extremely important indicator of climate change.
Looks good enough for me. I’m going to use a BPX65 because I have some and they’re cheap-ish. The BPW21 is a better choice for visible light only, but it’s dearer, I don’t have one and it’s easy enough to switch the photodiode later on.
Right off the bat I don’t like the design of the system described on David Brooks’ page, because it takes the photodiode and rams the signal into a 470 ohm resistor across the diode. In itself there’s nothing wrong with that, but because the resulting signal voltage is low, to keep the response linear, it demands 12-bit resolution from the datalogger A/D converter though it only uses the few lower bits. Making the sensor cheaper makes the datalogger needlessly dearer without using the extra precision you’re paying for, and makes the whole system more sensitive to noise and crap due to the low signal level. However, it makes it simpler to replicate, which probably was the main design brief for that project, but I can do better because I have control of the whole system.
I’m not going to fiddle about with Arduino here – though Arduino makes some things easier it makes things dearer, and seems to lead people to a penchant for digital sensors like the TSL235R or even truly digitised sensors like the DHT22 humidity sensor with proprietary non-standard interfaces. These get hard to service in future years, compared to an analogue voltage interface.
I want a single supply transimpedance amplifier that I can limit to 5V so I don’t nuke the A/D converter of my PIC. Fortunately I have one- a CA3140 can run the input down to 0V or even 0.5V lower, can bring the output to 0V, and the strobe input lets me limit the output to 5V if I run the opamp off a higher voltage (haven’t decided there yet – if I run it off 5V then there’s no problem).
Looks like once a minute is the fastest that it’s worth sampling this and light level doesn’t really change that fast. The photocurrent is rated at 10nA/lux, daylight is about 10,000 lux peak corresponding to a photocurrent of 100µA. Given a maximum output of 4V the transimpedance resistor should be about 4/100 MΩ = 40kΩ. 39k is the closest preferred value to that, but I took 47k. This is the UK, I can probably expect a little bit less peak sunlight than noon in the Sahara. With the slow response time needed I can slug the frequency response with the 220nF capacitor – this gives me a 10 second RC time constant.
Transimpedance amplifier
You can’t suddenly demand Peak Noonday sun, NOW so I will have to field test this for sensitivity. On the bench it works fine, though the peak output with my bench lamp close to the diode is all of about 400mV. However, it’s not bright as the noonday sun there 😉
The CA3140 is a great opamp for this. Being a MOSfet design, it has virtually no input bias current to speak of, compared to the diode dark current (0.1pA as opposed to 1nA dark current). It can run down to -0.5V on the inputs, and to 0.13V on the output low. I could improve the low end by biasing the input (diode cathode and pin3) up 0.6V on a silicon diode and referring the low end of the A/D converter to that, or just sense it with another input and subtract it in software. The input offset voltage of the opamp is the waek point with MOSFET op-amps – 5mV worst case which would get a bipolar opamp binned.
However, it isn’t the worst limitation on the lowest light that can be sensed, that is the 0.13V saturation point, which would correspond to an current of .13/47k = 2.8µA, an illumination of about 280 lux. This probably needs improving, as it’s higher than a dark overcast day. The 5mV offset voltage limit corresponds to about 10㏓, though it has to be added to the various PIC A/D converter offsets which I haven’t developed yet.
This will need fine-tuning later on, but it’s good enough to get me going and ready to tackle the PIC side of things.
This is the sound of the flow inside the well-house at Chalice Well. Two springs rise in this area – the Chalice Well and gardens are home to the chalybeate Red Spring, rising from a deep underground source with little variation in flow or temperature over the years and seasons. Only a few tens of yards away is the White Spring, which rises from theg round closer to the surface. There is a definite tone to the flow – the well-head has a pentagonal chamber underneath it and the resonance of this makes a peaceful steady sound.
From a field recordist’s point of view life is made more difficult by the A361 carrying HGVs down Chilkwell Street, but the wellhead is far enough away and loud enough that this doesn’t impair the recording.
Maplin flog these SMJ remote controlled mains sockets.
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
So the first thing is to pop the lid of the remote and see what gives
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.
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 😉
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.
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
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.
Ciseco OKG
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.
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.
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
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,
