Thursday, December 28, 2017

Controlling X10 with Alexa

 I thought it would be fun to control the X10 modules in my house with an Echo Dot .

I am unapologetic about using this 1980's technology for much of my HA.  It's cheap and it works for me.

A quick search revealed that there is an Arduino library written by  Tinkerman that interfaces an ESP8266 to Alexa. (It mimics Belkin WeMo switches.)

Once you have the ESP8266 responding to Alexa, the world is your oyster!

Since I have already written the code to control the CM17A X10 module in Arduino, it was just a matter of combining the two functionalities.

In use, the chain of events is as follows ...
I tell Alexa, "turn tree on". Alexa sees a WeMo switch device named "tree". The Arduino sketch receives that event and calls the corresponding house and unit command for the CM17A. The CM17A transmits the code wirelessly to a TM751 transceiver (or the like) which puts the signal on the powerline. The signal is picked up by an X10 module which turns on the device.

Hardware-wise you need some kind of ESP8266 dev board, an optional I2C OLED display, a CM17A module (AKA X10 Firecracker),  an X10 wireless receiver, a lamp or appliance module. You also need a level shifter.

The level shifter is needed because the ESP8266 is a 3.3V device and the CM17A requires ~5V to operate. Also, since the CM17A is powered by the difference between RTS and DTR,  strong pullup resistors (330Ω) must also be used on the high side of these signals. Here's a rough diagram ...

I have the source code pretty much finalized for this project. If you are interested, you can download what I currently have here,


Thursday, March 2, 2017

MPPT Solar Charger - Introduction

Please note: This project is probably 90% completed. The remainder was giving me hell, but I'm back at it. Currently it should only be considered for reference but I be updating it soon. 

First off I want to acknowledge and thank "soldernerd" for the inspiration and education. His blog posts on his MPPT charger are nothing short of fantastic. They are one of the most thorough writeups I've seen for any project, and his hardware and software design are totally professional. If you are interested in any solar MPPT project you should go through his blog - which is here. In fact some of the below will assume that you are familiar with it.

So I have borrowed from his project heavily, but I have also adapted it to my own needs and skills. Here are the main differences . . .
  • The main processor is an ESP8266 rather than a PIC. Besides that fact that I'm not familiar with the PIC, the ESP8266 allows me to easily monitor the performance of the charger on IOT sites. It also has all the memory I'll need, and is programmed with the Arduino IDE.

    The main disadvantages of the ESP are that they are power hungry and have limited I/O. To address the power issue, the ESP will sleep through the night and will only control the buck circuit intermittently during the day. However, since the buck needs a continuous PWM signal to operate, the PWM is supplied by an ATtiny85. The only job of the ATtiny85 is to read it's analog input coming from the ESP and set the duty of the PWM it supplies.

    The lack of I/O is handled by two I2C chips that I use a lot - the PCF8574  GPIO, and the PCF8591 - DAC / ADC. Between them they provide 8 digital inputs or outputs, 3 analog inputs, and 1 analog output.
  • An MPPT charger needs to know the voltage of the solar panel and the battery. In addition, it's nice to know the current from the panel and to the battery. I originally used the INA219 modules available from Adafruit or the knockoffs available on eBay (example). It was handy having an I2C interface for voltage and current. However after smoking about 8 of these I went back to a simple voltage divider for voltage and the ACS711 for current. A nice breakout board for this chip is available at Pololu. It is a lot hardier than the INA219.
  • I think soldernerd may incorporate an RTC at some point, but for me it is essential. Since it's a connected device, I am able to set the time from the NTP server. This allows the ESP to calculate the times for sunrise and sunset so it can sleep accordingly.
  • I added a pot to manually control the PWM duty. This is handy for testing. When running, the duty is controlled in the software for the optimum performance. This is a good time to acknowledge and thank another MPPT project where that idea came from. Julian Ilett has created a series of 20 videos which walk you through his Arduino based MPPT project. It's really amazing to see the work he has put into the models he uses to explain it. The first video in the series is here.
  • I used an I2C OLED display (example) for the ESP as I'm familiar with it and it's pretty readable in sunlight. The display will normally be off and only on when a button is pressed.
  • Rather than put everything on one board, I already had boards for my "ESP Swiss Army Knife" that I used for my garden watering project. These boards have the ESP8266, OLED, RTC, and the GPIO and DAC / ADC on them. I made a separate MPPT board that fits under it to provide the buck converter and other goodies for the MPPT charger.  
There are other changes of course. Note that even with the big head start I got from soldernerd, I have a couple of months work into this project so far. This is not a project you can knock off in a short time. It's also very unforgiving! I was stuck burning out chips for quite awhile. It turned out I used a 'byte' instead of an 'int'!

OK, if you've read this far you are probably ready for some pictures!

First, here is the "ESP Swiss Army Knife" that I have already used in my watering project shown on top of the MPPT board ...
As mentioned this board supplies the ESP8266, OLED, RTC, and the GPIO and DAC / ADC. There are a few parts on this board that are not used for this project - namely the moisture sensor, MOSFET, and SD card.
You can also see a bit of the MPPT board at the bottom.

You can find the schematic and board layout for this board in this post.

Here is a photo of the Rev. B MPPT board.

Since I was burning out MOSFET drivers during development I have it mounted on a green carrier board temporarily. There are also 2 variations of the MIC4605 driver - one only for a synchronous buck, and one that can support asynchronous as well. I will likely only be able to use a synchronous buck due to not having the knowledge to do mirrored PWM on the ATtiny85.

The ATtiny85 is in the lower center. It simply reads the requested duty from the DAC output as analog in, and supplies the MOSFET driver the PWM at 122.5kHz. Note that the DAC supplies its analog signal even when the ESP is sleeping so the buck converter will still run.

Beyond that are are the MOSFETs for the buck and additionally; 2 more for aux power, one to disconnect the panel, one to disconnect the load, and one to control power to the buck converter.

The 2 ACS711 modules are on the left.

Here is is screenshot of the data set by the MPPT Charger to the Sparkfun IOT site ...

OK, you may be wanting to see schematics, board files, and source code. A word of warning. At this point I do not suggest trying to build off what I have here, and indeed, I am not ready to cooperate. When I'm further along this project will be open source, but lets wait for the goal post to quit moving. I may even have some PCBs available. Another warning is that a project like this will likely cost more than you can buy a pretty good MPPT charger for.

Having said that, here is the schematic and board view for Rev. B of the MPPT PCB.

I have not mentioned the software yet. That will be a separate post and this is just an intro.

If you have general questions at this point, it may be best to wait until I am further along. Specific questions, and observations are welcome at any point however.

Thursday, April 28, 2016

Solar Swiss Army Knife

Over the past month or so I built an  ESP-8266 based "Solar Swiss Army Knife".

It's primary purpose is to measure the soil moisture, and turn on a valve to water my garden when the soil is dry.

Since it's solar powered, the only connection needed is to the garden hose.

Soil moisture is detected by measuring the AC resistance across a probe stuck in the soil. An AC square wave is made with a 555 timer. Using AC eliminates the galvanic reaction a DC probe would have.

Watering is controlled by a pulse valve driven by an  H-bridge. A pulse valve uses no current when in the open or the closed position so it's perfect for a solar powered project.

A parameter file is read from a micro SD card and sets the watering parameters. Watering parameters include the soil moisture to trigger watering, minimum time watering, and watering hours. The file also provides the network credentials needed to connect to WiFi and the Sparkfun IOT site.

When the  device connects, it gets the time from the NTP server and sets the RTC. It then gets its readings and controls the valve if necessary. Finally, it sends watering and battery status to an IOT site where I can monitor its activity. You can see the data it sends here.

A MOSFET output is provided if I want to control something that needs high current.

A 2000 mAh LiPo is used. To save power, it sleeps for 4 minutes and wakes only to check if the soil needs water and send it's data.

In order to supply all the necessary I/Os, the board uses an I2C GPIO (PCF8574) for 8 additional I/O and I2C ADC/DAC (PCF8591) for 4 analog in and 1 analog out.

To make the build easier I used SMD components and off the shelf modules. The modules used are:
  • Adafruit solar charger - It's worth having a good solar charger. The solar cell is also from AdaFruit.
  • Pololu H-Bridge - Used to reverse polarity to turn pulse valve on and off.
  • LiPo Fuel Gauge - Measures battery voltage and state of charge (SOC). Knock-offs are also available on eBay.
  • Current Sensor - (eBay) Measures the current to and from the battery
  • SD card module - (eBay) 
  • RTC module - (eBay)  
  • Pulse Valve - (eBay) Garden hose in, drip watering system out.

Schematic of the board ...

Wiring diagram . . .

PCB board layout ...

I have some boards available for this project.If you're interested contact me.

Sunday, November 22, 2015

Network Control of X10 - take 2

I posted an earlier version of this, but it was based on the Atmega328 and an Ethernet module.

This version is based on the ESP8266 which provides the microprocessor and connection to the network via WiFi.

I've been having a ball with the ESP8266. It's cheap, programs with the Arduino IDE, and it just works. I've already created a product with it that connects my Geiger Kits to the internet.

So what is it?
The ESP8266 puts up a webpage (like the above) on your local network. The page has buttons for the X10 devices that you want to control. When a button is pressed the ESP8266 drives a CM17A and turns your device on or off. The page also displays any sensor readings that are connected to the ESP8266. So if you are into X10 home automation, this is a cool gadget.

Hardware-wise it's an ESP12 variant of the ESP8266. It's connected to the CM17A through a level shifter. The level shifter is needed because the ESP8266 is a 3.3V device and the CM17A requires 5V to operate. (Since the CM17A is powered by the difference between RTS and DTR strong pullup resistors must be used on the high side - 330Ω.)

You can also attach an I2C OLED display to the ESP8266 which will show the X10 commands that were received.

Here is the complete setup. I used the ESP8266 development board I created for the GK-WiFi kit (available here).

The software is finished (as far as I'm concerned) and is available here.

Friday, January 30, 2015

Life Clock - Redo

Add caption
I created the Life Clock in 2008. Originally it was a "3 board stack"  with one being ATmega, RTC, and EEPROM and another with the MAX7221 chips that the bicolored matrix plugs into.

I really liked how it came out, but I thought I'd update it and add some features.

During that process I discovered a great little bicolor matrix kit from Jollifactory which provides the led matrix and a driver board. It's well priced, and really simplifies construction.

The matrix kit is available on Tindie here and shown below. It's  especially nice that multiple matrices can be chained together to make a larger display. If you're interested in led matrix projects it's a good way to go.

I then made a new PCB to hold the ATmega, RTC, EEPROM, piezo and IR sensor. It stacks on one of the Jollifactory matrix boards and provides a complete Life Clock. More matrices can be added if desired. The PCB looks like this:

A kit is now available here and also on Tindie .

Below is a video showing the current LifeClock software on 1-3 Jollifactory matrices.

The new software supports from 1 to at least, 4 Jollifactory matrices. The original LedControl library was modified to use hardware SPI instead of shiftout. This much faster lib is necessary if multiple matrices are used. As shown in the video, the LifeClock now has the following features:
  • Displays the time, hourly chime, alarm, and auto DST set.
  • Plays Conway's Game of Life in 3 colors.
  • Shows the phase of the moon, days to next full moon, and name of full moon.
  • Displays the time of sunrise and sunset.
  • Displays reminders for birthdays, etc.
  • Time setting controlled by a NEC mini-remote.
  • Optionally, a GPS can be added to sync the time automatically.
  • Fonts, messages, and reminders stored in external EEPROM.
[7/1/15 update] A more affordable "mini" version of the Life Clock is now available here.  It uses smaller single color matrix displays .

Saturday, January 24, 2015

Network Control of X10

I really love remote control!
This project allows you to control your X10 devices from any web browser.

The Arduino is used as a web server which puts up a page with controls for House Code, Unit Code, and Command. 

The response is sent back to the Arduino which sends out the X10 commands wirelessly through the CM17A module.

So far it's just on my local network but it appears to be working pretty well.

Still a few things I'd like to change, but the current  Arduino source code is available here.

Wednesday, October 12, 2011

Solar Powered Wireless Radiation Monitor

Like the Geiger Kit in the previous post, this project is going to get too big to properly handle in a blog format.

So it's introduced here, but the function and build details are posted on this website.

Listening to what people want in the way of radiation detection, it appeared that there are 3 types of needs:
1.       a portable device that gives instant readings - the classic Geiger Counter
2.       a portable device that logs readings, and maybe location
3.       a stationary monitoring device that is always displaying, and logging readings

I think I’ve covered the first two with the GK-B5 and the GK-Plus Geiger kits. So this project is intended to cover the 3rd need - a stationary monitoring device.

[March 2017] Let's stop right here! Since this was written I have created severial new stationary monitoring kits based on the ESP8266. So they are WiFi rather than RF as described below. Radiation data can now be sent to severial IOT sites. One of the kits looks like this ...

 There is more information on these new "RadMon" kits here.
Sorry to interrupt - to continue ...

The idea is simple – a box outside with a Geiger counter and radio transceiver (solar powered as an option) talking wirelessly to a box inside with a display and an SD card.

the outside piece . . .

the outside piece outside . . .

the inside piece . . .

Again, you can find all the details on this website. However, I'd appreciate any comments you'd like to leave here.

Wednesday, March 23, 2011

Geiger Counter Kit - Part 3

Please visit this web site if you want to purchase or learn more about the Geiger kit I am offering. 

I'll leave the pics and video here, but you'll find all the details about the kit through the link above. However, you can leave a comment here if you like.

Geiger Kit PCB  . . .

The video gives a pretty good introduction to the GK-Plus

Monday, February 14, 2011

Accelerometer & Compass

No, it's not a B/W TV from the 50's. However Felix the Cat was one of the very first images transmitted to a TV screen.

I wanted to mess around with an accelerometer and this is what I came up with - before getting waylaid making Geiger Counter Kits.

From the beginning, I have to say that this was one of the most frustrating projects I've ever worked on. I consider myself a "completer" but several times, I had the desire to just dump the damn thing in a box, and say to hell with it. I'll try to spare the details of that side of the project.

I had a few goals in mind:
  • to learn about accelerometer and compass modules
  • to make a LiPo battery operated project
  • to use a graphic LCD and a menu system
  • and maybe make something I could put in my car
Lets start with the battery side of the thing. I wanted to be able to charge the LiPo, and I also wanted a constant 3.3V for Vcc and the Aref voltage. For the LiPo charger I used a MAX1555 wired per the datasheet.

Since the voltage on a LiPo can vary on both sides of 3.3V (3.0-3.7V), I decided I needed a "buck-boost regulating charge pump". (It's possible I didn't need one, but the name was so cool . . ..) I discovered the MAX1759 and also wired it per the datasheet. Soldering the tiny uMax package to a piece of proto board was an exercise in tedium.

I didn't want a toggle or slide power switch. I wanted a push button On/Off and I also wanted to Pololu Pushbutton Power Switch - it does all those things. I am working on a homemade version of this switch using an ATtiny85 that I will post here soon.  I added an ATmega328, with all pins broken out, and LCD and FTDI connectors.
automatically power it off from the uC if there was no movement for awhile. And of course, I didn't want to use much power to monitor the switch when the power was off. The solution was the

At last! A shield that actually looks like a shield! This round board fits over this square board. After cutting two notches in it to access the LCD and FTDI connectors it was actually fit for a Gladiator - at least until I added the HMC6352 compass (I2C), MMA7361 accelerometer (analog) and DS1621 temperature sensor (I2C).

Finally, the graphic LCD and joystick. After a few flaky Nokia cell phone faceplates, I got a less flaky version of the Nokia 5110 graphic LCD. For the joystick I used a neat trick I learned from nuelectronics that switches resistors with the joystick so the 5 positions can be sensed by only one analogue input.

A wise man once told me "a project is only as good as it's case". (Actually no one told me that.) Long ago, I made a faceplate out of copper clad PCB board. Why not a whole case? 3D soldering! I also had some vintage phenolic board and some copper foil. I cut the copper clad board and mitered the edges. I soldered the box up from the inside. It solders very well. (I cranked up the iron to 425C.) I used the copper foil to attach and solder the phenolic board on the bottom. In a lot of ways, the case was the most rewarding part of the project. If there's anything worth learning here, this technique might be it.

So that's the hardware side. I'm less proud of the software side. I discovered that coding for the accelerometer and compass quickly make you wish you didn't sleep on your desk during geometry. In addition there's the low pass filtering, running average and . . . the dreaded Kalman filter (actually I didn't use one). I'll post the code at the end here, but if your smart, you won't download it. The menu system is sorta nice though. I got the basis from nuelectronics. I also wrote some simple graphic utilities.

Functionally - well, it needs some work, but he's a rundown of the screens . . .

The main menu . . .
(The accelerometer screen is boring. So is Debug.) The calibrate screen calibrates the compass - 2 revolutions in 20sec.

The compass screen shows degrees and ordinals.
There is also a temperature display.

The performance screen shows acceleration (right of center) and deceleration (left of center.)
The line through the bar sticks at the max recorded.

The roll and pitch screen shows, you know what.

Here's the sketch.

Saturday, January 22, 2011

X10 Remote Temperature - Redo

I became interested in the ATtiny85 processor recently. Up till now, my projects were based on the ATmega328 or the ATmega644. The  ATtiny85 is just that, tiny - only 8 pins vs. 28 on the ATmega328. The photo on the left shows the new  X10 temperature transmitter, with the DS1621 temperature chip on the left and the ATtiny85 on the right.
(The CM17A X10 RF transmitter is not shown.)

This board replaces what I had in the original X10 Wireless Temperature Transmitter which I've been using for the past year and a half.  (post is here)

So why the redo? The rational part of the answer is that I wanted the batteries to last longer.

The original temperature transmitter drew a whopping 2.2mA while in sleep mode. It was powered by 2 NiMH AA batts stepped up to 5V with a boost inverter. I'd change the batteries every month or so.

The redo board draws about .07mA while in sleep mode. It's running directly on 4 NiMH AA batts.  I'm guessing I'll change the batteries every 1.5 years or so. I choose AA batts over a 3.7V LiPo because it's easier to replace the NiMH batts with fresh ones, and I wanted the higher voltage for better range on the X10 transmitter. However, it's worth noting that the processor draws less current at lower voltages.

Most of the power savings can not be attributed to using the ATtiny, however. Along the way, I discovered a few things.

The first had to do with how I was reading the temperature on the DS1621. I was using "continuous mode" (most examples use this mode) which would give me a reading as soon as I asked for it, but at the cost of almost 1mA! I switched to "one-shot" mode which makes me wait ~750ms for a reading, but at a huge savings.

The second thing I found is that the CM17A library I made left the RTS & DTR lines high after transmitting. Setting them low, results in about a .5mA savings. Note that if you are using this lib and want to try it, be sure to give a nice delay before transmitting after you set the lines high. (There's always a trade off!)

I always use sleep mode for the lowest power usage when not transmitting. It's set to transmit about once every 6 minutes. There are several sleep mode routines for the ATmega processors, but the ATtiny needs entirely different registers set. I found good info on sleep mode, and good tutorials for the ATtiny at and Inside Gadgets.

The way to do the things mentioned above will be much clearer when you look at the the example code, which will be provided later in this post. But now, I would like to describe how to go about using the Arduino environment to work with the ATtiny85 chip, and most of all, how to get I2C working on them so you can communicate with the DS1621, real time clocks, and even 2x16 displays - all with an 8 pin chip!

The first thing you must do is to get the ATtiny "core files" for the Arduino environment. There are several out there - each supporting more or less of the standard Arduino features. Core files, and instructions on how to get started with the Tiny85 can be found here, however, I prefer the core files from here.

You can use the ArduinoISP as a way of downloading the sketch into the ATtiny. I've used it and it works fine - just be sure to disable the automatic reboot after load! For me, an easy way to do that is to use a serial cable instead of the USB cable. However, there are other ways to do it. Keep in mind, you only need to hit reset when you load the ArduinoISP on to your Arduino. Once it's an ISP, change the Board type to ATTiny85, and just hit "Upload" (don't press "reset"). After you work with the ArduinoISP a while, I think you will want a real ISP Programmer to load the ATtiny. They are cheap and much easier!

Finally, get at least the TinyWireM "master" library for this project. I made a Playground article that explains this library and has a link to download it. The Playground article is here.

OK, almost done. To get the source code for the new X10 Remote Temperature Transmitter, you can download it here. (a new version as of 3/13/11)

 [1/18/15] You can get a schematic for this project here.

Saturday, October 16, 2010

Receiving X10 RF Transmissions (Updated 11/21/10)

For me, at least, this was the last piece of the open hardware X10 puzzle. In this blog you'll find open hardware projects that receive and transmit PLC (powerline) signals, as well as transmitting X10 RF signals (via the CM17A). Now sitting in front of me, is an off the shelf 315MHz receiver (detuned to 310Mhz), happily beeping away each time a warm body crosses an X10 motion detector.

The receiver is from Sparkfun, but any similar receiver should work. The key is to get one with a tuning slug as opposed to a crystal. The software that interfaces the receiver to the Arduino is from a suite of X10 libraries written by ThomasM. You can find the whole suite (PLC transmit & receive, RF receive, and IR receive) here. Having written an earlier version of PLC receive, I'd recommend his version for PLC receive and transmit as well.

So lets get started. Get a  315MHz receiver, wire it up per the data sheet, get Thomas's libraries and his example sketch, (or get the "test & calibrate" sketch I made here). Press a key on an X10 RF remote. It should work right away, but only at close range.

So the next step is to tune this receiver closer to 310MHz. You'll want to start by adding an antenna. This page gave me the following lengths (in inches) for a vertical wire antenna at 310MHz:

  • 1/4 wave - 9 1/16"
  • 1/2 wave - 18 1/8"
  • full wave - 36 1/4"
I started with 1/4 wave whip antenna, but the ultimate may be the "egg beater" antenna (Google for examples).

Now it's time to tune the receiver to 310Mhz. I don't have a scope, and I found that a sound card scope was of little help, since the signal is clipped to soundcard inputs, so I came up with two alternate methods.

The first method I tried was to simply connect the output (data pin) of the receiver to the Aux-in on my PC. You will hear a lot of noise! (This is due to the AGC built into the receiver.) However you will clearly hear the RF signal when you push a button on an X10 RF remote - as long as it's close and pointing at the antenna. Pointing the remote away from the antenna gave a fainter signal, and moving it further away made it even fainter. So with the faint signal, I simply turned the tuning slug until I got a clearer sound in the speakers when I pushed a button on the remote. Not very scientific, but it seemed to do the job. (I started by turning the slug CCW - this post said ~160° CCW.)

Later I used a different method which seemed to be more "real word". I made the "test & calibrate sketch" linked above. It simply beeps a piezo and outputs to serial whenever the receiver has a good read. Then I clamped a button down on an X10 RF Remote (HR12A) so it would continuously transmit,  and located it at varying distances from the receiver. While listening for the beeps, I adjusted the tuning slug for good reads at the furthest distance.

While using the second method, I also played around with antennas.  The 1/4 wave whip antenna really didn't seem to do much, and I couldn't pick up signals if the transmitter was outside my house. Then I tried a 36 1/4"  piece of twisted pair from a phone cable. One wire to the ANT pin on the receiver and the other to GND. This made a big difference, and the grounded lead contributed to the difference.

That's about where I am at this point. Interfaced to the example sketch I can receive RF signals from the motion sensors on my front and back doors. There's more about this in last half of this thread in the Arduino forum. [4-3-13] (There were changes to X10rf.h - here is the modified version I used.)

Not sure at this point where I want to go with this - perhaps a "whole house" X10 receiver with some other goodies, or some little dedicated device. We'll see.

Sunday, April 4, 2010

Geiger Counter - Part 2 (complete)

[Edit 4/10/11] This project is now available in kit form - with PCB and parts. Please click here for more information.

This post describes how I went about integrating the circuit described in the previous post with an Arduino and a LCD display.

I put it all into an old laptop power supply case - not my best work, but as we said in Arkansas, "it ain't no piano". It does have a nice sturdy feel though.

After experimenting with an LED bar graph and a Nokia 3310 cell phone display, I settled on a simple and cheap 8x2 LCD display from Sure Electronics.

First I moved the Geiger circuit off the breadboard and on to a proto board.
Add caption
I kept things fairly tight which left a little room for future expansion. The piezo is mounted on the bottom of the board. I cut an opening in the bottom of the case under the tube.

On the other side of the case, I added the batteries, display and a small board for the Arduino MCU. It's just a simple stand-alone Arduino circuit using a resonator.
There are also 2 slide switches on the bottom - one to turn off the piezo, and the other to turn off the Arduino and display to save batteries. A salvaged push button on top turns the whole thing on and off.

The code counts the interrupts from the tube for a period of time, and displays the counts / minute as a value on the 1st line and as a bar graph on the second. I adapted the code for the bar graph from DeFex . It's nice because it uses custom characters to make partial blocks.

I used two different counting periods - a longer period when the CPM is below 100 (counting background radiation) and a shorter period when there is more activity. You can download the code here.

Here is the obligatory short movie . . .

It was a nice surprise to find our bathroom tile was hot. (Should help kill the germs!) Since the house was built in the '20s, I imagine it's uranium green glaze.