Blog

In my previous post, I created a chart without axis labels. Such an action is a breach of Intergalactic Science Law, and I’m going to have to solve the problem of converting these values into real sensor readings eventually. So for my next task in this home sensor project/obsession, I set about to do exactly that. It should have been a fairly simple task. It was not.

Let’s explore. The temperature sensor is a fairly simple device which outputs a voltage proportional to the ambient temperature. The analog voltage output is fed directly to a microcontroller on the sensor node. The microcontroller performs a process of analog-to-digital conversion (ADC) and translates the voltage to an 8-bit binary number. That byte is shoved into a packet of other bytes and beamed via radio to the receiver, which is attached to my trusty Arduino. So, we wind up with decimal values like these, taken during the shower (the values “peaked” at the 5 minute mark, probably when I shut the water off).

So, the task of recovering the real sensor value involves translating those ADC output bytes into the original units of measurement being read; in this case, degrees Celsius.The math should just involve a couple of straightforward equations.

V_out = V_cc * (ADC_out / ADC_max)
T = 100 * V_out – 50

The value Vcc is a constant, the source voltage for the microcontroller: 5 Volts. ADCmax is 255, which is the largest number 8 bits can represent. The temperature equation came from the part datasheet (actually from the SparkFun comments, but I tested it myself to verify). Just to make things easier for my silly American brain, I’ll also convert the temperature into degrees Fahrenheit. Man, one of these days I need to learn LaTeX.

T_f = (9/5) * T_c + 32

Okay, so what do we have here?

Oh bother. I don’t carry the blood of the dragon, so those temperatures would have killed me almost instantly. No, I believe something might be wrong with my assumptions. I checked the transmitter, and it looks like the voltage regulator is working; I see 5V everywhere it needs to be. And remember when I said I tested the temperature equation? I double checked by reading the sensor directly: it read 0.7V, which is 20^oC, or 68^oF, exactly room temperature according to my thermostat. While checking this, the transmitter kept sending “92” to the Arduino.

During the soldering process, I kept having the nagging feeling that I put some parts in the wrong place. That mostly because the instructions at one point simply directly me to solder down the “blue” capacitors in a specific spot, when I had two different sizes of blue capacitors in the damn kit. So now, I have the sinking feeling that my coin flip came up tails. The good folks at the WickedDevice Q/A thought I also might have a low battery. That isn’t the case, but I appreciated a vendor giving my such a timely response.

Now I’m waiting for my order of three new nodes to arrive. If I don’t bungle the assembly, I can get some real readings, and put together a network with multiple transmitters. I was hoping to work on those two goals one at a time. Que sera sera.

It felt good to have a soldering iron back in my hand. Felt right. I’m in the process of channeling a new obsession into an old hobby. The latter is electronics design. The former is home maintenance and environmental awareness.

When we first moved in, it became apparent we had a minor microbial problem. It turns out that mold likes two things: moisture and warmth. We were also beset by a series of issues with the forced hot air system. Furnace cleanliness, closed ducts, and (as by brother was keen to point out) an open window were all contributing to a serious temperature difference between upstairs and downstairs.

So, I started thinking about ways to quantify these problems and more actively monitor my surroundings. I cooked up a nifty microcontroller project. Have an Arduino receive sensor information from a series of wireless nodes scattered throughout the house. The nodes would be equipped with temperature and humidity sensors. I wound up buying a Wicked Device transmitter node/receiver shield pair from MakerSHED.  The kits come as an empty board and loose components.  A little solder work, and we’re ready to write some code.

There are two software components required immediately: the microcontroller code to manage receiving the wireless data and forwarding it out through USB, and a daemon running on a PC to intercept and log it.

As a test run, I left one in the bathroom while (and after) I took a hot shower. I didn’t timestamp the data, but the node transmitted a packet every ten seconds. Some packets seem to get dropped, but that should give a rough idea about time elapsed. I’m also just too lazy to convert the data into actual degrees or percentages, thus no labels on the axes. This is all relative.  Statistics faux pas, I know.

I left the fan running and the door closed during and after. The point where the shower ended is pretty obvious, but I’m rather surprised at how long it took for the conditions to get back to normal. Towards the end, I opened the door, causing the quick equalization at the tail of the graph.

Eventually I may push the results into a database and add more sensor nodes. Maybe even a web frontend to view the house’s current conditions in a visual manner, or graphically inspect logs.  Of course, that will require more soldering.  Bring it on.

The debate among gamers between analog control sticks and the classic mouse/keyboard conversation has been raging for decades. I’ve been kicking around the ideas behind this post for a while, and my recent foray into Mechwarrior Online has rekindled my interest in putting this idea out there. Let’s look at the mathematics of the these control systems as a means of addressing their relative pros and cons.

The mouse is a simple rodent. It controls the cursor position, directly. Moving the mouse ‘x’ distance will result in a proportional cursor displacement.

Let’s take a look at how moving the mouse back and forth over one dimension translates to cursor movement over time.

Pretty simple triangular wave.

Now let’s look at analog sticks, or joysticks. Joysticks are a bit more complicated. In most applications, the joystick doesn’t directly control position. It controls the derivative of position (in other words, cursor speed). Move the joystick a little, and the cursor moves slowly. Push it farther, and the cursor moves faster.

Let’s do the same graph as above, where a user is moving the joystick back and forth from its resting position. Note that this is all hand-waving and not mathematically precise (or even properly scaled).

Note the curvature of the cursor position. Because we’re only controlling the derivative, the actual position will be a continuous function. Therein lies the primary difference between a mouse and a joystick: a cursor driven by a mouse can be move in a discontinuous fashion (think jagged edges), but a cursor driven by a joystick will always need to form smooth curves.

Truth be told, this paints analog sticks in a pretty grim light. But we’re making a couple of assumptions that might not be true for all games:

1. that the joystick always controls the derivative of cursor position
2. that the mouse movement is directly mapped and not limited.

There are mechanics available which can turn both assumptions on their heads and level the playing field a bit. We’re also leaving out a critical portion of the mouse-and-keyboard setup: the keyboard. We’ll look at both of these factors in the next post.