Steven's Logbook

It’s freezing outside. Literally, there’s literally a blizzard, and Boston is shut down. Appropriately, I made a thermometer last week.

67°F in a blizzard? Actually, it’s a thermometer for my room. It consists of an array of LM335Z temperature sensors that I’ve distributed around my room. Each sensor has wires leading back to my Arduino, and the Arduino is connected to a USB port on my desktop.

The third pin of the LM335Z is for calibration, but I’m instead doing calibration in software.

Wires come from sensors to a perfboard to the ‘duino, which sits atop the molding in my room.

I used Python to talk to the Arduino over serial. Then, I created a module for reading the temperature from a sensor on a pin on the ‘duino. I created a temperature object for storing temperature values in a way easy to convert between absolute temperature in Kelvin and temperature in degrees Fahrenheit as well as other representations.

In the sensor-reading module, I also included a method for calibrating each sensor with a list of known values. Then, when the sensor is called to give a reading, the method makes a linear regression of the calibration values and uses the regression to correct the new reading. I used the numPy module to implement a least squares linear regression. I also used the pickle module to serialize these calibration points and save them to a backup to avoid re-calibrating between program restarts.

It doesn’t feel like 77 in here…

To gather calibration points, I’ve been leaving a digital thermometer by each sensor and regularly submitting readings from that thermometer to my program using the user inputs at the bottom of the screenshot at the top of the post. In the window, the first input is a menu to select a sensor by location; the second is a box to type in the true temperature; and the third is a button that takes the true temperature along with the current reading from the selected sensor and saves them to the list of calibration points for that sensor.

I’m concerned that my off-the-shelf digital thermometer is not very accurate, so I’m going to borrow a better thermometer soon, but I also hope to remove some precision error by data averaging. Also, I suspect a linear regression may not be ideal for calibration–as you can seem below, a quadratic regression fits much better, for example.

Several calibration data points for a sensor produced this graph, overlaid with a linear regression (red) and a quadratic regression (green).

At the top level, I’m averaging the readings from all the sensors and displaying them in a UI that I made with the tkinter module. I mentioned the calibration button earlier; the large number above it is the average temperature from the sensor. For now, I’m also printing the reading off every sensor to a terminal. In the future, I plan to display a weighted average of the temperature based on places I’m likely to be–weighting my desk and bed heavily, for example. Better yet, weight the reading dynamically based on where I currently am in my room or where I am likely to be in the near future. I also plan to add more sensors.

The radiator temperature seems incredibly low for a radiator because my radiator was turned off and is adjacent to the window, which is very cold.

One thing that surprises me is how fast these sensors respond to changes in temperature. The temperature read off one instantly changes a few degrees upon touching it with a finger. Yet, when untouched, they don’t vary by more than half a degree for several minutes.

Next, I want to make a controller for my radiator and add it to the system. I’ll also update you on the MASLab robot I worked on last month. Also, I started using github, which is nice.

If you walk into my room, you might see an interesting interface on my desktop:

I’m referencing the clock and the mixer, not Unity :p

These are two tools I made freshman year: a unique clock and an audio mixer. They run on my desktop, an old HP computer that I got off reuse. I made the clock first, so I’ll describe it first and save the mixer for a later post.

Background

Laypeople count “1, 2, 3, …”; programmers count “0, 1, 2, 3, …”. However timekeepers must be really terrible at counting because, for each am or pm period, they count “12, 1, 2, 3, …”! A couple standards for time exist around MIT, whose students often require timekeeping that is unambiguous even during the night hours.

Take for example Random Standard Time (RST), created to accommodate the waking hours of residents of Random Hall. In RST, each day starts at 6:00 and ends at 30:00. 6:00 RST aligns with 6:00am of that day while 30:00 is actually 6:00am the next morning. This way, residents can avoid the inconvenience of day changes at midnight.

Another example is the practice of adding a delay to events around midnight to avoid the confusion of day changes. Suppose, for example, I have a pset due 9am Wednesday. If I want to tool with my friends 7 hours before the pset is due, it is ambiguous what day to tell my friends to join me. To employ the delay strategy, I would say to meet 11:59 Tuesday night, which falls unambiguously under a certain 24 hour period. Then, I would add that we should be 2 hours late, thus meeting at the desired time. One alternative phrasing, meeting at “2AM Tuesday night”, sounds a lot like meeting at “2AM Tuesday”, which would allow far too little punting!

Because hackers are notoriously late, a 15 minute delay is sometimes called “Hacker Standard Time”, so the phrase “HST” can be implemented when using the delay strategy described above to concisely remove ambiguity for events around midnight.

Beyond these standards, there’s lots of cool ways to count time. One more practice listed in the Wikipedia article is to continue counting past 23:59 to express nighttime am hours as 24:00, 25:00, 26:00, etc, and this is the basis for my clock.

Besides timekeeping, RST also implies a system of datekeeping in which every day is still 24 hours but each day is shifted. However, the following rule is my favorite system for datekeeping: it is considered a new day if at least two of the following happen; otherwise, it’s still night of the previous day.

• You eat breakfast.
• The sun rises.
• You wake up.

This system is great because, even if you pull an all-nighter, you are still guaranteed a new day as long as you eat something that you consider breakfast, and there is a new sun in the sky. Conversely, maybe you slept all afternoon, woke up at 11:00pm, and you’d like it to be tomorrow already so you can start feeling productive. Simply chug some cereal and you’re golden.

Implementation

Regardless of how you keep dates or time, I wanted to have some fun making a unique clock for my room, and I wanted to practice some of the Python I had been learning in classes like IAP’s 6.S189, so I made this clock. I used the tkinter and time modules for the first time. I also tried Python 3 instead of Python 2, which we used in class. The font is Digital-7, which is free for personal use. I made the font large enough that I could read it from bed without glasses, which is more than I can say for my cell phone or alarm clock.

Example shot at 2:51pm

For my clock, the time starts synced with normal time when I wake up. Rather than am or pm, the clock runs from 0:00 to 23:59. Then, at midnight, it keeps counting up through 24:00, 25:00, etc until I press a button to tell it that I’m going to sleep. When I wake up, I press a button to tell it, and the clock re-syncs with standard time.

Example shot late in the night of 30 December; you can see in the top left that it’s actually 1:07am on 31 December

To do this, the program toggles a Boolean at midnight to indicate that the time is extended from the previous day. The “Going to sleep” button seen above disables this toggle, so the clock rolls over to 0:00 at midnight. A “Waking up” button, which appears in place of the “Going to sleep button” re-enables the toggle for the next night. The “Override” button seen above manually toggles the variable, and the “Close Clock” button closes the clock.

The “going to sleep” changes to a “waking up” button after being pressed

For my curiosity, I’d also like to implement a program that keeps a log of when I sleep. However, the interface for this would probably be more convenient on a phone or some device that I carry with me regardless of where I sleep, so a program on my desktop is not convenient. I plan to link this my clock to reset it remotely.

P.S. even if you’re away from your dorm room for winter break, you can still apparently ssh into your desktop and take screenshots: xwd -out screenshot.xwd -root -display :0.0