Centretown Observatory:

2019-12-26

Two new faces have been added to the CTO crew roster. We now have Buddy, a General Assistant, and Furrrgus, Security and Greeter, in training.

Both were picked up at the Ottawa Humane Society, over the weekend.

Buddy:

Furrrgus:

-Bill

2019-12-16

I've made further progress with mcOCR. I'm adding a history feature; and I've got a couple bugs to fix. Expecting mcOCR V. 3.30 out soon.

As there have been some petty thefts lately, my doorway camera now archives all images (24/7; every 15 seconds) for one month. A notice to some similar effect will soon be posted.

-Bill

2019-12-14

Okay, we've settled down. I have mcOCR exquisitely adjusted for both my primary and backup sensors data capture. I note one bug, wherein bad values, which should be returning a nil, aren't; but are returning a zero, instead. Unsure whether that is in mcOCR or wxCondition; I'm betting on the former. I'll do some testing this morning and debug.

Incidentally, when I say 'exquisitely adjusted,' here's what I'm talking about. Yesterday, the primary-capture incidence of mcOCR recorded zero scan failures (a very common outcome) and one scan where error correction was required. The backup-capture incidence, which relies on absolutely shitty images, recorded two incidents of error correction. That's out of 288 separate images, of roughly 12 data items each—times two.

These are approaching professional/research grade figures—my ultimate goal for mcOCR.

-Bill

2019-12-11

We reach the first turning post of the winter season, today.

Because of Earth's orbital eccentricity, the earliest and latest sunrises and sunsets do not occur on the solstices (approximately June 21 and December 21). Instead, they are staggered around it. The earliest sunset comes on December 11, and the latest sunrise about New Year's Day. Shortly after that, in early January, we have perihelion (our closest approach to the sun for the year). Around January 17, we have traditionally the coldest day of the winter; and then the next turning post is the Vernal Equinox, on roughly March 22.

These are the turning posts that I use to keep track of the passage of winter. In summer, there are the same set of turning posts, but in reverse order.

-Bill

2019-12-10

So, we're two days into the monthly-reboot project; and—pow! Power outage. These used never to happen, but in recent years they are becoming increasingly common. That's one thing that I just can't guard against.

In all, the power was out for a couple of hours, and we lost data through that period.

Thankfully, the network came back up; and away we go.

I've fixed a few of the graphics-generation scripts; they somehow became broken.

-Bill

2019-12-08

I have upgraded the server computer to Debian 10/Buster. The upgrade process went fine; I have a bit of work to do around shifting it over to the new reboot schedule (we're going to try monthly).

Addendum: we've run into some problems post-upgrade. The weather cam is currently unavailable; and the disk, post-upgrade, was full, to the point where I couldn't even login to my desktop. I've managed to uninstall enough software to be able to get logged in, and get FileLight installed; and then I can see where my big files are. Hoping to get most of the issues resolved today.

Okay, I've got the webcam working again. Device changed names during the upgrade. Now just need to scare up some disk space.

Upate: as of 08:54, I've got the system back to where it should be. Turned out the logs archive was filling up. I'll need to give it some extra attention.

-Bill

2019-12-07

First: business. I have added two images to the Diagnostics page; they are the second-latest sensor capture images. Why second-latest? It takes time to capture and process an image. I'm feeling lazy today, so I simply hijacked the capture script to copy the last processed image just before taking a new image to be processed.

Now, on to other things...

It's December 7, a day that will, in the words of former US President Franklin Delano Roosevelt, live in infamy. Today is the seventy-eighth anniversary of the Japanese air attack on Pearl Harbour, Hawaii, in 1941. Back in the mid-Seventies, when I was a kid, World War II had been over for just 25-30 years; it was all disturbingly recent. Now, not so much; but I am more aware than ever that I missed the war by less than twenty years. And I think that that fact has played some role in shaping whom I am today.

It is important to keep the memories of such incidents alive, for if we do not remember them, then, as history itself teaches, we are doomed to their repetition.

Often lost in the hyperbole surrounding Pearl Harbour Day is the fact that at the same time, the Japanese attacked other places, including those in which Canadians had a stake. Hong Kong, for example, where many Canadian defenders died.

So, America, this morning's coffee is dedicated to you, but also to others, including fallen countrymen.

Cheers.

-Bill

2019-12-03

After careful consideration, my upgrades to Buster all went well, after all. Therefore, this Sunday morning I will be upgrading the server.

As part of the upgrade, I will be changing the server to reboot only monthly. We'll see how that goes.

-Bill

2019-12-01

I did not, in fact, upgrade the server this morning. One of my other upgrades buggered up, and I'm still trying to determine why.

I have redone the backup sensors capture stage. The camera has been backed off a bit, for slightly sharper focus; and the lighting has been moved more offside.

Still making fine adjustments, but the results seem to be encouraging.

-Bill

2019-11-30

Tomorrow morning, I am currently planning to upgrade the server to Debian 10 (Buster). This will require approximately two hours, beginning around 5am.

This used to be a semi-annual ritual, until I got wise and dumped Ubuntu.

Also, I will be upgrading the various other machines involved in the system; performance will be spotty at times, although we anticipate little actual data loss.

-Bill

2019-11-27

Quick updates. I have restored most of the query functionality to the website. A quick check this morning shows that the webcam images continue now to be archived properly. Also, this morning I replaced the batteries in the primary receiver; all readings have since returned to believable values.

This morning, I've confirmed that mcOCR will compile and run in Windows without further modification. This is another step forward. Release in three days. I've already drawn up plans for its further revision, with the addition of a history display/edit page.

I believe the webcam page is not functioning for queries at present. I will look into this.

-Bill

2019-11-26

I am now actively engaged in returning the website to full functionality, in the wake of the server reinstall, back in the spring.

Recently, I had noticed that archived images were not being displayed on the Webcam Query page. A bit of investigation yielded that they were not being copied into the archive.

A fair bit of digging later (I actually had to embed an ls command, to show the folder contents), I found that with the bumping-up of the webcam-capture script's frequency, from every five minutes to every minute, I had unintentionally introduced a problem. Let me explain.

Each minute, a number of jobs are fired off on my server—including a webcam-capture script. This used to run only every five minutes, starting at two after. Now, the first thing that the capture script does is to delete the existing image file. It is then replaced.

Now, at a few minutes after each hour, the archiving script runs. It looks to copy the image file; but the capture script has beaten it to the punch by deleting the file.

The solution, after all that, was simple: the first thing the archiving script does is to sleep for about ten seconds, thus giving the capture script enough time to generate a new image file.

It'll take about a month for the fix to show up. We'll always be missing those files.

-Bill

2019-11-23

Well, we've had about an hour and a half of downtime this morning. I accidentally deleted all the files in the capture-server folder. Took me some time to rebuild them. In the meantime, no images were being captured, so we've lost about 90 minutes' worth of data.

That's the first time I've ever done that.

In other news, I've begun to use StationBase, my DX'ers tool, operationally. It's got a ways to go, yet; but I think my data are safe at this point.

-Bill

2019-11-15

I've released version 2.20 of wxCondition (I'm going to have to rename it), the data-multiplexing utility. It now has the ability to apply simple arithmetic to substitutions. For example, you'll now notice that the CTO reading for Relative Humidity is now about 5% lower than the airport's—which is very close to reality; to do this, I added a multiplication factor of 0.95 (could also have made it a division factor of about 1.053).

I'll add that, Thursday morning, I was having major detection problems with the backup sensors. The images looked okay; it just wasn't capturing a lot.

For fun, I tried cleaning the webcam lens. Yeah—since then, zero errors, and under the worst-case scenario in terms of image quality.

I've fixed a couple of bugs in mcOCR. The first was that the precipitation unit was not defaulting back to mm, after processing a reading in cm. The other was that Limits operations (Floor/Ceiling, MinValid/MaxValid) were not respecting bad scans; therefore, a bad scan for temperature would always return 0, if there were a MinValid value specified. The reason is that the code for a bad scan is -30000; any lower limits were being exceeded. This is now fixed. As of this morning, we're sitting at Version 3.20, beta 14.

-Bill

2019-11-11

Good Remembrance Day.

I've made a few tweaks in response to ongoing problems with my backup sensors. Temperature and relative humidity readings are suspect, and increasingy unreliable. The backup transmitter is about one metre from the receiver. which really is losing its ears, to use an old radio term again.

At present, I am grabbing the airport's RH reading and looking for a new backup-measuring system. I've also noticed that the primary feed's barometric pressure reading was getting low, so I'm swapping in the backup reading when higher. Possibly the batteries are running low in the receiver unit; regardless, adding backup values was a good way to go.

I'm hoping to have new backup sensors in place sometime this week.

The release of mcOCR was delayed, as I keep finding small new issues with it. End of November.

-Bill

2019-10-28

I'm the partly-crippled guy you see walking all over Centretown. My left leg is stiff with arthritis, so I take very long steps with it. I tend to lurch. The overall effect, according to Tonia, is of riding half of a bicycle. Other people take my appearance for that of a shuffling garden gnome; so there you go.

It's been like that for about ten years, now, having started with a 10k walk, that I did way too hard, in Kanata, in 2009.

I get a lot of funny looks along the way; mostly, I expect, from people who just find the sight of me marching along to be... unusual. When I'm out and about with Tonia (height difference: 1 foot) we stop traffic, period.

And that's okay; because I'm working on my walking, long-term.

My goal is to walk about five kilometres per day. It's odd, but I've noticed that the more I walk, the faster my knees recover, and the better they are the next day.

So, I'm treating it as training. Each day I try to walk a certain minimum distance; that distance is slowly increasing as I progress. My goal is two-pronged; (a) to get my mileage up to about 40 km per week; and (b) to consistently walk over 10k on the weekend.

The bottom line is: I'm working on it. I'm making progress. And it's eventually going to carry me into new neighbourhoods. So, if you happen to spot me at the side of the street, marching along, please, throwing a makeup bottle out the car window and shouting "Cripple!" or "Fuckup!" or "Weirdo!" is disingenuous, to say the least. And, these days, I always have my camera at the ready. So do smile while you shout; it'll look better in court.

Thanks,

-Bill

2019-10-27

You may have noticed that I was having a problem with my backup sensors in recent weeks. The signal was growing increasingly intermittent; and, no basic changes having occurred in the signal path, I concluded that the receiver was slowly "losing its ears," to use an old radio term.

I have now moved the sensors to inside the window screen in the Server Room. It's separated from the outside air by a window screen. This will have some effect on the temperature readings on sunny days in the summer, as the sensor in its new position will be exposed to the late-afternoon sun in summer. I will do my best to mitigate that—when it becomes an issue. In the meantime, it means that the receiver shouldn't ever lose touch with the transmitter; and my backup readings are almost 100% reliable again.

-Bill

2019-10-17

I've fixed up the statistics generation/scan status indication in mcOCR. Now at version 3.20 beta 08. Still scheduled for release Oct. 31.

-Bill

2019-10-15

Well, as we sit through the second backup-sensors outage in recent weeks, I got tired of seeing zeroes in the relative humidity column; so I've restored an old rule. In the data multiplexer, wxCondition, I've established a rule to substitute airport data when the relative humidity reads zero. There should be no more stark dropouts in the RH data.

I have also spent some time on the News page this morning, and broken it out into a series of pages, by year. Looks better; much more accessible.

As to mcOCR, it's almost done. I swear. I promise. I just don't like how it generates and reports stats (there are some issues), so I'm re-doing that part. I have a firm release date for Oct. 31; the documentation is done; I just need a short test of the rejigged stats.

After I've spent some time on StationBase, I'll probably return to mcOCR, as I just keep thinking up new features.

-Bill

2019-09-28

Well, the big project at work is nearly completed. Also, the beta period for wxOCR is coming to an end. I have the documentation completed. I have one bug still to address; this morning.

I must say how pleased I am with the operation of the system, with the recent hardware replacements. For instance: captured data are now being published in the pages within a minute. The weather webcam is taking a snap every minute; the doorcam, every fifteen seconds. I now have almost eight years of accumulated weather data, at five-minute resolution. And the servers are hardly feeling the load.

I'll soon be turning my attention back to StationBase, as DXing season has returned. That product should rapidly progress to beta.

-Bill

2019-09-08

In spite of working 10- and 12-hour days for my day job, I'm still able to find some time for development work.

mcOCR is rapidly maturing as a releasable product. Version 3.20, β 03, is looking good, behaving well, and capturing near-perfect data. In anticipation of a release in early October, I'm working on the documentation for it now. I hadn't anticipated the workload associated with creating docs from scratch for 15 new screens, plus adding tips and tricks, specifications, an explanation on how characters and segments work, can be automatically calculated, etc. The important thing: it's coming along.

I've got β 03 running on both my capture servers now, and about the only thing that it cannot lock onto and provide perfect capture is the wind direction. Nothing much I can do if the character is changing just at the time the image is taken. At the same time, persistence is not generally a good idea with wind values.

-Bill

2019-09-01

The weathercam here at CTO is now updating its images by the minute. We certainly had the server capacity; and it doesn't really affect anything else. So there you go.

In other news, I'm about three-quarters of the way through Sprint 112 with mcOCR. I've added or will add some new features, like a visual indication of the scan status (Good, Bad, or Error Correction); a way to click and immediately adjust a character's contrast value; new control over your characters' appearance; and an autocalculation routine that has been rewritten from scratch. I've corrected some inefficiencies in the .ini file, made it look for either wxocr.ini or mcocr.ini; and it will write to mcocr.ini. The conversion is automatic. I'm adding a feature, too, that allows any character, mis-scanned, to take a specific value. I envision this mostly for displays with smaller decimal readings; you could set the mis-scanned character to 5 and therefore get, say, 20.5 instead of a bad scan. Another way to cut down on errors. I'm happy to report that with the existing new features as of version 3.10, the error rate already has dropped even further.

Even the backup scans, which I've come to rely upon as a sort of torture test for the program, are yielding near-perfect results, as I get the application tuned.

(Update 2019-09-03): I've completed the sprint. I took out a few items which, on closer examination, offered little benefit. My main goal lately has been to improve the usability of the program, and vastly improve one's ability to tune it. I strongly feel that I have accomplished both.

2019-08-25

I have just completed mcOCR, Version 3.10. I'm going to make it available for dnwnload, as-is.

I'm immediately starting work on Sprint 111, which will add some minor features and bring it up to Version 3.20, which is my 'final' vision for the program (for now). Once I have finished developing that version, there will be a public beta period of one month; and then it will be released.

Version 3.10 drastically simplifies the Settings screen, so that you select your Location, Value, and Character there. One click takes you to the properties screen, where you can choose another element to work on. The main settings screen is updated accordingly. Each time you return to the settings screen, it will be in the same state as you left it. There is now a very useful information box at top-right, outlining performance statistics for both Today and This Run. A 'Cycle' button allows you to cycle through your locations on the data display.

Coming in Version 3.20: a new autocalculation scheme that allows you to specify the segment width, as well as its offset. There will be no more need for a size specification, so your auto-calc declarations will be simply Auto H or Auto V. Some other new specs will be added, including Ceiling and Floor (Maximum and Minimum) values which constrain the values generated. Finally, there will be the ability to specify that the last character in a value is optional, for instances where the decimal portion is smaller and subject to frequent error. Better to get, say, 21.0 from a reading of 21.9, than no reading at all.

-Bill

2019-08-16

We are several days into our final hardware configuration, and it's looking good. Along with the hardware upgrades came an upgrade to mcOCR, version 3.00.

As a result, our figures have never been more reliable. Single-scan failures no longer factor in, as the last good value is used, to a definable number of iterations. I now have backup capture of everything except for wind readings. Let's have a short discussion on that topic.

Temperature, barometric pressure, etc., tend to vary at a snail's pace. In general, you're lucky to see a reading vary by two-tenths of a unit in the span of five minutes. Therefore, the chance of a scan occurring right as a character is changing is quite small (probably in the neighbourhood of 1/100,000 scans). Wind information, on the other hand, can be upated in as little as 15 seconds, and there frequently are major changes between readings. What this means is that the chance of a scan collision, as described above, can be as much as 1 in 1,000 scans. There is not much that I can do about that. To be sure, I'll be reviewing each misscan and trying to correct it through the settings. But, for this reason, data capture will never be perfect.

That said, I now have two sets of sensors for everything else. At present, backup data are scanned for the Indoors location, but not incorporated into the dataset. I'll be changing that soon; I'll route the data packets through the incoming folder on the server, and use wxCondition to substitute in the values, as needed. A powerful little tool, is wxCondition. As there is no public access to that location's page, the only visual indication will be that the error rate creeps even lower.

One other point of weakness worth mentioning: relative humidity. The main sensor here almost always reads "1"; therefore, I have to rely on the backup sensor. Now, the backup sensors are a bit of a stress-test for mcOCR; the camera is way too close and out-of-focus; and the background lighting varies highly from one end of the screen to the other—I'm sure you've seen pictures. Bottom line: the decimal in the temperature readings is very small, and often unintelligible visually. mcOCR usually manages to pull out the data anyway; but there is a bit of a failure rate. Probably always will be; and for that one reason, I will probably figure out a scheme to specify that, say, the last character is optional (i.e. 20.0 instead of a mis-read 20.1).

In other news, I'm slowly working on mcOCR version 3.10, which will feature a radically-simplified Global Settings screen, making it much easier to access settings fast. I've recently figured out a method of auto-calculating segments that would take into account such things as character slant, and the offset from the edge to the beginning of segments; I'll probably throw in a segment-width directive, too. I'll be incorporating all of that into mcOCR, eventually; I've its ongoing evolution mapped out as far as Version 3.20.

-Bill

2019-08-10

So, we are, at last, almost in our 'final' hardware configuration.

For the server, we're now running on a refurb HP Box with 4 Gigs of RAM. It's well more than enough for my needs. I'm really pleased that I was able to replace both my server and my development boxes with refurbs, for less than $300 in total. I can tell you that PC's are mature enough now that a recent refurb is nearly as good as a brand-new machine.

For the capture server, it's been on its last legs for some time. I've been nursemaiding it along, while it's lost its calibration and most of its ability to take input from the outside world. Just haven't had time to get to it. This morning, I'm replacing it with the screen-less laptop which has run the CTO server for the last several months.

In general, the only visible effect of the capture-server issues is that occasionally the wind velocity is absent, and of course the capture statistics are far from perfect. The backup sensors are filling in almost all the other readings. What we're missing is readings from the living room--something I'm sure that most of you will agree is far from critical.

(Update @ 13:00: the switchover has gone well. I thought I had issues; they were just configuration matters. Data capture has been perfect since the switchover. I'm just about to shut off the old capture server. I'm just going to throw it away. RIP.)

Now, there have been challenges in recent days. Wednesday, there was a late-afternoon thunderstorm, during which the backup LCD display was knocked slightly out of position. I finally figured out that a gust of wind must have jarred my shade screen, which in turn jostled the display. Anyway, I recalibrated mcOCR (which took all of one minute), and we were good again. Thursday, in the morning, the light blew out in the capture stage. Incidentally, it was a little eerie seeing it still capturing data from near-black images carrying practically no visual intelligence. Luckily, I caught it within a half-hour, replaced the light and managed to get it back into the same position. (One thing is critical with mcOCR: a consistent lighting position.) I've tweaked the settings a couple of times since, and it's again capturing nearly perfectly.

In other news, I'm slowly working on the next version of mcOCR. I'm working full-time and then some in my regular job, so I've curtailed my own development activities temporarily.

There is one other thing on which I've been meaning to comment—and, goodness knows, I never miss an oportunity to see my comments in print. In the roughly five years during which I've been collecting live local precipitation data, I've really noticed how much the local precipitation levels can vary from the airport's, from month to month, and especially in summer. The airport is less than ten kilometres away, as the crow flies; but that is enough that we can experience completely different weather systems in the summer, when small convective cells often roam the skies. In the winter, we experience much more frontal weather, and precipitation amounts don't vary as much.

Back in the eighties, I had a social-studies teacher, one Mr. Hutcheson, who recounted an experiment done with rain gauges in Winnipeg. They had installed several throughout the city. At the end of a season, they tallied up the results and compared. In summer, the totals differed, by surprising amounts. My own results would tend to confirm that original observation.

Moments like this are why I try very hard to remember everything. I don't always succeed; but I still remember a great deal of what I learned in school, some 35+ years ago. It serves me well enough.

-Bill

2019-07-13

I have an official release planned for wxCondition. Putting together the downloads now. For the moment, there will be a source dowload (all platforms), and a binary download for Linux-amd64 only. That will quickly change, as I am provisioning compiling environments in Linux-i386 and Windows-64. Win32 is not likely ever to appear. I don't have a Mac, to produce versions for that machine; but it would be a simple thing for someone to download the source and forward me the compiled results; it's just one file.

I am still working on the documentation for mcOCR; it turns out to be one complicated program, and a lot of explaining is required.

Meanwhile, I'm firming up plans for mcOCR v. 3.20. It will feature more diagnostic information on the front panel, and a greatly-simplified settings model that puts everything within two pages. Believe me, you'll thank me for that one! (When it eventually is released.)

-Bill

2019-07-09

I have a new version of MCH ready to go. I've been slowly recreating my test environment, but on a 64-bit VM, because I'd really like to test it before deploying.

There will be a brief period when observations will be cached, probably this afternoon, while I amalgamate some server functions. I do not anticipate any data loss.

mcOCR has been performing nicely in beta; and I've got it set up on a VM, suitable for demoing. Lagging on the documentation. Like I said; I'm not worried; I'll release it when it's ready.

I had a down period with the backup sensors, yesterday; you'll see the anomalies in the appropriate time period page. To be fair, the value persistence thing kicked in, and it shortened the downtime consideraby.

-Bill

2019-06-27

Crashes resumed this morning, with the issuance of the 5am forecast.

With the help of the GNU debugger, gdb, I've determined that the "access violation" was being caused by attempting to access element 0 of an array that starts at 1.

So I've narrowed down the bug that's causing the crashes. MCH maintains a list of forecast terms and their accompanying images. When a term is passed to the routine that searches for the term, if the term is not found, it is added to the list. That's not happening, now; so I've temporarily patched it to return a test-pattern image when it can't find the forecast term. I'm going to have to look deeper into my forecast-terms stuff; I suspect it thinks it's run out of entries (255), when really there are about 1,000 available. Probably a variable-sizing issue. I wish to note that it took seven years for the list to fill up, in the first place.

I'm confident that I can have this fixed by tonight. In the meantime, we should have no further crashes (famous last words, I know).

-Bill

2019-06-26

In the wee hours of Tuesday morning, we had a crash of the weather server. The error message was most unhelpful; it only said "Access Violation." Norally, I think of that as an I/O error. Several attempts to restart the system were met with the same error.

So, the weather system has been down for the past couple of days, while I worked up a version with the logging largely cleaned up, and that gives a log notification before and after completing any file I/O.

Copied it to the server machine, fired it up, waited for it to start regenerating pages at the top of the minute, and crash... and it trundled on. Still trundling.

Anyway, I'm in much better shape, should this happen again.

-Bill

2019-06-22 (updated 2019-06-23)

Progress on mcOCR. It's now in place, on a temporary server; I've got an IP cam taking pictures of the LCD readout. I can now retire the ancient, ancient capture server, a little Toshiba laptop that ran nearly continously for circa 20 years, and got by on 256 Megs of RAM (yes, you read that correctly). It started out its 'retirement' (from work life) as my network server, and even hosted the early iterations of MCH, the weather server. It's so old, it can barely run a GUI. I don't think I'm even going to hang onto it. RIP, old friend.

mcOCR is still heading for release. I've got to do some major work on the documentation this weekend, and I'm beginning to put together download skeletons (basic folder structures). I intend to release binaries for Linux (both 32- and 64-bit), and Windows (64-bit). I'll also release the source package, which is one version for all platforms. Right now I'm populating the skeletons with test files. They'll come preconfigured with test snapshots from two locations, and configuration files for both, so you can get going right away. The release date keeps slipping, but we're going to catch up to it eventually, because the To-Do list grows shorter by the day.

Update 2019-06-23: I realized that I wasn't saving my sky readings, so I've temporarily diverted them to a capture folder. I'll get about an hour-or-two's worth of sky readings, and bundle them together with the LCD captures. That way, one can fully test the system.

-Bill

2019-06-16

I am now ready to move mcOCR to production data-capture. For the past week I have run it on a parallel machine; its performance has been near-perfect. I've only had to do minimal adjusting.

Also, running mcOCR in two places gives me two places where I can enter manually-measured preciptation amounts, with the help of mcCondition. Most convenient.

mcOCR v. 3.00 should be ready to go in a week's time, so long as I get the documentation done.

-Bill

2019-06-09

mcOCR is now in beta (v 3.00b). I am finding a few bugs, but I still expect the beta test period to be over in a couple of weeks. I've got it set up now on a virtual machine, parallelling the production capture. I was pleased that it began just capturing data, with simplified settings (no massive sets of segment-threshold overrides, for example). Setting it up in a second location gives me a double-check on functionality, and a 'real-world' test case. At this point, I have two major goals: (1) fully debugging the program; and (2) revising the documentation.

That said, as alluded-to last Sunday, I've come up with a settings scheme which is much more usable. Instead of multiple settings screens, all nested, I'll have one settings screen, from which you can select your location, value, character, and segment. Properties screens and positioners will be available directly off the main settings screen. It'll simplify things tremendously, and make the whole settings regime much easier to access. I'm not going to do that one right away; I'll pencil it in for mcocr 3.20. Luckily, when the time comes, I've got the screen already mocked up; I've got one relatively simple screen to construct; and it will require only small changes to the existing screens—mostly button removal.

I'm doing my best to keep my capture server running. It needs a little extra TLC to get booted, now; luckily, I'm a very early riser, so I was able to get it going this morning. I think, though, that this will probably be its last week in service. I'm desperately trying to rig up some kind of machine to do the job when it fails.

I've noticed, with the evening sun now shining in the window where the CTO weather cam resides that the sunlight illuminates part of the backup-data-capture stage, causing misreads. To that end, I've erected a large sheet of cardboard to use as a shade; it seems to be working. My old saying: where there's a William, there's a way.

Catcha later.

-Bill

2019-06-02

We're back to regular 24/7 operation. No more crashes. That little timing problem, which I recently fixed, was the culprit.

mcOCR (the LCD-data-capture program) is coming along nicely. It's overwriting the .ini file, now; I've added a couple of new directives; I'm working on some internals now (value persistence, other things); and then I'll turn my attention to the interface.

In other news, backup data capture has become so reliable that I've instituted more substitutions; both the barometric pressure and the temperature will now go to the backup sensors when they are missing in the primary feed. Another step forward.

(Update 2019-06-04: I've completed Sprint 106 for mcOCR. The program now rewrites its own .ini file after processing each image; I've added some new internals and some new functions; it's capturing backup data; one more sprint, then a beta period, and then I'm done.

That said, I've already identified how I can make the settings much more accessible. Won't take much work, but, later...

-Bill

2019-05-28

mcOCR has reached the point where I've completed Sprint 105. There were quite a few items attached, and the list grew as I worked and debugged. There are still a few issues; I've got them written up for the next sprint. So, at this point, I am versioning it as 2.97b. It's settling in, capturing backup data.

There are a raft of changes to this version. Here's the short list:

• There is now a settings item for everything in the .ini file--no more text editing!
• The Settings pages are arranged in hierarchical order: Global, Location, Value, Character, Segment; plus positioners, sub-editors, etc. The original app was a one-pager. It is now comprised of some eleven pages, ten of which are for settings.
• It is now possible to convert values from one measurement system to another. In total, there are ten different conversions you can perform on your data (examples: Fahrenheit to Celsius; MPH to km/h; etc.
• The .ini file remains human-editable; and there remains a Reload button, to reload settings from disk.
• New Locations, Values, Characters, and Segments can be defined on-the-fly.

Anyway... have a good one.

-Bill

2019-05-17

I have restored CGI-BIN functionality. The minute I had that, I entered in rainfall amounts from during the outage (the "from" may sound funny, but it's necessary to establish chronology; i.e. I did not enter the amounts while the outage was occurring; but I digress). And, with that, my server migration is officially complete. I'm now running on the latest distribution of 64-bit Debian Stretch. Having a server with capacity to do meaningful desktop work is relatively new to me, on the home front.

And let there be no mistake about it: (the slightly conservative) I am a Debian man, through-and-through. I've tried and used many distributions over the past 27-odd years:

• Debian (of course)
• Slackware (Yay! Independent distribution!)
• CentOS (too stodgy even for me)
• ZenWalk (Recommended, BTW, if it's still current. Lives up to its name.)
• Mint (Ewww, MATE)
• Ubuntu (Ewww, Unity)
• AntiX (Crash city on older hardware)
• Corel (Remember them?)
• NetWinder (based on Red Hat, I believe)
• Arch (Another 'reference' distribution)
• Fedora (too different, too proprietary)
• OpenSuse (dogawful slab menu system)
• Puppy (cute, limited)
• Gentoo
• Mandriva (wasn't bad in its old incarnation)

Going even further off-topic, I was intrigued by the news that Microsoft will include a Linux kernel within Windows, to permit Linux utilities to run in a Windows environment. Okay--now we're making progress. There's a bunch of stuff in Linux that I wish to hell worked in Windows--and vice versa. This is a major step forward, for both interoperability and convergence.

Lo these last 20 years or so, I've had a dream: that you could run Windows and Linux stuff, concurrently and without a virtual machine, from a very Windows- like desktop. I can see another ten-or-so years down the road, when Linux has spread to billions of small devices and actual desktop computers have been relegated to light-server duties, where Windows becomes just another desktop manager available for a Linux-like platform. Frankly, I can't wait.

Interestingly, looking down the road, I might decide to do exactly what Microsoft has done. It's a pre-emptive move, because Linux can't really respond without containers or the like.

Anyway, I've pontificated enough. Have a good one.

-Bill

2019-05-13

I may just have tracked down what was causing the occasional crash. Looking through my crontab, I noted that some calls to the scripts that generate the graphics were occurring at roughly the same time that the scripts were being updated. I have a theory that occasionally a script was open for reading and executing at exactly the same time that the server was trying to open it for writing.

I've adjusted the timing under which the scripts run, and we'll see. I may have to implement a little fix for when files are in use.

I realize, in hindsight, that this also fixes the problem with inconsistent graphics generation, mostly noticeable in the Today page. Suddenly, they are always all present.

-Bill

2019-05-12

Okay, things are beginning to calm down here at the CTO.

Yesterday, I was able to copy my working development files to my 64-bit virtual machine, and load them into Lazarus. Test compiles worked. That's another step forward; I can now resume my development work.

Venus, the linux box, has been retired. I've recovered the drive from it, and hooked it up to copy over the data directly. (Again, I used that handy-dandy USB converter, and it went like a charm.) Next, I am going to junk it, as it has exhibited sketchy performance lately.

My next step is to experiment with my new Subversion server, to ensure that the pathing is correct.

At that point, I'm really in business.

Meanwhile, the capture server is on a death watch. I've drawn up a detailed plan to convert temporarily the securicam server to take up data-capture duties, just as I had temporarily repurposed it into a web server a couple of weeks ago. Fortunately, with Linux it's fairly easy to do.

Wishing you a decent week,

-Bill

2019-05-10

I've long noticed that hardware failures seem to come in clusters.

Venus, my long-running Linux box, probably 15 years old and my primary personal development machine, is failing. I first noticed yesterday, when I was logged into its 64-bit incarnation. I was in the middle of doing updates, when suddenly there were a steady stream of errors, because the drive had been remounted read-only. In Linux, it's usually specified right in /etc/fstab (a table of filesystems to be mounted at boot time): errors=remount-ro.

Quick as a bunny, I shut the system down. Tried to reboot; no go. Just for run, I tried booting into the 32-bit incarnation; lo and behold, that worked.

Now, I must explain that right now is a precarious time for developing at Demmery Software. My live development files are on a drive in the dying machine, and my backups on subversion aren't yet available.

Anyway, I've copied off my development files, so they're safe and sound. Later today, I'll copy them onto the 64-bit VM on my everyday machine. I'll just work from there, for now; and maybe in a couple of months, when I'm on a sounder financial footing, I'll buy a dirt-cheap refurb box to replace Venus, which I've shut down for the penultimate time and very soon will dispatch to the Long Sleep. It's already eaten a number of drives; it's a sign.

So, the roundup is as follows: dead server, dying development box, dying capture server.

While I was writing this, by the way, I managed to get my subversion server going. Thank Dog for that! And I think, with that, that gypsy has her full personality back, and some, as I've set her up as a NAS server. Nice machine; 6 Gigs of RAM; spacious hard drive; lots of wiggle room. It's a generation behind, but this thing easily has ten times the processing power of the machine it's replacing.

Have yourself a decent week.

-Bill

2019-05-07

It's the end of an era here at CTO. Yesterday, the city replaced the street light across the street. It was a low-pressure sodium lamp, and so for the past 25-or-so years, nighttime has featured a curtain of almost opaque orange light. I'm sure you're familiar with the effect.

The new streetlight is an LED fixture. It's not orange; and it's not blindingly bright; yet it lights up the area. Best of all, it's essentially full-cutoff, meaning virtually no light radiated in the vertical. As an amateur astronomer, I find this issue extremely important. And, of course, you can't beat the energy efficiency of LEDs.

For years, one of the stickiest problems I've had is to prevent stray light, from the street light in question, from messing up the webcam. What I've had for the last few years is an opaque strip along the window. The strip barely blocks the stray light, and the webcam is aimed high enough that you don't see it. (Spoiler: extreme bottom-left margin). I don't think I even need that now.

We had a data outage from Sunday afternoon to yesterday morning; the batteries in the transmitter ran out.

In the next few days, I will be testing mcOCR's new conversion functions; then I'll add to the backup dataset being captured and used.

The backup sensors are down this morning. I've reconfigured wxCondition to substitute in the value from the airport when the Relative Humidity still reads 1% after processing the backup value. Another step forward. I imagine the backup sensors will come back online on their own, in a few hours. Very soon now, mcOCR will be in Production, and I'll be able to deal with these dropouts much more quickly.

Incidentally...

Not to toot my own horn too loudly, but I'm something of a polymath, having attained a high degree of competence in many disparate fields. (Programming, bookkeeping, admin support, astronomy, cooking, writing/editing/publishing, script/screenplay writing, network/server administration, software testing, PC Technician, web design, meteorology, radio show management, audio production (recording) and post production (editing).) Potential employers are often put off by my resume, because I've done many things in my life, have little formal training and don't specialize in one area. The salient point is that I'm good enough to have made my living or otherwise be engaged for a long time in any one of those areas, and every now and then I run into an employer bright enough to harness more than one of my talents. Case in point: my current employer, TPG Technology. It's taken a few years, but they've come to appreciate that I'm not a one-trick pony. Now I'm working as a developer, software tester, and documentation author; and lately I've been dabbling in software architecting. Between the various USPS projects, there's plenty of work to be done. It feels good to harness more than one of my talents at a time; and, frankly, I don't give a shit if it doesn't look good on my resume. I am what I am: a chamaeleon. If prospective employers are too stupid to look at my resume and see that I've done most of the things listed above for significant stretches of time; and that with my tendency to serve both my employers and my clients for long periods of time, I can only have done so if I were, in fact, quite competent; well, the loss is theirs.

Have yourself a decent week.

-Bill

2019-05-05

I've noticed that some folders were restored incorrectly. I've fixed that, and am busy fixing charts now.

The CGI-BIN interface appears to be down, for the time being. I'll work to get that going again fairly soon.

I can now turn my hand back to development, until I can replace the capture server. That'll be a much-easier job. It occurs to me that I have three programs closing in on release; time to get back to 'em.

Incidentally, a roundup of the data we've lost:

• Webcam, Sky Condition and Relative Humidity, Dew Point, Humidex for April 18-May 3; for CTO.
• All Environment Canada locations for April 18-May 3. (Can be restored from public records.)
• In addition, there was a brief outage, caused by cleaning in the living room, interrupting data-capture for about an hour.

And, finally, here's a screenshot of mcOCR (pulling backup data out of its ass with crappy source photos) and mcSky both running comforably on the new server.

-Bill

2019-05-04

Well, something I had feared finally happened. At 1:04 am on April 18, my server died. It was an Acer Aspire laptop, with a whole Gig of memory, circa 2005. For the past six years it had been serving its final duty.

Anyway, that left me in a pickle.

Long story short, I got some replacement hardware, thanks to the generosity of my friends. For the past several days, I have been installing Debian Linux and matching its configuration to the old server's. Thankfully (I try to keep my feathers numbered for just such an emergency), I had a detailed, step-by-step plan for upgrading the server. I had long since gone through and identified pretty much every folder and file to copy over or adapt from. So I got all that done last Thursday evening. Now, to restore the weather server, first, I had to get some data into place. For that, I had the old (and fortunately still functioning) server drive. With the help of a fascinating, multi-interface USB adapter, I was able to access it. Slowly I put functionality into place, got basic networking looked after, restored all my services, restored all the weather data, began to reconstruct the weather system. That meant recompiling all my software for a 64-bit platform. Luckily, that went off almost without a hitch.

Around ten-thirty last evening, all of the subsystems were running. I took a deep breath, and started the weather server. It just worked, and proceeded to suck down two week's worth of data in about one minute (the capture server working through the downtime), and we were away to the races.

And now the capture server is giving hints about its impending death. That one is an even older laptop--circa 2000--and I'm surprised it even runs modern Linux. It's slow as death; the capture program functions in a sort-of slow-motion manner, trundling away for some seconds before generating capture results. Its days are definitely numbered.

Have a good week,

-Bill

2019-04-13

I've added some new graphs to some of the pages. For example, the Today and Yesterday pages have new graphs for wind speed and direction. This Month and Last Month have a new graph for dailly precipitation. Finally, This Year has a new graph for Monthly Precipitation.

The new version of mcOCR is coming along nicely; I'm still anticipating a release two or three weeks down the road. I'm working on it daily. Just finishing up on the settings pages. I still have to link a few things together, then I install on the backup server and test the hell out of it. I'll add any final enhancements and then install it on Production. Shortly thereafter, I'll release it.

With my new version of the software, I'm still waiting for a crash. Meanwhile, I believe I've implemented a re-launch feature which will mean little or no downtime if it does crash again.

Have a good one,

-Bill

2019-03-31

We're now getting crashes on a regular basis. I kinda suspect a corrupt file; to this end, I am running v. 4.84a, which adds some logging of filenames, so I can at least learn where the error is occurring. Apparently the error code means "Text file busy" when attempting to open for output; that's odd, because I know I'm closing all my files properly after processing. Hopefully, the extra information will be enough. If it becomes enough of a problem, then in the meantime I'll add an auto-relaunch feature in a bash script. (You'll hear often about bash, when speaking of Linux. Bash is a 'command shell,' a text-based interface between you and the computer, along the same vein as MS_DOS, or the Windows command line. Bash commands can be composed together into a script, which works like a simple program. Now you know.)

In other news, mcOCR is inching toward completion. I've almost got the Character Settings page perfected; then it's Values, Location, and Global--just fixups so the pages are 'perfect.' I still have to add a new display section, for current values; that won't take too long. After that, I have a bit of recoding to do (I/O routines, mostly); and value persistence to add. Then I'll be in fine shape. Say, two to three weeks. I'm learning not to be in such a hurry.

Backup data capture has been 'perfect' for some days, now. Took a little while, but I've finally got it adjusted just so. I'm pleased; it's capturing good data from really shitty images: unfocused, and poor contrast.

I've recently had a thought that mcOCR could indicate, perhaps in the file name, whether error-correction had occurred during the scan. It would require the ValidMap strings (simply a comma-separated list of scan codes and their character translations) to be structured in strict order; but it could work. I could even provide some visual indication that error-correction was used, via a new data-output tag. It would really be helpful in nailing down your configuration. I would implement it in such a way that it would be backwards-compatible with existing records.

An interesting observation about the last couple of days. The temperature has remained mostly above zero here in Centretown; the proof was that in the last eighteen hours or so, while Airport has reported mostly negative temperatures, and freezing rain and drizzle, there was no sign of an ice film on anything here in Centretown. We got three centimetres of snow, followed by rain; the new snow is mostly melted off at this point—hello, West Coast cold snap! This morning, the temperature is certainly trending towards the freezing mark; but the precipitation has turned to snow. I suspect Centretown is almost home-free. In fact, as I was completing this, Environment Canada lifted its freezing-rain warning.

In my ongoing quest for more-accurate data, I notice that the wind vane freezes up with every snowstorm. I suspect water is getting inside the housing; gonna have to lubricate it lavishly, come Spring (real Spring). Also, the next round of testing of mcOCR will involve conversions—Fahrenheit to Celsius; inches of mercury to millibars; etc. That will net me three additional backup data values—I'll have five in all. Won't be difficult to figure out how best to mix them with the production data.

Another observation: March came in like a lamb, and is going out like a lion cub.

And, fair warning. Statistics say that we're still due one last brush with winter, further complicating a so-far cold Spring. Meh.

I'll end on some good news: for the past ten years or so, my left leg has been a bit lame, due to arthritis. Lately I've been taking steps to ameliorate the condition; and so far, it's working. I walked four kilometres with my Goddess, yesterday morning, mostly pain-free and largely limp-free. Going out again this morning—just because I can. As they say, mind over matter...

Have a good one.

-Bill

2019-03-26

I've steadily been working on the data-capture program, mcOCR. It's coming right along, though I'm beginning to tire of wading through the settings. At this point, I'm finishing up with the Character Settings page (quite an involved page, by the way). then I'll back out, testing as I go, and get all the other pages completely finished. Then I have a couple more features to implement, and some bugs to kill. I tentatively estimate three weeks' additional work, at this point.

In other news, I've now got the Relative Humidity readings in an ideal place. wxCondition (the data substition program) now replaces the value coming from the main sensors with the backup value, only if the backup value is higher. Just switched over, and the RH jumped nine points. Future transitions will be more subtle, and should only be discernible when the main RH sensor abruptly cuts out, and there is a significant difference between the main and backup readings. That shouldn't happen too often. In the next few weeks, as mcOCR matures into its new form, I'll be testing its new conversion functions, allowing me to add four new backup values to the mix (Outside temperature, Inside temperature and RH, and barometric pressure. The display unit for the backup sensors displays values in Imperial/American, specifically for this purpose.

In sadder news, we've had to euthanize our dear little Sphynx cat, Teeka, who was the official Security Officer here at the CTO for the past nine years. This just seven months or so since we had to put to rest her adoptive brother, Elroy. There are pictures in the About section. Rest well, Princess; you had a wonderful life. Thanks for all the beard cuddles. Miss you.

May your week be better than mine.

-Bill

2019-03-09

I've been working steadily on the weather system, in little ways, to improve things. For instance, since its inception, the CTO weather sensors have been mounted on a pole over the back balcony. For years, it's been shrouded in tinfoil, to reflect solar radiation. Well, that wasn't working so well; so I've switched it up. I tried mounting an inverted ice-cream bucket (y'know; the half-gallon-sized, translucent-plastic tubs from Anonymous Dairy Products, Concord, ON. Yeah—one of those). So, first I tried covering the whole thing in tin foil, and mounting it atop the sensor. Just before I did that, I realized that I had created an ungrounded Farraday shield; and, grounded or not, there wouldn't be many radio signals escaping! So, I cut out a roughly-rectangular section facing the receiver.

Well, that was an improvement; but it was still warming up awfully fast in the morning. So, now the tinfoil is gone. In its place, the ice-cream bucket is now coated in a thick layer of white paint. It's an improvement--but already I can see the next iteration will simply be a whole bucket, spray-painted white. It will be really handy to have the current radio aperature covered up--since paint does not appreciably block radio signals. The morning heating is caused by the sun, shining at a very low angle, reflecting off the large window—and off the side of the building in general. Naturally, the radio aperture faces the building.

The new sun shield will be mounted to top of the sensor's Stephenson screen by way of standoffs, to reduce thermal coupling. Finally, the bottom of the sensor casing, which protrudes below the shield, will be painted white. The lid end of the tub, facing downwards, will be left open to promote circulation. I'll open a couple of vents in the top, so that warmed air can escape.

All of these efforts should reduce insolation considerably below its current levels; and daytime temperatures should more accurately reflect reality.

In other news (because I just love to see my own words in print, even if nobody else ever reads them), I'm making steady progress on mcOCR. I've got pages for Global settings, Location settings, Value settings, and Character settings. Each page (except Location) has a positioner to allow you to quickly position your onscreen elements. There are special editor pages for unusual things (validation maps, which equate codes from scans with real characters; output defintions, which let you tailor the output of the program). I'm completing the character settings area now. I've just finished the Valdation-Maps editor page; I still have a segments editor page to complete.

The new version will be a joy to use. I'm taking my time, making sure that each piece functions perfectly before moving on to the next.

By the way, I have here a self-congratulatory note from my landlord, bragging about how the construction work has been wrapped up for late February, as predicted. No—as predicted would have been within ten weeks. We're at forty, and as far as I'm concerned, the clock is still running. There are no eavestroughs at the front of the building--can we expect another massive scaffolding erection in the spring, when they have to come back and finish the job? The fencing and other infrastructure in the backyards still has to be done. Murphy knows how long the contractor will play that one out. When all is said and done, this 'ten-week' project will have taken a full year to complete. Folks will have been without the use of their backyards for a year--and still paying full rent. It's shameful. Just shameful. The lack of honest communications from the landlord shows that they're much more interested in their 'image' (an old broadcasting mantra is never to apologize for anything--you carry on as though whatever's just happened was planned all along) than in actually communicating with their tenants. This is what happens when you define a 'Communications' position, cripple it with rules, and staff it with someone holding a recent degree in Commnications. You get an unending stream of cut-and-paste bullshit, in which the landlord is always the hero. Very low signal-to-noise ratio. CCOC is about as good at communicating as NASA (and if you're as old as I am, you should know exactly what I mean).

Have a good week,

-Bill

2019-02-27 (Updated 2019-02-28)

I've been working hard on mcOCR, and it's paying off in spades. First off, in the process of implementing the new data model, I made a fortuitous discovery: when scanning segments, the scanner was simply reading in pixel 1, over and over again. No wonder I've been getting inconsistent results! It now locks onto every lit-up segment without fail. The surprising part, to me, is that it's performed so well over the years, regardless!

I've been working on making settings available in the program, and it's also going well. I've got a settings page, with a global position adjustor that pops up and lets you steer all the fields around the capture window. I've implemented a Locations Manager page, with a subsidary Output Definition page, where you tune the prrogram's output. I've still got Value Settings (and position adjustor), Character Settings (and position adjustor, and subdidiary segments-editor) to do.

I'm nearing a key test in the system: I'm going to install it on my server, in place of the existing instance, to capture backup data. I'll first copy over the .ini file from the server, to get it all pre-adjusted, so that it works on the first go. I'll have to do adjustments the old- fashioned way, via the .ini file, at first; but what the hey. I really want to test out its enhanced data-capture ability. (Update 2019-02-28: it's now running on the server, capturing backup data. 'Take a day or two to get it completely adjusted. Also: you can see by the webcam that the scaffolding is disappearing. Yay!)

Once I've got it fully implemented, I'll install it at the Production data-capture site. I'll take a break and move on to something else; then I'll work on fixing some long-standing bugs. The result will be a finished, bug-free program that just works. At that point, I'll release it as an open-source project, because I think it answers a need.

That's it for now.

-Bill

2019-02-17

I've completed testing v. 4.84. This version adds two new output files to its roster of tabular data files: wxg_mp.txt, which contains monthly data for last year; and wxg_dp.txt, which contains daily data for last year. I've got it generating two new charts on the test server—monthly temperatures and monthly precipitation, both for last year. They'll show up on the Production side following deployment.

I've just missed the deadline for rolling it out to Production, so it's scheduled for deployment on Sunday, Feb. 24.

In other news, I'm removing the accordions from most of my pages. I wasn't happy with the way they were working. I may search for a replacement scheme. Don't want to go with the Bootstrap Platform. I'll leave accordions in when they hide large stretches of repetitive stuff, in the middle of things. Also, I'm well into the process of turning the data-capture program, mcOCR, into a finished product. Things are going very well; I'm just adjusting how it captures and handles data, and i'm already generating the settings pages.

-bill

2019-02-13

We've just been through a major snowstorm, with the Ottawa airport reporting 29 centimetres of snow as of 07:30 this morning. Here at Centretown, we've recorded 27cm.

For CTO visitors, the after-effects are plainly visible: our weather webcam has been blocked by a wall of snow; it's slowly slipping down and melting against the window and should be gone in a couple of days (update: four hours was all it took). Meanwhile, it's showing interesting structure. I see lots of people heading out hopefully for work; seems the city has been busy ploughing roads, but hasn't bothered with even major-street sidewalks. Yeah. I'm a transit user; I'm not going in to work today.

I got outside early this morning and did some shovelling. Man/Woman, that felt good; and, okay, I've slowed down very slightly from my heyday. I did our walkway, then shovelled out the sidewalk as far as the two neighbouring walkways; cleared out exits, for lack of a better term, through the roadside snowbank—and helped a neighbour shovel out his car. I still do that fairly often; I am, despite my calendar age, still quite young and strong, and enjoy helping my neighbours. It's a great way to get to know them.

My girlfriend thought she had killed her computer this morning. She explained that she had rubbed it down with a damp cloth, and when she turned it on afterwards, she was getting an error message. Boot media missing; cable disconnected, was the gist of it. Luckily, I am also a crack computer technician. I opened it up, found that the hard drive had jarred loose (it had been a replacement and lacked the necessary mounting hardware). Quick as you like, I fashioned a cardboard shim, and it shouldn't ever loosen up again. Just tooting my own horn on that one. I've been doing some work as an installation and servicing technician with Kingscross lately, and I'm enoying the hell out of it.

<trumpspeak>That's me; great guy, great guy; works several jobs; local hero. <handgesture /> You'll love me.</trumpspeak>.

And let it not be said that I am unmitigatedly negative on everything. During our ongoing renovation project, the screen door was removed from our balcony, while one was added to our front door. At first, I was perturbed; then I realized it was a big plus. No screen door on the balcony means it no longer being snowed shut all winter; the one door opens inward, so we always have a route of egress in an emergency. We had an elaborate escape plan, involving a hammer and the living-room windows. Simpler now. Having a screen door in the front means we can lock it, open up the screens, and have some circulation here in the summer. (We're about 30 feet from the street, close enough that people occasionally wander in to take a boo.) So, thank you to CCOC for at least getting that part right. Notice, too, that I did not accuse the workers of peering in through the windows. Fair is fair.