A fun project was using the Electric IMP001 to communicate with an RS485 pressure transducer. The readings are delivered to the cloud and use the nice (and evolving) services of thingspeak.net.
The starting point was to test the stability of an RS485 pressure sensor – and check out the then new IMP001 – two projects in one.
Stability testing a pressure transducer is putting it into a bottle of water and letting the daily temperature cycle drive the water temperature and seeing how stable the readings are that the temperature sensor makes, as the water height is steady and only the temperature varies. Of course stopping water from evaporating takes a bit more planning.
The basic data flow thru is shown below – the hardware circuit is fairly simple. Yeah!!
Since it’s a prototype I used a lab 12V power supply.The parts from Sparkfun
- IMP001 – $29.95
- IMP Breakout board BOB-12886 $12.95
- RS485 breakout board BOB10124
- Power supply – 12v to +5V
- FDG6324 transistor switch (Digikey) – optional
The IMP001 is a WiFi speaking device, in a SD card format with 6pins that can be controlled from it.
It uses a totally cloud based IDE for program development –
– pretty good. Compile on the cloud and download a ‘nut’ programmed in Squirrel Language to the IMP.
This is cutting edge for trying a new IOT (Internet of Things) device.
In the data flow schematic diagram below everything in hot red is the IMP domain.
The IMP software pushes a proprietary packet through the firewall to a proprietary “agent” service on the cloud.
The IMP001 and thingspeak.net are where the smarts are.
The IMP001 pin out is shown
I define a periodic loop on the IMP that reads from the modus RS485 devices and then pushes the readings to the agent services – where I format it into a REST protocol that is pushed to thingspeak. Of course that’s the simple explanation – a lot of tight software is involved – and squirrel language takes some getting used to.
Thingspeak.com (everything in cool green) is an open source REST based API, developed by Iobridge.com, to store readings – REST API/internet. These readings can then be brought up by a web interface – html/http/internet
Pretty cool – and it works!
Here is a link to the software https://github.com/neilh10/ei_modbus
– the ‘.nut’ is put in the cloud IDE ‘device’ and the .agent in the agent window.
So what’s the downside. There are always a few issues somewhere and the benefit of prototyping is to discover them.
Getting the IMP into the protected WiFi space has been implemented using what’s called a “Blinkup”. The IMP has a photo diode that receives a light message about the WiFi networks passwords. This is an App that runs on the iPhone or an android device. I have android – at the time Android 2.2 and then 4.0, (no iPhone). It had problems. The founder Hugo is from Apple – a really nice guy, and the IMP001 is a nice design. The App blinks the WiFi passwords to the IMP. If I tried long enough it did eventually work – and I did get some help from the Electric Imp developers to get it communicating – and the IMP software has improved since I first tried it. I still like the way the Honeywell RTH6580WF WiFi thermostat does it. The RTH6580 broadcasts as a WiFi host, which can be selected from the WiFi device, and then in the local RTH6580 web site you enter the password keys to the WiFi net of choice.
The IMP is based on basic STM32 – so maybe there are technical challenges with putting up a local web host
IMHO there are other IMP limitations – and they maybe because it’s a low cost STM32 device. These are 1) it isn’t visible on the local WiFi network. 2) The IMP requires all REST publishing to be done from the cloud – and the support for identifying which IMP is reporting on the cloud is challenging. 3) The cloud IDE is great for getting started, but doesn’t scale well. I like my local Eclipse IDE.
Another limitation is more fundamental to a riparian zone. WiFi uses the 2.4GHz spectrum, and 2.4GHz is absorbed by water. For a building with relatively low water content, WiFi works well. For a riparian zone – where there might be a bush in the way and it is opaque – the signal disappears. General WiFi specs are typically specified at low power, as they are only meant to serve a building. So if the sensor is near a building with internet, WiFi can be a good choice.
With specialist transmission equipment, and good power availability, a 2.4GHz signal can go a long distance.
Another idea for an IMP: use it on a tipping bucket rain collector.
I’ve mounted my tipping bucket on the roof of my house, and run the contact closures for the tipping bucket through telephone wire to an Arduino board, which sends it to the internet. A lot of work went into getting the telephone line from my roof to my equipment closet.
Arduino has some great examples of the REST interface that can be translated to the IMP Agent format. Here is my tipping bucket Davis Rain Gauge output
https://thingspeak.com/channels/8652
Has anybody else had experience with the Electric IMP device, or stability testing of a pressure sensor? The stability testing of the pressure sensor was pretty good, and I’m keeping it going for some long term checks, though I’m also talking to the manufacturer about some other issues. The problem is that the Modbus interface is not supported by other access technologies. Standard interface technologies – like 4-20mA interfaces – often are the only interfaces for proprietary transmission technologies.
What kind of pressure sensor are you using? You can usually get temperature-compensated ones for only a slightly higher cost than non-compensated ones.
I’m working with a variety of models – the base specification has been 0.1%FS TEB (Full Scale Total Error Band) with acceptance testing for a 10C shift in water temp across a diurnal cycle. The spec has been to accurately measure low levels at about the 0.2-1foot mark of water in summer – with a hydro-graph range of 0-10feet.
Initially we used the Keller levelgauge -and some of them came up with a wild temperature instability, that is as the water warmed by couple of degrees they oscillated the full extent of their error band and in some cases went outside it. The error wasn’t allocated proportionately across the error band.
Then switched to a Keller Acculelvel that has a tighter error band. I ran tests on them all before we deployed them to the field.
I’m interested in what other people are using. The critical issue is having the 0.1% Total Error Band across a 10C shift in water temperature.
I’ve heard some people recommend the Solinst devices, and the standalone Insitu – so I’m building a database if anybody has a favorite and any experience to share 🙂