Hub Shields Arrived!

I’m getting a bit ahead of the posts here, but I just received the bare boards for the other end of the Wireless RH/Temp Sensor system.

On the other end of this system, there needs to be a device to collect the data being generated by the sensor modules. I chose to go with a daughter board to the BeagleBone Black, which already includes an Ethernet interface to push the data to a server. The shield (cape, etc.) contains the radio device for receiving the data, the standard cape EEPROM, another RH/Temp sensor, a buzzer and some LEDs for indication.

The board has already been designed, and I had three PCBs fabbed. You may recognize the signature purple solder mask, courtesy of OSH Park. Well they arrived the other day and I wanted to share.

Bare Hub Shield PCBs.

Bare Hub Shield PCBs.

Choosing a Sensor

I’m back to discuss my choice of sensor for the Wireless RH/Temp Sensor Module. I wanted to capture a few simple requirements with the device.

  • Should be PCB mount, preferably SMT.
  • Should be capable of automated assembly, to avoid hand-placement in production.
  • Have an accuracy of ±3% RH or better.
  • Have an accuracy of ±0.5°C or better.
  • Have a resolution of 10-bits or better.
  • Have a response time of 10s. or better.
  • Needs to operate at the VCC rail of the device.

With regards to the system VCC I chose 2.5V to allow it to operate in the bottom-end of a Li-Poly battery charge life (around 2.8V), and to reduce current consumption. Keeping in mind that there would need to be LDO regulators to get down to 2.5V, and being conscious of their dropout voltage which might be ~0.1V. The radio works down to 2.0V, and most micros work down to 1.8V in some limited oscillator + power ranges. If for some reason a chosen device won’t work that low, I would have the flexibility to replace the 2.5V regulators with 3.0V or 3.3V ones, even if I didn’t get the same battery life.

One of the things I discovered when I went searching for a sensor device was that there is a great disparity in price with relation to accuracy, but it doesn’t scale linearly by any means.

I first searched to see what people might be using with Arduinos, and found this device at Sparkfun. Unfortunately, the minimum voltage is 3.3V, and it’s a little large.

I also found this board at Adafruit, using a Measurement Specialties device. It meets all of the requirements, so I looked the device up on Digikey. Although it has great specs, it’s also $12 per part in low volumes. So, I poked around on Digikey some more and found some Honeywell parts that met the specs as well. The problem here was the range of costs for similar parts. Most parts were ±4%, and ranged from $18-30 in SIP packages. The ±3% parts were even higher, some at nearly $80 a piece. I decided to take a look at Honeywell’s line guide on their site, and configured the part that I was looking for. The part I found was an HIH7130, which was difficult to buy on distributor sites and was costly ~$22 ea.

So I broadened my search on Digikey for different manufacturers, and eventually found a Silicon Labs part, SI7013-A10-GM1R. The only spec it didn’t meet was the response time (18s.) However, I realized humidity doesn’t change that quickly and I would only be sampling once a minute or less frequently. In addition, the per part cost was $5.13 ea. in low volumes at DK. At Mouser they are slightly less @$5.10 ea. In volume the costs are hard to predict because you can work with distributors and vendors to get the best pricing. But, it appeared that it would be around $4.50 / 1000 pcs.

The lesson here is that in product design, you may allow for one requirement (response time) to slip for another (cost.) In some client projects, there is little wiggle room and often something like response time may actually drive the rest of the requirements. For instance, if a sensor system is operating in a highly dynamic environment that requires continuous monitoring. RH isn’t a good example here, but if the sensor is monitoring the temperature of a mission-critical server node it definitely applies.

Datasheet of SI7013.

Silicon Labs SI7013 RH/Temp Sensor in T/R Strip.

Silicon Labs SI7013 RH/Temp Sensor in T/R Strip.

Intro to the Wireless RH/Temp Sensor Module

For a while now, I’ve wanted to have the capability to monitor isolated environments for changes in relative humidity and temperature over time. There are certain areas of our house that always seem hotter or more humid, especially in the summer. I’d like to have measurement nodes to confirm this by logging it over time, which will allow my to take some corrective action in the worst areas.

So the major requirements become:

  • Must be able to measure RH + Temp.
  • Must be wireless.
  • Must be battery powered.
  • Must allow remote data to be collected somewhere for future reference.

There are already available products on the market that do just this. One such product is the Wireless Sensor Tag System. These devices are small, relatively low-cost, battery powered, and wireless, with a backend for tracking and data. There are three things that I felt could use improvement, however: battery type/life, range, and the backend application.

Also, I like making things. So I decided to design my own. In addition to the above requirements, I had some additional ones:

  • Uses a Li-Poly or Li-Ion type battery.
  • Operates in the 900MHz ISM band.
  • Has some local intelligence.
  • Has a USB interface for battery charging, FW updates, and parameter changes.

I had the option of making the devices true IoT (Internet of Things) products by putting something like the TI SimpleLink WiFi devices on there, but I was concerned about battery life. Granted, the devices only need to wake up once a minute (or every five minutes, etc.,) transmit a data packet, and go back to sleep. Still, it takes time for a device to register on the network. By opting for just a low-bandwidth, low-power transmitter, the device can wake up and transmit a packet within several milliseconds, where WiFi can sometimes take 10’s of seconds to register on a network. According to the datasheet for the CC3100, TX mode can consume anywhere from 160-272mA.

The radio I decided to go with was the TI CC1175 transmitter. By comparison, the spec for transmit mode in the 900MHz band for a +10dBm output is 34mA. I chose this radio for several reasons: low-cost, low-power, flexibility of configuration, and ease of implementation. I’ve had experience with this series of radios before, so the interface feels familiar.

Full disclosure, I’m already pretty far along with this project, but I wanted to walk through the design process for everyone else. In the next post I’ll either detail the selection of sensor or micro.

The TX radio section of the wireless sensor module.

The TX radio section of the wireless sensor module.