Archive for the ‘Documentation’ Category

Temperature graphs from EXIF header

January 15, 2011

In case it’s interesting to anyone I generated simple graphs showing temperature change when sending a camera up in the air using the tags in the images.

These two are from a camera attached to my kite on different winter days.  You can see how the temperature decreases about 1C every 100m of altitude and the camera then gets warmer again while lowering the kite back to the ground (up to about -4C), nothing surprising in there.

(I was curious what the minimum was the camera would operate in since Li-ion and Li-poly batteries are known to perform poorly in sub-zero temperatures, most of the time giving less than 3V.  My Canon was showing “change batteries” all the time but then showed 65% again when warmed at home.)  Well, here’s a gnuplot graph from a near-space balloon flight, unfortunately with much fewer data points, where you can see that a Canon G11 still works in under -20C.

I extracted these temperatures from the headers of the images taken by the seven Google Android branded high-altitude balloons at Greg Klein’s page, launched in November reaching over 100000ft. There are only 15 pictures on that page and they possibly come from different balloons as the seven balloons were launched over a period of 2 hours.  The page also mentions that the balloons had battery powered USB power supplies so that the cameras wouldn’t stop working in the cold of near-space, but that seems to be only for the GoPro ones and the phones, not the Canon G11 (the Canon models I’ve seen can’t even be powered fromUSB).  It’s curious how the graph doesn’t drop below -20C, possibly this is the sensor’s limitation and the temperature actually got much lower.

Update: I did the same with a few pictures from the Hollands Hoge Hogte project‘s near-space balloon launch of last August, which also featured a CHDK equipped camera.  Here the camera was in an insulated styrofoam box and it was the middle of summer so the payload was well protected from the cold.  It reached just below 100000 feet with minium temperature of 8C inside the box.  The graph is again suffering from only partial data, the few data points on the far right are from pictures taken by the camera as the box was floating in one of the Dutch bays just before recovery by a boat.

For some background, most programmable chips these days have a sensor of own temperature, an average cell phone probably has a number of them even if the phone doesn’t use or expose the measurement results in any way.  My old Palm PDA for example had an unused temperature sensor in the touchscreen controller that could be read when Linux was hacked onto the device.  The Canon cameras also measure their temperature and save the result in the images with 1 centigrade accuracy, at least when the CHDK open-source firmware is installed on them, (which seems very popular in many do-it-yourself projects like aerial photography and weather balloon launches).

Exporting javascript objects

July 16, 2010, the script that is part of my little ofono web-based client which I mentioned before, now lets its clients export their own objects as D-bus objects.  While not very practical, a full D-bus service can be written in javascript that way.  I added this capability mainly because ofono will now start using agent interfaces as part of its D-bus interface and other daemons, like connman and bluez, already have agents, so you need to be able to export an object to make a UI.

All other types of http requests remain as listed here.  The new (GET) requests are:

  • /path/to/object/export/<n>/ObjectName[;Interface.MethodOrSignalName,<in_signature>[,<out_signature>][;…]] – This looks complex but it just creates a D-bus object with the given name (arbitrary string, used just internally), and a given list of members on given interfaces. Members list is ;-delimited, each member is a signal or a method depending on whether it has an out signature.  New calls with their parameters are sent to the client in replies to the “idle” request using the same syntax as for signals from remote objects.  In turn signals from exported objects are emitted using the same syntax as method calls on remote objects.
  • /path/to/object/Interface.MethodName/return/[<value>[,…]] – Return a (possibly empty) tuple of values to a pending call sent in an “idle” request earlier.
  • /path/to/object/Interface.MethodName/error/<string> – Return an exception / error constant to a pending call sent in an “idle” request earlier.