To simplify developing (low power wireless) IoT sensor prototypes we have come up with the following architecture specifications.
Key Features of this Architecture
Check out www.PUREmodules.com. Where you can buy modules based on this architecture.
Common Hardware Interconnect
To allow for prototypes to be small and low cost we have chosen a 62mil PCB edge connector as the hardware interface. This interface has 0 components to be added to a PCB to allow it to connect to the system by a low cost connector. By using a PCB edge the costs remain low for the sensor and can be added to nearly any development board with no additional cost.
The 009159010061916 AVX Open Ended Card Edge: BTB was chosen as the default interface to connect two PCB's together. The connection is very robust and allows for many insertions and can carry higher currents if needed. The density is high and doesn't use very much PCB real estate.
We have chosen I2C to be the primary interface to adding new sensors to the system. I2C was chosen for its simple two wire interface and multi drop architecture. The protocol is typically used for low power hardware sensors, so for most common sensors there is no interconnect logic.
The common pin-out is as follows
It is preferred to pass these signals through the PCB if possible, but not required because a multi expansion board could be used if needed if no sensors have pass through capability.
Common Firmware platform
We have chosen contiki as the the foundation for the system. Contiki has been used for many years now and is very stable and well supported. It was designed around low power, low resource, wireless systems. This is an ideal fit for a Modular Sensor Architecture.
Common Sensor Communication
MQTT was chosen as the data transport layer due to its extremely lightweight overhead. It easily allows scaling from one sensor to millions. It is well used and supported. Both MQTT and MQTT-sn are utilized depending on the RF communication interface. MQTT-sn is typically used over MQTT due to its lower overhead.
Common Data protocol
To describe data moving from A->B Protocol Buffers and more specifically nanoPb is used. By using a compact and common protocol data can be digested by almost anything simply by publishing your .proto file.
Common Micro Controllers
We have chosen two micro controllers to be the primary supported micro-controllers under this sensor architecture.
nrf52 : Nordic's latest SoC had handle almost anything thrown at it and still remain a low power.
cc2650: TI novel three core architecture allows for extremely low power systems.
Sample Breakout Board
This sample board showcases a sample sensor that was developed for this architecture, to allow for daisy chaining additional sensors to it, the hardware interconnect passes through the PCB to allow another sensor to plug into it. This allows for a versatile system to be built quickly and easily.
For adding Analog sensors to the system, the preferred route is using an I2C ADC converter chip. we highly recommend the ADS7924 due to its low power standby current and the ability to control the power of the analog sensors to reduce power usage. The Mics 6814 sensor module uses this chip.
We highly recommend the Semtech SX1508B GPIO chip. This chip is very versatile and low power. it most likely can do what you need. We recommend using this I2C GPIO over the micro-controller pins mainly to keep your pin count low and flexible. Also this IC provides level shifting if needed and when going to low power sleep states, you won't have to mess with the GPIO states of the micro-controller. Lastly by using I2C instead of pin on the controller we can expand to a complex system very easily.
Ideally your sensors can connect via I2C but in the case of a legacy system sometimes you have to UART. One recommended route is using the SC16IS740 to provide a path from I2C to uart (this part is 30uA so not ideal for a coin cell). We know this isn't always the best option so one uart to the micro is provided, but remember that only one sensor can use it at a time.
The goal is to be able to run from a coin cell for years. So ideally any sensor added to the system can enter sleep mode to something less than 1uA. If the sensor can't do this, then think about adding a way to shut power off completely, but remember for I2C we want to keep the bus with open collector sensors only, this way the bus is not corrupted with a sensor without power.
If your sensor is capable of low power sensing (like an 1Hz accelerator waiting for motion) Then it makes sense to run an interrupt to the main micro-controller. We prefer that pin 10 be used for this, and that the interrupt is open collector. This way if more than one sensor wishes to wake-up the micro, then there is no contention on this one interrupt line. If the sensor is in a push-pull configuration for its interrupt and n-fet can be used to convert it to a open-collector IO.
This image above shows how the connector is oriented for a sensor. Note the location of pin 1 as well as the slot location.
A tentative expansion is proposed below for SPI sensors:
The SPI Sensor pin-out is as follows
To prevent accidental plugging into the I2C sensor port, the connector will be reversed. Additionally the recommended placement of the SPI port is to be adjacent to the standard I2C sensor expansion port. This would allow both ports to run to a sensor board if needed.
For SPI sensors, typically the GPIO will be consumed by the Sensor typically for a CS. If additional GPIO is needed as well, those can be used as well. GPIO 6 should be used before 7, and etc. When passing though the signals should the board, the GPIO positions should shift downwards, so say one used GPIO(6) for the CS line, then when passing the signals through the PCB, GPIO(7) will route to pin 6 on outgoing line. Pin 10 would be not be connected.
Additionally we have standardized the spacing from an i2c connector to allow both the i2c and spi connections to be used at the same time. This allows more complex sensors to be used and interconnected with the system.
Here is road-map of some planned sensor modules, email any suggestions or if you have created a compable sensor to add to the list above.
Visit this Google Group to ask questions and make suggestions.
Please feel free to email us about suggestions, questions or inquiries about this Architecture as well.