# Up for Review: Build an Arduino Multi-Node BLE Humidity and Temperature Sensor Monitor

#### RK37

Joined Jun 26, 2015
677

Hi Raymond,

Here are a few sections that I wasn't sure about:

1. "Scans for solar beacons (sensor 1 and sensor 2, as per the Major field) and, when found, displays the respective temperature and humidity values to the serial monitor." The structure of this sentence makes it susceptible to miscues. What do you think about this revision:

"Scans for solar beacons (sensor 1 and sensor 2, as per the Major field); if a beacon is found, this program displays the received temperature and humidity values via the serial monitor."

2. "Ideally, you always want to be scanning and the price you pay for this scheme is the possibility that you can miss a beacon advertisement." I'm not clear on why there is a risk of missing an advertisement if you are always scanning.

3. "Using a counter value equivalent to about 16 minutes as a default (i.e., missing three consecutive advertisements at the long interval rate), I would, on very rare occasions, see this occurring." I think it would help if we could clarify 1) how exactly 16 minutes is related to the long interval rate and 2) what "this" refers to.

@Kate Smith Once Part 1 (i.e., the companion technical article) is published, we should add a link to it at the top of this article, and also here: "(see Part 1 for making the sensor a hybrid)."

#### Kate Smith

Joined May 2, 2016
72
@RK37 Sounds like a plan!

#### Raymond Genovese

Joined Mar 5, 2016
1,658
Thanks for the review @RK37,

1. "Scans for solar beacons (sensor 1 and sensor 2, as per the Major field) and, when found, displays the respective temperature and humidity values to the serial monitor." The structure of this sentence makes it susceptible to miscues. What do you think about this revision:

"Scans for solar beacons (sensor 1 and sensor 2, as per the Major field); if a beacon is found, this program displays the received temperature and humidity values via the serial monitor."

That’s fine.

2. "Ideally, you always want to be scanning and the price you pay for this scheme is the possibility that you can miss a beacon advertisement." I'm not clear on why there is a risk of missing an advertisement if you are always scanning.

When you are NOT always scanning, there is a risk of missing the advertisement because it is a very short duration. As far as I can tell from the somewhat vague documentation for the HM-10/11, when you make a scan request, it scans for 3 seconds. That in itself is somewhat speculative because we don’t have the code that the HM-10/11 is using. But, when you add to that the additional 1 sec interval to deal with the serial transmission (as described in some detail in the text) you have a period of time when you are NOT scanning. Moreover, there is overhead involved in processing the results of a scan. That is the point that I wanted to communicate.

To be more explicit, I changed:

“Ideally, you always want to be scanning and the price you pay for this scheme is the possibility that you can miss a beacon advertisement."

To:

“Ideally, you always want to be scanning and the price you pay for this scheme, which includes some time in which you are not scanning, is the possibility that you can miss a beacon advertisement.”

3. "Using a counter value equivalent to about 16 minutes as a default (i.e., missing three consecutive advertisements at the long interval rate), I would, on very rare occasions, see this occurring." I think it would help if we could clarify 1) how exactly 16 minutes is related to the long interval rate and 2) what "this" refers to.

As per the existing text, the variable isstale contains a user-defined value representing the maximum number of scans without an advertisement before considering the last sensor value as stale.

Counts of the number of scans without an advertisement for each sensor are kept in the variables s1stale and s2stale. Each scans takes about 4 seconds. The isstale counter is initialized to 240. 240 X 4=960 seconds or 16 minutes. When either s1stale or s2stale hits the isstale limit, that sensor’s data are considered stale.

The code around the variable isstale contains the following comments:

Code:
// this is the number of scans without a sensor that will be marked
// as "stale" on the LCD with the capital S replaced by a small s
// each scan is 4 seconds (plus additional processing time)
// max = 255 * 4 = 1000 seconds or 17 minutes
const byte isstale=240;  // ~16 minutes
This is clear to me. But, I don’t think you are just yanking my chain here and if it is not clear to you it might not be clear to others. I just don’t know exactly how to make it clearer, but I have tried. I have modified the sentence:

Using a counter value equivalent to about 16 minutes as a default (i.e., missing three consecutive advertisements at the long interval rate), I would, on very rare occasions, see this occurring.

To:

Using a value for isstale equivalent to16 minutes as a default (i.e., representing missing three consecutive advertisements at the long interval rate which is 5.17 minutes), I would, on very rare occasions, see the occurrence of ‘stale’ data.

If you have some ideas to clarify this further, I am fine with that.

I also added the following text:

The calculation formula is: RH [%] = 125 × (HUMIDITY × 256) / 65536 – 6. As noted in the Si7020 data sheet PDF (see section 5.1.1) when conditions approach 100% or 0% humidity, it is possible to receive humidity values above 100% or below 0%, respectively, due to sensor variations in accuracy. The data sheet suggests that when this occurs, it is appropriate for the host software to limit the humidity range to 0-100%. No artificial limits are used, however, in the included software, although this could be easily added to the code.

Under Making a Beacon Weather-Resistant for Outdoor Use

Be forewarned, your results may be different, but at the time of this writing, mounted on a porch railing, it has performed well for about two months, including multi-day snow/sleet/rain/wind storms. It is notable that during times of prolonged high humidity levels, such as 3-4 consecutive rainy days, the polymer sensor film inside the sensor can become wet and produce inaccurately high humidity values. This is a known characteristic of the sensor (see sections 4.3 and 4.6 of the Si7020 data sheet PDF). It is recommended that a baking procedure be used but it is also noted that accurate values will return over time under less extreme humidity conditions. I have noticed this wetting to occur and, while I didn't specifically use the baking procedure, I simply took the sensor indoors and placed it near a strong light for a few hours and that seemed to work. I have also seen the humidity values appear to recover left alone after a day of drier conditions.

Last edited:

#### RK37

Joined Jun 26, 2015
677
Thanks for the feedback, Raymond. I like your revisions for #2 and #3, and I added in the proposed revision for #1. I also made a few other minor revisions, and now I'm going to move this article to Ready for Publication.

Overall are you impressed with the beacon's performance in the outdoor environment, or would you say that it is more or less doing what it should be able to do?

#### Raymond Genovese

Joined Mar 5, 2016
1,658
"Overall are you impressed with the beacon's performance in the outdoor environment, or would you say that it is more or less doing what it should be able to do?"

Overall, I am very impressed with them - especially in particular environments. As we discussed earlier, there are some documentation/explanation issues, but compared to what we regularly see, those issues are not in the top 10 of "guess what this component does"?

The lower power mode has, in my opinion, limited utility - 5.17 minutes is too long of an advertising interval and is longer than any other advertising interval with any other beacon that I am aware (although I am admittedly pretty new to BLE in general and beacons in particular). But, you don't have to use the lowest power mode - for the outdoor one I'm not using that mode and I used a battery that was 8 years old (but never used) and it is a 2025, not the higher capacity 2032 that costs all of \$1. It has been working for over 2 months and is working fine as I type. For the price, I don't see anything on the market that comes close to doing what they do and I know I couldn't build one as cheaply. I wish you could buy them on a per puck basis, but they are clearly just show-off kits rather than true development boards.

As far as the outdoor part. Yeah, I am basically satisfied and it hasn't been bricked so far. I have read about the saturation problems with several humidity sensors and they also seem to all have lower accuracy at the extremes. Also, I still get a chuckle out of looking at the holder - it looks like something that a 10 year-old might make But hey, it does work.

Last edited: