Earth Notes: On IoT Sensor Set Selection for Launchpad
(Part of WP1 Research, D14 Sensors and internals. To research the possible sensors, constraints, benefits etc. Internal components (microprocessors, power, radio etc) what we would like to measure and what we need to make it all work. Provide the intelligence to communicate the data back to base.)
Bus Shelter Footfall
Some sensing technologies to be considered for bus shelter footfall, highest-priority first, given that we'd not like anything we use to be visible nor require physical modification of the shelters/flags if at all possible:
- [core] Light obstruction (eg sudden drop indicates someone seated) in seats or maybe elsewhere.
- [core] Push-buttons on timetable boards and other direct physical interaction.
- [core] Human voice (eg Quantimetrica).
- Bluetooth phone (eg on person) detection (eg WRL-12576 or Bluetooth module PRO). Bluetooth preferred over (say) Wifi for lower-range and thus less likely to pick up signals from nearby buildings, etc.
- Capacitive proximity detection in seats or maybe elsewhere (eg CapSenseTest).
- Microwave doppler (eg HB100 and breakout board, Parallax X-Band Motion Detector #32213 5V@8mA digital output).
- Seat strain gauge to detect breathing and/or heartbeat.
- Resistive strain gauge in seats.
- Wifi phone (eg on person) detection.
- GSM phone (eg on person) detection.
- NFC direct to sensor unit.
- RF/RSSI disturbance.
- Web contact (eg via NFC or QR-code in shelter) possibly fed back to the shelter or just used centrally, screened to be from a plausible local mobile number or IP address if necessary.
- Ultrasound beam reflection/doppler (eg https://github.com/OpenSensorsIO/arduino).
Additional for consideration:
- IR beam curtain break, eg Politec Sadrin battery powered.
- Combined PIR and microwave, eg GJD D-TECT 3.
- Microwave doppler (XeThru).
- IR beam reflection proximity detection.
- Thermal imaging.
- Accelerometer in structural elements, eg detecting people sitting/leaning.
- CO2 (breath exhalation) detection.
- Laser curtain (eg from roof-mounted unit) to look for objects above a certain size in specific areas, eg adults in front of ads.
- Audio (ultrasonic?, automatic/manual) beacon app on mobile phones to signal presence and get attention of our units.
- PaveGen-style pavement pressure sensing and energy harvesting.
- Monitoring power usage for detecting (eg) lighting failure.
- (Interaction with units such as BuggyAir mobile air sensor.)
- (Video analysis from CCTV overlooking shelter.)
- (LIDAR scanning of street and shelters.)
- (Satellite X-band radar scanning of street and shelters.)
One possibility is to have a hierarchy of presence detectors, only invoking the more energy-intensive ones intermittently and also only if lower-power ones haven’t detected presence already.
We may also want to collect some readings not directly connected to footfall, eg to help the bus operator try to predict footfall from parameters such as temperature:
- [core] Temperature (eg TMP112, SHT21).
- Relative humidity (eg SHT21).
- Ambient light (eg LDR or phototransistor).
- Ambient noise levels.
- CO2, CO, NOX (MiCS-2710, MiCS-4514, CCS801, etc).
- Wind speed.
- PM10, PM2.5 particulates.
Interesting devices that probably don't make the grade because of power-requirements, eg 'warm-up time' preventing low-duty-cycle sampling include:
- CO2: Grove 25mW consumption (@5V) with 3-minute warm-up time.
- Generic AQ: Winsen MP503 ~25mW consumption (@5V) with 3-minute warm-up time.
Note that techniques that minimise disruption are preferred, eg:
- Don't require permanent physical alteration of the shelter, eg drilling holes for PIR.
- Don't obstruct use of the shelter in any way.
- Don't leave visible traces for bored people to notice/attack.
- Don't look valuable to avoid encouraging theft.
- Don't collect/relay data that identifies individuals, eg phone numbers.
- Don't annoy classes of users such as teens or pet owners, eg with near ultrasound.
- Don't use lots of power, in order to make battery or energy harvesting viable.
- Don't cost too much!
Footfall sensing for shelters probably does not need to be massively accurate, and some passengers for example will lurk away from shelters where we cannot reasonably notice them. The difference between no one waiting and someone, and (say) in bands of [1--5, 6--10, more] may suffice in most cases.
It is assumed that combinations of sensors will be needed, and different sets of sensors in (eg) quiet and noisy/busy streets will help.
We could nominally cover several areas under this part of the programme, from a sensor point of view:
- Metering; possibly including more novel forms such as estimating radiator heat usage from flow and return temperature and valve position.
- Environmental: temperature, humidity, illumination, noise levels, CO2, CO, NOX, VOC, pressure, etc. Example sensors: CubeSensors, Netatmo.
- Light quality (NM of ED to further characterise as of 2015/05/29):
- Daylight vs artificial light - why? Is it the colour rendering? What matters for the difference beyond pure light intensity. Is it more than just CRI (colour rendering index) or flicker for example?
- Richard Francis confirms there is a preference for daylight, but does not know the science behind it as to why. Need to do some research on parameters (Nic to do).
- Looks like it’ll be medical literature where we’ll get the best research from here - links between daylight and healing/health seem to have been studied.
- Usage/utilisation: occupancy (eg footfall as for bus shelters), including proxies from existing systems such as coffees bought at cafe, vending machine usage, photocopy usage, security barriers + PIR, water usage, other virtual/proxy streams from (BMS) data streams.
(See also 2015/05/29 meeting notes.)
Expecting only to need telemetry data volumes, eg medium-precision numbers such as temperatures to 16ths°C every few minutes.
The customisable set of sensors per sensing node seems a useful feature, according to Richard Francis, because not all sensors required in all places. So one-size-fits-all solutions tend to miss some important sensors. Add ability to retrofit sensors (eg as tech improves) would be valuable. (Conversation w/ Nic Mason of Energy Deck 2015/05/29.)
May need multiple sensors per room/space. Cheap sensors mean more can be deployed in case of doubt. Deal with gradients of various parameters across spaces, eg temp, RH%. Though will always be extremes such as 30°C under desk with many PCs, 15°C above desk directly under an aircon vent!
May want to (say) initially deploy 100 sensors, then whittle down to 20 representative, which may imply mobile or temporary sensors with tracking and integrity issues.
May also wish to incoroprate sensor outputs from (staff) mobile phones, if data issues can be dealt with properly. eg using BuggyAir-style sensors talking to the user's phone and/or Bluetooth Smart or WiFi access points, with one or the other doing data transfer and location.
Bruno's (EnergyDeck CTO) note D14 2015/06/07 (edited here to include core designations as needed)...
# D14: Sensors and internals # ## Essential [core] ## - Temperature - Light - Humidity ## Use case specific ## ### Hotels + social housing ### - Occupancy indication, e.g. CO2 [core] ### Hotels, social housing and office ### - Environment quality: - Air: particulates, NOX, CO, CO2 - Noise - Airflow ### Industrial ### - Movement sensor to detect when the device is moved ## Device management ## A number of feeds that represent internal system status rather than actual sensors are useful for device management: - Battery level [core] - Quality of communication link ## Other possible internals ## - Capacitor to give the device a few seconds of life when batteries are removed (enough time to record battery removal before shutting down)
2015/06/17 additionally, non-core: linear/digital heat detection cable (eg 700-770 70°C) for discovering persistent overheating (eg early warning for fire safety.
2015/06/25 additionally, non-core: airspeed (indoors and outdoors).
Note in particular the use of a motion sensor to detect/deter tampering, or, for example, moving a sensor from a failing fridge to a working one to cover up problems. Forwarded from D16 Security. See for example the MC3600 series: mCube Introduces Accelerometers Optimized for the ‘Internet of Moving Things’... which may also be good for things get moved that shouldn't, drawing 0.6uA and is 2mm on a side, PCB mount.
Note the OpenThings' Protocol "Universal Messaging Structure for Connected Devices" (2014) 'alarm' messages (B low battery, P power fail, T over temperature, Z tamper) which probably represent in the first instance the range of management parameters that should be considered.
Also a battery-removed (restart) counter may be treated as a pseudo-sensor for security and estate-monitoring purposes. Forwarded from D16 Security.
2015/05/08: spoke to XeThru about its product, which looks initially suitable to include in our sensor set indoor and outdoor as occupancy/footfall sensing, noting the following key points:
- Unit cannot be used in fixed applications outdoors in the EU currently, which means that we could probably not permanently deploy in bus shelters without further regulatory approval though we could probably do a 2h test or similar.
- Current firmware runs continuously, drawing 400mW; we discussed 'enable' GPIO or I2C to allow the unit to run (say) up to 15 seconds in each few minutes to save energy and still detect footfall. Major movements such as walking take a second or two to detect, breathing takes ~10s.
- As expected cannot see through metal (plate), but happy to have metal in view and can work with reflections via them.
- 3.3-5.5V supply voltage and 3V I/O (3.3V compliant) on X2M300 Presence Module.
- Dev kit currently $1499.
More on the outdoor regs issue: XeThru says:
"A bus shelter is may be a gray area in the regulations. Static outdoor installations are not allowed. A parking garage or a carport is OK. Use in handheld applications outdoors is OK. Also mounting in a car or a boat is OK."
Mike S notes:
 UWB  is not the same as conventional SRD (covered by IR2030 in the UK). It seems the FCC is ahead of Europe on this, which is presumably why they say they got their FCC approval already (although I can't find it on the FCC database).
I guess the relevant EU standard is this one: http://www.etsi.org/deliver/etsi_en/302500_302599/30250001/01.02.01_60/en_30250001v010201p.pdf
It's all pretty new in the UK, and in fact it looks like it was only properly written into the WT act [March 2015]: http://stakeholders.ofcom.org.uk/binaries/consultations/uwb-regulations/statement/statement.pdf
From the ETSI doc:The following additional information shall be included in the users' manual:
- statements that the UWB transmitter equipment conforming to the present document shall not be:
- installed at a fixed outdoor location;
A likely reason for this is the risk of interference to radio-astronomy and deep space comms; the latter I believe is often around 8 GHz.
(AVR, ARM, others; toolchains, community support, licensing issues, cost, power use, integrated support eg for AES. Existing full system contenders such as Libelium. Missing pieces such as pluggability.)
The current OpenTRV (V0p2) board is essentially an Arduino UNO tweaked to minimise power consumption (<10uW when idle and maintaining a software real-time clock, and <100uW or less typically including common sensors and ISM radio) and to allow running directly from 2xAA cells, usually NiMH rechargables. It is programmable directly from the Arduino IDE and is fundamentally cheap and simple and robust. It is based on the Atmel AVR ATMega328P with 32kB of Flash, 2kB RAM and 1kB EEPROM, and has a variety of digital I/O and multiplexed ADC and comparator inputs, including, for example, an internal reference voltage and access to the supply voltage, and a very crude temperature sensor. The 328P has an 8-bit CPU, a good toolchain based on gcc, and some key instructions such as fast multiplies, but does not have (for example) any crypto support.
(Note that a typical NiMH AA cell has a capacity of ~2Wh, so a pair is ~4Wh, thus 100uW consumption implies 40,000h runtime (4.5 years), when self-discharge time for even NiMH hybrids is likely to be a year or two at most.)
A clear alternative candidate MCU would be one based on (say) the ARM Cortex-M0 core, which at 32 bits and often bundled with more advanced I/O and crypto feature and in many implementations from several manufacturers is attractive, though toolchain limitations (eg licensing) and a smaller development community can be limit the relative attractiveness over the 328P world. (Arduino's extension to ARM helps bring the huge development and user community over though.)
This Launchpad project is not committed to using the OpenTRV hardware, and is for example looking at Microduino which seems to share our cost and pluggability aims (for sensors and MCUs) and has a clever physical form. This supports AVR and ARM variants, and leans on the Arduino ecosystem as OpenTRV's board does.
The Libelium Waspmote stack looks like something that this Launchpad project could aspire to in terms of the range of sensors and radios it supports for example, and runs on the ATmega1281 and is open source, though apparently has a higher base running power consumption ~180uW, and a price point one or two orders of magnitude above our target.
There are other low-power low-cost MCUs out there at good price points, including long-lived product cores such as the 8051 and STM8L for example, but AVR and ARM may well have the deepest development and toolchain support where many design and debugging issues can be solved with your favourite search engine rather than expensive or cumbersome debugging tools, so these may be currently the most productive IoT architectures. (Note that the first OpenTRV hardware was done on the PICAXE, eg a PIC derivative, which also has an excellent pedigree.)
(Note that the presence of non-volatile storage with a high-write count, such as the 328P's 100k+ byte-by-byte write-cycle EEPROM vs 10k page-write Flash, is a very useful tool in many applications where state/adaptation is needed.)
Where sensitive data is managed the ability to protect hardware, security keys, and some of the data itself, as, for example, supported by good security 'fuses' in the MCU is useful and may be critical. (It also allows the deployment of added-value protected secret-sauce code in some applications allowing for a wide variety of business models even within an open-source ecosystem; schematics aren't hard to reverse engineer but code smarts are harder.)
Initially the Launchpad project will use OpenTRV hardware designs purely for the pragmatic reason that we have full rights to do so and are set up to use and modify them easily. Some one-off elements of the project may however use third-party hardware, and the whole project could switch to third-party hardware and software base if that appears to provide the best platform for us and other using our work.
Note also there has been preliminary work done on a proposed 14-pin I2CEXT connector and board, which also supports in-circuit programming of the AVR, and which we have used on the REV7 production-engineered all-in-one valve PCB (with a minor alteration).
There are various sources of power available in our target bus shelters:
- Mains power (available in many), allows a wider range or sensors, but requires a more skilled crew and more time to install.
- Battery power: a few months' run time would do for our trial, but years would be desirable for production deployments. Power for sensors an radios has to be carefully managed. Primary or secondary (rechargable) cells are possible.
- Renewable power (eg solar PV) or energy harvesting with rechargable batteries and/or supercap-type storage.
Power consumption of a battery-powered MCU+sensors+radio stack should probably be pitched to be around the self-discharge rate of the batteries to maximise utility vs cost/size/weight for example.
Many of the same ergonomics apply in office/building deployments, with even quite a small area of PV able to power efficient sensors at room light levels for example, but there are also sources of power such as PoE (Power over Ethernet).
Where mains is available some scavenging that does not require a qualified sparky may be possible.
For minimum friction and cost for our trials most devices will probably battery powered, but minimising maintenance costs in long term deployments may dictate either mains or (expensive) multi-year batteries or some sort of harvesting.
Relatively power-hungry sensors such as WiFi/Bluetooth sniffing, or particulates sensors (with fans requiring several Watts), may dictate mains supplies or very intermittent use with battery power.
The aim as far as possible with the Launchpad trial is to use a standardised 2xAA NiMH (normal or hybrid) battery pack; variants may need to be supported, and voltage converters or regulators provided for specialist sensor/radio equipment.
(Having common sensor support in Flash image with runtime sensor discovery/enumeration, but also with possibility to compose and build new Flash images in IDE or on-line without programming, especially for uncommon sensors and/or those that need bulky code or for enhanced crypto, plus possible interpreter support for boot/init such as Sun Forth-based workstations/servers.)
Arguably the nub of the entire Launchpad project, this will only get a preliminary examination now.
This concerns the ability to, at deployment time and after, select a suitable set of sensors for the site and have them, without explicit coding or anything more than physical plugging in where possible, (a) be discovered by the run-time and (b) send their data downstream.
Note that we always want to let (indeed, encourage) experienced low-level hackers get right in there and manage the hardware and so on directly, eg specialised final engineering support to optimise for final production, but this project will achieve its purpose if no one has to break out an Arduino IDE or equivalent to get at least common cases working easily and cheaply.
Pluggable cards into slots on a motherboard, or even I/O 'shields' on a device such as an Arduino, are nothing new. Nor is run-time discovery of connected devices; most consumer/server operating systems such as *nix variants and Windows do it. But 'loading' or 'updating' a driver as is common on one those systems is a very different world to the capabilities of a microcontroller, eg the microcontroller also has far smaller code and RAM capacity than the *nix/Windows systems, more akin to older DOS or CP/M systems.
The Microduino has an interesting take on physical pluggability with magnetic clips, and has a substitutable CPU; we will be investigating a kit in due course. Its licensing and actual 'open'ness remain unclear.
Adding crypto (ie security) support where the selected data backhaul bearer does not provide adequate provision itself, will further eat into available code space, and that will restrict the number of 'drivers' and thus devices that can be summoned up at run time from any one standard code image.
The data backhaul radio drivers themselves can be complex, and code heavy. (Note also that these radios may provide some sensing capability, eg in terms of RSSI.)
Equally, power management may require significant adjustments to code and supply design, eg an especially low-power start-up and extra circuitry beyond the MCU's brown-out-detection for energy harvesting apps even as simple as running directly from solar PV where marginal light and slow ramp-up times may cause boot-up to fail (observed with REV2 boards for example).
This suggests that although power, MCU and radio should be available entirely distinctly to allow maximum freedom of configuration, it will often be useful to integrate those elements on to single boards (with a small number of basic, cheap sensors) with code tuned for those elements plus drivers for the most common sensors to be plugged in on 'shields' such as via I2CEXT.
Some sensors will be difficult to make run-time detectable, eg attempting to detect them when not present might cause the MCU to hang. Or other pairs of drivers/devices may not be able to co-exist, eg because of sharing the same I2C address.
If large numbers of leaf nodes are to be deployed in the field for a particular application then forcing a custom code release for each device is probably not ideal, and it is also specifically useful to add and remove sensors after deployment, eg to winnow out uses of a more expensive sensor where it proves not to add much value, eg for rare issues.
In any case it will be necessary to tweak the driver selection for more unusual combinations, and it should be possible to do this and create a code image largely automatically without the end user having to do more than specify which components they want to have supported in a given set of deployments, eg by visually assembling all the combinations of 'bricks' they want on screen, or in a text file or series thereof.
In the OpenTRV code already there is a standard ‘Sensor’ base class that might help achieve mix-n-match sensor drivers. (And the Actuator class derives from Sensor.) With extra cleverness it may be possible to drop sensors at standard locations in memory rather than doing a full link, though that may waste some space or have other complications, eg with constructors/destructors or multiple instances of the same sensor such as temperature and RH% at multiple heights.
(Note possible use of constructors and static initialisers for drivers to 'announce' their own availability, then be called to test for actual device during start-up.)
There are probably some things that we want to avoid, such as plugging two MCUs into the same stack, or two instances of exactly the same sensor, usually, but accommodating multiple power sources could be very useful with such things as RF energy harvesting + solar PV + rechargable batteries in combination being good.
In any case, many of the pluggable-driver techniques could be applied to (say) Arduino shields, ie could be used outside the Launchpad hardware.
(See the pluggability thread in the OpenTRV-dev mail archive.)
(Note radio (D17) and value rotation and transmission on deltas vs traffic analysis, security (D16), JSON vs binary (D15) and security and frame sizes (D16/D17).)
Key to making a viable IoT ecosystem is minimising these values:
- Development effort/complexity.
- Capital cost (CAPEX).
- Deployment and maintenance cost (OPEX).
- Power consumption of sensor leaf nodes.
- Radio bandwidth use of sensor leaf nodes.
All of these are limiting resources; parsimony makes more projects possible.
Some things that can be done to minimise radio bandwidth use are:
- Use efficient basic data sensor/data representations, eg scaled integer offset from typical central value rather than floating-point, and delta encoding between related values in one message such as temperatures at multiple heights which are likely to be fairly similar.
- Switch to optimised binary encoding (from JSON) ASAP.
- Send deltas/changes and/or send data upon changes and/or send changed data more often (though may enable extra traffic analysis (see D16 Security) by malicious actors, so consider some TX-timing randomisation to mitigate for example, which can help anyway in such shared-channel systems).
- Allow variable-length frames and/or rotate set of values to be sent into relatively small frames (perhaps sending at least one changed value in each).
- Apply noise reduction and filtering before sending.
- Send fewer more information-rich synthetic higher-level readings, eg occupancy, rather than lots of lower-value raw direct sensor readings.
This project assumes that the 'telemetry'-scale data to be transmitted can be logically expressed as a small number of name/value pairs, with the name optionally carrying an explicit unit, and the value primarily numeric and usually integer. For JSON encoding an 'object' is the natural representation. For an efficient hand-crafted binary representation (usually requiring some specialist effort, and after a project has stabilised) names and units are likely to be largely implicit (not explicitly transmitted) and more exotic value representations may be possible.
Note that for bulky multi-sensor data sets with many components, and when encoded in JSON in particular, rotation of various name/value pairs into transmitted frames, given a typical size limit of ~60 bytes (or maybe ~30 with auth/enc), is probably essential. OpenTRV already has some relatively lightweight (Arduino) code that does this (the SimpleStatsRotation C++ class) though it could be improved, eg by moving the ID (@) and sequence number (+) out of the frame if provided out-of-band by the backhaul bearer.
Main sensors to support:
- Light level/obstruction (LDR/phototransistor as per OpenTRV).
- Push-buttons on timetable boards and other direct physical interaction.
- Human voice (eg Quantimetrica).
- Temperature (eg TMP112, SHT21), possibly multiple sensors per leaf node.
- Relative humidity (eg SHT21).
- Battery level (internal).
- Restart counter 'low power / power fail' (internal).
- Accelerometer, tilt switch, loop wire, 'tamper detection' etc (eg MC3600).
- Over-temperature (internal).
- Occupancy/presence, explicit or synthetic as per OpenTRV now.
- One set of indoor and outdoor air quality instruments TBD, including CO2.
Power: use a standard 2xAA NiMH battery pack wherever possible, avoid mains.
Hardware: initially use OpenTRV AVR designs, based on V0p2 REV2 or REV4.
- Provide bare CPU board, and some combined MCU+radio+sensor boards.
- Support a standard sensor mix code-stack or two, plus ability to explicitly combine any desired sensor driver set.
- Continue to allow IDE-level access.
- Build on standard Sensor interface.
(We won't support nor necessarily protect against multiple power sources or CPUs or clashing sensors in one stack, at least initially.)
Other: use various techniques to minimise bandwidth.