Category: Programming

Categories
Programming

I got my Pebble, now let’s play

Just received my Pebble smartwatch yesterday, a bit more than a year after the Kickstarter campaign has ended. Its pitch is being a watch with e-paper display, Bluetooth communication with Android and iOS, a Cortex-M3 ARM processor, with the ability to run programs that change the watch look (“watchfaces”) or provide extra functionality (“watchapps” ).

I almost forgot about that I have supported it, until my friends on Facebook started to receive theirs, and I run into a person recently wearing one (the red coloured one, mine is gray and that was manufactured later). Even if I’m not really a wristwatch person – haven’t had one for years -, I like watches in general and clever new tech all is always welcome with me. (I wonder if any of these will be  in pocket watch form some day).

Pebble watch showing the time, 2:45
Pebble watch in action. Or just chilling and showing the time anyways.

Setting it up was pretty easy, the Pebble app on Android does pretty much everything. Setting up notifications for emails, Facebook messages, calls and SMS is one of the first thing. Until I get overwhelmed them and will turn them off, probably. The app also sets up such that when my phone downloads a file with the right extension (.pbw), it will automatically sent to the connected Pebble. The updates are pretty easy and quick too. I got a bunch of different watchfaces from My Pebble Faces, an unofficial repository that has much more than the official one. Maxed out around 10 or so, then had to use the app on my phone to remove some of them. Easy, though now really feel it all depends on the phone I use as well, the watch is mostly as clever as the accompanying phone app.

Fooled around with it a bit more, checking the alarms, the automatic Runkeeper integration (pretty neat, if only I could switch from “pace” display to “speed” for the watch), some small watchapps. In the case of watchfaces, I switched back to the original “Text Watch” face, which is pretty neat and unique for non-smart-watches. If only it could be modified to write things like “ten oh seven” for “10:07” instead of “ten seven”, it would feel more natural. There’s a watchface called Words o’Date that does that, except that it also adds the date, making the front look a bit too crowded for me. So keeping the original at the moment.

With this playing around I noticed one possible strength of the display, that almost everything can be animated, and that animation is pretty smooth. [Update: it’s actually e-paper, not e-ink, so my bad, the following comparison is not really valid Thanks for the comment.] From my limited experience with e-ink in the form of reading on my Kindle Touch, Pebble is really agile. Looking in the the Software Development Kit (SDK) documentation, there is a lot of functionality dedicated to animation.

After the whole day of usage I was thinking that when I was young(er), I would start hacking on interesting things right away, would have a lot of ideas, put in loads of effort, oftentimes stay up late to make something new to work. These days it’s less like that, even if I have much more toys lying around waiting to be hacked on. Around dinner time I decided that it cannot continue like that, so before going to sleep, will have my very on watchapp done.

Magic 8-Ball

Didn’t have many ideas, though, and haven’t looked yet too much, just wanted something simple. A Magic 8-Ball came up as a possibility: an app that gives you answers to your yes/no questions. It’s pretty easy in the core: a bunch of stock answers (20 in the original case), a random number generator to choose from them, and display it. Can do just bare text for the first time.

To set up my Linux box for the development, got the latest Pebblekit from Github, which is the SDK and examples and all the tools together. Unfortunately everything inside relies on “python” being Python 2.x, and on my ArchLinux this is not the case. The quickest workaround I found was to use Python’s virtualenv. I have also needed a different version of GCC that compiles for the Pebble’s ARM processor, the arm-none-eabi-gcc, fortunately in the ArchLinux User Repository (AUR). It just took a looooong time to compile. These two steps put me right into business and been able to compile the example watchapps and watchfaces.

I don’t remember much of my C skills (never had that much), that are mostly kept alive just by Arduino programming. Fortunately the Magic 8-Ball is simple enough program that looking at the examples, Stack Overflow, and Github, I could find all the pieces I needed (array of strings, random number generator in C, text display).

The Magic 8-Ball app is showing its result to my question: ask again later.
My first watchapp, the Magic 8-Ball

By around 1am I had a working version, and it’s totally fine. It’s even fun, even if very simple. People can get it directly from its page on My Pebble Faces, and apparently while I was writing this, 3 people already did, sweet!

In the future, I would like to keep up this creative hacking. For the Magic 8-Ball I could include some graphics, maybe neater transitions, make it less an “example” app and more an app. It’s really cool, that so many of the uploaded watchapps and watchfaces on My Pebble Faces also share their source code (50% of the 500 items, can filter for it in the search form), so I can learn from that. How much better Android apps would be if they’d do the same? My code is also on Github, naturally, in the magic8 repo.

For Pebble in general, communicating with the phone over Bluetooth can be very useful, if a useful Android app complements it. Smart clothing and accessories are just going to be more prevalent. There are already “next generation” smartwatches out there, like the Agent, that will be cool in a different way (I haven’t supported yet, they got 10x funding anyways).

Also, I think I should put some effort into compiling Libpebble for my laptop, that would make it possible to cut out the phone as a middleman and make things more future proof.

And as a first priority, I should be getting used to wearing a watch again, it’s been a while.

Categories
Computers Lab Programming

OSLO is a strange one

Experimental physicists have to be the jack-of-all-trades, even on a good day, but building a new laboratory, on a budget (for any definition of “budget”) and with a limited team, is an exercise that would test anyone.

For my field, atomic physics, one needs a lot of different expertise: vacuum systems, computers, electronics, machining, optics are among the ones first to my mind. Today I’m looking at one of the tools that we are using for the last topics: optics.

In some ways, optics is pretty straightforward (both geometrical and diffraction optics), many of the calculations one could write in Python/Numpy just as well, as any software can do it. They are just pretty tedious, and there are a lot of them, optics is not a new profession. Some optics design software is very useful then, and there are not that many of them, lots of work goes into the ones that exist, thus they can be extremely expensive. One of the industry standard seem to be Zemax, and many lens manufacturers provide the specs of their lenses in a Zemax format – though it is fortunately just a relatively simple text file. On the other hand, its cheapest edition is $2500, and goes up to $9500…

Another serious competitor is OSLO (Optics Software for Layout and Optimization) which is still very well known, and fortunately for us, has a dumbed down (limited number of surfaces, not all the functions available), EDU version, for free. It even runs on Linux with Wine.

I instinctively resist any software in science & research that is not free & open source, because I feel that it closes some people out, though had to use something, and in the meantime I have grown to OSLO quite a bit.

OSLO ray graph of an imaging system
One of our imaging system design

Using OSLO, I have found that one big advantage of these software is their catalog: the glasses (oh-very-important for optics) and stock optics of different companies. This alone makes everything much easier.

What does the lens designer software do? You enter the parameters of some lenses by defining different surfaces and materials & distances between those surfaces, give it some lightbeams, and see what comes out of it. Most of this happens in this window:

The window to enter the system parameters
Lens spreadsheet

After these settings, one can run a number of different analytics code, checking the performance and behaviour of the system by calculating a bunch of physics parameters, or can modify the system to optimize that performance one way or another.

This is where the number 1 strangeness – and big bonus – comes in: OSLO can be scripted in a language called Compiled Command Language (CCL), which is a subset of C; and not just scripted, but the whole program is written on top of the CCL compiler (as I understand)! The result of this is that:

  • Your scripting can be just as powerful as the entire program, since both sides have the same functions accessible
  • There are a bunch of scripts included in the main version and even if CCL itself feels poorly documented, there are plenty of examples to learn from
  • Once your script is compiled for OSLO, it can be totally part of the system, your own menuitems, options, defaults, everything
  • Scripting is not just bolted on later, but the whole software feels like a result of “eating your own dogfood“, resulting in a much better experience.

Optics design is tedious, so once I figured out how to do the scripting, everything just become nicer. Haven’t had time to do a lot of things, but the script I have so far is open source, and hope to add other things later.

From the programming point of view, there’s one more strangeness. Starts with that the output of numerical calculations looks like this:

Window showing numerical results of a lens' calculation
Looking at some numerical results

Those are all results from different functions, calculating spot sizes and wavefront distortions and what not, and those can be run from your own script – but the return variables are just printed. And they are a table. Those are table values that have to be accessed, so for example if I want to have the Strehl Ratio there, I would have to assign the value of something like “c1” to my internal variable – c for 3rd column, 1 for first row. Though to be this simple my code would have to clear the existing table before running the wavefront function correctly. This results in a lot of counting on the screen to see what row/column output of a function I want to actually use.

Internally, I think most of the calculations are following a finite number of rays. Finite but very high (~1000). The big problem, that could get the unsuspecting people (like I was), that what looks like a continuous calculation, is actually digital. For example if I set an aperture within the system that cuts into the incoming rays, and keep changing the aperture size (which is just a real number), the output results don’t really change unless I exclude or include some of the beams that OSLO is using for calculation – thus the result is changing in steps, and hard to trust. I guess there should be a setting somewhere to change the number of rays used, but still trying to find it.

It is one clever program though. The input and output parameters of a lightbeam are really connected by the system, since practically speaking, the optics are just transforming some parameters of the beam into other values, thus if I set the input parameters, the output is given. With OSLO they do this in a way, that the code just follows what parameters you have changed last time (input beam size? output image angles?…) and that will be a fixed variable, while everything else is adjusted. Some parameters disappear when others take certain values (set your object very far away? then we don’t have to let you set your object size, since it’s not important, instead give you a viewfield angle). It’s funky when I figured it out, but took a while…

I don’t know how much longer I’ll have to use it at work, but this looks something that really tickled my interest learning optical design much more, and once I have the hang of the quirks, it’s pretty neat. If anyone’s interested, there’s a pretty useful mailing list.

Now if only there was an open source solution… : )  (please drop me a line if there’s a good one)

Categories
Programming

The Gift of Code

I like advent calendars a lot. They can bring a lot of surprise, preparation, focus, and joy. They can come in many shapes and forms, and they encourage DIY – make your own calendar, count the things that are important.

This year, I got to play with a very interesting “advent calendar”, called 24PullRequests. It is the kind of thing that I don’t understand why people haven’t done it before. The mission: help out open source projects by submitting enhancements and fixes (i.e. “pull requests“), and do that for 24 days counting down to Christmas.

my 24 Pull Requests calendar
my 24 Pull Requests calendar

I had to take part in that one, and while the result wasn’t as successful as I wanted, it was so far my best contribution to open source.

My pull requests

Instead of 24, I managed to make 4 enhancements that were ready to be sent off. That’s not consoling me that it seems nobody managed 24, but never mind. Here are the things I made:

  • SmoothieCharts: make the charts use newer browser animation technologies that have better performance, and save on battery as well. This one was prepared somewhat earlier than December, but the final version was pushed within the right time frame. Being tested, not merged yet.
  • OpenHack: I’m organizing the event in Taipei, and noticed that some other place has broken image link. Hunted down the same pic from Google Cache, and set it up again.
  • Python Guide: added some info about installing certain Python packages in Arch Linux and Ubuntu. This is embarrassingly tiny fix, there’s so much more to do here
  • AngularJS: this is fixing that one couldn’t run the build script if the system Java can’t run in 32bit mode. I didn’t know that this was a Google project, until they sent me a request to sign some contributor agreement. I feel strangely humbled.

Lessons learned

Four contributions were already a lot of experience, because all of them were so different. Here are some lessons learned:

  • Write good pull requests – that starts with writing good commit message! People keep saying that, but seriously, no excuse not to do that.
  • When the changes have been sent in, don’t mind that they are not accepted yet. Every project have their own pace. Keep working on whatever you like
  • I was looking for ow hanging fruit, but one has to go in there still to make some meaningful contribution.
  • The issue tracker is a good start to see what to fix, but not always helpful, as it can be difficult to understand what propblem the others try to describe, if you are new to the project. On the other hand, try to use the code, I’m sure you’ll find some pain points right away (that was AngularJS). Also, the busiest issue trackers are not the best, they are full of things that would side-track you for a long time. Projects with a medium count are good for such an improve-and-run contribution.
  • Don’t be afraid to do things, but still do them the best you can. Your contribution doesn’t always feel meaningful, but still a little improvement is more than most people do. (just like PythonGuide was)
  • Keep things simple – easier to do, easier to pull. Even if sometimes that takes longer to write (the AngularJS contribution srunk to the quarter of its size while I was trying to figure out the simplest way to achieve what I wanted)
  • If interested, don’t worry if the project uses programming language you don’t know. You can pick up new things easier than it seems. Also, many projects give you feedback on your contribution, to help you improve it.
  • This project don’t encourage to work on your own stuff, but that doesn’t matter, there are another 11 months for that, or every day after these contributions are done
  • How to do this for the whole year? Bug squashing day in general? Still need to get deeper in projects, but go and explore. Can also see CodeTriage and ContribHub, linked from 24PullRequests
  • If stuck in the fixing, but the problem is interesting, don’t worry if it doesn’t fit in the 24 days. Keep working on it, the recipients will be happy any time (I have have 1 or 2 such patches)

Now let’s be a better coder in 2013.

Categories
Admin Lab Programming

Laboratory 2.0 – a monitoring system

Looks like that one of my specialty as a physicist, and contribution to the labs where I have worked so far, is bringing different kinds of programming techniques, and technologies to the table. I’m not saying I’m any better than many of the professors, post-docs, and students I’ve met so far (there are plenty of ingenious ones), it’s more like I experiment with different tools, have tried more of the cutting edge or recent technologies, did some web programming and could whip up something quick – that might not work very well at first, but does broaden the horizon for the rest of the people.

Also, I’m a lazy person, so want to automate as much as possible. That was on my mind recently when we have been preparing to do a vacuum-system bake-out. It’s essentially a procedure to have a delicate experimental system, mostly made up of steel, glass, and stuff like that, closed up from the atmosphere, all the air pumped out, then heated up to high temperature (~150-300°C). One has to be careful, because things can break, there are temperature limitations for some materials, also on how quickly that temperature can change, requiring careful monitoring of the status of the system. And the whole thing takes something like two weeks or more. Perfect setting for automation.

Set up the electronics

The pressure measurements are done by some expensive other equipment so didn’t have to bother with that one yet, so set to work first on the temperature monitoring. Before it was a bunch of thermocouples and multimeters, requiring manual intervention and lots of labour. Instead, got some inspiration from Adafruit’s Thermocouple Breakout Board, using the MAX31855 chip, and also from the Thermocouple Multiplexer Shield. It can handle only one channel, but can use some other chip together with it to switch between the different thermocouples, and so we can read it out one-by-one. The Adafruit board could only handle 1 channel, and the multiplexer shield was using an older chip for the measurement that I could not buy anymore. In the end, found a good analog multiplexer that one that is sold in the computer market here in Taipei, the CD4067B, and it works pretty well.

Breadboard setup for temperature monitoring Arduino
Breadboard setup for temperature monitoring with Arduino

Of course, setting it all up was quite a bit of fun times, as there were way too many gotchas along the way.

  • MAX31855 is a surface-mount component, and haven’t worked with it before. Not too bad, and can be much neater, just takes some plactice
  • MAX31855 is a 3.3V circuit, so the CMOS voltage levels used by my Arduino Mega ADK had to be level shifted
  • Unlike the older chip, MAX31855 really needs differential input, and it’s much more sensitive to the environment. This required different kind of analog multiplexer than that board had
  • The Arduino Mega is a new model for me, and had some strange behaviour in terms of the serial communication
  • Surprisingly there are not too many options for 3.3V voltage regulators over here, just the LM1117, which is different from what others are using elsewhere
  • Lots of noise and stability issues until figured out what should be how. For example under no circumstance should touch the thermocouple to conducting surfaces, and avoid ground loops
  • While MAX31855 says it’s “cold-point compensated”, meaning that it accounts for the chip-s local temperature when measuring the thermocouple, it doesn’t appear completely compensated, meaning that we can have unexpected measurement change because the chip is heating up for example by being in a closed box.
  • Figuring out the right amount of time to wait between switching channels (375ms seems to be good enough, 500ms is totally fine)
In the end, though, we did have a nice 16 channel thermocouple multiplexer, sending off the measurements onto an LCD screen and to the computer over an USB cable.
Temperature monitoring board soldered
Temperature monitoring board in it’s lab setting with 16 thermocouple channels

This is then saved in a database, and can be accessed from elsewhere.

Visualize!

The thing that my co-workers were most amazed by wasn’t the electronics. Sure, they haven’t worked with Arduinos, but did do similar stuff. Instead they liked the monitoring interface much more, this is the one on the picture right here (can click to enlarge)

Bakeout Monitor interface showing the vacuum system, temperatures, pressures and long term graphs
Bakeout Monitor interface (click image for full view)

It’s the schematic layout of our equipment, with the temperatures positioned where the actual sensors are. Also, the change of the measured values in time are also displayed with live scrolling.

I’m not saying it’s great. Thinking about it, the major insight that made it good for the rest of the people is that I realized how much more people understand visual data: the placement of the values to the corresponding locations on the schematics. That’s the only thing.

So inside it’s a MongoDB database (learned from previous mistakes, using a replica-set at least), with Python scripts talking to the sensors and saving the data, NodeJS / Smoothie Charts for visualization (and plain old CSS positioning of <input> tags for the reading display), nginx‘s upstream module for running two monitoring servers just in case. It’s mostly in the Github repo of the monitoring code, as well as the Arduino sketch for talking to the electronics.

It was actually quite fun to write it all, and the gradual improvements, trying the new tech, trying not to lose to much data, amazed how well it works. Especially had a good time learning about the database, scaling, fault tolerance, performance…

Of course there could be room for a lot more improvements.

  • My failover-restart bash scripts are awful, though they do seem to work more or less and counteract the USB unreliablilities
  • There were some changes to Smoothie Charts that I could improve on: logarithmic plotting, some display enhancements, wonder if it can be more optimized for performance
  • More efficient data loading. 12h data is about 30Mb in JSON format, that I send compressed, apparently it gets down to ~5% in size, but it still takes quite a bit of time to process on the frontend
  • The layout now can be changed from config files if the sensors change, so co-workers can do that without programming knowledge. I wonder if that can be simplified even more

Of course, I’m a person who generally overengineers stuff, so maybe it’s good to stop somewhere. And the somewhere might be when I got to the point to use my Kindle for monitoring (craps out on 1h data already, but some real time things are good enough).

Bakeout Monitor interface running on Kindle
Bakeout Monitor on running on Kindle 3, not perfect but does work

Get on with it

I did learn a lot along the way, and I’m sure that with this experience I will be let to do a little bit more in the lab in terms of programming ideas. I don’t like that the rest of the system is currently forced to be LabView, but that’s for another post, and there are so many things that can be improved in general as well. Let’s just go and do that.

Categories
Programming

Let’s talk about humidity

It is very much summer now here in Taiwan, and if one thing the Tropics is good at, then it’s being hot and humid. That’s sometimes fun, when there’s enough chance to hang out by a pool or on the seaside, but most of the time not that much. That’s why there are so many air conditioners, and other clima controls.

As I really like data, and this place is great for electronics, I thought I can just combine the two things, and try to learn more about my environment. Temperature is relatively easy, but for a long time I was looking for a humidity sensor. At the local electronics market I found a few different models the other day, and got one of them – pretty much the cheapest one, because all the manuals were in Chinese anyway (which I don’t yet read), and they were also all packed up, so there was not much peeking anyway. There was a combined temperature/humidity sensor board (two sensors already packed up together), but at 450NT it felt pricey and needed to buy some connectors for it as well. There was a larger round capacitive sensor, but it was too large for my liking.

I ended up with a “CM-R Resistive Humidity Sensor” (here’s an English spec scheet for it). It was 250NT (~5 quid or 8 bucks) which makes it relatively expensive equipment for me, though maybe because I was saving my cash in my wallet for going to Mobile Monday Taipei later that night. Still, if it works then it does worth it, and might get a few more pieces.

Wiring it up

I never actually knew how the electronic humidity sensors work, so this is a good primer for that.  Nevertheless, the plan was afoot to hook it up to an Arduino and measure some RH% (relative humidity). It was quite tricky for me to figure out the wiring, though, because I never worked with resistive element that could handle only AC voltage, and gets destroyed by DC.

That white rectangle with black spots, the humidity sensor at work, all plugged in with Arduino

Fortunately there were a couple of people (indeed just 2 or 3 that I could find) who were working with this, and had some good information. The one I went with was this post from the Arduino forums. Was quite informative, though I think the final formula is faulty – not because I understand it completely (my electronics theory is spotty at best) but because experimentally I figured out what works instead (being an experimental physicist, that’s pretty much what I do all day anyway).

Finally it is hooked up something like what is shown in this hideous schematics (really got to find some better way to draw this):

Humidity sensor schematics, done with Fritzing

After this wiring, I have to switch the digital output (DO) pin between High and Low at about 1kHz with 50% duty cycle. When the pin is on High value, every now and then I measure the voltage with the analog input pin. From the measured voltage I can deduce the resistance of the humidity sensor as

RH = R1 / ((Vref - Vm) / (Vin - Vm) - 1)

where Vref is the reference voltage (5V of the digital pin), Vin is the measured voltage, Vm is in this case Vref/2=2.5V, the voltage that the capacitors are charged to during all this switching, and R1 is the reference resistance. It works very well, I tried to measure some fixed resistances, and the results are pretty accurate.

When we have the resistance value, the spec sheet has a look-up table for translating the resistance into relative humidity (RH%). It’s quite cumbersome, because will have to interpolate between values, and it’s also not that accurate if the temperature is not known. On the other hand, the values from 25℃ can be used pretty well for all normal temperature ranges here in the summer (let’s say air conditioned 21℃ to outside summery 33℃) with maybe ±5% error in the humidity measurement, that’s not that bad.

The sensor itself feels really sensitive, just having it in the lab, could sense changes in RH as others were doing water-related things the next room. Even if reading is not that accurate, it is still quite precise, and for most of the things it is still okay. I could try in different environments, like our “dry box”, which maintains ~20% humidity, but that means quite high resistance of the sensor, MOhm instead of tens of kOhm, so the voltage reading just moving around near 5V, making it not that precise and noisy as well. For 30-90% humidity it works pretty well, though.

To monitor the readings, I wrote up a quick web-app from some reused code with NodeJS, Express, Socket.io, node-serialport2 and Flot. There’s no kill like overkill, but at least I can already monitor it from any other computer as well, it’s real-time, and the GUI is much easier to adapt than most other ways I know.

All the code for the Arduino and the monitoring server is in my Weatherstation repo on Github. It’s pretty buggy and not documented, will clean that up later when I’ll have a good working version.

Deployment

Now let’s get down to some real action. Being at home, I often feel that my flat is way too humid. Firing this circuit up, I got a reading of 80-85% relative humidity, that’s not something to sneeze at. Then turned on the air conditioning in dehumidifier mode, and watched what happened.

First there was an increase of the relative humidity, because the drop in temperature is quicker and the drop in water content. After chilling for a while, this is how it looked like.

Humidity logging while running the AC’s built in dehumidifier (RH% vs time in minutes)

Looks like some funky periodic behaviour, but empirically I felt much better, even if the humidity didn’t drop much. Maybe the extra comfort comes from the temperature drop as well, so will try to do the same thing in the usual temperature-control-only mode as well, see what does that one look like? I haven’t had neither my laptop battery charger, nor a spare battery with me, so I couldn’t run this too long, I wonder what level it would reach over a longer time. Looks like it has a downward slope, but it’s hard to tell.

Also, the wobbles are likely because of some feedback control that is turning the dehumidifier inside the AC on and off, and that controller has a huge hysteresis. It is not totally surprising, though: as much as I know, dehumidifiers are just big cold surfaces and the water condenses on them from the passing air. For that you have to keep a large surface pretty cold, and it is likely some time to cool a surface or let it warm back up again, thus the controller likely overshoots in both the de- and the re-humidifying parts of the process.

From what I have tried, it feels like a pretty good sensitive sensor, and coupled with

Plans

I’ve seen another way to wire up the sensor in a tutorial, which is basically a resonant circuit and the chance of the sensor’s resistance will change the output frequency. That frequency can be readily measured with Arduino already, so if I get the few extra components, might give it a try. It seems that potentially it can have better noise characteristics then the method I’m using.

Want to add some real logging function to it, maybe saving readings and timestamps into an SQLite database, which I can analyze properly later with Numpy. Or maybe store it in MongoDB, on which I can still interface and do some concurrent analytics even when the sensor is running. Or maybe I consider that just because I use Mongo for Friendcare?

Would like to add a 10-LED light bar, which could display the humidity decades without any computer, thus making the whole setup so much more portable. Though for that I will definitely have to revive a 74HC595 STP16C596 Serial-in/Parallel-out shift register, because then I’ll need one resistor and a single DO channel to control those LEDs, instead of 10 DO channels and 10 resistors.

Could also add an LCD screen like this SparkFun SerLCD. The only problem is that it interferes with the serial connection, so might not be able to use it together with the computer monitoring. Might worth it, though, that LCD I have (white-on-black with backlight) looks pretty darn funky.

Could also add some long-term monitoring and some other sensors, to build up a real home weather station. I have my eyes on a barometric pressure sensor, but that’s quite expensive.

Update (2012/11/6): 

  • Been using this in our laboratory for almost two months now, it works quite well, though still thinking of there’s any better way to measure the resistance of the sensor. Brushing up on RC circuits is in order?
  • Looks like I’m not the only one thinking about humidity sensors and data logging: there’s also another post from the awesome Tom Igoe.