40: C++ map() function vs. the HIH-4030 Humidity Sensor
-- revised 5/22/2016 --
-- re-revised5/25/2016 --

So I got my expensive HIH sensor (explained in post 39).

tiny, isn't it

According to Honeywell's graph there is a straight line relationship between voltage output (at 5v, 20C) and relative humidity. I.e., 0.8v = 0% to 3.75v = 100%.

So I wrote this Arduino sketch:
=============
#define spr(x) Serial.print(x)   // because I'm a slow typist
#define spl(x) Serial.println(x) //      " "

void setup() {
  pinMode(A1, INPUT);
  Serial.begin(9600);
  delay(5000);
  spl("HIH-4030");
}

void loop() {
  int r = analogRead(A1);
  spr("raw: ");spr(r);
  float v = r * (5.0 / 1023.0);
  spr(", V: ");spr(v); 
  float rh = map(v, 0.8,3.75, 0.01,100.0);
  spr(", rh%: ");spl(rh);
  delay(5000);
} 
============
This produced the following output (from Mac Coolterm):
============
raw: 297, V: 1.45, rh%: 33.00
raw: 305, V: 1.49, rh%: 33.00
raw: 289, V: 1.41, rh%: 33.00
raw: 224, V: 1.09, rh%: 33.00
raw: 651, V: 3.18, rh%: 100.00 *
raw: 526, V: 2.57, rh%: 66.00
raw: 367, V: 1.79, rh%: 33.00
raw: 322, V: 1.57, rh%: 33.00
raw: 291, V: 1.42, rh%: 33.00
raw: 278, V: 1.36, rh%: 33.00
============ * I breathed on the sensor
The "33", "66", etc.  made me suspect that while the C++ map() function happily accepts float arguments, it treats them as integers. So I wrote my own float version:
============
#define spr(x) Serial.print(x)
#define spl(x) Serial.println(x)

float mapf(float value, float istart, float istop, float ostart, float ostop) {
    return ostart + (ostop - ostart) * ((value - istart) / (istop - istart));
}
void setup() {
  pinMode(A1, INPUT);
  Serial.begin(9600);
  delay(5000);
  spl("HIH-4030");
}

void loop() {
  int r = analogRead(A1);
  spr("raw: ");spr(r);
  float v = r * (5.0 / 1023.0);
  spr(", V: ");spr(v); 
  float rh = mapf(v, 0.8,3.75, 0.0,100.0);
  spr(", rh%: ");spl(int(rh));
  delay(5000);
}
============
Here's the "mapf()" output:
============
raw: 295, V: 1.44, rh%: 25
raw: 294, V: 1.44, rh%: 24
raw: 293, V: 1.43, rh%: 24
raw: 318, V: 1.55, rh%: 29
raw: 449, V: 2.19, rh%: 52 *
raw: 378, V: 1.85, rh%: 39
raw: 306, V: 1.50, rh%: 27
raw: 293, V: 1.43, rh%: 24
raw: 291, V: 1.42, rh%: 24
============ * hot breath, again
Nasty! I wonder whether the provided map() code protects against divide-by-zero? It could happen.

Now I just have to worry about why my HIH-4030 values are screwy -- readings around my house are in the 40s, at the moment.

Later: Then I moved the program to the Particle Photon. The only source change was for the 12-bit analog return (4095 instead of 1023). The Particle C++ map() function bug ("feature") was the same. But, for some reason the results were correct!
============ code:
#define spr(x) Serial.print(x)
#define spl(x) Serial.println(x)
// sensor to Photon: 5v to Vin, 0v to A1, GND to GND

float mapf(float value, float istart, float istop, float ostart, float ostop) {
    return ostart + (ostop-ostart) * ((value-istart) / (istop-istart));
}

void setup() {
  pinMode(A1, INPUT);
  Serial.begin(9600);
  delay(5000);
  spl("HIH-4030");
}

void loop() {
  int r = analogRead(A1);
  spr("raw: ");spr(r);
  float v = r * (5.0 / 4095.0);
  spr(", V: ");spr(v); 
  float rh = mapf(v, 0.8,3.75, 0.0,100.0);
  spr(", rh%: ");spl(int(rh));
  delay(5000);
}
============ ok results?
rawh: 1674, V: 2.04, rh%: 42
rawh: 1576, V: 1.92, rh%: 38
rawh: 1607, V: 1.96, rh%: 39
rawh: 1562, V: 1.91, rh%: 37
============
Finally, about the HIH readings: they vary a lot between samples so my latest code reports a weighted running average -- 3 previous readings and the latest one doubled.

Revision: I soldered the tiny board to wires -- trying to keep from frying it in the process. I found new software on Github. Now the Arduino is right (seemingly) and the Photon is too high*. The HIH-4030 is a pain. The mounting board should be bigger just to protect the sensor part.

* Because the Photon analog pins are only rated for 3.3v. It's in their Docs -- but not obvious. Forget my code. Use the more accurate code from github.

39: Problems with DHT22 Temperature/Humidity Sensors

For the past month or so I've tried DHT22s in my granddaughter's hoop house. With them I can provide her with useful humidity and dew point data. As I've mentioned in an earlier post, the hoop house is a rather hostile environment for electronics. If the spring sun is out, the temperature/humidity mid-day can be 90F/25% and at 2AM 40F/99% (dew point 40F). I've tried three different DHT22s and they have all failed after a few nights of 99% humidity. For my latest attempt I housed the DHT inside 16oz water bottle (bottom cut off, sealed at the top). It lasted 2 nights. BTW: they recover after a couple days away from the hoop.

Now I've ordered an HIH-4030, humidity-only sensor (much more expensive). I'll pair it with a cheap TMP36 (cheap & reliable). Unlike the DHT22, the HIH provides a simple analog output.  I won't have to use a mysterious software library -- but I'll have to run 2 sets of wires instead of 1.

Anyone have similar problems?

38: Particle Electron -- Bah, Humbug.

-- see post 36 --

After waiting months, breaking the first one and wasting 30 hours trying to get the 2nd one to work reliably, I've given up on the Electron. It seems clear to me that a cheap cell modem & cheap month-to-month service connected to Particle Photons is cheaper and much more reliable. Too bad I didn't figure that out before I blew $150 plus hours of effort!

38: Search for the Perfect Connector

Here's some recent purchases:

The white spring clips are cheap, easy to use, fairly secure, not waterproof. I've had some of the 2-wire type for a year. They are useful while you are messing around. Generally better than alligator clips.

The lower set are pretty much the opposite: secure, waterproof and not cheap. And once you snap one of these suckers together it's work getting them apart. But really waterproof. Also, they could use a screw-down hole like the white clips.

The search goes on...

37: Raising an "Exception" in a Particle Photon or Electron

Let's say that that you have a remote Photon that is monitoring a temperature sensor and it reads a value that is out of range (too hot, too cold, whatever). I have a Raspberry Pi Linux system (could be any other Unix or Linux computer) that needs to be notified. One way would be for the Linux system to "ask" (i.e., "poll") the Photon every few minutes for the current temperature value and then to test for out of range for itself. A plausible action would be to send a text message to a (hopefully) responsible human.

A better procedure would be for the Photon to decide what is out of range and to send an alert message directly to the Linux on its own. The Particle programming interface offers a neat way to do this between that Photon and another Particle device. The sending device "publishes" a uniquely named message (up to the "cloud") and the receiving device can "subscribe" to it. Note that Particle has gone and gotten metaphorical on us: overloading the words "publish" and "subscribe" with new specialized meanings.

This is good for Particle Photons or Electrons but the interface to a Linux doesn't seem so straightforward. Linux/Unix systems like to receive this kind of message by reading a named device. So, until Particle provides such an interface, the simple solution is to publish/subscribe between 2 Particle devices and have the receiving computer pass the data on through the USB cable. In Linux shell this statement could record the message;

$ my-pgm </dev/ttyACM0 # program "hangs" waiting for data

Note that the single subscribing device could be used to receive messages from several publishing devices. And these could be either Photons or Electrons. The Photon receiver would cost a negligible $20.

36: Early Experiences with the Particle Electron
-- Revised 4/16/2016 --

See https://docs.particle.io/guide/getting-started/intro/electron/ for a full description. But, briefly, the Electron communicates with the cloud via cell service instead of wifi & your Internet connection. Also, it's costs more than the $19 Photon ($80 for the developer setup). In addition, you need to have cell service -- starting at $2.99/mo (initial 1MB).

I hadn't bought in to the Kickstarter campaign so I waited a while for my first unit. See post 32. In a single day I managed to break it twice: first I mangled the tiny brass antenna socket (but I repaired it with the help of a strong magnifying glass). Next, I broke the USB plug off the board -- I was moving the Electron around trying to get it to connect to cell service & pulled too hard on the cord (Warning: not very hard). BTW: Particle did not give me a replacement.

Irksome. But I thought I still needed the cell-connection feature. So I ordered another one. Quick delivery. I'd learned a couple lessons (you can, too): I was patient and got the antenna connected at the cost of only 15 minutes of teeth-gnashing. Then I taped the whole setup to a board and used a USB extension cord so I never have to plug/unplug directly to the Electron's socket.

Programming is nearly the same as the Photon (there are some Electron-only cell service functions). But here's a few differences: I have pretty reliable AT&T cell service (2 or 3 of 5 bars on my phone). But while a Photon connects to my wifi in a couple seconds the Electron can take 1 to 5 minutes (thats what led me to break my unit #1). Also, it appears to me that orientation of the provided antenna matters. When the antenna is lying flat (edge on to the signal) connection is less reliable than if the upright (flat on to the signal). I've written a C++ program to test this & I'll post the results.

REVISION/ADDITION
I haven't had a lot of joy with the Electron. The place I was going to install a few appears to have good FreedomPop cell modem service. Current price is: Modem $0, 1 GB LTE data/month $15. Particle Photons are $19 (plus cell modem), Electrons $69.

My test program was no fun. I wasted most of my month's data just trying to download versions of the code (download often failed but data was used, anyway). Downloading via USB seldom worked.

Also: I sometimes get the blinking red light "hard fault" signal. Hard fault is not explained. Lately I've had a LED signal not described in the online Docs. The usual sequence when you power up a Particle device is--

1. blinking green (looking for signal)
2. blinking blue (signal found, working on logging in, etc. -- this reminds me of dogs sniffing each other's butts)
3. breathing cyan (you are in!)

-- but in my case it's solid cyan (not useable).

35: My Arduino Nanos

I currently have 4 fully working Nanos. I recently installed one in a real-life situation for one of my granddaughter-farmers. At the time this left me with only one that I could download new code to. So I ordered 2 more cheap ones ($7 and change each). When they arrived they seemed to be working but the Coolterm app on my Mac couldn't detect their USB ports. I tried downloading a new driver and when that didn't work I send them back (too much trouble for the price). Unfortunately, I'd done the cheap Nano bit before ($3 each that time). Those 2 also didn't play nice. When will I learn? I now have a price point that maybe helps. I replaced the latest non-working pair with 2 from Sainsmart (via Amazon) for $12-ish each. They work fine.

I also have a Nano that Coolterm "sees" but which fails half way through downloading code from the Arduino app. So, essentially broken. And, I have literally burned 2 out through wiring mistakes. Best not to reverse connecting to VIN and GND (right next to each other, 2.5mm apart).

So, I bought 10 Nanos & have 3 working. You could probably do better.