Sunday 25 October 2015

A Nitpicker's Review of the Movie The Martian

I watched the movie last weekend, and I have to say that, overall, I was impressed by its technical correctness.

That said, I have to pick a few nits.

Martian Surface Gravity is Not One Gee
(For obvious reasons, such as expense) the movie depicts Mars' surface gravity at one gee (one Earth-normal gravity). In fact, Mars pulls about one-third gee. Movements would be different, and things would fall more slowly than here on Earth.

Cumulus Clouds
In one of the opening shots of the movie, Mars' sky is depicted with a row of cumulus clouds down near the horizon. That's a no-no. Clouds on Mars are wispy cirrus and quite high up.

The Dust Storm
Okay, there's a couple of things wrong here. Point one: a Martian dust storm approaching from a distance would not produce thick rolls of dust, as we see cascading down the mountainside towards the camp. Point two: it would not blot out the sky and make everything dark, as Mars' atmosphere is too thin for that. Point three: although the wind speeds are high in a Martian dust storm, Mars' atmosphere is so thin that it would be like a gentle summer breeze on Earth, with no catastrophic damage to infrastructure and human beings.  Point four: Martian dust is silt-fine, yet the movie featured particles the size of snowflakes. You don't even get that on Earth.

"I'll Implode"
While the protagonist records a log entry, he states that if the habitat lost pressure, he would implode. Quite the opposite, actually; his body would try to explode from the steep drop in pressure.

Items Dangling and Flapping in the Wind
See The Dust Storm, above. In one of the penultimate scenes in the movie, he's shown hauling a tarpaulin over the nose cone of the escape rocket. Said tarpaulin is strongly lifted by the breeze, flapping away like on Earth.  No.

Consumables
It's not clear where he's getting all that extra oxygen for long trips into the Martian desert.

The Spare Pathfinder
The movie depicts this as activating along with the one actually on Mars. Sorry, but this just wouldn't happen in real life. That said, I experienced a whoop of joy when he dug it up (something that could conceivably happen in future).

Takes More than Plastic and Duct Tape
In one scene, after losing pressure in the airlock, he's seen sealing the blown-out habitat with sheet plastic and duct tape and then re-pressurizing. Any high-school kid can tell you that it'd take a lot more than that to hold in the twelve pounds of pressure it's inflated to. The actual total pressure there would be many tons (about twenty-four, from a quick back-of-the-envelope calculation, assuming the diameter of the entranceway to be about six feet).

That said, it was a fun and inspiring movie, and I can only hope it's inspired the next generation of aerospace engineers.
-Bill

Wednesday 21 October 2015

A Funny Thing Happened
on the Way to an Election

There's no question that Prime Minister Stephen Harper was a master political strategist. His handling of Stephane Dion and Michael Ignatieff proved that, along with his artful management of a once-minority government. An artful manipulator of the media, he deftly sidestepped his opponents' strong points, pointed out their perceived weaknesses, and bought himself a decade of power.


But, this time around, he made some critical mistakes, especially in the last few weeks of the campaign.


Let's examine what I think are the key ones.


Too Long a Campaign

This near-record-setting campaign was just too damned long. I know Harper thought he needed that amount of time to deliver his message effectively; and at first it seemed to be working. But as the long weeks ground on, it only gave people more time to think and to decide that Stephen Harper's Canada is not the Canada we want. Add to that the Mike Duffy trial and other things, it was enough, in the end, to tip the scales in the wrong direction.

"Justin's Just Not Ready"
You know, you have to have a certain respect for Canadian voters. Simply repeating a mantra and hoping it'll stick doesn't work; we Canadians can think for ourselves. Being told repeatedly, day after day, that Justin wasn't ready got dull. It was repeated way too often. It took the sting out of it. And it was petty and mean-minded. I think we resented it, in the end, and, again, the facts came out. And I think it backfired.


People already knew that Justin had nice hair and, come to think of it, a whole lot of other positive attributes that people could never find in Harper. With Harper, it was always the same story, the same dull guy with eyes like a dead haddock and a bad toupe, the parrotting of US foreign and drug policy, the embarrassment on the world stage. People recognized that Justin was, in fact, a nice guy, someone you wouldn't mind having over for dinner--with the advantage that he had political smarts. He took the high road while the Cons waded through the muck, American-style.


One fact: Justin is perhaps more ready than any before him. Don't forget that he was born at 24 Sussex and has years of political experience at this point. Politics is in his blood. Oops.


Extending Maternity Leave to 18 Months

This is a no-brainer. Harper was seen, by his mean-old-Conservative base, i.e. the diehards, to be handing over even more of their hard-won money to people who didn't deserve it. You've got to respect your own constituents, and Harper forgot that.

"The Price is Right" Fiasco

As the campaign wore on, people got tired of the message that only the Conservatives could effectively manage Canada's economy.  Once again, the facts came out: Harper's economic record was poor indeed--one of the worst since the Great Depression. Most years, the Conservatives ran huge deficits. That was conveniently forgotten as the government shouted from the rooftops that Justin would spend us into the poorhouse. Fact is, Justin's promise of a 10-billion-dollar deficit was about par for the course for the Conservatives, except, of course, in election years. Harper's desperate attempt to portray it as something it was not was irritating, annoying, and insulting.

Rob and Doug Ford

In the last days of the campaign, as Harper's advisors made clear the fact that he was about to lose, Stephen got desperate. He courted the Ford brothers--yes, there was ol' crackhead, drunk-driving Robbie preaching to the converted. Problem is, Ford Nation is actually pretty small--and small-minded. Outside of the GTA, it's just not a factor. But Harper cozying up to the Fords was too much for many people outside of that region, who might otherwise have gone ahead and voted Con. The Liberal sweep in Atlantic Canada would seem to confirm this. I have great respect for maritimers (I am one, myself). They know the smell of rotting fish from a mile away; and, in that sense at least, the Fords stink to high heaven.

His Autocratic Nature

Stephen Harper is an autocrat. Throughout his terms in office, that much was very clear. Global warming isn't happening. Scientists don't know what they're talking about. It's my way or the highway. Canada's New Government. The Harper Government. The recession isn't happening (twice). I think, in the end, he pulled the rug out from under his own candidates, by not giving them a voice--because only Uncle Stephen could beat those big, bad Liberals.

Conclusion

The final outcome was almost pre-ordained; Justin Trudeau won a majority, and Harper tried, rather lamely, to turn his concession speech into a victory speech. He couldn't even bring himself to say that he was quitting. A sad exit for the master political strategist.

Disclaimer:

I am not a Conservative Party supporter.

-Bill


Tuesday 29 September 2015

The Weather System

My weather server is a Linux (Ubuntu) server configured with Apache2.


The server runs 24/7 as a high-availability system.  I also have a test server running on a VM (VirtualBox) on another machine, and it's saved my bacon more than once.


The server system as a whole is comprised of a number of programs which interact with one another.  For example, there is wxOCR (a GUI program, which I'm going to have to rename before open-sourcing it), which captures local data from an LCD panel.  When it rains, the system knows it and automatically appends a second condition (Rain)  to the sky condition.  Every five minutes, a cron job fires off another suite of programs which capture information from the web--statistics, records, forecasts and normals from 27 locations.  Another GUI program captures the webcam image and deduces the sky condition from it.  These all feed into the server system.


The server captures data as it comes in, after a short delay to eliminate file collisions. Each location has an independent database which tracks all data. Pages are updated every five minutes from templates.


The template language is fairly simple and yet highly complex.  Housed in <@ > tags, there are thousands of tags for data-output; every statistic tracked by the database can be output in this way.  Optional suffixes, separated by colons, control the way the data are formatted (including alternate measuring units, dependent upon the source data), and the source itself (any tag can pull data from any location, allowing multiple locations' data on one page).  There are loops and constants, to make it easier to show ordered data (hourly, daily, monthly, yearly). Essentially, the weather engine is acting as a HTML pre-processor.


A number of tags can be used to pull statistics from the system, as you'll see on the Diags page.  In addition, a number of control parameters can be set and modified using a system configuration file.


A number of queries are possible, from raw data to webcam archives and even recalculation of the database from source readings (not as relevant now that the system is working properly).  Extra web pages allow input of daily statistics and a second sky condition (ie; Cloudy, Snow).


Graphics are another big part of the system. Both canned graphics and on-the-fly charts are used.  A special facility allows such graphics as wind direction to be displayed.

The system also maintains an events database (meant for astronomical events, seasonal markers and time changes, but applicable to anything, really) and associated output tags. Events can be listed forward and backward in time.

The entire system is written in a modern, OOP version of Pascal, known as Lazarus, which includes an IDE. It compiles to native code.
Given Lazarus' write-once, compile-anywhere philosophy, I could come up with a version for Windows in about 15 minutes; I prefer Linux for its stability and open-source tools. Pascal is not that different from Java or C; in fact, in my last job, as Java Developer, on my first day I hadn't written a line of Java code.  By the end of the day I had designed a page and underlying services, with the help of Apache Tapestry, a GUI add-on for Java. But I digress.

Bugs are tracked through Bugzilla, and the source code is backed up on a Subversion server.  Both of these are also on the weather server itself.


The project consists of about 20,000 lines of source and is slowly growing to the point where it's difficult for one person to maintain.  This, too, will be open-sourced eventually.


You've got to see it to truly understand.  It's available at 

http://mizar64.dyndns-home.com:64180/weather.html.

-Bill


Saturday 22 August 2015

Advance and be Recognized

Another important component of my weather server (MetCommand-Home) is the sky-recognizer program.

Every five minutes, a webcam aimed out of an upstairs window snaps a shot of the sky. Usually, that's as far as it would get. But I wanted to have real observations, and not something I'd be having to update manually every few hours.

I finally settled on programming something, wxSky, that would do the job.

wxSky examines the pixels of an image and comes up with an observation. Currently, the list of observations is:

- Sunny (daytime only)
- Cloudy
- Twilight
- Clear (nighttime only)

The sky condition is gauged by examining the colour channels of the image, both separately and together. The rules are relatively simple and are accurate at least 90% of the time, although it can be difficult to detect clouds on a summer's night--contrast that with winter, when the ground is covered by snow and glowing in all the light pollution, and the clouds light up just fine. Partly cloudy would be more difficult to detect, and I find that, 90% of the time, sunny or cloudy does just fine.

It is, of course, a GUI program, with an editable parameters file, Linux-style (in fact, the production version runs on Linux).


wxSky v 1.27

It's difficult to see in this photo, but in the upper-left-hand corner of the window is mostly administrative stuff--the time and date; the latest observation, the middle is a view of the picture as nine averaged zones, with the Sweet Spot (more on this shortly) highlighted. Below that is a box simply recording the last five observations.

The upper right-hand corner is a view of the average values for the nine zones of the picture. Three buttons--R, G and B--are for selecting Red and/or Green and/or Blue channels.

Finally, there is one composite (master) value--displayed for R, G and B channels (and combined). These are averaged values for the entire picture.

Below that there is the same display, but for the Sweet Spot, which is a user-selectable zone (1/9 of the pic).

Why all the RGB breakouts? Because different sky conditions are based on colour-channel values. Twilight is a deep blue, a bit of green, and almost no red. Sunny is a deep blue with a good helping of green and a little red. Cloudy is almost equal values of red, green and blue; or, at night, with significant red, some green and almost no blue. Easy access to those values is important when calibrating the program to a new camera.

Why a Sweet Spot? Because your camera could be facing in any direction or (like mine) be partially obscured in a particular zone. I personally find that zone 7 (lower-left corner) has the best values.

The output of the program is a single text file simply containing one line with the date and time of the observation, and the observation itself. This is handed off to wxOCR, the LCD recognizer, for incorporation into an observations packet.

The weather server (Centretown Observatory) is available at:
http://mizar64.dyndns-home.com:64180/weather.html.

-Bill

Wednesday 19 August 2015

Avast, Damned Thing!

[Edit 2015-08-22: I see there is an existing product for OCR'ing LCDs called, coincidentally, WxOCR.  I will have to change the name of the program.]

I really should have blogged, before now, on the wonderful little OCR (WxOCR) program that reads my home weather station's statistics from snapped JPEGs. It was a couple of years in the making, and put my coding skills to the test; but it's been running for at least three years, and running very well.

The Hardware
I have a home weather station, which consists of several outdoor sensors, wirelessly linked to an LCD display pad. I also have a spare ancient laptop and a 1024x768 webcam.

The Mission
To deduce the values of the readings on the display, accurately, cheaply.

It's Dependable
(In essence) what happens is that at five-minute intervals, cron fires off a message telling a shell script to snap a picture of the weather station's LCD display. Having done so, the photo is handed off to WxOCR, which analyzes the green portion of the image (for maximum contrast, and it's configurable--you can use red, green, blue, or all channels). Data are defined as Groups, Characters and Segments; for each character, the expected location of each segment area is scanned and compared to a control value to determine whether it is lit, or extinguished. The LCD character has seven segments (we ignore any decimal point) which can correspond to the bits in a binary series; we add up the seven resulting bits to get a value from 0 to 127.  This is compared to a list of permissible values; if it's a match, then you've done one character, and move on to the next. If no match, a null is generated, which immediately halts processing for that number-group.

Later in the processing, the output values are herded into CSV format, along with the Sky Recognizer program's output, and handed off to the weather server.

So far, in about three years' operation, it has yielded probably hundreds of thousands of observations.  Most weeks, it is about 99.98% accurate.

It's Highly Configurable
All the configuration is via two files, one of which can be altered at any time and one of which is reserved by the system.  Most configuration directives are concerned with the placement of characters and segments.  Also, for each character, a control spot (a nearby area guaranteed always to be clear) can be defined by both position and dimension.  Characters can be configured horizontally or vertically, and optionally their individual segments can be defined.  Character groups can be interpreted is several modes: direct-read (for most things), darkest-segment-wins (useful for displays with a windrose), and (for precipitation) a running-totals mode.  A decimal point may be placed at any character position. Math (+-*/) can be performed on the character group at several points in its processing.

It's Error-Correcting
Because all of the values permissible must be defined, error-correction can be handled.  Partial characters, or characters with an extra segment in them, can be converted to their proper values.  In general, this works exceedingly well.

It's GUI
The program was designed from the outset to be a GUI program (screenshot below).  It's got everything I need to be able to position data groups quickly--or even the whole screen.  It even has 'second sky condition' buttons, plus a timer value; these are for situations where it's difficult for the system to detect; fog, snow, etc.

It's Linux
I need a rock-solid operating platform; but even the most-advanced Windows version needs to be rebooted regularly.  Therefore, WxOCR is built on Debian Linux and has essentially no downtime (it reboots weekly, three minutes early each Sunday morning).

But it ain't Perfect
It's a minor annoyance, but for whatever reason the character '2' is often missing the top bar, even though it's clearly in the image.  Technically, this shouldn't be happening.  It does anyway.  And, during the day, differences in lighting can throw off the threshold values established for each character. [Edit 2015-10-25: This is now essentially fixed.]

Nor Ever Will Be
It's almost impossible to get a perfect week's readings.  In fact, in all those three years, I've only seen it happen once.  This is for various reasons: the digits were themselves in transition as the pic was snapped; the camera shifted (damned cats); the contrast was poor in one particular image; and so on.  Plus, the camera can drift in aim and focus over time. I'd frankly like to see a commercial system (if one exists; I can't find one) with a better accuracy than WxOCR.

It's Still Evolving
I can still see more work I'd like to do on the program.  I'd like to add a four-way doodad for the individual characters in a group (refer to photo below).  I'd like to change slightly how the precipitation sensor works, to cut down on n/a readings from it.

It Needs to Go Open-Source
So far, I've not found another program that does what WxOCR does.  I really think this program needs to be open-sourced, and I'll do that in the near future.  I think it could really fill a (highly vertical, admittedly) need.

Here it is, in all its glory:


Image of WxOCRWxOCR v. 2.82

Wednesday 18 February 2015

A Proposal for Superluminal Communications Using Entangled Photon Pairs

For the life of me, I cannot understand why the following proposal should not work:

Exactly between two points (points A, B) in space time separated by an arbitrary distance (point C), position a photon generator and a beam splitter.  Then generate photons, split them into entangled pairs, and send them towards (A) and (B).

An entangled pair of photons is linked; the destiny of the one is the destiny of the other.  The effect is instantaneous, no matter how far the particles end up separated in space time.

At each endpoint (A, B), there are just two pieces of equipment:  a photon detector, and a shutter positioned slightly ahead of the detector.  Each endpoint takes turns sending and receiving.

When it's A's turn to send, sliding the shutter closed will intercept the incoming photon, causing its entangled partner also to extinguish; thus the detector at (B) will detect nothing; call that a 1.  If A does not slide the shutter, the photon can continue, then the detector at (B) will register a photon; call that a zero.

When it's B's turn to send, the same situation obtains at (A).

Granted, this method requires a source of photons to be positioned in advance.  Depending upon the separation of (A) and (B), it could be years before the stream of entangled photons is available to be manipulated.  Also, it requires extreme coordination for the entangled pairs to arrive at both stations simultaneously.

This communication method could be tested using present-day equipment.

-Bill