Categories
Uncategorized

Bad Date Data

Bad Dates

And people wonder why I complain so much about date formatting… (See Also: raster’s rants on 4-digit years.)

Take this example from Nikon’s web site, captured lovingly in the screen shot above.

If you’re in a hurry, and don’t have time to read everything (I hear that covers 75% of the people who use the Internet) you might need info on the D4 and see that it’s at the top of the list, and hey… looks like it was updated December 4, 2010! At least that may be your assumption by seeing 12/04/10.

You also need info on the D40, and you see 08/04/04 and think “Wow, it was last updated in 2004!” which is weird, because the D40 didn’t come out until 2006. (And yeah, the D4 wasn’t around in 2010 either.)

If you scan the whole column, you’ll see that first part of the date is the year, followed by the month, and then the day. While I do prefer year, month, day, I definitely prefer YYYY-MM-DD.

This isn’t 1975, you’re not saving vast amounts of computer memory by typing “08” instead of “2008” and all your really doing is creating opportunities for people to get confused.

Yes, I know people should actually read things in a critical fashion especially if it has to do with an SDK for hardware, but this is just one example of many.

Categories
Uncategorized

More Tracking (Please!)

Boston

Remember last year when I wrote about how your iPhone tracks your location? (Sort of.) Some people find this stuff creepy, but I’m a fan of geo-tracking, and I want more of this data. It’s part of the reason I use things like Foursquare and Google Latitude. A fellow Milwaukee Makerspace member is even working on a device to seamlessly let your office mates know which office you are in. (See Marco.)

Last 30 Days
Last 30 days of tracking, via Google Latitude

The fact that Google Latitude only shows the last 30 days is (to me) a bug, not a feature, and it means that if I want to save that data, I probably need to dig into the API and write my own code to do it. I wrote some code to grab and save all my Foursquare data, and it worked great until they deprecated the API. I haven’t upgrade my code to use new API because it’s an OAuthMess, which I haven’t wanted to deal with yet.

Delete!
A sad list of choices for hardcore geo-nerds

I understand that many (most?) people don’t want this data public, or shared, or kept, or all of those things. I mean, look at the options: Show timestamps, Export to KML, Delete history from this time period, Delete all history. Half of your choices involve deleting data.

When I look at some of the mapping crazy-geo stuff that Aaron has done… I’m floored by it, and I want to see more of that, not less. Again, it’s not for everyone, but for the people who want their own data, or the ability to share/republish their own data, there’s some good potential there… and I hope to see more of it in the future.

Categories
Uncategorized

Pachube Learning

Pachube I first heard of Pachube shortly after it launched, and took a look at it, but didn’t really have any data to feed it. Then they started charging for the service, so I never pursued it, and then they got acquired by LogMeIn, and became free again, so I figured I’d check it out.

If you’ve seem my posts about logging the temperature and humidity, then you can guess what data I started feeding into Pachube.

Take a look at the feed Environment for a constantly-updated view of my office. We’re tracking the temperature and the humidity, but I’d also like to add a photocell (light sensor) and occupancy sensor (PIR) at some point.

I dabbled in Processing code, but ended up going back to Perl after some instability. There’s still some issues with bad data I need to sort out. (See below.)

Bad Data

There’s not a lot of amazing code in place yet, as it’s all learn-as-I-go experimental, but that’s fine with me…

Pachube iPhone

I mean, as it stands right now, I can quickly see the status of my office from anywhere in the world as long as I’ve got a mobile phone and an Internet connection. That alone should be worth something…

I’ve been adding updates along the way over at the project page on the Milwaukee Makerspace wiki. I’m sure I’ll have more blog posts on this, but smaller updates will probably just show up on the wiki.

Categories
Uncategorized

Safe Nuclear Disaster

Help Fund Community Radiation Sensors

After the Fukushima Nuclear Accident happened, I made a comment about the safety of nuclear energy. I’ll freely admit I am not an expert on such things, and a few friends called me out with some numbers, pointing out that more people died from coal mining disasters. (Though I’m still not sure that long-term, that’s true.) The difference in my mind, was that typically coal miners (and their families) are affected by coal mining disasters, while nuclear disasters have a greater chance of affecting the environment more, not just people, but animals, plants, and the world we live in.

After reading How I spent my Sunday in Fukushima by Sean Bonner, and seeing the fallout from this nuclear accident, I don’t know how anyone can think that nuclear energy is safe.

Again, I’m no expert, so if I’m missing something, please let me know.

The only good to come out of this disaster is the rise of Safecast, which is a global project working to empower people with data, primarily by building a sensor network and enabling people to both contribute and freely use the data collected. I’m a fan of data, and sensors, and sharing information, and if it can help people live safer lives, then all the better.

Categories
Uncategorized

Logging the temperature and humidity (code)

Temperature and Humidity

I’m always annoyed with myself when I don’t publish my code, so this is a follow-up to my Logging the temperature and humidity post.

This whole thing is definitely a work in progress. The hardware has exposed wires, and the software is all just cobbled together pieces. Making something that works is much different than making something that will continue to work, and work properly, and efficiently. Making something that works is a first step. It’s an important step, but it’s only the first step. So let’s begin!

I started with the example from Adafruit over on GitHub and about the only changes I made was to the format output of the data.

// Example testing sketch for various DHT humidity/temperature sensors
// Written by ladyada, public domain

#include "DHT.h"
#define DHTPIN 2     // what pin we're connected to
#define DHTTYPE DHT22   // DHT 22  (AM2302)

DHT dht(DHTPIN, DHTTYPE);

void setup() {
  Serial.begin(9600); 
  dht.begin();
  delay(1000);
}

void loop() {
  int h = dht.readHumidity();
  int t = dht.readTemperature();

  // check if returns are valid, if they are NaN (not a number) then something went wrong!
  if (isnan(t) || isnan(h)) {
    Serial.println("Failed to read from DHT");
  } else {
    Serial.print(h);
    Serial.print("\t");
    int temperatureF = (t * 9 / 5) + 32.5;
    Serial.print(temperatureF);
    Serial.print("\n");
  }
}

So this outputs the value for the humidity, then a tab, then the value for the temperature, and then a line return. Oh, I did change the code to output the temperature in Fahrenheit instead of Celcius. If we get a bad value, it’ll print “Failed to read from DHT” though I’ve yet to see that in the log files, I should probably take it out. Also, the Arduino just streams data at a fast rate, much faster than I need. I typically put the sleep functions (to limit the amount of data logged) in my reading code which runs on the computer. I think this is the right way to go, but if you have other ideas, please let me know.

Here’s a fairly simple Processing sketch that will read the data coming in from the Arduino. (Obviously you need the Arduino connected to the computer via USB.)

import processing.serial.*;

PrintWriter output;

Serial myPort;    // The serial port: 
PFont myFont;     // The display font: 
String inString;  // Input string from serial port: 
int lf = 10;      // ASCII linefeed 

void setup () {
  // set the window size:
  size(500,200);  
  println(Serial.list());
  myPort = new Serial(this, Serial.list()[0], 9600);
  // don't generate a serialEvent() unless you get a newline character:
  myPort.bufferUntil('\n');
  background(50);
  output = createWriter("output.txt");
}

void draw () {
  // everything happens in the serialEvent()
}

void serialEvent (Serial myPort) {
  // get the ASCII string:
  String inString = myPort.readStringUntil('\n');
  
    String[] words = split(inString, '\t');
    String humid = words[0];
    String tempe = words[1];
  
    background(50);
    textSize(40);
    text("   Humidity: " + humid, 40,90);
    text("Temperature: " + tempe, 40,160);

   output.printf("%d-%02d-%02d %02d:%02d:%02d\t%s", year(), month(), day(), hour(), minute(), second(), inString); // Write to the file
   output.flush(); // flush output
}

Besides displaying a small window with the humidity and temperature (seen at the top of this post) it will also log the data to a file named output.txt

Processing Output

2011-07-25 19:09:14     44      91
2011-07-25 19:09:14     44      91
2011-07-25 19:09:15     44      91
2011-07-25 19:09:15     44      91
2011-07-25 19:09:16     44      91
2011-07-25 19:09:17     44      91
2011-07-25 19:09:17     44      91
2011-07-25 19:09:18     44      91
2011-07-25 19:09:18     44      91

This is pretty terrible, as we’re getting way too much data. I should probably add some delay into the Processing sketch, as it’s creating a log file line much faster than the sensor can even output data! This will result in large log files and is just wasteful. If all I wanted was the window showing the current temperature and humidity, I’d probably just delete the logging part of the sketch. Add that to the TODO list. Anyway, it works, and as a proof of concept, it’s a start.

Here’s the Perl code I was using:

#!/usr/bin/perl

use Device::SerialPort;
use IO::Handle; FILE->autoflush(1);
my $port = Device::SerialPort->new("/dev/tty.usbmodemfd411");

$port->baudrate(9600);
$port->databits(8);
$port->parity("none");
$port->stopbits(1);

my $fileout = './templight.log';
my $filerec = './templight-recent.log';

open (FILE, ">>$fileout") or die ("Ooops! Could not open $fileout: $!");

while () {
    # Poll to see if any data is coming in
    my $char = $port->lookfor();

    # If we get data, then print it
    if ($char) {
	$time = localtime(time);
	if (length($char) > 1) {

		my $str = ($time . "\t" . $char . "\n");
		print FILE $str;

		open (FREC, ">$filerec") or die ("Ooops! Could not open $filerec: $!");
		print FREC $str;
		close (FREC);
	}
    }
    # Uncomment the following lines, for slower reading, 
    # but lower CPU usage, and to avoid 
    # buffer overflow due to sleep function. 

    $port->lookclear; 
    sleep (10);
}
close (FILE);

The logging here is a little better than the Processing sketch, at least we add some delay with that sleep at the bottom so our log files won’t be quite as large. We’re saving to two files, templight.log and templight-recent.log. The second one just saves the current data, this just enables us to grab the data from that file and do something else with it, like… send it to Twitter or something.

Perl Output

Tue Jul 26 04:30:39 2011        46      89
Tue Jul 26 04:30:49 2011        46      89
Tue Jul 26 04:30:59 2011        46      89
Tue Jul 26 04:31:09 2011        46      89
Tue Jul 26 04:31:19 2011        46      89
Tue Jul 26 04:31:29 2011        46      89
Tue Jul 26 04:31:39 2011        46      89
Tue Jul 26 04:31:49 2011        46      89
Tue Jul 26 04:31:59 2011        46      89

So our output from Perl looks similar, though we have much less data (but still plenty of data) and the date format is a little different. (Chalk that up to laziness.) Oh, the Perl code also has the serial port hardcoded to /dev/tty.usbmodemfd411, which is lame, and I do have code somewhere to grab the serial port dynamically, but I didn’t implement it yet.

Whew! It feels so liberating to publish all that terrible code… (I mean my own code, not Adafruit’s!) Now I feel the need to start re-writing it and making it less terrible.