(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 Q-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.
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.
# 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.
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.
Other: use various techniques to minimise bandwidth.
Sources and Links
- 2016/03/15: The Air You Breathe at Work May Be Slowing You Down: "The higher the concentration of CO2, the lower the test scores. Even allowing for uncontrolled factors such as diet, previous night sleep quality and mood, employees’ overall sharpness fell by an average of 15 percent when CO2 levels reached “moderate” levels of about 945 parts per million (ppm). In modern office buildings, designed to maximize energy efficiency by letting in as little outside air as possible, CO2 levels around 1,000 ppm are common. However, mainly because until recently carbon dioxide was thought to be harmless, the buildup of CO2 is often even higher. That’s not good. At 1,400 ppm, for instance, the test subjects’ performance dropped by 50 percent on average, and in some cases by much more. When they were breathing well-ventilated air, with roughly the same low CO2 content as in a “green” building, the employees were 172 percent better at applying knowledge to a problem, and 97 percent more effective at responding to a crisis. Curious about the air where you work? Allen notes that there are lots of consumer-friendly carbon dioxide detectors on the market, adding that the research found that people performed best at CO2 levels of 500 to 600 ppm."
- 2015/12: "Early findings from a recent study show that our Head Office refurbishment is making people feel happier, healthier and more productive." Metrics: pressure, humidity, noise, temperature, VOCs, light.
- 2015/12/23: another set of interesting sensors:
- MSP430-PIR: PIR movement detection with good power supply characteristics (eg suitable for 2xAA rechargeables).
- EKMC160111X Panasonic PIR with ~3V supply.
- IAQ_100 combination air-quality sensor with good power supply characteristics (eg suitable for 2xAA rechargeables).
- COZIR(TM) low power (3.5mW), high performance CO2 sensor.
- 2015/10/31: analysis of relative humidity vs occupancy.
- 2015/10/29: Green offices can double your brainpower, study finds: "... people who work in well-ventilated offices with below-average levels of indoor pollutants and carbon dioxide have “significantly higher” cognitive functioning scores than those who work in offices with typical levels." and "The study also revealed that average scores for seven of the nine cognitive functions tested decreased as CO2 levels increased to levels 'commonly observed in many indoor environments'."
- 2015/10/29: Seeing through walls with WiFi detecting presence of people.
- 2015/08/31: Low-Cost Device Can Revolutionize Air Quality Monitoring and Help Countries Prevent Deaths from Outdoor Pollution: "cost around $1,500 per unit" ... "100 times less than existing solutions" ... "UNEP's device can measure the concentration of particulate matter ranging from 1 to 10 microns in diameter (PM 1 - PM 10), including PM 2.5, considered by the WHO to have the greatest effect on human health. It also records the concentration of sulphur and nitrogen oxides and can be extended to measure other gases such as ozone. The unit was designed for affordability throughout its lifecycle, with less frequent calibration required and a durability of up to 4 years. High quality has been ensured through rigorous testing in various settings, and a built-in GPS system means that the device can also be used as a mobile unit."
- 2015/07/14: Google joins Bluetooth snoop pals with iBeacon rival tech Eddystone.
- 2015/07/07: Unveiling the #BBCMicroBit.
- 2015/06/26: WiFi Offloading To Skyrocket: "The capacity of the 2.4GHz band is reaching its limit. Studies at the University of Twente in The Netherlands have demonstrated that the growing number of WiFi devices using unlicensed bands is seriously affecting network efficiency. Capacity is compromised by the number of simultaneously active devices, with transmission speeds dropping as much as 20% of the nominal value. With the number of IoT and M2M applications using WiFi continuously rising, that could become a serious problem soon." And this will apply as much to band such as those used by LoRa and its ilk.
- 2015/06/25: Batteries in the Internet of Things.
- OpenThings (O-things) "free-to-use, wireless communication standard for the IoT" could be one of the supported 'binary' formats for OpenTRV sensors.
- MicroMonitor (OpenThings) "Low-cost metrology and wireless control in a chip" and "With variants providing output over UART and SPI, and including OpenThings TM radio drivers for HopeRF 433MHz radio modules, MicroMonitor chips are easy to integrate, enabling you to get your products to your customers' hands quickly."
- Libelium eg Waspmote, with LoRa / air-quality / presence detection products.
- Bluetooth/WiFi detection:
- Where’ve you been? Your smartphone’s Wi-Fi is telling everyone.
- Passive WiFi Tracking.
- 2014/03/07: Q: How Many Phones Have Bluetooth On? A: Based on our own apps across 50,000 iPhone users, 33% already have Bluetooth turned on.
- RPi: WiFi and Bluetooth device detection.
- Bluetooth Presence Detection.
- SparkFun Bluetooth Mate Silver WRL-12576 (3.3V--6V @ 25mA, built-in antenna).
- RFD22102 RFDUINO BLE 4.0 DIP (1.9V--3.6V).
- Bluetooth module PRO for Arduino (underlying WT12 Bluetooth Class 2 Module: 2.7V to 3.6V).
- BBC micro:bit low-cost device with built-in Bluetooth Smart.
- RF Power Measurement Techniques.
- Wireless Detector (WiFi/Bluetooth).
- WiFi Signal Strength Sensor.
- Arduino Based Bluetooth Scanners.
- Bluetooth Module for Arduino.
- How to Count BT Devices with LEDs Using Bluetooth Connectivity Kit.
- Bluetooth module PRO for Arduino and Raspberry Pi.
- New Waspmote Bluetooh Radio for Device Discovery The new Bluetooth radio module has been specifically designed in order to scan up to 250 devices in a single inquiry. The main purpose is to be able to detect as many Bluetooth users as possible in the surrounding area.
- Ubertooth "The Ubertooth is able to capture and demodulate signals in the 2.4GHz ISM band with a bandwidth of 1MHz using a modulation scheme of Frequency Shift Keying or related methods. This includes, but is not limited to: * Bluetooth Basic Rate packets * Bluetooth Low Energy (Bluetooth Smart)"
- AltBeacon: "The Open and Interoperable Proximity Beacon Specification".
- Density.io: Meet Density, a startup that lets you see if your favorite coffee shop is full.
- Placemeter quantifies the movement of modern cities, at scale: $99 per month; $40 their own device cost, aiming to get it to $25 uses IR camera and tracks thermal masses requires power, uses GSM modem.
- Uber Home Automation w/ Arduino & Pi.
- XeThru microwave doppler presence/respiration sensor.
- Cambridge CMOS Sensors: Environmental Monitoring.
- airqualityegg Hardware-Sensors.
- BuggyAir mobile air sensor.
- OpenTRV raw CO2 data sets, eg office and classroom.
- Kew remote sensing work for monitoring effects of climate change on coffee growing in Ethiopia.
- Bruno's (EnergyDeck CTO) OpenThings protocol review 2015/07/09 (also here).
- Bruno's note D14 2015/06/07.
- 2015/05/29 Sensors meeting notes.